Tính thời gian khứ hồi một cách thông minh là cách khắc phục nguyên nhân thứ
hai dẫn tới việc vi phạm nguyên lý “Bảo toàn các gói số liệu”, đó là việc đưa vào mạng một gói tin mới trước khi có một gói tin cũ ra khỏi mạng. Nhưđã được trình bày tại tiểu mục 1.3.2.2, có hai sai lầm dẫn đến nguyên nhân thứ hai này, cách giải quyết chúng được trình bày dưới đây.
Cách giải quyết sai lầm thứ nhất: tính ước lượng thời gian khứ hồi bằng một bộ lọc dải thông thấp để tránh cho đại lượng này khỏi thăng giáng quá mạnh nhằm duy trì sự cân bằng. Đặc tả cho giao thức TCP, RFC-793 [49] gợi ý tính ước lượng thời gian khứ hồi như sau:
RTT ←α.RTT+(1-α).M (1-2) Trong đó RTT là ước lượng thời gian khứ hồi trung bình, M là số đo thời gian khứ hồi nhận được từ gói số liệu đã được biên nhận gần nhất và α là hệ số làm trơn của bộ lọc, giá trị mà người ta gợi ý nên sử dụng là α=0.9.
Tác dụng làm trơn các thăng giáng của thời gian khứ hồi theo thuật toán trên, với một vài giá trị của α, có thể minh họa bằng thí dụ sau. Giả sử với mỗi gói tin được biên nhận (received_ack), được đánh số từ 1..20, chúng ta đo được thời gian khứ
hồi M, từ đó tính được thời gian khứ hồi được làm trơn RTT, như được trình bày trên Bảng 1.2 và được biểu diễn bằng đồ thị trên hình 1.10.
Bảng 1.2 Tính RTT từ M cho mỗi gói tin được biên nhận received_ack 1 2 3 4 5 6 7 8 9 10 M (new_rtt) 1 1.2 0.8 0.6 1.2 1.4 2 1.8 1.2 1 RTT (α = 0.9) 1 1.02 1 0.96 0.98 1.02 1.12 1.19 1.19 1.17 RTT (α = 0.4) 1 1.04 0.99 0.91 0.97 1.6 1.25 1.36 1.33 1.26 RTT (α = 0.2) 1 1.16 0.87 0.65 1.09 1.34 1.87 1.81 1.32 1.06 Received_ack 11 12 13 14 15 16 17 18 19 20 M (new_rtt) 0.8 0.9 0.9 0.9 1 1 1 1 1 1 RTT (α = 0.9) 1.13 1.11 1.09 1.07 1.06 1.06 1.05 1.05 1.04 1.04 RTT (α = 0.4) 1.17 1.11 1.07 1.04 1.03 1.02 1.02 1.02 1.01 1.01 RTT (α = 0.2) 0.85 0.89 0.9 0.9 0.98 1 1 1 1 1 Hình 1.10 Thời gian trễ khứ hồi được làm trơn RTT
Sau khi ước lượng về RTT đã được cập nhật, thì thời gian hết giờđể phát lại gói số liệu tiếp theo, RTO (retransmit timeout) được tính như sau:
RTO = β.RTT (1-3)
Cần phải chọn β sao cho việc phát lại do hết giờ không bị sai lầm do thăng giáng của thời gian khứ hồi; nghĩa là làm cho xác suất thời gian khứ hồi của một gói tin
lớn hơn RTO là rất nhỏ. Chính vì vậy, β cần được chọn không quá nhỏ, có thể sẽ
dẫn đến việc phát lại vội vàng, khi gói tin vẫn đang ở trong mạng; β cũng không
được chọn quá lớn, có thể sẽ dẫn đến việc phát lại quá chậm trễ, gói tin bị mất từ
lâu, mà bên gửi vẫn chờ cho hết giờ rồi mới phát lại.
Trong các phiên bản TCP được cài đặt đầu tiên, người ta thường chọn β là một số
cốđịnh bằng 2. Tuy nhiên, các nghiên cứu thực nghiệm sau này cho thấy rằng, RTT thăng giáng trong một miền tương đối rộng, vì vậy không nên chọn β theo cách đơn giản như trên. Công trình đầu tiên đề xuất việc cải tiến thuật toán tính RTO của Jacobson được công bố năm 1988 [26]. Ông đã đề xuất cách làm cho β xấp xỉ tỉ lệ
với độ lệch chuẩn của hàm mật độ xác suất thời gian đến của biên nhận. Cụ thể là, sử dụng độ lệch trung bình như một ước lượng rẻ (cheap estimator) của độ lệch chuẩn. Thuật toán này đòi hỏi phải tính một biến nữa là độ lệch được làm trơn D, như sau:
D = α.D + (1-α).|RTT-M| (1-4) Trong đó, các tham số RTT và M hoàn toàn tương tự như trong biểu thức (1-2), còn α ởđây không nhất thiết phải có cùng giá trị như tham sốα trong biểu thức đó. Jacobson đã chỉ ra rằng, mặc dù D không hoàn toàn giống độ lệch chuẩn, nhưng nó cũng là một xấp xỉđủ tốt. Cách tính D như trên nhằm đạt được tốc độ cao nhất, chỉ
sử dụng các phép tính cộng, trừ và dịch trên các số nguyên. Ngày nay, các phiên bản TCP đều sử dụng thuật toán này và tính thời gian hết giờđể phát lại như sau:
RTO = RTT + 4.D (1-5)
Sử dụng hệ số 4 có hai ưu điểm, thứ nhất là việc nhân với 4 sẽ được thực hiện bởi phép dịch, có tốc độ thực hiện cao; thứ hai là, xác suất một gói tin được biên nhận chậm hơn RTO là rất nhỏ, có thể bỏ qua [8], [26].
Cách giải quyết sai lầm thứ hai: rút lui theo hàm mũ. Đây là cách giải quyết duy nhất đúng đắn, bởi vì theo cơ chế khởi động chậm, cửa sổ gửi tăng lên theo hàm mũ, cho nên cũng cần phải rút lui theo cách này cho đủ nhanh khi đã có dấu hiệu của tắc nghẽn. TCP sẽ đặt đồng hồ phát lại bằng khoảng thời gian rút lui và
khoảng đó sẽ được tăng gấp đôi cứ mỗi lần bị hết giờ liên tiếp. Cơ chế rút lui này
được giải thích tỉ mỉ trong [26], [41].