- Gần đây, giao thức truyền đa đường TCP cho phép truyền tải các gói dữ liệu của nó trên nhiều đường (path) đồng thời. - Việc truyền dữ liệu trên đa đường như thế sẽ cải thiện thông lượng truyền, có thể cân bằng tắc nghẽn trong các đường và cung cấp khả năng chuyển vùng tự nhiên trong mạng.. - Tuy nhiên, tốc độ truyền dữ liệu của MPTCP biến thiên lớn, không phù hợp cho các ứng dụng multimedia mà chúng yêu cầu tốc độ dữ liệu mượt.. - Các kết quả mô phỏng đã chứng tỏ rằng thuật toán đề xuất MPTFRC không những đảm bảo ba tiêu chắ thiết kế thuật toán đa đường mà còn cung cấp tốc độ dữ liệu mượt hơn MPTCP trong khi vẫn duy trì được sự chia sẻ công bằng với các luồng TCP Reno và MPTCP hiện có.. - Kiến trúc multipath TCP [8] là giao thức mở rộng các đặc điểm từ giao thức TCP, cho phép một kết nối phân chia thành nhiều đường (path) và dữ liệu được truyền trên các đường đồng thời.. - Một kết nối multipath TCP là một tập hợp của nhiều subflow mà mỗi subflow điều khiển một đường, sử dụng cửa sổ điều khiển tắc nghẽn để điều chỉnh tốc độ trên mỗi đường. - MPTCP thực hiện điều khiển tốc độ gửi dữ liệu phối hợp giữa các đường đảm bảo ba tiêu chắ: (i) nâng cao thông lượng truyền, (ii) đảm bảo tắnh công bằng đối với các luồng TCP hiện có và (iii) có khả năng cân bằng tắc nghẽn: chuyển dữ liệu từ đường có tắc nghẽn nhiều sang đường có tắc nghẽn ắt hơn. - Vì MPTCP được thiết kế cho đa ứng dụng, nên tốc độ truyền dữ liệu của MPTCP biến thiên lớn, không phù hợp cho các ứng dụng multimedia mà ở đó chúng yêu cầu tốc độ dữ liệu truyền mượt (chúng tôi gọi yêu cầu này tiêu chắ (iv) cho các ứng dụng multimedia).. - Đã có nhiều nghiên cứu điều khiển tắc nghẽn cho các ứng dụng multimedia trong giao thức đa đường, cụ thể: MultiTCP [12] là một điều khiển định hướng bên nhận (receiver-driven control), nó tăng tốc độ như TCP đơn đường và giảm tốc độ tỉ lệ nghịch với bình phương của số lượng đường được sử dụng. - Ngược lại, DMP scheme [10] là một điều khiển định hướng bên gửi (sender-driven control), nó không quan tâm các luồng con có chia sẻ đường truyền cổ chai hay không, cả hai giải pháp trên không quan tâm đến tốc độ mượt và cân bằng tắc nghẽn. - Ngoài ra, TCP-ROME [11] giảm sự biến động của tốc độ tức thời bằng cách sử dụng điều khiển dựa trên tốc độ như trong TFRC [3], đầu nhận trong TCP-ROME điều chỉnh tốc độ của luồng con tùy theo tốc độ video yêu cầu và tỉ lệ thông lượng của mỗi luồng, không quan tâm có đường truyền cổ chai.. - năng bù khác biệt RTT, mặc dù nó có khả năng cung cấp tốc độ truyền dữ liệu mượt.. - Hình 2: Thông lượng chia sẻ công bằng giữa MulTFRC và TCP Reno. - Các kết quả mô phỏng đã chứng tỏ rằng thuật toán đề xuất MPTFRC không những đảm bảo ba tiêu chắ trên mà còn cung cấp tốc độ dữ liệu mượt hơn MPTCP trong khi vẫn duy trì được sự chia sẻ công bằng với TCP chuẩn, TFRC và MPTCP hiện có.. - Để cải tiến công thức truyền tốc độ từ thuật toán TFRC gốc [3], việc chứng minh công thức dựa vào giao thức TCP đa đường. - Xuất phát từ công thức điều khiển tốc độ trong TFRC gốc được đề xuất trong [3].. - trong đó, công thức tắnh thông lượng được tắnh bằng gói tin/giây, là round-trip-time, tỉ lệ mất gói tin là là số gói tin được xác nhận bởi một ACK. - Trọng số đề xuất điều chỉnh phối hợp tốc độ truyền dữ liệu đưa vào giao thức MPTFRC ở trạng thái ổn định là. - Trong đó là tốc độ truyền dữ liệu ở trạng thái ổn định, gọi là số gói tin được xác nhận bởi một ACK trên đường. - gói tin trong cửa sổ tắc nghẽn và trong quá trình các gói tin được gửi đi sẽ không có bất kỳ gói tin nào được gửi, trýớc khi ACK đầu tiên được gửi về. - trên một vòng hay trong giai đoạn tránh tắc nghẽn và không mất gói tin. - Khoảng thời gian của một vòng bằng với và gói tin bị mất trong một vòng thì độc lập với các vòng khác.. - 2.1 Phát hiện mất gói tin theo cơ chế dupACK. - Xét trên mỗi đường , chúng tôi định nghĩa thông lượng được xác định số gói tin được truyền đi trong khoảng thời gian nhất định và TDP r. - là khoảng giữa hai lần xảy ra mất gói tin trong cơ chế dupACK.. - Hình 3: Cơ chế phát hiện mất gói tin dạng dupACK. - Trong một TDP r thứ , thì là số gói tin được gửi đi, là khoảng thời gian và là kắch thước cửa sổ. - Mối quan hệ giữa thông lượng và xác suất mất gói tin được tắnh như sau:. - Giả sử hệ số là gói tin bị mất đầu tiên trong TDP r thứ tại vòng . - gói tin sẽ được thêm vào vòng theo công thức:. - Do trong vòng độc lập với các gói tin trong các vòng khác, vì thế là một chuỗi các biến ngẫu nhiên độc lập và phân phối giống nhau. - Xác suất tức là gói tin đã gửi thành công trước khi gói tin bị mất xảy ra.. - 2.2 Phát hiện mất gói tin theo cõ chế dupACK và Time-out. - Đặt là khoảng thời gian trong trường hợp mất gói tin dưới dạng time-out và khoảng thời gian trong trường hợp mất gói tin dưới dạng dupACK. - Đặt M r là số gói tin đã truyền trong khoảng thời gian S r , khi đó {S r, M r } là một chuỗi các biến ngẫu nhiên. - Thông lượng được tắnh như sau:. - Trong TDP r thứ , xác định các giá trị là số gói tin được gửi, là khoảng thời gian và. - Týõng tự, là số gói tin gửi trong khoảng thời gian. - Thông lượng cụ thể được tắnh như sau:. - Hình 4: Mất gói tin dạng dupACK và time-out. - Hình 5: Gói tin bị mất trong vòng kế cuối Xét các gói tin từ được gửi tại vòng kế cuối, các gói nhận được ACK và giả. - sử gói tin là gói tin đầu tiên bị mất. - Do đó, tất cả các gói tin từ trong vòng kế cuối đều bị mất. - Tuy nhiên, khi các gói tin nhận được ACK thì có gói tin khác. - được gửi trong vòng kế tiếp mà có thể được xem là vòng cuối cùng có một số gói tin bị mất, giả sử gói tin bị mất là , tức là gói tin từ. - Đặt là số gói tin đã gửi thành công trong vòng cuối cùng được xác nhận bởi ACK cho các gói tin . - Giả sử là xác suất mà gói tin đầu tiên nhận được ACK trong một vòng của gói tin thì:. - Giả sử là xác suất mà gói tin nhận được ACK trong vòng cuối cùng ( là gói tin được gửi) và phần còn lại của những gói tin trong vòng. - Nếu có bị mất gói tin thì. - Đặt là xác suất mất gói tin trên cửa sổ với kắch thước dưới dạng time-out.. - Xác suất có gói tin bị mất trong vòng kế cuối và gói tin bị mất trong vòng cuối cùng và có giá trị. - Tiếp theo, xem xét khi một gói tin được truyền giữa hai chuỗi time-out liên tiếp. - Một chuỗi dạng time-out xảy thì có liên tiếp mất gói tin. - Trong quá trình thiết kế MPTFRC, chúng tôi nhận thấy rằng, tốc độ truyền dữ liệu của MPTFRC nếu chỉ cập nhật tăng, giảm theo công thức (1) thì xảy ra hiện tượng đánh võng. - Giả sử rằng MPTFRC truyền dữ liệu trên hai đường độc lập có cùng băng thông, độ trễ và cùng mức độ nghẽn mạng thì sự đánh võng được mô tả là: dữ liệu gần như chỉ truyền trên một đường trong khoảng thời gian ngẫu nhiên và sau đó chỉ truyền trên đường còn lại và lặp lại như thế. - Thuật toán tăng tốc độ truyền trên đường được trình bày:. - Thuật toán điều khiển tăng tốc độ trên đường trong giao thức MPTFRC:. - Trong Hình 7 khi truyền dữ liệu chúng tôi không sử dụng tham số tránh đánh võng . - Thông lượng truyền trên hai đường thay đổi. - Đầu tiên thông lượng tăng nhanh trên đường truyền thứ 2 (path 2) sau đó bắt đầu giảm tốc độ, thông lượng truyền thay đổi chỉ truyền trên đường 1 (path 1) và gần như chỉ truyền trên một đường trong khoảng thời gian ngẫu nhiên, tốc độ truyền trên hai đường luân phiên thay đổi, hiện tượng đánh võng xảy ra. - trên hai đường. - Khi sử dụng tham số tránh đánh võng thì không xuất hiện sự đánh võng như trong Hình 8, ở đó tốc độ trên hai đường truyền (path 1 và path 2) gần như bằng nhau trong suốt 100 giây mô phỏng.. - Với các tham số mô phỏng như sau: kắch thước gói dữ liệu là 576 byte, sử dụng cơ chế hàng đợi active RED, tốc độ lấy mẫu sau mỗi 500 ms, kắch thước bộ đệm bằng băng thông nhân với độ trễ.. - Đánh giá theo tiêu chắ tăng thông lượng Để đánh giá tiêu chắ tăng thông lượng của MPTFRC, đầu tiên chúng tôi mô phỏng hai đường MPTFRC qua hai link như Hình 9(a), sau đó chúng tôi tiếp tục mô phỏng riêng biệt một luồng TFRC qua 1 link như Hình 9(b).. - Hình 9: Mô hình mạng đánh giá tiêu chắ tăng thông lượng. - Hình 10: Tăng thông lượng của MPTFRC. - Kết quả Hình 10 thấy rằng, thông lượng tổng hai đường của MPTFRC là gần gấp đôi so với TFRC đơn đường, tăng thông lượng đạt được như trong thuật toán điều khiển tắc nghẽn giao thức truyền đa đường. - Việc tăng thông lượng của MPTFRC so với TFRC đơn đường phụ thuộc vào số lượng Subflow trong một kết nối MPTFRC.. - Hình 12: Thông lượng chia sẻ công bằng giữa MPTFRC với TFRC. - Thông lượng hai đường MPTFRC chỉ bằng gần một nửa so với thông lượng trên đường TFRC. - nên đưa vào công thức (1) thì tốc độ trên mỗi đường sẽ. - Hình 13: Thông lượng chia sẻ công bằng giữa MPTFRC với TCP Reno. - Tổng thông lượng của hai đường MPTFRC gần bằng với thông lượng trên đường TFRC đơn đường, cũng như TCP đơn đường (Hình 13) cùng cạnh tranh qua một link. - Trong đó path 1 cạnh tranh với đường TFRC, có n= 20 luồng qua link 1, tốc độ C 1 = 15 Mbps, độ trễ D 1 = 10 ms. - path 2 cạnh tranh với một đường TFRC qua link 2 có m= 12 luồng, tốc độ C 2 = 15 Mbps, độ trễ D 2 = 30 ms. - Tỉ lệ mất gói tin đo được trên hai đường cụ thể như sau:. - Bảng 1: Tỉ lệ mất gói tin. - Vì tỉ lệ mất gói tin >. - tức là luồng MPTFRC chỉ tập trung truyền thông lượng vào path 2 là chắnh, để đạt được tiêu chắ tăng thông lượng, MPTFRC gửi càng nhiều càng tốt trên path 2 trong khi tốc độ truyền dữ liệu trên path 1 gần như bằng không, nhưng tổng thông lượng của MPTFRC xấp xỉ thông lượng đường tốt nhất trên TFRC (Single-path TFRC2) trong Hình 15.. - Hình 15: Thông lượng cân bằng tắc nghẽn giữa MPTFRC và TFRC. - Đánh giá theo tiêu chắ sự mượt của tốc độ truyền. - Một trong những mục tiêu quan trọng trong thiết kế giao thức cho các ứng dụng multimedia là sự mượt của tốc độ truyền dữ liệu. - Đánh giá tốc độ mượt của dữ liệu truyền sử dụng mô hình mạng Hình 16.. - Hình 16: Mô hình mạng mô phỏng sự mượt của tốc độ truyền. - Hình 17: Tốc độ dữ liệu truyền mượt của MPTCP. - Sự mượt của tốc độ truyền dữ liệu của hai đường MPTCP có sự dao động lớn như Hình 17, tốc độ truyền dữ liệu liên tục thay đổi. - Vì trong MPTCP, thuật toán điều chỉnh tốc độ trong giai đoạn giảm tương tự như TCP nên tốc độ có sự dao động lớn.. - Ngược lại, sự mượt của tốc độ truyền dữ liệu của hai đường MPTFRC như Hình 18, thông lượng tăng chậm hơn so với MPTCP, tuy nhiên tốc độ truyền trong MPTFRC ắt thay đổi, biên độ thay đổi nhỏ. - Do MPTFRC thay đổi tốc độ dựa vào công thức (như TFRC).. - Hình 18: Tốc độ dữ liệu truyền mượt của MPTFRC. - Tiếp theo, chúng tôi mô phỏng so sánh tốc độ truyền dữ liệu mượt của hai đường MPTFRC và hai đường MPTCP song song đều qua hai link:. - link 1 và link 2 có độ trễ D= 40 ms và tốc độ C= 4 Mbps như Hình 19.. - Hình 19: Mô hình mạng mô phỏng tốc độ dữ liệu truyền mượt của hai đường MPTFRC và. - Hình 20: Tốc độ dữ liệu truyền mượt của hai đường MPTFRC và hai đường MPTCP. - Kết quả Hình 20 cho thấy rằng, tốc độ truyền dữ liệu của hai đường MPTCP và MPTFRC qua hai link song song gần như tương đương. - Tuy nhiên, thay đổi tốc độ trên MPTFRC tương đối chậm, tốc độ thay đổi giữa hai lần liên tiếp không lớn. - Cụ thể xem xét thời gian từ giây 100 đến giây 150, biên độ dao động tốc độ của MPTCP lớn hơn so với MPTFRC. - Cải tiến giao thức bao gồm xác định trọng số động nhằm điều chỉnh thông lượng gửi dữ liệu giữa các đường trong nhiều điều kiện mạng khác nhau. - (iv) tốc độ dữ liệu truyền mượt.. - Để sử dụng đường truyền không bị đánh võng giữa các đường được thực hiện bằng cách tắnh tham số tránh đánh võng giữa các đường dựa trên đường có kắch thước cửa sổ lớn nhất và đường tốt nhất trong quá trình truyền dữ liệu