Các giải pháp loại bỏ ảnh hưởng băng thông bất đối xứng ADSL đối với TCP/IP

Chia sẻ: Than Kha Tu | Ngày: | Loại File: PDF | Số trang:17

0
385
lượt xem
194
download

Các giải pháp loại bỏ ảnh hưởng băng thông bất đối xứng ADSL đối với TCP/IP

Mô tả tài liệu
  Download Vui lòng tải xuống để xem tài liệu đầy đủ

Giao thức TCP được sử dụng rộng rãi trên mạng truyền thông, đặc biệt trên Internet, cung cấp kết nối tin cậy và khả năng thích ứng tốt với nhiều sự thay đổi trong cấu hình và điều kiện hoạt động của mạng. Ngày nay, khi nhu cầu về truyền dữ liệu và sử dụng dịch vụ thông qua mạng và Internet phát triển nhanh chóng, nghẽn trong mạng trở thành vấn đề nghiêm túc và việc kiểm soát nghẽn trở thành một yếu tố quan trọng của giao thức lớp chuyển tải. ...

Chủ đề:
Lưu

Nội dung Text: Các giải pháp loại bỏ ảnh hưởng băng thông bất đối xứng ADSL đối với TCP/IP

  1. Các giải pháp loại bỏ ảnh hưởng băng thông bất đối xứng ADSL đối với TCP/IP Nguồn: khonggianit.vn I. GIỚI THIỆU Giao thức TCP được sử dụng rộng rãi trên mạng truyền thông, đặc biệt trên Internet, cung cấp kết nối tin cậy và khả năng thích ứng tốt với nhiều sự thay đổi trong cấu hình và điều kiện hoạt động của mạng. Ngày nay, khi nhu cầu về truyền dữ liệu và sử dụng dịch vụ thông qua mạng và Internet phát triển nhanh chóng, nghẽn trong mạng trở thành vấn đề nghiêm túc và việc kiểm soát nghẽn trở thành một yếu tố quan trọng của giao thức lớp chuyển tải. ADSL là một công nghệ cho phép truy cập tốc độ cao trên đôi cáp đồng thông thường. Băng thông khác nhau cho kênh truyền lên (upstream) và kênh truyền xuống (downstream) là đặc tính nổi bật của ADSL và ngược lại. Đối với TCP, đặc tính băng thông bất đối xứng của ADSL lại là một thách thức. Một yếu tố cho sự tin cậy của TCP nằm trong luồng hồi báo (ACK feedback flow) và được gọi là nhịp ACK (ACK clocking) [9]. Khi TCP được sử dụng trên đường truyền ADSL, các gói hồi báo (acknowledgement segment - ACK) cho luồng dữ liệu trên băng thông rộng downstream sẽ di chuyển từ phía client tới máy chủ trên upstream có băng thông hẹp. Gián đoạn hay chậm trễ đối với luồng ACK gây nên bởi nghẽn trên hướng upstream có thể dẫn đến sự gián đoạn hoạt động bình thường của TCP ngay khi hướng downstream không bị
  2. nghẽn. Trong tình huống xấu hơn, do luồng ACK bị ngắt quãng và không theo nhịp, bên đầu gửi có thể gửi khối lượng dữ liệu lớn một cách đột ngột (bursty) làm cho nghẽn xảy ra mặc dù bản chất cơ chế kiểm soát nghẽn của TCP là ngăn ngừa nghẽn trong mạng. Sự trễ của luồng ACK trên upstream cũng dẫn đến việc đánh giá sai về thời gian chờ để truyền lại (retransmit timeout) gây nên những sự truyền lại gói tin một cách không cần thiết. II. CƠ CHẾ KIỂM SOÁT NGHẼN TRONG GIAO THỨC TCP TCP/IP là bộ giao thức được sử dụng rất phổ biến trên mạng truyền thông, đặc biệt là Internet. TCP (Transmission Control Protocol) thuộc vào các giao thức chuyển tải và nằm ở lớp 4 theo mô hình OSI, phía trên lớp IP. So với dịch vụ lớp IP được coi là không tin cậy, TCP cung cấp các kết nối tin cậy dựa trên các yếu tố sau: - Các gói dữ liệu (segment) được đóng gói với kích cỡ thay đổi được tùy điều kiện mạng. - Mã checksum được tính cho toàn bộ segment. - Hệ thống hồi báo tích cực [12], kết hợp với số thứ tự (sequence number) cho mỗi byte1 được gửi và được hồi báo: bên nhận hồi đáp các dữ liệu đã nhận tốt trong một khoảng thời gian và bên gửi sẽ gửi lại dữ liệu nếu quá thời gian định trước. Đối với một kết nối TCP, mỗi byte gửi đi sẽ được gán một số thứ tự và bên nhận hồi đáp đối với từng byte được nhận. Trên dữ liệu gửi đi, phần TCP header chứa số thứ tự của byte đầu tiên của khối dữ liệu trong segment. Gói dữ liệu hồi đáp sẽ chứa số thứ tự của byte kế tiếp đang chờ nhận. Bằng cách đó, bên gửi biết tất cả các byte dữ liệu cho tới số thứ tự đó đã được nhận tốt.
  3. - Sử dụng kỹ thuật “cửa sổ trượt” (sliding window): bên gửi có thể truyền nhiều segment trước khi có hồi báo. TCP cũng hỗ trợ hồi báo tích lũy (cumulative acknowledgement) cho phép bên nhận hồi báo nhiều segment bằng một gói tin ACK. Khi gửi hồi báo về cho bên gửi, bên nhận có thể gửi kèm theo dữ liệu (kỹ thuật piggyback). - Sử dụng cơ chế quản lý kết nối để thực hiện thiết lập và chấm dứt kết nối, cơ chế điều khiển luồng đầu cuối-đầu cuối cho phép các nguồn dữ liệu có tốc độ khác nhau có thể giao tiếp được với nhau, và cơ chế kiểm soát nghẽn rất cần thiết cho mạng ngày nay. Cơ chế kiểm soát nghẽn 1) Các giải thuật kiểm soát nghẽn trong TCP Nghẽn xảy ra khi số lượng các gói tin đưa vào mạng vượt qua số lượng các gói tin mạng có thể xử lý được, hay nói theo cách khác, nhu cầu vượt quá tài nguyên hiện tại của mạng. Khi đó, các gói tin phải mất thời gian lâu hơn để di chuyển qua mạng, hoặc bị loại bỏ tại các hàng đợi bị tràn (overflow), làm cho bộ định thời (timer) ở bên gửi kích hoạt việc gửi lại các gói tin. Điều này làm tăng lưu lượng không cần thiết vào mạng đang trong tình trạng nghẽn và trầm trọng hơn tình hình, nhiều khả năng dẫn đến hiện tượng “sập mạng do nghẽn” [7]. Tình trạng nghẽn dẫn đến suy giảm hiệu suất tổng thể và lãng phí tài nguyên mạng (như băng thông, năng lực xử lý). Nghẽn cũng gây ra các vấn đề nghiêm trọng cho các hệ thống đầu cuối: sự sẵn sàng và thông lượng bị giảm sút trong khi thời gian đáp ứng tăng lên [13]. Cơ chế kiểm soát nghẽn của TCP cố gắng ngăn chặn nghẽn bằng cách kiểm soát
  4. và tăng dần lượng dữ liệu được đưa vào mạng. Khi nhận thấy nghẽn xảy ra, tốc độ truyền sẽ được giảm xuống tương ứng. Ngoài ra, cơ chế kiểm soát nghẽn cũng cho phép TCP thích ứng tốc độ luồng dữ liệu với tình trạng (thường thay đổi nhanh chóng) của mạng. TCP sử dụng một bộ các giải thuật kiểm soát nghẽn: khởi động chậm (slow start), tránh nghẽn (congestion avoidance), truyền lại và khôi phục nhanh (fast retransmission and fast recovery) [1], [9], [10]. Những giải thuật này rất quan trọng và cùng kiến tạo nên bộ khung cho cơ chế kiểm soát nghẽn của TCP. a) Giải thuật slow start Sau khi kết nối TCP được mở, nếu bên gửi tiến hành gửi ngay toàn bộ số lượng segment dữ liệu bằng với kích thước cửa sổ được bên nhận thông báo (advertised window size), các router trung gian và các đường kết nối có tốc độ chậm giữa bên gửi và bên nhận có thể gặp vấn đề tràn bộ đệm hay vượt quá băng thông kết nối (link saturation). Giải thuật slow start sẽ tránh tình trạng này. Bên gửi chỉ có thể gửi một lượng dữ liệu tới mức nhỏ nhất giữa cửa sổ nghẽn (cwnd) và cửa sổ nhận (receive window) được bên nhận thông báo cho bên gửi. Kích thước khởi đầu của cwnd là một segment. Sau đó, ứng với mỗi ACK nhận được, giá trị cwnd được tăng thêm một segment. Ví dụ, sau khi nhận được ACK đầu tiên, cwnd tăng lên thành 2 segment, và bên gửi có thể truyền tới 2 segment dữ liệu mới. Khi mỗi ACK của các segment này được nhận, cwnd được tăng thành 4. Việc tăng này gần với hàm mũ, cho thấy số lượng các gói tin được đưa vào mạng tăng lên khá nhanh. Bên gửi giữ nguyên trạng thái slow start tới khi kích thước của cwnd đạt tới một mức ngưỡng (ssthresh - slow start threshold), khi đó sẽ kích hoạt TCP chuyển sang trạng thái congestion avoidance, hoặc cho tới khi phát hiện việc mất gói. Các
  5. dấu hiệu mà TCP sử dụng để xác định tình trạng nghẽn mạng là sự vượt quá thời gian chờ (RTO) và việc nhận được các gói ACK lặp lại. Khi xảy ra nghẽn, ngưỡng ssthresh sẽ được giảm đi tới một nửa của kích thước cwnd hiện thời, và cwnd được gán giá trị là một segment (giá trị này thay đổi tùy biến thể TCP). Bằng cách này, TCP giảm tốc độ gửi dữ liệu và chuyển về giai đoạn slow start cho đến khi kích thước cwnd bằng hoặc lớn hơn ssthresh, hoặc việc mất gói xảy ra. Lúc này, giới hạn trên cho slow start bằng một nửa tốc độ khi xảy ra mất gói và được xác định bằng giá trị mới của ssthresh. b) Giải thuật congestion avoidance Giai đoạn congestion avoidance được sử dụng khi kích thước cửa sổ cwnd bằng hoặc lớn hơn ngưỡng ssthresh để thăm dò khả năng của mạng. Theo [1], khi giá trị cwnd và ssthresh bằng nhau, bên gửi có thể sử dụng slow start hoặc congestion avoidance. Trong một vài biến thể TCP, ssthresh có thể có giá trị cao, hoặc được cấu hình bằng với kích thước cửa sổ do bên nhận thông báo. Trong pha congestion avoidance, kích thước cửa sổ cwnd tăng lên tuyến tính và chậm hơn so với trong pha slow start, do cwnd được tăng lên một segment cho mỗi chu trình di chuyển (round-trip time), tức là đối với mỗi ACK không lặp (non-duplicate), cwnd được tăng thêm 1/cwnd. Việc tăng này diễn ra cho đến khi cwnd đạt tới kích thước cửa sổ mà bên nhận thông báo, hoặc tới khi xảy ra mất gói. Khoảng thời gian để cwnd đạt được giá trị cửa sổ mà bên nhận thông báo tính theo công thức slowstart_time = RTT x log2WS, trong đó RTT là thời gian chu trình di chuyển, WS là kích thước cửa sổ bên nhận thông báo tính bằng số segment [4]. c) Giải thuật Fast retransmit
  6. Một segment được truyền lại khi quá thời gian chờ gửi lại (thực chất là khoảng thời gian chờ gói tin hồi đáp). TCP có thể truyền lại segment bị mất nhanh hơn bằng cách sử dụng giải thuật fast retransmit, dựa trên nguyên tắc khuyến cáo bên nhận nên gửi ngay một ACK lặp lại khi nhận được một gói dữ liệu sai thứ tự. Khi nhận được 3 ACK lặp lại, giải thuật fast retransmit sẽ lập tức truyền lại segment bị mất mà không phải chờ cho tới khi quá thời gian chờ gửi lại. Sau đó giá trị ngưỡng ssthresh được gán bằng một nửa giá trị cwnd, với giá trị tối thiểu là 2 segment. Giá trị cwnd được gán bằng ssthresh + 3 segment, theo đó cwnd tăng thêm số segment gây nên ACK lặp lại (tức là 3). Đối với mỗi ACK lặp lại nhận được tiếp theo, cwnd tăng thêm 1 segment. Nếu giá trị mới của cwnd cho phép, một segment mới sẽ được gửi đi. Sau khi thực hiện fast retransmit, TCP sẽ thực hiện pha fast recovery. d) Giải thuật Fast recovery Do bên nhận chỉ tạo ra và gửi một ACK lặp lại khi một segment đã tới nơi, việc nhận được ACK lặp lại không chỉ báo hiệu một segment đã bị mất, mà còn cho thấy một segment đã rời khỏi mạng. Đó là lý do cho việc thực hiện congestion avoidance thay vì slow start. Pha fast recovery được sử dụng khi nhận được một gói tin ACK hồi đáp cho dữ liệu đã gửi. Kích thước cwnd được gán bằng giá trị ssthresh (đã được thay đổi trong pha fast retransmit). Thực tế, khi này giai đoạn congestion avoidance được thực hiện với tốc độ giảm đi một nửa so với tốc độ khi segment bị mất. Lưu ý rằng nếu quá thời gian chờ hồi đáp (retransmission timer), bên gửi bắt buộc thực hiện slow start. Giải thuật fast recovery được áp dụng đầu tiên trong biến thể TCP-Reno. Đây là
  7. biến thể được dùng phổ biến nhất. 2) Mối liên hệ giữa các giải thuật kiểm soát nghẽn Phần này sẽ mô tả hoạt động tương tác trong thực tế của kết nối TCP của các giải thuật kiểm soát nghẽn đã trình bày ở trên. Đầu tiên, giải thuật slow start được sử dụng để thử “sức chứa” của mạng và tăng dần số lượng các segment được đưa vào mạng, tức tăng dần tốc độ truyền dữ liệu. Nếu kích thước cửa sổ cwnd bằng hoặc lớn hơn ngưỡng ssthresh (được gán bằng kích thước cửa sổ bên nhận), bên gửi sẽ thận trọng hơn với việc tăng tốc độ truyền. Khi này, giải thuật congestion avoidance làm chậm lại tốc độ đưa các segment mới (chưa được hồi báo) vào mạng. Nếu phát hiện mất gói thông qua việc nhận được các ACK trùng lắp (3 gói tin ACK trùng lặp), trong khi chưa quá hạn thời gian chờ gửi lại, bên gửi sử dụng giải thuật fast retransmit để truyền lại segment bị mất, sau đó thực hiện fast recovery để đảm bảo tốc độ truyền không quá nhanh. Trong trường hợp quá thời gian chờ gửi lại, chứng tỏ tình trạng của mạng đã trở nên tồi tệ hơn, bên gửi sẽ phải quay trở lại pha slow start để thích ứng với trạng thái hiện tại (mới) của mạng. III. ẢNH HƯỞNG CỦA BĂNG THÔNG BẤT ĐỐI XỨNG CỦA ADSL ĐỐI VỚI HIỆU SUẤT CỦA TCP Ảnh hưởng của tính bất đối xứng trong băng thông ADSL đối với TCP Hiệu suất của kết nối TCP bị ảnh hưởng khi thực hiện trên đường kết nối ADSL. Hãy xem xét một ví dụ đơn giản với một kết nối TCP được thiết lập trên một đường dây ADSL có tốc độ upstream là 64kbps và downstream là 6.4 Mbps. Giả
  8. sử chiều dài của segment dữ liệu và gói tin hồi báo ACK có chiều dài tương ứng là 1000 bytes và 40 bytes. Đối với việc truyền dữ liệu theo một hướng, tức là dữ liệu truyền theo downstream và ACK truyền theo hướng ngược lại trên upstream, kênh upstream khi đầy sẽ chứa 64kbps/(8 bit/byte * 40 byte cho mỗi ACK) = 200 gói ACK di chuyển trong mỗi giây đồng hồ. Nếu mỗi gói ACK hồi báo cho một segment, sẽ không có hơn 200 segment dữ liệu có thể được gửi trong mỗi giây trên downstream, tương ứng 1.6 Mbps (khoảng 27%). Nếu có nhiều hơn 200 segment dữ liệu được gửi đi trên downstream, hướng upstream sẽ bị bão hòa và gói tin ACK sẽ bị loại bỏ, dẫn đến tình trạng tăng giảm đột ngột lưu lượng luồng dữ liệu trên hướng downstream. Nếu sử dụng một gói tin hồi báo ACK cho mỗi hai segment dữ liệu (khuyến cáo trong [1]), tốc độ dữ liệu trên hướng downstream đạt 3.2 Mbps (khoảng 53%). Việc sử dụng băng thông sẽ thấp hơn trong trường hợp truyền dữ liệu theo hai hướng, tức là khi đó hướng upstream được sử dụng chung cho gói dữ liệu và gói ACK, vì băng thông hiệu dụng cho ACK bị giảm xuống. Ví dụ nêu trên chỉ đề cập đến ảnh hưởng của sự bất đối xứng trong băng thông ADSL, mà chưa xem xét đến các điều kiện khác của mạng như tình trạng nghẽn trên hướng upstream, luồng dữ liệu giật cục, mất dữ liệu hay trễ. Hiệu suất của TCP trên đường truyền với băng thông bất đối xứng vẫn đang được quan tâm và nghiên cứu, đặc biệt là ảnh hưởng của ADSL đối với cơ chế kiểm soát nghẽn của TCP. Để đơn giản, trong các phân tích ở phần sau, chúng ta sẽ chỉ xem xét trường hợp đường truyền ADSL có một kết nối TCP, không có lỗi đường truyền, và chia ra hai trường hợp: truyền một hướng (downstream chỉ dành cho dữ liệu từ máy chủ tới client, upstream dành cho ACK theo chiều ngược lại) và truyền hai hướng (downstream và upstream được sử dụng chung cho dữ liệu và ACK). Phân tích Về cơ bản, cơ cấu kiểm soát nghẽn của TCP gồm bốn thành phần [6]:
  9. - Tăng chậm, giảm nhanh (additive increase, multiplicative decrease): cửa sổ cwnd được giảm một nửa (giảm nhanh) khi thực hiện truyền lại (do bị lỗi), và tăng lên 1 (tăng chậm) với mỗi chu trình di chuyển (RTT). - Sử dụng bộ định thời chờ gửi lại với việc ước tính RTO và giảm thời gian chờ gửi lại theo hàm mũ (backed off) khi bị mất gói tin gửi lại. - Khởi đầu chậm (slow start) để kiểm tra khả năng của mạng và tăng dần tốc độ truyền. - Sử dụng gói tin ACK để giữ nhịp: bên gửi dùng sự kiện nhận được gói tin hồi báo ACK để truyền gói dữ liệu mới vào mạng. Tình trạng nghẽn trên hướng upstream sẽ gây cản trở cho việc tăng kích thước cửa sổ cwnd trong giai đoạn slow start và congestion avoidance. Do thời gian thực hiện giai đoạn congestion avoidance dài hơn so với giai đoạn slow start nên ảnh hưởng tác động lên giai đoạn này cần phải quan tâm [11]. Việc trễ các gói tin ACK khi hướng upstream bị nghẽn cũng làm việc tính toán thời gian RTT và RTO không chính xác, dẫn đến giảm sút hiệu suất của TCP. Ngoài ra, sự ổn định của luồng ACK giúp bên gửi truyền các gói dữ liệu mới vào mạng một cách đều đặn. Do vậy, sự gián đoạn trên luồng hồi đáp ACK có thể tác động tiêu cực đối với việc truyền dữ liệu. Chẳng hạn số lượng ACK tăng đột biến trên kênh upstream sẽ làm cho lưu lượng dữ liệu trên kênh downstream tăng vọt và có thể dẫn đến mất gói hay nghẽn [2]. Đối với ADSL, do hướng upstream có băng thông thấp hơn hướng downstream với tỷ lệ từ 10:1 đến 35:1 [5], tình trạng nghẽn trên hướng upstream dễ xảy ra và ảnh hưởng tới hiệu suất kể cả khi hướng downstream hoàn toàn không bị nghẽn.
  10. Để phản ánh sự khác nhau về băng thông trên kênh upstream và downstream của đường dây ADSL, ngoài tỷ số bất đối xứng thông thường (là tỷ lệ giữa tốc độ hai kênh), người ta còn định nghĩa tỷ số bất đối xứng chuẩn hóa, là tỷ lệ giữa thời gian truyền gói ACK trên kênh upstream so với thời gian truyền gói dữ liệu trên kênh downstream. Nói cách khác, tính hiệu dụng của băng thông bất đối xứng được chuẩn hóa bởi tỷ lệ của số lượng các gói tin dữ liệu được gửi đi trên kênh downstream trong mỗi giây với số lượng các gói ACK quay về trong mỗi giây trên kênh upstream. Tỷ số bất đối xứng chuẩn hóa được đề ra đầu tiên trong [11]. Kích thước của gói ACK thường nhỏ hơn gói dữ liệu, do đó tỷ lệ bất đối xứng chuẩn hóa thường nhỏ hơn tỷ số bất đối xứng thông thường. Một gói tin ACK thuần túy thường có kích thước 40 bytes (gồm 20 bytes cho header của IP và 20 bytes cho header của TCP). Áp dụng cho ví dụ nêu trên, tỷ lệ bất đối xứng thông thường là 6.4 Mbps / 64 kbps = 100. Trong mỗi giây, có tối đa 6.4 Mbps / (1000 * 8) = 800 gói dữ liệu kích thước 1000 bytes được truyền từ máy chủ về client trên kênh downstream, còn trên kênh upstream có 64kbps / (40 * 8) = 200 gói tin ACK kích thước 40 bytes di chuyển theo chiều ngược lại. Do đó, tỷ lệ bất đối xứng chuẩn hóa là 800 / 200 = 4. Sau đây xem xét ảnh hưởng khác nhau đối với truyền dữ liệu một chiều hay đơn hướng, và truyền dữ liệu theo hai chiều. 1) Truyền dữ liệu đơn hướng Loại truyền dữ liệu này rất thường thấy khi người sử dụng tải dữ liệu xuống từ máy chủ, đặc biệt trong truy cập Internet. Như [9] đề cập, khoảng cách về thời gian giữa các gói tin hồi đáp ACK gửi trả về nguồn gửi được đồng bộ với khoảng cách về thời gian giữa các segment dữ liệu, cho phép nguồn gửi truyền đi các segment mới với khoảng cách về thời gian là như nhau (cơ chế tự đồng bộ - TCP self-clocking, hay cơ chế đồng bộ ACK - ACK clocking).
  11. Khi TCP hoạt động trên ADSL, khoảng cách thời gian giữa các ACK được giãn rộng ra so với thông thường khi các gói tin hồi đáp ACK phải chờ trong hàng đợi khi tốc độ của chúng lớn hơn tốc độ cho phép của kênh upstream với tỷ số bất đối xứng chuẩn hóa lớn hơn 1 [3]. Do đó, nguồn gửi sẽ gửi các segment dữ liệu ra với tốc độ chậm hơn. Điều này cũng dẫn đến kích thước của cửa sổ cwnd tăng chậm hơn. Nếu việc truyền dữ liệu tiếp tục diễn ra như vậy (tốc độ ACK lớn) trong một thời gian, khi bộ đệm bị đầy, các gói tin ACK sẽ bị loại bỏ. Giả sử bên nhận gửi ACK cho mỗi segment dữ liệu, trung bình sẽ chỉ có một gói tin hồi đáp ACK tới được bên gửi cho mỗi số lượng k segment dữ liệu đã gửi (k là tỷ số bất đối xứng chuẩn hóa), tức là số lượng gói tin ACK bên gửi nhận được sẽ ít hơn bình thường. Khi đó, bên gửi có thể gửi ra tới k segment dữ liệu cùng lúc, làm luồng dữ liệu trên kênh downstream trở nên tăng vọt thay vì đều đặn (smooth) và làm tăng khả năng bị mất gói dữ liệu. Luồng ACK giảm cũng gây cản trở sự tăng của cửa sổ cwnd [2]. 2) Truyền dữ liệu hai chiều Trong trường hợp này, việc truyền dữ liệu xảy ra trên cả hai hướng. Trên kênh downstream, ngoài dữ liệu lưu chuyển theo hướng từ máy chủ về client, còn có cả luồng gói tin ACK di chuyển theo hướng từ máy chủ về client để thực hiện hồi đáp cho dữ liệu do client gửi cho máy chủ trên kênh upstream. Trên kênh upstream cũng có các luồng dữ liệu và ACK tương tự như vậy. Băng thông kênh upstream đã thấp, lại phải chia sẻ cho dữ liệu và ACK, làm cho băng thông hiệu dụng cho mỗi loại segment giảm xuống, tức là làm tăng sự bất đối xứng và làm trầm trọng hơn hiện tượng nêu ở trên. Ngoài ra, do sự tác động qua
  12. lại giữa các segment dữ liệu trên kênh upstream và ACK lưu chuyển trên upstream mà hồi đáp cho kênh downstream, các gói tin ACK còn bị ảnh hưởng bởi vấn đề trễ và mất gói. Thông thường, segment dữ liệu có kích thước lớn hơn kích thước gói tin ACK. Theo ví dụ đã nêu ở trên, để truyền một segment có kích thước 1000 bytes trên kênh upstream, cần khoảng thời gian là (1000 x 8)/64kbps = 125ms. Nếu gói tin ACK xếp hàng sau những segment dữ liệu lớn như vậy, khoảng thời gian giữa các gói tin ACK sẽ bị kéo dãn, gây nên hiện tượng “khan hiếm” ACK. Gọi luồng ACK hồi đáp cho các segment dữ liệu trên downstream là ACK downstream. Bằng cách khảo sát quan hệ của tỷ số giữa kích thước của segment dữ liệu trên kênh downstream và kích thước của ACK downstream (af), và tỷ số giữa kích thước của segment dữ liệu trên kênh upstream và kích thước của ACK downstream (ar), và băng thông của kênh downstream và upstream, [11] đã chỉ ra rằng để giảm tác động của hiện tượng trên, nên duy trì tỷ số ar nhỏ bằng các sử dụng kích thước segment dữ liệu nhỏ trên kênh upstream. Các tác giả [11] cũng đề cập đến việc sử dụng hàng đợi fair-queue trên kênh upstream thay cho hàng đợi FIFO thông thường khi truyền dữ liệu theo hai hướng. Phần tiếp theo, một số nghiên cứu về kỹ thuật giải quyết ảnh hưởng của sự bất đối xứng băng thông cho TCP sẽ được trình bày. Một số giải pháp loại bỏ ảnh hưởng của băng thông bất đối xứng Như đã trình bày ở trên, yếu tố then chốt đối với cơ chế quản lý nghẽn TCP trong cả hai trường hợp truyền dữ liệu một và hai chiều là băng thông thấp của kênh upstream làm ảnh hưởng đến sự lưu chuyển của các gói tin ACK. Một giải pháp là giảm kích thước của ACK, qua đó làm giảm tỉ số bất đối xứng chuẩn hóa. Giải pháp khác là giảm số lượng gói tin ACK lưu chuyển trên kênh upstream, tức là
  13. giảm tần suất của ACK. Việc này đòi hỏi sử dụng một kỹ thuật đi kèm để cho phép bên gửi đối phó với luồng ACK khan hiếm (infrequent) do bản thân TCP không xử lý tốt trường hợp này. 1) Giải pháp nén TCP header Khi giao thức PPP được sử dụng trên đường kết nối ADSL, việc nén TCP header có thể được thực hiện. Mục tiêu của giải pháp này là giảm tỉ số bất đối xứng chuẩn hóa thông qua việc giảm kích thước của TCP header, tức làm giảm kích thước gói ACK. Giải thuật chi tiết có thể tham khảo trong [8]. Giải pháp nén này được khuyến cáo sử dụng cho môi trường có tỉ lệ mất gói thấp do cần thiết phải có sự đồng bộ giữa bên nén và bên giải nén. Hạn chế của giải pháp này là TCP header không thể được nén xuống bất kỳ kích thước nào, và phần mào đầu (overhead) của các lớp dưới vẫn chiếm tỉ lệ đáng kể. Ngoài ra, trong trường hợp tương tác giữa các gói tin ACK và các segment kích thước lớn khi truyền dữ liệu trên cả hai hướng, giải pháp nén không có tác dụng nhiều [2]. 2) Giải pháp lọc gói ACK (ACK filtering) Giao thức TCP sử dụng hệ thống hồi tiếp ACK tích lũy, tức là gói tin ACK cuối cùng nhận được có thể hồi báo (acknowledge) cho tất cả các segment truyền trước đó. Dựa trên cơ chế này, giải pháp lọc ACK thực hiện giảm số lượng các gói tin ACK lưu chuyển trên kênh upstream bằng cách loại bỏ một vài gói tin ACK trong hàng đợi. Để tránh tình trạng khan hiếm (starvation) ACK tại bên gửi, giải thuật sẽ loại bỏ những gói tin ACK thỏa mãn những điều kiện nhất định. Khi một gói tin ACK chuẩn bị được xếp vào hàng đợi cho kênh upstream, các gói tin ACK cũ hơn mà không phải là gói tin ACK lặp lại hoặc lựa chọn sẽ được loại ra khỏi hàng đợi, làm cho giảm số lượng ACK gửi trở lại cho bên gửi và cũng tăng chỗ trống trong bộ đệm (xem thêm [3]).
  14. 3) Giải pháp điều khiển nghẽn ACK (ACK congestion control) Đây là giải pháp hoạt động toàn tuyến, từ bên gửi đến bên nhận. Nó tương tự như cơ chế điều khiển nghẽn của TCP với bên nhận đóng vai trò chủ động trong giải thuật này. Điều kiện để áp dụng giải pháp này là hạ tầng mạng phải có khả năng thông báo cho bên nhận về tình trạng nghẽn trên kênh upstream, và bên nhận phải đáp ứng với dấu hiệu nghẽn mạng. Giải thuật RED (Random Early Detection) được sử dụng tại các router của mạng. Nếu kích thước trung bình của hàng đợi tại router vượt quá một mức ngưỡng định trước, các segment trong hàng đợi sẽ được lựa chọn ngẫu nhiên để đặt bít ECN (Explicit Congestion Notification) lên 1. Khi bên nhận nhận được gói tin ACK với bit ECN bằng 1, nó có thể giảm tốc độ gửi ACK. Bên nhận duy trì một hệ số trễ ACK (gọi là d), tính bằng số các segment dữ liệu nhận được trước khi gửi gói tin hồi báo ACK cho bên gửi. Hệ số d tăng theo cấp số nhân mỗi lần nhận được gói tin ACK có bít ECN bằng 1, như vậy làm cho tần suất gửi ACK giảm đi tương ứng. Nếu bên nhận không nhận được gói tin ACK với bít ECN bằng 1 cho mỗi thời gian RTT, hệ số d giảm đi một cách tuyến tính, do vậy làm tăng tần suất gửi ACK ([3]). Hoạt động này tương tự như nguyên tắc tăng chậm giảm nhanh (additive increase, multiplicative decrease) của cơ chế kiểm soát nghẽn của TCP. Một đề xuất bổ sung cho giải pháp này được nêu trong [11], với việc thêm tùy chọn mới cho TCP để bên nhận được thông báo về cửa sổ của bên gửi để bên nhận tính toán giá trị tối đa cho hệ số d. Giá trị tối thiểu của d là 1 (một ACK được gửi đi cho mỗi segment dữ liệu nhận được). Tùy chọn này là cần thiết do kích thước cửa sổ bên gửi thường xuyên thay đổi trong thời gian truyền dữ liệu. 4) Giải pháp ưu tiên ACK (ACK-first scheduling)
  15. Giải pháp này được sử dụng cho trường hợp truyền dữ liệu hai chiều với việc chia sẻ băng thông upstream giữa gói tin ACK và segment dữ liệu. Do kích thước của gói tin ACK thường nhỏ hơn so với kích thước của segment dữ liệu, nếu sử dụng hàng đợi kiểu FIFO, các gói tin ACK có thể bị trễ lớn khi sắp sau các gói dữ liệu. Giải thuật này giảm thời gian chờ của ACK trong hàng đợi bằng cách cho các gói tin ACK độ ưu tiên cao hơn các gói dữ liệu [2]. Đối với kênh upstream băng thông thấp, vẫn có thể có trễ cho các ACK do thời gian truyền gói dữ liệu kích thước lớn. Giải pháp cho vấn đề này là sử dụng kích thước segment dữ liệu nhỏ trên kênh upstream [11]. 5) Giải pháp TCP thích nghi (TCP sender adaptation) Sự khan hiếm các gói ACK do băng thông upstream thấp, hoặc có thể do tác động của các phương án nêu trên, có thể gây ra việc tăng đột ngột (bursty) dữ liệu truyền vào mạng và làm giảm độ tăng của cửa sổ cwnd. Vấn đề này có thể được giảm bớt bằng kỹ thuật áp dụng toàn trình. Đối với vấn đề tăng đột ngột lượng dữ liệu truyền vào mạng, có thể giới hạn số lượng segment dữ liệu tối đa bên gửi có thể đưa vào mạng, cho dù cửa sổ cwnd cho phép truyền nhiều hơn. Ngoài ra, có thể chia nhỏ burst dữ liệu lớn thành các burst dữ liệu nhỏ hơn, ít nguy hại hơn, bằng cách ước lượng tốc độ dữ liệu theo tỉ số cwnd/srtt [2]. Do việc tăng của cửa sổ cwnd liên quan tới băng thông còn trống trên kênh downstream, có thể giải quyết việc chậm tăng của cửa sổ cwnd bằng cách sử dụng số lượng dữ liệu được hồi báo bởi mỗi ACK (không phải là số lượng các gói tin ACK). Khi một số lượng các segment dữ liệu được hồi báo, cửa sổ cwnd sẽ được tăng lên với số lượng đó, như thể có một số lượng tương ứng ACK được nhận.
  16. 6) Giải pháp khôi phục ACK (ACK reconstruction) Giải pháp TCP thích nghi mô tả ở trên phần nào giải quyết được việc khan hiếm ACK gửi về bên phát theo upstream có băng thông thấp. Nhược điểm là phương pháp này đòi hỏi giao thức TCP phải được sửa đổi để thực hiện. Giải pháp khôi phục ACK là một kỹ thuật khác để giải quyết vấn đề khan hiếm ACK. Tại mỗi đầu cuối trên kênh upstream, một ứng dụng nhỏ gọi là “bộ khôi phục ACK” (ACK reconstructor [2]) được thiết lập nhằm làm giảm một cách hợp lệ các “khe hở” (về thời gian) trong luồng ACK sao cho luồng ACK trở nên “mịn” (smooth) đối với bên gửi dữ liệu. Các giải pháp như lọc gói ACK (ACK filtering) sử dụng ưu điểm của hệ thống ACK tích lũy để loại bỏ một số các gói tin ACK được coi là dư thừa. Theo cơ chế của TCP, nếu nhận được hai gói tin ACK liên tục, bên gửi có thể sẽ bơm vào mạng một lượng dữ liệu bằng chênh lệch số thứ tự (sequence number) của các gói tin ACK này và cửa sổ cwnd vẫn tăng lên 1 không kể đến số lượng dữ liệu đưa vào mạng, tức là việc tăng của cửa sổ cwnd được điều khiển bởi kênh upstream, không phải kênh downstream. Nếu có thể đưa một vài gói tin ACK xen vào giữa các gói tin ACK liên tiếp kể trên, lượng dữ liệu bơm vào mạng sẽ nhỏ hơn. Đây là cách mà giải pháp khôi phục ACK thực hiện để lấp các khoảng trống ACK, cho phép luồng ACK mịn hơn đối với bên gửi. Điểm mấu chốt của giải pháp là kiểm soát số lượng ACK và khoảng cách giữa chúng nhằm tránh việc bơm đột ngột số lượng dữ liệu lớn vào mạng và duy trì một cách hợp lý tốc độ tăng của cửa sổ nghẽn. Giải pháp này không tạo ra các ACK giả mạo và không gây ảnh hưởng đến hoạt động bình thưởng của cơ chế điều khiển end-to-end của TCP. Giải thuật tính khoảng cách (về số thứ tự và thời gian) cho các gói tin ACK xen vào được trình bày chi tiết trong [2].
  17. V. KẾT LUẬN Bài viết trình bày về ảnh hưởng của sự bất đối xứng về băng thông trên đường truyền ADSL đối với cơ chế điều khiển nghẽn của giao thức TCP. Do TCP sử dụng hệ thống hồi báo bằng các gói tin ACK từ bên nhận về bên gửi để đảm bảo việc truyền tin cậy và nhịp nhàng, việc gây nhiễu hay làm gián đoạn luồng ACK có thể dẫn đến việc suy giảm hiệu suất. ADSL chỉ là một trường hợp cụ thể của sự bất đối xứng băng thông ảnh hưởng tới hoạt động của TCP. Có nhiều mạng bất đối xứng khác như mạng chuyển mạch gói vô tuyến, mạng modem cáp, hay mạng phát quảng bá trực tiếp (direct broadcast); ngoài băng thông, trên thực tế sự bất đối xứng còn thể hiện qua cấu hình mạng hay tốc độ mất gói (loss rate). Việc nghiên cứu và cải tiến các giải pháp nâng cap hiệu suất của TCP vẫn tiếp tục phải được thực hiện để thích ứng tốt hơn nữa cho các môi trường bất đối xứng. [1] Số thứ tự gắn kèm với segment (chuẩn bị gửi) bằng số thứ tự của segment gửi trước (hoặc số thứ tự khởi tạo) cộng với số byte dữ liệu được truyền trong segment. Còn số thứ tự trong gói tin ACK là số thứ tự của byte đầu tiên mà bên nhận đang chờ để nhận. Như vậy, vô hình chung, mỗi byte trong khối dữ liệu truyền đi đều được đánh số. Nói như vậy không có nghĩa là TCP sẽ truyền lại từng byte khi bị lỗi, mà sẽ truyền lại nguyên một segment.

CÓ THỂ BẠN MUỐN DOWNLOAD

Đồng bộ tài khoản