Theo mô phỏng, ta sẽ ƣu tiên các gói tin từ nguồn S1 và S3, và sẽ hạn chế thông lƣợng từ S2 và S4. Ngƣỡng CIR của S1, S3 đặt max băng thông của nó và lần lƣợt là 1Mbps và 3Mbps. Ngƣỡng CIR của 2 luồng cần giới hạn S2, S4 sẽ đặt lần lƣợt là 0.5Mbps và 1Mbps.
Tham số PIR của TSW3CM sẽ đƣợc thiết lập gấp đôi so với CIR.
TSW2CM sử dụng 2 hàng đợi ảo, trong đó hàng đợi (0,0) màu green sẽ đƣợc ƣu tiên hơn, hàng đợi (0,1) màu đỏ sẽ có xác suất drop cao hơn. Cụ thể trong cấu hình configQ nhƣ sau:
$qCR2 configQ 0 0 20 80 0.02 $qCR2 configQ 0 1 20 40 0.10
TSW3CM sử dụng 3 hàng đợi ảo, trong đó hàng đợi (0,0) màu green sẽ đƣợc ƣu tiên nhất, tiếp đó hàng đợi (0,1) màu vàng sẽ có xác suất drop cao hơn., và cuối cùng hàng đợi (0,2) màu đỏ kém ƣu tiên sẽ bị drop nhiều nhất. Cụ thể trong cấu hình configQ nhƣ sau:
$qCR2 configQ 0 0 20 80 0.02 $qCR2 configQ 0 1 20 40 0.10 $qCR2 configQ 0 2 10 20 0.30
b. Phương thức thu thập kết quả
− Lấy dữ liệu từ NS2:
Với mục đích nghiên cứu về các cơ chế quản lý hàng đợi nên kết quả thu thập đƣợc sẽ chủ yếu đƣợc lấy từ hàng đợi Core-R2, là nơi có băng thông thấp và xảy ra hiện tƣợng nút cổ chai.
Thông số thu thập bao gồm kích cỡ, thông lƣợng và số gói tin bị mất. Các giá trị này đƣợc tính toán và ghi vào file bằng việc phân tích dữ liệu ở qFile – đối tƣợng thuộc dạng monitor-queue. Từ các giá trị thu đƣợc ta dùng xgraph để vẽ biểu đồ so sánh tƣơng ứng.
− Đường trung bình
Do dữ liệu thô có biên độ dao động lớn, để trực quan hơn ta sử dụng giá trị trung bình. Ta tính giá trị này theo thuật toán:
average = (old_average * (1 – 1/2n )) + (current_queue_size * 1/2n ) Trong đó:
n: là hệ số trọng số và có thể cấu hình đƣợc. average: Cỡ hàng đợi trung bình
old_average: Cỡ hàng đợi trung bình trƣớc đó current_queue_size: Kích thƣớc hàng đợi hiện tại
File shell script: calculate_average_point.sh lấy đầu vào là file dữ liệu kích cỡ, thông lƣợng hoặc số gói tin bị mất, từ đó sinh ra file ghi các giá trị trung bình tƣơng
ứng. Ta sử dụng file mới này để vẽ đƣờng trung bình. Chi tiết code của file calculate_average_point.sh đƣợc cung cấp trong phụ lục của luận văn.
− Độ trễ
Để tính độ trễ của các gói tin khi qua các node thì ta phải phân tích tệp vết của file tcl.
Tệp vết sẽ sử dụng 2 chƣơng trình awk để phân tích :
calculate-queue-delay.awk : tính độ trễ trung bình khi các gói tin đi qua 1 link (thƣờng bị chậm do lƣu trong queue).
calculate-flow-delay.awk: tính độ trễ trung bình của 1 flow từ nguồn đến đích. Do các tệp vết ghi đầy đủ thông tin về tất cả các gói tin qua mạng nên dung lƣợng thƣờng khá lớn. Với 45s mô phỏng của mỗi kịch bản thì tệp vết sẽ có xấp xỉ khoảng 3 triệu record và dung lƣợng khoảng 120MB. Trong luận văn ứng với mỗi kịch bản mô phỏng và cơ chế quản lý hàng đợi thì đều có 1 tệp vết tƣơng ứng. Vì vậy, có tất cả 3x3=9 tệp vết đƣợc phân tích.
c. Kết quả
Ta xem xét kích thƣớc hàng đợi và băng thông qua Core router khi sử dụng các kĩ thuật RED, TSW2CM, TSW3CM
- Kịch bản 1: Tăng cƣờng độ tắc nghẽn với nguồn phát TCP
Hình 4. 8. Kích thước hàng đợi RED, WRED-TSW2CM , WRED-TSW3CM
Hình 4. 9 Kết quả so sánh thông lượng của RED với hai chính sách của WRED
Hình 4. 10Đường thông lượng trung bình của RED, tsw2cm và tsw3cm
Giao thức quản lý hàng đợi Thời gian trễ trung bình của link R1 - Core (s) Thời gian trễ trung bình của link Core – R2 (s) Thời gian trễ trung bình của link R2 – Dest (s) Thời gian trễ trung bình từ nguồn S1 đến đích (s) RED 0.00512952 0.00950826 0.005112 0.00859365 WRED tsw2cm 0.0101001 0.0182467 0.005112 0.00976031 WRED tsw3cm 0.0100821 0.024623 0.00508321 0.0092573
Bảng 4.1. Kết quả so sánh thời gian trễ của RED, tsw2cm và ts3cm ở kịch bản 1
- Kịch bản 2: Tăng cường độ tắc nghẽn với nguồn phát UDP
Hình 4. 11 Kích thước hàng đợi của RED, tsw2cm và tsw3cm (Kịch bản 2)
Hình 4. 13 Kết quả so sánh đường thông lượng trung bình của RED với ba chính sách của WRED Giao thức quản lý hàng đợi Thời gian trễ trung bình của link R1 - Core (s) Thời gian trễ trung bình của link Core – R2 (s) Thời gian trễ trung bình của link R2 – Dest (s) Thời gian trễ trung bình từ nguồn S1 đến đích (s) RED 0.00510018 0.0310101 0.00510062 0.00852365 WRED tsw2cm 0.0101055 0.0154239 0.005112 0.00920217 WRED tsw3cm 0.0100949 0.0196376 0.00509856 0.00922524
Bảng 4.2. Kết quả so sánh thời gian trễ của RED, tsw2cm và ts3cm ở kịch bản 2
Hình 4. 14 Kích thước hàng đợi của RED, tsw2cm và tsw3cm (Kịch bản 3)
Hình 4. 16 Kết quả so sánh thông lượng trung bình của RED với ba chính sách của WRED Giao thức quản lý hàng đợi Thời gian trễ trung bình của link R1 - Core (s) Thời gian trễ trung bình của link Core – R2 (s) Thời gian trễ trung bình của link R2 – Dest (s) Thời gian trễ trung bình từ nguồn S1 đến đích (s) RED 0.00508605 0.0606333 0.00508553 0.00850128 WRED tsw2cm 0.0101001 0.0182467 0.005112 0.00976031 WRED tsw3cm 0.0100821 0.024623 0.00508321 0.0092573
Bảng 4.3.Kết quả so sánh thời gian trễ của RED, tsw2cm và ts3cm ở kịch bản 3
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.