Giao thức điều khiển tắt nghẽn đa đường tiết kiệm năng lượng

HỌC VIỆN CÔNG NGHỆ BƢU CHÍNH VIỄN THÔNG
---------------------------------------

PHẠM THỊ MỸ LINH

GIAO THỨC ĐIỀU KHIỂN TẮC NGHẼN ĐA ĐƢỜNG
TIẾT KIỆM NĂNG LƢỢNG

LUẬN VĂN THẠC SĨ KỸ THUẬT

TP. HỒ CHÍ MINH - 2016


HỌC VIỆN CÔNG NGHỆ BƢU CHÍNH VIỄN THÔNG
---------------------------------------

PHẠM THỊ MỸ LINH

GIAO THỨC ĐIỀU KHIỂN TẮC NGHẼN ĐA ĐƢỜNG
TIẾT KIỆM NĂNG LƢỢNG
CHUYÊN NGÀNH : HỆ THỐNG THÔNG TIN
MÃ SỐ:

0

60.48.01.04

LUẬN VĂN THẠC SĨ KỸ THUẬT

NGƢỜI HƢỚNG DẪN KHOA HỌC: TS. VÕ THỊ LƢU PHƢƠNG

TP. HỒ CHÍ MINH - 2016


i

LỜI CAM ĐOAN
Tôi cam đoan đây là công trình nghiên cứu của riêng tôi.
Các số liệu, kết quả nêu trong luận văn là trung thực và chƣa từng đƣợc ai
công bố trong bất cứ công trình nào.

Hồ Chí Minh, ngày 15 tháng 06 năm 2016
Học viên thực hiện luận văn

Phạm Thị Mỹ Linh


ii

LỜI CẢM ƠN
Trong suốt thời gian học tập tại trƣờng, em đ nhận đƣợc rất nhiều sự quan
tâm, gi p đ của qu Thầy Cô Khoa sau đại học Học viện Công nghệ

ƣu chính

Vi n Thông Cơ sở TP. Hồ Chí Minh. Xin chân thành cảm ơn qu Thầy Cô đ giảng
dạy, truyền đạt những kiến thức chuyên môn và luôn tạo mọi điều kiện tốt nhất cho
chúng em trong quá trình theo học.
Với lòng biết ơn sâu sắc nhất em xin gửi lời cảm ơn tới TS. Võ Thị Lƣu
Phƣơng, Khoa Công nghệ Thông tin – Trƣờng Đại Học Quốc Tế - Đại Học Quốc
Gia TP. Hồ Chí Minh, là giáo viên trực tiếp hƣớng dẫn khoa học cho em. Cô đ

dành nhiều thời gian hƣớng dẫn em cách nghiên cứu, đọc tài liệu, cài đặt các thuật
toán và gi p đ em trong việc xây dựng chƣơng trình, em xin chân thành cảm ơn
Cô!
Và cuối cùng em xin bày tỏ lòng chân thành và biết ơn tới l nh đạo khoa
Công nghệ Thông tin – Học viện

ƣu chính Vi n Thông Cơ sở TP. Hồ Chí Minh

cùng bạn bè đồng nghiệp đ luôn ở bên cạnh những l c em khó khăn và tạo điều
kiện thuận lợi gi p em hoàn thành luận văn.

Hồ Chí Minh, ngày 15 tháng 06 năm 2016
Học viên thực hiện luận văn

Phạm Thị Mỹ Linh


iii

MỤC LỤC
LỜI CAM ĐOAN ....................................................................................................... i
LỜI CẢM ƠN................ ............................................................................................ ii
DANH MỤC CÁC THUẬT NGỮ, CHỮ VIẾT TẮT ................................................v
DANH SÁCH HÌNH VẼ ......................................................................................... vii
MỞ ĐẦU.................................................. ...................................................................1
Chƣơng 1 - CƠ SỞ LÝ LUẬN ...................................................................................3
1.1 Giới thiệu về giao thức điều khiển tắc nghẽn đa đƣờng ................................3
1.2

Lợi ích, mục tiêu của giao thức điều khiển tắc nghẽn đa đƣờng ...................4

1.2.1 Lợi ích......................................................................................................4
1.2.2 Mục tiêu ...................................................................................................4
1.3

Mô hình phân chia chức năng ........................................................................6

1.4

Hoạt động của giao thức điều khiển tắc nghẽn đa đƣờng ..............................8

1.4.1 Một số khái niệm .....................................................................................8
1.4.2 Khởi tạo một kết nối MPTCP ..................................................................9
1.4.3 Khởi tạo một luồng con mới với kết nối đa đƣờng hiện tại ..................11
1.4.4 Truyền dữ liệu trong MPTCP ................................................................12
1.4.5 Quản l đƣờng dẫn ................................................................................18
1.4.6 Đóng một kết nối MPTCP .....................................................................21
1.5

Thách thức về năng lƣợng trong MPTCP ....................................................22

1.6

Kết luận chƣơng 1 ........................................................................................22

Chƣơng 2 - CÁC GIAO THỨC ĐIỀU KHIỂN TẮC NGHẼN CÓ TIẾT KIỆM
NĂNG LƢỢNG HIỆN TẠI ......................................................................................23
2.1 Vấn đề tắc nghẽn trong mạng ......................................................................23
2.1.1 Nguyên nhân gây ra tắt nghẽn ...............................................................23
2.1.2 Khái niệm điều khiển tắc nghẽn ............................................................23

2.1.3 Tiêu chí đánh giá thuật toán ..................................................................23
2.2 Thuật toán điều khiển tắc nghẽn trong giao thức điều khiển tắc nghẽn đa
đƣờng.....................................................................................................................24
2.2.1 Thuật toán MPTCP ................................................................................24
2.2.2 Thuật toán mReno .................................................................................25
2.3 Thuật toán điều khiển tắc nghẽn trong giao thức điều khiển tắc nghẽn đa
đƣờng có tiết kiệm năng lƣợng .............................................................................26


iv

2.3.1 Các công việc liên quan.........................................................................26
2.3.2 Hiệu quả năng lƣợng của giao thức điều khiển tắc nghẽn đa đƣờng cho
thiết bị di động ..................................................................................................28
2.3.3 Thuật toán ecMTCP ..............................................................................30
2.4

Kết luận chƣơng 2 ........................................................................................31

Chƣơng 3 - ĐỀ XUẤT GIAO THỨC ĐIỀU KHIỂN TẮC NGHẼN ĐA ĐƢỜNG
TIẾT KIỆM NĂNG LƢỢNG ...................................................................................32
3.1

Mô hình năng lƣợng .....................................................................................32

3.2

Mô hình thiết kế ...........................................................................................33

3.3

Giao thức emReno 1 ....................................................................................34

3.4

Giao thức emReno 2 ....................................................................................35

3.5

Kết luận chƣơng 3 ........................................................................................36

Chƣơng 4 - KẾT QUẢ THỰC NGHIỆM .................................................................37
4.1 Giới thiệu phần mềm NS-2 ..........................................................................37
4.2

Thực hiện mô phỏng ....................................................................................37

4.2.1 Thông lƣợng ..........................................................................................38
4.2.2 Cân bằng tải ...........................................................................................39
4.2.3 Đánh võng và công bằng .......................................................................40
4.2.4 Hiệu quả năng lƣợng .............................................................................43
KẾT LUẬN VÀ KIẾN NGHỊ...................................................................................47
DANH MỤC TÀI LIỆU THAM KHẢO ..................................................................48


v

DANH MỤC CÁC THUẬT NGỮ, CHỮ VIẾT TẮT
Viết tắt

Tiếng Anh

Tiếng Việt

Transmission Control Protocol/

Giao thức điều khiển truyền

Internet protocol

dẫn/ giao thức Internet

Multipath Transmission Control

Giao thức điều khiển truyền

Protocol

dẫn đa đƣờng

IETF

Internet Engineering Task Force

Nhóm quản l kỹ thuật Internet

NAT

Network address translation

TNG

Transport next-generation

Tầng vận chuyển thế hệ mới

API

Application Programming Interface

Giao diện lập trình ứng dụng

NS2

Network Simulator

Công cụ mô phỏng mạng

SACK

Selective Acknowledgements

RTT

Round trip time

TCP/IP

MPTCP

iên dịch địa chỉ mạng

áo nhận có chọn lọc
Thời gian tr trọn vòng


vi

DANH SÁCH BẢNG
Bảng 4.1: Tốc độ trung bình (kbps) của các luồng con

38

Bảng 4.2: Môi trƣờng thiết lập mô phỏng

43


vii

DANH SÁCH HÌNH VẼ
Hình 1.1: So sánh mô hình TCP và mô hình của MPTCP

6

Hình 1.2: Kịch bản sử dụng MPTCP

8

Hình 1.3: Quá trình khởi tạo phiên đầu tiên của kết nối MPTCP

10

Hình 1.4: Bản tin Add Address

20

Hình 1.5: Bản tin Remove Address

20

Hình 3.1: Thiết bị di động với giao diện truy cập 4G, Wifi

33

Hình 4.1: Mô hình thiết kế

38

Hình 4.2: Cân bằng tải khi thay đổi tỉ lệ mất gói trên hai giao thức

40

Hình 4.3: Tình trạng đánh võng khi thay đổi ε trên emReno 1

41

Hình 4.4: Tình trạng đánh võng khi thay đổi ε trên emReno 2

42

Hình 4.5: Tiết kiệm năng lƣợng trên giao thức emReno 1

44

Hình 4.6: Tiết kiệm năng lƣợng trên giao thức emReno 2

44

Hình 4.7: So sánh tiết kiệm năng lƣợng giữa giao thức emReno 1 và emReno 2

45


1

MỞ ĐẦU
Internet phát triển từng ngày, việc sử dụng internet cũng tăng mạnh nhƣng
nguồn tài nguyên băng thông không đƣợc sử dụng một cách có hiệu quả. TCP hầu
nhƣ không thay đổi trong 20 năm mặc dù có nhiều sự thay đổi trong hạ tầng mạng
Internet, nhƣ hầu hết các thiết bị di động ngày nay đƣợc trang bị đa giao diện truy
cập 3G, 4G, Wifi… Tuy nhiên việc kết nối internet hiện nay đƣợc điều khiển bởi
TCP và TCP truyền thống vẫn sử dụng duy nhất một đƣờng dẫn để kết nối mạng.
Chính vì vậy nó không tận dụng đƣợc lợi thế của các thiết bị đầu cuối này, đồng
thời dẫn đến những hạn chế trong việc điều khiển tắc nghẽn và cân bằng tải. Nếu
các nguồn tài nguyên nhƣ băng thông có thể đƣợc sử dụng đồng thời, trải nghiệm
ngƣời dùng có thể đƣợc cải thiện rất nhiều. Những cải tiến nhƣ vậy cũng sẽ làm
giảm chi phí đầu tƣ cơ sở hạ tầng mạng.

ằng cách ứng dụng chia sẻ tài nguyên,

những tài nguyên sẵn có có thể đƣợc gộp lại nhƣ một nguồn tài nguyên duy nhất
dành cho ngƣời sử dụng.
Đ có nhiều giải pháp đƣợc đƣa ra, trong đó đáng ch

là giao thức điều

khiển tắc nghẽn đa đƣờng của tổ chức IETF đ và đang phát triển các phần mở rộng
đa đƣờng dẫn từ giao thức TCP, cho phép một cặp đầu cuối sử dụng nhiều đƣờng
dẫn để truyền các gói tin trên một kết nối duy nhất. Giao thức điều khiển tắc nghẽn
đa đƣờng hứa hẹn trong việc cung cấp các kết nối nhanh và đáng tin cậy hơn cho
các thiết bị di động bằng cách tận dụng sự đa dạng kết nối trong môi trƣờng năng
động.
Một mối quan tâm lớn của việc sử dụng giao thức điều khiển tắc nghẽn đa
đƣờng trong các thiết bị di động đó là yêu cầu năng lƣợng cao hơn cho việc duy trì
hoạt động đa giao diện. Phần lớn năng lƣợng của thiết bị điện thoại di động đƣợc
tiêu thụ trong truyền tải. Để tối đa hóa thời gian sống của pin, điều quan trọng là
phải nhận ra rằng chi phí năng lƣợng cho mỗi bit của mỗi đƣờng dẫn là khác nhau.
Trong một số thiết bị, Wifi thì tiết kiệm năng lƣợng cho phạm vi thông lƣợng thấp
trong khi 3G thì hiệu quả hơn nếu thông lƣợng cao. Tuy nhiên, ngay cả khi trên một
thiết bị có đa giao diện vật l mà có thể liên tục thay đổi kết nối, thì việc lập lịch


2

cho đa đƣờng dẫn là điều không đơn giản. Ngoài ra, khi chi phí năng lƣợng là tiêu
chí duy nhất để xác định đƣờng dẫn, dữ liệu đi qua đƣờng truyền sẽ bị suy giảm
đáng kể nếu đƣờng dẫn có hiệu quả năng lƣợng cũng là đƣờng dẫn tắc nghẽn nhất.
Vì vậy, việc thiết kế các giao thức truyền tải có sự cân bằng thông minh giữa hiệu
suất sử dụng băng thông và năng lƣợng tiêu thụ là điều cấp bách hiện nay.

Chính vì những yêu cầu cấp thiết trên, tôi xin chọn đề tài nghiên cứu “Giao
thức điều khiển tắc nghẽn đa đƣờng tiết kiệm năng lƣợng”
Luận văn gồm 4 chƣơng tập trung nghiên cứu những vấn đề sau: Chƣơng 1 Tổng quan về giao thức điều khiển tắc nghẽn đa đƣờng. Cung cấp cái nhìn tổng
quan về l thuyết giao thức điều khiển tắc nghẽn đa đƣờng trên các mục tiêu thiết kế
của giao thức này, mô hình kiến tr c chung, cách thức hoạt động cũng nhƣ điều
khiển tắc nghẽn trên giao thức điều khiển tắc nghẽn đa đƣờng. Chƣơng 2 - Các
giao thức điều khiển tắc nghẽn có tiết kiệm năng lƣợng hiện tại. Trong chƣơng
này sẽ nêu chi tiết hai thuật toán điều khiển tắc nghẽn có tiết kiệm năng lƣợng hiện
tại là thuật toán ecMTCP của nhóm tác giả Tuan Anh Le, và các thuật toán điều
khiển tắc nghẽn đa đƣờng có nhận thức năng lƣợng cho thiết bị di động do nhóm
tác giả Qiuyu Peng đề xuất. Chƣơng 3 - đề xuất giao thức điều khiển tắc nghẽn
đa đƣờng có tiết kiệm năng lƣợng mới. Trong chƣơng này sẽ đề xuất một nhận
thức về năng lƣợng cho việc điều khiển tắc nghẽn, sao cho chuyển lƣu lƣợng từ các
đƣờng tắc nghẽn sang các con đƣờng trống hơn cũng nhƣ từ các đƣờng dẫn có chi
phí năng lƣợng cao sang đƣờng dẫn có chi phí năng lƣợng thấp hơn từ đó đạt đƣợc
cân bằng tải và tiết kiệm năng lƣợng. Chƣơng 4 : kết quả mô phỏng.


3

Chƣơng 1 - CƠ SỞ LÝ LUẬN
1.1 Giới thiệu về giao thức điều khiển tắc nghẽn đa đƣờng
Với sự phát triển nhanh chóng của công nghệ khoa học và kỹ thuật, mạng
ngày nay là đa đƣờng, các thiết bị di động có đa giao diện vật l . Trong khi đó TCP
bản chất vẫn là một giao thức đơn đƣờng. Khi một kết nối TCP đƣợc thành lập, kết
nối sẽ ràng buộc với địa chỉ IP của hai máy chủ giao tiếp, nếu một trong những địa
chỉ này thay đổi vì bất kì l do nào thì kết nối cũng sẽ bị thất bại. Chính vì vậy, kết
nối TCP không thể cân bằng tải trên nhiều hơn một đƣờng trong mạng vì nó hiểu
nhầm việc sắp xếp lại nhƣ một tắc nghẽn và làm chậm lại quá trình truyền tải.
Sự không phù hợp giữa mạng đa đƣờng ngày nay và thiết kế TCP đơn đƣờng

đ thực sự tạo ra nhiều vấn đề cũng nhƣ sự khó chịu của ngƣời dùng khi nguồn tài
nguyên luôn có sẵn nhƣng không tận dụng đƣợc triệt để.
Giao thức điều khiển tắc nghẽn đa đƣờng là một sửa đổi lớn để TCP cho
phép nhiều đƣờng dẫn đƣợc sử dụng đồng thời bởi một kết nối duy nhất. Giao thức
điều khiển tắc nghẽn đa đƣờng ra đời nhằm cải thiện thông lƣợng và tăng khả năng
điều khiển tắc nghẽn so với TCP thông thƣờng. Nó còn đặc biệt hữu ích trong bối
cảnh mạng không dây, mà việc sử dụng đồng thời nhiều giao diện vật l nhƣ wifi,
3G, 4G đang ngày càng phổ biến hiện nay.
Kiến tr c của giao thức điều khiển tắc nghẽn đa đƣờng 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
và dữ liệu đƣợc truyền trên các đƣờng đồng thời. Giao thức điều khiển tắc nghẽn đa
đƣờng hoạt động giống nhƣ TCP và mở rộng thêm các giao diện lập trình ứng dụng
nhằm cung cấp thêm chức năng điều khiển cho các ứng dụng của giao thức điều
khiển tắc nghẽn đa đƣờng [1].
Một kết nối của giao thức điều khiển tắc nghẽn đa đƣờng là tập hợp của
nhiều luồng con mà mỗi luồng con điều khiển một đƣờng và 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 đó.


4

1.2 Lợi ch, mục ti u c a giao thức điều khiển tắc nghẽn đa đƣờng
1.2.1

c
Các dự phòng cung cấp bởi giao thức điều khiển tắc nghẽn đa đƣờng cho

phép các nguồn tài nguyên có thể ghép kênh nghịch, do đó tăng thông lƣợng TCP
để tính tổng của tất cả các kênh thay vì chỉ sử dụng một liên kết đơn bởi TCP.
Giao thức điều khiển tắc nghẽn đa đƣờng đặc biệt hữu ích trong bối cảnh

mạng không dây, ví dụ nhƣ sử dụng đồng thời Wifi và một mạng di động. Ngoài
việc tăng thông lƣợng từ việc ghép kênh nghịch, liên kết có thể tăng hoặc giảm khi
ngƣời sử dụng di chuyển trong hoặc ngoài vùng phủ sóng mà không làm giám đoạn
các kết nối đầu cuối TCP. Những cải tiến nhƣ thế cũng sẽ làm giảm chi phí đầu tƣ
cơ sở hạ tầng mạng

1.2.2 Mục t êu
Phần này phác thảo các mục tiêu chính mà giao thức điều khiển tắc nghẽn đa
đƣờng cần phải hƣớng tới. Các mục tiêu này bao gồm mục tiêu về chức năng - dịch
vụ và tính năng mà giao thức điều khiển tắc nghẽn đa đƣờng cung cấp, và các mục
tiêu về khả năng tƣơng thích - ảnh hƣởng của giao thức điều khiển tắc nghẽn đa
đƣờng đến các giao thức hay hệ thống đang tồn tại khác [1].
Mục tiêu về chức năng
Trong việc hỗ trợ sử dụng truyền dẫn đa đƣờng dẫn, giao thức điều khiển tắc
nghẽn đa đƣờng có hai mục tiêu chức năng nhƣ sau:
 Cải thiện thông lƣợng: Giao thức điều khiển tắc nghẽn đa đƣờng phải
hỗ trợ việc sử dụng đồng thời nhiều đƣờng dẫn. Một kết nối của giao
thức điều khiển tắc nghẽn đa đƣờng có thông lƣợng không đƣợc thấp
hơn thông lƣợng của một kết nối TCP đơn lẻ trên đƣờng dẫn tốt nhất.
 Cải thiện khả năng phục hồi: giao thức điều khiển tắc nghẽn đa đƣờng
phải hỗ trợ việc sử dụng nhiều đƣờng dẫn thay thế cho nhau cho các
mục đích khả năng phục hồi, bằng cách cho phép các gói dữ liệu
đƣợc gửi đi và gửi lại trên bất kỳ đƣờng dẫn có sẵn nào. Vì vậy, trong
trƣờng hợp xấu nhất, khả năng phục hồi của một kết nối giao thức


5

điều khiển tắc nghẽn đa đƣờng không nhỏ hơn khả năng phục hồi của
một kết nối TCP đơn bất kỳ.

Mục tiêu về sự tương thích
Ngoài các mục tiêu chức năng đƣợc liệt kê ở trên, một giao thức điều khiển
tắc nghẽn đa đƣờng phải đáp ứng một số mục tiêu tƣơng thích để hỗ trợ việc triển
khai trên mạng Internet ngày nay. Những mục tiêu này đƣợc phân loại nhƣ sau:
 Tƣơng thích với ứng dụng.
 Tƣơng thích với tầng mạng. Các khái niệm tƣơng thích với tầng mạng
và tƣơng thích với các thiết bị hoạt động ở tầng mạng nghĩa là giao
thức điều khiển tắc nghẽn đa đƣờng phải tƣơng thích với mạng
Internet ngày nay bao gồm khả năng truyền qua các middlebox sẵn có
nhƣ: firewall, NAT, và các proxy nâng cao hiệu suất. Điều này yêu
cầu phải xây dựng giao thức với các chức năng có thể dò và truyền
qua các middlebox.
 Tƣơng thích với ngƣời dùng các mạng khác: Là hệ quả tất yếu của sự
tƣơng thích về mạng và tƣơng thích về ứng dụng, kiến trúc giao thức
điều khiển tắc nghẽn đa đƣờng phải cho phép việc tồn tại song song
giữa các luồng đa đƣờng mới và các luồng TCP thông thƣờng. Việc
sử dụng nhiều đƣờng dẫn không có nghĩa là làm tổn hại đến những
luồng TCP tại những liên kết thắt cổ chai. Các luồng đa đƣờng trên
cùng một nút cổ chai phải chia sẻ băng thông với mỗi luồng khác
tƣơng tự nhƣ việc chia sẻ xảy ra tại một nút thắt cổ chai của TCP
thông thƣờng.
Mục tiêu

t

Mở rộng của giao thức TCP với khả năng truyền đa đƣờng sẽ mang lại một
số mối đe dọa mới trong vấn đề an ninh mạng. Mục tiêu an ninh cho giao thức điều
khiển tắc nghẽn đa đƣờng là cung cấp một dịch vụ không kém an toàn hơn so với
TCP thông thƣờng. Điều này sẽ đạt đƣợc thông qua sự kết hợp cơ chế bảo mật của

6

TCP hiện tại (có thể sửa đổi để phù hợp với mở rộng giao thức điều khiển tắc nghẽn
đa đƣờng) và cơ chế bảo mật của truyền dẫn đa đƣờng.

1.3 Mô hình phân chia chức năng
Giao thức điều khiển tắc nghẽn đa đƣờng sử dụng các phiên TCP chuẩn, gọi là
các luồng con, để cung cấp cách thức truyền tải trên mỗi đƣờng dẫn, chính vì vậy
nó có khả năng tƣơng thích trên mạng. Thông tin đặc tả giao thức điều khiển tắc
nghẽn đa đƣờng đƣợc thực hiện một cách tƣơng thích với TCP , mặc dù cơ chế này
là tách biệt với các thông tin thực tế đƣợc chuyển giao để có thể phát triển trong các
phiên bản trong tƣơng lai. Hình 1.1 dƣới đây minh họa chuẩn TCP và chồng giao
thức MPTCP.

Application

Application

TCP

MPTCP

IP

Subflow (TCP)

Subflow (TCP)

IP

IP

Hình 1.1: So sánh mô hình TCP và mô hình c a MPTCP

Nằm bên dƣới tầng ứng dụng, mở rộng của giao thức điều khiển tắc nghẽn đa
đƣờng lần lƣợt quản l các luồng con đa đƣờng dƣới nó. Để làm điều này, nó phải
thực hiện các chức năng sau [1]:
Qu n lý đường dẫn(Path Management): Đây là chức năng để phát hiện và sử
dụng nhiều đƣờng dẫn giữa hai host. Giao thức điều khiển tắc nghẽn đa đƣờng sử
dụng sự hiện diện của nhiều địa chỉ IP tại một hoặc cả hai host để phát hiện khả
năng sử dụng nhiều đƣờng dẫn. Tính năng quản l đƣờng dẫn của giao thức điều
khiển tắc nghẽn đa đƣờng là các cơ chế để báo hiệu những địa chỉ khác nhau cho


7

các host biết, và cơ chế để thiết lập các luồng con mới tham gia vào một kết nối
MPTCP đang tồn tại.
l ch ch c c h n đ

n( chedule

: Chức năng này chia dòng bytes nhận

đƣợc từ tầng ứng dụng thành các phân đoạn để truyền đi trên một trong những
luồng con sẵn có. Thiết kế giao thức điều khiển tắc nghẽn đa đƣờng sử dụng một
ánh xạ chuỗi dữ liệu, liên kết các phân đoạn đƣợc gửi trên các luồng con khác nhau
bằng một số kí tự ở mức kết nối, do đó cho phép các phân đoạn gửi trên các luồng
con khác nhau đƣợc sắp xếp lại đ ng thứ tự ở bên nhận. Lập lịch gói tin là phụ

thuộc vào thông tin các đƣờng dẫn có sẵn từ thành phần quản l đƣờng dẫn, và sau
đó nó sử dụng các luồng con để truyền các phân đoạn hàng đợi. Chức năng này
cũng chịu trách nhiệm cho việc sắp xếp lại các phân đoạn ở cấp kết nối khi nhận
đƣợc gói tin từ các luồng con TCP, dựa theo bản đồ chuỗi dữ liệu.
uồng c n (TCP đơn đường : Thành phần luồng con có các phân đoạn từ các
thành phần lập lịch gói tin và truyền ch ng trên đƣờng dẫn chỉ định. MPTCP sử
dụng luồng con TCP cho việc tƣơng thích mạng. TCP đảm bảo gửi tin cậy, theo thứ
tự. TCP đánh số thứ tự riêng vào các phân đoạn, sử dụng cho việc phát hiện cũng
nhƣ truyền lại các gói bị mất ở lớp luồng con. ên nhận, luồng con chuyển tập hợp
các phân đoạn cho thành phần lập lịch gói tin ở mức kết nối. Ánh xạ chuỗi dữ liệu
của thành phần lập lịch gói tin bên gửi cho phép sắp xếp lại toàn bộ dòng byte theo
đ ng nhƣ thứ tự bên gửi.
Kiể

s

t tắc nghẽn: Chức năng này phối hợp kiểm soát tắc nghẽn trên mỗi

luồng con. Theo quy định, thuật toán điều khiển tắc nghẽn này phải đảm bảo rằng
một kết nối MPTCP không đƣợc chiếm nhiều băng thông một cách không công
bằng hơn một luồng con TCP tại một liên kết cổ chai.
Các chức năng này liên quan chặt chẽ với nhau nhƣ sau: Quản l đƣờng dẫn
sau khi phát hiện (hoặc khởi tạo) đa đƣờng dẫn giữa hai host. Lập lịch gói tin sau
đó nhận đƣợc một dòng dữ liệu từ các ứng dụng dành cho mạng, và thực hiện các
hoạt động cần thiết trên dữ liệu nhận đƣợc này rồi gửi nó vào luồng con. Luồng con
sau khi thêm số thứ tự riêng (cấp luồng con), khung báo nhận ACKs, và chuyển


8

ch ng vào mạng. Luồng con bên nhận sắp xếp lại dữ liệu(nếu cần thiết) và chuyển
dữ liệu sau khi xử l lên cho thành phần lập lịch gói tin, thành phần này sẽ sắp xếp
dữ liệu lại một lần nữa nhƣng ở cấp kết nối và gửi dòng dữ liệu lên tầng ứng dụng.
Cuối cùng thành phần kiểm soát tắc nghẽn tồn tại nhƣ một phần của thành phần lập
lịch gói tin (tính toán, lập lịch các phân mảnh nên gửi với tốc độ nào, ở luồng con
nào...).

1.4 Hoạt động c a giao thức điều khiển tắc nghẽn đa đƣờng
1.4.1 Một số khái niệm
Hoạt động tổng quát của giao thức điều khiển tắc nghẽn đa đƣờng đƣợc thể
hiện trong hình 1.2.
Host B

Host A
Address A1

Address A2

Address B1

Address B2

Thiết lập kết nối ban đầu

Thiết lập thêm luồng con

Hình 1.2: Kịch bản sử dụng MPTCP

Đối với các ứng dụng không có khả năng nhận biết MPTCP, MPTCP sẽ cƣ
xử giống giao thức TCP thông thƣờng. Các API mở rộng có thể cung cấp điều khiển

bổ sung để các ứng dụng nhận biết đƣợc MPTCP. Tất cả hoạt động của MPTCP
đƣợc thực hiện nhờ việc triển khai cấu tr c MPTCP ở lớp 4 và một ứng dụng sẽ bắt
đầu với việc mở một socket TCP theo cách thông thƣờng.


9

Một kết nối MPTCP đƣợc bắt đầu nhƣ một phiên TCP thông thƣờng. Nó
đƣợc minh họa trong hình 1.2 giữa hai địa chỉ A1 và 1, tƣơng ứng trên hai host A
và host B.
Nếu có thêm một hay nhiều đƣờng dẫn, thì sẽ có thêm một hay nhiều phiên
TCP (thuật ngữ MPTCP gọi là luồng con) đƣợc tạo nên trên các đƣờng dẫn này, và
những luồng con mới này sẽ đƣợc kết hợp với luồng con đang tồn tại. Tất cả những
phiên TCP này đƣợc coi là của cùng một kết nối của ứng dụng ban đầu giữa hai đầu
cuối và đƣợc mô tả ở hình 1.2 giữa địa chỉ A2 trên host A và 1 trên host .
MPTCP nhận dạng đa đƣờng dẫn bằng nhiều địa chỉ tại điểm đầu cuối. Sự
kết hợp giữa nhiều địa chỉ tạo nên các đƣờng dẫn mới. Ví dụ, các đƣờng dẫn mới có
thể đƣợc tạo nên từ hình 1.2 là giữa A1 - B2, A2 - 2. Cũng trong hình 1.2, luồng
con mới đƣợc thiết lập từ A2 hoặc từ 1.
Việc tìm thấy và thiết lập những luồng con mới đƣợc thực hiện thông qua
phƣơng thức quản l đƣờng dẫn (đƣợc mô tả trong mục 1.3) của lớp MPTCP.
Giao thức điều khiển tắc nghẽn đa đƣờng thêm một số kí tự nhận dạng gói
tin cấp kết nối cho phép lắp ghép các phân đoạn mà nó nhận đƣợc từ nhiều luồng
con với các điều kiện mạng khác nhau.
Các luồng con đƣợc kết th c nhƣ các kết nối TCP đơn, bằng quy trình bắt tay
bốn bƣớc. Các kết nối đƣợc MPTCP kết th c nhờ bản tin DATA FIN, hay là bằng
nhiều gói tin FIN độc lập trên các luồng con [4].

1.4.2 Khởi tạo một kết nối MPTCP
Đây là tín hiệu tƣơng tự nhƣ việc khởi tạo một kết nối TCP thông thƣờng,

bắt đầu bởi một bản tin SYN, SYN/ACK và các gói ACK đƣợc trao đổi trên cùng
một đƣờng dẫn, ch ng cũng sẽ mang theo bản tin MP_CAPABLE (Multipath
Capable). Đây là chiều dài biến thiên và phục vụ đa mục đích. Đầu tiên, nó xác định
máy chủ từ xa có hỗ trợ giao thức điều khiển tắc nghẽn đa đƣờng hay không, sau đó
cho phép các máy chủ trao đổi một số thông tin để xác thực việc thiết lập các luồng
con mới.


10

Host A

Host B

MP_CAPABLE
[A’s key, flags]
MP_CAPABLE
[ ’s key, flags]
MP_CAPABLE
[A’s key, ’s key, flags]
Hình 1.3: Quá trình khởi tạo phi n đầu ti n c a kết nối MPTCP

Một kết nối MPTCP đƣợc khởi tạo với luồng con đầu tiên bắt đầu với
MP_CAPA LE đƣợc thực hiện trên SYN, SYN/ACK, and gói ACK. Dữ liệu thực
hiện bởi mỗi gói nhƣ trong hình 1.3 với A là bên khởi tạo,

là bên nhận.

SYN (A-> ): kết nối với khóa A’s.
SYN / ACK (B-> A): kết nối với khóa ’s

ACK (A-> ): khóa A’s theo sau khóa ’s.
ản tin “Multipath Capable” bao gồm các trƣờng: loại bản tin (8 bit), chiều
dài bản tin (8 bit), 32 bit Token để xác định kết nối (mỗi kết nối có một Token duy
nhất), Initial Data Sequence Number (48 bit) để khởi tạo số thứ tự dữ liệu ban đầu.
Ý nghĩa của bản tin “Multipath Capable” này là cho biết một đầu cuối có khả năng
hoạt động giao thức điều khiển tắc nghẽn đa đƣờng hay không cũng nhƣ là cung cấp
Token nhận dạng kết nối trong trƣờng hợp đầu cuối muốn thêm những luồng con
mới vào kết nối này.
Token này đƣợc tạo ra bởi bên gửi, và nó xác định duy nhất cho bên gửi.
Token phải an toàn để tránh bị tấn công, và nên đƣợc tạo ra bằng cách lấy ngẫu
nhiên.
ản tin “Multipath Capable” đƣợc đƣa ra trong gói tin với cờ SYN đƣợc đặt là
1. Nó chỉ đƣợc sử dụng trong phiên TCP đầu tiên của một kết nối, để xác định kết


11

nối đó có khả năng truyền cùng l c trên nhiều đƣờng dẫn hay không; tất cả các
phiên sau đó sẽ sử dụng các bản tin quản l đƣờng dẫn để kết hợp luồng con mới
vào kết nối đang tồn tại.
Nếu một gói tin SYN bao gồm một bản tin “Multipath Capable” nhƣng bản tin
đáp trả lại SYN/ACK không có thì bên gứi sẽ giả thiết bên nhận không có khả năng
nhận đa đƣờng và do đó phiên MPTCP sẽ thực hiện nhƣ một phiên TCP bình
thƣờng. Nếu gói tin SYN không bao gồm bản tin “Multipath Capable”, thì gói tin
SYN/ACK gửi lại cũng sẽ không phải bao gồm bản tin “Multipath Capable”.
Nếu gói tin “Multipath Capable” này không đƣợc xác nhận, bên gửi sẽ dựa
vào những chính sách cục bộ để quyết định cách truyền gói tin. Và bên gửi cũng sẽ
gửi nhƣ một phiên TCP trên một đƣờng dẫn thông thƣờng (mà không có bản tin
“Multipath Capable”), một khả năng khác là các Middlebox có thể loại bỏ các gói
tin có các bản tin mà nó không biết; tuy nhiên số lần thử khả năng có đa đƣờng đầu

tiên đƣợc tạo ra hay không sẽ phụ thuộc vào chính sách cục bộ. Trong trƣờng hợp
các gói tin không theo thứ tự, ví dụ nếu bên gửi nhận đƣợc một gói tin SYN/ACK
chứa bản tin “Multipath Capable”, sau khi nó gửi một bản tin SYN thông thƣờng,
thì khi nó nó sẽ dựa vào bộ khởi tạo để quyết định cách thức thực hiện [4].

1.4.3 Khởi tạo một luồng con mới với kết nố đa đường hiện tại
Việc trao đổi khóa trong bắt tay MP_CAPA LE cung cấp thông tin để xác
thực đầu cuối khi luồng con mới đƣợc thiết lập. Luồng con bổ sung bắt đầu nhƣ một
kết nối TCP bình thƣờng, nhƣng các gói tin SYN, SYN/ACK, and ACK cũng mang
theo bản tin MP_JOIN.
Các đầu cuối phải biết về các địa chỉ của nó, và có thể nhận biết đƣợc các địa
chỉ của các đầu cuối khác thông qua việc trao đổi báo hiệu. Nhờ sự nhận biết này
mà một đầu cuối sẽ khởi tạo một luồng con mới trên các cặp địa chỉ hiện tại chƣa
đƣợc sử dụng.
Một luồng con mới đƣợc bắt đầu với việc trao đổi SYN/ACK TCP thông
thƣờng.

ản tin “Joint Connection” (MP_JOIN) đƣợc sử dụng để xác định luồng

con này thuộc về kết nối mới nào. Nó sử dụng dữ liệu khóa đƣợc trao đổi trong quá


12

trình bắt tay MP_CAPA LE và quá trình này cũng tìm ra thuật toán m hóa để sử
dụng cho quá trình bắt tay MP_JOIN.
Đầu tiên, bản tin MP_JOIN trong gói SYN sẽ gửi một token, số ngẫu nhiên
và địa chỉ ID. Các token đƣợc sử dụng để xác định các kết nối MPTCP và một m
băm của khóa nhận. Token trong bản tin “Join Connection ” này là token của kết
nối mà luồng con này muốn kết hợp vào. Mỗi kết nối có một token duy nhất và

đƣợc xác định trong bản tin “Multipath Capable” nhận đƣợc khi trao đổi SYN/ACK
đầu tiên. Nếu trong bản tin “Join Connection” có token phù hợp với kết nối MPTCP
đang tồn tại, bên nhận sẽ gửi lại một gói tin TCP SYN/ACK cũng bao gồm bản tin
“Join Connection” với token ban đầu. với mục đích đảm bảo cả hai đầu cuối đều
đồng

xác nhập với kết nối đƣa ra và đảm bảo không Middlebox nào trên đƣờng

dẫn sẽ loại bỏ các bản tin MPTCP theo đƣờng dẫn ngƣợc lại.
Nếu một token không xác định, bên nhận sẽ gửi lại một TCP RST giống nhƣ
trƣờng hợp một cổng không xác định trong TCP.
ản tin MP_JOIN trong gói SYN không chỉ gửi token mà cũng gửi chuỗi số
ngẫu nhiên gọi là nonces dùng để ngăn chặn các cuộc tấn công tiếp di n. Địa chỉ ID
là một định danh dùng để nhận dạng, có

nghĩa trong một kết nối duy nhất, nơi mà

nó xác định là địa chỉ nguồn của gói tin này. Nó có hai chức năng là nếu một địa chỉ
vì một l do nào đó trở nên không tồn tại đối với bên gửi, nó có thể thông báo điều
này đến bên nhận trông qua bản tin “Remove Address” mà không cần biết địa chỉ
nguồn thực chất là gì (do cho phép sử dụng NAT). Thứ hai, nó cho phép thử một
kết nối mới và thông báo địa chỉ để ngăn chặn lặp lại việc khởi tạo luồng con [4].

1.4.4 Truyền dữ liệu trong MPTCP
1.4.4.1 Ánh xạ thứ tự dữ liệu
Ánh xạ thứ tự dữ liệu xác định một ánh xạ từ không gian của chuỗi luồng
con đến không gian chuỗi dữ liệu.
Đầu cuối triển khai giao thức MPTCP sẽ nhận dòng dữ liệu từ một ứng dụng,
phân chia nó vào một hay nhiều luồng con. Tất cả dòng dữ liệu này có thể đƣợc ráp

13

lại tại bên nhận bằng cách sử dụng bản tin “Data Sequence Mapping”, để ánh xạ số
thứ tự cấp dữ liệu với số thứ tự cấp luồng con. Nhờ bản tin này mà tầng ứng dụng ở
bên nhận có thể nhận đƣợc dữ liệu theo đ ng thứ tự. Trong khi đó, trƣờng
“Subflow Sequence Number” xác định dữ liệu thuộc về luồng con nào.
Những xác nhận này ở mức độ luồng con, vì vậy bên nhận phải có khả năng
đối chiếu những xác nhận này với trƣờng “Data Sequence Number” có trong gói tin
liên quan. Do vậy, nếu một phân đoạn dữ liệu trong một luồng con bị mất thì bên
nhận phải báo cho bên gửi truyền lại phân đoạn dữ liệu này. Để thực hiện đƣợc điều
này, trong mỗi luồng con nên thực hiện cơ chế SACK.
ản tin “Data Sequence Mapping” cung cấp

đầy đủ từ trƣờng “Data

Sequence Number” với trƣờng “Subflow Sequence Number”, thông báo cho bên
nhận rằng có một ánh xạ giữa hai không gian chuỗi này với chiều dài xác định.
Trƣờng “Data Sequence Number” trong bản tin này là tuyệt đối, trong khi trƣờng
“Subflow Sequence Number” là tƣơng đối (khi gói tin SYN đƣợc gửi đi thì nó khởi
tạo giá trị của trƣờng “Subflow Sequence Number” là 1). Mỗi ánh xạ là duy nhất, ở
đó “Subflow Sequence Number” là giới hạn của “Data Sequence Number” sau khi
việc ánh xạ hoàn tất. Về sau không thể thay đổi sự ánh xạ này, tuy nhiên khi truyền
lại cùng một “Data Sequence Number” có thể đƣợc trên nhiều luồng con khác nhau
(hay dữ liệu bị mất có thể đƣợc truyền lại trên luồng con khác).

ên nhận không

chấp nhận dữ liệu mà nó không có ánh xạ đến không gian “Data Sequence
Number”. Để thực hiện điều này, bên nhận sẽ không xác nhận dữ liệu không đƣợc

ánh xạ ở mỗi luồng con. Trong trƣờng hợp nhƣ vậy một luồng con bị hỏng đƣợc
xem là tốt hơn là dữ liệu nhận đƣợc không đ ng thứ tự. Tuy nhiên, nếu xảy ra mất
gói ở một luồng con, bên nhận phải chờ gói này đƣợc truyền lại trƣớc khi đóng
luồng con đó, nếu gói bị mất chứa những thông tin ánh xạ cần thiết. Mặc dù việc
triển khai ban đầu sẽ sử dụng 32 bit cho trƣờng “Data Sequence Number” (4 octet,
chiều dài của trƣờng là 12), tuy nhiên nếu đặt chiều dài trƣờng đến 16 và bao gồm
64 bit Sequence Number (8 octet) thì phải xem xét tính hợp l khi xử l . Điều này
sẽ rất hữu dụng cho mục đích bảo mật. Cũng nhƣ trƣờng “Sequence Number” trong


14

giao thức TCP thông thƣờng, “Data Sequence Number” không bắt đầu từ 0, mà
đƣợc đặt ở một giá trị bất kì để việc tấn công phiên khó xảy ra (session hjjacking
harder). Ta thực hiện điều này bằng cách kết hợp bản tin “Data Sequence Number”
với bản tin “Multipath Capable” trong gói tin SYN khởi tạo kết nối ban đầu. Trong
trƣờng hợp này, để tiết kiệm không gian trƣờng Option trong TCP header, chiều dài
mức data hoặc trƣờng Subflow Sequence Number đƣợc đƣa vào trong Option này,
do đó trƣờng chiều dài sẽ là chiều dài của Data Sequence Number, cộng thêm hai
octet. Trong mỗi gói tin MPTCP không nhất thiết phải có bản tin “Data Sequence
Mapping”, mi n là bên nhận đ biết ánh xạ đối với “Subflow Sequence Number”
trong gói tin đó. Điều này có thể đƣợc sử dụng để giảm chi phí trong trƣờng hợp
ánh xạ đ biết, một trƣờng hợp khác là khi chỉ có một luồng con giữa hai đầu cuối,
đầu cuối khác là các phân đoạn dữ liệu đ đƣợc lập lịch [4].

1.4.4.2 Báo nhận dữ liệu
Từ trên ta thấy rằng ta hoàn toàn có thể xác nhận ở cấp luồng con, khi bên
gửi giữ các xác nhận này khi dữ liệu đ đƣợc nhận thành công. Nếu xảy ra trƣờng
hợp mà dữ liệu trong luồng bị loại bỏ sau khi nó đƣợc xác nhận (có thể xảy ra khi
proxy middlebox bị lỗi, hay bộ đệm ở một máy bị tràn), kết nối sẽ đứt hoàn toàn vì

bên gửi cho rằng dữ liệu đ đƣợc nhận trong khi thực tế lại chƣa.
Do vậy, MPTCP đƣa ra xác nhận cấp kết nối (bản tin DATA_ACK) hoạt
động nhƣ là “cumulative ACK” trong toàn bộ kết nối. ản tin này cũng hoạt động
tƣơng tự nhƣ gói tin “cumulative ACK” trong SACK trong TCP chuẩn – cho biết có
bao nhiêu dữ liệu đ đƣợc nhận thành công. ản tin này đƣợc thêm vào trong mỗi
gói tin bởi một máy triển khai giao thức điều khiển tắc nghẽn đa đƣờng [4].

1.4.4.3 Xem xét bên nhận
TCP thông thƣờng thông báo kích thƣớc cửa sổ mong muốn nhận trong mỗi
gói tin, để báo cho bên gửi biết nó có thể nhận đƣợc gói tin có kích thƣớc bao nhiêu.
Cửa sổ nhận đƣợc sử dụng để thực hiện điều khiển luồng, giảm tốc độ gửi của bên
gửi khi bên nhận không có khả năng nhận tiếp.


15

MPTCP cũng sử dụng một cửa sổ nhận duy nhất, chia sẻ giữa các luồng con.
Ý tƣởng này cho phép bất cứ luồng con nào đều có thể gửi dữ liệu mi n là bên nhận
có thể nhận đƣợc; hoặc duy trì cửa sổ nhận trên mỗi luồng con, có thể thiết lập hay
kết th c trên một vài luồng trong khi những luồng con còn lại không sử dụng những
cửa sổ này. “Receive Window” liên quan đến DATA_ACK. Nhƣ trong TCP, trong
giao thức MPTCP, DATA_ACK ở bên phải “Receive Window”. ên nhận sẽ dùng
“Data Sequence Number” để thông báo nếu một gói tin đƣợc chấp nhận ở cấp dữ
liệu. Khi quyết định chấp nhận những gói tin cấp luồng con, TCP thông thƣờng sử
dụng trƣờng “Sequence Number” trong gói tin và kiểm tra ch ng phù hợp với
“Receive Window” không. Vậy, khi nào các phân đoạn đƣợc xử l ở cấp kết nối ?
Mặc định là ch ng phải chờ cho đến khi ch ng đƣợc sắp xếp theo thứ tự ở cấp
luồng con, và sau đó mới đƣợc xem xét ở cấp kết nối. Tuy nhiên ta có thể tối ƣu tốc
độ xử l các phân đoạn ở cấp kết nối bằng cách không xác nhận ở cấp luồng con.
Ch

rằng sau này phân đoạn có thể bị loại bỏ ở cấp luồng con vì nó không theo

thứ tự; DATA_ACK đảm bảo rằng kết nối có thể xử l mà không cần phải chờ
truyền lại trên luồng con. Một vấn đề sẽ nảy sinh liên quan đến là kích thƣớc bộ
đệm bên nhận để nhận dữ liệu. Ranh giới thấp hơn cho việc sử dụng mạng đầy đủ là
tích băng thông độ tr lớn nhất của bất kì đƣờng dẫn nào, tuy nhiên bộ đệm sẽ d
dàng bị đầy khi một gói tin bị mất ở trên luồng con chậm hơn và cần truyền lại.
Ranh giới cao hơn sẽ là RTT lớn nhất nhân với tổng băng thông sẵn có lớn nhất trên
tất cả các đƣờng. Điều này cho phép tất cả luồng con tiếp tục ở tốc độ cao trong khi
gói tin đƣợc truyền lại nhanh chóng trên đƣờng có RTT lớn nhất.

1.4.4.4 Xem xét bên gửi
ên gửi chỉ xem xét việc quảng bá cửa sổ nhận với “Sequence Number” từ
bên nhận. Nó chỉ cập nhật giá trị của cửa sổ nhận cục bộ khi số thứ tự lớn nhất cho
phép tăng (Ví dụ, DATA_ACK + receive window). Điều này rất quan trọng để cho
phép sử dụng nhiều đƣờng dẫn với RTT khác nhau, và do đó vòng lặp hồi tiếp cũng
khác nhau. MPTCP sử dụng một cửa sổ nhận đơn trên tất cả các luồng con, và nếu


16

cửa sổ nhận đƣợc đảm bảo không thay đổi điểm đầu cuối, một máy chủ có thể đọc
hầu hết giá trị cửa sổ nhận gần đây.
ản tin “Data Sequence Mapping” cho phép bên nhận có thể gửi lại dữ liệu
với cùng một số thứ tự dữ liệu trên luồng con khác. Khi thực hiện điều này, một đầu
cuối vẫn phải truyền lại gói tin dữ liệu ban đầu trên luồng con ban đầu, để đảm bảo
trọn vẹn luồng con đó (Middlebox có thể chạy lại dữ liệu cũ, hoặc có thể từ chối
những chỗ khuyết trong luồng con), và bên nhận sẽ bỏ qua những sự truyền lại này.
Lƣu

rằng số thứ tự luồng con không ảnh hƣởng đến việc kiểm soát luồng nếu

cùng cửa sổ nhận đƣợc thông báo trên tất cả luồng con. Ch ng sẽ thực hiện kiểm
soát luồng cho những luồng con với một cửa sổ nhận thông báo nhỏ.

1.4.4.5 Độ tin cậy và truyền lại
Việc ánh xạ số thứ tự dữ liệu cho phép bên gửi có thể gửi lại dữ liệu với cùng
số thứ tự dữ liệu trên một luồng con khác. Khi thực hiện điều này, một máy chủ
phải truyền lại toàn bộ dữ liệu ban đầu trên luồng con ban đầu, để giữ đƣợc tính
toàn vẹn (middleboxes có thể chạy lại dữ liệu cũ, từ chối lỗ hổng trong các luồng
con), và bên nhận sẽ bỏ qua sự truyền lại này.
Đặc tả trong giao thức này không có bất kỳ cơ chế nào cho việc xử l truyền
lại khi đƣờng dẫn hỏng, mà phụ thuộc vào chính sách của mỗi luồng con. Ta có thể
tƣợng tƣợng chính sách truyền lại ở cấp kết nối là mỗi lần mất gói tại cấp luồng con
đƣợc truyền lại trên một luồng con khác (gây l ng phí băng thông nhƣng có thể làm
giảm việc chậm tr giữa các ứng dụng), hoặc chính sách truyền lại bảo thủ là việc
truyền lại ở cấp kết nối chỉ đƣợc sử dụng sau khi một vài cấp luồng con đƣợc cấp
phát lại sau khi hết thời gian.
Tất nhiên, việc truyền lại trong những luồng con tồn tại sẽ chỉ xảy ra nếu do
những chính sách của luồng con đề nghị. Thực vậy, nó có thể đƣợc hợp l một cách
bình đẳng để truyền lại trên cùng một luồng con nếu chất lƣợng hoặc dịch vụ của
các đƣờng dẫn khác xấu đi một cách đáng kể, hoặc là đƣợc giữ cho mục đích dự
phòng. Thêm vào đó, có thể thực hiện một vài triển khai để thông báo cho các lớp