5. Cấu trúc của luận văn
2.1.3. Thuật toán tính ngưỡng ssthresh
Ý tưởng chung là sử dụng ước lượng băng thông BWE để thiết lập cửa sổ tắc nghẽn (cwin) và ngưỡng bắt đầu chậm(ssthresh) sau sự kiện tắc nghẽn. Vai trò cơ bản của cwin và ssthresh trong kiểm soát tắc nghẽn TCP là cwin được tăng lên và giảm xuống để tìm độ trễ băng thông được miêu tả bằng ssthresh.
Một thuận lợi nữa của việc sử dụng BWE như một thông tin phản hồi ẩn để thiết lập cwin và ssthresh xuất phát từ thực tế rằng các bộ định tuyến mạng có thể dễ dàng thực thi xếp hàng công bằng trên hàng đợi FIFO bằng cách thực hiện các cơ chế hàng đợi cơ bản như RED, WRED hoặc FRED. Trong khi TCP Westwood không dựa vào thông tin từ các nút trung gian, tuy nhiên có thể khai thác những chiến lược xếp hàng đợi. Dựa vào kết quả này có thể phân luồng băng thông chính xác hơn.
2.1.3.1. Thuật toán sau khi nhận n ACK trùng lặp
Sau khi nhận n ACK trùng lặp số hiệu, ngưỡng ssthresh và kích thước cửa số cwin được cập nhật như sau:
if (n DUPACKs are received)
if (cwin>ssthresh) /* congestion avoid. */ ssthresh = f1(BWE*RTTmin);
cwin = ssthresh; endif
if (cwin<ssthresh) /*slow start */ ssthresh= f2(BWE*RTTmin) if (cwin > ssthresh) cwin = ssthresh endif endif endif
Ngưỡng khởi đầu chậm được thiết lập bằng với kích thước “đường ống” sẵn có, tức là BWE*RTTmin, cửa sổ tắc nghẽn được thiết lập bằng
ssthresh và giai đoạn tránh tắc nghẽn được thiết lập trở lại để thăm dò băng
thông có sẵn mới. Hàm f1 đưa vào một biến độc lập có thể được sử dụng để điều chỉnh thuật toán. Trong nội dung này, tôi chọn một chức năng đồng nhất cho f1, tức là f1 (.) = (.). Trong giai đoạn khởi đầu chậm, tôi tiếp tục thăm dò băng thông sẵn có. Vì vậy BWE có được sau khi nhận n ACK trùng lặp được sử dụng để thiết lập ngưỡng khởi đầu chậm. Sau khi ssthresh được thiết lập, cửa sổ tắc nghẽn được thiết lập bằng ngưỡng khởi đầu chậm chỉ khi cwin>
ssthresh. Nói cách khác, trong quá trình khởi đầu chậm, cwin vẫn là một tính
năng gia tăng nhanh như trong qua trình thực hiện của TCP Reno hiện tại. Hàm f2 đưa vào một biến độc lập để sử dụng để điều chỉnh thuật toán.
2.1.3.2. Thuật toán sau khoảng thời gian timeout
if (coarse timeout expires)
if (cwin>ssthresh) /* congestion avoid. */ ssthresh = f3(BWE*RTTmin);
if (ssthresh < 2) ssthresh = 2; cwin = 1; else
cwin = f4(BWE*RTTmin); endif
endif
if (cwin<ssthresh) /* slow start */ ssthresh = f5(BWE*RTTmin)
if (ssthresh < 2) ssthresh = 2;cwin = 1; else
cwin = f6(BWE*RTTmin) endif
endif endif
Sau một thời gian chờ, cwin và ssthresh được thiết lập theo một trong các hàm fi, i = 3 tới 6 tùy thuộc vào mỗi giai đoạn thuật toán khi thời gian time out. Chú ý rằng việc sử dụng các hàm chung fi, i = 1,6 cung cấp 6 biến độc lập để điều chỉnh thuật toán.
Giá trị ngưỡng ssthreh cập nhật theo công thức: ssthresh = fi(x)(BWE*RTTmin)
- Với BWE: băng thông được ước tính ở thuật toán trước
- RTTmin = baseRTT: thời gian nhỏ nhất gói tin đi trọn 1 vòng
- Việc xác định giá trị hàm fi(x) trong từng trường hợp sẽ được tính theo thuật toán phù hợp.
if (3 DUPACKs are received)
if (cwin<ssthresh) /* slow start */ a = a + 0.25;
if (a > 4) a = 4; endif endif
if (cwin>ssthresh) /* congestion avoid. */ a = 1;
endif
ssthresh = (BWE*RTTmin)/(pkt_size*8*a);/* reset cwin to ssthresh, if larger */
if (cwin>ssthresh) cwin = ssthresh; endif
endif
Kiểm tra mã, nó có thể được nhìn thấy rằng trong thời gian tránh tắc nghẽn, f1 chỉ đơn giản được lựa chọn như là một hàm đồng nhất, tức là f1(x) = x. Ngược lại, trong quá trình khởi đầu chậm, f2 (x) = x/a. Chú ý rằng a (hệ số giảm ngưỡng) tăng 1-4 (mỗi lần tăng là 0,25 đối mỗi lần 3 DUPACKs được nhận trong khởi đầu chậm), trong khi a được thiết lập bằng 1 khi DUPACK 3 được nhận được trong tránh tắc nghẽn. Tại thiết lập kết nối, a được khởi tạo là 1.
Thật vậy, bộ ba DUPACK được nhận trong quá trình khởi đầu chậm (dấu hiệu cho thấy ssthresh được đặt quá cao), yếu tố giảm trở nên lớn hơn. a
được khôi phục lại 1 nếu tắc nghẽn được phát hiện trong tránh tắc nghẽn; Rõ ràng, ssthresh được thiết lập một cách chính xác và không cần giảm tác động của BWE.
+ Trường hợp sau khoảng thời gian chớ timeout
Sau khi hết hạn thời gian time out, một tập các hoạt động tương tự như trường hợp bộ ba DUPACK được kích hoạt:
if (coarse timeout expires)
if (cwin<ssthresh) /* slow start */ a = a + 1;
if (a > 4) a = 4; endif
endif
if (cwin>ssthresh) /* congestion avoid. */ a = 1; endif ssthresh = (BWE*RTTmin)/(pkt_size*8*a); if (ssthresh > 2) ssthresh = 2; cwin = 1; endif endif
Trong trường hợp này, hàm f3, được sử dụng để thiết lập ssthresh khi
thời gian chờ xảy ra trong quá trình tránh tắc nghẽn, f3(x) = x. Hàm f4(x) = 1. Hàm f5 được sử dụng để thiết lập ssthresh khi thời gian chờ xảy ra trong giai đoạn khởi đầu chậm, f5(x) = x/a, a tăng từ 1-4, mỗi bước là 1 (trái ngược với 0. 25 trong trường hợp bộ 3 DUPACK) mỗi lần một thời gian time out xảy ra, và được thiết lập để 1 khi thời gian time out xảy ra trong tránh tắc nghẽn. Ngoài ra f6 được thiết lập bằng 1.
Chú ý cửa sổ tắc nghẽn thiết lập lại là 1 sau một thời gian time out, như đã thực hiện bởi TCP Reno. Lựa chọn này là bảo thủ bởi vì nó không tận dụng đầy đủ các thông tin BWE để tránh sự thu hẹp của cửa sổ tắc nghẽn tới 1 trong sự hiện diện của mất mát không thường xuyên do sự can thiệp liên kết
không dây chứ không phải là tắc nghẽn. Có một lý do cho sự lựa chọn này: sự công bằng. Tôi nghĩ rằng với hàng đợi drop-tail FIFO điều quan trọng là duy trì hoạt động theo chu kỳ của TCP, cho phép lưu lượng biến động trên mỗi kết nối TCP. Thật vậy, hoạt động này đảm bảo việc chia sẻ công bằng các nguồn tài nguyên băng thông giữa các kết nối nút cổ chai khác nhau cùng một hàng đợi FIFO mà không ảnh hưởng đến sự ổn định của thuật toán. Những thiết lập khác nhau có thể được đề xuất cho cwin và ssthresh sau một thời gian chờ khi các nút mạng thực hiện RED hoặc WRED, nhưng vấn đề này được để lại để nghiên cứu thêm. Ngoài ra, cơ chế mới có thể được đưa ra để chuyển đổi giữa tránh tắc nghẽn và bắt đầu chậm, tức là, một chiến lược để tăng ssthresh, bằng cách sử dụng một bộ lọc được thiết kế để ước lượng băng thông trong việc tận dụng thấp của mạng.
Việc xác minh tính đúng đắn của TCP Westwood sẽ được trình bày mô phỏng ở chương 3.
2.2. Giao thức RoVegas
Mặc dù Vegas là vượt trội so với Reno trong các khía cạnh, nhưng nó bị một số vấn đề mà ở đây là vấn đề tránh tắc nghẽn, bao gồm các vấn đề về định tuyến lại, công bằng, mạng không đối xứng và không tương thích giữa Reno và Vegas. Tất cả những vấn đề này có thể là việc trở ngại cho Vegas để đạt được hiệu năng cao. Trong nghiên cứu này, tôi tìm hiểu một cơ chế dựa trên cơ chế tránh tắc nghẽn của TCP Vegas là RoVegas [5]. Thông qua cơ chế này, RoVegas có thể giải quyết vấn đề định tuyến lại (Rerouting) và tránh tắc nghẽn, nâng cao tính công bằng trong cạnh tranh kết nối, và cải thiện thông lượng khi tắc nghẽn xảy ra trên chiều báo nhận.
2.2.1. Cơ chế hoạt động
RoVegas cải tiến của TCP Vegas nên nó cũng điều khiển kích thước cửa sổ bằng cách theo dõi thời gian RTT.
Việc đo RTT chia thành 4 phần:
+ Độ trễ chuyển tiếp ( tức là độ trễ đường truyền và thời gian xử lý gói tin) + Thời gian chuyển tiếp ở hàng đợi
+ Độ trễ báo nhận ACK
+ Thời gian báo nhận ở hàng đợi
Trong phần này, tôi trình bày một phân tích trạng thái ổn định của cả hai giao thức Vegas và RoVegas khi tắc nghẽn xảy ra trong đường báo nhận ACK. Bằng cách kiểm tra chiều dài hàng đợi của bộ đệm nút cổ chai thông qua các phương pháp phân tích, tôi tìm hiểu và làm sáng tỏ bản chất tự nhiên của hai cơ chế này. Các mô hình mạng được sử dụng trong phân tích được mô tả hình 2.2 [5].
Hình 2.2: Mô hình phân tích RoVegas
S1: nguồn, D1: đích, R1 và R2 là hai nút cổ chai Các liên kết chuyển tiếp giữa hai bộ định tuyến: + Công suất uf (số gói dữ liệu được xử lý/giây tại R1) + Công suất ub (số gói ACK được xử lý/ giây tại R2)
+ lf , lb là độ dài các gói tin của nút chuyển tiếp di và nút phía báo nhận ACK của nút cổ chai bộ đệm tương ứng.
2.2.2. Phân tích trên Vegas
Nhắc lại, các tham số α, β và BaseRTT luôn có một mối liên hệ giữa thông lượng mong đợi và thông lượng thực tế, đó là:
(Expected-Actual)BaseRTT (1)
α ≤ ≤β
Expected là thông lượng mong đợi Actual là thông lượng thực tế
BaseRTT là thời gian RTT nhỏ nhất được theo dõi
Cơ chế tránh tắc nghẽn của Vegas thể hiện trong công thức (1) có thể được viết lại như sau:
(2) RTT CWND RTT RTT BaseRTT− α ≤ ≤ RTT BaseRTT− β Ta đặt (3) BaseRTT =τ (4) f b f b l l RTT u u τ = + +
Thay (3), (4) vào (2) ta được
(5) f b f b b f f b f b b f f b b f f b b f u u l u l u u u l u l u CWND l u l u l u l u τ + + α ≤ ≤τ + + β + + Đặt f b u k u
= , mạng được định nghĩa là đối xứng nếu k<=1, bất đối xứng nếu k>1.
2.2.2.1. Mạng đối xứng ( k ≤ 1 )
Nếu nút cổ chai là ở đường chuyển tiếp, các gói tin sẽ được tích lũy trong hàng đợi nút cổ chai chuyển tiếp và không có gói tin sẽ được xếp hàng trong hướng báo nhận ACK, rằng = 0, do đó công thức (8) có thể được đơn giản hóa như:
(6) f f f f f f u l u l CWND l l τ + α≤ ≤τ + β
Dựa trên tính xấp xỉ, kích thước cửa sổ CWND của S1 có thể được có được thông qua độ trễ băng thông của nút cổ chai như sau:
(7) f f f l CWND u u τ = + ÷÷ Thay (7) vào (6) ta có: (8) f l α ≤ ≤β
Thông lượng T của S1 có thể viết lại từ (4) và (7): (9) f CWND T u RTT = =
Từ công thức (8) và (9), tôi quan sát thấy rằng khi nút cổ chai xuất hiện trong hướng chuyển tiếp, số lượng các gói tin xếp hàng đợi trong bộ đệm nút cổ chai về trong hướng chuyển tiếp nằm giữa α và β, và băng thông liên kết luôn luôn đầy. Quan sát này phù hợp với mục tiêu thiết kế của Vegas.
2.2.2.2. Mạng bất đối xứng ( k > 1 )
Nếu nút cổ chai tồn tại trong hướng báo nhận ACK và không có gói tin được xếp trong hàng đợi ở hướng chuyển tiếp, nghĩa là , do đó công thức (5) có thể được viết lại như sau:
(10) b b b b b b u l CWND u l l l τ + α ≤ ≤τ + β
Tương tự như với công thức (7), kích thước cửa sổ CWND của S1 có thể thu được bởi độ trễ băng thông của nút cổ chai liên kết:
(11) b b b l CWND u u τ = + ÷ Thay (11) vào (10) ta có (12) b l α ≤ ≤ β
Trong khi đó, thông lượng T của S1 có thể viết lại từ (4) và (11):
= f (13) b u CWND T u RTT k = =
Từ biểu thức (12), chúng ta có thể thấy rằng TCP Vegas không thể phân biệt được tình trạng tắc nghẽn xảy ra trong hướng chuyển tiếp hoặc hướng báo nhận ACK. Nó giữ một lượng dữ liệu thêm ổn định giữa α và β trên hướng báo nhận ACK. Điều này có thể dẫn đến việc dữ liệu bị hạn chế ở hướng chuyển tiếp. Như thể hiện trong công thức (13), thông lượng của S1 bị giới hạn bởi công suất của hướng báo nhận ACK. Đáng chú ý, một ACK trong hướng báo nhận nói lên rằng một gói tin dữ liệu đã đến tại điểm đến của nó. Vì vậy, thông lượng của S1 là uf
k (số gói dữ liệu trên giây).
Hình 2.3: Kích thước cửa sổ và độ dài hàng đợi nút cổ chai của Vegas với k=2
2.2.3. Phân tích trên RoVegas
2.2.3.1. Mạng đối xứng (k<=1)
Cơ chế tránh tắc nghẽn của RoVegas thể được thể hiện ngắn gọn như sau:
(14)
b
b
CWND CWND
l
BaseRTT BaseRTT RTT BaseRTT u
α ≤ − ≤ β
Từ công thức (14) ta có CWND của RoVegas như sau: (15) b b b b RTT RTT l l RTT BaseRTT RTT BaseRTT u u CWND α β − − ≤ ≤ − −
Từ công thức (3) và (4) thì công thức (15) có thể viết lại như sau:
(16) f f f f f f u l u l CWND l l τ + α ≤ ≤τ + β
Từ kết quả của công thức (16) là giống như của công thức (6). Nếu nút cổ chai ở phía chuyển tiếp ( ) thì hoạt động của RoVegas giống với Vegas. Tuy nhiên, kết quả của công thức (16) cho thấy thông lượng của RoVegas trong trường hợp tắc nghẽn hướng báo nhận không chỉ đơn giản là bị giới hạn bởi băng thông trên hướng báo nhận như của Vegas.
Như thể hiện trong hình 2.4 [5], khi một kết nối RoVegas chạy trên mạng không đối xứng (k=2), kích thước cửa sổ ổn định (33 gói) là lớn hơn so với một kết nối Vegas chạy trên cùng một mạng như mô tả trong hình 2.3 [5]. RoVegas giữ một chiều dài hàng đợi ổn định (hai gói dữ liệu) trong các nút cổ chai về phía chuyển tiếp và hàng đợi nút cổ chai phía báo nhận của nó luôn luôn đầy đủ.
Gọi F là tỷ lệ thông lượng của RoVegas so với Vegas.Trong mạng không đối xứng, tôi tìm được mối liên hệ:
1≤ ≤F 3, k>1 (17)∀
Kết quả này sẽ được chứng minh rõ ràng hơn trong mô phỏng [5].
2.3. Giao thức QuickVegas
Một vấn đề quan trọng trong việc thiết kế một thuật toán điều khiển tắc nghẽn TCP là nó sẽ cho phép các giao thức nhanh chóng điều chỉnh tốc độ thông tin liên lạc từ đầu đầu cuối đến đầu cuối với băng thông vào liên kết nút cổ chai. Tuy nhiên, điều khiển tắc nghẽn TCP có thể hoạt động kém trong mạng có độ trễ băng thông cao vì phản ứng chậm với cửa sổ tắc nghẽn lớn. Trong phần này, tôi tìm hiểu một phiên bản nâng cao của TCP Vegas gọi là Quick Vegas [6]. Thuật toán điều khiển cửa sổ tắc nghẽn của Quick Vegas cải thiện các kỹ thuật ở giai đoạn khởi động chậm (slow start) và tránh tắc nghẽn (congestion avoidance) của TCP Vegas.
2.3.1. Cơ chế hoạt động
Nhắc lại công thức tính số lượng dữ liệu thêm (Δ) được ước tính như sau:
Δ = (Expected - Actual) × BaseRTT, (1)
Expected = CWnd / BaseRTT (băng thông dự kiến) Actual = CWnd / RTT (băng thông thực tế)
- Các CWnd được giữ ổn định khi Δ là giữa hai ngưỡng α và β.
- Nếu Δ > β, nó được coi là một dấu hiệu cho tắc nghẽn, do đó CWnd sẽ được giảm.
- N nếu Δ < α, kết nối có thể sử dụng băng thông có sẵn. Do đó, CWnd sẽ được tăng lên.
Việc cập nhật của CWnd là cơ sở cho mỗi RTT. Nguyên tắc điều chỉnh cửa sổ tắc nghẽn có thể được thể hiện như sau:
TCP gửi các gói dữ liệu nhiều lên trong giai đoạn khởi động chậm của nó do sự gia tăng nhanh cửa sổ và việc truyền tải dựa trên ACK. Hiện tượng này gây ra TCP Vegas thay đổi từ giai đoạn khởi động chậm đến giai đoạn tránh tắc nghẽn quá sớm trong các liên kết có độ trễ băng thông lớn. Bên cạnh đó, lượng gói tin và số trạm gửi mang tính cạnh tranh có thể thay đổi theo thời gian không thể lường trước. Để phản ứng nhanh hơn và tốt hơn với các mạng có độ trễ băng thông lớn, thì thuật toán điều chỉnh cửa sổ của giai đoạn chống nghẽn mạng nên cải tiến tốt hơn so với trước. Giao thức Quick Vegas cố gắng giải quyết những vấn đề này.
2.3.2. Giai đoạn khởi động chậm
Theo phương trình (1), Vegas tính toán các dữ liệu thêm (Δ) và tăng gấp đôi cửa sổ tắc nghẽn của mỗi RTT khác. Khi lượng Δ > γ (thường được thiết lập là 1), Vegas bắt đầu giai đoạn khởi động chậm. Vấn đề cơ bản là khi cửa sổ tắc nghẽn nên được tăng gấp đôi, Vegas gửi hai gói back-to-back bất cứ khi nào nó nhận được một ACK. Điều này dẫn đến số lượng các gói tin được gửi tăng gấp đôi trong một khoảng thời gian ngắn. Sự truyền hàng loạt có thể gây ra biến thiên Δ. Kết quả là, Vegas bắt đầu giai đoạn khởi động chậm quá sớm và hiệu suất kém đi.
Hình 2.5: Điều khiển cửa sổ của TCP Vegas
Bảng 2.1: Kích thước cửa sổ tắc nghẽn cho Vegas và Quick Vegas ở mỗi vòng RTT