PHÁT TRIỂN IP QoS THEO CƠ CHẾ DIFFSERV

Chuyên đề cấp tiến sỹ : PHÁT TRIỂN IP QoS THEO CƠ CHẾ DIFFSERV DiffServ về cơ bản là một lược đồ quan hệ ưu tiên, bằng cách đánh dấu vào trường ToS (Type of Service field) của gói IP và ưu tiên xử lý các gói tùy vào trường này, từ đó hình thành nên các lớp dịch vụ (service class) khác nhau 1. Để nhận các dịch vụ từ nhà cung cấp dịch vụ (Service Provider), người dùng cần phải có hợp đồng mức dịch vụ (Service Level Agreement) với nhà cung cấp dịch vụ. Một SLA về cơ bản là chỉ ra lớp dịch vụ được hỗ trợ và lượng tải cho phép trong mỗi lớp.

BỘ GIÁO DỤC VÀ ĐÀO TẠO TẬP ĐOÀN BCVT VIỆT NAM HỌC VIỆN CÔNG NGHỆ BƯU CHÍNH VIỄN THÔNG ********************************************* NGUYỄN HỒNG SƠN CHUYÊN ĐỀ 2 PHÁT TRIỂN IP QoS THEO CƠ CHẾ DIFFSERV CHUYÊN ĐỀ CẤP TIẾN SỸ Giáo viên hướng dẫn: TS. L Ê H ỮU L ẬP TS. V Ũ NH Ư L ÂN HÀ NỘI 4-2008 2 MỤC LỤC 3 CHUYÊN ĐỀ 2 PHÁT TRIỂN IP QoS THEO CƠ CHẾ DIFFSERV 1.Tổng quan về triển khai DiffServ DiffServ về cơ bản là một lược đồ quan hệ ưu tiên, bằng cách đánh dấu vào trường ToS (Type of Service field) của gói IP và ưu tiên xử lý các gói tùy vào trường này, từ đó hình thành nên các lớp dịch vụ (service class) khác nhau [1]. Để nhận các dịch vụ từ nhà cung cấp dịch vụ (Service Provider), người dùng cần phải có hợp đồng mức dịch vụ (Service Level Agreement) với nhà cung cấp dịch vụ. Một SLA về cơ bản là chỉ ra lớp dịch vụ được hỗ trợ và lượng tải cho phép trong mỗi lớp. Một SLA có thể là tĩnh hay động (static SLA hay dynamic SLA). SLA tĩnh được thỏa ước theo định kỳ từng tháng hay năm. Một SLA động đòi hỏi người dùng phải dùng giao thức báo hiệu để yêu cầu dịch vụ cho từng cuộc gọi. Người dùng có thể đánh dấu vào gói IP để chỉ ra dịch vụ mong muốn và router nội bộ sẽ đánh dấu gói IP trên cơ sở đó. Tại ngõ vào mạng của nhà cung cấp dịch vụ, gói sẽ được phân loại và điều chỉnh theo SLA đã được ký kết. Lượng bộ đệm cần cho các hoạt động này cũng được chỉ ra trong SLA. Khi gói đi từ domain này sang domain khác, trường ToS của nó có thể được đánh dấu lại dựa trên SLA đã ký kết giữa các domain. DiffServ sử dụng các cơ chế phân loại, chỉnh dạng và lập lịch để cung cấp các dịch vụ như: -Premium Service cho các ứng dụng yêu cầu độ trễ và biến động trễ đều nhỏ. -Assured Service cho các ứng dụng yêu cầu độ tin cậy tốt hơn dịch vụ best- effort. -Olympic Service cung cấp bộ ba dịch vụ gồm vàng, bạc và đồng với chất lượng dịch vụ của vàng là tốt nhất và đồng là thấp nhất,[2][3]. Điều lưu ý là DiffServ chỉ định nghĩa các mã DSCP (DiffServ Code Point) ghi trong trường ToS và các PHB. Còn các nhà cung cấp dịch vụ chịu trách nhiệm qui định dịch vụ cụ thể để cung cấp. DiffServ khác nhau đáng kể so với IntServ (Integrated Service). Thứ nhất, nó chỉ có một số giới hạn các lớp dịch vụ được chỉ định. Vì dịch vụ được gán theo lớp nên lượng thông tin trạng thái lớn hay nhỏ là tùy vào số lượng lớp thay vì tùy vào số lượng luồng như IntServ, nhờ đó DiffServ có tính khả triển (scalability) cao. Thứ hai, các hoạt động phân loại, điều chỉnh phức tạp chỉ diễn ra ở biên giới mạng. Các router bên trong domain chỉ cần phân loại các BA (Behavior Aggegate) [9]. Do đó, dễ dàng hiện thực và triển khai DiffServ. Các mạng của nhà cung cấp 4 dịch vụ thường có các router biên (edge router) kết nối với khách hàng và nối với các router bên trong (core router). Core router cần phải chuyển gói đi rất nhanh nên nhiệm vụ của chúng phải đơn giản hơn. Các router biên không cần phải chuyển gói đi rất nhanh vì hầu hết các liên kết với khách hàng đều chậm. Vì vậy các router biên có nhiều thời gian để phân loại và điều chỉnh [4] lưu lượng. Các router biên tại các điểm truy nhập mạng NAP (Network Access Point) là ngoại lệ vì chúng phải chuyển gói đi rất nhanh và còn phải xử lý phân loại và điều chỉnh nên phải được trang bị tốt nhất. Trong mô hình DiffServ có thể gia tăng triển khai dịch vụ đảm bảo (Assured Service). Các router không có khả năng DiffServ sẽ bỏ qua trường ToS của gói Assured Service và chuyển gói dạng này theo dịch vụ Best Effort. Tuy nhiên, vì các gói của Assured Service không bị bỏ rơi tại các DiffServ router nên chất lượng toàn cục của lưu lượng Assured Service vẫn tốt hơn so với lưu lượng của Best Effort. Dịch vụ Assured Service hướng đến các khách hàng cần dịch vụ tin cậy từ nhà cung cấp dịch vụ ngay cả trong trường hợp nghẽn mạng. Khách hàng phải có SLA với nhà cung cấp dịch vụ và SLA sẽ chỉ ra lượng băng thông sẽ cấp cho khách hàng. Khách hàng sẽ chịu trách nhiệm quyết định chia sẻ lượng băng thông này như thế nào cho các ứng dụng của họ. SLA cho Assured Service là tĩnh, có nghĩa là khách hàng có thể bắt đầu truyền số liệu bất cứ lúc nào họ muốn mà không cần báo hiệu cho nhà cung cấp dịch vụ của họ. Assured Service có thể được hiện thực như sau. Đầu tiên, sự phân loại và điều chỉnh được thực hiện tại router ngõ vào (ingress router) của mạng phía ISP (Internet Service Provider). Nếu tốc độ của lưu lượng không vượt quá tốc độ bit được chỉ ra trong SLA thì chúng được xem như phù hợp với profile và ngược lại. Thứ hai, tất cả các gói phù hợp hay không phù hợp đều được đặt vào một hàng đợi để tránh sai thứ tự. Thứ ba, hàng đơi được quản lý bởi một lược đồ quản lý hàng đợi gọi là phát hiện sớm RED (Random Early Detection) [5]. RED có các phiên bản như GRED (generalized RED), RIO (RED with in and out). RED là lược đồ quản lý hàng đợi hủy bỏ gói sớm để ngăn ngừa nghẽn mạng. Điều này sẽ tác động lên cơ chế điều khiển luồng (flow control) TCP tại các đầu cuối khác nhau khiến cho tốc độ truyền sẽ thay đổi. Bằng cách này RED có thể ngăn chặn hàng đợi của router khỏi bị tràn và do đó tránh được động thái bỏ đuôi (tail-drop). Tail-drop tác động lên nhiều luồng TCP khiến chúng giảm tốc và lại tăng tốc một cách đồng thời. Điều này gây ra sự dao động mạnh và có thể ảnh hưởng xấu đến chất lượng mạng. RED đã được triển khai rộng rãi trong các mạng của ISP ngày nay. RIO là một lược đồ cải tiến của RED. Về cơ bản nó giữ lại hai giải thuật chính của RED, một cho các gói phù hợp và một cho các gói không phù hợp. Có hai ngưỡng được chỉ ra trong mỗi hàng đợi. Khi kích thước hàng đợi còn nhỏ hơn mức thứ nhất, không có gói nào bị hủy. Khi kích thước hàng đợi nằm trong khoảng giữa hai 5 ngưỡng, chỉ có gói không phù hợp là bị hủy một cách ngẫu nhiên. Khi hàng đợi vượt quá ngưỡng thứ hai thì cả hai dạng gói đều bị hủy một cách ngẫu nhiên, nhưng gói không phù hợp sẽ bị hủy nhiều hơn. Vì các gói phù hợp bị hủy ít hơn ngay cả khi có nghẽn nên khách hàng sẽ nhận được một dịch vụ có thể dự báo được từ mạng nếu họ giữ lưu lượng đúng theo cam kết. Khi không có nghẽn các gói không phù hợp vẫn được chuyển nên hiệu suất của mạng cao. Dịch vụ Best Effort có thể được xử lý theo cách khác hay tương tự với lưu lượng không phù hợp của dịch vụ Assured Service. Premium Service cung cấp dịch vụ có yêu cầu độ trễ và biến động trễ thấp cho khách hàng nên sẽ đảm bảo truyền với tốc độ đỉnh một cách cố định. Mỗi khách hàng sẽ có một SLA với ISP, trong đó chỉ ra tốc độ đỉnh mong muốn cho một luồng hay một tập hợp nhiều luồng. Khách hàng phải đảm bảo không để vượt quá tốc độ đỉnh đã ký kết, nếu không lưu lượng sẽ bị hủy. Về phía ISP sẽ đảm bảo băng thông theo hợp đồng phải luôn khả dụng cho lưu lượng của khách hàng. Premium Service thích hợp cho điện thoại IP, hội nghị truyền hình hay xây dựng các kênh leased line ảo cho các mạng riêng ảo VPN (virtual private network) [6]. Vì Premium Service đắt tiền hơn Assured Service nên mong muốn ISP cung cấp SLA cả tĩnh và động. SLA động cho phép khách hàng yêu cầu dịch vụ chất lượng cao mà không cần đăng ký. Hoạt động điều khiển chấp nhận kết nối rất cần cho SLA động. Premium Service có thể được hiện thực như sau. Phía khách hàng, vài thực thể truyền thông sẽ quyết định luồng ứng dụng nào sẽ dùng dịch vụ chất lượng cao. Router nối trực tiếp với khách hàng sẻ phân loại và điều chỉnh lưu lượng. Về mặt khái niệm, giả sử có một bit P nào đó trong trường ToS, nếu bit P được cài thì gói thuộc về Premium Service, ngược lại gói sẽ thuộc về các dịch vụ khác. Sau khi chỉnh dạng, bit P của tất cả các gói của luồng được phép dùng Premium Service đều được cài. Router ngõ ra của domain khách hàng có thể chỉnh lại lưu lượng để đảm bảo rằng lưu lượng không vượt quá tốc độ đỉnh được chỉ ra trong SLA. Về phía nhà cung cấp dịch vụ, ingress router sẽ kiểm tra lưu lượng, lưu lượng vượt quá tốc độ sẽ bị hủy. Tất cả các gói với bit P được cài đều được đưa vào hàng đợi ưu tiên cho dịch vụ này. Các gói trong hàng đợi chất lượng cao bao giờ cũng được truyền đi trước. Xử lý truyền được tiến hành theo ba bước: trước tiên, bằng cách điều khiển chấp nhận kết nối lượng lưu lượng chất lượng cao có thể bị giới hạn trong một số phần trăm nhỏ của băng thông liên kết ngõ vào, giả sử 10%. Kế đến, các gói vượt quá bị hủy tại ingress router của mạng. Các luồng không hợp lệ sẽ không thể ảnh hưởng xấu đến phẩm chất của các luồng hợp lệ khác. Sau cùng, các gói chất lượng cao được chuyển đi trước các gói của các lớp khác; chúng có thể dùng 100% băng thông của liên kết ngõ ra. 6 Vì hầu hết các liên kết đều là song công hoàn toàn nên băng thông của liên kết ngõ ra bằng băng thông của liên kết ngõ vào. Do đó, nếu lưu lượng Premium Service được phân phối đều nhau giữa các liên kết thì ba bước trên phải đảm bảo tốc độ phục vụ của hàng đợi Premium Service phải lớn hơn tốc độ đến. Do đó, tốt nhất là các gói Premium Service đến trong điều kiện hàng đợi trống hay phải đợi trong thời gian rất ngắn. Thời gian trễ hay jitter mà gói Premium Service trãi qua phải rất nhỏ. Tuy nhiên, Premium Service lại không đảm bảo giới hạn về định lượng của thời gian trễ và jitter. Sự phân phối lưu lượng Premium Service không đều có thể gây ra vấn đề cho Premium Service. Trong các mạng ISP, sự tập trung lưu lượng từ các router biên đến các core router bên trong là không thể tránh khỏi, nhưng điều này không thành vấn đề vì tốc độ ngõ ra lớn hơn tốc độ ngõ vào rất nhiều. Tuy nhiên, sự tập trung lưu lượng đến core router từ các core router khác thì không thể đảm bảo điều tương tự. Bản thân DiffServ không thể giải quyết được khó khăn này. Công nghệ lưu lượng/định tuyến dựa vào ràng buộc phải được dùng để tránh nghẽn gây ra bởi sự phân phối lưu lượng mất cân đối. Bằng cách hạn chế tổng lượng băng thông được yêu cầu bởi lưu lượng Premium Service, người quản trị mạng có thể đảm bảo lưu lượng của Premium Service không làm suy sụp lưu lượng của các dịch vụ khác. Cách khác là dùng WFQ (Weighted Fair Queuing) [7] giữa hàng đơi của Premium Service và hàng đợi Assured Service. Sau đây là ví dụ về phương thức phân phối tài nguyên tại hai phía khách hàng và ISP. Phân phối tài nguyên tại domain của khách hàng Cho trước một SLA, domain của khách hàng sẽ quyết định cách thức để các host của domain chia sẻ dịch vụ được chỉ định trong SLA. Quá trình này được gọi là sự phân phối dịch vụ. Có hai chọn lựa cơ bản: -Mỗi host tự ra quyết định dùng dịch vụ nào. -Một bộ điều khiển tài nguyên gọi là bandwidth broker (BB) [2] quyết định cho tất cả các host. Một BB có thể là một host, một router hay một phần mềm trên router ngõ ra. BB được cấu hình theo các chính sách tổ chức và quản lý tài nguyên của domain. Mỗi domain cũng có một BB dự phòng. Vì tất cả các host phải cùng chia sẻ lượng tài nguyên có giới hạn được đặc tả bởi SLA nên tốt hơn là phải có một BB để cấp phát tài nguyên. Ở giai đoạn triển khai ban đầu các host không cần cơ chế DiffServ. Chúng chỉ cần truyền các gói không đánh dấu. Router ngõ ra sẽ đánh dấu trước khi chuyển đến ISP. Các gói được xử lý như là dịch vụ Best Effort bên trong domain của khách hàng. Trong giai đoạn triển khai kế tiếp, các host có thể có vài cơ chế báo hiệu hay 7 đánh dấu. Trước khi host truyền gói nó có thể quyết định lớp dịch vụ nào cho gói hay có thể tham vấn BB. Host có thể đánh dấu các gói hay truyền các gói không đánh dấu. Nếu host truyền các gói không đánh dấu thì BB phải dùng vài giao thức như RSVP hay LDAP (Lightweight Directory Protocol) [8] để xác lập các luật phân loại, kiểm tra và chỉnh dạng tại router nối trực tiếp với host sao cho router biết cách đánh dấu các gói truyền. Nếu SLA giữa khách hàng và ISP là động thì BB trong domain của khách hàng phải dùng vài giao thức báo hiệu để yêu cầu tài nguyên từ ISP. Phân phối tài nguyên tại domain của ISP Đối với từng SLA, ISP phải quyết định cấu hình các router biên như thế nào để chúng có thể biết cách kiểm soát lưu lượng đến. Với SLA tĩnh, các router biên có thể được cấu hình bằng tay theo các luật phân loại, kiểm tra và sửa dạng. Do đó, các tài nguyên được phân phối một cách thống kê cho mỗi khách hàng. Các tài nguyên không dùng có thể chia sẻ cho các khách hàng khác. Với SLA động, sự phân phối tài nguyên có quan hệ gần với quá trình báo hiệu. Thành phần BB ở domain khách hàng dùng RSVP để yêu cầu tài nguyên từ ISP. Về phía ISP, các quyết định điều khiển chấp nhận được đưa ra bởi BB ở đó. Nếu các router biên liên quan trực tiếp đến quá trình báo hiệu, chúng được cấu hình theo các luật phân loại, kiểm tra và sửa dạng tương ứng. Nếu BB liên quan đến quá trình báo hiệu chứ không phải router biên, BB phải cấu hình router biên khi chúng phát ra yêu cầu. Trong cả hai trường hợp core router của ISP phải được bảo vệ để tránh vấn đề khả triển (scalability). 2. Phương pháp phát triển hệ thống DiffServ Công việc phát triển một hệ thống DiffServ liên quan đến tổ chức và phát triển hai thành phần chính là bộ điều chỉnh lưu lượng (traffic conditioner) tại router biên (edge router) và các PHB tại các router, đặc biệt là các router bên trong DiffServ domain (core router). Lộ trình của các gói là khi vào edge router sẽ được điều chỉnh lưu lượng cho phù hợp với SLA sau đó được đưa tới giao tiếp ngõ ra của router, tại đó chúng sẽ được định nghĩa PHB (là EF (Expedited Forwarding), AF (Assured Forwarding) hay BE (Best Effort)). Việc này liên quan đến sự phân loại và chuyển gói vào hàng đợi tương ứng. Cách thức kiểm soát các hàng đợi này được chỉ ra bởi cơ chế lập lịch (scheduling mechanism) được dùng. Bộ lập lịch gói chịu trách nhiệm hướng dẫn các gói từ các hàng đợi khác nhau thoát ra khỏi hàng đợi và được truyền lên mạng một cách có trật tự. Bên trong mạng (core network) căn cứ vào các PHB của từng gói mà các router bên trong (core router) sẽ chuyển các gói đi theo cách xử lý cho từng PHB. Như vậy trong phần tử mạng đầu tiên là router biên sẽ được phát triển một bộ điều chỉnh lưu lượng (traffic conditioner) và 8 các PHB. Trong phần tử mạng kế tiếp là các core router chỉ cần phát triển các PHB. 2.1. Phát triển bộ điều chỉnh lưu lượng Như đã mô tả trong [9] bộ điều chỉnh lưu lượng sẽ gồm các thành phần con là classifier, marker, meter, remarker hay shaper hay dropper. Thông thường các thành phần này được hiện thực bằng cách dùng một Token Bucket đơn và một Token Bucket đôi (Dual Token Bucket) [10]. Qua đó các thông số của luồng đã cam kết theo SLA được cấu hình thành một Token Bucket profile. Các gói lấy được token được xem là các gói hợp lệ (in-profile packet) và các gói còn lại là không hợp lệ (out-profile) [11]. Các Token Bucket bảo vệ các luồng với cửa sổ nhỏ, ngăn chặn sự tổn thất gói bằng cách chỉ đánh dấu hợp lệ (in-profile) Hình 1- Cấu trúc luận lý của bộ điều chỉnh lưu lượng 2.2. Phát triển các PHB Sau khi các gói đã đi qua giao tiếp ngõ vào của một router mà không bị hủy sẽ được chèn vào giao tiếp ngõ ra của router. Hàng đợi tại ngõ ra có thể là một hàng đợi đơn giữ tất cả các gói của các lớp lưu lượng hay gồm một số các hàng đợi, mỗi hàng đợi giữ gói cho mỗi lớp lưu lượng khác nhau. Mỗi PHB được thể hiện qua hai cơ chế: cơ chế quản lý hàng đợi và cơ chế lập lịch gói. Cơ chế quản lý hàng đợi Lưu lượng của mỗi user được đánh dấu là in-profile hay out-profile. Các gói in- profile được gán một mức hủy gói (drop precedence) thấp hơn các gói out-profile và đựợc mã hóa bằng mã DSCP (DiffServ Code Point) ghi trong trường ToS (Type of Service) của gói. Nguyên lý quản lý hàng đợi tích cực (Active Queue Classifier Marker Meter Remarker Shaper Dropper 9 Traffic Profile Management) RED (Random Early Detection) được dùng để hiện thực quản lý hàng đợi cho DiffServ. RED cho phép router hủy gói trước khi hàng đợi bị tràn. RED làm được điều này bằng cách hủy các gói theo một xác suất tùy thuộc vào chiều dài hàng đợi trung bình. Để hiện thực các mức hủy (drop precedence) khác nhau hay để hình thành các AFij, nguyên lý hàng đợi gồm nhiều RED gọi là GRED (Generalized RED) được dùng. Nguyên lý RED này và cách áp dụng vào hiện thực DiffServ sẽ được đề cập ở mục kế tiếp. Cơ chế lập lịch gói Có một số cơ chế lập lịch gói có thể được áp dụng bao gồm -FIFO (first In First Out) -PQ (Priority Queuing) -WFQ (Weigh Fair Queuing) -PQWFQ (Priority Queuing with Weighted Fair Queuing), giải thuật này là sự kết hợp của PQ và WFQ như trình bày trên hình 2. Hình 2- Tổ chức của cơ chế lập lịch PQWFQ Lưu lượng ưu tiên cao được chuyển đi với mức ưu tiên cao nhất, bất chấp sự hiện diện của các lưu lượng khác, nhằm hỗ trợ cho các dịch vụ yêu cầu nghiêm ngặt về thời gian thực. Trong DiffServ thì dành cho EF PHB. Những lưu lượng khác gồm AF PHB và BE được lập lịch chuyển đi theo giải thuật WFQ. 3. Hiện thực DiffServ với RED 3.1. Giải thuật phát hiện sớm ngẫu nhiên RED RED được đề xuất vào năm 1993 [12]. Ý tưởng của RED là cung cấp một phản hồi cho nguồn lưu lượng càng sớm càng tốt trước khi hàng đợi bị tràn để chỉ ra P Q WFQ PQWFQ Ưu tiên cao Ưu tiên thấp 10 [...]... hầu hết các triển khai trên thực tế đều bám sát vào kiến trúc này Mỗi nhà cung cấp dịch vụ hay nhà sản xuất thiết bị có chọn lựa kỹ thuật phát triển khác nhau nhưng vẫn có những điểm chung cơ bản Trong đó tại router biên thường dùng các token bucket để thực hiện các chức năng khác nhau của bộ điều chỉnh lưu lượng theo mô hình DiffServ Trong tất cả các router, thuật toán RED được dùng làm cơ chế quản lý... PHB RED được dùng với kỳ vọng là cung cấp một cơ chế tránh nghẽn tốt, đồng thời loại bỏ được nhược điểm đồng bộ của các cơ chế quản lý hàng đợi theo kiểu cắt đuôi (tail drop) nhờ khả năng hủy gói theo xác suất Tuy nhiên, việc xác định tham số cho RED trở nên thiếu thực tế vì gần như rất khó chọn được các tham số RED mà chất lượng mạng không bị ảnh hưởng xấu Theo các phân tích cho thấy để hệ thống dùng... hội tụ về 0 theo hàm mũ Kết quả nghiên cứu trong [22] cho thấy hệ thống điều khiển tuyến tính có + phản hồi trong hình 9 là ổn định đối với tất cả các N ≥ N − và R0 ≤ R nếu Lred và K thỏa Lred ( R + C ) 3 ≤ (2 N − ) 2 2 ωg K2 +1 (16) Trong đó  2N − 1    ω g = 0.1 min  , + + 2 R C R    ( ) (17) 5 Kết luận về hiện thực DiffServ Xu thế triển khai IP QoS hiện nay đều dùng giải pháp DiffServ, hầu... được phát triển trong [18] làm điểm xuất phát để phân tích Phân tích của họ đã đưa ra một số cân nhắc trong việc chọn lựa các tham số cho RED cũng như cung cấp một vài hướng dẫn về thiết kế các hệ thống ổn định tuyến tính và các đại lượng biểu thị tính ổn định và bền vững của hệ thống tuyến tính 4.2 Mô hình luồng động biểu diễn động thái của luồng TCP Trong [18] một mô hình động học của TCP được phát triển. .. dấu gói theo khoảng thời gian đều nhau để tránh hiện tượng phân cực hay đồng bộ toàn cục và đánh dấu gói đủ thường xuyên để kiểm soát kích thước hàng đợi trung bình RED về cơ bản là một nguyên tắc hàng đợi không phân cấp nhằm hạn chế kích thước hàng đợi một cách khôn khéo Các hàng đợi thông thường chỉ hủy gói khi bị đầy chứ không có một động thái tối ưu RED cũng hủy gói theo lối cắt đuôi nhưng theo cách... hàng đợi TCP được tuyến tính hóa theo tín hiệu nhỏ P(s) là Ptcp(s)Pqueue(s) δp và δq lần lượt ký hiệu sự dao động của xác suất tổn thất và chiều dài hàng đợi Trong hình 9 hàm truyền C(s) ký hiệu một chiến lược điều khiển AQM như RED Cắt đuôi (tail-drop) là một chiến lược điều khiển đóng ngắt (on-off) với lượng hủy δp ∈ { 0,1} , theo lý thuyết điều khiển xem đó như cơ chế đóng ngắt gây ra dao động với... TCP, cố gắng điều khiển chiều dài hàng đợi tại các router và cố gắng thông báo nghẽn càng sớm càng tốt để nguồn có những hành động thích hợp Tuy nhiên, đối với DiffServ sẽ không dùng RED theo cách này, thay vào đó là lợi dụng cơ cấu hủy gói theo xác suất để hiện thực các AF class Mỗi AF class cần hỗ trợ ba mức hủy gói (drop precedence) mà sự khác biệt giữa các mức là xác suất hủy gói RED chỉ hỗ trợ... đổi bản chất tự nhiên của cơ chế giảm nhiều lần và chúng ta có thể thu được động học của TCP λi(t) là chỉ dấu của tổn thất mà nguồn nhận được Nó tiếp cận nguồn phát xấp xỉ thời gian một chu trình đi và về RTT (τ) sau khi một gói bị hủy hay bị đánh dấu tại hàng đợi Trong [19] một phương trình vi phân ngẫu nhiên chính xác cho TCP có xét đến trễ do phản hồi đã được nghiên cứu và theo một ngữ cảnh công bằng... - N (1 + e − sR0 ) 2 R0 C R0 C 2 −sR0 e 2N 2 N R0 1 s+ q 1 δ R0 Động học hàng đợi δp Điều khiển cửa sổ Hình 5-Sơ đồ khối của kết nối TCP được tuyến tính hóa Trong [20] một mô hình cho cơ chế điều khiển cửa sổ được phát triển và cho rằng có chứa một cấu trúc điều chỉnh Smith trong đó Tuy nhiên, mô hình trong [16] và hình 5 không hỗ trợ điều này Thật sự, đối với điều khiển TCP trong hình 5 để tác động... cho hàng đợi có thể lớn 3.2 Dùng RED trong hiện thực DiffServ Bản chất tự nhiên của RED rất thích hợp cho thực hiện vài động thái khác thay vì chỉ là cảnh báo nghẽn sớm Vì RED có thể hủy gói một cách ngẫu nhiên theo thông số xác suất có được qua thao tác cấu hình, nên có thể được dùng để hiện thực động thái AF (Assure Forwarding behavior) trong DiffServ Như trong [9] đã đặc tả, trong một lớp AF còn . đơn giản sau s 1 )1( 0 2 0 sR e CR N − + 0 R N 0 1 1 R s + 0 2 2 0 2 sR e N CR − W δ q δ δp - - Động học hàng đợi Điều khiển cửa sổ 19 )( 1 )()( )( 2 )( 2 )( 00 0 2 2 0 2 0 tq R tW R N tq Rtp N CR tW CR N tW δδδ δδδ −= −−−= • • ( 12) như. trễ hành trình (round trip delay) mà thiết kế có thể chịu để CR N s N CR 2 0 2 2 0 2 2 + 0 0 1 R s R N + 0 sR e − δW δq δp - Động học hàng đợi Điều khiển cửa sổ 20 . cho N CR Wq pWW 0 0 0 2 0 0 20 =⇒= =⇒= • • (10) Trong đó p T C q R += 0 . 0 Giả sử N(t) ≡ N và R(t) ≡ R 0 là hằng số, tuyến tính hóa (9) về điểm hoạt động ta có )( 1 )()( )( 2 ))()(()( 00 0 2 2 0 0 2 0 tq R tW R N tq Rtp N CR RtWtW CR N tW δδδ δδδδ −= −−−+−= • • (11) Trong