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

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

ĐẠ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Ụ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 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 -

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

Projects Agency Network

HTTP HyperText Transfer

Protocol CBQ Class-Based Weighted

Fair Queuing

IETF Internet Engineering Task

Force

Rate

ISP Internet Service Provider

DDRR Dynamic Deficit Round

Robin

NFSNET National Science

Foundation Network DiffServ Differentiated Service NS Network Simulator

DS Diffierentiated Service PBRR Packet-Based Round

Robin ECN Explicit Congestion

Notification

PFQ Packet Fair Queuing

FCFS First Come First Serve PWFQ Packet-based Weighted

Fair Queuing FEC Forward Error Correction QoS Quality of Service

RED Random Early Detection;

Random Early Drop

SPFQ Starting Potential-Based

Fair Queuing

RIO RED with In and Out bit TCP Transmission Control

Protocol RSVP Resource Revervation

Fair Queuing SCFQ Self-Clocked Fair Queuing WFQ Flow-Based Weighted Fair

Queuing

SFQ Start-time Fair Queuing WRR Weighted Round Robin

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

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

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

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

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

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

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

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 đã

đượ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ể

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

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

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

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

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

Độ 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

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

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

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 ,

theo công thức:

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 p j = t j + 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

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

được tăng 25% Lược đồ này cũng làm tăng độ trễ bởi vì phía nhận phải nhận toàn

bộ khối gói tin xong mới có thể thực hiện chạy chúng được

Cơ chế FEC thứ hai là gửi kèm một luồng âm thanh chất lượng thấp hơn luồng ban đầu như là luồng thông tin bổ sung (xem hình 1.3) Chẳng hạn, phía gửi tạo một luồng bình thường (được mã hóa PCM với tốc độ 64Kbps) và một luồng tốc độ bit

thấp (được mã hóa GSM, có tốc độ 13 Kbps) Phía gửi sẽ tạo ra gói tin thứ n bằng cách lấy đoạn thứ n của luồng bình thường và đoạn thứ n-1 của luồng bổ sung Khi

có sự mất gói tin không liên tục, phía nhận có thể chạy đoạn mã hóa tốc độ bit thấp trong gói tin kế tiếp Hiển nhiên là đoạn tốc độ bit thấp cho chất lượng âm thanh thấp hơn đoạn bình thường, nhưng trên tổng thể gồm nhiều đoạn tốc độ cao, một vài đoạn tốc độ thấp và không có sự mất mát các đoạn thì vẫn cho chất lượng âm thanh tốt Trong lược đồ này, phía nhận chỉ phải nhận 2 gói tin trước khi thực hiện chạy chúng, vì thế phần độ trễ tăng thêm là nhỏ Hơn nữa, nếu mã hóa tốc độ bit thấp chiếm ít hơn nhiều so với mã hóa bình thường, tốc độ truyền tăng không đáng kể

Hình 1.3: Cơ chế thứ hai của FEC

Để xử lý sự mất gói tin liên tiếp, một biến thể của cơ chế trên có thể được sử

dụng Thay vì chèn đoạn tốc độ bit thấp thứ n-1 vào đoạn bình thường thứ n, phía gửi sẽ chèn đoạn tốc độ bit thấp thứ n-1 và n-2 , hoặc chèn đoạn tốc độ bít thấp thứ

n-1 và thứ n-3 Việc chèn càng nhiều đoạn bổ sung vào giúp cho các ứng dụng có

thể đáp ứng được trong nhiều môi trường best-effort, tuy nhiên nó cũng làm tăng băng thông cần sử dụng và làm tăng độ trễ

b Cơ chế xen kẽ (Interleaving)

Ứng dụng điện thoại Internet có thể gửi âm thanh theo kiểu xen kẽ, phía gửi sẽ xếp lại thứ tự các phần tử dữ liệu âm thanh trước khi truyền, các phần tử sát nhau sẽ được xếp cách một khoảng cố định trong luồng truyền đi Cơ chế này có thể làm giảm ảnh hưởng của việc mất gói tin Việc mất gói tin sẽ chỉ làm cho mỗi đoạn nhận được sau khi được khôi phục lại giảm chất lượng đi chút ít Hình 1.4 minh hoạ cho cơ chế này Mỗi đoạn chứa 4 phần tử, đoạn đầu tiên chứa các phần tử thứ: 1, 5,

9, 13; đoạn thứ 2 chứa phần tử thứ: 2, 6, 10, 14, Giả sử đoạn thứ 3 bị mất, các đoạn sau đó được tạo lại và mỗi đoạn bị mất đi một phần tử (phần tử thứ 3); chất lượng mỗi đoạn thu được chỉ bị giảm đi chút ít

Hình 1.4: Cơ chế xen kẽ

Cơ chế trên có thể cải thiện đáng kể chất lượng luồng nhận được Bất lợi dễ thấy là tăng độ trễ bởi vì tất cả các đoạn cần phải được tạo lại trước khi chạy Đây là hạn chế của nó khi áp cho các ứng dụng tương tác thời gian thực như điện thoại Internet; tuy nhiên nó thực hiện tốt cho các ứng dụng truyền audio/video được lưu trữ trên server Thuận lợi là nó không yêu cầu tăng băng thông

1.5 Hiệu suất và đánh giá hiệu suất mạng

Hiệu suất là vấn đề rất quan trọng đối với một hệ thống nói chung và mạng máy tính nói riêng Đối với một mạng với số máy là nhỏ thì chúng ta có thể dễ dàng kiểm soát được hiệu suất của nó Tuy nhiên trong thực tế có nhiều mạng rất lớn với hàng nghìn máy tính được kết nối với nhau thông qua nhiều tương tác phức tạp, dẫn tới hiệu suất mạng giảm đi và việc quản lý nó trở nên không đơn giản Do vậy cần phải có những chiến lược thích hợp trong việc xây dựng và duy trì sự hoạt động ổn định của hệ thống Để làm được điều này cần phải có các phương tiện đánh giá được hiệu suất của hệ thống Việc đánh giá hiệu suất phải được tiến hành từ khi xây dựng giải pháp hệ thống, trong quá trình lắp đặt, cho đến khi triển khai hệ thống cho khách hàng Phần này chúng ta sẽ tìm hiểu khái niệm hiệu suất và các độ đo hiệu suất, các phương pháp đánh giá hiệu suất đang được sử dụng

1.5.1 Khái niệm hiệu suất và các độ đo hiệu suất mạng

Hiệu suất là một độ đo mức độ thực hiện công việc của một hệ thống Đối với một hệ thống tính toán, đánh giá hiệu suất là xác định về mặt định tính và định lượng chất lượng phục vụ của hệ thống đó đối với một loại bài toán nhất định Hiệu suất chủ yếu được xác định bởi sự kết hợp của các nhân tố: tính sẵn sàng (availability), thông lượng (throughput) và thời gian đáp ứng (response time) Đối với mạng máy tính, hiệu suất còn được xác định dựa trên các nhân tố khác nữa như

độ trễ (delay), độ tin cậy (reliability), tỉ suất lỗi (error rate), hiệu suất của ứng dụng v.v [3]

Với mỗi đối tượng khác nhau, hiệu suất mạng được nhìn nhận theo những cách khác nhau Người sử dụng thì quan tâm đến các thông số liên quan trực tiếp

đến công việc của họ, tương ứng với các độ đo thời gian đáp ứng (response time) hoặc thời gian phản ứng của hệ thống (system reaction time) Thời gian đáp ứng là

khoảng thời gian từ khi có một yêu cầu đến hệ thống cho đến khi nó được hệ thống

thực hiện xong Thời gian phản ứng của hệ thống là khoảng thời gian tính từ khi

yêu cầu đến hệ thống cho đến khi yêu cầu đó nhận được khe thời gian phục vụ đầu tiên Độ đo này đo mức độ nhanh chóng trong việc cung cấp dịch vụ cho một yêu

cầu mới đến của hệ thống Đối với hệ thống thì các độ đo điển hình là thông lượng (throughput) và độ trễ (delay) Thông lượng là số đơn vị thông tin (bits, bytes, gói tin) trung bình được vận chuyển qua mạng trong một đơn vị thời gian Độ trễ là thời

gian trung bình để vận chuyển một gói số liệu qua mạng, từ nguồn tới đích

Có nhiều phương pháp đánh giá hiệu năng mạng máy tính, có thể chia chúng làm ba mô hình: mô hình Giải tích (Analytic Models), mô hình Mô phỏng (Simulation Models) và Đo hiệu năng (Measurement) [3] Sau đây là chi tiết về ba phương pháp đó

1.5.2 Các phương pháp đánh giá hiệu suất mạng

a Mô hình Giải tích

Mô hình này dựa trên sự biểu diễn mối quan hệ giữa các tham số mạng và các tiêu chuẩn hiệu suất cần quan tâm bằng các phương trình toán học có thể giải được bằng giải tích Các tham số mạng ở đây là số lượng, chiều dài gói tin, thời gian kết nối, các tài nguyên được chia sẻ, Các tham số này thay đổi một cách ngẫu nhiên Các tiêu chuẩn hiệu suất có thể là thông lượng, độ trễ, hệ số sử dụng đường truyền, Trong mô hình này, các đại lượng liên quan đến khái niệm xác suất thường được tính toán như các giá trị trung bình, kỳ vọng, phương sai Lý thuyết hàng đợi đóng vai trò mấu chốt trong việc phân tích mạng, bởi vì đó là công cụ Toán học thích hợp nhất để phát biểu và giải các bài toán về hiệu suất

Ưu điểm của phương pháp này là nó được thực hiện với chi phí thấp nhất, bởi

vì khi muốn tính hiệu suất với các tham số khác ta chỉ cần thay đổi các tham số hệ thống và cấu hình mạng với một chi phí rất thấp (chỉ cần thực hiện lại các thao tác tính toán dã xây dựng trước) Tuy nhiên, để giải được các bài toán theo các mô hình này ta thường phải đơn giản hoá bài toán bằng các giả thiết thích hợp, hoặc phân rã thành các mô hình nhiều cấp Các kết quả thu được thường không phản ánh chính xác thực tế, cho nên phương pháp này thường chỉ được sử dụng ngay trong giai đoạn đầu của việc thiết kế mạng, giúp cho người thiết kế dự đoán được các giá trị giới hạn của hiệu suất Ngoài ra, các kết quả của phương pháp này bắt buộc phải được kiểm nghiệm bằng các phương pháp khác, như mô phỏng hoặc đo (được trình bày dưới đây)

b Mô phỏng

Mô phỏng là sự bắt chước một hay nhiều khía cạnh của sự vật có thực, bằng một cách nào đó càng giống càng tốt Ngày nay, với sự trợ giúp đắc lực của máy tính, phương pháp này tỏ ra rất hiệu quả và được sử dụng rộng rãi Trong việc đánh giá hiệu suất mạng, mô phỏng là một kỹ thuật sử dụng máy tính để thực hiện các thí nghiệm về mạng Trong mô hình này người ta có thể theo dõi được sự hoạt động của mạng theo tiến trình thời gian Đối với mô hình mô phỏng, việc quan trọng nhất

là xây dựng được bộ mô phỏng Việc này đòi hỏi nhiều công sức và thời gian Độ lớn của bộ mô phỏng tuỳ thuộc vào độ phức tạp của thí nghiệm mô phỏng Nó thường được xây dựng có cấu trúc, cho phép mô-đun hoá chương trình mô phỏng thành tập các chương trình con, sao cho việc sửa đổi, bổ sung các chương trình con được dễ dàng Ngoài ra, các chương trình mô phỏng cũng phải được xây dựng sao cho tối ưu hoá về mặt tốc độ nhằm làm giảm thời gian chạy mô phỏng

Có nhiều trường hợp dùng phương pháp giải tích, mặc dù đã được đơn giản hoá tối đa nhưng vẫn không giải được thì người ta chỉ còn cách dùng phương pháp

mô phỏng Mặt khác nó đặc biệt hiệu quả trong giai đoạn thiết kế hệ thống, bởi vì

người ta có thể chọn các thiết bị mạng (ảo) một cách thoải mái và đánh giá mức độ phù hợp của nó trước khi quyết định đầu tư cho hệ thống Mặc dù phương pháp này đòi hỏi phải xây dựng bộ mô phỏng với chi phí rất cao, nhưng sau khi đã xây dựng được thì có thể thực hiện bao nhiêu thí nghiệm tuỳ ý theo các tham số khác nhau với chi phí rất thấp Các kết quả của mô phỏng cần phải được kiểm nghiệm lại bằng phương pháp mô hình giải tích hoặc phương pháp đo (được trình bày dưới đây)

c Đo

Khác với hai mô hình trên, trong đó việc đánh giá hiệu suất là trên mô hình mạng ảo, đo là phương pháp xác định hiệu suất bằng cách đo các tham số trên mạng thực Hai nhiệm vụ quan trọng mà việc đo phải đảm nhiệm là: 1/ thu thập số liệu để lập mô hình dữ liệu vào cho các phương pháp đánh giá hiệu suất khác; 2/ kiểm chứng các mô hình khác dựa trên các số liệu đo được Việc đo phải được tiến hành xuyên suốt từ khi xây dựng giải pháp cho hệ thống, giai đoạn lắp đặt và sau khi đưa

hệ thống vào hoạt động Trong giai đoạn xây dựng giải pháp, việc đo sẽ giúp quyết định loại thiết bị nào phù hợp nhất với điều kiện của khách hàng Trong giai đoạn lắp đặt, việc đo hiệu suất giúp người ta điều chỉnh lại cấu hình cho phù hợp Việc đo hiệu suất mạng sau khi hệ thống đi vào hoạt động giúp quản trị viên theo dõi tình trạng của mạng để có các phương án khắc phục các sự cố nếu có Hiện nay, hầu như tất cả các hệ thống mạng đều tích hợp bên trong nó các công cụ đo và đánh giá hiệu suất; nhờ đó có thể đo hiệu suất bất cứ lúc nào trong suốt vòng đời của hệ thống

Phương pháp đo phải được thực hiện trên mạng thực, nó cũng đòi hỏi chi phí cho các công cụ đo và cho việc tiến hành đo Việc đo cần được tiến hành tại nhiều điểm trên mạng thực, ở những thời điểm khác nhau và cần lặp đi lặp lại trong một khoảng thời gian đủ dài Ngoài ra, người nghiên cứu phải có kiến thức về Lý thuyết thống kê thì mới có thể rút ra được các kết luận hữu ích từ các số liệu thu thập được Mặc dầu vậy, bằng phương pháp đo có thể vẫn không phát hiện hoặc dự đoán được các hành vi đặc biệt của mạng

CHƯƠNG 2 MỘT SỐ CHIẾN LƯỢC PHỤC VỤ PHỔ BIẾN

Trong các mạng chuyển mạch gói, các gói tin thuộc các luồng lưu lượng khác nhau thường phải chia sẻ đường truyền trên suốt chặng đường đến trạm đích Để đảm bảo việc phân phối dải thông cho các luồng đạt hiệu quả cao nhất cần phải có các cơ chế phục vụ công bằng tại các nút mạng, đặc biệt là tại gateways hoặc routers, những nơi thường xuyên có nhiều luồng dữ liệu khác nhau đi qua Bộ lập lịch có nhiệm vụ phục vụ 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 (hình 2.1) Ở đây luồng được hiểu là tập các gói tin thuộc cùng một lớp ưu tiên, hoặc cùng phát ra từ một nguồn, hoặc cùng có cùng địa chỉ nguồn và đích, Vì vậy, trong các mục sau của chương chúng tôi sử dụng các thuật ngữ luồng, lớp ưu tiên hay hàng đợi để chỉ cùng một khái niệm

Sau đây chúng ta sẽ xem xét một số cơ chế lập lịch phổ biến:

2.1 Cơ chế FCFS (FIFO)

Đây là chiến lược lập lịch truyền thống được sử dụng trên Internet Theo chiến lược này, các gói tin đến được xếp vào hàng đợi nếu đường truyền đang bận; khi hàng đợi đầy, tất cả các gói tin đến sẽ bị loại bỏ cho đến khi có chỗ trống do các gói tin trong hàng đợi được chuyển đi Các gói tin trong hàng đợi sẽ được chuyển tiếp theo thứ tự đến của chúng, gói nào đến trước thì được phục vụ trước, đúng như tên

Luồng 3 -

Luồng nào?

Luồng 1 Luồng 2

Luồng n

Hình 2.1: Bộ lập lịch

gọi First-Come-First-Serve (FCFS) hay First-In-First-Out (FIFO) (ai đến trước

được phục vụ trước) Trong chiến lược này, tất cả các gói tin đến được đưa vào một hàng đợi duy nhất, không có sự phân biệt theo mức ưu tiên của chúng (hình 2.2) Đây là một hạn chế của chiến lược FIFO, vì có thể nhiều gói tin có mức ưu tiên cao

sẽ bị loại Mặt khác, các luồng có sự tăng đột biến về thông lượng thường gây ra sự chiếm giữ độc quyền đường truyền, dẫn tới không công bằng cho các luồng khác

Hình 2.3 minh họa việc chuyển tiếp 5 gói tin theo cơ chế FCFS Các gói tin

đến (miền arrivals) được đánh số thứ tự từ 1 đến 5, trong đó gói 2 có mức ưu tiên thấp hơn các gói khác Miền packet in service minh hoạ thời gian phục vụ các gói tin, mỗi gói tin được phục vụ trong một khe thời gian Miền departures thể hiện thời

điểm các gói tin thực sự được truyền đi Theo hình vẽ, gói tin thứ 2 có độ ưu tiên thấp hơn gói 3, nhưng nó vẫn được phục vụ trước vì nó đến trước gói 3, sau đó là các gói 4, 5

Hình 2.3: Ví dụ về cơ chế phục vụ FCFS Hình 2.2: Cơ chế phục vụ FCFS

2.2 Hàng đợi ưu tiên (PQ)

Trong hàng đợi ưu tiên (Priority Queue), các gói tin đến được phân loại thành

2 hay nhiều lớp ưu tiên Việc nhận biết các lớp ưu tiên thông qua các giá trị chứa

trong header của các gói tin trong lớp, chẳng hạn, giá trị của trường ToS (Type of

Service) trong gói tin IPv4, địa chỉ nguồn/đích, số hiệu cổng nguồn/đích của nó,

Mỗi lớp gói tin có một hàng đợi riêng Bộ lập lịch của hàng đợi ưu tiên sẽ chọn các gói tin từ lớp có độ ưu tiên cao nhất nếu hàng đợi dành riêng cho chúng không rỗng (có gói tin đang đợi truyền đi) để truyền đi; sau khi truyền hết các gói tin trong hàng đợi ưu tiên cao nhất nó mới truyền các gói tin của hàng đợi có ưu tiên tiếp theo, v.v Các gói tin trong một lớp ưu tiên được chọn theo cơ chế FCFS (hình 2.4)

Hình 2.4: Cơ chế lập lịch hàng đợi ưu tiên với 2 lớp ưu tiên

Hình 2.4: Cơ chế lập lịch hàng có ưu tiên

Hình 2.5: Ví dụ về cơ chế lập lịch hàng có ưu tiên

Hình 2.5 minh họa việc thực hiện cơ chế hàng đợi ưu tiên với hai lớp ưu tiên Các gói tin 1, 3, 4 thuộc lớp có độ ưu tiên cao; các gói tin 2, 5 thuộc lớp có độ ưu tiên thấp hơn Gói 1 tới hàng đợi đầu tiên, khi đó đường truyền đang rỗi, nó được truyền đi ngay Sau đó gói tin thứ 2 và thứ 3 tới, gói thứ 2 có độ ưu tiên thấp nên gói thứ 3 được truyền trước, rồi tới gói thứ 2 Khi gói thứ 2 đang được truyền thì gói thứ 4 có độ ưu tiên cao tới hàng đợi, gói tin thứ 2 vẫn tiếp tục được truyền chứ không bị ngắt lại Sau khi gói tin thứ 2 truyền xong tới gói thứ 4, v.v

PQ được dùng trong những trường hợp cần áp đặt mức độ ưu tiên tuyệt đối của một luồng đối với các luồng khác Ví dụ, Cisco sử dụng PQ để đảm bảo các thông tin về việc bán các sản phẩm dựa trên Oracle phải được gửi đến đích trước tất

cả các lưu lượng khác Hiện tại PQ được cấu hình tĩnh, và không được hiệu chỉnh tự động theo sự thay đổi yêu cầu của mạng

Mặc dù PQ cung cấp một cách tiếp cận lập lịch đơn giản, nhưng nó có thể gây

ra sự thiếu băng thông cho các luồng có mức ưu tiên thấp PQ có thể dành hết băng thông để phục vụ cho luồng có ưu tiên cao, và nếu băng thông hạn chế thì có thể dẫn tới những luồng thấp hơn không bao giờ được phục vụ Để tránh xảy ra tình trạng này, PQ phải được kết hợp với các kỹ thuật nhằm hạn chế tốc độ của các lưu

lượng có mức ưu tiên cao, như Shaping hay CAR (Committed Access Rate) [13]

2.3 Chiến lược Packet-Based Round Robin (PBRR)

Theo chiến lược này, các gói tin trong các luồng được phục vụ luân phiên theo vòng Các gói tin cũng được phân thành các lớp ưu tiên khác nhau Tuy nhiên ở đây không có sự ưu tiên phục vụ trong các hàng đợi, thay vào đó, mỗi hàng đợi sẽ được phục vụ quay vòng, hết hàng này đến hàng kia và mỗi hàng chỉ được chọn 1 gói tin mỗi khi đến lượt (hình 2.6) Chẳng hạn, đầu tiên là gói tin trong luồng 1 được phục

vụ, tiếp theo là gói tin trong luồng 2, , gói tin luồng n, rồi quay lại gói tin luồng 1, v.v Đến một lúc nào đó, một (hoặc một vài) luồng không còn gói tin chờ thì bộ lập lịch sẽ bỏ qua và chuyển tới luồng còn dữ liệu

Cơ chế này đơn giản và dễ dàng cài đặt với độ phức tạp O(1) cho mỗi gói tin, tuy nhiên nó không giải quyết được sự cấp phát dải thông công bằng Bởi vì cơ chế này không quan tâm đến đặc tính lưu lượng của các luồng gói tin đến như độ dài hàng đợi hiện tại, mức độ ưu tiên của mỗi luồng gói tin, vì vậy, những luồng có hàng đợi dài (nhiều gói tin đang chờ) hoặc có mức ưu tiên cao hơn cũng chỉ được cấp một lượng dải thông như các luồng khác Hạn chế này được các nhà nghiên cứu đưa ra giải pháp khắc phục bằng một chiến lược mới tốt hơn, đó là Fair Queuing (FQ) cùng một loạt các biến thể của nó

2.4 Chiến lược Packet Fair Queuing và một số biến thể

Chiến lược này xuất phát từ bộ lập lịch lý tưởng GPS - Generalized Processor

Sharing [4] Ý 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ỳ ý Rõ ràng đây là một cơ chế lý tưởng, đảm bảo được sự phân chia công bằng nhất Tuy nhiên GPS không thể cài đặt được trên thực tế, bởi vì tại một thời điểm, server chỉ có thể phục vụ được một gói tin trong một luồng, gói tin cũng có một độ dài nhất định chứ không thể chia nhỏ tuỳ ý

Luồng 3 -

được, và toàn bộ một gói tin được phục vụ xong thì gói tin tiếp theo mới được phục

vụ

Packet Fair Queuing (PFQ) là một thể hiện xấp xỉ của GPS PFQ gán nhãn

thời gian cho mỗi gói tin đến trong từng hàng đợi bằng cách ước lượng ngay tức khắc thời điểm mà gói tin phải rời khỏi router, và phục vụ chúng theo thứ tự từ nhỏ đến lớn của các nhãn này (hình 2.7) Nhãn thời gian được tính dựa vào thời điểm đến hàng đợi và ước lượng thời gian chờ trong hàng đợi của gói tin

Packet-based Weighted Fair Queuing (PWFQ) [5] là cài đặt đầu tiên của PFQ

Việc gán nhãn thời gian cho mỗi gói tin đến được thực hiện như sau: Mỗi gói tin đến được gán cho một thời điểm bắt đầu ảo và thời điểm kết thúc ảo Gói tin được chọn lên đường truyền ra là gói tin có thời điểm kết thúc ảo nhỏ nhất Lý do chọn thời gian ảo thay vì thời gian thực là vì các thời điểm này đều là ước lượng, không phải là những thời điểm chính xác; mặt khác đây chỉ là một cách sắp xếp thứ tự phục vụ cho mỗi gói tin, nên các thời điểm này cũng không cần phải chính xác

Thời điểm bắt đầu ảo của gói tin thứ k trong luồng thứ i, ký hiệu là S(k,i) và thời điểm kết thúc ảo là F(k,i) được tính như sau:

S(k,i) = max(F(k-1,i), V(a(k,i))) F(k,i) = S(k,i) + L(k,i)/r(i)

Hình 2.7: Cơ chế PFQ

với F(0,i) = 0, a(k,i) và L(k,i) tương ứng là thời điểm đến và độ dài của gói tin, r(i)

là tốc độ đến trung bình của các gói tin luồng i, do đó L(k,i)/r(i) là độ trễ ước lượng của gói tin thứ k trong hàng đợi của luồng thứ i V(t) là một hàm theo thời điểm đến

t, biểu diễn thời gian ước lượng (thời gian ảo) để phục vụ một lượng dữ liệu rất nhỏ

từ mỗi luồng đang hoạt động (luồng đang có gói tin chờ) trong mô hình GPS, nó được tính như sau:

dV(t)/dt = 1/N, với N là số các luồng đang hoạt động tại thời điểm t

(tức là trong mỗi khoảng thời gian dt rất nhỏ từ thời điểm t, mỗi luồng nhận được 1/N thời gian phục vụ) Theo công thức này, khi có nhiều luồng không hoạt động

(luồng không có gói tin chờ) thì các luồng hoạt động sẽ được phục vụ nhiều hơn

Một số cài đặt cải tiến nhằm đơn giản hoá độ phức tạp tính toán và cải thiện hiệu năng thực hiện của PWFQ đã được đưa ra Một trong số đó phải kể đến là

WF 2 Q (Worst-case Fair Weighted Fair Queuing), bộ lập lịch đạt được sự công bằng

nhất cho từng gói tin Trong WF2

Q, để chọn gói tin tiếp theo để phục vụ tại thời

điểm t, thay vì chọn trong số tất cả các gói tin đang chờ như trong PWFQ, server chỉ

xem xét những gói tin đã nhận được dịch vụ trong hệ thống GPS tương ứng [14]

WF2Q là một xấp xỉ tốt hơn của GPS và có cận trên độ trễ thấp hơn nhưng độ phức tạp cài đặt lớn hơn so với PWFQ

Hai phiên bản mới hơn là Self-Clocked Fair Queuing (SCFQ) [29] và

Start-time Fair Queuing (SFQ) [24], với cài đặt đơn giản hơn, tuy nhiên không đạt được

sự công bằng như WF2Q Các thuật toán FQ khác như Frame-based Fair Queuing (FFQ) và Starting Potential-Based Fair Queuing (SPFQ) [9] cố gắng làm giảm độ

phức tạp trong việc tính toán nhãn thời gian Tuy nhiên, với việc sắp xếp các gói tin

đã được gán nhãn trong n hàng đợi khác nhau, tất cả các thuật toán đều có ít nhất độ phức tạp là O(log n) cho mỗi gói tin Đó là một chi phí không nhỏ

Mặc dù đã đạt được sự công bằng và cận trên về độ trễ cho các gói tin đến khá tốt, họ các thuật toán FQ vẫn không phù hợp đối với các mạng tốc độ cao Điều này

dẫn tới nhu cầu phải có những giải thuật với độ phức tạp tính toán thấp hơn Đó là

họ các thuật toán dựa trên thuật toán PBRR (đã đề cập ở mục 2.3) Các thuật toán này phục vụ các luồng gói tin theo thứ tự quay vòng, do đó giảm độ phức tạp xuống

còn O(1) cho mỗi gói tin Để khắc phục sự phân phối dải thông không công bằng của PBRR, một số cải tiến đã được đưa ra, đó là Deficit Round Robin (DRR) [22],

và Superplus Round Robin (SRR) [12] (một cải tiến của DRR), sử dụng biến đếm

deficit để ước lượng mức độ không công bằng của việc phân phối đường truyền

Tuy nhiên chúng cần phải biết cận trên độ dài của các gói tin nếu muốn đảm bảo độ

phức tạp O(1) Giải thuật Elastic Round Robin (ERR) [27] khử yêu cầu này và đảm bảo độ phức tạp O(1) mà không cần biết đến độ dài các gói tin Các phiên bản mới dựa trên giải thuật này, chẳng hạn, Dynamic Deficit Round Robin (DDRR) [20] và

Weighted Round Robin (WRR) thoả mãn được hai tiêu chí thông lượng cao và độ trễ

thấp cho các gói tin ngắn Đặc điểm chính của các giải thuật trên là chi phí thấp đáng kể tuy nhiên mức độ công bằng thấp hơn so với FQ

Mức độ công bằng của thuật toán FQ và sự đơn giản của PBRR phải được kết hợp với nhau trong cùng một thuật toán Điều này đã được thể hiện trong Fair

Queuing with Round Robin (FQRR) [32] Bộ lập lịch này đã đạt được sự công bằng

tốt hơn các giải thuật Round Robin với cùng độ phức tạp O(1)

Sau đây là bảng so sánh một số chiến lược chính vừa được mô tả ở trên:

Bảng 2.1 cho ta một các nhìn tổng quát về hai thuộc tính quan trọng của một

số thuật toán khác nhau đề cập ở trên Mức độ công bằng được định nghĩa như là sự chênh lệch về thông lượng giữa các mẫu tin đến giữa thuật toán đang khảo sát so

với thuật toán GSP lý tưởng, ở bất kỳ thời điểm nào, tại bất kỳ hàng đợi nào MAX

là kích thước tối đa của gói tin Theo đó PWFQ đạt được độ công bằng cao nhất, sau đó là FQRR, DRR và cuối cùng là PBRR

Các chiến lược FQ mà chúng ta vừa xem xét trên là các chiến lược FQ áp

dụng cho từng gói tin (Packet-based Weighted Fair Queuing), theo đó mỗi lần phục

vụ server sẽ chọn một gói tin theo trọng số của chúng Ưu điểm của chiến lược này

là mức độ công bằng cao, tuy nhiên nó có hai hạn chế: Thứ nhất, mặc dù đã có nhiều cải tiến, song chi phí để gán nhãn thời gian cho mỗi gói tin vẫn là khá lớn, dẫn tới hạn chế tốc độ phục vụ của server; Thứ hai, các gói tin thuộc cùng một luồng sẽ không được phục vụ một lượt, mà sẽ bị đứt quãng, điều này không phù hợp cho các ứng dụng multimedia tương tác thời gian thực Một cách tiếp cận khác là thay vì phải xem xét và gán nhãn thời gian đến từng gói tin, người ta áp dụng gán

trọng số weight cho cả một tập (luồng) các gói tin, trọng số đặc trưng cho lượng

dịch vụ được cấp phát cho mỗi luồng, các gói tin trong cùng một luồng (có cùng trọng số) sẽ được phục vụ theo chính sách FIFO và các luồng sẽ được phục vụ theo

cơ chế quay vòng (Round Robin) Chúng ta sẽ xét hai trong số những thuật toán

theo hướng này, đó là Flow-Based Weighted Fair Queuing (viết tắt là WFQ) và

Class-Based Weighted Fair Queuing (viết tắt là CBQ) Chi tiết về hai thuật toán này

sẽ được trình bày trong hai phần tiếp theo

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

Trong WFQ (hình 2.8), các gói tin tới hàng đợi được phân thành các luồng theo từng mức ưu tiên, mỗi luồng được xếp vào một hàng đợi đợi riêng và sẽ nhận được một dịch vụ khác nhau Cũng như cơ chế Round Robin, bộ lập lịch của server cũng phục vụ các lớp theo vòng, từ lớp 1, lớp 2, rồi lớp 3, v.v Tuy nhiên, WFQ khác RR ở chỗ, một lớp sẽ nhận được một lượng dịch vụ khác nhau trong mỗi lần

phục vụ, tuỳ theo trọng số của lớp đó Cụ thể, giả sử mỗi luồng i, được gán cho một