Trong những năm qua, một số TCP mới đã được đề xuất triển khai. Giao thức TCP đường cơ sở (TCP Reno) chỉ định khởi động chậm, tránh tắc nghẽn, truyền lại nhanh và phục hồi nhanh để kiểm soát tắc nghẽn. Giao thức TCP không thể phân biệt sự suy giảm hiệu suất do lỗi liên kết và tắc nghẽn. Nó giả định rằng bất kỳ tổn thất nào trong mạng chỉ là do tắc nghẽn và người gửi phản hồi bằng cách giảm tốc độ truyền gói của nó.
Giao thức TCP sử dụng cơ chế kiểm soát luồng cửa sổ, trong đó cửa sổ truyền cho phép TCP nhận kiểm soát lượng dữ liệu được gửi đến nó tại bất kỳ thời điểm nào. Người nhận quảng cáo kích thước cửa sổ cho người gửi. Cửa sổ đo lường, tính bằng byte, lượng dữ liệu chưa được xác nhận mà người gửi có thể có khi chuyển đến người nhận.
3.3.2.1 Độ trễ băng thông
Độ trễ băng thông (BOP) xác định lượng dữ liệu mà một kết nối TCP phải có "đang bay" (dữ liệu đã được truyền, nhưng chưa được ghi nhận) vào bất kỳ lúc nào để sử dụng hết dung lượng kênh khả dụng. Độ trễ được sử dụng trong trường hợp này là RTT và băng thông là dung lượng của liên kết nút cổ chai trong đường dẫn. Bởi vì RTT cho các vệ tinh GEO là lớn và các liên kết băng thông cao hơn được yêu cầu, TCP sẽ cần giữ một số lượng lớn các gói được gửi nhưng chưa được thừa nhận.
Trong các kết nối với một BOP lớn, chẳng hạn như mạng vệ tinh GEO, người gửi và người nhận TCP có cửa sổ nhận/tắc nghẽn hạn chế sẽ không thể tận dụng băng thông có sẵn. Cửa sổ TCP tối đa tiêu chuẩn là 65,535 byte không đủ để cho phép một kết nối TCP duy nhất sử dụng toàn bộ băng thông có sẵn trên một số kênh vệ tinh. Trong một mạng không mất mát, thông lượng TCP bị giới hạn bởi công thức sau:
Thông lượng tối đa = kích thước cửa sổ / RTT (3.3)
Do đó, khi sử dụng kích thước cửa sổ TCP tối đa là 65,535 byte và liên kết vệ tinh GEO với RTT là 560 ms, thông lượng tối đa bị giới hạn ở:
Thông lượng tối đa = 65,535 byte / 560 ms = 117,027 byte/ giây
Vì vậy, một kết nối TCP tiêu chuẩn duy nhất không thể sử dụng đầy đủ, ví dụ như kênh GEO tốc độ T1. Bảng 3.3 cho thấy RTT tối đa để có thể sử dụng băng thông nhất định với một kết nối TCP duy nhất sử dụng kích thước cửa sổ tối đa 64KB.
Bảng 3.4: RTT tương ứng với kích thước cửa sổ tiêu chuẩn tối đa là 64 KB ở các mức giá khác nhau Tỷ lệ RTT (Giây) 33.6 Kbps 128 Kbps 1.55 Kbps 10 Kbps 155 Kbps 622 Kbps 15.6 4.096 0.340 0.050 0.003 0.0008
Nói chung, các luồng TCP chia sẻ băng thông vệ tinh và ngay cả khi một luồng không thể sử dụng dung lượng kênh, các luồng khác có thể làm như vậy. Một vấn đề khác liên quan đến BOP cao là tính ổn định của các sơ đồ kiểm soát tắc nghẽn TCP. Khi BOP tăng lên, các kế hoạch quản lý hàng đợi hoạt động bao gồm phát hiện sớm ngẫu nhiên (RED), đánh dấu sớm ngẫu nhiên (REM) và hàng đợi ảo, cuối cùng sẽ trở nên không ổn định, dẫn đến hiệu suất thấp hơn.
3.3.2.2 Khởi động chậm và tránh tắc nghẽn
Người gửi TCP duy trì một biến được gọi là cửa sổ tắc nghẽn (cwnd) để đo dung lượng mạng. Số lượng gói tin chưa được xác nhận trong mạng được giới hạn ở cwnd hoặc rcvwnd tùy theo giá trị nào thấp hơn. Ban đầu, cwnd được đặt thành một phân đoạn và nó tăng lên một phân đoạn khi nhận được mỗi ACK mới cho đến khi nó đạt đến mức tối đa (thường là 65536 byte). Có thể thấy rằng bằng cách này, cwnd tăng gấp đôi mỗi RTT. Điều này cho thấy rằng mọi RTT, cwnd đều tăng theo cấp số nhân.
Người gửi duy trì thời gian chờ truyền lại cho gói chưa được xác nhận cuối cùng. Sự tắc nghẽn được biểu thị bằng việc hết thời gian chờ truyền lại. Khi bộ hẹn giờ hết hạn, người gửi sẽ lưu một nửa cwnd trong một biến có tên là ssthresh và đặt cwnd thành 1 phân đoạn. Sau đó, người gửi sẽ truyền lại các phân đoạn bắt đầu từ phân đoạn bị mất. cwnd được tăng lên một phân đoạn khi nhận được mỗi ACK mới cho đến khi nó đạt đến ssthresh. Đây được gọi là giai đoạn bắt đầu chậm. Sau đó, cwnd tăng một phân đoạn mỗi RTT. Điều này dẫn đến sự gia tăng tuyến tính của cwnd mỗi RTT và được gọi là giai đoạn tránh tắc nghẽn. Hình 3.17 cho thấy các giai đoạn khởi động chậm và tránh tắc nghẽn cho một kết nối TCP điển hình.
Hình 3.17 TCP Khởi động chậm và Tránh tắc nghẽn
TCP sử dụng cơ chế Khởi động chậm để thăm dò mạng khi bắt đầu kết nối. Thời gian cần thiết của khởi động chậm để đạt tốc độ bit B được tính theo công thức sau: Thời lượng khởi động chậm = RTT (l + log2 𝐵∗𝑅𝑇𝑇
𝑙 ) (3.4) trong đó l là độ dài gói trung bình được biểu thị bằng bit.
Trong bảng 3.4 thể hiện khoảng thời gian của pha Bắt đầu chậm đối với các loại vệ tinh khác nhau, LEO, MEO và GEO, và đối với các giá trị khác nhau của B, khi l = 1 KB, là giá trị chung cho kích thước phân đoạn. Rõ ràng là đối với các vệ tinh có độ trễ lâu, chẳng hạn như GEO, TCP ở chế độ Slow Start lâu hơn.
Bảng 3.5: Khoảng thời gian Bắt đầu chậm cho các vệ tinh LEO, MEO và GEO
Loại vệ tinh RTT (ms) Thời lượng bắt đầu chậm (giây)
B = 1 Mbps B = 10 Mbps B = 155 Mbps LEO MEO GEO 50 250 550 0.18 1.49 3.91 0.35 2.32 5.73 0.55 3.31 7.91
Nếu cơ chế ACK bị trì hoãn được thực hiện thì thời gian cần thiết của Slow Start để đạt đến tốc độ bit B được tính theo công thức sau:
Thời lượng khởi động chậm = RTT (l + log1.5 𝐵∗𝑅𝑇𝑇
𝑙 ) (3.5)
Điều đó có nghĩa là Khoảng thời gian bắt đầu chậm thậm chí còn dài hơn thời lượng trước đó. Do đó, ACK bị trễ là một nguồn khác của công suất lãng phí trong giai đoạn khởi động chậm.
Để tránh tắc nghẽn, tốc độ dữ liệu tăng trưởng là một chức năng của sản phẩm băng thông trễ. Trên thực tế, trong mỗi lần RTT, tốc độ dữ liệu được tăng lên 1/(B * RTT). Vì vậy, nếu kết nối TCP đang trong tình trạng tránh tắc nghẽn và một số băng thông khả dụng, kết nối này sẽ không sử dụng băng thông trong một thời gian dài. Thời gian này sẽ
lâu hơn khi có tổn thất đường truyền. Do đó, khả năng tránh tắc nghẽn trong mạng vệ tinh có RTT cao thực hiện thấp hơn so với mạng mặt đất.
3.3.2.3 Truyền lại nhanh và phục hồi nhanh
Hiện tại các triển khai TCP sử dụng mức độ chi tiết thô (thường là 500 ms) cho thời gian chờ truyền lại. Do đó, trong quá trình tắc nghẽn, kết nối TCP có thể mất nhiều thời gian chờ hết thời gian. Trong hình 3.18, đường cwnd nằm ngang cho thấy thời gian bị mất khi chờ hết thời gian. Trong thời gian này, TCP không gửi các gói mới cũng như không truyền lại các gói bị mất. Hơn nữa, khi hết thời gian chờ xảy ra, cwnd được đặt thành 1 phân đoạn và kết nối sẽ thực hiện nhiều chuyến khứ hồi để sử dụng hiệu quả mạng. TCP Reno triển khai các thuật toán khôi phục và truyền lại nhanh chóng cho phép kết nối nhanh chóng phục hồi sau các tổn thất phân đoạn bị cô lập.
Nếu một phân đoạn bị mạng bỏ qua, các phân đoạn tiếp theo đến người nhận là các phân đoạn không theo thứ tự cho mỗi phân đoạn đó, bộ nhận TCP ngay lập tức gửi một ACK cho người gửi cho biết số thứ tự của phân đoạn bị thiếu. ACK này được gọi là ACK trùng lặp. Khi người gửi nhận được ba ACK trùng lặp, nó kết luận rằng phân đoạn được chỉ ra bởi các ACK đã bị mất và ngay lập tức truyền lại phân đoạn bị mất. Sau đó, người gửi giảm cwnd xuống một nửa (cộng thêm 3 phân đoạn) và cũng lưu một nửa giá trị cwnd ban đầu trong ssthresh. Đối với mỗi ACK trùng lặp tiếp theo, người gửi tăng cwnd lên một và cố gắng gửi một phân đoạn mới. Một cách hiệu quả, người gửi đợi nửa chuyến khứ hồi trước khi gửi một phân đoạn cho mỗi ACK trùng lặp tiếp theo mà nó nhận được. Do đó, người gửi duy trì đường ống mạng ở một nửa dung lượng tại thời điểm truyền lại nhanh.
Khoảng một chuyến khứ hồi sau khi đoạn bị thiếu được truyền lại; ACK của nó được nhận (giả sử phân đoạn được truyền lại không bị mất). Tại thời điểm này, thay vì đặt cwnd thành một phân đoạn và tiến hành khởi động chậm cho đến khi cwnd đạt đến ssthresh, TCP đặt cwnd thành ssthresh và sau đó thực hiện tránh tắc nghẽn. Đây được gọi là thuật toán khôi phục nhanh.
Việc truyền lại và khôi phục nhanh cũng bị ảnh hưởng bởi RTT dài, điển hình cho các kết nối vệ tinh. Các kết nối này có thể đưa đủ phân đoạn mới vào mạng trong quá trình khôi phục để kích hoạt nhiều lần truyền lại nhanh trên mỗi cửa sổ dữ liệu, điều này có thể ảnh hưởng đến hiệu suất TCP.
Ảnh hưởng của BER đến thông lượng TCP là một yếu tố quan trọng khác. Như thể hiện trong hình 3.18, TCP có thể hoạt động kém khi có lỗi và nhạy cảm hơn với lỗi đối với kích thước cửa sổ lớn hơn. Để đạt được cửa sổ tắc nghẽn lớn hơn, TCP sẽ không bị tổn thất, điều đó có nghĩa là phải có BER thấp hơn.
Hình 3.18 Tác động của BER đến thông lượng TCP đối với các tệp lớn với kích thước cửa sổ là tham số. RTT = 590 và B = 2048 Kb / giây
Phần sau đây mô tả các cải tiến của giao thức TCP để xem xét các lỗi liên kết, độ trễ và không đối xứng băng thông.