Thuật toán quản lý hàng đợi A - RIO

- 0 -


















ĐẠI HỌC QUỐC GIA HÀ NỘI
TRƯỜNG ĐẠI HỌC CÔNG NGHỆ






Lê Đình Danh

THUẬT TOÁN QUẢN LÝ HÀNG ĐỢI A-RIO



Ngành: Công nghệ thông tin
Chuyên ngành: Mạng và truyền thông
Mã số: 1.01.10





LUẬN VĂN THẠC SĨ





NGƯỜI HƯỚNG DẪN KHOA HỌC:
GVC, TS. Nguyễn Đình Việt




Hà nội – 2007

- 2 -
MỤC LỤC

LỜI CAM ĐOAN - 1 -
MỤC LỤC - 2 -
BẢNG CHỮ CÁI VIẾT TẮT - 4 -
DANH MỤC CÁC BẢNG BIỂU - 6 -
DANH MỤC CÁC HÌNH VẼ, ĐỒ THỊ - 7 -
MỞ ĐẦU - 9 -
CHƢƠNG 1 GIỚI THIỆU - 12 -
1.1 Lịch sử phát triển của mạng Internet và bộ giao thức TCP/IP - 12 -
1.2 Các khái niệm về Multimedia và QoS - 13 -
1.2.1 Khái niệm truyền thông đa phương tiện (multimedia) - 13 -
1.2.2 Khái niệm QoS - 15 -
1.3 Rào cản đối với truyền thông multimedia trên Internet - 18 -
1.4 Hạn chế của dịch vụ cố gắng tối đa và các phƣơng pháp khắc phục - 19 -
1.4.1 Hạn chế của dịch vụ cố gắng tối đa - 19 -
1.4.2 Các phương pháp đảm bảo QoS cho truyền thông multimedia trên nền
các dịch vụ Best Effort - 21 -
1.5 Hiệu suất và đánh giá hiệu suất mạng - 28 -
1.5.1 Khái niệm hiệu suất và các độ đo hiệu suất mạng - 28 -
1.5.2 Các phương pháp đánh giá hiệu suất mạng - 29 -

CHƢƠNG 2 MỘT SỐ CHIẾN LƢỢC PHỤC VỤ PHỔ BIẾN - 32 -
2.1 Cơ chế FCFS (FIFO) - 32 -
2.2 Hàng đợi ƣu tiên (PQ) - 34 -
2.3 Chiến lƣợc Packet-Based Round Robin (PBRR) - 35 -
2.4 Chiến lƣợc Packet Fair Queuing và một số biến thể - 36 -
2.5 Chiến lƣợc Flow-Based Weighted Fair Queuing (WFQ) - 40 -
2.6 Chiến lƣợc Class-Based Weighted Fair Queuing (CBQ) - 43 -
CHƢƠNG 3 CÁC CHIẾN LƢỢC QUẢN LÝ HÀNG ĐỢI ĐỘNG - 46 -
3.1 Cách tiếp cận truyền thống và hệ quả - 46 -
3.1.1 Hiện tượng Lock-Out và Global Synchronization - 47 -
3.1.2 Hiện tượng Full Queues - 47 -
3.2 Chiến lƣợc AQM - 48 -
3.2.1 Giảm số gói tin bị loại bỏ tại router - 48 -
3.2.2 Giảm độ trễ - 48 -
3.2.3 Tránh hiện tượng Lock-Out - 49 -
3.3 Thuật toán RED - 49 -
3.3.1 Giới thiệu - 49 -
3.3.2 Mục tiêu và nguyên tắc thíết kế - 50 -


- 3 -
3.3.3 Giải thuật - 52 -
3.3.4 Thiết lập các tham số - 54 -
3.3.5 Một số đánh giá về RED - 57 -
3.3.6 Nghiên cứu RED bằng mô phỏng - 59 -
3.4 Thuật toán Adaptive-RED - 65 -
3.4.1 Ý tưởng của A-RED - 66 -
3.4.2 Thuật toán A-RED - 67 -
3.4.3 Thiết lập các tham số cho A-RED - 68 -
3.4.4 Nghiên cứu A-RED bằng mô phỏng - 71 -

CHƢƠNG 4 THUẬT TOÁN QUẢN LÝ HÀNG ĐỢI A-RIO - 75 -
4.1 Giới thiệu - 75 -
4.2 Thuật toán RIO - 76 -
4.2.1 Ý tưởng của RIO - 76 -
4.2.2 Thuật toán RIO - 77 -
4.2.3 Nghiên cứu RIO bằng mô phỏng - 79 -
4.3 Kiến trúc các dịch vụ phân loại DiffServ - 84 -
4.3.1 Cấu trúc DiffServ - 85 -
4.3.2 Quản trị hàng đợi động trong kiến trúc DiffServ - 89 -
4.4 Thuật toán A-RIO - 91 -
4.5 Nghiên cứu A-RIO bằng mô phỏng - 95 -
4.5.1 Cấu hình mạng mô phỏng - 95 -
4.5.2 Các nguồn lưu lượng - 96 -
4.5.3 Kỹ thuật đánh dấu trTCM - 97 -
4.5.4 Các tham số AQM - 99 -
4.5.5 Kết quả mô phỏng - 100 -
KẾT LUẬN VÀ PHƢƠNG HƢỚNG NGHIÊN CỨU TIẾP THEO - 113 -
A. KẾT LUẬN - 113 -
B. PHƢƠNG HƢỚNG NGHIÊN CỨU TIẾP THEO - 115 -
DANH MỤC TÀI LIỆU THAM KHẢO - 116 -
A. TÀI LIỆU TIẾNG VIỆT - 116 -
B. TÀI LIỆU TIẾNG ANH - 116 -


- 4 -
BẢNG CHỮ CÁI VIẾT TẮT

A-RED
Adaptive - Random Early
Drop; Adaptive-RED

FFQ
Frame-based Fair Queuing
A-RIO
Adaptive – RED with In
and Out bit; Adaptive-RIO
FIFO
First In First Out
ACL
Access Control Lists
FQRR
Fair Queuing with Round
Robin
AF
Assured Forwarding
FTP
File Transport Protocol
AIMD
Additive-Increase
Multiplicative-Decrease
G-RIO
Gentle-RIO
AQM
Active Queue
Management
GPS
Generalized Processor
Sharing
ARPANET
Advanced Research
Projects Agency Network

HTTP
HyperText Transfer
Protocol
CBQ
Class-Based Weighted
Fair Queuing
IETF
Internet Engineering Task
Force
CBR
Constant Bit Rate
IntServ
Integrated Service
CBS
Commited Burst Size
IP
Internet Protocol
CIR
Commited Infomation
Rate
ISP
Internet Service Provider
CP
Code Point
LAN
Local Area Network
CV
Coefficient of Variation
MAN
Wide Area Network

DDRR
Dynamic Deficit Round
Robin
NFSNET
National Science
Foundation Network
DiffServ
Differentiated Service
NS
Network Simulator
DRR
Deficit Round Robin
PCM
Pulse Code Modulation
DS
Diffierentiated Service
PBRR
Packet-Based Round
Robin
ECN
Explicit Congestion
Notification
PFQ
Packet Fair Queuing
EF
Expedited Forwarding
PHB
Per-Hop Behavior
ERR
Elastic Round Robin

PIR
Peak Information Rate
FCFS
First Come First Serve
PWFQ
Packet-based Weighted
Fair Queuing
FEC
Forward Error Correction
QoS
Quality of Service


- 5 -
RED
Random Early Detection;
Random Early Drop
SPFQ
Starting Potential-Based
Fair Queuing
RFC
Request For Comment
SRR
Superplus Round Robin
RIO
RED with In and Out bit
TCP
Transmission Control
Protocol
RSVP

Resource Revervation
Protocol
TDM
Time Division
Multiplexing
RIO-C
RIO-Coupled
trTCM
two rate Three Color
Marking
RIO-D
RIO-Decoupled
TSW
Time Sliding Window
RTO
Round Trip TimeOut
UDP
User Datagram Protocol
RTT
Round Trip Time
WF
2
Q
Worst-case Fair Weighted
Fair Queuing
SCFQ
Self-Clocked Fair Queuing
WFQ
Flow-Based Weighted Fair
Queuing

SD
Standard Deviation
WRED
Weighted RED
SFQ
Start-time Fair Queuing
WRR
Weighted Round Robin


- 6 -
DANH MỤC CÁC BẢNG BIỂU
Bảng 2.1: So sánh một số chiến lƣợc phục vụ 39
Bảng 3.1: Kết quả thống kê của mô phỏng 1 so sánh DropTail/RED 63
Bảng 3.2: Kết quả thống kê của mô phỏng 2 so sánh DropTail/RED 65
Bảng 3.3: Kết quả thống kê của mô phỏng 1 RED/A-RED 73
Bảng 3.4: Kết quả thống kê của mô phỏng 2 RED/A-RED 74
Bảng 4.1: So sánh RED và RIO-TSW với 10 luồng TCP 81
Bảng 4.2: Các kịch bản mô phỏng 96
Bảng 4.3: Các tham số lƣu lƣợng 97
Bảng 4.4: Mô hình chồng ngƣỡng cho RIO 99
Bảng 4.5: Các tham số cho các chiến lƣợc AQM 100
Bảng 4.6: Hệ số sử dụng đƣờng truyền và mức độ bảo vệ gói tin ƣu tiên cao 103
Bảng 4.7: Độ đo mức độ công bằng 105
Bảng 4.8: Các thông số hiệu năng trƣờng hợp 3 - 100% 107
Bảng 4.9: Các thông số hiệu năng, trƣờng hợp 6 - 50% 110
Bảng 4.10: Các thông số hiệu năng trƣờng hợp 4 - 75% 111

- 7 -
DANH MỤC CÁC HÌNH VẼ, ĐỒ THỊ
Hình 1.1: Các tham số QoS chính 16
Hình 1.2: Hai chiến lược tạm dừng khác nhau và kết quả của chúng 22
Hình 1.3: Cơ chế thứ hai của FEC 26
Hình 1.4: Cơ chế đan xen 27
Hình 2.1: Bộ lập lịch 32
Hình 2.2: Cơ chế phục vụ FCFS 33
Hình 2.3: Ví dụ về cơ chế phục vụ FCFS 33
Hình 2.4: Cơ chế lập lịch hàng ưu tiên 34
Hình 2.5: Ví dụ về cơ chế lập lịch hàng ưu tiên 34
Hình 2.6: Cơ chế lập lịch Round Robin 36
Hình 2.7: Cơ chế PFQ 37
Hình 2.8: Cơ chế Weighted Fair Queuing (WFQ) 41
Hình 2.9: IP Precedence bits 41
Hình 2.10: Ví dụ về cấu trúc phân cấp chia sẻ băng thông trong CBQ 44
Hình 3.1: Giải thuật tổng quát cho RED gateways 52
Hình 3.2: Giải thuật chi tiết cho RED gateway 53
Hình 3.3: Cấu hình mạng mô phỏng 1 59
Hình 3.4: Các kết quả mô phỏng với DropTail 62
Hình 3.5: Các kết quả mô phỏng với RED 62
Hình 3.6: Cấu hình mạng mô phỏng 2 63
Hình 3.7: Kết quả mô phỏng 2 so sánh DropTail và RED 64
Hình 3.8: Thuật toán hiệu chỉnh max
p

trong Adaptive RED 68


- 8 -
Hình 3.9: Cấu hình mạng mô phỏng RED/A-RED 71
Hình 3.10: RED với sự tăng cường độ tắc nghẽn 72
Hình 3.11: A-RED với sự tăng cường độ tắc nghẽn 72
Hình 3.12: RED với sự giảm cường độ tắc nghẽn 74
Hình 3.13: A-RED với sự giảm cường độ tắc nghẽn 74
Hình 4.1: Thuật toán RIO 78
Hình 4.2: Các thuật toán RED và RIO 78
Hình 4.3: Cấu hình mạng mô phỏng RIO 79
Hình 4.4: Kích thước hàng đợi trung bình tương ứng với RED và RIO 83
Hình 4.5: So sánh kích thước cửa sổ các cặp kết nối 83
Hình 4.6: Một kiến trúc DiffServ đơn giản 85
Hình 4.7: Phân loại và đánh dấu gói tin 86
Hình 4.8: Thuật toán RIO với ba mức ưu tiên 90
Hình 4.9: Thuật toán A-RIO 93
Hình 4.10: Thuật toán A-RIO với ba mức ưu tiên 94
Hình 4.11: Cấu hình mạng mô phỏng A-RIO 95
Hình 4.12: Kích thước hàng đợi trung bình ứng với ba thuật toán 101
Hình 4.13: Trường hợp 3 - 100% 108
Hình 4.14: Trường hợp 6 - 50% 109
Hình 4.15: Trường hợp 4 - 75% 112





- 9 -

MỞ ĐẦU
Cùng với sự phát triển về hạ tầng mạng, các ứng dụng trên mạng Internet ngày
càng phong phú, đa dạng. Dữ liệu đƣợc truyền đi không chỉ đơn thuần là text đơn
giản, mà là dữ liệu đa phƣơng tiện (multimedia) bao gồm cả hình ảnh, âm thanh,
audio, video, Các ứng dụng đa phƣơng tiện phổ biến có thể kể đến nhƣ điện thoại
qua mạng (Internet telephony), hội thảo trực tuyến (video conferencing), xem video
theo yêu cầu (video on demand), đang ngày càng đƣợc sử dụng rộng rãi. Đối với
truyền thông đa phƣơng tiện, điều quan trọng nhất là phải đảm bảo chất lƣợng dịch
vụ (QoS), tức là đảm bảo độ trễ và jitter nhỏ, thông lƣợng đủ lớn, hệ số sử dụng
đƣờng truyền cao và tỷ lệ mất gói tin có thể chấp nhận ở một mức độ nhất định. Để
làm đƣợc điều này cần phải có những cơ chế đặc biệt thực hiện ở các router.
Sự phát triển nhanh chóng của các ứng dụng trên mạng làm cho kích thƣớc
mạng trở nên khổng lồ, nhu cầu vận chuyển dữ liệu trên Internet lớn dẫn tới thƣờng
xuyên xảy ra tình trạng tắc nghẽn dữ liệu trên đƣờng truyền, vì vậy cần phải có các
biện pháp xử lý nhằm hạn chế tối đa tắc nghẽn để mạng luôn duy trì đƣợc sự ổn
định cao nhất. Kỹ thuật truyền thống để quản lý kích thƣớc hàng đợi là thiết lập độ
dài tối đa cho mỗi hàng đợi, nhận các gói tin đến cho đến khi kích thƣớc hàng đợi
đạt đến ngƣỡng trên, sau đó loại bỏ các gói tin đi đến cho đến khi kích thƣớc hàng
đợi giảm xuống do các gói tin trong hàng đợi đã đƣợc chuyển đi theo chính sách
FIFO (hay FCFS). Trong bộ mô phỏng mạng NS, kỹ thuật này đƣợc biết đến với tên
gọi “DropTail”. Tuy nhiên, nếu thi hành chính sách phục vụ tại hàng đợi kiểu FIFO
thì hàng đợi sẽ thƣờng xuyên ở trạng thái đầy, làm tăng đáng kể thời gian trễ trung
bình của các gói tin trong mạng. Do vậy cần phải có các kỹ thuật khác hiệu quả hơn,
đảm bảo cho mạng đạt đƣợc thông lƣợng cao và độ trễ trung bình nhỏ. AQM
(Active Queue Management) là một chiến lƣợc quản lý hàng đợi động, trong đó các
thực thể đầu cuối có thể phản ứng lại tắc nghẽn khi hiện tƣợng này mới chớm có
dấu hiệu xuất hiện. Theo đó, gateway sẽ quyết định cách thức loại bỏ sớm gói tin
trong hàng đợi của nó trong khi tình trạng của mạng còn có thể kiểm soát đƣợc.

- 10 -
RED (Random Early Detection of Congestion; Random Early Drop) là một
chiến lƣợc AQM đặc biệt, áp dụng cho mạng TCP/IP. RED gateway thực hiện loại
bỏ gói tin trong hàng đợi theo chiến lƣợc AQM nhƣ mô tả ở trên. Một tuỳ chọn của
RED là đánh dấu vào trƣờng ECN trong header của các gói tin TCP, để báo cho
bên gửi biết về hiện tƣợng tắc nghẽn có dấu hiệu sắp xảy ra, yêu cầu nguồn có phản
ứng tích cực (giảm tỷ lệ phát gói tin). Ƣu điểm chính của RED là tính đơn giản,
không yêu cầu tất cả các gateway trên Internet cùng phải sử dụng kỹ thuật này, mà
có thể triển khai dần.
A-RIO (Adaptive – RED with In and Out) là một sự kết hợp trực tiếp của thuật
toán A-RED và thuật toán RIO. A-RIO là thuật toán AQM áp dụng cho kiến trúc
mạng DiffServ, dùng để chuyển tiếp có phân loại các gói tin. A-RIO có khả năng ổn
định đƣợc kích thƣớc hàng đợi (và vì vậy độ trễ) quanh một giá trị mong muốn,
trong khi vẫn duy trì đƣợc thông lƣợng cao và bảo vệ các gói tin có mức ƣu tiên
cao.
Mục tiêu chính của Luận văn là tập trung nghiên cứu và đánh giá hiệu suất
của thuật toán quản lý hàng đợi A-RIO. Bởi vì A-RIO là sự kết hợp của nhiều thuật
toán AQM, nên để phục vụ cho mục tiêu chính, chúng tôi đã dành nhiều thời gian
nghiên cứu các thuật toán AQM cơ sở của nó, đó là RED, A-RED, RIO. Ngoài ra,
vì mục đích cuối cùng là phải hƣớng tới ngƣời sử dụng, nên chúng tôi cũng đã dành
một chƣơng để trình bày tổng quan về truyền thông đa phƣơng tiện trên mạng, đây
là các dịch vụ ở mức ứng dụng, hiệu quả của nó phụ thuộc chặt chẽ vào các dịch vụ
mức dƣới. Xuất phát từ quan điểm trên, ngoài phần Mở đầu và Kết luận, Luận văn
đƣợc chia làm 4 chƣơng đƣợc tóm tắt nhƣ sau:
Chƣơng 1 giới thiệu về truyền thông đa phƣơng tiện trên mạng, khái niệm
QoS và các phƣơng pháp đảm bảo chất lƣợng dịch vụ trong truyền thông
multimedia trên mạng.


- 11 -

Chƣơng 2 trình bày sơ lƣợc về một số chiến lƣợc phục vụ hàng đợi phổ biến:
FIFO, RR, FQ, WFQ, CBQ,
Chƣơng 3 trình bày về chiến lƣợc quản lý hàng đợi động AQM và hai thuật
toán tiêu biểu của nó: RED, A-RED. Ở mỗi thuật toán chúng tôi đều có những mô
phỏng để kiểm chứng các đánh giá hiệu suất của chúng. Đây là những thuật toán cơ
sở trực tiếp cho A-RIO đƣợc trình bày trong chƣơng 4.
Chƣơng 4 là chƣơng quan trọng nhất của Luận văn. Nội dung chính của
chƣơng 4 là tập trung trình bày thuật toán A-RIO và việc áp dụng nó vào kiến trúc
mạng DiffServ; sử dụng bộ mô phỏng mạng NS để nghiên cứu sâu về A-RIO và so
sánh hiệu suất của nó với các chiến lƣợc quản lý hàng đợi khác: RIO và G-RIO.
Tác giả xin bày tỏ lòng biết ơn chân thành tới TS. Nguyễn Đình Việt, thầy đã
luôn ân cần, chỉ bảo, động viên, giúp đỡ tác giả trong suốt quá trình thực hiện Luận
văn. Tôi xin chân thành cảm ơn gia đình, bạn bè, đồng nghiệp đã luôn tin tƣởng,
động viên và giúp đỡ về nhiều mặt trong thời gian qua. Tôi xin chân thành cảm ơn
các thầy cô giáo trong khoa Kỹ thuật - Công nghệ, trƣờng Đại học Hồng Đức đã
động viên và tạo điều kiện giúp đỡ tôi hoàn thành tốt nhất Luận văn này.









- 12 -
CHƢƠNG 1 GIỚI THIỆU
1.1 Lịch sử phát triển của mạng Internet và bộ giao thức TCP/IP
Tiền thân của mạng Internet là ARPANET, xuất phát từ một mạng thí nghiệm
đƣợc Robert L.G đề xuất vào năm 1967. Cơ quan quản lý dự án nghiên cứu phát

triển ARPA thuộc Bộ Quốc phòng Mỹ đã liên kết mạng tại 4 địa điểm đầu tiên vào
tháng 7 năm 1968 bao gồm: Viện nghiên cứu Stanford, Đại học tổng hợp California
ở Los Angeles, Đại học tổng hợp Utah và Đại học tổng hợp California ở Santa
Barbara (UCSB). Đó chính là mạng liên khu vực (WAN) đầu tiên đƣợc xây dựng.
Năm 1983, giao thức TCP/IP chính thức đƣợc coi nhƣ một 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 ARPANET phải sử dụng chuẩn
mới này. ARPANET phát triển rất nhanh, mọi trƣờng đại học đều muốn gia nhập,
việc quản lý mạng trở nên khó khăn. Vì vậy, năm 1984, ARPANET đƣợc chia ra
thành hai phần: phần thứ nhất cho các địa điểm quân sự, đƣợc gọi là MILNET; phần
thứ hai là một ARPANET mới, cho các địa điểm phi quân sự, dành cho việc nghiên
cứu và phát triển. Tuy nhiên hai mạng này vẫn đƣợc liên kết với nhau nhờ giao thức
liên mạng IP.
Giao thức TCP/IP ngày càng thể hiện rõ các điểm mạnh của nó, quan trọng
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. Chính điều này
cùng với các chính sách mở cửa đã cho phép các mạng dùng cho nghiên cứu và
thƣơng mại kết nối đƣợc với ARPANET, thúc đẩy việc tạo ra một siêu mạng
(SuperNetwork).
Mốc lịch sử quan trọng của Internet đƣợc xác lập vào giữa thập kỷ 80 khi Hội
đồng Khoa học Quốc gia Mỹ NSF (National Science Foundation) thành lập mạng
liên kết các trung tâm máy tính lớn với nhau gọi là NSFNET. Nhiều doanh nghiệp
đã chuyển từ ARPANET sang NSFNET và do đó sau gần 20 năm hoạt động,
ARPANET không còn hiệu quả đã ngừng hoạt động vào khoảng năm 1990.


- 13 -
Sự phát triển của mạng xƣơng sống NSFNET và những mạng vùng khác đã
tạo ra một môi trƣờng thuận lợi cho sự phát triển của Internet. Đến năm 1995,
NSFNET thu lại thành một mạng nghiên cứu còn Internet thì vẫn tiếp tục phát triển.
Với khả năng kết nối mở, Internet đã trở thành một mạng lớn nhất trên thế
giới, mạng của các mạng, xuất hiện trong mọi lĩnh vực thƣơng mại, chính trị, quân

sự, nghiên cứu, giáo dục, văn hoá, xã hội Cũng từ đó các dịch vụ trên Internet
không ngừng phát triển. Ngày nay khi cơ sở hạ tầng của mạng Internet đƣợc nâng
cao (đặc biệt là về băng thông) đã 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.
1.2 Các khái niệm về Multimedia và QoS
1.2.1 Khái niệm truyền thông đa phƣơng tiện (multimedia)
Đặc trƣng của các ứng dụng truyền thống nhƣ Web, truyền file, email là nội
dung (dữ liệu) của chúng ở dạng tĩnh (văn bản, hình ảnh). Dữ liệu đƣợc truyền từ
máy này đến máy khác trên mạng một cách nhanh nhất có thể. Tuy nhiên đối với
những ứng dụng dạng này, độ trễ đầu-cuối cho phép có thể lên tới 10s.
Phần này chúng tôi sẽ đề cập đến một loại ứng dụng mà nội dung của nó là các
file audio và video. Chúng đƣợc gọi là các ứng dụng đa phƣơng tiện (multimedia).
Đây là loại ứng dụng nhạy cảm với độ trễ, tuy nhiên chúng lại cho phép sự mất mát
gói tin ở một mức độ nào đó. Nhƣ vậy so với các ứng dụng truyền thống thì tính
chất của nó hoàn toàn ngƣợc lại: chấp nhận mất mát nhƣng yêu cầu độ trễ nhỏ,
trong khi các ứng dụng truyền thống thì cho phép độ trễ lớn và không chấp nhận
mất mát dữ liệu.
Các ứng dụng đa phƣơng tiện có thể chia làm 3 lớp lớn nhƣ sau:
 Truyền audio và video đã đƣợc lƣu trữ: Đối với các ứng dụng loại này,
ngƣời dùng tại các máy trạm (client) truy cập đến các files audio hoặc video đã


- 14 -
đƣợc lƣu trữ sẵn trên các máy phục vụ (server). Các files audio có thể là các bài hát,
bài giảng, hoặc các đoạn băng đƣợc ghi âm từ trƣớc, Các files video có thể là
những bộ phim, video clips, các đoạn video của những sự kiện thể thao, giải trí
Trong hầu hết các ứng dụng loại này, sau một thời gian trễ vài giây, các máy trạm
có thể chạy đƣợc các file trong khi chúng vẫn tiếp tục nhận phần còn lại từ server.
Nhiều ứng dụng còn cho phép tính năng tƣơng tác với ngƣời dùng: cho phép ngƣời
dùng pause, play, next, previous. Từ lúc ngƣời dùng đƣa ra yêu cầu đến khi nhận

đƣợc đáp ứng khoảng từ 1 – 10s là có thể chấp nhận đƣợc. Yêu cầu đối với độ trễ và
jitter (sự biến thiên độ trễ) không chặt chẽ bằng ở trong ứng dụng thời gian thực
nhƣ điện thoại Internet, video conference thời gian thực Các chƣơng trình dùng để
chạy các file audio/video đƣợc lƣu trữ trên mạng hiện nay nhƣ: RealOne Player,
Winamp, Windows Media Player…
 Truyền audio và video thời gian thực: Các ứng dụng loại này tƣơng tự
nhƣ phát thanh và truyền hình quảng bá, có điều nó đƣợc thực hiện trên Internet.
Các ứng dụng cho phép ngƣời dùng nghe/xem đƣợc các chƣơng trình phát
thanh/truyền hình từ bất kỳ nơi nào trên thế giới. Chẳng hạn ngƣời dùng có thể nghe
đài BBC phát từ Anh, các kênh truyền hình VTV phát đi từ Hà nội từ bất kỳ máy
nào kết nối Internet. Đặc trƣng của lớp ứng dụng này là nhiều ngƣời có thể đồng
thời nhận đƣợc cùng một chƣơng trình audio/video. Các ứng dụng này không cho
phép tƣơng tác ngƣời dùng. Cũng nhƣ lớp ứng dụng truyền audio/video đƣợc lƣu
trữ, độ trễ các ứng dụng loại này cho phép tối đa là 10s. Việc phân phối audio/video
cho nhiều ngƣời dùng đƣợc thực hiện bằng kỹ thuật multicast hoặc nhiều dòng
unicast riêng biệt cho mỗi ngƣời nhận.
 Ứng dụng tƣơng tác audio và video thời gian thực: Lớp ứng dụng này
cho phép nhiều ngƣời dùng sử dụng audio/video để tƣơng tác với nhau trong thời
gian thực. Một ứng dụng tiêu biểu của audio thời gian thực là điện thoại Internet, nó
cung cấp dịch vụ điện thoại cục bộ cũng nhƣ điện thoại đƣờng dài với giá rẻ hơn
nhiều so với điện thoại truyền thống. Các ứng dụng cho audio thời gian thực có thể


- 15 -
kể đến nhƣ: Voice Chat trong Yahoo Messenger, Skype, Palm Talk Đối với ứng
dụng video thời gian thực, điển hình là Hội thảo trực tuyến (video conferencing),
trong đó các “đại biểu” có thể giao tiếp với nhau bằng cả âm thanh và hình ảnh.
Trong quá trình hội thảo, mỗi “đại biểu” đƣợc hiển thị trên một cửa sổ giao diện
chƣơng trình ngƣời dùng, khi cần giao tiếp với ai ngƣời ta chỉ cần mở cửa sổ tƣơng
ứng với ngƣời đó. Hiện nay đã có nhiều ứng dụng cho video thời gian thực nhƣ

Microsoft Netmeeting, Yahoo Messenger, Trong các ứng dụng tƣơng tác
audio/video thời gian thực thì yêu cầu độ trễ nhỏ hơn vài trăm miligiây. Với âm
thanh, độ trễ tốt nhất là nên nhỏ hơn 150 ms, với độ trễ từ 150-400ms thì có thể
chấp nhận đƣợc, còn lớn hơn 400 ms thì không thể chấp nhận đƣợc.
1.2.2 Khái niệm QoS
Các hệ thống đa phƣơng tiện thƣờng là phân tán, yêu cầu về nguồn tài nguyên
lớn và thƣờng là động, do đó phải có các giải pháp để đảm bảo chất lƣợng thoả mãn
yêu cầu của ngƣời dùng. Yêu cầu của ngƣời dùng đƣợc thoả mãn bởi việc đảm bảo
chất lƣợng dịch vụ (QoS - Quality of Service). QoS chỉ khả năng cung cấp các dịch
vụ của mạng cho một lưu lượng nào đó [13]. Mục đích chính của QoS là cung cấp
băng thông riêng, điều khiển độ trễ và jitter, giảm tỷ lệ mất mát gói tin cho các
luồng lƣu lƣợng của các ứng dụng thời gian thực và tƣơng tác. Một điều quan trọng
nữa là nó cung cấp quyền ƣu tiên cho một hoặc một vài luồng trong khi vẫn đảm
bảo các luồng khác (có quyền ƣu tiên thấp hơn) không mất quyền đƣợc phục vụ.
Việc đảm bảo chất lƣợng dựa trên cơ sở quản lý tài nguyên vì QoS phụ thuộc vào
tài nguyên khả dụng của hệ thống, việc quản lý tài nguyên bao gồm:
 Tính toán, ƣớc lƣợng đƣợc hiệu suất sử dụng tài nguyên
 Dành tài nguyên cho dịch vụ
 Lập lịch truy cập tài nguyên



- 16 -
Các tham số QoS chính
Hình 1.1 minh hoạ các tham số QoS chính, bao gồm: độ trễ, thông lƣợng, tỷ lệ
mất tin, jitter.
 Độ trễ: là thời gian để truyền một gói tin từ nguồn đến đích, bao gồm thời gian
phát một gói tin lên đƣờng truyền, thời gian xử lý tại hàng đợi và thời gian
truyền trên đƣờng truyền; nó phụ thuộc vào tốc độ truyền tin, tốc độ truyền tin
càng lớn, độ trễ càng nhỏ và ngƣợc lại.

 Thông lượng: thông lƣợng quyết định khả năng truyền tin, thông lƣợng đƣợc
tính bằng tổng số đơn vị dữ liệu đƣợc truyền trong 1 đơn vị thời gian, chẳng
hạn số gói tin hoặc số bytes dữ liệu truyền đi trong 1s.
 Tỷ số mất tin: là số đơn vị dữ liệu bị mất cực đại trong một đơn vị thời gian.
 Jitter: là sự biến thiên của độ trễ.
 Ngoài ra còn có khái niệm kích thước mất tin: đó là số gói tin bị mất liên tiếp
cực đại. Bên cạnh tỷ số mất tin ta có thể dùng khái niệm độ tin cậy: tỷ số mất
tin tỷ lệ nghịch với độ tin cậy.
Các mức QoS
Mức chất lượng dịch vụ (mức QoS) chỉ khả năng thực sự của QoS, đó là khả
năng của mạng trong việc phân phát dịch vụ cho một lƣu lƣợng mạng cụ thể. Các
Hình 1.1: Các tham số QoS chính


- 17 -
mức dịch vụ khác nhau theo mức độ nghiêm ngặt của QoS, đƣợc đặc tả bởi sự giới
hạn về dải thông, độ trễ, jitter và đặc tính mất tin.
Có ba mức QoS trong mạng không đồng nhất [13]:
 Dịch vụ cố gắng tối đa (Best-effort service): đây là dịch vụ kết nối không đảm
bảo, đƣợc đặc trƣng bởi hàng đợi FIFO, không có sự phân loại giữa các luồng.
 Dịch vụ phân loại (Differentiated service): còn đƣợc gọi là QoS mềm. Một
luồng nào đó đƣợc phục vụ tốt hơn những luồng khác (xử lý nhanh hơn, đƣợc
cấp nhiều băng thông hơn, tỷ lệ mất tin giảm xuống). Việc này dựa trên sự
phân loại các dòng lƣu lƣợng với các công cụ nhƣ hàng ƣu tiên PQ, WFQ,
 Dịch vụ đảm bảo (Guaranteed service): còn đƣợc gọi là QoS cứng. Đó là sự

đặt trƣớc tài nguyên mạng cho một luồng lƣu lƣợng xác định. Điều này đƣợc
cung cấp bởi giao thức RSVP và CBQ.
Dịch vụ cố gắng tối đa và các công cụ đƣợc dùng để đảm bảo QoS trên nền
dịch vụ này sẽ đƣợc chúng tôi trình bày ở chƣơng 2, còn dịch vụ phân loại DiffServ
sẽ đƣợc trình bày ở chƣơng 4.
Việc quyết định chọn loại dịch vụ nào thích hợp để triển khai trong mạng dựa
vào các yếu tố sau:
 Ứng dụng hoặc bài toán cần giải quyết. Mỗi loại dịch vụ nêu trên thích hợp
cho một ứng dụng cụ thể. Ngƣời dùng không nhất thiết phải sử dụng dịch vụ
đảm bảo khi ứng dụng của họ không yêu cầu đến mức đó. Một dịch vụ phân
loại – hoặc thậm chí là cố gắng tối đa – có thể phù hợp, tuỳ theo yêu cầu của
ứng dụng ngƣời dùng.
 Chi phí cho cài đặt và triển khai dịch vụ: dịch vụ càng tốt thì chi phí càng lớn.
Do đó phải cân đối đƣợc chất lƣợng và giá thành.


- 18 -
1.3 Rào cản đối với truyền thông multimedia trên Internet
Giao thức IP cung cấp dịch vụ cố gắng tối đa, nghĩa là nó cố gắng chuyển mỗi
datagram từ nguồn đến đích một cách nhanh nhất có thể. Tuy nhiên nó không đảm
bảo độ trễ cũng nhƣ jitter của các gói tin. Mặt khác TCP và UDP đều chạy trên IP,
chúng cũng không đảm bảo về mặt độ trễ cho các gói tin. Đây là một vấn đề gây
cản trở rất lớn cho sự phát triển các ứng dụng đa phƣơng tiện trên Internet. Cho đến
nay, các ứng dụng multimedia đã đƣợc cải thiện đáng kể, song vẫn còn nhiều hạn
chế. Chẳng hạn các ứng dụng truyền audio/video đƣợc lƣu trữ thì độ trễ trung bình
trong khoảng từ 5-10s, tuy nhiên ở những điểm tắc nghẽn thì độ trễ có thể tăng đến
mức không thể chấp nhận đƣợc. Điện thoại Internet và các ứng dụng tƣơng tác thời
gian thực còn hạn chế hơn, bởi vì chúng yêu cầu độ trễ và jitter nhỏ hơn đối với các
ứng dụng truyền audio/video đƣợc lƣu trữ. Còn các ứng dụng truyền audio/video
trực tiếp thì có thể làm việc tốt trong vùng có băng thông dồi dào, nhƣng chất lƣợng

có thể tồi đến mức không thể chấp nhận đƣợc khi các gói tin đi qua các kênh truyền
tắc nghẽn.
Với dịch vụ cố gắng tối đa, các gói tin đƣợc đối xử nhƣ nhau, nghĩa là không
gói nào nhận đƣợc ƣu tiên hơn trong hàng đợi, chúng đều đƣợc đƣa vào cuối hàng
đợi của router và chờ đến lƣợt đƣợc phục vụ cho dù bạn trả bao nhiêu tiền. Tuy
nhiên chúng ta vẫn có thể có một số biện pháp để cải thiện các ứng dụng truyền
thông multimedia. Chẳng hạn, chúng ta có thể gửi audio/video để khắc phục thông
lƣợng thấp của TCP trong giai đoạn Slow-Start của nó; có thể dừng chạy ở phía
nhận khoảng 100ms hay hơn để loại bỏ hiệu ứng jitter; có thể gán nhãn (timestamp)
cho các gói tin tại phía gửi để cho phía nhận biết khi nào chạy chúng. Đối với các
ứng dụng truyền audio/video đƣợc lƣu trữ, chúng ta có thể nạp trƣớc dữ liệu trong
khi client đang chạy mỗi khi bộ nhớ phía client và băng thông đang sẵn sàng.
Chúng ta có thể gửi kèm thông tin dƣ thừa để giảm nhẹ ảnh hƣởng của sự mất mát
dữ liệu. Các kỹ thuật này sẽ đƣợc trình bày chi tiết ở các phần sau.


- 19 -
1.4 Hạn chế của dịch vụ cố gắng tối đa và các phƣơng pháp khắc phục
Trong các phần trên chúng tôi đã đề cập đến dịch vụ cố gắng tối đa, phần này
chúng ta sẽ xem xét kỹ hơn về nó.
1.4.1 Hạn chế của dịch vụ cố gắng tối đa
Tỉ lệ mất mát gói tin có thể rất lớn khi xảy ra tắc nghẽn
Chúng ta xem xét một UDP segment đƣợc tạo ra bởi ứng dụng một điện thoại
Internet. Nó đƣợc đóng gói trong một IP datagram và IP datagram đƣợc chuyển tới
phía nhận. Datagram đƣợc truyền trên mạng qua các bộ đệm trong các router. Nếu
một trong các bộ đệm của router đã đầy thì datagram sẽ không đƣợc nhận vào.
Trong trƣờng hợp này, IP datagram bị loại bỏ và coi nhƣ bị mất, không tới đƣợc
phía nhận.
Sự mất mát gói tin có thể đƣợc loại bỏ bằng cách gửi gói tin bằng TCP. TCP
có cơ chế biên nhận nên sẽ truyền lại các gói tin bị mất. Tuy nhiên, cơ chế truyền lại

nói chung là không thể chấp nhận đƣợc đối với ứng dụng thời gian thực nhƣ là điện
thoại Internet bởi vì nó làm tăng độ trễ. Hơn nữa, theo cơ chế điều khiển tắc nghẽn
trong TCP, sau khi mất gói tin, tốc độ phát tại phía gửi có thể giảm tới mức thấp
nhất, điều này ảnh hƣởng nghiêm trọng tới chất lƣợng âm thanh tại phía nhận. Vì
thế, hầu hết các ứng dụng điện thoại Internet đều chạy trên UDP và không thực hiện
truyền lại các gói tin bị mất. Trên thực tế, tỉ lệ mất gói tin từ 1% tới 20% là có thể
chấp nhận đƣợc, phụ thuộc vào cách âm thanh đƣợc nén và truyền đi và phụ thuộc
vào cách che đậy sự mất gói tin của phía nhận nhƣ thế nào. Cơ chế sửa lỗi FEC
(Forward Error Correction - sẽ đề cập chi tiết ở phần sau) có thể đƣợc dùng để che
đậy sự mất gói tin. Tuy nhiên, nếu đƣờng truyền giữa bên gửi và bên nhận bị tắc
nghẽn trầm trọng, tỉ lệ mất gói tin vƣợt quá 10-20%, khi đó sẽ không có cách nào
đạt đƣợc chất lƣợng âm thanh mong muốn. Đây là hạn chế của dịch vụ cố gắng tối
đa.


- 20 -
Độ trễ end-to-end có thể vƣợt quá giới hạn chấp nhận đƣợc
Độ trễ end-to-end là tổng của thời gian xử lý và chờ trong hàng đợi của các
router dọc theo đƣờng truyền từ ngƣời gửi đến ngƣời nhận, thời gian truyền và thời
gian xử lý của phía nhận. Với các ứng dụng tƣơng tác thời gian thực nhƣ điện thoại
Internet, độ trễ end-to-end nhỏ hơn 150ms đƣợc coi là không có vấn đề gì (giác
quan con ngƣời không cảm nhận đƣợc sự khác biệt), độ trễ từ 150-400ms là có thể
đƣợc chấp nhận đƣợc nhƣng không nên lớn đến mức nhƣ vậy, độ trễ lớn hơn 400ms
là quá lớn, không thể chấp nhận đƣợc. Phía nhận của ứng dụng điện thoại Internet
sẽ không nhận bất kì gói tin nào đến trễ hơn một ngƣỡng nhất định, ví dụ 400ms.
Do đó, các gói tin đến trễ hơn ngƣỡng trên thì coi nhƣ là mất.
Jitter là không thể tránh khỏi và làm giảm chất lƣợng âm thanh
Một trong những thành phần tạo nên độ trễ end-to-end là thời gian chờ ngẫu
nhiên ở hàng đợi của router. Do thời gian chờ ngẫu nhiên này, độ trễ end-to-end có
thể thay đổi đối với từng gói tin, sự biến đổi này đƣợc gọi là jitter.

Ví dụ: xét 2 gói tin đƣợc sinh ra liên tiếp nhau trong một đoạn của ứng dụng
điện thoại Internet. Phía gửi phát gói tin thứ 2 sau gói tin đầu 20ms. Nhƣng tại bên
nhận, khoảng thời gian giữa 2 lần nhận 2 gói tin đó có thể lớn hơn hoặc nhỏ hơn
20ms. Chúng ta có thể thấy rõ hơn nhƣ sau: giả sử gói tin đầu tiên tới khi hàng đợi
router hầu nhƣ là rỗng, nó sẽ đƣợc truyền đi ngay, nhƣng trƣớc khi gói tin thứ hai
tới thì một lƣợng lớn gói tin từ các nguồn khác đổ về làm đầy hàng đợi, gói tin thứ
hai này đƣợc xếp vào cuối hàng đợi và phải chờ một khoảng thời gian nhất định
trƣớc khi đƣợc chuyển tiếp. Nhƣ vậy rõ ràng hai gói tin sẽ đến đích trong khoảng
thời gian lớn hơn 20ms (có thể lên tới vài giây hoặc nhiều hơn). Ngƣợc lại, giả sử
gói tin đầu tới cuối hàng đợi (hàng đợi lúc đó hầu nhƣ rất đầy), gói tin thứ 2 tới
hàng đợi đó và ngay sau gói tin thứ nhất. Khi đó độ lệch thời gian hai gói đến đích
sẽ nhỏ hơn 20ms.


- 21 -
Nếu phía nhận bỏ qua jitter và chạy ngay đoạn âm thanh ngay khi nhận đƣợc,
kết quả chất lƣợng âm thanh sẽ rất kém. Có thể loại bỏ jitter bằng các cách sau:
đánh số số tuần tự các gói tin, gán nhãn thời gian cho các gói tin, tạm dừng chạy.
Sau đây chúng ta sẽ xem xét kỹ hơn các phƣơng pháp này.
1.4.2 Các phƣơng pháp đảm bảo QoS cho truyền thông multimedia trên nền các
dịch vụ Best Effort
1.4.2.1 Loại bỏ jitter ở phía nhận
Với một ứng dụng tiếng nói (voice) nhƣ Điện thoại Internet hay Phát thanh
theo yêu cầu, phía nhận cố gắng cung cấp khả năng chạy đồng bộ các đoạn (chunk)
khi có jitter. Điều này có thể đƣợc thực hiện bằng cách kết hợp ba cơ chế sau [18]:
 Chèn một số tuần tự vào mỗi đoạn, phía gửi sẽ tăng số tuần tự lên 1 khi có một
gói tin đƣợc tạo ra;
 Gắn thêm một nhãn thời gian (timestamp) cho mỗi đoạn; phía gửi sẽ gán nhãn
cho mỗi đoạn chính là thời điểm mà đoạn đó đƣợc tạo ra;
 Tạm dừng chạy ở phía nhận. Việc tạm dừng phải đủ lâu để phần lớn các gói tin

phải đƣợc nhận trƣớc khi chúng đƣợc cho chạy, các gói tin không tới đƣợc
phía nhận trƣớc thời điểm đến lƣợt cho chạy đƣợc xem nhƣ là bị mất. Thời
gian tạm dừng có thể cố định hoặc thay đổi.
Số tuần tự và nhãn thời gian chiếm một số trƣờng trong header của mỗi đoạn
audio theo một định dạng chuẩn mà chúng tôi không đƣa ra ở đây vì khuôn khổ có
hạn của Luận văn. Ở đây chúng ta sẽ thảo luận cơ chế thứ ba.
Sau đây chúng ta sẽ xem xét 2 chiến thuật tạm dừng chạy ở phía nhận: tạm
dừng cứng và tạm dừng linh hoạt.



- 22 -
a. Tạm dừng cứng
Phía nhận thực hiện chạy mỗi đoạn đúng q ms sau khi đoạn đó đƣợc sinh ra.
Nếu timestamp của một đoạn là t, phía nhận sẽ chạy đoạn đó tại thời điểm t + q (giả
sử đoạn tới phía nhận trƣớc thời điểm theo thứ tự nó đƣợc chạy), nếu nó tới sau thời
điểm đó, coi nhƣ là đã bị mất.
Trong chiến lƣợc này, số tuần tự là không cần thiết. Việc quan trọng là lựa
chọn đƣợc giá trị q tốt nhất. Ta biết rằng đối với điện thoại Internet, độ trễ cho phép
lên tới 400 ms, còn đối với các ứng dụng audio tƣơng tác thì yêu cầu q nhỏ hơn.
Nếu q nhỏ hơn nhiều so với 400 ms, rất nhiều gói tin có thể bị coi nhƣ là bị mất do
jitter; vì vậy, nếu độ trễ end-to-end lớn và/hoặc jitter lớn thì nên dùng q lớn, nếu độ
trễ nhỏ và jitter nhỏ thì nên dùng q nhỏ, chẳng hạn nên chọn q từ 100-150 ms.

Hình 1.2 minh họa mối quan hệ giữa thời gian tạm dừng và sự mất mát gói tin
(gói tin bị coi là mất khi nó tới phía nhận sau thời điểm đƣợc chạy). Hình vẽ thể
Hình 1.2: Hai chiến lược tạm dừng cứng khác nhau và kết quả của chúng
7
6
5
4
3
2
1
0
0 20 40 60 80 100 120 140 160 180 200 220

(ms)


- 23 -
hiện thời gian mà tại đó gói tin đƣợc tạo và đƣợc chạy. Hai lựa chọn khác nhau về
thời gian chạy đƣợc xét. Phía gửi tạo ra và gửi các gói tin cách nhau 20 ms. Gói tin
đầu tiên tới phía nhận tại thời điểm r. Theo chiến lƣợc tạm ngƣng đầu tiên, thời gian
tạm ngƣng là p - r, gói tin thứ 4 không tới phía nhận trƣớc thời gian đƣợc chạy nên
bị coi là mất. Trong khi đó ở chiến lƣợc tạm ngƣng thứ 2, thời gian tạm ngƣng là p’
- r, (p’ > p) toàn bộ các gói tin đều tới phía nhận trƣớc thời gian chạy và không có
sự mất gói tin.
b. Tạm ngƣng thích nghi
Với chiến lƣợc tạm ngƣng cứng, nếu thiết lập thời gian tạm ngƣng lớn, phần
lớn các gói tin sẽ tới phía nhận trƣớc thời gian đƣợc chạy nên không có sự mất mát
gói tin do jitter. Tuy nhiên, với các ứng dụng tƣơng tác nhƣ điện thoại Internet, độ

trễ quá lớn là không thể chấp nhận đƣợc. Vì vậy phải có cơ chế giảm thời gian tạm
ngƣng tới giá trị cực tiểu, đồng thời đảm bảo tỷ lệ mất mát gói tin là có thể chấp
nhận đƣợc.
Để giải quyết vấn đề trên, ta phải ƣớc lƣợng đƣợc độ trễ và jitter, từ đó điều
chỉnh thời gian tạm ngƣng tại lúc bắt đầu mỗi cuộc hội thoại. Sau đây là thuật toán
mà phía nhận dùng để hiệu chỉnh thời gian tạm ngƣng theo sự thay đổi của độ trễ và
jitter.
Gọi t
i
là timestamp (thời điểm gói tin đƣợc sinh ra) của gói tin thứ i, r
i
là thời
điểm gói tin thứ i tới phía nhận, p
i
là thời điểm gói tin thứ i đƣợc chạy ở phía nhận.
Khi đó, độ trễ end-to-end của gói tin thứ i là r
i
– t
i
. Tùy theo jitter, độ trễ này thay
đổi khác nhau đối với mỗi gói tin. Gọi d
i
là độ trễ trung bình cho tới khi nhận đƣợc
gói tin thứ i, d
i
đƣợc tính theo công thức:
d
i
= (1-u) d
i-1

+ u (r
i
- t
i
), với u là một hằng số (chẳng hạn u = 0.01).
Nhƣ vậy d
i
chính là giá trị trung bình đã đƣợc làm trơn của các độ trễ r
1
– t
1
, r
2
– t
2
,


r
i
- t
i
. Gọi v
i
là độ lệch trung bình giữa độ trễ và độ trễ trung bình, v
i
đƣợc tính
theo công thức:

- 24 -
v
i
= (1-u) v
i-1
+ u | r
i
- t
i
- d
i
|
d
i
, v
i


đƣợc tính cho mỗi gói tin nhận đƣợc, mặc dù chúng chỉ đƣợc dùng để tính thời
điểm chạy cho gói tin đầu tiên của mỗi đoạn hội thoại.
Sau khi tính đƣợc các ƣớc lƣợng này, phía nhận sẽ dùng thuật toán sau để tính
thời điểm chạy cho các gói tin: Nếu gói tin i là gói tin đầu tiên của một đoạn hội
thoại, thời điểm chạy của nó đƣợc tính theo công thức:
p
i
= t
i
+ d
i
+ Kv

i

trong đó K là hằng số dƣơng (ví dụ K = 4). Kv
i
đƣợc thêm vào để thiết lập thời gian
chạy đủ lâu để chỉ một phần nhỏ các gói tin bị coi là mất do đến muộn. Thời điểm
chạy của các gói tin trong đoạn đƣợc tính bằng timestamp của nó cộng với khoảng
thời gian từ khi gói đầu tiên đƣợc sinh ra tại phía gửi đến lúc nó đƣợc chạy tại phía
nhận. Cụ thể nhƣ sau: Đặt q
i
= p
i
- t
i
là thời gian từ khi gói tin đầu tiên đƣợc tạo ra
(bên gửi) cho tới khi nó đƣợc chạy (bên nhận). Khi đó gói tin thứ j trong đoạn sẽ
đƣợc chạy tại thời điểm pj = tj + q
j
.
Trong thuật toán trên ta đã giả sử rằng phía nhận biết đƣợc gói tin nào là gói
tin đầu tiên đƣợc tạo ra. Nếu không có sự mất mát gói tin, phía nhận có thể xác định
đƣợc điều này bằng cách so sánh timestamp của gói tin thứ i với timestamp của gói
tin thứ i-1. Nếu t
i
- t
i-1
> 20ms, thì phía nhận sẽ biết rằng gói tin thứ i là gói tin đầu
tiên của đoạn hội thoại. Nhƣng việc mất gói tin là hoàn toàn có thể xảy ra. Trong
trƣờng hợp này, 2 gói tin nhận đƣợc trong cùng một đoạn cũng có hiệu 2 timestamp
lớn hơn 20ms. Khi đó, số tuần tự trở nên hữu ích. Phía nhận có thể dùng số tuần tự

để xác định khi hiệu hai timestamp > 20 ms, đâu là trƣờng hợp do gói tin đầu tiên
đƣợc phát ra, đâu là trƣờng hợp do đã có sự mất mát gói tin. Cụ thể là: nếu t
i
- t
i-1
>
20ms, và hai gói tin có số tuần tự liên tiếp nhau thì gói tin thứ i là gói tin đầu tiên
của đoạn hội thoại, ngƣợc lại nếu hai gói tin không liên tiếp thì chắc chắn là có sự
mất mát gói tin.



- 25 -
1.4.2.2 Khôi phục các gói tin bị mất
Ở phần trên chúng ta đã thảo luận khá chi tiết về cách mà một ứng dụng điện
thoại Internet loại bỏ jitter của các gói tin nhƣ thế nào. Bây giờ chúng ta sẽ xem xét
một chiến lƣợc khác trong việc đảm bảo chất lƣợng audio khi có sự mất mát gói tin.
Chiến lƣợc này đƣợc gọi là Chiến lƣợc khôi phục sự mất mát. Ở đây chúng ta định
nghĩa sự mất gói tin theo nghĩa rộng: gói tin bị mất nếu hoặc nó không tới phía nhận
hoặc tới sau thời điểm mà lẽ ra nó đƣợc chạy tại phía nhận. Chúng tôi vẫn lấy ứng
dụng điện thoại Internet làm ví dụ để mô tả các chiến lƣợc này.
Nhƣ đã nói ở phần đầu của mục 1.4.1, việc truyền lại gói tin bị mất là không
phù hợp với ứng dụng thời gian thực nhƣ điện thoại Internet, vì có thực hiện truyền
lại gói tin thì khi đến đích cũng đã quá hạn (deadline), gói tin đến sau thời điểm này
là không có ý nghĩa. Mặt khác, việc truyền lại một gói tin khi bộ đệm tại router đã
đầy thƣờng làm cho tình trạng tắc nghẽn càng tồi tệ hơn. Chính vì thế ứng dụng
điện thoại Internet thƣờng sử dụng một lƣợc đồ khắc phục sự mất mát gói tin. Có 2
kiểu lƣợc đồ lƣờng trƣớc mất mát là: sửa lỗi ở phía trƣớc - FEC và xen kẽ
(interleaving) [18].
a. Sửa lỗi ở phía trƣớc - FEC

Ý tƣởng của FEC là thêm các thông tin bổ sung vào gói tin ban đầu, các thông
tin này có thể đƣợc dùng để khôi phục các gói tin bị mất. Hiện nay ngƣời ta dùng 2
cơ chế FEC. Cơ chế thứ nhất: gửi một đoạn chứa thông tin bổ sung đƣợc mã hoá
sau n đoạn. Đoạn chứa thông tin bổ sung đó thu đƣợc bằng cách thực hiện phép
XOR n đoạn ban đầu. Theo cơ chế này, nếu một gói tin nào đó trong n + 1 gói tin bị
mất, phía nhận có thể khôi phục hoàn toàn lại gói tin đó. Nhƣng nếu có hai hay
nhiều gói tin bị mất, phía nhận sẽ không thể tái tạo lại đƣợc. Nếu để cỡ của khối đó
(tức là n + 1) nhỏ, một phần lớn các gói tin bị mất có thể đƣợc khôi phục. Tuy
nhiên, cỡ khối càng nhỏ, băng thông đƣờng truyền càng phải đƣợc tăng lên. Cụ thể,
băng thông đƣờng truyền tăng theo hệ số 1/n. Ví dụ nếu n = 4, băng thông phải