Để hiểu sự khác biệt đầy đủ giữa các thuật toán RED và BLUE, hình 4.6 so sánh đồ thị chiều dài hàng đợi trong một thí nghiệm bổ sung. Trong thí nghiệm này, một tải làm việc với nguồn vô hạn được thay đổi bằng cách tăng thêm số lượng 200 kết nối sau mỗi 20 giây. Như hình 2.32(a) cho thấy, RED duy trì liên tục mất gói thông qua thí nghiệm. Ngoài ra, với tải thấp hơn, thời điểm mất gói tin thường phụ thuộc vào thời gian không khả dụng như đánh dấu gói xác định và mất gói cuối
Số hóa bởi Trung tâm Học liệu – Đại học Thái Nguyên http://www.lrc-tnu.edu.vn
cùng gây ra quá nhiều nguồn làm giảm tốc độ truyền của chúng. Ngược lại, như hình 2.32(b) cho thấy, quản lý BLUE cho tỷ lệ đánh dấu thông minh hơn, với đồ thị chiều dài hàng đợi ổn định hơn. Thông báo tắc nghẽn được đưa ra với tốc độ mà không gây ra giai đoạn mất gói liên tục hoặc cũng không có giai đoạn không khả dụng liên tục. Chỉ khi tăng tải cung cấp tới 800 kết nối, BLUE duy trì lượng gói mất đáng kể .
Hình 2.32 Đồ thị chiều dài hàng đợi của RED và BLUE
Hình 2.32 là đồ thị chiều dài hàng đợi trung bình (Qave) và xác suất đánh dấu [pb/(1-count×pb)] của RED trong thí nghiệm. Chiều dài hàng đợi trung bình của RED ảnh hưởng trực tiếp tới xác suất đánh dấu của nó vì pb là hàm tuyến tính của Qave (pb = maxp×(Qave-minth)/(Maxth-minth)). Như thể hiện trong hình 2.32(a), chiều dài hàng đợi trung bình của RED biến động đáng kể sau những biến động của chiều dài hàng đợi tức thời. Vì vậy, xác suất đánh dấu của RED, như trong hình 2.32(b), cũng biến động đáng kể. Ngược lại, hình 2.33 cho thấy khả năng đánh dấu của BLUE. Như hình vẽ cho thấy, xác suất đánh dấu hội tụ về giá trị kết quả với tỷ lệ thông báo tắc nghẽn nhằm ngăn ngừa mất gói và giữ độ khả dụng kết nối cao trong suốt thí nghiệm. Trong thực tế, chỉ tại vị trí BLUE không thể duy trì ngăn chặn mất gói khi mỗi gói được đánh dấu, nhưng tải cung cấp vẫn còn lấn át kết nối cổ chai. Như được mô tả trước đó, điều này xảy ra tại t = 60s khi số lượng các nguồn được tăng lên 800. Lý do vẫn xảy ra mất gói tin khi mỗi gói được đánh dấu ECN chính là vì TCP không gọi RTO khi nhận được tín hiệu ECN với cửa sổ tắc nghẽn bằng 1. Điều này ảnh hưởng xấu đến hiệu suất của cả RED và BLUE trong thí nghiệm này. Lưu ý rằng việc so sánh xác suất đánh dấu giữa RED và BLUE đưa ra một số cái
Số hóa bởi Trung tâm Học liệu – Đại học Thái Nguyên http://www.lrc-tnu.edu.vn
nhìn sâu sắc là làm thế nào để RED hoạt động tốt hơn. Bằng cách đặt một bộ lọc thông thấp trên xác suất đánh dấu đã tính của RED, nó có thể hợp lý hoá cho cơ chế đánh dấu của RED để có hành vi tương tự như của BLUE.
Hình 2.33 Hành vi đánh dấu của RED
Trong khi tỷ lệ mất gói thấp, trễ hàng đợi thấp, và độ khả dụng kết nối cao là vô cùng quan trọng, đồ thị chiều dài hàng đợi và xác suất đánh dấu cho phép chúng tôi khám phá tính hiệu quả của RED và BLUE trong việc ngăn chặn đồng bộ hóa toàn cục và trong việc loại trừ xu hướng truyền liên tục từ các nguồn. RED cố gắng tránh đồng bộ hóa toàn cục bằng cách đánh dấu xác định ngẫu nhiên chúng bởi khoảng cách đánh dấu. Đáng tiếc, khi tải TCP tổng hợp thay đổi đột ngột như khi số lượng lớn các kết nối cùng xuất hiện, thì RED không thể đạt được mục tiêu này. Như hình 2.33(b) cho thấy, xác suất đánh dấu của RED thay đổi đáng kể trong khoảng thời gian rất ngắn. Như vậy, RED không đánh dấu gói tin đồng đều theo thời gian và do đó không thể loại bỏ đồng bộ hóa giữa các nguồn. Như hình 2.34 cho thấy, xác suất đánh dấu của BLUE vẫn ổn định. Kết quả là, BLUE đánh dấu gói tin ngẫu nhiên và đồng đều theo thời gian. Do đó, nó hoạt động tốt hơn trong việc tránh đồng bộ hóa toàn cục.
Một mục tiêu khác của RED là để loại bỏ xu hướng truyền ngược liên tục từ các nguồn trong mạng. Nó được thực hiện bằng cách hạn chế chiếm dụng hàng đợi để luôn luôn có chỗ còn lại trong hàng đợi tạo khối đệm tạm thời. Ngoài ra, chức năng đánh dấu của RED xem xét thời gian đánh dấu các gói tin cuối cùng đã tính toán để giảm xác suất của các gói tin liên tiếp thuộc cùng một cụm được đánh dấu.
Số hóa bởi Trung tâm Học liệu – Đại học Thái Nguyên http://www.lrc-tnu.edu.vn
Sử dụng một xác suất đánh dấu duy nhất, BLUE đạt được cùng một mục tiêu tốt như nhau.
Như đồ thị chiều dài hàng đợi của BLUE (Hình 2.34) cho thấy, sự chiếm dụng hàng đợi vẫn dưới khả năng thực tế, do đó cho phép thêm chỗ cho các gói tin. Ngoài ra, vì xác suất đánh dấu vẫn đều đặn (smooth) trên khoảng thời gian lớn, xác suất mà hai gói tin liên tiếp từ một nguồn truyền đều đặn được đánh dấu tương tự như với hai gói tin liên tiếp từ một nguồn truyền liên tục.
Hình 2.34 Hành vi đánh dấu của BLUE (pm)