− Trong vòng 20 giây đầu, chưa có sự quá tải băng thông xảy ra, vì thế trong cả 2 giao thức thì luồng dữ liệu đều đi qua thông suốt, gần như không có packet nào phải ở trong hàng đợi. Tốc độ truyền của các luồng TCP qua link giữa 2 router CORE – R2 đạt tốc độ tối đa.
− 20s – 30s: bắt đầu xuất hiện tắc nghẽn, các gói tin được lưu lại ở trong hàng đợi. Với giao thức DropTail thì đạt ổn định khoảng 38 packet thường xuyên trong
queue, dưới ngưỡng tối đa 50 packet của link, và vì thế không có packet nào bị drop, dù băng thông đã bị đầy. Nhưng giao thức RED lại khác, do có cơ chế drop sớm các gói tin trong hàng đợi nên đã xuất hiện các packet bị mất, từ đó lưu lượng truyền dao động, không liên tục đạt ngưỡng tối đa 3Mbps, nhưng bù lại số gói tin trong hàng đợi giảm hẳn, dao động mạnh trong khoảng từ 0 đến 36 packet.
− 30s - 40s: lưu lượng truyền tăng cường TCP, tại giây 30 đột ngột tăng làm tràn đầy queue (hiện tượng lock out) ở cả 2 giao thức. Với DropTail, do đặc tính của nó nên băng thông lúc nào cũng được sử dụng tối đa, tuy nhiên số gói tin trong hàng đợi dao động hết sức thất thường, từ 0-50 packet, rất thường xuyên đạt ngưỡng 50 packet và drop mọi gói tin đến (hiện tượng lockout). Với RED, do có khả năng drop sớm nên không bị hiện tượng này, và số gói tin trong hàng đợi vẫn dao động ổn định quanh ngưỡng từ 5 đến 35 packet.
− 40s – 50s: quá trình bùng phát dữ liệu kết thúc, hàng đợi được giải phóng, không có gói tin nào bị mất. Trong thí nghiệm này thì giao thức DropTail tỏ ra tốt hơn khi gần như ngay lập tức tốc độ truyền của S1 và S2 đã duy trì ở mức tối đa. Trong khi đó, dựa vào biểu đồ băng thông, ta thấy với giao thức RED thì S1 và S2 phải mất 2 giây để từ từ tăng window size lên để truyền với tốc độ cao nhất. Nguyên nhân của việc này là do trong quá trình trước đó, RED đã drop nhiều gói tin hơn hẳn so với DropTail, trong đó vì tính ngẫu nhiên, nhiều gói tin từ nguồn S1, S2 cũng bị drop theo, vì thế trường window size từ 2 nguồn này đã giảm thấp và cần thời gian để phục hồi.
4.4.2. Thí nghiệm 2: Tăng cường độ tắc nghẽn với nguồn phát UDPa. Kết quả a. Kết quả
Ta theo dõi sự thay đổi của thông lượng - throughput sử dụng trên link CORE – R2 với 2 lần thay đổi mức độ bùng phát UDP như kịch bản đã phát biểu ở trên.
Hình 4. 6 Thông lượng của Droptail và RED khi CBR có throughput 3Mbps
Hình 4.7. Tỉ lệ packet bị mất của Droptail và RED b. Nhận xét:
Giao thức UDP truyền tin không tin cậy, nó không sử dụng trường window size hay 1 cơ chế nào khác để tự giảm tốc độ truyền mà chỉ đơn thuần là làm ngập băng thông, khác với giao thức TCP có thể tự giảm tốc độ truyền khi gặp tắc nghẽn. Trong thí nghiệm 2, ta có thể thấy tại giây 30, sau khi dừng phát UDP, chỉ còn luồng TCP đang hoạt động, thì có sự khác biệt giữa tốc độ phục hồi của luồng TCP giữa giao thức DropTail và RED.
Trong trường hợp mức độ bùng phát tại nguồn UDP chưa thật sự lớn (3Mbps, bằng với băng thông nút cổ chai) thì kết quả thu được cho thấy 2 nguồn TCP khi sử dụng giao thức RED có thể phục hồi nhanh hơn hẳn so với DropTail. Cụ thể tại các giây 30, 3 luồng TCP ở RED với tổng thông lượng 100Kbps chỉ mất 2s để đạt được thông lượng tối đa 3Mbps. Trong khi đó với Droptail thì từ 0 Kbps và phải mất đến 5s mới phục hồi hoàn toàn, lâu hơn 2,5 lần.
Tuy nhiên khi mức độ bùng phát tại nguồn UDP nghiêm trọng (5Mbps) thì kết quả thu được giữa 2 giao thức là không có sự khác biệt rõ ràng. Với lượng dữ liệu lớn, ngập tràn thì thuật toán loại bỏ sớm ngẫu nhiên của RED không còn tỏ ra hiệu quả, và tốc độ phục hồi ở giây 30 như trong thí nghiệm trên không có nhiều sự khác biệt so với giải thuật DropTail.
4.5. Đánh giá hiệu năng truyền thông đa phương tiện khi sử dụng WRED
Topô mạng và kịch bản được xây dựng chung như đã trình bày trong phần trên. WRED có nhiều loại khác nhau, tùy theo mục đích cần minh họa cho Policier Type nào mà ta sẽ có kịch bản tùy chỉnh các tham số tương ứng. Chi tiết sẽ được trình bày trong mô phỏng cụ thể tiếp theo.
