d. Nhận xét
Kịch bản 1: bùng phát TCP, ta có thể thấy 1 sự khác biệt đáng kể giữa 3 chính sách: RED, TSW2CM và TSW3CM:
− RED tận dụng đƣợc nhiều băng thông nhất, tuy nhiên không có cơ chế QoS để ƣu tiên luồng dữ liệu từ S1 và S3. Khi có tắc nghẽn (từ giây 20 đến giây 40) thì loại bỏ gói tin ngẫu nhiên trong hàng đợi. Sau khi nguồn S3 ngập băng thông ngừng truyền, thì thông lƣợng qua router cũng bị giảm đột ngột, dữ liệu từ S1 và S2 phải mất 2 giây để phục hồi từ tốc độ 1Mbps lên 2Mbps
− TSW2CM theo cấu hình luôn ƣu tiên S1 vào hàng đợi (0,0) ƣu tiên còn S2 vào hàng đợi (0,1) có xác suất loại bỏ rất cao. Theo cấu hình tại configQ thì các traffic của S2 đã vƣợt ngƣỡng maxth 20 nên trong kịch bản này bị drop toàn bộ. Biên độ dao động tốc độ truyền là khá lớn, nhƣng đến khi dữ liệu ƣu tiên từ nguồn S3 làm ngập mạng, thì router tận dụng hết throughput để phục vụ S3 và đƣờng throughput trở nên “mịn”. Đặc biệt, sau khi S3 dừng truyền ở giây 40 thì ngay lập tức S1 vẫn có tốc độ truyền tối đa (1Mbps) chứ không bị mất 2 giây
phục hồi nhƣ RED. Điều này chứng tỏ sau khi S1 đƣợc ổn định tốc độ tối đa, dù có xảy ra tắc nghẽn nhƣng do đƣợc ƣu tiên nên không có gói tin nào của S1 bị mất. Từ đó tốc độ S1 không bị ảnh hƣởng.
− TSW3CM đƣợc cấu hình với các luồng dữ liệu từ S2, S4 ban đầu sẽ đƣợc cho vào hàng đợi (0,1), nói cách khác traffic đƣợc màu vàng, chỉ hạn chế phần nào tốc độ truyền chứ không cấm chặt chẽ nhƣ màu đỏ ở hàng đợi (0,2).Vì vậy khi tới giây 10, nguồn S2 với tốc độ 1Mbps bắt đầu truyền nhƣng chỉ đƣợc đi qua 55%, từ giây 10 đến giây 20, băng thông đi qua router core dao động trong khoảng 1,55 Mbps. Khi bùng phát xảy ra ở giây 30, do nguồn gây bùng phát là S3 và cũng là 1 nguồn đƣợc ƣu tiên, vì thế dữ liệu bùng phát nhanh chóng chiếm đầy hàng đợi mà không bị drop. Từ đó gây nên hiện tƣợc lockout và sau đó băng thông của router tụt xuống về gần 0. Sau đó quá trình truyền dữ liệu khi quá tải của CORE router hết sức bất thƣờng với sự tăng giảm đột ngột, liên tục của tốc độ truyền. Khi nguồn bùng phát S3 dừng truyền dữ liệu thì giống nhƣ TSW2CM, ngay lập tức S1 và S2 vẫn giữ đƣợc tốc độ lý tƣởng (1,55Mbps) nhƣ trƣớc khi xảy ra tắc nghẽn. Điều này chứng tỏ khả năng phục hồi của hệ thống là rất tốt.
− Về độ trễ trung bình, giao thức RED cho thời gian trễ là nhỏ nhất. Nguyên nhân là khi chạy giao thức WRED tsw2cmm tsw3cm, các gói tin cần mất thêm thời gian tại link R1-CORE để đánh dấu và router core ở link CORE-R2 cũng mất nhiều thời gian phân loại, ƣu tiên gói tin theo hàng đợi hơn.
Kịch bản 2: bùng phát UDP
− RED: kết quả của thí nghiệm không khác với những gì đã làm trong phần trên. Băng thông đƣợc tận dụng nhiều nhƣng khi bùng phát xảy ra, dữ liệu truyền lại chủ yếu là UDP, và sau đó các luồng tcp phải mất đến 6 giây mới phục hồi đƣợc tốc độ 3Mbps nhƣ ban đầu.
− TSW2CP: Do cấu hình đã đánh dấu traffic từ S2 và S4 bằng màu đỏ, đặt vào hàng đợi (0,1) với tham số loại bỏ rất cao. Vì thế ngay từ khi bắt đầu S2 và S4 đã vi phạm ngƣỡng truyền CIR và bị drop sớm. Dữ liệu bùng phát không đƣợc truyền qua router CORE, không làm ngập băng thông và các traffic TCP từ S1, S3 đƣợc bảo đảm hoàn toàn, không gặp phải tắc nghẽn.
− TSW3CP: Dữ liệu từ nguồn bùng phát S4 đƣợc đánh dấu màu vàng, cho vào hàng đợi (0,1) với các tham số loại bỏ vừa phải. Tuy nhiên do traffic UDP bùng phát sinh ra là quá lớn nên trong khoảng thời gian từ 20s đến 30s đã chiếm toàn bộ băng thông của router CORE. Kết quả là hệ thống cũng mất đến 6s để phục hồi lại tốc độ truyền TCP nhƣ trƣớc khi tắc nghẽn, TSW3CP trong trƣờng hợp này không đạt hiệu quả nào đáng kể trong việc chống bùng phát.
− Về thời gian trễ trung bình, RED vẫn chỉ bằng 1 nửa so với tsw2cm và tsw3cm trong link R1-CORE vì không phải đánh dấu gói tin. Tuy nhiên tại link CORE- R2 thì thời gian trễ của RED là 0,0310101 giây, nhiều hơn gấp đôi so với 0.0154239 và 0.0196376 của tsw2cm và tsw3cm. Nguyên nhân vì lƣu lƣợng CBR phát ra là rất lớn, giao thức RED drop gói tin sớm không hiệu quả bằng WRED nên trong thời gian hàng đợi bị tràn nhiều hơn hẳn. Vì thế gói tin bị giữ trong hàng đợi lâu hơn và tổng hợp lại làm thời gian trễ trung bình của gói tin RED trong kết nối CORE-R2 nhiều lên.
Kịch bản 3: Luồng ưu tiên bắt đầu chạy khi đang có tắc nghẽn
− RED: do traffic từ S2, S4 truyền quá mạnh, và không có cơ chế ƣu tiên nên traffic từ S1, S3 truyền vào trong thời gian tắc nghẽn không gây đƣợc hiệu quả nào. Sau khi hết tắc nghẽn, băng thông đƣợc giải phóng thì S1, S3 mới bắt đầu tăng window size từ 0 lên và mới truyền đƣợc dữ liệu
− TSW2CM: traffic từ S2, S4 bị đánh màu Đỏ và nhanh chóng bị drop, vì thế khi S1 và S3 bắt đầu truyền vào giây 10 và giây 20, chúng không gặp cản trở gì và nhanh chóng đạt tốc độ tối đa.
− TSW3CM: Dữ liệu từ S2, S4 bị đánh màu Vàng, có khả năng bị drop nhiều hơn nhƣng do lƣu lƣợng bùng phát là quá lớn, nên cho dù traffic ƣu tiên từ S1, S3 cũng không thể truyền qua đƣợc. Sau khi nguồn S2, S4 dừng truyền thì traffic của S1, S3 dần dần chiếm đƣợc băng thông nhƣng với tốc độ chậm hơn RED
− Thời gian trễ trung bình của RED và WRED trong link R1-CORE không có gì thay đổi so với kịch bản 1 và 2. Tuy nhiên tại nút cổ chai CORE-R2 thì có sự khác biệt rõ rệt. Ta có thể quan sát tƣơng ứng với biểu đồ thông lƣợng, thì giải thuật nào có thời gian truyền với full throughput lâu hơn thì sẽ có nhiều packet lƣu trong hàng đợi hơn, theo đó thì độ trễ của gói tin sẽ lớn theo. Theo bảng dữ liệu thì RED với cơ chế quản lý hàng đợi kém hơn có thời gian trễ lớn nhất ở nút cổ chai là 0.0606333, so với 0.0182467 và 0.024623 của tsw2cm và tsw3cm.
4.5 So sánh và kết luận chung
Qua việc lập mô phỏng WRED với phƣơng pháp TSW2CM và TSW3CM, so với RED, DropTail thì ta thấy có 1 số ƣu điểm nhƣ sau:
− Ta có thể định nghĩa chính xác ƣu tiên cho những luồng dữ liệu nào, và có thể chặn hoặc giới hạn traffic từ những nguồn không mong muốn. Điều này có ý nghĩa quyết định trong việc triển khai mô hình QoS bảo đảm chất lƣợng dịch vụ truyền tin.
− Độ phục hồi của dữ liệu sau khi xảy ra bùng phát đƣợc cải thiện đáng kể. Nếu có cấu hình đúng đắn, thì tốc độ truyền sẽ đƣợc bảm đảo, vẫn đạt tối đa ngay cả khi tắc nghẽn xảy ra.
Việc thiết lập cấu hình ƣu tiên một cách hợp lý cho các luồng traffic là tối quan trọng trong WRED. Thí nghiệm với TSW3CM cho thấy nếu nguồn bùng phát đƣợc giới hạn không đúng mức, thì khi xảy ra tắc nghẽn, giao thức sẽ không có đƣợc kết quả mong muốn, thậm chí còn giảm đáng kể hiệu năng của hệ thống
4.6 Hướng nghiên cứu tiếp theo
Trong phạm vi luận văn này chúng tôi mới nghiên cứu, tìm hiểu, đánh giá và mô phỏng một số chiến lƣợc quản lý hàng đợi: DropTail, RED và đặc biệt là WRED. Để có thể chứng minh đƣợc tính ƣu việt của giao thức WRED cũng nhƣ tăng tính chất thực tiễn của nghiên cứu, chúng ta có thể phát triển luận văn theo hƣớng triển khai, áp dụng RED, WRED trên 1 số thiết bị router/switch của Cisco.
Trong thực tế, cơ chế quản lý hàng đợi RED và WRED đã đƣợc lập trình nhƣ là 1 thành phần hoàn chỉnh của router/switch và đƣợc tích hợp vào hệ điều hành IOS trên một số thiết bị phần cứng của Cisco, Juniper. Các dòng router/switch của Cisco hỗ trợ RED, WRED là: AS5200, 4000, 4500 4700, 7000 series, 7500 series…
Qua quá trình nghiên cứu, có 3 kịch bản triển khai thực tế của Cisco mà sử dụng cơ chế quản lý hàng đợi RED, WRED nhƣ là 1 thành phần của QoS. Chúng tôi đề xuất một số giải pháp triển khai trong doanh nghiệp.
Dƣới đây là các giải pháp triển khai:
4.6.1 SNA ToS (System Network Architecture Term of Service)
Kiến trúc hệ thống mạng (SNA) ToS là 1 khái niệm liên quan đến sự chuyển mạch ở tầng datalink (datalink switching plus DSLw+), nó cho phép ánh xạ giữa một kiến trúc hệ thống mạng CoS (Class of Service) với 1 dịch vụ IP riêng lẻ.
Hình 4.17 Kiến trúc mạng TOS
DLSW+ mở 4 TCP session và ánh xạ mỗi lƣu lƣợng SNA ToS vào 1 session, trong hình vẽ trên là các dịch vụ SNA interactive, Telnet, SNA batch và FTP. Mỗi session lại đƣợc đánh dấu bằng 1 độ ƣu tiên trong queue và có thể áp dụng các cơ chế quản lý hàng đợi của QoS.
4.6.2 QoS VoIP Solution
Với mục đích tăng cƣờng chất lƣợng thoại trong truyền tin VoIP, khả năng QoS cần phải thêm vào mạng dữ liệu truyền thống. Chức năng QoS của hệ điều hành IOS trên các thiết bị Cisco đáp ứng tốt yêu cầu đó với việc kết hợp luồng dữ liệu voice với dữ liệu thông thƣờng.
Sơ đồ sau diễn tả một mô hình mạng doanh nghiệp thực tế sử dụng hệ thống VoIP đã đƣợc tối ƣu về chi phí thoại.
Hình 4.18 Sơ đồ hệ thống VoIP trong doanh nghiệp
3 router dòng 3620, 3640 kết nối giữa 3 chi nhánh của doanh nghiệp, trên đó đƣợc cấu hình QoS với các chiến lƣợc quản lý hàng đợi để tối ƣu tốc độ truyền và giảm độ trễ cho dữ liệu thoại.
4.6.3 QoS trong streaming video
Xây dựng hệ thống streaming video thì khó khăn hơn hệ thống VoIP vì video yêu cầu đƣợc đáp ứng một lƣợng dải thông lớn hơn rất nhiều. Trong sơ đồ tiếp theo, giao thức RSVP (Resource Reservation Protocol) đƣợc kết nối với hệ thống ATM PVCs để đảm bảo 1 lƣợng băng thông ổn định cho việc truyền streaming video.
TÀI LIỆU THAM KHẢO Tài liệu Tiếng Việt
[1]. PGS.TS. Nguyễn Đình Việt, Bài giảng đánh giá hiệu năng mạng máy tính, 2008.
[2]. PGS.TS. Nguyễn Đình Việt, Bài giảng Mạng và Truyền số liệu nâng cao, 2008.
[3]. Luận văn cao học - Nguyễn Đức Xuân Bình, 2009.
[4]. 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, 24-25/9/2004). NXB Khoa học và Kỹ thuật, Hà Nội, 5/2005, trang 394-403.
Báo cáo khoa học, PGS,TS Vũ Duy Lợi, TS Nguyễn Đình Việt, Sinh viên Ngô Thị Duyên, Lê Thị Hợi, 2004.
[5]. Luận văn cao học – Lê Đình Danh, 2007
Tài liệu Tiếng Anh
[6]. The ns Manual (formerly ns Notes and Documentation) - A Collaboration between researchers at UC Berkeley, LBL, USC/ISI, and Xerox PARCAAuthor,
Reference 1, Publisher, Year.
[7]. A study of TCP-RED congestion control using ns2 - Arijit Ganguly & Pasi Lassila
[8]. A Network Simulator Differentiated Services Implementation - Peter Pieda & Jeremy Ethridge & Mandeep Baines & Farhan Shallwani
[9]. Implementing Quality of Service – Cisco
[10]. Integration of Mechanisms for ACK Control and Queueing Management in Network Traffic Control – Vo Thanh Tu & Nguyen Thuc Hai
[11]. Adaptive RED: An Algorithm for Increasing the Robustness of RED’s Active Queue Management - Sally Floyd, Ramakrishna Gummadi, and Scott Shenker [12]. NS Simulator for beginners - Eitan Altman & Tania Jimenez
[13]. Network advanced modeling in NS-2 - Giovanni Perbellini
[14]. B. SUTER ET AL., “Efficient Active Queue Management for Internet Routers”, Proc. Eng. Conf. at Interop 98, Las Vegas, NV, May 1998.
[15]. http:// www. isi.edu/nsnam/ns/ns-documentation.html
[16]. LEONARD KLEINROCK, “On the Modeling and Analysis of Computer Networks”, IEEE, vol.81, No.8, August 1993.
[17]. M. BORDEN, V. FIROIU, “Queue Management for Congestion Control”, IEEE INFOCOM, Mar 2000.
[18]. S. FLOYD AND V. JACOBSON, “Random Early Detection Gateways for Conges-tion Avoidance”, IEEE/ACM Trans. Net., vol. 1, no. 4, Aug. 1993, pp.397–413.
[19]. SALLY FLOYD, “A Report on Some Recent Developments in TCP Congestion Control”, IEEE Magazine, April 2001.
[20]. R. G. GALLAGER, A. K. PAREKH, “A Generalized Processor Sharing Approach to Flow Control in Integrated Services Networks: The Multiple Node Case”, IEEE Net., vol. 2, no. 2, Apr. 1994, pp. 137–50.