(Bài dịch)
Giới thiệu
Mạng máy
tính đã trải qua thời kỳ phát triển bùng nổ trong vài năm gần đây kèm theo đó
nhiều vấn đề về tắc nghẽn. Một ví dụ, ta thường thấy cổng mạng hủy 10% gói tin
đến vì tràn bộ đệm. Bản điều tra của chúng tôi về các vấn đề này sẽ đưa ra nhiều
nguyên nhân nằm trên cách triển khai tầng giao vận (Transport protocol) (chứ
không phải chính các giao thức đó). Cách rõ ràng để thực thi một giao thức truyền
tải dựa trên cửa sổ (window-based transport protocol) có thể chính xác gây ra
phản ứng sai làm tắc nghẽn mạng. Chúng tôi xin đưa ra các ví dụ về phản ứng sai
và mô tả một số thuật toán đơn giản để khắc phục tình trạng này. Các thuật toán
được bắt nguồn từ ý tưởng đạt được độ tinh cậy của mạng bằng cách buộc cái kết
nối ở tầng giao vận tuân theo nguyên tắc 'bảo toàn gói' (packet conservation).
Chúng tôi sẽ đưa ra thuật toán xuất phát từ nguyên tắc này và hiệu quả mang lại
cho đường truyền trong mạng đang sảy ra tắc nghẽn.
Vào
tháng 10 năm 1986, mạng Internet lần đầu tiên trở thành một phần của sự sụp đổ
vì tắc nghẽn. Trong thời gian này, Thông lượng từ LBL đến UC Berkeley (các vùng
cách nhau 400 thước và 2 hốp IMP) bị rớt từ 32Kbps về 40 bps. Chúng tôi bị mê
hoặc bởi hàng ngàn các yếu tố gây nên rớt băng thông và bị thu hút vào một cuộc
điều tra về sự việc này. Trong thực tế, chúng tôi băn khoăn nếu 4.3BSD
(Berkeley UNIX ) TCP thiếu các phản ứng hoặc nó có thể được điều chỉnh để làm
việc tốt hơn trong điều kiện mạng tệ hại. Và câu trả lời đều là
"YEAH!"
GETTING
TO EQUILIBRIUM: SLOW-START 2
Trong thời
gian này, chúng tôi đã triển khai 7 thuật toán vào gói giao thức 4BSD TCP:
(i)
round-trip-time
variance estimation
(ii)
exponential
retransmit timer backoff
(iii)
slow-start
(iv)
more
aggressive receiver ack policy
(v)
dynamic
window sizing on congestion
(vi)
Karn’s
clamped retransmit backoff
(vii)
fast
retransmit
Cách
tính toán và các bản báo cáo của bước test bản beta cho thấy sản phẩn cuối cùng
khá là tốt trong việc xử lý với các điều kiện tắc nghẽn của mạng. Bài bào này
là một bản mô tả tóm tắt từ 1-5 và nguồn gốc sau chúng. Thuật toán thứ 6 được
phát triển bởi Phil Karn tại Bell Communications Research được mô tả trong mục
[16]. Thuật toán thứ 7 sẽ được mô tả sớm trong xuất bản tại RFC.
Thuật
toán 1-5 xuất phát từ việc theo dõi: Luồng trên một kết nối (ISO TP-4 hoặc XeroxNS
SPP) cần phải tuân theo nguyên tắc 'bảo toàn gói' (packet conservation). Và nếu
nguyên tắc được tuân theo, sự sụp đổ do tắc nghẽn sẽ trở thành ngoại lệ hơn là
các luật. Thêm nữa, việc điều khiển tắc nghẽn còn bao gồm cả việc tìm kiếm nơi
vi phạm việc bảo toàn và sửa chúng. Thuật ngữ 'bảo toàn gói' tương đương với một
kết nối cân bằng. Ví dụ như chạy ổn định với trường window cao nhất của gói tin
trong việc vận chuyển, lưu lượng của gói thuật ngữ vật lý gọi nó là bảo toàn
khi: Một gói mới không được truyền trước khi gói cũ được gửi. Nguyên lý của dòng
dữ liệu yêu cầu hệ thống với những thuộc tính trên phải mạnh khi đối mặt với
tình trạng tắc nghẽn.
Có 3 khả
năng phá vỡ bảo toàn gói:
1.
Kết
nối không đạt đến trạng thái cân bằng
2.
Thiết
bị gửi thêm một gói trước khi gói cũ được truyền xong
3.
Không
thể đạt được trạng thái cân bằng vì giới hạn tài nguyên trên đường truyền.
Trong phần
sau đây, chúng tôi sẽ tìm cách xử lý tối ưu tránh những khả năng trên.
Trong phần
sau đây, chúng tôi sẽ tìm cách xử lý tối ưu tránh những khả năng trên.
Getting
to Equilibrium: Slow-start
Lỗi [1] xuất
phát từ một kết nối đang bắt đầu hoặc thử
kết nối lại sau khi mất một gói tin. Nói cách khác tính bảo toàn là việc thiết
bị gửi sử dụng biên nhận ACKs như một chiếc đồng hồ thăm dò để gửi gói tin mới.
Kể từ khi thết bị nhận có thể sinh các ACK không nhanh hơn gói tin đi qua mạng,
giao thức gọi là ‘tự đếm thời gian' (Hình 1). Hệ thống đồng hồ tự đếm tự động
điều chỉnh theo mức tăng giảm băng thông và độ trễ và có một khoảng động rộng
(giả sử TCP mở rộng dải từ 800 Mbs kênh Cray đến 1200 bps gói liên kết). Nhưng
điều tương tự làm hệ thống tự đếm thời gian ổn định khi nó chạy từ từ - để nhận
dữ liệu phải có biên nhận để đếm thời gian các gói nhưng để nhận được biên nhận
ACK thì phải có dòng dữ liệu.
Sender: Thiết bị gửi
Receiver: Thiết bị nhận
Pb: biểu thị khoảng cách nhỏ nhất của gói trong phần liên kết chậm nhất của đường mạng (nút thắt cổ chai).
Pr: khoảng cách giữa các gói của mạng bên nhận
As: khoảng cách ACK của mạng thiết bị gửi As = Pb
Ab:
Ar: khoảng cách giữa gói ACK tại thiết bị nhận là Ar=Pr=Pb
Receiver: Thiết bị nhận
Pb: biểu thị khoảng cách nhỏ nhất của gói trong phần liên kết chậm nhất của đường mạng (nút thắt cổ chai).
Pr: khoảng cách giữa các gói của mạng bên nhận
As: khoảng cách ACK của mạng thiết bị gửi As = Pb
Ab:
Ar: khoảng cách giữa gói ACK tại thiết bị nhận là Ar=Pr=Pb
Đây là cơ chế mô tả của thiết bị
gửi/nhận trong một mạng băng thông rộng kết nối với một mạng chậm hơn, mạng đường
dài. Thiết bị gửi chỉ bắt đầu và đã truyền đi một gói chứa trường window, liên
tiếp nhau. Gói ACK biên nhận cho đợt gửi đầu tiên được gửi
trở lại thiết bị gửi (Ký hiệu bằng đường thẳng đứng ở ống to bên
trái phía dưới). Chiều dọc là băng thông, chiều ngang là thời gian. Mỗi
một khối đen là một gói. Bandwidth_Time = Bits nên kích thước khối đen
tương đương với độ lớn của gói. Số bits không thay đổi đóng vai trò
như gói tin đi qua mạng
do đó gói tin bị nén thành các đường chiếm băng thông trải dài theo trục thời
gian. Thời gian Pb biểu thị khoảng cách nhỏ nhất của gói trong phần liên kết chậm
nhất của đường mạng (nút thắt cổ chai). Khi gói tin đi ra khỏi nút thắt, khoảng
cách các gói tin không thay đổi bởi vậy khoảng cách giữa các gói của mạng bên
nhận Pr = Pb. Nếu thời gian xử lý của thiết bị nhận bằng nhau đối với tất cả
các gói tin, thì khoảng cách giữa gói ACK tại thiết bị nhận là Ar=Pr=Pb. Nếu
các khe thời gian Pb lớn vừa đủ cho một gói, nó sẽ đủ lớn cho gói ACK bởi vậy
khoảng cách giữa các gói ACK được bảo toàn xuốt đường trở về. Vì thế nên khoảng
cách ACK của mạng thiết bị gửi As = Pb. Vậy, Nếu gói tin sau đợt gửi đầu tiên
chỉ được gửi khi nhận gói tin ACK, khoảng cách gói tin của thiết bị gửi sẽ bằng
chính xác thời gian gói tin tại liên kết chậm nhất của đường mạng.
Để bắt đầu đếm, chúng tôi đã phát triển thuật toán
slow-start để dần dần tăng lượng dữ liệu truyền đi[2]. Mặc
dù chúng tôi hy vọng bằng việc thiết kế như vậy giải thuật sẽ tinh vi hơn,
nhưng việc triển khai thì thật đơn giản - Một biến trạng thái mới và 3 dòng
code trong thiết bị gửi.
[1]
Một luồng cân bằng có nghĩa là bất kỳ thời điểm nào, Tích phân của mật độ gói tin xung quanh
vòng gửi/nhận/gửi là một hằng số. Từ khi
các gói tin truyền quanh vòng lặp này, Tích phân tiếp tục đủ để thành lập hàm
Lyapunov của hệ thống. Một hàm hằng số không đáng kể phù hợp với điều kiện ổn định
của Lyapunov vì vậy hệ thống đạt trạng thái ổn định và bất kỳ sự chồng chất hệ
thống nào đều ổn định. (Xem [3], Chương 11-12 hoặc [21], Chương 9 về định lý hệ
thống ổn định)
[2]
Slow-start hơi giống với giải thuật CUTE trong [14]. Thời điểm nghĩ ra thuật
toán này chúng tôi không hay biết gì về CUTE nhưng sau đó thì có biết - CUTE được
đưa ra trước vài tháng. Khi mô tả thuật toán của chúng tôi vào tháng 1 - 1987,
tại cuộc họp tại IETF, chúng tôi gọi nó là soft-start. Cái tên slow-start được
đề nghị bởi John Nagle trong một thông điệp gửi đến IETF vào tháng 3 - 1987.
Cái tên tỏ ra khá rõ ràng và chúng tôi đặt theo nó.