Tieu luan hoc phan mang va truyen du lieu

Theo những nghiên cứu trước, một phiên bản TCP Vegas có khả năng đạt được thông lượng cao hơn TCP truyền thống trên mạng không dây, mà những phiên bản này được sử dụng rộng rãi trong Internet ngày nay. Tuy nhiên, chúng ta cần xem xét một hướng chuyển đổi cho TCP Vegas được triển khai trên Internet. Trong đề tài này, bằng việc tập trung vào các cải tiến TCP Vegas, chúng ta sẽ nghiên cứu tính cân bằng giữa các phiên bản này. Từ sự phân tích và sự mô tả các kết quả, chúng ta nhận thấy rằng sự thực thi của TCP Vegas là tốt hơn nhiều so với sự thực thi của TCP truyền thống trên mạng không dây. Thuật toán VegasW cải tiến nâng cao thông lượng so với TCP, FeW. Theo đó, chúng ta xem xét tiếp cách tiếp cận để cải tiến là sửa đổi thuật toán điều khiển tắc nghẽn của TCP Vegas. Chúng ta sử dụng cả hai kinh nghiệm phân tích và mô phỏng cho việc đánh giá và xác nhận tính hiệu quả của các kỹ thuật đã đề xuất.

MỤC LỤC

LỜI NÓI ĐẦU

Theo những nghiên cứu trước, một phiên bản TCP Vegas có khả năng đạt được thông lượng cao hơn TCP truyền thống trên mạng không dây, mà những phiên bản này được sử dụng rộng rãi trong Internet ngày nay Tuy nhiên, chúng ta cần xem xét một hướng chuyển đổi cho TCP Vegas được triển khai trên Internet Trong đề tài này, bằng việc tập trung vào các cải tiến TCP Vegas, chúng ta sẽ nghiên cứu tính cân bằng giữa các phiên bản này Từ sự phân tích và sự mô tả các kết quả, chúng ta nhận thấy rằng

sự thực thi của TCP Vegas là tốt hơn nhiều so với sự thực thi của TCP truyền thống trên mạng không dây Thuật toán Vegas-W cải tiến nâng cao thông lượng so với TCP,

FeW Theo đó, chúng ta xem xét tiếp cách tiếp cận để cải tiến là sửa đổi thuật toán

điều khiển tắc nghẽn của TCP Vegas Chúng ta sử dụng cả hai kinh nghiệm phân tích

và mô phỏng cho việc đánh giá và xác nhận tính hiệu quả của các kỹ thuật đã đề xuất

CẢI TIẾN THÔNG LƯỢNG TCP-VEGAS TRONG MẠNG MULTIHOP AD HOC

(Improve throughput of TCP-Vegas in multihop ad hoc networks)

1 Giới thiệu

Hiệu suất của giao thức TCP truyền thống trên mạng multihop ad hoc là không hiệu quả vì những tính năng đặc biệt của mạng không dây, các vấn đề giao tiếp với thiết bị đầu cuối, lỗi truyền dẫn giữa các nút, tính di động của các nút, các biến thể cấu trúc mạng và định tuyến bất ổn định, [1] Tuy nhiên, hầu hết các ứng dụng không dây đều dựa trên giao thức TCP truyền thống để giao tiếp với hệ thống mạng có dây và TCP vẫn là giao tức vận chuyển chính cho mạng 802.11, [2] Do đó, phân tích và cải tiến hiệu suất của TCP trên mạng multihop ad hoc là quan trọng và cần thiết

Trong những năm gần đây, các nhà nghiên cứu đã có nhiều nghiên cứu cải tiến hiệu suất TCP trên mạng multihop ad hoc, [1,3-7] Hầu hết các nghiên cứu chủ yếu là xem xét tính năng của mạng không dây và lớp giao thức định tuyến ảnh hưởng đến hiệu suất của TCP Các gói tin bị mất do các router quá tải hoặc lỗi truyền dẫn được gọi là sự tắc nghẽn và được xử lý bằng các cơ chế tránh tắc nghẽn khác nhau

Một nguyên nhân khác ít được quan tâm làm hiệu suất của TCP trên mạng multihop ad hoc thấp là cơ chế tăng kích thước cửa sổ của TCP Nalm và các đồng nghiệp, [2] trong chương này đã báo cáo kết quả và đề suất một bước cải tiến về thông lượng TCP-Newreno

Tuy nhiên, cơ chế kiểm soát của các biến thể TCP là khác nhau và do đó hiệu suất trên mạng multihop ad hoc là khác nhau Ứng dụng TCP trên mạng multihop ad hoc phải xét đến những đặc tính riêng của các biến thể TCP Cơ chế quản lí cửa sổ của TCP-Newreno [8] và quản lí thời gian đợi của TCP-Vegas [9] là hai giao thức được sử phổ biến hơn Cơ chế FeW [2] đề suất là phù hợp với TCP-Newreno và hiệu suất của TCP-Newreno vẫn còn hạn chế Với Vegas, một số kết quả thử nghiệm đã được công

bố [10,11] Kết quả này cho thấy Vegas nhanh hơn so với các giao thức khác trong hầu hết các kịch bản điều chỉnh của sổ của nó dựa trên RTT Để hiểu hơn, ta xem xét một

số tính năng của Vegas và đề suất cải tiến thuật toán

Do đó, trong bài báo này, chúng tôi tập trung phân tích hiệu quả của TCP-Vegas

và đề suất thuật toán mới nâng cao thông lượng Trước tiên, chúng ta phân tích ảnh hưởng của Vegas trên mạng multihop ad hoc với cùng mô hình mạng và cửa sổ nguồn Trình kết quả phân tích tổng hợp và thông lượng trung bình trên mỗi kích thước cửa

sổ Sau đó, trên nguyên tắc tối đa hóa, TCP nguồn giữ thông lượng trung bình lớn nhất với xác suất tốt nhất Hiệu quả của Vegas trên mạng multihop ad hoc là tổng thông lượng của các luồng trên mạng tăng Khi cửa sổ ở mức tối thiểu, cơ chế bắt đầu chậm (Slow Start) đặt lại ngưỡng r

th

W và tăng nhanh là lí do chính gây quá tải Đó là nguyên nhân chính gây ra tình trạng quá tải của mạng và xung đột tại tầng MAC, tầng định tuyến phản ứng bằng cách giảm thông lượng

Dựa trên những phân tích, các nhà khoa học đề xuất một Vegas sửa đổi, được gọi là Vegas-W, trong đó cải thiện bốn phương diện của TCP-Vegas trên mạng không dây multihop: (i) Mở rộng cửa sổ tắc nghẽn để điều chỉnh thời gian kiểm soát của TCP gửi; (ii) Thay đổi cơ chế thăm dò trong giai đoạn Slow Start bằng cách giữ cửa

sổ tắc nghẽn ổn định cho đến khi số các ACK nhận được lớn hơn ngưỡng (Threshold); (iii) Mức tăng cửa sổ trong cơ chế tránh tắc nghẽn tương tự như cơ chế Slow Start, nhưng với ngưỡng lớn hơn; (iv) Cập nhật ngưỡng Slow Start r

th

W để theo dõi sự ổn định; Kết quả mô phỏng cho thấy Vegas-W cải thiện đáng kể thông lượng so với Vegas qua nhiều kịch bản

Phần còn lại của bài báo được tổ chức như sau: Các thông tin cở bản của TCP-Vegas và các vấn đề liên quan được trình bày trong phần 2 Phần 3 trình bày mô hình của TCP-Vegas-W và thuật toán Đánh giá hiệu suất của Vegas-W qua NS2 trong phần

4 Bài báo kết luận trong phần 5

2 Các thông tin cở bản của TCP-Vegas và các vấn đề liên quan

2.1 TCP-Vegas

TCP-Vegas là giao thức dựa trên thời gian chờ, điều chỉnh cửa sổ theo các giai đoạn thực hiện và tỉ lệ ∆ giữa thời gian gửi thực và thời gian ước tính Ba ngưỡng α, β

và γ được xác định trong Vegas TCP so sánh Δ và γ trong cơ chế Slow Start và với α,

β trong cơ chế tránh tắc nghẽn để điều chỉnh cửa sổ Vegas đặt BaseRTT cực tiểu thời

gian đi trọn một vòng và được tính tỉ lệ Expected=w/BaseRTT, trong đó w là kích

thước cửa sổ Gọi RTTa là tỉ lệ trung bình của RTT, tính tỉ lệ thực Actual=w/RTTa Sau

đó, xác định độ lệch giữa tỉ lệ thực và ước tính tỉ lệ gửi:

Δ =( Expected- Actual)* BaseRTT

Trong cơ chế bắt đầu chậm, giá trị cửa sổ tắc nghẽn nhỏ hơn ngưỡng W th Khi

nhận được một ACK mới và Δ<γ, TCP gửi tăng w thêm 1 Ngược lại, Vegas giảm kích thước cửa sổ bằng một tỉ lệ p%, đặt lại giá trị W th và chuyển sang cơ chế tránh tắc

nghẽn Cơ chế bắt đầu chậm được khởi động và kết thúc khi cửa sổ lớn hơn ngưỡng

W th Vegas kiểm soát time-out bởi một bộ đếm thời gian và kiểm tra sau mỗi 500ms Kích thước cửa sổ được cập nhật trong cơ chế bắt đầu chậm được xác định như sau:







≥

∆

−

<

∆ +

=

γ

γ

if p W

if W

W

) 1 (

*

1

(1) Khi TCP gửi thực hiện cơ chế tránh tắc nghẽn và nhận ACK mới, Vegas tăng

kích thước cửa sổ bằng

W

1

nếu Δ<α, giảm

W

1

nếu Δ>β và không đổi nếu nằm trong khoảng giữa α và β:

W=

















≥

∆

<

∆

<

−

≤

∆ +

β

β α

α

if W

if W W

if W

W

1

1

(2)

Tương tự cơ chế tránh tắc nghẽn là hai cơ chế phát lại nhanh (fast retransmit) và phục hồi nhanh (fast recovery), sẽ truyền lại các gói dữ liệu bị mất khi nhận ba ACK

trùng lặp mà không cần thời gian time-out Bên cạnh cơ chế kiểm soát thời gian, Vegas thực hiện phát lại nhanh các gói tin, cho phép Vegas truyền lại nhanh hơn so với các biến thể TCP khác Chi tiết tham khảo từ [9,12]

2.2 Các vấn đề liên quan

Những nghiên cứu trước đây về TCP trong mạng multihop ad hoc chủ yếu là phân biệt giữa gói tin mất do router quá tải hoặc lỗi truyền và những lỗi do nghẽn mạng Giao thức TCP được hoàn chỉnh, [13,14] Thời gian truyền được xác định sau mỗi lần truyền lại thay vì tăng theo cấp số nhân, [14] Dấu hiệu để phát hiện lỗi router, [14] Thông tin phản hồi thông báo quá tải router, [1,6] Khi nhận thông báo lỗi truyền dẫn, TCP nguồn đóng tất các các biến và ngừng phát để giảm tác động đến mạng multihop ad hoc

Trong khi đó, sự tương tác giữa tầng giao thức và tầng liên kết đã được nhiều bài báo trình bày Khung điều khiển của lớp MAC được sử dụng để điều khiển luồng ở tầng mạng, [15] Fu và các đồng nghiệp chỉ ra rằng thông lượng tối đa có thể đạt được dưới cửa sổ giới hạn, [3] và thuật toán LRED dùng thả rơi các gói tin giống như RED, [17] Zhai và các đồng nghiệp công bố rằng cửa sổ TCP nhỏ hơn trong mạng multihop

ad hoc và tỉ lệ kiểm soát thông lượng trên các kênh thông tin được đề xuất để cải thiện hiệu quả, [7]

Ngoài ra, một số nghiên cứu đã được thực hiện để phân tích và cải tiến hiệu suất của các biến thể TCP trên mạng multihop ad hoc Hiệu suất của các biến thể TCP

là khác nhau được so sánh tại [10, 11] Malm và các đồng nghiệp đã quan sát sự tương tác giữa các TCP, định tuyến và tầng MAC và đề xuất bước cải tiến nhỏ trên của sổ nền trên giao thức TCP-Newreno

Tuy nhiên hiệu suất của TCP-Vegas trên mạng multihop ad hoc chưa được nghiên cứu sâu Tương tác giữa Vegas và mạng, giữa Vegas và giao thức tầng MAC chưa được đề cập Do đó, trong bài báo này, chúng tôi nghiên cứu các đặc tính của TCP-Vegas trên mạng multihop ad hoc và đề xuất Vegas-W nhàm cải thiện thông lượng

3 Vegas-W

3.1 Khuôn dạng mạng

Tương tác giữa TCP đích và mạng được mô tả như hình 1, gồm ba thành phần: TCP nguồn, mạng và TCP nhận Mạng là nơi chứa dữ liệu và gói ACK với nguồn tài nguyên hạn chế, các gói tin được thả vói tỉ lệ xác suất ngẫu nhiên Tất cả TCP nguồn

gửi với tỉ lệ λ d , như hình 1 Tất cả TCP nhận phản hồi ACK với tỉ lệ λ a TCP nguồn điều chỉnh tỉ lệ gửi, được kiểm soát bởi cơ chế cửa sổ tránh tắc nghẽn, dựa trên các ACK (ACK mất, mới và lặp) và sự thay đổi của RTT, sau đó điều chỉnh thông lượng cho phù hợp Con số này tương tự như trong [12], trong khi đó các yếu tố ảnh hưởng đến hiệu suất của TCP còn bao gồm cả những đặc tính riêng của mạng không dây

Hình 1: Khuôn dạng mô hình mạng

Từ đó, tỉ lệ ACK λ a bởi tỉ lệ dữ liệu λ d, lưu lượng của mạng được xác định bằng

tỉ lệ gửi của tất cả các TCP nguồn Khả năng của mạng bị hạn chế bởi cơ sở hạ tầng, phạm vi, thuật toán tầng MAC, giao thức định tuyến,… Theo kết quả tại [3], chỉ ra ngưỡng lưu lượng tối đa mạng có thể đạt được Ngưỡng lưu lượng bằng kích thước gói

tin chia cho số luồng TCP, chúng tôi định nghĩa W* cho luồng trên cửa sổ tránh tắc

nghẽn tối ưu, trong đó tổng thông lượng của các luồng là cực đại

3.2 Mô hình cửa sổ TCP

Một nguồn Vegas với cửa sổ tối đa W m=8, các trạng thái cửa sổ được mô tả như một chuỗi Markov liên tục thể hiện trong hình 2, tương tự như trong [12] Các vòng tròn biểu diễn trạng thái khác nhau, và các giá trị bên trong là kích thước cửa sổ tránh tắc nghẽn Trạng thái 0 là thời gian chờ time-out, nơi giá trị 0 là không có truyền mới

và ACK trong giai đoạn time-out Trong khung sáng là trạng thái bình thường Trạng

thái trong hình vuông là giai đoạn bắt đầu chậm với W th =2 và W th=4 Các liên kết theo chiều dọc với trạng thái bằng 0 là lặp lại hàm mũ Các liên kết theo chiều ngang thể hiện giảm kích thước cửa sổ trong cơ chế phát lại nhanh khi nhận ACK lặp

Hình 2: Thay đổi của cửa sổ TCP nguồn

Khi tải trọng khác nhau, những xung đột tại tầng MAC sử dụng giao thức 802.11 (CSMA/CA) là khác nhau, và RTT không phải luôn luôn là hằng số như trong

mạng có dây Đối với các cửa sổ có kích thước w, giả sử có n giá trị RTT, trong đó mỗi RTT(n) có xác suất p(n), thông lượng trung bình của w là:

T w =∑n w*p(n)*

) (

1

n RTT

Thông lượng tối đa T w được xác định khi w bằng giá tri tối ưu W * Vì vậy, kích thước cửa sổ trong mạng multihop ad hoc là nhỏ thì xác suất ACK trùng lặp là thấp

Do đó, đặt π(i) là xác suất điều kiện và T w(i) là thông lượng trung bình tại thời điểm i

với cửa sổ w(i) Khi đó, thông lượng trung bình là:

∑

=

i

w i T i

Từ (3) là một là một phương trình tuyến tính và π(i) và T w(i) là tin cậy, dễ dàng kết luận rằng thông lượng tối đa đạt được khi xác suất điều kiện π của cửa sổ W* là

cực đại, được gọi là nguyên tắc tối đa hóa Điều này có nghĩa là nếu TCP nguồn ở

trạng thái W* càng lâu thì tổng thông lượng sẽ cao hơn.

3.3 Vegas-W

Căn cứ vào phân tích trên, trong phần này chúng tôi đề xuất thuật toán

Vegas-W Cải tiến của nố bao gồm bốn khía cạnh: hỗ trợ cửa sổ phân đoạn, bắt đầu chậm

hơn, giảm tắc nghẽn, và cập nhật W th Với hỗ trợ cửa sổ phân đoạn, cửa sổ được mở rộng hơn 1, giảm ảnh hưởng của vấn đề cửa sổ tối thiểu bắt đầu chậm hơn và giảm tắc nghẽn làm tăng cửa sổ nền trên giá trị delta nhằm giải quyết vấn đề cửa sổ tăng mạnh Bên cạnh đó, tốc độ tăng cửa sổ trong giai đoạn bắt đầu chậm và giai đoạn tránh tắc

nghẽn được phân biệt với các đặc tính khác nhau W th cập nhật nhằm tránh cửa sổ tăng

quá chậm khi W* lớn hơn W th

3.3.1 Hỗ trợ phân đoạn cửa sổ

Trong các mạng không dây ad hoc, W* có thể được phân đoạn, thậm chí ít hơn

một, nó yêu cầu TCP nguồn gửi số phân đoạn của gói dữ liệu trong mỗi RTT Ảnh

hưởng của phần thập phân khi W*>1 là không nhiều như khi W*<1, vì phần nguyên số lượng các gói tin trong mỗi RTT khi W*<1 mới gây ra tình trạng quá tải của mạng Do

đó, phân đoạn hỗ trợ cửa sổ chỉ đề xuất phân đoạn cửa sổ khi W* <1 Tối ưu cửa sổ

trong Vegas-W là thiết lập một hỗ trợ phân đoạn cửa sổ

Giả sử rằng Nfw time-out liên tiếp xảy ra là dấu hiệu yêu cầu phân đoạn cửa sổ

Để đơn giản, cửa sổ thiết lập bằng 0.5 khi yêu cầu xuất hiện Thời gian kiểm soát được đặt dưới quá trình TCP gửi, được xác lập khi cửa sổ ít hơn một và ngừng trong các trường hợp còn lại Khoảng thời gian thiết lập RTT chia bởi kích thước cửa sổ và cập nhật RTT Khi xảy ra time-out, TCP nguồn gửi dữ liệu và lập lịch

3.3.2 Cơ chế Slow Start

Trong cơ chế bắt đầu chậm, Vegas truyền thống tăng cửa sổ khi nhận được một ACK mới và Δ nhỏ hơn γ Cơ chế bắt đầu chậm đề xuất trong Vegas-W thăm dò mạng với ít nhất một RTT và giữ cửa sổ không đổi cho đến khi số ACK nhận được lớn hơn

ngưỡng Đặt nS biểu thị số ACK nhận được thỏa Δ< γ trong cơ chế bắt đầu chậm Đặt

NS biểu thị ngưỡng tăng cửa sổ Khi nS nhỏ hơn NS và tính Δ trên RTT nhỏ hơn γ, cửa

sổ không đổi và tăng nS lên 1 Khi nS lớn hơn NS thì cửa sổ tăng thêm 1 và nS đặt lại

bằng 0 Cửa sổ giảm một lượng p% tương tự như trong Vegas Quá trình bắt đầu chậm

được mô tả như sau:









≥

∆

−

>

<

∆ +

≤

<

∆

=

γ γ γ

if p W

N n if

W

N n if

W

S S

) 1 (

*

&

1

&

(4)

3.3.3 Giảm tắc nghẽn

Đặt nCA là số ACK nhận được thỏa Δ<α trong cơ chế tránh tắc nghẽn Đặt NCA

biểu thị ngưỡng tăng cửa sổ Khi nCA nhỏ hơn NCA và Δ nhỏ hơn α thì cửa sổ không đổi

và nCA tăng 1 Khi nCA lớn hơn NCA thì cửa sổ tránh tắc nghẽn tăng

W

1

và nCA đặt lại bằng 0 Khi Δ trong khoảng α và β thì nCA không đổi Các giá trị khác tương tự như Vegas Giảm tắc nghẽn được mô tả như sau:















≥

∆

−

≤

≤

∆

<

∆

<

>

≤

∆ +

=

β

α β

α

α

if W W

N n or

if W

N n if

W

W

CA CA

1

&

&

1

(5)

Với giảm tắc nghẽn, chúng tôi làm chậm tốc độ tăng cửa sổ trong giai đoạn

tránh tắc nghẽn và làm cho cửa sổ ổn định ở mức tối ưu W* trong thời gian dài với

ngưỡng tăng cửa sổ NCA

Cơ chế tránh tắc nghẽn và bắt đầu chậm là hai cơ chế trong giao thức TCP có những đặc tính khác nhau Trong cơ chế tránh tắc nghẽn, TCP nguồn ước đoán băng thông của mạng và giao động xung quanh ngưỡng ổn định Do đó bước tăng là nhỏ để tránh gây ra tình trạng quá tải của hệ thống mạng Trong cơ chế bắt đầu chậm, các TCP

nguồn không biết tình trạng mạng và W* có thể lớn Nếu cửa sổ tăng chậm trong cơ

chế tránh tắc nghẽn, băng thông sẽ lãng phí sau khi xuất hiện time-out Vì vậy, mức

tăng cửa sổ trong cơ chế bắt đầu chậm nên được nhanh hơn Sự khác nhau của ngưỡng

tăng cửa sổ N s và N CA phản ánh tính năng đặc biệt của hai cơ chế

3.3.4 Cập nhật W th

Trong Vegas truyền thống, W th được thiết lập bằng một nửa kích thước cửa sổ khi xuất hiện time-out Điều này phù hợp cho các mạng có dây, nơi mất gói tin là chỉ

do tràn bội nhớ đệm Trong mạng không dây ad hoc, gói tin rơi do các lỗi vật lí hoặc

xung đột tại tầng MAC, đó không phải là dấu hiệu của tắc nghẽn thực W th nên không phải luôn giảm một nửa khi time-out xuất hiện Đối với mạng không dây ad hoc, băng thông tương đối ổn định Cửa sổ tăng chậm khi áp dụng cơ chế giảm tắc nghẽn trong

Vegas-W, và khoảng cách lớn giữa W th và W* sẽ lãng phí băng thông.

Ngoài ra, ngưỡng r

th

W tương đối lớn so với W* là lí do cho hiệu suất kém, mà

nó vẫn tồn tại khi cơ chế bắt đầu chậm được thực hiện

Vì vậy, phương pháp điều chỉnh W th trong Vegas truyền thống nên được thay

đổi cho phù hợp với mạng multihop ad hoc Cập nhật W th được đề xuất dựa trên quan

sát W* Ước tính giá trị cửa sổ tối ưu W* là khó khăn, W* được xem như là cửa sổ ổn

định khi TCP nguồn ổn định trong thời gian dài trên ngưỡng, nơi thời gian xác định

bởi RTT Cập nhật W th bao gồm hai phần: một là đặt lại W th khi nhận được ACK mới,

hai là giảm W th khi xuất hiện time-out

Đặt nsCA biểu thị số khoảng RTT ổn định trong cửa sổ W s trong cơ chế tránh tắc nghẽn Khi Δ nằm trong khoảng α và β, ns CA tăng thêm 1, hoặc không đổi Khi ns CA lớn

hơn ngưỡng NS CA thì W th thiết lập bằng kích thước cửa sổ và ns CA đặt bằng 0 Khi cửa

sổ hiện tại lớn hơn W s , ns CA đặt bằng 0 và W s đặt bằng kích thước cửa sổ hiện tại Cập

nhật W th khi nhận được một ACK mới thể hiện như sau:

Algorithm 1: W th update when receive a new ACK

Initialization: Receive a new ACK with sequence number equal to or large than beg_seqno

1 Calculate Expected and Actual

2 Calculate the integral number of packets congested:

∆=(int)((Expected-Actual)*baseRTT+0.5))

3 If w < Wth