Nguyên lý bảo toàn gói tin trong điều khiển lưu lượng TCP: ”giữ cho số gói số liệu có mặt trong mạng của một kết nối không thay đổi”
2.4.2.1 Reno, new-Reno, SACK v.v Cho mạng truyền thông có dây Reno TCP:
Reno TCP:
Reno TCP đã giữ lại những điểm nổi bật hợp thành lên Tahoe TCP nhưng đã sửa thuật toán phát lại nhanh để thêm vào thuật toán khôi phục nhanh. Thuật toán mới này ngăn chặn đường truyền thông sẽ bị rỗng sau khi phát lại nhanh (do bắt đầu Slow Start lại), vì thế tránh được việc cần thiết phải có thuật toán Slow Start để làm đầy lại đường truyền thông sau khi xảy ra sự mất mát của gói tin.
Khôi phục nhanh (fast recovery) hoạt động bằng cách giả thiết rằng mỗi biên nhận lặp ACK đã nhận, sẽ đại diện cho một gói tin đã vừa ra khỏi đường truyền thông. Do đó, trong suốt thời gian khôi phục nhanh, người gửi có thể thực hiện những ước lượng thông minh về khối lượng dữ liệu còn tồn tại.
Fast recovery được đưa vào bởi TCP người gửi sau khi nhận một ngưỡng khởi tạo của cácc biên nhận lặp. Giá trị ngưỡng này thường được biết đến như là tcprexmtthresh, thường được gán giá trị bằng 3. Khi giá trị ngưỡng của các biên nhận lặp được nhận, người gửi truyền lại một gói và giảm bớt cửa sổ tắc nghẽn của mình xuống một nửa. Thay vì Slow Start, như được thực hiện bởi người gửi ở Tahoe TCP,
người gửi Reno TCP sử dụng các biên nhận lặp mới đến thêm vào để điểm giờ cho các gói tin sắp đi ra tiếp sau.
Sau đây là sơ đồ hoạt động của Reno TCP:
Hình 22. Hoạt động của Reno TCP
Trong hoạt động của Reno TCP, cửa sổ có thể sử dụng được của người gửi trở thành min(awin,cwnd+ndup), ở đây awin là cửa sổ đã thông báo của người nhận, cwnd là cửa sổ tắc nghẽn của người gửi,và ndup được duy trì tại 0 cho đến khi số lượng các biên nhận lặp đạt tới tcprexmtthresh, và sau đó theo dõi số lượng của các biên nhận lặp. Do đó, trong giai đoạn fast recovery người gửi tăng thêm cửa sổ của mình bằng số lượng của các biên nhận lặp mà nó đã vừa nhận, phụ thuộc vào sự theo dõi mỗi biên nhận lặp đó và chỉ ra vài gói tin đã bị đi ra khỏi mạng và đón được tại phía người nhận.sau khi đưa vào thuật toán fast recovery và gửi lại một gói đơn lẻ, người gửi chờ cho đến khi một nửa cửa sổ của các biên nhận lặp được nhận, và rồi gửi một gói tin mới cho mỗi biên nhận lặp thêm vào mà đã được nhận. Cho đến khi nhận một biên nhận ACK cho một gói tin mới (được gọi là biên nhận phục hồi, “recovery ACK”), người gửi thoát khỏi fast recovery bằng cách đặt ndup tới 0.
Hình 23. Reno TCP với một gói tin bị loại bỏ
Với Reno TCP, thuật toán fast recovery của nó đưa đến sự thực thi tối ưu trong khuôn cảnh này. Cửa sổ tắc nghẽn người gửi bị giảm xuống một nửa, các biên nhận lặp mới đến đã được sử dụng để điểm giờ cho các gói tin sắp đi ra, nó tránh được Slow Start.
Các hoạt động của Reno như trên là giống với Tahoe cho đến khi biên nhận thứ tư cho gói tin 13 được nhận ở người gửi. Các biên nhận tương ứng với các gói từ 15 đến 28 bao gồm 14 biên nhận lặp cho gói tin 13. Biên nhận lặp thứ ba gây ra việc truyền lại của gói tin 14, làm cho người gửi phải dùng đến fast recovery, và giảm cửa sổ tắc nghẽn của nó xuống, ngưỡng Slow Start được đặt tới bẩy.
Trong giai đoạn fast recovery, việc nhận biên nhận lặp thứ tư đưa cửa sổ có thể sử dụng được đến 11, và bởi biên nhận lặp thứ 14 cửa sổ có thể sử dụng được đạt đến 21. Cửa sổ đã tăng thêm từ sáu biên nhận lặp vừa rồi cho phép ngưòi gửi gửi các gói tin từ 29 đến 34. Cho đến khi biên nhận cho gói 28, người gửi thoát khỏi fast recovery và tiếp tục thực hiện congestion avoidance với cửa sổ tắc nghẽn là bảy.
Hình 24. Hoạt động chi tiết của Reno TCP với một gói tin bị loại bỏ New-Reno
New-Reno có một sửa đổi nhỏ trong thuật toán frcv để cải thiện hiệu năng trong trường hợp một cửa sổ có trên một gói số liệu bị loại. Sự thay đổi liên quan đến hành vi của bên gửi trong quá tình thực hiện frcv, khi nhận được một biên nhận một phần (partial ACK), đó là một biên nhận mới, nhận được sau khi thực hiện phát lại nhanh, biên nhận này có số thứ tự nhỏ hơn số thứ tự của byte cuối cùng đã truyền khi thực hiện phát lại nhanh. Mỗi biên nhận từng phần biên nhận cho một số chứ không phải là tất cả các gói số liệu đã đi vào trong mạng từ khi bắt đầu giai đoạn frcv, do đó nó chỉ ra việc có nhiều gói số liệu bị mất trong một cửa sổ phát.
Trong Reno TCP, biên nhận từng phần không làm cho TCP ra khỏi giai đoạn frcv, ngược lại, việc nhận được các biên nhận từng phần được coi như là một tín hiệu
báo rằng gói số liệu đi sau (có thứ tự tiếp theo) gói số liệu được biên nhận đã bị mất
và nó cần được truyền lại. Như vậy, khi trong một cửa sổ có nhiều gói số liệu bị mất, new-Reno có thể phát lại ngay chứ không bị hết giờ. Mỗi gói số liệu bị mất được phát lại trong khoảng thời gian khứ hồi cho đến khi tất cả các gói số liệu bị mất trong cùng cửa sổ đã được phát lại hết. New-Reno sẽ vẫn ở trong trạng thái frcv cho đến khi mọi gói số liệu được gửi đi từ khi bắt đầu thực hiện frcv được nhận hết.
Hình 25. Hoạt động của New Reno TCP, trường hợp có ba gói số liệu bị loại bỏ
Trường hợp trong một cửa sổ chỉ có một gói số liệu bị loại, hoạt động của new-Reno và Reno là giống nhau. Hình 25 minh hoạ sự hoạt động của new-Reno trong trường hợp có ba gói số liệu bị loại.
SACK TCP
Trong SACK TCP (Selective ACKnowledgement TCP) mỗi segment có chứa một trường tuỳ chọn SACK, trường này gồm một số khối SACK, mỗi khối chứa các thông tin về một khối dữ liệu đã được nhận, nhưng không đúng thứ tự, đang được bên nhận chứa trong bộ đệm. Khối SACK thứ nhất chứa thông tin về gói số liệu nhận được mới nhất, khối SACK thứ hai cũng chứa các thông tin như vậy. Việc bổ sung tuỳ chọn SACK vào giao thức TCP không làm thay đổi cơ chế điều khiển tắc nghẽn bên trong của nó, SACK TCP vẫn bảo toàn được các đặc tính của Tahoe và Reno TCP là mạnh trong trường hợp có các gói số liệu đến không đúng thứ tự, nó sử dụng cơ chế phát lại khi bị hết giờ như giải pháp cuối cùng.
Hình 26 minh hoạ sự hoạt động của SACK TCP trong trường hợp có ba gói số liệu bị loại.
Hình 26. Hoạt động của SACK TCP, trường hợp có ba gói số liệu bị mất
SACK TCP giống Reno TCP ở chỗ: SACK TCP đi vào giai đoạn frcv khi bên gửi nhận được số biên nhận lặp bằng tcprexmtthresh; bên gửi sẽ phát lại gói số liệu và giảm cwnd xuống còn một nửa.
SACK TCP khác Reno TCP ở chỗ: trong khi thực hiện frcv, SACK TCP duy trì một biến được gọi là pipe. Biến này biểu diễn ước lượng số gói số liệu đã gửi vào mạng nhưng chưa có biên nhận. Bên gửi chỉ gửi dữ liệu mới hoặc phát lại khi ước lượng nói trên nhỏ hơn cửa sổ tắc nghẽn cwnd. Biến pipe sẽ được tăng thêm một mỗi khi bên gửi phát đi một gói số liệu mới hoặc phát lại một gói số liệu cũ, nó giảm đi một khi bên gửi nhận được một gói số liệu biên nhận lặp, trong đó trường tuỳ chọn SACK cho biết rằng bên nhận đã nhận được dữ liệu mới.
Trong trường hợp một cửa sổ có không quá một gói số liệu bị loại, hoạt động của SACK TCP cũng giống như Reno và new-Reno TCP. SACK TCP khác Reno TCP một cách căn bản khi nhiều gói số liệu trong một cửa sổ bị loại.
Nhận xét các biện pháp thực thi TCP:
• Hiệu suất của Tahoe TCP không bị giảm quá mạnh khi tỉ lệ gói tin hỏng tăng. • Reno TCP có hiệu suất cao hơn hẳn Tahoe TCP khi trong một cửa sổ có một
gói số liệu bị loại. Số gói số liệu bị loại trong một cửa sổ càng tăng thì hiệu suất của Reno TCP càng tồi. Ngay cả trường hợp trong một cửa sổ có hai gói
số liệu bị loại, hiệu suất của Reno TCP đã thấp hơn hiệu suất của Tahoe TCP nhiều.
• New-Reno và SACK TCP có hiệu suất cao hơn Tahoe và Reno khi số gói số liệu bị loại trong một cửa sổ lớn hơn một. Khi số gói số liệu trong một cửa sổ bị loại tăng lên trên hai, SACK TCP có hiệu suất cao hơn new-Reno TCP. Đó là vì new-Reno chỉ có thể phát lại nhiều nhất là một gói số liệu bị loại trong mỗi khoảng thời gian khứ hồi, gây ra sự trễ lớn trong việc phát lại các gói số liệu bị loại tiếp theo trong cùng cửa sổ.