Tìm hiểu thuật toán choke
MỤC LỤC MỤC LỤC..................................................................................................................1 1 I. GIỚI THIỆU Internet cung cấp một nổ lực kết nối tốt nhất, các dịch vụ gói dữ liệu truyền đầu cuối sử dụng giao thức IP. Nó phụ thuộc vào cơ chế tránh tắc nghẽn thực hiện trong lớp vận chuyển giao thức như TCP, để cung cấp dịch vụ tốt dưới tải nặng. Tuy nhiên có nhiều TCP không bao gồm các cơ chế tránh tắc ngẽn ngẫu nhiên hay tai nạn. Hơn nữa số các ứng dụng chạy trên Internet dựa trên nền UDP ngày càng tăng, chẳng hạn như các gói thoại và gói video. Luồng của các ứng dụng này không quay trở lại đúng khi gặp sự cố tắc nghẽn. Kết quả là, nó chiếm hầu hết băng thông của dòng TCP tương thích khác. Điêu này có thể gây ra khủng hoảng trên Internet mà người ta gọi là “Internet Meltdown”. Do đó, cần thiết phải có cơ chế định tuyến để bảo vệ luồng hồi đáp từ luồng không hồi đáp hoặc luồng hoạt động mạnh và cung cấp dịch vụ (QoS) chất lượng tốt cho tất cả người sử dụng. Có hai loại thuật toán định tuyến để điều khiển tắc nghẽn được sử dụng rộng rải là lớp "thuật toán lập lịch trình" và lớp "thuật toán quản lý hàng đợi". Lớp thuật toán lập lịch trình, mà nổi tiếng là thuật toán FQ, đòi hỏi các vùng đệm ở đầu ra của bộ định tuyến chia thành các hàng đợi riêng biệt, nơi mà sẽ là vùng đệm cho các gói tin của mỗi luồng. Gói dữ liệu từ vùng đệm của luồng được cho qua bằng cách sử dụng một lịch trình theo quy tắc luân chuyển dần dần. Vì xếp hàng theo luồng nên các gói tin thuộc các luồng khác nhau về cơ bản độc lập với nhau và một luồng không làm ảnh hưởng đến các luồng khác. Tuy nhiên phương pháp này quá phức tạp ở thông tin trạng thái mỗi luồng, phải bỏ chi phí quá lớn khi triển khai trên diện rộng. Để giảm chi phí của việc duy trì thông tin trạng thái luồng, gần đây Stoica và cộng sự đã đề xuất một thuật toán lập lịch trình gọi là Core Stateless Fair Queueing (CSFQ). Trong phương pháp này định tuyến được chia thành hai loại: bộ định tuyến biên và bộ định tuyến lõi. Một bộ định tuyến biên giữ mỗi thông tin trạng thái luồng và ước tính tỷ lệ xuất hiện của từng luồng. Các ước tính được đưa vào tiêu đề gói tin và truyền lại cho 2 các bộ định tuyến lõi. Bộ định tuyến lõi chỉ đơn giản là duy trì một hàng đợi FIFO phi trạng thái và trong thời gian tắc ngẻn giảm một gói tin ngẫu nhiên dựa trên các ước tính tỷ lệ. Đề án này làm giảm độ phức tạp thiết kế cho các bộ định tuyến lõi. Tuy nhiên việc thiết kế bộ định tuyến biên vẫn còn rất phức tạp. Ngoài ra, vì những thông tin tỷ lệ trong tiêu đề, các bộ định tuyến lõi cần phải giải nén gói tin khác nhau từ các bộ định tuyến truyền thống. Một chương trình khác cũng đáng chú ý với mục đích gần với FQ nhưng chi phí nhỏ hơn là SFQ do McKinney đề xuất. SFQ phân loại các gói tin vào hàng đợi nhỏ hơn FQ sử dụng một hàm băm. Mặc dù điều này làm giảm thiết kế phức tạp của FQ, nhưng SFQ vẫn cần khoảng 1.000-2.000 hàng đợi trong một bộ định tuyến điển hình để đạt được hiệu suất của FQ. Do đó các thuật toán lập lịch trình có thể cung cấp một phân bổ băng thông công bằng, nhưng lại quá phức tạp cho triển khai tốc độ cao và không tốt cho quy mô có nhiều người sử dụng.Mặt khác các thuật toán quản lý hàng đợi từ đầu đã có thiết kế đơn giản. Và với sự đơn giản đó ta mong hi vọng có được sự gần công bằng. Lớp thuật toán này được minh họa bới thuật toán RED. Bộ định tuyến thực hiện RED duy trì một hàng đợi FIFO duy nhất cho tất cả các luồng, và làm rơi ngẫu nhiên các gói tin đến trong thời gian xảy ra tắc ngẽn. Xác suất rơi tăng giảm dựa vào mức độ tắc ngẽn. Khi RED dự đoán sẽ xảy ra tắc ngẽn để không xảy ra việc cắt phần đuôi và hàng đợi đầy là vấn đề hay xảy ra trong cơ chế DropTail. Bằng cách dữ kích thước hàng đợi trung bình nhỏ, RED giảm sự chậm trể của hầu hết các luồng. Tuy nhiên, như Drop Tail, RED không thể giải quyết các luồng không hồi đáp. Điều này là do tỷ lệ phần trăm của các gói rơi từ mỗi dòng trong một khoảng thời gian là gần như giống nhau. Do đó, luồng dữ liệu không tương thích có thể chiếm nhiều băng thông và làm chết các luồng TCP . Để cải thiện khả năng của RED cho những luồng không phản hồi các phiên bản như RED với box bất lợi, hay FRED đả được đề xuất. Tuy nhiên, các phiên bản phải chịu thêm chi phí thực hiện khi nó phải thu thập thông tin trạng thái. RED với box bất lợi lưu trữ thông tin về luồng khó sử dụng trong khi FRED cần thông tin về kết nối hoạt động. Các nghiên cứu gần đây của Ott và cộng sự đề xuất một thuật toán thú vị được gọi là ổn định RED (SRED) , SRED ổn đinh xác 3 suất sử dụng bộ đệm FIFO, độc lập với số lượng luồng hoạt động. Thú vị hơn, SRED ước tính số lượng kết nối hoạt động và tìm thấy các ứng cử viên cho luồng không tương thích. Thực hiện bằng cách duy trì một cấu trúc dữ liệu, được gọi là "Zombie list", xử lý như là sự ủy nhiệm cho những thông tin của luồng gần nhất. Mặc dù SRED xác định được luồng không tương thích, nhưng nó không đề nghị một cơ chế định tuyến đơn giản để xử lý các luồng không tương thích. Thuật toán CHOKe đề xuất dưới đây vừa xác định vừa chống lại luồng không tương thích, và đơn giản dễ thực hiện hơn SRED. Tóm lại, tất cả các thuật toán định tuyến (lập kế hoạch và quản lý hàng đợi) phát triển cho đến nay hoặc có thể cung cấp sự công bằng hoặc đơn giản để thực hiện, nhưng không phải cả hai cùng một lúc. Điều này cho ta suy nghĩ rằng chúng xung khắc với nhau. Trong bài viết này dẫn theo hướng bắc cầu cho sự đơn giản và công bằng. Cụ thể là thuật toán hoạt động quản lý hàng đợi, được gọi là CHOKe, đơn giản để thực hiện (vì nó không cần thông tin trạng thái) và theo cách khác chống lại luồng không tương thích bằng cách làm rơi các gói dữ liệu của chúng. Bằng cách này, CHOKe (chọn và dữ luồng phản hồi và loại bỏ luồng không phản hồi) nhằm mục đích đảm bảo gần công bằng max-min cho các luông qua bộ định tuyến tắc ngẽn. Ý tưởng cơ bản đằng sau CHOKe là nội dung bộ đệm FIFO tạo thành một "bảng thống kê đủ số liệu" về lưu lượng truy cập đến và có thể được sử dụng một cách đơn giản để giải quyết các luồng không tương thích. Khi một gói tin tới một bộ định tuyến tắc nghẽn, CHOKe rút ra một gói tin ngẫu nhiên từ bộ đệm FIFO và so sánh nó với các gói tin đến, nếu cả hai đều thuộc về cùng một dòng, thì cho cả hai rơi, ngược lại thì giữ lại gói chọn ngẫu nhiên và các gói tin đến được nạp vào bộ đệm với một xác suất phụ thuộc vào mức độ tắc nghẽn (xác suất này được tính toán chính xác như trong RED). Do thực hiện được điều này nên bộ đệm FIFO có nhiều khả năng lựa chọn được các gói cùng một luồng để so sánh. Hơn nữa các gói thuộc vào luồng chiếm nhiều băng thông có nhiều khả năng bị so sánh. Giao điểm của xác xuất cao chính là thời điểm gói tin của 4 luồng không tương thích bị rơi. Do đó gói tin của các luồng không tương thích sẽ rơi nhiều hơn các gói tin thuộc luồng tương thích II. THUẬT TOÁN CHOKE Nhu cầu về một thuật toán không trạng thái mà có thể đạt được việc cô lập hoạt động các luồng và/hoặc phân bổ băng thông xấp xỉ công bằng. Mà các thuật toán hiện có (như RED, FQ và những thuật toán khác) chỉ có thể giải quyết được một trong hai vấn đề. Vì thế cần phải có phương án có thể giải quyết luồng "không thân thiện" hoặc "không phản hồi" mà phải tìm cách bảo tồn một số tính năng chính của RED; như khả năng tránh đồng bộ toàn cục, đảm bảo độ trể thấp, và tránh được bùng phát lưu lượng dữ liệu. Bằng cách làm này, trong trường hợp không có luồng không thân thiện hoặc luồng không phản hồi thuật toán sẽ thực hiện tương tự như RED. Tiếp theo, cần một chuẩn mực để so sánh mức độ công bằng đạt được bằng giải pháp sử dụng CHOKe. Dựa và giá trị lớn nhất nhỏ nhất của sự công bằng như là điều tự nhiên vì hai lý do: thứ nhất nó được sử dụng rộng rãi trong mạng máy và thứ hai là thuật toán FQ đả đạt được điều đó. Tuy nhiên, đối với bất kỳ chương trình nào để đạt được hoàn hảo công bằng Max-min mà không cần thông tin trạng thái của luồng dữ liệu dường như là không thể. Công bằng max-min là không phù hợp trong trường hợp ta không nhận biết được luồng cùng với sự phân phối tài nguyên nhỏ nhất cũng như lớn nhất. Thay vào đó, chúng ta xác định và làm giảm việc phân bổ các luồng tiêu thụ hầu hết các nguồn tài nguyên. Nói cách khác, chúng ta cố gắng để giảm thiểu tiêu thụ tài nguyên của luồng cực đại hoặc tìm kiếm sự công bằng min-max. Tài nguyên được giải phóng như một kết quả của việc giảm thiểu tiêu thụ lưu lượng tối đa được phân phối giữa các luồng khác. Trên Internet trước đây sử dụng TCP or UDP và sau này là TCP. Thuât toán CHOKe Giả sử một router duy trì một bộ đệm FIFO cho các gói tin của tất cả các luồng. Thuật toán CHOKe sử dụng cách khác để xử lý luồng không thân thiện và không phản hồi. Giả sử thông tin trạng thái được lấy từ luồng tích cực và ID luồng trong mỗi gói là không 5 biết đến trong thuật toán. CHOKe tính toán xác suất trung bình của bộ đệm FIFO sử dụng kích thước trung bình hàm mũ tương tự RED. Nó cũng đánh dấu hai ngưỡng trên bộ đệm, ngưỡng minth và ngưởng maxth. Nếu kích thước hàng đợi trung bình bé hơn minth tất cả các gói tin đến được đưa vào bộ đệm FIFO. Nếu tổng tỷ lê đến là nhỏ hơn so với sức chứa của đầu ra, kích thước hàng đợi trung bình không đạt ở mức min th và các gói dữ liệu không bị rơi nhiều. Nếu kích thước hàng đợi trunh bình hơn max th thì toàn bộ gói tin đến đều bị rơi. Lúc này điều chỉnh xác suất hàng đợi xuống dưới ngưỡng maxth. Khi kích thước trung bình lớn hơn ngưỡng min th thì mỗi gói đến được so sánh với gói lựa chọn ngẩu nhiêu từ vùng đệm, được gọi là gói ứng viên. Nếu nó thuộc cùng một luồng thì cả 2 đều cho rơi. Nếu không, gói tin trong vùng đệm được dữ nguyên vị trí, còn các gói tin đến sẽ cho rơi với xác suất tùy theo kích thước hàng đợi trung bình. Xác suất rơi được tính toán chính xác như trong RED. Như vậy khi xác suất là 1 thì có nghĩa là kích thước hàng đợi trung bình đa vượt qua ngưỡng max th. Hình 1: Sơ đồ thuật toán CHOKe Để công suất hàng đợi quay lại dưới mức maxth càng nhanh càng tốt, thì chúng ta vẫn so sánh và cho rơi gói tin từ hàng đợi khi kích thước hàng đợi trên mức max th. 6 Nói chung, có thể lựa chọn m> 1 gói dữ liệu từ bộ đệm, đem chúng so sánh với các gói tin gửi đến, và cho rơi các gói tin cùng luồng với gói tin đến. Không ngạc nhiên khi lựa chọn nhiều ứng viên cho rơi làm hoàn thiện hiệu suất thực hiện của CHOKe. Điều này đặc biệt đúng khi có nhiều luồng không phản hồi, thực vậy khi số lượng luồng không phản hồi tăng thì việc cần thiết là phải chọn nhiều gơi tin ứng viên cho rơi hơn. Tuy nhiên khi tác giả có ý tưởng thiết kế hoàn toàn không dựa vào trạng thái, thì chúng ta không thể biết có bao nhiêu luồng không phản hồi đang hoạt động tại thời điểm đang xét (để sau đó chọn giá trị phù hợp cho m). Nó chỉ ra rằng chúng ta có thể xử lý để thuật toán tự động chọn giá trị thích hợp m>1. Một cách để đạt được điều này là đưa vào một ngưỡng trung gian ở giữa max th và minth. Khi xác suất bộ đệm trung bình nằm trong ngưỡng min th và intth thì cho m=1, và khi xác suất nằm từ ngưỡi int th và maxth thì cho m=2 . Một cách tổng quát hơn ta có thể phân thành k ngưỡng nằm giữa min th và maxth , k ngưỡng đó là R 1, R2, …Rk và chọn giá trị khác nhau của m tùy thuộc vào khu vực xác suất trung bình bộ đệm rơi vào. Ví dụ ta lấy m=2*i (i=1,2,..k), khi xác suất trung bình ở vùng R i. Rõ ràng chúng ta phải tăng m tỉ lệ cùng với kích thước hàng đợi trung bình. CHOKe là thuật toán không trạng thái, nó đòi hỏi một cấu trúc dữ liệu đặc biệt. So với một hàng đợi FIFO thuần túy, cần có thêm một số thao tác đơn giản mà CHOKe cần để thực hiện: lấy ra một gói tin ngẫu nhiên từ hàng đợi, so sánh với ID luồng và có thể cho rơi cả gói tin ứng viên lẫn gói tin đến. Vì CHOKe nhúng vào RED nên nó thừa hưởng những tính năng tốt của RED đã được biết đến trước đó. Cuối cùng, như một thuật toán không trạng thái, nó thực hiện đơn giản gần như RED. Để thấy điều này chúng ta hãy xem xét chi tiết thực hiện. Rút ngẫu nhiên một gói tin có thể được thực thi bởi một địa chỉ ngẩu nhiên được đọc từ địa chỉ luồng của gói tin. Việc so sánh địa chỉ luồng là dễ thực hiện trên phần cứng. Việc thả gói tin chọn ngẫu nhiên được cho là khó khăn hơn, tức là loại bỏ nó ra khỏi dach sách liên kết. Thay vì thực hiện điều này chúng ta đề nghị thêm một bit tiêu đề (bit header) của gói tin. Bit này sẽ là 1 nếu là gói ứng viên để thả rơi. Khi một gói tin 7 truyền đến đầu bộ đệm của FIFO, trạng thái của bit này xác định ngay lập tức có nên cho rơi gói tinh hay tiếp tục truyền đi. III. KẾT QUẢ MÔ PHỎNG Phần này trình bày kết quả mô phỏng thực hiện thuật toán CHOKe trong giải quyết các luồng không tương thích và do đó đạt được phân bổ băng thông xấp xỉ cân bằng. Chúng ta sẽ sử dụng RED và Drop Tail, là các thuật toán có độ phức tạp gần với CHOKe để so sánh. 1. Đơn tắc nghẽn Để minh họa hoạt của CHOKe khi có một đường tắc nghẽn duy nhất, chúng ta xem xét cấu hình mạng tiêu chuẩn thể hiện trong hình 2. Liên kết tắc ngẽn này xảy ra giữa R1 và R2. Liên kết với mức 1 Mbps, được chia sẻ bởi m TCP và UDP n luồng. Một máy nhận được kết nối với bộ định tuyến sử dụng một liên kết 10 Mbps, gấp 10 lần công suất của băng thông liên kết. Tất cả các liên kết đều có độ trễ 1ms là nhỏ, do đó độ trễ là do sự chậm trễ của bộ đệm hơn là sự chậm trễ của đường truyền. Kích thước cửa sổ tối đa của TCP được thiết lập là 300 điều này không trở thành nhân tố giới hạn lưu lượng của luồng. Dòng TCP có nguồn gốc từ các phiên FTP cái mà truyền tải tệp với kích thước lớn hơn. Máy chủ UDP gửi các gói tin với tốc độ bit không đổi (CBR) của r Kbps, trong đó r là một biến. Tất cả các gói được thiết lập cùng một kích thức là 1K Bytes. 8 Hình 2: Cấu hình mạng gồm m nguồi TCP và n nguồn UDP Nghiên cứu nhiều nguồn UDP không tương thích qua bộ định tuyến sử dụng chương trình quản lý hàng đợi khác nhau, chúng ta thiết lập mô phỏng sau: Mô phỏng gồm có 32 nguồn TCP (luồng 1 đến luồng 32) và 1 nguồn UDP (luồng 33) trong mạng. Nguồn UDP gửi các gói với tốc độ r = 2 Mbps, gấp đôi băng thông của liên kết nút cổ chai, do vậy mà liên kết R1-R2 trở nên tắc nghẽn. Các ngưỡng min th ở RED và CHOKe thiết đặt là 100, cho phép khoảng 3 gói trên một luồng đi vào vùng đệm trước khi bộ định tuyến bắt đầu cho rơi gói tin. Tiếp theo là thiết lập ngưỡng max th bằng 2 lần ngưỡng minth, và kích thước hàng đợi vật lý được cố định là 300 gói. Biểu đồ lưu lượng của luồng UDP dưới các thuật toán điều khiển bộ định tuyến: DropTail, RED and CHOKe ở hình 3. 9 Hình 3. So sánh lưu lượng UDP Hình 3, chúng ta có thể thấy rõ rằng RED và DropTail không nhận biết và cản trở luồng không hồi đáp. Luồng UDP chiếm hơn 95% công suất liên kết nút cổ chai và các kết nối TCP chỉ có thể dữ 50 kbps còn lại. CHOKe cải thiện thông lượng của giao thức luồng TCP đáng kể bằng cách hạn chế băng thông UDP đến 250 Kbps, chiếm khoảng 25% khả năng liên kết. Thông lượng tổng số các dòng TCP được nâng từ 50 Kbps đến 750 Kbps. Để đánh giá mức độ phân phối băng thông công bằng của CHOKe, xét 33 kết nối với lưu lượng riêng biệt trong mô phỏng trên, cùng với sự công bằng lý tưởng cho mỗi luồng, được thể hiện ở biểu đồ trong hình 4. Hình 4: Lưu lượng cho mỗi luồng ở thuật toán CHOKe Mặc dù thông lượng của luồng UDP (luồng 33) vẫn còn cao hơn so với các luồng TCP còn lại, nhưng có thể thấy rằng với mỗi luồng TCP được phân bổ băng thông là tương đối công bằng. Trong CHOKe, một gói tin có thể bị rơi vì sự va chạm hoặc một loại bỏ ngẫu nhiên như trong RED. Một luồng không tương thích, là luồng có một tỷ lệ gói tin cao và xác suất sử dụng bộ đệm cao, phải chịu rơi gói tin chủ yếu là do các sự va chạm. Mặt khác, các gói tin của luồng có hồi đáp rất khó để được xuất hiện, và do đó bị rơi chủ yếu là do loại bỏ ngẫu nhiên. Trong các mô phỏng trên đây, chúng ta thấy rằng 10 sự va chạm chiếm 85% gói tin rơi của UDP, trong khi 70% các gói tin rơi của TCP là do loại bỏ ngẫu nhiên. Chúng ta thay đổi tỷ lệ đến r của UDP để nghiên cứu hiệu suất CHOKe với điều kiện lưu lượng tải khác nhau. Kết quả mô phỏng được tóm lược trong Hình 5, cho thấy thông lượng của UDP chống lại tỉ lệ đến. Hình 5: Hiệu suất CHOKe dưới lưu lượng tải khác nhau Tỷ lệ phần trăm rơi của luồng UDP cũng được hiển thị trong hình. Ngưỡng min th và ngưỡng maxth được thiết lập là 30 và 60 gói để thấy được Choke thực hiện chương trình theo thiết lập ngưỡng khác nhau. Từ biểu đồ chúng ta có thể thấy rằng CHOKe làm rơi 23% gói UDP khi tỉ lệ đến dưới 100Kbps. Và khi tỉ lệ đến tăng lên thì tỉ lệ phần trăm rơi sẽ tăng lên. Và gần như tất cả gói tin đều rơi (98.3%) khi tỉ lệ đến là 10Mbps. Thông lượng trung bình của TCP thì không thay đổi. Trong biểu đồ cho thấy RED thực hiện dưới nhiều lưu lượng tải khác nhau cũng không khác. Điều này cho thấy RED không tách biệt luồng không hồi đáp khi cho rơi gói tin và luồng không hồi đáp có thể chiếm hết băng thông của mạng và gây ra sự bất lợi cho các luồng tương thích. Khi kích thước hàng đợi trung bình đạt ngưỡng max th tất cả các gói tin đến đều bị rơi, RED trở thành Drop Tail. Trong hình 6 cho thấy việc phân phối hàng đợi cho luồng với điều kiện tải trọng luồng khác nhau. 11 Hình 6: Phân phối hàng đợi dưới trọng tải khác nhau Không ngạc nhiên khi CHOKe có thể kiểm soát kích thước hàng đợi trung bình như RED vì nó kế thừa từ RED. Khi tỷ lệ đến của luồng UDP là 100 Kbps, CHOKe có thể phát hiện sự khác biệt nhỏ này và giảm 23% lưu lượng UDP. Khi tỷ lệ đến UDP tăng lên, thị phần của sự chiếm đóng hàng đợi của nó tăng lên. Do đó, gói UDP dễ dàng trở thành ứng viên cho việc thả gói tin. Bên cạnh đó, với tỷ lệ xuất hiện ngày càng tăng, dòng chảy UDP tạo nên nhiều sự so sánh hơn. Kết quả là, khả năng có được sự trùng khớp gói UDP tăng. Cùng với mỗi sự trùng khớp có 2 gói tin bị rơi, một trong số đó là từ hàng đợi. Vì vậy, khi xác suất của sự trùng khớp dần đến 0.5, cho mỗi gói tin UDP đến, có trung bình 0,5* 0+ 0,5* 0,2 = 1 gói tin bị rơi, tỷ lệ rơi các gói tin UDP đến gần đến 1 và một luồng lưu lượng tốt của UDP về giá trị 0. Điều này giải thích tại sao lưu UDP đi xuống dưới tải nặng và lý do tại sao kích thước hàng đợi trung bình của luồng UDP không trở thành phần chiếm ưu thế của việc sử dụng hàng đợi. Chúng ta sẽ tìm hiểu chi tiết trong phần tiếp theo. 2. Đa tắc ngẽn Ở phần này chúng ta sẽ tìm hiểu sự thực hiện của CHOKe trên nhiều vị trí tắc ngẽn trên mạng như hình 7. 12 Hình 7: Cấu trúc đa liên kết Liên kết đầu tiên giữa bộ định tuyến R1 và R2 (R1-R2) có công suất 10 Mbps để khi các nguồn kết nối với nó gửi các gói dữ liệu với tốc độ cao, liên kết sau R2-R3 trở nên tắc nghẽn. Liên kết thứ ba, R3-R4, băng thông chỉ bằng một nữa của liên kết R2-R3 và trở nên tắc nghẽn vì tỷ lệ gói tin đến vượt quá khả năng của nó. Cuối cùng liên kết R4R5 với trọng tải 10Mbps. Sử dụng mạng này cho thấy sự xử lý của CHOKe dưới tác động của nhiều kết nối tắc ngẽn. Với tổng 25 luồng TCP và 1 luồng UDP trong mạng thể hiện như hình 7. Nguồn UDP gửi các gói với tốc độ 2 Mbps, trong khi các thông số mạng khác vẫn như thể hiện ở hình 5. Bảng 1: Thông lượng cho mỗi luồng tại các liên kết khác nhau. Bảng 1 liệt kê các thông lượng của mỗi luồng tại các liên kết khác nhau trong mạng. Chúng ta thấy rằng sau khi cạnh tranh với 25 dòng TCP trong lần tiên tắc nghẽn đầu 13 tiên ở R2-R3, luồng UDP mất khoảng 63% lưu lượng của nó khi nó gửi dữ liệu ở mức 2 Mbps. Lưu lượng UDP đi qua các liên kết R3-R4 chiếm 74% tỷ lệ gói tin đến tại liên kết đó. Luồng bị mất thêm 55% tại liên kết này khi cạnh tranh với các 20 luồng TCP còn lại. So sánh kết quả này với các trường hợp liên kết đơn tắc nghẽn, chúng ta có thể thấy rằng tại mỗi liên kết tắc nghẽn xem như đó là liên kết đơn tắc nghẽn. Do đó trong liên kết đa tắc nghẽn có tác dụng nhân tỉ lệ tổn thất gói UDP lên. Luồng TCP có thể tự động phát hiện các liên kết tắc ngẽn nên nó chịu mất ít gói tin hơn. Từ kết quả mô phỏng trong Bảng 1 và các thảo luận nói trên, ta suy luận rằng khi luồng hồi đáp TCP thông báo có sự tắc ngẽn và điều chỉnh ánh xạ tỉ lệ gói cho phù hợp, thì tỷ lệ mất gói của nó trong mạng sử thuật toán CHOKe là khá nhỏ. Còn luồng không tương thích như UDP thì bị tổn thất mất gói tin nặng. 3. Đa luồng không tương thích Bây giờ chúng ta tìm hiểu tác động của các thuật toán CHOKe trong trường hợp tổng quát, có nhiều hơn một ứng cử viên rơi được rút ra từ bộ đệm. Hình 8 cho thấy việc thực hiện của thuật toán CHOKe với một, hai và ba ứng cử viên thả. Cấu hình mạng để mô phỏng giống như hình 2 với tham số luồng UDP khác nhau. Tỷ lệ đối với nguồn UDP là 2 Mbps. CHOKe với m - 1 ứng cử viên thả là tối đa trong m gói(m – 1 gói ứng viên còn 1 gói đến), nó sẽ gọi CHOKe với m gói thả. (Theo thuật ngữ này chương trình CHOKe cơ bản sẽ được gọi là CHOKe 2 gói thả). 14 Hình 8: So sánh lưu lượng với CHOKe rơi nhiều gói. Hình 8 cho thấy thuật toán CHOKe với nhiều gói rơi có một kiểm soát lưu lượng UDP không hồi đáp tốt hơn so với các thuật toán cơ bản CHOKe, là điều không phải quá ngạc nhiên. Khi có nhiều luồng UDP trong mạng, CHOKe với nhiều ứng viên thả lợi thế hơn các thuật toán cơ bản. Một mô phỏng với cấu hình 32 TCP và UDP 5 nguồn được thiết lập, sử dụng các cấu trúc liên kết mạng cơ bản thể hiện trong hình 2. Tất cả các nguồn UDP đều có cùng tỷ lệ đến. Các ngưỡng min th và ngưỡng maxth vẫn được thiết lập là 30 và 60. Kết quả mô phỏng cho các thuật toán CHOKe cơ bản được đưa ra trong hình 9. Như thể hiện trong hình, thông lượng của nguồn UDP tỉ lệ thuận với tỷ lệ gói tin đến của nó. Kết quả là, hầu như không có băng thông để lại cho các nguồn TCP. Hình 9: Thông lượng với 32 TCP và 5 UDP nguồn với CHOKe Mặc dù tổng luồng UDP chiếm gần như tất cả các không gian bộ đệm, mỗi kết nối UDP chỉ mất khoảng 20% của hàng đợi. Kết quả là, cơ hội chọn gói ứng viên của luồng UDP không thể điều chỉnh như mong muốn. Mặt khác, CHOKe với 5 gói thả làm tăng thông lượng của các luồng TCP trong tình trạng này, như thể hiện trong hình 9. Bởi vì nhiều ứng cử viên giảm được lựa chọn từ hàng đợi, cơ hội bắt luồng xấu tăng lên. Vì vậy, CHOKe với nhiều gói thả có thể trừng phạt những dòng khó 15 phát hiện nhưng sử dụng nhiều hơn chia sẻ công bằng băng thông cho các luồng trên mạng. Các mô phỏng trên cho thấy sự cần thiết cho nhiều gói rơi khi có nhiều luồng không hồi đáp. Vì kích thước hàng đợi trung bình là một dấu hiệu tốt cho thấy mức độ của tắc nghẽn, sử dụng nó để tự động quyết định số lượng gói rơi thích hợp. Chương trình hoạt động như sau: mức giữa min th và maxth được chia thành mức bé hơn và số lượng gói rơi trong một mức bé được thiết lập là 2*i (i = 1 ... k). Kết quả mô phỏng, trên hình 10, cho thấy rõ ràng rằng cơ chế này tự điều chỉnh hoạt động tốt trong trường hợp của nhiều luồng không hồi đáp. Hình 10: CHOKe tự điều chỉnh thông lượng cho 32 TCP và 5 UDP IV. MÔ HÌNH VÀ PHÂN TÍCH THUẬT TOÁN Phần này phát triển một số mô hình toán học để phân tích thuật toán CHOKe. CHOKe được chi làm làm 3 phiên bản như sau: CHOKe nguyên thủy: Ở thuật toán này gói ứng cử viên thả được chọn ngẫu nhiên từ hàng đợi. Front CHOKe, Ở đây các ứng cử viên thả luôn luôn là các gói tin ở đầu hàng đợi. Back CHOKe, Ở đây các ứng cử viên thả luôn luôn là các gói tin ở đuôi hàng đợi. 16 Chúng ta sẽ tìm hiểu hai biến thể CHOKe vì những khó khăn trong việc phân tích CHOKe nguyên thủy. Đối với cả hai mặt trước và sau Choke mô hình đơn giản được trình bày, phân tích, và gần đúng với chương trình thực tế. 1. Front CHOKe Xem xét một danh sách với N Poisson đến độc lập, có tỷ lệ là λ i, và thời gian thực thi độc lập theo cấp số nhân. Sử dụng kỷ thuật FIFO và thời gian phục vụ trung bình của mỗi gói tin được giả định là 1/µ. Để tiện cho việc trình bày, đầu tiên chúng ta hãy xem xét chỉ có hai quá trình đến với tỉ lệ là λ 1, λ2. Chúng ta sẽ đề cập đến các gói tin của các luồng tương ứng loại 1 và loại 2. Một gói tin đến, hoặc là được nạp vào hàng đợi hoặc bị cho rơi tùy thuộc vào kết quả của sự so sánh. Mỗi gói tin đến được so sánh với các gói dữ liệu ở phần đầu của hàng đợi (nếu hàng đợi không rỗng). Nếu kiểu của cả hai gói là như nhau, thì cả hai đều bị cho rơi, nếu khác loại các gói tin đến được nạp vào hàng đợi. Nếu một gói tin đến ở một hàng đợi rỗng thì gói tin đến sẽ được thêm vào hàng đợi. Chúng ta giả sử có một phòng chờ vô tận và việc cho rơi gói tin chỉ có thể là đầu hàng hoặc là gói tin đến. Bây giờ ta giả sử rằng λ1 + λ2 2, tất cả các đối số PASTA sẽ thỏa mãn và một kết quả: pi = λi µ + 2λi (1) từ đó sự đi vào tốt của luồng i được xem là µp i. Cho N> 2 không tự đảm bảo sự ổn định và một đòi hỏi tỉ lệ đến λi thỏa mãn N N λi ∑ p = ∑ µ + 2λ i =1 i i =1 [...]... đáp Hình 10: CHOKe tự điều chỉnh thông lượng cho 32 TCP và 5 UDP IV MÔ HÌNH VÀ PHÂN TÍCH THUẬT TOÁN Phần này phát triển một số mô hình toán học để phân tích thuật toán CHOKe CHOKe được chi làm làm 3 phiên bản như sau: CHOKe nguyên thủy: Ở thuật toán này gói ứng cử viên thả được chọn ngẫu nhiên từ hàng đợi Front CHOKe, Ở đây các ứng cử viên thả luôn luôn là các gói tin ở đầu hàng đợi Back CHOKe, Ở đây... là 2 Mbps CHOKe với m - 1 ứng cử viên thả là tối đa trong m gói(m – 1 gói ứng viên còn 1 gói đến), nó sẽ gọi CHOKe với m gói thả (Theo thuật ngữ này chương trình CHOKe cơ bản sẽ được gọi là CHOKe 2 gói thả) 14 Hình 8: So sánh lưu lượng với CHOKe rơi nhiều gói Hình 8 cho thấy thuật toán CHOKe với nhiều gói rơi có một kiểm soát lưu lượng UDP không hồi đáp tốt hơn so với các thuật toán cơ bản CHOKe, là... hợp, thì tỷ lệ mất gói của nó trong mạng sử thuật toán CHOKe là khá nhỏ Còn luồng không tương thích như UDP thì bị tổn thất mất gói tin nặng 3 Đa luồng không tương thích Bây giờ chúng ta tìm hiểu tác động của các thuật toán CHOKe trong trường hợp tổng quát, có nhiều hơn một ứng cử viên rơi được rút ra từ bộ đệm Hình 8 cho thấy việc thực hiện của thuật toán CHOKe với một, hai và ba ứng cử viên thả Cấu... ta hiểu về thuật toán CHOKe thực hiện việc phân phối băng thông xấp xỉ cân bằng dựa trên mô hình và kết quả mô phỏng Và dựa trên mô phỏng cho thấy thuật toán CHOKe thực hiện tốt công việc điều khiển tắc ngẽn và giải quyết luồng không phản hồi Để triển khai trên thực tế cần phải xem xét tìm hiểu về vấn đề phần cứng 25 TÀI LIỆU THAM KHẢO 1 Understanding CHOKe: Throughput and Spatial Characteristics 2 CHOKe, ... đuôi hàng đợi 16 Chúng ta sẽ tìm hiểu hai biến thể CHOKe vì những khó khăn trong việc phân tích CHOKe nguyên thủy Đối với cả hai mặt trước và sau Choke mô hình đơn giản được trình bày, phân tích, và gần đúng với chương trình thực tế 1 Front CHOKe Xem xét một danh sách với N Poisson đến độc lập, có tỷ lệ là λ i, và thời gian thực thi độc lập theo cấp số nhân Sử dụng kỷ thuật FIFO và thời gian phục vụ... Khi có nhiều luồng UDP trong mạng, CHOKe với nhiều ứng viên thả lợi thế hơn các thuật toán cơ bản Một mô phỏng với cấu hình 32 TCP và UDP 5 nguồn được thiết lập, sử dụng các cấu trúc liên kết mạng cơ bản thể hiện trong hình 2 Tất cả các nguồn UDP đều có cùng tỷ lệ đến Các ngưỡng min th và ngưỡng maxth vẫn được thiết lập là 30 và 60 Kết quả mô phỏng cho các thuật toán CHOKe cơ bản được đưa ra trong hình... phỏng hàng đợi còn cột kết quả lý thuyết cho biết thông lượng thu được từ các công thức ở trên Bảng 2: Kết quả Mô phỏng Front CHOKe so với mô hình 2 Back CHOKe Back CHOKe đề cập đến tình huống mà các gói ứng cử viên thả luôn luôn lựa chọn từ phía sau của hàng đợi Theo thuật toán, các gói dữ liệu mới nạp gần đây và một gói tin đến sẽ được thả nếu chúng cùng một luồng (có chung ID) Một lần nữa nếu máy... xuống dưới tải nặng và lý do tại sao kích thước hàng đợi trung bình của luồng UDP không trở thành phần chiếm ưu thế của việc sử dụng hàng đợi Chúng ta sẽ tìm hiểu chi tiết trong phần tiếp theo 2 Đa tắc ngẽn Ở phần này chúng ta sẽ tìm hiểu sự thực hiện của CHOKe trên nhiều vị trí tắc ngẽn trên mạng như hình 7 12 Hình 7: Cấu trúc đa liên kết Liên kết đầu tiên giữa bộ định tuyến R1 và R2 (R1-R2) có công suất... = ∑ j =1 π ij Điều N λi π i < µ ∑ i kiện cho sự ổn định của hàng đợi là: =1 Bảng 3: Kết quả Back CHOKe với Ti là thông lượng của luồng i và bằng π i Bảng 3 là một số kết quả của Back CHOKe Để ổn định ta thiết lập µ =30 lớn hơn nhiều so với tổng tỉ lệ đến So sánh dòng 1 và 2 ta thấy sự cải tiến Back CHOKe, ngay cả khi bộ nhớ nhỏ thì vẫn nạp được hết gói tin Nạp tất cả các gói tương đương với không... của nó là tăng hơn gấp đôi 24 Các quan sát thú vị nhất với sự Back CHOKe đã thực hiện với bộ nhớ M Rõ ràng từ ba hàng đầu tiên của bảng 3 mà như tăng bộ nhớ, chương trình này trở nên công bằng hơn kể từ khi thông lượng của mỗi dòng tiếp cận chia sẻ công bằng của nó Trong trường hợp đặc biệt N - M = 1 chương trình hoạt động như một thuật toán robin tròn, kết quả là công bằng hoàn hảo giữa các dòng Số lượng ... hai loại thuật toán định tuyến để điều khiển tắc nghẽn sử dụng rộng rải lớp "thuật toán lập lịch trình" lớp "thuật toán quản lý hàng đợi" Lớp thuật toán lập lịch trình, mà tiếng thuật toán FQ,... tương thích II THUẬT TOÁN CHOKE Nhu cầu thuật toán không trạng thái mà đạt việc cô lập hoạt động luồng và/hoặc phân bổ băng thông xấp xỉ công Mà thuật toán có (như RED, FQ thuật toán khác) giải... Hình 10: CHOKe tự điều chỉnh thông lượng cho 32 TCP UDP IV MÔ HÌNH VÀ PHÂN TÍCH THUẬT TOÁN Phần phát triển số mô hình toán học để phân tích thuật toán CHOKe CHOKe chi làm làm phiên sau: CHOKe nguyên