Dịch vụ viết bài trọn gói ZALO 0917193864, profile picture
Uploaded byDịch vụ viết bài trọn gói ZALO 0917193864
775 views

Luận văn: Chất lượng dịch vụ cho truyền thông đa phương tiện, 9đ

Luận văn của Hoàng Trọng Thủy nghiên cứu về chất lượng dịch vụ (QoS) trong truyền thông đa phương tiện trên internet, tập trung vào các chiến lược quản lý hàng đợi động nhằm giảm thiểu tắc nghẽn. Tác giả phân tích các mô hình QoS, giúp nâng cao hiệu quả cho các ứng dụng như gọi điện qua mạng và hội thảo trực tuyến. Nghiên cứu cũng đề xuất các giải pháp và kết luận về hiệu quả của chúng dựa trên mô phỏng.

Embed presentation

ĐẠI HỌC QUỐC GIA HÀ NỘI TRƯỜNG ĐẠI HỌC CÔNG NGHỆ HOÀNG TRỌNG THỦY ĐẢM BẢO CHẤT LƯỢNG DỊCH VỤ CHO TRUYỀN THÔNG ĐA PHƯƠNG TIỆN THỜI GIAN THỰC TRÊN INTERNET NGÀNH: CÔNG NGHỆ THÔNG TIN CHUYÊN NGÀNH: TRUYỀN DỮ LIỆU VÀ MẠNG MÁY TÍNH MÃ SỐ: LUẬN VĂN THẠC SĨ NGÀNH CÔNG NGHỆ THÔNG TIN GVHD: PGS TS Nguyễn Đình Việt Hà Nội - 2016
LỜI CAM ĐOAN Tôi xin cam đoan rằng đây là công trình nghiên cứu của cá nhân tôi dưới sự hướng dẫn giúp đỡ của PGS TS. Nguyễn Đình Việt. Các kết quả được viết chung với các tác giả khác đều được sự đồng ý của tác giả trước khi đưa vào luận văn. Trong toàn bộ nội dung nghiên cứu của luận văn, các vấn đề được trình bày đều là những tìm hiểu và nghiên cứu của chính cá nhân tôi hoặc là được trích dẫn từ các nguồn tài liệu có ghi tham khảo rõ ràng, hợp pháp. Trong luận văn, tôi có tham khảo đến một số tài liệu của một số tác giả được liệt kê tại mục tài liệu tham khảo. Hà nội, tháng 11 năm 2016 Tác giả luận văn Hoàng Trọng Thủy
LỜI CẢM ƠN Để hoàn thành tốt luận văn này, đầu tiên tôi xin bày tỏ lòng biết ơn chân thành và sâu sắc đến Thầy Nguyễn Đình Việt, người đã tận tình và trực tiếp hướng dẫn tôi trong suốt quá trình triển khai và nghiên cứu đề tài, tạo điều kiện để tôi hoàn thành luận văn này. Thứ hai, tôi xin bày tỏ lòng biết ơn chân thành tới toàn thể các thầy cô giáo trong khoa Công nghệ thông tin, trường Đại học Công nghệ, Đại học Quốc gia Hà Nội đã dạy bảo tận tình tôi trong suốt quá trình tôi học tập tại khoa. Cuối cùng tôi xin chân thành cảm ơn tới gia đình, bạn bè, đồng nghiệp đã luôn bên em cổ vũ, động viên, giúp đỡ tôi trong suốt quá trình học tập và thực hiện luận văn. Mặc dù đã cố gắng hoàn thành luận văn trong phạm vi và khả năng cho phép nhưng chắc chắn sẽ không tránh khỏi những thiếu sót. tôi rất mong được sự góp ý chân thành của thầy cô và các bạn để tôi hoàn thiện luận văn của mình. Tôi xin chân thành cảm ơn! Hà Nội, tháng 11 năm 2016 Học viên Hoàng Trọng Thủy
MỤC LỤC Chương 1. GIỚI THIỆU..................................................................................................2 1.1. Tổng quan về bộ giao thức TCP/IP và sự phát triển của mạng Internet..............2 Giới thiệu chung .....................................................................................................2 1.2. Tổng quan về truyền thông đa phương tiện (Multimedia) và chất lượng dịch vụ (QoS)...........................................................................................................................3 1.2.1. Giới thiệu chung về truyền thông đa phương tiện (Multimedia)..................3 1.2.2. Giới thiệu chung về chất lượng dịch vụ (QoS).............................................4 1.3. Kiến trúc QoS cở bản...........................................................................................8 1.3.1. QoS nhận dạng và đánh dấu .........................................................................8 1.3.2. QoS trong một thiết bị mạng ........................................................................9 1.4. Các mô hình đảm bảo chất lượng dịch vụ............................................................9 1.4.1. Mô hình các dịch vụ được tích hợp IntServ .................................................9 1.4.2. Mô hình các dịch vụ phân biệt DiffServ.....................................................12 1.5. Kiến trúc DiffServ trong bộ mô phỏng NS2......................................................17 1.5.1. Router MRED (Milti RED) ........................................................................18 1.5.2. Các cơ chế đánh dấu gói tin và chính sách phục vụ ...................................18 1.5.3. Các cơ chế lập lịch hàng đợi.......................................................................20 1.6. Thách thức của việc truyền thông đa phương tiện trên Internet hiện nay..........20 1.6.1. Hạn chế của việc truyền thông đa phương tiện hiện nay............................20 1.6.2. Các phương pháp đảm bảo chất lượng dịch vụ trên nền các dịch vụ cố gắng tối đa (best effort) .................................................................................................20 Chương 2. CÁC CHIẾN LƯỢC QUẢN LÝ HÀNG ĐỢI VÀ KHẢ NĂNG ÁP DỤNG ĐỂ ĐẢM BẢO QOS CHO TRUYỀN THÔNG ĐA PHƯƠNG TIỆN THỜI GIAN THỰC ............................................................................................................................21 2.1. Các chiến lược quản lý hàng đợi truyền thống ..................................................21 2.1.1. Hàng đợi FIFO (First in first out) ...............................................................21 2.1.2. Chiến lược hàng đợi ưu tiên PQ ( Priority Queue )....................................22 2.1.3. Chiến lược Packet-Based Round Robin .....................................................23 2.1.4. Bộ lập lịch lý tưởng GPS - Generalized Processor Sharing .......................24
2.1.5. Chiến lược Flow-Based Weighted Fair Queuing (WFQ)..........................24 2.1.6. Chiến lược Class-Based Weighted Fair Queuing (CBQ)...........................27 2.2. CÁC CHIẾN LƯỢC QUẢN LÝ HÀNG ĐỢI ĐỘNG......................................29 2.2.1. Chiến lược quản lý hàng đợi truyền thống và hệ quả.................................29 2.2.2. Ưu điểm các chiến lược quản lý hàng đợi động.........................................30 2.2.3. Thuật toán RED trong chiến lược quản lý hàng đợi động..........................32 2.2.4. Thuật toán A-RED......................................................................................39 2.2.5. Thuật toán RIO ...........................................................................................41 2.2.6. Thuật toán A-RIO.......................................................................................44 Chương 3. ĐÁNH GIÁ HIỆU QUẢ ĐẢM BẢO QOS CHO TRUYỀN THÔNG ĐA PHƯƠNG TIỆN THỜI GIAN THỰC CỦA MỘT SỐ CHIẾN LƯỢC QUẢN LÝ HÀNG ĐỢI....................................................................................................................46 3.1. Đánh giá bằng mô phỏng hiệu quả của thuật toán RED....................................46 3.2. Đánh giá bằng mô phỏng việc áp dụng kiến trúc mạng Diffserv có sử dụng RED...........................................................................................................................49 3.2.1. Cấu hình mạng mô phỏng...........................................................................50 3.3. Kết luận và hướng nghiên cứu tiếp theo ............................................................58 TÀI LIỆU THAM KHẢO.............................................................................................59
DANH SÁCH CÁC KÝ HIỆU VÀ CHỮ VIẾT TẮT STT Từ viết tắt Từ hoặc cụm từ Ý nghĩa 1 ACL Access Control Lists Danh sách điều khiển truy cập 2 AF Assured Forwarding 3 AIMD Additive-Increase Multiplicative-Decrease Tăng theo cấp số cộng, giảm theo cấp số nhân 4 AQM Active Queue Management Quản lý hàng đợi động 5 A-RIO Adaptive – RED with In/Out bit Thuật toán RED thích nghi với bit In/Out 6 CBQ Class-Based Weighted Fair Queuing 7 CBR Constant Bit Rate 8 CBS Committed Burst Size Kích thước cụm cam kết 9 CIR Committed Information Rate Tốc độ thông tin cam kết 10 CP Code Point 11 DiffServ Differentiated Services Dịch vụ phân biệt 12 EBS Excess Burst Size Kích thước cụm vượt mức 13 ECN Explicit Congestion Notification Cờ thông báo tắc nghẽn 14 EF Expedited Forwarding 15 FIFO First In First Out
16 FTP File Transfer Protocol Giao thức truyền file 17 IntServ Integrated Services Dịch vụ tích hợp 18 IP Internet Protocol 19 ISP Internet Service Provider Nhà cung cấp dịch vụ 20 LAN Local Area Network Mạng cục bộ 21 NS Network Simulator 22 PBS Peak Burst Size Kích thước cụm tối đa 23 PIR Peak Information Rate Kích thước cam kết tối đa 24 PQ Priority Queue Hàng đợi ưu tiên 25 PRI Priority 26 PHB Per-Hop Behavior Đối xử theo chặng 27 QoS Quality of Service Chất lượng dịch vụ 28 RED Random Early Detection/ Random Early Drop Phát hiện sớm ngẫu nhiên, Loại bỏ sớm ngẫu nhiên 29 RIO RED with In/Out bit 30 RIO – C Rio Coupled 31 RIO - D Rio DeCoupled 32 RR Round Robin 33 RSVP Resource Revervation Protocol Giao thức dành trước tài nguyên
34 TCP Transmission Control Protocol Giao thức điều khiển truyền vận 35 TSW Time Sliding Window Cửa sổ thời gian trượt 36 UDP User Datagram Protocol 37 WAN Wide Area Network Mạng diện rộng 38 WFQ Flow-Based Weighted Fair Queuing Hàng đợi luồng có trọng số 39 WIRR Weighted Interleaved Round Robin
DANH MỤC CÁC HÌNH VẼ, ĐỒ THỊ Hình 1.1. Sự phát triển của QoS........................................................................................ Hình 1.2. Các kỹ thuật QoS............................................................................................... Hình 1.3. Mô hình nguyên lý hoạt động của giao thức RSVP........................................... Hình 1.4. Kiến trúc DiffServ đơn giản .............................................................................. Hình 1.4. Phân loại và đánh dấu gói tin ở router biên ..................................................... Hình 2.1. Cơ chế phục vụ FIFO........................................................................................ Hình 2.2. Cơ chế phục vụ hàng đợi ưu tiên....................................................................... Hình 2.3. Cơ chế phục vụ hàng đợi Packet-Based Round Robin...................................... Hình 2.4. Cơ chế WFQ ...................................................................................................... Hình 2.5. IP Precedence bits............................................................................................. Hình 2.5. Chia sẻ băng thông trong CBQ ......................................................................... Hình 2.7. Giải thuật tổng quát cho RED gateway............................................................. Hình 2.8 Giải thuật RED chi tiết....................................................................................... Hình 2.9. Các tham số thuật toán RED............................................................................. Hình 2.10. Giải thuật tổng quát cho A-RED gateway....................................................... Hình 2.11. Giải thuật RIO ................................................................................................. Hình 3.1. Mô phỏng DropTail........................................................................................... Hình 3.2. Mô phỏng RED.................................................................................................. Hình 3.3. Giải thuật RIO ................................................................................................... Hình 3.4. Topo mạng mô phỏng ........................................................................................ Hình 3.5. So sánh thông lượng các kết nối UDP trường hợp tắc nghẽn ít ....................... Hình 3.6. So sánh kích thước hàng đợi trung bình trường hợp tắc nghẽn ít .................... Hình 3.7. So sánh độ trễ hàng đợi trung bình trường hợp tắc nghẽn ít............................
Hình 3.8 . So sánh thông lược các kết nối UDP trường hợp tắc nghẽn nhiều.................. Hình 3.9. So sánh kích thước hàng đợi trung bình trường hợp tắc nghẽn nhiều.............. Hình 3.10. So sánh độ trễ hàng đợi trung bình trường hợp tắc nghẽn nhiều ...................
DANH SÁCH BẢNG BIỂU Bảng 3.1.. So sánh RED với DropTail .............................................................................. Bảng 3.2. Thông kê gói tin trường hợp tắc nghẽn ít ......................................................... Bảng 3.3. Thống kê Từng kết nối Trường hợp tắc nghẽn ít .............................................. Bảng 3.4. Thông kê gói tin trường hợp tắc nghẽn nhiều................................................... Bảng 3.5.. Thống kê Từng kết nối trường hợp tắc nghẽn nhiều........................................
1 MỞ ĐẦU 1. ĐẶT VẤN ĐỀ Sự phát triển mạnh mẽ của mạng Internet ngày này kéo theo sự sự phát triển của các ứng dụng trên Internet. Dữ liệu trao đổi trên mạng không chỉ đơn thuần là văn bản (text) nữa mà thêm vào đó là dữ liệu đa phương tiện (multimedia) bao gồm có hình ảnh (image), âm thanh (audio), phim, nhạc… Các ứng dụng đa phương tiện phổ biến có thể kể đến như gọi điện qua mạng (Internet telephony), hội thảo trực tuyến (video conferencing) hoặc các ứng dụng xem video theo yêu cầu (video on demand) càng ngày càng được sử dụng rộng rãi. Vấn đề đảm bảo chất lượng dịch vụ (QoS) đang trở nên quan trọng hơn bao giờ hết. 2. MỤC ĐÍCH CỦA LUẬN VĂN Do sự bùng nổ mạng mẽ của mạng Internet như hiện nay khiến cho dữ liệu vận chuyển quan mạng Internet trở nên khổng lồ, nhu cầu quá lớn khiến cho việc tắc nghẽn xảy ra thường xuyên và vấn đề đặt ra là làm sao hạn chế tối đa tắc nghẽn trên mạng Internet và duy trì sự ổn định cao nhất cho mạng. Các kỹ thuật truyền thống nhằm giảm thiểu tắc nghẽn trên mạng ngày càng kém hiệu quả. Mục đích của luận văn là nghiên cứu một giải pháp quản lý và điều khiển nhằm hạn chế tối đa tắc nghẽ trên mạng Internet. Thay vì sử dụng hàng đợi FIFO truyền thống (Trong bộ mô phỏng NS2 được gọi với cái tên DropTail) luận văn này sẽ nghiên cứu sâu các chiến lược quản lý hàng đợi động mà tiêu biểu là RED (Random Early Detection of Congestion; Random Early Drop), Adaptive-RED, A-RIO (Adaptive – RED with In and Out). 3. BỐ CỤC CỦA LUẬN VĂN a) Chương 1: Giới thiệu b) Chương 2: Các chiến lược quản lý hàng đợi và khả năng áp dụng để đảm bảo QoS cho truyền thông đa phương tiện thời gian thực c) Chương 3: Đánh giá hiệu quả đảm bảo QoS cho truyền thông đa phương tiện thời gian thực của một số chiến lược quản lý hàng đợi
2 Chương 1. GIỚI THIỆU 1.1. Tổng quan về bộ giao thức TCP/IP và sự phát triển của mạng Internet Giới thiệu chung Năm 1967 từ một thí nghiệm mạng do Robert L.G đề xuất. ARPA trực thuộc bộ quốc phòng Mỹ đã kết nối 4 địa điểm đầu tiên vào tháng 7 năm 1967 gồm: Viện nghiên cứu Standford, Đại học California tại Los Angeles, Đại học tổng hợp Utah và Đại học California tại Santa Barbara. Đó là mạng WAN đầu tiên được xây dựng được gọi là ARPANET sau này là mạng Internet [17] Bộ giao thức TCP/IP chính thức ra đời năm 1983 và được coi là chuẩn đối với ngành quân sự Mỹ và tất cả các máy tính nối với mạng ARPANET phải sử dụng theo chuẩn mới này. Sự phát triển như vũ bão khiến cho mọi trường đại học đều muốn gia nhập vào mạng này và việc quản lý mạng trở nên khó khăn. Chính vì lẽ đó mạng ARPANET được tách ra thành 2 phần là MILNET và ARPANET mới vào năm 1983, tuy tách rời nhưng hai mạng này vẫn liên kết với nhau nhờ giao thức liên mạng IP. Sự ra đời của TCP/IP đánh dấu mốc lịch sử quan trọng và càng ngày càng hiện rõ điểm mạnh của nó nhất là khả năng liên kết các mạng khác với nhau một cách dễ dàng. Vào thập kỷ 80 khi hội đồng Khoa học quốc gia Mỹ NSF (Nation Science Foundation) thành lập mạng liên kết các trung tâm máy tính lới với nhau gọi là NSFNET. Các doanh nghiệp đã chuyển từ ARPANET sang NSFNET. Sau gần 20 năm hoạt động ARPANET đã dừng hoạt động vào khoảng năm 1990. Sự phát triển của backbone NSFNET và những mạng khác đã tạo ra mội trường thuận lợi cho sự phát triển của Internet. Năm 1995 NSFNET thu lại thành một mạng nghiên cứu và Internet thì tiếp tục phát triển. Cùng với khả năng kết nối mở Internet đã trở thành một mạng lớn nhất thế giới, mạng của các mạng xuất hiện trong mọi linh vực thương mại, chính trị, quân sự, xã hội… Ngày nay khi cơ sở hạ tầng của mạng Internet được nâng cao đã làm cho nhu cầu của các ứng dụng đa phương tiện qua mạng tăng lên nhanh chóng.
3 1.2. Tổng quan về truyền thông đa phương tiện (Multimedia) và chất lượng dịch vụ (QoS) 1.2.1. Giới thiệu chung về truyền thông đa phương tiện (Multimedia) Trước đây, khi mà Internet chủ yếu là truyền data thì người ta không cần quan tâm đến việc phân biệt và ưu tiên cho các gói tin bởi vì lúc này băng thông mạng và các tài nguyên khác đủ để cung cấp cho các ứng dụng trong mạng, vì vậy các ISPs sẽ cung cấp cho khách hàng của họ dịch vụ theo kiểu “Cố gắng tối đa” (Best-Effort - BE) khi đó tất cả các khách hàng sẽ được đối xử như nhau họ chỉ khác nhau ở loại kết nối. Đây là dịch vụ phố biến trên mạng Internet hay mạng IP nói chung. Các gói thông tin được truyền đi theo nguyên tắc “đến trước được phục vụ trước” mà không quan tâm đến đặc tính lưu lượng của dịch vụ là gì. Điều này dẫn đến rất khó hỗ trợ các dịch vụ đòi hỏi độ trễ thấp như các dịch vụ thời gian thực hay video. Cho đến thời điểm này, đa phần các dịch vụ được cung cấp bởi mạng Internet vẫn sử dụng nguyên tắc Best Effort này. Dữ liệu truyền thông trên mạng Internet thường được chia làm 2 loại chính là dữ liệu dạng tĩnh và dữ liệu dạng động. Các ứng dụng trên Internet truyền thống như Web, email, file tranfer thường truyền dữ liệu dạng tĩnh. Dữ liệu được truyền một cách nhanh nhất có thể. Tuy nhiên trộ trễ đầu cuối có thể lên tới 10s hoặc hơn vẫn chấp nhận được. Dữ liệu động ở đây thường là Audio hoặc Video và các ứng dụng truyền thông loại dữ liệu trên được gọi chung là ứng dụng đa phương tiện. Loại dữ liệu này rất nhạy cảm với độ trễ nhưng lại cho phép sự mất mát gói tin trong một ngưỡng chấp nhận được. Tính chất hoàn toàn trái ngược với các ứng dụng truyền thống nên nó đòi hỏi chất lượng dịch vụ khác hoàn toàn với các ứng dụng truyền thống. Tùy theo từng yêu cầu về chất lượng dịch vụ có thể chia ứng dụng đa phương tiện thành 3 lớp cơ bản sau:  Truyền audio và video đã được lưu trữ  Truyển audio và video thời gian thực  Ứng dụng tương tác audio và video thời gian thực
4 1.2.2. Giới thiệu chung về chất lượng dịch vụ (QoS) Quality of Service – QoS: chỉ khả năng cung cấp các dịch vụ mạng cho một lưu lượng nào đó. Mục đích chính là điều khiển băng thông, độ trễ và jitter. Giảm độ trễ, giảm tỉ lệ mất mát gói tin cho các ứng dụng thời gian thực và tương tác trong khi vẫn đảm bảo phục vụ tốt cho các luồng dữ liệu khác. Theo khuyến nghị của CCITT, E800 đưa ra một tính chất chung qua QoS: “Hiệu ứng chung của đặc tính chất lượng dịch vụ là xác định mức độ hài lòng của người sử dụng đối với chất lượng dịch vụ” Khuyến nghị ETR300003 của ETSI chia và cải tiến định nghĩa của ITU thành các định nghĩa nhỏ hơn, nó phù hợp với các yêu cầu và quan điểm của các nhóm khác nhau trong viễn thông đó là:  Yêu cầu QoS của người sử dụng.  Đề nghị QoS của nhà cung cấp dịch vụ.  Sử cảm nhận QoS từ khách hàng.  Việc thực hiện QoS của nhà cung cấp dịch vụ.  Yêu cầu QoS của nhà cung cấp dịch vụ. Như vậy một cách tổng quan QoS mang ý nghĩa là “Khả năng của mạng đảm bảo và duy trì các mức thực hiện nhất định cho mỗi ứng dụng theo như yêu cầu đã chỉ rõ của mỗi người sử dụng”. Một ý trong định nghĩa này chính là chìa khóa để hiểu được QoS là gì từ góc nhìn của nhà cung cấp mạng. Nhà cung cấp dịch vụ mạng đảm bảo QoS cung cấp cho người sử dụng và thực hiện các biện pháp duy trì mức QoS khi điều kiện mạng thay đổi vì các nguyên nhận như tắc nghẽn, hỏng hóc thiết bị hay lỗi đường truyền v. v… QoS cần được cung cấp cho mỗi ứng dụng để người sử dụng có thể chạy ứng dụng đó tuy nhiên người sử dụng cũng cần phải tìm hiểu các thông tin từ người quản trị để hiểu mạng phải cung cấp những gì cần thiết cho mỗi sứng dụng. Đảm bảo chất lượng dịch vụ thường phụ thuộc nhiều vào tài nguyên của hệ thống, việc quản lý tài nguyên đó bao gồm có:  Tính toán hiệu suất sử dụng tài nguyên  Dành tài nguyên cho dịch vụ
5  Lập lich truy cập tài nguyên Hình 1.1: Sự phát triển của QoS Các tham số QoS chính liên quan đến mạng bao gồm: a) Độ trễ (Delay): là thời gian truyền 1 gói tin từ nguồn tới đích, nó phụ thuộc vào tốc độ truyền tin. Tốc độ truyền tin càng lớn thì độ trễ càng nhỏ và ngược lại. Delay liên quan chặt chẽ tới băng thông. Với các ứng dụng giới hạn băng thông thì băng thông càng lớn độ trễ càng nhỏ. b) Thông lượng (Throughput): là khả năng truyền tin được tính bằng tổn số đơn vị dữ liệu truyền được trong 1 đơn vị thời gian ví dụ: packet/s c) Jitter: là sự biến thiên độ trễ. Thông số QoS jitter thiết lập giới hạn lên lượng biến đổi của độ trễ mà một ứng dụng có thể gặp phải trên mạng. Một cách chính xác hơn thì jitter được xem như là biến động trễ. Jitter theo lý thuyết có thể là một giá trị tương đối hoặc tuyệt đối. Ví dụ nếu trễ mạng cho một ứng dụng được thiết lập là 100ms, jitter có thể đặt là cộng trừ 10% độ trễ. Theo đó độ trễ đảm bảo phải dao động trong khoảng từ 90ms đến 110ms. Mặt khác nếu giá trị jitter là 5ms thì độ trễ phải dao động trong khoảng từ 95ms đến 105ms. Các ứng dụng nhạy cảm nhất với jitter là các ứng dụng thời gian thực
6 như voice, video streaming nhưng lại không quan trọng đối với các ứng dụng như web hoặc truyền file qua mạng… Đây là vấn đề cố hữu trọng mạng chuyển mạch gói do cơ chế định tuyến và chuyển mạch các gói tin trong mạng của cùng một luồng có thể đi theo nhiều đường khác nhau để đến đích khi đó độ trễ của các gói tin nay là khác nhau dẫn tới việc jitter là không thế nào tránh khỏi. d) Tỉ lệ mất gói tin (Packet loss ratio): là số đơn vị gói tin bị mất trong một đơn vị thời gian, đây là một tham số QoS không thường xuyên được nói đến. Bản chất của Internet hiên nay vẫn dựa trên nền “BE” thế nên việc mất gói tin là không tránh khỏi. Chính vì thế tham số QoS Packet loss không nên định rõ một giới hạn trên đối với anh hưởng của lỗi mà nên cho phép người sử dụng xác định xem có lựa chọn cách sửa lỗi bằng việc truyền lại không hoặc các cơ chế khắc phục khác. e) Độ khả dụng (Đáng tin cậy): Các mạng tồn tại để phục vụ người sử dụng , tuy nhiện mạng cần có các biện pháp bảo dưỡng và phòng người trước các tình huống hỏng hóc tiềm tàng được phát hiện và dự đoán trước. Một chiến lược đúng đắn bằng cách định kì tách các thiết bị ra khỏi mạng và thực hiện các công việc bảo dưỡng và chẩn đoán trong một thời gian gnawns để có thể giảm thời gian ngưng hoạt động do hỏng hóc. Thậm chí với biện pháp bảo dưỡng hoàn hảo nhất cũng không thể tránh được các lỗi không tiên đoán trước và các lỗi nghiêm trọng của các thiết bị và kết nối theo thời gian. Việc bảo trì mạng dữ liệu trở nên đơn giản hơn, hầu hết mạng dữ liệu sinh ra dành cho kinh doanh thường là từ 8h sáng đến 6h chiều từ thứ 2 đến thứ 6. Các hoạt động bổ trở hoặc bảo trì có thể được thực hiện ngoài giờ hoặc trong các ngày nghỉ. Internet và web đã thay đổi tất cả, một mạng toàn cầu phải giải quyết được vấn đề rằng thực sự có một số người luôn cố gắng truy nhập vào mạng tại một số địa điểm và thậm chí Internet còn có ích cho một số người vào giờ ngoài hành chính hơn. Một năm có 31.536.000 giây, giả thiết rằng độ khả dụng của một mạng là 99% thì điều này có nghĩa rằng nhà cung cấp dịch vụ có 315.360 giây hay 87,6 giờ mạng không hoạt động trong 1 năm. Khoảng thời gian này là tương đối lớn. Nếu giá trị này 99,99% thì sẽ tốt hơn nhiều. Tất nhiên nhà cung cấp dịch vụ cần nhiều cơ chế
7 dự phòng và khắc phục lỗi để đảm bảo độ sẵn sàng của mạng càng cao. Ngày ngay QoS khả dụng của mạng thường khoảng 99,995% f) Bảo mật: Đây là một tham số mới trong danh sách các tham số QoS nhưng lại là một tham số quan trọng, thực tế trong một số trường hợp độ bảo mật có thể được xét ngay sau băng thông. Gầy đây sự đe dọa rông rãi của các hacker và sự lan tràn virus trên mạng Internet toàn cầu thì tham số này càng trở nên quan trọng hơn. Hầu hết vấn đề bảo mật liên quan tới tính riêng tư, tự tin cậy và xác nhận Server – Client. Các vấn đề bảo mật thường được gắn với một vài hình thức của phương pháp mật mã như mã hóa giữ liệu và giải mã. Các phương pháp trên mạng cũng được sử dụng như xác thực (Authentication). Một tham số QoS bảo mật điển hình có thể là “Mã hóa và xác thực đòi hỏi trên tất cả các luồn lưu lượng”. Ngày nay tầm quan trọng của bảo mật như một tham số QoS là rất lớn không thể đánh giá hết được g) Ngoài ra còn một số tham số như “Kích thước mất tin” hoặc “độ tin cậy” Hình 1.2: Các kỹ thuật QoS
8 Mức QoS:  Best-Effort: Đây là mức thấp nhất, dịch vụ kết nối không đảm bảo đặc trưng bởi hàng đợi FIFO, không có sự phân loại giữa các luồng dữ liệu  QoS Cứng: là sự đặt trước tài nguyên phục vụ cho một luồng dữ liệu xác định trước thường được cung cấp bởi giao thức RSVP và CBR có trong kiến trúc IntServ  QoS Mềm: trong kiến trúc mạng phân loại (Differentiated service) dựa trên sự phân loại các luồng dữ liệu theo nhiều mức ưu tiên thì một luồng dữ liệu nào đó sẽ được ưu tiên phục vụ tốt hơn các luồn còn lại. Việc lựa chọn loại dịch vụ nào để triển khai trong mạng phụ thuộc vào các yếu tố sau:  Ứng dụng hoặc tính chất của bài toán cần giải quyết  Chi phí cho cài đặt và triển khai dịch vụ 1.3. Kiến trúc QoS cở bản QoS cơ bản bảo gồm có 3 phần chính  Định dạng QoS và các kỹ thuật đánh dấu cho phép QoS phối hợp từ điểm đầu tới điểu cuối giữa từng thành phần mạng.  QoS trong từng thành phần mạng đơn (Các chiến lược, công cụ quản lý, lập lịch hàng đợi).  Các chính sách điều khiển QoS giám sát lưu lượng đầu cuối qua mạng 1.3.1. QoS nhận dạng và đánh dấu Điểm cơ bản trong việc đảm bảo chất lượng cho các dịch vụ trên Internet là việc ta nhận dạng, phân loại và đánh dấu được từng mức ưu tiên cho các dịch vụ để cung cấp các chính sách phục vụ ưu tiên cho các lớp lưu lượng cũng như dịch vụ có độ ưu tiên cao hơn các lớp còn lại. Điều này thường được thực hiện bằng cách dựa vào các trường trong tiêu đều gói tin IP như: IP nguồn, Ip đích, Port nguồn, Port đích, hoặc các giá trị trong trường Type Of Service…
9 1.3.2. QoS trong một thiết bị mạng QoS trong một thiết bị mạng thường bao gồm các cơ chế sau: a) Quản lý tắc nghẽn: do sự phát triển của mạng Internet kéo theo sự phát triển mạnh mẽ của các ứng dụng đa phương tiên thời gian thực, các ứng dụng này thường có lưu lượng dữ liệu bùng nổ lớn khiến cho mạng thường xuyên xảy ra tắc nghẽn. Nếu tắc nghẽn xảy ra thì các router sẽ phản ứng như thế nào để giảm thiểu tác hại của tắc nghẽn. b) Quản lý hàng đợi: Vì kích thước của hàng đợi không vô hạn và độ dài của hàng đợi tỉ lệ với độ trễ của gói tin vậy nên cần có cơ chế quản lý hàng đợi hợp lý sao cho lượng gói tin bị drop và độ trễ hàng đợi của gói tin là chấp nhận được cũng như khả năng hấp thu các lưu lượng đột biệt của hàng đợi c) Hiệu suất đường truyền: router phải có các cơ chết kết hợp để đạt được hiệu suất đường truyền cao nhất nhằm tránh lãng phí đường truyền, mặt khác cũng cần phải cân bằng với các tham số QoS khác như độ trễ và tỉ lệ mất gói tin. 1.4. Các mô hình đảm bảo chất lượng dịch vụ 1.4.1. Mô hình các dịch vụ được tích hợp IntServ Mô hình IntServ (Integrated Services) được IETF (Internet Engineering Task Force) giới thiệu vào giữa thập niên 90 và được định nghĩa trong RFC (Request For Comments) 1633. Mô hình này nhằm cung cấp khả năng đảm bảo chất lượng dịch vụ cho một số luồng lưu lượng bằng cách đặt trước tài nguyên từ nguồn tới đích thông qua giao thức đặt trước tài nguyên RSVP. IntServ đưa ra khả năng cho các ứng dụng lụa chọn trong nhiều khả năng các mức điều khiển cho các gói dữ liệu, hỗ trợ QoS theo luồng. Nó yêu cầu kiến trúc phức hợp bao gồm phân loại, xếp hang và định trình dọc theo một tuyến đường truyền bất kỳ từ nguồn tới đích. IntServ phát triển dựa trên nền BestEfford Internet nhưng mở rộng cho các ứng dụng tương tác và thời gian thực. IntServ hỗ trợ cho hai lớp ứng dụng: Các ứng dụng thời gian thực có yêu cầu chặt chẽ về băng thông và độ trễ mà người sử dụng không có được ở mạng chỉ hỗ trợ BestEffort
10 Các ứng dụng truyền thống mà trong đó người sử dụng không phải quan tâm đến lưu lượng cũng những người sử dụng khác, khi đó mạng được xem như mạng BestEffort có mức tải thấp. Nguyên lý căn bản của mô hình IntServ là dành riêng tai nguyên mạng: băng thông, độ trễ,… cho từng luồng dữ liệu xuyên suốt từ nguồn phát cho tới đích. Tài nguyên này không được chiếm dụng cho bất cứ một luồng dữ liệu nào khác, vì tài nguyên bị chiếm dụng nhưng nếu không được sử dụng nó sẽ dẫn tới việc lãng phí tài nguyên. Sự ra đời của kiến trúc IntServ nhằm giải quyết các vấn đề sau:  Dịch vụ BestEfford không còn dủ đáp ứng nhu cầu sử dụng hàng ngày: Ngày càng có nhiều ứng dụng khác nhau và có yêu cầu khác nhau về đặc tính lưu lượng được triển khai, đồng thời người sử dụng cũng yêu cầu chất lượng ngày càng cao hơn  Sự xuất hiền ngày càng nhiều của các ứng dụng đa phương tiện: mạng IP phải có khả năng hỗ trợ không chỉ đơn dịch vụ mà còn hỗ trợ đa dịch vụ của nhiều loại lưu lượng khác nhau từ voice, data cho đến video  Tối ưu hóa hiệu suất sử dụng mạng và tài nguyên mạng: đảm bảo hiệu quả sử dụng và đầu tư. Tài nguyên mạng sẽ được lưu trữ cho lưu lượng có độ ưu tiên cao hơn  Cung cấp dịch vụ tốt nhất cho một lớp người sử dụng. Các mức QoS được cung cấp bởi IntServ bao gồm:  Dịch vụ BestEffort  Dịch vụ đảm bảo GS (Guaranteed Service)  Dịch vụ kiểm soát tải CL (Controlled Load) Giao thức dành trước tài nguyên RSVP RSVP là giao thức giành tài nguyên là giao thức được sử dụng bởi Intserv được đề cập trong RFC2205, tự động cập nhật tình trạng đường truyền khi có lỗi xảy ra. RSVP là giao thức điều khiển Internet được thiết kế để cài đặt chất lượng dịch vụ trên mạng IP (RSVP không phải chỉ sử dụng dành riêng với mô hình Intserv). Về tổng quát, giao thức RSVP hoạt động như sau: Khi một node nào đó gửi dữ liệu, nó gửi một bản tin RSVP qua các node trung gian tới nút nhận, bản tin này chứa đặc điểm lưu lượng sẽ gửi, đặc điểm của các node mạng trên đường đi. Node nhận sau khi nhận được thông điệp, căn cứ vào đặc điểm lưu lượng và đặc điểm đường đi, sẽ gửi lại một thông điệp để đăng ký
11 tài nguyên tại các node trung gian trên đường đi đó. Nếu việc đăng ký thành công, node gửi bắt đầu truyền dữ liệu. Nếu không, thông điệp đi đến node gửi sẽ báo lỗi. RSVP có thể mang dịch vụ yêu cầu và đáp ứng tương ứng của thành phần chấp nhận luồng từ máy tính tới router, từ router tới router và từ router tới máy đích (hoặc nhiều một máy). RSVP sử dụng 6 thông điệp, “Path” và “Resv”. Thông điệp Resv mang tham số dịch vụ. Thông điệp Path bắt đầu từ nguồn và được gửi tới đích. Mục đích chính của nó là để router biết trên kết nào sẽ chuyển tiếp thông điệp giành tài nguyên (nó cũng bao gồm định nghĩa về đặc điểm lưu lượng của luồng). Thông điệp Error được sử dụng khi việc giành tài nguyên thất bại. RSVP không phải là một giao thức định tuyến do đó nó không cần xác định liên kết nào sẽ được dùng để giành trước mà nó dựa vào các giao thức định tuyến bên dưới để xác định tuyến đường cho một luồng. Một khi tuyến đường được xác định, RSVP bắt đầu thực hiện việc giành trước tài nguyền. Trong suốt quá trình thiết lập để giành tài nguyên, RSVP phải được thông qua mô đun điều khiển về chính sách và mô đun quản lý về việc chấp nhận tuyến đường. Mô đun điều khiển về chính sách xác định xem người dùng có đủ thẩm quyền để giành được nguồn tài nguyên hay không. Thành phần chấp nhận tuyến đường xác định xem nút đó có đủ tài nguyên để cung cấp cho yêu cầu QoS hay không. Nếu cả hai bước kiểm tra đều tốt, các tham số được thiết lập trong bộ phân loại gói và trong bộ lập lịch để đạt được QoS mong muốn. Tiến trình này được thực hiện tại mọi router và máy tính dọc theo tuyến đường. Nếu có xảy ra lỗi, thông điệp RSVP Error được tạo và quảng bá cho mọi nút. Hình 1.3: Mô hình nguyên lý hoạt động của giao thức RSVP Theo hình 1.1, máy gửi gửi bản tin PATH (mô tả thông tin truyền thông qua địa chỉ IP nguồn và địa chỉ IP đích theo chiều đi) đến máy nhận để yêu cầu dành trước tài nguyên và thiết lập một luồng truyền thông. Máy nhận nhận được bản tin PATH sẽ gửi
12 lại máy gửi bản tin RESV (mô tả thông tin truyền thông qua địa chỉ IP nguồn và địa chỉ IP đích theo chiều về) để thiết lập và duy trì việc dự trữ tài nguyên. Khi đi qua các router, dựa vào hai bản tin PATH và RESV, các router đăng ký nhận dạng luồng và lưu đặc tính luồng vào cơ sở dữ liệu. Nếu bản tin PATH lỗi thì bản tin PathErr sẽ được sử dụng để thông báo. Tương tự, RSVP sử dụng bản tin ResvErr để thông báo lỗi cho bản tin RESV. Bên cạnh đó, RSVP còn dùng hai bản tin PathTear và ResvTear. PathTear sử dụng để xóa bỏ tài yêu cầu dành tài nguyên theo hướng đi đã được thiết lập. Tương tự, ResvTear sử dụng để xóa bỏ tài yêu cầu dành tài nguyên theo hướng về. Tại mỗi node mạng, yêu cầu dự trữ tài nguyên gồm 2 hoạt động:  Dự trữ tài nguyên tại một node mạng.  Chuyển tiếp yêu cầu dự trữ tài nguyên cho các node khác còn lại trên mạng. Trong môi trường truyền đa hướng (một máy nhận dữ liệu từ nhiều máy gửi, một máy gửi dữ liệu tới nhiều máy nhận) các yêu cầu dự trữ tài nguyên được chuyển sang một node khác khi node trước đó đã đáp ứng việc dự trữ các yêu cầu tài nguyên. Một đặc điểm quan trọng của RSVP là việc giành tài nguyên được thực hiện bởi “trạng thái mềm”. Có nghĩa là trạng thái giành tài nguyên có liên quan tới một bộ định thời, và khi bộ định thời hết hạn, việc giành trước tài nguyên được loại bỏ. Nếu nơi nhận muốn lưu lại trạng thái giành tài nguyên nào, nó phải đều đặn gửi các thông điệp giành tài nguyên. Nơi gởi cũng phải thường xuyên gửi các thông điệp này. RSVP được thiết kế dành cho kiến trúc Intserv nhưng vai trò của nó cũng được mở rộng cho giao thức báo hiệu trong MPLS 1.4.2. Mô hình các dịch vụ phân biệt DiffServ Sự phát triển mạnh mẽ của mạng Internet và hạ tầng mạng trong những năm gần đây, ngày càng nhiều các tổ chức tham gia cung cấp các dịch vụ Intenet với nhiều loại hình gói cước khác nhau, đáp ứng nhu cầu của nhiều người dùng khác nhau tùy theo khả năng chi trả. Lượng dữ liệu vận chuyển trên Internet ngày càng tăng, để đáp ứng thực tế
13 đó ngoài sự phát triển mạnh về phần cứng hạ tầng mạng đặc biệt là băng thông mạng, điều quan trọng hơn là phải có những chính sách phục vụ tốt hơn tại các nút mạng. Hình 1.4: Kiến trúc DiffServ đơn giản Trong quá trình triển khai đảm bảo chất lượng dịch vụ cho các ứng dụng đa phương tiện thời gian thực trên Internet, mặc dù kiến trúc IntServ đảm bảo cung cấp QoS một cách chắc chắn nhưng lại chứa khá nhiều nhược điểm như khả năng mở rộng (scalability) trong core network hoặc chi phí cao, cài đặt phức tạp và khó quản lý ở router vì nó phản đảm nhiệm rất nhiều việc dẫn tới làm chậm tốc độ truyền dữ liệu và gia tăng độ trễ end- to-end. Điều này đã tạo ra động lực cho các nghiên cứu rộng hơn để phát triển một giải pháp cung ứng QoS phi trạng thái (stateless), đó là kiến trúc Diffserv (Differentiated services). DiffServ trở thành giải pháp QoS thứ 2 của IETF. Diffserv trái ngược với Intserv là dựa trên từng luồng dữ liệu, nó phân loại các gói thành một số lượng không lớn các tập (gọi là các lớp) và do đó đạt được hiệu quả cho các mạng lớn. Các chức năng đơn giản được thực hiện tại router lõi, trong khi các chức năng phức tạp được triển khai tại các router biên. Tính linh động rất là cần thiết vì dịch vụ mới có thể xuất hiện và một
14 số dịch vụ trở lên lỗi thời. Kiến trúc DiffServ khắc phục được những nhược điểm của kiến trúc IntServ vì có tính khả triển cao. Tuy nhiên để đáp ứng được các nhu cầu đa dạng của ứng dụng trên thực tế kiến trục được triển khai phải đi kèm các thuật toán quản lý lưu lượng trên đó. Các giải thuật quản lý lưu lượng có thể được phân loại theo thời gian hoạt động của chúng hay theo khả năng điều khiển. Do đó, các giải thuật này có thể hoạt động theo mức gói hay khối dữ liệu hay kết nối. Các nguyên lý phục vụ gói là ví dù về các giải thuật theo mức gói hya khối số liệu, với nhiệu vụ cung cấp các phẩm chất giữa hai đầu cưới thông qua biện pháp phân loại và lập lịch lưu lượng. Trong số các giải pháp điều khiên lưu lượn theo từng cuộc gọi hay từng kết nối thì điểu khiển chấp nhận (admission control) là một trong số các giải pháp phổ dụng nhất. Tùy theo vị trí hoạt động mà có thể là tấp trung hay phân tán. Đại diện tiêu biểu cho điều khiển chấp nhận nối phân tán là giao thức RSVP. Nguyên lý hoạt động của mô hình DiffServ như sau: Các gói tin được phân loại ra thành nhiều nhóm ưu tiên từ thấp đến cao tùy theo đặc điểm của từng dịch vụ, thiết bị sẽ tiến hành cung cấp tài nguyên theo từng nhóm, nhóm nào có thứ tự cao hơn thì sẽ được cung cấp quyền được sử dụng tài nguyên ưu tiên hơn, tài nguyên sẽ được các nhóm thấp hơn dùng nếu nhóm trên không sử dụng nữa. Tất cả các quá trình này sẽ được thực hiện riêng lẻ trên từng thiết bị. Cấu trúc DiffServ Cấu trúc của mô hình DiffServ bao gồm nhiều class lưu lượng cho từng dịch vụ cụ thể và mỗi class được cung cấp một lượng tài nguyên xác định. Để phân biệt các class, DiffServ sử dụng một thông tin gọi là điểm mã phân biệt dịch vụ DSCP (Differentiated Service Code Point). DSCP có tiền thân là vùng ToS (Type of Service) trong IP header. Trong kiến trúc DiffServ chia thành 2 thành phần chính là phần biên và mạng lõi.  Mạng biên: có nhiệm vụ phân loại gói tin và điều kiển lưu lượng, Vị trí này có thể là một nguồn lưu lượng có cài đặt chính sách phân loại gói tin hoặc router hỗ trợ DiffServ đầu tiên (router biên). Tại biên mạng này các gói tin sẽ được đánh dấu vào trường Diffierentiated Service (DS) trong header của các gói tin một giá trị nào đó gọi là Code Point (CP). Các lớp lưu lượng khác nhau sẽ được đánh dấu với
15 các giá trị CP khác nhau và sẽ nhận được dịch vụ khác nhau trong phần mạng lõi. Sau khi đánh dấu, các gói tin có thể được xếp vào hàng đợi hay chuyển thẳng vào trong mạng lõi  Mạng Lõi: chức năng chính là chuyển tiếp các gói tin. Một gói tin đã được đánh dấu với giá trị CP sẽ được chuyển tới note tiếp theo thông qua từng chính sách (PHB – Per-hop Behavior). PHB ảnh hưởng tới việc chia se băng thông và bộ đệm giữa các lớp lưu lượng cạnh tranh tại router. Hai chính sách quan trọng nhất ứng với mỗi thành phần của DiffServ đó là chính sách phân loại và điều khiển lưu lượng của mạng biên và chính sách đối xử từng chặng PHP của thành phần mạng lõi. a. Phân loại và điều khiển lưu lượng của mạng biên Một packet được đánh dấu vào trường DS của header gói tin IP tại vị trí vào của mạng, nó có thể diễn ra tại một host hỗ trợ DiffServ hoặc router biên hỗ trợ DiffServ. Giả sử rằng việc phân loại và đánh dấu gói tin này được xảy ra ở router kết nối trực tiếp với bên gửi tin được gọi là router biên (edge router). Hình 1.5: Phân loại và đánh dấu gói tin ở router biên Một packet sau khi được gửi sẽ đi tới edge router. Các router phân loại gói tin dựa trên giá trị của một hoặc nhiều trường tiêu đều của packet ví dụ như địa chỉ ip nguồn, địa chỉ ip đích, port nguồn, port đích… hoặc dựa trên tốc độ tới của các gói tin so với ngưỡng. Giá trị trường DS sẽ nhận được một giá trị tại bộ đánh dấu gói tin (Maker). Ngay sau khi được đánh dấu các gói tin sẽ được chuyển đến router tiếp theo
16 để đi tới đích. Tại mỗi router có hỗ trợ DiffServ những gói tin đã được đánh dấu này sẽ nhận được lượng dịch vụ dựa theo các đánh dấu của chúng. b. Per-Hop Behavior Sau khi các gói tin đi qua edge router sẽ được phân loại và đánh dấu vào trường DS trong header gói tin và được chuyển tiếp tới các router tiếp theo ở đây là core router, thành phần thứ hai của kiến trúc DiffServ. Tại core router được cài đặt chính sách theo từng chằng PHB và nó chứa những đặc điểm sau:  Các lớp lưu lượng khác nhau (các lớp có giá trị trường DS khác nhau) sẽ nhận được các dịch vụ khác nhau (cách chuyển tiếp khác nhau, băng thông khác nhau,…)  Hiệu năng phải quan sát được và đo được  PHB không chỉ định cụ thể cơ chế nào phải được áp dụng để đạt được mục đích và vì vậy bất kì một có chế quản lý cấp phát tài nuyên hay cơ chế chuyển tiếp nào cũng có thể được sử dụng miễn là đạt được các mục đích tiêu chí hiệu năng mong muốn. Hiện tại có hai chuẩn PHB được chú ý nhiều nhất đó là EF (Expedited Forwarding) và AF (Assured Forwarding)  EF PHB chỉ ra rằng tốc độ gói tin ra khỏi router của một lớp lưu lượng nào đó phải bằng hoặc vượt qua một ngưỡng cho trước. Nghĩa là trong mọi khoảng thời gian lớp lưu lượng đó được đảm bảo nhận được đủ băng thông sao cho tốc độ ra của có vượt qua tốc độ đặt trước này. EF PHB đảm bảo ngay cả khi có nhiều lớp lưu lượng khác đi đến router và tài nguyên của đường truyền thì một lượng đủ tài nguyên vẫn được ta sẵn cho lớp để đảm bảo nó nhận được một tốc độ tối thiểu.  AF PHB thì phức tạp hơn. AF PHB chia lưu lượng thành 4 lớp, trong đó mỗi lớp AFF được đảm bảo cung cấp một lượng băng thông tối thiểu và bộ đệm. Trong mỗi lớp các packet lại được phân vào một trong 3 loại “ưu tiên loại bỏ”. Khi tắc nghẽn xuất hiện trong một lớp AF, router có thể loại bỏ các gói tin dựa trên giá trị ưu tiên loại bỏ của chúng. Bằng cách thay đổi lượng tài nguyên cấp phát cho từng lớp, một nhà cung cấp dịch vụ Internet (ISP) có thể cung cấp các mức độ ưu tiên thực hiện khác nhau có các lớp lưu lượng AF khác nhau. AF PHB có thể được
17 dùng để cung cấp các mức dịch vụ khác nhau cho các hệ thống cuối. Trong các hệ thống này việc quyết định số lượng các tài nguyên cấp cho từng lớp dịch vụ phải gắn liền với việc giới hạn các thám số liên quan. Ví dụ như có 3 lớp dịch vụ khác nhau là A, B, C trong đó lớp A được cung cấp x% băng thông, lớp B được cung cấp x/2% băng thông, lớp C được cung cấp x/4% băng thông. Thoạt nhìn ta có thể thấy rằng lớp A nhận được lượng băng thông nhiều nhất và có thể nói lớp A được phục vụ tốt hơn lớp B và C. Tuy nhiên nếu ta xét rằng lưu lượng dữ liệu tại lớp A cao gấp nhiều lần lớp B và C thì có thể thấy rằng các gói tin lớp A sẽ được phục vụ ít hơn các gói tin lớp B và C. Như vậy kích thước tài nguyên được cung cấp là chưa đủ để đánh giá chất lượng dịch vụ của một lớp mà phải gắn thêm ràng buộc dữ liệu tối đa cho các gói tin lớp đó nữa. Trong NS-2, các lớp AF được cài đặt với các hàng đợi vật lý khác nhau, trong các hàng đợi đó thì các gói tin ứng với các mức ưu tiên khác nhau được đưa vào một hàng đợi ảo tương ứng. Như vậy ta có tối đa 4 hàng đợi vật lý, mỗi hàng đợi vật lý sẽ có tối đa 3 hàng đợi ảo. Mỗi hàng đợi sẽ có thể cài đặt một chính sách quản lý hàng đợi và phục vụ riêng, có thể là DropTail, RED, RIO-C, RIO-D… 1.5. Kiến trúc DiffServ trong bộ mô phỏng NS2 Trong NS2 modul DiffServ được thược hiện theo “Assured forwarding”. Diffserv dựa trên việc đánh dấu các gói tin tại rìa của mạng (nơi gói tin chuẩn bị đi vào DiffServ network) theo các mức hiệu suất cần đảm bảo, sau đó dựa vào các đánh dấu này các gói tin sẽ có các chính sách xử lý khác nhau tại các nút mạng. Cách dễ dàng nhất để phân biệt các gói tin là sử dụng hàng đợi RED, dùng các tham số khác nhau cho các loại gói tin khác nhau. Modul NS có xử lý diffserv được phát triển ở Nortel network. Diffserv chia các gói tin thành nhiều lớp khác nhau (Tối đa là 8 lớp), Gói tin thuộc lớp nào sẽ được xếp vào hàng đợi của lớp đó, ngoài ra để phân biệt các gói tin trong cùng một lớp người ta chia hàng đợi vật lý này thành 3 hàng đợi ảo. Mỗi gói tin thuộc vào một luồng có thể nhận 3 mức ưu tiên cùng với luồng đó, đôi khi còn được gọi là “Drop precedence” Kiến trúc Diffserv trong NS2 được chia thành 3 phần chính:
18 - Thành phần quản lý tài nguyên và chính sách: Xây dựng các chính sách và phân phối chúng cho đến các router hỗ trợ diffserv. Các chính sách này sẽ xác định một gói tin sẽ nhận được mức dịch vụ như thế nào trong mạng. Việc này phụ thuộc vào tính chất tài nguyên của luồng đó và các thành phần của mạng. - Edge Router: chịu trách nhiệm phân loại và đánh dấu các gói tin khi các gói tin này đi vào Diffserv Network - Core Router: thực hiện các chính sách đảm bảo chất lượng dịch vụ cho các gói tin theo từng mức ưu tiên đã được đánh dấu (Per-Hop behavior) 1.5.1. Router MRED (Milti RED) Trong mỗi hàng đợi vật lý được phân ra thành 3 hàng đợi ảo, các hàng đợi ảo này sử dụng thuật toán RED để quản lý các gói tin sau khi được phân loại. Các mode của router MRED được hỗ trợ trong NS2 bao gồm có: - RIO – C (Rio Coupled): Trong đó xác suất loại bỏ các gói tin có độ ưu tiên thấp (các gói tin ngoài luồng) dựa trên độ dài trung bình của tất cả các hàng đợi ảo, xác suất hủy các gói tin có mức ưu tiên cao thì dựa trên kích thước hàng đợi trung bình của hàng đợi ảo chưa gói tin đó. - RIO – D (Rio De-coupled): Xác suất loại bỏ các gói tin dựa trên kích thước hàng đợi trung bình của chính hàng đợi chứa gói tin đó. - WRED (Weight RED): xác suất loại bỏ gói tin dựa trên chiều dài của hàng đợi đơn. - DROP: Giống như hàng đợi Droptail với chiều dài hàng đợi tối đa được chỉ định bằng ngưỡng 𝑚𝑖𝑛 𝑡ℎ của thuật toán RED, khi kích thước hàng đợi trung bình vượt quá ngưỡng 𝑚𝑖𝑛 𝑡ℎ tất cả các gói tin sẽ bị loại bỏ không kể việc gói tin có được đánh dấu hay không. 1.5.2. Các cơ chế đánh dấu gói tin và chính sách phục vụ Khi một luồng các gói tin đi đến một router có hỗ trợ diffserv, các router này sẽ phân loại gói tin và đánh dấu chúng. Trong bộ mô phỏng NS2 thì thành phần này được gọi là các “Policer”. Có 6 loại được sử dụng trong bộ mô phỏng NS2:
19 1. Time Sliding Window with 2 Color Marking (TSW2CMPolicer): Sử dụng giá trị CIR và 2 giá trị ưu tiên loại bỏ gói tin. Giá trị ưu tiên thấp hơn thì được sử dụng khi CIR vượt mức cho phép. 2. Time Sliding Window with 3 Color Marking (TSW3CMPolicer): Sử dụng 2 giá trị CIR, PIR và 3 giá trị ưu tiên loại bỏ. Giá trị ưu tiên loại bỏ gói tin cao nhất khi vượt quá PIR, giá trị ưu tiên loại bỏ trung bình khi CIR vượt mức cho phép. 3. Token Bucket (tokenBucketPolicer): Sử dụng 2 giá trị CIR, CBS và 2 giá trị ưu tiên loại bỏ gói tin. Một gói tin đến sẽ được đánh dấu giá trị ưu tiên lớn khi và chỉ khi kích thước gói tin lớn hơn token bucket. 4. Single Rate Three Color Marker (srTCMPolicer)[5]: Sử dụng CIR, CBS, EBS để chọn 3 thứ tự ưu tiên hủy gói tin. 5. Two Rate Three Color Marker (trTCMPolicer): Sử dụng CIR, CBS, PIR, PBS để chọn 3 thứ tự ưu tiên hủy gói tin. 6. NullPolicer: không có thứ tự ưu tiên hủy gói. Các gói tin sau khi đi qua các “Policer” này sẽ nhận được các giá trị ưu tiên “Drop Precedence”. Các giá trị này sẽ được mã hóa thành các CP (code point) và được ghi vào trong trường DS (Differentiated Services) của gói tin IP. Trong đó Các giá trị CIR và PIR được tính là bps, Các giá trị CBS, EBS, and PBS được tính theo byte. 1. CIR (committed information rate) – Tốc độ truyền tin cam kết 2. PIR (peak information rate) – Tốc độ truyền tin tối đa cam kết 3. CBS (committed burst size) – Kích thước bùng nổ cam kết 4. EBS (excess burst size) – Kích thước cụm vượt mức 5. PBS (peak burst size) – Kích thước cụm tối đa 6. C bucket: Kích thước hiện thời của khối dung lượng cho phép 7. E bucket: Kích thước hiện thời của khối dung lượng vượt mức 8. P bucket: Kích thước hiện thời của khối dung lượng tối đa
20 1.5.3. Các cơ chế lập lịch hàng đợi Trong bộ mô phỏng NS2 sử dụng các chế độ lập lịch RR, WRR, WIRR, PIR. Trong đó thì mặc định sử dụng bộ lập lịch RR. Các chế độ lập lịch sẽ được mô tả kỹ hơn trong chương 2 của luận văn. 1.6. Thách thức của việc truyền thông đa phương tiện trên Internet hiện nay 1.6.1. Hạn chế của việc truyền thông đa phương tiện hiện nay Hiện nay giao thức IP trên Internet cung cấp dịch vụ Best-Effort nghĩa là nó cố gắng chuyền các datagram từ nguồn tới đích 1 cách nhanh nhất có thể và không đảm bảo độ trễ và tỉ lệ mất mát gói tin. Các giao thức tầng transport là TCP hoặc UDP cũng không cung cấp các cơ chế đảm bảo về mặt độ trễ gói tin. Do vậy việc truyền thông đa phương tiện trên nên Internet truyền thống gặp rất nhiều trở ngại kìm hãm sự phát triển. Đối với các ứng dụng thời gian thực kèm theo tương tác đòi hỏi độ trễ và jitter cực thấp thì khi xảy ra tắc nghẽn chất lượng dịch vụ có thể tồi đến mức không thể chấp nhận được.  Tỉ lệ mất mát gói tin lớn khi mạng xảy ra tắc nghẽn  Đỗ trễ đầu cuối có thể tăng cao tới mức không thể chấp nhận được  Biến thiên độ trễ là không thể tránh khỏi khiến cho chất lượng âm thanh không chấp nhận được. 1.6.2. Các phương pháp đảm bảo chất lượng dịch vụ trên nền các dịch vụ cố gắng tối đa (best effort) Trong dịch vụ best-effort thì các gói tin được đối xử như nhau nghĩa là không có gói tin nào được ưu tiên hơn trong hàng đợi. Các gói tin khi đi tới router sẽ được đưa vào cuối hàng đợi và chờ đến lượt được phục vụ. Vẫn có 1 số cơ chế để cải thiện chất lượng dịch vụ cho các ứng dụng đa phương tiện trên nên best-effort dựa vào các giao thức tầng giao vận là TCP như: Slow-Start, Window-size hay có thể dừng chạy ở phía nhận khoảng 1 thời gian để loại bỏ các hiệu ứng biến thiên độ trễ. Có thể gửi kèm thông tin dư thừa để khắc phục tình trạng mất mát gói tin khi mạng xảy ra tắc nghẽn.
21 Chương 2. CÁC CHIẾN LƯỢC QUẢN LÝ HÀNG ĐỢI VÀ KHẢ NĂNG ÁP DỤNG ĐỂ ĐẢM BẢO QOS CHO TRUYỀN THÔNG ĐA PHƯƠNG TIỆN THỜI GIAN THỰC Trong mạng chuyển mạch ip thì các gói tin thuộc các luồng dữ liệu khác nhau được truyền trên cùng đường truyền để đến trạm đích. Để việc phân phối băng thông đường truyền đạt hiệu quả cao nhất thì cần một cơ chế phục vụ công bằng tại các nút mạng hoặc Router. Router ở đây sẽ phục vụ các gói tin của luồng đã chọn và quyết định gói tin nào sẽ được phục vụ tiếp theo. 2.1. Các chiến lược quản lý hàng đợi truyền thống 2.1.1. Hàng đợi FIFO (First in first out) FIFO là hàng đợi mặc định được sử dụng trong hầu hết các router. FIFO không có sự phân loại vì tất cả các gói đều thuộc về cùng một lớp. Các gói đến từ các luồng khác nhau được đối xử công bằng bằng cách đưa vào hàng đợi theo trật tự đến (gói nào đến trước sẽ được đưa vào trước và được phục vụ trước) theo đúng nghĩa First-Come-First- Serve (FCFS) hay First-In-First-Out (FIFO) Hình 2.1: Cơ chế phục vụ FIFO Hàng đợi FIFO sử dụng một hàng đợi đơn cho bộ giao tiếp. Vì chỉ có một hàng đợi nên không cần phân lớp để quyết định khi gói đi vào. Và cũng không cần lập lịch ban đầu để cho hàng đợi lấy gói tiếp theo. Ta chỉ quan tâm đến cách cấu hình chiều dài hàng đợi FIFO tránh tác động đến độ trễ và mất gói. FIFO thường được dùng trên các giao diện (interface) mạng tốc độ cao khó có khả năng xảy ra tắc nghẽn. Đây là một hạn góisGói tin đến Hàng đợi Gói tin đi Link
22 chế lớn của hàng đợi này vì trong mạng Internet ngày nay có rất nhiều gói tin có độ ưu tiên cao cần xử lý trước tuy nhiên cơ chế FIFO có thể loại bỏ các gói tin này khi hàng đợi đầy hoặc khi tắc nghẽn xảy ra thì sẽ làm gia tăng độ trễ tới mức không chấp nhận được. Đôi khi một luồng lưu lượng bùng nổ lớp sẽ độc chiếm đường truyền khiến cho các luồng khác không được phụ vụ gây bất công bằng giữa các luồng dữ liệu. 2.1.2. Chiến lược hàng đợi ưu tiên PQ ( Priority Queue ) Kĩ thuật này được sử dụng trong trường hợp đa hàng đợi, mỗi hàng đợi có một mức ưu tiên khác nhau, hàng đợi nào có mức ưu tiên cao nhất sẽ được ưu tiên phục vụ trước. Khi có tắc nghẽn xảy ra thì các gói trong các hàng đợi có độ ưu tiên thấp sẽ bị loại bỏ. Nói cách khác, lưu lượng quan trọng sẽ được gán các mức ưu tiên cao và lưu lượng có mức ưu tiên cao nhất được truyền trước, còn lại các lưu lượng ít quan trọng hơn. Hình 2.2: Cơ chế phục vụ hàng đợi ưu tiên PQ Các gói được phân loại dựa trên các tiêu chuẩn phân loại của người sử dụng, và được đặt ở một trong số các hàng đợi đầu ra với các độ ưu tiên: độ ưu tiên cao, trung bình, bình thường (không được ưu tiên), ưu tiên thấp. Các gói không được ấn định độ ưu tiên sẽ được đưa tới các hàng đợi bình thường. Khi các gói được gửi tới giao diện đầu ra, các hàng đợi ưu tiên tại giao diện đó được quét các gói theo thứ tự độ ưu tiên giảm dần. Hàng đợi có độ ưu tiên cao nhất được quét đầu tiên, sau đó đến các hàng đợi trung bình và tiếp tục các hàng đợi có độ ưu tiên khác. Gói đứng đầu hàng đợi có độ ưu góisGói tin đến Hàng đợi 1 Gói tin đi Link Hàng đợi 2 Phân loại
23 tiên cao nhất được truyền đầu tiên. Thủ tục này được lặp lại mỗi khi có một gói được truyền. Chiều dài lớn nhất của hàng đợi được định nghĩa theo chiều dài giới hạn. Khi một hàng đợi dài hơn chiều dài hàng đợi giới hạn thì các gói đến sau sẽ bị loại bỏ. PQ thường được dùng cho các interface băng thông thấp ở đó ta muốn gán mức ưu tiên tuyệt đối cho ứng dụng hay traffic trọng yếu. Mặc dù PQ là cách tiếp cận lập lịch đơn giản nhưng nó có thể gây thiếu hụt băng thông nghiêm trọng cho các luồng có độ ưu tiên thấp. PQ có thể dành hết băng thông cho các luồng có độ ưu tiên cao và dẫn tới việc các luồng có độ ưu tiên thấp không bao giờ được phục vụ. Hiện nay PQ thường được cấu hình tĩnh và không được tùy chỉnh theo sự thay đổi của mạng. 2.1.3. Chiến lược Packet-Based Round Robin Tương tự như chiến lược PQ đã trình bày ở phần trước. Chiến lược này cũng dựa vào việc phân loại các gói tin đến theo từng luồng khác nhau mỗi luồng được xếp vào một hàng đợi và được phục vụ lần lượt theo vòng. Tuy nhiên thay vì phục vụ theo mức ưu tiền thì PBRR lại phục vụ lần lượt quay vòng từng hàng đợi, mỗi hàng đợi chỉ phục vụ 1 gói tin. Nếu hàng đợi nào rỗng thì bộ lập lịch sẽ bỏ qua không phục vụ. Hình 2.3: Cơ chế phục vụ hàng đợi PBRR (Packet-Based Round Robin) góisGói tin đến Hàng đợi 1 Gói tin đi Link Hàng đợi 3 Phân loại Hàng đợi 2
24 Bộ lập lịch PBRR sẽ đối xử với các luồng dữ liệu giống nhau, nghĩa là không có mức độ ưu tiên dành cho các luồng có mức ưu tiên cao và nó cũng không quan tâm đến độ dài hàng đợi hiện tại khiến cho những luồng có hàng đợi dài chứa nhiều gói tin cũng chỉ được cấp cho một lượng băng thông giống như các luồng khác. Làm giảm hiệu suất sử dụng đường truyền. Không đáp ứng được băng thông cho các luồng dữ liệu multimedia. 2.1.4. Bộ lập lịch lý tưởng GPS - Generalized Processor Sharing Ý tưởng của GPS là trong mỗi khoảng thời gian hữu hạn phải thăm mỗi hàng đợi ít nhất một lần, phục vụ cho một lượng rất nhỏ dữ liệu từ mỗi hàng đợi. Khoảng thời gian và lượng dữ liệu này đủ nhỏ để có thể giả định rằng máy phục vụ (server) có thể phục vụ được tất cả các luồng có gói tin đang chờ một cách đồng thời và các luồng có thể được chia nhỏ tuỳ ý. Đây là một cơ chế lý tưởng vì nó đảm bảo sự phân chia công bằng nhất dành cho các luồng dữ liệu. Tuy nhiên việc cài đặt GPS trong thực tế là không thực hiện được vì trong 1 khoảng thời gian thì server chỉ có thể phục vụ 1 hàng đợi thay vì tất cả các hàng đợi của các luồng dữ liệu và độ dài kích thước gói tin là cố định không thế chia nhỏ tùy ý, gói tin này được phục vụ xong thì gói tin khác mới được phục vụ. Cài đặt đơn giản nhất của GPS là chiến lược Weighted Round Robin (WRR), thay vì thăm mỗi hàng đợi ít nhất một lần và phục vụ một lượng nhỏ dữ liệu tại hàng đợi như GPS thì WRR lại phục vụ một số gói tin tại từng hàng đợi, số gói tin được phục vụ tại từng hàng đợi phụ thuộc vào trong số “Weight” của hàng đợi đó. Trong kiến trúc DiffServ có thể phân biệt các hàng đợi này thông qua giá trị trường DS trong gói tin IP. Một biến thể của WRR là Weighted Interleaved Round Robin (WIRR) về cơ bản thì chiến lược này giống với WRR nhưng có thêm một cơ chế “Interleaved behavior”. Cơ chế này cho phép bộ lập lịch bỏ qua các hàng đợi không có gói tin một khoảng thời gian mà bộ lập lịch phải phục vụ hàng đợi đó. 2.1.5. Chiến lược Flow-Based Weighted Fair Queuing (WFQ) Các chiến lược đã nói trong phần trước đều dựa trên packet-base nghĩa là nó áp dụng cho từng gói tin theo đó mỗi lần phục vụ server sẽ chọn 1 gói tin theo mức độ ưu tiên của nó. Ưu điểm của chiến lược này nó đạt được mức độ công bằng cao cho các gói tin nhưng lại chứa nhiều điểm hạn chế: Thứ nhất là chi phí gán nhãn cho từng gói tin là
25 lớn và làm gia tăng độ phức tạp thuật toán và tiêu tốn tài nguyên của server. Thứ 2 là các gói tin của cùng 1 luồng sẽ không được phụ vụ cùng 1 lúc mà bị gián đoạn bởi các gói tin của các luồng khác, điều này không phù hợp với các ứng dụng truyền thông đa phương tiện thời gian thực trên Internet cần độ liền mạch các gói tin. Chính vì lẽ đó ta cần 1 cách tiếp cận hay 1 chiến lược khác là việc xác định và gán độ ưu tiên cho một luồng dữ liệu thay vì 1 gói tin riêng lẻ. Các gói tin trong cùng 1 luồng dữ liệu sẽ có cùng 1 độ ưu tiên và được phục vụ liên tục. Server sẽ phục vụ các luồng theo tứ tự ưu tiên hoặc trọng số, các gói tin trong cùng 1 luống sẽ được phục vụ theo cơ chế FIFO nghĩa là gói tin nào đến trước được phục vụ trước. Chiến lược này được gọi là Flow-Base Weighted Fair Queuing. Trong chiến lược WFQ này khi các gói tin tới hàng đợi sẽ được phân chia thành các luồng theo từng mức ưu tiên khác nhau. Mỗi luồng sẽ được xếp vào 1 hàng đợi riêng và nhận được 1 lượng phục vụ tùy theo trọng số của hàng đợi đó. Hình 2.4: Cơ chế WFQ Giả sử mỗi luồng i được gán 1 trọng số 𝑤𝑖. Trong khoảng thời gian phục vụ lớp i sẽ nhận được một lượng phục vụ là: 𝑤𝑖/ ∑ (𝑤𝑖)𝑛 𝑖−𝑛 tổng dung lượng đường truyền trong đó:  n là tổng số luồng có gói tin đang chờ  C là tổng dung lượng đường truyền góisGói tin đến Hàng đợi 1 Gói tin đi Link Hàng đợi 3 Phân loại Hàng đợi 2 𝑤1 𝑤2 𝑤3
26  Luồng i sẽ nhận được 𝐶 ∗ ( 𝑤 𝑖 ∑ (𝑤 𝑖)𝑛 𝑖−𝑛 ) băng thông mỗi lần phục vụ Có nhiều cách xác định trọng số cho từng luồng WFQ, một trong những cách được sử dụng phổ biến nhất là sử dụng các bit ưu tiên (IP precedence bits) của trường TOS (Type of Services) trong header packet ipv4. Đó là 3 bit bên trái nhất của trường TOS. Tổ hợp của 3 bit này tạo nên 6 mức ưu tiên từ 0 – 5, các mức 7, 8 được dành riêng và không được phép sử dụng. Như vậy dựa vào các bit trên ta có thể phân chia thành 6 luồng khác nhau với các mức ưu tiên. Giả sử chúng ta có 6 luồng với 6 mức ưu tiên khác nhau (IP precedence = 0 ÷ 5), mỗi luồng sẽ chiếm 1 lượng băng thông đường truyền là (IP precedence + 1)/(tổng dung lượng đường truyền). Tổng dung lượng đường truyền là: 1 + 2 +3 + 4 + 5 + 6 = 21 Các luồng sẽ nhận được lần lượt là 1/21, 2/21, 3/21, 4/21, 5/21, 6/21 dung lượng đường truyền. Hình 2.5: IP Precedence bits Như vậy có thể thấy rằng WFQ thực hiện phân phối dải thông đường truyền một cách công bằng cho các luồng dữ liệu dựa vào mức ưu tiên của chúng. Có thể nó rằng WFQ đảm bảo được chất lượng dịch vụ có phân loại hay còn gọi là QoS mềm. Trên thực tế WFQ thường được dùng trong trường hợp mạng yêu cầu thời gian đáp ứng nhất quán khi tải nặng cũng như khi tải nhẹ trong khi băng thông không thay đổi. Nó đảm bảo cho Ipv4 header payload TOS Bytes 3 bits IP precedence bits
27 hàng đợi lúc nào cũng có băng thông và lượng dịch vụ dành cho mỗi luồng là có thể dự đoán trước được. WFQ còn có thể được kết hợp với giao thức đặt trước tài nguyên RSPV - Resource Reservation Protocol để cung cấp QoS cứng. 2.1.6. Chiến lược Class-Based Weighted Fair Queuing (CBQ) Không giống như WFQ, CBQ được thiết kế nhằm đảm bảo băng thông cho các lớp lưu lượng do người dùng đặt trước mà vẫn đảm bảo phân phối công bằng cho các luồng trong lớp đó. CBQ cung cấp nhiều hàng đợi riêng biệt, mỗi hàng đợi có thể phân chia thành nhiều lớp, các luồng này có thể được xác định dựa vào các tiêu chi như giao thức (FTP, HTTP, Telnet, SSh..) hoặc danh sách điều khiển truy cập (Access list). Các gói tin thỏa mãn các tiêu chí được xếp chung vào 1 lớp Class-Based Weighted Fair Queuing (CBQ) là cơ chế queuing được dùng để reserve (giành trước) một lượng bandwidth tối thiểu cho một loại lớp lưu lượng (traffic class) khi xảy ra nghẽn. Lệnh bandwidth trong policy-map sẽ được dùng để tính toán ra giá trị weight cho lớp đó. Công thức tính weight của mỗi lớp có liên quan đến bandwidth của interface, vì vậy việc cấu hình đúng bandwidth của interface (thỏa với tốc độ vật lý của đường link) là rất quan trọng. CBQ cho phép người quản trị mạng xác định chính xác lượng băng thông được cấp phát cho 1 luồng lưu lượng cụ thể dựa vào băng thông có sẵn mà WFQ không làm được – Tính trọng số ưu tiện dựa vào các bit trong trường ToS chứ không phải do người dùng đặt trước. Điều ngày giúp người quản trị có thể phân phối cho một lớp lưu lượng đặc biệt nào đó một lượng băng thông tối thiểu đủ để hoạt động Xét 1 ví dụ có một luồng thoại thời gian thực yêu cầu băng thăng tối thiểu bằng một nửa dung lượng đường truyền T1 (1.544Mbps). Nếu chỉ có 2 luồng dữ liệu ta hoàn toàn có thể sử dụng WFQ để phân phối. Tuy nhiên vấn để xảy ra khi có thêm nhiều luồng dữ liệu tham gia vào đường truyền khi đó đặc tính của WFQ sẽ phân phối giải thông công bằng cho các luồng, như vậy luồng thoại thời gian thực ban đầu sẽ không có đủ lượng băng thông yêu cầu là một nữa đường truyền T1. Khác với WFQ khi sử dụng
28 CBQ thì hoàn toàn có thể cấu hình dành 1 nửa đường truyền T1 cho luồng dữ liệu thoại thời gian thực này. Luồng này được đưa vào 1 lớp và có đủ băng thông để hoạt động, các luồng còn lại được xếp vào một lớp khác và chia sẻ một nửa băng thông còn lại. CBQ còn hỗ trợ chia sẻ băng thông giữa các lớp bằng cách sử dụng cấu trúc cây phân lớp, để hiểu rõ hơn chúng ta cùng xét ví dụ dưới đây. Tại mức cao nhất người quản trị chia sẻ đường truyền cho 3 người dùng khác nhau. Tại mức này từng người đùng sẽ chia sẻ băng thông họ nhận được cho các ứng dụng theo một tỉ lệ nào đó, quá trình lặp lại cho đến khi ứng dụng nhận được phần băng thông được cấp phát để truyền. Hình 2.6: Chia sẻ băng thông trong CBQ Trong quá trình hoạt động có những lớp không sử dụng hết băng thông được cấp phát, lượng băng thông này sẽ được chia sẻ cho các lớp còn lại, các lớp cùng cấp có thể mượn số băng thông này thông qua lớp cha của nó, lớp nào có ưu tiên cao hơn sẽ mượn được nhiều bằng thông hơn. CBQ đã được cài đặt trên linux bằng cách dùng thuật toán từ bộ mô phỏng NS2. Cài đặt ban đầu của CBQ là WRR (Weighted Round Robin), trong linux là DRR links Agency A 40% Agency B 30% Agency C 30% HTTP 20% FTP 10% POP3 10% TCP 10% IP 20% HTTP 20% SSH 10% RTP 10% FTP 10%
29 (Deficit Round Robin). Chính sách chia sẻ băng thông được sử dụng trong DRR như sau: Khi lớp A có độ ưu tiên cao hơn lớp B, cả 2 đang mượn băng thông từ lớp C thì A sẽ lấy phần băng thông nó cần sau đó phần băng thông còn lại sẽ dành cho B, nếu độ ưu tiên của lớp A và B bằng nhau thì 2 lớp sẽ cùng nhận được 1 lượng băng thông chia sẻ giống nhau. 2.2. CÁC CHIẾN LƯỢC QUẢN LÝ HÀNG ĐỢI ĐỘNG Trong lý thuyết hàng đợi người ta chứng minh được rằng thời gian trung bình mà các gói tin đi qua hàng đợi bao gồm thời gian các gói tin phải chờ trong hàng đợi cộng với thời gian chúng được phục vụ, tỉ lệ thuận với chiều dài hàng đợi, tỉ lệ nghịch với tốc độ gói tin đến hàng đợi trung bình. Mục tiêu chính của các chiến lược quản lý hàng đợi là giữ cho chiều dài hàng đợi trung bình đủ nhỏ và ổn định. Đảm bảo độ trễ trung bình của các gói tin không vượt quá ngưỡng cho phép đồng thời đạt được hệ số sử dụng đường truyền cao. Hai yêu cầu này là trái ngược nhau chính vì vậy cần có một sự thỏa hiệp. Để biểu diễn đại lượng này người ta đưa ra một đại lượng là “Công suất”, đó là tỉ lệ giữa thông lượng và độ trễ. Điểm tối ưu là điểm có hiệu suất cực đại. Trong chương này sẽ trình bày về các chiến lược quản lý hàng đợi động AQM và một số thuật toán tiêu biểu. Các chiến lược này nhằm đáp ứng các mục tiêu đã nêu phía trên. Trước khi tìm hiểu về các chiến lược quản lý hàng đợi động chúng ta hãy xem xét chiến lược quản lý hàng đợi truyền thống và các nhược điểm của nó. 2.2.1. Chiến lược quản lý hàng đợi truyền thống và hệ quả Các cách tiếp cận quản lý hàng đợi truyền thống đều dựa trên cơ chế FIFO như đã trình bày ở phần trước. Với các cơ chế này thì gói tin khi tới gateway hoặc router sẽ được xếp vào hàng đợi, khi hàng đợi đầy thì các gói tin tới sau sẽ bị loại bỏ. Các gói tin tới trước sẽ được phụ vụ trước và hàng đợi này được mô phỏng trong bộ mô phỏng NS2 với tên gọi “DropTail”. Do tính đơn giản và dễ cài đặt mà nó được sử dụng trong nhiều năm trên Internet tuy nhiên do sự phát triển mạnh mẽ của mạng Internet ngày nay nó xuất hiện nhiều nhược điểm mà nổi bật nhất là hai nhược điểm sau đây
30 a. Hiện tượng Global Synchronization Theo cơ chế FIFO, chúng ta nói rằng các luồng khác bị “Lock Out” tại một thời điểm khi xuất hiện một luồng lưu lượng bùng nổ khiến cho hàng đợi bị chiếm độc quyền, các gói tin của các luồng lưu lượng khác không được nhận vào vì hàng đợi đầy. Khi xảy ra hiện tượng lockout nếu các thực thể sử dụng giao thức TCP để truyền thì chúng sẽ bị TimeOUT. Theo thuật toán tránh tắc ngẽn của TCP chúng sẽ đồng loạt giảm cửa số phát, thực hiện rút lui theo hàm mũ làm cho lưu lượng trên mạng đồng loại giảm nhanh chóng gây lãng phí băng thông đường truyền, làm giảm hiệu suất sử dụng. Hiện tượng đồng loạt giảm lưu lượng đó được gọi là hiện tượng đồng bộ toàn cầu – Global synchronization. b. Hiện tượng hàng đợi đầy (Full Queue) Hàng đợi FIFO có thể thường xuyên nằm trong trạng thái đầy trong trong thời gian dài nếu có nhiều luồng lưu lượng, vì cơ chế FIFO chỉ loại bỏ gói tin khi hàng đợi đã đầy. Lưu lượng trên mạng thường xuyên có sử bùng nổ và các gói tin tới các node mạng thường theo cụm nên bộ đệm tại các node mạng phải đủ lớn để hấp thu các lưu lượng bùng nổ này. Nhược điểm của nó là khi tăng kích thước bộ đêm để hấp thu các lưu lượng bùng nổ đồng thời sẽ làm gia tăng độ trễ và thăng giáng độ trễ. Ưu tiên sẽ là lựa chọn một cơ chế quản lý hàng đợi tốt thay vì tăng kích thước hàng đợi tại node mạng. Ngoài “DropTail” còn có 2 phương pháp khác có thể được sử dụng là loại bỏ gói tin ngẫu nhiên “Random Drop” và loại bỏ gói tin ở đầu “Drop Front”. Tư tưởng của Random Drop là các router sẽ loại bỏ ngẫu nhiên các gói tin trong hàng đợi để dành chỗ cho các gói tin đến. Còn với phương pháp Drop Front thì router sẽ loại bỏ các gói tin ở đầu hàng đợi. Cả 2 phương pháp này đều có thể khắc phục được hiện tượng “Lock-out” nhưng không khắc phục được hiện tượng đầy hàng đợi (Full Queue). 2.2.2. Ưu điểm các chiến lược quản lý hàng đợi động Như đã nói ở trên thì các chiến lược quản lý hàng đợi truyền thống sẽ loại bỏ gói tin khi hàng đợi đầy, điều nay không hợp lý vì đôi khi hàng đợi đầy thì hiện tượng tắc nghẽn đã trở nên khó kiểm soát. Giải pháp hợp lý cho trường hợp này là loại bỏ gói tin
31 trước khi hàng đợi đầy khi đó các thực thể gửi và nhận sẽ nhận biết và phản ứng với tắc nghẽn ngay khi hiện tượng tắc nghẽn bắt đầu xảy ra. Đây chính là tư tưởng chính của các chiến lược quản lý hàng đợi động – Active Queues Managerment AQM. Điểm cần chú ý rằng các chiến lược quản lý hàng đợi động này chỉ có hiệu quả đối khi được gắn với các giao thức vận chuyển có cơ chế kiểm soát lưu lượng (Flow control) như TCP, và nó không có hiệu quả đối với các giao thức như UDP. Các chiến lược quản lý hàng đợi động sẽ đem lại những ưu điểm sau: a. Giảm độ trễ và giảm thăng giáng độ trễ Việc loại bỏ sớm các gói tin khi tắc nghẽn chưa xảy ra sẽ giữ kích thước hàng đợi ở mức trung bình đủ nhỏ và làm giảm độ trễ một cách đáng kể. Điều này vô cùng quan trọng với các ứng dụng thời gian thực như voice, video thời gian thực b. Làm giảm số lượng gói tin bị loại bỏ tại các node mạng Mạng Internet ngày nay sự bùng nổ lưu lượng các gói tin là không thể tránh khỏi. Với chiến lược quản lý hàng đợi truyền thống kích thước hàng đợi tăng rất nhanh khi lưu lượng bùng nổ, các gói tin bị loại bỏ sẽ tăng nhanh khi hàng đợi đầy. Việc sử dụng các chiến lược quản lý hàng đợi động sẽ giúp cho kích thước hàng đợi nằm trong một khoảng trung bình đủ nhỏ, hàng đợi sẽ hấp thu các thăng giáng lưu lượng dễ dàng hơn khiến cho số gói tin bị loại bỏ giảm, hệ số sử dụng đường truyền tăng, việc khôi phục các gói tin bị mất đơn lẻ cũng dễ dàng hơn với TCP. c. Tránh hiện tượng Lock-out Hiện tượng lock-out xảy ra khi hàng đợi đầy, gói tin khi đi tới node mạng sẽ không được xếp vào hàng đợi vì không còn chỗ trống. AQM sẽ đảm bảo cho hàng đợi luôn luôn có chỗ trống dành cho các gói tin tới do đó tránh được hiện tượng này. Chúng ta sẽ tiến hành nghiên cứu 1 số thuật toán quản lý hàng đợi động tiêu biểu như RED, A-RED và RIO.
32 2.2.3. Thuật toán RED trong chiến lược quản lý hàng đợi động a. Giới thiệu thuật toán RED Khi có dấu hiệu của tắc nghẽn xảy ra trong mạng, hàng đợi tài router đầy thì router bắt đầu loại bỏ các gói tin đến. Đối với các luồng lưu lượng TCP thì đây là tín hiệu thông báo tắc nghẽn xảy ra và báo hiệu các nguồn phát giảm lưu lượng để giảm bớt tắc nghẽn. Có hai vấn đề quan trọng cần giải quyết: Thứ nhất là đối với các luông TCP thì các gói tin bị loại bỏ sẽ được truyền lại, điều này làm tăng tải trong mạng đồng thời phát sinh thêm độ trễ. Thứ hai là hiện tượng đồng bộ toàn cầu đã nói ở phân trên. Năm 1993 hai nhà khoa học của phòng thí nghiệm Lawrence Berkeley thuộc đại học California, Mỹ là Sally Floyd và Van Jacobson đã đề xuất thuật toán quản lý hàng đợi động AQM – một trong những thuật toán quản lý hàng đợi đầu tiên là RED – Random Early Detection of congestion, Random Early Drop. Với như ưu điểm vượt trội so với các thuật toán quản lý hàng đợi truyền thống nên RED đã được triển khai rộng rãi trên mạng Internet. Việc phát hiện sớm tắc nghẽn và phản ứng lại để giữ đường truyền ổn định thường được thực hiện trên các gateway. Các thực thể nguồn cũng có thể làm điều này thông qua thời gian phục vụ ước lượng tại gateway, thông qua độ trễ end-to-end, qua sự thay đổi thông lượng hoặc số lượng các gói tin bị loại bỏ. Tuy nhiên khung nhìn của một kết nối cụ thể bị giới hạn bởi thời gian phát tin và số lượng dữ liệu phát, ngoài ra nó cũng không thể biết được gateway nào đang tắc nghẽn, không phân biệt được độ trễ lan truyền và độ trễ hàng đợi. Chỉ có các Gateway là có cái nhìn đúng đắn nhất về trạng thái của hàng đợi, sự chia sẻ đường truyển của các kết nối đi qua nó tại mọi thời điểm cũng như yêu cầu chất lượng dịch vụ của các dòng lưu lượng. Các RED gateway sẽ theo dõi độ dài trung bình của hàng đợi để dựa vào đó phán đoán sớm tắc nghẽn sắp xảy ra (chiều dài của hàng đợi vượt quá một ngưỡng được định trước) và phản ứng một cách thích hợp đối với các gói tin đến theo hai cách:  Loại bỏ các gói tin đến theo một xác suất nhất định được định trước nhằm gián tiếp thông báo cho nguồn về sự tắc nghẽn đồng thời giữ kích thước hàng đợi nằm trong một ngưỡng đủ nhỏ  Đánh dấu cờ “có tắc nghẽn” theo một xác suất nhất định vào trường ECN trong header của các gói tin để báo cho bên nguồn biết.
33 b. Tư tưởng và nguyên tắc thiết kế thuật toán Mục đích chính của các RED gateway là điều khiển kích thước hàng đợi nằm trong một vùng đủ nhỏ được định nghĩa trước và ổn định. Ngoài ra nó còn tránh hiện tượng Global-Synchronization và không chống lại các luồng có lưu lượng đột biến, Duy trì kích thước hàng đợi ngay cả khi không có sự hợp tác từ các giao thức tầng giao vận Để đạt được những mục tiêu trên RED gateway phải làm được các công việc sau: - Phát hiện sớm tắc nghẽn và giữ kích thước hàng đợi trung bình đủ nhỏ làm cho mạng hoạt động ở vùng có độ trễ thấp, thông lượng cao, trong khi vẫn cho phép hàng đợi giao động trong một miền nhất định để hấp thu các luồng có lưu lượng đột biến hoặc độ thăng giáng cao. RED gateway là nơi thích hợp nhất để phát hiện tắc nghẽn và cũng là nơi thích hợp nhất để quyết định chọn kết nối cụ thể nào để thông báo tắc nghẽn. - Thông báo tới nguồn phát về tắc nghẽn có thể xảy ra. Việc này được thực hiện bằng cách đánh dấu và thông báo cho nguồn phát giảm lưu lượn xuống. Thông thường RED gateway sẽ loại bỏ gói tin, tuy nhiên nếu tắc nghẽn được phát hiện sớm thì thay vì loại bỏ nó RED gateway sẽ có 2 lựa chọn là đánh dấu hoặc loại bỏ gói tin. Việc đánh dấu gói tin được thực hiện bằng cách đánh dấu vào trường ECN trong header của gói tin với một xác suất nhất định để báo hiệu cho nguồn giảm lưu lượng đưa vào mạng. - Mục tiêu quan trọng cần đạt được là tránh hiện tượng Global-synchronization và không chống lại các luồng có lưu lượng đột biến. Như đã trình bày ở các phần trước hiện tượng này xảy ra khi các thực thể phát đồng loại giảm kích thước cửa sổ phát làm lưu lượng giảm nhanh trong cùng một thời điểm. Các chiến lược như Droptail hoặc Random Drop rất nhạy cảm với các luồng lưu lượng đột biến tức là các hàng đợi tại gateway thường sẽ bị tràn khi các gói tin của luồng này tới. Để tránh hiện tượng này các RED gateway phải chọn các gói tin ngẫu nhiên tới để đánh dấu. Với phương pháp này xác suất đánh dấu một gói tin từ một kết nối cụ thể tỉ lệ với phần băng thông được chia sẻ cho kết nối đó tại gateway. - Một mục tiêu quan trọng nữa của RED gateway cần đạt được đó là giữ kích thước hàng đợi trung bình ngay cả khi không có sự hợp tác từ các thực thể nguồn phát (nguồn phát sử dụng giao thức UDP). Có thể thực hiện điều này bằng cách loại bỏ
34 gói tin khi kích thước trung bình của hàng đợi vượt qua ngưỡng trên thay vì đánh dấu nó. Phương pháp này là cần thiết trong trường hợp hầu hết các kết nối có khoảng thời gian phát nhỏ hơn thời gian đợi gói tin khứ hồi hoặc các thực thể nguồn không có các cơ chế kiểm soát lưu lượng để phản ứng với việc đánh dấu hay loại bỏ gói tin (như các luồng UDP) c. Giải thuật và các tham số cho thuật toán RED RED gateway tính kích thước hàng đợi trung bình bằng cách sử dụng bộ lọc thông thấp LPF (Low Pass Filter). Kích thước hàng đợi trung bình được so sánh với hai ngưỡng : Ngưỡng dưới 𝑚𝑖𝑛 𝑡ℎ và ngưỡng trên 𝑚𝑎𝑥𝑡ℎ. Khi kích thước hàng đợi trung bình nhỏ hơn ngưỡng dưới thì không gói tin nào bị đánh dấu hoặc loại bỏ, Khi kích thước hàng đợi trung bình nằm trong khoảng 𝑚𝑖𝑛 𝑡ℎ đến 𝑚𝑎𝑥𝑡ℎ thì RED gateway sẽ đánh dấu các gói tin đến với một xác suất 𝑝 𝑎. Trong đó 𝑝 𝑎 là một hàm theo kích thước hàng đợi trung bình avg. Xác suất đánh dấu một gói tin của một kết nối cụ thể tỉ lệ với phần băng thông chia sẻ của kết nối đó tại gateway. Giải thuật được mô tả trong giải mã sau: Hình 2.7: Giải thuật tổng quát cho RED gateway Như vậy giải thuật tại RED gateway được chia thành hai thuật toán tách biệt: Thuật toán tính kích thước hàng đợi trung bình quyết định mức độ bùng nổ cho phép trong hàng đợi tại gateway và Thuật toán tính xác suất đánh dấu quyết định mức độ thường xuyên đánh dấu gói tin của gateway. Giải thuật đánh dấu gói tin phải đảm bảo sao cho các gói tin đánh dấu tại những khoảng thời gian đều nhau để tránh hiện tượng đồng bộ toàn cầu trong khi vẫn giữ kích thước hàng đợi trunh bình ở một khoảng nhất định Giải thuật chi tiết được mô tả dưới đây: Với mỗi gói tin đến gateway Tính toán kích thước hàng đợi trung bình avg Nếu 𝑚𝑖𝑛 𝑡ℎ < kích thước hàng đợi trung bình avg < 𝑚𝑎𝑥𝑡ℎ Tính xác xuất 𝑝 𝑎 Với 𝑝 𝑎: Đánh dấu các gói tin đến Nếu 𝑚𝑎𝑥𝑡ℎ < kích thước hàng đợi trung bình avg Đánh dấu gói tin đến
35 Hình 2.8: Giải thuật RED chi tiết Khởi tạo: avg ← 0 count ← -1 for mỗi gói tin đến Tính kích thước hàng đợi trung bình avg: if hàng đợi không rỗng avg ← (1- 𝑤𝑞) avg + 𝑤𝑞*q else m ← f(time – q_time) avg ← (1-𝑤𝑞)m avg if 𝑚𝑖𝑛 𝑡ℎ≤ avg < 𝑚𝑎𝑥𝑡ℎ count ++ Tính xác suất 𝑝 𝑎: 𝑝 𝑎 ← 𝑚𝑎𝑥 𝑝 (agv – 𝑚𝑖𝑛 𝑡ℎ)/( 𝑚𝑎𝑥𝑡ℎ - 𝑚𝑖𝑛 𝑡ℎ) 𝑝 𝑎 ← 𝑝 𝑏 / (1 – count. 𝑝 𝑏) với xác suất 𝑝 𝑎: đánh dấu gói tin đến count ← 0 else if avg ≥ 𝑚𝑎𝑥𝑡ℎ đánh dấu gói tin đến count ← 0 else count ← -1 Khi Khi hàng đợi trở nên rỗng q_time ← time
36 Hình 2.9 Các tham số thuật toán RED Theo giải thuật, mỗi khi có một gói tin đi đến hàng đợi, RED gateway sẽ tính kích thước hàng đợi trung bình bằng bộ lọc: avg ← (1- 𝑤𝑞) avg + 𝑤𝑞*q trong đó : q là kích thước hàng đợi trung bình hiện thời; 𝑤𝑞 là trọng sô của hàng đợi và nhận giá trị trong khoảng 0..1. 𝑤𝑞 còn gọi là hệ số làm trơn và quyết định độ lớn và độ kéo dài cho phép của sự bùng nổ lưu lượng. Xác suất đánh dấu gói tin 𝑝 𝑎 tăng chậm khi số gói tin từ gói cuối cùng được đánh dấu count tăng lên. Điều này đảm bảo cho gateway không phải chờ quá lâu trước khi đánh dấu một gói tin. RED gateway đánh dấu tất cả các gói tin nếu như kích thước hàng đợi trung bình avg vượt quá 𝑚𝑎𝑥𝑡ℎ Thêm 1 tùy chọn trong RED để đảm bảo xác suất để một gói tin bị loại bỏ tỉ lệ với thông lượng tính bằng bit/s chứ không phải packet/s. Trong trường hợp này thì một gói tin lớn sẽ dễ bị loại bỏ hơn một gói tin có kích thước nhỏ. 𝑝 𝑏 = 𝑃𝑎𝑐𝑘𝑒𝑡𝑆𝑖𝑧𝑒 𝑀𝑎𝑥𝑃𝑎𝑐𝑘𝑒𝑡𝑆𝑖𝑧𝑒 ∗ 𝑚𝑎𝑥𝑝 ∗ 𝑎𝑣𝑔−𝑚𝑖𝑛 𝑡ℎ 𝑚𝑎𝑥 𝑡ℎ−𝑚𝑖𝑛 𝑡ℎ Các biến thay đổi: avg: kích thước hàng đợi trung bình q_time: thời gian hàng đợi bắt đầu rỗng count: số gói tin từ gói cuối cùng bị đánh dấu Các tham số cố định: 𝑤𝑞: trọng số hàng đợi 𝑚𝑖𝑛 𝑡ℎ: ngưỡng dưới của hàng đợi 𝑚𝑎𝑥𝑡ℎ: ngưỡng trên của hàng đợi 𝑚𝑎𝑥 𝑝: xác suất loại bỏ tối đa Các tham số khác: 𝑝 𝑎: xác suất đánh dấu gói tin hiện tại q: kích thước hàng đợi hiện tại time: thời gian hiện tại f(t): một hàm tuyến tính của thời gian t
37 Có bốn tham số cố định cần đặt trước trong thuật toán RED. Việc thiết lập các thuật toán này là rất quan trọng vì nó ảnh hưởng tới chất lượng cũng như hiệu suất thuật toán. Để mang lại hiệu quả cao nhất cho thuật toán chúng tôi sẽ trình bày song song hai cách thiết lập các tham số: Định tính và định lượng (bằng mô phỏng) để có thể chọn ra một bộ tham số hợp lý và đêm lại hiệu quả cao nhất. Tất cả mô phỏng trong luận văn này đều được thực hiện trên bộ mô phỏng NS-2. Các tham số đầu vào được tác giả trong [3] nghiên cứu rất kỹ bằng mô phỏng, sau khi lặp lại các mô phỏng đó và thấy rằng các kết quả đó là hoàn toàn chính xác. d. Trọng số hàng đợi 𝒘 𝒒 Kích thước hàng đợi trung bình trong thuật toán RED được RED gateway tính toán bằng cách sử dụng bộ lọc thông thấp. Sự gia tăng kích thước hàng đợi hiện tại do luồng lưu lượng bùng nổ hoặc sử tắc nghẽn ngắn hạn sẽ không ảnh hưởng tới kích thước hàng đợi kích thước hàng đợi trung bình: avg ← (1- 𝑤𝑞) avg + 𝑤𝑞*q trong đó trọng số hàng đợi 𝑤𝑞 đóng vai trò quyết định giá trị của avg. Nhìn vào công thức trên có thể thấy răng nếu 𝑤𝑞 quá lớn thì kích thước hàng đợi trung bình avg sẽ bám sát kích thước hàng đợi vào thời điểm hiện tại, khiến cho hàng đợi trống rất ít. RED gateway sẽ không thể hấp thu được các luồng có lưu lượng bùng nổ. Cận trên cho 𝒘 𝒒 Giả sử ban đầu hàng đợi rỗng (kích thước trung bình bằng 0), sau đó khi có các gói tin đến, số gói tin trong hàng đợi sẽ tăng từ 0 đến L (giả sử có L gói tin đi đến hàng đợi) lúc này kích thước hàng đợi trung bình sẽ được tính như sau: 𝑎𝑣𝑔 𝐿 = ∑ 𝑖𝑤𝑞(1 − 𝑤𝑞) 𝐿−𝑖𝐿 𝑖=1 =𝑤𝑞(1 − 𝑤𝑞) 𝐿 ∑ 𝑖( 1 1−𝑤 𝑞 )𝑖𝐿 𝑖=1 = L + 1 + (1−𝑤 𝑞) 𝐿−𝑖−1 𝑤 𝑞 Với ngưỡng 𝑚𝑖𝑛 𝑡ℎ cho trước và chúng ta muốn cho phép RED gateway hấp thu bùng nổ đến L gói tin thì kích thước hàng đợi trung bình 𝑎𝑣𝑔 𝐿 < 𝑚𝑖𝑛 𝑡ℎ L + 1 + (1−𝑤 𝑞) 𝐿−𝑖−1 𝑤 𝑞 < 𝑚𝑖𝑛 𝑡ℎ
38 Cận dưới cho 𝒘 𝒒 Thuật toán RED được thế kế sao cho RED gateway luôn giữ hàng đợi ở mức trung bình nằm dưới một ngưỡng nào đó. Tuy nhiên nếu giá trị 𝑤𝑞 được thiết lập quá thấp thì avg sẽ phản ứng rất chậm với sự thay đổi nhanh của hàng đợi thực khiến cho gateway không thế phát hiện được sự bắt đầu của tắc nghẽn. Theo các nghiên cứu và thực nghiệm về thuật toán RED người ta khuyến cáo 𝑤𝑞 ≥ 0.001. Tùy điều kiện của mạng thực tế có thể lựa chọn 𝑤𝑞 nằm trong khoảng (0.002,0.003). e. Xác suất loại bỏ gói tin 𝒎𝒂𝒙 𝒑 Số lượng gói tin bị loại bỏ tại RED gateway phụ thuộc vào giá trị của 𝑚𝑎𝑥 𝑝 và sẽ quyết định kích thước hàng đợi trung bình avg sẽ nằm trong khoảng nào giữa 𝑚𝑖𝑛 𝑡ℎ và 𝑚𝑎𝑥𝑡ℎ. Vì thế tùy từng yêu cầu của mạng trong thực tế mà chúng ta lựa chọn giá trị 𝑚𝑎𝑥 𝑝 phù hợp. Đối với mạng ít xảy ra tắc nghẽn thì nên thiết lập giá trị 𝑚𝑎𝑥 𝑝 nhỏ để tận dụng tối đa đường truyền và giảm số gói tin bị loại bỏ. Giá trị phù hợp ở đây thường là 𝑚𝑎𝑥 𝑝 = 0.02. Tuy nhiên đối với mạng hay xảy ra tắc nghẽn thì giá trị 𝑚𝑎𝑥 𝑝 thường được thiết lập lớn hơn. Giá trị thường được chọn là 𝑚𝑎𝑥 𝑝 = 0.1 f. Thiết lập ngưỡng 𝒎𝒊𝒏𝒕𝒉 và 𝒎𝒂𝒙𝒕𝒉 Để thiết lập được giá trị tối ưu cho 𝑚𝑖𝑛 𝑡ℎ và 𝑚𝑎𝑥𝑡ℎ cần xem xét tới rất nhiều yếu tố, trong đó có kích thước hàng đợi trung bình mong muốn avg. Giá trị 𝑚𝑖𝑛 𝑡ℎ và 𝑚𝑎𝑥𝑡ℎ cần phải thoải mãn các yêu cầu sau: - Để tận dụng tối đa đường truyền thì 𝑚𝑖𝑛 𝑡ℎ và 𝑚𝑎𝑥𝑡ℎ cần được thiết lập giá trị cao trong trường hợp lưu lượng trên mạng ít đột biến - Nếu lưu lượng trong mạng thường xuyên có đột biến thì 𝑚𝑖𝑛 𝑡ℎ và 𝑚𝑎𝑥𝑡ℎ cần được thiết lập giá trị nhỏ để có thể hấp thu các lưu lượng này. Tuy nhiên khi thiết lập giá trị nhỏ cho 𝑚𝑖𝑛 𝑡ℎ và 𝑚𝑎𝑥𝑡ℎ khiến cho hiệu suất sử dụng đường truyền thấp gây lãng phí dải thông, số gói tin bị loại bỏ không cần thiết sẽ cao hơn. Vì vậy cần cân bằng giữa việc tận dụng tối đa đường truyền và khả năng hấp thu lưu lượng bùng nổ sao cho hiệu suất sử dụng đường truyền là cao nhất.
39 - Khoảng giá trị 𝑚𝑖𝑛 𝑡ℎ và 𝑚𝑎𝑥𝑡ℎ ảnh hưởng tới biến thiên độ trễ, thông lượng và khả năng hấp thu các đột biến tạm thời tại hàng đợi. Để tránh hiện tượng đồng bộ toàn cầu thì không nên đề khoảng giá trị này quá nhỏ. Theo khuyến nghị thì nên thiết lập 𝑚𝑎𝑥𝑡ℎ gấp đôi giá trị 𝑚𝑖𝑛 𝑡ℎ 2.2.4. Thuật toán A-RED Điều khiển tắc nghẽn đầu cuối được sử dụng rộng rãi trong các mạng ngày này để ngăn chặn tắc nghẽn xảy ra. Tuy nhiên do lưu lượng dữ liệu đến các router dưới dạng luồng nên các router cần được cung cấp hàng đợi lớn để hấp thu các lưu lượng bùng nổ giúp duy trì việc sử dụng các kết nối. Khi tắc nghẽn xảy ra tại các router các gói tin sẽ bị gia tăng độ trễ hàng đợi. Do đó cần phải chọn lựa giữa hiệu suất sử dụng đường truyền cao (Kích thước hàng đợi lớn) hay độ trễ hàng đợi nhỏ (Kích thước hàng đợi nhỏ). Thuật toán quản lý hàng đợi RED thì tích cực hơn do sử dụng quá trình loại bỏ ngẫu nhiên bằng việc thay đổi kích thước hàng đợi trung bình. Mục tiêu chính của RED là phối hợp giữa kích thước hàng đợi trung bình và thông báo tắc nghẽn sớm để đạt được độ trễ hàng đợi trung bình thấp và thông lượng cao Chiến lược quản lý hàng đợi động bằng cách sử dụng thuật toán RED cho phép mạng đồng thời đạt được cả thông lượng cao và độ trễ thấp. Tuy nhiên RED có hai yếu điểm cơ bản cần phải được khắc phục. Thứ nhất là kích thước hàng đợi trung bình nhạy cảm với các cấp đội tắc nghẽn và các tham số đầu vào thiết lập trên router. Đối với mạng có sự thay đổi lớn về các cấp độ tắc nghẽn thì việc thiết lập một bộ tham số đầu vào cho RED gateway là khó. Độ trễ là một thành phần chính của QoS cấp phát cho người dùng, để đạt được độ trễ trung bình có thể đoán trước thì cần phải liên tục hiệu chỉnh các tham số đấu vào của thuật toán RED đáp ứng sự thay đổi liên tục của lưu lượng dữ liệu trên mạng. Điểm yếu thứ hai của RED là thông lượng cũng nhạy cảm với tải và các thông số đầu vào của RED. Thường thì khi kích thước hàng đợi trung bình avg lớn hơn 𝑚𝑎𝑥𝑡ℎ thì thuật toán RED không còn hiệu quả dẫn tới việc giảm đáng kể thông lượng và tăng tỷ lệ loại bỏ gói tin. Để tránh hiện tượng này thì cũng cần liên tục điều chỉnh các tham số đầu vào của thuật toán RED.
40 a. Giải thuật A-RED A-RED ra đời nhằm khắc phục hai nhược điểm của RED nguyên bản được đề xuất bởi Feng từ năm 1997[17]. Cấu trúc RED vẫn được giữ nguyên và chỉ hiệu chỉnh thông số 𝑚𝑎𝑥 𝑝 để duy trì kích thước hàng đợi trung bình trong khoảng 𝑚𝑖𝑛 𝑡ℎ đến 𝑚𝑎𝑥𝑡ℎ. Có nhiều phiên bản A-RED được đưa ra tuy nhiên trong giới hạn luận án này chúng tôi giới thiệu một phiên bản thuật toán A-RED trong đó người quản trị viên có thể lựa chọn chế độ tự động thiết lập các tham số đầu vào cho RED gateway dựa trên độ trễ mong muốn và kích thước miền hàng đợi trung bình mong muốn. Như vậy thuật toán A-RED này có thể tự động thiết lập tất cả các tham số đầu vào của thuật toán RED dựa trên kết quả mong muốn đạt được tránh trong những hạn chế lớn của RED 𝑚𝑎𝑥 𝑝 được hiểu chỉnh không chỉ cho kích thước hàng đợi trung bình nằm trong ngưỡng 𝑚𝑖𝑛 𝑡ℎ, 𝑚𝑎𝑥𝑡ℎ mà còn giữ kích thước hàng đợi trung bình nằm trong một dải cho phép nằm trong khoảng 𝑚𝑖𝑛 𝑡ℎ, 𝑚𝑎𝑥𝑡ℎ. Giá trị 𝑚𝑎𝑥 𝑝 được duy trì nằm trong khoảng từ 0.01 đên 0.5. Bằng mô phỏng có thể thấy rằng A-RED đạt được độ dài hàng đợi trung bình đích với một miền rộng các kịch bản, có nghĩa là nó giữ nguyên được những ưu điểm của RED. Điều này giúp quản trị viên dự đoán được độ trễ hàng đợi trung bình và hạn chế khả năng kích thước hàng đợi trung bình vượt quá ngưỡng 𝑚𝑎𝑥𝑡ℎ từ đó giảm tỉ lệ mất gói tin và sự thăng giáng độ trễ hàng đợi. b. Giải thuật và các tham số trong thuật toán A-RED Thuật toán A-RED cơ bản chia làm hai thuật toán chính la: Thuật toán RED và thuật toán hiệu chỉnh 𝑚𝑎𝑥 𝑝, 𝑚𝑖𝑛 𝑡ℎ, 𝑚𝑎𝑥𝑡ℎ. Sau đó 𝑚𝑎𝑥 𝑝 lại được dùng trong thuật toán RED. Thuật toán hiệu chỉnh 𝑚𝑎𝑥 𝑝 được trình bày như Hình 2.10:
41 Hình 2.10: Giải thuật tổng quát cho A-RED gateway Giới hạn trên của giá trị 𝑚𝑎𝑥 𝑝 = 0.5 có thể được chỉnh sửa theo cách cố gắn tối ưu RED để tốc độ loại bỏ gói tin nhỏ hơn 50% 2.2.5. Thuật toán RIO Giới thiệu chung Phần này chúng ta sẽ nghiên cứu về việc áp dụng các thuật toán quản lý hàng đợi động trong kiến trúc các dịch vụ phân loại Diffserv. Kiến trúc này được định nghĩa bời IETF nhằm cung cấp cho mạng IP sự đảm bảo chất lượng dịch vụ cho các lưu lượng khác nhau cùng chia sẻ kênh truyển chung. Bằng việc sử dụng cờ đánh dấu trong một số trường đặc biệt của gói tin IP để báo cho Router biết cách xử lý nào được áp dụng cho mỗi gói tin. Điển hình của thuật toán quản lý hàng đợi động được áp dụng cho kiến trúc mạng dịch vụ phân loại DiffServ là thuật toán A-RIO (Adaptive RED with IN and OUT). Thuật toán này là sự kết hợp của A-RED và thuật toán RIO được đề xuất bởi Julio Orozco, David Ros với mục đích chính bao gồm: - Áp dụng cho kiến trúc mạng DiffServ nhằm đảm bảo chất lượng dịch vụ cho các dịch vụ trong trường hợp nhiều luồng lưu lượng cùng chia sẻ một kênh truyền bằng việc sử dụng các bit trong trường TOS của gói tin ip. Every interval giây: if (avg > target and 𝑚𝑎𝑥 𝑝 ≤ 0.5) tăng 𝑚𝑎𝑥 𝑝: 𝑚𝑎𝑥 𝑝 = 𝑚𝑎𝑥 𝑝 + α; elseif (avg < target and 𝑚𝑎𝑥 𝑝 ≥ 0.01) giảm 𝑚𝑎𝑥 𝑝: 𝑚𝑎𝑥 𝑝 = 𝑚𝑎𝑥 𝑝 * β; Biến: avg: kích thước hàng đợi trung bình Các tham số cố định: interval: thời gian; 0.5 giây target: target for avg: [𝑚𝑖𝑛 𝑡ℎ + 0.4 * (𝑚𝑎𝑥𝑡ℎ – 𝑚𝑖𝑛 𝑡ℎ), 𝑚𝑖𝑛 𝑡ℎ + 0.6 * (𝑚𝑎𝑥𝑡ℎ – 𝑚𝑖𝑛 𝑡ℎ)] α: hệ số tăng; min(0.01, maxp / 4); β: hệ số giảm; 0.9
42 - Đơn giản hóa cấu hình cho Router bằng việc tính toán tự động để chuyển đổi các tham số đầu vào sang tham số routers. - Cố gắng giữ hàng đợi ở mức trung bình ổn định quanh một giá trị khi tải nặng không phụ thuộc vào hiện trạng lưu lượng a. Ý tưởng Thuật toán RIO Đối với các thuật toán như RED, A-RED router chỉ thực hiện tính toán hàng đợi trung bình sau đó tiến hành đánh dấu hoặc loại bỏ gói tin, các gói tin đều được đối xử bình đẳng với nhau và không có sự phân biệt ưu sự ưu tiên. Tuy nhiên trong thực tế hiện nay khi mà tốc độ phát triển mạnh của Internet khiến cho sự đa dạng trong dịch vụ cũng tăng. Người dùng hoàn toàn có thể yêu cầu nhà cung cấp để được sự ưu tiên cao hơn và chấp nhận trả chi phí lớn hơn. Nếu sử dụng thuật toán RED hoặc A-RED cho trường hợp này thì không thể giải quyết được bài toán, các luồng (ứng dụng) đã trả nhiều tiền hơn cũng chỉ được cung cấp 1 lượng dịch vụ như những luồng khác. Chính vì lẽ đó thuật toán RIO ra đời dựa trên sự cải tiến của thuật toán RED bằng cách phân chia các gói tin đến theo hai mức ưu tiên là “In” và “Out”. Việc gắn thẻ cho mỗi gói tin phụ thuộc vào thỏa thuận giữa khách hàng và nhà cung cấp dịch vụ theo đó, các gói tin có gắn thẻ “In” nghĩa là các gói tin này nằm trong dịch vụ đã được thỏa thuận trước, các gói tin có gắn thẻ “Out” có nghĩa là không nằm trong hồ sơ dịch vụ. Khi tắc nghẽn xảy ra các router sẽ ưu tiên loại bỏ các gói tin có gắn thẻ “Out” nhanh hơn. Tuy nhiên RIO không phân tách các luồng thành các lớp hoặc các hàng đợi khác nhau mà gộp tất cả chung vào một hàng đợi. RIO là viết tắt của RED with In/Out bit. Vì được cải tiến từ RED nên nó có đầy đủ các ưu điểm của RED như đạt thông lượng cao, hiệu suất sử dụng đường truyền lớn, độ trễ thấp, kích thước hàng đợi trung bình nhỏ ngoài ra nó còn phân biệt các gói tin theo hai mức ưu tiên là “In” và “Out”. Việc sử dụng bộ đôi thuật toán RED cho các gói tin “In” và “Out” với thiết lập thông số khác nhau khiến cho các gói tin “Out” bao giờ cũng bị loại bỏ sớm hơn khi tắc nghẽn xảy ra. b. Giải thuật Tương tự như RED nhưng RIO được thiết lập hai bộ tham số riêng biệt, một bộ dành cho các gói tin với thẻ “In” và một bộ tham số dành cho gói tin thẻ “Out”. Khi một
43 gói tin đi tới RIO gateway nó sẽ kiểm tra xem gói tin này có gắn thẻ “In” hay “Out” và tính toán hàng đợi trung bình tương ứng với các gói tin. Nếu gói tin đi tới có gắn cơ “In” thì RIO gateway sẽ tính avg_in, ngược lại nếu gói tin đi tới có gắn thẻ Out thì RIO gateway sẽ tính avg_total. Xác suất loại bỏ gói tin “In” phụ thuộc vào kích thước hàng đợi trung bình avg_in và xác suất loại bỏ gói tin “Out” phụ thuộc vào kích thước hàng đợi trung bình avg_total. Giải thuật được mô tả như Hình 2.11 dưới đây: Hình 2.11 Giải thuật RIO RIO gateway sẽ loại bỏ hầu hết các gói tin có gắn thẻ “Out” khi tắc nghẽn bắt đầu xảy ra và khi tắc nghẽn kéo dài sẽ loại bỏ toàn bộ các gói tin “Out”, Các gói tin “In” rất ít khi bị loại bỏ trừ trường hợp tắc nghẽn xảy ra do toàn bộ các gói tin “In”. Tuy nhiên với mạng được điều khiển tốt thì trường hợp này rất ít khi xảy ra và nếu xảy ra trường hợp đó thì mạng có thể coi là không chấp nhận được. Chưa có bất cứ chuẩn mực nào trong việc lựa chọn avg_total sao cho hợp lý. Nếu ta chọn avg_out dành cho các gói tin “Out” thì việc lựa chọn tham số cho hàng đợi trung For mỗi gói tin đến if nó là gói tin In tính kích thước trung bình hàng đợi In: avg_in; tính kích thước trung bình hàng đợi tổng avg_total; if nó là gói tin In if min_in < avg_in < max_in tính xác suất 𝑃𝑖𝑛; loại bỏ gói tin này với xác suất 𝑃𝑖𝑛; else if max_in < avg_in loại bỏ gói tin này. if nó là gói tin Out if min_out <avg_total < max_out tính xác suất 𝑃𝑜𝑢𝑡; loại bỏ gói tin này với xác suất 𝑃𝑜𝑢𝑡; else if max_out <avg_total loại bỏ gói tin này;
44 bình này rất khó và không có sự tương quan rõ ràng nào giữa các tham số dành cho gói in “In”. Việc sử dụng avg_total dành cho cả hai loại gói tin giúp cho RIO gateway có thể giữ được kích thước hàng đợi trung bình đủ nhỏ và đạt được thông thượng cao bất kể lưu lượng nào trộn lẫn vào. 2.2.6. Thuật toán A-RIO Đây là một mở rộng trực tiếp từ thuật toán A-RED và RIO. A-RIO đi theo cách tiếp cận của thuật toán A-RED, các thông số đầu vào của thuật toán được hiệu chỉnh online một cách tự động nhằm đạt được hiệu suất mong muốn đã đặt trước, có nhiều cách tiếp cận được đưa ra nhằm hiệu chỉnh các thông số thuật toán RED theo kết quả mong muốn đạt được, A-RED được chọn vì tính đơn giản trong cài đặt của nó. Giống như A-RED, A-RIO chỉ cần một tham số đầu vào là độ trễ mà người dùng mong muốn đạt được, A-RIO sẽ tự động ánh xạ sang tập các tham số đầu vào. Đặc trưng này rất có ý nghĩa đối với nhà cung cấp dịch vụ phân loại cấu hình router theo độ trễ - một độ đo QoS liên quan trực tiếp đến đặc tả dịch vụ và đặc tả yêu cầu người dùng, dễ hiểu hơn rất nhiều so với các tham số trìu tượng như các ngưỡng hàng đợi, xác suất loại bỏ gói tin hoặc trọng số trung bình. Do là mở rộng trực tiếp từ thuật toán A-RED nên A-RIO vẫn giữ được những ưu điểm và đặc trung của A-RED như:  Xác suất loại bỏ gói tin 𝑚𝑎𝑥 𝑝 chạy từ 0.01 đến 0.5  Ngưỡng dưới 𝑚𝑖𝑛 𝑡ℎ được tính theo độ trễ hàng đợi mong muốn (đích) 𝑑 𝑡 và dung lượng đường truyền C (packet/s) với cận dưới là 5 gói tin thì: 𝑚𝑖𝑛 𝑡ℎ = max(5, 𝑑 𝑡. 𝐶/2). Ngưỡng 𝑚𝑎𝑥𝑡ℎ luôn được tính cố định bằng 3. 𝑚𝑖𝑛 𝑡ℎ  𝑤𝑞 cũng được tính theo dung lượng đường truyền: 𝑤𝑞 = 1 − exp(−1/𝐶)  Nếu tải thay đổi một cách đột ngột thì kích thước hàng đợi trung bình có thể nằm ngoài khoảng mục tiêu, khi đó các tham số α, β được chọn cố định sao cho kích thước hàng đợi trung bình sẽ quay trở lại miền mục tiêu trong vòng 25 giây.
45  Hàm hiệu chỉnh 𝑚𝑎𝑥 𝑝 (𝑖) được tính theo luật AIMD (tăng theo cấp số cộng, giảm theo cấp số nhân) nhằm tránh sự thay đổi đột ngột của 𝑚𝑎𝑥 𝑝 (𝑖) dẫn tới sự dao động mạnh của kích thước hàng đợi. Trên đây là một số thuật toán quản lý hàng đợi động điển hình, ngoài ra còn nhiều thuật toán khác là biến thể từ các thuật toán trên nhưng không được đề cập trong nội dung luận văn, các thuật toán đều có ưu, nhược điểm riêng tùy vào từng trường hợp mạng cụ thể mà người ta có thể chọn chiến lược sao cho đạt được hiệu quả cao nhất. Chương tiếp theo sẽ trình bày mô phỏng để đánh giá các thuật toán quản lý hàng đợi động RED và FIFO truyền thống, áp dụng thuật toán RED trong kiến trúc mạng DiffServ nhằm đảm bảo chất lượng dịch vụ cho các ứng dụng đa phương tiện thời gian thực trên Internet.
46 Chương 3. ĐÁNH GIÁ HIỆU QUẢ ĐẢM BẢO QOS CHO TRUYỀN THÔNG ĐA PHƯƠNG TIỆN THỜI GIAN THỰC CỦA MỘT SỐ CHIẾN LƯỢC QUẢN LÝ HÀNG ĐỢI 3.1. Đánh giá bằng mô phỏng hiệu quả của thuật toán RED Các mô phỏng trong luận văn này được thực hiện trên bộ mô phỏng NS-2 đã được cộng đồng nghiên cứu và sử dụng rộng rãi đặc biệt là trong các trường đại học và các viện nghiên cứu. Sau đây là phần trình bày mô phỏng của tôi nhằm đánh giá và so sánh hiệu suất của thuật toán RED so với DropTail Hình 3.1: Cấu hình mạng mô phỏng DropTail & RED Mô phỏng đánh giá hiệu suất của thuật toán RED so với DropTail, mỗi loại tôi đưa ra 3 đồ thị biểu diễn đó là : Kích thước hàng đợi trung bình, thông lượng, và kích thước cửa sổ của mỗi kết nối TCP để tìm ra ưu nhược điểm của 2 giải thuật quản lý hàng đợi này. Mạng mô phỏng bao gồm 6 nút, các luồng tcp1, tcp2, tcp3 được gắn vào các nút 1, 2, 3. Luồng udp được gắn vào nút 4, đường truyền chia sẻ từ nút 0 đến nút 5, tại đây sử dụng hàng đợi RED hoặc DropTail, tất cả các kết nối đều là full-duplex và mặc định không lỗi.
47  Kết nối từ nút 0 đến nút 1, 2, 3 có băng thông 10Mbps, độ trễ 1ms.  Kết nối từ nút 0 đến nút 4 có băng thông 2Mbps, độ trễ 10ms.  Kết nối từ nút 0 đến nút 5 có băng thông 2Mbps, độ trễ 20ms. Sử dụng hàng đợi RED hoặc DropTail  Các thực thể gắn với 3 luồng TCP ở đây là giao thức FTP (ftp1, ftp2, ftp3). Kích thước các gói tin TCP được gửi đỉ là 1000byte với kích thước cửa sổ tối đa là 100 gói tin. Các thực thể này phát gói tin theo thời gian ngẫu nhiên trong khoảng từ 0 – 3s từ lúc bắt đầu chạy mô phỏng.  Thực thể gắn với luồng udp ở đây là nguồn phát CBR (Nguồn phát sinh lưu lượng không đổi có tốc độ phát là 2Mbps). Thực thể udp bắt đầu sinh lưu lượng vào khoảng 5 – 7s và từ 8 – 10s để tạo lưu lượng đột biến  Hàng đợi được đặt trên kết nối từ node 0 đến node 5 kích thước 100 gói tin. Toàn bộ mô phỏng được chạy trong khoảng thời gian 50s.  Các tham số được thiết lập cho RED như sau: minth = 5, maxth = 15, maxp = 0.1 và wq = 0.002. Sau khi chạy mô phỏng 2 thuật toán trên với cùng một kích bản mô phỏng chúng thu được kết quả: Chiến lược Số gói tin (packet) Kích thước hàng đợi trung bình (packet) Độ trễ hàng đợi trung bình (ms) Hệ số sử dụng đường truyền (%) DropTail 11944 73.00 389.33 95.55 RED 11728 8.00 42.67 93.82 Bảng 3.1: So sánh RED với DropTail
48 Hình 3.2: Mô phỏng DropTail Hình 3.3: Mô phỏng RED a) Kích thước hàng đợi trung bình a) Kích thước hàng đợi trung bình b) Kích thước cửa sổ b) Kích thước cửa sổ c) Thông lượng trung bình các kết nối c) Thông lượng trung bình các kết nối
49 Nhận xét về kết quả mô phỏng chiến lược DropTail: Nhìn đồ thị có thể thấy được rằng hiện tượng lockout xảy ra khi có lưu lượng đột vào khoảng thời gian từ 5 – 7s và từ 8 – 10s (Nguồn CBR sinh lưu lượng có tốc độ cao hơn dung lượng đường truyền tại nút 0) dẫn tới việc các kết nối TCP đồng loạt giảm kích thước cửa sổ phát, dẫn tới việc thông lượng của các kết nốt TCP giảm đột ngột về gần bằng 0. Ngay cả khi nguồn CBR đã ngừng hoạt động vào khoảng 10 - 12s thì thông lượng của các luồng TCP vẫn giảm về gần 0 do cơ chế rút lui theo hàm mũ của TCP trong khi đó thì hàng đợi vẫn đầy. DropTail đã không tránh khỏi hiện tượng Global Synchronization. Ngay cả khi nguồn CBR không hoạt động thì hiện tượng Global Synchronization vẫn xảy ra vào các khoảng thời gian 24s, 34s, 44s, khi các kết nối TCP cùng tăng kích thước cửa sổ phát đạt đến ngưỡng và đồng loạt giảm. Kích thước trung bình của hàng đợi luôn giữ ở mức rất cao. Nhận xét về kết quả mô phỏng chiến lược RED: Trong gian đoạn 12s đầu tiên khi có lưu lượng đột biến vào mạng thì các kết nối TCP giảm kích thước cửa sổ phát dẫn tới việc thông lượng của các kết nối này giảm tuy nhiên ngay sau đó chúng đã tăng kích thước cửa sổ phát và thông lượng cũng tăng ngay sau đó, kích thước hàng đợi có tăng nhưng nhanh chóng giảm và giữ ở mức ổn định. Trong khoản thời gian còn lại không có đột biến lưu lượng thì RED luôn duy trì kích thước hàng đợi trung bình trong 1 khoảng nhỏ trong khoảng từ 6 – 10 gói tin. Nhận xét: Nhìn chung có thể thấy rằng chiến lược DropTail không tránh được hiện tượng Global synchronization không hỗ trợ chia se băng thông công bằng giữa các kết nối nhất là khi có lưu lượng bùng nổ vào mạng thì không giữ được các kết nối đã có sẵn. RED tránh được hiện tượng lockout và Global synchronization. Việc giữ kích thước hàng đợi đủ nhỏ nên đạt được độ trễ hàng đợi nhỏ hơn nhiều lần so với DropTail trong khi vẫn giữ được hệ số sử dụng đường truyền cao. 3.2. Đánh giá bằng mô phỏng việc áp dụng kiến trúc mạng Diffserv có sử dụng RED Việc mô phỏng đảm bảo chất lượng dịch vụ cho các ứng dụng thời gian thực trên Internet dựa trên kiến trúc mạng DiffServ được thực hiện trên bộ mô phỏng NS2. Trong kết nối TCP việc mất mát một số gói tin thường ảnh hưởng nhiều tới hiệu năng của phiên
50 kết nối so với đa số các gói tin còn lại. Những gói tin này thường là những gói tin điều khiển thiết lập kết nối, điều khiển lưu lượng, kiểm soát lỗi. Ta gọi những gói tin này là những gói tin có độ ưu tiên cao. Việc đánh dấu các gói tin này và cung cấp chất lượng dịch vụ cao hơn trong kiến trúc DiffServ sẽ làm hiệu suất của TCP được cải thiện đáng kể. Tuy nhiên việc đánh dấu gói tin yêu cầu các thành phần lớp mạng biết về thông tin lớp vận chuyển. Mục đích của mô phỏng mà chúng tôi giới thiệu để chỉ ra rằng có thể đánh dấu ưu tiên các gói tin quan trọng mà không cần bất kỳ thông tin nào của lớp vận chuyển, vì vậy sẽ đơn giản hóa các việc thực hiện đánh dấu các gói tin TCP. Về phân loại dịch vụ thường có 3 mức ưu tiên được định nghĩa. Mức ưu tiên cao nhất thường được gọi là “in policy” hay Green packets, mức ưu tiên thấp hơn chia thành 2 mức là Yellow Packets và thấp nhất là Red packets hay “Out policy”. Thuật toán RED được sử dụng trong hàng đợi nhằm tránh tắc nghẽn còn trong kiến trúc mạng DiffServ thì thuật toán RED được sử dụng để loại bỏ các gói tin có đánh dấu “Out Policy” 3.2.1. Cấu hình mạng mô phỏng Chúng ta sẽ xem xét một topo mạng đơn giản để mô phỏng mạng DiffServ trong đó ký hiệu các router biên là EDGE1 và EDGE2, còn router lõi là Core, hàng đợi sử dụng giữa router biên và router core là hàng đợi MRED, Các thực thể gửi và nhận là UDP sender và UDP Rec. Nguồn phát là nguồn CBR (nguồn sinh lưu lượng với tốc độ không đổi), băng thông và độ trễ được mô tả đầy đủ trong Hình 3.4 Hàng đợi được sử dụng giữa các Router EDGE và các thực thể gửi, nhận là hàng đợi DropTail. Topo mạng này có một nút cổ chai tại hàng đợi từ router EDGE1 đến router CORE.
51 Hình 3.4: Topo mạng mô phỏng Mỗi node gửi sẽ được kết nối với node nhận tương ứng với lưu lượng được đánh dấu theo các tham số đã chỉ rõ. Có 3 node nguồn, mỗi node sẽ liên tục gửi các gói tin UDP tới các node đích (được ghi nhãn với số thứ tự tương ứng). Tổng tốc độ gửi của 3 node là (600,000bps*3)=1,800,000bps. Mô phỏng trên mạng LAN có tốc độ cao, độ trễ thấp và đường truyền đối xứng. Mô hình lưu lượng: Đảm bảo chất lượng dịch vụ cho node UDP Sender 0  Node UDP Sender 1 sẽ bắt đầu truyền từ 0.1s  Node UDP Sender 0 sẽ bắt đầu truyền từ 5.0s  Nodd UDP Sender 2 sẽ bắt đầu truyền từ 15.0s Hàng đợi MRED được xây dựng tại router EDGE1, do băng thông đường truyền giữa Router EDGE1 với router CORE chỉ có 1Mbps nên nhỏ hơn tổng tốc độ truyền của 3 Node nên ở đây sẽ xảy ra tắc nghẽn. Hàng đợi MRED tại đây sử dụng mode RIO-C và chia thành 3 hàng đợi vật lý, mỗi hàng đợi vật lý lại chia thành 3 hàng đợi ảo, các tham số hàng đợi là giống nhau. Mục đích của việc này không phải để tìm một bộ tham số tối ưu để đạt được hiệu năng cần thiết cho mô phỏng, thay vào đó ta sẽ thử nghiệm dựa trên các điều kiện tham số đầu vào để nghiên cứu ảnh hưởng của Kiến trúc Diffserv đến việc đảm bảo chất lượng dịch vụ cho các ứng dụng có dộ ưu tiên cao.
52 Có 3 mức ưu tiên được định nghĩa dựa trên chính sách Single Rate Three Color Marker (srTCMPolicer): Sử dụng các tham số CIR, CBS, EBS để phân loại và đánh dấu các gói tin thành “Green packets”, “Yellow packets”, “Red packets”. Gói tin được đánh dấu là Green khi chưa vượt qua ngưỡng CBS, được đánh dấu là Yellow khi vượt qua ngưỡng CBS nhưng chưa vượt qua ngưỡng EBS và được đánh dấu là Red khi vượt qua ngưỡng EBS. Mô phỏng dựa trên 3 hàng đợi vật lý, mỗi kết nối từ node nguồn đến node đích được gán trên một hàng đợi vật lý riêng. Chế độ lập lịch cho hàng đợi sử dụng trong mô phỏng là WIRR với các trọng số lần lượt là 6, 3, 1 cho hàng đợi 0, 1, 2. Kết quả mô phỏng đối với trường hợp tắc nghẽn thấp tại do tốc độ truyền của nguồn UDP Sender 0 thấp. Hình 3.5: So sánh thông lượng các kết nối UDP
53 Hình 3.6: So sánh kích thước hàng đợi trung bình Hình 3.7: So sánh độ trễ hàng đợi trung bình
54 Code Point Gói tin nhận Gói tin gửi Drop RED Drop All 9743 5889 689 3165 10 333 333 0 0 11 500 500 0 0 12 2542 2542 0 0 20 167 142 25 0 21 200 98 52 50 22 2258 1078 109 1071 30 174 174 0 0 31 200 200 0 0 32 3369 822 503 2077 Bảng 3.2: Thông kê gói tin Source Packet send Packet loss Lost rate (%) UDP Sender 0 3368 0 0 UDP Sender 1 2587 1289 49.7 UDP Sender 2 3666 2487 67.38 Bảng 3.3: Thống kê Từng kết nối
55 Kết quả mô phỏng 2: Thay đổi tốc độ truyền của UDP Sender 0 từ 600.000bps lên 1.000.000bps Hình 3.8: So sánh thông lược các kết nối UDP Hình 3.9: So sánh kích thước hàng đợi trung bình
56 Hình 3.11: So sánh độ trễ hàng đợi trung bình Thống kê các gói tin CP Gói tin nhận Gói tin gửi Drop RED Drop All 11993 6029 1027 4937 10 333 333 0 0 11 500 368 0 132 12 4792 2994 0 1798 20 167 140 27 0 21 200 99 68 33 22 2258 1072 108 1078 30 174 171 3 0 31 200 200 0 0 32 3369 652 821 1896 Bảng 3.4: Thông kê gói tin trường hợp tắc nghẽn nhiều
57 Source Packet send Packet loss Lost rate (%) UDP Sender 0 5601 1922 34.3 UDP Sender 1 2592 1296 50.0 UDP Sender 2 3627 2640 72.7 Bảng 3.5: Thống kê Từng kết nối Nhận xét về các kết quả mô phỏng được: Việc sử dụng bộ lập lịch WIRR để đảm bảo băng thông tối thiểu cho hàng đợi 0 khiến cho thông lượng kết nối UDP Sender 0 – UDP Rec 0 luôn giữ ở mức trung bình khoảng 600Bps, kết nối có kích thường hàng đợi trung bình và độ trễ hàng đợi rất thấp. Với việc thiết lập tốc độ truyển của UDP Sender 0 là 600.000bps ngang bằng với phần băng thông được chia sẻ của hàng đợi 0 (0.6Mbps) khiến cho kích thước hàng đợi trung bình gần như bằng 0, các packet sau khi tới hàng đợi được xử lý luôn. Sau khi thiết lập tốc độ truyền tăng cường lên 1Mbps thì tại hàng đợi 0 bắt đầu xảy ra tắc nghẽn do băng thông chia sẻ không đáp ứng kịp tốc độ truyền. Khi đó thuật toán RED trên hàng đợi bắt đầu có tác dụng. Việc áp dụng kiến trúc Diffserv để phân loại gói tin thành các mức ưu tiên loại bỏ khác nhau, hàng đợi RED bắt đầu loại bỏ các gói tin có độ ưu tiên thấp để giữ kích thước hàng đợi năm trong ngưỡng đã thiết lập và độ trễ hàng đợi thấp. Không có gói tin Green nào bị loại bỏ. Mô phỏng việc đánh dấu và đảm bảo chất lượng dịch vụ sử dụng kiến trúc DiffServ có thể chưa đem lại sự cải thiện đáng kể trong một vài trường hợp. Có thể thấy rằng việc DiffServ bảo vệ rất tốt các gói tin có ưu tiên cao (Green packets) thường được gọi là các goi tin nhạy cảm. Việc mất mát các gói tin này thường dẫn tới giảm hiệu suất đang kể của phiên kết nối. Trong một số trường hợp mất gói tin đồng bộ sẽ dẫn tới thời gian timeout 3s hoặc 6s đối với các kết nối TCP. Việc cam kết băng thông tối thiểu dành cho một người dùng cụ thể có thể thực hiện được bằng cách gán người dùng đó với một hàng đợi riêng biệt và cấp phát một lượng băng thông như đã cam kết cho hàng đợi đó. Như vậy ta có thể đạt được cả hai mục tiêu đó là vừa đảm bảo được băng thông tối thiểu cho người dùng đặt trước và vừa bảo vệ được luồng dữ liệu nhạy cảm khi tắc nghẽn xảy ra tại chính người dùng đó.
58 3.3. Kết luận và hướng nghiên cứu tiếp theo A. KẾT LUẬN RED là một trong những thuật toán AQM đầu tiên và được nghiên cứu rất nhiều trên thế giới, hầu hết các nghiên cứu đó đều công nhận hiệu quả của nó đạt được. tuy nhiên nó vẫn có những nhược điểm cố hữu là nhạy cảm với các tham số đầu vào và điều kiện của mạng. Ngoài ra RED không đảm bảo được sự công bằng cho các luồng dữ liệu khác nhau. Mục tiêu chính của RED là giữ hàng đợi trung bình đủ nhỏ trong một miền định trước nhằm hấp thu đột biến tức thời giúp mạng đạt được thông lượng cao và độ trễ thấp. Các thuật toán A-RED, RIO, A-RIO ra đời nhằm khắc phục các nhược điểm của RED với việc đơn giản hóa các tham số đầu vào và cố gắng đạt được sự công bằng cho một lớp lưu lượng riêng. Kiến trúc mạng IntServ ra đời nhằm đảm bảo chất lượng dịch vụ cho một lớp lưu lượng đặt trước bằng cách đặt trước tài nguyên từ nguồn tới đích tuy nhiên lại có nhiều nhược điểm như khả năng mở rộng kém trong mạng lõi, chi phí cao, cài đặt phức tạp. Kiến trúc mạng DiffServ được phát triển với những ưu điểm trái ngược với kiến trúc IntServ, với việc phân loại gói tin thành các mức độ ưu tiên khác nhau và áp dụng những chính sách khác nhau cho từng mức ưu tiên đó khiến cho DiffServ đạt được tính linh động rất tốt, dễ cài đặt và mở rộng. Việc áp dụng chiến lược RED trong mô hình kiến trúc mạng DiffServ giúp người quản trị có thể vừa đạt được công bằng cho các luồng dữ liệu, bảo vệ các luồng dữ liệu nhạy cảm vừa đạt được thông lượng và độ trễ cao nhờ thuật toán RIO. B. HƯỚNG NGHIÊN CỨU TIẾP THEO. Chúng tôi sẽ tiếp tục nghiên cứu sâu hơn về kiến trúc mạng DiffServ cụ thể là: Ảnh hưởng của việc thay đổi thuật toán lập lịch giữa các hàng đợi trong kiến trúc mạng DiffServ. Ảnh hưởng của các lưu lượng cũng như các gói tin khác nhau đến hiệu năng của thuật toán RIO.
59 TÀI LIỆU THAM KHẢO 1. Nguyễn Đức Thắng, Nguyễn Ngọc Chân, Trần Công Hùng, Giải pháp đảm bảo chất lượng dịch vụ (QoS) cho mạng lõi. 2. Nguyễn Thị Thu Huyền, Đồ án: Nghiên cứu về QoS và định hướng phát triển mạng viễn thông Việt Nam 3. Vũ Duy Lợi, Nguyễn Đình Việt, Ngô Thị Duyên, Lê Thị Hợi (2004), “Đánh giá hiệu suất chiến lược quản lý hàng đợi RED bằng bộ mô phỏng NS”, Kỷ yếu Hội thảo Khoa học Quốc gia lần thứ hai về Nghiên cứu, Phát triển và Ứng dụng Công nghệ Thông tin và Truyền thông (ICT.rda'04), (Hà nội, 2425/9/2004). NXB Khoa học và Kỹ thuật, Hà Nội, 5/2005, trang 394-403. 4. Lê Đình Danh(2007), Luận văn cao học: Thuật toán quản lý hàng đợi A-RIO 5. Sally Floyd and Van Jacobson, “Random Early Detection Gateways for Congestion Avoidance” Lawrence Berkeley Laboratory University of California 6. Eitan Altman, Tania Jimenez, “NS Simulator for Beginners” 7. RFC: 2474, 2475, 2597, 2598, 3260, 2697 8. Luigi Alcuri, Francesco Saitta , Telephony Over IP: A QoS Measurement-Based End to End Control Algorithm and a Queue Schedulers Comparison 9. D. Stiliadis, A. Varma (1998), “Efficient Fair Queuing Algorithms for PacketSwitched Networks”, IEEE Trans. Networking, Vol. 6, No. 2, pp. 175-185 10. David D.Clark, Wenjia Fang (1998), “Explixit Allocation of Best Effort Packet Delivery Service”, Labratory for Computer Sciences Computer Science Department, Massachusetts Institute of Technology Princeton University A. Demers, S. Keshav and S. Shenkar (1989), “Analysis and Simulation of a Fair Queuing Algorithms” 11. Ns2 Document, http://www.isi.edu/nsnam/ns/doc/ 12. Luigi Alcuri, Francesco Saitta, “Telephony Over IP: A QoS Measurement-Based End to End Control Algorithm and a Queue Schedulers Comparison” Viale delle Scienze 9, 90128 Palermo Italy 13. Jia-Shiang Jou, Xiaobo Tan and John S. Baras, “A Parallel Virtual Queue Structure for Active Queue Management” Department of Electrical and Computer
60 Engineering and Institute for Systems Research University of Maryland, College Park, MD 20742 USA 14. Mikko Vanhala, “Differentiated Services – architecture” 44368D Teknillinen korkeakoulu Teletekniikan laboratorio 15. Oyetunji M.O, Oladeji F.A Emuoyinbofarhe O.J, “Performance Evaluation of Traffic Meters: Token Bucket Marker and Two Rate Three Color Marker (trTCM) QoS Admission Control” 16. Rong Pan, “Active Queue Management” Cisco System EE384y Spring Quarter 2006 17. W. Feng, D. Kandlur, D. Saha, and K. G. Shin (1999), “A Self-Configuring RED Gateway”, In Proceedings of IEEE INFOCOM, pages 1320-1328. 18. Andrew s. Tanenbaum, The Netherlands Computer networks fifth edition, Vrije Universiteit Amsterdam, The Netherlands

More Related Content

PDF
Đề tài: Xây dựng Website quản lý điểm trường Phổ thông, 9đ
byDịch vụ viết bài trọn gói ZALO: 0909232620
 
PDF
KẾT CẤU PHÓNG SỰ NGẮN TRUYỀN HÌNH - TẢI FREE ZALO: 093 457 3149
byDịch vụ viết bài trọn gói ZALO: 0936 885 877
 
PDF
Ky thuat-truyen-so-lieu
byNguyen Vong
 
DOCX
Đề cương ôn tập Kinh Tế Viễn Thông
byHuynh MVT
 
PPTX
Slide Bao Cao Thuc Tap
bythanhhauuit
 
DOCX
Xây dựng ứng dụng hỗ trợ học tiếng anh trên thiết bị android
byTrần Võ Khôi Nguyên
 
DOC
Hướng dẫn sử dụng phần mềm packet tracer
byBình Tân Phú
 
PPTX
Các loại mã đường truyền và ứng dụng neptune
by給与 クレジット
 
Đề tài: Xây dựng Website quản lý điểm trường Phổ thông, 9đ
byDịch vụ viết bài trọn gói ZALO: 0909232620
 
KẾT CẤU PHÓNG SỰ NGẮN TRUYỀN HÌNH - TẢI FREE ZALO: 093 457 3149
byDịch vụ viết bài trọn gói ZALO: 0936 885 877
 
Ky thuat-truyen-so-lieu
byNguyen Vong
 
Đề cương ôn tập Kinh Tế Viễn Thông
byHuynh MVT
 
Slide Bao Cao Thuc Tap
bythanhhauuit
 
Xây dựng ứng dụng hỗ trợ học tiếng anh trên thiết bị android
byTrần Võ Khôi Nguyên
 
Hướng dẫn sử dụng phần mềm packet tracer
byBình Tân Phú
 
Các loại mã đường truyền và ứng dụng neptune
by給与 クレジット
 

What's hot

PDF
Bài giảng công nghệ phần mềm PTIT
byNguynMinh294
 
PDF
đồ áN xây dựng website bán laptop 1129155
bynataliej4
 
PDF
Đề tài: Xây dựng phần mềm quản lý quán cà phê, HOT, 9đ
byDịch vụ viết bài trọn gói ZALO 0917193864
 
PDF
Đề tài: Mô hình giáo dục Kỹ năng mềm cho sinh viên ĐH, HAY
byDịch vụ viết bài trọn gói ZALO: 0909232620
 
PDF
Giáo trình mạng máy tính PTIT
byNguynMinh294
 
DOCX
[Báo cáo] Bài tập lớn Kỹ thuật phần mềm ứng dụng: Thiết kế hệ thống quản lý p...
byThe Nguyen Manh
 
DOCX
Đồ án chương trình quản lý website du lịch
bywem81315
 
PDF
Giáo trình xử lý ảnh
byTùng Trần
 
DOC
De thi qlda cntt itc vdc trac nghiem 05-2006
byTran Tien
 
PDF
Ptit mô phỏng hệ thống truyền thông slide
byLinh Linpine
 
DOC
Đề tài: Xây dựng website bán hàng trực tuyến, HAY
byDịch vụ viết thuê Khóa Luận - ZALO 0932091562
 
PDF
Xử lý tín hiệu số
byKhôi Nguyễn Đăng
 
PDF
Văn chính luận Hồ Chí Minh từ góc nhìn phân tích diễn ngôn, HAY
byDịch vụ viết bài trọn gói ZALO 0917193864
 
PDF
Mang va cac cong nghe truy nhap
byvanliemtb
 
PDF
cau-hoi-trac-nghiem-thong-tin-di-dong
byHuynh MVT
 
PDF
Tổng hợp 35 câu hỏi phần triết học kèm trả lời
byVan-Duyet Le
 
DOCX
200 đề tài luận văn ngành ngôn ngữ trung quốc. HAY
byDịch vụ viết thuê Khóa Luận - ZALO 0932091562
 
DOCX
Báo cáo đồ án môn công nghệ phần mềm
byRiTa15
 
PDF
NGHIÊN CỨU KHOA HỌC
byTrang Dai Phan Thi
 
PPTX
Mã đường truyền
byToản Lê Văn
 
Bài giảng công nghệ phần mềm PTIT
byNguynMinh294
 
đồ áN xây dựng website bán laptop 1129155
bynataliej4
 
Đề tài: Xây dựng phần mềm quản lý quán cà phê, HOT, 9đ
byDịch vụ viết bài trọn gói ZALO 0917193864
 
Đề tài: Mô hình giáo dục Kỹ năng mềm cho sinh viên ĐH, HAY
byDịch vụ viết bài trọn gói ZALO: 0909232620
 
Giáo trình mạng máy tính PTIT
byNguynMinh294
 
[Báo cáo] Bài tập lớn Kỹ thuật phần mềm ứng dụng: Thiết kế hệ thống quản lý p...
byThe Nguyen Manh
 
Đồ án chương trình quản lý website du lịch
bywem81315
 
Giáo trình xử lý ảnh
byTùng Trần
 
De thi qlda cntt itc vdc trac nghiem 05-2006
byTran Tien
 
Ptit mô phỏng hệ thống truyền thông slide
byLinh Linpine
 
Đề tài: Xây dựng website bán hàng trực tuyến, HAY
byDịch vụ viết thuê Khóa Luận - ZALO 0932091562
 
Xử lý tín hiệu số
byKhôi Nguyễn Đăng
 
Văn chính luận Hồ Chí Minh từ góc nhìn phân tích diễn ngôn, HAY
byDịch vụ viết bài trọn gói ZALO 0917193864
 
Mang va cac cong nghe truy nhap
byvanliemtb
 
cau-hoi-trac-nghiem-thong-tin-di-dong
byHuynh MVT
 
Tổng hợp 35 câu hỏi phần triết học kèm trả lời
byVan-Duyet Le
 
200 đề tài luận văn ngành ngôn ngữ trung quốc. HAY
byDịch vụ viết thuê Khóa Luận - ZALO 0932091562
 
Báo cáo đồ án môn công nghệ phần mềm
byRiTa15
 
NGHIÊN CỨU KHOA HỌC
byTrang Dai Phan Thi
 
Mã đường truyền
byToản Lê Văn
 

Similar to Luận văn: Chất lượng dịch vụ cho truyền thông đa phương tiện, 9đ

PDF
Kế hoạch quản lý hàng đợi động cho truyền thông đa phương tiện
byDịch vụ viết bài trọn gói ZALO 0917193864
 
PDF
Luận án: Nâng cao hiệu năng mạng MANET sử dụng kỹ thuật định tuyến cân bằng t...
byDịch vụ viết thuê Khóa Luận - ZALO 0932091562
 
PDF
Network Programming in C#
byjvinhit
 
PDF
Quản lý hàng đợi động Blue cho truyền thông đa phương tiện, 9đ
byDịch vụ viết bài trọn gói ZALO 0917193864
 
PDF
Luận văn: Quản trị mạng tập trung trên nền WEB sử dụng công nghệ SNMP, CGI và...
byDịch Vụ Viết Thuê Khóa Luận Zalo/Telegram 0917193864
 
PDF
lap-trinh-mang-voi-c#
byTruong NGUYEN
 
DOC
Thiết kế hệ thống mạng tại bưu điện tỉnh quảng ngãi
byHate To Love
 
PDF
Lap trinhmang(socket)c#
bycozyhome0923
 
PDF
Bai giang lap trinhmang voi c#
bynttrang9090
 
PDF
Tailieu.vncty.com van de-chat_luong_dich_vu_trong_mang_the_he_moi_va_trien_...
byTrần Đức Anh
 
PDF
Luận văn Nghiên cứu chất lượng dịch vụ và quản lý băng thông cho mạng men đa ...
bydethiorg
 
PDF
Luận văn thạc sĩ Quản lý QoS và QoE trong IPTV
bylop1eduvn
 
DOCX
cau hoi on tap mang NGN trong viễn thông.docx
byTrnhHa3
 
PDF
Luận văn: Kế hoạch quản lý hàng đợi động cho truyền thông, HAY
byDịch Vụ Viết Bài Trọn Gói ZALO 0917193864
 
PDF
Nâng cao hiệu năng mạng Manet bằng kỹ thuật định tuyến cân bằng tải - Gửi miễ...
byDịch vụ viết bài trọn gói ZALO: 0909232620
 
PDF
Lvch k20 t-dinhthithu-tomtat
byVAN QUY DO
 
PDF
Luận văn: Chất lượng dịch vụ cho giải pháp thoại trên Internet, 9đ
byDịch vụ viết bài trọn gói ZALO: 0909232620
 
PDF
Slideshare.vn luan van_giai_phap_dam_bao_chat_luong_dich_vu_qos_tren_mang_ipa...
byQuân Quân
 
PDF
Tailieu.vncty.com tim hieu-ve_mang_khong_day_va_phat_trien_dich_vu_tren_man...
byTrần Đức Anh
 
DOC
Tailieu.vncty.com bao cao xay dung he thong thong tin mang
byTrần Đức Anh
 
Kế hoạch quản lý hàng đợi động cho truyền thông đa phương tiện
byDịch vụ viết bài trọn gói ZALO 0917193864
 
Luận án: Nâng cao hiệu năng mạng MANET sử dụng kỹ thuật định tuyến cân bằng t...
byDịch vụ viết thuê Khóa Luận - ZALO 0932091562
 
Network Programming in C#
byjvinhit
 
Quản lý hàng đợi động Blue cho truyền thông đa phương tiện, 9đ
byDịch vụ viết bài trọn gói ZALO 0917193864
 
Luận văn: Quản trị mạng tập trung trên nền WEB sử dụng công nghệ SNMP, CGI và...
byDịch Vụ Viết Thuê Khóa Luận Zalo/Telegram 0917193864
 
lap-trinh-mang-voi-c#
byTruong NGUYEN
 
Thiết kế hệ thống mạng tại bưu điện tỉnh quảng ngãi
byHate To Love
 
Lap trinhmang(socket)c#
bycozyhome0923
 
Bai giang lap trinhmang voi c#
bynttrang9090
 
Tailieu.vncty.com van de-chat_luong_dich_vu_trong_mang_the_he_moi_va_trien_...
byTrần Đức Anh
 
Luận văn Nghiên cứu chất lượng dịch vụ và quản lý băng thông cho mạng men đa ...
bydethiorg
 
Luận văn thạc sĩ Quản lý QoS và QoE trong IPTV
bylop1eduvn
 
cau hoi on tap mang NGN trong viễn thông.docx
byTrnhHa3
 
Luận văn: Kế hoạch quản lý hàng đợi động cho truyền thông, HAY
byDịch Vụ Viết Bài Trọn Gói ZALO 0917193864
 
Nâng cao hiệu năng mạng Manet bằng kỹ thuật định tuyến cân bằng tải - Gửi miễ...
byDịch vụ viết bài trọn gói ZALO: 0909232620
 
Lvch k20 t-dinhthithu-tomtat
byVAN QUY DO
 
Luận văn: Chất lượng dịch vụ cho giải pháp thoại trên Internet, 9đ
byDịch vụ viết bài trọn gói ZALO: 0909232620
 
Slideshare.vn luan van_giai_phap_dam_bao_chat_luong_dich_vu_qos_tren_mang_ipa...
byQuân Quân
 
Tailieu.vncty.com tim hieu-ve_mang_khong_day_va_phat_trien_dich_vu_tren_man...
byTrần Đức Anh
 
Tailieu.vncty.com bao cao xay dung he thong thong tin mang
byTrần Đức Anh
 

More from Dịch vụ viết bài trọn gói ZALO 0917193864

DOCX
Kho 200 đề tài luận văn tốt nghiệp ngành điện tử viễn thông, 9 điểm
byDịch vụ viết bài trọn gói ZALO 0917193864
 
DOCX
Kho 200 Đề Tài Luận Văn Tốt Nghiệp Ngành Giáo Dục Tiểu Học
byDịch vụ viết bài trọn gói ZALO 0917193864
 
DOCX
Kho 200 Đề Tài Luận Văn Tốt Nghiệp Ngành Sư Phạm Tin Học
byDịch vụ viết bài trọn gói ZALO 0917193864
 
DOCX
Danh sách 200 đề tài luận văn thạc sĩ ngữ văn, hay nhất
byDịch vụ viết bài trọn gói ZALO 0917193864
 
DOCX
Kho 200 đề tài luận văn tốt nghiệp ngành luật, hay nhất
byDịch vụ viết bài trọn gói ZALO 0917193864
 
DOCX
Kho 200 Đề Tài Luận Văn Tốt Nghiệp Ngành Xuất Nhập Khẩu
byDịch vụ viết bài trọn gói ZALO 0917193864
 
DOCX
Kho 200 đề tài luận văn tốt nghiệp ngành quản trị văn phòng, 9 điểm
byDịch vụ viết bài trọn gói ZALO 0917193864
 
DOCX
Danh sách 200 đề tài luận văn thạc sĩ quản trị rủi ro, hay nhất
byDịch vụ viết bài trọn gói ZALO 0917193864
 
DOCX
Danh sách 200 đề tài luận văn tốt nghiệp ngành khách sạn,10 điểm
byDịch vụ viết bài trọn gói ZALO 0917193864
 
DOCX
Danh sách 200 đề tài luận văn thạc sĩ quản lý giáo dục mầm non, mới nhất
byDịch vụ viết bài trọn gói ZALO 0917193864
 
DOCX
Kho 200 Đề Tài Luận Văn Ngành Thủy Sản, từ các trường đại học
byDịch vụ viết bài trọn gói ZALO 0917193864
 
DOCX
Danh sách 200 đề tài luận văn thạc sĩ ô tô, 10 điểm
byDịch vụ viết bài trọn gói ZALO 0917193864
 
DOCX
Danh sách 200 đề tài luận văn thạc sĩ tiêm chủng mở rộng, 10 điểm
byDịch vụ viết bài trọn gói ZALO 0917193864
 
DOCX
danh sach 200 de tai luan van thac si ve rac nhua
byDịch vụ viết bài trọn gói ZALO 0917193864
 
DOCX
Danh sách 200 đề tài luận văn thạc sĩ ngân hàng, hay nhất
byDịch vụ viết bài trọn gói ZALO 0917193864
 
DOCX
Kho 200 Đề Tài Bài Luận Văn Tốt Nghiệp Ngành Kế Toán, 9 điểm
byDịch vụ viết bài trọn gói ZALO 0917193864
 
DOCX
Kho 200 đề tài luận văn ngành thương mại điện tử
byDịch vụ viết bài trọn gói ZALO 0917193864
 
DOCX
Danh sách 200 đề tài luận văn thạc sĩ tài chính ngân hàng, từ sinh viên giỏi
byDịch vụ viết bài trọn gói ZALO 0917193864
 
DOCX
200 de tai khoa luạn tot nghiep nganh tam ly hoc
byDịch vụ viết bài trọn gói ZALO 0917193864
 
DOCX
Kinh Nghiệm Chọn 200 Đề Tài Tiểu Luận Chuyên Viên Chính Trị Hay Nhất
byDịch vụ viết bài trọn gói ZALO 0917193864
 
Kho 200 đề tài luận văn tốt nghiệp ngành điện tử viễn thông, 9 điểm
byDịch vụ viết bài trọn gói ZALO 0917193864
 
Kho 200 Đề Tài Luận Văn Tốt Nghiệp Ngành Giáo Dục Tiểu Học
byDịch vụ viết bài trọn gói ZALO 0917193864
 
Kho 200 Đề Tài Luận Văn Tốt Nghiệp Ngành Sư Phạm Tin Học
byDịch vụ viết bài trọn gói ZALO 0917193864
 
Danh sách 200 đề tài luận văn thạc sĩ ngữ văn, hay nhất
byDịch vụ viết bài trọn gói ZALO 0917193864
 
Kho 200 đề tài luận văn tốt nghiệp ngành luật, hay nhất
byDịch vụ viết bài trọn gói ZALO 0917193864
 
Kho 200 Đề Tài Luận Văn Tốt Nghiệp Ngành Xuất Nhập Khẩu
byDịch vụ viết bài trọn gói ZALO 0917193864
 
Kho 200 đề tài luận văn tốt nghiệp ngành quản trị văn phòng, 9 điểm
byDịch vụ viết bài trọn gói ZALO 0917193864
 
Danh sách 200 đề tài luận văn thạc sĩ quản trị rủi ro, hay nhất
byDịch vụ viết bài trọn gói ZALO 0917193864
 
Danh sách 200 đề tài luận văn tốt nghiệp ngành khách sạn,10 điểm
byDịch vụ viết bài trọn gói ZALO 0917193864
 
Danh sách 200 đề tài luận văn thạc sĩ quản lý giáo dục mầm non, mới nhất
byDịch vụ viết bài trọn gói ZALO 0917193864
 
Kho 200 Đề Tài Luận Văn Ngành Thủy Sản, từ các trường đại học
byDịch vụ viết bài trọn gói ZALO 0917193864
 
Danh sách 200 đề tài luận văn thạc sĩ ô tô, 10 điểm
byDịch vụ viết bài trọn gói ZALO 0917193864
 
Danh sách 200 đề tài luận văn thạc sĩ tiêm chủng mở rộng, 10 điểm
byDịch vụ viết bài trọn gói ZALO 0917193864
 
danh sach 200 de tai luan van thac si ve rac nhua
byDịch vụ viết bài trọn gói ZALO 0917193864
 
Danh sách 200 đề tài luận văn thạc sĩ ngân hàng, hay nhất
byDịch vụ viết bài trọn gói ZALO 0917193864
 
Kho 200 Đề Tài Bài Luận Văn Tốt Nghiệp Ngành Kế Toán, 9 điểm
byDịch vụ viết bài trọn gói ZALO 0917193864
 
Kho 200 đề tài luận văn ngành thương mại điện tử
byDịch vụ viết bài trọn gói ZALO 0917193864
 
Danh sách 200 đề tài luận văn thạc sĩ tài chính ngân hàng, từ sinh viên giỏi
byDịch vụ viết bài trọn gói ZALO 0917193864
 
200 de tai khoa luạn tot nghiep nganh tam ly hoc
byDịch vụ viết bài trọn gói ZALO 0917193864
 
Kinh Nghiệm Chọn 200 Đề Tài Tiểu Luận Chuyên Viên Chính Trị Hay Nhất
byDịch vụ viết bài trọn gói ZALO 0917193864
 

Recently uploaded

PDF
Nhận diện hành động trong video (Đề Olympic AI 2025)
byMan_Ebook
 
PDF
100 ĐỀ THI THỬ TỐT NGHIỆP THPT 2026 - TỪ CÁC TRƯỜNG, TRƯỜNG CHUYÊN, SỞ GIÁO D...
byNguyen Thanh Tu Collection
 
PDF
20 CHUYÊN ĐỀ TỔNG ÔN NGỮ PHÁP ỨNG DỤNG (BÀI GIẢNG + BÀI THI ONLINE) - MAI PHƯ...
byNguyen Thanh Tu Collection
 
PDF
BỘ ĐỀ THI NÂNG CAO B2-C2 30 ĐỀ THI THỬ KỲ THI TỐT NGHIỆP TRUNG HỌC PHỔ THÔNG ...
byNguyen Thanh Tu Collection
 
PDF
99055-Article Text-207823-1-10-20240705.pdf
bynghiepsqtt
 
PPTX
CHUONG-3-DJOC-HOC-MyfycgcycOI-TRUONG-NUOC-WATER-ECOTOXICOLOGY.pptx
byHunhNam16
 
DOCX
HUONG DAN DN KHAI BAO CO TREN HE THONG MOI CO.MOIT.GOV.VN.docx
byDoan Tran Ngocvu
 
PDF
100 ĐỀ THI THỬ TỐT NGHIỆP THPT 2026 - TỪ CÁC TRƯỜNG, TRƯỜNG CHUYÊN, SỞ GIÁO D...
byNguyen Thanh Tu Collection
 
PDF
BỘ ĐỀ ÔN TẬP KHỞI ĐỘNG KỲ THI TỐT NGHIỆP TRUNG HỌC PHỔ THÔNG 2026 - MỤC TIÊU ...
byNguyen Thanh Tu Collection
 
PPTX
Bất bình đẳng trong chăm sóc y tế ở nhóm yếu thế_Nhân học và xã hội học SK
bymaiquocbinh22012005
 
PDF
100 ĐỀ THI THỬ TỐT NGHIỆP THPT 2026 - TỪ CÁC TRƯỜNG, TRƯỜNG CHUYÊN, SỞ GIÁO D...
byNguyen Thanh Tu Collection
 
DOCX
LỊCH CÔNG TÁC TUẦN 17 (Từ ngày 29/12/2025 đến 04/01/2026)
byQucHHunhnh
 
DOCX
Những ưu điểm, nhược điểm trong hoạt động quản lý giáo dục trong trường mầm non
bylamluanvan.net Hỗ trợ viết luận văn
 
PDF
100 CAU hoi trac nghiem ve Thi truong chưng khoan
bytranmyngan2510
 
DOCX
LỊCH CÔNG TÁC TUẦN 18 (Từ ngày 05/01/2026 đến 11/01/2026)
byQucHHunhnh
 
PPTX
Ngu van 9Bai 20 Cach lam ba dang nghi luan xa hoi.pptx
byhoangthingoclinh1702
 
Nhận diện hành động trong video (Đề Olympic AI 2025)
byMan_Ebook
 
100 ĐỀ THI THỬ TỐT NGHIỆP THPT 2026 - TỪ CÁC TRƯỜNG, TRƯỜNG CHUYÊN, SỞ GIÁO D...
byNguyen Thanh Tu Collection
 
20 CHUYÊN ĐỀ TỔNG ÔN NGỮ PHÁP ỨNG DỤNG (BÀI GIẢNG + BÀI THI ONLINE) - MAI PHƯ...
byNguyen Thanh Tu Collection
 
BỘ ĐỀ THI NÂNG CAO B2-C2 30 ĐỀ THI THỬ KỲ THI TỐT NGHIỆP TRUNG HỌC PHỔ THÔNG ...
byNguyen Thanh Tu Collection
 
99055-Article Text-207823-1-10-20240705.pdf
bynghiepsqtt
 
CHUONG-3-DJOC-HOC-MyfycgcycOI-TRUONG-NUOC-WATER-ECOTOXICOLOGY.pptx
byHunhNam16
 
HUONG DAN DN KHAI BAO CO TREN HE THONG MOI CO.MOIT.GOV.VN.docx
byDoan Tran Ngocvu
 
100 ĐỀ THI THỬ TỐT NGHIỆP THPT 2026 - TỪ CÁC TRƯỜNG, TRƯỜNG CHUYÊN, SỞ GIÁO D...
byNguyen Thanh Tu Collection
 
BỘ ĐỀ ÔN TẬP KHỞI ĐỘNG KỲ THI TỐT NGHIỆP TRUNG HỌC PHỔ THÔNG 2026 - MỤC TIÊU ...
byNguyen Thanh Tu Collection
 
Bất bình đẳng trong chăm sóc y tế ở nhóm yếu thế_Nhân học và xã hội học SK
bymaiquocbinh22012005
 
100 ĐỀ THI THỬ TỐT NGHIỆP THPT 2026 - TỪ CÁC TRƯỜNG, TRƯỜNG CHUYÊN, SỞ GIÁO D...
byNguyen Thanh Tu Collection
 
LỊCH CÔNG TÁC TUẦN 17 (Từ ngày 29/12/2025 đến 04/01/2026)
byQucHHunhnh
 
Những ưu điểm, nhược điểm trong hoạt động quản lý giáo dục trong trường mầm non
bylamluanvan.net Hỗ trợ viết luận văn
 
100 CAU hoi trac nghiem ve Thi truong chưng khoan
bytranmyngan2510
 
LỊCH CÔNG TÁC TUẦN 18 (Từ ngày 05/01/2026 đến 11/01/2026)
byQucHHunhnh
 
Ngu van 9Bai 20 Cach lam ba dang nghi luan xa hoi.pptx
byhoangthingoclinh1702
 

Luận văn: Chất lượng dịch vụ cho truyền thông đa phương tiện, 9đ

  • 1.
    ĐẠI HỌC QUỐCGIA HÀ NỘI TRƯỜNG ĐẠI HỌC CÔNG NGHỆ HOÀNG TRỌNG THỦY ĐẢM BẢO CHẤT LƯỢNG DỊCH VỤ CHO TRUYỀN THÔNG ĐA PHƯƠNG TIỆN THỜI GIAN THỰC TRÊN INTERNET NGÀNH: CÔNG NGHỆ THÔNG TIN CHUYÊN NGÀNH: TRUYỀN DỮ LIỆU VÀ MẠNG MÁY TÍNH MÃ SỐ: LUẬN VĂN THẠC SĨ NGÀNH CÔNG NGHỆ THÔNG TIN GVHD: PGS TS Nguyễn Đình Việt Hà Nội - 2016
  • 2.
    LỜI CAM ĐOAN Tôixin cam đoan rằng đây là công trình nghiên cứu của cá nhân tôi dưới sự hướng dẫn giúp đỡ của PGS TS. Nguyễn Đình Việt. Các kết quả được viết chung với các tác giả khác đều được sự đồng ý của tác giả trước khi đưa vào luận văn. Trong toàn bộ nội dung nghiên cứu của luận văn, các vấn đề được trình bày đều là những tìm hiểu và nghiên cứu của chính cá nhân tôi hoặc là được trích dẫn từ các nguồn tài liệu có ghi tham khảo rõ ràng, hợp pháp. Trong luận văn, tôi có tham khảo đến một số tài liệu của một số tác giả được liệt kê tại mục tài liệu tham khảo. Hà nội, tháng 11 năm 2016 Tác giả luận văn Hoàng Trọng Thủy
  • 3.
    LỜI CẢM ƠN Đểhoàn thành tốt luận văn này, đầu tiên tôi xin bày tỏ lòng biết ơn chân thành và sâu sắc đến Thầy Nguyễn Đình Việt, người đã tận tình và trực tiếp hướng dẫn tôi trong suốt quá trình triển khai và nghiên cứu đề tài, tạo điều kiện để tôi hoàn thành luận văn này. Thứ hai, tôi xin bày tỏ lòng biết ơn chân thành tới toàn thể các thầy cô giáo trong khoa Công nghệ thông tin, trường Đại học Công nghệ, Đại học Quốc gia Hà Nội đã dạy bảo tận tình tôi trong suốt quá trình tôi học tập tại khoa. Cuối cùng tôi xin chân thành cảm ơn tới gia đình, bạn bè, đồng nghiệp đã luôn bên em cổ vũ, động viên, giúp đỡ tôi trong suốt quá trình học tập và thực hiện luận văn. Mặc dù đã cố gắng hoàn thành luận văn trong phạm vi và khả năng cho phép nhưng chắc chắn sẽ không tránh khỏi những thiếu sót. tôi rất mong được sự góp ý chân thành của thầy cô và các bạn để tôi hoàn thiện luận văn của mình. Tôi xin chân thành cảm ơn! Hà Nội, tháng 11 năm 2016 Học viên Hoàng Trọng Thủy
  • 4.
    MỤC LỤC Chương 1.GIỚI THIỆU..................................................................................................2 1.1. Tổng quan về bộ giao thức TCP/IP và sự phát triển của mạng Internet..............2 Giới thiệu chung .....................................................................................................2 1.2. Tổng quan về truyền thông đa phương tiện (Multimedia) và chất lượng dịch vụ (QoS)...........................................................................................................................3 1.2.1. Giới thiệu chung về truyền thông đa phương tiện (Multimedia)..................3 1.2.2. Giới thiệu chung về chất lượng dịch vụ (QoS).............................................4 1.3. Kiến trúc QoS cở bản...........................................................................................8 1.3.1. QoS nhận dạng và đánh dấu .........................................................................8 1.3.2. QoS trong một thiết bị mạng ........................................................................9 1.4. Các mô hình đảm bảo chất lượng dịch vụ............................................................9 1.4.1. Mô hình các dịch vụ được tích hợp IntServ .................................................9 1.4.2. Mô hình các dịch vụ phân biệt DiffServ.....................................................12 1.5. Kiến trúc DiffServ trong bộ mô phỏng NS2......................................................17 1.5.1. Router MRED (Milti RED) ........................................................................18 1.5.2. Các cơ chế đánh dấu gói tin và chính sách phục vụ ...................................18 1.5.3. Các cơ chế lập lịch hàng đợi.......................................................................20 1.6. Thách thức của việc truyền thông đa phương tiện trên Internet hiện nay..........20 1.6.1. Hạn chế của việc truyền thông đa phương tiện hiện nay............................20 1.6.2. Các phương pháp đảm bảo chất lượng dịch vụ trên nền các dịch vụ cố gắng tối đa (best effort) .................................................................................................20 Chương 2. CÁC CHIẾN LƯỢC QUẢN LÝ HÀNG ĐỢI VÀ KHẢ NĂNG ÁP DỤNG ĐỂ ĐẢM BẢO QOS CHO TRUYỀN THÔNG ĐA PHƯƠNG TIỆN THỜI GIAN THỰC ............................................................................................................................21 2.1. Các chiến lược quản lý hàng đợi truyền thống ..................................................21 2.1.1. Hàng đợi FIFO (First in first out) ...............................................................21 2.1.2. Chiến lược hàng đợi ưu tiên PQ ( Priority Queue )....................................22 2.1.3. Chiến lược Packet-Based Round Robin .....................................................23 2.1.4. Bộ lập lịch lý tưởng GPS - Generalized Processor Sharing .......................24
  • 5.
    2.1.5. Chiến lượcFlow-Based Weighted Fair Queuing (WFQ)..........................24 2.1.6. Chiến lược Class-Based Weighted Fair Queuing (CBQ)...........................27 2.2. CÁC CHIẾN LƯỢC QUẢN LÝ HÀNG ĐỢI ĐỘNG......................................29 2.2.1. Chiến lược quản lý hàng đợi truyền thống và hệ quả.................................29 2.2.2. Ưu điểm các chiến lược quản lý hàng đợi động.........................................30 2.2.3. Thuật toán RED trong chiến lược quản lý hàng đợi động..........................32 2.2.4. Thuật toán A-RED......................................................................................39 2.2.5. Thuật toán RIO ...........................................................................................41 2.2.6. Thuật toán A-RIO.......................................................................................44 Chương 3. ĐÁNH GIÁ HIỆU QUẢ ĐẢM BẢO QOS CHO TRUYỀN THÔNG ĐA PHƯƠNG TIỆN THỜI GIAN THỰC CỦA MỘT SỐ CHIẾN LƯỢC QUẢN LÝ HÀNG ĐỢI....................................................................................................................46 3.1. Đánh giá bằng mô phỏng hiệu quả của thuật toán RED....................................46 3.2. Đánh giá bằng mô phỏng việc áp dụng kiến trúc mạng Diffserv có sử dụng RED...........................................................................................................................49 3.2.1. Cấu hình mạng mô phỏng...........................................................................50 3.3. Kết luận và hướng nghiên cứu tiếp theo ............................................................58 TÀI LIỆU THAM KHẢO.............................................................................................59
  • 6.
    DANH SÁCH CÁCKÝ HIỆU VÀ CHỮ VIẾT TẮT STT Từ viết tắt Từ hoặc cụm từ Ý nghĩa 1 ACL Access Control Lists Danh sách điều khiển truy cập 2 AF Assured Forwarding 3 AIMD Additive-Increase Multiplicative-Decrease Tăng theo cấp số cộng, giảm theo cấp số nhân 4 AQM Active Queue Management Quản lý hàng đợi động 5 A-RIO Adaptive – RED with In/Out bit Thuật toán RED thích nghi với bit In/Out 6 CBQ Class-Based Weighted Fair Queuing 7 CBR Constant Bit Rate 8 CBS Committed Burst Size Kích thước cụm cam kết 9 CIR Committed Information Rate Tốc độ thông tin cam kết 10 CP Code Point 11 DiffServ Differentiated Services Dịch vụ phân biệt 12 EBS Excess Burst Size Kích thước cụm vượt mức 13 ECN Explicit Congestion Notification Cờ thông báo tắc nghẽn 14 EF Expedited Forwarding 15 FIFO First In First Out
  • 7.
    16 FTP FileTransfer Protocol Giao thức truyền file 17 IntServ Integrated Services Dịch vụ tích hợp 18 IP Internet Protocol 19 ISP Internet Service Provider Nhà cung cấp dịch vụ 20 LAN Local Area Network Mạng cục bộ 21 NS Network Simulator 22 PBS Peak Burst Size Kích thước cụm tối đa 23 PIR Peak Information Rate Kích thước cam kết tối đa 24 PQ Priority Queue Hàng đợi ưu tiên 25 PRI Priority 26 PHB Per-Hop Behavior Đối xử theo chặng 27 QoS Quality of Service Chất lượng dịch vụ 28 RED Random Early Detection/ Random Early Drop Phát hiện sớm ngẫu nhiên, Loại bỏ sớm ngẫu nhiên 29 RIO RED with In/Out bit 30 RIO – C Rio Coupled 31 RIO - D Rio DeCoupled 32 RR Round Robin 33 RSVP Resource Revervation Protocol Giao thức dành trước tài nguyên
  • 8.
    34 TCP Transmission Control Protocol Giaothức điều khiển truyền vận 35 TSW Time Sliding Window Cửa sổ thời gian trượt 36 UDP User Datagram Protocol 37 WAN Wide Area Network Mạng diện rộng 38 WFQ Flow-Based Weighted Fair Queuing Hàng đợi luồng có trọng số 39 WIRR Weighted Interleaved Round Robin
  • 9.
    DANH MỤC CÁCHÌNH VẼ, ĐỒ THỊ Hình 1.1. Sự phát triển của QoS........................................................................................ Hình 1.2. Các kỹ thuật QoS............................................................................................... Hình 1.3. Mô hình nguyên lý hoạt động của giao thức RSVP........................................... Hình 1.4. Kiến trúc DiffServ đơn giản .............................................................................. Hình 1.4. Phân loại và đánh dấu gói tin ở router biên ..................................................... Hình 2.1. Cơ chế phục vụ FIFO........................................................................................ Hình 2.2. Cơ chế phục vụ hàng đợi ưu tiên....................................................................... Hình 2.3. Cơ chế phục vụ hàng đợi Packet-Based Round Robin...................................... Hình 2.4. Cơ chế WFQ ...................................................................................................... Hình 2.5. IP Precedence bits............................................................................................. Hình 2.5. Chia sẻ băng thông trong CBQ ......................................................................... Hình 2.7. Giải thuật tổng quát cho RED gateway............................................................. Hình 2.8 Giải thuật RED chi tiết....................................................................................... Hình 2.9. Các tham số thuật toán RED............................................................................. Hình 2.10. Giải thuật tổng quát cho A-RED gateway....................................................... Hình 2.11. Giải thuật RIO ................................................................................................. Hình 3.1. Mô phỏng DropTail........................................................................................... Hình 3.2. Mô phỏng RED.................................................................................................. Hình 3.3. Giải thuật RIO ................................................................................................... Hình 3.4. Topo mạng mô phỏng ........................................................................................ Hình 3.5. So sánh thông lượng các kết nối UDP trường hợp tắc nghẽn ít ....................... Hình 3.6. So sánh kích thước hàng đợi trung bình trường hợp tắc nghẽn ít .................... Hình 3.7. So sánh độ trễ hàng đợi trung bình trường hợp tắc nghẽn ít............................
  • 10.
    Hình 3.8 .So sánh thông lược các kết nối UDP trường hợp tắc nghẽn nhiều.................. Hình 3.9. So sánh kích thước hàng đợi trung bình trường hợp tắc nghẽn nhiều.............. Hình 3.10. So sánh độ trễ hàng đợi trung bình trường hợp tắc nghẽn nhiều ...................
  • 11.
    DANH SÁCH BẢNGBIỂU Bảng 3.1.. So sánh RED với DropTail .............................................................................. Bảng 3.2. Thông kê gói tin trường hợp tắc nghẽn ít ......................................................... Bảng 3.3. Thống kê Từng kết nối Trường hợp tắc nghẽn ít .............................................. Bảng 3.4. Thông kê gói tin trường hợp tắc nghẽn nhiều................................................... Bảng 3.5.. Thống kê Từng kết nối trường hợp tắc nghẽn nhiều........................................
  • 12.
    1 MỞ ĐẦU 1. ĐẶTVẤN ĐỀ Sự phát triển mạnh mẽ của mạng Internet ngày này kéo theo sự sự phát triển của các ứng dụng trên Internet. Dữ liệu trao đổi trên mạng không chỉ đơn thuần là văn bản (text) nữa mà thêm vào đó là dữ liệu đa phương tiện (multimedia) bao gồm có hình ảnh (image), âm thanh (audio), phim, nhạc… Các ứng dụng đa phương tiện phổ biến có thể kể đến như gọi điện qua mạng (Internet telephony), hội thảo trực tuyến (video conferencing) hoặc các ứng dụng xem video theo yêu cầu (video on demand) càng ngày càng được sử dụng rộng rãi. Vấn đề đảm bảo chất lượng dịch vụ (QoS) đang trở nên quan trọng hơn bao giờ hết. 2. MỤC ĐÍCH CỦA LUẬN VĂN Do sự bùng nổ mạng mẽ của mạng Internet như hiện nay khiến cho dữ liệu vận chuyển quan mạng Internet trở nên khổng lồ, nhu cầu quá lớn khiến cho việc tắc nghẽn xảy ra thường xuyên và vấn đề đặt ra là làm sao hạn chế tối đa tắc nghẽn trên mạng Internet và duy trì sự ổn định cao nhất cho mạng. Các kỹ thuật truyền thống nhằm giảm thiểu tắc nghẽn trên mạng ngày càng kém hiệu quả. Mục đích của luận văn là nghiên cứu một giải pháp quản lý và điều khiển nhằm hạn chế tối đa tắc nghẽ trên mạng Internet. Thay vì sử dụng hàng đợi FIFO truyền thống (Trong bộ mô phỏng NS2 được gọi với cái tên DropTail) luận văn này sẽ nghiên cứu sâu các chiến lược quản lý hàng đợi động mà tiêu biểu là RED (Random Early Detection of Congestion; Random Early Drop), Adaptive-RED, A-RIO (Adaptive – RED with In and Out). 3. BỐ CỤC CỦA LUẬN VĂN a) Chương 1: Giới thiệu b) Chương 2: Các chiến lược quản lý hàng đợi và khả năng áp dụng để đảm bảo QoS cho truyền thông đa phương tiện thời gian thực c) Chương 3: Đánh giá hiệu quả đảm bảo QoS cho truyền thông đa phương tiện thời gian thực của một số chiến lược quản lý hàng đợi
  • 13.
    2 Chương 1. GIỚITHIỆU 1.1. Tổng quan về bộ giao thức TCP/IP và sự phát triển của mạng Internet Giới thiệu chung Năm 1967 từ một thí nghiệm mạng do Robert L.G đề xuất. ARPA trực thuộc bộ quốc phòng Mỹ đã kết nối 4 địa điểm đầu tiên vào tháng 7 năm 1967 gồm: Viện nghiên cứu Standford, Đại học California tại Los Angeles, Đại học tổng hợp Utah và Đại học California tại Santa Barbara. Đó là mạng WAN đầu tiên được xây dựng được gọi là ARPANET sau này là mạng Internet [17] Bộ giao thức TCP/IP chính thức ra đời năm 1983 và được coi là chuẩn đối với ngành quân sự Mỹ và tất cả các máy tính nối với mạng ARPANET phải sử dụng theo chuẩn mới này. Sự phát triển như vũ bão khiến cho mọi trường đại học đều muốn gia nhập vào mạng này và việc quản lý mạng trở nên khó khăn. Chính vì lẽ đó mạng ARPANET được tách ra thành 2 phần là MILNET và ARPANET mới vào năm 1983, tuy tách rời nhưng hai mạng này vẫn liên kết với nhau nhờ giao thức liên mạng IP. Sự ra đời của TCP/IP đánh dấu mốc lịch sử quan trọng và càng ngày càng hiện rõ điểm mạnh của nó nhất là khả năng liên kết các mạng khác với nhau một cách dễ dàng. Vào thập kỷ 80 khi hội đồng Khoa học quốc gia Mỹ NSF (Nation Science Foundation) thành lập mạng liên kết các trung tâm máy tính lới với nhau gọi là NSFNET. Các doanh nghiệp đã chuyển từ ARPANET sang NSFNET. Sau gần 20 năm hoạt động ARPANET đã dừng hoạt động vào khoảng năm 1990. Sự phát triển của backbone NSFNET và những mạng khác đã tạo ra mội trường thuận lợi cho sự phát triển của Internet. Năm 1995 NSFNET thu lại thành một mạng nghiên cứu và Internet thì tiếp tục phát triển. Cùng với khả năng kết nối mở Internet đã trở thành một mạng lớn nhất thế giới, mạng của các mạng xuất hiện trong mọi linh vực thương mại, chính trị, quân sự, xã hội… Ngày nay khi cơ sở hạ tầng của mạng Internet được nâng cao đã làm cho nhu cầu của các ứng dụng đa phương tiện qua mạng tăng lên nhanh chóng.
  • 14.
    3 1.2. Tổng quanvề truyền thông đa phương tiện (Multimedia) và chất lượng dịch vụ (QoS) 1.2.1. Giới thiệu chung về truyền thông đa phương tiện (Multimedia) Trước đây, khi mà Internet chủ yếu là truyền data thì người ta không cần quan tâm đến việc phân biệt và ưu tiên cho các gói tin bởi vì lúc này băng thông mạng và các tài nguyên khác đủ để cung cấp cho các ứng dụng trong mạng, vì vậy các ISPs sẽ cung cấp cho khách hàng của họ dịch vụ theo kiểu “Cố gắng tối đa” (Best-Effort - BE) khi đó tất cả các khách hàng sẽ được đối xử như nhau họ chỉ khác nhau ở loại kết nối. Đây là dịch vụ phố biến trên mạng Internet hay mạng IP nói chung. Các gói thông tin được truyền đi theo nguyên tắc “đến trước được phục vụ trước” mà không quan tâm đến đặc tính lưu lượng của dịch vụ là gì. Điều này dẫn đến rất khó hỗ trợ các dịch vụ đòi hỏi độ trễ thấp như các dịch vụ thời gian thực hay video. Cho đến thời điểm này, đa phần các dịch vụ được cung cấp bởi mạng Internet vẫn sử dụng nguyên tắc Best Effort này. Dữ liệu truyền thông trên mạng Internet thường được chia làm 2 loại chính là dữ liệu dạng tĩnh và dữ liệu dạng động. Các ứng dụng trên Internet truyền thống như Web, email, file tranfer thường truyền dữ liệu dạng tĩnh. Dữ liệu được truyền một cách nhanh nhất có thể. Tuy nhiên trộ trễ đầu cuối có thể lên tới 10s hoặc hơn vẫn chấp nhận được. Dữ liệu động ở đây thường là Audio hoặc Video và các ứng dụng truyền thông loại dữ liệu trên được gọi chung là ứng dụng đa phương tiện. Loại dữ liệu này rất nhạy cảm với độ trễ nhưng lại cho phép sự mất mát gói tin trong một ngưỡng chấp nhận được. Tính chất hoàn toàn trái ngược với các ứng dụng truyền thống nên nó đòi hỏi chất lượng dịch vụ khác hoàn toàn với các ứng dụng truyền thống. Tùy theo từng yêu cầu về chất lượng dịch vụ có thể chia ứng dụng đa phương tiện thành 3 lớp cơ bản sau:  Truyền audio và video đã được lưu trữ  Truyển audio và video thời gian thực  Ứng dụng tương tác audio và video thời gian thực
  • 15.
    4 1.2.2. Giới thiệuchung về chất lượng dịch vụ (QoS) Quality of Service – QoS: chỉ khả năng cung cấp các dịch vụ mạng cho một lưu lượng nào đó. Mục đích chính là điều khiển băng thông, độ trễ và jitter. Giảm độ trễ, giảm tỉ lệ mất mát gói tin cho các ứng dụng thời gian thực và tương tác trong khi vẫn đảm bảo phục vụ tốt cho các luồng dữ liệu khác. Theo khuyến nghị của CCITT, E800 đưa ra một tính chất chung qua QoS: “Hiệu ứng chung của đặc tính chất lượng dịch vụ là xác định mức độ hài lòng của người sử dụng đối với chất lượng dịch vụ” Khuyến nghị ETR300003 của ETSI chia và cải tiến định nghĩa của ITU thành các định nghĩa nhỏ hơn, nó phù hợp với các yêu cầu và quan điểm của các nhóm khác nhau trong viễn thông đó là:  Yêu cầu QoS của người sử dụng.  Đề nghị QoS của nhà cung cấp dịch vụ.  Sử cảm nhận QoS từ khách hàng.  Việc thực hiện QoS của nhà cung cấp dịch vụ.  Yêu cầu QoS của nhà cung cấp dịch vụ. Như vậy một cách tổng quan QoS mang ý nghĩa là “Khả năng của mạng đảm bảo và duy trì các mức thực hiện nhất định cho mỗi ứng dụng theo như yêu cầu đã chỉ rõ của mỗi người sử dụng”. Một ý trong định nghĩa này chính là chìa khóa để hiểu được QoS là gì từ góc nhìn của nhà cung cấp mạng. Nhà cung cấp dịch vụ mạng đảm bảo QoS cung cấp cho người sử dụng và thực hiện các biện pháp duy trì mức QoS khi điều kiện mạng thay đổi vì các nguyên nhận như tắc nghẽn, hỏng hóc thiết bị hay lỗi đường truyền v. v… QoS cần được cung cấp cho mỗi ứng dụng để người sử dụng có thể chạy ứng dụng đó tuy nhiên người sử dụng cũng cần phải tìm hiểu các thông tin từ người quản trị để hiểu mạng phải cung cấp những gì cần thiết cho mỗi sứng dụng. Đảm bảo chất lượng dịch vụ thường phụ thuộc nhiều vào tài nguyên của hệ thống, việc quản lý tài nguyên đó bao gồm có:  Tính toán hiệu suất sử dụng tài nguyên  Dành tài nguyên cho dịch vụ
  • 16.
    5  Lập lichtruy cập tài nguyên Hình 1.1: Sự phát triển của QoS Các tham số QoS chính liên quan đến mạng bao gồm: a) Độ trễ (Delay): là thời gian truyền 1 gói tin từ nguồn tới đích, nó phụ thuộc vào tốc độ truyền tin. Tốc độ truyền tin càng lớn thì độ trễ càng nhỏ và ngược lại. Delay liên quan chặt chẽ tới băng thông. Với các ứng dụng giới hạn băng thông thì băng thông càng lớn độ trễ càng nhỏ. b) Thông lượng (Throughput): là khả năng truyền tin được tính bằng tổn số đơn vị dữ liệu truyền được trong 1 đơn vị thời gian ví dụ: packet/s c) Jitter: là sự biến thiên độ trễ. Thông số QoS jitter thiết lập giới hạn lên lượng biến đổi của độ trễ mà một ứng dụng có thể gặp phải trên mạng. Một cách chính xác hơn thì jitter được xem như là biến động trễ. Jitter theo lý thuyết có thể là một giá trị tương đối hoặc tuyệt đối. Ví dụ nếu trễ mạng cho một ứng dụng được thiết lập là 100ms, jitter có thể đặt là cộng trừ 10% độ trễ. Theo đó độ trễ đảm bảo phải dao động trong khoảng từ 90ms đến 110ms. Mặt khác nếu giá trị jitter là 5ms thì độ trễ phải dao động trong khoảng từ 95ms đến 105ms. Các ứng dụng nhạy cảm nhất với jitter là các ứng dụng thời gian thực
  • 17.
    6 như voice, videostreaming nhưng lại không quan trọng đối với các ứng dụng như web hoặc truyền file qua mạng… Đây là vấn đề cố hữu trọng mạng chuyển mạch gói do cơ chế định tuyến và chuyển mạch các gói tin trong mạng của cùng một luồng có thể đi theo nhiều đường khác nhau để đến đích khi đó độ trễ của các gói tin nay là khác nhau dẫn tới việc jitter là không thế nào tránh khỏi. d) Tỉ lệ mất gói tin (Packet loss ratio): là số đơn vị gói tin bị mất trong một đơn vị thời gian, đây là một tham số QoS không thường xuyên được nói đến. Bản chất của Internet hiên nay vẫn dựa trên nền “BE” thế nên việc mất gói tin là không tránh khỏi. Chính vì thế tham số QoS Packet loss không nên định rõ một giới hạn trên đối với anh hưởng của lỗi mà nên cho phép người sử dụng xác định xem có lựa chọn cách sửa lỗi bằng việc truyền lại không hoặc các cơ chế khắc phục khác. e) Độ khả dụng (Đáng tin cậy): Các mạng tồn tại để phục vụ người sử dụng , tuy nhiện mạng cần có các biện pháp bảo dưỡng và phòng người trước các tình huống hỏng hóc tiềm tàng được phát hiện và dự đoán trước. Một chiến lược đúng đắn bằng cách định kì tách các thiết bị ra khỏi mạng và thực hiện các công việc bảo dưỡng và chẩn đoán trong một thời gian gnawns để có thể giảm thời gian ngưng hoạt động do hỏng hóc. Thậm chí với biện pháp bảo dưỡng hoàn hảo nhất cũng không thể tránh được các lỗi không tiên đoán trước và các lỗi nghiêm trọng của các thiết bị và kết nối theo thời gian. Việc bảo trì mạng dữ liệu trở nên đơn giản hơn, hầu hết mạng dữ liệu sinh ra dành cho kinh doanh thường là từ 8h sáng đến 6h chiều từ thứ 2 đến thứ 6. Các hoạt động bổ trở hoặc bảo trì có thể được thực hiện ngoài giờ hoặc trong các ngày nghỉ. Internet và web đã thay đổi tất cả, một mạng toàn cầu phải giải quyết được vấn đề rằng thực sự có một số người luôn cố gắng truy nhập vào mạng tại một số địa điểm và thậm chí Internet còn có ích cho một số người vào giờ ngoài hành chính hơn. Một năm có 31.536.000 giây, giả thiết rằng độ khả dụng của một mạng là 99% thì điều này có nghĩa rằng nhà cung cấp dịch vụ có 315.360 giây hay 87,6 giờ mạng không hoạt động trong 1 năm. Khoảng thời gian này là tương đối lớn. Nếu giá trị này 99,99% thì sẽ tốt hơn nhiều. Tất nhiên nhà cung cấp dịch vụ cần nhiều cơ chế
  • 18.
    7 dự phòng vàkhắc phục lỗi để đảm bảo độ sẵn sàng của mạng càng cao. Ngày ngay QoS khả dụng của mạng thường khoảng 99,995% f) Bảo mật: Đây là một tham số mới trong danh sách các tham số QoS nhưng lại là một tham số quan trọng, thực tế trong một số trường hợp độ bảo mật có thể được xét ngay sau băng thông. Gầy đây sự đe dọa rông rãi của các hacker và sự lan tràn virus trên mạng Internet toàn cầu thì tham số này càng trở nên quan trọng hơn. Hầu hết vấn đề bảo mật liên quan tới tính riêng tư, tự tin cậy và xác nhận Server – Client. Các vấn đề bảo mật thường được gắn với một vài hình thức của phương pháp mật mã như mã hóa giữ liệu và giải mã. Các phương pháp trên mạng cũng được sử dụng như xác thực (Authentication). Một tham số QoS bảo mật điển hình có thể là “Mã hóa và xác thực đòi hỏi trên tất cả các luồn lưu lượng”. Ngày nay tầm quan trọng của bảo mật như một tham số QoS là rất lớn không thể đánh giá hết được g) Ngoài ra còn một số tham số như “Kích thước mất tin” hoặc “độ tin cậy” Hình 1.2: Các kỹ thuật QoS
  • 19.
    8 Mức QoS:  Best-Effort:Đây là mức thấp nhất, dịch vụ kết nối không đảm bảo đặc trưng bởi hàng đợi FIFO, không có sự phân loại giữa các luồng dữ liệu  QoS Cứng: là sự đặt trước tài nguyên phục vụ cho một luồng dữ liệu xác định trước thường được cung cấp bởi giao thức RSVP và CBR có trong kiến trúc IntServ  QoS Mềm: trong kiến trúc mạng phân loại (Differentiated service) dựa trên sự phân loại các luồng dữ liệu theo nhiều mức ưu tiên thì một luồng dữ liệu nào đó sẽ được ưu tiên phục vụ tốt hơn các luồn còn lại. Việc lựa chọn loại dịch vụ nào để triển khai trong mạng phụ thuộc vào các yếu tố sau:  Ứng dụng hoặc tính chất của bài toán cần giải quyết  Chi phí cho cài đặt và triển khai dịch vụ 1.3. Kiến trúc QoS cở bản QoS cơ bản bảo gồm có 3 phần chính  Định dạng QoS và các kỹ thuật đánh dấu cho phép QoS phối hợp từ điểm đầu tới điểu cuối giữa từng thành phần mạng.  QoS trong từng thành phần mạng đơn (Các chiến lược, công cụ quản lý, lập lịch hàng đợi).  Các chính sách điều khiển QoS giám sát lưu lượng đầu cuối qua mạng 1.3.1. QoS nhận dạng và đánh dấu Điểm cơ bản trong việc đảm bảo chất lượng cho các dịch vụ trên Internet là việc ta nhận dạng, phân loại và đánh dấu được từng mức ưu tiên cho các dịch vụ để cung cấp các chính sách phục vụ ưu tiên cho các lớp lưu lượng cũng như dịch vụ có độ ưu tiên cao hơn các lớp còn lại. Điều này thường được thực hiện bằng cách dựa vào các trường trong tiêu đều gói tin IP như: IP nguồn, Ip đích, Port nguồn, Port đích, hoặc các giá trị trong trường Type Of Service…
  • 20.
    9 1.3.2. QoS trongmột thiết bị mạng QoS trong một thiết bị mạng thường bao gồm các cơ chế sau: a) Quản lý tắc nghẽn: do sự phát triển của mạng Internet kéo theo sự phát triển mạnh mẽ của các ứng dụng đa phương tiên thời gian thực, các ứng dụng này thường có lưu lượng dữ liệu bùng nổ lớn khiến cho mạng thường xuyên xảy ra tắc nghẽn. Nếu tắc nghẽn xảy ra thì các router sẽ phản ứng như thế nào để giảm thiểu tác hại của tắc nghẽn. b) Quản lý hàng đợi: Vì kích thước của hàng đợi không vô hạn và độ dài của hàng đợi tỉ lệ với độ trễ của gói tin vậy nên cần có cơ chế quản lý hàng đợi hợp lý sao cho lượng gói tin bị drop và độ trễ hàng đợi của gói tin là chấp nhận được cũng như khả năng hấp thu các lưu lượng đột biệt của hàng đợi c) Hiệu suất đường truyền: router phải có các cơ chết kết hợp để đạt được hiệu suất đường truyền cao nhất nhằm tránh lãng phí đường truyền, mặt khác cũng cần phải cân bằng với các tham số QoS khác như độ trễ và tỉ lệ mất gói tin. 1.4. Các mô hình đảm bảo chất lượng dịch vụ 1.4.1. Mô hình các dịch vụ được tích hợp IntServ Mô hình IntServ (Integrated Services) được IETF (Internet Engineering Task Force) giới thiệu vào giữa thập niên 90 và được định nghĩa trong RFC (Request For Comments) 1633. Mô hình này nhằm cung cấp khả năng đảm bảo chất lượng dịch vụ cho một số luồng lưu lượng bằng cách đặt trước tài nguyên từ nguồn tới đích thông qua giao thức đặt trước tài nguyên RSVP. IntServ đưa ra khả năng cho các ứng dụng lụa chọn trong nhiều khả năng các mức điều khiển cho các gói dữ liệu, hỗ trợ QoS theo luồng. Nó yêu cầu kiến trúc phức hợp bao gồm phân loại, xếp hang và định trình dọc theo một tuyến đường truyền bất kỳ từ nguồn tới đích. IntServ phát triển dựa trên nền BestEfford Internet nhưng mở rộng cho các ứng dụng tương tác và thời gian thực. IntServ hỗ trợ cho hai lớp ứng dụng: Các ứng dụng thời gian thực có yêu cầu chặt chẽ về băng thông và độ trễ mà người sử dụng không có được ở mạng chỉ hỗ trợ BestEffort
  • 21.
    10 Các ứng dụngtruyền thống mà trong đó người sử dụng không phải quan tâm đến lưu lượng cũng những người sử dụng khác, khi đó mạng được xem như mạng BestEffort có mức tải thấp. Nguyên lý căn bản của mô hình IntServ là dành riêng tai nguyên mạng: băng thông, độ trễ,… cho từng luồng dữ liệu xuyên suốt từ nguồn phát cho tới đích. Tài nguyên này không được chiếm dụng cho bất cứ một luồng dữ liệu nào khác, vì tài nguyên bị chiếm dụng nhưng nếu không được sử dụng nó sẽ dẫn tới việc lãng phí tài nguyên. Sự ra đời của kiến trúc IntServ nhằm giải quyết các vấn đề sau:  Dịch vụ BestEfford không còn dủ đáp ứng nhu cầu sử dụng hàng ngày: Ngày càng có nhiều ứng dụng khác nhau và có yêu cầu khác nhau về đặc tính lưu lượng được triển khai, đồng thời người sử dụng cũng yêu cầu chất lượng ngày càng cao hơn  Sự xuất hiền ngày càng nhiều của các ứng dụng đa phương tiện: mạng IP phải có khả năng hỗ trợ không chỉ đơn dịch vụ mà còn hỗ trợ đa dịch vụ của nhiều loại lưu lượng khác nhau từ voice, data cho đến video  Tối ưu hóa hiệu suất sử dụng mạng và tài nguyên mạng: đảm bảo hiệu quả sử dụng và đầu tư. Tài nguyên mạng sẽ được lưu trữ cho lưu lượng có độ ưu tiên cao hơn  Cung cấp dịch vụ tốt nhất cho một lớp người sử dụng. Các mức QoS được cung cấp bởi IntServ bao gồm:  Dịch vụ BestEffort  Dịch vụ đảm bảo GS (Guaranteed Service)  Dịch vụ kiểm soát tải CL (Controlled Load) Giao thức dành trước tài nguyên RSVP RSVP là giao thức giành tài nguyên là giao thức được sử dụng bởi Intserv được đề cập trong RFC2205, tự động cập nhật tình trạng đường truyền khi có lỗi xảy ra. RSVP là giao thức điều khiển Internet được thiết kế để cài đặt chất lượng dịch vụ trên mạng IP (RSVP không phải chỉ sử dụng dành riêng với mô hình Intserv). Về tổng quát, giao thức RSVP hoạt động như sau: Khi một node nào đó gửi dữ liệu, nó gửi một bản tin RSVP qua các node trung gian tới nút nhận, bản tin này chứa đặc điểm lưu lượng sẽ gửi, đặc điểm của các node mạng trên đường đi. Node nhận sau khi nhận được thông điệp, căn cứ vào đặc điểm lưu lượng và đặc điểm đường đi, sẽ gửi lại một thông điệp để đăng ký
  • 22.
    11 tài nguyên tạicác node trung gian trên đường đi đó. Nếu việc đăng ký thành công, node gửi bắt đầu truyền dữ liệu. Nếu không, thông điệp đi đến node gửi sẽ báo lỗi. RSVP có thể mang dịch vụ yêu cầu và đáp ứng tương ứng của thành phần chấp nhận luồng từ máy tính tới router, từ router tới router và từ router tới máy đích (hoặc nhiều một máy). RSVP sử dụng 6 thông điệp, “Path” và “Resv”. Thông điệp Resv mang tham số dịch vụ. Thông điệp Path bắt đầu từ nguồn và được gửi tới đích. Mục đích chính của nó là để router biết trên kết nào sẽ chuyển tiếp thông điệp giành tài nguyên (nó cũng bao gồm định nghĩa về đặc điểm lưu lượng của luồng). Thông điệp Error được sử dụng khi việc giành tài nguyên thất bại. RSVP không phải là một giao thức định tuyến do đó nó không cần xác định liên kết nào sẽ được dùng để giành trước mà nó dựa vào các giao thức định tuyến bên dưới để xác định tuyến đường cho một luồng. Một khi tuyến đường được xác định, RSVP bắt đầu thực hiện việc giành trước tài nguyền. Trong suốt quá trình thiết lập để giành tài nguyên, RSVP phải được thông qua mô đun điều khiển về chính sách và mô đun quản lý về việc chấp nhận tuyến đường. Mô đun điều khiển về chính sách xác định xem người dùng có đủ thẩm quyền để giành được nguồn tài nguyên hay không. Thành phần chấp nhận tuyến đường xác định xem nút đó có đủ tài nguyên để cung cấp cho yêu cầu QoS hay không. Nếu cả hai bước kiểm tra đều tốt, các tham số được thiết lập trong bộ phân loại gói và trong bộ lập lịch để đạt được QoS mong muốn. Tiến trình này được thực hiện tại mọi router và máy tính dọc theo tuyến đường. Nếu có xảy ra lỗi, thông điệp RSVP Error được tạo và quảng bá cho mọi nút. Hình 1.3: Mô hình nguyên lý hoạt động của giao thức RSVP Theo hình 1.1, máy gửi gửi bản tin PATH (mô tả thông tin truyền thông qua địa chỉ IP nguồn và địa chỉ IP đích theo chiều đi) đến máy nhận để yêu cầu dành trước tài nguyên và thiết lập một luồng truyền thông. Máy nhận nhận được bản tin PATH sẽ gửi
  • 23.
    12 lại máy gửibản tin RESV (mô tả thông tin truyền thông qua địa chỉ IP nguồn và địa chỉ IP đích theo chiều về) để thiết lập và duy trì việc dự trữ tài nguyên. Khi đi qua các router, dựa vào hai bản tin PATH và RESV, các router đăng ký nhận dạng luồng và lưu đặc tính luồng vào cơ sở dữ liệu. Nếu bản tin PATH lỗi thì bản tin PathErr sẽ được sử dụng để thông báo. Tương tự, RSVP sử dụng bản tin ResvErr để thông báo lỗi cho bản tin RESV. Bên cạnh đó, RSVP còn dùng hai bản tin PathTear và ResvTear. PathTear sử dụng để xóa bỏ tài yêu cầu dành tài nguyên theo hướng đi đã được thiết lập. Tương tự, ResvTear sử dụng để xóa bỏ tài yêu cầu dành tài nguyên theo hướng về. Tại mỗi node mạng, yêu cầu dự trữ tài nguyên gồm 2 hoạt động:  Dự trữ tài nguyên tại một node mạng.  Chuyển tiếp yêu cầu dự trữ tài nguyên cho các node khác còn lại trên mạng. Trong môi trường truyền đa hướng (một máy nhận dữ liệu từ nhiều máy gửi, một máy gửi dữ liệu tới nhiều máy nhận) các yêu cầu dự trữ tài nguyên được chuyển sang một node khác khi node trước đó đã đáp ứng việc dự trữ các yêu cầu tài nguyên. Một đặc điểm quan trọng của RSVP là việc giành tài nguyên được thực hiện bởi “trạng thái mềm”. Có nghĩa là trạng thái giành tài nguyên có liên quan tới một bộ định thời, và khi bộ định thời hết hạn, việc giành trước tài nguyên được loại bỏ. Nếu nơi nhận muốn lưu lại trạng thái giành tài nguyên nào, nó phải đều đặn gửi các thông điệp giành tài nguyên. Nơi gởi cũng phải thường xuyên gửi các thông điệp này. RSVP được thiết kế dành cho kiến trúc Intserv nhưng vai trò của nó cũng được mở rộng cho giao thức báo hiệu trong MPLS 1.4.2. Mô hình các dịch vụ phân biệt DiffServ Sự phát triển mạnh mẽ của mạng Internet và hạ tầng mạng trong những năm gần đây, ngày càng nhiều các tổ chức tham gia cung cấp các dịch vụ Intenet với nhiều loại hình gói cước khác nhau, đáp ứng nhu cầu của nhiều người dùng khác nhau tùy theo khả năng chi trả. Lượng dữ liệu vận chuyển trên Internet ngày càng tăng, để đáp ứng thực tế
  • 24.
    13 đó ngoài sựphát triển mạnh về phần cứng hạ tầng mạng đặc biệt là băng thông mạng, điều quan trọng hơn là phải có những chính sách phục vụ tốt hơn tại các nút mạng. Hình 1.4: Kiến trúc DiffServ đơn giản Trong quá trình triển khai đảm bảo chất lượng dịch vụ cho các ứng dụng đa phương tiện thời gian thực trên Internet, mặc dù kiến trúc IntServ đảm bảo cung cấp QoS một cách chắc chắn nhưng lại chứa khá nhiều nhược điểm như khả năng mở rộng (scalability) trong core network hoặc chi phí cao, cài đặt phức tạp và khó quản lý ở router vì nó phản đảm nhiệm rất nhiều việc dẫn tới làm chậm tốc độ truyền dữ liệu và gia tăng độ trễ end- to-end. Điều này đã tạo ra động lực cho các nghiên cứu rộng hơn để phát triển một giải pháp cung ứng QoS phi trạng thái (stateless), đó là kiến trúc Diffserv (Differentiated services). DiffServ trở thành giải pháp QoS thứ 2 của IETF. Diffserv trái ngược với Intserv là dựa trên từng luồng dữ liệu, nó phân loại các gói thành một số lượng không lớn các tập (gọi là các lớp) và do đó đạt được hiệu quả cho các mạng lớn. Các chức năng đơn giản được thực hiện tại router lõi, trong khi các chức năng phức tạp được triển khai tại các router biên. Tính linh động rất là cần thiết vì dịch vụ mới có thể xuất hiện và một
  • 25.
    14 số dịch vụtrở lên lỗi thời. Kiến trúc DiffServ khắc phục được những nhược điểm của kiến trúc IntServ vì có tính khả triển cao. Tuy nhiên để đáp ứng được các nhu cầu đa dạng của ứng dụng trên thực tế kiến trục được triển khai phải đi kèm các thuật toán quản lý lưu lượng trên đó. Các giải thuật quản lý lưu lượng có thể được phân loại theo thời gian hoạt động của chúng hay theo khả năng điều khiển. Do đó, các giải thuật này có thể hoạt động theo mức gói hay khối dữ liệu hay kết nối. Các nguyên lý phục vụ gói là ví dù về các giải thuật theo mức gói hya khối số liệu, với nhiệu vụ cung cấp các phẩm chất giữa hai đầu cưới thông qua biện pháp phân loại và lập lịch lưu lượng. Trong số các giải pháp điều khiên lưu lượn theo từng cuộc gọi hay từng kết nối thì điểu khiển chấp nhận (admission control) là một trong số các giải pháp phổ dụng nhất. Tùy theo vị trí hoạt động mà có thể là tấp trung hay phân tán. Đại diện tiêu biểu cho điều khiển chấp nhận nối phân tán là giao thức RSVP. Nguyên lý hoạt động của mô hình DiffServ như sau: Các gói tin được phân loại ra thành nhiều nhóm ưu tiên từ thấp đến cao tùy theo đặc điểm của từng dịch vụ, thiết bị sẽ tiến hành cung cấp tài nguyên theo từng nhóm, nhóm nào có thứ tự cao hơn thì sẽ được cung cấp quyền được sử dụng tài nguyên ưu tiên hơn, tài nguyên sẽ được các nhóm thấp hơn dùng nếu nhóm trên không sử dụng nữa. Tất cả các quá trình này sẽ được thực hiện riêng lẻ trên từng thiết bị. Cấu trúc DiffServ Cấu trúc của mô hình DiffServ bao gồm nhiều class lưu lượng cho từng dịch vụ cụ thể và mỗi class được cung cấp một lượng tài nguyên xác định. Để phân biệt các class, DiffServ sử dụng một thông tin gọi là điểm mã phân biệt dịch vụ DSCP (Differentiated Service Code Point). DSCP có tiền thân là vùng ToS (Type of Service) trong IP header. Trong kiến trúc DiffServ chia thành 2 thành phần chính là phần biên và mạng lõi.  Mạng biên: có nhiệm vụ phân loại gói tin và điều kiển lưu lượng, Vị trí này có thể là một nguồn lưu lượng có cài đặt chính sách phân loại gói tin hoặc router hỗ trợ DiffServ đầu tiên (router biên). Tại biên mạng này các gói tin sẽ được đánh dấu vào trường Diffierentiated Service (DS) trong header của các gói tin một giá trị nào đó gọi là Code Point (CP). Các lớp lưu lượng khác nhau sẽ được đánh dấu với
  • 26.
    15 các giá trịCP khác nhau và sẽ nhận được dịch vụ khác nhau trong phần mạng lõi. Sau khi đánh dấu, các gói tin có thể được xếp vào hàng đợi hay chuyển thẳng vào trong mạng lõi  Mạng Lõi: chức năng chính là chuyển tiếp các gói tin. Một gói tin đã được đánh dấu với giá trị CP sẽ được chuyển tới note tiếp theo thông qua từng chính sách (PHB – Per-hop Behavior). PHB ảnh hưởng tới việc chia se băng thông và bộ đệm giữa các lớp lưu lượng cạnh tranh tại router. Hai chính sách quan trọng nhất ứng với mỗi thành phần của DiffServ đó là chính sách phân loại và điều khiển lưu lượng của mạng biên và chính sách đối xử từng chặng PHP của thành phần mạng lõi. a. Phân loại và điều khiển lưu lượng của mạng biên Một packet được đánh dấu vào trường DS của header gói tin IP tại vị trí vào của mạng, nó có thể diễn ra tại một host hỗ trợ DiffServ hoặc router biên hỗ trợ DiffServ. Giả sử rằng việc phân loại và đánh dấu gói tin này được xảy ra ở router kết nối trực tiếp với bên gửi tin được gọi là router biên (edge router). Hình 1.5: Phân loại và đánh dấu gói tin ở router biên Một packet sau khi được gửi sẽ đi tới edge router. Các router phân loại gói tin dựa trên giá trị của một hoặc nhiều trường tiêu đều của packet ví dụ như địa chỉ ip nguồn, địa chỉ ip đích, port nguồn, port đích… hoặc dựa trên tốc độ tới của các gói tin so với ngưỡng. Giá trị trường DS sẽ nhận được một giá trị tại bộ đánh dấu gói tin (Maker). Ngay sau khi được đánh dấu các gói tin sẽ được chuyển đến router tiếp theo
  • 27.
    16 để đi tớiđích. Tại mỗi router có hỗ trợ DiffServ những gói tin đã được đánh dấu này sẽ nhận được lượng dịch vụ dựa theo các đánh dấu của chúng. b. Per-Hop Behavior Sau khi các gói tin đi qua edge router sẽ được phân loại và đánh dấu vào trường DS trong header gói tin và được chuyển tiếp tới các router tiếp theo ở đây là core router, thành phần thứ hai của kiến trúc DiffServ. Tại core router được cài đặt chính sách theo từng chằng PHB và nó chứa những đặc điểm sau:  Các lớp lưu lượng khác nhau (các lớp có giá trị trường DS khác nhau) sẽ nhận được các dịch vụ khác nhau (cách chuyển tiếp khác nhau, băng thông khác nhau,…)  Hiệu năng phải quan sát được và đo được  PHB không chỉ định cụ thể cơ chế nào phải được áp dụng để đạt được mục đích và vì vậy bất kì một có chế quản lý cấp phát tài nuyên hay cơ chế chuyển tiếp nào cũng có thể được sử dụng miễn là đạt được các mục đích tiêu chí hiệu năng mong muốn. Hiện tại có hai chuẩn PHB được chú ý nhiều nhất đó là EF (Expedited Forwarding) và AF (Assured Forwarding)  EF PHB chỉ ra rằng tốc độ gói tin ra khỏi router của một lớp lưu lượng nào đó phải bằng hoặc vượt qua một ngưỡng cho trước. Nghĩa là trong mọi khoảng thời gian lớp lưu lượng đó được đảm bảo nhận được đủ băng thông sao cho tốc độ ra của có vượt qua tốc độ đặt trước này. EF PHB đảm bảo ngay cả khi có nhiều lớp lưu lượng khác đi đến router và tài nguyên của đường truyền thì một lượng đủ tài nguyên vẫn được ta sẵn cho lớp để đảm bảo nó nhận được một tốc độ tối thiểu.  AF PHB thì phức tạp hơn. AF PHB chia lưu lượng thành 4 lớp, trong đó mỗi lớp AFF được đảm bảo cung cấp một lượng băng thông tối thiểu và bộ đệm. Trong mỗi lớp các packet lại được phân vào một trong 3 loại “ưu tiên loại bỏ”. Khi tắc nghẽn xuất hiện trong một lớp AF, router có thể loại bỏ các gói tin dựa trên giá trị ưu tiên loại bỏ của chúng. Bằng cách thay đổi lượng tài nguyên cấp phát cho từng lớp, một nhà cung cấp dịch vụ Internet (ISP) có thể cung cấp các mức độ ưu tiên thực hiện khác nhau có các lớp lưu lượng AF khác nhau. AF PHB có thể được
  • 28.
    17 dùng để cungcấp các mức dịch vụ khác nhau cho các hệ thống cuối. Trong các hệ thống này việc quyết định số lượng các tài nguyên cấp cho từng lớp dịch vụ phải gắn liền với việc giới hạn các thám số liên quan. Ví dụ như có 3 lớp dịch vụ khác nhau là A, B, C trong đó lớp A được cung cấp x% băng thông, lớp B được cung cấp x/2% băng thông, lớp C được cung cấp x/4% băng thông. Thoạt nhìn ta có thể thấy rằng lớp A nhận được lượng băng thông nhiều nhất và có thể nói lớp A được phục vụ tốt hơn lớp B và C. Tuy nhiên nếu ta xét rằng lưu lượng dữ liệu tại lớp A cao gấp nhiều lần lớp B và C thì có thể thấy rằng các gói tin lớp A sẽ được phục vụ ít hơn các gói tin lớp B và C. Như vậy kích thước tài nguyên được cung cấp là chưa đủ để đánh giá chất lượng dịch vụ của một lớp mà phải gắn thêm ràng buộc dữ liệu tối đa cho các gói tin lớp đó nữa. Trong NS-2, các lớp AF được cài đặt với các hàng đợi vật lý khác nhau, trong các hàng đợi đó thì các gói tin ứng với các mức ưu tiên khác nhau được đưa vào một hàng đợi ảo tương ứng. Như vậy ta có tối đa 4 hàng đợi vật lý, mỗi hàng đợi vật lý sẽ có tối đa 3 hàng đợi ảo. Mỗi hàng đợi sẽ có thể cài đặt một chính sách quản lý hàng đợi và phục vụ riêng, có thể là DropTail, RED, RIO-C, RIO-D… 1.5. Kiến trúc DiffServ trong bộ mô phỏng NS2 Trong NS2 modul DiffServ được thược hiện theo “Assured forwarding”. Diffserv dựa trên việc đánh dấu các gói tin tại rìa của mạng (nơi gói tin chuẩn bị đi vào DiffServ network) theo các mức hiệu suất cần đảm bảo, sau đó dựa vào các đánh dấu này các gói tin sẽ có các chính sách xử lý khác nhau tại các nút mạng. Cách dễ dàng nhất để phân biệt các gói tin là sử dụng hàng đợi RED, dùng các tham số khác nhau cho các loại gói tin khác nhau. Modul NS có xử lý diffserv được phát triển ở Nortel network. Diffserv chia các gói tin thành nhiều lớp khác nhau (Tối đa là 8 lớp), Gói tin thuộc lớp nào sẽ được xếp vào hàng đợi của lớp đó, ngoài ra để phân biệt các gói tin trong cùng một lớp người ta chia hàng đợi vật lý này thành 3 hàng đợi ảo. Mỗi gói tin thuộc vào một luồng có thể nhận 3 mức ưu tiên cùng với luồng đó, đôi khi còn được gọi là “Drop precedence” Kiến trúc Diffserv trong NS2 được chia thành 3 phần chính:
  • 29.
    18 - Thành phầnquản lý tài nguyên và chính sách: Xây dựng các chính sách và phân phối chúng cho đến các router hỗ trợ diffserv. Các chính sách này sẽ xác định một gói tin sẽ nhận được mức dịch vụ như thế nào trong mạng. Việc này phụ thuộc vào tính chất tài nguyên của luồng đó và các thành phần của mạng. - Edge Router: chịu trách nhiệm phân loại và đánh dấu các gói tin khi các gói tin này đi vào Diffserv Network - Core Router: thực hiện các chính sách đảm bảo chất lượng dịch vụ cho các gói tin theo từng mức ưu tiên đã được đánh dấu (Per-Hop behavior) 1.5.1. Router MRED (Milti RED) Trong mỗi hàng đợi vật lý được phân ra thành 3 hàng đợi ảo, các hàng đợi ảo này sử dụng thuật toán RED để quản lý các gói tin sau khi được phân loại. Các mode của router MRED được hỗ trợ trong NS2 bao gồm có: - RIO – C (Rio Coupled): Trong đó xác suất loại bỏ các gói tin có độ ưu tiên thấp (các gói tin ngoài luồng) dựa trên độ dài trung bình của tất cả các hàng đợi ảo, xác suất hủy các gói tin có mức ưu tiên cao thì dựa trên kích thước hàng đợi trung bình của hàng đợi ảo chưa gói tin đó. - RIO – D (Rio De-coupled): Xác suất loại bỏ các gói tin dựa trên kích thước hàng đợi trung bình của chính hàng đợi chứa gói tin đó. - WRED (Weight RED): xác suất loại bỏ gói tin dựa trên chiều dài của hàng đợi đơn. - DROP: Giống như hàng đợi Droptail với chiều dài hàng đợi tối đa được chỉ định bằng ngưỡng 𝑚𝑖𝑛 𝑡ℎ của thuật toán RED, khi kích thước hàng đợi trung bình vượt quá ngưỡng 𝑚𝑖𝑛 𝑡ℎ tất cả các gói tin sẽ bị loại bỏ không kể việc gói tin có được đánh dấu hay không. 1.5.2. Các cơ chế đánh dấu gói tin và chính sách phục vụ Khi một luồng các gói tin đi đến một router có hỗ trợ diffserv, các router này sẽ phân loại gói tin và đánh dấu chúng. Trong bộ mô phỏng NS2 thì thành phần này được gọi là các “Policer”. Có 6 loại được sử dụng trong bộ mô phỏng NS2:
  • 30.
    19 1. Time SlidingWindow with 2 Color Marking (TSW2CMPolicer): Sử dụng giá trị CIR và 2 giá trị ưu tiên loại bỏ gói tin. Giá trị ưu tiên thấp hơn thì được sử dụng khi CIR vượt mức cho phép. 2. Time Sliding Window with 3 Color Marking (TSW3CMPolicer): Sử dụng 2 giá trị CIR, PIR và 3 giá trị ưu tiên loại bỏ. Giá trị ưu tiên loại bỏ gói tin cao nhất khi vượt quá PIR, giá trị ưu tiên loại bỏ trung bình khi CIR vượt mức cho phép. 3. Token Bucket (tokenBucketPolicer): Sử dụng 2 giá trị CIR, CBS và 2 giá trị ưu tiên loại bỏ gói tin. Một gói tin đến sẽ được đánh dấu giá trị ưu tiên lớn khi và chỉ khi kích thước gói tin lớn hơn token bucket. 4. Single Rate Three Color Marker (srTCMPolicer)[5]: Sử dụng CIR, CBS, EBS để chọn 3 thứ tự ưu tiên hủy gói tin. 5. Two Rate Three Color Marker (trTCMPolicer): Sử dụng CIR, CBS, PIR, PBS để chọn 3 thứ tự ưu tiên hủy gói tin. 6. NullPolicer: không có thứ tự ưu tiên hủy gói. Các gói tin sau khi đi qua các “Policer” này sẽ nhận được các giá trị ưu tiên “Drop Precedence”. Các giá trị này sẽ được mã hóa thành các CP (code point) và được ghi vào trong trường DS (Differentiated Services) của gói tin IP. Trong đó Các giá trị CIR và PIR được tính là bps, Các giá trị CBS, EBS, and PBS được tính theo byte. 1. CIR (committed information rate) – Tốc độ truyền tin cam kết 2. PIR (peak information rate) – Tốc độ truyền tin tối đa cam kết 3. CBS (committed burst size) – Kích thước bùng nổ cam kết 4. EBS (excess burst size) – Kích thước cụm vượt mức 5. PBS (peak burst size) – Kích thước cụm tối đa 6. C bucket: Kích thước hiện thời của khối dung lượng cho phép 7. E bucket: Kích thước hiện thời của khối dung lượng vượt mức 8. P bucket: Kích thước hiện thời của khối dung lượng tối đa
  • 31.
    20 1.5.3. Các cơchế lập lịch hàng đợi Trong bộ mô phỏng NS2 sử dụng các chế độ lập lịch RR, WRR, WIRR, PIR. Trong đó thì mặc định sử dụng bộ lập lịch RR. Các chế độ lập lịch sẽ được mô tả kỹ hơn trong chương 2 của luận văn. 1.6. Thách thức của việc truyền thông đa phương tiện trên Internet hiện nay 1.6.1. Hạn chế của việc truyền thông đa phương tiện hiện nay Hiện nay giao thức IP trên Internet cung cấp dịch vụ Best-Effort nghĩa là nó cố gắng chuyền các datagram từ nguồn tới đích 1 cách nhanh nhất có thể và không đảm bảo độ trễ và tỉ lệ mất mát gói tin. Các giao thức tầng transport là TCP hoặc UDP cũng không cung cấp các cơ chế đảm bảo về mặt độ trễ gói tin. Do vậy việc truyền thông đa phương tiện trên nên Internet truyền thống gặp rất nhiều trở ngại kìm hãm sự phát triển. Đối với các ứng dụng thời gian thực kèm theo tương tác đòi hỏi độ trễ và jitter cực thấp thì khi xảy ra tắc nghẽn chất lượng dịch vụ có thể tồi đến mức không thể chấp nhận được.  Tỉ lệ mất mát gói tin lớn khi mạng xảy ra tắc nghẽn  Đỗ trễ đầu cuối có thể tăng cao tới mức không thể chấp nhận được  Biến thiên độ trễ là không thể tránh khỏi khiến cho chất lượng âm thanh không chấp nhận được. 1.6.2. Các phương pháp đảm bảo chất lượng dịch vụ trên nền các dịch vụ cố gắng tối đa (best effort) Trong dịch vụ best-effort thì các gói tin được đối xử như nhau nghĩa là không có gói tin nào được ưu tiên hơn trong hàng đợi. Các gói tin khi đi tới router sẽ được đưa vào cuối hàng đợi và chờ đến lượt được phục vụ. Vẫn có 1 số cơ chế để cải thiện chất lượng dịch vụ cho các ứng dụng đa phương tiện trên nên best-effort dựa vào các giao thức tầng giao vận là TCP như: Slow-Start, Window-size hay có thể dừng chạy ở phía nhận khoảng 1 thời gian để loại bỏ các hiệu ứng biến thiên độ trễ. Có thể gửi kèm thông tin dư thừa để khắc phục tình trạng mất mát gói tin khi mạng xảy ra tắc nghẽn.
  • 32.
    21 Chương 2. CÁCCHIẾN LƯỢC QUẢN LÝ HÀNG ĐỢI VÀ KHẢ NĂNG ÁP DỤNG ĐỂ ĐẢM BẢO QOS CHO TRUYỀN THÔNG ĐA PHƯƠNG TIỆN THỜI GIAN THỰC Trong mạng chuyển mạch ip thì các gói tin thuộc các luồng dữ liệu khác nhau được truyền trên cùng đường truyền để đến trạm đích. Để việc phân phối băng thông đường truyền đạt hiệu quả cao nhất thì cần một cơ chế phục vụ công bằng tại các nút mạng hoặc Router. Router ở đây sẽ phục vụ các gói tin của luồng đã chọn và quyết định gói tin nào sẽ được phục vụ tiếp theo. 2.1. Các chiến lược quản lý hàng đợi truyền thống 2.1.1. Hàng đợi FIFO (First in first out) FIFO là hàng đợi mặc định được sử dụng trong hầu hết các router. FIFO không có sự phân loại vì tất cả các gói đều thuộc về cùng một lớp. Các gói đến từ các luồng khác nhau được đối xử công bằng bằng cách đưa vào hàng đợi theo trật tự đến (gói nào đến trước sẽ được đưa vào trước và được phục vụ trước) theo đúng nghĩa First-Come-First- Serve (FCFS) hay First-In-First-Out (FIFO) Hình 2.1: Cơ chế phục vụ FIFO Hàng đợi FIFO sử dụng một hàng đợi đơn cho bộ giao tiếp. Vì chỉ có một hàng đợi nên không cần phân lớp để quyết định khi gói đi vào. Và cũng không cần lập lịch ban đầu để cho hàng đợi lấy gói tiếp theo. Ta chỉ quan tâm đến cách cấu hình chiều dài hàng đợi FIFO tránh tác động đến độ trễ và mất gói. FIFO thường được dùng trên các giao diện (interface) mạng tốc độ cao khó có khả năng xảy ra tắc nghẽn. Đây là một hạn góisGói tin đến Hàng đợi Gói tin đi Link
  • 33.
    22 chế lớn củahàng đợi này vì trong mạng Internet ngày nay có rất nhiều gói tin có độ ưu tiên cao cần xử lý trước tuy nhiên cơ chế FIFO có thể loại bỏ các gói tin này khi hàng đợi đầy hoặc khi tắc nghẽn xảy ra thì sẽ làm gia tăng độ trễ tới mức không chấp nhận được. Đôi khi một luồng lưu lượng bùng nổ lớp sẽ độc chiếm đường truyền khiến cho các luồng khác không được phụ vụ gây bất công bằng giữa các luồng dữ liệu. 2.1.2. Chiến lược hàng đợi ưu tiên PQ ( Priority Queue ) Kĩ thuật này được sử dụng trong trường hợp đa hàng đợi, mỗi hàng đợi có một mức ưu tiên khác nhau, hàng đợi nào có mức ưu tiên cao nhất sẽ được ưu tiên phục vụ trước. Khi có tắc nghẽn xảy ra thì các gói trong các hàng đợi có độ ưu tiên thấp sẽ bị loại bỏ. Nói cách khác, lưu lượng quan trọng sẽ được gán các mức ưu tiên cao và lưu lượng có mức ưu tiên cao nhất được truyền trước, còn lại các lưu lượng ít quan trọng hơn. Hình 2.2: Cơ chế phục vụ hàng đợi ưu tiên PQ Các gói được phân loại dựa trên các tiêu chuẩn phân loại của người sử dụng, và được đặt ở một trong số các hàng đợi đầu ra với các độ ưu tiên: độ ưu tiên cao, trung bình, bình thường (không được ưu tiên), ưu tiên thấp. Các gói không được ấn định độ ưu tiên sẽ được đưa tới các hàng đợi bình thường. Khi các gói được gửi tới giao diện đầu ra, các hàng đợi ưu tiên tại giao diện đó được quét các gói theo thứ tự độ ưu tiên giảm dần. Hàng đợi có độ ưu tiên cao nhất được quét đầu tiên, sau đó đến các hàng đợi trung bình và tiếp tục các hàng đợi có độ ưu tiên khác. Gói đứng đầu hàng đợi có độ ưu góisGói tin đến Hàng đợi 1 Gói tin đi Link Hàng đợi 2 Phân loại
  • 34.
    23 tiên cao nhấtđược truyền đầu tiên. Thủ tục này được lặp lại mỗi khi có một gói được truyền. Chiều dài lớn nhất của hàng đợi được định nghĩa theo chiều dài giới hạn. Khi một hàng đợi dài hơn chiều dài hàng đợi giới hạn thì các gói đến sau sẽ bị loại bỏ. PQ thường được dùng cho các interface băng thông thấp ở đó ta muốn gán mức ưu tiên tuyệt đối cho ứng dụng hay traffic trọng yếu. Mặc dù PQ là cách tiếp cận lập lịch đơn giản nhưng nó có thể gây thiếu hụt băng thông nghiêm trọng cho các luồng có độ ưu tiên thấp. PQ có thể dành hết băng thông cho các luồng có độ ưu tiên cao và dẫn tới việc các luồng có độ ưu tiên thấp không bao giờ được phục vụ. Hiện nay PQ thường được cấu hình tĩnh và không được tùy chỉnh theo sự thay đổi của mạng. 2.1.3. Chiến lược Packet-Based Round Robin Tương tự như chiến lược PQ đã trình bày ở phần trước. Chiến lược này cũng dựa vào việc phân loại các gói tin đến theo từng luồng khác nhau mỗi luồng được xếp vào một hàng đợi và được phục vụ lần lượt theo vòng. Tuy nhiên thay vì phục vụ theo mức ưu tiền thì PBRR lại phục vụ lần lượt quay vòng từng hàng đợi, mỗi hàng đợi chỉ phục vụ 1 gói tin. Nếu hàng đợi nào rỗng thì bộ lập lịch sẽ bỏ qua không phục vụ. Hình 2.3: Cơ chế phục vụ hàng đợi PBRR (Packet-Based Round Robin) góisGói tin đến Hàng đợi 1 Gói tin đi Link Hàng đợi 3 Phân loại Hàng đợi 2
  • 35.
    24 Bộ lập lịchPBRR sẽ đối xử với các luồng dữ liệu giống nhau, nghĩa là không có mức độ ưu tiên dành cho các luồng có mức ưu tiên cao và nó cũng không quan tâm đến độ dài hàng đợi hiện tại khiến cho những luồng có hàng đợi dài chứa nhiều gói tin cũng chỉ được cấp cho một lượng băng thông giống như các luồng khác. Làm giảm hiệu suất sử dụng đường truyền. Không đáp ứng được băng thông cho các luồng dữ liệu multimedia. 2.1.4. Bộ lập lịch lý tưởng GPS - Generalized Processor Sharing Ý tưởng của GPS là trong mỗi khoảng thời gian hữu hạn phải thăm mỗi hàng đợi ít nhất một lần, phục vụ cho một lượng rất nhỏ dữ liệu từ mỗi hàng đợi. Khoảng thời gian và lượng dữ liệu này đủ nhỏ để có thể giả định rằng máy phục vụ (server) có thể phục vụ được tất cả các luồng có gói tin đang chờ một cách đồng thời và các luồng có thể được chia nhỏ tuỳ ý. Đây là một cơ chế lý tưởng vì nó đảm bảo sự phân chia công bằng nhất dành cho các luồng dữ liệu. Tuy nhiên việc cài đặt GPS trong thực tế là không thực hiện được vì trong 1 khoảng thời gian thì server chỉ có thể phục vụ 1 hàng đợi thay vì tất cả các hàng đợi của các luồng dữ liệu và độ dài kích thước gói tin là cố định không thế chia nhỏ tùy ý, gói tin này được phục vụ xong thì gói tin khác mới được phục vụ. Cài đặt đơn giản nhất của GPS là chiến lược Weighted Round Robin (WRR), thay vì thăm mỗi hàng đợi ít nhất một lần và phục vụ một lượng nhỏ dữ liệu tại hàng đợi như GPS thì WRR lại phục vụ một số gói tin tại từng hàng đợi, số gói tin được phục vụ tại từng hàng đợi phụ thuộc vào trong số “Weight” của hàng đợi đó. Trong kiến trúc DiffServ có thể phân biệt các hàng đợi này thông qua giá trị trường DS trong gói tin IP. Một biến thể của WRR là Weighted Interleaved Round Robin (WIRR) về cơ bản thì chiến lược này giống với WRR nhưng có thêm một cơ chế “Interleaved behavior”. Cơ chế này cho phép bộ lập lịch bỏ qua các hàng đợi không có gói tin một khoảng thời gian mà bộ lập lịch phải phục vụ hàng đợi đó. 2.1.5. Chiến lược Flow-Based Weighted Fair Queuing (WFQ) Các chiến lược đã nói trong phần trước đều dựa trên packet-base nghĩa là nó áp dụng cho từng gói tin theo đó mỗi lần phục vụ server sẽ chọn 1 gói tin theo mức độ ưu tiên của nó. Ưu điểm của chiến lược này nó đạt được mức độ công bằng cao cho các gói tin nhưng lại chứa nhiều điểm hạn chế: Thứ nhất là chi phí gán nhãn cho từng gói tin là
  • 36.
    25 lớn và làmgia tăng độ phức tạp thuật toán và tiêu tốn tài nguyên của server. Thứ 2 là các gói tin của cùng 1 luồng sẽ không được phụ vụ cùng 1 lúc mà bị gián đoạn bởi các gói tin của các luồng khác, điều này không phù hợp với các ứng dụng truyền thông đa phương tiện thời gian thực trên Internet cần độ liền mạch các gói tin. Chính vì lẽ đó ta cần 1 cách tiếp cận hay 1 chiến lược khác là việc xác định và gán độ ưu tiên cho một luồng dữ liệu thay vì 1 gói tin riêng lẻ. Các gói tin trong cùng 1 luồng dữ liệu sẽ có cùng 1 độ ưu tiên và được phục vụ liên tục. Server sẽ phục vụ các luồng theo tứ tự ưu tiên hoặc trọng số, các gói tin trong cùng 1 luống sẽ được phục vụ theo cơ chế FIFO nghĩa là gói tin nào đến trước được phục vụ trước. Chiến lược này được gọi là Flow-Base Weighted Fair Queuing. Trong chiến lược WFQ này khi các gói tin tới hàng đợi sẽ được phân chia thành các luồng theo từng mức ưu tiên khác nhau. Mỗi luồng sẽ được xếp vào 1 hàng đợi riêng và nhận được 1 lượng phục vụ tùy theo trọng số của hàng đợi đó. Hình 2.4: Cơ chế WFQ Giả sử mỗi luồng i được gán 1 trọng số 𝑤𝑖. Trong khoảng thời gian phục vụ lớp i sẽ nhận được một lượng phục vụ là: 𝑤𝑖/ ∑ (𝑤𝑖)𝑛 𝑖−𝑛 tổng dung lượng đường truyền trong đó:  n là tổng số luồng có gói tin đang chờ  C là tổng dung lượng đường truyền góisGói tin đến Hàng đợi 1 Gói tin đi Link Hàng đợi 3 Phân loại Hàng đợi 2 𝑤1 𝑤2 𝑤3
  • 37.
    26  Luồng isẽ nhận được 𝐶 ∗ ( 𝑤 𝑖 ∑ (𝑤 𝑖)𝑛 𝑖−𝑛 ) băng thông mỗi lần phục vụ Có nhiều cách xác định trọng số cho từng luồng WFQ, một trong những cách được sử dụng phổ biến nhất là sử dụng các bit ưu tiên (IP precedence bits) của trường TOS (Type of Services) trong header packet ipv4. Đó là 3 bit bên trái nhất của trường TOS. Tổ hợp của 3 bit này tạo nên 6 mức ưu tiên từ 0 – 5, các mức 7, 8 được dành riêng và không được phép sử dụng. Như vậy dựa vào các bit trên ta có thể phân chia thành 6 luồng khác nhau với các mức ưu tiên. Giả sử chúng ta có 6 luồng với 6 mức ưu tiên khác nhau (IP precedence = 0 ÷ 5), mỗi luồng sẽ chiếm 1 lượng băng thông đường truyền là (IP precedence + 1)/(tổng dung lượng đường truyền). Tổng dung lượng đường truyền là: 1 + 2 +3 + 4 + 5 + 6 = 21 Các luồng sẽ nhận được lần lượt là 1/21, 2/21, 3/21, 4/21, 5/21, 6/21 dung lượng đường truyền. Hình 2.5: IP Precedence bits Như vậy có thể thấy rằng WFQ thực hiện phân phối dải thông đường truyền một cách công bằng cho các luồng dữ liệu dựa vào mức ưu tiên của chúng. Có thể nó rằng WFQ đảm bảo được chất lượng dịch vụ có phân loại hay còn gọi là QoS mềm. Trên thực tế WFQ thường được dùng trong trường hợp mạng yêu cầu thời gian đáp ứng nhất quán khi tải nặng cũng như khi tải nhẹ trong khi băng thông không thay đổi. Nó đảm bảo cho Ipv4 header payload TOS Bytes 3 bits IP precedence bits
  • 38.
    27 hàng đợi lúcnào cũng có băng thông và lượng dịch vụ dành cho mỗi luồng là có thể dự đoán trước được. WFQ còn có thể được kết hợp với giao thức đặt trước tài nguyên RSPV - Resource Reservation Protocol để cung cấp QoS cứng. 2.1.6. Chiến lược Class-Based Weighted Fair Queuing (CBQ) Không giống như WFQ, CBQ được thiết kế nhằm đảm bảo băng thông cho các lớp lưu lượng do người dùng đặt trước mà vẫn đảm bảo phân phối công bằng cho các luồng trong lớp đó. CBQ cung cấp nhiều hàng đợi riêng biệt, mỗi hàng đợi có thể phân chia thành nhiều lớp, các luồng này có thể được xác định dựa vào các tiêu chi như giao thức (FTP, HTTP, Telnet, SSh..) hoặc danh sách điều khiển truy cập (Access list). Các gói tin thỏa mãn các tiêu chí được xếp chung vào 1 lớp Class-Based Weighted Fair Queuing (CBQ) là cơ chế queuing được dùng để reserve (giành trước) một lượng bandwidth tối thiểu cho một loại lớp lưu lượng (traffic class) khi xảy ra nghẽn. Lệnh bandwidth trong policy-map sẽ được dùng để tính toán ra giá trị weight cho lớp đó. Công thức tính weight của mỗi lớp có liên quan đến bandwidth của interface, vì vậy việc cấu hình đúng bandwidth của interface (thỏa với tốc độ vật lý của đường link) là rất quan trọng. CBQ cho phép người quản trị mạng xác định chính xác lượng băng thông được cấp phát cho 1 luồng lưu lượng cụ thể dựa vào băng thông có sẵn mà WFQ không làm được – Tính trọng số ưu tiện dựa vào các bit trong trường ToS chứ không phải do người dùng đặt trước. Điều ngày giúp người quản trị có thể phân phối cho một lớp lưu lượng đặc biệt nào đó một lượng băng thông tối thiểu đủ để hoạt động Xét 1 ví dụ có một luồng thoại thời gian thực yêu cầu băng thăng tối thiểu bằng một nửa dung lượng đường truyền T1 (1.544Mbps). Nếu chỉ có 2 luồng dữ liệu ta hoàn toàn có thể sử dụng WFQ để phân phối. Tuy nhiên vấn để xảy ra khi có thêm nhiều luồng dữ liệu tham gia vào đường truyền khi đó đặc tính của WFQ sẽ phân phối giải thông công bằng cho các luồng, như vậy luồng thoại thời gian thực ban đầu sẽ không có đủ lượng băng thông yêu cầu là một nữa đường truyền T1. Khác với WFQ khi sử dụng
  • 39.
    28 CBQ thì hoàntoàn có thể cấu hình dành 1 nửa đường truyền T1 cho luồng dữ liệu thoại thời gian thực này. Luồng này được đưa vào 1 lớp và có đủ băng thông để hoạt động, các luồng còn lại được xếp vào một lớp khác và chia sẻ một nửa băng thông còn lại. CBQ còn hỗ trợ chia sẻ băng thông giữa các lớp bằng cách sử dụng cấu trúc cây phân lớp, để hiểu rõ hơn chúng ta cùng xét ví dụ dưới đây. Tại mức cao nhất người quản trị chia sẻ đường truyền cho 3 người dùng khác nhau. Tại mức này từng người đùng sẽ chia sẻ băng thông họ nhận được cho các ứng dụng theo một tỉ lệ nào đó, quá trình lặp lại cho đến khi ứng dụng nhận được phần băng thông được cấp phát để truyền. Hình 2.6: Chia sẻ băng thông trong CBQ Trong quá trình hoạt động có những lớp không sử dụng hết băng thông được cấp phát, lượng băng thông này sẽ được chia sẻ cho các lớp còn lại, các lớp cùng cấp có thể mượn số băng thông này thông qua lớp cha của nó, lớp nào có ưu tiên cao hơn sẽ mượn được nhiều bằng thông hơn. CBQ đã được cài đặt trên linux bằng cách dùng thuật toán từ bộ mô phỏng NS2. Cài đặt ban đầu của CBQ là WRR (Weighted Round Robin), trong linux là DRR links Agency A 40% Agency B 30% Agency C 30% HTTP 20% FTP 10% POP3 10% TCP 10% IP 20% HTTP 20% SSH 10% RTP 10% FTP 10%
  • 40.
    29 (Deficit Round Robin).Chính sách chia sẻ băng thông được sử dụng trong DRR như sau: Khi lớp A có độ ưu tiên cao hơn lớp B, cả 2 đang mượn băng thông từ lớp C thì A sẽ lấy phần băng thông nó cần sau đó phần băng thông còn lại sẽ dành cho B, nếu độ ưu tiên của lớp A và B bằng nhau thì 2 lớp sẽ cùng nhận được 1 lượng băng thông chia sẻ giống nhau. 2.2. CÁC CHIẾN LƯỢC QUẢN LÝ HÀNG ĐỢI ĐỘNG Trong lý thuyết hàng đợi người ta chứng minh được rằng thời gian trung bình mà các gói tin đi qua hàng đợi bao gồm thời gian các gói tin phải chờ trong hàng đợi cộng với thời gian chúng được phục vụ, tỉ lệ thuận với chiều dài hàng đợi, tỉ lệ nghịch với tốc độ gói tin đến hàng đợi trung bình. Mục tiêu chính của các chiến lược quản lý hàng đợi là giữ cho chiều dài hàng đợi trung bình đủ nhỏ và ổn định. Đảm bảo độ trễ trung bình của các gói tin không vượt quá ngưỡng cho phép đồng thời đạt được hệ số sử dụng đường truyền cao. Hai yêu cầu này là trái ngược nhau chính vì vậy cần có một sự thỏa hiệp. Để biểu diễn đại lượng này người ta đưa ra một đại lượng là “Công suất”, đó là tỉ lệ giữa thông lượng và độ trễ. Điểm tối ưu là điểm có hiệu suất cực đại. Trong chương này sẽ trình bày về các chiến lược quản lý hàng đợi động AQM và một số thuật toán tiêu biểu. Các chiến lược này nhằm đáp ứng các mục tiêu đã nêu phía trên. Trước khi tìm hiểu về các chiến lược quản lý hàng đợi động chúng ta hãy xem xét chiến lược quản lý hàng đợi truyền thống và các nhược điểm của nó. 2.2.1. Chiến lược quản lý hàng đợi truyền thống và hệ quả Các cách tiếp cận quản lý hàng đợi truyền thống đều dựa trên cơ chế FIFO như đã trình bày ở phần trước. Với các cơ chế này thì gói tin khi tới gateway hoặc router sẽ được xếp vào hàng đợi, khi hàng đợi đầy thì các gói tin tới sau sẽ bị loại bỏ. Các gói tin tới trước sẽ được phụ vụ trước và hàng đợi này được mô phỏng trong bộ mô phỏng NS2 với tên gọi “DropTail”. Do tính đơn giản và dễ cài đặt mà nó được sử dụng trong nhiều năm trên Internet tuy nhiên do sự phát triển mạnh mẽ của mạng Internet ngày nay nó xuất hiện nhiều nhược điểm mà nổi bật nhất là hai nhược điểm sau đây
  • 41.
    30 a. Hiện tượngGlobal Synchronization Theo cơ chế FIFO, chúng ta nói rằng các luồng khác bị “Lock Out” tại một thời điểm khi xuất hiện một luồng lưu lượng bùng nổ khiến cho hàng đợi bị chiếm độc quyền, các gói tin của các luồng lưu lượng khác không được nhận vào vì hàng đợi đầy. Khi xảy ra hiện tượng lockout nếu các thực thể sử dụng giao thức TCP để truyền thì chúng sẽ bị TimeOUT. Theo thuật toán tránh tắc ngẽn của TCP chúng sẽ đồng loạt giảm cửa số phát, thực hiện rút lui theo hàm mũ làm cho lưu lượng trên mạng đồng loại giảm nhanh chóng gây lãng phí băng thông đường truyền, làm giảm hiệu suất sử dụng. Hiện tượng đồng loạt giảm lưu lượng đó được gọi là hiện tượng đồng bộ toàn cầu – Global synchronization. b. Hiện tượng hàng đợi đầy (Full Queue) Hàng đợi FIFO có thể thường xuyên nằm trong trạng thái đầy trong trong thời gian dài nếu có nhiều luồng lưu lượng, vì cơ chế FIFO chỉ loại bỏ gói tin khi hàng đợi đã đầy. Lưu lượng trên mạng thường xuyên có sử bùng nổ và các gói tin tới các node mạng thường theo cụm nên bộ đệm tại các node mạng phải đủ lớn để hấp thu các lưu lượng bùng nổ này. Nhược điểm của nó là khi tăng kích thước bộ đêm để hấp thu các lưu lượng bùng nổ đồng thời sẽ làm gia tăng độ trễ và thăng giáng độ trễ. Ưu tiên sẽ là lựa chọn một cơ chế quản lý hàng đợi tốt thay vì tăng kích thước hàng đợi tại node mạng. Ngoài “DropTail” còn có 2 phương pháp khác có thể được sử dụng là loại bỏ gói tin ngẫu nhiên “Random Drop” và loại bỏ gói tin ở đầu “Drop Front”. Tư tưởng của Random Drop là các router sẽ loại bỏ ngẫu nhiên các gói tin trong hàng đợi để dành chỗ cho các gói tin đến. Còn với phương pháp Drop Front thì router sẽ loại bỏ các gói tin ở đầu hàng đợi. Cả 2 phương pháp này đều có thể khắc phục được hiện tượng “Lock-out” nhưng không khắc phục được hiện tượng đầy hàng đợi (Full Queue). 2.2.2. Ưu điểm các chiến lược quản lý hàng đợi động Như đã nói ở trên thì các chiến lược quản lý hàng đợi truyền thống sẽ loại bỏ gói tin khi hàng đợi đầy, điều nay không hợp lý vì đôi khi hàng đợi đầy thì hiện tượng tắc nghẽn đã trở nên khó kiểm soát. Giải pháp hợp lý cho trường hợp này là loại bỏ gói tin
  • 42.
    31 trước khi hàngđợi đầy khi đó các thực thể gửi và nhận sẽ nhận biết và phản ứng với tắc nghẽn ngay khi hiện tượng tắc nghẽn bắt đầu xảy ra. Đây chính là tư tưởng chính của các chiến lược quản lý hàng đợi động – Active Queues Managerment AQM. Điểm cần chú ý rằng các chiến lược quản lý hàng đợi động này chỉ có hiệu quả đối khi được gắn với các giao thức vận chuyển có cơ chế kiểm soát lưu lượng (Flow control) như TCP, và nó không có hiệu quả đối với các giao thức như UDP. Các chiến lược quản lý hàng đợi động sẽ đem lại những ưu điểm sau: a. Giảm độ trễ và giảm thăng giáng độ trễ Việc loại bỏ sớm các gói tin khi tắc nghẽn chưa xảy ra sẽ giữ kích thước hàng đợi ở mức trung bình đủ nhỏ và làm giảm độ trễ một cách đáng kể. Điều này vô cùng quan trọng với các ứng dụng thời gian thực như voice, video thời gian thực b. Làm giảm số lượng gói tin bị loại bỏ tại các node mạng Mạng Internet ngày nay sự bùng nổ lưu lượng các gói tin là không thể tránh khỏi. Với chiến lược quản lý hàng đợi truyền thống kích thước hàng đợi tăng rất nhanh khi lưu lượng bùng nổ, các gói tin bị loại bỏ sẽ tăng nhanh khi hàng đợi đầy. Việc sử dụng các chiến lược quản lý hàng đợi động sẽ giúp cho kích thước hàng đợi nằm trong một khoảng trung bình đủ nhỏ, hàng đợi sẽ hấp thu các thăng giáng lưu lượng dễ dàng hơn khiến cho số gói tin bị loại bỏ giảm, hệ số sử dụng đường truyền tăng, việc khôi phục các gói tin bị mất đơn lẻ cũng dễ dàng hơn với TCP. c. Tránh hiện tượng Lock-out Hiện tượng lock-out xảy ra khi hàng đợi đầy, gói tin khi đi tới node mạng sẽ không được xếp vào hàng đợi vì không còn chỗ trống. AQM sẽ đảm bảo cho hàng đợi luôn luôn có chỗ trống dành cho các gói tin tới do đó tránh được hiện tượng này. Chúng ta sẽ tiến hành nghiên cứu 1 số thuật toán quản lý hàng đợi động tiêu biểu như RED, A-RED và RIO.
  • 43.
    32 2.2.3. Thuật toánRED trong chiến lược quản lý hàng đợi động a. Giới thiệu thuật toán RED Khi có dấu hiệu của tắc nghẽn xảy ra trong mạng, hàng đợi tài router đầy thì router bắt đầu loại bỏ các gói tin đến. Đối với các luồng lưu lượng TCP thì đây là tín hiệu thông báo tắc nghẽn xảy ra và báo hiệu các nguồn phát giảm lưu lượng để giảm bớt tắc nghẽn. Có hai vấn đề quan trọng cần giải quyết: Thứ nhất là đối với các luông TCP thì các gói tin bị loại bỏ sẽ được truyền lại, điều này làm tăng tải trong mạng đồng thời phát sinh thêm độ trễ. Thứ hai là hiện tượng đồng bộ toàn cầu đã nói ở phân trên. Năm 1993 hai nhà khoa học của phòng thí nghiệm Lawrence Berkeley thuộc đại học California, Mỹ là Sally Floyd và Van Jacobson đã đề xuất thuật toán quản lý hàng đợi động AQM – một trong những thuật toán quản lý hàng đợi đầu tiên là RED – Random Early Detection of congestion, Random Early Drop. Với như ưu điểm vượt trội so với các thuật toán quản lý hàng đợi truyền thống nên RED đã được triển khai rộng rãi trên mạng Internet. Việc phát hiện sớm tắc nghẽn và phản ứng lại để giữ đường truyền ổn định thường được thực hiện trên các gateway. Các thực thể nguồn cũng có thể làm điều này thông qua thời gian phục vụ ước lượng tại gateway, thông qua độ trễ end-to-end, qua sự thay đổi thông lượng hoặc số lượng các gói tin bị loại bỏ. Tuy nhiên khung nhìn của một kết nối cụ thể bị giới hạn bởi thời gian phát tin và số lượng dữ liệu phát, ngoài ra nó cũng không thể biết được gateway nào đang tắc nghẽn, không phân biệt được độ trễ lan truyền và độ trễ hàng đợi. Chỉ có các Gateway là có cái nhìn đúng đắn nhất về trạng thái của hàng đợi, sự chia sẻ đường truyển của các kết nối đi qua nó tại mọi thời điểm cũng như yêu cầu chất lượng dịch vụ của các dòng lưu lượng. Các RED gateway sẽ theo dõi độ dài trung bình của hàng đợi để dựa vào đó phán đoán sớm tắc nghẽn sắp xảy ra (chiều dài của hàng đợi vượt quá một ngưỡng được định trước) và phản ứng một cách thích hợp đối với các gói tin đến theo hai cách:  Loại bỏ các gói tin đến theo một xác suất nhất định được định trước nhằm gián tiếp thông báo cho nguồn về sự tắc nghẽn đồng thời giữ kích thước hàng đợi nằm trong một ngưỡng đủ nhỏ  Đánh dấu cờ “có tắc nghẽn” theo một xác suất nhất định vào trường ECN trong header của các gói tin để báo cho bên nguồn biết.
  • 44.
    33 b. Tư tưởngvà nguyên tắc thiết kế thuật toán Mục đích chính của các RED gateway là điều khiển kích thước hàng đợi nằm trong một vùng đủ nhỏ được định nghĩa trước và ổn định. Ngoài ra nó còn tránh hiện tượng Global-Synchronization và không chống lại các luồng có lưu lượng đột biến, Duy trì kích thước hàng đợi ngay cả khi không có sự hợp tác từ các giao thức tầng giao vận Để đạt được những mục tiêu trên RED gateway phải làm được các công việc sau: - Phát hiện sớm tắc nghẽn và giữ kích thước hàng đợi trung bình đủ nhỏ làm cho mạng hoạt động ở vùng có độ trễ thấp, thông lượng cao, trong khi vẫn cho phép hàng đợi giao động trong một miền nhất định để hấp thu các luồng có lưu lượng đột biến hoặc độ thăng giáng cao. RED gateway là nơi thích hợp nhất để phát hiện tắc nghẽn và cũng là nơi thích hợp nhất để quyết định chọn kết nối cụ thể nào để thông báo tắc nghẽn. - Thông báo tới nguồn phát về tắc nghẽn có thể xảy ra. Việc này được thực hiện bằng cách đánh dấu và thông báo cho nguồn phát giảm lưu lượn xuống. Thông thường RED gateway sẽ loại bỏ gói tin, tuy nhiên nếu tắc nghẽn được phát hiện sớm thì thay vì loại bỏ nó RED gateway sẽ có 2 lựa chọn là đánh dấu hoặc loại bỏ gói tin. Việc đánh dấu gói tin được thực hiện bằng cách đánh dấu vào trường ECN trong header của gói tin với một xác suất nhất định để báo hiệu cho nguồn giảm lưu lượng đưa vào mạng. - Mục tiêu quan trọng cần đạt được là tránh hiện tượng Global-synchronization và không chống lại các luồng có lưu lượng đột biến. Như đã trình bày ở các phần trước hiện tượng này xảy ra khi các thực thể phát đồng loại giảm kích thước cửa sổ phát làm lưu lượng giảm nhanh trong cùng một thời điểm. Các chiến lược như Droptail hoặc Random Drop rất nhạy cảm với các luồng lưu lượng đột biến tức là các hàng đợi tại gateway thường sẽ bị tràn khi các gói tin của luồng này tới. Để tránh hiện tượng này các RED gateway phải chọn các gói tin ngẫu nhiên tới để đánh dấu. Với phương pháp này xác suất đánh dấu một gói tin từ một kết nối cụ thể tỉ lệ với phần băng thông được chia sẻ cho kết nối đó tại gateway. - Một mục tiêu quan trọng nữa của RED gateway cần đạt được đó là giữ kích thước hàng đợi trung bình ngay cả khi không có sự hợp tác từ các thực thể nguồn phát (nguồn phát sử dụng giao thức UDP). Có thể thực hiện điều này bằng cách loại bỏ
  • 45.
    34 gói tin khikích thước trung bình của hàng đợi vượt qua ngưỡng trên thay vì đánh dấu nó. Phương pháp này là cần thiết trong trường hợp hầu hết các kết nối có khoảng thời gian phát nhỏ hơn thời gian đợi gói tin khứ hồi hoặc các thực thể nguồn không có các cơ chế kiểm soát lưu lượng để phản ứng với việc đánh dấu hay loại bỏ gói tin (như các luồng UDP) c. Giải thuật và các tham số cho thuật toán RED RED gateway tính kích thước hàng đợi trung bình bằng cách sử dụng bộ lọc thông thấp LPF (Low Pass Filter). Kích thước hàng đợi trung bình được so sánh với hai ngưỡng : Ngưỡng dưới 𝑚𝑖𝑛 𝑡ℎ và ngưỡng trên 𝑚𝑎𝑥𝑡ℎ. Khi kích thước hàng đợi trung bình nhỏ hơn ngưỡng dưới thì không gói tin nào bị đánh dấu hoặc loại bỏ, Khi kích thước hàng đợi trung bình nằm trong khoảng 𝑚𝑖𝑛 𝑡ℎ đến 𝑚𝑎𝑥𝑡ℎ thì RED gateway sẽ đánh dấu các gói tin đến với một xác suất 𝑝 𝑎. Trong đó 𝑝 𝑎 là một hàm theo kích thước hàng đợi trung bình avg. Xác suất đánh dấu một gói tin của một kết nối cụ thể tỉ lệ với phần băng thông chia sẻ của kết nối đó tại gateway. Giải thuật được mô tả trong giải mã sau: Hình 2.7: Giải thuật tổng quát cho RED gateway Như vậy giải thuật tại RED gateway được chia thành hai thuật toán tách biệt: Thuật toán tính kích thước hàng đợi trung bình quyết định mức độ bùng nổ cho phép trong hàng đợi tại gateway và Thuật toán tính xác suất đánh dấu quyết định mức độ thường xuyên đánh dấu gói tin của gateway. Giải thuật đánh dấu gói tin phải đảm bảo sao cho các gói tin đánh dấu tại những khoảng thời gian đều nhau để tránh hiện tượng đồng bộ toàn cầu trong khi vẫn giữ kích thước hàng đợi trunh bình ở một khoảng nhất định Giải thuật chi tiết được mô tả dưới đây: Với mỗi gói tin đến gateway Tính toán kích thước hàng đợi trung bình avg Nếu 𝑚𝑖𝑛 𝑡ℎ < kích thước hàng đợi trung bình avg < 𝑚𝑎𝑥𝑡ℎ Tính xác xuất 𝑝 𝑎 Với 𝑝 𝑎: Đánh dấu các gói tin đến Nếu 𝑚𝑎𝑥𝑡ℎ < kích thước hàng đợi trung bình avg Đánh dấu gói tin đến
  • 46.
    35 Hình 2.8: Giảithuật RED chi tiết Khởi tạo: avg ← 0 count ← -1 for mỗi gói tin đến Tính kích thước hàng đợi trung bình avg: if hàng đợi không rỗng avg ← (1- 𝑤𝑞) avg + 𝑤𝑞*q else m ← f(time – q_time) avg ← (1-𝑤𝑞)m avg if 𝑚𝑖𝑛 𝑡ℎ≤ avg < 𝑚𝑎𝑥𝑡ℎ count ++ Tính xác suất 𝑝 𝑎: 𝑝 𝑎 ← 𝑚𝑎𝑥 𝑝 (agv – 𝑚𝑖𝑛 𝑡ℎ)/( 𝑚𝑎𝑥𝑡ℎ - 𝑚𝑖𝑛 𝑡ℎ) 𝑝 𝑎 ← 𝑝 𝑏 / (1 – count. 𝑝 𝑏) với xác suất 𝑝 𝑎: đánh dấu gói tin đến count ← 0 else if avg ≥ 𝑚𝑎𝑥𝑡ℎ đánh dấu gói tin đến count ← 0 else count ← -1 Khi Khi hàng đợi trở nên rỗng q_time ← time
  • 47.
    36 Hình 2.9 Cáctham số thuật toán RED Theo giải thuật, mỗi khi có một gói tin đi đến hàng đợi, RED gateway sẽ tính kích thước hàng đợi trung bình bằng bộ lọc: avg ← (1- 𝑤𝑞) avg + 𝑤𝑞*q trong đó : q là kích thước hàng đợi trung bình hiện thời; 𝑤𝑞 là trọng sô của hàng đợi và nhận giá trị trong khoảng 0..1. 𝑤𝑞 còn gọi là hệ số làm trơn và quyết định độ lớn và độ kéo dài cho phép của sự bùng nổ lưu lượng. Xác suất đánh dấu gói tin 𝑝 𝑎 tăng chậm khi số gói tin từ gói cuối cùng được đánh dấu count tăng lên. Điều này đảm bảo cho gateway không phải chờ quá lâu trước khi đánh dấu một gói tin. RED gateway đánh dấu tất cả các gói tin nếu như kích thước hàng đợi trung bình avg vượt quá 𝑚𝑎𝑥𝑡ℎ Thêm 1 tùy chọn trong RED để đảm bảo xác suất để một gói tin bị loại bỏ tỉ lệ với thông lượng tính bằng bit/s chứ không phải packet/s. Trong trường hợp này thì một gói tin lớn sẽ dễ bị loại bỏ hơn một gói tin có kích thước nhỏ. 𝑝 𝑏 = 𝑃𝑎𝑐𝑘𝑒𝑡𝑆𝑖𝑧𝑒 𝑀𝑎𝑥𝑃𝑎𝑐𝑘𝑒𝑡𝑆𝑖𝑧𝑒 ∗ 𝑚𝑎𝑥𝑝 ∗ 𝑎𝑣𝑔−𝑚𝑖𝑛 𝑡ℎ 𝑚𝑎𝑥 𝑡ℎ−𝑚𝑖𝑛 𝑡ℎ Các biến thay đổi: avg: kích thước hàng đợi trung bình q_time: thời gian hàng đợi bắt đầu rỗng count: số gói tin từ gói cuối cùng bị đánh dấu Các tham số cố định: 𝑤𝑞: trọng số hàng đợi 𝑚𝑖𝑛 𝑡ℎ: ngưỡng dưới của hàng đợi 𝑚𝑎𝑥𝑡ℎ: ngưỡng trên của hàng đợi 𝑚𝑎𝑥 𝑝: xác suất loại bỏ tối đa Các tham số khác: 𝑝 𝑎: xác suất đánh dấu gói tin hiện tại q: kích thước hàng đợi hiện tại time: thời gian hiện tại f(t): một hàm tuyến tính của thời gian t
  • 48.
    37 Có bốn thamsố cố định cần đặt trước trong thuật toán RED. Việc thiết lập các thuật toán này là rất quan trọng vì nó ảnh hưởng tới chất lượng cũng như hiệu suất thuật toán. Để mang lại hiệu quả cao nhất cho thuật toán chúng tôi sẽ trình bày song song hai cách thiết lập các tham số: Định tính và định lượng (bằng mô phỏng) để có thể chọn ra một bộ tham số hợp lý và đêm lại hiệu quả cao nhất. Tất cả mô phỏng trong luận văn này đều được thực hiện trên bộ mô phỏng NS-2. Các tham số đầu vào được tác giả trong [3] nghiên cứu rất kỹ bằng mô phỏng, sau khi lặp lại các mô phỏng đó và thấy rằng các kết quả đó là hoàn toàn chính xác. d. Trọng số hàng đợi 𝒘 𝒒 Kích thước hàng đợi trung bình trong thuật toán RED được RED gateway tính toán bằng cách sử dụng bộ lọc thông thấp. Sự gia tăng kích thước hàng đợi hiện tại do luồng lưu lượng bùng nổ hoặc sử tắc nghẽn ngắn hạn sẽ không ảnh hưởng tới kích thước hàng đợi kích thước hàng đợi trung bình: avg ← (1- 𝑤𝑞) avg + 𝑤𝑞*q trong đó trọng số hàng đợi 𝑤𝑞 đóng vai trò quyết định giá trị của avg. Nhìn vào công thức trên có thể thấy răng nếu 𝑤𝑞 quá lớn thì kích thước hàng đợi trung bình avg sẽ bám sát kích thước hàng đợi vào thời điểm hiện tại, khiến cho hàng đợi trống rất ít. RED gateway sẽ không thể hấp thu được các luồng có lưu lượng bùng nổ. Cận trên cho 𝒘 𝒒 Giả sử ban đầu hàng đợi rỗng (kích thước trung bình bằng 0), sau đó khi có các gói tin đến, số gói tin trong hàng đợi sẽ tăng từ 0 đến L (giả sử có L gói tin đi đến hàng đợi) lúc này kích thước hàng đợi trung bình sẽ được tính như sau: 𝑎𝑣𝑔 𝐿 = ∑ 𝑖𝑤𝑞(1 − 𝑤𝑞) 𝐿−𝑖𝐿 𝑖=1 =𝑤𝑞(1 − 𝑤𝑞) 𝐿 ∑ 𝑖( 1 1−𝑤 𝑞 )𝑖𝐿 𝑖=1 = L + 1 + (1−𝑤 𝑞) 𝐿−𝑖−1 𝑤 𝑞 Với ngưỡng 𝑚𝑖𝑛 𝑡ℎ cho trước và chúng ta muốn cho phép RED gateway hấp thu bùng nổ đến L gói tin thì kích thước hàng đợi trung bình 𝑎𝑣𝑔 𝐿 < 𝑚𝑖𝑛 𝑡ℎ L + 1 + (1−𝑤 𝑞) 𝐿−𝑖−1 𝑤 𝑞 < 𝑚𝑖𝑛 𝑡ℎ
  • 49.
    38 Cận dưới cho𝒘 𝒒 Thuật toán RED được thế kế sao cho RED gateway luôn giữ hàng đợi ở mức trung bình nằm dưới một ngưỡng nào đó. Tuy nhiên nếu giá trị 𝑤𝑞 được thiết lập quá thấp thì avg sẽ phản ứng rất chậm với sự thay đổi nhanh của hàng đợi thực khiến cho gateway không thế phát hiện được sự bắt đầu của tắc nghẽn. Theo các nghiên cứu và thực nghiệm về thuật toán RED người ta khuyến cáo 𝑤𝑞 ≥ 0.001. Tùy điều kiện của mạng thực tế có thể lựa chọn 𝑤𝑞 nằm trong khoảng (0.002,0.003). e. Xác suất loại bỏ gói tin 𝒎𝒂𝒙 𝒑 Số lượng gói tin bị loại bỏ tại RED gateway phụ thuộc vào giá trị của 𝑚𝑎𝑥 𝑝 và sẽ quyết định kích thước hàng đợi trung bình avg sẽ nằm trong khoảng nào giữa 𝑚𝑖𝑛 𝑡ℎ và 𝑚𝑎𝑥𝑡ℎ. Vì thế tùy từng yêu cầu của mạng trong thực tế mà chúng ta lựa chọn giá trị 𝑚𝑎𝑥 𝑝 phù hợp. Đối với mạng ít xảy ra tắc nghẽn thì nên thiết lập giá trị 𝑚𝑎𝑥 𝑝 nhỏ để tận dụng tối đa đường truyền và giảm số gói tin bị loại bỏ. Giá trị phù hợp ở đây thường là 𝑚𝑎𝑥 𝑝 = 0.02. Tuy nhiên đối với mạng hay xảy ra tắc nghẽn thì giá trị 𝑚𝑎𝑥 𝑝 thường được thiết lập lớn hơn. Giá trị thường được chọn là 𝑚𝑎𝑥 𝑝 = 0.1 f. Thiết lập ngưỡng 𝒎𝒊𝒏𝒕𝒉 và 𝒎𝒂𝒙𝒕𝒉 Để thiết lập được giá trị tối ưu cho 𝑚𝑖𝑛 𝑡ℎ và 𝑚𝑎𝑥𝑡ℎ cần xem xét tới rất nhiều yếu tố, trong đó có kích thước hàng đợi trung bình mong muốn avg. Giá trị 𝑚𝑖𝑛 𝑡ℎ và 𝑚𝑎𝑥𝑡ℎ cần phải thoải mãn các yêu cầu sau: - Để tận dụng tối đa đường truyền thì 𝑚𝑖𝑛 𝑡ℎ và 𝑚𝑎𝑥𝑡ℎ cần được thiết lập giá trị cao trong trường hợp lưu lượng trên mạng ít đột biến - Nếu lưu lượng trong mạng thường xuyên có đột biến thì 𝑚𝑖𝑛 𝑡ℎ và 𝑚𝑎𝑥𝑡ℎ cần được thiết lập giá trị nhỏ để có thể hấp thu các lưu lượng này. Tuy nhiên khi thiết lập giá trị nhỏ cho 𝑚𝑖𝑛 𝑡ℎ và 𝑚𝑎𝑥𝑡ℎ khiến cho hiệu suất sử dụng đường truyền thấp gây lãng phí dải thông, số gói tin bị loại bỏ không cần thiết sẽ cao hơn. Vì vậy cần cân bằng giữa việc tận dụng tối đa đường truyền và khả năng hấp thu lưu lượng bùng nổ sao cho hiệu suất sử dụng đường truyền là cao nhất.
  • 50.
    39 - Khoảng giátrị 𝑚𝑖𝑛 𝑡ℎ và 𝑚𝑎𝑥𝑡ℎ ảnh hưởng tới biến thiên độ trễ, thông lượng và khả năng hấp thu các đột biến tạm thời tại hàng đợi. Để tránh hiện tượng đồng bộ toàn cầu thì không nên đề khoảng giá trị này quá nhỏ. Theo khuyến nghị thì nên thiết lập 𝑚𝑎𝑥𝑡ℎ gấp đôi giá trị 𝑚𝑖𝑛 𝑡ℎ 2.2.4. Thuật toán A-RED Điều khiển tắc nghẽn đầu cuối được sử dụng rộng rãi trong các mạng ngày này để ngăn chặn tắc nghẽn xảy ra. Tuy nhiên do lưu lượng dữ liệu đến các router dưới dạng luồng nên các router cần được cung cấp hàng đợi lớn để hấp thu các lưu lượng bùng nổ giúp duy trì việc sử dụng các kết nối. Khi tắc nghẽn xảy ra tại các router các gói tin sẽ bị gia tăng độ trễ hàng đợi. Do đó cần phải chọn lựa giữa hiệu suất sử dụng đường truyền cao (Kích thước hàng đợi lớn) hay độ trễ hàng đợi nhỏ (Kích thước hàng đợi nhỏ). Thuật toán quản lý hàng đợi RED thì tích cực hơn do sử dụng quá trình loại bỏ ngẫu nhiên bằng việc thay đổi kích thước hàng đợi trung bình. Mục tiêu chính của RED là phối hợp giữa kích thước hàng đợi trung bình và thông báo tắc nghẽn sớm để đạt được độ trễ hàng đợi trung bình thấp và thông lượng cao Chiến lược quản lý hàng đợi động bằng cách sử dụng thuật toán RED cho phép mạng đồng thời đạt được cả thông lượng cao và độ trễ thấp. Tuy nhiên RED có hai yếu điểm cơ bản cần phải được khắc phục. Thứ nhất là kích thước hàng đợi trung bình nhạy cảm với các cấp đội tắc nghẽn và các tham số đầu vào thiết lập trên router. Đối với mạng có sự thay đổi lớn về các cấp độ tắc nghẽn thì việc thiết lập một bộ tham số đầu vào cho RED gateway là khó. Độ trễ là một thành phần chính của QoS cấp phát cho người dùng, để đạt được độ trễ trung bình có thể đoán trước thì cần phải liên tục hiệu chỉnh các tham số đấu vào của thuật toán RED đáp ứng sự thay đổi liên tục của lưu lượng dữ liệu trên mạng. Điểm yếu thứ hai của RED là thông lượng cũng nhạy cảm với tải và các thông số đầu vào của RED. Thường thì khi kích thước hàng đợi trung bình avg lớn hơn 𝑚𝑎𝑥𝑡ℎ thì thuật toán RED không còn hiệu quả dẫn tới việc giảm đáng kể thông lượng và tăng tỷ lệ loại bỏ gói tin. Để tránh hiện tượng này thì cũng cần liên tục điều chỉnh các tham số đầu vào của thuật toán RED.
  • 51.
    40 a. Giải thuậtA-RED A-RED ra đời nhằm khắc phục hai nhược điểm của RED nguyên bản được đề xuất bởi Feng từ năm 1997[17]. Cấu trúc RED vẫn được giữ nguyên và chỉ hiệu chỉnh thông số 𝑚𝑎𝑥 𝑝 để duy trì kích thước hàng đợi trung bình trong khoảng 𝑚𝑖𝑛 𝑡ℎ đến 𝑚𝑎𝑥𝑡ℎ. Có nhiều phiên bản A-RED được đưa ra tuy nhiên trong giới hạn luận án này chúng tôi giới thiệu một phiên bản thuật toán A-RED trong đó người quản trị viên có thể lựa chọn chế độ tự động thiết lập các tham số đầu vào cho RED gateway dựa trên độ trễ mong muốn và kích thước miền hàng đợi trung bình mong muốn. Như vậy thuật toán A-RED này có thể tự động thiết lập tất cả các tham số đầu vào của thuật toán RED dựa trên kết quả mong muốn đạt được tránh trong những hạn chế lớn của RED 𝑚𝑎𝑥 𝑝 được hiểu chỉnh không chỉ cho kích thước hàng đợi trung bình nằm trong ngưỡng 𝑚𝑖𝑛 𝑡ℎ, 𝑚𝑎𝑥𝑡ℎ mà còn giữ kích thước hàng đợi trung bình nằm trong một dải cho phép nằm trong khoảng 𝑚𝑖𝑛 𝑡ℎ, 𝑚𝑎𝑥𝑡ℎ. Giá trị 𝑚𝑎𝑥 𝑝 được duy trì nằm trong khoảng từ 0.01 đên 0.5. Bằng mô phỏng có thể thấy rằng A-RED đạt được độ dài hàng đợi trung bình đích với một miền rộng các kịch bản, có nghĩa là nó giữ nguyên được những ưu điểm của RED. Điều này giúp quản trị viên dự đoán được độ trễ hàng đợi trung bình và hạn chế khả năng kích thước hàng đợi trung bình vượt quá ngưỡng 𝑚𝑎𝑥𝑡ℎ từ đó giảm tỉ lệ mất gói tin và sự thăng giáng độ trễ hàng đợi. b. Giải thuật và các tham số trong thuật toán A-RED Thuật toán A-RED cơ bản chia làm hai thuật toán chính la: Thuật toán RED và thuật toán hiệu chỉnh 𝑚𝑎𝑥 𝑝, 𝑚𝑖𝑛 𝑡ℎ, 𝑚𝑎𝑥𝑡ℎ. Sau đó 𝑚𝑎𝑥 𝑝 lại được dùng trong thuật toán RED. Thuật toán hiệu chỉnh 𝑚𝑎𝑥 𝑝 được trình bày như Hình 2.10:
  • 52.
    41 Hình 2.10: Giảithuật tổng quát cho A-RED gateway Giới hạn trên của giá trị 𝑚𝑎𝑥 𝑝 = 0.5 có thể được chỉnh sửa theo cách cố gắn tối ưu RED để tốc độ loại bỏ gói tin nhỏ hơn 50% 2.2.5. Thuật toán RIO Giới thiệu chung Phần này chúng ta sẽ nghiên cứu về việc áp dụng các thuật toán quản lý hàng đợi động trong kiến trúc các dịch vụ phân loại Diffserv. Kiến trúc này được định nghĩa bời IETF nhằm cung cấp cho mạng IP sự đảm bảo chất lượng dịch vụ cho các lưu lượng khác nhau cùng chia sẻ kênh truyển chung. Bằng việc sử dụng cờ đánh dấu trong một số trường đặc biệt của gói tin IP để báo cho Router biết cách xử lý nào được áp dụng cho mỗi gói tin. Điển hình của thuật toán quản lý hàng đợi động được áp dụng cho kiến trúc mạng dịch vụ phân loại DiffServ là thuật toán A-RIO (Adaptive RED with IN and OUT). Thuật toán này là sự kết hợp của A-RED và thuật toán RIO được đề xuất bởi Julio Orozco, David Ros với mục đích chính bao gồm: - Áp dụng cho kiến trúc mạng DiffServ nhằm đảm bảo chất lượng dịch vụ cho các dịch vụ trong trường hợp nhiều luồng lưu lượng cùng chia sẻ một kênh truyền bằng việc sử dụng các bit trong trường TOS của gói tin ip. Every interval giây: if (avg > target and 𝑚𝑎𝑥 𝑝 ≤ 0.5) tăng 𝑚𝑎𝑥 𝑝: 𝑚𝑎𝑥 𝑝 = 𝑚𝑎𝑥 𝑝 + α; elseif (avg < target and 𝑚𝑎𝑥 𝑝 ≥ 0.01) giảm 𝑚𝑎𝑥 𝑝: 𝑚𝑎𝑥 𝑝 = 𝑚𝑎𝑥 𝑝 * β; Biến: avg: kích thước hàng đợi trung bình Các tham số cố định: interval: thời gian; 0.5 giây target: target for avg: [𝑚𝑖𝑛 𝑡ℎ + 0.4 * (𝑚𝑎𝑥𝑡ℎ – 𝑚𝑖𝑛 𝑡ℎ), 𝑚𝑖𝑛 𝑡ℎ + 0.6 * (𝑚𝑎𝑥𝑡ℎ – 𝑚𝑖𝑛 𝑡ℎ)] α: hệ số tăng; min(0.01, maxp / 4); β: hệ số giảm; 0.9
  • 53.
    42 - Đơn giảnhóa cấu hình cho Router bằng việc tính toán tự động để chuyển đổi các tham số đầu vào sang tham số routers. - Cố gắng giữ hàng đợi ở mức trung bình ổn định quanh một giá trị khi tải nặng không phụ thuộc vào hiện trạng lưu lượng a. Ý tưởng Thuật toán RIO Đối với các thuật toán như RED, A-RED router chỉ thực hiện tính toán hàng đợi trung bình sau đó tiến hành đánh dấu hoặc loại bỏ gói tin, các gói tin đều được đối xử bình đẳng với nhau và không có sự phân biệt ưu sự ưu tiên. Tuy nhiên trong thực tế hiện nay khi mà tốc độ phát triển mạnh của Internet khiến cho sự đa dạng trong dịch vụ cũng tăng. Người dùng hoàn toàn có thể yêu cầu nhà cung cấp để được sự ưu tiên cao hơn và chấp nhận trả chi phí lớn hơn. Nếu sử dụng thuật toán RED hoặc A-RED cho trường hợp này thì không thể giải quyết được bài toán, các luồng (ứng dụng) đã trả nhiều tiền hơn cũng chỉ được cung cấp 1 lượng dịch vụ như những luồng khác. Chính vì lẽ đó thuật toán RIO ra đời dựa trên sự cải tiến của thuật toán RED bằng cách phân chia các gói tin đến theo hai mức ưu tiên là “In” và “Out”. Việc gắn thẻ cho mỗi gói tin phụ thuộc vào thỏa thuận giữa khách hàng và nhà cung cấp dịch vụ theo đó, các gói tin có gắn thẻ “In” nghĩa là các gói tin này nằm trong dịch vụ đã được thỏa thuận trước, các gói tin có gắn thẻ “Out” có nghĩa là không nằm trong hồ sơ dịch vụ. Khi tắc nghẽn xảy ra các router sẽ ưu tiên loại bỏ các gói tin có gắn thẻ “Out” nhanh hơn. Tuy nhiên RIO không phân tách các luồng thành các lớp hoặc các hàng đợi khác nhau mà gộp tất cả chung vào một hàng đợi. RIO là viết tắt của RED with In/Out bit. Vì được cải tiến từ RED nên nó có đầy đủ các ưu điểm của RED như đạt thông lượng cao, hiệu suất sử dụng đường truyền lớn, độ trễ thấp, kích thước hàng đợi trung bình nhỏ ngoài ra nó còn phân biệt các gói tin theo hai mức ưu tiên là “In” và “Out”. Việc sử dụng bộ đôi thuật toán RED cho các gói tin “In” và “Out” với thiết lập thông số khác nhau khiến cho các gói tin “Out” bao giờ cũng bị loại bỏ sớm hơn khi tắc nghẽn xảy ra. b. Giải thuật Tương tự như RED nhưng RIO được thiết lập hai bộ tham số riêng biệt, một bộ dành cho các gói tin với thẻ “In” và một bộ tham số dành cho gói tin thẻ “Out”. Khi một
  • 54.
    43 gói tin đitới RIO gateway nó sẽ kiểm tra xem gói tin này có gắn thẻ “In” hay “Out” và tính toán hàng đợi trung bình tương ứng với các gói tin. Nếu gói tin đi tới có gắn cơ “In” thì RIO gateway sẽ tính avg_in, ngược lại nếu gói tin đi tới có gắn thẻ Out thì RIO gateway sẽ tính avg_total. Xác suất loại bỏ gói tin “In” phụ thuộc vào kích thước hàng đợi trung bình avg_in và xác suất loại bỏ gói tin “Out” phụ thuộc vào kích thước hàng đợi trung bình avg_total. Giải thuật được mô tả như Hình 2.11 dưới đây: Hình 2.11 Giải thuật RIO RIO gateway sẽ loại bỏ hầu hết các gói tin có gắn thẻ “Out” khi tắc nghẽn bắt đầu xảy ra và khi tắc nghẽn kéo dài sẽ loại bỏ toàn bộ các gói tin “Out”, Các gói tin “In” rất ít khi bị loại bỏ trừ trường hợp tắc nghẽn xảy ra do toàn bộ các gói tin “In”. Tuy nhiên với mạng được điều khiển tốt thì trường hợp này rất ít khi xảy ra và nếu xảy ra trường hợp đó thì mạng có thể coi là không chấp nhận được. Chưa có bất cứ chuẩn mực nào trong việc lựa chọn avg_total sao cho hợp lý. Nếu ta chọn avg_out dành cho các gói tin “Out” thì việc lựa chọn tham số cho hàng đợi trung For mỗi gói tin đến if nó là gói tin In tính kích thước trung bình hàng đợi In: avg_in; tính kích thước trung bình hàng đợi tổng avg_total; if nó là gói tin In if min_in < avg_in < max_in tính xác suất 𝑃𝑖𝑛; loại bỏ gói tin này với xác suất 𝑃𝑖𝑛; else if max_in < avg_in loại bỏ gói tin này. if nó là gói tin Out if min_out <avg_total < max_out tính xác suất 𝑃𝑜𝑢𝑡; loại bỏ gói tin này với xác suất 𝑃𝑜𝑢𝑡; else if max_out <avg_total loại bỏ gói tin này;
  • 55.
    44 bình này rấtkhó và không có sự tương quan rõ ràng nào giữa các tham số dành cho gói in “In”. Việc sử dụng avg_total dành cho cả hai loại gói tin giúp cho RIO gateway có thể giữ được kích thước hàng đợi trung bình đủ nhỏ và đạt được thông thượng cao bất kể lưu lượng nào trộn lẫn vào. 2.2.6. Thuật toán A-RIO Đây là một mở rộng trực tiếp từ thuật toán A-RED và RIO. A-RIO đi theo cách tiếp cận của thuật toán A-RED, các thông số đầu vào của thuật toán được hiệu chỉnh online một cách tự động nhằm đạt được hiệu suất mong muốn đã đặt trước, có nhiều cách tiếp cận được đưa ra nhằm hiệu chỉnh các thông số thuật toán RED theo kết quả mong muốn đạt được, A-RED được chọn vì tính đơn giản trong cài đặt của nó. Giống như A-RED, A-RIO chỉ cần một tham số đầu vào là độ trễ mà người dùng mong muốn đạt được, A-RIO sẽ tự động ánh xạ sang tập các tham số đầu vào. Đặc trưng này rất có ý nghĩa đối với nhà cung cấp dịch vụ phân loại cấu hình router theo độ trễ - một độ đo QoS liên quan trực tiếp đến đặc tả dịch vụ và đặc tả yêu cầu người dùng, dễ hiểu hơn rất nhiều so với các tham số trìu tượng như các ngưỡng hàng đợi, xác suất loại bỏ gói tin hoặc trọng số trung bình. Do là mở rộng trực tiếp từ thuật toán A-RED nên A-RIO vẫn giữ được những ưu điểm và đặc trung của A-RED như:  Xác suất loại bỏ gói tin 𝑚𝑎𝑥 𝑝 chạy từ 0.01 đến 0.5  Ngưỡng dưới 𝑚𝑖𝑛 𝑡ℎ được tính theo độ trễ hàng đợi mong muốn (đích) 𝑑 𝑡 và dung lượng đường truyền C (packet/s) với cận dưới là 5 gói tin thì: 𝑚𝑖𝑛 𝑡ℎ = max(5, 𝑑 𝑡. 𝐶/2). Ngưỡng 𝑚𝑎𝑥𝑡ℎ luôn được tính cố định bằng 3. 𝑚𝑖𝑛 𝑡ℎ  𝑤𝑞 cũng được tính theo dung lượng đường truyền: 𝑤𝑞 = 1 − exp(−1/𝐶)  Nếu tải thay đổi một cách đột ngột thì kích thước hàng đợi trung bình có thể nằm ngoài khoảng mục tiêu, khi đó các tham số α, β được chọn cố định sao cho kích thước hàng đợi trung bình sẽ quay trở lại miền mục tiêu trong vòng 25 giây.
  • 56.
    45  Hàm hiệuchỉnh 𝑚𝑎𝑥 𝑝 (𝑖) được tính theo luật AIMD (tăng theo cấp số cộng, giảm theo cấp số nhân) nhằm tránh sự thay đổi đột ngột của 𝑚𝑎𝑥 𝑝 (𝑖) dẫn tới sự dao động mạnh của kích thước hàng đợi. Trên đây là một số thuật toán quản lý hàng đợi động điển hình, ngoài ra còn nhiều thuật toán khác là biến thể từ các thuật toán trên nhưng không được đề cập trong nội dung luận văn, các thuật toán đều có ưu, nhược điểm riêng tùy vào từng trường hợp mạng cụ thể mà người ta có thể chọn chiến lược sao cho đạt được hiệu quả cao nhất. Chương tiếp theo sẽ trình bày mô phỏng để đánh giá các thuật toán quản lý hàng đợi động RED và FIFO truyền thống, áp dụng thuật toán RED trong kiến trúc mạng DiffServ nhằm đảm bảo chất lượng dịch vụ cho các ứng dụng đa phương tiện thời gian thực trên Internet.
  • 57.
    46 Chương 3. ĐÁNHGIÁ HIỆU QUẢ ĐẢM BẢO QOS CHO TRUYỀN THÔNG ĐA PHƯƠNG TIỆN THỜI GIAN THỰC CỦA MỘT SỐ CHIẾN LƯỢC QUẢN LÝ HÀNG ĐỢI 3.1. Đánh giá bằng mô phỏng hiệu quả của thuật toán RED Các mô phỏng trong luận văn này được thực hiện trên bộ mô phỏng NS-2 đã được cộng đồng nghiên cứu và sử dụng rộng rãi đặc biệt là trong các trường đại học và các viện nghiên cứu. Sau đây là phần trình bày mô phỏng của tôi nhằm đánh giá và so sánh hiệu suất của thuật toán RED so với DropTail Hình 3.1: Cấu hình mạng mô phỏng DropTail & RED Mô phỏng đánh giá hiệu suất của thuật toán RED so với DropTail, mỗi loại tôi đưa ra 3 đồ thị biểu diễn đó là : Kích thước hàng đợi trung bình, thông lượng, và kích thước cửa sổ của mỗi kết nối TCP để tìm ra ưu nhược điểm của 2 giải thuật quản lý hàng đợi này. Mạng mô phỏng bao gồm 6 nút, các luồng tcp1, tcp2, tcp3 được gắn vào các nút 1, 2, 3. Luồng udp được gắn vào nút 4, đường truyền chia sẻ từ nút 0 đến nút 5, tại đây sử dụng hàng đợi RED hoặc DropTail, tất cả các kết nối đều là full-duplex và mặc định không lỗi.
  • 58.
    47  Kết nốitừ nút 0 đến nút 1, 2, 3 có băng thông 10Mbps, độ trễ 1ms.  Kết nối từ nút 0 đến nút 4 có băng thông 2Mbps, độ trễ 10ms.  Kết nối từ nút 0 đến nút 5 có băng thông 2Mbps, độ trễ 20ms. Sử dụng hàng đợi RED hoặc DropTail  Các thực thể gắn với 3 luồng TCP ở đây là giao thức FTP (ftp1, ftp2, ftp3). Kích thước các gói tin TCP được gửi đỉ là 1000byte với kích thước cửa sổ tối đa là 100 gói tin. Các thực thể này phát gói tin theo thời gian ngẫu nhiên trong khoảng từ 0 – 3s từ lúc bắt đầu chạy mô phỏng.  Thực thể gắn với luồng udp ở đây là nguồn phát CBR (Nguồn phát sinh lưu lượng không đổi có tốc độ phát là 2Mbps). Thực thể udp bắt đầu sinh lưu lượng vào khoảng 5 – 7s và từ 8 – 10s để tạo lưu lượng đột biến  Hàng đợi được đặt trên kết nối từ node 0 đến node 5 kích thước 100 gói tin. Toàn bộ mô phỏng được chạy trong khoảng thời gian 50s.  Các tham số được thiết lập cho RED như sau: minth = 5, maxth = 15, maxp = 0.1 và wq = 0.002. Sau khi chạy mô phỏng 2 thuật toán trên với cùng một kích bản mô phỏng chúng thu được kết quả: Chiến lược Số gói tin (packet) Kích thước hàng đợi trung bình (packet) Độ trễ hàng đợi trung bình (ms) Hệ số sử dụng đường truyền (%) DropTail 11944 73.00 389.33 95.55 RED 11728 8.00 42.67 93.82 Bảng 3.1: So sánh RED với DropTail
  • 59.
    48 Hình 3.2: Môphỏng DropTail Hình 3.3: Mô phỏng RED a) Kích thước hàng đợi trung bình a) Kích thước hàng đợi trung bình b) Kích thước cửa sổ b) Kích thước cửa sổ c) Thông lượng trung bình các kết nối c) Thông lượng trung bình các kết nối
  • 60.
    49 Nhận xét vềkết quả mô phỏng chiến lược DropTail: Nhìn đồ thị có thể thấy được rằng hiện tượng lockout xảy ra khi có lưu lượng đột vào khoảng thời gian từ 5 – 7s và từ 8 – 10s (Nguồn CBR sinh lưu lượng có tốc độ cao hơn dung lượng đường truyền tại nút 0) dẫn tới việc các kết nối TCP đồng loạt giảm kích thước cửa sổ phát, dẫn tới việc thông lượng của các kết nốt TCP giảm đột ngột về gần bằng 0. Ngay cả khi nguồn CBR đã ngừng hoạt động vào khoảng 10 - 12s thì thông lượng của các luồng TCP vẫn giảm về gần 0 do cơ chế rút lui theo hàm mũ của TCP trong khi đó thì hàng đợi vẫn đầy. DropTail đã không tránh khỏi hiện tượng Global Synchronization. Ngay cả khi nguồn CBR không hoạt động thì hiện tượng Global Synchronization vẫn xảy ra vào các khoảng thời gian 24s, 34s, 44s, khi các kết nối TCP cùng tăng kích thước cửa sổ phát đạt đến ngưỡng và đồng loạt giảm. Kích thước trung bình của hàng đợi luôn giữ ở mức rất cao. Nhận xét về kết quả mô phỏng chiến lược RED: Trong gian đoạn 12s đầu tiên khi có lưu lượng đột biến vào mạng thì các kết nối TCP giảm kích thước cửa sổ phát dẫn tới việc thông lượng của các kết nối này giảm tuy nhiên ngay sau đó chúng đã tăng kích thước cửa sổ phát và thông lượng cũng tăng ngay sau đó, kích thước hàng đợi có tăng nhưng nhanh chóng giảm và giữ ở mức ổn định. Trong khoản thời gian còn lại không có đột biến lưu lượng thì RED luôn duy trì kích thước hàng đợi trung bình trong 1 khoảng nhỏ trong khoảng từ 6 – 10 gói tin. Nhận xét: Nhìn chung có thể thấy rằng chiến lược DropTail không tránh được hiện tượng Global synchronization không hỗ trợ chia se băng thông công bằng giữa các kết nối nhất là khi có lưu lượng bùng nổ vào mạng thì không giữ được các kết nối đã có sẵn. RED tránh được hiện tượng lockout và Global synchronization. Việc giữ kích thước hàng đợi đủ nhỏ nên đạt được độ trễ hàng đợi nhỏ hơn nhiều lần so với DropTail trong khi vẫn giữ được hệ số sử dụng đường truyền cao. 3.2. Đánh giá bằng mô phỏng việc áp dụng kiến trúc mạng Diffserv có sử dụng RED Việc mô phỏng đảm bảo chất lượng dịch vụ cho các ứng dụng thời gian thực trên Internet dựa trên kiến trúc mạng DiffServ được thực hiện trên bộ mô phỏng NS2. Trong kết nối TCP việc mất mát một số gói tin thường ảnh hưởng nhiều tới hiệu năng của phiên
  • 61.
    50 kết nối sovới đa số các gói tin còn lại. Những gói tin này thường là những gói tin điều khiển thiết lập kết nối, điều khiển lưu lượng, kiểm soát lỗi. Ta gọi những gói tin này là những gói tin có độ ưu tiên cao. Việc đánh dấu các gói tin này và cung cấp chất lượng dịch vụ cao hơn trong kiến trúc DiffServ sẽ làm hiệu suất của TCP được cải thiện đáng kể. Tuy nhiên việc đánh dấu gói tin yêu cầu các thành phần lớp mạng biết về thông tin lớp vận chuyển. Mục đích của mô phỏng mà chúng tôi giới thiệu để chỉ ra rằng có thể đánh dấu ưu tiên các gói tin quan trọng mà không cần bất kỳ thông tin nào của lớp vận chuyển, vì vậy sẽ đơn giản hóa các việc thực hiện đánh dấu các gói tin TCP. Về phân loại dịch vụ thường có 3 mức ưu tiên được định nghĩa. Mức ưu tiên cao nhất thường được gọi là “in policy” hay Green packets, mức ưu tiên thấp hơn chia thành 2 mức là Yellow Packets và thấp nhất là Red packets hay “Out policy”. Thuật toán RED được sử dụng trong hàng đợi nhằm tránh tắc nghẽn còn trong kiến trúc mạng DiffServ thì thuật toán RED được sử dụng để loại bỏ các gói tin có đánh dấu “Out Policy” 3.2.1. Cấu hình mạng mô phỏng Chúng ta sẽ xem xét một topo mạng đơn giản để mô phỏng mạng DiffServ trong đó ký hiệu các router biên là EDGE1 và EDGE2, còn router lõi là Core, hàng đợi sử dụng giữa router biên và router core là hàng đợi MRED, Các thực thể gửi và nhận là UDP sender và UDP Rec. Nguồn phát là nguồn CBR (nguồn sinh lưu lượng với tốc độ không đổi), băng thông và độ trễ được mô tả đầy đủ trong Hình 3.4 Hàng đợi được sử dụng giữa các Router EDGE và các thực thể gửi, nhận là hàng đợi DropTail. Topo mạng này có một nút cổ chai tại hàng đợi từ router EDGE1 đến router CORE.
  • 62.
    51 Hình 3.4: Topomạng mô phỏng Mỗi node gửi sẽ được kết nối với node nhận tương ứng với lưu lượng được đánh dấu theo các tham số đã chỉ rõ. Có 3 node nguồn, mỗi node sẽ liên tục gửi các gói tin UDP tới các node đích (được ghi nhãn với số thứ tự tương ứng). Tổng tốc độ gửi của 3 node là (600,000bps*3)=1,800,000bps. Mô phỏng trên mạng LAN có tốc độ cao, độ trễ thấp và đường truyền đối xứng. Mô hình lưu lượng: Đảm bảo chất lượng dịch vụ cho node UDP Sender 0  Node UDP Sender 1 sẽ bắt đầu truyền từ 0.1s  Node UDP Sender 0 sẽ bắt đầu truyền từ 5.0s  Nodd UDP Sender 2 sẽ bắt đầu truyền từ 15.0s Hàng đợi MRED được xây dựng tại router EDGE1, do băng thông đường truyền giữa Router EDGE1 với router CORE chỉ có 1Mbps nên nhỏ hơn tổng tốc độ truyền của 3 Node nên ở đây sẽ xảy ra tắc nghẽn. Hàng đợi MRED tại đây sử dụng mode RIO-C và chia thành 3 hàng đợi vật lý, mỗi hàng đợi vật lý lại chia thành 3 hàng đợi ảo, các tham số hàng đợi là giống nhau. Mục đích của việc này không phải để tìm một bộ tham số tối ưu để đạt được hiệu năng cần thiết cho mô phỏng, thay vào đó ta sẽ thử nghiệm dựa trên các điều kiện tham số đầu vào để nghiên cứu ảnh hưởng của Kiến trúc Diffserv đến việc đảm bảo chất lượng dịch vụ cho các ứng dụng có dộ ưu tiên cao.
  • 63.
    52 Có 3 mứcưu tiên được định nghĩa dựa trên chính sách Single Rate Three Color Marker (srTCMPolicer): Sử dụng các tham số CIR, CBS, EBS để phân loại và đánh dấu các gói tin thành “Green packets”, “Yellow packets”, “Red packets”. Gói tin được đánh dấu là Green khi chưa vượt qua ngưỡng CBS, được đánh dấu là Yellow khi vượt qua ngưỡng CBS nhưng chưa vượt qua ngưỡng EBS và được đánh dấu là Red khi vượt qua ngưỡng EBS. Mô phỏng dựa trên 3 hàng đợi vật lý, mỗi kết nối từ node nguồn đến node đích được gán trên một hàng đợi vật lý riêng. Chế độ lập lịch cho hàng đợi sử dụng trong mô phỏng là WIRR với các trọng số lần lượt là 6, 3, 1 cho hàng đợi 0, 1, 2. Kết quả mô phỏng đối với trường hợp tắc nghẽn thấp tại do tốc độ truyền của nguồn UDP Sender 0 thấp. Hình 3.5: So sánh thông lượng các kết nối UDP
  • 64.
    53 Hình 3.6: Sosánh kích thước hàng đợi trung bình Hình 3.7: So sánh độ trễ hàng đợi trung bình
  • 65.
    54 Code Point Góitin nhận Gói tin gửi Drop RED Drop All 9743 5889 689 3165 10 333 333 0 0 11 500 500 0 0 12 2542 2542 0 0 20 167 142 25 0 21 200 98 52 50 22 2258 1078 109 1071 30 174 174 0 0 31 200 200 0 0 32 3369 822 503 2077 Bảng 3.2: Thông kê gói tin Source Packet send Packet loss Lost rate (%) UDP Sender 0 3368 0 0 UDP Sender 1 2587 1289 49.7 UDP Sender 2 3666 2487 67.38 Bảng 3.3: Thống kê Từng kết nối
  • 66.
    55 Kết quả môphỏng 2: Thay đổi tốc độ truyền của UDP Sender 0 từ 600.000bps lên 1.000.000bps Hình 3.8: So sánh thông lược các kết nối UDP Hình 3.9: So sánh kích thước hàng đợi trung bình
  • 67.
    56 Hình 3.11: Sosánh độ trễ hàng đợi trung bình Thống kê các gói tin CP Gói tin nhận Gói tin gửi Drop RED Drop All 11993 6029 1027 4937 10 333 333 0 0 11 500 368 0 132 12 4792 2994 0 1798 20 167 140 27 0 21 200 99 68 33 22 2258 1072 108 1078 30 174 171 3 0 31 200 200 0 0 32 3369 652 821 1896 Bảng 3.4: Thông kê gói tin trường hợp tắc nghẽn nhiều
  • 68.
    57 Source Packet sendPacket loss Lost rate (%) UDP Sender 0 5601 1922 34.3 UDP Sender 1 2592 1296 50.0 UDP Sender 2 3627 2640 72.7 Bảng 3.5: Thống kê Từng kết nối Nhận xét về các kết quả mô phỏng được: Việc sử dụng bộ lập lịch WIRR để đảm bảo băng thông tối thiểu cho hàng đợi 0 khiến cho thông lượng kết nối UDP Sender 0 – UDP Rec 0 luôn giữ ở mức trung bình khoảng 600Bps, kết nối có kích thường hàng đợi trung bình và độ trễ hàng đợi rất thấp. Với việc thiết lập tốc độ truyển của UDP Sender 0 là 600.000bps ngang bằng với phần băng thông được chia sẻ của hàng đợi 0 (0.6Mbps) khiến cho kích thước hàng đợi trung bình gần như bằng 0, các packet sau khi tới hàng đợi được xử lý luôn. Sau khi thiết lập tốc độ truyền tăng cường lên 1Mbps thì tại hàng đợi 0 bắt đầu xảy ra tắc nghẽn do băng thông chia sẻ không đáp ứng kịp tốc độ truyền. Khi đó thuật toán RED trên hàng đợi bắt đầu có tác dụng. Việc áp dụng kiến trúc Diffserv để phân loại gói tin thành các mức ưu tiên loại bỏ khác nhau, hàng đợi RED bắt đầu loại bỏ các gói tin có độ ưu tiên thấp để giữ kích thước hàng đợi năm trong ngưỡng đã thiết lập và độ trễ hàng đợi thấp. Không có gói tin Green nào bị loại bỏ. Mô phỏng việc đánh dấu và đảm bảo chất lượng dịch vụ sử dụng kiến trúc DiffServ có thể chưa đem lại sự cải thiện đáng kể trong một vài trường hợp. Có thể thấy rằng việc DiffServ bảo vệ rất tốt các gói tin có ưu tiên cao (Green packets) thường được gọi là các goi tin nhạy cảm. Việc mất mát các gói tin này thường dẫn tới giảm hiệu suất đang kể của phiên kết nối. Trong một số trường hợp mất gói tin đồng bộ sẽ dẫn tới thời gian timeout 3s hoặc 6s đối với các kết nối TCP. Việc cam kết băng thông tối thiểu dành cho một người dùng cụ thể có thể thực hiện được bằng cách gán người dùng đó với một hàng đợi riêng biệt và cấp phát một lượng băng thông như đã cam kết cho hàng đợi đó. Như vậy ta có thể đạt được cả hai mục tiêu đó là vừa đảm bảo được băng thông tối thiểu cho người dùng đặt trước và vừa bảo vệ được luồng dữ liệu nhạy cảm khi tắc nghẽn xảy ra tại chính người dùng đó.
  • 69.
    58 3.3. Kết luậnvà hướng nghiên cứu tiếp theo A. KẾT LUẬN RED là một trong những thuật toán AQM đầu tiên và được nghiên cứu rất nhiều trên thế giới, hầu hết các nghiên cứu đó đều công nhận hiệu quả của nó đạt được. tuy nhiên nó vẫn có những nhược điểm cố hữu là nhạy cảm với các tham số đầu vào và điều kiện của mạng. Ngoài ra RED không đảm bảo được sự công bằng cho các luồng dữ liệu khác nhau. Mục tiêu chính của RED là giữ hàng đợi trung bình đủ nhỏ trong một miền định trước nhằm hấp thu đột biến tức thời giúp mạng đạt được thông lượng cao và độ trễ thấp. Các thuật toán A-RED, RIO, A-RIO ra đời nhằm khắc phục các nhược điểm của RED với việc đơn giản hóa các tham số đầu vào và cố gắng đạt được sự công bằng cho một lớp lưu lượng riêng. Kiến trúc mạng IntServ ra đời nhằm đảm bảo chất lượng dịch vụ cho một lớp lưu lượng đặt trước bằng cách đặt trước tài nguyên từ nguồn tới đích tuy nhiên lại có nhiều nhược điểm như khả năng mở rộng kém trong mạng lõi, chi phí cao, cài đặt phức tạp. Kiến trúc mạng DiffServ được phát triển với những ưu điểm trái ngược với kiến trúc IntServ, với việc phân loại gói tin thành các mức độ ưu tiên khác nhau và áp dụng những chính sách khác nhau cho từng mức ưu tiên đó khiến cho DiffServ đạt được tính linh động rất tốt, dễ cài đặt và mở rộng. Việc áp dụng chiến lược RED trong mô hình kiến trúc mạng DiffServ giúp người quản trị có thể vừa đạt được công bằng cho các luồng dữ liệu, bảo vệ các luồng dữ liệu nhạy cảm vừa đạt được thông lượng và độ trễ cao nhờ thuật toán RIO. B. HƯỚNG NGHIÊN CỨU TIẾP THEO. Chúng tôi sẽ tiếp tục nghiên cứu sâu hơn về kiến trúc mạng DiffServ cụ thể là: Ảnh hưởng của việc thay đổi thuật toán lập lịch giữa các hàng đợi trong kiến trúc mạng DiffServ. Ảnh hưởng của các lưu lượng cũng như các gói tin khác nhau đến hiệu năng của thuật toán RIO.
  • 70.
    59 TÀI LIỆU THAMKHẢO 1. Nguyễn Đức Thắng, Nguyễn Ngọc Chân, Trần Công Hùng, Giải pháp đảm bảo chất lượng dịch vụ (QoS) cho mạng lõi. 2. Nguyễn Thị Thu Huyền, Đồ án: Nghiên cứu về QoS và định hướng phát triển mạng viễn thông Việt Nam 3. Vũ Duy Lợi, Nguyễn Đình Việt, Ngô Thị Duyên, Lê Thị Hợi (2004), “Đánh giá hiệu suất chiến lược quản lý hàng đợi RED bằng bộ mô phỏng NS”, Kỷ yếu Hội thảo Khoa học Quốc gia lần thứ hai về Nghiên cứu, Phát triển và Ứng dụng Công nghệ Thông tin và Truyền thông (ICT.rda'04), (Hà nội, 2425/9/2004). NXB Khoa học và Kỹ thuật, Hà Nội, 5/2005, trang 394-403. 4. Lê Đình Danh(2007), Luận văn cao học: Thuật toán quản lý hàng đợi A-RIO 5. Sally Floyd and Van Jacobson, “Random Early Detection Gateways for Congestion Avoidance” Lawrence Berkeley Laboratory University of California 6. Eitan Altman, Tania Jimenez, “NS Simulator for Beginners” 7. RFC: 2474, 2475, 2597, 2598, 3260, 2697 8. Luigi Alcuri, Francesco Saitta , Telephony Over IP: A QoS Measurement-Based End to End Control Algorithm and a Queue Schedulers Comparison 9. D. Stiliadis, A. Varma (1998), “Efficient Fair Queuing Algorithms for PacketSwitched Networks”, IEEE Trans. Networking, Vol. 6, No. 2, pp. 175-185 10. David D.Clark, Wenjia Fang (1998), “Explixit Allocation of Best Effort Packet Delivery Service”, Labratory for Computer Sciences Computer Science Department, Massachusetts Institute of Technology Princeton University A. Demers, S. Keshav and S. Shenkar (1989), “Analysis and Simulation of a Fair Queuing Algorithms” 11. Ns2 Document, http://www.isi.edu/nsnam/ns/doc/ 12. Luigi Alcuri, Francesco Saitta, “Telephony Over IP: A QoS Measurement-Based End to End Control Algorithm and a Queue Schedulers Comparison” Viale delle Scienze 9, 90128 Palermo Italy 13. Jia-Shiang Jou, Xiaobo Tan and John S. Baras, “A Parallel Virtual Queue Structure for Active Queue Management” Department of Electrical and Computer
  • 71.
    60 Engineering and Institutefor Systems Research University of Maryland, College Park, MD 20742 USA 14. Mikko Vanhala, “Differentiated Services – architecture” 44368D Teknillinen korkeakoulu Teletekniikan laboratorio 15. Oyetunji M.O, Oladeji F.A Emuoyinbofarhe O.J, “Performance Evaluation of Traffic Meters: Token Bucket Marker and Two Rate Three Color Marker (trTCM) QoS Admission Control” 16. Rong Pan, “Active Queue Management” Cisco System EE384y Spring Quarter 2006 17. W. Feng, D. Kandlur, D. Saha, and K. G. Shin (1999), “A Self-Configuring RED Gateway”, In Proceedings of IEEE INFOCOM, pages 1320-1328. 18. Andrew s. Tanenbaum, The Netherlands Computer networks fifth edition, Vrije Universiteit Amsterdam, The Netherlands