Nghiên cứu cơ chế truyền lại chùm có điều khiển trên mạng TCP/OBS
Kỷ yếu Hội nghị KHCN Quốc gia lần thứ XII về Nghiên cứu cơ bản và ứng dụng Công nghệ thông tin (FAIR); Huế, ngày 07-08/6/2019
DOI: 10.15625/vap.2019.00043
NGHIÊN CỨU CƠ CHẾ TRUYỀN LẠI CHÙM CÓ ĐIỀU KHIỂN
TRÊN MẠNG TCP/OBS
Dương Phước Đạt 1, Lê Mạnh Thạnh 2, Võ Viết Minh Nhật 3
1 Khoa Du lịch - Đại học Huế
2 Trường Đại học Khoa học, Đại học Huế
3 Đại học Huế
TÓM TẮT: Chuyển mạch chùm quang (OBS) là công nghệ truyền thông đường trục cho mạng Internet thế hệ mới, mà trên đó các
luồng TCP được truyền với tốc độ cao. Tuy nhiên, do tác động của việc thu hẹp cửa sổ TCP khi có mất mát dữ liệu xảy ra, thể hiện
dưới dạng độ trễ phản hồi lớn, lượng dữ liệu được truyền vào mạng OBS sẽ bị hạn chế mà điều này làm giảm hiệu quả sử dụng
băng thông của các đường trục quang OBS. Đã có một số mô hình điều khiển được đề xuất ở tầng mạng OBS sao cho cửa sổ TCP ít
bị thu hẹp, nhằm tăng hiệu quả sử dụng băng thông của các sợi quang. Bài báo này sẽ trình bày một hướng tiếp cập điều khiển
truyền lại sao cho hạn chế việc thu hẹp cửa sổ TCP. Các kết quả phân tích và mô phỏng sẽ chỉ ra rằng giải pháp điều khiển truyền
lại được đề xuất đã cải tiến đáng kể thông lượng được truyền vào mạng lõi và do đó nâng cao được hiệu quả sử dụng băng thông
mạng OBS.
Từ khóa: Mạng chuyển mạch chùm quang, truyền lại, phục hồi mất mát, hiệu quả sử dụng băng thông, TCP-OBS.
I. GIỚI THIỆU
Chuyển mạch chùm quang (Optical Burst Switching - OBS) [1][2][3] đã được xem là một mô hình truyền tải dữ
liệu hứa hẹn nhất và có khả năng triển khai thực tế so với các mô hình chuyển mạch gói quang đã được đề xuất khác.
Với tốc độ truyền tải cao, băng thông lớn và khả năng sử dụng tối đa các nguồn tài nguyên trong hệ thống, OBS đang
là một công nghệ rất triển vọng trong việc triển khai mạng quang thế hệ tiếp theo. Ở tầng trên, các lưu lượng lưu thông
trên mạng Internet đều sử dụng giao thức TCP (Transport Control Protocol), đó chính là giao thức truyền tải đáng tin
cậy do có khả năng tự điều chỉnh tốc độ truyền tải thông qua những cơ chế kiểm soát tắc nghẽn của mình và thực hiện
truyền tải lại các gói tin TCP bị mất một cách nhanh chóng. Vì vậy hiệu năng của mô hình mạng tích hợp TCP/OBS
(TCP over OBS) thu hút khá nhiều sự quan tâm nghiên cứu.
Do những đặc trưng truyền tải riêng biệt chỉ có trong mạng OBS (như là độ trễ tập hợp chùm, độ trễ của cơ chế
báo hiệu,…), điều này đã làm ảnh hưởng không nhỏ tới hiệu năng tổng thể của các luồng TCP truyền vào mạng lõi
OBS, làm giảm thông lượng của các luồng TCP vào và dẫn đến không tận dụng hết khả năng băng thông cao của mạng
OBS. Trong mạng OBS, một chùm chứa hàng ngàn gói tin IP từ nhiều nguồn TCP/IP, vì vậy hiệu suất TCP sẽ bị ảnh
hưởng đáng kể khi mất một chùm. Nếu xảy ra mất chùm do tranh chấp tài nguyên ở tầng OBS tại thời điểm tải lưu
lượng thấp, điều này sẽ gây ra sự báo hiệu tắc nghẽn mạng lớn đối với tầng TCP do hàng ngàn gói tin TCP chứa trong
chùm bị mất và điều dẫn đến việc giảm kích thước cửa sổ kiểm soát tắc nghẽn TCP để chống tắc nghẽn. Đây là một
thông báo mất mát sai ở tầng TCP (False Time Out - FTO) [4], nên việc điều chỉnh cửa số TCP là không cần thiết và
làm ảnh hưởng lớn đến thông lượng và hiệu năng của luồng TCP vì tải lưu lượng của mạng vẫn còn thấp. Đã có một số
cơ chế được đề xuất để giải quyết vấn đề tranh chấp trong mạng OBS như chuyển đổi bước sóng [5], định tuyến lệch
hướng [6], đường trễ quang (FDL- fiber delay line) [7], …; nhưng các cơ chế này yêu cầu các kỹ thuật phức tạp và chi
phí cao.
Cơ chế truyền lại cũng là một giải pháp giảm tỉ lệ mất chùm hiệu quả trong mạng OBS [8]. Tuy nhiên việc
truyền lại sẽ làm tăng độ truyền đầu-cuối của các gói tin IP chứa trong chùm, vì vậy việc điều khiển cơ chế truyền lại
chùm cần được xem xét nhằm tăng hiệu quả của mạng. Bài báo sẽ phân tích và đánh giá ảnh hưởng của cơ chế truyền
lại có điều khiển ở tầng OBS đối với hiệu quả sử dụng băng thông của các luồng TCP.
Các phần tiếp theo của Bài báo được tổ chức như sau: Phần 2 trình bày cơ chế truyền lại chùm trong TCP/OBS.
Phần 3 mô phỏng, phân tích, so sánh hiệu năng một số giao thức TCP đối với trường hợp có hoặc không áp dụng cơ
chế truyền lại có điều khiển trong mạng TCP/OBS. Cuối cùng là Kết luận và Tài liệu tham khảo.
II. CƠ CHẾ TRUYỀN LẠI CHÙM TRONG MẠNG TCP/OBS
A. Một số giao thức TCP/IP
Một trong những chức năng chính của TCP là điều khiển tốc độ truyền tải hợp lý và phù hợp với tình trạng của
mạng. Đây là một điều hết sức quan trọng đối với quá trình truyền tải nhằm có được một tốc độ đủ lớn không chỉ đảm
bảo được hiệu năng cao, mà còn phù hợp với khả năng đáp ứng của mạng, tránh làm mạng quá tải.
TCP duy trì một cửa sổ kiểm soát tắc nghẽn để xử lý các vấn đề tắc nghẽn lưu lượng trong quá trình truyền tải
trong mạng. Thông qua các gói tin phản hồi (ACK - Acknowledgement) nhận được từ nút đích (TCP receiver), TCP sẽ
điều chỉnh kích thước cửa sổ sao cho phù hợp nhất với tình hình mạng hiện tại. Hơn nữa, mỗi gói tin TCP được gửi đi
338
NGHIÊN CỨU CƠ CHẾ TRUYỀN LẠI CHÙM CÓ ĐIỀU KHIỂN TRÊN MẠNG TCP/OBS
sẽ được thiết lập khoảng thời gian tồn tại của gói tin. Cứ sau một khoảng thời gian nhất định (Round Trip Time - RTT)
nếu không nhận được thông báo phản hồi của gói tin từ nút đích thì xem như gói tin đó đã bị mất.
Thông thường để kiểm soát tốc độ truyền tải các gói tin của mình, TCP sử dụng bốn cơ chế kiểm soát tắc nghẽn
chính, đó là: bắt đầu chậm (slow start), tránh tắc nghẽn (congestion avoidance), truyền lại nhanh (fast retransmission)
và phục hồi nhanh (fast recovery). Để có thể tính toán trạng thái của mạng hiện tại, TCP sử dụng các sự kiện mà nó thu
thập được thông qua cơ chế phản hồi ACK, Duplicated-ACK, hoặc timeout,… để đánh giá tình hình mạng hiện tại và
thông qua đó sẽ hiệu chỉnh tốc độ truyền tải một cách phù hợp nhất với trạng thái mạng hiện tại. Dựa vào mô hình
kiểm soát, có thể phân loại TCP như sau:
- TCP dựa trên sự kiện mất mát gói tin để kiểm soát tắc nghẽn (như TCP Tahoe, TCP Reno [9],…): thực hiện
việc kiểm soát tắc nghẽn của mình theo cơ chế tăng cộng/giảm nhân kích cỡ cửa sổ kiểm soát tắc nghẽn đối với việc
quy định truyền tải dữ liệu và duy trì việc sử dụng băng thông mạng và lấy sự kiện một gói tin TCP chỉ thị cho việc
nhận định mạng đang bị tắc nghẽn.
- TCP dựa trên độ trễ truyền tải để kiểm soát tốc độ truyền tải (như TCP Vegas [10],…): đánh giá băng thông và
tình trạng tắc nghẽn của mạng bằng cách đo độ trễ của một chu kỳ truyền thông gói tin chu kỳ (RTT). Đầu tiên TCP
Vegas tính toán RTT cơ sở (BaseRTT) như là một RTT tối thiểu, gồm độ trễ truyền tải và độ trễ chờ đợi tại các router
trung gian. Từ đó, thông lượng mong đợi (Expected) có thể được ước lượng như sau: Expected = cwnd/BaseRTT, mà
trong đó cwnd là kích thước cửa sổ kiểm soát tắc nghẽn hiện tại. Sau đó, thông lượng thực tế (Actual throughput) được
tính toán cho mỗi RTT bằng cách đo RTT gần nhất: Actual = cwnd/RTT, mà trong đó cwnd là kích thước cửa sổ kiểm
soát tắc nghẽn. Cuối cùng dựa vào sự chênh lệch giữa hai đại lượng Actual và Expected mà TCP Vegas sẽ để hiệu
chỉnh kích cỡ cửa sổ truyền sao cho phù hợp nhất với trạng thái mạng hiện tại.
- TCP dựa trên các thông điệp phản hồi để thông báo thêm thông tin về tình trạng mạng hiện tại (như TCP Sack
[11],…): thông tin về tình trạng mạng hiện tại được thêm vào các gói phản hồi gửi về các nguồn gửi (TCP sender). Dựa
vào thông tin tình trạng mạng được phản hồi, nguồn gửi sẽ điều chỉnh kích thước cửa sổ phù hợp nhất để đảm bảo tốc
độ truyền tải dữ liệu
B. Truyền lại chùm trong mạng OBS
Nút biên vào
Nút lõi 1
Nút lõi 2
Nút lõi 3
Nút biên ra
BCP
BCP
Thời gian
Hình 1. Cơ chế truyền lại trong mạng OBS
Hiệu năng truyền thông của các luồng TCP trong mạng OBS bị ảnh hưởng rất nhiều do vấn đề mất mát chùm dữ
liệu ngay cả khi tải lưu lượng vào mạng không cao. Trong mạng OBS, một chùm dữ liệu có thể chứa tới hàng ngàn gói
tin TCP/IP, nên việc mất chùm sẽ có ảnh hưởng rất lớn đến các nguồn gửi TCP (TCP sender) ở tầng TCP/IP khiến cho
các nguồn gửi TCP này phải giảm kích thước cửa sổ truyền một cách không cần thiết. Vì vậy việc giảm mất chùm sẽ
làm tăng hiệu năng truyền thông của TCP trong mạng TCP/OBS.
Cơ chế truyền lại chùm trong mạng OBS đã được đề xuất trong [12] nhằm giải quyết vấn đề mất mát do tranh chấp
tài nguyên. Để thực hiện truyền lại chùm, ngoài các thông tin cơ bản, gói điều khiển (Burst Control Pachket - BCP) còn
lưu thêm thông tin định danh (ID) của chùm, trong đó mỗi chùm được gán một ID duy nhất. Nút biên vào được trang bị
các bộ đệm để lưu lại các bản sao chùm phục vụ cho việc truyền lại chùm và các nút lõi được giả thiết có khả năng gửi gói
tin phản hồi (ARQ - Automatic Repeat reQuest hoặc NACK - Negative ACKnowledgement) về nút biên vào và nút đích
được trang bị khả năng gửi gói tin báo nhận (ACK - Acknowledgement) để thông báo tình trạng chùm nhận được về nút
nguồn. Nếu gói tin BCP của một chùm được gửi đi nhưng không đặt trước tài nguyên thành công tại nút lõi thì nút lõi sẽ
gửi gói tin phản hồi ARQ về nút biên của chùm tương ứng để thông báo việc mất chùm. Khi nhận được gói tin ARQ, nút
Dương Phước Đạt, Lê Mạnh Thạnh, Võ Viết Minh Nhật
339
biên sẽ thực hiện truyền lại ngay bản sao của chùm. Như được mô tả trong Hình 1, gói tin BCP được truyền bởi nút biên
vào ở thời điểm t0, chùm được gửi đi sau đó khoảng thời gian offset vào thời điểm t1. Tại thời điểm t2 chùm không thể lập
lịch thành công ở nút trung gian (Nút lõi 3), một thông báo ARQ được gởi bởi nút này trở lại nút biên vào. Nút biên vào
nhận được thông báo ARQ tại thời điểm t3 sẽ gởi lại một gói tin BCP mới và truyền lại một bản sao chùm tại thời điểm t4
sau một khoảng thời gian offset. Nếu lần truyền thứ hai thành công và tại giả thiết thời điểm t5 chùm đến được nút đi đích,
bản sao của chùm tại nút biên sẽ được xóa khỏi bộ đệm. Nếu không thành công, việc truyền lại bản sao chùm này sẽ được
thử nhiều lần (tùy thuộc chính sách truyền lại đã được thiết lập tại nút biên) cho đến khi việc truyền chùm đến nút biên
đích thành công. Việc truyền lại chùm sẽ làm giảm tỉ lệ mất chùm đáng kể, tuy nhiên truyền lại nhiều lần sẽ làm tăng độ
trễ đầu-cuối; vì vậy cần có cơ chế điều khiển truyền lại chùm nhằm quyết định thực hiện truyền lại hay loại bỏ chùm bị
đánh rơi khi xảy ra tranh chấp tài nguyên trong tầng OBS.
C. Cơ chế truyền lại chùm có điều khiển trên mạng TCP/OBS
Đã có một số nghiên cứu đánh giá về ảnh hưởng của các cơ chế điều khiển trong mạng TCP/OBS, trong đó đa
số tập trung vào các tác động đối với cơ chế tập hợp chùm [13][14][15][16]. Trong bài báo này, chúng tôi nghiên cứu
sự ảnh hưởng của truyền lại đối với các cơ chế điều khiển cửa sổ TCP dựa vào hiệu quả thông lượng và tỉ lệ mất mát.
Trong mạng TCP/OBS, các gói tin TCP được tập hợp thành các chùm dữ liệu ở nút biên trước khi được vào để
truyền bên trong mạng lõi, việc mất chùm ngẫu nhiên do xung đột đã dẫn đến rất nhiều gói tin TCP chứa trong chùm bị
mất ngay cả khi tải lưu lượng của mạng đang rất thấp. Điều này đã gây ra hiện tượng phát hiện sai (False Time Out -
FTO) về trạng thái tắc nghẽn của mạng ở tầng TCP. Với phát hiện sai này, kích thước cửa sổ kiểm soát tắc nghẽn của
các luồng TCP thay đổi và liên tục bị thu hẹp. Điều này làm cho hiệu năng của mạng TCP/OBS bị ảnh hưởng do không
thể tận dụng hết khả năng đáp ứng băng thông của mạng OBS. Vì vậy điều khiển truyền lại chùm trong mạng
TCP/OBS cần được nghiên cứu và cải tiến.
Tách chùm
Tập hợp chùm
Mạng IP
E
Mạng IP
Mạng OBS
I
TCP nhận
(TCP Receiver)
TCP phát
(TCP Sender)
Ta
Tb
Tp
Tb
Ta
Hình 2. Mô hình kết nối TCP/OBS
Khi áp dụng cơ chế truyền lại chùm, độ trễ truyền chùm là yếu tố quan trọng. Một chùm chứa hàng ngàn gói tin
IP, vì vậy độ trễ của một chùm ảnh hưởng rất lớn đến tầng TCP. Hình 2 biểu diễn mô hình kết nối TCP/OBS, trong đó
Tp là độ trễ lan truyền trong lớp OBS, Ta thời gian trễ của mạng truy cập IP, Tb là thời gian tập hợp chùm và phân tách
chùm tại nút biên vào và nút biên ra. Đối với tầng TCP, giá trị RTT được xác định bằng RTT = 2(Tp + 2Ta + 2Tb). Giá
trị Ta đối với các luồng TCP khác nhau sẽ khác nhau và tùy vào cơ chế tập hợp chùm được thiết lập, giá Tb cũng sẽ
khác nhau. Với một tập các luồng truy cập TCP cho trước và cơ chế tập hợp chùm thiết lập trước, giá trị Ta và Tb không
ảnh hưởng đến việc điều khiển truyền lại; chỉ có độ trễ lan truyền chùm ở tầng OBS RTTOBS = 2Tp là yếu tố được xem
xét đến khi điều khiển truyền lại [17].
Đối với cơ chế truyền lại trong mạng OBS, số nút trên hành trình mà chùm đi qua là một yếu tố quan trọng ảnh
hưởng trực tiếp đến độ trễ đầu-cuối của chùm. Đối các chùm đã đi qua hành trình dài hoặc đã đến gần với nút biên ra,
việc truyền lại sẽ càng làm cho tải lưu lượng và độ trễ trong mạng sẽ tăng lên. Vì vậy việc nghiên cứu và đề xuất cơ
chế truyền lại có điều khiển dựa trên hành trình của chùm đã đi qua để quyết định đánh rơi hay truyền lại chùm trong
mạng TCP/OBS là trọng tâm chính của bài viết này.
Cơ chế truyền lại đã giới thiệu ở Phần 2.2 sẽ thực hiện truyền lại chùm khi nút biên vào nhận được gói tin ARQ.
Tuy nhiên trong một số trường hợp việc truyền lại sẽ không hiệu quả do độ trễ quá lớn và khi thực hiện truyền lại sẽ
dẫn đến phát hiện timeout sai (FTO). Vì vậy chúng tôi đề xuất cơ chế truyền lại có điều khiển dựa trên độ dài hành
trình của chùm để quyết định có thực hiện truyền lại hay đánh rơi chùm. Độ dài hành trình của chùm có thể xác định
dựa vào thời gian offset (toffset). Thời gian offset trong mạng OBS phụ thuộc vào số chặng (nh) mà chùm đi qua giữa nút
nguồn và nút đích, thời gian xử lý tại các nút lõi (tproc) và thời gian cấu hình chuyển mạch (tg): toffset = tg +nh * tproc [18].
Hình 3 biểu diễn cơ chế truyền lại có điều khiển. Sau khi tập hợp chùm và gửi gói điều khiển, nếu việc cấp phát
tài nguyên cho chùm tương ứng thành công, việc truyền chùm sẽ được thực hiện; khi đó chùm dữ liệu sẽ được chuyển
tiếp đến nút tiếp theo và quá trình này được lặp lại. Ngược lại, nút lõi sẽ thực hiện gửi gói tin phản hồi chứa thông tin
hành trình của chùm về nút biên tương ứng. Tại nút biên, khi nhận được gói tin phản hồi từ nút lõi, dựa vào hành trình
của chùm đã đi qua, nút biên sẽ quyết định có hoặc không truyền lại chùm. Dựa vào thông tin hành trình nút lõi gửi về,
nút biên sẽ tính toán được thời gian trễ còn lại của chùm, sau đó so sánh với thời gian offset của chùm tương ứng để
quyết định liệu có truyền lại hoặc xóa chùm. Thời gian trễ còn lại của chùm được xác định bằng TTLb = RTTOBS - 2Rb,
trong đó Rb là thời gian chùm đi từ nút biên đến nút xảy ra tranh chấp. Cơ chế điều khiển truyền lại sẽ giúp hạn chế
việc truyền lại chùm không cần thiết vì các chùm đã đi qua hành trình dài khi thực hiện truyền lại không những sẽ
không hiệu quả mà còn làm tăng độ trễ đầu cuối.
340
NGHIÊN CỨU CƠ CHẾ TRUYỀN LẠI CHÙM CÓ ĐIỀU KHIỂN TRÊN MẠNG TCP/OBS
Nút biên
Bắt đầu
Truyền bản sao
Lập lịch cho chùm
của chùm
Đ
Gửi gói tin điều
khiển
S
Xóa bản sao chùm
khỏi bộ đêm
TTLb >= toffset
Kết thúc
TTLb := RTTobs - 2Rb
Nút lõi
Đ
Cấp được tài nguyên
S
Tính số hop đã đi
qua
Chuyển tiếp chùm
đến nút tiếp theo
Gửi phản hồi chứa
thông tin hành trình
của chùm
Hình 3. Cơ chế truyền lại có điều khiển trên mạng TCP/OBS
Trong phần tiếp theo, chúng tôi sẽ thực hiện mô phỏng và phân tích kết quả của các giao thức TCP khi có hoặc
không áp dụng cơ chế truyền lại chùm có điều khiển trong mạng TCP/OBS.
III. MÔ PHỎNG VÀ PHÂN TÍCH KẾT QUẢ
Để đánh giá ảnh hưởng của cơ chế truyền lại có điều khiển đối với các giao thức TCP, chúng tôi thực hiện mô
phỏng và đánh giá hiệu năng của các luồng TCP dựa trên thông lượng và xác suất mất chùm. Môi trường mô phỏng là
NS2 với gói NS2-obs0.9a, ngôn ngữ lập trình C++, cài đặt trên máy tính CPU Intel Core i3 CPU 3.6 GHz, 4Gb RAM.
E0
E1
E2
E3
E4
E5
E6
E7
E8
E9
10 Gbps
10 Gbps
10 Gbps
10 Gbps
10 Gbps
30 Gbps
10 Gbps
10 Gbps
C0
C1
10 Gbps
10 Gbps
10 Gbps
Hình 4. Mô hình mạng Dumpbell
Mô phỏng được thực hiện trên một mạng Dumpbell có 2 nút lõi (Co và C1), mỗi nút lõi kết nối với 5 nút biên
(Ei, i = 0, . . ., 9) như mô tả ở Hình 4. Giả sử các luồng dữ liệu đến tại các nút biên có phân phối Poisson và các
chùm sinh ra có kích thước thay đổi theo hàm số mũ. Mỗi liên kết chỉ có 16 kênh dữ liệu và 4 kênh điều khiển. Băng
thông của mỗi kênh từ nút biên đến các nút lõi là 10Gb/s, băng thông giữa 2 nút lõi là 30Gb/s. Thời gian quan sát là
100 giây. Xét 3 luồng TCP Reno, TCP Vegas và TCP Sack đến tại nút biên mạng TCP/OBS có hoặc không sử dụng
cơ chế truyền lại có điều khiển. Mục tiêu mô phỏng là nhằm mục đích đánh giá sự tác động của mô hình truyền lại
chùm có điều khiển đối các cơ chế kiểm soát cửa số tắc nghẽn khác nhau của TCP. Kết quả mô phỏng được thể hiện
ở phần tiếp theo.
Dương Phước Đạt, Lê Mạnh Thạnh, Võ Viết Minh Nhật
341
A. Hiệu năng của các giao thức TCP khi không sử dụng cơ chế truyền lại
Thông lượng các luồng TCP là một tham số quan trọng để đánh giá hiệu năng. Kết quả mô phỏng thể hiện ở
Hình 5 cho thấy thông lượng của TCP Sack là cao nhất, lần lượt tiếp theo là TCP Reno và TCP Vegas có thông lượng
thấp nhất. Điều này cho thấy TCP Sack với các thông tin về trạng thái của mạng được gửi trong gói tin phản hồi giúp
nhận diện đúng nhất các tranh chấp của các chùm trong mạng OBS. Ngược lại, TCP Vegas điều khiển cửa sổ dựa vào
độ trễ các gói tin TCP, vì vậy bị tác động rất lớn bởi độ trễ truyền tải cũng như tranh chấp tài nguyên trong mạng OBS.
Việc tranh chấp tài nguyên trong mạng OBS dẫn đến phát hiện mạng tắc nghẽn không chính xác khiến thông lượng đối
với TCP Vegas thấp nhất. Thông lượng của TCP dựa vào mất gói tin để đánh giá tình trạng tắc nghẽn của mạng như
TCP Reno có thông lượng thấp hơn không đáng kể so với TCP Sack.
Hình 5. So sánh thông lượng giữa các giao thức TCP Reno, TCP Sack, TCP Vegas trong mạng TCP/OBS
Bên cạnh thông lượng, tỉ lệ mất mát cũng là một tham số quan trọng để đánh giá hiệu năng các luồng TCP. Kết
quả mô phỏng thể hiện ở Hình 6 cho thấy xác suất mất gói tin đối với TCP Sack là cao nhất, tiếp đến là TCP Reno và
thấp nhất là TCP Vegas. Điều này thể hiện rõ sự biển đổi rất lớn kích thước cửa sổ kiểm soát tắc nghẽn đối với TCP
Sack do việc dựa trên thông tin trạng thái của mạng được gửi về theo gói tin phản hồi, trong khi đó TCP Vegas dựa vào
độ trễ các gói tin để điều chỉnh kích thước cửa sổ thông qua giá trị RTT để đánh giá mức độ sử dụng băng thông và
tình trạng tắc nghẽn của mạng. Vì vậy, với TCP Vegas, việc tăng thêm độ trễ của RTT dựa vào RTT của gói tin truyền
trước đó dẫn đến việc kích thước của sổ ít biến đổi nhất.
Hình 6. Tỉ lệ mất mát của các giao thức TCP
B. Hiệu năng của các giao thức TCP trường hợp có sử dụng cơ chế điều khiển truyền lại
Để đánh giá sự ảnh hưởng của cơ chế truyền lại có điều khiển đối với các giao thức TCP, chúng tôi tiến hành so
sánh thông lượng và tỉ lệ mất mát của ba giao thức TCP Reno, TCP Sack và TCP Vegas khi có sử dụng và không sử
dụng cơ chế truyền lại có điều khiển.
Qua kết quả mô phỏng cho thấy nhờ vào cơ chế truyền lại chùm có điều khiển tại tầng OBS đã làm giảm tỉ lệ
mất chùm tại các nút trung gian dẫn đến tỉ lệ mất gói tin IP giảm (Hình 11) cũng như thông lượng của các loại TCP đã
được cải thiện (Hình 7, Hình 8 và Hình 9). Thông lượng của TCP tuy có tăng so với khi không thực hiện cơ chế truyền
lại chùm có điều khiển trong mạng OBS (Hình 10) nhưng vẫn không đáng kể so với khả năng truyền tải lên tới hàng
Gb/s của mạng OBS. Chủ yếu thông lượng TCP tăng là do sự truyền lại các chùm trong mạng OBS khi xảy ra tranh
chấp cũng như hạn chế việc thay đổi kích thước cửa sổ do các chùm truyền không thành công khi không được cấp phát
tài nguyên trong lần truyền đầu tiên. Do truyền lại các chùm bị đánh rơi trong tầng OBS nên xác suất mất chùm trên
mạng OBS đã giảm đi đáng kể qua đó làm tăng thông lượng chung cho tất cả các lưu lượng và do đó thông lượng của
TCP đã tăng lên cũng như làm giảm tỉ lệ mất gói tin IP. Một nguyên nhân khiến cho thông lượng TCP vẫn còn thấp mà
chưa tận dụng hết khả năng của mạng OBS mang lại đó là: trật tự của các gói tin TCP ở nút biên ra. Do có sự mất mát
chùm trên hành trình truyền tải mà thứ tự của các gói tin TCP này ở nút biên ra không theo đúng trật tự ban đầu và nút
biên ra vẫn tiếp tục tách chùm và gửi các gói tin TCP tới các bên nhận TCP (TCP Receiver). Do đó khi trật tự bị thay
đổi, bên nhận TCP vẫn gửi các gói Duplicated-ACKs tới bên gửi TCP (TCP Sender) để thông báo với bên gửi TCP về
các gói tin chưa nhận được. Khi bên gửi TCP Sender được ba hoặc nhiều hơn các gói Duplicated-ACK cho một gói tin
342
NGHIÊN CỨU CƠ CHẾ TRUYỀN LẠI CHÙM CÓ ĐIỀU KHIỂN TRÊN MẠNG TCP/OBS
TCP thì nó sẽ tiến hành gửi lại gói tin TCP đó mà không biết rằng gói tin TCP đó đang được truyền tải lại bởi chính cơ
chế truyền tải lại trong mạng OBS. Điều này cũng khiến cho kích thước cửa sổ truyền tải của TCP bị cắt giảm liên tục
khi nhận được các Duplicated-ACKs này, qua đó ảnh hưởng trực tiếp đến thông lượng chung của các luồng TCP. Hơn
nữa, việc điều khiển truyền lại chùm có điều khiển sẽ chủ động đánh rơi mà không thực hiện việc truyền lại đối với các
chùm đã đi qua nhiều chặn trong mạng OBS dẫn đến hàng ngàn gói tin chứa trong chùm bị đánh rơi. Do đó dẫn đến
TCP phát hiện sai tình trạng mạng tắc nghẽn nặng. Lúc đó TCP sẽ cắt giảm kích thước cửa sổ. Một khi lưu lượng của
mạng thực sự lớn và xảy ra tình trạng tắc nghẽn kéo dài, việc sử dụng cơ chế truyền lại chùm có thể làm tăng tải của
mạng dẫn đến thông lượng của TCP khó có thể tăng cao được. Vì vậy bên cạnh việc điều khiển truyền lại dựa vào hành
trình, cần có những cải tiến để tính toán số lần truyền lại dựa vào thông lượng của mạng nhằm tránh làm tăng tải của
mạng khi cố gắng thực hiện truyền lại vào thời điểm mạng đang ở trạng thái tải cao.
Hình 7. So sánh thông lượng TCP Reno khi có/không sử dụng cơ chế truyền lại có điều khiển
Hình 8. So sánh thông lượng TCP Sack khi có/không sử dụng cơ chế truyền lại có điều khiển
Hình 9. So sánh thông lượng TCP Vegas khi có/không sử dụng cơ chế truyền lại
Dương Phước Đạt, Lê Mạnh Thạnh, Võ Viết Minh Nhật
343
Hình 10. Thông lượng chung của 3 giao TCP trong trường hợp có/ không sử dụng cơ chế truyền lại
Hình 11. Tỉ lệ mất mát của 3 giao thức TCP khi có/không sử dụng cơ chế truyền lại
IV. KẾT LUẬN
Đóng góp chính của bài báo này là nghiên cứu và phân tích mô hình truyền lại có điều khiển dựa vào hành trình
của chùm trên mạng TCP/OBS, đồng thời thực hiện cài đặt mô phỏng để đánh giá sự tác động của cơ chế truyền lại có
điều khiển đối với hiệu năng các loại giao thức TCP dựa trên thông lượng truyền thông và xác suất mất chùm. Các kết
quả trong bài báo chỉ ra rằng, thông lượng được cải thiện khi sử dụng cơ chế truyền lại có điều khiển trong mạng
TCP/OBS. Việc phân tích này nhằm đánh giá sự tác động của truyền lại đối với hiệu năng của các luồng TCP trên
mạng OBS từ đó đề xuất cách cải tiến các giao thức TCP cũng như cơ chế truyền lại nhằm nâng cao hiệu quả truyền
thông của mạng OBS.
TÀI LIỆU THAM KHẢO
[1] Y. Chen, C. Qiao, and X. Yu, “Optical burst switching: A new area in optical networking research,” IEEE Netw.,
vol. 18, no. 3, pp. 16-23, 2004.
[2] T. Battestilli and H. Perros, “An introduction to optical burst switching,” IEEE Commun. Mag., vol. 41, no. 8, pp.
S10-S15, 2003.
[3] Y. Xiong, M. Vandenhoute, and H. C. Cankaya, “Control architecture in optical burst-switched WDM networks,”
IEEE J. Sel. Areas Commun., vol. 18, no. 10, pp. 1838-1851, 2000.
[4] Xians Yu, Chunming Qiao, and Yona Liu, “TCP implementations and false time out detection in OBS networks,”
2005.
[5] A. Rajabi, A. Dadlani, F. Hormozdiari, A. Khonsari, A. Kianrad, and H. S. Razi, “Analysis of the impact of
wavelength converters on contention resolution in optical burst switching,” in Proceedings - 2nd Asia
International Conference on Modelling and Simulation, AMS 2008, 2008.
[6] S. K. Lee, K. Sriram, H. S. Kim, and J. S. Song, “Contention-based limited deflection routing protocol in optical
burst-switched networks,” IEEE J. Sel. Areas Commun., 2005.
[7] D. Tafani, C. McArdle, and L. P. Barry, “A two-moment performance analysis of optical burst switched networks
with shared fibre delay lines in a feedback configuration,” Opt. Switch. Netw., 2012.
[8] A. Maach, G. Bochmann, and H. Mouftah, “Robust optical burst switching,” 11th Int. Telecommun. Netw.
Strateg. Plan. Symp. NETWORKS 2004, pp. 447-452, 2004.
[9] J. Melorose, R. Perroy, and S. Careas, “TCP Slow Start, Congestion Avoidance, Fast Retransmit, and Fast
Recovery Algorithms,” Statew. Agric. L. Use Baseline 2015, 2015.
[10] L. S. Brakmo, S. W. O. Malley, and L. L. Peterson, “TCP Vegasꢀ : New Techniques for Congestion Detection
and Avoidance,” in SIGCOMM, 1994.
[11] M. Mathis, J. Mahdavi, S. Floyd, and A. Romanow, “TCP Selective Acknowledgment Options,” 1996.
344
NGHIÊN CỨU CƠ CHẾ TRUYỀN LẠI CHÙM CÓ ĐIỀU KHIỂN TRÊN MẠNG TCP/OBS
[12] Y. Hirota, H. Tode, and K. Murakami, “A Novel RWA Cooperation Method Considering Retransmission In
Optical Burst Switched Networks BurstData Crossconnect,” pp. 6-8, 2006.
[13] X. Yu, J. Li, X. Cao, Y. Chen, and C. Qiao, “Traffic statistics and performance evaluation in optical burst
switched networks,” J. Light. Technol., vol. 22, no. 12, pp. 2722-2738, 2004.
[14] M. Casoni, “TCP window estimation for burst assembly in OBS networks,” in Proceedings - IEEE Symposium on
Computers and Communications, 2010.
[15] K. Ramantas, K. Vlachos, Ó. González de Dios, and C. Raffaelli, “TCP Traffic Analysis for Timer-Based
Burstifiers in OBS Networks,” in Optical Network Design and Modeling, 2007.
[16] S. Ozsarac and E. Karasan, “Congestion window-based adaptive burst assembly for TCP traffic in OBS
networks,” Photonic Netw. Commun., 2010.
[17] Q. Zhang, N. Charbonneau, V. M. Vokkarane, and J. P. Jue, “TCP over optical burst-switched networks with
controlled burst retransmission,” Photonic Netw. Commun., vol. 22, no. 3, pp. 299-312, 2011.
[18] V. M. V. Jason P. Jue, Optical Burst Switched Networks. Boston: Springer Science + Business Media Inc, 2005.
A STUDY ON CONTROLLED BURST RETRANSMISSION SCHEME FOR TCP OVER
OBS NETWORK
Duong Phuoc Dat, Le Manh Thanh, Vo Viet Minh Nhat
ABSTRACT: Optical Burst Switching (OBS) technology offers a promising solution for the next generation of Internet backbone,
in which TCP flows are transmitted at high speed. However, due to the impact of congestion window size when data loss occurs,
expressed in the form of a round trip time delay, the amount of data transferred to OBS networks will be limited. This reduces the
effectiveness of bandwidth utilization of OBS backbone. There have been some proposed schemes at OBS layer to control congestion
windows size in order to increase the efficiency of fiber bandwidth utilization. In this paper, we propose a controlled burst
retransmission scheme for TCP over OBS networks to limit the occurrence of TCP congestion window size reduction. The analysis
and simulation results show that the proposed controlled burst retransmission scheme has significantly improved throughput
transmitted to the core OBS networks and thus enhanced the efficiency of OBS network bandwidth utilization.
8 trang
12540
Free
Bạn đang xem tài liệu "Nghiên cứu cơ chế truyền lại chùm có điều khiển trên mạng TCP/OBS", để tải tài liệu gốc về máy hãy click vào nút Download ở trên
File đính kèm:
- nghien_cuu_co_che_truyen_lai_chum_co_dieu_khien_tren_mang_tc.pdf
