Tìm hiểu các cơ chế của TCP reno và TCP vegas

TIỂU LUẬN MÔN HỌC
MẠNG VÀ KỸ THUẬT TRUYỀN DỮ LIỆU
Đề tài:
Tìm hiểu các cơ chế của TCP Reno và TCP Vegas
MỤC LỤC
A. LỜI NÓI ĐẦU 3
B. NỘI DUNG 4

2
A. LỜI NÓI ĐẦU
Giao thức TCP (Transmission Control Protocol - "Giao thức điều khiển
truyền vận") là một trong các giao thức cốt lõi của bộ giao thức TCP/IP. Sử
dụng TCP, các ứng dụng trên các máy chủ được nối mạng có thể tạo các "kết
nối" với nhau, mà qua đó chúng có thể trao đổi dữ liệu hoặc các gói tin. Giao
thức này đảm bảo chuyển giao dữ liệu tới nơi nhận một cách đáng tin cậy và
đúng thứ tự. TCP còn phân biệt giữa dữ liệu của nhiều ứng dụng (chẳng hạn,
dịch vụ Web và dịch vụ thư điện tử) đồng thời chạy trên cùng một máy chủ.
TCP hỗ trợ nhiều giao thức ứng dụng phổ biến nhất trên Internet và các
ứng dụng kết quả, trong đó có WWW, thư điện tử và Secure Shell.
Trong bộ giao thức TCP/IP, TCP là tầng trung gian giữa giao thức IP bên
dưới và một ứng dụng bên trên. Các ứng dụng thường cần các kết nối đáng tin
cậy kiểu đường ống để liên lạc với nhau, trong khi đó, giao thức IP không cung
cấp những dòng kiểu đó, mà chỉ cung cấp dịch vụ chuyển gói tin không đáng tin
cậy. TCP làm nhiệm vụ của tầng giao vận trong mô hình OSI đơn giản của các
mạng máy tính.
Trong khuôn khổ tiểu luận này sẽ chỉ trình bày về các giao thức cải tiến của
TCP đó là: TCP Reno và TCP Vegas, tiếp đó sẽ đưa ra hai phương pháp để giải
quyết vấn đề nhằm làm tốt hơn sự chuyển từ Reno sang Vegas. Xin chân thành
cảm ơn TS Võ Thanh Tú đã giúp đỡ chúng tôi trong việc hoàn thành tiểu luận
này.
3

B. NỘI DUNG
I. Mô tả về TCP Reno và TCP Vegas.
Một kết nối TCP gồm 3 thành phần: bên gửi, định tuyến và bên nhận. Bên
gửi sử dụng một số thuật toán để đánh giá và điều khiển một lượng dữ liệu để
truyền sang bên nhận thông qua một số router. Một router trong kết nối TCP chỉ
làm nhiệm vụ chuyển tiếp dữ liệu. Bên nhận nhận được gói tin sẽ phúc đáp cho
bên gửi tín hiệu ACK. Nếu có bất kỳ một trở ngại nào về gói nhận được, bên
nhận sẽ gửi một gói ACK trở lại cho bên gửi.
1. TCP Reno.
Để điều khiển truyền thông TCP Reno sử dụng hầu hết các cơ chế điều khiển
như: Cơ chế cửa sổ trượt, cơ chế bắt đầu chậm, cơ chế tránh tắc nghẽn, cơ chế
phát lại nhanh và cơ chế phục hồi nhanh. Thuật toán của TCP Reno nhu sau:
Ban đầu khi một kết nối được thiết lập thì TCP Reno đặt ngưỡng của cửa sổ phát
có độ lớn tối đa và cwnd bằng 1 Segment.
Tại thời điểm (t+1) thì chỉ xảy ra ở 1 trong các trường hợp sau:
* Trường hợp 1: Trạm phát nhận được Segment hồi đáp ACK (Truyền nhận
thành công):
Nếu w <= ssth thì:
Sử dụng cơ chế bắt đầu chậm:
Kích thước cửa sổ được cập nhật: w(t+1) = w(t) + 1
Ngoài ra (Cho trường hợp w>ssth)
Tăng kích thước w theo tuyến tính:
Kích thước cửa sổ được cập nhật: w(t+1) = w(t) + 1/w(t)
* Trường hợp 2: Trạm phát nhận 3 Segments ACK hồi đáp trùng lặp số hiệu:
Sử dụng cơ chế phát lại nhanh và phục hồi nhanh:
Đặt lại ngưỡng: ssth = w(t)/2
Kích thước cửa sổ được cập nhật: w(t+1) = ssth
* Trường hợp 3: Khi phát hiện có Segment bị Time Out
Đặt lại ngưỡng: ssth = w(t)/2
Kích thước cửa sổ được cập nhật: w(t+1) = 1

Sử dụng cơ chế bắt đầu chậm
4
Như vậy TCP Reno điều khiển cửa sổ phát bằng cách nhận thông tin từ Segment
hồi đáp ACK và Segment bị Time Out. Hình 1 mô tả cơ chế hoạt động của TCP
Reno
Sự cải tiến của TCP Reno ở đây là sau khi sử dụng cơ chế phát lại nhanh nó sử
dụng cơ chế phục hồi nhanh. Như vậy TCP Reno đã tận dụng được đường
truyền, cho nên thông lượng trên đường truyền tăng lên một cách đáng kể.
1) Cơ chế bắt đầu chậm: khi một kết nối bắt đầu hoặc bị trễ xảy ra, trạng
thái bắt đầu chậm bắt đầu hoạt động. Giá trị ban đầu của cwnd được đặt là
1 gói tin cho trạng thái ban đầu trong trường hợp này. Trạm gửi tăng
cwnd theo hàm mũ bằng cách thêm mỗi lần một gói khi nó nhận được
ACK. Cơ chế bắt đầu chậm điều khiển kích thước cửa sổ cho đến khi
cwnd đạt đến mức đã được thiết, lập trước đó gọi là ngưỡng bắt đầu chậm
(ssthresh). Khi cwnd vượt ra khỏi ssthresh , việc tránh tắc nghẽn sẽ bắt
đầu.
2) Cơ chế tránh tắc nghẽn: khi kích thước cửa sổ trong trạng thái bắt đầu
chậm vượt qua hàm mũ, những gói tin gởi đi trong thời điểm này tăng lên
một cách nhanh chóng nên gây ra sự tắc nghẽn. Để giải quyết vấn đề này
cơ chế “tránh tắc nghẽn” được khởi tạo khi cwnd vượt quá ssthresh.
Trong trường hợp này, cwnd được cộng thêm 1/cwnd gói mỗi lần nó nhận
được ACK để tăng kích thước cửa sổ theo hàm tuyến tính.
5
Fast
retransmissio
n
Retransmission
timout
Congestion
avoidance

Slow start Fast recovery
Time Out
all ACK
timeout
timeout
w≥ssthresh

start
send missing
packet
non-dup ACK
≥ 3 dup ACK
≥ 3 dup ACK
w=w+1 w=w+1/w
w=w+1
dup ACK
ACK
ACK
Hình 1: Cơ chế hoạt động của TCP Reno
3) Cơ chế truyền lại nhanh: Gói phản hồi ACK là nguyên nhân của một gói
không đúng thủ tục nhận được của bên nhận. Trạm gửi xử lý nó như một
tín hiệu cho gói bị mất hoặc gói bị trễ. Nếu 3 hoặc nhiều hơn gói hồi đáp
ACK được nhận tại một dòng, gói mất sẽ cũng tương tự như vậy. Bên gửi
sẽ thực hiện cơ chế truyền lại nhanh, nhưng gói được truyền là những gói
bị lỗi mà không cần đợi thời gian để coarse-grain kết thúc.
4) Cơ chế phục hồi nhanh: khi cơ chế truyền lại nhanh được thực thi,
ssthresh cài đặt bằng một nữa của cwnd và sau đó cwnd được cài đặt đến
ssthresh cộng với kích thước của 3 gói tin. Cwnd được thêm vào mỗi gói
với một lần nhận được ACK. Khi ACK của gói truyền lại được nhận,
cwnd cài đặt đến ssthresh và trạm gửi lại trở về tránh tắc nghẽn. Khi khởi

tạo lại, cwnd được đặt lại bằng ½ giá trị của cwnd sau khi đã phục hồi
nhanh.
2. TCP Vegas.
Trong báo cáo, họ cho rằng TCP Vegas có thể đạt được thông lượng cao hơn từ
37% đến 71% so với TCP Reno trên Internet. Sự phát lại các segments của nó
chỉ bằng từ 1/5 đến 1/2 của TCP Reno và cho rằng sự cải tiến thông lượng trên
đường truyền là làm sao giảm được các gói tin bị mất và giảm sự phát lại các gói
tin. Năm 1995 Ahn và các đồng sự đó kiểm nghiệm TCP Vegas trên SunOS
4.1.3 và cho chúng cạnh tranh trên mạng diện rộng và trên internet. Họ tuyên bố
TCP Vegas đạt được thông lượng cao, giảm sự phát lại và thời gian trung bình
của RTT ngắn hơn TCP Reno. Cùng thời gian đó một số nhà nghiên cứu chú ý
sự thực thi của TCP Vegas với hàng đợi RED trên Gateway. Họ báo cáo rằng
TCP Vegas sử dụng hàng đợi RED có kết quả tốt hơn hàng đợi Droptail. Trong
khoảng thời gian hơn 10 năm trở lại đây có nhiều nghiên cứu về TCP Vegas.
Trong các tài liệu của mình, các tác giả đều chỉ ra những ưu điểm và các khuyết
điểm của TCP Vegas. Khuyết điểm lớn nhất của TCP Vegas là nếu có sự cạnh
tranh trên đường truyền giữa TCP Vegas và các phiên bản TCP khác thì TCP
Vegas tỏ ra kém cạnh tranh, từ đó họ đưa ra các cải tiến để khắc phục các nhược
điểm của nó. Hiện nay TCP Vegas vẫn chưa được sử dụng rộng rãi trên
Internet.
Thuật toán điều khiển của TCP Vegas
Ý tường then chốt của TCP Vegas là ngăn ngừa các segments bị mất
trong quá trình truyền thông và tránh tắc nghẽn mạng. TCP Vegas điều khiển
kích thước cửa sổ tắc nghẽn bằng cách theo dõi các RTT (Round Trip Time).
RTT là thời gian được tính từ khi một segment được gửi đi từ trạm phát đến
6
trạm nhận, cho đến khi trạm phát nhận được segment hồi đáp ACK, chứa thông
tin về segment đó đó được nhận thành công. Nếu thời gian của các RTT được
theo dõi tăng, thì TCP Vegas nhận biết mạng sắp bị tắc nghẽn và thực hiện cơ
chế tránh tắc nghẽn. Nếu thời gian của các RTT giảm thì TCP Vegas nhận biết

mạng được khai thông và TCP Vegas thực hiện cơ chế tăng kích thước cửa sổ để
tận dụng thông lượng của đường truyền. Trong quá trình điều khiển truyền
thông, TCP Vegas sử dụng các cơ chế : Cơ chế cửa sổ trượt, cơ chế bắt đầu
chậm, tránh tắc nghẽn, phát lại nhanh, phục hồi nhanh và cơ chế điều khiển
truyền thông của nó. Cơ chế bắt đầu chậm được TCP Vegas sử dụng khi bắt đầu
một kết nối. Cơ chế phát lại nhanh và phục hồi nhanh được thực hiện khi nó
nhận được 1 hoặc 3 segments ACK trùng lặp số hiệu. Thuật toán TCP Vegas
thực hiện như sau:
Ký hiệu: D: là thời gian RTT được theo dõi d: là giá trị nhỏ nhất của các RTT
được theo dõi là các trị hằng
Thuật toán điều khiển của TCP Vegas :
Trong pha bắt đầu chậm TCP Vegas ước tính diff và so sánh nó với 1 ngưỡng α
(thường chọn bằng 1) nếu diff < α thì cửa sổ tắc nghẽn sẽ được tăng gấp đôi
trong mỗi lần nhận được ACK hồi đáp. Sau pha bắt đầu chậm TCP Vegas thực
hiện pha tránh tắc nghẽn. Khi TCP Vegas nhận 3 ACK trùng lặp số hiệu nó thực
hiện cơ chế phát lại nhanh và phục hồi nhanh, tuy nhiên trong pha này TCP
Vegas có cải tiến là nó đặt cửa sổ xuống còn 3/4 cửa sổ hiện hành trong khi TCP
Reno đặt là 1/2. Khi phát hiện có segment bị Timeout TCP Vegas thực hiện
giống TCP Reno.
Ảnh hưởng của các tham số trong thuật toán TCP Vegas
• v_alpha_
• v_beta_
• v_gamma_
• v_rtt_
TCP Vegas dựa vào sự quan sát các RTT để điều khiển truyền thông. Các tham
số như: độ trễ d của đường truyền, độ trễ D của các RTT (D = d + thời gian trễ
trên bộ đệm) và việc thiết lập các giá trị α, β. Các tham số trên có ảnh hưởng lớn
đến việc điều khiển truyền thông của TCP Vegas trên mạng.
Trong một mạng chỉ dùng TCP Vegas thì thông lượng tăng, khả năng tránh tắc
nghẽn tốt, tỷ lệ mất gói tin giảm, nhưng khi mạng có sự tham gia của TCP Reno

thì khả năng cạnh tranh của nó tỏ ra kém hơn TCP Reno. Dễ thấy điều này qua
thuật toán của nó.
7
Các hằng số α, β thường được chọn là 1 và 3 (hoặc là 2 và 4). Khi cửa sổ của nó
đủ lớn, lưu lượng trên đường truyền cao, độ trễ của các RTT tăng (Do thời gian
chờ của các segments trên hàng đợi tăng) thì khả năng tăng kích thước cửa sổ rất
khó xảy ra . Nếu lớn hơn β TCP Vegas sẽ giảm kích thước cửa sổ xuống 1. Điều
này cho thấy TCP Vegas tăng hoặc giảm kích thước cửa sổ linh hoạt, dựa vào sự
quan sát độ trễ của các RTT và cách thiết lập trị số cho các hằng α, β. Trong
trường hợp dung lượng đường truyền nhỏ, độ trễ của đường truyền thấp, chiều
dài hàng đợi hạn chế, khả năng xử lý tại hàng đợi chậm, khả năng nghẽn mạng
có thể xảy ra. Nếu mạng chỉ sử dụng giao thức TCP Vegas thì thông lượng
đường truyền được nâng cao rõ rệt nhờ kích thước cửa sổ luôn được giữ ở mức
cao. Rõ ràng TCP ra đời nhằm đáp ứng những hạn chế về tài nguyên phần cứng
của mạng. TCP Reno tăng kích thước cửa sổ cho đến khi phát hiện sự mất các
segments, bất chấp RTT có tăng hay không. Với cơ chế như vậy nên khi TCP
Vegas tham gia truyền thông cùng với TCP Reno thì khả năng chiếm giữ đường
truyền và hàng đợi của TCP Reno nhiều hơn. TCP Vegas khó có cơ hội tăng
kích thước cửa sổ, do độ trễ trên hàng đợi tăng, trị số của α, β thiết lập nhỏ, làm
số lượng các segments trên mạng của TCP Vegas giảm.
II. Mô phỏng TCP Reno và TCP Vegas
Mô phỏng được thực hiện trên phần mềm NS-2 chạy trên hệ điều hành
Windows XP. Thời gian mô phỏng: 10 giây
Phương pháp mô phỏng: xây dựng 2 mô hình hoàn toàn giống nhau về các thông
số, mô hình thứ nhất sử dụng giao thức TCP Reno, mô hình thứ 2 sử dụng giao
thức TCP Vegas
8
Ta có biểu đồ mô tả thời gian và thông lượng của 2 mô hình như sau:
Biểu đồ của giao thức TCP Reno
9

Biểu đồ của giao thức TCP Vegas
III. Hai phương pháp cải tiến.
Như chúng ta đã biết Vegas sử dụng chung với Reno thì sẽ bị Reno chiếm
băng thông. Trong phần này sẽ đưa ra 2 phương pháp cải tiến đơn giản. Phương
pháp đầu tiên là hạn chế hoạt động của Reno. Chúng ta dùng lược đồ dò tìm sớm
ngẫu nhiên RED để giữ độ lớn hằng đợi trung bình ở mức thấp trong router. Do
đó cửa sổ phát triển của Reno bị giới hạn. Cách thứ 2 là tăng giá trị α và β của
Vegas đến một giá trị tốt nhất cho Vegas.
1. Phương Pháp RED.
Router có sử dụng hằng đợi RED dò tìm tắc nghẽn khi nó mới bắt đầu
bằng cách đo giá trị hàng đợi trung bình. Khi độ lớn hàng đợi tiến đến ngưỡng
cài đặt trước là tắc nghẽn xảy ra, router làm rơi mỗi gói đến với khả năng được
cho ở chức năng của độ dài hàng đợi trung bình. Lược đồ này duy trì độ lớn
hằng đợi trung bình ở mức thấp trong khi cho phép dao động ở độ lớn hằng đợi
trung bình để điều tiết sao cho giao thông trên đường truyền đông đúc và chuyển
sang trạng thái tắc nghẽn. Phương thức tránh vấn đề đồng bộ toàn cục mà ở đó
có nhiều kết nối để giảm kích thước cửa sổ cùng lúc. Trong router dùng RED,
kích thước hằng đợi trung bình được so sánh với 2 ngưỡng, min
th
và max
th
. Khi
giá trị trung bình giảm nhỏ hơn min
th
thì không có gói rơi. Khi giá trị trung bình
lớn hơn max
th
thì mỗi gói đến đều rơi. Khi giá trị trung bình ở giữa min
th
và

max
th
mỗi gói bị rơi với khả năng Pa, với Pa là hàm của giá trị trung bình. Gói
rơi có khả năng rơi số lượng nhiều khi có kết nối chia sẻ băng thông của router.
10
Mỗi Pa thời gian được tính toán lại và đạt đến Pb/(1- count x Pb) ở đây Pb tiến
đến Maxp x (avg – minth )/ (maxth – minth) và đếm số gói tin đến gói tin rơi
cuối cùng. Thay chính sách droptail bởi Red, giá trị hằng đợi trung bình ở mức
thấp được duy trì. Sử dụng chính sách Droptail, Reno sẽ phát triển không giới
hạn, cửa sổ của nó sẽ phát triển đến khi bộ đệm đầy. Tuy vậy sử dụng Red, Reno
sẽ gặp gói tin mất sớm và thường xuyên hơn. Vì thế Reno sẽ ít chiếm băng
thông và Vegas cải tiến cách thức của nó.
Mô phỏng hàng đợi Red
Biểu đồ thông lượng chung hai giao thức trong cùng mô phỏng
Dùng hàng đợi DropTail
11
TCP Reno
TCP Reno
TCP Vegas
TCP Vegas
Red
Reno
Vegas
Biểu đồ thông lượng chung hai giao thức trong cùng mô phỏng
Dùng hàng đợi Red
Thông tin mô phỏng
12
Reno
Vegas
Vegas - Red Vegas -DropTail

2. Tăng α và β.
Kết nối Vegas với α và β lớn hơn cho phép nhiều gói tin được giữ lại
trong bộ đệm và đưa đến kết quả thông lượng cao hơn. Chúng ta điều chỉnh α và
β để đạt kết quả với những biến này.
Một mô phỏng được tiến hành bằng cách thay đổi α và cài đặt β = α + 2.
Hình 7 chỉ ra Vegas với α cao hơn và β tốt hơn. Tuy nhiên, việc tăng này không
giới hạn tương ứng với tăng α và β. Tăng α quá 13 có kết quả không tốt về thông
lượng với Vegas và Reno vì khi α và β tăng lên cao, Vegas gặp phải nhiều gói
mất, giảm cửa sổ của nó thường xuyên hơn và cuối cùng nhận được trạng thái
ổn định. Cách khác, khi α và β nhỏ, mặt dù mất gói tin xảy ra chủ yếu ở kết nối
Reno, Vegas không mở rộng cửa sổ của nó vì giới hạn α và β
Hình 7. Thông lượng Vegas và Reno với α khác (β = α + 2)
Lưu ý rằng tổng băng thông của hầu hết hiệu dụng đáng kể đầy đủ của
những giá trị của α và β bởi vì khả năng rơi gói tin không tăng khi kích thước bộ
đệm cố định.
Những đường tỷ số thông lượng R chống lại α và β. Tăng β không có kết
quả khi β > α + 4. Trong trường hợp này, đường ở giữa 2 đường cong
và thì lớn. Kích thước cửa sổ của Vegas,
theo phương trình (3) là hoàn toàn điều khiển bởi hình dạng đường cong, độc lập
với đường cong gần hơn. Vì vậy, thậm chí cài đặt α tốt là quan trọng hơn cài đặt
β, α sẽ không quá thấp và β cũng không nhỏ hơn α nhận được. Tuy nhiên cài
đặt 1 giá trị α lớn không phải là nguyên nhân đưa đến khả năng rơi gói tin. Vì
vậy cuối cùng thì ta cũng phải chọn giá trị α và β thật sự đủ lớn.
13
Trong ví dụ mô phỏng, chúng tôi sử dụng 2 mô hình giống nhau, mô hình
thứ nhất cài đặt α=3, β=5 và mô hình thứ hai α=7, β=9. Kết quả là ở mô hình hai
thông lượng của Vegas được nâng cao nhưng số gói tin rơi nhiều hơn.
α=3, β=5
14
Reno

Vegas
α=7, β=9
TÀI LIỆU THAM KHẢO
1. TCP With Faster Recovery
2. E. Weigle and W. Feng. “A Case for TCP Vegas in High-Performance
Computational Grids.” In Proc
3. V. Jacobson. “Congestion Avoidance and Control.” In SIGCOMM 1988
15
Reno
Vegas