Bài báo khảo sát một số giải thuật điều khiển tắc nghẽn thông dụng dùng trong các hệ điều hành window và Linux như TCP-Tahoe, TCP-Reno, TCP-NewReno, BIC-TCP và CUBIC. Trong từng giải pháp, các cơ chế điều khiển cửa sổ tắc nghẽn sử dụng các hàm khác nhau được phân tích và so sánh dựa vào mức độ tận dụng tài nguyên mạng của từng giải pháp. Mời các bạn cùng tham khảo!
Trang 1Khảo sát giải thuật điều khiển tắc nghẽn cho luồng
TCP
Nguyễn Xuân Khánh
Khoa Viễn Thông II, Học Viện Công Nghệ Bưu Chính Viễn Thông Email: xuankhanh@ptithcm.edu.vn
Abstract— TCP (Transmisssion Control Protocol) mang hầu hết
các lưu lượng trên Internet, vì thế hiệu năng của Internet phụ
thuộc rất lớn vào TCP thực hiện như thế nào khi truyển qua
Internet, nhất là hiệu quả của giải thuật điều khiển tắc nghẽn mà
TCP sử dụng Bài báo này khào sát một số giải thuật điều khiển
tắc nghẽn thông dụng dùng trong các hệ điều hành window và
Linux như TCP-Tahoe, TCP-Reno, TCP-NewReno, BIC-TCP và
CUBIC Trong từng giải pháp, các cơ chế điều khiển cửa sổ tắc
nghẽn sử dụng các hàm khác nhau được phân tích và so sánh
dựa vào mức độ tận dụng tài nguyên mạng của từng giải pháp
Keywords- TCP, Điều khển tắc nghẽn, giải thuật tránh tắc
nghẽn, Khởi động chậm
Các giải thuật điều khiển tránh tắc nghẽn trong TCP nhằm
giải quyết vấn đề sử dụng tài nguyên mạng một cách hiệu quả,
công bằng và giảm thiểu sự mất gói xảy ra Mỗi kết nối TCP sẽ
phản ứng với hiện tượng này bằng cách điều chỉnh tải đưa vào
mạng sao cho vẫn đảm bảo được ở một mức độ hợp lý chất
lượng kết nối TCP, giảm thiểu mức độ tắc nghẽn xảy ra trên
mạng và ảnh hưởng của nó Bên cạnh đó, các giải thuật này
còn đảm bảo sự công bằng trong việc sử dụng tài nguyên mạng
giữa các kết nối Tuy nhiên trong bài báo này chỉ đề cập đến
góc độ điều chỉnh mức độ phát của bên phát thông qua điều
chỉnh cửa sổ tắc nghẽn
Phần còn lại của bài báo được tổ chức như sau: trong phần
II, miêu tả về các hoạt động cơ bản trong điều khển tắc nghẽn
Phần III, IV và V giới thiệu các giải pháp TAHOE, RENO,
NEWRENO Phần VI và VI giới thiệu các giải thuật cho mạng
tộc độ cao và độ trễ lớn BIC-TCP và CUBIC Phần VIII cung
cấp các kết quả mô phỏng và phân tích lý thuyết Cuối cùng, là
kết luận bài báo trong phần IX
II ĐIỀU KHIỂN TẮC NGHẼN TRONG TCP
Cơ chế điều khiển lưu lượng của TCP nhằm tránh hiện tượng
quá tải/tắc nghẽn ở phía TCP nhận khi tốc độ TCP phát cao
hơn tốc độ xử lý ở TCP nhận Tuy nhiên, nó không giải quyết
được tình trạng tắc nghẽn trên đường truyển khi luồng TCP
được truyền qua mạng (ví dụ Internet) Hiện tượng tắc nghẽn
trên mạng gây ra do một router hay một gateway trên con
đường đi của luồng TCP bị tắc nghẽn trong khoản thời gian tải
nặng Trong khoản thời gian tắc nghẽn này, các bộ đệm dùng
lưu trữ gói truyền tại hàng đợi đầu ra của router tạm thời có thể bị tràn và gây ra tình trạng mất gói (mất segment TCP) Mặc dù, một nguyên nhân khác gây ra hiện tượng mất gói cũng có thể do lỗi sai truyền dẫn nhưng hiện nay lý do chính
là vẫn do tình trạng tắc nghẽn trên mạng (hiện nay mạng sử dụng phương tiện truyền dẫn quang rộng rãi nên lỗi truyển dẫn thấp)
Luồng TCP qua mạng Internet thường đi qua nhiều đường truyền, liên kết có tốc độ khác nhau Do đó, tốc độ truyền segment trên toàn bộ tuyến được xác định bởi liên kết có tốc
độ thấp nhất Tắc nghẽn có thể xảy ra ở phía phát của liên kết này (hàng đợi đầu ra) khi có nhiều segment trong nhiều kết nối TCP đồng hiện hành cùng tới với tốc độ nhanh hơn tốc độ truyển trên liên kết này Trong tình huống này, số lượng gói trong hàng đợi đầu ra này tăng dần lên cho đến khi bộ đệm đầy và xảy ra hiện tượng gói bị loại bỏ Điều này cũng ảnh hưởng đến các ACK liên quan đến những gói đã mất và như vậy nó có một ảnh hưởng đáng kể đến tổng thời gian truyền một bản tin
Để giảm khả năng xảy ra mất segment, mỗi host TCP phát có một thủ tục điều khiển tắc nghẽn cho mỗi kết nối TCP, thủ tục này sử dụng tốc độ đến của các ACK trong một kết nối để ổn định tốc độ đưa segment vào Internet Bên cạnh thủ tục điều khiển lưu lượng dùng cửa sổ trượt, mỗi kết nối TCP cũng có một biến cửa sổ tắc nghẽn Wc kết hợp với thủ tục điều khiển tắc nghẽn này Mỗi kết nối đều phải duy trì cả 2 biến này và chỉ có thể thực hiện truyền một segment trong kết nối khi cả 2 cửa số này đều trong trạng thái mở (con hạn mức truyền) Như trên đã trình bày, thủ tục điều khiển tắc nghẽn có tác dụng khi xảy ra trường hợp mạng nặng tải và trạng thái luồng segment được điều khiển chính bởi cửa sổ tắc nghẽn Wc Còn trong trường hợp mạng có tải nhẹ thì nó được điều khiển chính bởi cửa sổ phát Ws Tuy nhiên, một kết nối TCP khi bắt đầu truyền do chưa nhận các ACK nên TCP phát không biết được mức độ tải hiện hành của mạng Nên để ngăn tránh việc truyền một khối lượng lớn các segment (lên đến kích thước cửa sổ
Ws cực đại đã thỏa thuận giữa 2 đầu phát và nhận) thì kích thước của sổ tắc nghẽn Wc được thiết lập ban đầu là 1 segment Do kích thước Wc tính theo đơn vị byte nên giá trị ban đầu này sẽ bằng với kích thước segment lớn nhất MSS (Maximum Segment Size) đã được thỏa thuận giữa 2 đầu thu phát của kết nối TCP vào lúc thiết lập kết nối
Trang 2Thủ tục điều khiển cửa sổ tắc nghẽn thực hiện khi TCP phát
bắt đầu pha truyền dữ liệu của một kết nối bằng cách gởi một
segment với kích thước MSS Sau đó nó khởi tạo một bộ định
thời phát lại RTO (Retransmission TimeOut) cho segment này
và chờ nhận ACK cho segment này Nếu thời gian định thời
phát lại hết hạn thì nó sẽ phát lại segment này Nếu nó nhận
được ACK trước thời hạn này thì Wc được tăng lên 2 segment
với kích thước mỗi segment là MSS TCP phát sau đó có thể
phát 2 segment và mỗi ACK nhận được cho các segment này
Wc được tăng lên 1 segment (MSS byte) Do đó, TCP phát
bây giờ có thể phát 4 segment và cứ tiếp tục như thế Wc sẽ
tăng theo qui luật hàm mũ Mặc dù, Wc tăng nhanh như vậy,
nhưng pha này vẫn được gọi là khởi đầu chậm (slow start) vì
nó được tăng từ 1 segment Việc tăng này được tiếp tục cho
đến khi có một sự hết hạn thời gian phát lại của một segment
bị mất, hoặc TCP phát nhận được một ACK nhân bản (nhiều
ACK giống nhau xác nhận cho cùng một segment), hoặc đạt
đến mức cao hơn mức ngưỡng SST (Slow Start Threshold)
Với mỗi kết nối TCP, SST được thiết lập 64 kbyte Tuy
nhiên, trong ví dụ hình 1 giá trị này được giả định ban đầu là
32 kbyte và nếu MSS là 1 kbyte thì nó bằng với 32 segment
8
16
32
64
4
Wc
(segment/kbyte)
37
3 nhân bản ACK đầu tiên
3 nhân bản ACK thứ 2 SST= 32
SST= 17
Wc = 34
a)
8
16
32
64
4
Wc
(segment/kbyte)
RTO đầu tiên
SST= 32
RTO thứ 2
RTO thứ 3
b)
Hình 1 Điều chỉnh cửa sổ tắc nghẽn : a) Vào lúc nhận các
ACK nhân bản ; b) Vào lúc hết hạn bộ định thời phát lại RTO
Giả sử Wc đạt đến SST cho thấy đường truyền không bị tắc
nghẽn và do đó thủ tục sẽ bước vào giai đoạn 2 Trong giai
đoạn 2 thay vì Wc tăng 1 segment, thì nó chỉ tăng 1/Wc
segment cho mỗi ACK nhận được Như vậy, giai đoạn này
Wc sẽ tăng 1 segment khi nhận được một tập Wc ACK Pha
này được gọi là pha tránh tắc nghẽn và trong pha này việc tăng
Wc mang tính cộng Giai đoạn này tiếp tục cho đến khi Wc
đạt được đến một mức ngưỡng thứ 2 – trong ví dụ này là 64
kbyte – thì Wc sẽ được duy trì không đổi ở giá trị này
Trong trường hợp mạng có tải nhẹ - có nghĩa là không có liên kết nào trên con đường qua mạng bị tắc nghẽn - thì luồng segment trên kết nối được điều khiển chính bởi Ws miễn sao
Wc luôn lớn hơn Ws cực đại Trong trạng thái này tất cả các segment được truyền với một độ biến động trễ và độ trễ tương đối là hằng số Tuy nhiên, khi số lượng kết nối trên mạng tăng dẫn đến mức độ lưu lượng tăng đến một mức bắt đầu xảy ra mất gói thì thủ tục điều khiển tránh tắc nghẽn trên mỗi kết nối
sẽ bắt đầu điều chỉnh cửa sổ Wc của kết nối sao cho phản ánh được mức độ tắc nghẽn
Khi xảy ra mất gói thủ tục điểu khiển tắc nghẽn ở TCP phát sẽ phản ứng lại bằng cách điều chỉnh Wc (giảm Wc) tùy vào trường hợp cụ thể phát hiện ra sự mất gói do nhận được các ACK nhân bản hay hết thời hạn của bộ định thời phát lại Trường hợp thứ nhất : phát hiện ra mất gói khi nhận được các ACK nhân bản Việc nhận được ACK nhân bản cho thấy ở host đích vẫn nhận được các segment Do đó mức độ tắc nghẽn có thể được giả định là nhẹ và vào lúc nhận được ACK nhân bản thứ 3 liên quan đến segment bị mất (thủ tục fast retransmit) thì kích thước của Wc sẽ được giảm phân nữa và thủ tục tránh tắc nghẽn được thực hiện bắt đầu từ giá trị này Thủ tục này được gọi là khôi phục nhanh (fast recovery) Trong ví dụ trong hình 1 (a) , vào lúc nhận ACK nhân bản thứ
3, segment bị mất được phát lại và Wc được thiết lập lại bằng phân nữa - 32 kbyte - giá trị hiện hành (64 kbyte) Sau đó Wc được tăng trở lại theo như thủ tục tránh tắc nghẽn Tuy nhiên, khi đạt đến 34 segment (34 kbyte) một segment thứ 2 bị mất (giả sử do nhận được ACK nhân bản ACK thứ 3 lần 2) làm cho Wc lại bị thiết lập lại phân nữa là 17 segment và thủ tục tránh tắc nghẽn lại khởi động lại Lần này ở giá trị Wc=17 segment
Trường hợp thứ hai : mất gói được nhận ra do quá hạn bộ định thời phát lại RTO trong trường hợp này được giả định là mức
độ tắc nghẽn xảy ra đến nổi không có segment nào thuộc kết nối có thể đi qua mạng Như ví dụ trong hình 1(b), khi bộ định thời phát lại hết hạn (RTO), Wc được thiết lập lại 1 segment bất chấp giá trị hiện hành của nó là bao nhiêu và thủ tục slow start được khởi động lại Như vậy, khi mức độ tắc nghẽn đạt đến mức làm quá hạn bộ định thời phát lại thì luồng segment được điều khiển chính bằng Wc
III GIẢI PHÁP TCP-TAHOE TCP Tahoe là một trong những giải pháp điều khiển tắc nghẽn trong TCP có sớm nhất do V Jacobson đề xuất [3] Giải pháp này dựa trên đặc tả RFC 793 (TCP chuẩn) và bao gồm một số giải thuật được chia thành 3 nhóm : Khắc phục vấn đề ước lượng thời hạn phát lại (RTO), Tăng cường nhận diện sự mất gói nhanh hơn và Các giải thuật tránh tắc nghẽn (CA-Congestion Avoidance) và khởi động chậm (SS-Slow Start) Cải tiến đầu tiên : Nếu giá trị RTO được ước lượng quá cao thì viện nhận ra sự mất gói sẽ quá bảo toàn và hiệu suất của các luồng TCP riêng biệt có thể suy giảm nghiêm trọng Trong trường hợp ngược lại, khi giá trị RTO được ước lượng không
Trang 3đúng mức thì cơ chế phát hiện lỗi có thể gây ra tình trạng phát
lại không cần thiết, lãng phí các tài nguyên mạng dùng chung
và làm cho sự tắc nghẽn trên toàn mạng tồi tệ hơn Do thực tế
không thể phân biệt giữa một ACK cho gói phát lần đầu hay
cho gói phát lại nên việc tính toán RTO phức tạp hơn
Giải thuật ước lượng sự biến động độ trễ đi-về rttvar
(round-trip variance) cố gắng giảm bớt vấn đề ước lương quá cao
Thay vì sử dụng mối quan hệ tuyến tính giữa RTO và giá trị
ước lượng RTT βxSRTT (RFC 793) sau
Với
SRTT = ( α x SRTT ) + ((1- α ) x RTT) (2)
SRTT : Smoothed RTT
Ubound : giới hạn trên của thời hạn phát lại
Lbound : giới hạn dưới của thời hạn phát lại
α : hằng số nhuyễn ( 0,8 – 0,9)
β : hằng số biến động trễ ( 1,3-2,0)
TCP Tahoe tính toán ước lượng biến động RTT thiết lập một
giới hạn trên cho RTO (SRTT + 4rttvar) như sau
RTO = min [SRTT+4rttvar, max[Lbound, [β x SRTT)]] (3)
Sự ước lượng RTO không đúng mức được giải quyết bằng
cách nhân đôi giá trị RTO khi có mỗi sự kiện phát lại Nói
cách khác, trong quá trình xảy ra tắc nghẽn nghiêm trọng, khi
nhận ra chuỗi mất gói liên tục thì RTO được tăng theo hàm
mũ Việc này làm giảm đáng kể tổng số gói phát lại và giúp
ổn định trạng thái mạng
Cải tiến thứ 2 : Tăng cường việc nhận ra mất gói đặc tả TCP
đầu tiên dùng RTO là cơ chế nhận ra mất gói duy nhất Mặc
dù RTO đủ tin cậy để nhận ra sự mất gói nhưng nó không đủ
nhanh để phản ứng lại sự mất gói này Rõ ràng, thời gian tối
thiểu để nhận ra mất gói là RTT, nghĩa là nếu đầu nhận TCP
có thể nhận ra tức thời và báo cáo một sự kiện mất gói cho đầu
phát TCP thì báo cáo này sẽ đến đầu phát trong thời gian
chính xác một RTT sau khi đầu phát gởi gói bị mất RTO, theo
định nghĩa, lớn hơn RTT Mặt khác, nếu đầu thu được yêu
cầu đáp ứng lại ngay tức thời tất cả những gói dữ liệu đến
không đúng thứ tự bằng cách báo cáo gói đúng thứ tự nhận
được sau cùng (ACK nhân bản) thì sự mất gói có thể nhận biết
được hầu như trong khoản thời khoản RTT (nhỏ hơn RTO)
Nói cách khác, giả định xác suất sắp xếp lại thứ tự và nhân
bản gói trong mạng không đáng kể thì các ACK nhân bản có
thể được xem như là một chỉ thị mất gói tin cậy Như vậy với
chỉ thị mất gói mới này thì đầu phát có thể phát lại gói mất mà
không cần phải chờ đến sự kiện quá hạn RTO
Cải tiến thứ 3 : đây là cải tiến quan trọng nhất Nó bao gồm
các giải thuật khởi động chậm (SS) và Tránh tắc nghẽn (CA)
Những giải thuật này cho phép một đầu phát TCP nhận ra các
tài nguyên mạng khả dụng và điều chỉnh tốc độ truyền của
luồng TCP đến các giới hạn tài nguyên mà nó nhận biết được
Giả sử xác suất hư hỏng gói ngẫu nhiên trong truyền dẫn là
không đáng kể (<< 1%), đầu phát có thể xử lý tất cả các sự mất gói nhận biết được như là các chỉ thị tắc nghẽn Hơn nữa, việc nhận được bất kỳ một gói ACK nào đều cho biết mạng có thể nhận và truyền ít nhất một gói mới (vì một gói được ACK
đã rời mạng) Như vậy, đầu phát có thể gởi ít nhất một số lượng dữ liệu vừa được xác nhận Sự cân bằng vào-ra này được gọi là nguyên lý bảo toàn gói và là nguyên lý cốt lõi của
2 giải thuật SS và CA
Trong giải thuật SS, khi nhận được một ACK đầu phát có thể gởi gấp đôi số lượng dữ liệu đã được xác nhận bởi ACK này (tăng theo cấp bội) Như vậy, thay vì phát triển một bước theo
số lượng gói tồn đọng (hình 2) giống như trong đặc tả ban đầu (RFC 793) thì giải thuật SS phát triển cửa sổ theo một hàm mũ (hình 3) Nếu nhận ra một gói bị mất(có nghĩa mạng đang trong tình trạng tắc nghẽn) thì của số tắc nghẽn sẽ được thiết lập lại giá trị ban đầu (bằng một) để đảm bảo giải tỏa các tài nguyên mạng Đồ thị trong hình 3 cho thấy 2 trường hợp biến động cửa sổ tắc nghẽn : đồ thị a biểu diễn trường hợp khi đầu nhận không thể xử lý theo tốc độ nhận và đồ thị b cho thầy những biến động cửa sổ tắc nghẽn khi mạng không thể phân phối mọi gói thành công ở tốc độ truyền dẫn
Thời gian
Giới hạn đầu nhận (cửa sổ)
cực đại
Hình 2 Biến động số lượng gói tồn đọng trong RFC 793
Thời gian
Giới hạn đầu nhận
b)
Thời gian
Giới hạn đầu nhận
Giới hạn mạng Giới hạn mạng
Nhận ra mất gói
a)
Hình 3 Biến động cửa số tắc nghẽn của SS nếu giới hạn được tác động bởi điều khiển lưu lượng cũ (a) và bởi mạng (b) Tính hiệu quả của giải thuật có thể được định nghĩa là tỉ số giữa vùng bên dưới của đồ thị cửa sổ tắc nghẽn và vùng bên dưới đường giới hạn mạng (hình 3) Rõ ràng khi tài nguyên mạng khả dụng thấp hơn giới hạn ấn định bởi đầu nhận (đồ thị
Trang 4b trong hình 3), hiệu suất của giải thuật SS trong một khoản
thời gian dài rất thấp
Giải thuật thứ hai trong nhóm này là tránh tắc nghẽn CA Mục
đích của giải thuật này nhằm cải tiến hiệu suất của TCP trong
trường hợp tài nguyên mạng giới hạn, có khả năng xảy ra hiện
tượng cổ trai truyền dẫn So với giải thuật khởi động chậm thì
giải thuật này dè dặt nhiều hơn trong đáp ứng cho những gói
ACK nhận được và với việc nhận ra mất gói Nếu tất cả các
gói đã được giao thành công trong khoản thời gian RTT thì
thay vì nhân đôi cửa sổ tắc nghẽn như trong giai đoạn SS thì
giải thuật CA chỉ tăng 1 (tăng cộng) Và khi có sự mất gói xảy
ra, thay vì khởi động lại với kích thước 1 gói thì cửa sổ tắc
nghẽn chỉ đơn giản giảm phân nữa so với kích thước hiện
hành (ngay trước khi sự mất gói xảy ra) Theo phân tích của
Jacobson [3] để đạt được mạng không có tắc nghẽn thì việc
giảm phân nữa cửa sổ tắc nghẽn bởi các luồng riêng biệt là đủ
Cách giảm có tính nhân này giống như hành vi hàm mũ khi
nhiều gói liên tiếp bị mất (trạng thái tắc nghẽn kéo dài) Theo
như trong hình 4, Giải thuật CA này đúng là có hiệu quả trong
thời gian dài nhưng bù lại thì thời gian tìm ra tài nguyên mạng
của nó lại chậm do tốc độ tăng kích thước cửa sổ của nó mang
tính dè dặt
Thời gian
Giới hạn mạng Nhận ra mất gói
Hình 4 Biến động cửa sổ tắc nghẽn và hiệu quả của giải thuật
tránh tắc nghẽn CA
Giải thuật TCP Tahoe gồm cả 2 giải thuật SS và CA hoạt động
riêng biệt Nó tổ hợp cả khám phá nhanh tài nguyên mạng
(SS) và hiệu suất dài hạn (CA) Để chuyển giữa 2 pha giải
thuật này, một mức ngưỡng ssthresh được định nghĩa Mức
ngưỡng này xác định kích thước cực đại của cửa sổ tắc nghẽn
trong pha khởi động chậm SS, và nếu có bất kỳ sự mất gói xảy
ra thì ssthreh được điều chỉnh về phân nữa kích thước cửa sổ
tắc nghẽn hiện hành Khi nằm trong giai đoạn của giải thuật
SS và có một sự mất gói được nhận biết thì bản thân cửa sổ
luôn thiết lập lại ở giá trị tối thiểu (=1) Ngay khi giá trị cửa sổ
tắc nghẽn thấp hơn ssthreh, pha SS được thực hiện Khi cửa sổ
lớn hơn mức ngưỡng này, giải thật CA được sử dụng Đây là
gọi là chu trình SS-CA (hình 5)
Thời gian
Giới hạn mạng Nhận ra mất gói
Hình 5 Biến động cửa sổ tắc nghẽn của tổ hợp 2 giải thuật SS
và CA
IV GIẢI PHÁP TCP RENO Trong TCP Tahoe, việc giảm cửa sổ tắc nghẽn về 1 khi có sự mất gói xảy ra là một việc khá hà khắc và trong một vài trường hợp có thể dẫn đến sự suy giảm độ thông xuất nghiêm trọng Ví dụ, với tỉ lệ mất gói 1% có thể gây ra sự suy giảm đến 75% độ thông xuất của một luồng TCP chạy giải thuật Tahoe [4] Để giải quyết vấn đề này, Jacobson đã đưa ra khái niệm về sự khác biệt giữa những sự kiện tắc nghẽn nhẹ và tắc nghẽn nghiêm trọng và đồng thời đã hiệu chỉnh lại các giải thuật khởi động chậm và tránh tắc nghẽn
Sự nhận ra mất gói thông qua thời hạn phát lại RTO cho thấy trong một khoản thời gian nhất định (ví dụ RTO-RTT) một sự kiện tắc nghẽn nghiêm trọng nào đó đã ngăn cản việc truyền bất kỳ gói nào trên mạng Vì vậy, bên phát TCP sẽ áp dụng chính sách bảo toàn thiết lập lại cửa sổ tắc nghẽn tới một giá trị tối thiểu
Một cách khác có thể nhận ra mất gói bằng các ACK nhân bản Giả sử bên phát TCP nhận được 4 ACK, ACK đầu tiên xác nhận cho gói dữ liệu mới nào đó, 3 ACK còn lại là các bản copy chính xác của ACK đầu tiên Các ACK nhân bản cho thấy những gói nào đó đã bị lỗi Tuy nhiên, sự hiện diện của mỗi gói ACK (bao gồm ACK nhân bản) cho biết một gói dữ liệu đã đến đích thành công Hơn nữa, phía phát bên cạnh việc nhận ra mất gói nó cũng quan sát khả năng của mạng trong việc phân phối dữ liệu Như vậy, trong trường hợp này trạng thái của mạng có thể được xem là bị tắc nghẽn nhẹ, và phản ứng với sự kiện mất gói có thể lạc quan hơn Trong TCP Reno, phản ứng lạc quan này là sử dụng giải thuật khôi phục nhanh FR (Fast Recovery)
Ý định của FR là giảm phân nữa cửa sổ tắc nghẽn và thực hiện thăm dò tài nguyên mạng cho đến khi lỗi được khắc phục Hay nói một cách khác, bên phát nằm trong trạng thái khôi phục nhanh cho đến khi nó nhận được gói ACK không nhân bản Các giai đoạn của giải thuật được minh họa trong hình 6 Các kích thước cửa sổ tắc nghẽn trong các trạng thái khác nhau được biểu thị bởi các đoạn bên trên các đường trạng thái, và các mũi tên biểu thị kích thước cửa sổ hiệu lực hay số lượng gói đang được chuyển tiếp
Trang 5Sự chuyển từ trạng thái 1 sang trạng thái 2 biểu thị sự giảm
việc sử dụng tài nguên mạng dùng chính sách giảm gấp bội
Sau khi giảm phân nữa (Wc/2), giải thuật không chỉ phát lại
gói dữ liệu chưa được xác nhận cũ nhất mà còn’thổi phồng’
cửa sổ theo số lượng gói ACK nhân bản (trang thái 2 sang
trạng thái 3) Như chúng ta đã biết, một ACK sẽ chỉ thị ít nhất
một gói dữ liệu đã được giao thành công Như vậy, nếu chúng
ta muốn duy trì một số lượng gói không đổi đang được chuyển
tiếp, chúng ta phải thổi phồng cửa sổ tắc nghẽn để mở một vị
trí gởi dữ liệu mới (trạng thái 4) Nếu không có sự tăng này thì
các gói dữ liệu mới không thể được gởi trước khi lỗi được
khắc phục, và số lượng gói đang được chuyển tiếp có thể giảm
nhiều hơn mong đợi
Dữ liệu đã phát chờ ACK
Dữ liệu đã
được ACK đệm chờ phátDữ liệu được
Wc Trạng thái 1
Wc/2 Trạng thái 2
Ngay trước khi nhận ra mất gói
Wc/2+#dup Trạng thái 3
Wc/2+#dup Trạng thái 4
Wc/2 Trạng thái 5
Ngay sau khi nhận ra mất gói
Wc “phình ra” theo số lượng ACK nhân bản nhận được Các ACK nhân bản có thêm làm Wc “phình ra” thêm Sau khi khôi phục thành công
Dữ liệu tồn đọng không được phép phát lại
Số lượng dữ liệu mới được phép gởi đi do
cửa sổ tắc nghẽn “xã hơi”
Số lượng dữ liệu tới đầu nhận thành công,
suy ra từ các ACK nhân bản nhận được
Số lượng gói đang chuyển tiếp
Kích thước cửa sổ tắc nghẽn là tổng của 2 thành phần này
Hình 6 Các trạng thái tiêu biểu của FR
Trong trạng thái cuối cùng (trạng thái 5), khi một gói ACK
không nhân bản được nhận, chúng ta muốn khôi phục lại hoạt
động tránh tắc nghẽn với phân nữa cửa sổ tắc nghẽn ban đầu
Với xác suất cao, các ACK không nhân bản này sẽ xác nhận
việc giao thành công tất cả các gói dữ liệu tồn đọng suy luận
từ các ACK nhân bản nhận được trước đây Ở thời điểm này,
việc giảm cửa số tắc nghẽn tới Wc/2 (giá trị ngay trước khi
vào giai đoạn khối phục -trang thái 2) là một cách thức tin cậy
và đơn giản để đảm bảo mục tiêu thoát trạng thái khôi phục
nhanh FR
Thời gian
Giới hạn mạng Nhận ra mất gói
ssthresh
Hình 7 Những biến động cửa sổ tắc nghẽn của TCP Reno
Kết quả những biến động cửa sổ tắc nghẽn lý thuyết của TCP Reno biểu diễn trong hình 7 So với nững biến động của TCP Tahoe, bằng cách thay các giai đoạn khởi động chậm SS sau mỗi sự kiện mất gói bằng các giai đoạn phát lại nhanh FR ngắn hơn, TCP Reno đạt hiệu quả trong trạng thái ổn định cải thiện đáng kể
Thực ra, Việc khôi phục từ một sự mất gói đơn sẽ luôn hoàn thành trong một RTT Tuy nhiên, hiệu suất được cải thiện không chỉ bởi rút ngắn giai đoạn khôi phục, mà còn bởi việc cho phép truyền dữ liệu trong giai đoạn khôi phục
V GIẢI PHÁP TCP NEWRENO Một trong những điểm yếu của giải thuật FR trong TCP Reno
sẽ bộc lộ khi nhiều gói mất xảy ra trong một sự kiện tắc nghẽn đơn lẽ Điều này làm giảm đáng kể hiệu năng của TCP Reno trong những môi trường tải nặng Khi một một sự kiện tắc nghẽn đơn lẽ (đột biến lưu lượng trong một khoản thời gian ngắn) gây ra mất nhiều gói dữ liệu Phản ứng giảm phân nữa cửa số tắc nghẽn của FR đột nhiên chuyển thành một sự giảm cửa cổ tắc nghẽn theo quy luật hàm mũ mang tính thận trọng
Sự mất gói đầu tiên gây ra giải thuật bắt đầu vào giai đoạn khôi phục và giảm phân nữa cửa sổ tắc nghẽn sau đó nếu nhận được một ACK không nhân bản thì giải thuật sẽ kết thúc qua trình khôi phục Tuy nhiên, các sự mất tiếp theo sẽ gây ra cửa sổ tắc nghẽn tiếp tục giảm thêm nữa theo cùng một cơ chế vào và thoát trạng thái khôi phục như trường hợp mất gói đầu tiên trong chuỗi mất gói này
Theo một ý nghĩa nào đó, việc phản ứng theo quy luật hàm mũ này đối với nhiều sự mất gói là mong muốn của các giải thuật tránh tắc nghẽn với mục đích giảm sự tiêu thụ tài nguyên mạng trong những tình trạng tắc nghẽn nghiêm trọng Nhưng
sự mong muốn này dựa trên giả định các trạng thái tắc nghẽn độc lập nhau và trong ví dụ trên thì điều này không đúng Có khả năng cao tất cả sự mất gói trong nhóm dữ liệu ban đầu (những gói dữ liệu còn tồn đọng vào lúc xảy ra sự mất gói) được gây ra bởi cùng một sự kiện mất gói đơn lẽ Như vậy, các sự mất gói thứ hai, thứ ba trong ví dụ trên nên được xử lý như là một yêu cầu phát lại dữ liệu chứ không phải như là những chỉ báo tắc nghẽn Hơn nữa, việc giảm cửa sổ tắc nghẽn không đảm bảo sẽ giải phóng tài nguyên mạng ngay tức thời
do tất cả gói dữ liệu được phát trước khi giảm cửa sổ vẫn đang được chuyển tiếp Vì vậy, trước khi kích thước cửa sổ tắc nghẽn mới có hiệu lực, ta không nên áp dụng thêm bất kỳ chiến lược giảm nào nữa Điều này có thể hiểu là việc giảm cửa sổ tắc nghẽn không nên thường xuyên hơn một lần trong khoản thời gian độ trễ lan truyền một chiều hay xấp xỉ RTT/2 Floyd et al [7] đưa ra một sự cải tiến đơn giản giải thuật khôi phục nhanh FR Sự cải tiến này nhằm giải quyết sự không tường minh của các sự kiện tắc nghẽn bằng cách trì hoãn việc thoát khỏi giai đoạn khôi phục cho tới khi tất cả các gói dữ liệu trong giới hạn cửa sổ tắc nghẽn ban đầu (ngay khi tắc nghẽn xảy ra) được xác nhận Giải thuật NewReno bổ sung thêm một biến trạng thái đặc biệt để nhớ số thứ tự của gói dữ
Trang 6liệu sau cùng được gởi đi trước khi vào trạng thái khôi phục
nhanh FR Giá trị này giúp phân biệt giữa ACK nội bộ (ACK
cho các gói tồn đọng) và ACK cho dữ liệu mới Việc nhận
được một ACK cho gói dữ liệu mới có nghĩa là tất cả các gói
được gởi trước khi nhận ra lỗi đã được giao thành công và bất
kỳ một sự mất gói mới nào sẽ chỉ báo một sự kiện tắc nghẽn
mới Một ACK nội bộ xác nhận sự khôi phục từ chỉ một lỗi sai
đầu tiên và chỉ báo thêm nhiều sự mất gói trong bó gói đầu
tiên
Dữ liệu đã phát chờ
ACK
Dữ liệu đã
được ACK đệm chờ phátDữ liệu được
Wc Trạng thái 1
Wc/2 Trạng thái 2
Ngay trước khi nhận ra mất gói
#dup+Wc/2 Trạng thái 3
#dup+Wc/2-ACK Trạng thái 6
Wc/2 Trạng thái 7
Ngay sau khi nhận ra mất gói Phát lại gói mất Mỗi ACK nhân bản ‘thổi phồng’ Wc
Các ACK nhân bản chỉ làm
Wc “phình ra” thêm Thoát trạng thài khôi phục và làm giảm Wc khi nhận được Mất gói do sự kiện tắc nghẽn thấp
Phát lại gói
Số lượng dữ liệu tới đầu nhận thành công,
biết được từ các ACK nhân bản nhận được
Số lượng gói đang chuyển tiếp
Kích thước cửa sổ tắc nghẽn là tổng của 2 thành phần này
#dup+Wc/2-ACK Trạng thái 4
ACK nội bộ làm giàm cwnd, các gói trước khi nhận
#dup+Wc/2-ACK Trạng thái 5
Phát lại gói bị mất ( ) Wc vẫn duy trì không đổi
X X
X
Nhận ra mất gói (3 ACK nhân bản)
ACK không nhân bản
Hình 8 Các trạng thái của giải thuật khôi phục nhanh FR của
TCP NewReno
Hình 8 minh họa sự biến động kích thước cửa sổ tắc nghẽn
trong NewReno Tương tự với giải thuật Reno, việc nhận bất
kỳ các gói ACK nhân bản đều chỉ kích khởi việc ‘thổi phồng’
cửa sổ tắc nghẽn (các trạng thái 3,4,6) Một ACK nội bộ cho
biết chính xác về phần nào đó dữ liệu đã được giao thành
công Như vậy, phản ứng với ACK nội bộ chỉ là một sự giảm
bớt cửa sổ tắc nghẽn (trạng thái 4) và một sự phát lại gói dữ
liệu chưa được xác nhận kế tiếp (trạng thái 5) Cuối cùng,
việc thoát khỏi giai đoạn khôi phục nhanh FR chỉ có thể thực
hiện khi bên phát nhận được một ACK cho gói dữ liệu mới
và kèm theo đó là việc giảm kích thước cửa sổ hoàn toàn
VI GIẢI PHÁP BIC-TCP
BIC-TCP (Binary Increase Congestion Control – TCP) mở rộng NewReno thêm một một giai đoạn hội tụ nhanh RC (Rapid Convergence) Trong giai đoạn này, BIC-TCP sử dụng cách thức tìm kiếm nhị phân để khám phá nhanh kích thước cửa sổ tắc nghẽn tối ưu (giá trị tương ứng với tài nguyên mạng khả dụng) bằng cách xem sự nhận biết mất gói như là một chỉ báo cửa sổ tắc nghẽn có kích thước qua mức
Thời gian
Wmax
Wmin
Hình 9 Tìm kiếm nhị phân để đạt kích thước cửa sổ tối ưu Trong khi mạng giao các gói dữ liệu thành công (bên phát nhận được ACK trong khoảng RTT) cửa sổ tắc nghẽn được cập nhật đến điểm giữa (giá trị trung bình) trong dãy tìm kiếm giữa kích thước cửa sổ tối thiểu Wmin (không có sự mất gói trong khoản RTT) và kích thước cửa sổ cực đại Wmax (giá trị
có sự mất gói xảy ra) Khi có một chỉ báo giao dữ liệu thành công (nhận được ACK không nhân bản) thì Wmin được tăng lên giá trị cửa sổ trước đó (gía trị cửa sổ khi mạng không có tắc nghẽn) Sau khi cửa sổ tăng đến điểm giữa, nếu mạng không có mất gói xảy ra thì có nghĩa rằng mạng có thể xử lý nhiều lưu lượng hơn và như vậy có thể thiết lập điểm giữa là một giá trị Wmin mới và thực hiện một sự tìm kiếm khác với giá trị Wmin và Wmax mới Ngay khi nhận ra mất gói ( ví dụ nhận được 3 ACK nhân bản) thì Wmax được thiết lập bằng gía trị cửa sổ hiện hành (giá trị khi mạng có tắc nghẽn) và vào giai đoạn khôi phục nhanh như trong NewReno Với cách thực hiện này, cửa sổ tăng rất nhanh khi kích thước cửa sổ hiện hành cách xa giá trị tương ứng với dung lượng của đường truyền (giá trị xảy ra mất gói trước đó) Còn nếu gần với giá trị này thì nó sẽ giảm chậm mức độ tăng kích thước Mức độ tăng cửa sổ nhỏ nhất ở điểm bảo hòa và số lượng quá mức của
nó vượt qua điểm bảo hòa với sự mất gói rất nhỏ Toàn bộ hàm phát triển cửa sổ này đơn giản là một hàm logarit lõm Hàm lõm này giữ cho cửa sổ tắc nghẽn ở điểm bảo hòa lâu và cân bằng hơn nhiều so với các hàm tuyến tính và hàm lồi (các hàm này có mức tăng cửa sổ lớn nhất ở điểm bảo hòa và như vậy gây ra sự quá mức lớn nhất về kích thước cửa sổ ở thời điểm mất gói xảy ra Đặc tính này giúp cho BIC-TCP rất ổn định
Tuy nhiên, việc tăng đến điểm giữa có thể tăng quá nhiều trong một RTT, vì thế nếu khoảng cách giữa điểm giữa và Wmin hiện hành lớn hơn một hằng số cố định nào đó Smax thì BIC-TCP sẽ tăng cửa sổ theo Smax Nếu không có sự mất gói xảy ra ở kích thước cửa sổ cập nhật này, thì kích thước cửa sổ này trở thành giá trị Wmin mới Tiến trình này tiếp tục cho
Trang 7đến khi độ tăng cửa sổ này ít hơn một hằng số nhỏ Smin nào
đó và lúc này kích thước cửa sổ được thiết lập tới giá trị cực
đại hiện hành (Wmax) Như thế, sau khi thực hiện giảm cửa sổ
do tắc nghẽn, hàm phát triển cửa sổ này sẽ hầu như phù hợp
với một hàm tuyến tính (giai đoạn tăng cộng) theo sau bởi một
hàm logarithmic (giai đoạn tìm kiếm nhị phân)
Nếu kích thước cửa sổ tăng quá giá trị cực đại, kích thước cửa
số cân bằng phải lớn hơn giá trị cực đại hiện hành và một giá
trị cực đại mới được thiết lập BIC-TCP vào một giai đoạn
mới gọi là thăm dò giá trị cực đại Giai đoạn thăm do cực đại
sử dụng một hàm phát triển cửa sổ đối xứng chính xác với sự
phát triển trong giai đoạn tăng cộng và tìm kiếm nhị phân
Hình-10a biểu diễn hàm phát triển này trong giai đoạn thăm
dò giá trị cực đại Trong quá trình thăm dò, kích thước cửa sổ
ban đầu phát triển chậm để tìm giá trị cực đại cận kề, và sau
một khoản thời gian phát triển chậm mà không tim thấy giá trị
cực đại mới (không có sự mất gói xảy ra) thì nó đoán giá trị
cực đại mới nằm xa vị trí hiện hành và nó chuyển sang tăng
nhanh hơn bằng cách chuyển sang tăng cộng Trong quá trình
này kích thước cửa sổ được tăng với mức tăng cố định
BIC-TCP có hiệu năng tốt là nhờ sự tăng chậm quanh giá trị Wmax
và tăng tuyến tính trong quá trình tăng công và thăm dò giá trị
cực đại
b)
a)
Tăng
cộng Tìm kiếm nhị phân
Thăm dò cực đại Wmax
Trạng thài ổn định
Thăm dò cực đại Wmax
Hàm phát triển cửa số BIC-TCP
Hàm phát triển cửa số CUBIC
Hình 10 Các hàm phát triển cửa sổ BIC-TCP và CUBIC
BIC-TCP đạt được tính linh hoạt tốt trong mạng tốc độ cao,
công bằng giữa các luồng và ổn định do sự dao động cửa sổ
thấp Tuy nhiên, hàm phát triển của nó có thể vẫn quá mạnh
đối với TCP., đặc biệt trong trường hợp mạng tốc độ chậm và
có RTT nhỏ Hơn nữa nhiều giai đoạn khác nhau (tăng nhị
phân, tham dò giá trị cực đại, Smax và Smin) của quá trình
điều khiển cửa sổ làm tăng độ phức tạp khi thực hiện giao thức
và phân tích hiệu năng của nó Để giải quyết những vần đề
này, CUBIC đã được giới thiệu như là một biến thể của
BIC-TCP với sự điều khiển cửa sổ đơn giản và tăng cường tình
công bằng giữa các luồng TCP trong việc sử dụng tài nguyên
mạng khi có tắc nghẽn xảy ra
VII GIẢI PHÁP CUBIC CUBIC là một biến thể của BIC-TCP Tên gọi của giải thuật này xuất phát từ hàm phát triển cửa sổ của nó là một hàm cubic Dạng của hàm này rất giống với hàm phát triển cửa sổ của BIC-TCP CUBIC sử dụng hàm cubic theo thời gian trôi qua từ sự kiện tắt nghẽn mới nhất Trong khi hầu hết các giải thuật sử dụng hàm tăng lồi khi có sự kiện mất gói xảy ra, mức
độ tăng cửa sổ là luôn luôn tăng, CUBIC sử dụng cả 2 giai đoạn lõm và lồi của hàm CUBIC
Chi tiết của hoạt động của CUBIC như sau Khi có sự mất gói xảy ra CUBIC thiết lập Wmax bằng kích thước cửa sổ nơi sự kiện mất gói xảy ra và thực hiện giảm kích thước cửa sổ theo bội số với hệ số β ( hằng số giảm kích thước cửa sổ), thực hiện giai đoạn khôi phục nhanh thông thường và phát lại của TCP Sau đó nó vào giai đoạn tránh tắc nghẽn, bắt đầu tăng cửa sổ dùng giai đoạn lõm của hàm cubic Hàm cubic được thiết lập
có giai đoạn bằng phẳng của nó ở Wmax, như vậy hàm lõm sẽ phát triển tiếp tục cho tới khi kích thước cửa sổ bằng Wmax Giải thuật tiếp tục chuyển sang phần lồi của hàm cubic và bắt đầu giai đoạn phát triển cửa sổ lồi Cách điều chỉnh cửa sổ này (lõm và sau đó lồi) cải thiện giao thức và độ ổn định của mạng nhưng vẫn duy trì sự tận dụng mạng cao [8] Điều này là do kích thước cửa sổ duy trì hầu như là hằng số, hình thành một
sự bình ổn quanh giá trị Wmax nơi mà được xem như hiệu quả
sử dụng mạng cao nhất và trong trạng thái ổn định, hầu hết những mẫu kích thước cửa sổ của CUBIC là gấn với Wmax, như vậy nó đẩy mạnh việc tận dụng mạng cao và ổn định giao thức
Hàm phát triển cửa sổ CUBIC sử dụng hàm sau :
𝑊𝑊(𝑡𝑡) = 𝐶𝐶(𝑡𝑡 𝑡 𝑡𝑡)3+ 𝑊𝑊𝑊𝑊𝑊𝑊𝑊𝑊 (4) C: là một thông số CUBIC
t : thời gian trôi qua từ sự giảm kích thước cửa sổ gần nhất
K : khoản thời gian hàm W(t) tăng W đến Wmax khi không có thêm sự mất gói xảy ra
Wmax : Kích thước cửa sổ tắc nghẽn ngay trước khi nhận
ra sự kiện mất gói gần nhất
K được tính theo công thức sau ;
K = √3 WmaxβC (5)
β : Hệ số giảm bội số Vào lúc nhận một ACK trong giai đoạn tắc nghẽn, CUBIC tính toán tốc độ phát triển cửa sổ trong giai đoạn RTT kế dùng công thức (4) Nó thiết lập W(t+RTT) như là giá trị mục tiêu
dự kiến của cửa sổ tắc nghẽn Giả sử kích thước cửa sổ tắc nghẽn hiện hành là Wc Phụ thuộc vào giá trị của Wc, CUBIC thực hiện trong 3 phương thức khác nhau Đầu tiên, nếu Wc nhỏ hơn kích thước cửa sổ mà TCP chuẩn đạt được ở thời điểm t sau sự kiện mất gói gần nhất, thì CUBIC nằm trong mô
Trang 8hình TCP Ngược lại, nếu Wc thấp hơn Wmax, thì CUBIC
năm trong vùng lõm, và nếu Wc lớn hơn Wmax thì CUBIC
nằm trong vùng lồi
Khi nhận được một ACK trong giai đoạn tránh tắc nghẽn,
CUBIC sẽ kiểm tra xem giao thức có nằm trong vùng TCP
hay không Để trả lời câu hỏi này, đầu tiên phải phân tích kích
thước cửa sổ của TCP theo thời gian trôi qua t Kích thước
cửa sổ trung bình của giải thuật tăng công giảm bội số AIMD
(sử dụng trong TCP chuẩn Reno) với hệ số cộng α, hệ số nhân
β và xác suất mất gói p được tính theo công thức sau
1 RTTx√α2x2−ββ x1p (6) Kích thước cửa sổ trung bình của TCP với α = 1 và β = 0,5 là
RTT1 x√32x1p (7)
Như vậy để phương trình (6) giống với (7) thì α phải bằng
3β/2-β Nếu TCP tăng cửa sổ lên α trong khoảng RTT thí kích
thước cửa sổ theo thời gian trôi qua t sẽ là
Wtcp(t) = Wmax(1 − β) + 32−ββ xRTTt (8)
Nếu Wc nhỏ hơn Wtcp(t), thì giao thức nằm trong phương
thức TCP và Wc được thiết lập giá trị Wtcp(t) mỗi lần nhận
được ACK
VIII KẾT QUẢ
Mô phỏng được thực hiện trên một mạng giả lập gồm 2 subnet
(HN và HCMC) và mạng Internet Subnet HCMC bao gồm
một FPT server kết nối vào mạng Internet thông qua một
Router Tương tự, subnet HN gồm một Client và Router_HN
kết nối vào Internet Luồng lưu lượng trong mô phỏng là
luồng FPT truyền qua giao thức TCP từ FPT server đến Client
Với các giải thuật điều khiển tắc nghẽn khác nhau thì sự biến
động kích thước cửa sổ khác nhau thể hiện tương tự như trong
các phần trên đã trình bày
Subnet HN Subnet HCMC
Internet
Hình-11 Mô hình mạng giả lập
Mô phỏng gồm 3 ngữ cảnh Tahoe, Reno và Cubic tương ứng
với 3 giải thuật trong phần III,IV và VII Trong 2 ngữ cảnh
Tahoe và Reno, giá trị các thông số SST=64000 và xác suất
mất gói trên mạng Internet là 0.5% Kết quả như sau :
Đồ thị trong hình-12 biểu diễn sự biến động của kích thước
cửa sổ tắc nghẽn trong ngữ cảnh Tahoe Khi tắc nghẽn được
chỉ thị bởi một RTO, giải thuật khởi động chậm (SS) và Wc được thiết lập về một segment
Đồ thị trong hình-13 biểu diễn biến động của kích thước cửa
sổ tắc nghẽn trong ngữ cảnh Reno Trong giải thuật Reno khi tắc nghẽn xảy ra thì giải thuật khôi phục nhanh (FR) được thực hiện nên Wc không thiết lập lại ở giá trị 1 segment như trong Tahoe mà được thiết lập giá trị 3 segment (4886 byte )
Hình-12 biến động cửa sổ tắc nghẽn của giải thuật Tahoe
Hình-13 Biến động cửa sổ tắc nghẽn của giải thuật Reno Trong ngữ cảnh Cubic độ mất gói trong mạng Internet vẫn là 0,5% những độ trễ lan truyền một chiều được thiết lập 100ms (mạng độ trễ cao, ví dụ vệ tinh) Hình-14 biểu diễn sự biến động cửa sổ tắc nghẽn của giải thuật Cubic, kết quả cho thấy hàm cubic được thể hiện qua những vùng lõm hoặc lõm và lồi
Hình-14 Biến động cửa sổ tắc nghẽn của giải thuật Cubic
IX KẾT LUẬN Bài báo đã khảo sát và mô phỏng một số giải thuật điều khiển tắc nghẽn phổ biến cho luồng TCP dùng trong các hệ điều hành window và linux
Cả 2 vùng lõm và lồi Vùng lõm
Trang 9LỜI CÁM ƠN
Nghiên cứu này được tài trợ bởi Học Viện Công Nghệ Bưu
Chính Viễn Thông với mã số đề tài 02-HV-2015-RD_VT2
TÀI LIỆU THAM KHẢO
[1] J.Postel, “ RFC 793- Transmission Control Protocol “, RFC, 1981.
[2] S Floyd,T Henderson and A Gurtov, “RFC3782 – The NewReno
modification to TCP’s fast recovery algorithm,“ RFC, 2004
[3] V Jacobson, “ Congestion avoidance and control, ” ACM
SIGCOMM,pp 314-329, 1988
[4] V Jacobson, “ Modified TCP congestion avoidance algorithm,“ email to
the end2end list, 4/1990
[5] S Floyd and T Henderson, “RFC2582 – The NewReno modification to TCP’s fast recovery algorithm,“ RFC, 1999.
[6] Alexander Afanasyev, Neil Tilley, Peter Reiher, and Leonard Kleinrock,
“ Host-to-Host Congestion Control for TCP,“ IEEE Communication Surveys & Tutorial, Vol.12, No 3, 2010.
[7] S Floyd,T Henderson, A Gurtov and Y Nishida, “RFC6582 – The NewReno modification to TCP’s fast recovery algorithm,“ RFC, 2012 [8] Cai, H., eun, D., Ha, S., Rhee, I., and xu, L., “Stochastic ordering for internet congestion control and its applications,“ In proceedings of IEEE INFOCOM, 2007
[9] Peng Yang, Wen Luo, Lisong Xu, Jitender Deogun, and Ying Lu , “TCP Congestion Avoidance Algorithm Identification,“ 31st International Conference on Distributed Computing System, 2011
