5. Cấu trúc của luận văn
2.1.2. Thuật toán ước tính băng thông
Một giả định cơ bản của thiết kế TCP, mạng là một "hộp đen". Kết quả là, một TCP nguồn có thể không nhận được bất kỳ thông tin phản hồi tắc nghẽn rõ ràng từ mạng và chỉ dựa vào thông tin phản hồi ngầm như thời gian chờ, các ACK trùng lặp, đo thời gian khứ hồi RTT. Trong công việc này, tôi giới thiệu một thông tin phản hồi ngầm mới được sử dụng để tránh tắc nghẽn.
Fast retransmission Retransmission timout Congestion avoidance
Slow start Fast recovery
timeou t all ACK timeou t timeou t cwnd≥ssthresh start send missing packet non-dup ACK ≥ 3 dup ACK ≥ 3 dup ACK cwnd=cwnd+1 cwnd=cwnd+1/cwnd cwnd=BWE*RTTmi n dup ACK ACK ACK
Tôi tìm hiểu “ nguồn” thực hiện một ước tính đầu cuối của băng thông sẵn có dọc theo kết nối TCP bằng cách đo tốc độ ACK hồi đáp. Đối với ước tính như vậy có ý nghĩa, “nguồn” phải có khả năng để dự đoán số lượng dữ liệu chuyển giao cho trạm nhận theo thời gian. Các giao thức TCP cung cấp cho trạm nhận thông báo bên nhận của trạm phát một phân đoạn bằng ACK, mang một dấu hiệu các phân đoạn đã nhận. Khi một ACK được nhận bởi nguồn, nó cho biết một số lượng dữ liệu tương ứng với một gói tin cụ thể được truyền đã được chuyển tới điểm đến. Nếu quá trình truyền dẫn không bị ảnh hưởng bởi mất mát, thường thì trung bình các dữ liệu được chuyển giao tính theo lần các kết quả ước tính hợp lý của băng thông hiện tại được sử dụng bởi nguồn.
Khi nhận các ACK trùng lặp, chúng được tính vào ước lượng băng thông và một ước tính mới cần phải được tính ngay sau sự tiếp nhận của chúng. Tuy nhiên, nguồn không là nơi đảm bảo chắc chắn phân đoạn gây ra việc truyền tải các gói ACK trùng lặp, vì vậy nó không thể cập nhật dữ liệu được tính bằng kích thước của phân đoạn đó. Do đó trong kết nối đang diễn ra kích thước trung bình của phân đoạn gửi xa nên được sử dụng, cho phép chỉnh sửa khi ACK tích lũy kế tiếp được nhận.
Điều quan trọng cần chú ý là ngay sau khi sự kiện tắc nghẽn, xảy ra bởi time-out hoặc n ACKs trùng lặp, băng thông được sử dụng bởi kết nối đúng bằng với băng thông sẵn có tối đa tới kết nối đó. Điều này được khẳng định bởi thực tế các gói tin bị rớt, là dấu hiệu cho thấy bộ đệm gần bão hòa. Trước khi sự kiện tắc nghẽn, băng thông sử dụng ít hơn hoặc bằng với băng thông sẵn có bởi vì TCP nguồn vẫn còn thăm dò hiệu năng của mạng. Điều quan trọng là sử dụng bộ lọc tần số thấp để có được các thành phần tần số thấp của băng thông sẵn có. Vì vậy nó rất hữu ích để theo dõi chỉ các thành phần tần số thấp của băng thông sẵn có. Trong chương trình này, ước lượng băng thông
được thực hiện bằng cách sử dụng một bộ lọc tấn số thấp, được mô tả bởi đoạn mã sau:
Đoạn mã ước lượng băng thông:
if (ACK is received) sample_BWE[k]=(acked*pkt_size*8)/(now - lastacktime); BWE[k]=(19/21)*BWE[k-1]+(1/21)* (sample_BWE[k]+sample_BWE[k-1]); Endif Trong đó:
acked: số lượng của các phân đoạn được thừa nhận bởi ACK gần nhất. pkt_size: kích thước phân đoạn theo byte.
now: thời gian tại thời điểm hiện tại
lastacktime: thời gian ACK trước đó đã nhận được. k,(k-1): giá trị hiện tại và trước đó của biến.
BWE: số đo bộ lọc tầng số thấp của băng thông sẵn có.
Bộ lọc được thu được bằng cách quyết định lệnh đầu tiên qua bộ lọc tầng số thấp sử dụng quy tắc hình thang và bằng cách giả sử tỷ lệ giữa một hằng thời gian với thời gian gốc bằng 10.
Cuối cùng ước lượng băng thông được chuyển thành kích thước cửa sổ thích hợp như cwin = BWE*RTTmin , RTTmin là thời gian khứ hồi nhỏ nhất được tính toán bởi TCP nguồn(và được sử dụng để thiết lập thời gian timeout).
Trong phần này, tôi thực hiện ước lượng băng thông sẵn có tại TCP nguồn để giảm thiểu và định vị việc sửa đổi của TCP ở phía trạm phát. Rõ ràng băng thông sẵn có dọc theo một kết nối TCP có thể được đánh giá ở phía
trạm nhận bằng cách sử dụng cùng một thủ tục lọc. Sau đó, thông tin phản hồi này có thể được cung cấp trở lại thông qua các nguồn ACKs bằng cách thiết lập trường AdvertisedWindow:
AdvertisedWindow:= min(AdvertisedWindow, RT T*BWE)
Một mặt, sự lựa chọn này có lợi thế lớn của sự ước lượng băng thông thô đối với việc mất ACKs dọc theo đường trở về. Thật vậy, mất ACKs, tức là, dọc theo các kết nối TCP không đối xứng, có thể ảnh hưởng không tốt đến ước lượng băng thông tại nguồn. Mặt khác, nó sẽ yêu cầu việc sửa đổi của TCP nhận, trong khi sự lựa chọn đặt ước lượng băng thông tại trạm phát chỉ ưu tiên khía cạnh trạm phát bởi sự thi hành của giao thức mới.
•Những ảnh hưởng của độ trễ và ACKs lũy tích đối với BWE. Sự kết hợp của ACKs trễ và tích lũy có khả năng gây cản trở quá trình ước lượng băng thông. Ví dụ: Giả sử một kết nối chuyển thành công các phân đoạn tới số 99, và 100 cho tới 109 thì bị mất do tắc nghẽn đột ngột. Nếu cửa sổ phát vào thời điểm đó là đủ lớn để gửi thêm 20 phân đoạn, và tắc nghẽn được khai thông, các phân đoạn có thứ tự từ 110 đến 129 sẽ được chuyển thành công và sẽ gây ra một loạt 20 ACKs trùng lặp. Theo thuật toán ước lượng băng thông, mỗi DUPACK nhận được kích hoạt một bản cập nhật BWE. Trong trường hợp nhận 3 DUPACKs, TCP sẽ thiết lập cơ chế “Fast ReTransmist” và sẽ gửi lại các gói dữ liệu có thứ tự từ 100 trở đi. Giả sử mất mát không xảy ra, nơi nhận sẽ đáp lại những phân đoạn được gửi bằng cách đưa ra 5 ACKs trễ (tương ứng với 10 phân đoạn từ 100 tới 109) và 1 ACK tích lũy(công nhận các phân đoạn từ 110 đến 129, mà nó nhận được và được lưu trữ). Rõ ràng, nếu qui định giả trên được áp dụng đúng, ước lượng băng thông sẽ tăng vọt lên do sự tiếp nhận ACK liên tục ở nguồn, một trong số đó chỉ thừa nhận 20 phân đoạn. Do đó, giá trị của acked trong giả thiết phải được
chọn lựa cẩn thận. Ví dụ này nhấn mạnh hai khía cạnh quan trọng của quá trình ước lượng băng thông:
+ Nguồn phải theo dõi số lượng DUPACKs nó đã nhận được trước khi dữ liệu mới được thừa nhận;
+ Nguồn có thể phát hiện ACKs bị trễ và điều chỉnh phù hợp.
Hai vấn đề này được trình bày bởi thủ tục AckedCount, chi tiết dưới đây, hiển thị một tập các thao tác được thực hiện khi nhận được một ACK, xác định chính xác acked. Biến chính là accounted_for dùng để theo dõi các DUPACK được nhận. Khi một ACK nhận được, số lượng của các phân đoạn nó nhận lần đầu tiên xác định (cumul_ack). Nếu cumul_ack là bằng 0, thì ACK nhận là một DUPACK và tính như là 1 phân đoạn đối với BWE; đếm DUPACK cũng được cập nhật. Nếu cumul_ack lớn hơn 1, ACK nhận được hoặc là một ACK trễ hoặc một ACK tích lũy sau một sự kiện truyền lại, trong trường hợp đó, số lượng các đoạn ACKed được kiểm tra đối với các phân đoạn được đếm (accounted_for). Nếu ACK nhận được công nhận ít hơn hoặc cùng một số phân đoạn dự kiến, điều đó có nghĩa "mất tích" phân đoạn được phát hiện khi DUPACKs được nhận, và chúng không được tính lần hai. Nếu ACK được nhận thừa nhận các phân đoạn nhiều hơn so với dự kiến, có nghĩa mặc dù một phần trong số chúng đã phát hiện theo cách của DUPACKs, phần còn lại được thừa nhận tích lũy bởi ACK hiện tại, do đó, ACK hiện tại chỉ nên được tính như sự tích lũy các phân đoạn được thừa nhận. Cần lưu ý rằng điều kiện cuối cùng ước lượng một cách chính xác độ trễ ACKs là (cumul_ack = 2 và accounted_for = 0).
Thuật toán tính số ACK
PROCEDURE AckedCount
cumul_ack = current_ack_seqno - last_ack_seqno; if (cumul_ack = 0) accounted_for=accounted_for+1;
cumul_ack=1; endif if (cumul_ack > 1)
if (accounted_for >= cumul_ack)
accounted_for=accounted_for-cumul_ack; cumul_ack=1;
else if (accounted_for < cumul_ack)
cumul_ack=cumul_ack-accounted_for; accounted_for=0; endif endif endif last_ack_seqno=current_ack_seqno; acked=cumul_ack; return(acked); END PROCEDURE