báo cáo bài tập lớn đề tài opportunistic mobility with multipath tcp

GIỚI THIỆU Việc các thiết b ị di động như điện thoại thông minh và máy tính bảng được trang b ịnhiều sóng như WiFi, 3G và Bluetooth đã trở thành điều thông thường.. Mỗi công ngh sóng có

Mụ ụụụục l c l c l c ụụụụụ c

TÓM T

TÓM TẮẮẮT ẮT T 3 3

1

1 GIGIGI I THIỚI THIỆỆỆỆỆU U U 3 3 2.KI

2.KIẾN TRÚC MPTCP ẾN TRÚC MPTCP ẾN TRÚC MPTCP DI ĐỘDI ĐỘNG DI ĐỘNG NG 5 5 2

2.1.1.1.ClClClieieientntnt-S-S-Sererervvvvvererer O Ope Operrrrratipeatiationonon 6 6 2

2.2 2 2 MPMPTCMPTCTCP P P PrPrProooxixixieseses 8 8 8 2

2.2.2.2.1 1 1 MPMPMPTCTCTCP P PPP PProProroxyxyxy f f funununctctctioioionananalililililityty 9ty 9 9 2

2.3 3 3 PePePeererer-t-t-to-o-o-pepepeeeeeer r r OpOperOpereratatatioioion n n 1 10 10

TÓM T T Ắ

Tính di động c a máy ch ủ ủ đã được giải quy t truy n th ng ế ề ố ở t ng mầ ạng, nhưng mặc

dù Mobile IP đã được chuẩn hóa trong 15 năm, nhưng vẫn chưa được h tr bỗ ợ ởi các nhà điều hành Vai trò kép của IP như một định danh v ịtrí và định danh điểm giao ti p mang ế

đến nhi u về ấn đề ề v chức năng và hiệu su t ấ

Chúng tôi cho rằng nơi tốt nhất để xử lý tính di động là t ng giao v n Mở ầ ậ ặc dù đây không ph i là m t l p lu n m i, chúng tôi tin r ng tiêu chuả ộ ậ ậ ớ ằ ẩn m i n i c a Multipath ớ ổ ủTCP (MPTCP) có thể được s dử ụng để ả gi i quy t nhi u vế ề ấn đề liên quan đến tính di động MPTCP t nhiên triự ển khai cơ chế "make-before-break" (tạo trước trước khi phá vỡ), có th tri n khai tể ể ừng bước, tương thích ngược v i TCP tiêu chu n và th m chí có ớ ẩ ậthể giúp đơn giản hoá quá trình áp d ng IPv6 theo t ng ph n ụ ừ ầ

Sử dụng mô phỏng và thực nghi m trong nhà v i WiFi và 3G, chúng tôi cho th y ệ ớ ấMPTCP cung cấp thông lượng tốt hơn, đạt được vi c chuyệ ển giao mượt mà hơn và có thể được điều chỉnh để tiết kiệm năng lượng hơn

1 GIỚI THIỆU

Việc các thiết b ị di động như điện thoại thông minh và máy tính bảng được trang b ịnhiều sóng như WiFi, 3G và Bluetooth đã trở thành điều thông thường Với sự tích hợp ngày càng tăng và sóng vô tuyến được định nghĩa bằng phần mềm, chúng ta d kiự ến xu hướng này sẽ ti p tế ục và các thi t b s h tr nhi u công ngh sóng vô tuyế ị ẽ ỗ ợ ề ệ ến hơn Mỗi công ngh sóng có nhệ ững ưu điểm và nhược điểm riêng; 3G cung c p ph m vi ph sóng ấ ạ ủphổ biến hơn, nhưng ở các thành ph lố ớn thường g p tình tr ng t c nghặ ạ ắ ẽn đủ độ để gần như không thể sử dụng; WiFi cung cấp tốc độ truyền dữ liệu cao, nhưng phạm vi ph ủsóng không đồng đều và đố ới người dùng di động thười v ng là tạm thời Làm thế nào chúng ta có th t n d ng t t nh t t t c các k t n i sóng vô tuy n có sể ậ ụ ố ấ ấ ả ế ố ế ẵn, nhằm có được phạm vi phủ sóng và thông lượng tốt nh t, và s dấ ử ụng ít năng lượng pin nh t trong quá ấtrình đó?

Các gi i pháp truy n thả ề ống thường là thô sơ; điện thoại thông minh thông thường kết n i thông qua mố ột m ng m t lúc s d ng m t chính sách c ạ ộ ử ụ ộ ố định như "sử d ng WiFi ụnếu có s n, n u không thì s d ng 3G" Khi m ng WiFi và 3G cung c p m i mẵ ế ử ụ ạ ấ ỗ ột địa chỉ

IP, vi c chuyệ ển đổi gi a hai mữ ạng này gây gián đoạn, đòi hỏi các ứng dụng phải thiết lập lại k t nế ối Các chính sách đơn g ản như vậi y hoạt động t t nố ếu người dùng không di động Khi đang ở trên xe lửa hoặc ô tô, kết nối WiFi là t m thạ ời - thường có k t n i t t ế ố ốnhưng chỉ trong vài giây [7] Các chính sách như vậy quá gây gián đoạn để sử dụng khi kết n i (ho c m t k t n i) là tố ặ ấ ế ố ạm th i ờ

Mobile IP [1] lý thuy t có th ế ể được s dử ụng để chuy n ti p m t k t nể ế ộ ế ối đang diễn ra

từ m t m ng sang m ng khác Tuy nhiên, ngay c ộ ạ ạ ả sau 15 năm kể t ừ khi Mobile IP được chuẩn hóa, nó vẫn ít được triển khai đến mức không đủ cho các nhà cung cấp điện tho i ạ

thông minh s dử ụng Hơn nữa, do tính ch t c a nó là mấ ủ ột giao th c t ng IP, Mobile IP ứ ầkhông có thông tin c n thiầ ết để hoạt động tối ưu trong các sự ki n di chuy n make-ệ ểbefore-break Đặc biệt, mà không cần viết l i TCP, Mobile IP không th chia d li u ạ ể ữ ệthành các "care-of" addresses khác nhau cho cùng m t k t nộ ế ối TCP vì các RTT và băng thông khác nhau s làm r i lo n TCP và ẽ ố ạ ảnh hưởng nghiêm trọng đến hi u su t ệ ấMột mô hình di động lý tưởng không ch là make-before-break (dỉ ễ dàng đạt được với nhi u sóng vô tuyề ến), mà còn duy trì hơn một liên k t hoế ạt động trong th i gian có ờthể Vì vậy, m t tộ ải xuống đang tiến hành qua 3G trong khi trên xe lửa sẽ không được chuyển sang WiFi, mà s ti p t c trên 3G và thêm kh ẽ ế ụ ả năng tải xu ng b sung qua WiFi ố ổkhi có th M c tiêu không ph i là th c hi n chuy n ti p nhanh, mà là th c hi n chuy n ể ụ ả ự ệ ể ế ự ệ ểtiếp ch m nhậ ất có thể khi c hai liên kả ết v n có th s dẫ ể ử ụng Để làm được điều đó, giải pháp di động phải có thông tin về các đường đi khả dụng khác nhau, chẳng hạn thông tin RTT và t c ngh n Nh ng quan sát này dắ ẽ ữ ẫn chúng tôi đến k t lu n r ng lế ậ ằ ớp IP không phải là vị trí đúng trong ngăn xếp để hỗ trợ tính di động; th c t , l p vự ế ớ ận chuy n là l p ể ớthấp nhất có đủ thông tin để hoạt động tốt

Multipath TCP [5], hiện đang được chu n hóa trong IETF, có thẩ ể là cơ chế để kích hoạt mô hình di động như vậy MPTCP là m t t p h p các ti n ích m r ng cho TCP ộ ậ ợ ệ ở ộcho phép cặp máy chủ thương lượng vi c s dệ ử ụng MPTCP, và sau đó thiế ật l p nhiều luồng phụ song song s d ng nhiử ụ ều địa ch IP cho mỉ ộ ết k t nối duy nh t M i lu ng ph ấ ỗ ồ ụthực hi n ki m soát t c ngh n riêng c a nó, và dệ ể ắ ẽ ủ ữ liệu được chia thành các lu ng phồ ụ phù h p vợ ới băng thông có sẵn trên mỗi đường đi

Trong k ch bị ản di động, mộ ế ốt k t n i MPTCP có th ể được thiế ật l p thông qua b t k ấ ỳgiao di n mệ ạng và a chđị ỉ IP nào đang hoạt động Sau đó, nếu có thể kết nối bằng cách

sử d ng giao di n mụ ệ ạng và địa ch IP khác, m t lu ng ph th hai sỉ ộ ồ ụ ứ ẽ được thi t lế ập, và

dữ liệu hi n tệ ại có thể được truy n qua c hai lu ng phề ả ồ ụ Sau đó, nếu m t k t n i cho ấ ế ốmột luồng ph , lu ng ph còn l i có th ti p tụ ồ ụ ạ ể ế ục mà không bị gián đoạn

Nếu máy ch t xa không h tr ủ ừ ỗ ợ MPTCP, điều này có th x y ra ể ả ở giai đoạn đầu của triển khai, proxy MPTCP s tham gia vào quá trình Proxy MPTCP là mẽ ột điểm neo c ố

định liên k t với máy chủ di độế ng, hỗ trợ MPTCP Khi máy chủ di động truy n thông ềvới máy ch t xa không h trủ ừ ỗ ợ MPTCP, máy ch ủ di động thi t l p m t k t n i MPTCP ế ậ ộ ế ốvới proxy, sau đó proxy thiết lập m t k t nộ ế ối TCP thông thường v i máy ch tớ ủ ừ xa cũ Khả năng di động c a máy ch ủ ủ di động được h tr thông qua k t n i MPTCP v i proxy, ỗ ợ ế ố ớnhư trong trường hợp trước đó Proxy cũng hỗ trợ sự di chuyển đồng thời

Có các k ch b n bị ả ổ sung đòi hỏi các cơ chế ổ sung, đặ b c bi t là h tr cho các k t ệ ỗ ợ ếnối không ph i TCP và cho các kả ết n i TCP n thi t bố đế ế ị di động Dynamic DNS có th ểđược s dử ụng để kích ho t kạ ết nối đến thi t bế ị di động, nhưng trong thế gi i IPv4, các ớthiết bị di động hầu như luôn đứng sau NAT Do đó, trường hợp cấp thiết cho các kết

nối đến là thực sự cho các ứng dụng ngang hàng (peer-to-peer), và chúng thông thường bao g m mồ ột cơ chế ẹ h n g p ngoài kênh (out-of-band rendezvous) ti p theo là vi c m ặ ế ệ ởđồng th i t c ờ ừ ả hai đầu Chúng tôi s th o lu n v ẽ ả ậ ề điều này chi tiết hơn sau Trường hợp không ph i TCP chính cả ần xem xét là cho lưu lượng truy n thông th i gian thề ờ ực như VoIP Hiện nay, IETF đang tiêu chuẩn hóa các ph n m r ng multipath cho RTP [10] ầ ở ộ

để ự th c hiện vai trò tương tự như MPTCP đối với các kết n i TCP Trong các ph n sau, ố ầchúng tôi mô t các k ch b n khác nhau và các chi ti t cả ị ả ế ủa các thành ph n khác nhau c a ầ ủkiến trúc được đề xu t ấ

2.1.Client-Server Operation

Kịch bản đơn giản nhất và trong tương lai có lẽ là ph bi n nh t là truyổ ế ấ ền thông được khởi t o bạ ởi m t máy ch ộ ủ di động MPTCP v i m t máy ch t xa h tr MPTCP Trong ớ ộ ủ ừ ỗ ợtrường h p này, truy n thông tr c ti p di n ra gi a máy ch ợ ề ự ế ễ ữ ủ di động và máy chủ từ xa Một k t nế ối được kh i t o b ng cách máy ch ở ạ ằ ủ di động th c hiự ện bước b t tay TCP 3 ắbước v i máy ch t xa M t tùy ch n TCP trong các tín hi u SYN và SYN / ACK cho ớ ủ ừ ộ ọ ệbiết kh ả năng MPTCP của các đầu cuối cũng như các thông tin MPTCP liên quan khác Khi k t nế ối MPTCP được thi t l p, có hai s kiế ậ ự ện di động cơ bản có th x y ra: m t giao ể ả ộdiện mới có sẵn ho c m t giao di n hi n có ngặ ộ ệ ệ ừng hoạt động

Khi m t giao di n m i có sộ ệ ớ ẵn và địa chỉ IP được thu được, n u vi c s dế ệ ử ụng được cho phép b i chính sách c a máy ch , máy ch ở ủ ủ ủ di động thêm địa chỉ IP m i vào k t n i ớ ế ốMPTCP đã thiế ập Để làm điềt l u này, nó thực hiện một bước bắt tay TCP 3 bước m i ớ

sử dụng địa ch IP mỉ ới làm địa ch ngu n Trong quá trình b t tay này, k t n i m i này ỉ ồ ắ ế ố ớđược xác định là một luồng con c a k t nủ ế ối đang diễn ra

Điểm này, k t n i MPTCP có hai subflow s dế ố ử ụng địa chỉ IP ban đầu và địa ch IP ỉmới c a mobile host M i subflow chủ ỗ ạy cơ chế điều khi n t c ngh n riêng cể ắ ẽ ủa nó, nhưng chúng được kết nối Một c a s t c nghử ổ ắ ẽn riêng được duy trì cho m i subflow và m i ỗ ỗsubflow th c hi n khự ệ ởi động ch m Tuy nhiên, trong chậ ế độ tránh t c nghắ ẽn, tăng của

cửa sổ liên quan đế ổn t ng c a t t c các c a s tủ ấ ả ử ổ ắc ngh n c a t t c các subflow M t ẽ ủ ấ ả ộsubflow t c nghắ ẽn tăng cửa s c a nó chổ ủ ậm hơn một subflow không b t c ngh n, cho ị ắ ẽphép MPTCP di chuy n d li u kh i t c ngh n và cho phép tể ữ ệ ỏ ắ ẽ ối ưu hóa sử d ng tài nguyên ụmạng như được mô t trong [?] Trong mả ọi trường h p, vi c qu n lý rõ ràng các subflow ợ ệ ảkhác nhau và c a s t c nghử ổ ắ ẽn tương ứng c a chúng cho phép MPTCP theo dõi d li u ủ ữ ệtrao đổi thông qua từng giao diện và thực hiện điều khiển dòng dữ liệu, điều khiển tắc nghẽn, phát hiện l i và truyỗ ền lại dữ liệu tương ứng Một số thứ tự cấp kết nối bổ sung được mang trong các gói d liữ ệu b ng cách s dằ ử ụng các tùy chọn TCP, cho phép bên nhận x lý nh ử ẹ nhàng các trường h p s p xợ ắ ếp l i và giao d liạ ữ ệu đến ứng dụng theo đúng thứ t Chi tiự ết hơn về hoạt động subflow của MPTCP được trình bày trong [5] N u m t ế ộgiao di n trên mobile host b ng t k t n i, t t c ệ ị ắ ế ố ấ ả các subflow liên quan đến giao diện đó

sẽ d ng truy n d li u B t k subflow nào khác ti p từ ề ữ ệ ấ ỳ ế ục trao đổi d li u và sữ ệ ẽ truy n l i ề ạbất k d li u b thiỳ ữ ệ ị ếu đang trong quá trình truyền trên các subflow bị lỗi N u không có ếgiao di n nào khác kh d ng, mobile host sệ ả ụ ẽ đợi cho đến khi m t giao di n m i xu t ộ ệ ớ ấhiện, sau đó khởi tạo một subflow mới trên k t nế ối MPTCP, như đã mô tả trước đó, và tiếp tục trao đổi d li u ữ ệ

Make-before-break handoff là vi c mobile host l y m t interface/IP address m i khi ệ ấ ộ ớinterface/IP address hi n t i vệ ạ ẫn đang hoạt động, sau đó mới tách khỏi địa chỉ ban đầu Với MPTCP, mobile host thêm m t subflow m i vào k t n i MPTCP hi n tộ ớ ế ố ệ ại b ng cách ằ

sử dụng địa ch IP mỉ ới và trao đổi dữ liệu qua cả hai subflow Khi interface đầu tiên ngừng hoạt động, dữ liệu không được gửi qua subflow ban đầu nữa

Break-before-make handoff là khi t t c ấ ả các subflow đang sử ụ d ng m t interface c ộ ụthể, và interface đó ngừng kết nối với Internet Kết n i MPTCP v n mố ẫ ở, nhưng bị đình trệ Sau đó, một địa ch IP m i tr nên kh dỉ ớ ở ả ụng cho mobile host, khi đó nó sử ụng đị d a chỉ mới này để thi t l p m t subflow m i c a k t n i MPTCP hi n tế ậ ộ ớ ủ ế ố ệ ại D liữ ệu được trao đổi qua subflow mới

Nếu remote host h tr MPTCP thỗ ợ ì đây là một giải pháp di động hoàn ch nh Trong ỉtương lai, chúng ta kỳ vọng tất cả các hệ điều hành chính sẽ hỗ trợ MPTCP Đặc biệt là

sự sử d ng cao c a MPTCP t các máy chụ ủ ừ ủ được mong đợi do lợi ích đáng kể mà MPTCP cung c p cho trung tâm d li u Tuy nhấ ữ ệ iên, trong khi đó, ít máy chủ ẽ ỗ ợ s h trMPTCP Để cho phép di động, cần một giải pháp proxy

2.2 MPTCP Proxies

Mobile host có thể được c u hình vấ ới địa ch IP c a m t máy ch proxy MPTCP ỉ ủ ộ ủTrong th c t , các nhà cung c p Internet không dây có th cung c p d ch v proxy và ự ế ấ ể ấ ị ụthông báo điều này thông qua DHCP Sau đó, máy chủ proxy sẽ kết nối với máy chủ từ

xa và thiết l p kậ ết nối TCP, sau đó trở thành m t tr m chuy n tiộ ạ ể ếp ch passive cho d ữliệu Mobile host sau đó có thể khởi t o các subflow b ạ ổ sung đến máy ch ủ proxy như đã

mô tả trước đó trong trường h p máy ch t xa h tr MPTCP Proxy s phân chia d ợ ủ ừ ỗ ợ ẽ ữliệu cho mobile host qua các subflow

Có một số điểm chính cần lưu ý về ệ ử ụng proxy này Đầu tiên, proxy không vi c s dquan tâm đến ứng dụng là gì Tương tự, ứng dụng TCP trên c mobile host và remote ảhost đều không nhận thức đượ ự ồ ạ ủc s t n t i c a proxy - t t c các yêu cấ ả ầu đều được x lý ửbởi ngăn xếp MPTCP c a mobile host Cu i cùng, proxy s c gủ ố ẽ ố ắng th a thu n MPTCP ỏ ậvới remote host N u remote host này thế ực s h tr MPTCP, proxy sự ỗ ợ ẽ thông báo địa chỉ IP của remote host cho mobile host để ử d s ụng làm địa ch b sung cho MPTCP ỉ ổMobile host sau đó có thể thiết l p m t subfow mậ ộ ới tr c tiự ếp đến remote host, th ảsubflow đang được proxy chuy n ti p và lo i b proxy kh i kể ế ạ ỏ ỏ ết nối Do đó, khi các máy chủ t xa ngày càng h trừ ỗ ợ MPTCP, rất ít lưu lượng d liữ ệu được chuy n ti p b i proxy ể ế ở

Trường hợp 1: Máy chủ t xa hỗ trợ MPTCP N u máy chủ t xa đã đàm phán ừ ế ừMPTCP, proxy hoạt động như một kênh truy n c p gói N u máy chề ấ ế ủ di động khởi t o ạmột lu ng ph mồ ụ ới, proxy chuy n ti p yêu c u lu ng ph ể ế ầ ồ ụ đến máy chủ t ừ xa Do đó, có

một mối tương ứng một-một giữa các luồng ph tụ ừ máy chủ di động đến proxy và từ proxy đến máy ch tủ ừ xa Điều này cho phép proxy ch ỉ đơn giản chuy n ti p các gói tin ể ế

mà không cần đưa chúng vào hàng đợi, và cho phép ki m soát t c ngh n và tái truyể ắ ẽ ền hoạt động từ đầu đến cuối

Trường hợp 2: Máy chủ cũ Nếu máy chủ t chối đàm phán MPTCP, thì không thể ừ

có b t k luấ ỳ ồng phụ nào tránh được proxy Điều này đơn giản hóa tình huống, nhưng

đồng th i yêu c u proxy hoờ ầ ạt động như một proxy đầy đủ thay vì một trạm chuyển tiếp gói tin Proxy duy trì c a s t c ngh n riêng c a mình khi gử ổ ắ ẽ ủ ửi đến máy chủ t xa và cho ừmỗi luồng phụ đến thiết bị di động Các gói tin t thi t bừ ế ị di động đến máy ch t xa ủ ừphải được lắp ráp lại theo thứ tự trước khi được gửi đến máy ch t xa Các gói tin t ủ ừ ừmáy chủ t ừ xa đến thi t bế ị di động không cần đượ ắp ráp l i theo th t - chúng có thc l ạ ứ ự ể đơn gi n ch ả ỉ được chuy n ti p vào b t k lu ng ph ể ế ấ ỳ ồ ụ nào đang có chỗ trống trong c a s ử ổtắc ngh n c a nó Các s th t ẽ ủ ố ứ ự được cung c p b i máy ch t xa tr thành s th t d ấ ở ủ ừ ở ố ứ ự ữliệu MPTCP, và các s thố ứ tự luồng ph b sung theo dõi t c ngh n và tái truy n trên ụ ổ ắ ẽ ềmỗi luồng ph ụ

2.3 Peer-to-peer Operation

Hoạt động ngang hàng (peer-to-peer) trên các thiết bị di động gặp ph i hai y u t ả ế ốphức tạp: NAT thường ngăn cản k t nế ối tr c tiự ếp và di động đồng th i có th khiờ ể ến các thiết b ị đồng th i mờ ất liên l c Tr ng thái hi n t i c a các k thu t NAT traversal ngang ạ ạ ệ ạ ủ ỹ ậhàng t t nh t là ICE [?], s d ng k t h p gi a ki m tra hành vi NAT và các k thu t ố ấ ử ụ ế ợ ữ ể ỹ ậproxy để cho phép thiết lập kết n i khi cố ả hai đầu cuối đều đang đằng sau NAT Tuy nhiên, trong nhiều trường h p, vi c thiợ ệ ết l p k t n i không th th c hi n mà không có ậ ế ố ể ự ệproxy, vì nhi u NAT không cho phép m ề ở đồng thời TCP Để kích hoạt tính di động v i ớMPTCP, vi c s dệ ử ụng các proxy MPTCP cũng là điều mong mu n Không ch cho phép ố ỉNAT traversal, mà nó cung c p ít nh t m t subfow v i a ch ấ ấ ộ ớ đị ỉ ổn định (tuy nhiên là địa chỉ được proxy) để tránh vấn đề của di động đồng th i Khi giao di n c a m t thi t b di ờ ệ ủ ộ ế ịđộng được kích hoạt, một subfow mới có thể được thiết lập từ địa chỉ mới đến proxy, cho phép s d ng giao diử ụ ện đó ngay lập tức Đồng th i, máy ch có th th c hiờ ủ ể ự ện các k ỹthuật ICE, c g ng thi t l p mố ắ ế ậ ột đường tr c ti p gi a các máy ch cuự ế ữ ủ ối, tránh đường dài qua proxy

3 ĐÁNH GIÁ

Bất k viể ệc có sử dụng m t proxy hay không, lộ ợi ích của MPTCP đố ới v i các thi t ế

bị di động nằm ở khả năng chồng chéo sử dụng nhi u sóng vô tuy n ề ế

Nếu tính di động được che giấu sau một địa chỉ IP duy nhất, như trong trường hợp của Mobile IP, thì máy chủ di động phải đối m t v i s l a ch n t t c ho c không có ặ ớ ự ự ọ ấ ả ặ

gì để chuyển sang m t liên k t vô tuy n khác N u k t nộ ế ế ế ế ối được xem như một trạng thái nhị phân, thì điều này sẽ hợp lý Ta có thể tối ưu hóa hiệu suất, chi phí, tiêu thụ năng lượng hoặc m t s chộ ố ức năng của cả ba yếu t này, d a trên hi u su t liên k t d ố ự ệ ấ ế ự đoán Rất ti c, k t n i trên các mế ế ố ạng không dây không ph i là nh phân - ả ị ở đây chúng ta xem xét 3G và WiFi Điều chúng ta thực s mu n là kh o sát liên kự ố ả ết WiFi mà không

từ b liên k t 3G ỏ ế

Rõ ràng lưu lượng truy cập thăm dò tốt nhất là lưu lượng d liữ ệu th c s mong mu n; ự ự ốkhi nó được nhận, điều này làm tăng khả năng chuyển dữ liệu tốt; khi nó không được nhận, có th gể ửi lại trên liên k t 3G MPTCP cung c p chính xác kh ế ấ ả năng này

Hình 1: So sánh giữa MPTCP và chiến lược đường đi đơn tối ưu của TCP; thực nghiệm di động trong nhà sử dụng laptop với kết nối WiFi và 3G

Khi có nhiều hơn một luồng con được thi t l p, MPTCP ph i quyế ậ ả ết định xem có s ửdụng một liên k t duy nhế ất hay nhi u liên k t cùng m t lúc N u hi u su t t i xu ng là ề ế ộ ế ệ ấ ả ố