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

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 TCPIP. 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ủ.

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 2

B NỘI DUNG 3

I Mô tả về TCP Reno và TCP Vegas 3

1 TCP Reno 3

2 TCP Vegas 5

II Mô phỏng TCP Reno và TCP Vegas 7

III Hai phương pháp cải tiến 9

1 Phương Pháp RED 9

2 Tăng α và β 12

TÀI LIỆU THAM KHẢO 14

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.

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

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

Fast retransmissio n

Retransmission timout

Congestion avoidance

Time Out

all ACK

timeou t

timeou t

wssthresh start

send missing

packet

non-dup ACK

 3 dup ACK

 3 dup ACK

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

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ó

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

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

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, minth và maxth Khi giá trị trung bình giảm nhỏ hơn minth thì không có gói rơi Khi giá trị trung bình lớn hơn maxth thì mỗi gói đến đều rơi Khi giá trị trung bình ở giữa minth và maxth 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

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

TCP Reno

TCP Reno

TCP Vegas

TCP Vegas

Red

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

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