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

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ị 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à 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á 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. m ch không cần thiết. - 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 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 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 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à 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ả 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]: - 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. Để 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). 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 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