Tieu luan hoc phan mang va truyen du lieu

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.

1


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
2


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
r
(Slow Start) đặt lại ngưỡng Wth 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,
r
nhưng với ngưỡng lớn hơn; (iv). Cập nhật ngưỡng Slow Start Wth để 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 TCPVegas 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.

3


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 Wth. 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ị Wth 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
Wth. 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
 W +1
W =
W * (1 − p ) if

∆<γ
∆≥γ

(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

1
1
nếu Δ<α, giảm
nếu Δ>β và không đổi nếu nằm trong
W
W

khoảng giữa α và β:
1


W + W

1
W= W −
W

W



if

∆ ≤α

if

α <∆<β

if

∆≥β

(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
4


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.
5

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 Wm=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
6


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 Wth=2 và Wth=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à:
Tw=∑nw*p(n)*

1
RTT (n)

Thông lượng tối đa Tw đượ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à Tw(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à:
T = ∑ π (i ).Tw (i )
i

(3)

Từ (3) là một là một phương trình tuyến tính và π(i) và Tw(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à
7


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 VegasW. 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 Wth. 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. Wth cập nhật nhằm tránh cửa sổ tăng
quá chậm khi W* lớn hơn Wth.
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
8


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 n S 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à n S đặ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:
W

W
if


=  W +1
if
W * (1 − p ) if


∆ < γ & nS ≤ N S
∆ < γ & nS > N S
∆≥γ

(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 N CA
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

1
và nCA đặt lại
W

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:
1


W + W

W = W

1
W − W


if

∆ ≤ α & nCA > N CA

if

α < ∆ < β or ∆ ≤ α & nCA ≤ N CA

if

∆≥β

(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

9


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ổ Ns và NCA phản ánh tính năng đặc biệt của hai cơ chế.
3.3.4 Cập nhật Wth
Trong Vegas truyền thống, Wth đượ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. Wth 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 Wth và W* sẽ lãng phí băng thông.
Ngoài ra, ngưỡng Wthr 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 Wth 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 Wth đượ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 Wth bao gồm hai phần: một là đặt lại Wth khi nhận được ACK mới,
hai là giảm Wth khi xuất hiện time-out.
Đặt nsCA biểu thị số khoảng RTT ổn định trong cửa sổ Ws trong cơ chế tránh tắc
nghẽn. Khi Δ nằm trong khoảng α và β, nsCA tăng thêm 1, hoặc không đổi. Khi nsCA lớn
hơn ngưỡng NSCA thì Wth thiết lập bằng kích thước cửa sổ và nsCA đặt bằng 0. Khi cửa
sổ hiện tại lớn hơn Ws, nsCA đặt bằng 0 và Ws đặt bằng kích thước cửa sổ hiện tại. Cập
nhật Wth khi nhận được một ACK mới thể hiện như sau:
Algorithm 1: Wth 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
10


4.
If ∆>γ
5.
Wth=current window minus 1
6.
End
Receive
7. Else
a
new
8.
If ∆<α
ACK
ctual)*baseRTT+0.5))
9.
nsCA keeps unchanged ∆=(int)((Expected-a
10.
End
11.
If ∆>β
w < Wth and ∆>γ

12.
NSCA=0
false
13.
End
false
∆<α
14.
If α<∆<β
true
15.
If currentwindow>WS
nsCA keeps unchanged
16.
nsCA=0
17.
WS=currentwindow
false
∆>β
18.
End
true
19.
nsCA=nsCA+1
NSCA=0
20.
If nsCA>NSCA
21.
Wth=w
22.

nsCA=0
α<∆<β and
true
currentwindo
23.
End
w>WS
24.
End
false
25. End
26. beg_seqno=sequence number of the ACK

Wth=current
window
minus 1

true

NSCA=0
WS=currentwindow
nsCA=nsCA+1
nsCA>NSCA

false

true
Wth=w
nsCA=0

End

Đặt toSS biểu thị số sự kiện time-out liên tiếp khi cửa sổ nhỏ hơn Wth. Khi toSS
lớn hơn ngưỡng TOSS giảm 1 và toSS đặt bằng 0. Wth cập nhật khi xuất hiện time-out
được thể hiện như sau:
Algorithm 2: Wth update when time-out occurs
Initialization: Time-out occurs
Time-out
occurs
1. If w2.
toSS←toSS+1
3. Else
w4.
toSS←0
false
toSS←toSS+1
5. End
6. If toSS≥ TOSS
false
7.
Wth←Wth-1
toSS≥ TOS
true
8.
toSS←0
S
Wth←Wth-1
9.

If Wth<1
toSS←0
10.
Wth←1
11.
End
12. End
W <1

true

toSS←0

false

th

true
Wth←1
End

11


4. Mô phỏng và kết quả đạt được
Trong phần này, chúng tôi đánh giá Vegas-W và so sánh với TCP-Vegas truyền
thống và FeW qua nhiều kịch bản. Do giới hạn về thời gian, chúng tôi trình bày các kết
quả chính và còn nhiều kết quả khác được giới thiệu trong các báo cáo kĩ thuật, [19].
4.1 Thiết lập mô phỏng
Chúng tôi thực hiện mô phỏng trên NS2 [20] và đánh giá hiệu suất qua DSR

[21], IEEE 802.11 [22] được thiết lập như giao thức tầng MAC. Tỉ lệ cơ bản và tỉ lệ dữ
liệu tại 802.11 tầng MAC được thiết lập 2Mbps. Các tham số khác được giữ mặc định
như trong NS2. Thời gian sống luồng TCP được đánh giá qua chuỗi, lưới và topo ngẫu
nhiên. Khoảng cách nhận là 500m, khoảng cách vận chuyển là 500m. Mô hình truyền
không dây. Kích thước gói là 1024 bytes. Ba ngưỡng α, β, γ được đặt lần lượt là 1, 3
và 1, và tham số p trong cơ chế Slow Start được đặt mặc định là

1
. Lựa chọn các tham
8

số trong Vegas-W phải xét đến tính động của thuật toán và tính ổn định của mạng. Dựa
trên kết quả mô phỏng, chúng ta chọn giá trị như sau: Nfw chỉ phân đoạn cửa sổ bằng 2;
NS và NCA chỉ mức tăng cửa sổ được thiết lập 10 và 100 để phân biệt mức tăng cửa sổ
trong nhưng giai đoạn khác nhau; hai tham số NSCA và TOSS để cập nhật Wth được thiết
lập lần lượt là 100 và 2.
4.2 Kết quả
Chuỗi là một topo chung với tài nguyên hạn chế và được chia sẻ bởi nhiều
luồng TCP. Chúng tôi kiểm tra thuật toán Vegas-W trên topo chuỗi với số nút trung
gian 4-16. Số luồng khác nhau được đặt trên chuỗi để chỉ sự thay đổi của lưu lượng.
Tất cả các luồng TCP được đặt từ nút nguồn đến nút đích được biểu thị bởi cạnh nối.
Số gồm 1, 2, 4 và 8. Thông lượng của Vegas-W, TCP-Vegas, FeW được thể hiện qua
hình 3. Nói chung, thông lượng giảm tương ứng nút trung gian tăng, sự khác nhau từ
kết quả phân tích cho thấy rằng thông lượng gần như không đổi khi số nút trung gian
lớn hơn 4. Về lý thuyết, năng lực của mạng không dây ad hoc được xác định bởi yếu tố
không gian. Tuy nhiên, thông lượng end-to-end được xác định bởi tương tác giữa TCP,
12


giao thúc định tuyến và thức tầng MAC, kênh không dây, các công nghệ sử dụng trên

tầng vật lí. Vì số nút trung gian tăng, thời gian chờ của việc điều khiển gửi tăng, thời
gian thiết lập đường truyền tăng, số gói tin rơi do đường truyền hỏng tăng. Do đó,
thông lượng end-to-end giảm.

Hình 3: Biểu đồ so sánh thông lượng giữa Vegas-W, Vegas và FeW
(a) 8 luồng, (b) 4 luồng, (c) 2 luồng và (d) 1 luồng
Chúng ta có thể thấy trong hình 3, khi số luồng là 8 và thông lượng lớn, lưu
lượng của mạng lớn, thông lượng của Vegas-W là tốt hơn của Vegas khoảng 62% và
*
tốt hơn FeW khoảng 22%. Dựa vào kết quả trên, cửa sổ tối ưu W8 cho 8 luồng là nhỏ

hơn 1. Phân đoạn cửa sổ hỗ trợ của Vegas-W mở rộng cửa sổ tránh tắc nghẽn nhỏ hơn

13


1. Wth cập nhật để điều chỉnh Wthr đến 1 và tăng chậm tốc độ tăng cửa sổ. Sự kết hợp
của hai cơ chế mới thu được thông lượng cao.
Khi số lượng luồng là 4 và lưu lượng của mạng ở mức trung bình, thông lượng
của mạng Vegas-W tốt hơn so với Vegas khoảng 87%. Cửa sổ tối ưu W4* nhỏ hơn và
gần mức 1, trong khi của Vegas truyền thống là 2. Những thay đổi của cửa sổ tối thiểu
từ 2 xuống 1, cơ chế bắt đầu chậm và cơ chế tránh tắc nghẽn làm TCP nguồn nạp thích
hợp luồng vào mạng và nâng cao thông lượng.
Khi số luồng là hai và trọng tải của mạng là lớn, thông lượng của Vegas-W lớn
hơn Vegas khoảng 27%. Lí do tương tự như kịch bản với 4 luồng vào.
Khi số luồng vào là 4 và 2, thông lượng của Vegas-W tương đương FeW. Điều
này là do các cửa sổ tối ưu là giữa 1 và 2, các cửa sổ điều chỉnh của Vegas-W tương tự
như FeW.
Khi chỉ có 1 luồng qua, thông lượng của Vegas-W và Vegas là như nhau và tốt
hơn FeW khoảng 7%. Đối với kịch bản này, W*=1, Wth=2 của Vegas truyền thống, và

TCP nguồn ổn định trong hầu hết thời gian. Vì vậy, xác suất tổn thất nhỏ và hệ thống
sẽ chạy lưu loát.
Ngưỡng tăng cửa sổ khác nhau trong các cơ chế bắt đầu chậm và tránh tắc
nghẽn và cập nhật Wth của Vegas-W kế thừa từ Vegas và làm cho thông lượng của
Vegas-W ổn định.
5. Kết luận
Thông qua bài này, chúng tôi phân tích thấy hiệu suất của Vegas thấp trên mạng
không dây ad hoc thông qua mô phỏng trên cùng một mô hình mạng thống nhất và cửa
sổ TCP nguồn. Chúng tôi xác định lí do chính là cửa sổ tối thiểu, đặt lại ngưỡng của cơ
chế bắt đầu chậm Wthr và cửa sổ tăng nhanh. Sau đó chúng tôi đề xuất một thuật toán
mới, được gọi là Vegas-W, trong đó xét đến những đặc tính của mạng không đây ad
hoc và cải tiến Vegas truyền thống trong 4 phương diện: hỗ trợ cửa sổ phân đoạn, bắt
14


đầu chậm hơn, giảm tắc nghẽn và cập nhật Wth. Chúng tôi đánh giá Vegas-W qua NS2
và so sánh với Vegas và FeW qua một loạt các topo mạng khác nhau. Kết quả mô
phỏng cho thấy rằng thông lượng Vegas-W cao hơn Vegas lên đến 87% và hơn FeW
lên đến 22%.

Hình 4: Biểu đồ đánh giá thông lượng.
Làm thế nào để thiết lập mô hình toán toàn diện hơn và phân tích sự tương tác
giữa TCP nguồn và mạng, giữa TCP, định tuyến và giao thức tầng MAC trên mạng
multihop ad hoc được dành cho phần sau.

15


TÀI LIỆU THAM KHẢO
[1] G. Holland, N. Vaidya, Analysis of tcp performance over mobile ad hoc networks,

in: Proceedings of the IEEE/ACM MOBICOM, August 1999.
[2] K. Nahm, A. Helmy, C.-C. Jay Kuo, TCP over multihop 802.11 networks: issues
and performance enhancement, in: Proceedings of the ACM MobiHoc, UrbanaChampaign, IL, USA, May 2005.
[3] Z. Fu, P. Zerfos, H. Luo, S. Lu, L. Zhang, M. Gerla, The impact of multihop
wireless channel on tcp throughput and loss, in: Proceedings of the IEEE INFOCOM,
San Francisco, USA, March 2003.
[4] K. Xu, M. Gerla, L. Qi, Y. Shu, Enhancing tcp fairness in ad hoc wireless networks
using neighborhood red, in: Proceedings of the MobiCom, San Diego, California,
USA, September 2003.
[5] Z. Fu, X. Meng, S. Lu, How bad tcp can perform in mobile ad hoc networks, in:
IEEE International Symposium on Computers and Communications (ISCC’02),
Taormina, Italy, July 2002.
[6] K. Chandran, S. Raghunathan, S. Venkatesan, R. Prakash, A feedback-based
scheme for improving TCP performance in ad hoc wireless networks, in: IEEE PacificRim Conference on Multimedia, vol. 8, no. 1, February 2001.
[7] H. Zhai, X. Chen, Y. Fang, Rate-based transport control for mobile ad hoc
networks, in: Proceedings of the IEEE WCNC, New Orleans, LA USA, March 2005.
[8] S. Floyd, T. Henderson, RFC2582: the NewReno modification to TCP’s fast
recovery algorithm, April 1999.
[9] L.S. Brakmo, S.W. O’Malley, L.L. Peterson, TCP vegas: new techniques for
congestion detection and avoidance, in: Proceedings of the ACM SIGCOMM, October
1994.
16


[10] M. Yahia, J. Bíró, Behavior of TCP algorithms on ad-hoc networks based on
different routing protocols (MANETS) and propagation models, in: Proceedings of the
ICWMC, Bucharest, Romania, July 2006.
[11] M. Berger, S. Lima, A. Manoussakis, J. Pulgarin, B. Sanchez, A performance
comparison of TCP protocols over mobile ad hoc wireless networks, in: Proceedings
of the CERMA, Cuernavaca, Mexico, December 2006.

[12] A. Wierman, T. Osogami, Jörgen Olsén, A unified framework for modeling TCPVegas, TCP-SACK, and TCP-Reno, in: Proceedings of the MASCOTS, Orlando, FL,
USA, October 2003.
[13] T.D. Dyer, R.V. Boppana, A comparison of TCP performance over three routing
protocols for mobile ad hoc netwoks, in: Proceedings of the ACM MobiHoc, October
2001.
[14] F. Wang, Y. Zhang, Improving TCP performance over mobile ad-hoc networks
with out-of-order detection and response, in: Proceedings of the ACM MobiHoc,
Lausanne, Switzerland, June 2002.
[15] H. Zhai, Y. Fang, Distributed flow control and medium access in multihop ad hoc
networks, IEEE Trans. Mobile Comput. 5 (11) (2006) 1503–1514.
[16] K. Chen, Y. Xue, K. Nahrstedt, On setting TCP’s congestion window limit in
mobile ad hoc network, in: Proceedings of the IEEE ICC, Anchorage, Alaska, May
2003.
[17] S. Floyd, V. Jacobson, Random early detection gateways for congestion
avoidance, IEEE/ACM Trans. Netw. 1 (4) (1993). August.
[18] J. Li, C. Blake, D.S.J. De Couto, H.I. Lee, R. Morris, Capacity of ad hoc wireless
networks, in: Proceedings of MobiCom, Rome, Italy, July 2001.

17


[19] L. Ding, X. Wang, Y. Xu, W. Zhang, Y. Liu, Improve throughput of TCP-Vegas in
multihop ad hoc networks, Department of Electronic Engineering, Shanghai Jiaotong
University,

China,

Technical

Report,

2007.

Available

from:

< />[20] The Network Simulator – ns2. Available from: < />[21] D. Johnson, D. Maltz, Y. Hu, The dynamic source routing for mobile ad hoc
networks, IETF Internet Draft, July 2004. Available from:
< />[22] IEEE 802.11 WG, Part 11: Wireless lan medium access control (mac) and
physical layer (phy) specification, Standard, IEEE, August 1999.

18