Khảo sát giải thuật điều khiển tắc nghẽn cho luồng TCP

Hội Thảo Quốc Gia 2015 về Điện Tử, Truyền Thông và Công Nghệ Thông Tin (ECIT 2015)

Hội Thảo Quốc Gia 2015 về Điện Tử, Truyền Thông và Công Nghệ Thông Tin (ECIT 2015)

Khả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:
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).

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.

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 tồ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.

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 .

I.

GIỚI THIỆU

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

Để 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).

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.

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.

Đ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

ISBN: 978-604-67-0635-9

51
51


HộiHội
Thảo
Quốc
GiaGia
2015
và Công
CôngNghệ
NghệThông
Thông

(ECIT
2015)
Thảo
Quốc
2015vềvềĐiện
ĐiệnTử,
Tử,Truyền
TruyềnThông
Thông và
TinTin
(ECIT
2015)
Thủ 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.

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 ln 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.

a)

Wc
(segment/kbyte)

3 nhân bản
ACK đầu tiên

64

3 nhân bản
ACK thứ 2
Wc =
34

SST= 32

32

SST= 17

16
8
4

2

5

10

20

30

37 40

50

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

RTT

b)
Wc
(segment/kbyte)
RTO đầu tiên

64

RTO thứ 2

SST= 32

32

RTO thứ 3
16
8
4
2

III.
5

10

20

30

40

50

RTT

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 (CACongestion Avoidance) và khởi động chậm (SS-Slow Start).

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.

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ẽ q bảo tồ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

52
52

HộiHội
Thảo
Quốc
vàCơng
CơngNghệ
Nghệ
Thơng
(ECIT
2015)
Thảo
QuốcGia
Gia2015
2015về
vềĐiện
Điện Tử,
Tử, Truyền
Truyền Thơng
Thơng và
Thơng
Tin Tin
(ECIT
2015)
đú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 ngun 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 tốn RTO phức tạp hơn.

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 tồn gói và là ngun lý cốt lõi của
2 giải thuật SS và CA.

Giải thuật ước lượng sự biến động độ trễ đi-về rttvar (roundtrip 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
RTO = min[Ubound,max[Lbound,( β x SRTT)]]

(1)

SRTT = ( α x SRTT ) + ((1- α ) x RTT)
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)

(2)

TCP Tahoe tính tố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)
Giới hạn đầu nhận
(cửa sổ)

Số gói tồn đọng
cực đại

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.

Chuyển dữ liệu

cực đại

Thời gian

Hình 2. Biến động số lượng gói tồn đọng trong RFC 793
Giới hạn đầu nhận

Cửa sổ tắc nghẽn

Giới hạn mạng
Giới hạn đầu nhận

Giới hạn mạng
Cửa sổ tắc nghẽn

Với

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
a)

Thời gian
b)

Nhận ra mất gói

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)

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à

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ị

53
53


HộiHội
Thảo

Quốc
Gia
2015
và Cơng
CơngNghệ
NghệThơng
Thơng
(ECIT
2015)
Thảo
Quốc
Gia
2015về
vềĐiện
ĐiệnTử,
Tử,Truyền
TruyềnThơng
Thơng và
TinTin
(ECIT
2015)
b 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.

Nhận ra mất gói

Cửa sổ tắc nghẽn

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 ngun 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.

Cửa sổ tắc nghẽn

Giới hạn mạng

SS

SS

CA

SS

Thời gian

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.

Nhận ra mất gói

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 tồn thiết lập lại cửa sổ tắc nghẽn tới một giá
trị tối thiểu.

Giới hạn mạng

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).

Thời gian

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ổ
ln 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)

Ý đị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.

54
54


Thảo
QuốcGia
Gia2015
2015về
vềĐiện
Điện Tử,
Tử,Truyền
Truyền Thông
Thông và
Thông
TinTin
(ECIT
2015)
HộiHội

Thảo
Quốc
vàCông
CôngNghệ
Nghệ
Thông
(ECIT
2015)

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ể.

Sự 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 đã

được ACK

Dữ liệu đã phát chờ
ACK

Thực ra, Việc khôi phục từ một sự mất gói đơn sẽ ln hồ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.

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à thố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.

Dữ liệu được
đệm chờ phát

Wc

Ngay trước khi
nhận ra mất gói

Trạng thái 1
Wc/2

Ngay sau khi
nhận ra mất gói

Trạng thái 2
Wc/2+#dup

Wc “phình ra” theo số lượng
ACK nhân bản nhận được

Trạng thái 3
Wc/2+#dup

Các ACK nhân bản có thêm
làm Wc “phình ra” thêm

Trạng thái 4
Wc/2
Trạng thái 5

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

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 ngun 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.

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 thốt trạng thái khơi phục
nhanh FR.

Cửa sổ tắc nghẽn

Nhận ra mất gói
Giới hạn mạng

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ì hỗn việc
thố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ữ

ssthresh

SS

FR

CA

GIẢI PHÁP TCP NEWRENO

Thời gian

Hình 7. Những biến động cửa sổ tắc nghẽn của TCP Reno

55
55


Thảo
QuốcGia
Gia2015
2015về
vềĐiện
Điện Tử,
Tử,Truyền
Truyền Thông
Thông và
Thông
TinTin
(ECIT
2015)
HộiHội
Thảo
Quốc
vàCông

CôngNghệ
Nghệ
Thông
(ECIT
2015)

liệ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
XX
Wc

Dữ liệu được
đệm chờ phát
Ngay trước khi
nhận ra mất gói

Trạng thái 1
Wc/2

Ngay sau khi
nhận ra mất gói

Trạng thái 2
#dup+Wc/2

Phát lại gói mất . Mỗi ACK
nhân bản ‘thổi phồng’ Wc

Trạng thái 3
#dup+Wc/2-ACK

ACK nội bộ làm giàm cwnd,
các gói trước khi nhận

#dup+Wc/2-ACK

Phát lại gói bị mất ( ). Wc vẫn
duy trì khơng đổi

Trạng thái 4

Trạng thái 5
#dup+Wc/2-ACK

Wc/2
Trạng thái 7

Thốt trạng thài khơi phục và làm
giảm Wc khi nhận được

Phát lại gói

ACK khơng nhân bản
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 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 thố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ổ hồn tồn.
VI.

Wmin

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 q mức của
nó vượt qua điểm bảo hịa với sự mất gói rất nhỏ. Tồ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.

Mất gói do sự kiện tắc nghẽn thấp

Số lượng gói đang chuyển tiếp

Giới hạn mạng

Hình 9. Tìm kiếm nhị phân để đạt kích thước cửa sổ tối ưu.

Nhận ra mất gói (3 ACK nhân bản)

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

Wmax

Thời gian

Các ACK nhân bản chỉ làm
Wc “phình ra” thêm

Trạng thái 6

X

Cửa sổ tắc nghẽn

Dữ liệu đã
được ACK

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.

GIẢI PHÁP BIC-TCP

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

56
56


HộiHội
Thảo
Quốc
vàCông
CôngNghệ
Nghệ
Thông
(ECIT
2015)
Thảo
QuốcGia
Gia2015
2015về
vềĐiện
Điện Tử,
Tử,Truyền
Truyền Thông
Thông và

Thông
TinTin
(ECIT
2015)
đế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).

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.

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 q 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ó đố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 q trình
này kích thước cửa sổ được tăng với mức tăng cố định. BICTCP 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 q trình tăng cơng và thăm dị giá trị
cực đại.
Tăng
cộng

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.

Tìm kiếm
nhị phân

Wmax

Thăm dò cực đại

Hàm phát triển cửa sổ CUBIC sử dụng hàm sau :
a)

Hàm phát triển cửa số BIC-TCP

(4)
𝑊𝑊(𝑡𝑡) = 𝐶𝐶(𝑡𝑡 𝑡 𝑡𝑡)3 + 𝑊𝑊𝑊𝑊𝑊𝑊𝑊𝑊
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

Trạng thài ổn định

Wmax

Thăm dò cực đại

b)

Hàm phát triển cửa số CUBIC

K được tính theo cơng thức sau ;

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 BICTCP 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

3 Wmaxβ

K= √

β : Hệ số giảm bội số

C

(5)

Vào lúc nhận một ACK trong giai đoạn tắc nghẽn, CUBIC
tính tố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ơ

57
57


HộiHội
Thảo
Quốc Gia 2015 về Điện Tử, Truyền Thông và Công Nghệ Thông Tin (ECIT 2015)
Thảo Quốc Gia 2015 về Điện Tử, Truyền Thơng và Cơng Nghệ Thơng Tin (ECIT 2015)
hì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.

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 ).

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

RTT

α

x√ x
2

2−β
β

x

1

(6)

p

Kích thước cửa sổ trung bình của TCP với α = 1 và β = 0,5 là
1

RTT

3

1

(7)

x√ x
2 p

Hình-12 biến động cửa sổ tắc nghẽn của giải thuật Tahoe

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à
β

t

(8)

x
Wtcp(t) = Wmax(1 − β) + 3
2−β RTT

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Ả

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

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.

Vùng lõm

Cả 2 vùng
lõm và lồi

Internet
Ftp Server

Router

Router

Client
Subnet HN

Subnet HCMC

Hình-11 Mơ hình mạng giả lập

Hình-14 Biến động cửa sổ tắc nghẽn của giải thuật Cubic

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

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 .

58
58


Hội Thảo Quốc Gia 2015 về Điện Tử, Truyền Thông và Công Nghệ Thông Tin (ECIT 2015)
Hội Thảo Quốc Gia 2015 về Điện Tử, Truyền Thông và Công Nghệ Thông Tin (ECIT 2015)

LỜ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.

[5]
[6]

TÀI LIỆU THAM KHẢO
[1]
[2]
[3]
[4]

[7]

J.Postel, “ RFC 793- Transmission Control Protocol “, RFC, 1981.
S. Floyd,T. Henderson and A. Gurtov, “RFC3782 – The NewReno
modification to TCP’s fast recovery algorithm,“ RFC, 2004.
V. Jacobson, “ Congestion avoidance and control, ” ACM
SIGCOMM,pp. 314-329, 1988.
V. Jacobson, “ Modified TCP congestion avoidance algorithm,“ email to
the end2end list, 4/1990

[8]
[9]

59
59

S. Floyd and T. Henderson, “RFC2582 – The NewReno modification to
TCP’s fast recovery algorithm,“ RFC, 1999.
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.
S. Floyd,T. Henderson, A. Gurtov and Y. Nishida, “RFC6582 – The
NewReno modification to TCP’s fast recovery algorithm,“ RFC, 2012.
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
Peng Yang, Wen Luo, Lisong Xu, Jitender Deogun, and Ying Lu , “TCP
Congestion Avoidance Algorithm Identification,“ 31st International
Conference on Distributed Computing System, 2011