ĐẠI HỌC QUỐC GIA HÀ NỘI

TRƯỜNG ĐẠI HỌC CÔNG NGHỆ

HOÀNG TRỌNG THỦY

ĐẢM BẢO CHẤT LƯỢNG DỊCH VỤ CHO TRUYỀN

THÔNG ĐA PHƯƠNG TIỆN THỜI GIAN THỰC
TRÊN INTERNET

NGÀNH: CÔNG NGHỆ THÔNG TIN

CHUYÊN NGÀNH: TRUYỀN DỮ LIỆU VÀ MẠNG MÁY TÍNH
MÃ SỐ:

LUẬN VĂN THẠC SĨ NGÀNH CÔNG NGHỆ THÔNG TIN

GVHD: PGS TS Nguyễn Đình Việt

Hà Nội - 2016
 LỜI CAM ĐOAN

Tôi xin cam đoan rằng đây là công trình nghiên cứu của cá nhân tôi dưới sự hướng dẫn
giúp đỡ của PGS TS. Nguyễn Đình Việt. Các kết quả được viết chung với các tác giả
khác đều được sự đồng ý của tác giả trước khi đưa vào luận văn. Trong toàn bộ nội dung
nghiên cứu của luận văn, các vấn đề được trình bày đều là những tìm hiểu và nghiên cứu
của chính cá nhân tôi hoặc là được trích dẫn từ các nguồn tài liệu có ghi tham khảo rõ
ràng, hợp pháp.

Trong luận văn, tôi có tham khảo đến một số tài liệu của một số tác giả được liệt kê tại
mục tài liệu tham khảo.

Hà nội, tháng 11 năm 2016

Tác giả luận văn

Hoàng Trọng Thủy

 LỜI CẢM ƠN

Để hoàn thành tốt luận văn này, đầu tiên tôi xin bày tỏ lòng biết ơn chân thành và
sâu sắc đến Thầy Nguyễn Đình Việt, người đã tận tình và trực tiếp hướng dẫn tôi trong
suốt quá trình triển khai và nghiên cứu đề tài, tạo điều kiện để tôi hoàn thành luận văn
này.

Thứ hai, tôi xin bày tỏ lòng biết ơn chân thành tới toàn thể các thầy cô giáo trong
khoa Công nghệ thông tin, trường Đại học Công nghệ, Đại học Quốc gia Hà Nội đã dạy
bảo tận tình tôi trong suốt quá trình tôi học tập tại khoa.

Cuối cùng tôi xin chân thành cảm ơn tới gia đình, bạn bè, đồng nghiệp đã luôn bên
em cổ vũ, động viên, giúp đỡ tôi trong suốt quá trình học tập và thực hiện luận văn.

Mặc dù đã cố gắng hoàn thành luận văn trong phạm vi và khả năng cho phép nhưng
chắc chắn sẽ không tránh khỏi những thiếu sót. tôi rất mong được sự góp ý chân thành
của thầy cô và các bạn để tôi hoàn thiện luận văn của mình.

Tôi xin chân thành cảm ơn!

Hà Nội, tháng 11 năm 2016

Học viên

Hoàng Trọng Thủy

 MỤC LỤC

Chương 1. GIỚI THIỆU .................................................................................................. 2

1.1. Tổng quan về bộ giao thức TCP/IP và sự phát triển của mạng Internet .............. 2
Giới thiệu chung ..................................................................................................... 2
1.2. Tổng quan về truyền thông đa phương tiện (Multimedia) và chất lượng dịch vụ
(QoS) ........................................................................................................................... 3
1.2.1. Giới thiệu chung về truyền thông đa phương tiện (Multimedia) .................. 3
1.2.2. Giới thiệu chung về chất lượng dịch vụ (QoS) ............................................. 4
1.3. Kiến trúc QoS cở bản ........................................................................................... 8
1.3.1. QoS nhận dạng và đánh dấu ......................................................................... 8
1.3.2. QoS trong một thiết bị mạng ........................................................................ 9
1.4. Các mô hình đảm bảo chất lượng dịch vụ............................................................ 9
1.4.1. Mô hình các dịch vụ được tích hợp IntServ ................................................. 9
1.4.2. Mô hình các dịch vụ phân biệt DiffServ ..................................................... 12
1.5. Kiến trúc DiffServ trong bộ mô phỏng NS2 ...................................................... 17
1.5.1. Router MRED (Milti RED) ........................................................................ 18
1.5.2. Các cơ chế đánh dấu gói tin và chính sách phục vụ ................................... 18
1.5.3. Các cơ chế lập lịch hàng đợi ....................................................................... 20
1.6. Thách thức của việc truyền thông đa phương tiện trên Internet hiện nay.......... 20
1.6.1. Hạn chế của việc truyền thông đa phương tiện hiện nay ............................ 20
1.6.2. Các phương pháp đảm bảo chất lượng dịch vụ trên nền các dịch vụ cố gắng
tối đa (best effort) ................................................................................................. 20
Chương 2. CÁC CHIẾN LƯỢC QUẢN LÝ HÀNG ĐỢI VÀ KHẢ NĂNG ÁP DỤNG
ĐỂ ĐẢM BẢO QOS CHO TRUYỀN THÔNG ĐA PHƯƠNG TIỆN THỜI GIAN
THỰC ............................................................................................................................ 21
2.1. Các chiến lược quản lý hàng đợi truyền thống .................................................. 21
2.1.1. Hàng đợi FIFO (First in first out) ............................................................... 21
2.1.2. Chiến lược hàng đợi ưu tiên PQ ( Priority Queue ) .................................... 22
2.1.3. Chiến lược Packet-Based Round Robin ..................................................... 23
2.1.4. Bộ lập lịch lý tưởng GPS - Generalized Processor Sharing ....................... 24
 2.1.5. Chiến lược Flow-Based Weighted Fair Queuing (WFQ) .......................... 24
2.1.6. Chiến lược Class-Based Weighted Fair Queuing (CBQ) ........................... 27
2.2. CÁC CHIẾN LƯỢC QUẢN LÝ HÀNG ĐỢI ĐỘNG ...................................... 29
2.2.1. Chiến lược quản lý hàng đợi truyền thống và hệ quả ................................. 29
2.2.2. Ưu điểm các chiến lược quản lý hàng đợi động ......................................... 30
2.2.3. Thuật toán RED trong chiến lược quản lý hàng đợi động .......................... 32
2.2.4. Thuật toán A-RED ...................................................................................... 39
2.2.5. Thuật toán RIO ........................................................................................... 41
2.2.6. Thuật toán A-RIO ....................................................................................... 44
Chương 3. ĐÁNH GIÁ HIỆU QUẢ ĐẢM BẢO QOS CHO TRUYỀN THÔNG ĐA
PHƯƠNG TIỆN THỜI GIAN THỰC CỦA MỘT SỐ CHIẾN LƯỢC QUẢN LÝ
HÀNG ĐỢI.................................................................................................................... 46
3.1. Đánh giá bằng mô phỏng hiệu quả của thuật toán RED .................................... 46
3.2. Đánh giá bằng mô phỏng việc áp dụng kiến trúc mạng Diffserv có sử dụng
RED ........................................................................................................................... 49
3.2.1. Cấu hình mạng mô phỏng ........................................................................... 50
3.3. Kết luận và hướng nghiên cứu tiếp theo ............................................................ 58
TÀI LIỆU THAM KHẢO ............................................................................................. 59
DANH SÁCH CÁC KÝ HIỆU VÀ CHỮ VIẾT TẮT

STT Từ viết tắt Từ hoặc cụm từ Ý nghĩa

1 ACL Access Control Lists Danh sách điều khiển truy cập

2 AF Assured Forwarding

Additive-Increase Tăng theo cấp số cộng, giảm

3 AIMD
Multiplicative-Decrease theo cấp số nhân

Active Queue Quản lý hàng đợi động

4 AQM
Management

Adaptive – RED with Thuật toán RED thích nghi với

5 A-RIO
In/Out bit bit In/Out

Class-Based Weighted
6 CBQ
Fair Queuing

7 CBR Constant Bit Rate

8 CBS Committed Burst Size Kích thước cụm cam kết

Committed Information Tốc độ thông tin cam kết

9 CIR
Rate

10 CP Code Point

11 DiffServ Differentiated Services Dịch vụ phân biệt

12 EBS Excess Burst Size Kích thước cụm vượt mức

Explicit Congestion Cờ thông báo tắc nghẽn

13 ECN
Notification

14 EF Expedited Forwarding

15 FIFO First In First Out

16 FTP File Transfer Protocol Giao thức truyền file

17 IntServ Integrated Services Dịch vụ tích hợp

18 IP Internet Protocol

19 ISP Internet Service Provider Nhà cung cấp dịch vụ

20 LAN Local Area Network Mạng cục bộ

21 NS Network Simulator

22 PBS Peak Burst Size Kích thước cụm tối đa

23 PIR Peak Information Rate Kích thước cam kết tối đa

24 PQ Priority Queue Hàng đợi ưu tiên

25 PRI Priority

26 PHB Per-Hop Behavior Đối xử theo chặng

27 QoS Quality of Service Chất lượng dịch vụ

Random Early Detection/ Phát hiện sớm ngẫu nhiên, Loại

28 RED
Random Early Drop bỏ sớm ngẫu nhiên

29 RIO RED with In/Out bit

30 RIO – C Rio Coupled

31 RIO - D Rio DeCoupled

32 RR Round Robin

Resource Revervation Giao thức dành trước tài

33 RSVP
Protocol nguyên
 Transmission Control Giao thức điều khiển truyền
34 TCP
Protocol vận

35 TSW Time Sliding Window Cửa sổ thời gian trượt

36 UDP User Datagram Protocol

37 WAN Wide Area Network Mạng diện rộng

Flow-Based Weighted Hàng đợi luồng có trọng số

38 WFQ
Fair Queuing

Weighted Interleaved
39 WIRR
Round Robin
 DANH MỤC CÁC HÌNH VẼ, ĐỒ THỊ

Hình 1.1. Sự phát triển của QoS........................................................................................

Hình 1.2. Các kỹ thuật QoS ...............................................................................................

Hình 1.3. Mô hình nguyên lý hoạt động của giao thức RSVP ...........................................

Hình 1.4. Kiến trúc DiffServ đơn giản ..............................................................................

Hình 1.4. Phân loại và đánh dấu gói tin ở router biên .....................................................

Hình 2.1. Cơ chế phục vụ FIFO ........................................................................................

Hình 2.2. Cơ chế phục vụ hàng đợi ưu tiên .......................................................................

Hình 2.3. Cơ chế phục vụ hàng đợi Packet-Based Round Robin ......................................

Hình 2.4. Cơ chế WFQ ......................................................................................................

Hình 2.5. IP Precedence bits .............................................................................................

Hình 2.5. Chia sẻ băng thông trong CBQ .........................................................................

Hình 2.7. Giải thuật tổng quát cho RED gateway.............................................................

Hình 2.8 Giải thuật RED chi tiết .......................................................................................

Hình 2.9. Các tham số thuật toán RED .............................................................................

Hình 2.10. Giải thuật tổng quát cho A-RED gateway .......................................................

Hình 2.11. Giải thuật RIO .................................................................................................

Hình 3.1. Mô phỏng DropTail ...........................................................................................

Hình 3.2. Mô phỏng RED ..................................................................................................

Hình 3.3. Giải thuật RIO ...................................................................................................

Hình 3.4. Topo mạng mô phỏng ........................................................................................

Hình 3.5. So sánh thông lượng các kết nối UDP trường hợp tắc nghẽn ít .......................

Hình 3.6. So sánh kích thước hàng đợi trung bình trường hợp tắc nghẽn ít ....................

Hình 3.7. So sánh độ trễ hàng đợi trung bình trường hợp tắc nghẽn ít ............................
Hình 3.8 . So sánh thông lược các kết nối UDP trường hợp tắc nghẽn nhiều ..................

Hình 3.9. So sánh kích thước hàng đợi trung bình trường hợp tắc nghẽn nhiều ..............

Hình 3.10. So sánh độ trễ hàng đợi trung bình trường hợp tắc nghẽn nhiều ...................
DANH SÁCH BẢNG BIỂU

Bảng 3.1.. So sánh RED với DropTail ..............................................................................

Bảng 3.2. Thông kê gói tin trường hợp tắc nghẽn ít .........................................................

Bảng 3.3. Thống kê Từng kết nối Trường hợp tắc nghẽn ít ..............................................

Bảng 3.4. Thông kê gói tin trường hợp tắc nghẽn nhiều ...................................................

Bảng 3.5.. Thống kê Từng kết nối trường hợp tắc nghẽn nhiều ........................................
 1

MỞ ĐẦU

1. ĐẶT VẤN ĐỀ

Sự phát triển mạnh mẽ của mạng Internet ngày này kéo theo sự sự phát triển của
các ứng dụng trên Internet. Dữ liệu trao đổi trên mạng không chỉ đơn thuần là văn bản
(text) nữa mà thêm vào đó là dữ liệu đa phương tiện (multimedia) bao gồm có hình ảnh
(image), âm thanh (audio), phim, nhạc… Các ứng dụng đa phương tiện phổ biến có thể
kể đến như gọi điện qua mạng (Internet telephony), hội thảo trực tuyến (video
conferencing) hoặc các ứng dụng xem video theo yêu cầu (video on demand) càng ngày
càng được sử dụng rộng rãi. Vấn đề đảm bảo chất lượng dịch vụ (QoS) đang trở nên
quan trọng hơn bao giờ hết.

2. MỤC ĐÍCH CỦA LUẬN VĂN

Do sự bùng nổ mạng mẽ của mạng Internet như hiện nay khiến cho dữ liệu vận
chuyển quan mạng Internet trở nên khổng lồ, nhu cầu quá lớn khiến cho việc tắc nghẽn
xảy ra thường xuyên và vấn đề đặt ra là làm sao hạn chế tối đa tắc nghẽn trên mạng
Internet và duy trì sự ổn định cao nhất cho mạng. Các kỹ thuật truyền thống nhằm giảm
thiểu tắc nghẽn trên mạng ngày càng kém hiệu quả. Mục đích của luận văn là nghiên
cứu một giải pháp quản lý và điều khiển nhằm hạn chế tối đa tắc nghẽ trên mạng Internet.
Thay vì sử dụng hàng đợi FIFO truyền thống (Trong bộ mô phỏng NS2 được gọi với cái
tên DropTail) luận văn này sẽ nghiên cứu sâu các chiến lược quản lý hàng đợi động mà
tiêu biểu là RED (Random Early Detection of Congestion; Random Early Drop),
Adaptive-RED, A-RIO (Adaptive – RED with In and Out).
3. BỐ CỤC CỦA LUẬN VĂN
a) Chương 1: Giới thiệu
b) Chương 2: Các chiến lược quản lý hàng đợi và khả năng áp dụng để đảm bảo
QoS cho truyền thông đa phương tiện thời gian thực
c) Chương 3: Đánh giá hiệu quả đảm bảo QoS cho truyền thông đa phương tiện
thời gian thực của một số chiến lược quản lý hàng đợi
 2

Chương 1. GIỚI THIỆU

1.1. Tổng quan về bộ giao thức TCP/IP và sự phát triển của mạng Internet

Giới thiệu chung

Năm 1967 từ một thí nghiệm mạng do Robert L.G đề xuất. ARPA trực thuộc bộ
quốc phòng Mỹ đã kết nối 4 địa điểm đầu tiên vào tháng 7 năm 1967 gồm: Viện nghiên
cứu Standford, Đại học California tại Los Angeles, Đại học tổng hợp Utah và Đại học
California tại Santa Barbara. Đó là mạng WAN đầu tiên được xây dựng được gọi là
ARPANET sau này là mạng Internet [17]

Bộ giao thức TCP/IP chính thức ra đời năm 1983 và được coi là chuẩn đối với
ngành quân sự Mỹ và tất cả các máy tính nối với mạng ARPANET phải sử dụng theo
chuẩn mới này. Sự phát triển như vũ bão khiến cho mọi trường đại học đều muốn gia
nhập vào mạng này và việc quản lý mạng trở nên khó khăn. Chính vì lẽ đó mạng
ARPANET được tách ra thành 2 phần là MILNET và ARPANET mới vào năm 1983,
tuy tách rời nhưng hai mạng này vẫn liên kết với nhau nhờ giao thức liên mạng IP.

Sự ra đời của TCP/IP đánh dấu mốc lịch sử quan trọng và càng ngày càng hiện rõ
điểm mạnh của nó nhất là khả năng liên kết các mạng khác với nhau một cách dễ dàng.
Vào thập kỷ 80 khi hội đồng Khoa học quốc gia Mỹ NSF (Nation Science Foundation)
thành lập mạng liên kết các trung tâm máy tính lới với nhau gọi là NSFNET. Các doanh
nghiệp đã chuyển từ ARPANET sang NSFNET. Sau gần 20 năm hoạt động ARPANET
đã dừng hoạt động vào khoảng năm 1990.

Sự phát triển của backbone NSFNET và những mạng khác đã tạo ra mội trường
thuận lợi cho sự phát triển của Internet. Năm 1995 NSFNET thu lại thành một mạng
nghiên cứu và Internet thì tiếp tục phát triển. Cùng với khả năng kết nối mở Internet đã
trở thành một mạng lớn nhất thế giới, mạng của các mạng xuất hiện trong mọi linh vực
thương mại, chính trị, quân sự, xã hội… Ngày nay khi cơ sở hạ tầng của mạng Internet
được nâng cao đã làm cho nhu cầu của các ứng dụng đa phương tiện qua mạng tăng lên
nhanh chóng.
 3

1.2. Tổng quan về truyền thông đa phương tiện (Multimedia) và chất lượng dịch
vụ (QoS)

1.2.1. Giới thiệu chung về truyền thông đa phương tiện (Multimedia)

Trước đây, khi mà Internet chủ yếu là truyền data thì người ta không cần quan tâm
đến việc phân biệt và ưu tiên cho các gói tin bởi vì lúc này băng thông mạng và các tài
nguyên khác đủ để cung cấp cho các ứng dụng trong mạng, vì vậy các ISPs sẽ cung cấp
cho khách hàng của họ dịch vụ theo kiểu “Cố gắng tối đa” (Best-Effort - BE) khi đó tất
cả các khách hàng sẽ được đối xử như nhau họ chỉ khác nhau ở loại kết nối. Đây là dịch
vụ phố biến trên mạng Internet hay mạng IP nói chung. Các gói thông tin được truyền
đi theo nguyên tắc “đến trước được phục vụ trước” mà không quan tâm đến đặc tính lưu
lượng của dịch vụ là gì. Điều này dẫn đến rất khó hỗ trợ các dịch vụ đòi hỏi độ trễ thấp
như các dịch vụ thời gian thực hay video. Cho đến thời điểm này, đa phần các dịch vụ
được cung cấp bởi mạng Internet vẫn sử dụng nguyên tắc Best Effort này.

Dữ liệu truyền thông trên mạng Internet thường được chia làm 2 loại chính là dữ
liệu dạng tĩnh và dữ liệu dạng động. Các ứng dụng trên Internet truyền thống như Web,
email, file tranfer thường truyền dữ liệu dạng tĩnh. Dữ liệu được truyền một cách nhanh
nhất có thể. Tuy nhiên trộ trễ đầu cuối có thể lên tới 10s hoặc hơn vẫn chấp nhận được.

Dữ liệu động ở đây thường là Audio hoặc Video và các ứng dụng truyền thông loại
dữ liệu trên được gọi chung là ứng dụng đa phương tiện. Loại dữ liệu này rất nhạy cảm
với độ trễ nhưng lại cho phép sự mất mát gói tin trong một ngưỡng chấp nhận được.
Tính chất hoàn toàn trái ngược với các ứng dụng truyền thống nên nó đòi hỏi chất lượng
dịch vụ khác hoàn toàn với các ứng dụng truyền thống. Tùy theo từng yêu cầu về chất
lượng dịch vụ có thể chia ứng dụng đa phương tiện thành 3 lớp cơ bản sau:

 Truyền audio và video đã được lưu trữ

 Truyển audio và video thời gian thực
 Ứng dụng tương tác audio và video thời gian thực
 4

1.2.2. Giới thiệu chung về chất lượng dịch vụ (QoS)

Quality of Service – QoS: chỉ khả năng cung cấp các dịch vụ mạng cho một lưu
lượng nào đó. Mục đích chính là điều khiển băng thông, độ trễ và jitter. Giảm độ trễ,
giảm tỉ lệ mất mát gói tin cho các ứng dụng thời gian thực và tương tác trong khi vẫn
đảm bảo phục vụ tốt cho các luồng dữ liệu khác.

Theo khuyến nghị của CCITT, E800 đưa ra một tính chất chung qua QoS: “Hiệu
ứng chung của đặc tính chất lượng dịch vụ là xác định mức độ hài lòng của người sử
dụng đối với chất lượng dịch vụ”

Khuyến nghị ETR300003 của ETSI chia và cải tiến định nghĩa của ITU thành các
định nghĩa nhỏ hơn, nó phù hợp với các yêu cầu và quan điểm của các nhóm khác nhau
trong viễn thông đó là:

 Yêu cầu QoS của người sử dụng.

 Đề nghị QoS của nhà cung cấp dịch vụ.
 Sử cảm nhận QoS từ khách hàng.
 Việc thực hiện QoS của nhà cung cấp dịch vụ.
 Yêu cầu QoS của nhà cung cấp dịch vụ.

Như vậy một cách tổng quan QoS mang ý nghĩa là “Khả năng của mạng đảm bảo
và duy trì các mức thực hiện nhất định cho mỗi ứng dụng theo như yêu cầu đã chỉ rõ của
mỗi người sử dụng”. Một ý trong định nghĩa này chính là chìa khóa để hiểu được QoS
là gì từ góc nhìn của nhà cung cấp mạng. Nhà cung cấp dịch vụ mạng đảm bảo QoS
cung cấp cho người sử dụng và thực hiện các biện pháp duy trì mức QoS khi điều kiện
mạng thay đổi vì các nguyên nhận như tắc nghẽn, hỏng hóc thiết bị hay lỗi đường truyền
v. v… QoS cần được cung cấp cho mỗi ứng dụng để người sử dụng có thể chạy ứng
dụng đó tuy nhiên người sử dụng cũng cần phải tìm hiểu các thông tin từ người quản trị
để hiểu mạng phải cung cấp những gì cần thiết cho mỗi sứng dụng.

Đảm bảo chất lượng dịch vụ thường phụ thuộc nhiều vào tài nguyên của hệ thống,
việc quản lý tài nguyên đó bao gồm có:

 Tính toán hiệu suất sử dụng tài nguyên

 Dành tài nguyên cho dịch vụ
 5

 Lập lich truy cập tài nguyên

Hình 1.1: Sự phát triển của QoS

Các tham số QoS chính liên quan đến mạng bao gồm:

a) Độ trễ (Delay): là thời gian truyền 1 gói tin từ nguồn tới đích, nó phụ thuộc vào
tốc độ truyền tin. Tốc độ truyền tin càng lớn thì độ trễ càng nhỏ và ngược lại. Delay
liên quan chặt chẽ tới băng thông. Với các ứng dụng giới hạn băng thông thì băng
thông càng lớn độ trễ càng nhỏ.
b) Thông lượng (Throughput): là khả năng truyền tin được tính bằng tổn số đơn vị
dữ liệu truyền được trong 1 đơn vị thời gian ví dụ: packet/s
c) Jitter: là sự biến thiên độ trễ. Thông số QoS jitter thiết lập giới hạn lên lượng biến
đổi của độ trễ mà một ứng dụng có thể gặp phải trên mạng. Một cách chính xác
hơn thì jitter được xem như là biến động trễ.
Jitter theo lý thuyết có thể là một giá trị tương đối hoặc tuyệt đối. Ví dụ nếu trễ
mạng cho một ứng dụng được thiết lập là 100ms, jitter có thể đặt là cộng trừ 10%
độ trễ. Theo đó độ trễ đảm bảo phải dao động trong khoảng từ 90ms đến 110ms.
Mặt khác nếu giá trị jitter là 5ms thì độ trễ phải dao động trong khoảng từ 95ms
đến 105ms. Các ứng dụng nhạy cảm nhất với jitter là các ứng dụng thời gian thực
 6

như voice, video streaming nhưng lại không quan trọng đối với các ứng dụng như
web hoặc truyền file qua mạng…
Đây là vấn đề cố hữu trọng mạng chuyển mạch gói do cơ chế định tuyến và chuyển
mạch các gói tin trong mạng của cùng một luồng có thể đi theo nhiều đường khác
nhau để đến đích khi đó độ trễ của các gói tin nay là khác nhau dẫn tới việc jitter
là không thế nào tránh khỏi.
d) Tỉ lệ mất gói tin (Packet loss ratio): là số đơn vị gói tin bị mất trong một đơn vị
thời gian, đây là một tham số QoS không thường xuyên được nói đến. Bản chất
của Internet hiên nay vẫn dựa trên nền “BE” thế nên việc mất gói tin là không tránh
khỏi. Chính vì thế tham số QoS Packet loss không nên định rõ một giới hạn trên
đối với anh hưởng của lỗi mà nên cho phép người sử dụng xác định xem có lựa
chọn cách sửa lỗi bằng việc truyền lại không hoặc các cơ chế khắc phục khác.
e) Độ khả dụng (Đáng tin cậy): Các mạng tồn tại để phục vụ người sử dụng , tuy
nhiện mạng cần có các biện pháp bảo dưỡng và phòng người trước các tình huống
hỏng hóc tiềm tàng được phát hiện và dự đoán trước. Một chiến lược đúng đắn
bằng cách định kì tách các thiết bị ra khỏi mạng và thực hiện các công việc bảo
dưỡng và chẩn đoán trong một thời gian gnawns để có thể giảm thời gian ngưng
hoạt động do hỏng hóc. Thậm chí với biện pháp bảo dưỡng hoàn hảo nhất cũng
không thể tránh được các lỗi không tiên đoán trước và các lỗi nghiêm trọng của
các thiết bị và kết nối theo thời gian.
Việc bảo trì mạng dữ liệu trở nên đơn giản hơn, hầu hết mạng dữ liệu sinh ra dành
cho kinh doanh thường là từ 8h sáng đến 6h chiều từ thứ 2 đến thứ 6. Các hoạt
động bổ trở hoặc bảo trì có thể được thực hiện ngoài giờ hoặc trong các ngày nghỉ.
Internet và web đã thay đổi tất cả, một mạng toàn cầu phải giải quyết được vấn đề
rằng thực sự có một số người luôn cố gắng truy nhập vào mạng tại một số địa điểm
và thậm chí Internet còn có ích cho một số người vào giờ ngoài hành chính hơn.
Một năm có 31.536.000 giây, giả thiết rằng độ khả dụng của một mạng là 99% thì
điều này có nghĩa rằng nhà cung cấp dịch vụ có 315.360 giây hay 87,6 giờ mạng
không hoạt động trong 1 năm. Khoảng thời gian này là tương đối lớn. Nếu giá trị
này 99,99% thì sẽ tốt hơn nhiều. Tất nhiên nhà cung cấp dịch vụ cần nhiều cơ chế
 7

dự phòng và khắc phục lỗi để đảm bảo độ sẵn sàng của mạng càng cao. Ngày ngay
QoS khả dụng của mạng thường khoảng 99,995%
f) Bảo mật: Đây là một tham số mới trong danh sách các tham số QoS nhưng lại là
một tham số quan trọng, thực tế trong một số trường hợp độ bảo mật có thể được
xét ngay sau băng thông. Gầy đây sự đe dọa rông rãi của các hacker và sự lan tràn
virus trên mạng Internet toàn cầu thì tham số này càng trở nên quan trọng hơn. Hầu
hết vấn đề bảo mật liên quan tới tính riêng tư, tự tin cậy và xác nhận Server –
Client. Các vấn đề bảo mật thường được gắn với một vài hình thức của phương
pháp mật mã như mã hóa giữ liệu và giải mã. Các phương pháp trên mạng cũng
được sử dụng như xác thực (Authentication). Một tham số QoS bảo mật điển hình
có thể là “Mã hóa và xác thực đòi hỏi trên tất cả các luồn lưu lượng”. Ngày nay
tầm quan trọng của bảo mật như một tham số QoS là rất lớn không thể đánh giá
hết được
g) Ngoài ra còn một số tham số như “Kích thước mất tin” hoặc “độ tin cậy”

Hình 1.2: Các kỹ thuật QoS

 8

Mức QoS:

 Best-Effort: Đây là mức thấp nhất, dịch vụ kết nối không đảm bảo đặc trưng bởi
hàng đợi FIFO, không có sự phân loại giữa các luồng dữ liệu
 QoS Cứng: là sự đặt trước tài nguyên phục vụ cho một luồng dữ liệu xác định
trước thường được cung cấp bởi giao thức RSVP và CBR có trong kiến trúc
IntServ
 QoS Mềm: trong kiến trúc mạng phân loại (Differentiated service) dựa trên sự
phân loại các luồng dữ liệu theo nhiều mức ưu tiên thì một luồng dữ liệu nào đó
sẽ được ưu tiên phục vụ tốt hơn các luồn còn lại.

Việc lựa chọn loại dịch vụ nào để triển khai trong mạng phụ thuộc vào các yếu tố sau:

 Ứng dụng hoặc tính chất của bài toán cần giải quyết
 Chi phí cho cài đặt và triển khai dịch vụ

1.3. Kiến trúc QoS cở bản

QoS cơ bản bảo gồm có 3 phần chính

 Định dạng QoS và các kỹ thuật đánh dấu cho phép QoS phối hợp từ điểm đầu tới
điểu cuối giữa từng thành phần mạng.
 QoS trong từng thành phần mạng đơn (Các chiến lược, công cụ quản lý, lập lịch
hàng đợi).
 Các chính sách điều khiển QoS giám sát lưu lượng đầu cuối qua mạng

1.3.1. QoS nhận dạng và đánh dấu

Điểm cơ bản trong việc đảm bảo chất lượng cho các dịch vụ trên Internet là việc
ta nhận dạng, phân loại và đánh dấu được từng mức ưu tiên cho các dịch vụ để cung cấp
các chính sách phục vụ ưu tiên cho các lớp lưu lượng cũng như dịch vụ có độ ưu tiên
cao hơn các lớp còn lại. Điều này thường được thực hiện bằng cách dựa vào các trường
trong tiêu đều gói tin IP như: IP nguồn, Ip đích, Port nguồn, Port đích, hoặc các giá trị
trong trường Type Of Service…
 9

1.3.2. QoS trong một thiết bị mạng

QoS trong một thiết bị mạng thường bao gồm các cơ chế sau:

a) Quản lý tắc nghẽn: do sự phát triển của mạng Internet kéo theo sự phát triển mạnh
mẽ của các ứng dụng đa phương tiên thời gian thực, các ứng dụng này thường có
lưu lượng dữ liệu bùng nổ lớn khiến cho mạng thường xuyên xảy ra tắc nghẽn.
Nếu tắc nghẽn xảy ra thì các router sẽ phản ứng như thế nào để giảm thiểu tác hại
của tắc nghẽn.
b) Quản lý hàng đợi: Vì kích thước của hàng đợi không vô hạn và độ dài của hàng
đợi tỉ lệ với độ trễ của gói tin vậy nên cần có cơ chế quản lý hàng đợi hợp lý sao
cho lượng gói tin bị drop và độ trễ hàng đợi của gói tin là chấp nhận được cũng
như khả năng hấp thu các lưu lượng đột biệt của hàng đợi
c) Hiệu suất đường truyền: router phải có các cơ chết kết hợp để đạt được hiệu suất
đường truyền cao nhất nhằm tránh lãng phí đường truyền, mặt khác cũng cần
phải cân bằng với các tham số QoS khác như độ trễ và tỉ lệ mất gói tin.

1.4. Các mô hình đảm bảo chất lượng dịch vụ

1.4.1. Mô hình các dịch vụ được tích hợp IntServ

Mô hình IntServ (Integrated Services) được IETF (Internet Engineering Task

Force) giới thiệu vào giữa thập niên 90 và được định nghĩa trong RFC (Request For
Comments) 1633. Mô hình này nhằm cung cấp khả năng đảm bảo chất lượng dịch vụ
cho một số luồng lưu lượng bằng cách đặt trước tài nguyên từ nguồn tới đích thông qua
giao thức đặt trước tài nguyên RSVP. IntServ đưa ra khả năng cho các ứng dụng lụa
chọn trong nhiều khả năng các mức điều khiển cho các gói dữ liệu, hỗ trợ QoS theo
luồng. Nó yêu cầu kiến trúc phức hợp bao gồm phân loại, xếp hang và định trình dọc
theo một tuyến đường truyền bất kỳ từ nguồn tới đích. IntServ phát triển dựa trên nền
BestEfford Internet nhưng mở rộng cho các ứng dụng tương tác và thời gian thực.
IntServ hỗ trợ cho hai lớp ứng dụng:
Các ứng dụng thời gian thực có yêu cầu chặt chẽ về băng thông và độ trễ mà người
sử dụng không có được ở mạng chỉ hỗ trợ BestEffort
 10

Các ứng dụng truyền thống mà trong đó người sử dụng không phải quan tâm đến
lưu lượng cũng những người sử dụng khác, khi đó mạng được xem như mạng BestEffort
có mức tải thấp.
Nguyên lý căn bản của mô hình IntServ là dành riêng tai nguyên mạng: băng thông,
độ trễ,… cho từng luồng dữ liệu xuyên suốt từ nguồn phát cho tới đích. Tài nguyên này
không được chiếm dụng cho bất cứ một luồng dữ liệu nào khác, vì tài nguyên bị chiếm
dụng nhưng nếu không được sử dụng nó sẽ dẫn tới việc lãng phí tài nguyên. Sự ra đời
của kiến trúc IntServ nhằm giải quyết các vấn đề sau:
 Dịch vụ BestEfford không còn dủ đáp ứng nhu cầu sử dụng hàng ngày: Ngày càng
có nhiều ứng dụng khác nhau và có yêu cầu khác nhau về đặc tính lưu lượng được
triển khai, đồng thời người sử dụng cũng yêu cầu chất lượng ngày càng cao hơn
 Sự xuất hiền ngày càng nhiều của các ứng dụng đa phương tiện: mạng IP phải có
khả năng hỗ trợ không chỉ đơn dịch vụ mà còn hỗ trợ đa dịch vụ của nhiều loại lưu
lượng khác nhau từ voice, data cho đến video
 Tối ưu hóa hiệu suất sử dụng mạng và tài nguyên mạng: đảm bảo hiệu quả sử dụng
và đầu tư. Tài nguyên mạng sẽ được lưu trữ cho lưu lượng có độ ưu tiên cao hơn
 Cung cấp dịch vụ tốt nhất cho một lớp người sử dụng.

Các mức QoS được cung cấp bởi IntServ bao gồm:

 Dịch vụ BestEffort
 Dịch vụ đảm bảo GS (Guaranteed Service)
 Dịch vụ kiểm soát tải CL (Controlled Load)

Giao thức dành trước tài nguyên RSVP

RSVP là giao thức giành tài nguyên là giao thức được sử dụng bởi Intserv được đề
cập trong RFC2205, tự động cập nhật tình trạng đường truyền khi có lỗi xảy ra. RSVP
là giao thức điều khiển Internet được thiết kế để cài đặt chất lượng dịch vụ trên mạng IP
(RSVP không phải chỉ sử dụng dành riêng với mô hình Intserv). Về tổng quát, giao thức
RSVP hoạt động như sau: Khi một node nào đó gửi dữ liệu, nó gửi một bản tin RSVP
qua các node trung gian tới nút nhận, bản tin này chứa đặc điểm lưu lượng sẽ gửi, đặc
điểm của các node mạng trên đường đi. Node nhận sau khi nhận được thông điệp, căn
cứ vào đặc điểm lưu lượng và đặc điểm đường đi, sẽ gửi lại một thông điệp để đăng ký
 11

tài nguyên tại các node trung gian trên đường đi đó. Nếu việc đăng ký thành công, node
gửi bắt đầu truyền dữ liệu. Nếu không, thông điệp đi đến node gửi sẽ báo lỗi.

RSVP có thể mang dịch vụ yêu cầu và đáp ứng tương ứng của thành phần chấp
nhận luồng từ máy tính tới router, từ router tới router và từ router tới máy đích (hoặc
nhiều một máy). RSVP sử dụng 6 thông điệp, “Path” và “Resv”. Thông điệp Resv mang
tham số dịch vụ. Thông điệp Path bắt đầu từ nguồn và được gửi tới đích. Mục đích chính
của nó là để router biết trên kết nào sẽ chuyển tiếp thông điệp giành tài nguyên (nó cũng
bao gồm định nghĩa về đặc điểm lưu lượng của luồng). Thông điệp Error được sử dụng
khi việc giành tài nguyên thất bại. RSVP không phải là một giao thức định tuyến do đó
nó không cần xác định liên kết nào sẽ được dùng để giành trước mà nó dựa vào các giao
thức định tuyến bên dưới để xác định tuyến đường cho một luồng. Một khi tuyến đường
được xác định, RSVP bắt đầu thực hiện việc giành trước tài nguyền. Trong suốt quá
trình thiết lập để giành tài nguyên, RSVP phải được thông qua mô đun điều khiển về
chính sách và mô đun quản lý về việc chấp nhận tuyến đường. Mô đun điều khiển về
chính sách xác định xem người dùng có đủ thẩm quyền để giành được nguồn tài nguyên
hay không. Thành phần chấp nhận tuyến đường xác định xem nút đó có đủ tài nguyên
để cung cấp cho yêu cầu QoS hay không. Nếu cả hai bước kiểm tra đều tốt, các tham số
được thiết lập trong bộ phân loại gói và trong bộ lập lịch để đạt được QoS mong muốn.
Tiến trình này được thực hiện tại mọi router và máy tính dọc theo tuyến đường. Nếu có
xảy ra lỗi, thông điệp RSVP Error được tạo và quảng bá cho mọi nút.

Hình 1.3: Mô hình nguyên lý hoạt động của giao thức RSVP

Theo hình 1.1, máy gửi gửi bản tin PATH (mô tả thông tin truyền thông qua địa
chỉ IP nguồn và địa chỉ IP đích theo chiều đi) đến máy nhận để yêu cầu dành trước tài
nguyên và thiết lập một luồng truyền thông. Máy nhận nhận được bản tin PATH sẽ gửi
 12

lại máy gửi bản tin RESV (mô tả thông tin truyền thông qua địa chỉ IP nguồn và địa chỉ
IP đích theo chiều về) để thiết lập và duy trì việc dự trữ tài nguyên. Khi đi qua các router,
dựa vào hai bản tin PATH và RESV, các router đăng ký nhận dạng luồng và lưu đặc
tính luồng vào cơ sở dữ liệu.

Nếu bản tin PATH lỗi thì bản tin PathErr sẽ được sử dụng để thông báo. Tương tự,
RSVP sử dụng bản tin ResvErr để thông báo lỗi cho bản tin RESV. Bên cạnh đó, RSVP
còn dùng hai bản tin PathTear và ResvTear. PathTear sử dụng để xóa bỏ tài yêu cầu
dành tài nguyên theo hướng đi đã được thiết lập. Tương tự, ResvTear sử dụng để xóa bỏ
tài yêu cầu dành tài nguyên theo hướng về.

Tại mỗi node mạng, yêu cầu dự trữ tài nguyên gồm 2 hoạt động:

 Dự trữ tài nguyên tại một node mạng.

 Chuyển tiếp yêu cầu dự trữ tài nguyên cho các node khác còn lại trên mạng. Trong
môi trường truyền đa hướng (một máy nhận dữ liệu từ nhiều máy gửi, một máy
gửi dữ liệu tới nhiều máy nhận) các yêu cầu dự trữ tài nguyên được chuyển sang
một node khác khi node trước đó đã đáp ứng việc dự trữ các yêu cầu tài nguyên.

Một đặc điểm quan trọng của RSVP là việc giành tài nguyên được thực hiện bởi
“trạng thái mềm”. Có nghĩa là trạng thái giành tài nguyên có liên quan tới một bộ định
thời, và khi bộ định thời hết hạn, việc giành trước tài nguyên được loại bỏ. Nếu nơi nhận
muốn lưu lại trạng thái giành tài nguyên nào, nó phải đều đặn gửi các thông điệp giành
tài nguyên. Nơi gởi cũng phải thường xuyên gửi các thông điệp này. RSVP được thiết
kế dành cho kiến trúc Intserv nhưng vai trò của nó cũng được mở rộng cho giao thức
báo hiệu trong MPLS

1.4.2. Mô hình các dịch vụ phân biệt DiffServ

Sự phát triển mạnh mẽ của mạng Internet và hạ tầng mạng trong những năm gần
đây, ngày càng nhiều các tổ chức tham gia cung cấp các dịch vụ Intenet với nhiều loại
hình gói cước khác nhau, đáp ứng nhu cầu của nhiều người dùng khác nhau tùy theo khả
năng chi trả. Lượng dữ liệu vận chuyển trên Internet ngày càng tăng, để đáp ứng thực tế
 13

đó ngoài sự phát triển mạnh về phần cứng hạ tầng mạng đặc biệt là băng thông mạng,
điều quan trọng hơn là phải có những chính sách phục vụ tốt hơn tại các nút mạng.

Hình 1.4: Kiến trúc DiffServ đơn giản

Trong quá trình triển khai đảm bảo chất lượng dịch vụ cho các ứng dụng đa phương
tiện thời gian thực trên Internet, mặc dù kiến trúc IntServ đảm bảo cung cấp QoS một
cách chắc chắn nhưng lại chứa khá nhiều nhược điểm như khả năng mở rộng (scalability)
trong core network hoặc chi phí cao, cài đặt phức tạp và khó quản lý ở router vì nó phản
đảm nhiệm rất nhiều việc dẫn tới làm chậm tốc độ truyền dữ liệu và gia tăng độ trễ end-
to-end. Điều này đã tạo ra động lực cho các nghiên cứu rộng hơn để phát triển một giải
pháp cung ứng QoS phi trạng thái (stateless), đó là kiến trúc Diffserv (Differentiated
services). DiffServ trở thành giải pháp QoS thứ 2 của IETF. Diffserv trái ngược với
Intserv là dựa trên từng luồng dữ liệu, nó phân loại các gói thành một số lượng không
lớn các tập (gọi là các lớp) và do đó đạt được hiệu quả cho các mạng lớn. Các chức năng
đơn giản được thực hiện tại router lõi, trong khi các chức năng phức tạp được triển khai
tại các router biên. Tính linh động rất là cần thiết vì dịch vụ mới có thể xuất hiện và một
 14

số dịch vụ trở lên lỗi thời. Kiến trúc DiffServ khắc phục được những nhược điểm của
kiến trúc IntServ vì có tính khả triển cao. Tuy nhiên để đáp ứng được các nhu cầu đa
dạng của ứng dụng trên thực tế kiến trục được triển khai phải đi kèm các thuật toán quản
lý lưu lượng trên đó.
Các giải thuật quản lý lưu lượng có thể được phân loại theo thời gian hoạt động
của chúng hay theo khả năng điều khiển. Do đó, các giải thuật này có thể hoạt động theo
mức gói hay khối dữ liệu hay kết nối. Các nguyên lý phục vụ gói là ví dù về các giải
thuật theo mức gói hya khối số liệu, với nhiệu vụ cung cấp các phẩm chất giữa hai đầu
cưới thông qua biện pháp phân loại và lập lịch lưu lượng. Trong số các giải pháp điều
khiên lưu lượn theo từng cuộc gọi hay từng kết nối thì điểu khiển chấp nhận (admission
control) là một trong số các giải pháp phổ dụng nhất. Tùy theo vị trí hoạt động mà có
thể là tấp trung hay phân tán. Đại diện tiêu biểu cho điều khiển chấp nhận nối phân tán
là giao thức RSVP.
Nguyên lý hoạt động của mô hình DiffServ như sau: Các gói tin được phân loại ra
thành nhiều nhóm ưu tiên từ thấp đến cao tùy theo đặc điểm của từng dịch vụ, thiết bị
sẽ tiến hành cung cấp tài nguyên theo từng nhóm, nhóm nào có thứ tự cao hơn thì sẽ
được cung cấp quyền được sử dụng tài nguyên ưu tiên hơn, tài nguyên sẽ được các nhóm
thấp hơn dùng nếu nhóm trên không sử dụng nữa. Tất cả các quá trình này sẽ được thực
hiện riêng lẻ trên từng thiết bị.

Cấu trúc DiffServ

Cấu trúc của mô hình DiffServ bao gồm nhiều class lưu lượng cho từng dịch vụ cụ
thể và mỗi class được cung cấp một lượng tài nguyên xác định. Để phân biệt các class,
DiffServ sử dụng một thông tin gọi là điểm mã phân biệt dịch vụ DSCP (Differentiated
Service Code Point). DSCP có tiền thân là vùng ToS (Type of Service) trong IP header.

Trong kiến trúc DiffServ chia thành 2 thành phần chính là phần biên và mạng lõi.

 Mạng biên: có nhiệm vụ phân loại gói tin và điều kiển lưu lượng, Vị trí này có thể
là một nguồn lưu lượng có cài đặt chính sách phân loại gói tin hoặc router hỗ trợ
DiffServ đầu tiên (router biên). Tại biên mạng này các gói tin sẽ được đánh dấu
vào trường Diffierentiated Service (DS) trong header của các gói tin một giá trị
nào đó gọi là Code Point (CP). Các lớp lưu lượng khác nhau sẽ được đánh dấu với
 15

các giá trị CP khác nhau và sẽ nhận được dịch vụ khác nhau trong phần mạng lõi.
Sau khi đánh dấu, các gói tin có thể được xếp vào hàng đợi hay chuyển thẳng vào
trong mạng lõi
 Mạng Lõi: chức năng chính là chuyển tiếp các gói tin. Một gói tin đã được đánh
dấu với giá trị CP sẽ được chuyển tới note tiếp theo thông qua từng chính sách
(PHB – Per-hop Behavior). PHB ảnh hưởng tới việc chia se băng thông và bộ đệm
giữa các lớp lưu lượng cạnh tranh tại router.

Hai chính sách quan trọng nhất ứng với mỗi thành phần của DiffServ đó là chính sách
phân loại và điều khiển lưu lượng của mạng biên và chính sách đối xử từng chặng PHP
của thành phần mạng lõi.

a. Phân loại và điều khiển lưu lượng của mạng biên

Một packet được đánh dấu vào trường DS của header gói tin IP tại vị trí vào của
mạng, nó có thể diễn ra tại một host hỗ trợ DiffServ hoặc router biên hỗ trợ DiffServ.
Giả sử rằng việc phân loại và đánh dấu gói tin này được xảy ra ở router kết nối trực tiếp
với bên gửi tin được gọi là router biên (edge router).

Hình 1.5: Phân loại và đánh dấu gói tin ở router biên

Một packet sau khi được gửi sẽ đi tới edge router. Các router phân loại gói tin
dựa trên giá trị của một hoặc nhiều trường tiêu đều của packet ví dụ như địa chỉ ip
nguồn, địa chỉ ip đích, port nguồn, port đích… hoặc dựa trên tốc độ tới của các gói tin
so với ngưỡng. Giá trị trường DS sẽ nhận được một giá trị tại bộ đánh dấu gói tin
(Maker). Ngay sau khi được đánh dấu các gói tin sẽ được chuyển đến router tiếp theo
 16

để đi tới đích. Tại mỗi router có hỗ trợ DiffServ những gói tin đã được đánh dấu này sẽ
nhận được lượng dịch vụ dựa theo các đánh dấu của chúng.

b. Per-Hop Behavior
Sau khi các gói tin đi qua edge router sẽ được phân loại và đánh dấu vào trường
DS trong header gói tin và được chuyển tiếp tới các router tiếp theo ở đây là core router,
thành phần thứ hai của kiến trúc DiffServ. Tại core router được cài đặt chính sách theo
từng chằng PHB và nó chứa những đặc điểm sau:
 Các lớp lưu lượng khác nhau (các lớp có giá trị trường DS khác nhau) sẽ nhận
được các dịch vụ khác nhau (cách chuyển tiếp khác nhau, băng thông khác
nhau,…)
 Hiệu năng phải quan sát được và đo được
 PHB không chỉ định cụ thể cơ chế nào phải được áp dụng để đạt được mục đích
và vì vậy bất kì một có chế quản lý cấp phát tài nuyên hay cơ chế chuyển tiếp nào
cũng có thể được sử dụng miễn là đạt được các mục đích tiêu chí hiệu năng mong
muốn.

Hiện tại có hai chuẩn PHB được chú ý nhiều nhất đó là EF (Expedited Forwarding) và
AF (Assured Forwarding)

 EF PHB chỉ ra rằng tốc độ gói tin ra khỏi router của một lớp lưu lượng nào đó phải
bằng hoặc vượt qua một ngưỡng cho trước. Nghĩa là trong mọi khoảng thời gian
lớp lưu lượng đó được đảm bảo nhận được đủ băng thông sao cho tốc độ ra của có
vượt qua tốc độ đặt trước này. EF PHB đảm bảo ngay cả khi có nhiều lớp lưu lượng
khác đi đến router và tài nguyên của đường truyền thì một lượng đủ tài nguyên vẫn
được ta sẵn cho lớp để đảm bảo nó nhận được một tốc độ tối thiểu.
 AF PHB thì phức tạp hơn. AF PHB chia lưu lượng thành 4 lớp, trong đó mỗi lớp
AFF được đảm bảo cung cấp một lượng băng thông tối thiểu và bộ đệm. Trong
mỗi lớp các packet lại được phân vào một trong 3 loại “ưu tiên loại bỏ”. Khi tắc
nghẽn xuất hiện trong một lớp AF, router có thể loại bỏ các gói tin dựa trên giá trị
ưu tiên loại bỏ của chúng. Bằng cách thay đổi lượng tài nguyên cấp phát cho từng
lớp, một nhà cung cấp dịch vụ Internet (ISP) có thể cung cấp các mức độ ưu tiên
thực hiện khác nhau có các lớp lưu lượng AF khác nhau. AF PHB có thể được
 17

dùng để cung cấp các mức dịch vụ khác nhau cho các hệ thống cuối. Trong các hệ
thống này việc quyết định số lượng các tài nguyên cấp cho từng lớp dịch vụ phải
gắn liền với việc giới hạn các thám số liên quan. Ví dụ như có 3 lớp dịch vụ khác
nhau là A, B, C trong đó lớp A được cung cấp x% băng thông, lớp B được cung
cấp x/2% băng thông, lớp C được cung cấp x/4% băng thông. Thoạt nhìn ta có thể
thấy rằng lớp A nhận được lượng băng thông nhiều nhất và có thể nói lớp A được
phục vụ tốt hơn lớp B và C. Tuy nhiên nếu ta xét rằng lưu lượng dữ liệu tại lớp A
cao gấp nhiều lần lớp B và C thì có thể thấy rằng các gói tin lớp A sẽ được phục
vụ ít hơn các gói tin lớp B và C. Như vậy kích thước tài nguyên được cung cấp là
chưa đủ để đánh giá chất lượng dịch vụ của một lớp mà phải gắn thêm ràng buộc
dữ liệu tối đa cho các gói tin lớp đó nữa.

Trong NS-2, các lớp AF được cài đặt với các hàng đợi vật lý khác nhau, trong các
hàng đợi đó thì các gói tin ứng với các mức ưu tiên khác nhau được đưa vào một hàng
đợi ảo tương ứng. Như vậy ta có tối đa 4 hàng đợi vật lý, mỗi hàng đợi vật lý sẽ có tối
đa 3 hàng đợi ảo. Mỗi hàng đợi sẽ có thể cài đặt một chính sách quản lý hàng đợi và
phục vụ riêng, có thể là DropTail, RED, RIO-C, RIO-D…

1.5. Kiến trúc DiffServ trong bộ mô phỏng NS2

Trong NS2 modul DiffServ được thược hiện theo “Assured forwarding”. Diffserv
dựa trên việc đánh dấu các gói tin tại rìa của mạng (nơi gói tin chuẩn bị đi vào DiffServ
network) theo các mức hiệu suất cần đảm bảo, sau đó dựa vào các đánh dấu này các gói
tin sẽ có các chính sách xử lý khác nhau tại các nút mạng. Cách dễ dàng nhất để phân
biệt các gói tin là sử dụng hàng đợi RED, dùng các tham số khác nhau cho các loại gói
tin khác nhau. Modul NS có xử lý diffserv được phát triển ở Nortel network.

Diffserv chia các gói tin thành nhiều lớp khác nhau (Tối đa là 8 lớp), Gói tin thuộc
lớp nào sẽ được xếp vào hàng đợi của lớp đó, ngoài ra để phân biệt các gói tin trong
cùng một lớp người ta chia hàng đợi vật lý này thành 3 hàng đợi ảo. Mỗi gói tin thuộc
vào một luồng có thể nhận 3 mức ưu tiên cùng với luồng đó, đôi khi còn được gọi là
“Drop precedence”

Kiến trúc Diffserv trong NS2 được chia thành 3 phần chính:
 18

- Thành phần quản lý tài nguyên và chính sách: Xây dựng các chính sách và phân
phối chúng cho đến các router hỗ trợ diffserv. Các chính sách này sẽ xác định
một gói tin sẽ nhận được mức dịch vụ như thế nào trong mạng. Việc này phụ
thuộc vào tính chất tài nguyên của luồng đó và các thành phần của mạng.
- Edge Router: chịu trách nhiệm phân loại và đánh dấu các gói tin khi các gói tin
này đi vào Diffserv Network
- Core Router: thực hiện các chính sách đảm bảo chất lượng dịch vụ cho các gói
tin theo từng mức ưu tiên đã được đánh dấu (Per-Hop behavior)

1.5.1. Router MRED (Milti RED)

Trong mỗi hàng đợi vật lý được phân ra thành 3 hàng đợi ảo, các hàng đợi ảo này
sử dụng thuật toán RED để quản lý các gói tin sau khi được phân loại. Các mode của
router MRED được hỗ trợ trong NS2 bao gồm có:

- RIO – C (Rio Coupled): Trong đó xác suất loại bỏ các gói tin có độ ưu tiên thấp
(các gói tin ngoài luồng) dựa trên độ dài trung bình của tất cả các hàng đợi ảo,
xác suất hủy các gói tin có mức ưu tiên cao thì dựa trên kích thước hàng đợi trung
bình của hàng đợi ảo chưa gói tin đó.
- RIO – D (Rio De-coupled): Xác suất loại bỏ các gói tin dựa trên kích thước hàng
đợi trung bình của chính hàng đợi chứa gói tin đó.
- WRED (Weight RED): xác suất loại bỏ gói tin dựa trên chiều dài của hàng đợi
đơn.
- DROP: Giống như hàng đợi Droptail với chiều dài hàng đợi tối đa được chỉ định
bằng ngưỡng 𝑚𝑖𝑛𝑡ℎ của thuật toán RED, khi kích thước hàng đợi trung bình
vượt quá ngưỡng 𝑚𝑖𝑛𝑡ℎ tất cả các gói tin sẽ bị loại bỏ không kể việc gói tin có
được đánh dấu hay không.

1.5.2. Các cơ chế đánh dấu gói tin và chính sách phục vụ

Khi một luồng các gói tin đi đến một router có hỗ trợ diffserv, các router này sẽ
phân loại gói tin và đánh dấu chúng. Trong bộ mô phỏng NS2 thì thành phần này được
gọi là các “Policer”. Có 6 loại được sử dụng trong bộ mô phỏng NS2:
 19

1. Time Sliding Window with 2 Color Marking (TSW2CMPolicer): Sử dụng

giá trị CIR và 2 giá trị ưu tiên loại bỏ gói tin. Giá trị ưu tiên thấp hơn thì được
sử dụng khi CIR vượt mức cho phép.

2. Time Sliding Window with 3 Color Marking (TSW3CMPolicer): Sử dụng 2

giá trị CIR, PIR và 3 giá trị ưu tiên loại bỏ. Giá trị ưu tiên loại bỏ gói tin cao
nhất khi vượt quá PIR, giá trị ưu tiên loại bỏ trung bình khi CIR vượt mức cho
phép.

3. Token Bucket (tokenBucketPolicer): Sử dụng 2 giá trị CIR, CBS và 2 giá trị
ưu tiên loại bỏ gói tin. Một gói tin đến sẽ được đánh dấu giá trị ưu tiên lớn khi
và chỉ khi kích thước gói tin lớn hơn token bucket.

4. Single Rate Three Color Marker (srTCMPolicer)[5]: Sử dụng CIR, CBS,

EBS để chọn 3 thứ tự ưu tiên hủy gói tin.

5. Two Rate Three Color Marker (trTCMPolicer): Sử dụng CIR, CBS, PIR,
PBS để chọn 3 thứ tự ưu tiên hủy gói tin.

6. NullPolicer: không có thứ tự ưu tiên hủy gói.

Các gói tin sau khi đi qua các “Policer” này sẽ nhận được các giá trị ưu tiên “Drop
Precedence”. Các giá trị này sẽ được mã hóa thành các CP (code point) và được ghi
vào trong trường DS (Differentiated Services) của gói tin IP.

Trong đó Các giá trị CIR và PIR được tính là bps, Các giá trị CBS, EBS, and PBS
được tính theo byte.

1. CIR (committed information rate) – Tốc độ truyền tin cam kết

2. PIR (peak information rate) – Tốc độ truyền tin tối đa cam kết
3. CBS (committed burst size) – Kích thước bùng nổ cam kết
4. EBS (excess burst size) – Kích thước cụm vượt mức
5. PBS (peak burst size) – Kích thước cụm tối đa
6. C bucket: Kích thước hiện thời của khối dung lượng cho phép
7. E bucket: Kích thước hiện thời của khối dung lượng vượt mức
8. P bucket: Kích thước hiện thời của khối dung lượng tối đa
 20

1.5.3. Các cơ chế lập lịch hàng đợi

Trong bộ mô phỏng NS2 sử dụng các chế độ lập lịch RR, WRR, WIRR, PIR.
Trong đó thì mặc định sử dụng bộ lập lịch RR. Các chế độ lập lịch sẽ được mô tả kỹ
hơn trong chương 2 của luận văn.

1.6. Thách thức của việc truyền thông đa phương tiện trên Internet hiện nay

1.6.1. Hạn chế của việc truyền thông đa phương tiện hiện nay

Hiện nay giao thức IP trên Internet cung cấp dịch vụ Best-Effort nghĩa là nó cố
gắng chuyền các datagram từ nguồn tới đích 1 cách nhanh nhất có thể và không đảm
bảo độ trễ và tỉ lệ mất mát gói tin. Các giao thức tầng transport là TCP hoặc UDP cũng
không cung cấp các cơ chế đảm bảo về mặt độ trễ gói tin. Do vậy việc truyền thông đa
phương tiện trên nên Internet truyền thống gặp rất nhiều trở ngại kìm hãm sự phát triển.
Đối với các ứng dụng thời gian thực kèm theo tương tác đòi hỏi độ trễ và jitter cực thấp
thì khi xảy ra tắc nghẽn chất lượng dịch vụ có thể tồi đến mức không thể chấp nhận
được.

 Tỉ lệ mất mát gói tin lớn khi mạng xảy ra tắc nghẽn
 Đỗ trễ đầu cuối có thể tăng cao tới mức không thể chấp nhận được
 Biến thiên độ trễ là không thể tránh khỏi khiến cho chất lượng âm thanh không
chấp nhận được.

1.6.2. Các phương pháp đảm bảo chất lượng dịch vụ trên nền các dịch vụ cố gắng
tối đa (best effort)

Trong dịch vụ best-effort thì các gói tin được đối xử như nhau nghĩa là không có
gói tin nào được ưu tiên hơn trong hàng đợi. Các gói tin khi đi tới router sẽ được đưa
vào cuối hàng đợi và chờ đến lượt được phục vụ. Vẫn có 1 số cơ chế để cải thiện chất
lượng dịch vụ cho các ứng dụng đa phương tiện trên nên best-effort dựa vào các giao
thức tầng giao vận là TCP như: Slow-Start, Window-size hay có thể dừng chạy ở phía
nhận khoảng 1 thời gian để loại bỏ các hiệu ứng biến thiên độ trễ. Có thể gửi kèm thông
tin dư thừa để khắc phục tình trạng mất mát gói tin khi mạng xảy ra tắc nghẽn.
 21

Chương 2. CÁC CHIẾN LƯỢC QUẢN LÝ HÀNG ĐỢI VÀ KHẢ NĂNG

ÁP DỤNG ĐỂ ĐẢM BẢO QOS CHO TRUYỀN THÔNG ĐA PHƯƠNG
TIỆN THỜI GIAN THỰC

Trong mạng chuyển mạch ip thì các gói tin thuộc các luồng dữ liệu khác nhau được
truyền trên cùng đường truyền để đến trạm đích. Để việc phân phối băng thông đường
truyền đạt hiệu quả cao nhất thì cần một cơ chế phục vụ công bằng tại các nút mạng
hoặc Router. Router ở đây sẽ phục vụ các gói tin của luồng đã chọn và quyết định gói
tin nào sẽ được phục vụ tiếp theo.

2.1. Các chiến lược quản lý hàng đợi truyền thống

2.1.1. Hàng đợi FIFO (First in first out)

FIFO là hàng đợi mặc định được sử dụng trong hầu hết các router. FIFO không có
sự phân loại vì tất cả các gói đều thuộc về cùng một lớp. Các gói đến từ các luồng khác
nhau được đối xử công bằng bằng cách đưa vào hàng đợi theo trật tự đến (gói nào đến
trước sẽ được đưa vào trước và được phục vụ trước) theo đúng nghĩa First-Come-First-
Serve (FCFS) hay First-In-First-Out (FIFO)

góisGói tin đến Gói tin đi

Hàng đợi Link

Hình 2.1: Cơ chế phục vụ FIFO

Hàng đợi FIFO sử dụng một hàng đợi đơn cho bộ giao tiếp. Vì chỉ có một hàng
đợi nên không cần phân lớp để quyết định khi gói đi vào. Và cũng không cần lập lịch
ban đầu để cho hàng đợi lấy gói tiếp theo. Ta chỉ quan tâm đến cách cấu hình chiều dài
hàng đợi FIFO tránh tác động đến độ trễ và mất gói. FIFO thường được dùng trên các
giao diện (interface) mạng tốc độ cao khó có khả năng xảy ra tắc nghẽn. Đây là một hạn
 22

chế lớn của hàng đợi này vì trong mạng Internet ngày nay có rất nhiều gói tin có độ ưu
tiên cao cần xử lý trước tuy nhiên cơ chế FIFO có thể loại bỏ các gói tin này khi hàng
đợi đầy hoặc khi tắc nghẽn xảy ra thì sẽ làm gia tăng độ trễ tới mức không chấp nhận
được. Đôi khi một luồng lưu lượng bùng nổ lớp sẽ độc chiếm đường truyền khiến cho
các luồng khác không được phụ vụ gây bất công bằng giữa các luồng dữ liệu.

2.1.2. Chiến lược hàng đợi ưu tiên PQ ( Priority Queue )

Kĩ thuật này được sử dụng trong trường hợp đa hàng đợi, mỗi hàng đợi có một
mức ưu tiên khác nhau, hàng đợi nào có mức ưu tiên cao nhất sẽ được ưu tiên phục vụ
trước. Khi có tắc nghẽn xảy ra thì các gói trong các hàng đợi có độ ưu tiên thấp sẽ bị
loại bỏ. Nói cách khác, lưu lượng quan trọng sẽ được gán các mức ưu tiên cao và lưu
lượng có mức ưu tiên cao nhất được truyền trước, còn lại các lưu lượng ít quan trọng
hơn.

Hàng đợi 1
góisGói tin đến
Gói tin đi

Phân loại Link

Hàng đợi 2

Hình 2.2: Cơ chế phục vụ hàng đợi ưu tiên PQ

Các gói được phân loại dựa trên các tiêu chuẩn phân loại của người sử dụng, và
được đặt ở một trong số các hàng đợi đầu ra với các độ ưu tiên: độ ưu tiên cao, trung
bình, bình thường (không được ưu tiên), ưu tiên thấp. Các gói không được ấn định độ
ưu tiên sẽ được đưa tới các hàng đợi bình thường. Khi các gói được gửi tới giao diện
đầu ra, các hàng đợi ưu tiên tại giao diện đó được quét các gói theo thứ tự độ ưu tiên
giảm dần. Hàng đợi có độ ưu tiên cao nhất được quét đầu tiên, sau đó đến các hàng đợi
trung bình và tiếp tục các hàng đợi có độ ưu tiên khác. Gói đứng đầu hàng đợi có độ ưu
 23

tiên cao nhất được truyền đầu tiên. Thủ tục này được lặp lại mỗi khi có một gói được
truyền. Chiều dài lớn nhất của hàng đợi được định nghĩa theo chiều dài giới hạn. Khi
một hàng đợi dài hơn chiều dài hàng đợi giới hạn thì các gói đến sau sẽ bị loại bỏ.

PQ thường được dùng cho các interface băng thông thấp ở đó ta muốn gán mức ưu
tiên tuyệt đối cho ứng dụng hay traffic trọng yếu. Mặc dù PQ là cách tiếp cận lập lịch
đơn giản nhưng nó có thể gây thiếu hụt băng thông nghiêm trọng cho các luồng có độ
ưu tiên thấp. PQ có thể dành hết băng thông cho các luồng có độ ưu tiên cao và dẫn tới
việc các luồng có độ ưu tiên thấp không bao giờ được phục vụ. Hiện nay PQ thường
được cấu hình tĩnh và không được tùy chỉnh theo sự thay đổi của mạng.

2.1.3. Chiến lược Packet-Based Round Robin

Tương tự như chiến lược PQ đã trình bày ở phần trước. Chiến lược này cũng dựa
vào việc phân loại các gói tin đến theo từng luồng khác nhau mỗi luồng được xếp vào
một hàng đợi và được phục vụ lần lượt theo vòng. Tuy nhiên thay vì phục vụ theo mức
ưu tiền thì PBRR lại phục vụ lần lượt quay vòng từng hàng đợi, mỗi hàng đợi chỉ phục
vụ 1 gói tin. Nếu hàng đợi nào rỗng thì bộ lập lịch sẽ bỏ qua không phục vụ.

Hàng đợi 1

góisGói tin đến Gói tin đi

Phân loại Hàng đợi 2

Link

Hàng đợi 3

Hình 2.3: Cơ chế phục vụ hàng đợi PBRR (Packet-Based Round Robin)
 24

Bộ lập lịch PBRR sẽ đối xử với các luồng dữ liệu giống nhau, nghĩa là không có
mức độ ưu tiên dành cho các luồng có mức ưu tiên cao và nó cũng không quan tâm đến
độ dài hàng đợi hiện tại khiến cho những luồng có hàng đợi dài chứa nhiều gói tin cũng
chỉ được cấp cho một lượng băng thông giống như các luồng khác. Làm giảm hiệu suất
sử dụng đường truyền. Không đáp ứng được băng thông cho các luồng dữ liệu
multimedia.

2.1.4. Bộ lập lịch lý tưởng GPS - Generalized Processor Sharing

Ý tưởng của GPS là trong mỗi khoảng thời gian hữu hạn phải thăm mỗi hàng đợi
ít nhất một lần, phục vụ cho một lượng rất nhỏ dữ liệu từ mỗi hàng đợi. Khoảng thời
gian và lượng dữ liệu này đủ nhỏ để có thể giả định rằng máy phục vụ (server) có thể
phục vụ được tất cả các luồng có gói tin đang chờ một cách đồng thời và các luồng có
thể được chia nhỏ tuỳ ý. Đây là một cơ chế lý tưởng vì nó đảm bảo sự phân chia công
bằng nhất dành cho các luồng dữ liệu. Tuy nhiên việc cài đặt GPS trong thực tế là không
thực hiện được vì trong 1 khoảng thời gian thì server chỉ có thể phục vụ 1 hàng đợi thay
vì tất cả các hàng đợi của các luồng dữ liệu và độ dài kích thước gói tin là cố định không
thế chia nhỏ tùy ý, gói tin này được phục vụ xong thì gói tin khác mới được phục vụ.

Cài đặt đơn giản nhất của GPS là chiến lược Weighted Round Robin (WRR),
thay vì thăm mỗi hàng đợi ít nhất một lần và phục vụ một lượng nhỏ dữ liệu tại hàng
đợi như GPS thì WRR lại phục vụ một số gói tin tại từng hàng đợi, số gói tin được phục
vụ tại từng hàng đợi phụ thuộc vào trong số “Weight” của hàng đợi đó. Trong kiến trúc
DiffServ có thể phân biệt các hàng đợi này thông qua giá trị trường DS trong gói tin IP.

Một biến thể của WRR là Weighted Interleaved Round Robin (WIRR) về cơ
bản thì chiến lược này giống với WRR nhưng có thêm một cơ chế “Interleaved
behavior”. Cơ chế này cho phép bộ lập lịch bỏ qua các hàng đợi không có gói tin một
khoảng thời gian mà bộ lập lịch phải phục vụ hàng đợi đó.

2.1.5. Chiến lược Flow-Based Weighted Fair Queuing (WFQ)

Các chiến lược đã nói trong phần trước đều dựa trên packet-base nghĩa là nó áp
dụng cho từng gói tin theo đó mỗi lần phục vụ server sẽ chọn 1 gói tin theo mức độ ưu
tiên của nó. Ưu điểm của chiến lược này nó đạt được mức độ công bằng cao cho các gói
tin nhưng lại chứa nhiều điểm hạn chế: Thứ nhất là chi phí gán nhãn cho từng gói tin là
 25

lớn và làm gia tăng độ phức tạp thuật toán và tiêu tốn tài nguyên của server. Thứ 2 là
các gói tin của cùng 1 luồng sẽ không được phụ vụ cùng 1 lúc mà bị gián đoạn bởi các
gói tin của các luồng khác, điều này không phù hợp với các ứng dụng truyền thông đa
phương tiện thời gian thực trên Internet cần độ liền mạch các gói tin. Chính vì lẽ đó ta
cần 1 cách tiếp cận hay 1 chiến lược khác là việc xác định và gán độ ưu tiên cho một
luồng dữ liệu thay vì 1 gói tin riêng lẻ. Các gói tin trong cùng 1 luồng dữ liệu sẽ có cùng
1 độ ưu tiên và được phục vụ liên tục. Server sẽ phục vụ các luồng theo tứ tự ưu tiên
hoặc trọng số, các gói tin trong cùng 1 luống sẽ được phục vụ theo cơ chế FIFO nghĩa
là gói tin nào đến trước được phục vụ trước. Chiến lược này được gọi là Flow-Base
Weighted Fair Queuing.

Trong chiến lược WFQ này khi các gói tin tới hàng đợi sẽ được phân chia thành
các luồng theo từng mức ưu tiên khác nhau. Mỗi luồng sẽ được xếp vào 1 hàng đợi riêng
và nhận được 1 lượng phục vụ tùy theo trọng số của hàng đợi đó.

𝑤1

Hàng đợi 1

góisGói tin đến 𝑤2 Gói tin đi

Phân loại Hàng đợi 2

Link

𝑤3

Hàng đợi 3

Hình 2.4: Cơ chế WFQ

Giả sử mỗi luồng i được gán 1 trọng số 𝑤𝑖 . Trong khoảng thời gian phục vụ lớp i
sẽ nhận được một lượng phục vụ là: 𝑤𝑖 / ∑𝑛𝑖−𝑛(𝑤𝑖 ) tổng dung lượng đường truyền trong
đó:

 n là tổng số luồng có gói tin đang chờ

 C là tổng dung lượng đường truyền
 26

𝑤𝑖
 Luồng i sẽ nhận được 𝐶 ∗ (∑𝑛 ) băng thông mỗi lần phục vụ
𝑖−𝑛(𝑤𝑖 )

Có nhiều cách xác định trọng số cho từng luồng WFQ, một trong những cách được
sử dụng phổ biến nhất là sử dụng các bit ưu tiên (IP precedence bits) của trường TOS
(Type of Services) trong header packet ipv4. Đó là 3 bit bên trái nhất của trường TOS.
Tổ hợp của 3 bit này tạo nên 6 mức ưu tiên từ 0 – 5, các mức 7, 8 được dành riêng và
không được phép sử dụng. Như vậy dựa vào các bit trên ta có thể phân chia thành 6
luồng khác nhau với các mức ưu tiên.

Giả sử chúng ta có 6 luồng với 6 mức ưu tiên khác nhau (IP precedence = 0 ÷ 5),
mỗi luồng sẽ chiếm 1 lượng băng thông đường truyền là (IP precedence + 1)/(tổng dung
lượng đường truyền).

Tổng dung lượng đường truyền là:

1 + 2 +3 + 4 + 5 + 6 = 21

Các luồng sẽ nhận được lần lượt là 1/21, 2/21, 3/21, 4/21, 5/21, 6/21 dung lượng
đường truyền.

Ipv4 header

payload

TOS Bytes

3 bits

IP precedence bits

Hình 2.5: IP Precedence bits

Như vậy có thể thấy rằng WFQ thực hiện phân phối dải thông đường truyền một
cách công bằng cho các luồng dữ liệu dựa vào mức ưu tiên của chúng. Có thể nó rằng
WFQ đảm bảo được chất lượng dịch vụ có phân loại hay còn gọi là QoS mềm. Trên thực
tế WFQ thường được dùng trong trường hợp mạng yêu cầu thời gian đáp ứng nhất quán
khi tải nặng cũng như khi tải nhẹ trong khi băng thông không thay đổi. Nó đảm bảo cho
 27

hàng đợi lúc nào cũng có băng thông và lượng dịch vụ dành cho mỗi luồng là có thể dự
đoán trước được.

WFQ còn có thể được kết hợp với giao thức đặt trước tài nguyên RSPV - Resource
Reservation Protocol để cung cấp QoS cứng.

2.1.6. Chiến lược Class-Based Weighted Fair Queuing (CBQ)

Không giống như WFQ, CBQ được thiết kế nhằm đảm bảo băng thông cho các lớp
lưu lượng do người dùng đặt trước mà vẫn đảm bảo phân phối công bằng cho các luồng
trong lớp đó. CBQ cung cấp nhiều hàng đợi riêng biệt, mỗi hàng đợi có thể phân chia
thành nhiều lớp, các luồng này có thể được xác định dựa vào các tiêu chi như giao thức
(FTP, HTTP, Telnet, SSh..) hoặc danh sách điều khiển truy cập (Access list). Các gói
tin thỏa mãn các tiêu chí được xếp chung vào 1 lớp

Class-Based Weighted Fair Queuing (CBQ) là cơ chế queuing được dùng để

reserve (giành trước) một lượng bandwidth tối thiểu cho một loại lớp lưu lượng (traffic
class) khi xảy ra nghẽn. Lệnh bandwidth trong policy-map sẽ được dùng để tính toán ra
giá trị weight cho lớp đó. Công thức tính weight của mỗi lớp có liên quan đến bandwidth
của interface, vì vậy việc cấu hình đúng bandwidth của interface (thỏa với tốc độ vật lý
của đường link) là rất quan trọng.

CBQ cho phép người quản trị mạng xác định chính xác lượng băng thông được
cấp phát cho 1 luồng lưu lượng cụ thể dựa vào băng thông có sẵn mà WFQ không làm
được – Tính trọng số ưu tiện dựa vào các bit trong trường ToS chứ không phải do người
dùng đặt trước. Điều ngày giúp người quản trị có thể phân phối cho một lớp lưu lượng
đặc biệt nào đó một lượng băng thông tối thiểu đủ để hoạt động

Xét 1 ví dụ có một luồng thoại thời gian thực yêu cầu băng thăng tối thiểu bằng
một nửa dung lượng đường truyền T1 (1.544Mbps). Nếu chỉ có 2 luồng dữ liệu ta hoàn
toàn có thể sử dụng WFQ để phân phối. Tuy nhiên vấn để xảy ra khi có thêm nhiều
luồng dữ liệu tham gia vào đường truyền khi đó đặc tính của WFQ sẽ phân phối giải
thông công bằng cho các luồng, như vậy luồng thoại thời gian thực ban đầu sẽ không có
đủ lượng băng thông yêu cầu là một nữa đường truyền T1. Khác với WFQ khi sử dụng
 28

CBQ thì hoàn toàn có thể cấu hình dành 1 nửa đường truyền T1 cho luồng dữ liệu thoại
thời gian thực này. Luồng này được đưa vào 1 lớp và có đủ băng thông để hoạt động,
các luồng còn lại được xếp vào một lớp khác và chia sẻ một nửa băng thông còn lại.

CBQ còn hỗ trợ chia sẻ băng thông giữa các lớp bằng cách sử dụng cấu trúc cây
phân lớp, để hiểu rõ hơn chúng ta cùng xét ví dụ dưới đây. Tại mức cao nhất người quản
trị chia sẻ đường truyền cho 3 người dùng khác nhau. Tại mức này từng người đùng sẽ
chia sẻ băng thông họ nhận được cho các ứng dụng theo một tỉ lệ nào đó, quá trình lặp
lại cho đến khi ứng dụng nhận được phần băng thông được cấp phát để truyền.

links

Agency A 40% Agency C 30%

Agency B 30%

HTTP FTP POP3 TCP IP 20% HTTP SSH

20% 10% 10% 10% 20% 10%

RTP FTP

10% 10%

Hình 2.6: Chia sẻ băng thông trong CBQ

Trong quá trình hoạt động có những lớp không sử dụng hết băng thông được cấp
phát, lượng băng thông này sẽ được chia sẻ cho các lớp còn lại, các lớp cùng cấp có thể
mượn số băng thông này thông qua lớp cha của nó, lớp nào có ưu tiên cao hơn sẽ mượn
được nhiều bằng thông hơn.

CBQ đã được cài đặt trên linux bằng cách dùng thuật toán từ bộ mô phỏng NS2.
Cài đặt ban đầu của CBQ là WRR (Weighted Round Robin), trong linux là DRR
 29

(Deficit Round Robin). Chính sách chia sẻ băng thông được sử dụng trong DRR như
sau: Khi lớp A có độ ưu tiên cao hơn lớp B, cả 2 đang mượn băng thông từ lớp C thì A
sẽ lấy phần băng thông nó cần sau đó phần băng thông còn lại sẽ dành cho B, nếu độ ưu
tiên của lớp A và B bằng nhau thì 2 lớp sẽ cùng nhận được 1 lượng băng thông chia sẻ
giống nhau.

2.2. CÁC CHIẾN LƯỢC QUẢN LÝ HÀNG ĐỢI ĐỘNG

Trong lý thuyết hàng đợi người ta chứng minh được rằng thời gian trung bình mà
các gói tin đi qua hàng đợi bao gồm thời gian các gói tin phải chờ trong hàng đợi cộng
với thời gian chúng được phục vụ, tỉ lệ thuận với chiều dài hàng đợi, tỉ lệ nghịch với tốc
độ gói tin đến hàng đợi trung bình. Mục tiêu chính của các chiến lược quản lý hàng đợi
là giữ cho chiều dài hàng đợi trung bình đủ nhỏ và ổn định. Đảm bảo độ trễ trung bình
của các gói tin không vượt quá ngưỡng cho phép đồng thời đạt được hệ số sử dụng
đường truyền cao. Hai yêu cầu này là trái ngược nhau chính vì vậy cần có một sự thỏa
hiệp. Để biểu diễn đại lượng này người ta đưa ra một đại lượng là “Công suất”, đó là tỉ
lệ giữa thông lượng và độ trễ. Điểm tối ưu là điểm có hiệu suất cực đại. Trong chương
này sẽ trình bày về các chiến lược quản lý hàng đợi động AQM và một số thuật toán
tiêu biểu. Các chiến lược này nhằm đáp ứng các mục tiêu đã nêu phía trên. Trước khi
tìm hiểu về các chiến lược quản lý hàng đợi động chúng ta hãy xem xét chiến lược quản
lý hàng đợi truyền thống và các nhược điểm của nó.

2.2.1. Chiến lược quản lý hàng đợi truyền thống và hệ quả

Các cách tiếp cận quản lý hàng đợi truyền thống đều dựa trên cơ chế FIFO như đã
trình bày ở phần trước. Với các cơ chế này thì gói tin khi tới gateway hoặc router sẽ
được xếp vào hàng đợi, khi hàng đợi đầy thì các gói tin tới sau sẽ bị loại bỏ. Các gói tin
tới trước sẽ được phụ vụ trước và hàng đợi này được mô phỏng trong bộ mô phỏng NS2
với tên gọi “DropTail”. Do tính đơn giản và dễ cài đặt mà nó được sử dụng trong nhiều
năm trên Internet tuy nhiên do sự phát triển mạnh mẽ của mạng Internet ngày nay nó
xuất hiện nhiều nhược điểm mà nổi bật nhất là hai nhược điểm sau đây
 30

a. Hiện tượng Global Synchronization

Theo cơ chế FIFO, chúng ta nói rằng các luồng khác bị “Lock Out” tại một thời
điểm khi xuất hiện một luồng lưu lượng bùng nổ khiến cho hàng đợi bị chiếm độc quyền,
các gói tin của các luồng lưu lượng khác không được nhận vào vì hàng đợi đầy. Khi xảy
ra hiện tượng lockout nếu các thực thể sử dụng giao thức TCP để truyền thì chúng sẽ bị
TimeOUT. Theo thuật toán tránh tắc ngẽn của TCP chúng sẽ đồng loạt giảm cửa số phát,
thực hiện rút lui theo hàm mũ làm cho lưu lượng trên mạng đồng loại giảm nhanh chóng
gây lãng phí băng thông đường truyền, làm giảm hiệu suất sử dụng. Hiện tượng đồng
loạt giảm lưu lượng đó được gọi là hiện tượng đồng bộ toàn cầu – Global
synchronization.

b. Hiện tượng hàng đợi đầy (Full Queue)

Hàng đợi FIFO có thể thường xuyên nằm trong trạng thái đầy trong trong thời gian
dài nếu có nhiều luồng lưu lượng, vì cơ chế FIFO chỉ loại bỏ gói tin khi hàng đợi đã đầy.
Lưu lượng trên mạng thường xuyên có sử bùng nổ và các gói tin tới các node mạng
thường theo cụm nên bộ đệm tại các node mạng phải đủ lớn để hấp thu các lưu lượng
bùng nổ này. Nhược điểm của nó là khi tăng kích thước bộ đêm để hấp thu các lưu lượng
bùng nổ đồng thời sẽ làm gia tăng độ trễ và thăng giáng độ trễ. Ưu tiên sẽ là lựa chọn
một cơ chế quản lý hàng đợi tốt thay vì tăng kích thước hàng đợi tại node mạng.

Ngoài “DropTail” còn có 2 phương pháp khác có thể được sử dụng là loại bỏ gói
tin ngẫu nhiên “Random Drop” và loại bỏ gói tin ở đầu “Drop Front”. Tư tưởng của
Random Drop là các router sẽ loại bỏ ngẫu nhiên các gói tin trong hàng đợi để dành chỗ
cho các gói tin đến. Còn với phương pháp Drop Front thì router sẽ loại bỏ các gói tin ở
đầu hàng đợi. Cả 2 phương pháp này đều có thể khắc phục được hiện tượng “Lock-out”
nhưng không khắc phục được hiện tượng đầy hàng đợi (Full Queue).

2.2.2. Ưu điểm các chiến lược quản lý hàng đợi động

Như đã nói ở trên thì các chiến lược quản lý hàng đợi truyền thống sẽ loại bỏ gói
tin khi hàng đợi đầy, điều nay không hợp lý vì đôi khi hàng đợi đầy thì hiện tượng tắc
nghẽn đã trở nên khó kiểm soát. Giải pháp hợp lý cho trường hợp này là loại bỏ gói tin
 31

trước khi hàng đợi đầy khi đó các thực thể gửi và nhận sẽ nhận biết và phản ứng với tắc
nghẽn ngay khi hiện tượng tắc nghẽn bắt đầu xảy ra. Đây chính là tư tưởng chính của
các chiến lược quản lý hàng đợi động – Active Queues Managerment AQM. Điểm
cần chú ý rằng các chiến lược quản lý hàng đợi động này chỉ có hiệu quả đối khi được
gắn với các giao thức vận chuyển có cơ chế kiểm soát lưu lượng (Flow control) như
TCP, và nó không có hiệu quả đối với các giao thức như UDP.

Các chiến lược quản lý hàng đợi động sẽ đem lại những ưu điểm sau:

a. Giảm độ trễ và giảm thăng giáng độ trễ

Việc loại bỏ sớm các gói tin khi tắc nghẽn chưa xảy ra sẽ giữ kích thước hàng đợi
ở mức trung bình đủ nhỏ và làm giảm độ trễ một cách đáng kể. Điều này vô cùng quan
trọng với các ứng dụng thời gian thực như voice, video thời gian thực

b. Làm giảm số lượng gói tin bị loại bỏ tại các node mạng

Mạng Internet ngày nay sự bùng nổ lưu lượng các gói tin là không thể tránh khỏi.
Với chiến lược quản lý hàng đợi truyền thống kích thước hàng đợi tăng rất nhanh khi
lưu lượng bùng nổ, các gói tin bị loại bỏ sẽ tăng nhanh khi hàng đợi đầy. Việc sử dụng
các chiến lược quản lý hàng đợi động sẽ giúp cho kích thước hàng đợi nằm trong một
khoảng trung bình đủ nhỏ, hàng đợi sẽ hấp thu các thăng giáng lưu lượng dễ dàng hơn
khiến cho số gói tin bị loại bỏ giảm, hệ số sử dụng đường truyền tăng, việc khôi phục
các gói tin bị mất đơn lẻ cũng dễ dàng hơn với TCP.

c. Tránh hiện tượng Lock-out

Hiện tượng lock-out xảy ra khi hàng đợi đầy, gói tin khi đi tới node mạng sẽ không
được xếp vào hàng đợi vì không còn chỗ trống. AQM sẽ đảm bảo cho hàng đợi luôn
luôn có chỗ trống dành cho các gói tin tới do đó tránh được hiện tượng này.

Chúng ta sẽ tiến hành nghiên cứu 1 số thuật toán quản lý hàng đợi động tiêu biểu
như RED, A-RED và RIO.
 32

2.2.3. Thuật toán RED trong chiến lược quản lý hàng đợi động

a. Giới thiệu thuật toán RED

Khi có dấu hiệu của tắc nghẽn xảy ra trong mạng, hàng đợi tài router đầy thì router
bắt đầu loại bỏ các gói tin đến. Đối với các luồng lưu lượng TCP thì đây là tín hiệu thông
báo tắc nghẽn xảy ra và báo hiệu các nguồn phát giảm lưu lượng để giảm bớt tắc nghẽn.
Có hai vấn đề quan trọng cần giải quyết: Thứ nhất là đối với các luông TCP thì các gói
tin bị loại bỏ sẽ được truyền lại, điều này làm tăng tải trong mạng đồng thời phát sinh
thêm độ trễ. Thứ hai là hiện tượng đồng bộ toàn cầu đã nói ở phân trên. Năm 1993 hai
nhà khoa học của phòng thí nghiệm Lawrence Berkeley thuộc đại học California, Mỹ là
Sally Floyd và Van Jacobson đã đề xuất thuật toán quản lý hàng đợi động AQM – một
trong những thuật toán quản lý hàng đợi đầu tiên là RED – Random Early Detection of
congestion, Random Early Drop. Với như ưu điểm vượt trội so với các thuật toán quản
lý hàng đợi truyền thống nên RED đã được triển khai rộng rãi trên mạng Internet.

Việc phát hiện sớm tắc nghẽn và phản ứng lại để giữ đường truyền ổn định thường
được thực hiện trên các gateway. Các thực thể nguồn cũng có thể làm điều này thông
qua thời gian phục vụ ước lượng tại gateway, thông qua độ trễ end-to-end, qua sự thay
đổi thông lượng hoặc số lượng các gói tin bị loại bỏ. Tuy nhiên khung nhìn của một kết
nối cụ thể bị giới hạn bởi thời gian phát tin và số lượng dữ liệu phát, ngoài ra nó cũng
không thể biết được gateway nào đang tắc nghẽn, không phân biệt được độ trễ lan truyền
và độ trễ hàng đợi. Chỉ có các Gateway là có cái nhìn đúng đắn nhất về trạng thái của
hàng đợi, sự chia sẻ đường truyển của các kết nối đi qua nó tại mọi thời điểm cũng như
yêu cầu chất lượng dịch vụ của các dòng lưu lượng. Các RED gateway sẽ theo dõi độ
dài trung bình của hàng đợi để dựa vào đó phán đoán sớm tắc nghẽn sắp xảy ra (chiều
dài của hàng đợi vượt quá một ngưỡng được định trước) và phản ứng một cách thích
hợp đối với các gói tin đến theo hai cách:

 Loại bỏ các gói tin đến theo một xác suất nhất định được định trước nhằm
gián tiếp thông báo cho nguồn về sự tắc nghẽn đồng thời giữ kích thước hàng đợi
nằm trong một ngưỡng đủ nhỏ
 Đánh dấu cờ “có tắc nghẽn” theo một xác suất nhất định vào trường ECN
trong header của các gói tin để báo cho bên nguồn biết.
 33

b. Tư tưởng và nguyên tắc thiết kế thuật toán

Mục đích chính của các RED gateway là điều khiển kích thước hàng đợi nằm trong
một vùng đủ nhỏ được định nghĩa trước và ổn định. Ngoài ra nó còn tránh hiện tượng
Global-Synchronization và không chống lại các luồng có lưu lượng đột biến, Duy trì
kích thước hàng đợi ngay cả khi không có sự hợp tác từ các giao thức tầng giao vận

Để đạt được những mục tiêu trên RED gateway phải làm được các công việc sau:

- Phát hiện sớm tắc nghẽn và giữ kích thước hàng đợi trung bình đủ nhỏ làm cho
mạng hoạt động ở vùng có độ trễ thấp, thông lượng cao, trong khi vẫn cho phép
hàng đợi giao động trong một miền nhất định để hấp thu các luồng có lưu lượng
đột biến hoặc độ thăng giáng cao. RED gateway là nơi thích hợp nhất để phát hiện
tắc nghẽn và cũng là nơi thích hợp nhất để quyết định chọn kết nối cụ thể nào để
thông báo tắc nghẽn.
- Thông báo tới nguồn phát về tắc nghẽn có thể xảy ra. Việc này được thực hiện
bằng cách đánh dấu và thông báo cho nguồn phát giảm lưu lượn xuống. Thông
thường RED gateway sẽ loại bỏ gói tin, tuy nhiên nếu tắc nghẽn được phát hiện
sớm thì thay vì loại bỏ nó RED gateway sẽ có 2 lựa chọn là đánh dấu hoặc loại bỏ
gói tin. Việc đánh dấu gói tin được thực hiện bằng cách đánh dấu vào trường ECN
trong header của gói tin với một xác suất nhất định để báo hiệu cho nguồn giảm
lưu lượng đưa vào mạng.
- Mục tiêu quan trọng cần đạt được là tránh hiện tượng Global-synchronization và
không chống lại các luồng có lưu lượng đột biến. Như đã trình bày ở các phần
trước hiện tượng này xảy ra khi các thực thể phát đồng loại giảm kích thước cửa
sổ phát làm lưu lượng giảm nhanh trong cùng một thời điểm. Các chiến lược như
Droptail hoặc Random Drop rất nhạy cảm với các luồng lưu lượng đột biến tức là
các hàng đợi tại gateway thường sẽ bị tràn khi các gói tin của luồng này tới. Để
tránh hiện tượng này các RED gateway phải chọn các gói tin ngẫu nhiên tới để
đánh dấu. Với phương pháp này xác suất đánh dấu một gói tin từ một kết nối cụ
thể tỉ lệ với phần băng thông được chia sẻ cho kết nối đó tại gateway.
- Một mục tiêu quan trọng nữa của RED gateway cần đạt được đó là giữ kích thước
hàng đợi trung bình ngay cả khi không có sự hợp tác từ các thực thể nguồn phát
(nguồn phát sử dụng giao thức UDP). Có thể thực hiện điều này bằng cách loại bỏ
 34

gói tin khi kích thước trung bình của hàng đợi vượt qua ngưỡng trên thay vì đánh
dấu nó. Phương pháp này là cần thiết trong trường hợp hầu hết các kết nối có
khoảng thời gian phát nhỏ hơn thời gian đợi gói tin khứ hồi hoặc các thực thể
nguồn không có các cơ chế kiểm soát lưu lượng để phản ứng với việc đánh dấu
hay loại bỏ gói tin (như các luồng UDP)

c. Giải thuật và các tham số cho thuật toán RED

RED gateway tính kích thước hàng đợi trung bình bằng cách sử dụng bộ lọc thông
thấp LPF (Low Pass Filter). Kích thước hàng đợi trung bình được so sánh với hai ngưỡng
: Ngưỡng dưới 𝑚𝑖𝑛𝑡ℎ và ngưỡng trên 𝑚𝑎𝑥𝑡ℎ . Khi kích thước hàng đợi trung bình nhỏ
hơn ngưỡng dưới thì không gói tin nào bị đánh dấu hoặc loại bỏ, Khi kích thước hàng
đợi trung bình nằm trong khoảng 𝑚𝑖𝑛𝑡ℎ đến 𝑚𝑎𝑥𝑡ℎ thì RED gateway sẽ đánh dấu các
gói tin đến với một xác suất 𝑝𝑎 . Trong đó 𝑝𝑎 là một hàm theo kích thước hàng đợi trung
bình avg. Xác suất đánh dấu một gói tin của một kết nối cụ thể tỉ lệ với phần băng thông
chia sẻ của kết nối đó tại gateway. Giải thuật được mô tả trong giải mã sau:

Với mỗi gói tin đến gateway

Tính toán kích thước hàng đợi trung bình avg
Nếu 𝑚𝑖𝑛𝑡ℎ < kích thước hàng đợi trung bình avg < 𝑚𝑎𝑥𝑡ℎ
Tính xác xuất 𝑝𝑎
Với 𝑝𝑎 : Đánh dấu các gói tin đến
Nếu 𝑚𝑎𝑥𝑡ℎ < kích thước hàng đợi trung bình avg
Đánh dấu gói tin đến
Hình 2.7: Giải thuật tổng quát cho RED gateway

Như vậy giải thuật tại RED gateway được chia thành hai thuật toán tách biệt: Thuật
toán tính kích thước hàng đợi trung bình quyết định mức độ bùng nổ cho phép trong
hàng đợi tại gateway và Thuật toán tính xác suất đánh dấu quyết định mức độ thường
xuyên đánh dấu gói tin của gateway. Giải thuật đánh dấu gói tin phải đảm bảo sao cho
các gói tin đánh dấu tại những khoảng thời gian đều nhau để tránh hiện tượng đồng bộ
toàn cầu trong khi vẫn giữ kích thước hàng đợi trunh bình ở một khoảng nhất định

Giải thuật chi tiết được mô tả dưới đây:

 35

Khởi tạo:
avg ← 0
count ← -1
for mỗi gói tin đến
Tính kích thước hàng đợi trung bình avg:
if hàng đợi không rỗng
avg ← (1- 𝑤𝑞 ) avg + 𝑤𝑞 *q
else
m ← f(time – q_time)
avg ← (1-𝑤𝑞 )m avg
if 𝑚𝑖𝑛𝑡ℎ ≤ avg < 𝑚𝑎𝑥𝑡ℎ
count ++
Tính xác suất 𝑝𝑎 :
𝑝𝑎 ← 𝑚𝑎𝑥𝑝 (agv – 𝑚𝑖𝑛𝑡ℎ )/( 𝑚𝑎𝑥𝑡ℎ - 𝑚𝑖𝑛𝑡ℎ )
𝑝𝑎 ← 𝑝𝑏 / (1 – count. 𝑝𝑏 )
với xác suất 𝑝𝑎 :
đánh dấu gói tin đến
count ← 0
else if avg ≥ 𝑚𝑎𝑥𝑡ℎ
đánh dấu gói tin đến
count ← 0
else count ← -1
Khi Khi hàng đợi trở nên rỗng
q_time ← time

Hình 2.8: Giải thuật RED chi tiết

 36

Các biến thay đổi:

avg: kích thước hàng đợi trung bình
q_time: thời gian hàng đợi bắt đầu rỗng
count: số gói tin từ gói cuối cùng bị
đánh dấu
Các tham số cố định:
𝑤𝑞 : trọng số hàng đợi
𝑚𝑖𝑛𝑡ℎ : ngưỡng dưới của hàng đợi
𝑚𝑎𝑥𝑡ℎ : ngưỡng trên của hàng đợi
𝑚𝑎𝑥𝑝 : xác suất loại bỏ tối đa
Các tham số khác:
𝑝𝑎 : xác suất đánh dấu gói tin hiện tại
q: kích thước hàng đợi hiện tại
time: thời gian hiện tại
f(t): một hàm tuyến tính của thời gian t

Hình 2.9 Các tham số thuật toán RED

Theo giải thuật, mỗi khi có một gói tin đi đến hàng đợi, RED gateway sẽ tính kích
thước hàng đợi trung bình bằng bộ lọc:

avg ← (1- 𝑤𝑞 ) avg + 𝑤𝑞 *q

trong đó : q là kích thước hàng đợi trung bình hiện thời; 𝑤𝑞 là trọng sô của hàng đợi và
nhận giá trị trong khoảng 0..1. 𝑤𝑞 còn gọi là hệ số làm trơn và quyết định độ lớn và độ
kéo dài cho phép của sự bùng nổ lưu lượng.

Xác suất đánh dấu gói tin 𝑝𝑎 tăng chậm khi số gói tin từ gói cuối cùng được đánh
dấu count tăng lên. Điều này đảm bảo cho gateway không phải chờ quá lâu trước khi
đánh dấu một gói tin. RED gateway đánh dấu tất cả các gói tin nếu như kích thước hàng
đợi trung bình avg vượt quá 𝑚𝑎𝑥𝑡ℎ

Thêm 1 tùy chọn trong RED để đảm bảo xác suất để một gói tin bị loại bỏ tỉ lệ với
thông lượng tính bằng bit/s chứ không phải packet/s. Trong trường hợp này thì một gói
tin lớn sẽ dễ bị loại bỏ hơn một gói tin có kích thước nhỏ.
𝑃𝑎𝑐𝑘𝑒𝑡𝑆𝑖𝑧𝑒 𝑎𝑣𝑔−𝑚𝑖𝑛𝑡ℎ
𝑝𝑏 = ∗ 𝑚𝑎𝑥𝑝 ∗
𝑀𝑎𝑥𝑃𝑎𝑐𝑘𝑒𝑡𝑆𝑖𝑧𝑒 𝑚𝑎𝑥𝑡ℎ −𝑚𝑖𝑛𝑡ℎ
 37

Có bốn tham số cố định cần đặt trước trong thuật toán RED. Việc thiết lập các
thuật toán này là rất quan trọng vì nó ảnh hưởng tới chất lượng cũng như hiệu suất thuật
toán. Để mang lại hiệu quả cao nhất cho thuật toán chúng tôi sẽ trình bày song song hai
cách thiết lập các tham số: Định tính và định lượng (bằng mô phỏng) để có thể chọn ra
một bộ tham số hợp lý và đêm lại hiệu quả cao nhất. Tất cả mô phỏng trong luận văn
này đều được thực hiện trên bộ mô phỏng NS-2. Các tham số đầu vào được tác giả trong
[3] nghiên cứu rất kỹ bằng mô phỏng, sau khi lặp lại các mô phỏng đó và thấy rằng các
kết quả đó là hoàn toàn chính xác.

d. Trọng số hàng đợi 𝒘𝒒

Kích thước hàng đợi trung bình trong thuật toán RED được RED gateway tính toán
bằng cách sử dụng bộ lọc thông thấp. Sự gia tăng kích thước hàng đợi hiện tại do luồng
lưu lượng bùng nổ hoặc sử tắc nghẽn ngắn hạn sẽ không ảnh hưởng tới kích thước hàng
đợi kích thước hàng đợi trung bình: avg ← (1- 𝑤𝑞 ) avg + 𝑤𝑞 *q trong đó trọng số hàng
đợi 𝑤𝑞 đóng vai trò quyết định giá trị của avg. Nhìn vào công thức trên có thể thấy răng
nếu 𝑤𝑞 quá lớn thì kích thước hàng đợi trung bình avg sẽ bám sát kích thước hàng đợi
vào thời điểm hiện tại, khiến cho hàng đợi trống rất ít. RED gateway sẽ không thể hấp
thu được các luồng có lưu lượng bùng nổ.

Cận trên cho 𝒘𝒒

Giả sử ban đầu hàng đợi rỗng (kích thước trung bình bằng 0), sau đó khi có các
gói tin đến, số gói tin trong hàng đợi sẽ tăng từ 0 đến L (giả sử có L gói tin đi đến hàng
đợi) lúc này kích thước hàng đợi trung bình sẽ được tính như sau:
𝐿 1
𝑎𝑣𝑔𝐿 = ∑𝑖=1 𝑖𝑤𝑞 (1 − 𝑤𝑞 )𝐿−𝑖 =𝑤𝑞 (1 − 𝑤𝑞 )𝐿 ∑𝐿𝑖=1 𝑖( )𝑖
1−𝑤𝑞

(1−𝑤𝑞 )𝐿−𝑖 −1
=L+1+
𝑤𝑞

Với ngưỡng 𝑚𝑖𝑛𝑡ℎ cho trước và chúng ta muốn cho phép RED gateway hấp thu
bùng nổ đến L gói tin thì kích thước hàng đợi trung bình 𝑎𝑣𝑔𝐿 < 𝑚𝑖𝑛𝑡ℎ

(1−𝑤𝑞 )𝐿−𝑖 −1
L+1+ < 𝑚𝑖𝑛𝑡ℎ
𝑤𝑞
 38

Cận dưới cho 𝒘𝒒

Thuật toán RED được thế kế sao cho RED gateway luôn giữ hàng đợi ở mức trung
bình nằm dưới một ngưỡng nào đó. Tuy nhiên nếu giá trị 𝑤𝑞 được thiết lập quá thấp thì
avg sẽ phản ứng rất chậm với sự thay đổi nhanh của hàng đợi thực khiến cho gateway
không thế phát hiện được sự bắt đầu của tắc nghẽn. Theo các nghiên cứu và thực nghiệm
về thuật toán RED người ta khuyến cáo 𝑤𝑞 ≥ 0.001. Tùy điều kiện của mạng thực tế có
thể lựa chọn 𝑤𝑞 nằm trong khoảng (0.002,0.003).

e. Xác suất loại bỏ gói tin 𝒎𝒂𝒙𝒑

Số lượng gói tin bị loại bỏ tại RED gateway phụ thuộc vào giá trị của 𝑚𝑎𝑥𝑝 và sẽ
quyết định kích thước hàng đợi trung bình avg sẽ nằm trong khoảng nào giữa 𝑚𝑖𝑛𝑡ℎ và
𝑚𝑎𝑥𝑡ℎ . Vì thế tùy từng yêu cầu của mạng trong thực tế mà chúng ta lựa chọn giá trị
𝑚𝑎𝑥𝑝 phù hợp. Đối với mạng ít xảy ra tắc nghẽn thì nên thiết lập giá trị 𝑚𝑎𝑥𝑝 nhỏ để
tận dụng tối đa đường truyền và giảm số gói tin bị loại bỏ. Giá trị phù hợp ở đây thường
là 𝑚𝑎𝑥𝑝 = 0.02. Tuy nhiên đối với mạng hay xảy ra tắc nghẽn thì giá trị 𝑚𝑎𝑥𝑝 thường
được thiết lập lớn hơn. Giá trị thường được chọn là 𝑚𝑎𝑥𝑝 = 0.1

f. Thiết lập ngưỡng 𝒎𝒊𝒏𝒕𝒉 và 𝒎𝒂𝒙𝒕𝒉

Để thiết lập được giá trị tối ưu cho 𝑚𝑖𝑛𝑡ℎ và 𝑚𝑎𝑥𝑡ℎ cần xem xét tới rất nhiều yếu
tố, trong đó có kích thước hàng đợi trung bình mong muốn avg. Giá trị 𝑚𝑖𝑛𝑡ℎ và 𝑚𝑎𝑥𝑡ℎ
cần phải thoải mãn các yêu cầu sau:

- Để tận dụng tối đa đường truyền thì 𝑚𝑖𝑛𝑡ℎ và 𝑚𝑎𝑥𝑡ℎ cần được thiết lập giá trị cao
trong trường hợp lưu lượng trên mạng ít đột biến
- Nếu lưu lượng trong mạng thường xuyên có đột biến thì 𝑚𝑖𝑛𝑡ℎ và 𝑚𝑎𝑥𝑡ℎ cần được
thiết lập giá trị nhỏ để có thể hấp thu các lưu lượng này. Tuy nhiên khi thiết lập giá
trị nhỏ cho 𝑚𝑖𝑛𝑡ℎ và 𝑚𝑎𝑥𝑡ℎ khiến cho hiệu suất sử dụng đường truyền thấp gây
lãng phí dải thông, số gói tin bị loại bỏ không cần thiết sẽ cao hơn. Vì vậy cần cân
bằng giữa việc tận dụng tối đa đường truyền và khả năng hấp thu lưu lượng bùng
nổ sao cho hiệu suất sử dụng đường truyền là cao nhất.
 39

- Khoảng giá trị 𝑚𝑖𝑛𝑡ℎ và 𝑚𝑎𝑥𝑡ℎ ảnh hưởng tới biến thiên độ trễ, thông lượng và
khả năng hấp thu các đột biến tạm thời tại hàng đợi. Để tránh hiện tượng đồng bộ
toàn cầu thì không nên đề khoảng giá trị này quá nhỏ. Theo khuyến nghị thì nên
thiết lập 𝑚𝑎𝑥𝑡ℎ gấp đôi giá trị 𝑚𝑖𝑛𝑡ℎ

2.2.4. Thuật toán A-RED

Điều khiển tắc nghẽn đầu cuối được sử dụng rộng rãi trong các mạng ngày này để
ngăn chặn tắc nghẽn xảy ra. Tuy nhiên do lưu lượng dữ liệu đến các router dưới dạng
luồng nên các router cần được cung cấp hàng đợi lớn để hấp thu các lưu lượng bùng nổ
giúp duy trì việc sử dụng các kết nối. Khi tắc nghẽn xảy ra tại các router các gói tin sẽ
bị gia tăng độ trễ hàng đợi. Do đó cần phải chọn lựa giữa hiệu suất sử dụng đường truyền
cao (Kích thước hàng đợi lớn) hay độ trễ hàng đợi nhỏ (Kích thước hàng đợi nhỏ).

Thuật toán quản lý hàng đợi RED thì tích cực hơn do sử dụng quá trình loại bỏ
ngẫu nhiên bằng việc thay đổi kích thước hàng đợi trung bình. Mục tiêu chính của RED
là phối hợp giữa kích thước hàng đợi trung bình và thông báo tắc nghẽn sớm để đạt được
độ trễ hàng đợi trung bình thấp và thông lượng cao

Chiến lược quản lý hàng đợi động bằng cách sử dụng thuật toán RED cho phép
mạng đồng thời đạt được cả thông lượng cao và độ trễ thấp. Tuy nhiên RED có hai yếu
điểm cơ bản cần phải được khắc phục. Thứ nhất là kích thước hàng đợi trung bình nhạy
cảm với các cấp đội tắc nghẽn và các tham số đầu vào thiết lập trên router. Đối với mạng
có sự thay đổi lớn về các cấp độ tắc nghẽn thì việc thiết lập một bộ tham số đầu vào cho
RED gateway là khó. Độ trễ là một thành phần chính của QoS cấp phát cho người dùng,
để đạt được độ trễ trung bình có thể đoán trước thì cần phải liên tục hiệu chỉnh các tham
số đấu vào của thuật toán RED đáp ứng sự thay đổi liên tục của lưu lượng dữ liệu trên
mạng.

Điểm yếu thứ hai của RED là thông lượng cũng nhạy cảm với tải và các thông số
đầu vào của RED. Thường thì khi kích thước hàng đợi trung bình avg lớn hơn 𝑚𝑎𝑥𝑡ℎ
thì thuật toán RED không còn hiệu quả dẫn tới việc giảm đáng kể thông lượng và tăng
tỷ lệ loại bỏ gói tin. Để tránh hiện tượng này thì cũng cần liên tục điều chỉnh các tham
số đầu vào của thuật toán RED.
 40

a. Giải thuật A-RED

A-RED ra đời nhằm khắc phục hai nhược điểm của RED nguyên bản được đề xuất
bởi Feng từ năm 1997[17]. Cấu trúc RED vẫn được giữ nguyên và chỉ hiệu chỉnh thông
số 𝑚𝑎𝑥𝑝 để duy trì kích thước hàng đợi trung bình trong khoảng 𝑚𝑖𝑛𝑡ℎ đến 𝑚𝑎𝑥𝑡ℎ . Có
nhiều phiên bản A-RED được đưa ra tuy nhiên trong giới hạn luận án này chúng tôi giới
thiệu một phiên bản thuật toán A-RED trong đó người quản trị viên có thể lựa chọn chế
độ tự động thiết lập các tham số đầu vào cho RED gateway dựa trên độ trễ mong muốn
và kích thước miền hàng đợi trung bình mong muốn. Như vậy thuật toán A-RED này có
thể tự động thiết lập tất cả các tham số đầu vào của thuật toán RED dựa trên kết quả
mong muốn đạt được tránh trong những hạn chế lớn của RED

𝑚𝑎𝑥𝑝 được hiểu chỉnh không chỉ cho kích thước hàng đợi trung bình nằm trong
ngưỡng 𝑚𝑖𝑛𝑡ℎ , 𝑚𝑎𝑥𝑡ℎ mà còn giữ kích thước hàng đợi trung bình nằm trong một dải
cho phép nằm trong khoảng 𝑚𝑖𝑛𝑡ℎ , 𝑚𝑎𝑥𝑡ℎ . Giá trị 𝑚𝑎𝑥𝑝 được duy trì nằm trong khoảng
từ 0.01 đên 0.5.

Bằng mô phỏng có thể thấy rằng A-RED đạt được độ dài hàng đợi trung bình đích
với một miền rộng các kịch bản, có nghĩa là nó giữ nguyên được những ưu điểm của
RED. Điều này giúp quản trị viên dự đoán được độ trễ hàng đợi trung bình và hạn chế
khả năng kích thước hàng đợi trung bình vượt quá ngưỡng 𝑚𝑎𝑥𝑡ℎ từ đó giảm tỉ lệ mất
gói tin và sự thăng giáng độ trễ hàng đợi.

b. Giải thuật và các tham số trong thuật toán A-RED

Thuật toán A-RED cơ bản chia làm hai thuật toán chính la: Thuật toán RED và
thuật toán hiệu chỉnh 𝑚𝑎𝑥𝑝 , 𝑚𝑖𝑛𝑡ℎ , 𝑚𝑎𝑥𝑡ℎ . Sau đó 𝑚𝑎𝑥𝑝 lại được dùng trong thuật
toán RED. Thuật toán hiệu chỉnh 𝑚𝑎𝑥𝑝 được trình bày như Hình 2.10:
 41

Every interval giây:

if (avg > target and 𝑚𝑎𝑥𝑝 ≤ 0.5)
tăng 𝑚𝑎𝑥𝑝 : 𝑚𝑎𝑥𝑝 = 𝑚𝑎𝑥𝑝 + α;
elseif (avg < target and 𝑚𝑎𝑥𝑝 ≥ 0.01)
giảm 𝑚𝑎𝑥𝑝 : 𝑚𝑎𝑥𝑝 = 𝑚𝑎𝑥𝑝 * β;
Biến:
avg: kích thước hàng đợi trung bình
Các tham số cố định:
interval: thời gian; 0.5 giây
target: target for avg:
[𝑚𝑖𝑛𝑡ℎ + 0.4 * (𝑚𝑎𝑥𝑡ℎ – 𝑚𝑖𝑛𝑡ℎ ),
𝑚𝑖𝑛𝑡ℎ + 0.6 * (𝑚𝑎𝑥𝑡ℎ – 𝑚𝑖𝑛𝑡ℎ )]
α: hệ số tăng; min(0.01, maxp / 4);
β: hệ số giảm; 0.9

Hình 2.10: Giải thuật tổng quát cho A-RED gateway

Giới hạn trên của giá trị 𝑚𝑎𝑥𝑝 = 0.5 có thể được chỉnh sửa theo cách cố gắn tối ưu
RED để tốc độ loại bỏ gói tin nhỏ hơn 50%

2.2.5. Thuật toán RIO

Giới thiệu chung

Phần này chúng ta sẽ nghiên cứu về việc áp dụng các thuật toán quản lý hàng đợi
động trong kiến trúc các dịch vụ phân loại Diffserv. Kiến trúc này được định nghĩa bời
IETF nhằm cung cấp cho mạng IP sự đảm bảo chất lượng dịch vụ cho các lưu lượng
khác nhau cùng chia sẻ kênh truyển chung. Bằng việc sử dụng cờ đánh dấu trong một
số trường đặc biệt của gói tin IP để báo cho Router biết cách xử lý nào được áp dụng
cho mỗi gói tin. Điển hình của thuật toán quản lý hàng đợi động được áp dụng cho kiến
trúc mạng dịch vụ phân loại DiffServ là thuật toán A-RIO (Adaptive RED with IN and
OUT). Thuật toán này là sự kết hợp của A-RED và thuật toán RIO được đề xuất bởi
Julio Orozco, David Ros với mục đích chính bao gồm:

- Áp dụng cho kiến trúc mạng DiffServ nhằm đảm bảo chất lượng dịch vụ cho các
dịch vụ trong trường hợp nhiều luồng lưu lượng cùng chia sẻ một kênh truyền bằng
việc sử dụng các bit trong trường TOS của gói tin ip.
 42

- Đơn giản hóa cấu hình cho Router bằng việc tính toán tự động để chuyển đổi các
tham số đầu vào sang tham số routers.
- Cố gắng giữ hàng đợi ở mức trung bình ổn định quanh một giá trị khi tải nặng
không phụ thuộc vào hiện trạng lưu lượng

a. Ý tưởng Thuật toán RIO

Đối với các thuật toán như RED, A-RED router chỉ thực hiện tính toán hàng đợi
trung bình sau đó tiến hành đánh dấu hoặc loại bỏ gói tin, các gói tin đều được đối xử
bình đẳng với nhau và không có sự phân biệt ưu sự ưu tiên. Tuy nhiên trong thực tế hiện
nay khi mà tốc độ phát triển mạnh của Internet khiến cho sự đa dạng trong dịch vụ cũng
tăng. Người dùng hoàn toàn có thể yêu cầu nhà cung cấp để được sự ưu tiên cao hơn và
chấp nhận trả chi phí lớn hơn. Nếu sử dụng thuật toán RED hoặc A-RED cho trường
hợp này thì không thể giải quyết được bài toán, các luồng (ứng dụng) đã trả nhiều tiền
hơn cũng chỉ được cung cấp 1 lượng dịch vụ như những luồng khác. Chính vì lẽ đó thuật
toán RIO ra đời dựa trên sự cải tiến của thuật toán RED bằng cách phân chia các gói tin
đến theo hai mức ưu tiên là “In” và “Out”. Việc gắn thẻ cho mỗi gói tin phụ thuộc vào
thỏa thuận giữa khách hàng và nhà cung cấp dịch vụ theo đó, các gói tin có gắn thẻ “In”
nghĩa là các gói tin này nằm trong dịch vụ đã được thỏa thuận trước, các gói tin có gắn
thẻ “Out” có nghĩa là không nằm trong hồ sơ dịch vụ. Khi tắc nghẽn xảy ra các router
sẽ ưu tiên loại bỏ các gói tin có gắn thẻ “Out” nhanh hơn. Tuy nhiên RIO không phân
tách các luồng thành các lớp hoặc các hàng đợi khác nhau mà gộp tất cả chung vào một
hàng đợi.

RIO là viết tắt của RED with In/Out bit. Vì được cải tiến từ RED nên nó có đầy
đủ các ưu điểm của RED như đạt thông lượng cao, hiệu suất sử dụng đường truyền lớn,
độ trễ thấp, kích thước hàng đợi trung bình nhỏ ngoài ra nó còn phân biệt các gói tin
theo hai mức ưu tiên là “In” và “Out”. Việc sử dụng bộ đôi thuật toán RED cho các gói
tin “In” và “Out” với thiết lập thông số khác nhau khiến cho các gói tin “Out” bao giờ
cũng bị loại bỏ sớm hơn khi tắc nghẽn xảy ra.

b. Giải thuật

Tương tự như RED nhưng RIO được thiết lập hai bộ tham số riêng biệt, một bộ
dành cho các gói tin với thẻ “In” và một bộ tham số dành cho gói tin thẻ “Out”. Khi một
 43

gói tin đi tới RIO gateway nó sẽ kiểm tra xem gói tin này có gắn thẻ “In” hay “Out” và
tính toán hàng đợi trung bình tương ứng với các gói tin.

Nếu gói tin đi tới có gắn cơ “In” thì RIO gateway sẽ tính avg_in, ngược lại nếu gói
tin đi tới có gắn thẻ Out thì RIO gateway sẽ tính avg_total. Xác suất loại bỏ gói tin “In”
phụ thuộc vào kích thước hàng đợi trung bình avg_in và xác suất loại bỏ gói tin “Out”
phụ thuộc vào kích thước hàng đợi trung bình avg_total. Giải thuật được mô tả như
Hình 2.11 dưới đây:

For mỗi gói tin đến

if nó là gói tin In
tính kích thước trung bình hàng đợi
In: avg_in;
tính kích thước trung bình hàng đợi tổng
avg_total;
if nó là gói tin In
if min_in < avg_in < max_in
tính xác suất 𝑃𝑖𝑛 ;
loại bỏ gói tin này với xác suất 𝑃𝑖𝑛 ;
else if max_in < avg_in
loại bỏ gói tin này.
if nó là gói tin Out
if min_out <avg_total < max_out
tính xác suất 𝑃𝑜𝑢𝑡 ;
loại bỏ gói tin này với xác suất 𝑃𝑜𝑢𝑡 ;
else if max_out <avg_total
loại bỏ gói tin này;

Hình 2.11 Giải thuật RIO

RIO gateway sẽ loại bỏ hầu hết các gói tin có gắn thẻ “Out” khi tắc nghẽn bắt đầu
xảy ra và khi tắc nghẽn kéo dài sẽ loại bỏ toàn bộ các gói tin “Out”, Các gói tin “In” rất
ít khi bị loại bỏ trừ trường hợp tắc nghẽn xảy ra do toàn bộ các gói tin “In”. Tuy nhiên
với mạng được điều khiển tốt thì trường hợp này rất ít khi xảy ra và nếu xảy ra trường
hợp đó thì mạng có thể coi là không chấp nhận được.

Chưa có bất cứ chuẩn mực nào trong việc lựa chọn avg_total sao cho hợp lý. Nếu
ta chọn avg_out dành cho các gói tin “Out” thì việc lựa chọn tham số cho hàng đợi trung
 44

bình này rất khó và không có sự tương quan rõ ràng nào giữa các tham số dành cho gói
in “In”. Việc sử dụng avg_total dành cho cả hai loại gói tin giúp cho RIO gateway có
thể giữ được kích thước hàng đợi trung bình đủ nhỏ và đạt được thông thượng cao bất
kể lưu lượng nào trộn lẫn vào.

2.2.6. Thuật toán A-RIO

Đây là một mở rộng trực tiếp từ thuật toán A-RED và RIO. A-RIO đi theo cách
tiếp cận của thuật toán A-RED, các thông số đầu vào của thuật toán được hiệu chỉnh
online một cách tự động nhằm đạt được hiệu suất mong muốn đã đặt trước, có nhiều
cách tiếp cận được đưa ra nhằm hiệu chỉnh các thông số thuật toán RED theo kết quả
mong muốn đạt được, A-RED được chọn vì tính đơn giản trong cài đặt của nó.

Giống như A-RED, A-RIO chỉ cần một tham số đầu vào là độ trễ mà người dùng
mong muốn đạt được, A-RIO sẽ tự động ánh xạ sang tập các tham số đầu vào. Đặc trưng
này rất có ý nghĩa đối với nhà cung cấp dịch vụ phân loại cấu hình router theo độ trễ -
một độ đo QoS liên quan trực tiếp đến đặc tả dịch vụ và đặc tả yêu cầu người dùng, dễ
hiểu hơn rất nhiều so với các tham số trìu tượng như các ngưỡng hàng đợi, xác suất loại
bỏ gói tin hoặc trọng số trung bình.

Do là mở rộng trực tiếp từ thuật toán A-RED nên A-RIO vẫn giữ được những ưu
điểm và đặc trung của A-RED như:

 Xác suất loại bỏ gói tin 𝑚𝑎𝑥𝑝 chạy từ 0.01 đến 0.5
 Ngưỡng dưới 𝑚𝑖𝑛𝑡ℎ được tính theo độ trễ hàng đợi mong muốn (đích) 𝑑𝑡 và dung
lượng đường truyền C (packet/s) với cận dưới là 5 gói tin thì: 𝑚𝑖𝑛𝑡ℎ =
max(5, 𝑑𝑡 . 𝐶/2). Ngưỡng 𝑚𝑎𝑥𝑡ℎ luôn được tính cố định bằng 3. 𝑚𝑖𝑛𝑡ℎ
 𝑤𝑞 cũng được tính theo dung lượng đường truyền: 𝑤𝑞 = 1 − exp(−1/𝐶)
 Nếu tải thay đổi một cách đột ngột thì kích thước hàng đợi trung bình có thể nằm
ngoài khoảng mục tiêu, khi đó các tham số α, β được chọn cố định sao cho kích
thước hàng đợi trung bình sẽ quay trở lại miền mục tiêu trong vòng 25 giây.
 45

(𝑖)
 Hàm hiệu chỉnh 𝑚𝑎𝑥𝑝 được tính theo luật AIMD (tăng theo cấp số cộng, giảm
(𝑖)
theo cấp số nhân) nhằm tránh sự thay đổi đột ngột của 𝑚𝑎𝑥𝑝 dẫn tới sự dao động
mạnh của kích thước hàng đợi.

Trên đây là một số thuật toán quản lý hàng đợi động điển hình, ngoài ra còn nhiều
thuật toán khác là biến thể từ các thuật toán trên nhưng không được đề cập trong nội
dung luận văn, các thuật toán đều có ưu, nhược điểm riêng tùy vào từng trường hợp
mạng cụ thể mà người ta có thể chọn chiến lược sao cho đạt được hiệu quả cao nhất.
Chương tiếp theo sẽ trình bày mô phỏng để đánh giá các thuật toán quản lý hàng đợi
động RED và FIFO truyền thống, áp dụng thuật toán RED trong kiến trúc mạng DiffServ
nhằm đảm bảo chất lượng dịch vụ cho các ứng dụng đa phương tiện thời gian thực trên
Internet.
 46

Chương 3. ĐÁNH GIÁ HIỆU QUẢ ĐẢM BẢO QOS CHO TRUYỀN
THÔNG ĐA PHƯƠNG TIỆN THỜI GIAN THỰC CỦA MỘT SỐ CHIẾN
LƯỢC QUẢN LÝ HÀNG ĐỢI

3.1. Đánh giá bằng mô phỏng hiệu quả của thuật toán RED

Các mô phỏng trong luận văn này được thực hiện trên bộ mô phỏng NS-2 đã
được cộng đồng nghiên cứu và sử dụng rộng rãi đặc biệt là trong các trường đại học và
các viện nghiên cứu. Sau đây là phần trình bày mô phỏng của tôi nhằm đánh giá và so
sánh hiệu suất của thuật toán RED so với DropTail

Hình 3.1: Cấu hình mạng mô phỏng DropTail & RED

Mô phỏng đánh giá hiệu suất của thuật toán RED so với DropTail, mỗi loại tôi đưa
ra 3 đồ thị biểu diễn đó là : Kích thước hàng đợi trung bình, thông lượng, và kích thước
cửa sổ của mỗi kết nối TCP để tìm ra ưu nhược điểm của 2 giải thuật quản lý hàng đợi
này.

Mạng mô phỏng bao gồm 6 nút, các luồng tcp1, tcp2, tcp3 được gắn vào các nút
1, 2, 3. Luồng udp được gắn vào nút 4, đường truyền chia sẻ từ nút 0 đến nút 5, tại đây
sử dụng hàng đợi RED hoặc DropTail, tất cả các kết nối đều là full-duplex và mặc định
không lỗi.
 47

 Kết nối từ nút 0 đến nút 1, 2, 3 có băng thông 10Mbps, độ trễ 1ms.
 Kết nối từ nút 0 đến nút 4 có băng thông 2Mbps, độ trễ 10ms.
 Kết nối từ nút 0 đến nút 5 có băng thông 2Mbps, độ trễ 20ms. Sử dụng hàng đợi
RED hoặc DropTail
 Các thực thể gắn với 3 luồng TCP ở đây là giao thức FTP (ftp1, ftp2, ftp3). Kích
thước các gói tin TCP được gửi đỉ là 1000byte với kích thước cửa sổ tối đa là 100
gói tin. Các thực thể này phát gói tin theo thời gian ngẫu nhiên trong khoảng từ 0
– 3s từ lúc bắt đầu chạy mô phỏng.
 Thực thể gắn với luồng udp ở đây là nguồn phát CBR (Nguồn phát sinh lưu lượng
không đổi có tốc độ phát là 2Mbps). Thực thể udp bắt đầu sinh lưu lượng vào
khoảng 5 – 7s và từ 8 – 10s để tạo lưu lượng đột biến
 Hàng đợi được đặt trên kết nối từ node 0 đến node 5 kích thước 100 gói tin. Toàn
bộ mô phỏng được chạy trong khoảng thời gian 50s.
 Các tham số được thiết lập cho RED như sau: minth = 5, maxth = 15, maxp = 0.1
và wq = 0.002.

Sau khi chạy mô phỏng 2 thuật toán trên với cùng một kích bản mô phỏng chúng
thu được kết quả:

Chiến lược Số gói tin Kích thước hàng Độ trễ hàng đợi Hệ số sử dụng
(packet) đợi trung bình trung bình (ms) đường truyền
(packet) (%)

DropTail 11944 73.00 389.33 95.55

RED 11728 8.00 42.67 93.82

Bảng 3.1: So sánh RED với DropTail

 48

Hình 3.2: Mô phỏng DropTail Hình 3.3: Mô phỏng RED

a) Kích thước hàng đợi trung bình a) Kích thước hàng đợi trung bình

b) Kích thước cửa sổ b) Kích thước cửa sổ

c) Thông lượng trung bình các kết nối c) Thông lượng trung bình các kết nối
 49

Nhận xét về kết quả mô phỏng chiến lược DropTail: Nhìn đồ thị có thể thấy
được rằng hiện tượng lockout xảy ra khi có lưu lượng đột vào khoảng thời gian từ 5 –
7s và từ 8 – 10s (Nguồn CBR sinh lưu lượng có tốc độ cao hơn dung lượng đường truyền
tại nút 0) dẫn tới việc các kết nối TCP đồng loạt giảm kích thước cửa sổ phát, dẫn tới
việc thông lượng của các kết nốt TCP giảm đột ngột về gần bằng 0. Ngay cả khi nguồn
CBR đã ngừng hoạt động vào khoảng 10 - 12s thì thông lượng của các luồng TCP vẫn
giảm về gần 0 do cơ chế rút lui theo hàm mũ của TCP trong khi đó thì hàng đợi vẫn đầy.
DropTail đã không tránh khỏi hiện tượng Global Synchronization.

Ngay cả khi nguồn CBR không hoạt động thì hiện tượng Global Synchronization
vẫn xảy ra vào các khoảng thời gian 24s, 34s, 44s, khi các kết nối TCP cùng tăng kích
thước cửa sổ phát đạt đến ngưỡng và đồng loạt giảm. Kích thước trung bình của hàng
đợi luôn giữ ở mức rất cao.

Nhận xét về kết quả mô phỏng chiến lược RED: Trong gian đoạn 12s đầu tiên
khi có lưu lượng đột biến vào mạng thì các kết nối TCP giảm kích thước cửa sổ phát
dẫn tới việc thông lượng của các kết nối này giảm tuy nhiên ngay sau đó chúng đã tăng
kích thước cửa sổ phát và thông lượng cũng tăng ngay sau đó, kích thước hàng đợi có
tăng nhưng nhanh chóng giảm và giữ ở mức ổn định. Trong khoản thời gian còn lại
không có đột biến lưu lượng thì RED luôn duy trì kích thước hàng đợi trung bình trong
1 khoảng nhỏ trong khoảng từ 6 – 10 gói tin.

Nhận xét: Nhìn chung có thể thấy rằng chiến lược DropTail không tránh được hiện
tượng Global synchronization không hỗ trợ chia se băng thông công bằng giữa các kết
nối nhất là khi có lưu lượng bùng nổ vào mạng thì không giữ được các kết nối đã có sẵn.

RED tránh được hiện tượng lockout và Global synchronization. Việc giữ kích
thước hàng đợi đủ nhỏ nên đạt được độ trễ hàng đợi nhỏ hơn nhiều lần so với DropTail
trong khi vẫn giữ được hệ số sử dụng đường truyền cao.

3.2. Đánh giá bằng mô phỏng việc áp dụng kiến trúc mạng Diffserv có sử dụng
RED

Việc mô phỏng đảm bảo chất lượng dịch vụ cho các ứng dụng thời gian thực trên
Internet dựa trên kiến trúc mạng DiffServ được thực hiện trên bộ mô phỏng NS2. Trong
kết nối TCP việc mất mát một số gói tin thường ảnh hưởng nhiều tới hiệu năng của phiên
 50

kết nối so với đa số các gói tin còn lại. Những gói tin này thường là những gói tin điều
khiển thiết lập kết nối, điều khiển lưu lượng, kiểm soát lỗi. Ta gọi những gói tin này là
những gói tin có độ ưu tiên cao. Việc đánh dấu các gói tin này và cung cấp chất lượng
dịch vụ cao hơn trong kiến trúc DiffServ sẽ làm hiệu suất của TCP được cải thiện đáng
kể. Tuy nhiên việc đánh dấu gói tin yêu cầu các thành phần lớp mạng biết về thông tin
lớp vận chuyển. Mục đích của mô phỏng mà chúng tôi giới thiệu để chỉ ra rằng có thể
đánh dấu ưu tiên các gói tin quan trọng mà không cần bất kỳ thông tin nào của lớp vận
chuyển, vì vậy sẽ đơn giản hóa các việc thực hiện đánh dấu các gói tin TCP.

Về phân loại dịch vụ thường có 3 mức ưu tiên được định nghĩa. Mức ưu tiên cao
nhất thường được gọi là “in policy” hay Green packets, mức ưu tiên thấp hơn chia thành
2 mức là Yellow Packets và thấp nhất là Red packets hay “Out policy”.

Thuật toán RED được sử dụng trong hàng đợi nhằm tránh tắc nghẽn còn trong kiến
trúc mạng DiffServ thì thuật toán RED được sử dụng để loại bỏ các gói tin có đánh dấu
“Out Policy”

3.2.1. Cấu hình mạng mô phỏng

Chúng ta sẽ xem xét một topo mạng đơn giản để mô phỏng mạng DiffServ trong
đó ký hiệu các router biên là EDGE1 và EDGE2, còn router lõi là Core, hàng đợi sử
dụng giữa router biên và router core là hàng đợi MRED, Các thực thể gửi và nhận là
UDP sender và UDP Rec. Nguồn phát là nguồn CBR (nguồn sinh lưu lượng với tốc độ
không đổi), băng thông và độ trễ được mô tả đầy đủ trong Hình 3.4 Hàng đợi được sử
dụng giữa các Router EDGE và các thực thể gửi, nhận là hàng đợi DropTail. Topo mạng
này có một nút cổ chai tại hàng đợi từ router EDGE1 đến router CORE.
 51

Hình 3.4: Topo mạng mô phỏng

Mỗi node gửi sẽ được kết nối với node nhận tương ứng với lưu lượng được đánh dấu
theo các tham số đã chỉ rõ. Có 3 node nguồn, mỗi node sẽ liên tục gửi các gói tin UDP
tới các node đích (được ghi nhãn với số thứ tự tương ứng). Tổng tốc độ gửi của 3 node
là (600,000bps*3)=1,800,000bps. Mô phỏng trên mạng LAN có tốc độ cao, độ trễ thấp
và đường truyền đối xứng.

Mô hình lưu lượng: Đảm bảo chất lượng dịch vụ cho node UDP Sender 0

 Node UDP Sender 1 sẽ bắt đầu truyền từ 0.1s

 Node UDP Sender 0 sẽ bắt đầu truyền từ 5.0s
 Nodd UDP Sender 2 sẽ bắt đầu truyền từ 15.0s

Hàng đợi MRED được xây dựng tại router EDGE1, do băng thông đường truyền
giữa Router EDGE1 với router CORE chỉ có 1Mbps nên nhỏ hơn tổng tốc độ truyền của
3 Node nên ở đây sẽ xảy ra tắc nghẽn. Hàng đợi MRED tại đây sử dụng mode RIO-C
và chia thành 3 hàng đợi vật lý, mỗi hàng đợi vật lý lại chia thành 3 hàng đợi ảo, các
tham số hàng đợi là giống nhau. Mục đích của việc này không phải để tìm một bộ tham
số tối ưu để đạt được hiệu năng cần thiết cho mô phỏng, thay vào đó ta sẽ thử nghiệm
dựa trên các điều kiện tham số đầu vào để nghiên cứu ảnh hưởng của Kiến trúc Diffserv
đến việc đảm bảo chất lượng dịch vụ cho các ứng dụng có dộ ưu tiên cao.
 52

Có 3 mức ưu tiên được định nghĩa dựa trên chính sách Single Rate Three Color
Marker (srTCMPolicer): Sử dụng các tham số CIR, CBS, EBS để phân loại và đánh
dấu các gói tin thành “Green packets”, “Yellow packets”, “Red packets”. Gói tin được
đánh dấu là Green khi chưa vượt qua ngưỡng CBS, được đánh dấu là Yellow khi vượt
qua ngưỡng CBS nhưng chưa vượt qua ngưỡng EBS và được đánh dấu là Red khi vượt
qua ngưỡng EBS.

Mô phỏng dựa trên 3 hàng đợi vật lý, mỗi kết nối từ node nguồn đến node đích
được gán trên một hàng đợi vật lý riêng. Chế độ lập lịch cho hàng đợi sử dụng trong mô
phỏng là WIRR với các trọng số lần lượt là 6, 3, 1 cho hàng đợi 0, 1, 2.

Kết quả mô phỏng đối với trường hợp tắc nghẽn thấp tại do tốc độ truyền của
nguồn UDP Sender 0 thấp.

Hình 3.5: So sánh thông lượng các kết nối UDP

 53

Hình 3.6: So sánh kích thước hàng đợi trung bình

Hình 3.7: So sánh độ trễ hàng đợi trung bình

 54

Code Point Gói tin nhận Gói tin gửi Drop RED Drop

All 9743 5889 689 3165

10 333 333 0 0

11 500 500 0 0

12 2542 2542 0 0

20 167 142 25 0

21 200 98 52 50

22 2258 1078 109 1071

30 174 174 0 0

31 200 200 0 0

32 3369 822 503 2077

Bảng 3.2: Thông kê gói tin

Source Packet send Packet loss Lost rate (%)

UDP Sender 0 3368 0 0

UDP Sender 1 2587 1289 49.7

UDP Sender 2 3666 2487 67.38

Bảng 3.3: Thống kê Từng kết nối

 55

Kết quả mô phỏng 2: Thay đổi tốc độ truyền của UDP Sender 0 từ 600.000bps lên
1.000.000bps

Hình 3.8: So sánh thông lược các kết nối UDP

Hình 3.9: So sánh kích thước hàng đợi trung bình

 56

Hình 3.11: So sánh độ trễ hàng đợi trung bình

Thống kê các gói tin

CP Gói tin nhận Gói tin gửi Drop RED Drop

All 11993 6029 1027 4937

10 333 333 0 0

11 500 368 0 132

12 4792 2994 0 1798

20 167 140 27 0

21 200 99 68 33

22 2258 1072 108 1078

30 174 171 3 0

31 200 200 0 0

32 3369 652 821 1896

Bảng 3.4: Thông kê gói tin trường hợp tắc nghẽn nhiều
 57

Source Packet send Packet loss Lost rate (%)

UDP Sender 0 5601 1922 34.3

UDP Sender 1 2592 1296 50.0

UDP Sender 2 3627 2640 72.7

Bảng 3.5: Thống kê Từng kết nối

Nhận xét về các kết quả mô phỏng được:

Việc sử dụng bộ lập lịch WIRR để đảm bảo băng thông tối thiểu cho hàng đợi 0
khiến cho thông lượng kết nối UDP Sender 0 – UDP Rec 0 luôn giữ ở mức trung bình
khoảng 600Bps, kết nối có kích thường hàng đợi trung bình và độ trễ hàng đợi rất thấp.
Với việc thiết lập tốc độ truyển của UDP Sender 0 là 600.000bps ngang bằng với phần
băng thông được chia sẻ của hàng đợi 0 (0.6Mbps) khiến cho kích thước hàng đợi trung
bình gần như bằng 0, các packet sau khi tới hàng đợi được xử lý luôn.

Sau khi thiết lập tốc độ truyền tăng cường lên 1Mbps thì tại hàng đợi 0 bắt đầu xảy
ra tắc nghẽn do băng thông chia sẻ không đáp ứng kịp tốc độ truyền. Khi đó thuật toán
RED trên hàng đợi bắt đầu có tác dụng. Việc áp dụng kiến trúc Diffserv để phân loại
gói tin thành các mức ưu tiên loại bỏ khác nhau, hàng đợi RED bắt đầu loại bỏ các gói
tin có độ ưu tiên thấp để giữ kích thước hàng đợi năm trong ngưỡng đã thiết lập và độ
trễ hàng đợi thấp. Không có gói tin Green nào bị loại bỏ.

Mô phỏng việc đánh dấu và đảm bảo chất lượng dịch vụ sử dụng kiến trúc DiffServ
có thể chưa đem lại sự cải thiện đáng kể trong một vài trường hợp. Có thể thấy rằng việc
DiffServ bảo vệ rất tốt các gói tin có ưu tiên cao (Green packets) thường được gọi là các
goi tin nhạy cảm. Việc mất mát các gói tin này thường dẫn tới giảm hiệu suất đang kể
của phiên kết nối. Trong một số trường hợp mất gói tin đồng bộ sẽ dẫn tới thời gian
timeout 3s hoặc 6s đối với các kết nối TCP.

Việc cam kết băng thông tối thiểu dành cho một người dùng cụ thể có thể thực
hiện được bằng cách gán người dùng đó với một hàng đợi riêng biệt và cấp phát một
lượng băng thông như đã cam kết cho hàng đợi đó. Như vậy ta có thể đạt được cả hai
mục tiêu đó là vừa đảm bảo được băng thông tối thiểu cho người dùng đặt trước và vừa
bảo vệ được luồng dữ liệu nhạy cảm khi tắc nghẽn xảy ra tại chính người dùng đó.
 58

3.3. Kết luận và hướng nghiên cứu tiếp theo

A. KẾT LUẬN
RED là một trong những thuật toán AQM đầu tiên và được nghiên cứu rất nhiều
trên thế giới, hầu hết các nghiên cứu đó đều công nhận hiệu quả của nó đạt được. tuy
nhiên nó vẫn có những nhược điểm cố hữu là nhạy cảm với các tham số đầu vào và điều
kiện của mạng. Ngoài ra RED không đảm bảo được sự công bằng cho các luồng dữ liệu
khác nhau. Mục tiêu chính của RED là giữ hàng đợi trung bình đủ nhỏ trong một miền
định trước nhằm hấp thu đột biến tức thời giúp mạng đạt được thông lượng cao và độ
trễ thấp. Các thuật toán A-RED, RIO, A-RIO ra đời nhằm khắc phục các nhược điểm
của RED với việc đơn giản hóa các tham số đầu vào và cố gắng đạt được sự công bằng
cho một lớp lưu lượng riêng.

Kiến trúc mạng IntServ ra đời nhằm đảm bảo chất lượng dịch vụ cho một lớp lưu
lượng đặt trước bằng cách đặt trước tài nguyên từ nguồn tới đích tuy nhiên lại có nhiều
nhược điểm như khả năng mở rộng kém trong mạng lõi, chi phí cao, cài đặt phức tạp.

Kiến trúc mạng DiffServ được phát triển với những ưu điểm trái ngược với kiến
trúc IntServ, với việc phân loại gói tin thành các mức độ ưu tiên khác nhau và áp dụng
những chính sách khác nhau cho từng mức ưu tiên đó khiến cho DiffServ đạt được tính
linh động rất tốt, dễ cài đặt và mở rộng. Việc áp dụng chiến lược RED trong mô hình
kiến trúc mạng DiffServ giúp người quản trị có thể vừa đạt được công bằng cho các
luồng dữ liệu, bảo vệ các luồng dữ liệu nhạy cảm vừa đạt được thông lượng và độ trễ
cao nhờ thuật toán RIO.

B. HƯỚNG NGHIÊN CỨU TIẾP THEO.

Chúng tôi sẽ tiếp tục nghiên cứu sâu hơn về kiến trúc mạng DiffServ cụ thể là:

Ảnh hưởng của việc thay đổi thuật toán lập lịch giữa các hàng đợi trong kiến trúc
mạng DiffServ.
Ảnh hưởng của các lưu lượng cũng như các gói tin khác nhau đến hiệu năng của
thuật toán RIO.
 59

TÀI LIỆU THAM KHẢO

1. Nguyễn Đức Thắng, Nguyễn Ngọc Chân, Trần Công Hùng, Giải pháp đảm bảo
chất lượng dịch vụ (QoS) cho mạng lõi.
2. Nguyễn Thị Thu Huyền, Đồ án: Nghiên cứu về QoS và định hướng phát triển
mạng viễn thông Việt Nam
3. Vũ Duy Lợi, Nguyễn Đình Việt, Ngô Thị Duyên, Lê Thị Hợi (2004), “Đánh giá
hiệu suất chiến lược quản lý hàng đợi RED bằng bộ mô phỏng NS”, Kỷ yếu Hội
thảo Khoa học Quốc gia lần thứ hai về Nghiên cứu, Phát triển và Ứng dụng Công
nghệ Thông tin và Truyền thông (ICT.rda'04), (Hà nội, 2425/9/2004). NXB Khoa
học và Kỹ thuật, Hà Nội, 5/2005, trang 394-403.
4. Lê Đình Danh(2007), Luận văn cao học: Thuật toán quản lý hàng đợi A-RIO
5. Sally Floyd and Van Jacobson, “Random Early Detection Gateways for
Congestion Avoidance” Lawrence Berkeley Laboratory University of California
6. Eitan Altman, Tania Jimenez, “NS Simulator for Beginners”
7. RFC: 2474, 2475, 2597, 2598, 3260, 2697
8. Luigi Alcuri, Francesco Saitta , Telephony Over IP: A QoS Measurement-Based
End to End Control Algorithm and a Queue Schedulers Comparison
9. D. Stiliadis, A. Varma (1998), “Efficient Fair Queuing Algorithms for
PacketSwitched Networks”, IEEE Trans. Networking, Vol. 6, No. 2, pp. 175-185
10. David D.Clark, Wenjia Fang (1998), “Explixit Allocation of Best Effort Packet
Delivery Service”, Labratory for Computer Sciences Computer Science
Department, Massachusetts Institute of Technology Princeton University
A. Demers, S. Keshav and S. Shenkar (1989), “Analysis and Simulation of a Fair
Queuing Algorithms”
11. Ns2 Document, http://www.isi.edu/nsnam/ns/doc/
12. Luigi Alcuri, Francesco Saitta, “Telephony Over IP: A QoS Measurement-Based
End to End Control Algorithm and a Queue Schedulers Comparison” Viale delle
Scienze 9, 90128 Palermo Italy
13. Jia-Shiang Jou, Xiaobo Tan and John S. Baras, “A Parallel Virtual Queue
Structure for Active Queue Management” Department of Electrical and Computer
 60

Engineering and Institute for Systems Research University of Maryland, College

Park, MD 20742 USA
14. Mikko Vanhala, “Differentiated Services – architecture” 44368D Teknillinen
korkeakoulu Teletekniikan laboratorio
15. Oyetunji M.O, Oladeji F.A Emuoyinbofarhe O.J, “Performance Evaluation of
Traffic Meters: Token Bucket Marker and Two Rate Three Color Marker (trTCM)
QoS Admission Control”
16. Rong Pan, “Active Queue Management” Cisco System EE384y Spring Quarter
2006
17. W. Feng, D. Kandlur, D. Saha, and K. G. Shin (1999), “A Self-Configuring RED
Gateway”, In Proceedings of IEEE INFOCOM, pages 1320-1328.
18. Andrew s. Tanenbaum, The Netherlands Computer networks fifth edition, Vrije
Universiteit Amsterdam, The Netherlands