Khi cho lưu lượng TCP và TFRC chạy trên topo mạng như hình 3.7 với các tỉ lệ lỗi vơ tuyến khác nhau thì thơng lượng của các luồng này sẽ bị suy giảm như chỉ ra trong hình 3.8. Khi tỉ lệ lỗi vơ tuyến càng tăng thì độ giảm về thơng lượng của các lưu lượng này càng lớn.
Hình 3.8 Sự giảm hiệu suất của TCP và TFRC khi có lỗi liên kết vơ tuyến trong mơi trường ở hình 3.7
Hình 3.9 Thơng lượng của các luồng TFRC qua các mạng có dây và khơng dây
Khi đó, TFRC cần được thay đổi để có thể hoạt động tốt hơn trong các mơi trường vô tuyến với nhiều lỗi ngẫu nhiên. Rất nhiều cải tiến đã được đưa ra với những tham số khác nhau. Dưới đây là một số cải tiến của TFRC như TFRC-Jr, TFRC Veno, TFRC dựa trên mức cường độ tín hiệu,….đã được nghiên cứu và thử nghiệm rộng rãi.
3.3.2 TFRC-Jr
Ý tưởng của TFRC-Jr là sử dụng jitter như là một dấu hiệu để phân biệt lỗi do tắc nghẽn trong mạng hay do lỗi ngẫu nhiên của môi trường vô tuyến.
Giao thức RTP đưa ra định nghĩa inter-arrival jitter như sau: giá trị của khoảng cách gói tại máy thu so với khoảng cách gói tại máy phát đối với một cặp gói [3]. Ví dụ, nếu Si là thời gian gửi đối với gói i và Ri là thời gian nhận đối với gói i, khi đó đối với hai gói i và j thì inter-arrival jitter D(i,j) được biểu diễn là:
D(i,j) = (Rj – Ri) – (Sj – Si) = (Rj – Sj) – (Ri – Si)
Giá trị của inter-arrival jitter có thể giải thích trễ giữa các gói. Nếu D lớn hơn 0, nó có nghĩa là thời gian truyền của gói j dài hơn gói i. Chúng ta có thể giả thiết gói j được xếp trong hàng đợi một thời gian. Tùy thuộc vào hiện tượng này, tỉ lệ jitter được định nghĩa là xấp xỉ tỉ lệ của các gói trong hàng đợi.
Tỉ lệ jitter cũng được định nghĩa như là tỉ lệ gói trong hàng đợi. Khi tăng hàng đợi đạt đến giới hạn cao nhất của bộ đệm, các gói đang đến tiếp theo tại router sẽ bị rớt. Do đó, tỉ lệ các gói bị rớt sẽ được xấp xỉ như tỉ lệ của các gói trong hàng đợi. Tỉ lệ này có thể được xử lý như bộ báo trước tỉ lệ mất gói mà được đưa vào biểu thức bởi inter- arrival jitter. Tham số này mà chúng ta gọi là tỉ lệ jitter có thể được định nghĩa như sau:
Tỉ lệ jitter là một gợi ý quan trọng để quyết định xem các gói có được xếp trong hàng đợi hay không. Trong phương pháp này, sự kiện tắc nghẽn được định nghĩa như là thời gian khi máy thu phát hiện việc mất gói và tỉ lệ jitter là đáng kể. Cơ chế TFRC sẽ chấp nhận việc ước tính tỉ lệ jitter để tăng hiệu suất của nó trong mơi trường vơ tuyến.
Trong phương pháp này, tỉ lệ jitter được tính tại máy phát dựa theo thơng tin phản hồi. Khi phát hiện mất gói, tỉ lệ jitter được tính tốn trước tiên để phán đốn xem mất gói là do tắc nghẽn hay lỗi ngẫu nhiên. Nếu do tắc nghẽn, TFRC sẽ sử dụng biểu thức thông lượng để cân đối lại tốc độ gửi. Ngược lại, máy phát đợi phản hồi kế tiếp. TFRC-Jr làm việc như sau:
1. Máy thu đo tốc độ sự kiện mất gói và gửi thơng tin này lại cho máy phát. 2. Nếu tốc độ sự kiện mất gói p là khác xa 0, máy phát sử dụng các bản tin phản
3. Nếu tỉ lệ jitter là vượt quá một ngưỡng, nó có nghĩa là sự kiện mất gói là do tắc nghẽn
4. Tốc độ sự kiện mất gói và RTT được phản hồi trong biểu thức thông lượng TFRC, đưa ra tốc độ truyền có thể chấp nhận được. Thuật tốn này có thể được được mơ tả như sau:
…….. Recv();
//máy thu nhận được gói phản hồi; If (p>0) {
Jr=cacu_jitter_ratio(); // tính tỉ lệ jitter hiện tại; If (Jr>threshold) //Tỉ lệ Jitter khác xa ngưỡng; X_rate=TCP_throught(P,R,t_rto,S); } Else Wait_for_feedback(); ……
Với TFRC-Jr tỉ lệ jitter trung bình Jrmean(i) được sử dụng như một ngưỡng. Jrmean(i) được tính sử dụng trung bình mũ với a=0.2:
Jrmean(i)=(1-a) * Jrmean(i-1) + a*Jri
Ở đó, (1-a) là hệ số suy giảm hàm mũ mà điều khiển độ trơn mịn của Jrmean.
Dưới đây là một số kết quả thực nghiệm đối với TFRC-Jr. Chúng ta sẽ đánh giá hiệu suất goodput và tính thân thiện của TFRC-Jr.
Cấu hình thực hiện mơ phỏng được cho như trong hình 3.10. Các liên kết sau cùng đến máy thu là các liên kết vô tuyến với băng thông và trễ là 100Mb và 1ms. Các liên kết từ các máy phát đến router là cố định với băng thông 100Mb và trễ 1ms. N luồng chia sẻ một liên kết cổ chai cố định với băng thơng 5Mb và trễ 35ms [3]. Chương trình mơ phỏng chạy trong 100 giây.
Hình 3.10 Cấu hình mạng lai có dây-khơng dây với N luồng
Trên topo này chạy TCP, TFRC và TFRC-Jr với N=1,2,4,8,10 và 16. Hình 3.11 chỉ ra goodput của một luồng với tỉ lệ lỗi khác nhau trên các liên kết vơ tuyến. Ở đó goodput là lượng dữ liệu đã được phân phát qua mạng một cách hiệu quả. Nó là một thơng số thơng báo trực tiếp hiệu suất mạng.
Hình 3.11 So sánh TCP và TFRC-Jr trong mạng có dây-khơng dây với các tỉ lệ lỗi liên kết vô tuyến khác nhau (1 luồng)
Khi tỉ lệ lỗi liên kết vơ tuyến tăng thì hiệu suất của các giao thức cũng giảm. Tuy nhiên TFRC-Jr đã cải thiện được hiệu suất khá nhiều so với TCP và TFRC nguyên gốc. 1 N 1 N 2 2 . . . … … …
Wired links Wireless links
Hình 3.12 Hiệu suất của nhiều luồng trong mơi trường có dây-khơng dây với tỉ lệ lỗi là 0,005
Hình 3.12 chỉ ra goodput trung bình của N (N=2,4,6,8,10,16) luồng trong mô phỏng với tỷ lệ lỗi là 0,005. Goodput trung bình chuẩn hóa được tính như goodput trung bình được chia bởi băng thơng cổ chai. Có thể thấy goodput chuẩn hóa tăng với số lượng luồng. Điều này là do không phải tất cả các luồng sẽ trải qua lỗi vô tuyến ở cùng một thời điểm mà tại cùng một thời điểm mỗi luồng có thể chịu các tỉ lệ lỗi vơ tuyến khác nhau. TFRC-Jr có thể đạt được goodput cao hơn TFRC nguyên gốc.
Mô phỏng thứ hai được thực hiện với m luồng TFRC-Jr và m luồng TCP để tính tỉ lệ giữa goodput trung bình của chúng và so sánh kết quả với TFRC. Hình 3.13 chỉ ra kết quả với m=1,2,4,6 và 8 và tỉ lệ lỗi là 0.0005 [3]. Các tỉ lệ này được sử dụng để đánh giá độ than thiện của TFRC-Jr so với TCP.
Hình 3.13 TFRC và tỉ lệ goodput TFRC-Jr với các luồng TCP
Hình 3.13 cho thấy TFRC-Jr có sự thân thiện với TCP là chấp nhận được (giá trị tỉ lệ là nhỏ hơn 2) và không làm yếu luồng TCP đến mức sai lệch. Nhưng nó khơng thân thiện nhiều với TCP như TFRC gốc. Lý do là TFRC-Jr có thể phân biệt các loại mất gói khác nhau trong khi TFRC và TCP không thể phân biệt được các loại mất gói này.
3.3.3 TFRC Veno
Như đã trình bày ở trên, TFRC sử dụng biểu thức thông lượng xuất phát từ thuật tốn điều khiển tắc nghẽn TCP Reno hay cịn gọi là biểu thức Reno. TCP Reno luôn đối xử với sự xuất hiện của mất gói như một biểu hiện của tắc nghẽn mạng. Giả thiết này không áp dụng được cho các mạng với các kênh vơ tuyến ở đó mất gói thường là do nhiễu, lỗi liên kết hoặc các lý do khác ngoài tắc nghẽn mạng. Việc hiểu sai của mất gói ngẫu nhiên như một chỉ dẫn của tắc nghẽn mạng gây ra Reno để giảm tốc độ gửi dữ liệu một cách không cần thiết mà kết quả là hiệu suất giảm đáng kể. Do đó, TFRC sử dụng biểu thức Reno cũng sẽ chịu sự giảm hiệu suất lớn trong các mạng không dây. Một phương pháp khác để cải thiện giao thức TFRC ban đầu này là giao thức TFRC Veno sử dụng một biểu thức thông lượng mới. TFRC Veno có thể đạt được sự cải thiện thơng lượng một cách đáng kể lên đến 300% (so với TFRC trong các mạng không dây với tỉ lệ lỗi 10%) [4]. Các đặc điểm cần có của tính bình đẳng, thân thiện TCP và độ trơn mịn trong TFRC cải tiến này là tương tự như trong TFRC gốc. Cũng nên chú ý rằng TFRC Veno chỉ bao gồm sự thay đổi của TFRC tại phía phát khơng u cầu bất cứ sự thay đổi nào về các giao thức phía thu hoặc sự can thiệp của các nút
mạng trung gian. Do đó, nó có thể được phát triển ngay trong các ứng dụng server qua mạng Internet hiện tại. Khác với tất cả những nỗ lực trước nhằm giữ biểu thức Reno không thay đổi với TFRC, TFRC Veno sử dụng một biểu thức tiến bộ hơn để thay thể biểu thức Reno. Trong thực tế, biểu thức này xuất phát từ wireless TCP có tên là TCP Veno.
TCP Veno được đề xuất năm 2003 và đã được tích hợp trong Linux Kernel từ phiên bản 2.6.18. Ý tưởng chính của TCP Veno là sử dụng trạng thái tắc nghẽn- trạng thái vi phân hoặc trạng thái khơng tắc nghẽn để giải quyết vấn đề khó khăn trong việc quyết định loại mất gói: mất gói do tắc nghẽn hay mất gói ngẫu nhiên. Đặc biệt, số lượng các gói trong liên kết N được ước lượng như sau:
Ở đó cwnd là kích thước cửa sổ tắc nghẽn hiện tại, BaseRTT là round-trip time nhỏ nhất đo được cho đến lúc đó và nó điều chỉnh bất cứ khi nào lỗi mất gói được phát hiện là do time-out hay các bản sao ACK.
Nếu N nhỏ hơn một ngưỡng β nào đó khi xuất hiện một lỗi mất gói, lỗi mất gói được suy luận như một lỗi ngẫu nhiên và Veno giảm cửa sổ tắc nghẽn của nó (cwnd) với hệ số ; ngược lại, lỗi mất gói được coi như lỗi tắc nghẽn và khi đó Veno giảm cửa sổ tắc nghẽn với hệ số . Thông thường β được thiết lập là 3, được thiết lập là 4/5 và được thiết lập là 1/2. Biểu thức dưới đây mô tả hoạt động này
Một vấn đề thực tế là TCP Veno hoạt động gần giống với Reno và chỉ có sự khác biệt giữa TCP Veno và TCP Reno là có bao nhiêu giá trị cwnd được giảm khi xuất hiện lỗi mất gói; Reno ln ln giảm cwnd của nó đi một nửa trong khi Veno đôi khi giảm với hệ số (lỗi ngẫu nhiên) và đôi khi là giảm với hệ số (lỗi tắc nghẽn).
Hình 3.14 Cấu hình mơ phỏng
Sau đây là một số kết quả thực nghiệm với TFRC Veno theo topo mạng như trong hình 3.14. Trước tiên, cho một luồng TFRC hoặc TFRC Veno chạy qua mạng. Thời gian bùng nổ và thời gian rỗi đều là 100ms. Tốc độ của mỗi kết nối được thiết lập là 100ms. Thời gian thực hiện là 300s.
Hình 3.15 So sánh thơng lượng của các luồng đơn với Wb = 5Mbps,
Delayb=80ms, tỉ lệ lỗi ngẫu nhiên là 0,01
Hình 3.15 là sự so sánh thông lượng của TFRC với TFRC Veno với các giá trị của được thiết lập lần lượt là 1, 2, 3. Với các giá trị khác nhau của thì thơng lượng của
1 2 N 1 2 N 1 2 N . . . . . . . . . 1 ms 1 ms 1 ms 10 ms 1 ms 1 ms
mỗi luồng TFRC Veno là khác nhau. Tuy nhiên, tất cả các TFRC Veno đều cải thiện thông lượng hơn nhiều (lên đến 70%) so với TFRC nguyên bản.
Hình 3.16 So sánh thơng lượng khi có nhiều luồng với Wb=5Mbps,
Delayb=80ms, tỉ lệ lỗi ngẫu nhiên là 0,01
Khi tăng số lượng luồng lên và so sánh thông lượng của TFRC và TFRC Veno với tỉ lệ lỗi ngẫu nhiên là 0,01 kết quả hình 3.16 cho thấy khi số lượng kết nối tăng lên, mạng bị ảnh hưởng nhiều bởi tắc nghẽn, khi đó TFRC Veno hoạt động tương tự TFRC nguyên bản.
Để đánh giá tính thân thiện với TCP của TFRC Veno, chúng ta thực hiện các mô phỏng sau: trước tiên thiết lập một số luồng TCP Sack nhất định (từ 4 đến 64) qua đường truyền và tính thơng lượng trung bình của chúng T1. Sau đó thay thế một nửa trong số đó bằng các luồng TFRC Veno và tính lại thơng lượng trung bình của các luồng TCP Sack T2. Nếu T2/T1 bằng 1 có nghĩa là các luồng Sack khơng bị ảnh hưởng bởi các luồng TFRC Veno và do đó các luồng TFRC Veno là hồn tồn thân thiện với TCP. Nếu T2/T1 càng gần bằng 1 có nghĩa là các luồng TFRC Veno càng thân thiện.
Hình 3.17 là kết quả mô phỏng thu được với β =1 và thực hiện với các số luồng là 4, 8, 16, 32, 64.
Hình 3.17 Tính thân thiện của TFRC Veno với
Khi giá trị ngưỡng càng lớn thì các luồng TFRC Veno càng kém thân thiện đặc biệt là khi mạng bị quá tải nghiêm trọng. Tuy nhiên, tính thân thiện của TFRC Veno khi là có thể chấp nhận được như hình 3.17 khi đó T2/T1 ln ở trong khoảng 85% thậm chí dưới điều kiện quá tải nghiêm trọng.
3.3.4 Một số phương pháp cải tiến khác của TFRC
Việc nâng cao các mạng hỗ trợ của TFRC cần đến sự hỗ trợ của các nút trung gian trong mạng, như các router, proxy, các điểm truy nhập và các loại thiết bị khác. Các ví dụ điển hình là TFRC dựa trên ECN (Explicit Congestion Notification) [4], TFRC dựa trên Proxy [4], WM-TFRC (Wireless Measurement based TFRC) và TFRC dựa trên AED (Accurate and Explicit Differentiation) [4].
TFRC dựa trên ECN sử dụng các router trung gian để phát hiện tắc nghẽn mạng mới chớm và thông báo cho máy thu bằng cách sử dụng việc đánh dấu ECN. Sau đó máy thu đo tỉ lệ sự kiện đánh dấu p và gửi thông tin này lại cho máy phát. Trong cách này, TFRC dựa trên ECN bỏ qua việc mất gói xuất hiện qua hop khơng dây hoặc ảnh hưởng của việc sắp xếp lại gói bắt gặp trên Internet và chỉ tính đến các mất gói do tắc nghẽn khi thực hiện cân đối tốc độ gửi.
TFRC dựa trên Proxy thuê một proxy để chia kết nối client-server và chỉ sử dụng TFRC qua các phần chung của kết nối client-server,…phần giữa server và proxy. Trong phần khác giữa client và proxy, nó tạo một đường hầm RTP thơng qua một TCP mà được định nghĩa là TCP thân thiện. Phương pháp này cải thiện thơng lượng trung bình và việc sử dụng liên kết vô tuyến.
WM-TFRC sử dụng điểm truy nhập AP (Access Point) trong mạng LAN không dây để đo tỉ lệ của các sự kiện mất gói khơng dây (ví dụ các sự kiện mất gói gây ra bởi các lỗi bit) pw và phản hồi giá trị này lại cho máy phát theo định kì. Trong khi đó, máy thu cũng cung cấp phản hồi về tỉ lệ của tổng các sự kiện mất gói (bao gồm mất gói khơng dây và mất gói do tắc nghẽn) p đến máy phát. Do đó, máy phát có thể luận ra tỉ lệ của các sự kiện mất gói do tắc nghẽn (ví dụ các sự kiện mất gói do tắc nghẽn) pcon bằng việc trừ pw đi p. Trong cách này, tốc độ gửi của WM-TFRC mà được suy ra từ pcon thay vì p, có thể được cải thiện.
TFRC dựa trên AED sử dụng một phương pháp vi phân mới gọi là phương pháp vi phân chính xác và rõ ràng ADE để cải thiện hiệu suất của TFRC. ADE giả sử rằng các trạm được triển khai trước và sau mỗi liên kết vô tuyến. Các trạm kiểm tra mỗi gói và phát hiện mất gói bằng việc tìm một gói có số thứ tự khơng đúng (out of order). Các trạm tại biên của các mạng cố định xử lý một mất gói như một mất gói do tắc nghẽn và các trạm sau khi một liên kết vơ tuyến xử lý một mất gói như là một mất gói vơ tuyến. Khi đó, các trạm đánh dấu các gói mà khơng bị mất với thơng tin về các gói đã mất (ví dụ các gói đã bị mất là do tắc nghẽn hay do các lỗi ngẫu nhiên). Do đó, khi nhận các gói đánh dấu này, máy thu có thể tính tỉ lệ sự kiện mất gói chính xác và cung cấp phản hồi lại phía máy phát.
Kết luận: Một ưu điểm quan trọng của TFRC là nó cải thiện tính ổn định về tốc độ