Các thí nghiệm trước đó kiểm tra việc sử dụng phát hiện sớm ở dạng "tinh khiết" mà thông báo tắc nghẽn là rỗi và không gây mất gói. Tuy nhiên, ngoại trừ sự hỗ trợ với ECN, RED phải dùng một gói mất để chỉ ra dấu hiệu tắc nghẽn. Điều này dẫn đến một vấn đề tối ưu hóa thú vị, tại hàng đợi RED phải chọn một giá trị maxp để tối thiểu hoá tổng các gói mất do phát hiện sớm và gói mất do tràn bộ nhớ đệm. Với những giá trị vô cùng lớn maxp, tỷ lệ mất gói dữ liệu được khống chế bởi việc mất gói do phát hiện sớm, trong khi với các giá trị maxp vô cùng nhỏ, các gói mất phần lớn là do sự tràn hàng đợi. Để minh họa điều này, các thí nghiệm trong Phần 2.2.2.1 đã được lặp đi lặp lại bằng cách sử dụng một hàng đợi RED bình thường. Hình 2.16 cho thấy tỷ lệ mất gói của RED với 32 và 64 kết nối hoạt động thông qua kết nối cổ chai. Một lần nữa, khi giảm maxp, hiệu suất của RED gần giống hàng đợi cắt-đuôi. Tuy nhiên, khi tăng maxp, sự mất gói giúp thuật toán phát hiện sớm bắt đầu khống chế tỷ lệ mất gói. Cả hai đồ thị cho thấy một điểm tổng gói mất tối thiểu do thuật toán phát hiện sớm và do tràn bộ đệm. Điểm này xảy ra tại các giá trị khác nhau của maxp tùy thuộc số lượng kết nối hiện tại. Khi các kết nối được bổ sung thêm, giá trị tối ưu maxp sẽ tăng.
Lưu ý rằng ngay cả với hàng đợi RED được tham số hoá với mất gói tối thiểu, tỷ lệ mất gói tiếp tục tăng với tải lưu lượng. Sử dụng gói mất như là một phương tiện để thông báo tắc nghẽn về cơ bản giới hạn tỷ lệ mất gói quan sát qua mạng
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
Internet. Khi thêm các kết nối đến, tỷ lệ thông báo tắc nghẽn tăng vì thế tỷ lệ mất gói tăng. Phân tích trạng thái ổn định của thuật toán tránh tắc nghẽn TCP [42, 64, 68, 76] cho thấy cái nhìn sâu sắc trong trường hợp này. Như phân tích cho thấy, tỷ lệ mất gói ngẫu nhiên tại xác suất không đổi p trên băng thông kết nối TCP có thể được tính là:
MSS C BW
RTT p
(2.1)
Ở đây, MSS là kích thước segment, RTT là chu kỳ truyền nhận, và C là hằng số. Với mô hình này, tỷ lệ mất gói trên một kết nối cổ chai duy nhất là L Mbps có thể xấp xỉ với số lượng kết nối cố định N. Với điều kiện, băng thông phân phối cho mỗi kết nối riêng lẻ xấp xỉ băng thông kết nối chia cho số lượng kết nối (L/N). Thay thế giá trị này vào phương trình (2.1) và rút ra p, thu được:
2 N MSS C p L RTT (2.2)
Theo phương trình (2.2) cho thấy, khi tất cả các kết nối đều sử dụng thuật toán tránh tắc nghẽn TCP, với L nhỏ p sẽ tăng với số lượng kết nối hiện tại. Dễ thấy, hiện tượng này có thể được thấy bằng cách sử dụng một ví dụ lý tưởng. Giả sử hai mạng giống hệt nhau đều có kết quả trễ băng thông 64KB từ một cặp điểm cuối như trong hình 2.17. Trong mạng thứ nhất, 4 kết nối giống hệt nhau hoạt động trong khi mạng kia là 8 kết nối giống hệt nhau. Các kết nối được chia sẻ công bằng, cửa sổ tắc nghẽn cho mỗi kết nối xấp xỉ trễ băng thông chia cho số lượng kết nối hiện tại. Đối với 4 kết nối, mỗi kết nối sẽ có cửa sổ tắc nghẽn dao động quanh 16KB. Giả sử cửa sổ TCP bình thường và kích thước một segment là 1KB, mỗi kết nối riêng lẻ trong mạng này thường sẽ xây dựng cửa sổ tắc nghẽn khoảng 16 gói, thông báo tắc nghẽn nhận được dưới dạng một gói mất, trở lại cửa sổ khoảng 8 gói và sau đó từ từ xây dựng cửa sổ tắc nghẽn tại tỷ lệ một gói cho mỗi RTT. Dựa vào hành vi này, tỷ lệ mất gói trên tất cả các kết nối trong mô hình lý tưởng sẽ xấp xỉ 4 gói mất cho 8 RTT hoặc (0,5 gói / RTT). Tương tự như vậy, bằng cách sử dụng cùng một mô hình lý tưởng, cho thấy khi hiện tại có 8 kết nối, mất gói xảy ra tại tỷ lệ (2 gói / RTT), và tăng theo bậc hai.
Vì nguồn gốc của phương trình 2.2 dựa trên kịch bản lý tưởng, tỷ lệ mất gói thực tế không giống bình phương số lượng kết nối. Từ thí nghiệm cắt-đuôi trong
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
hình 2.16, tỷ lệ mất gói quan sát cho thấy sự phụ thuộc vào số lượng kết nối ứng với khoảng giữa tuyến tính và bậc hai. Có vài lý do vì đây là trường hợp. Lý do thức nhất là đạo hàm giả định sự chia sẻ công bằng băng thông qua kết nối cổ chai. Nó cho thấy rằng, cũng như số lượng các kết nối TCP tăng, lượng bất công giữa các kết nối tăng đáng kể [74]. Một lý do khác là phương trình không có sự xuất hiện của mô hình khi truyền lại timeouts xảy ra. Bằng cách sử dụng các mô hình TCP có hành vi bắt giữ việc truyền lại timeouts, tỷ lệ mất gói có thể dự đoán chính xác hơn [79].
Hình 2.17 Mạng ví dụ
Các kết quả từ phương trình 2.2 vẫn quan trọng vì chúng cho thấy, khi mạng tắc nghẽn hơn, thì tỷ lệ mất gói tăng đáng kể, do đó làm cho xác suất của tắc nghẽn có nhiều khả năng sụp đổ hơn. Phương trình nêu bật sự cần thiết phải tách gói mất từ thông báo tắc nghẽn thông qua việc sử dụng các thông báo tắc nghẽn tường minh (ECN). Tuy nhiên, thay vì ECN, phương trình cũng cung cấp một cái nhìn sâu sắc về cách cải thiện tỷ lệ mất gói cho một số kết nối cố định. Cách thứ nhất là làm thay đổi chính cơ chế tránh tắc nghẽn là không tăng liên tục tốc độ gửi để vượt quá khả năng của mạng. Ví dụ, các đề xuất như: Tri-S [94, 95] hay TCP Vegas [23] có thể được sử dụng để làm giảm lượng mất gói được quan sát. Cách khác là tăng băng thông kết nối cổ chai L. Bởi việc tăng băng thông kết nối, tăng cửa sổ tắc nghẽn hiệu quả của các kết nối riêng lẻ, do đó giảm tần xuất thông báo tắc nghẽn trong các kịch bản ở trên. Giảm kích thước segment được sử dụng trong các thuật toán tránh tắc nghẽn cũng có thể cải thiện tỷ lệ mất gói. Kích thước segment nhỏ hơn cho phép các máy chủ cuối tăng cửa sổ tắc nghẽn của nó chậm hơn, do đó giảm tỷ lệ thông báo tắc nghẽn nhận được. Cuối cùng, tỷ lệ mất gói có thể được cải thiện bằng cách tăng RTT. Tăng RTT, thông qua việc sử dụng các bộ đệm mạng bổ sung [93] làm tăng độ trễ băng thông làm chậm tốc độ thông báo tắc nghẽn.
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