Khi không có lỗi hoặc lỗi rất nhỏ thì thông lƣợng của TCP lớn hơn thông lƣợng của TCP+FEC, nguyên nhân vì TCP+FEC cần truyền thêm các thông tin dƣ thừa để phát hiện và sửa lỗi. Lúc lỗi nhỏ hơn 0.01, lƣợng thông tin dƣ thừa
trong FEC đủ để khắc phụ lỗi, do đó thông lƣợng của TCP+FEC vẫn không đổi, trong khi thông lƣợng của TCP không sử dụng FEC bị suy giảm nghiêm trọng. Xác suất lỗi vƣợt quá 0.01 thì lƣợng thông tin dƣ thừa truyền trong TCP+FEC không còn đủ để TCP kiểm tra và tự sửa đƣợc lỗi, TCP sẽ phát yêu cầu phát lại các gói tin bị hỏng, do đó thông lƣợng của TCP+FEC bắt đầu bị suy giảm.
Nhƣợc điểm của thuật toán này là thông tin dƣ thừa bổ sung thêm vào sẽ không cần sử dụng đến trong những lúc trạng thái đƣờng truyền là tốt, gây ra sự lãng phí dải thông. Ngoài ra, việc tính toán đối với thông tin bổ sung này cũng cần đến thời gian xử lý của CPU và bộ nhớ. Tuy nhiên, trong những tình huống kênh truyền có khoảng cách lớn kết hợp với tỉ suất lỗi cao, ƣu điểm của FEC rất xứng đáng với cái giá phải trả. Kỹ thuật FEC còn có một ƣu điểm nổi bật nữa là nó không cản trở các cơ chế điều khiển của giao thức TCP. Với các ƣu và nhƣợc điểm trên, FEC thƣờng đƣợc sử dụng trong truyền thông vệ tinh và truyền thông vũ trụ.
3.2. TCP SACK
Trong SACK 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 có kích thƣớc 8 byte, 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 tƣơng tự nhƣ vậy.
Các thuật toán điều khiển tắc nghẽn cài đặt trong SACK TCP là sự cải tiến đồng thời kế thừa những kỹ thuật điều khiển tắc nghẽn của Reno TCP. Việc đƣa thông tin SACK vào TCP không làm thay đổi các cơ chế điều khiển tắc nghẽn hiện có và vẫn giữ nguyên tính hiệu quả của Tahoe và Reno TCP trong trƣờng hợp các gói tin đến không đúng theo trình tự gửi cũng nhƣ sử dụng đồng
hồ phát lại. Điểm phân biệt chính giữa SACK TCP và Reno TCP là ở cách xử lý khi có nhiều gói tin bị loại bỏ trong cùng một cửa sổ dữ liệu.
Giống nhƣ NewReno, SACK TCP cài đặt ở thực thể phát thực hiện Fast Recovery khi số biên nhận lặp nhận đƣợc đạt tới giá trị tcprexmtthresh. Bên phát sẽ phát lại một gói tin và giảm kích thƣớc cửa sổ tắc nghẽn đi một nửa. Trong quá trình Fast Recovery, SACK duy trì một giá trị gọi là pipe, đó là số gói tin còn đang nằm trên đƣờng truyền (đây là một giá trị ƣớc lƣợng). Bên gửi chỉ gửi các gói tin mới hoặc gửi lại dữ liệu khi pipe nhỏ hơn cửa sổ tắc nghẽn,
pipe đƣợc tăng thêm 1 đơn vị mỗi khi bên gửi phát đi hay phát lại một gói tin. Do do, giá trị pipe đƣợc giảm đi một đơn vị mỗi khi nhận đƣợc một báo nhận. Việc sử dụng biến pipe giúp TCP tách đƣợc quyết định gửi gói tin khi nào khỏi quyết định gửi gói tin nào. Thực thể nhận sử dụng cấu trúc dữ liệu scoreboard để lƣu trữ các biên nhận từ thông tin SACK trƣớc đó. Khi bên gửi có thể gửi một gói tin mới, nó chỉ gửi lại gói tin tiếp theo trong danh sách các gói tin đƣợc cho là đã thất lạc. Nếu không có gói tin nào nhƣ thế và kích thƣớc cửa sổ thông báo đủ lớn, bên gửi sẽ gửi đi một gói tin mới. Trong trƣờng hợp gói tin bị mất, SACK TCP có thể phát hiện ra điều này căn cứ vào việc hết giờ của đồng hồ phát lại và phát lại gói tin đó và chuyển sang chế độ slow start.
Trong TCP SACK, việc sử dụng biên nhận có chọn lọc - SACK (Selective ACK) cho phép phát lại nhiều gói tin bị mất từ một cửa sổ trong một khoảng thời gian khứ hồi RTT, qua đó làm giảm đáng kể thời gian phục hồi cửa sổ phát (liên quan trực tiếp đến thông lƣợng) nhất là khi RTT lớn (nhƣ đƣờng truyền vệ tinh).
Nhiều gói tin bị mất trong một RTT làm giảm nhanh chóng thông lƣợng của TCP. TCP sử dụng phƣơng pháp biên nhận tích luỹ các gói tin nhận đƣợc [16]. Khi các gói tin bị mất hoặc không đến đúng thứ tự, TCP sẽ luôn thông báo cho bên gửi biết gói tin mà nó mong muốn nhận đƣợc. TCP nhận không thông báo
về trạng thái của các gói tin khác đã đƣợc gửi sau gói tin bị mất hoặc đến không đúng thứ tự. Khi đã phát hết các gói tin trong một cửa sổ, TCP phát sẽ đợi các biên nhận từ TCP nhận.
Trong mô hình TCP ban đầu sử dụng phát lại go-back-n, nếu nhận đƣợc các biên nhận không đúng thứ tự, TCP sẽ phát lại toàn bộ các gói tin kể từ gói tin không đúng thứ tự đó [31]. Mô hình sẽ không đạt đƣợc hiệu suất cao, vì rất có thể nhiều gói tin đã đến đƣợc bên nhận nhƣng vẫn đƣợc phát lại.
Các cải tiến trong các phiên bản sau của TCP (Tahoe, Reno, Newreno) có đƣa thêm các thuật toán SS, CA, FRTX, FRTV nhằm hạn chế tắc nghẽn, nhanh chóng phát lại các gói tin bị mất, do đó làm tăng hiệu suất TCP. Tuy nhiên các thuật toán trên không giúp TCP biết đƣợc chính xác trong nhiều gói tin đƣợc phát trong một RTT, gói nào đã đến đƣợc đích (đã đƣợc xử lý hoặc nằm ở vùng đệm), gói tin nào chƣa đến đích. Nếu biết đƣợc chính xác thông tin đó thì TCP chỉ cần phát lại các gói tin chƣa đến đƣợc đích (thực sự bị mất).
SACK TCP đƣợc thiết kế để giải quyết vấn đề đƣợc nêu ở trên. SACK đã đƣợc V.Jacobson mô tả sơ lƣợc trong [14] và đƣợc S. Floyd mô tả chi tiết trong [16]. SACK TCP sẽ chỉ cho bên phát dữ liệu biết chính xác các gói tin nào đã đƣợc nhận, nhờ các thông tin đó mà bên gửi chỉ cần gửi lại các gói thực sự bị mất.
Để thực hiện đƣợc chiến lƣợc trên, SACK TCP đã đƣa thêm vào các trƣờng lựa chọn SACK (SACK option). Các trƣờng lựa chọn này đƣợc thêm vào trong các biên nhận của TCP nhận dữ liệu, các biên nhận này sẽ đƣợc báo nhận trở lại cho TCP phát dữ liệu.
Với SACK TCP, khi thiết lập kết nối giữa thực thể TCP phát và TCP nhận, vẫn thực hiện việc “bắt tay 3 bƣớc”. Tuy nhiên có một sửa đổi nhỏ là trong bƣớc 2, khi TCP phát thực hiện gửi lại gói dữ liệu đồng bộ (SYN) cho TCP
phát, TCP phát sẽ gửi lựa chọn cho phép SACK (SACK-Permitted Option) với cấu trúc nhƣ hình 3.2.