Luận văn Đánh giá hiệu quả đảm bảo qos cho truyền thông đa phương tiện của chiến lược quản lý hàng đợi wred

g tôi cũng đồng ý với các tác giả trong [1] rằng nên chọn maxp = 0.1. 3.2.4 Một số đánh giá về RED RED là một điển hình của các chiến lược quản lý hàng đợi động AQM, ngoài những ưu điểm chung của AQM, RED còn có một số tính chất (ưu điểm) riêng biệt khác nữa: − Tránh tắc nghẽn: Nếu RED gateway thực sự loại bỏ gói tin đến khi kích thước hàng đợi trung bình đạt đến ngưỡng trên, thì RED gateway đảm bảo kích thước hàng đợi trung bình tính theo lý thuyết không vượt quá ngưỡng trên. Nếu trọng số hàng đợi wq được thiết lập một cách hợp lý thì RED gateway hoàn toàn có thể điều khiển được kích thước hàng đợi trung bình thực sự. Nếu RED gateway đánh dấu một bit trong header của gói tin đến khi kích thước hàng đợi trung bình vượt quá ngưỡng trên, thay vì loại bỏ nó, thì hiệu quả hoạt động của RED gateway còn phụ thuộc vào sự hợp tác của các cặp nguồn/đích để điều khiển kích thước hàng đợi trung bình. − Tránh đồng bộ toàn cục: Tỷ lệ đánh dấu gói tin của RED gateway phụ thuộc vào mức độ tắc nghẽn. Ở giai đoạn tắc nghẽn thấp, RED gateway đánh dấu gói tin với một xác suất thấp, và khi tắc nghẽn tăng lên thì xác suất đánh dấu cũng tăng lên. Mặt khác, RED gateway chọn ngẫu nhiên các gói tin đến để đá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ẻ của kết nối đó tại gateway. Như vậy, RED gateway tránh hiện tượng đồng bộ toàn cục bằng cách đánh dấu gói tin theo một tỷ lệ thấp nhất có thể và việc đánh dấu các gói tin một cách ngẫu nhiên. − Đơn giản: Thuật toán RED có thể được cài đặt với một chi phí vừa phải, không yêu cầu phải cài đặt đồng loạt cho tất cả các gateway trong mạng mà có thể triển khai dần. 53 − Cực đại hoá công suất toàn cục: Công suất nói ở đây được định nghĩa bằng tỷ lệ giữa thông lượng và độ trễ. Vì RED gateway điều khiển cho kích thước hàng đợi nhỏ, dẫn tới độ trễ nhỏ, mặt khác như các mô phỏng chúng tôi trình bày dưới đây, hệ số sử dụng đường truyền với RED và DropTail là xấp xỉ nhau, vì vậy công suất đường truyền cao hơn rất nhiều so với DropTail (điều này được khẳng định bằng các mô phỏng dưới đây). − Tính công bằng: một trong những mục tiêu quan trọng của một thuật toán quản lý hàng đợi là sự công bằng trong việc cấp phát đường truyền cho các kết nối chia sẻ. Về điểm này thì RED gateway có phần hạn chế. RED gateway không phân biệt các kết nối hay các lớp kết nối khác nhau. Đối với RED gateway, tỷ lệ các gói tin bị đánh dấu tỷ lệ với phần băng thông chia sẻ của kết nối đó tại gateway. Tuy nhiên nó không cố gắng đảm bảo tất cả các kết nối nhận được cùng một tỷ lệ dải thông, mặt khác nó không điều khiển được hiện tượng misbehaving users - hiện tượng một kết nối nào đó nhận được tỷ lệ băng thông lớn hơn rất nhiều so với các kết nối khác đi qua gateway. 3.3 Phương pháp loại bỏ ngẫu nhiên theo trọng số - WRED Thuật toán RED không phải lúc nào cũng đảm bảo cho các luồng chia sẻ băng thông một cách cân đối nhau. Trong thực tế, RED không ưu tiên đối với các luồng TCP tốc độ thấp vì RED loại bỏ ngẫu nhiên các gói khi ngưỡng bị vượt quá. WRED (Weighted RED) là phương pháp tránh tắc nghẽn dựa trên việc các thuộc tính của thuật toán RED và ưu tiên IP. WRED có thể lựa chọn loại bỏ lưu lượng có mức ưu tiên thấp khi trên giao diện bắt đầu xảy ra quá trình tắc nghẽn và cung cấp các đặc tính tiêu chuẩn khác nhau cho các lớp dịch vụ khác nhau. Với các giao diện mạng được cấu hình sử dụng đặc tính giao thức dành sẵn tài nguyên (RSVP), khi quá trình nghẽn xảy ra WRED ưu tiên các luồng RSVP hơn là các luồng dữ liệu khác trong quá trình loại bỏ gói để tránh tắc nghẽn. Cũng giống như RED trong cơ chế của mình WRED loại bỏ gói một cách ngẫu nhiên, từ đó thông báo tới trạm gốc giảm tốc độ truyền gói tin vào mạng. Nếu trạm gốc sử dụng TCP, nó sẽ làm giảm tốc độ của chính các gói đó cho tới khi tất cả các gói có thể đến được đích. WRED loại gói dựa trên giá trị ưu tiên IP được gán cho mỗi gói. Các gói có giá trị ưu tiên thấp hơn có khả năng bị làm rớt cao. WRED khắc phục các điểm yếu của cơ chế DropTail khi đầu ra giao diện có nguy cơ bị tắc nghẽn nó sẽ thực hiện lựa chọn làm mất một số gói thay vì chờ cho tới khi các hàng đợi bị đầy rồi mới thực hiện việc loại bỏ gói. WRED tránh việc làm mất một lượng lớn các gói trong một khoảng thời gian ngắn, từ đó nó cho phép các đường truyền được sử dụng hữu ích tại mọi thời điểm. WRED tránh được các vấn đề đồng bộ toàn cục xảy ra khi sử dụng DropTail để tránh tắc 54 nghẽn. WRED chỉ hữu ích khi phần lớn lưu lượng là dữ liệu của giao thức TCP, khi đó các gói bị loại sẽ phát sinh thông báo (gián tiếp) về sự nghẽn mạch để từ đó trạm phát giảm tốc độ truyền dẫn của mình. Đối với các gói tin được đóng gói theo một giao thức khác có thể trạm gửi không phát hiện quá trình mất gói xảy ra, như vậy có thể không ngăn chặn được quá trình nghẽn mạch. Với các dữ liệu mà không thuộc dạng gói TCP, WRED coi đó như là dữ liệu có mức ưu tiên thấp nhất (Precedence = 0), bởi vậy khả năng bị loại của nó là cao hơn các dữ liệu TCP. Hình 3. 3 Cơ chế làm việc của WRED được minh hoạ trong hình vẽ trên Router sẽ tự động tính toán các thông số của WRED để xác định cỡ hàng đợi trung bình. Cỡ hàng đợi trung bình được tính trên cơ sở cỡ hàng đợi trung bình trước và cỡ hàng đợi hiện tại. Giá trị của nó được tính theo công thức sau: 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 Chúng ta nên chọn hệ số trọng số cho phù hợp nếu n quá lớn WRED sẽ không tác động để chống tắc nghẽn, các gói tin sẽ được gửi hoặc bị loại vì vậy việc áp dụng WRED là vô ích, tuy nhiên việc lựa chọn n quá nhỏ WRED sẽ phản ứng mãnh liệt với sự bùng nổ lưu lượng tạm thời dẫn đến làm mất gói trong khi không thực sự cần thiết. Chúng tôi sẽ sử dụng NS2 để mô phỏng thuật toán này và đưa ra các nhận xét trong chương 4. Như đã trình bày trong chương 2, DiffServ đi theo hướng đảm bảo chất lượng dựa trên nguyên lý hành vi theo từng chặng căn cứ vào mức ưu tiên của các gói tin đã được đánh dấu. Việc đưa ra chính sách với các loại lưu lượng khác nhau là do người quản trị quyết định và có thể thay đổi theo thực tế nên nó rất mềm dẻo. DiffServ tận dụng tốt tài nguyên mạng hơn, tránh được tình trạng nhàn rỗi băng thông và năng lực xử lý trên 55 router, ngoài ra mô hình DifServ có thể triển khai trên nhiều miền độc lập do vậy khả năng mở rộng mạng trở nên dễ dàng. Dưới đây, là các đặc tính của WRED được sử dụng trong kiến trúc DiffServ. a. Cấu trúc của DiffServ DiffServ cung cấp dịch vụ QoS bằng việc chia traffic ra làm nhiều nhóm (lớp) khác nhau, mỗi một packet sẽ được đánh dấu bằng 1 mã (Code Point) để xác định nhóm. Module DiffServ trong NS2 có thể hỗ trợ 4 lớp traffic, mỗi lớp lại có 3 loại quyền ưu tiên loại bỏ (dropping precedences) cho phép ta xử lý các lớp traffic theo nhiều cách khác nhau. Các packet trong một lớp đơn sẽ được đưa vào trong 1 hàng đợi RED vật lý (physical queue), trong đó chứa tối đa 3 hàng đợi ảo (virtual queue). Tại các hàng đợi ảo này ta có thể cấu hình để ưu tiên với các loại gói tin theo ý muốn. Những tham số khác nhau của RED có thể được cấu hình cho các virtual queue, từ đó có thể dẫn đến 1 virtual queue có thể drop gói tin thường xuyên hơn những virtual queue khác. Mỗi packet sẽ được gắn với 1 giá trị Code Point và các tham số của RED, trong đó có trị số drop (dropping precedences), nếu trị số này thấp thì sẽ packet được ưu tiên hơn, sẽ ít bị drop khi xảy ra tắc nghẽn. Module DiffServ trong NS2 có 3 thành phần chính như sau: - Policy: là bộ luật, nó được thiết lập bởi người quản trị mạng, nói về các cấp độ của dịch vụ mà của 1 lớp traffic nhận được trên mạng - Edge router: các router biên có nhiệm vụ đánh dấu mã Code Point vào packet. Giá trị Code Point tương ứng với policy đã được thiết lập ở trên. - Core router: các router lõi có nhiệm vụ thực thi policy dựa theo code point của gói tin. Tất cả những thủ tục và chức năng của DiffServ có thể tìm thấy trong bộ code/thư viện của NS2: ~ns/diffserv/dsred, dsredq, dsEdge, dsCore, dsPolicy.{cc, h} b. Hàng đợi RED trong module DiffServ Hàng đợi RED trong DiffServ khác với hàng đợi RED sẵn có của NS2 trong REDQueue, nó được định nghĩa trong lớp dsREDQueue, thừa kế từ lớp Queue, nó có những chức năng như sau: - Triển khai nhiều hàng đợi vật lý RED qua cùng 1 liên kết đơn - Triển khai nhiều hàng đợi ảo trong 1 hàng đợi vật lý, với những tham số riêng biệt cho mỗi hàng đợi ảo - Xác định 1 packet thuộc hàng đợi vật lý và hàng đợi ảo nào dựa vào giá trị Code Point của nó - Xác định hàng đợi vật lý và hàng đợi ảo nào mà packet đi ra. 56 Lớp dsREDQueue bao gồm tối đa 4 hàng đợi RED vật lý, mỗi cái lại chứa tối đa 4 hàng đợi ảo. Số hàng đợi vật lý và ảo được sử dụng có thể được thiết lập thông qua biến numPrec và numQueues_. Hàng đợi vật lý được định nghĩa trong lớp redQueue, nó khả năng phân biệt các traffic thông qua việc định nghĩa các hàng đợi ảo với các cấu hình độc lập, chi tiết về việc này có tại file dsredq.h và dsredq.cc trong bộ cài NS2. Lớp dsREDQueue còn chứa một kiến trúc dữ liệu là bảng Per Hop Behavior (PHB), các router biên đánh dấu packet bằng Code Point và core router xử lý packet dựa trên giá trị Code Point đó, và cả 2 loại router đều sử dụng bảng PHB để ánh xạ Code Point tới hàng đợi vật lý và ảo. Bảng PHB được định nghĩa như là 1 mảng với 3 trường như sau: struct phbParam { int codePt_; // giá trị Code Point int queue_; // số hiệu hàng đợi vật lý int prec_; // số hiệu hàng đợi ảo c. Router lõi và router biên Định nghĩa router lõi và router biên trong DiffServ có trong class edgeQueue và coreQueue, chúng thừa kế từ class dsREDQueue. Chi tiết có tại file dsEdge, dsCore.{h.cc}. Vị trí của router lõi và router biên trong miền DiffServ được minh hoạ trên Hình 3.4 sau đây. Hình 3. 4 Vị trí router lõi và biên trong miền DiffServ Nhiệm vụ của router biên: - Phân tích và phân loại các gói tin đến mạng dựa theo các policy đã thiết lập - Đánh dấu gói tin với 1 mã (code point) phản ánh mức độ phục vụ - Bảo đảm tất cả các luồng dữ liệu phải được đánh dấu và tuân theo policy Nhiệm vụ của router lõi: - Phân tích các gói tin - Xử lý gói tin dựa theo code point được đánh dấu 57 Các packet được đánh dấu bằng class edgeQueue. Mỗi packet với 1 code point xác định thường phải liên quan đến 1 policy đã định nghĩa trước đó. Class edgeQueue có mối liên hệ với class PolicyClassifier – nơi chứa các policy để đánh dấu gói tin. d. Các chính sách - Policy Lớp Policy và những lớp con của nó định nghĩa các cách xử lý gói tin bởi router biên trong việc đánh dấu. Một policy được xác định bởi node nguồn và đích. Tất cả những luồng packet mà có chung nguồn và đích thì đều được coi như 1 tập hợp traffic đơn (single traffic aggregate). Policy cho mỗi tập hợp này được gán bằng 3 thông số: polycier type, meter type và initial code point. Meter type xác định phương thức đo lường các giá trị cần thiết bởi polycier, ví dụ: TSW Tagger là một kiểu meter đo bằng tần suất traffic trung bình. Khi một gói tin tới 1 router biên, nó sẽ được phân tích để xác định thuộc luồng nào. Tiếp theo Policier sẽ xác định đánh dấu (marking) gói tin ra sao. Dựa vào các thông số: trạng thái của luồng, code point ban đầu, code point bị giảm, sau đó packet sẽ được đưa vào hàng đợi. Bảng chính sách (Policy Table): Lớp Policy sử dụng Policy Table để lưu trữ các bộ luật của mỗi luồng traffic. Bảng này là 1 mảng bao gồm nhiều trường, trong đó tùy theo policer type mà có nhiều trường không sử dụng. Các trường của Policy Table là: - Source node ID: định danh node nguồn - Destination node ID: định danh node đích - Policer type : kiểu policer - Meter type : kiểu đo - Initial code point : code point ban đầu - CIR (committed information rate) : là tốc độ thông tin cam kết và cũng được gọi là tốc độ cam kết hoặc tốc độ được định dạng. - CBS (committed burst size) : kích thước burst cam kết - C bucket (current size of the committed bucket) : Kích thước hiện tại của bucket cam kết - EBS (excess burst size) : kích thước burst ngưỡng giới hạn - E bucket (current size of the excess bucket) : kích thước hiện tại của bucket ngưỡng giới hạn - PIR (peak information rate) : Tốc độ gửi đỉnh - PBS (peak burst size) : Ngưỡng kích thước burst 58 - P bucket (current size of the peak bucket) : Kích thước hiện tại của ngưỡng bucket - Arrival time of last packet : thời gian tới của packet cuối cùng - Average sending rate: tốc độ gửi trung bình: - TSW window length : độ dài cửa sổ TSW Các kiểu thi hành (Policier Types): Hiện tại lớp Policy hỗ trợ 6 loại Policier: - Time Sliding Window with 2 Color Marking (TSW2CMPolicer): Cửa sổ trượt theo thời gian với việc đánh dầu 2 màu, sử dụng biến CIR và 2 hàng đợi ảo. Những hàng đợi ảo có số hiệu thấp hơn sẽ drop gói tin khi ngưỡng CIR bị vi phạm. - Time Sliding Window with 3 Color Marking (TSW3CMPolicer): Cửa sổ trượt theo thời gian với việc đánh dầu 3 màu, sử dụng biến CIR, PIR và 3 hàng đợi ảo. Khi PIR bị vi phạm thì sẽ drop trong hàng đợi thấp nhất, khi CIR bị vi phạm thì sẽ drop trong hàng đợi thấp thứ 2. - Token Bucket (tokenBucketPolicer): sử dụng CIR, CBS và 2 hàng đợi ảo. Mỗi packet sẽ bị ưu tiên drop bằng cách đặt vào hàng đợi ảo thấp hơn khi kích cỡ của nó lớn hơn CBS và tần suất gửi vi phạm CIR - Single Rate Three ColorMarker (srTCMPolicer): sử dụng biến CIR, CBS, EBS để ưu tiên packet từ 3 hàng đợi ảo. - Two Rate Three Color Marker (trTCMPolicer): sử dụng biến CIR, CBS, PIR và PBS để ưu tiên packet từ 3 hàng đợi ảo. - NullPlocier: không ưu tiên packet nào cả. Nhưng policy ở trên đều được định nghĩa như là một class con của class dsPolicy. 3.4 Một số phương pháp khác 3.4.1. Tốc độ truy cập cam kết (CAR - Committed Access Rate) CAR là một cơ chế giám sát tốc độ cho phép người quản trị mạng đưa ra các biện pháp xử lý để kiểm soát lưu lượng. Do CAR là một cơ chế kiểm soát chứ không phải là cơ chế hàng đợi vì vậy nó không có bộ đệm và nó cũng không làm phát sinh trễ có thể cho phép truyền tốc độ cao. 3.4.1.1. Cơ chế hoạt động Khi dữ liệu được gửi đến một giao tiếp, CAR thực hiện việc kiểm tra lưu lượng sau đó so sánh tốc độ của lưu lượng với thông số “token bucket” (xô chứa thẻ bài) và đưa ra hành động tương ứng dựa trên cơ sở kết quả so sánh đó. Ví dụ CAR sẽ loại gói, sửa lại quyền ưu tiên IP hay khởi tạo lại các bit ToS. Người quản trị mạng cũng có thể cấu 59 hình CAR để truyền gói, loại bỏ gói hoặc thiết lập quyền ưu tiên (xem hình sơ đồ khối của CAR). Hình 3. 5 Sơ đồ khối của CAR Lưu lượng chuyển đến đòi hỏi phải được nhận dạng phù hợp với các đặc tính về tốc độ giới hạn, quyền ưu tiên hoặc cả hai. Cơ sở của việc định nghĩa tốc độ giới hạn dựa trên 3 thông số sau: − Tốc độ trung bình, được xác định là tốc độ truyền dẫn trong một thời gian dài. Đó là lưu lượng luôn dưới mức tốc độ giới hạn cho phép. − Cỡ khối trung bình, xác định lưu lượng lớn cỡ nào trước khi một vài phần lưu lượng vượt quá tốc độ giới hạn cho phép. − Cỡ khối quá mức, xác định lưu lượng lớn cỡ nào trước khi tất cả lưu lượng vượt quá tốc độ giới hạn cho phép (CAR). 3.4.1.2. Các chức năng của CAR Chức năng giới hạn tốc độ được thể hiện như sau: − Cho phép điều khiển tốc độ tối đa truyền hay nhận trên một giao diện. − Thực hiện điều khiển tại lớp 3 để điều khiển lưu lượng cụ thể nào đó khi lưu lượng có thể phù hợp hoặc quá tải. − Nhà quản trị có thể giới hạn tốc độ dữ liệu dựa trên các đặc tính về quyền ưu tiên, địa chỉ MAC (Medium Access Control) hoặc các thông số khác. CAR thường được thiết lập tại các router biên (edge) trong tổ chức của một mạng để giới hạn tốc độ truyền dữ liệu đi và đến mạng. 60 Hình 3. 6 Lưu đồ thuật toán CAR được minh họa họa ở hình trên Khi CAR có hiệu lực, lưu lượng sẽ được đi vào phân lớp đầu tiên rồi đưa vào quá trình xử lý CAR. Sau đó CAR đo lưu lượng và trên kết quả đo của CAR cho biết lưu lượng có thể phù hợp hoặc vượt quá mức chính sách đã cấu hình. Có 3 hành động cơ bản có thể xẩy ra trên mỗi gói, phụ thuộc vào các gói đó hợp hay vượt quá so với chính sách: − Truyền (Transmit): gói được gửi đi. − Rớt (Drop): Gói bị loại bỏ. − Tiếp (Continue): Gói được đưa tiếp đến chính sách về tốc độ tiếp theo trên dây truyền giới hạn tốc độ. Nếu không còn chính sách nào khác thì gói sẽ được chuyển đi. Như đã đề cập ở phần trước, CAR cũng có thể được đánh dấu hoặc đánh dấu lại lưu lượng cũng như thực hiện giới hạn tốc độ. Phụ thuộc vào hình dạng lưu lượng các hành động đánh dấu hoặc tái đánh dấu có thể được thực hiện trong xử lý CAR như: Đặt Precedence hoặc giá trị DSCP và phát đi IP Precedence ToS hoặc bit DSCP trong header của gói được viết lại. Sau đó gói được phát đi. Hành động này có thể đánh dấu hoặc tái đánh dấu các gói. − Đặt bit MPLS experimental và truyền bit experimental MPLS có thể được thiết lập. Thường sử dụng các tham số QoS báo hiệu trong MPLS. − Đặt QoS group và phát QoS group có thể được đặt. Nó chỉ được sử dụng trong router nội tại (local router). QoS group có thể được dùng trong cơ chế QoS cuối cùng và thực hiện trên cùng một router, như là CB-WFQ. 3.4.1.3. Mô hình chiếc thùng và thẻ bài Thưc hiện cơ chế đo lưu lượng bằng mô hình chiếc thùng và thẻ bài được chỉ ra trong hình 61 Hình 3. 7 Mô hình chiếc thùng và thẻ bài Mô hình chiếc thùng và thẻ bài (Token Bucket) là một mô hình cho việc điều hoà lưu lượng, để xử lý bất kỳ một gói mới nào đi đến. Mỗi một thẻ (Token) đại diện sự cho phép gửi một số lượng bit cố định vào mạng. Bucket (cái thùng) là khả năng giữ một số lượng thẻ bài nào đó. Nếu bucket được điền đầy, thì các gói mới đến sẽ bị lờ đi, không có thẻ bài cho các gói đến sau, do vậy các gói sẽ bị drop. Ví dụ Token bucket với khả năng có thể là 700 bytes, khi một gói 500 byte đi đến giao diện, kích thước của gói sẽ được so sánh với Bucket và gói 500 byte này được lấy thẻ bài. Khi một gói 300 byte tiếp theo đến ngay sau gói thứ nhất, gói này không được nhận thẻ bài vì trong bucket chỉ còn có 200 thẻ cho gói tiếp theo, nên gói này bị drop. Thực hiện token bucket dựa vào 3 tham số CIR, Bc, Be. − CIR (Committed Information Rate) là tốc độ thông tin cam kết và cũng được gọi là tốc độ cam kết hoặc tốc độ được định dạng. − Bc được biết đến như là khả năng bùng nổ nằm trong giới hạn. − Be là khả năng bùng nổ quá giới hạn. − Tc là chu kỳ mà số thẻ được thêm vào. 3.4.2 Định dạng lưu lượng tổng quát - GTS (Generic Traffic Shaping) − GTS cho phép người quản trị điều khiển lưu lượng đầu ra của một giao diện phù hợp với các yêu cầu giữa tốc độ trạm đầu ra và chỉ tiêu của giao diện mà đã được thỏa thuận trước. Từ đó loại trừ hiệu ứng nút cổ chai xảy ra trong mạng. − GTS cho phép thực hiện điều khiển truy nhập băng thông khả dụng, bên cạnh đó nó cũng có tính năng ngăn cản quá tình làm mất gói. − GTS cũng có thể sử dụng để giới hạn tốc độ truyền dẫn. Người sử dụng có thể giới hạn tốc độ truyền dẫn theo một trong các đặc tính sau:  Tốc độ được thiết lập.  Tốc độ của trạm gửi dựa trên mức tắc nghẽn. − GTS làm “trơn” lưu lượng bằng cách lưu giữ lưu lượng có tốc độ lớn hơn tốc độ được thiết lập trong một hàng đợi. a. Cơ chế hoạt động của GTS 62 GTS bao gồm các khối chức năng (xem Hình 3.8 Sơ đồ các khối chức năng của GTS) như sau: − Bộ phân lớp lưu lượng: Phân loại các lớp lưu lượng khác nhau để có thể có các chính sách được áp dụng khác nhau. − Bộ đo (Metering): Dùng cơ chế token-bucket để phân biệt lưu lượng thỏa mãn và lưu lượng quá ngưỡng. − Định dạng: Dùng buffer để trễ những lưu lượng vượt quá tốc độ, và sửa dạng chúng tới một tốc độ giới hạn đã được cấu hình. GTS được thực hiện như cơ chế hàng đợi, trong đó có các hàng đợi trễ WFQ riêng biệt được thực hiện cho mỗi lớp lưu lượng. Mỗi hàng đợi trễ các gói cho tới khi chúng thỏa mãn tốc độ giới hạn, và cũng sắp xếp chúng theo thuật toán WFQ. Sau đó lưu lượng được thỏa mãn sẽ được gửi tới giao diện vật lý. Hình 3. 8 Sơ đồ các khối chức năng của GTS Đầu tiên các gói được đưa tới các bộ phân loại, sự phân lớp có thể được thực hiện bằng access-list. Một gói được phân lớp đi vào một lớp định dạng, kích thước của chúng được so sánh với số lượng thẻ bài có thể trong token bucket của lớp đó. Gói được chuyển tiếp tới hàng đợi giao diện chính nếu đủ thẻ bài. Nếu không đủ thẻ bài cho các gói chuyển tiếp, các gói nằm trong bộ đệm trong hệ thống WFQ được gán cho lớp định dạng này. Sau đó router làm đầy token bucket định kỳ và kiểm tra nếu đủ thẻ bài cấp cho các gói chuyển tiếp. Các gói được xếp ra khỏi hàng đợi định dạng tùy thuộc vào thuật toán sắp xếp WFQ. b. Kết luận GTS thực thi trong phiên bản router hỗ trợ đa giao thức và làm việc trên nhiều loại giao diện khác nhau. WFQ được dùng như hàng đợi trễ định dạng, cho phép sự sắp 63 xếp công bằng trong một lớp lưu lượng. GTS có thể thực hiện kết hợp với các cơ chế hàng đợi khác như: FIFO, PQ, CQ, WFQ. GTS chỉ làm việc ở đầu ra của giao diện. GTS có thể được dùng để định dạng tất cả lưu lượng đầu ra trên giao diện hoặc nó có thể chia thành nhiều lớp định dạng. Kết luận chương Chương 3 đã đưa ra các phân tích ưu điểm và hạn chế của các chiến lược quản lý hàng đợi DropTail, RED, WRED. Ngoài ra còn phương pháp Tốc độ truy cập cam kết – CAR và phương pháp Sửa dạng lưu lượng – GTS. Trong chương tiếp theo chúng tôi sử dụng NS2 để mô phỏng, so sánh giải thuật WRED với DropTail, RED, đưa ra những nhận xét, đánh giá hiệu năng và khẳng định bằng thực nghiệm mô phỏng về các giải thuật này. 64 Chương 4: ĐÁNH GIÁ VÀ SO SÁNH WRED VỚI DROP-TAIL VÀ RED 4.1. Giới thiệu bộ mô phỏng mạng NS-2 NS-2 là phần mềm mô phỏng mạng hướng đối tượng, được viết bằng ngôn ngữ C++ và OTcl. Bằng NS-2, ta có thể tạo ra các nút mạng theo 1 topo xác định, sau đó gắn các nguồn sinh lưu lượng dữ liệu lên các thực thể giao thức để truyền qua mạng, theo các giao thức định tuyến xác định, từ đó quan sát cách thức hoạt động của mạng và phân tích dữ liệu đến và đi qua các node. Sử dụng NS-2 mang lại 4 lợi ích chính: − Có khả năng kiểm tra, mô phỏng các giao thức sẵn có theo nhiều kịch bản, topo mạng khác nhau − Cho khả năng thử nghiệm, đánh giá các giao thức mạng mới trước khi triển khai thực hiện và đưa vào sử dụng trong mạng thực. − Khả năng thực thi mạnh: có những mô hình mạng lớn mà gần như ta không thể triển khai được trong thực tế nhưng lại dễ dàng xây dựng trên NS-2. − Có thể mô phỏng nhiều loại mạng khác nhau và rất linh hoạt khi xây dựng kịch bản. NS-2 là phần mềm mã nguồn mở có sẵn cho cả nền Windows 32 và Linux. Trong hệ thống mạng xây dựng cho luận văn, chúng tôi triển khai trên hệ điều hành Ubuntu 10.04 Lucid Lynx, phiên bản của phần mềm là 2.33. NS-2 được cài đặt chuẩn thông qua tiện ích aptitude, khai báo nguồn trong source.list như sau: deb lucid main deb-src lucid main 4.2. Thiết lập tô-pô mạng mô phỏng Trong các thí nghiệm mô phỏng DropTail, RED, WRED, chúng tôi sử dụng chung một tô-pô mạng mô phỏng (node, link...) để so sánh ưu nhược điểm giữa các giao thức. Nhằm mục tiêu kiểm tra hoạt động của hàng đợi nên hệ thống mạng mô phỏng cần phải có 1 đường truyền là nút cổ chai, có băng thông nhỏ hơn tổng thông lượng truyền qua nó. Mạng mô phỏng có cấu trúc như trong hình sau: 65 Hình 4.1 Cấu trúc mô phỏng Hệ thống gồm 8 nút, trong đó R1, R2, CORE đóng vai trò là router trên đường đi, S1, S2, S3, S4 là nguồn phát và DEST là đích. Với mục đích minh họa các chiến lược quản lý hàng đợi để chống tắc nghẽn, hệ thống được thiết kế như trên với nhiều nguồn phát tới đích, đi qua mạng có điểm nút cổ chai là đường truyền (link) nối nút CORE và nút R2 với băng thông thấp. Tất cả các đường truyền đều là song công với thời gian đáp ứng và băng thông như trên hình vẽ. Mỗi nguồn S1, S2, S3 được gắn với 1 thực thể gửi (nguồn) của giao thức TCP, mỗi thực thể gửi TCP lại được gắn với một nguồn sinh lưu lượng của ứng dụng FTP, đó là: ftp(1,1) ; ftp(1,2); ftp(1,3); ftp(2,1).... Nguồn sinh lưu lượng trên nút S4 phát dữ liệu với tốc độ không đổi - CBR bằng giao thức UDP. Nguồn S3 và S4 nằm trên nút nỗi với các đường truyền có băng thông lớn nhằm mục đích tạo ra các thời điểm bùng phát, truyền nhiều dữ liệu làm ngập nút cổ chai. Các thông số quan trọng khác: kích thước cửa sổ tối đa của các luồng TCP: 50; kích thước các gói tin: 100 byte. Router ghi nhãn CORE là nơi sẽ xảy ra tắc nghẽn, ta sẽ triển khai các dịch vụ quản lý hàng đợi tại đó để so sánh đặc tính của các chiến lược quản lý hàng đợi. 4.3. Kịch bản mô phỏng Trong các thí nghiệm mô phỏng DropTail, RED, WRED sử dụng chung 1 kịch bản mô phỏng (tô-pô mạng, các nguồn sinh lưu lượng, các thời điểm bắt đầu, kết thúc truyền, kích thước hàng đợi...). Mục tiêu của kịch bản là nhằm tạo ra ngữ cảnh thuận lợi cho việc quan sát trạng thái của hệ thống như: số gói tin trong hàng đợi, phục hồi tốc độ truyền giữa các nguồn, số gói tin bị mất… khi hệ thống trong trạng thái bình thường và khi có xảy ra tắc nghẽn. Với mỗi một giao thức, ta có 3 kịch bản như sau: − Kịch bản 1: Tăng cường độ tắc nghẽn với các nguồn phát TCP  Giây 0.1, 10 và 20 lần lượt các nguồn S1, S2, S3 bắt đầu truyền 1 luồng ftp tương ứng. 66  Tại giây 20, lúc S3 bắt đầu truyền thì tổng băng thông của 3 nguồn đã bắt đầu lớn hơn băng thông của nút cổ chai (3Mbps), nhưng do có hàng đợi nên vẫn trong phạm vi xử lý được của router CORE.  Đến giây 30, tại nguồn S3 thì 2 luồng ftp(3,2) và ftp(3,3) cùng lúc truyền và chiếm hết băng thông 5Mbps của link S4-R1. Từ đó tạo nên thời điểm tắc nghẽn ở nút cổ chai.  Đến giây 40, cả 3 luồng TCP tại S3 đều đột ngột dừng truyền, mô tả burst dữ liệu đã hết. Từ đó ta sẽ quan sát sự phục hồi về tốc độ truyền của S1 và S2.  Code: $ns at 0.1 "$ftp(1,1) start" $ns at 10 "$ftp(2,1) start" $ns at 20 "$ftp(3,1) start" $ns at 30 "$ftp(3,2) start" $ns at 30 "$ftp(3,3) start" $ns at 40 "$ftp(3,1) stop" $ns at 40 "$ftp(3,2) stop" $ns at 40 "$ftp(3,3) stop" − Kịch bản 2: Tăng cường độ tắc nghẽn với nguồn phát UDP  Thí nghiệm này có 2 phần: theo dõi, so sánh sự thay đổi khi có sự bùng phát về lưu lượng UDP trong 2 trường hợp UDP: khi các luồng TCP đang chạy ổn định và khi các luồng TCP cũng đang tắc nghẽn.  Thí nghiệm thực hiện với thông lượng của luồng UDP là 5Mbps. Trong khi đó băng thông của nút cổ chai chỉ là 3Mbps. Tình trạng tắc nghẽn sẽ xảy ra tại link CORE-R2, các gói tin sẽ được cache trong queue của router Core.  Code: $ns at 0.1 "$ftp(1,1) start" $ns at 0.1 "$ftp(2,1) start" $ns at 10 "$ftp(3,1) start" $ns at 20 "$cbr4 start" $ns at 30 "$cbr4 stop" $ns at 40 "$ftp(3,1) stop" - Kịch bản 3: Luồng ưu tiên bắt đầu chạy khi đang có tắc nghẽn  Kịch bản này chỉ áp dụng với cơ chế WRED với chức năng đặt ưu tiên truyền dữ liệu theo nguồn phát.  Khi mạng bị tắc nghẽn bởi nguồn CBR cbr4, các luồng dữ liệu TCP với độ ưu tiên khác nhau lần lượt được phát. Sau một thời gian thì luồng gây tắc 67 nghẽn CBR dừng truyền, từ đó ta sẽ quan sát được độ phục hồi của hệ thống.  Code: $ns at 0.1 "$cbr4 start" $ns at 0.1 "$ftp(2,1) start" $ns at 10 "$ftp(1,1) start" $ns at 20 "$ftp(3,1) start" $ns at 20 "$ftp(3,2) start" $ns at 20 "$ftp(3,3) start" $ns at 30 "$cbr4 stop" $ns at 40 "$ftp(2,1) stop" 4.4. Đánh giá hiệu năng truyền thông đa phương tiện khi sử dụng DropTail và RED 4.4.1 Kịch bản 1: Tăng cường độ tắc nghẽn với các nguồn phát TCP a. Kết quả Ta theo dõi 2 giải thuật DropTail và RED dựa trên 3 tham số: tỉ lệ packet mất, kích thước hàng đợi và thông lượng sử dụng. Hình 4. 2 Tỉ lệ packet bị mất của DropTail và RED 68 Hình 4. 3 – Kích thước hàng đợi của DropTail và RED Hình 4. 4 Thông lượng của DropTail và RED b. Nhận xét − Trong vòng 20 giây đầu, chưa có sự quá tải băng thông xảy ra, vì thế trong cả 2 giao thức thì luồng dữ liệu đều đi qua thông suốt, gần như không có packet nào phải ở trong hàng đợi. Tốc độ truyền của các luồng TCP qua link giữa 2 router CORE – R2 đạt tốc độ tối đa. − 20s – 30s: bắt đầu xuất hiện tắc nghẽn, các gói tin được lưu lại ở trong hàng đợi. Với giao thức DropTail thì đạt ổn định khoảng 38 packet thường xuyên trong 69 queue, dưới ngưỡng tối đa 50 packet của link, và vì thế không có packet nào bị drop, dù băng thông đã bị đầy. Nhưng giao thức RED lại khác, do có cơ chế drop sớm các gói tin trong hàng đợi nên đã xuất hiện các packet bị mất, từ đó lưu lượng truyền dao động, không liên tục đạt ngưỡng tối đa 3Mbps, nhưng bù lại số gói tin trong hàng đợi giảm hẳn, dao động mạnh trong khoảng từ 0 đến 36 packet. − 30s - 40s: lưu lượng truyền tăng cường TCP, tại giây 30 đột ngột tăng làm tràn đầy queue (hiện tượng lock out) ở cả 2 giao thức. Với DropTail, do đặc tính của nó nên băng thông lúc nào cũng được sử dụng tối đa, tuy nhiên số gói tin trong hàng đợi dao động hết sức thất thường, từ 0-50 packet, rất thường xuyên đạt ngưỡng 50 packet và drop mọi gói tin đến (hiện tượng lockout). Với RED, do có khả năng drop sớm nên không bị hiện tượng này, và số gói tin trong hàng đợi vẫn dao động ổn định quanh ngưỡng từ 5 đến 35 packet. − 40s – 50s: quá trình bùng phát dữ liệu kết thúc, hàng đợi được giải phóng, không có gói tin nào bị mất. Trong thí nghiệm này thì giao thức DropTail tỏ ra tốt hơn khi gần như ngay lập tức tốc độ truyền của S1 và S2 đã duy trì ở mức tối đa. Trong khi đó, dựa vào biểu đồ băng thông, ta thấy với giao thức RED thì S1 và S2 phải mất 2 giây để từ từ tăng window size lên để truyền với tốc độ cao nhất. Nguyên nhân của việc này là do trong quá trình trước đó, RED đã drop nhiều gói tin hơn hẳn so với DropTail, trong đó vì tính ngẫu nhiên, nhiều gói tin từ nguồn S1, S2 cũng bị drop theo, vì thế trường window size từ 2 nguồn này đã giảm thấp và cần thời gian để phục hồi. 4.4.2. Thí nghiệm 2: Tăng cường độ tắc nghẽn với nguồn phát UDP a. Kết quả Ta theo dõi sự thay đổi của thông lượng - throughput sử dụng trên link CORE – R2 với 2 lần thay đổi mức độ bùng phát UDP như kịch bản đã phát biểu ở trên. Hình 4. 5 Kích thước hàng đợi của DropTail và RED 70 Hình 4. 6 Thông lượng của Droptail và RED khi CBR có throughput 3Mbps Hình 4. 6.2. Thông lượng của Droptail và RED khi CBR có throughput 5Mbps 71 Hình 4.7. Tỉ lệ packet bị mất của Droptail và RED b. Nhận xét: Giao thức UDP truyền tin không tin cậy, nó không sử dụng trường window size hay 1 cơ chế nào khác để tự giảm tốc độ truyền mà chỉ đơn thuần là làm ngập băng thông, khác với giao thức TCP có thể tự giảm tốc độ truyền khi gặp tắc nghẽn. Trong thí nghiệm 2, ta có thể thấy tại giây 30, sau khi dừng phát UDP, chỉ còn luồng TCP đang hoạt động, thì có sự khác biệt giữa tốc độ phục hồi của luồng TCP giữa giao thức DropTail và RED. Trong trường hợp mức độ bùng phát tại nguồn UDP chưa thật sự lớn (3Mbps, bằng với băng thông nút cổ chai) thì kết quả thu được cho thấy 2 nguồn TCP khi sử dụng giao thức RED có thể phục hồi nhanh hơn hẳn so với DropTail. Cụ thể tại các giây 30, 3 luồng TCP ở RED với tổng thông lượng 100Kbps chỉ mất 2s để đạt được thông lượng tối đa 3Mbps. Trong khi đó với Droptail thì từ 0 Kbps và phải mất đến 5s mới phục hồi hoàn toàn, lâu hơn 2,5 lần. Tuy nhiên khi mức độ bùng phát tại nguồn UDP nghiêm trọng (5Mbps) thì kết quả thu được giữa 2 giao thức là không có sự khác biệt rõ ràng. Với lượng dữ liệu lớn, ngập tràn thì thuật toán loại bỏ sớm ngẫu nhiên của RED không còn tỏ ra hiệu quả, và tốc độ phục hồi ở giây 30 như trong thí nghiệm trên không có nhiều sự khác biệt so với giải thuật DropTail. 4.5. Đánh giá hiệu năng truyền thông đa phương tiện khi sử dụng WRED Topô mạng và kịch bản được xây dựng chung như đã trình bày trong phần trên. WRED có nhiều loại khác nhau, tùy theo mục đích cần minh họa cho Policier Type nào mà ta sẽ có kịch bản tùy chỉnh các tham số tương ứng. Chi tiết sẽ được trình bày trong mô phỏng cụ thể tiếp theo. 4.5.1. Mô phỏng WRED TSW2CM và TSW3CM 72 a. Cấu hình mô phỏng 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 73 ứ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 [ 74 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 75 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. 12 Kết quả so sánh thông lượng của RED với ba chính sách của WRED 76 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 - Kịch bản 3: Luồng ưu tiên bắt đầu chạy khi đang có tắc nghẽn 77 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. 15 Kết quả so sánh thông lượng của RED với ba chính sách của WRED 78 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 79 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. 80 − 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. 81 − Độ 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ẻ. Sơ đồ triển khai của hệ thống như sau: 82 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. 83 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. 84 Hình 4.19 Sơ đồ hệ thống Streaming Video trong doanh nghiệp 85 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. 86 [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.