Nhận viết luận văn Đại học , thạc sĩ - Zalo: 0917.193.864 Tham khảo bảng giá dịch vụ viết bài tại: vietbaocaothuctap.net Download luận văn thạc sĩ ngành công nghệ thông tin với đề tài: Đả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, cho các bạn làm luận văn tham khảo

1. ĐẠ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

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

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

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

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

6. 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
3 AIMD
Additive-Increase
Multiplicative-Decrease
Tăng theo cấp số cộng, giảm
theo cấp số nhân
4 AQM
Active Queue
Management
Quản lý hàng đợi động
5 A-RIO
Adaptive – RED with
In/Out bit
Thuật toán RED thích nghi với
bit In/Out
6 CBQ
Class-Based Weighted
Fair Queuing
7 CBR Constant Bit Rate
8 CBS Committed Burst Size Kích thước cụm cam kết
9 CIR
Committed Information
Rate
Tốc độ thông tin cam kết
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
13 ECN
Explicit Congestion
Notification
Cờ thông báo tắc nghẽn
14 EF Expedited Forwarding
15 FIFO First In First Out

7. 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ụ
28 RED
Random Early Detection/
Random Early Drop
Phát hiện sớm ngẫu nhiên, Loại
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
33 RSVP
Resource Revervation
Protocol
Giao thức dành trước tài
nguyên

8. 34 TCP
Transmission Control
Protocol
Giao thức điều khiển truyền
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
38 WFQ
Flow-Based Weighted
Fair Queuing
Hàng đợi luồng có trọng số
39 WIRR
Weighted Interleaved
Round Robin

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

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

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

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

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

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

15. 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ụ

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

17. 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ế

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

19. 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…

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

21. 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ý

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

23. 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ế

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

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

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

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

28. 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:

29. 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:

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

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

32. 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)
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
góisGói tin đến
Hàng đợi
Gói tin đi
Link

33. 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ì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
góisGói tin đến
Hàng đợi 1
Gói tin đi
Link
Hàng đợi 2
Phân loại

34. 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ình 2.3: Cơ chế phục vụ hàng đợi PBRR (Packet-Based Round Robin)
góisGói tin đến
Hàng đợi 1
Gói tin đi
Link
Hàng đợi 3
Phân loại Hàng đợi 2

35. 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à

36. 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 đó.
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
góisGói tin đến
Hàng đợi 1
Gói tin đi
Link
Hàng đợi 3
Phân loại Hàng đợi 2
𝑤1
𝑤2
𝑤3

37. 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.
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
Ipv4 header
payload
TOS Bytes
3 bits
IP precedence bits

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

39. 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.
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
links
Agency A 40%
Agency B 30% Agency C 30%
HTTP
20%
FTP
10%
POP3
10%
TCP
10%
IP 20% HTTP
20%
SSH
10%
RTP
10%
FTP
10%

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

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

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

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

44. 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ỏ

45. 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:
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:
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

46. 35
Hình 2.8: Giải thuật RED chi tiết
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

47. 36
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ỏ.
𝑝 𝑏 =
𝑃𝑎𝑐𝑘𝑒𝑡𝑆𝑖𝑧𝑒
𝑀𝑎𝑥𝑃𝑎𝑐𝑘𝑒𝑡𝑆𝑖𝑧𝑒
∗ 𝑚𝑎𝑥𝑝 ∗
𝑎𝑣𝑔−𝑚𝑖𝑛 𝑡ℎ
𝑚𝑎𝑥 𝑡ℎ−𝑚𝑖𝑛 𝑡ℎ
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

48. 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
= L + 1 +
(1−𝑤 𝑞) 𝐿−𝑖−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 𝑎𝑣𝑔 𝐿 < 𝑚𝑖𝑛 𝑡ℎ
L + 1 +
(1−𝑤 𝑞) 𝐿−𝑖−1
𝑤 𝑞
< 𝑚𝑖𝑛 𝑡ℎ