1. Trang chủ
  2. » Luận Văn - Báo Cáo

Phân tích đánh giá một số thuật toán quản lý hàng đợi tích cực trong TCP Network

85 570 2

Đang tải... (xem toàn văn)

Tài liệu hạn chế xem trước, để xem đầy đủ mời bạn chọn Tải xuống

THÔNG TIN TÀI LIỆU

Thông tin cơ bản

Định dạng
Số trang 85
Dung lượng 3,69 MB

Các công cụ chuyển đổi và chỉnh sửa cho tài liệu này

Nội dung

Nếu một host truyền tại tốc độ cao hơn và mạng bị nghẽn thì số lượng các gói bị mất sẽ tăng RFC2309 chỉ ra rằng thà chấp nhận các luồng dạng bó đến làm tràn hàng đợi còn hơn là cố gắng d

Trang 1

TRƯỜNG ĐẠI HỌC KỸ THUẬT CÔNG NGHIỆP

-

LUẬN VĂN THẠC SĨ KỸ THUẬT

NGÀNH:

PHÂN TÍCH ĐÁNH GIÁ MỘT SỐ THUẬT TOÁN QUẢN LÝ HÀNG ĐỢI

TÍCH CỰC TRONG TCP NETWORK

TN

2012 THÁI NGUYÊN 2012

Trang 2

ĐẠI HỌC THÁI NGUYÊN TRƯỜNG ĐẠI HỌC KỸ THUẬT CÔNG NGHIỆP

-

LUẬN VĂN THẠC SĨ KỸ THUẬT

PHÂN TÍCH ĐÁNH GIÁ MỘT SỐ THUẬT TOÁN

QUẢN LÝ HÀNG ĐỢI TÍCH CỰC TRONG TCP NETWORK

Trang 3

CHƯƠNG 1 TỔNG QUAN CÁC THUẬT TOÁN VỀ QUẢN LÝ HÀNG ĐỢI 1.1 Truyền dữ liệu trên một hệ thống mạng

Trong các hệ thống truyền số liệu, thông tin muốn gửi đi được chia thành các đơn vị dữ liệu nhỏ gọi là gói tin (packet) Ngoài việc gửi đi các gói tin, phía phát đồng thời đóng gói những thông tin điều khiển việc vận chuyển gói tin và đặt nó ở đầu của mỗi gói tin (packet header) Trong một

địa chỉ nguồn để chỉ rõ địa chỉ nơi gửi gói tin đó Packet header cũng chứa địa chỉ IP đích (distination IP address) là nơi gói tin phải chuyển đến Các bộ định tuyến sẽ dùng địa chỉ đích này để xác định đích đến của gói tin Và thực hiện việc chuyển gói tin đến đúng địa chỉ

Đa số các trường hợp, thiết bị phát và thiết bị thu không được nối trực tiếp với nhau mà chúng phải thông qua các bộ định tuyến trung gian Trong những trường hợp này, thiết bị gửi sẽ gửi các gói tin tới bộ định tuyến mà nó được nối trực tiếp

Bộ định tuyến này sẽ sử dụng địa chỉ đích (địa chỉ nơi nhận) của gói tin như một chìa khóa để tìm kiếm dữ liệu thông tin về lộ trình và đưa ra quyết định chuyển tiếp các gói tin Nếu bộ định tuyến này và thiết bị thu được kết nối trực tiếp với nhau thì

Trang 4

1.1: Kiến trúc mạng đơn giản

nó sẽ chuyển các gói tin đến thẳng thiết bị thu Nếu không phải nối trực tiếp, bộ định tuyến này sẽ chuyển gói tin đến một bộ định tuyến khác mà nó biết được qua quá trình phân tích thông tin theo lộ trình ở trên Quá trình như vậy được lặp lại cho đến khi gói tin được chuyển đến một bộ định tuyến được kết nối trực tiếp với thiết

bị thu và được chuyển đến đích cuối cùng

Trong một hệ thống mạng, một bộ định tuyến (router) thường có nhiều giao diện mạng gắn với những mối liên kết khác nhau như trong hình 1.2 Những liên kết này dùng để kết nối với các bộ định tuyến khác hay kết nối với các mạng con (subnetwork) Một router sau khi nhận được một gói tin sẽ sử dụng địa chỉ nơi nhận

và dữ liệu thông tin lộ trình của gói tin để xác định liên kết đầu ra cho gói tin đó Khi có nhiều gói tin từ nhiều nguồn khác nhau cùng đến router với một lộ trình đầu

ra giống nhau thì chỉ có duy nhất một gói tin được đáp ứng còn các gói tin còn lại bị đẩy vào một hàng đợi tại mối liên kết đầu ra mà chúng yêu cầu Khi nhịp độ đến router của các gói tin như vậy tăng lên, chúng sẽ tiếp tục được đưa vào hàng đợi đó Thông thường, hàng đợi này sẽ được duy trì với cơ chế FIFO (first in first out) Với cơ chế này thì những gói tin đến sau sẽ được xếp vào cuối hàng đợi Nếu mức

độ chuyển các gói tin đi của router lớn hơn mức độ các gói tin khác đến router thì sau một khoảng thời gian nào đó hàng đợi sẽ trở nên rỗng Ngược lại, nếu mức độ chuyển các

gói tin đi nhỏ hơn mức độ các gói tin khác đến router thì sau một khoảng thời gian hàng đợi sẽ đầy Khi đó, router sẽ phải loại bỏ các gói tin theo một cơ chế nào đó, nếu không hiện tượng tắc nghẽn sẽ xảy ra [1]

Trang 5

Hình 1.2: Kiến trúc cơ bản của một router

1.2 Điều khiển tắc nghẽn

1.2.1 Khái niệm

Trong quá trình hoạt động, mạng có thể rơi vào trạng thái không đủ khả năng đáp ứng các chỉ tiêu chất lượng cho các kết nối đã được thiết lập hay cho một yêu cầu kết nối mới do sự biến đổi bất thường, không dự đoán được của dòng lưu lượng cùng với tình trạng lỗi của các phần tử mạng (các chuyển mạch, đường truyền, …) Trạng thái này được gọi là tắc nghẽn

Các gói tin đi vào và đi ra các bộ đệm, hàng đợi thường dưới dạng bó từ một hoặc nhiều nguồn khác nhau Các bộ đệm sẽ giúp các router lưu trữ các bó cho đến khi chúng được chuyển đi Khi các bó gói tin đến vượt qua kích thước bộ đệm thì các gói đến sau sẽ bị loại bỏ Để khắc phục điều này, việc tăng bộ đệm không phải

là giải pháp tốt vì khi kích thước bộ đệm quá lớn thì sẽ tạo ra trễ lớn Tắc nghẽn xảy

ra khi lưu lượng từ nhiều tuyến đổ dồn về một tuyến và tuyến này không có khả năng xử lý hết được Tắc nghẽn cũng xảy ra ngay bên trong bản thân router tại mạng lõi của mạng khi các node nhận được nhiều lưu lượng hơn so với thiết kế của

Khi mạng xảy ra tắc nghẽn nếu không được xử lý kịp thời sẽ gây ra các hậu quả nghiêm trọng: các gói tin không được xử lý, không chuyển được đến đầu cuối người nhận và gây ùn tắc trong mạng, mạng không hoạt động được trong thời gian dài sẽ không thể truyền tải được giữ liệu, các thành phần có thể bị hư hỏng Do đó vấn đề quan trọng là phải điều khiển được tắc nghẽn trong mạng Đó có thể là hành động điều khiển để phòng tránh tắc nghẽn và cũng có thể là điền khiển tắc nghẽn khi nó

đã xảy ra

1.2.2 Các kỹ thuật được sử dụng trong quản lý tắc nghẽn

- Điều khiển luồng phía đầu cuối: đây không phải lược đồ điều khiển tắc nghẽn nhưng cũng là cách để tránh trường hợp phía phát gửi quá nhiều lưu lượng vượt qua

cả không gian bộ đệm chia thu

Trang 6

- Điều khiển tắc nghẽn mạng: trong lược đồ này, các hệ thống đầu cuối giảm tốc

độ của luồng lưu lượng để tránh tắc nghẽn trong mạng, cơ chế này tương tự như điều khiển luồng đầu cuối, nhưng mục đích chính là để giảm tắc nghẽn trong mạng chứ không phải phía thu

- Tránh tắc nghẽn trên cơ sở mạng: trong lược đồ này, router sẽ cố gắng dò tìm

ra tắc nghẽn khi nó có khả năng xảy ra, và cố gắng giảm tốc độ của luồng đầu vào trước khi hàng đợi đầy

- Phân phối tài nguyên: kỹ thuật bao gồm tiến trình lập lịch có sử dụng các mạch vật lý hoặc các luồng tài nguyên khác Một mạch ảo được xây dựng qua nhiều chuyển mạch cùng với băng thông đảm bảo cũng là một loại phân phối tài nguyên

Kỹ thuật này rất khó nhưng nó có khả năng loại trừ tắc nghẽn trong mạch bằng việc khóa các lưu lượng vượt quá khả năng của mạng

Giải pháp quan trọng nhất trong điều khiển tắc nghẽn đó là sử dụng kỹ thuật quản lý hàng đợi Các bộ đệm trong các thiết bị mạng được quản lý bởi rất nhiều kỹ thuật hàng đợi Nói đúng ra quản lý hàng đợi có thể tối thiểu hóa việc mất gói trong mạng và tắc nghẽn xảy ra cũng như cải thiện được hiệu năng của mạng

Kỹ thuật hàng đợi cơ bản nhất là FIFO, các gói được xử lý theo trật tự mà chúng đến hàng đợi, còn hàng đợi ưu tiên sử dụng cấu trúc đa hàng đợi với các mức ưu tiên khác nhau sẽ ưu tiên xử lý các gói quan trọng nhất và truền tới các node kế tiếp Một kỹ thuật hàng đợi quan trọng nữa là tự ấn định các luồng cho chính bản thân các hàng đợi Với các luồng khác nhau thì độ ưu tiên cũng được khác nhau, và mỗi luồng đều được xử lý để chắc chắn rằng chúng không làm tràn hàng đợi Việc tách rời các hàng đợi theo các này đảm bảo rằng các hàng đợi sẽ chỉ chứa các gói từ một nguồn đơn lẻ

1.2.3 Điều khiển tắc nghẽn và tránh tắc nghẽn trong mạng TCP

Trong những năm 1980 Internet dễ xảy ra hiện tượng “sụp đổ tắc nghẽn”, do có quá ít chức năng điều khiển quản lý mạng Các kết nối đơn lẻ sử dụng điều khiểu luồng giữa những người gửi và người nhận để tránh phía gửi làm tràn lưu lượng tại phía nhận

Trang 7

Nhưng việc điều khiển luồng trong thời điểm đó mới chỉ tránh tràn lụt lưu lượng tại các bộ đệm phía thu chứ chưa giải quyết được tại các bộ đệm phía trong các node mạng Tuy nhiêu lưu lượng sử dụng trên mạng Intrernet ngày đó chưa lớn và

nó bao gồm một số lượng các kết nối tốc độ chậm do đó vấn đề tắc nghẽn không quan trọng như ngày nay

Sau những năm 1980 Van Jacopson đã phát triển các cơ chế điều khiển tắc nghẽn, tạo ra các đáp ứng TCP để hạn chế tắc nghẽn trong mạng Nền tảng cơ bản

là loại bỏ các gói sẽ làm cho các host ngừng lại hoặc chậm dần

Thông thường khi một host nhận một gói hoặc một tập các gói thì nó sẽ gửi một ACK (acknowlegement) cho phía phát để thông báo là đã nhận được gói tin Cơ chế cửa sổ cho phép host nhận đa gói tin mà chỉ dùng một ACK Việc phía gửi không nhận được ACK chứng tỏ rằng phía thu bị tràn bộ đệm hoặc mạng bị nghẽn do đó phía phát phải dừng việc chuyển gói hoặc giảm tốc độ

Một chiến lược được đưa ra là “Giảm theo cấp số nhân, tăng theo cấp số cộng”

để điều chỉnh số lượng các gói đến trong cùng một thời điểm Nếu vẽ lược đồ về luồng dữ liệu ta sẽ thấy số lượng các gói tăng lên cho đến khi có tắc nghẽn xuất hiện trong mạng (tăng theo cấp số cộng) và khi gói bắt đầu bị loại bỏ thì ta giảm nhanh các gói truyền cho đến khi việc truyền gói bắt đầu dừng (giảm theo cấp số nhân) Kích thước cửa sổ sẽ lần lượt giảm một nửa khi có tắc nghẽn xảy ra Các host sẽ tìm ra tốc độ truyền dẫn tối ưu bằng việc thường xuyên kiểm tra mạng với tốc độ cao hơn Thỉnh thoảng tốc độ truyền cao hơn này được chấp nhận nhưng khi mạng bận thì các gói bắt đầu bị loại bỏ và host lại quay trở lại tốc độ ban đầu Lược

đồ này coi mạng như một hộp đen loại bỏ các gói khi có tắc nghẽn Do đó điều khiển tắc nghẽn được thực hiện bới các hệ thống đầu cuố

gói là để chỉ thị tắc nghẽn Phía người gửi sẽ truyền một số lượng lớn các file để đẩy lên tốc độ cao hơn cho tới khi nó đạt được tất cả băng thông Các host khác có thể gặp vài vấn đề khi chuyển gói qua mạng Các host bị túm lấy băng thông thì chỉ truyền tải được rất ít lưu lượng quan trọng

Trang 8

Tất nhiên, mạng có thể sử dụng vai trò tích cực trong điều khiển tắc nghẽn Cơ chế điều khiển và tránh tắc nghẽn có thể chia ra thành các quá trình:

- Khôi phục tắc nghẽn: hoàn trả lại trạng thái hoạt động của mạng khi yêu cầu vượt quá khả năng

- Đoán trước được tắc nghẽn xảy ra và có thể phòng tránh được không cho tắc nghẽn có thể xảy ra

Ngày nay tránh tắc nghẽn là công cụ cải thiện hiệu năng và QoS trong mạng Internet Chuẩn RFC 2309 (giới thiệu quản lý hàng đợi và tránh tắc nghẽn trong Internet) đưa ra cơ chế tránh tắc nghẽn dựa trên cơ cấu router Cơ chế này chia ra thành các thuật toán quản lý hàng đợi và thuật toán lập lịch

Mục đích quan trọng là tối thiểu số lượng các gói bị loại bỏ Nếu một host truyền tại tốc độ cao hơn và mạng bị nghẽn thì số lượng các gói bị mất sẽ tăng RFC2309 chỉ ra rằng thà chấp nhận các luồng dạng bó đến làm tràn hàng đợi còn hơn là cố gắng duy trì trạng thái không đầy của hàng đợi

TCP có xử lý điều khiển tắc nghẽn, UDP được điển hình sử dụng cho các luồng video và audio thời gian thực bởi vì nó không cần khôi phục lại các gói bị mất UDP là giao thức truyền tải không đảm bỏa do nó không truyền lại các báo hiệu ngược trở lại nguồn Các luồng UDP không thể được điều khiển bởi các điều khiển tắc nghẽn như trong TCP truyền thông

Trong chuẩn RFC 2581 giới thiệu 4 thuật toán cho điều khiển tắc nghẽn: Khởi đầu chậm, truyền lại nhanh, khôi phục nhanh, tránh tắc nghẽn

Điều khiển tắc nghẽn khởi đầu chậm:

Khởi đầu chậm làm giảm ảnh hưởng của bó khi một host đầu tiên được truyền

Nó yêu cầu một host khởi đầu việc truyền dẫn của nó chậm hơn, sau đó nó sẽ xử lý các điểm có tắc nghẽn xảy ra Một host lúc đầu không biết có bao nhiêu gói được gửi do đó nó sẽ sử dụng cách khởi đầu chậm để định giá dung lượng của mạng Một host bắt đầu việc truyền dẫn bằng cách gửi hai gói tin tới phía thu Khi phía thu nhận được các segment thì nó sẽ gửi phản hồi lại phía nhận một ACK để xác nhận Phía phát sẽ tăng số gói gửi theo cơ số hai, tức là sẽ gửi 4 gói Việc chỉ thị này tiếp

Trang 9

tục tại phía phát cho đến khi không nhận được phản hồi ACK Việc chỉ thị này cho thấy khả năng xử lý lưu lượng của mạng hoặc khả năng xử lý lưu lượng tới của phía thu

Khởi đầu chậm không có khả năng ngăn chặn tắc nghẽn mà nó chỉ giúp cho các host tránh được trạng thái tắc nghẽn tạm thời Nếu một host gửi quá nhiều gói thì nó

sẽ gây ra nghẽn mạng, tràn bộ đệm và các gói sẽ bị loại bỏ Nhưng trong một số ứng dụng mới như: thoại qua IP thì không thể chấp nhận được trễ gây ra bởi việc khởi đầu chậm, do đố trong một số trường hợp thì mạng sẽ không sử dụng kiểu này:

- Khôi phục và truyền lại nhanh:

Truyền lại và khôi phục lại nhanh là các thuật toán được thiết kế để tối thiểu hóa việc loại bỏ gói khi truyền trong mạng Cơ cế truyền lại nhanh suy luận từ cơ chế truyền TCP Phía thu sẽ gửi các báo hiệu tới phía gửi rằng nó nhận được các gói không theo trật tự Kỹ thuật này sẽ phải gửi rất nhiều bảo sao ACK tới phía phát Đây là cách để chỉ thị cá gọi bị mất Thay cho việc chờ đợi phản hồi ACK cho đến khi hết thời gian thì nguồn gửi sẽ tự phát lại gói khi nhận được 3 bản sao ACK Việc này xảy ra trước khi thời gian hết hạn do đó chúng cải thiện được khả năng thông qua của mạng Ví dụ khi một host nhận được gói thứ 5 và 7 (mà không nhận được gói thứ 6) thì nó sẽ gửi phản hồi ACK cho gói thứ 5 khi nó nhận được gói thứ

7

Khôi phục nhanh là cơ chế thay thế cho kiểu khởi đầu chậm khi truyền lại nhanh được sử dụng Các ACK vẫn tiếp tục được truyền để chỉ thị có bị mất gói hay không cho tới khi phía nguồn nhận được ACK có số thứ tự cao hơn gói bị mất Trong trường hợp đó có nghĩa là có một gói đơn bị mất và mạng không bị nghẽn hoàn toàn Do đó phía phát không cần thiết phải quay trở lại khởi động chậm ngay lập tức

mà chỉ cần giảm tốc độ truyền xuống bằng một nửa so với tốc độ ban đầu

Tránh tắc nghẽn bằng cách sử dụng quản lý hàng đợi tích cực:

Việc loại bỏ gói là hoàn toàn không hiệu quả Nếu một host bị ngập tràn và tức nghẽn xảy ra thì sẽ có rất nhiều gọi bị mất Do đó việc loại bỏ tắc nghẽn sắp xảy đến và quản lý tắc nghẽn tích cực là điều rất cần thiết Để thực hiện điều này ta sử

Trang 10

dụng quản lý hàng đợi tích cực và lập lịch Quản lý hàng đợi là một kỹ thuật mà các router loại bỏ gói một cách tích cực từ ngay trong hàng đợi để tránh tràn hàng đợi,và giảm tốc độ

1.3 Các kĩ thuật hàng đợi trong Router

1.3.1 Giới thiệu hàng đợi trong Router

Lý thuyết hàng đợi nảy sinh một cách tự nhiên trong việc nghiên cứu các chuyển mạch kênh, và chuyển mạch gói Trong các mạng chuyển mạch kênh, cuộc gọi đến chuyển mạch ngẫu nhiên, mỗi cuộc gọi sẽ giữ kênh trong một khoảng thời gian ngẫu nhiên nào đó Trong mạng chuyển mạch gói, các gói tin với các chiều dài khác nhau đi qua mạng, tài nguyên mạng (các chuyển mạch, kết nối sẽ được chia sẻ cho các gói) Các bản tin được định tuyến đến các node tiếp theo Thời gian sử dụng bộ đệm (trễ hàng đợi) là một vấn đề quan trọng trong truyền dẫn thông tin Thời gian này phụ thuộc vào các thời gian xử lý, độ dài bản tin hay thời gian chờ xử lý khi chưa có tài nguyên sử dụng

Trong các ứng dụng tương tác và thời gian thực thì thời gian trả lời trung bình được xem như một tiêu chuẩn quan trọng còn trong các ứng dụng khác thì thông lượng lại là điều quan trọng nhất Việc mô tả hàng đợi theo lý thuyết toán học rất phức tạp nên ta chỉ mô tả chúng them mô hình đơn giản để sử dụng trong các mạng

IP

Hình 1.3 Mô hình hàng đợi đơn giản trong mạng

Trang 11

Tin tức (có thể là gói tin hay bản tin) đến hệ thống để yêu cầu phục vụ Nếu server rỗi thì gói tin sẽ được phục vụ ngay lập tức, ngược lại chúng sẽ được lưu giữ trong các hàng đợi Khi rời khỏi hàng đợi các gói sẽ được xử lý

Các tham số cơ bản liên quan tới hàng đợi:

Bảng 1.1: Bảng các tham số cơ bản của hàng đợi

vận tốc trên một đơn vị thời gian (s)

độ µ trên một đơn vị thời gian Hiệu suất sử dụng dịch

Là khoảng thời gian server bận do phải

xử lý, đo bằng P= /µ

bình tại tất cả các thời điểm t

Có hai định nghĩa:

Thứ nhất: được tính bằng tất cả thời gian gói tin đến xử lý (bao gồm cả các gói không phải chờ trong hàng đợi)

Thứ hai: chỉ tính TB thời gian các gói tin phải chờ trong hàng đợi

tới server và thời điểm rời khỏi server

Số gói trung bình trong hệ thống, bao gồm các gói đang được sử dụng và các gói đang chờ trong hàng đợi

Trang 12

Các gói đến hàng đợi với tốc độ thay đổi và đây là một quá trình poisson, thời gian phục vụ có phân bổ mũ tốc độ µ (thực chất là thời gian trung bình mà các gói tin rời khỏi hàng đợi) Khi các gói đến hệ thống tăng thì hiệu suất sử dụng hệ thống cũng tăng, dẫn tới tắc nghẽn có khả năng xảy ra Với p = 1 thì các server bão hòa do

đó tốc lớn nhất theo lý thuyết mà hệ thống có thể xử lý được là:

max=1/Ts Tại max thìkích thước hàng đợi rất dài không thể kiểm soát được Trong thực tế thời gian trả lời và những yêu cầu kích thước hàng đợi giới hạn tốc độ đầu vào của thông tin là 70 – 90% so với max theo lý thuyết

Tại các router và chuyển mạch trong phần lõi của kiến trúc các dịch vụ phân biệt của mạng Internet có các thuật toán lập lịch và quản lý hàng đợi Ngày nay, kiến trúc dịch vụ phân biệt bao gồm hàng đợi cân bằng có trọng số (WFQ) cùng kĩ thuật tách sớm có trọng số (WRED) được ứng dụng rộng rãi Các kĩ thuật trên được sử dụng trong mạng Internet làm nhiệm vụ điều khiển tắc nghẽn và điều khiển luồng lưu lượng trong mạng Điền khiển tắc nghẽn là vấn đề quan trọng cần giải quyết trong việc truyền tin trong mạng Nó sử dụng hai cơ chế độc lập:

- Cơ chế điều khiển vòng kín (Closed Loop Control): điều khiển việc truyền các gói từ các nguồn đầu cuối tới đích

- Các thuật toán lập tích vòng hở (Opened Loop Control): ràng buộc độ ưu tiên được cấu hình từ trước và phân phối băng thông cho các kết nối

Hệ thống điều khiển vòng kín bao gồm các thuật toán nguồn được điều khiển bởi các thuật toán kết nối Thuật toán nguồn này là bất kì giao thức nào được truyền tải trên mạng Internet (ví dụ: TCP, UDP, RTP) và chúng không nhất thiết phải có phản hồi đáp ứng với tắc nghẽn Các thuật toán điều khiển kết nối hay còn gọi là các thuật toán quản lý hàng đợi (hoặc quản lý hàng đợi tích cực AQM) Các thuật toán AQM bao gồm thuật toán loại bỏ đuôi, thuật toán phát hiện sớm ngẫu nhiên (RED) Thuật toán AQM thực hiện việc báo hiệu tới nguồn bằng việc đánh dấu các gói, thông báo tắc nghẽn tường minh (ECN) hay loại bỏ các gói

Trang 13

Các thuật toán lập tích vòng mờ quyết định xem gói nào sẽ được gửi kế tiếp Thuật toán này quyết định trật tự các gói truyền dẫn trên cơ sở trật tự sắp xếp các gói đến và các lớp lưu lượng ưu tiên trong gói

Dịch vụ phân biệt sử dụng 3 bit trong tiêu đề mỗi gói để định nghĩa lớp Quá trình lập lịch của gói điều khiển trật tự truyền dẫn giống như phân bố băng thông tương ứng cho mỗi lớp dịch vụ Lập lịch bao gồm các thuật toán liên quan tới hàng đợi: hàng đợi FIFO, hàng đợi cân bằng có trọng số WFQ, và các thuật toán lập lịch như: Thuật toán RR, thuật toán PS

Hình 1.4: Tiến trình xử lý hàng đợi trong router

Để hiểu rõ về các hàng đợi được sử dụng trong có chế điều khiển tắc nghẽn ta phải trả lời các câu hỏi:

- Các gói sẽ được sắp đặt như thế nào trong hàng đợi:

- Thứ tự hay cách thức nào mà các thiết bị mạng phục vụ các hàng đợi của chúng?

- Các hoạt động nào cảu mạng để đối xử với các bó lưu lượng và hàng đợi bị tràn?

Ở ví dụ mô tả trong hình 1.4, router được xem như hộp lớn, trong đó có các thành phần thực hiện việc truyền thông tin Trong ví dụ này ta xét router có 2 giao diện Gói tin đi từ mạng A tới mạng B Mạng A tiếp xúc với router qua giao diện IF0, mạng B tiếp xúc với router qua giao diện IF1 Sau khi các gói được đưa đến từ giao diện IF0 sẽ được đặt vào trong h đợi queue 0 (hàng đợi đầu vào) Tiếp theo

Trang 14

các gói đi vào trong router và được định hư ng tới router kế tiếp dựa trên địa chỉ đích lưu giữ trong một phần header của gói tin, một số gói tin đi từ hàng đợi queue

0 được đưa vào hàng đợi queue 1 kết nối với giao diện IF1 Hàng đợi queue 1 còn gọi là hàng đợi đầu ra

Có rất nhiều kĩ thuật hàng đợi: FIFO (fist in fist out), PQ (priority queue – hàng đợi ưu tiên), FQ (fair queue – hàng đợi cân bằng) FIFO là kĩ thuật xếp hàng vào trước ra trước cơ bản Các gói đến trước sẽ là các gói đầu tiên được xử lý Khi hàng đợi đầy và có tắc nghẽn xảy ra thì các gói đến sẽ bị loại bỏ Hàng đợi FIFO dựa vào

hệ thống đầu cuối để điều khiển tắc nghẽn thông qua cơ chế điều khiển tắc nghẽn

Do loại hàng đợi này rất đơn giản nhiều khi không điều khiển được tắc nghẽn nên ta thường xét các loại hàng đợi hiệu quả hơn: hàng đợi ưu tiên (PQ), hàng đợi cân bằng (FQ), hàng đợi có trọng số (WQ)

1.3.2 Quản lý hàng đợi (Queue management)

Thế nào là quản lý hàng đợi

Các router chính trong mạng Internet được cấu hình có nhiều hàng đợi với kích thước lớn, do đó các gói truyền trong mạng sẽ phải mất một thời gian dài để truyền trong hàng đợi Trễ hàng đợi thậm chí còn lâu hơn cả trễ truyền trong mạng Đối với các hàng đợi quá dài, khi xảy ra tắc nghẽn thì chính sách “loại bỏ phần đuôi” được sử dụng nhiều Điều này có nghĩa là bất kì gói nào đến trong điều kiện hàng đợi bị đầy đều bị loại bỏ trước khi vào được hàng đợi Vấn đề đặt ra là làm thế nào khi có tắc nghẽn xảy ra Để giải quyết vấn đề này ta sử dụng các thuật toán quản lý hàng đợi và lập lịch

Nói đơn giản thuật toán quản lý hàng đợi được sử dụng để quản lý chiều dài của hàng đợi các gọi bằng cách loại bỏ các gói khi cần thiết

Quản lý hàng đợi bao gồm các hoạt động:

- Thêm gói vào hàng đợi theo ngữ cảnh của gói khi hàng đợi chưa đầy

- Loại bỏ gói nếu hàng đợi đã đầy

- Xóa bỏ gói khi được yêu cầu bởi bộ lập lịch

- Thường xuyên quản lý độ chiếm giữ của hàng đợi

Trang 15

- Loại bỏ gói khi hàng đợi đã đầy

- Đánh dấu các gói khi hàng đợi chuẩn bị đầy

- Sự cần thiết của quản lý hàng đợi

Mục đích chính của hàng đợi là điều khiển lưu lượng, chống tắc nghẽn trong mạng, đặc biệt là tại các nút cổ chai Kỹ thuật quản lý hàng đợi trước đây là thiết lập một kích thước hàng đợi lớn nhất cho mỗi hàng đợi, các gói sẽ được đưa vào trong hàng đợi cho đến khi hàng đợi đầy sau đó nếu còn có gói đến thì sẽ loại bỏ các gói mới tới nay Khi số lượng các gói trong hàng đợi giảm do được truyền tới chặng tiếp theo thì lúc đó hàng đợi mới nhập tiếp các gói tới Đây cũng chính là kĩ thuật

“loại bỏ phần đuôi” (drop tail) Tuy nhiên cách này có 2 hạn chế:

- Kĩ thuật này chỉ cho phép các gói từ một kết nối đơn hoặc một vài luồng đủ để chiếm dụng không gian hàng đợi, ngăn chặn không cho các kết nối khác cùng đến một hàng đợi Kĩ thuật này là kết quả của quá trình đồng bộ hoặc có hiệu quả định thời

- Thường thì các luồng lưu lượng đến hàng đợi dưới dạng bó Khi hàng đợi đầy thì bất kì luồng nào đến cũng đều bị loại bỏ cho tới khi số gói trong hàng đợi giảm xuống Kĩ thuật này sẽ loại bỏ các bó thông tin chứ không phải chỉ là các gói, do đó việc mất mát thông tin là rất lớn

Quản lý hàng đợi có các tính năng sau:

- Giảm số lượng các gói bị loại bỏ trong hàng đợi

Các gói thường đến mạng dưới dạng bó và có chủng loại rất phong phú, tốc độ không cố định Nếu ta đặt kích thước hàng đợi cố định thì không linh hoạt với từng loại lưu lượng khác nhau: như nếu kích thước hàng đợi quá bé thì hàng đợi rất dễ bị tràn và việc loại bỏ gói sẽ thường xuyên xảy ra, còn nếu kích thước hàng đợi quá lớn sẽ gây lãng phí tài nguyên Quản lý hàng đợi giữ kích thước trung bình của hàng đợi nhỏ cung cấp khả năng cao hơn Ngoài ra quản lý hàng đợi cho phép loại bỏ tắc nghẽn bằng việc loại bỏ gói tin chứ không loại bỏ cả bó tin điều này sẽ hạn chế được số lượng các gói bị loại bỏ

- Cung cấp các dịch vụ tương tác có độ trễ thấp

Trang 16

Do quản lý hàng đợi giữ kích thước trung bình của hàng đợi nhỏ nên giảm độ rễ trong các luồng Điều này rất quan trọng trong các ứng dụng tương tác: truyền web, lưu lượng telnet hay các phiên audio-video tương tác

Trang 17

CHƯƠNG 2 CÁC PHƯƠNG PHÁP QUẢN LÝ HÀNG ĐỢI TÍCH CỰC

2.1 Tổng quan

2.1.1 Khái niệm quản lý hàng đợi tích cực AQM (Active Queue Managament)

Quản lý hàng đợi tích cực (AQM) là một cơ chế phát hiện sự tắc nghẽn trong hệ thống mạng Những giải thuật quản lý hàng đợi tích cực chạy bên trong nh ng bộ định tuyến và phát hiện sự hình thành tắc nghẽn điển hình bằng cách theo dõi chiều dài hàng đợi tức thời hay chiều dài hàng đợi trung bình Khi kích thước hàng đợi trung bình vượt quá một ngưỡng nhất định nhưng vẫn còn ít hơn khả năng xử lý của hàng đợi, những giải thuật quản lý hàng đợi tích cực xem xét sự tắc nghẽn trên mối liên kết và thông báo trở lại cho những hệ thống bằng cách thả một số gói tin chuyển đến bộ định tuyến Các giải thuật AQM có thể cũng đặt một bit vào header của một gói tin nào đó rồi chuyển nó về phía thiết bị nhận của gói đó sau khi sự tắc nghẽn được phát hiện Khi thiết bị thu nhận được gói tin đã được đánh dấu này, nó

sẽ gửi trở lại bên phát gói tin đó một bit khác trong phiên làm việc giữa nó và bên phát Khi bên phát nhận được tín hiệu này, nó sẽ giảm bớt tín hiệu truyền dữ liệu Quá trình đặt một bit đặc biệt trong header của gói tin bởi những giải thuật AQM và việc chuyển gói tin đã được đánh dấu đó đến bên nhận gọi là sự đánh dấu (mark) Gói tin chứa bit đặc biệt trong quá trình trên gọi là gói tin đánh dấu Những hệ thống trải qua việc bị đánh dấu hoặc bị mất mát gói tin sẽ giảm nhịp độ truyền dữ liệu để giải tỏa sự tắc nghẽn và ngăn việc tràn hàng đợi

Mục tiêu quan trọng nhất cảu các giải thuật AQM là ngăn ngừa sự tắc nghẽn trước khi nó thực sự xuất hiện Như vậy, việc sử dụng hiệu quả các giải thuật quản

lý hàng đợi sẽ đem lại những hiệu quả đó là: giảm bớt sự mất mát các gói tin, đạt được một lưu lượng truyền dữ liệu cao và một độ trễ hàng đợi thấp Điều này thật

sự là một cải thiện rất tốt cho những ứng dụng tương tác như duyệt Web hay các cuộc hội thoại trực tiếp

Một mục tiêu quan trọng khác của quản lý hàng đợi tích cực là quản lý tắc nghẽn với yêu cầu ngăn ngừa sự đồng bộ hóa toàn cục (global synchronization)

Trang 18

bằng sự ngẫu nhiên trong quyết định đánh dấu hay loại bỏ gói tin Khi một sự tắc nghẽn được nghi ngờ trên một mối liên kết nào đó, đa số những giải thuật quản lý hàng đợi không đánh dấu hay loại bỏ gói tin một cách tất định mà là ngẫu nhiên Xác suất đánh dấu hay loại bỏ của một gói tin được chuyển đến thông thường phụ thuộc vào độ ước tính của sự tắc nghẽn trên mối liên kết [1]

2.1.2 Sự cần thiết phải có quản lý hàng đợi tích cực

Kỹ thuật truyền thống để quản lý chiều hài hàng đợi là thiết lập một giá trị chiều dài cực cho mỗi hàng đợi, những gói tin (packet) được chấp nhận đưa vào hàng đợi cho đến khi hàng đợi đạt giá trị max, sau đó sẽ loại bỏ những gói tin được chuyển đến tiếp theo cho đến khi hàng đợi được giảm bớt bởi các gói đa được truyền đi Kỹ thuật này được gọi là “Drop Tail” (Khi hàng đợi đầy nó sẽ loại bỏ những gói tin ở cuối hàng đợi)

Phương pháp này có 2 hạn chế:

- Look out (khóa): Trong một số trường hợp, gói tin cuối cho phép một kết nối đơn hoặc vài luồng dữ liệu độc quyền xếp hàng ngăn ngừa các kết nối khác trong cùng hàng đợi Hiện tượng “lock out” là kết quả của sự đồng bộ hóa hay các hiệu ứng thời gian khác

- Full queue (hàng đợi đầy): Kỹ thuật Drop Tail cho phép duy trì hàng đợi ở nguyên trạng thái trong suốt thời gian dài cho đến khi có các tín hiệu tắc nghẽ (các tín hiệu tắc nghẽn này được truyền qua các gói tin bị loại bỏ khi hàng đợi đầy) Điều này rất quan trọng trong việc giảm bớt kích thước hàng đợi dừng và đây là điều quan trọng nhất trong mục đích quản lý hàng đợi

Giả thiết đơn giản đó là có một sự cân bằng đơn giản giữa độ trễ (delay) và lưu lượng Nếu hàng đợi đầy hoặc gần đầy, dẫn đến burst làm cho nhiều gói tin được loại bỏ Điều này có thể dẫn đến một sự đồng bộ hóa ở phạm vi lớn các gói tin đến sau, làm cho lưu lượng toàn bộ quá trình giảm Full Queue gây lên trạng thái không

ổn định trong hàng đợi

Một cơ chế quản lý hàng đợi tích cực có thể đem lại những ưu điểm sau:

Trang 19

- Giảm bớt những gói tin bị loại bỏ trong router Các gói tin đến dạng bó là một khía cạnh không thể tránh được của mạng gói Nếu tất cả không gian hàng đợi trong router đã trạng thái chuyển vận ổn định, hay nếu không gian bộ đệm không đủ, router sẽ không có khả năng xử lý các bó gói tin Bằng việc giữ cho kích thước hàng đợi trung bình nhỏ, quản lý hàng đợi tích cực sẽ cung cấp khả năng lớn hơn để giảm bớt các gói bị loại bỏ trong quá trình chuyển vận Hơn nữa, nếu như không có quản lý hàng đợi tích cực thì sẽ có nhiều gói tin bị loại bỏ khi hàng đợi bị tràn đầy Đây là một hạn chế cho hàng đợi bởi các lý do:

- Với một hàng đợi dùng chung, một sự đồng bộ hóa các gói tin bị loại bỏ dẫn đến hiệu quả thấp hơn trong việc sử dụng mối liên kết trung bình và làm giảm lưu lượng mạng

- Làm cho quá trình phục hồi của hệ thống khó khăn hơn

- Đó là một sự tiêu phí băng thông một cách không cần thiết

- Giảm độ trễ dịch vụ: bằng việc giữ cho kích thước hàng đợi trung bình nhỏ, quản lý hàng đợi sẽ giảm bớt độ trễ giữa các luồng dữ liệu

Tránh hiện tượng Knock-out: Quản lý hàng đợi tích cực sẽ gần như luôn luôn đảm bảo một bộ đệm sẵn có cho các gói tin được chuyển tới hàng đợi Hàng đợi tích cực sẽ có thể ngăn ngừa một sự thiên lệch trong router chống lại việc giải thông thấp nhưng lại có nhiều luồng bursty cao [1] [2]

2.1.3 Các phương pháp quản lý hàng đợi tích cực

Căn cứ theo các tham số được sử dụng để đo lường sự tắc nghẽn, các phương pháp AQM có thể được phân ra thành ba nhóm: theo chiều dài hàng đợi, theo kiểm soát tải nạp và theo sự kết hợp đồng thời cả chiều dài hàng đợi và kiểm soát tải nạp Trong các phương pháp AQM dựa trên chiều dài hàng đợi, hiện tượng tắc nghẽn được thể hiện bằng độ dài tức thời hoặc trung bình của hàng đợi và mục đích của quá trình điều khiển là ổn định độ dài hàng đợi Hạn chế của các phương pháp AQM dựa trên độ đo hàng đợi là các tồn đọng vốn có của nó Phương pháp dựa trên

sự kiểm soát tải nạp dự đoán chính xác khả năng sử dụng tuyến liên kết, xác định tắc nghẽn và đưa ra hành động dựa trên tốc độ gói tin đến Phương pháp dựa trên độ

Trang 20

kiểm soát tải nạp có thể cung cấp sự phản hồi sớm cho các trường hợp tắc nghẽn Các phương pháp AQM khác sử dụng kết hợp cả độ dài hàng đợi và kiểm soát tải nạp để đo lường tắc nghẽn và đạt được sự cân bằng giữa độ ổn định của hàng đợi và khả năng đáp ứng

Hình 2.1: Phân loại các phương pháp quản lý hàng đợi tích cực

2.2 Quản lý hàng đợi tích cực dựa trên chiều dài hàng đợi

2.2.1 Cơ chế ECN (Explicit Congestion Notification)

2.2.1.1 Khái niệm chung

Cơ chế thông báo tắc nghẽn rõ ràng ECN (Explicit Congestion Notification) là một phương pháp điều khiển tắc nghẽn, ứng dụng vào điều khiển các luồng chuyển vận được sử dụng trong hệ thống sử dụng giao thức TCP/IP

Phương pháp ECN được đề xướng vào năm 1999 từ ý tưởng sẽ phát hiện sớm những tắc nghẽn của hệ thống và gửi những tín hiệu thông báo đến hệ thống trước khi hàng đợi bị tràn Phương pháp này là một sự tiếp cận khác từ phương pháp RED

và WRED (ta sẽ đề cập cụ thể hơn về 2 phương pháp này ở phần sau) [1] [2]

Queue Length & Load Based

Active Queue Managament

7 Adaptive RED 16 CHOCKe

8 PDRED 17 Stochastic RED

Trang 21

Trong những hệ thống mạng TCP/IP hiện nay, những gói bị loại bỏ được xem là dấu hiệu thông báo sự tắc nghẽn Phần lớn những bộ định tuyến trong mạng TCP/IP

đợi tràn, những gói tin sẽ bị loại bỏ Khi các nguồn TCP phát hiện ra việc các gói tin bị loại bỏ, nó sẽ phát hiện ra sự tắc nghẽn hiện thời trong mạng

Vì thế, người ta đề ra giải pháp để phát triển việc phát hiện sự tắc nghẽn

hệ thống bằng cách tính toán kích thước hàng đợi trung bình và đặt một bit ECN trong packet header khi kích thước hàng đợi trung bình vượt quá một ngưỡng nào đó với ý tưởng sẽ phát hiện và thông báo sự tắc nghẽn mà không cần phải dựa vào những gói tin bị loại bỏ Đây chính là sự khác biệt cơ bản giữa cơ chế ECN và cơ chế RED Ở cơ chế RED, khi xảy ra tắc nghẽn, các gói tin được loại bỏ một cách ngẫu nhiên Còn ở cơ chế ECN, những trường đã được đánh dấu sẽ được

đi qua để thông báo sự tắc nghẽn đến hệ thống Điểm giống nhau giữa hai cơ chế này là đều cùng sử dụng chung một giải thuật lựa chọn gói tin dự báo sự tắc nghẽn [2]

2.2.1.2 Sự đánh dấu trong IP header

ECN FIELD (Trường ECN trong IP header)

Hình 2.2: ECN Field trong IP header

TCP sử dụng một trường ECN ở IP header với hai bit để đánh dấu 4 mã ECN từ

“00” đến “11” được hiểu như một mã Congestion Experienced (CE) dùng để chỉ ra

sự tắc nghẽn đến các điểm nút kết thúc Mã “10” và “01” tương ứng biểu diễn các

mã ECT(0) và ECT(1) được sử dụng để biểu thị đó là ECN-Capable Hai mã này dùng để các bộ định tuyến nhận biết được và không xóa bỏ mã CE trong quá trình

Trang 22

chuyển đi của nó và đồng thời để các thiết bị nhận được mã CE báo cáo lại bên phát một cách chính xác việc đã nhận được các mã CE này Mã “00” để xác định gói dữ liệu đó hiện giống như các gói không sử dụng ECN khác (Mặc định trong tất cả các gói IP khác là “00”) [1] [2] [30]

Hình 2.3: ECN bit trong IP header 2.2.1.3 Sự đánh dấu trong TCP header

TCP header cũng chứa đựng những thông tin cho quá trình ECN Trong TCP header người ta đưa ra hai cờ: CWR (Congestion Window REDuced) và ECE (ECN Echo)

- Cờ ECE dùng để xem xét các khả năng ECN giữa nguồn phát và nguồn thu TCP

- Cờ CWR được dùng để gửi thông báo từ phía nguồn phát đến nguồn thu rằng cửa sổ tắc nghẽn đã được giảm bớt Qua thông báo này, nguồn nhận sẽ có thể xác định thời điểm ngừng đặt cờ ECN-Echo [1] [2] [30]

2.2.1.4 Cơ chế hoạt động

Trang 23

ECN sử dụng hai cờ ECT và CE ở trong IP header để báo hiệu giữa các endpoint (điểm cuối) với những bộ định tuyến trong một kết nối Hai cờ CWR và ECN-Echo trong TCP header để giao tiếp giữa 2 TCP-endpoit

Hoạt động giữa bên thu và bên phát TCP diễn ra theo một chuỗi các sự kiện:

- Sau những thỏa thuận rõ ràng giữa bên phát và bên thu về việc quyết định sử dụng ECN, bên phát đặt một mã ECN-Capable Transport (ECT) vào IP header của gói tin

Hình 2.4: Cấu trúc hai trường code field và Reserved field của TCP hearder

- Khi một bộ định tuyến có sử dụng ECN phát hiện ra sự tắc nghẽn, nó sẽ lựa chọn một gói tin Nếu gói tin đó được đặt mã ECT, thay vì loại bỏ gói tin này, bộ định tuyến sẽ đặt một mã CE (Congestion Experienced) thông báo sự tắc nghẽn vào

IP header của gói tin này mục đích để thông báo đến bên thu dấu hiệu của sự tắc nghẽn sắp xảy ra và tiếp tục chuyển nó đến bên nhận

- Khi nhận được gói tin với bit CE này, thiết bị thu sẽ đặt một cờ ECN-Echo (ECE) trong phiên TCP ACK tiếp theo của bên phát

- Khi bên phát nhận được gói ACK này, nó sẽ đặt một cờ CWR xác nhận việc

nó đã nhận được gói ACK với cờ ECE kia và đồng thời nó sẽ giảm nhịp độ gửi dữ liệu và thông báo nó đã sẵn sàng phản ứng lại tới sự tắc nghẽn sắp xảy đến [1] [3] [7]

Code field 6 bit URG

1bit

ACK

SYN 1bit

FIN 1bit Reserved Field 6 bit

Reserved

1bit

Reserved 1bit

Reserved 1bit

Reserved 1bit

CWR 1bit

ECN Echo 1bit

Trang 24

2.2.2 Cơ chế hủy bỏ sớm ngẫu nhiên theo trọng số WRED (Weighted

Random Early Detection)

2.2.2.1 Khái quát

Khi một hàng đợi bị đầy, nó không còn chỗ cho các gói tin vừa đến, vì vậy nó sẽ loại bỏ các gói này Hiện tượng này gọi là loại bỏ cuối hàng (tail drop) Thông thường khi một hàng đợi bị đầy, vài gói tin sẽ bị loại bỏ cùng lúc ở một thời điểm

Cơ chế loại bỏ cuối hàng tail drop có thể gây ảnh hưởng tiêu cực trên lưu lượng mạng, đặc biệt là lưu lượng TCP Khi thả một gói tin bị mất, vì bất kỳ lý do gì, các kết nối TCP sẽ giảm tốc độ gửi dữ liệu Khi hiện tượng loại bỏ gói tin xảy ra và nhiều gói tin bị mất, các kết nối TCP sẽ giảm tốc độ thêm nữa Ngoài ra, hầu như các mạng đều gửi một tỉ lệ phần trăm của lưu lượng TCP nhiều hơn UDP, nghĩa là toàn bộ tải của mạng có khuynh hướng bị loại bỏ

Thông lượng tổng thể của mạng có thể dược cải tiến bằng cách loại bỏ chỉ vài gói tin khi hàng đợi bắt đầu bị đầy Cách tốt hơn là chờ những ảnh hưởng của cơ chế Tail Drop Cisco đã tạo ra cơ chế WRED (Weighted Random Early Detection) đặt biệt cho mục đích giám sát chiều dài hàng đợi và loại bỏ một số gói tin trong hàng đợi để cải tiến hiệu năng của mạng Khi hàng đợi trở nên dài hơn, WRED bắt đầu loại bỏ nhiều gói tin, với hy vọng rằng sự gia giảm trong phần tải có thể đủ để ngăn ngừa hàng đợi bị đầy [3] [13]

2.2.2.2 Cơ chế hoạt động

Trang 25

Hình 2.5: Sơ đồ hoạt động của WRED

WRED dùng vài chỉ số khi thực hiện quyết định Đầu tiên, WRED dùng thông

số kích thước hàng đợi trung bình khi nó quyết định là một hàng đợi đã bị đầy đủ để bắt đầu loại bỏ gói tin WRED sau đó sẽ so sánh chiều sâu trung bình với mức giới chặn trên và chặn dưới, thực hiện các hành động loại bỏ khác nhau tùy thuộc vào kết quả so sánh Các hành động được liệt kê trong bảng dưới đây:

Bảng 2.1: Giải thuật WRED

Loại bỏ ngẫu nhiên

Trang 26

chặn dưới lên mức chặn trên

Kích thước trung bình >

Mức chặn trên

Tất cả các gói tin mới sẽ

bị loại bỏ Tương tự như loại bỏ cuối hàng (tail drop)

Loại bỏ hoàn toàn

Khi kích thước trung bình của hàng đợi là rất thấp hay rất cao, hành động là rất

rõ ràng Khi kích thước hàng đợi trung bình tăng trên mức giới hạn trên, WRED sẽ loại bỏ tất cả các gói tin mới Mặc dù hành động này có thể giống cơ chế loại bỏ cuối hàng tail drop, nhưng về phương diện kỹ thuật hai cơ chế không giống nhau, vì hàng đợi thực sự có thể không bị đầy Vì vậy, để thấy rõ sự khác biệt này, WRED gọi nhóm hành động này là loại bỏ hoàn toàn full drop

Hình 2.6: Cơ chế loại bỏ gói tin của WRED

Khi kích thước trung bình của hàng đợi nằm giữa hai giới hạn WRED sẽ loại bỏ một số gói tin Tỉ lệ loại bỏ tăng tuyến tính khi kích thước trung bình hàng của hàng đợi tăng từ mức tối thiểu lên mức tối đa như mô tả trong hình trên [14]

2.2.2.3 Sự ảnh hưởng của thông số MPD (mark probability denominator) đến

sự hoạt động của WRED

Thông số cuối cùng của WRED ảnh hưởng tới hoạt động của nó là thông số MDP (mark probability denominator) Thông số này là cơ sở để tính ra tỉ lệ phần

Trang 27

trăm tối đa 10% trong hình 2.6 IOS tính tỉ lệ phần trăm bị loại bỏ được dùng ở mức giới hạn chặn trên dựa trên công thức đơn giản 1/MPD Trong hình 2.6, giá trị MPD bằng 10 sẽ tính ra giá trị nêu trên, nghĩa là tốc độ loại bỏ gói tin tăng từ 0 đến 10% khi kích thước hàng đợi trung bình tăng từ mức tối thiểu đến mức tối đa Ngoài ra, khi WRED loại bỏ gói tin, nó sẽ ngẫu nhiên chọn lựa gói tin để loại bỏ

WRED gán các độ ưu tiên đến các gói tin với một giá trị IPP hoặc DSCP (Differentiated Services Codepoint) nào đó Để thực hiện điều này, WRED dùng các mẫu lưu lượng khác nhau cho các giá trị IPP và DSCP khác nhau Một mẫu lưu lượng WRED bao gồm việc gán ba biến quan trọng của WRED: mức chặn dưới, mức chặn trên và giá trị MPD

Bảng 2.2 liệt kê các thông số mặc định của WRED cho các giá trị DSCP khác nhau Các giá trị mặc định của hệ điều hành IOS sẽ đạt được mục đích đó bằng cách gán giá trị giới hạn chặn dưới và chặn trên thấp hơn cho các giá trị DSCP [14] Bảng 2.2: Các thông số mặc định của WRED cho các giá trị DSCP khác nhau

2.2.31 Tổng quan về Adaptive RED

Phương pháp Adaptive RED (ARED) được đề xướng lần đầu tiên bởi Feng vào năm 1997 Và sau đó, năm 2001, Floyd, Gummadi và Shenker đã có những cải tiến với đề xướng của Feng dựa trên những ý tưởng cơ bản ban đầu của ông Những tác giả này đưa ra những mở rộng trong RED để loại bỏ những khó khăn trong việc thiết đặt các tham số cho RED Hơn nữa, ARED có thể đạt được một kích thước hàng đợi trung bình chuẩn trong những lưu lượng mạng khác nhau [14]

Trang 28

Những ý tưởng đặt ra chủ yếu tập trung vào những vấn đề điều khiển tham số maxp của giải thuật RED thật phù hợp với sự thay đổi trong mạng Điều này sẽ làm cho kích thước hàng đợi ổn định hơn Giải thuật này sẽ khảo sát trung bình độ dài hàng đợi để quyết định xem RED có cần thiết phải linh hoạt hơn nữa không Nếu như trung bình chiều dài hàng đợi ở trạng thái nhỏ hơn giá trị minth thì cơ chế dò tìm đang hoạt động rất tốt, còn ngược lại, nếu giá trị trung bình chiều dài hàng đợi lớn hơn giá trị maxth thì cơ chế dò tìm chưa đủ linh hoạt

Every Q(ave) Update:

if (minth < Q(ave) < maxth)

Hình 2.7: Giải thuật Adaptive RED tổng quát

Giải thuật này giữ cấu trúc cơ bản của RED và đơn thuần điều chỉnh tham số maxp để giữ kích thước hàng đợi trung bình giữa maxth và minth

Giải thuật này không những dự đoán trước độ trễ của hàng đợi trung bình mà còn tối giản khả năng của việc vượt quá ngưỡng maxth của kích thước hàng đợi trung bình Như vậy, ARED giảm bớt cả 2 mức tổn thất mất gói và sự mâu thuẫn trong độ trễ hàng đợi ARED giải quyết vấn đề của việc thiết đặt các tham số cho RED, một trong những điểm yếu của RED Giải thuật này giúp tránh việc phải hủy

bỏ những thiết kế cơ bản của RED để làm ổn định chiều dài hàng đợi trung bình và

nó có thể thiết lập tự động các tham số khác của RED

Những mục đích của giải RED hay cũng như cảu quản lý hàng đợi tích cực nói chung là có được một trung bình hàng đợi trễ thấp và có được một lưu lượng cao

Trang 29

Vì vậy, những đánh giá của ARED tập trung chủ yếu vào xem xét trung bình hàng đợi trễ và lưu lượng [14][15][16][17][18]

- maxth được làm thích nghi một cách từ từ

- maxth được đặt cố định trong khoảng [0.01, 0.5] (hay tương đương [1%, 50%] Cách này sẽ đảm bảo sự thực hiện của ARED sẽ không bị giảm sút trong thời gian chu kỳ chuyển tiếp Điều này đảm bảo trong chu kỳ chuyển tiếp, chỉ tiêu toàn bộ của RED cần phải vẫn còn chấp nhận được, mặc dù kích thước trung bình hàng đợi

có lẽ đã không còn trong phạm vi đích, và trung bình độ trễ cũng như thông lượng mạng có thể đã suy giảm

- Thay vì việc tăng lên và giảm bớt maxp, người ta sử dụng chính sách increase multiplicative-decrease (AIMD)

additive-Cách tiếp cận thứ 3 sẽ đảm bảo sự thực hiện của ARED sẽ không bị giảm sút trong thời gian chu kỳ chuyển tiếp (giữ maxP trong phạm vi [0.01, 0.5) Điều này đảm bảo trong chu kỳ chuyển tiếp, chỉ tiêu toàn bộ của RED cần phải vẫn còn chấp nhận được, mặc dù kích thước trung bình hàng đợi có lẽ đã không trong phạm vi đích, và trung bình độ trễ và thông lượng có thể đã suy giảm

Every interval seconds:

if (avg > target and maxp ≤ 0.5)

increase maxp:

maxp <- maxp + α;

else if (avg < target and maxp ≥ 0.01)

Trang 30

- interval: thời gian, 0.5 giây

- target: phạm vi của avg Phạm vi này là một khoảng:

[minth + 0.4* (maxth – minth), minth + 0.6* (maxth – minth)]

α: Hệ số tăng; giá trị của nó bằng min (0.01, maxp/4)

ß: Hệ số giảm; giá trị được lấy bằng 0.9

Giải thuật ARED trong hình 2.8 sử dụng AIMD (sự tăng lên hay giảm bớt) cho việc làm thích nghi maxp [15]

- Cận dưới của maxp được đặt là 0.01 với một sự kỳ vọng giới hạn phạm vi của maxp

Với giới hạn dưới được đặt là 0.01 thì RED thực sự hoạt động rất tốt

- Những tham số α và ß:

Trang 31

Khi thiết lập các giá trị mặc định cho α và ß, ta cần đảm bảo trong một điều kiện bình thường, một sự cải biến đơn giản của maxp không dẫn đến sự thay đổi của kích thước hàng đợi trung bình trong phạm vi đích của nó

Mặc định, người ta chọn:

- α < 0.25 maxp (min [0.01, maxP/4]

- ß > 0.83 (ở hình trên, chọn ß =0.9)

- Thiết lập các tham số maxth và wq:

Như ở trên đã nói, Adaptive RED loại bỏ việc phụ thuộc các tham số của RED

Để giảm bớt yêu cầu phải điều chỉnh các tham số cho RED, người ta đưa ra các thủ tục cho sự thiết đặt tự động các tham số maxth và wq

Người ta thiết lập maxth bằng 3 lần minth Trong trường hợp này, kích thước hàng đợi trung bình đích được đặt chính giữa khoảng 2* minth vì thế, nó chỉ được xác định bởi giá trị minth của RED

Trang 32

Hình 2.9: Một mô hình kiến trúc mạng để thực hiện giải thuật DRED

Mô hình mạng trên bao gồm những TCP host (gồm cả host nguồn và đích), gateway (R1 và R2) Những nguồn dữ liệu từ TCP nguồn qua R1 và R2 chuyển đến những host đích Và giữa 2 gateway là một “bottleneck channel” Các thành phần của mô hình mạng trên được mô tả cụ thể hơn như sau:

TCP Host: Chứa những nguồn dữ liệu nguồn và những dữ liệu được chuyển đến (tạm gọi là dữ liệu đích) trong mạng Nó bao gồm việc chuyển vận các khối dữ liệu

“long-live-bulk-data” Nếu sự tắc nghẽn nhất thời xảy ra bởi việc truyền các khối dữ liệu long-live-bulk-data thì sự tắc nghẽn rất dễ trở nên lâu hơn nếu cơ chế điều khiển tắc nghẽn không có sự phản hồi tới những nguồn chuyển vận Nếu sự tắc nghẽn xảy ra bởi việc chuyển vận khối dữ liệu tương tác hay nguồn dữ liệu short-lived bulk-data hay các khối dữ liệu tương tác thì sự tắc nghẽn này là không quá nghiêm trọng khi hàng đợi chưa đầy vì những luồng chuyển vận như thế này sẽ nhanh chóng hoàn thành hoặc được ngưng lại

Data channel (kênh dữ liệu): Những kênh dữ liệu là một mối liên kết truyền thông giữa 2 (hoặc nhiều hơn) host trong mạng Mỗi kênh dữ liệu có một đặc điểm riêng về băng thông và độ trễ

Trang 33

Gateway: Gateway là một thiết bị dùng để kết nối hệ thống mạng sử dụng những giao thức chuyển vận khác nhau Nhờ thiết bị này mà thông tin có thể đi từ điểm này đến điểm khác trong một hệ thống sử dụng nhiều giao thức chuyển vận khác nhau [20]

2.2.4.2 Phân tích mô hình hệ thống

Như ta đã tìm hiểu về giải thuật RED, một cơ chế điều khiển tắc nghẽn RED gồm có 2 chức năng là: Phát hiện sớm sự tắc nghẽn và quyết định những kết nối nào được thông báo tắc nghẽn Ở đây, ta sẽ đi sâu xem xét việc phát hiện sự tắc nghẽn

như thế nào bằng việc sửa đổi cơ chế nguyên bản của RED để thiết kế một cơ chế điều khiển tắc nghẽn vô điều kiện cho sự tắc nghẽn nhất thời mà có hại cho hệ thống khi hàng đợi gần đầy

Trọng số hàng đợi wq được sử dụng để kiểm soát nhịp độ việc thay đổi các luồng vận chuyển tại gateway gây ra bởi kích thước hàng đợi trung bình (ở giải thuật RED nguyên bản, wq được thiết đặt trước và nó là một hằng số trong quá trình thực hiện) Ở phương pháp này, người ta thay đổi giá trị của wq cho phù hợp với sự thay đổi của kích thước hàng đợi thực tế Bằng việc thiết đặt lại tham số wq, sẽ giúp phát hiện ra sự tắc nghẽn nhất thời đúng lúc khi hàng đợi gần đầy và có thể đưa ra những hoạt động để dập tắt sự tắc nghẽn, tránh tràn bộ đệm

Việc thiết đặt lại tham số wq làm cho giải thuật RED thay đổi Pha tránh né tắc nghẽn được mở rộng và chia thành một số pha con DRED điều chỉnh giá trị maxp phụ thuộc vào chiều dài hàng đợi trung bình hiện thời maxp được tăng tỷ lệ với sự tăng lên của chiều dài hàng đợi trung bình [20]

2.2.4.3 Điều chỉnh trọng số hàng đợi Wq

Với tham số wq được thiết lập sẵn, giải thuật RED không thể phản ứng thật tốt khi xảy ra bursty cao để ngăn ngừa tràn bộ đệm Một khía cạnh khác, nếu đặt wq quá cao thì giải thuật RED lại phản ứng quá nhanh với những luồng short-lived-bursty (mà điều này hoàn toàn không cần thiết) Ở giải thuật RED, thông số wq được điều chỉnh mỗi khi có gói tin được chuyển tới như ở phương trình bên dưới

Trang 34

Ở phương pháp RED, người ta giới thiệu một ngưỡng mới gọi là “warning line” khi đo kích thước hàng đợi thực tế trên mỗi gói được chuyển đến Nó chia việc thiết đặt wq thành 2 phần: Nếu kích thước hàng đợi thực tế ở dưới ngưỡng “warning line”, wq được đặt giá trị chính xác giống như ở giải thuật RED thông thường Tuy nhiên, ngay khi kích thước hàng đợi thực tế ở trong hay vượt quá ngưỡng “warning

cao, trọng số wq càng lớn

For each arriving packet P:

q+ +

if (q > avg) diff = q – avg;

else diff = 0;

case 1: nwq = oldwq * 4 case 2: nwq = oldwq * 8 case 3: nwq = oldwq * 12 case 4: nwq = oldwq * 16 default: nwq = oldwq * 20 for each departing q ;

if (avg > q)

nwq = oldwq * 10;

Trang 35

Giải thuật chi tiết cho việc tính toán wq được biểu diễn dưới hình 2.10:

Ý nghĩa và giá trị của các tham số được thể hiện ở bảng 2.3:

Bảng 2.3: Ý nghĩa và giá trị của các tham số trong giải thuật DRED

Tỷ số giữa old_q và buf_s Phần nguyên của (10*ratio) Trọng số hàng đợi mới

Trang 36

Điểm nổi bật của giải thuật là sẽ phát hiện giai đoạn khởi sinh tắc nghẽn một cách nhanh chóng khi hàng đợi gần đây và lưu lượng đến là một luồng bursty cao [20]

2.2.4.4 Điều chỉnh xác suất loại bỏ gói cực đại maxp

Ở giải thuật RED, RED rất nhạy cảm với thông số xác suất loại bỏ gói cực đại maxp để xác định sự linh hoạt của giải thuật đối với những luồng dữ liệu chuyển tới khi kích thước hàng đợi trung bình nằm trong khoảng (maxth minth) Nhu cầu đặt ra là cần thay đổi maxp theo sự thay đổi của kích thước hàng đợi trung bình để giảm độ trễ của hàng đợi và tránh tràn bộ đệm

Giá trị maxp ở giải thuật RED là một hằng số, không phụ thuộc vào kích thước hàng đợi trung bình Xác suất loại bỏ gói tin Pb được tính theo công thức:

Ở mô hình DRED, việc điều chỉnh giá trị maxp tương ứng với sự thay đổi của kích thước hàng đợi trung bình Điều này làm cho maxp sẽ được điều chỉnh phù hợp với những luồng vận chuyển khác nhau [20]

2.2.5 Stabilized RED (SRED)

2.2.5.1 Cơ chế và ý nghĩa

Ở giải thuật RED, chiều dài hàng đợi trung bình phụ thuộc vào số những kết nối TCP Nhưng RED lại không phân biệt được những luồng “misbehaving flow” (những luồng chiếm giữ nhiều hơn lượng băng thông dùng chung) Người ta đưa ra phương pháp Stabilized RED (SRED) để ngăn ngừa sự sai lệch do các luồng

“misbehaving” này gây ra

Trang 37

SRED đánh giá số lượng các kết nối TCP tích cực và sẽ xác định xác suất loại

bỏ gói tin qua việc đánh giá các kết nối này Để đánh giá những kết nối TCP tích cực, SRED sử dụng khái niệm “zobie list” “Zombie list” có thể được hiểu là một danh sách gồm m luồng tin và những thông tin của các luồng này “Zombie list” lưu giữ thông tin tại mỗi kết nối và biểu thị chúng trong list Mỗi entry của “zombie list” bao gồm một định dạng luồng, 1 biến đếm và một “time stamp” Ở thời điểm ban đầu, “zombie list” là rỗng Khi có những gói tin được chuyển đến cho đến khi danh sách chưa đầy, các định danh như địa chỉ nguồn, địa chỉ đích,… cảu mỗi gói tin sẽ được đưa vào danh sách Ban đầu, biến đếm “count” của “zombie list” được đặt là 0 và “time stamp” là thời gian đến của gói tin Khi có một gói tin được chuyển đến router, SRED sẽ so sánh một sự lựa chọn ngẫu nhiên một entry nào đó

từ “zombie list” với entry tương ứng của gói tin vừa chuyển đến Nếu những mục này trùng nhau, bộ đếm sẽ tăng lên 1 và “time stamp” được thay đổi bằng thời gian đến của gói trong bộ đệm [22] [23] [25]

Hình 2.12: Một topo mạng gồm 2 router sử dụng SRED 2.2.5.2 Giải thuật của Stabilized RED và ý nghĩa các tham số

Đầu tiên, SRED sẽ so sánh một entry được lựa chọn ngẫu nhiên từ danh sách

“zombie list” với entry tương ứng trong gói tin vừa chuyển đến Chúng ta sẽ xem xét trên n gói tin chuyển đến Nếu những entry của chúng tương ứng với “zombie list”, H(n) sẽ được đặt bằng 0 Xác suất P(n) (xác suất “zombie list” chứa entry tương ứng entry của gói tin chuyển đến) được tính bởi công thức:

Trang 38

P(n) = (1- α)*P(n-1) + α*H(n)

Ở đây, α là tham số điều khiển của thuật toán SRED (0 < α < 1)

PsRED(q) là xác suất loại bỏ gói tin, nó tỷ lệ với chiều dài hàng đợi tức thời q

và được tính bởi công thức: [22][25]

Pzap = PsRED(q)*min (1, 2

))(

*256(

1

n

)(

)(

n P

n H

)

2.2.6 Phát hiện sớm ngẫu nhiên cân bằng FRED

RED không chắc chắn rằng lưu lượng cùng được chia sẽ băng thông công bằng Trên thực hiện tế, RED không đối xứ công bằng với các luồng TCP tốc độ thấp bởi RED ngẫu nhiên loại bỏ các gói khi vượt quá mức ngưỡng max, do đó mỗi gói trong số các gói đó có băng thông nhỏ hơn băng thông được chia sẻ công bằng Khi các luồng TCP có quá nhiều gói bị mất thì chúng cũng yêu cầu nhiều hơn các chức năng cửa sổ điều khiển tắc nghẽn, do đó tốc độ sẽ càng thấp hơn FRED là một biến thể của RED để giảm tính không công bằng trong phân bổ băng thông

FRED hoạt động giống như RED nhưng có thêm một số chức năng mới: FRED đưa ra thêm hai tham số maxp và minq là số lượng các gói lớn nhất và nhỏ nhất trong mỗi luồng được phép đưa vào hàng đợi Ngoài ra FRED còn có thêm biến toàn cục avgcq, đánh giá kết quả đếm bộ đệm trên mỗi luồng trung bình Khi một luồng có số lượng các gói trong hàng đợi nhỏ hơn avgcq thì chúng sẽ được ưu tiên

Trang 39

hơn FRED sẽ duy trì số đếm qlen của các gói được đệm cho mỗi luồng mà đã có bất kì gói nào đó trong bộ đệm FRED duy trì biến strike để đếm thời gian mà một luồng trượt đáp ứng với các thông báo tắc nghẽn FRED cho phép mỗi kết nối được đưa vào bộ đệm số lượng các gói có giá trị minq mà không bị loại bỏ Tất cả các gói thêm vào đều bị loại bỏ bởi RED Các gói đến được chấp nhận nếu kết nối có ít hơn minq được đệm và kích thước hàng đợi trung bình nhỏ hơn maxth Thông thường một kết nối TCP gửi ít hơn 3 gói ngược trở lại: hai gói cho trễ ACK, một gói để điều khiển tăng kích thước của sổ Do đó minq được thiết lập từ 2 đến 4 gói tin Khi số lượng các kết nối tích cực nhỏ (N<<minth/minq), FRED cho phép mỗi kết nối được đệm minq các gói mà không bị loại bỏ Nó cũng tăng từ giá trị minq tới kích thước hàng đợi trung bình trên một kết nối (avgcq) Một cách đơn giản, nó tính toán giá trị này bằng cách phân chia kích thước hàng đợi trung bình bằng việc

sử dụng số lượng các kết nối tích cực Một kết nối là tích cực khi nó có các gói được đưa vào trong bộ đệm và kết nối thụ động trong trường hợp ngược lại

FRED không bao giờ để các luồng tới bộ đệm có số lượng các gói tin lớn hơn maxp gói trong bộ đệm, và đếm thời gian mỗi luồng để cố gắng vượt qua giá trị maxq trong biến strike của mỗi luồng Các luồng có giá trị strike cao đều không được cho phép tới hàng đợi có nhiều hơn avgcq gói Vì vậy, chúng không cho phép

sử dụng nhiều gói hơn luồng trung bình Điều này cho phép thích ứng các luồng để gửi các bó gói RED ban đầu định giá kích thước hàng đợi trung bình tại mỗi gói đến Trong FRED trung bình được thực hiện tại các gói đến và đi Do đó tần số lấy mẫu là giá trị lớn nhất của tốc độ đầu vào và tốc độ đầu ra FRED không chỉnh sửa

độ trung bình nếu gói tới bị loại bỏ trừ khi kích thước hàng đợi tạm thời bằng 0

2.3 Quản lý hàng đợi tích cực dựa trên kiểm soát tải nạp

Các giải thuật AQM dựa trên kiểm soát tải nạp phát hiện tắc nghẽn và xử lý dựa trên tốc độ gói tin đến Mục đích của các giải thuật AQM dựa trên kiểm soát tải nạp

là giảm bớt sự chênh lệch tốc độ giữa đầu vào và đầu ra, đạt được sự mất gói là nhỏ, trễ nhỏ và hiệu quả sử dụng tuyến cao Do chiều dài hàng đợi là một giá trị tích lũy gián tiếp khác của sự chênh lệch tốc độ giữa đầu vào và đầu ra nên phương pháp

Trang 40

dựa trên chiều dài hàng đợi không nhạy cảm với tốc độ của các luồng đến hiện tại

và có thể dẫn đến gói tin tiếp tục bị đánh dấu dù hco chiều dài hàng đợi là nhỏ hay lớn Điều này diễn giải phần nào sự hoạt động kỳ vọng hơn của giải thuật AQM dựa trên kiểm soát tải nạp so với các giải thuật dựa trên độ dài hàng đợi trong các tình huống luồng lưu lượng động

2.3.1 Thuật toán SFB

Hình 2.13 cho thấy thuật toán SFB cơ bản SFB là một thuật toán hàng đợi FIFO

nó nhận biết và hạn chế tốc độ các luồng không đáp ứng dựa trên cơ chế tính toán tương tự như được sử dụng với BLUE với một lượng nhỏ thông tin về trạng thái SFB duy trì NxL ngăn nhớ (bins) đã tính toán Các ngăn nhớ được tổ chức thành L cấp với N ngăn nhớ trong mỗi cấp Ngoài ra, SFB duy trì (L) hàm hash độc lập, tương ứng với mỗi mức của các ngăn nhớ tính toán Mỗi hàm hash sắp xếp (maps) một luồng vào một trong N ngăn nhớ tính toán ở mức đó Các ngăn nhớ tính toán được sử dụng để theo dõi các số liệu thống kê sự chiếm dụng hàng đợi của các gói tin thuộc một ngăn nhớ cụ thể

B[l][n]: LxN array of bins (L levels, N bins per level)

Enque()

Calculate hash function values ho, h1,…, hL – 1;

Update bins at each level

Ngày đăng: 19/11/2014, 19:48

Nguồn tham khảo

Tài liệu tham khảo Loại Chi tiết
[1] Braen,B, Clark, D,et.al. (1998), “ Recommendations on queue management and congestion avoidance in the Internet ” IETF RFC (Information) 2309 Sách, tạp chí
Tiêu đề: Recommendations on queue management and congestion avoidance in the Internet ”
Tác giả: Braen,B, Clark, D,et.al
Năm: 1998
[2] Joerg Widmer., Robert Denda, Martin Mauve Prakitsche Informatik IV. (2001) , “ A Survey of TCP Friendly Congestion Control ” , IEEE Transactions on Network Sách, tạp chí
Tiêu đề: A Survey of TCP Friendly Congestion Control ”
[3] E.Hashem. (1998), “ Analysis of Random drop for gateway congestion Control” report LCS, TR - 465, Laboratory for Computer Science, MIT, Cambridge, MA, , p 103 Sách, tạp chí
Tiêu đề: Analysis of Random drop for gateway congestion Control” report LCS, TR - 465, "Laboratory for Computer Science, MIT, Cambridge, MA
Tác giả: E.Hashem
Năm: 1998
[4] T.V. Lakshman, A. Neidhardt, T. Ott, The Drop From Straegy in TCP Over ATM and Its Interworking with Other Control Features, Proc. Infocom 96, pp. 242 – 1250 Sách, tạp chí
Tiêu đề: Proc. Infocom 96
[6] W.Feng, D.D Kandlur, D.Saha, K.G.Shin. (1999), “ A Self Configuring RED Gateway ” , Proceedings of IEEE INFOCOMM, Vol 3 pp 1320 – 1328 Sách, tạp chí
Tiêu đề: A Self Configuring RED Gateway ” , "Proceedings of IEEE INFOCOMM
Tác giả: W.Feng, D.D Kandlur, D.Saha, K.G.Shin
Năm: 1999
[7] D.lin, R.Morris. (1997), “ Dynamics of Random early Detection ” , Proceedings of ACM SIGCOMM Sách, tạp chí
Tiêu đề: Dynamics of Random early Detection ”
Tác giả: D.lin, R.Morris
Năm: 1997
[8] Mark Parris, Kevin Jeffay, F. Donelson Smith. (1999), “ Lightweight Active Router Queue management for Multimedia Networking ” Multimedia Computing and Networking 1999, Proceedings, SPIE Proceeding Series, Volume 3654, San Jose, CA, pages 162-174 Sách, tạp chí
Tiêu đề: Lightweight Active Router Queue management for Multimedia Networking ” Multimedia Computing and Networking 1999, Proceedings, "SPIE Proceeding Series
Tác giả: Mark Parris, Kevin Jeffay, F. Donelson Smith
Năm: 1999
[9] T.J.Ott, T.V.Lakshman, and L.Wong. (1999), “ SRED: Stablised RED ” in IEEE INFOCOMM Sách, tạp chí
Tiêu đề: SRED: Stablised RED ”
Tác giả: T.J.Ott, T.V.Lakshman, and L.Wong
Năm: 1999
[10] Bing Zheng, Mogammed Atiquzzaman. (2000), “ DSRED: An active Queue Management Scheme for Next Generation Network”, Proceedings of 25th IEEE conference Local Computer Networks LCN 2000 Sách, tạp chí
Tiêu đề: DSRED: An active Queue Management Scheme for Next Generation Network”
Tác giả: Bing Zheng, Mogammed Atiquzzaman
Năm: 2000
[11] Jahoon Koo, Byunghun Song, Kwangsue Chung, Hyukjoon Lee, Hyunkook Kahng. (2001), “MRED: A New Approach To Random Early Detection” 15 th International Coference on Information Networking Sách, tạp chí
Tiêu đề: MRED: A New Approach To Random Early Detection” 15th
Tác giả: Jahoon Koo, Byunghun Song, Kwangsue Chung, Hyukjoon Lee, Hyunkook Kahng
Năm: 2001
[13] Jinsheng Sun, King-Tim Ko, Guanrong Chen, Sammy Chan, Moshe Sukerman . (2003), “PD – RED: To Improve Performance of RED”, IEEE COMMUNICATIONS LETTER Sách, tạp chí
Tiêu đề: PD – RED: To Improve Performance of RED”
Tác giả: Jinsheng Sun, King-Tim Ko, Guanrong Chen, Sammy Chan, Moshe Sukerman
Năm: 2003
[14] Chonggang Wang, Bin Liu, Y.thomas Hou, Kazem Sohraby, Yu Lin. (2004), “LRED: A Robust Active Queue Managemant Scheme Based On Packet Loss Ration” 23 rd Annual Joint conference of IEEE Computer and Communication Societies INFOCOM Sách, tạp chí
Tiêu đề: LRED: A Robust Active Queue Managemant Scheme Based On Packet Loss Ration” "23"rd
Tác giả: Chonggang Wang, Bin Liu, Y.thomas Hou, Kazem Sohraby, Yu Lin
Năm: 2004
[15] Mark Claypool, Robert Kinicki, Mathew Hartling. (2004), “Active Queue Management for Web Traffic” IEEE International Conference on Performance, Computing and Comunication 2004 Sách, tạp chí
Tiêu đề: Active Queue Management for Web Traffic”
Tác giả: Mark Claypool, Robert Kinicki, Mathew Hartling
Năm: 2004
[16] Liujia Hu, Ajay D.Kshemkalyani. (2004), “HRED: A simple and Efficient Active Queue Management Algorithm”, 13 th International Conferrence on Computer Communications and Networking ICCCN 2004 Sách, tạp chí
Tiêu đề: HRED: A simple and Efficient Active Queue Management Algorithm”, "13"th
Tác giả: Liujia Hu, Ajay D.Kshemkalyani
Năm: 2004
[17] Yue-Dong Xu, Zhen-Yu Wang, Hua Wang. (2005), “ARED A Novel Adative Congestion Controller” IEEE International Conference on Machine Learning and Cybernetics Sách, tạp chí
Tiêu đề: ARED A Novel Adative Congestion Controller”
Tác giả: Yue-Dong Xu, Zhen-Yu Wang, Hua Wang
Năm: 2005
[18] Tae-Hoon Kim, Kee-Hyun Lee. (2006), “Refined Adaptive RED in TCP/IP Networks”, IEEE ICASE Sách, tạp chí
Tiêu đề: Refined Adaptive RED in TCP/IP Networks”
Tác giả: Tae-Hoon Kim, Kee-Hyun Lee
Năm: 2006
[19] Jiong-Hwan Seol, Ki Young Lee, Yoon Sik Hong. (2006), “Performance Improvement of Adaptive AQM Using the Variation of Queue Length” IEEE Region 10 Conferencer TENCON Sách, tạp chí
Tiêu đề: Performance Improvement of Adaptive AQM Using the Variation of Queue Length”
Tác giả: Jiong-Hwan Seol, Ki Young Lee, Yoon Sik Hong
Năm: 2006
[20] Tetsuji Yamaguchi, Yutaka Takahashi. (2007), “A queue Management algorithrm for fair bandwidth allocation” Computer Communication Sách, tạp chí
Tiêu đề: A queue Management algorithrm for fair bandwidth allocation”
Tác giả: Tetsuji Yamaguchi, Yutaka Takahashi
Năm: 2007
[21] Pan,R, Pabhakar, B, Psounis,K. (2000), “CHOKe, a Stateless Active Queue Management Scheme for Approximating Fair BandwidthAllocation”, IEEE INFOCOM Sách, tạp chí
Tiêu đề: CHOKe, a Stateless Active Queue Management Scheme for Approximating Fair BandwidthAllocation”
Tác giả: Pan,R, Pabhakar, B, Psounis,K
Năm: 2000
[22] Shan Chen, Zhen Zhou, Brahim Bensaou. (2007), “Stochastic RED and its applacations” ICC 2007 Sách, tạp chí
Tiêu đề: Stochastic RED and its applacations”
Tác giả: Shan Chen, Zhen Zhou, Brahim Bensaou
Năm: 2007

HÌNH ẢNH LIÊN QUAN

Hình 1.3. Mô hình hàng đợi đơn giản trong mạng - Phân tích đánh giá một số thuật toán quản lý hàng đợi tích cực trong TCP Network
Hình 1.3. Mô hình hàng đợi đơn giản trong mạng (Trang 10)
Hình 2.1: Phân loại các phương pháp quản lý hàng đợi tích cực - Phân tích đánh giá một số thuật toán quản lý hàng đợi tích cực trong TCP Network
Hình 2.1 Phân loại các phương pháp quản lý hàng đợi tích cực (Trang 20)
Hình 2.2: ECN Field trong IP header - Phân tích đánh giá một số thuật toán quản lý hàng đợi tích cực trong TCP Network
Hình 2.2 ECN Field trong IP header (Trang 21)
Hình 2.3: ECN bit trong IP header  2.2.1.3. Sự đánh dấu trong TCP header - Phân tích đánh giá một số thuật toán quản lý hàng đợi tích cực trong TCP Network
Hình 2.3 ECN bit trong IP header 2.2.1.3. Sự đánh dấu trong TCP header (Trang 22)
Hình 2.4: Cấu trúc hai trường code field và Reserved field của TCP hearder - Phân tích đánh giá một số thuật toán quản lý hàng đợi tích cực trong TCP Network
Hình 2.4 Cấu trúc hai trường code field và Reserved field của TCP hearder (Trang 23)
Hình 2.5: Sơ đồ hoạt động của WRED - Phân tích đánh giá một số thuật toán quản lý hàng đợi tích cực trong TCP Network
Hình 2.5 Sơ đồ hoạt động của WRED (Trang 25)
Hình 2.6: Cơ chế loại bỏ gói tin của WRED - Phân tích đánh giá một số thuật toán quản lý hàng đợi tích cực trong TCP Network
Hình 2.6 Cơ chế loại bỏ gói tin của WRED (Trang 26)
Hình 2.9: Một mô hình kiến trúc mạng để thực hiện giải thuật DRED - Phân tích đánh giá một số thuật toán quản lý hàng đợi tích cực trong TCP Network
Hình 2.9 Một mô hình kiến trúc mạng để thực hiện giải thuật DRED (Trang 32)
Hình 2.11: Trọng số hàng đợi nwq của giải thuật DRED - Phân tích đánh giá một số thuật toán quản lý hàng đợi tích cực trong TCP Network
Hình 2.11 Trọng số hàng đợi nwq của giải thuật DRED (Trang 35)
Hình 2.14: Ví dụ về SFB  2.3.2. Thuật toán SFED - Phân tích đánh giá một số thuật toán quản lý hàng đợi tích cực trong TCP Network
Hình 2.14 Ví dụ về SFB 2.3.2. Thuật toán SFED (Trang 42)
Bảng trên cũng cho thấy đáp ứng tức thời của thuật toán SAVQ tốt hơn AVQ và - Phân tích đánh giá một số thuật toán quản lý hàng đợi tích cực trong TCP Network
Bảng tr ên cũng cho thấy đáp ứng tức thời của thuật toán SAVQ tốt hơn AVQ và (Trang 46)
Hình 3.1: Mô hình quản lý hàng đợi dùng thuật toán RED. - Phân tích đánh giá một số thuật toán quản lý hàng đợi tích cực trong TCP Network
Hình 3.1 Mô hình quản lý hàng đợi dùng thuật toán RED (Trang 49)
Hình 3.4: Giải thuật RED với “gentle option” - Phân tích đánh giá một số thuật toán quản lý hàng đợi tích cực trong TCP Network
Hình 3.4 Giải thuật RED với “gentle option” (Trang 53)
Hình 3.5: Giải thuật BLUE - Phân tích đánh giá một số thuật toán quản lý hàng đợi tích cực trong TCP Network
Hình 3.5 Giải thuật BLUE (Trang 55)
Hình 3.7 Tỷ lệ mất gói của RED và BLUE - Phân tích đánh giá một số thuật toán quản lý hàng đợi tích cực trong TCP Network
Hình 3.7 Tỷ lệ mất gói của RED và BLUE (Trang 58)

TỪ KHÓA LIÊN QUAN

TRÍCH ĐOẠN

TÀI LIỆU CÙNG NGƯỜI DÙNG

TÀI LIỆU LIÊN QUAN

🧩 Sản phẩm bạn có thể quan tâm

w