Nhóm công tác IETF TCP qua vệ tinh gần đây đã đưa ra một số khuyến nghị để nâng cao hiệu suất của TCP qua các liên kết vệ tinh trong các RFC của mình.
3.3.3.1 Cửa sổ ban đầu lớn
Giai đoạn đầu của kết nối TCP bắt đầu với giá trị cwnd bằng 1 ở phía người gửi. Khi giai đoạn bắt đầu chậm tiến triển, cwnd được tăng lên dựa trên các ACK đến. Cửa sổ ban đầu lớn đề xuất bắt đầu với giá trị cwnd lớn hơn, cho phép nhiều phân đoạn hơn được truyền trong RTT đầu tiên của kết nối. Điều này lần lượt tăng tốc số lượng ACK nhận được từ người gửi, cho phép cửa sổ tắc nghẽn tăng với tốc độ nhanh hơn. Giá trị ban đầu của cwnd được xác định như sau:
cwnd = min {4 * SMSS, max {2 * MSS, 4380 byte}} (3.6)
nơi SMSS xác định kích thước phân đoạn tối đa của người gửi. Công thức này cho phép người gửi ban đầu truyền tối đa 4 phân đoạn, điều này có thể đặc biệt có lợi cho các kết nối tồn tại trong thời gian ngắn, chẳng hạn như các kết nối được sử dụng cho các giao dịch HTTP.
3.3.3.2 ACK bị trễ sau khi khởi động chậm
Máy thu thường không ACK mọi phân đoạn đến, mà là ACK mọi phân đoạn khác. Mặc dù điều này có thể có lợi trên các liên kết không đối xứng với băng thông thấp theo chiều quay trở lại, chiến lược này làm chậm sự phát triển của cửa sổ tắc nghẽn và có thể hạn chế thông lượng, vì các đường truyền mới được xử lý dựa trên các xác nhận đã nhận. Các ACK bị trễ sau khi khởi động chậm được thiết kế để chống lại các tác động của các ACK bị trì hoãn trên các đường dẫn trễ dài. Máy thu ghi nhận mọi phân đoạn đến trong giai đoạn bắt đầu chậm và quay trở lại thuật toán ACK bị trì hoãn trong quá trình tránh tắc nghẽn. Do đó, giai đoạn bắt đầu chậm được rút ngắn vì cửa sổ tắc nghẽn của người gửi đạt đến giá trị tối đa nhanh hơn. Trong khi thông lượng nói chung được cải thiện, sự mất mát tăng vừa phải có thể xảy ra vì người gửi đang tích cực đưa các phân đoạn vào mạng hơn. Hơn nữa, việc triển khai có thể khó đạt được vì không rõ người nhận sẽ biết được khi nào người gửi đã kết thúc giai đoạn bắt đầu chậm.
3.3.3.3 Đếm byte
Việc đếm byte đề xuất tăng cửa sổ tắc nghẽn dựa trên số lượng byte truyền được các ACK đến, thay vì số lượng ACK nhận được. Đặc biệt, đối với các đường có độ trễ dài, sơ đồ này đã được chứng minh là giảm lượng thời gian cần thiết để đạt được kích thước cửa sổ tắc nghẽn tối ưu. Bảng 3.5 cho thấy sự cải thiện thông lượng khi cwnd được tăng lên dựa trên việc đếm byte thay vì đếm ACK. Sự cải thiện đối với chuyển khoản ngắn hạn tốt hơn đối với chuyển nhượng dài hạn.
Bảng 3.6: Cải thiện thông lượng bằng cách sử dụng đếm byte
Kích thước tập tin Cải thiện thông lượng (%) 30 KB 100 KB 200 KB 1 MB 5 MB 9.4 16.9 15.3 8.5 9.5 3.3.3.4 TCP NewReno
Thuật toán TCP Reno thường không phục hồi tốt khi có nhiều mất mát phân đoạn trong giá trị dữ liệu của một cửa sổ. Chỉ phân đoạn bị mất đầu tiên được khôi phục thông qua thuật toán truyền lại nhanh, trong khi phần còn lại thông thường phải đợi thời gian chờ truyền lại trước khi khôi phục (giai đoạn khôi phục nhanh kết thúc sau khi quá trình truyền lại đầu tiên được chấp nhận).
Đề xuất TCP NewReno sửa đổi truyền lại nhanh/khôi phục nhanh các thuật toán khôi phục của TCP Reno để cho phép khôi phục từ nhiều mất mát phân đoạn. ACK cho một phân đoạn được truyền lại thông thường sẽ xác nhận tất cả các phân đoạn được truyền trước khi đi vào quá trình truyền lại nhanh (phát hiện mất mát từ các ACK trùng lặp). Tuy nhiên, nếu có nhiều phân đoạn bị mất, thì ACK sẽ chỉ xác nhận một số phân đoạn đang hoạt động. Điều này loại xác nhận cho một phân đoạn được truyền lại được gọi là xác nhận một phần. TCP NewReno là một. Sửa đổi đối với các thuật toán truyền lại nhanh/khôi phục nhanh để đáp ứng với các xác nhận một phần. Khi nhận được một phần ACK, phân đoạn chưa được xác nhận đầu tiên sẽ được truyền lại và thuật toán khôi phục nhanh tiếp tục (các ACK trùng lặp gây ra sự gia tăng cwnd bởi 1 và truyền một phân đoạn mới nếu được cwnd và rwnd cho phép). Đây là một chính sách tích cực vì phân đoạn chưa được xác nhận đầu tiên được truyền lại mà không cần đợi ba lần xác nhận trùng lặp hoặc hết thời gian truyền lại. Nó thể hiện sự cân nhắc quan trọng vì các bản sao như vậy có thể không bao giờ đến tay người gửi vì các phân đoạn mới không được gửi đến người nhận. Nếu không có sửa đổi này, người gửi có thể sẽ phải đợi thời gian chờ truyền lại, điều này ảnh hưởng nghiêm trọng đến thông lượng. TCP NewReno bị giới hạn trong việc truyền lại nhiều nhất một phân đoạn bị loại bỏ trên mỗi RTT, vì sự mất mát thứ hai không được phát hiện cho đến khi việc truyền lại đầu tiên được thừa nhận.
Hình 3.19 cho thấy đồ thị cửa sổ tắc nghẽn của kết nối TCP đối với ba tổn thất phân đoạn liền kề. TCP truyền lại một phân đoạn mỗi thời gian khứ hồi (được hiển thị bằng cwnd đi xuống 1 phân đoạn) cho đến khi nhận được ACK mới.
3.3.3.5 Thông báo chọn lọc TCP (SACK)
TCP với Thông báo xác nhận có chọn lọc (SACK) đã được đề xuất để khôi phục hiệu quả từ các tổn thất nhiều phân đoạn. Trong SACK TCP, xác nhận chứa thông tin bổ sung về các phân đoạn đã được đích nhận. Khi đích nhận được các phân đoạn không theo thứ tự, nó sẽ gửi các ACK (SACK) trùng lặp xác nhận các phân đoạn không theo thứ tự mà nó đã nhận được. Từ các SACK này, TCP gửi có thể cấu trúc lại thông tin về các phân đoạn không nhận được ở đích. Khi người gửi nhận được ba ACK trùng lặp, nó sẽ truyền lại đoạn bị mất đầu tiên và thổi phồng cwnd của nó lên một cho mỗi ACK trùng lặp mà nó nhận được. Hành vi này giống như TCP Reno. Tuy nhiên, khi người gửi được phép gửi một phân đoạn, nó sẽ sử dụng thông tin SACK để truyền lại các phân đoạn bị mất trước khi gửi các phân đoạn mới. Do đó, người gửi có thể khôi phục từ nhiều phân đoạn bị rớt trong khoảng một chuyến đi khứ hồi. Hình 3.20 cho thấy đồ thị cửa sổ tắc nghẽn của một SACK TCP phục hồi từ các mất đoạn. Trong thời gian cửa sổ tắc nghẽn tăng cao (sau khi quá trình truyền lại nhanh xảy ra), TCP sẽ gửi các gói bị thiếu trước bất kỳ gói mới nào.
Hình 3.20 Khôi phục TCP SACK từ mất gói Ví dụ về TCP SACK cho nhiều phiên TCP
Dưới đây là một ví dụ để nghiên cứu ảnh hưởng của nhiều phiên TCP. Nhiều phiên ngụ ý kích thước cửa sổ hoạt động mỗi phiên nhỏ hơn, các mất mát liên tục ít có khả năng chỉ ảnh hưởng đến một luồng nhất định. Do đó, tổn thất cụm được lan truyền trên nhiều kết nối TCP, điều này cải thiện hiệu quả của thuật toán khôi phục và truyền lại nhanh của TCP Reno. Mô phỏng cho một liên kết MEO thay đổi BER được thể hiện trong hình 3.21.
Các tham số cho mô phỏng là: độ trễ lan truyền thuận một chiều là 120 ms, và kênh ngược từ đích TCP đến nguồn thông qua kênh mặt đất bị giới hạn ở 200 Kbps. Tốc độ liên kết vệ tinh được cố định ở 10 Mbps bỏ qua chi phí FEC và không có giao thức liên kết yêu cầu lặp lại tự động (ARQ) nào được sử dụng. Nhiều phiên TCP được sử dụng cùng với một kết nối TCP SACK duy nhất. Các tùy chọn mở rộng cửa sổ / PAWS được kích hoạt và kích thước phân đoạn TCP được cố định ở 9140 byte. Phần lớn bộ đệm được đặt tại các thiết bị truy cập và khoảng 300 Kbyte. Hiệu suất cho thấy sự cải thiện khi tăng nhiều phiên cho giá trị BER là 1x 10-7 điều này xác nhận rằng cần nhiều phiên hơn để có giá trị BER cao hơn.
3.3.3.6 Sửa lỗi chuyển tiếp (FEC)
TCP giải thích tất cả các tổn thất là do tắc nghẽn. Trong trường hợp mất mát do lỗi truyền, TCP không cần phải giảm cửa sổ tắc nghẽn của nó. Để TCP hoạt động hiệu quả, gần như tất cả các tổn thất đường truyền phải được loại bỏ. Một số kỹ thuật sửa lỗi chuyển tiếp (FEC) đã được đề xuất và thực hiện để cải thiện hiệu suất BER trên các liên kết vệ tinh.
Hình 3.21 Sử dụng băng thông với nhiều phiên TCP (truyền tải hàng loạt)
3.3.3.7 Thông báo tắc nghẽn rõ ràng (ECN)
Thông báo tắc nghẽn rõ ràng cho phép các bộ định tuyến thông báo cho người gửi TCP về tắc nghẽn sắp xảy ra mà không làm rơi các phân đoạn. Trong trường hợp tắc nghẽn, các bộ định tuyến đánh dấu các gói IP bằng mã điểm có kinh nghiệm tắc nghẽn (CE) cụ thể và bộ thu TCP gửi lại thông tin tắc nghẽn cho người gửi trong một gói ACK. ECN cải thiện hiệu suất của kết nối TCP và tránh rớt gói không cần thiết và truyền lại
thời gian chờ cho các kết nối TCP ngắn hoặc nhạy cảm với độ trễ. Cơ chế ECN có thể được sử dụng như một phần của cơ chế phân biệt giữa tổn thất do tắc nghẽn và tổn thất do lỗi trong mạng vệ tinh. Việc triển khai ECN yêu cầu triển khai quản lý hàng đợi tích cực như RED trong các bộ định tuyến. Mô tả việc kiểm soát tắc nghẽn bằng cách sử dụng Multilevel ECN cho các mạng vệ tinh.
3.3.3.8 Nén tiêu đề TCP / IP
Một lượng chi phí đáng kể tồn tại trong phân đoạn TCP, tức là với tiêu đề TCP/IPv4 ít nhất 40 byte và tiêu đề TCP/IPv6 ít nhất 60 byte. Một số thông tin này như địa chỉ nguồn và đích, số cổng, không đổi hoặc thay đổi chậm trong quá trình kết nối và không cần lặp lại với mỗi đoạn được truyền. Nén tiêu đề thường giảm tiêu đề TCP/IPv4 từ 40 xuống 3 - 5 byte. Nó liên quan đến quá trình truyền liên tục một tiêu đề đầy đủ, với các tiêu đề nén tiếp theo tham chiếu đến nội dung của tiêu đề đầy đủ trước đó. Người gửi có thể gửi tiêu đề đầy đủ khi một hoặc nhiều trường tiêu đề phải được cập nhật. Vì quá trình nén diễn ra ở lớp liên kết, nên việc định tuyến không bị ảnh hưởng vì tiêu đề được mở rộng trước khi được chuyển đến lớp IP. Ngoài việc cải thiện thông lượng dữ liệu người dùng, việc nén có thể làm giảm mất phân đoạn do lỗi bit vì giảm xác suất lỗi tiêu đề.
3.3.3.9 Tóm tắt các cải tiến TCP
Bảng 3.6 cung cấp tóm tắt về các cải tiến của giao thức TCP cho môi trường kết quả có độ trễ băng thông lớn như liên kết vệ tinh. Các RFC được đề xuất của IETF giải quyết các vấn đề về độ trễ, BDP lớn và suy giảm lỗi liên kết được hiển thị bên dưới. Nhiều thử nghiệm và triển khai được báo cáo trong tài liệu TCP SACK mới và NewReno cho các liên kết vệ tinh.