Nghiên cứu cơ chế truyền lại chùm có điều khiển trên mạng TCP/OBS

Chia sẻ: _ _ | Ngày: | Loại File: PDF | Số trang:8

Thêm vào BST

Báo xấu

25
lượt xem 3
download

Download Vui lòng tải xuống để xem tài liệu đầy đủ

Bài viết này sẽ trình bày một hướng tiếp cận đ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.

Chủ đề:

Bình luận(0) Đăng nhập để gửi bình luận!

Lưu

Nội dung Text: 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ế dpdat@hueuni.edu.vn, lmthanh@hueuni.edu.vn, vvmnhat@hueuni.edu.vn 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ập hợp chùm Tách chùm Mạng IP I Mạng OBS E Mạng IP TCP nhận TCP phát (TCP Receiver) (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 S Xóa bản sao chùm khiển TTLb >= toffset Kết thúc khỏi bộ đêm 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 E5 10 Gbps 10 Gbps E1 E6 10 Gbps 10 Gbps 10 Gbps 30 Gbps 10 Gbps E2 C0 C1 E7 10 Gbps 10 Gbps E3 E8 10 Gbps 10 Gbps E4 E9 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.