3.9.1. Đặc điểm của XCP
XCP (eXplicit Control Protocol) là một giao thức điều khiển chống tắc nghẽn đƣợc phát triển bởi Dina Katabi của MIT [KHR02]. XCP đƣợc phát triển nhằm cải tiến giải thuật điều khiển tắc nghẽn trong TCP, đặc biệt trong môi trƣờng mạng tốc độ cao nhƣ hiện nay.
Sự ra đời của XCP đƣợc đánh giá là một sự tiến bộ quan trọng trong điều khiển chống tắc nghẽn trên mạng IP. Giao thức điều khiển chống tắc nghẽn XCP là khái quát hóa các đề xuất trong Explicit Congestion Notification (ECN). Thay vì một bít thông báo tắc nghẽn sử dụng trong ECN, XCP đề xuất sử dụng báo hiệu tắc nghẽn rõ, mạng thông báo cho phía gửi về tình trạng tắc nghẽn trong mạng và cách thức phản ứng lại với tắc nghẽn. Nếu TCP sử dụng giải thuật AIMD (đáp ứng chậm nhƣng hội tụ đến sự công bằng) đề điều chỉnh tốc độ gửi gói tin thì XCP sử dụng giải thuật MIMD với đáp ứng nhanh và mức độ sử dụng cao hơn.
Giống nhƣ TCP, XCP là một giao thức điều khiển tắc nghẽn dựa trên cửa sổ. Phía gửi duy trì cửa sổ tắc nghẽn cwnd, RTT và thông tin tới bộ định tuyến thông qua một tiêu đề tắc nghẽn trong mỗi gói tin. Phía gửi sử dụng trƣờng phản hồi trong tiêu đề tắc nghẽn để điều chỉnh kích thƣớc cửa sổ. Bộ định tuyến giám sát tỷ lệ lƣu lƣợng đầu vào so với mỗi hàng đợi đầu ra. Trên cơ sở sự khác nhau giữa băng thông liên kết và lƣu lƣợng đầu vào, bộ định tuyến sẽ thông báo cho các luồng dữ liệu để tăng hoặc giảm cửa sổ tắc nghẽn. Thông tin phản hồi đƣợc phân chia giữa các luồng trên cơ sở các cửa sổ tắc nghẽn và RTTs nên hệ thống sẽ hội tụ đến sự cân bằng. Khi thông tin phản hồi đến phía nhận, nó sẽ đƣợc gửi trở lại phía nhận thông qua báo nhận gói tin ACK và phía gửi sẽ cập nhật cửa sổ tắc nghẽn cwnd một cách phù hợp. Phía nhận XCP tƣơng tự nhƣ trong TCP chấp nhận khi thực hiện báo nhận gói tin, nó sẽ sao chép tiêu đề tắc nghẽn vào báo nhận của nó.
XCP là một thiết kế đồng thời giữa của hệ thống đầu cuối và các bộ định tuyến, khác so với thiết kế end – to – end của TCP hay hop – by – hop của IP. Dữ liệu điều khiển tắc nghẽn trong XCP đƣợc đƣa vào phần tiêu đề gọi là tiêu đề tắc nghẽn (congestion header). XCP đƣa vào một phần tiêu đề 20 byte giữa lớp mạng và lớp truyền tải để mang thông tin về băng thông đề nghị của ngƣời gửi và thông tin mà các bộ định tuyến cho phép. XCP yêu cầu tất cả các bộ định tuyến và các máy chủ trong mạng sử dụng giao thức XCP để làm việc. Các bộ định tuyến XCP không phân biệt giữa các luồng dữ liệu khác nhau nhƣng có sự điều chỉnh trên mỗi gói tin riêng.
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
Protocol Length Version Format Unused
X RTT
Reserse_Feedback Delta_Throughput
Hình 3. 12. Định dạng tiêu đề XCP
Protocol (giao thức) : 8 bit
Trƣờng này biểu thị mức giao thức kế tiếp đƣợc sử dụng trong phần dữ liệu của gói tin. Giá trị cho các giao thức khác nhau đƣợc định nghĩa bởi IANA.
Length (độ dài): 8 bit
Trƣờng này biểu thị độ dài của tiêu đề tắc nghẽn đơn vị bằng byte. Chiều dài của phiên bản của XCP luôn là 20 byte hoặc 0x14.
Version: 4 bits
Trƣờng này biểu thị phiên bản của XCP đang sử dụng. version của XCP miêu tả trong tài liệu này có giá trị là 0x03. Các giá trị này đƣợc thiết kế do IANA
Trƣờng này bao gồm một mã để xác định định dạng tiêu đề tắc nghẽn. Hai định dạng đƣợc miêu tả tại thời điểm này: định định dạng chuẩn (standard format) và định dạng tối thiểu (minimal format).
Mã định dạng hiện nay đƣợc xác định trong Bảng 3.3 sau:
Bảng 3. 2. Mã định dạng trong tiêu đề tắc nghẽn
Format Code
Standard Format 0x1
Minimal Format 0x2
Định dạng chuẩn (Standard format): bao gồm X, Delta_throughput và trƣờng RTT. Định dạng này đƣợc sử dụng bởi XCP trong luồng dữ liệu từ nơi gửi đến nơi nhận.
Định dạng tối thiểu (Minimal Format): Các trƣờng X, Delta_Throughput và RTT không đƣợc sử dụng nên đƣợc thiết lập giá trị bằng 0. Một bộ định tuyến không phải thực hiện bất kỳ xử lý nào trong tiêu đề định dạng tối thiểu. Tiêu đề này đƣợc đề nghị sử dụng trong các gói ACK, để trả lại thông tin tắc nghẽn trừ phía nhận đến phía gửi.
Unused (chƣa sử dụng): 8 bit
Trƣờng này không đƣợc sử dụng và phải thiết lập giá trị bằng 0 trong phiên bản này của XCP.
RTT (thời gian khứ hồi): 32 bit
Trƣờng này biểu thị vòng lặp thời gian đo bởi ngƣời gửi, trƣờng này là một số nguyên không dấu.
X: 32 bits
Trƣờng này biểu thị khoảng thời gian giữa các gói của luồng và đƣợc tính toán bởi phía gửi.
Throughput: 32 bit
Trƣờng này biểu thị thông lƣợng hiện hành, cwnd/RTT, đƣợc đo bởi ngƣời gửi các đơn vị đƣợc tính theo kbps(kbyte/s).
Trƣờng này biểu thay đổi thông lƣợng theo yêu cầu hay thông lƣợng cấp phát. Đo bởi byte/s.
3.9.2. Nguyên tắc hoạt động
Quá trình gửi các gói tin: Ngƣời gửi chịu trách nhiệm duy trì hai tham
số: một ƣớc lƣợng hiện hành của vòng lặp thời gian RTT tới ngƣời nhận và một cửa số chống tắc nghẽn, cwnd. Ngƣời gửi có thể duy trì một thông lƣợng yêu cầu và một lƣợng yêu cầu tăng lên của thông lƣợng. Thông lƣợng yêu cầu có thể đƣợc hiểu bởi một ứng dụng qua một API hoặc tốc độ của giao diện cục bộ. Ngƣời gửi có thể chọn sử dụng một giá trị hợp lý nào đó cho thông lƣợng yêu cầu. Lƣợng yêu cầu tăng lên của thông lƣợng có đƣợc chính là do sự khác nhau của thông lƣợng hiện hành và thông lƣợng yêu cầu. Nếu ngƣời gửi không có dữ liệu để gửi tăng cửa sổ hiện hành cwnd thì lƣợng tăng thông lƣợng yêu cầu bằng 0.
Khi gửi một packet, ngƣời gửi điền vào trong các trƣờng trong header chống tắc nghẽn nhƣ sau:
Trƣờng Throughput thiết lập giá trị thông lƣợng hiện hành. Giá trị này đƣợc tính nhƣ sau: w ( ) ( ) c nd byte RTT ms (3.12)
Thông lƣợng hiện hành có giá trị bằng 0 khi chƣa biết RTT. Có nghĩa là các gói tin đầu tiên trong một dòng sẽ sử dụng dung lƣợng mà nó không kiểm tra qua các thuật toán điều khiển của bộ định tuyến. Từ đó nó chỉ yêu cầu một vòng lặp đơn của một gói tin cho mỗi dòng để xác định một giá trị ƣớc lƣợng của RTT.
- Trƣờng RTT đƣợc thiết lập giá trị vòng lặp thời gian hiện hành và nó có giá trị bằng 0 nếu vòng lặp chƣa đƣợc phát hiện.
- Trƣờng Delta_throughput thiết lập giá trị lƣợng tăng thông lƣợng yêu cầu.
Lƣợng tăng thông lƣợng yêu cầu này đƣợc phân phối cho tất cả các packet đƣợc gửi trong một vòng lặp thời gian RTT. Trƣờng Delta_throughput của mỗi packet có giá trị nhƣ bằng thông lƣợng yêu cầu trừ đi thông lƣợng hiện hành trƣớc đó (thông lƣợng hiện hành này đƣợc có giá trị bằng cwnd/RTT): Do đó công thức tính cụ thể nhƣ sau:
w *1024 / _ w / d T c nd RTT Delta throughput c nd MSS (3.13) Trong đó: d
T : Thông lƣợng yêu cầu (byte/s).
MSS: kích thƣớc dữ liệu lớn nhất có đơn vị là byte
RTT: có đơn vị là ms
cwnd: đơn vị là byte
Trong trƣờng hợp nếu dữ liệu thiếu thông tin cwnd hiện hành,
Delta_throughput sẽ thiết lập giá trị bằng 0 tức là không có lƣợng thông lƣợng yêu cầu nào đƣợc tăng lên.
Xử lý thông tin phản hồi tại ngƣời nhận: Ngƣời nhận XCP chịu trách
nhiệm sao chép dữ liệu Delta_throughput trên các gói tin gửi đến vào trong trƣờng Reverse_feedback của các gói tin phản hồi.
Xử lý thông tin tại bộ định tuyến: Công việc của một bộ định tuyến
XCP là tính toán giá trị thông tin phản hồi để hệ thống đƣa ra một hiệu lực tối ƣu nhất và công bằng nhất. Do đó XCP không có các gói tin bị loại bỏ. Nó hoạt động trên các kỹ thuật xử lý hàng đợi nhƣ Droptail, RED hoặc AVQ. Dựa vào tính toán thông tin phản hồi, một bộ định tuyến XCP sử dụng một điều khiển công bằng và một điều khiển hiệu lực. Cả hai ƣớc lƣợng tính toán này thực hiện trên toàn bộ các vòng lặp thời gian trung bình (RTT) của các luồn trên đƣờng liên kết. Các điều khiển XCP tạo dựng một điều khiển đơn quyết định mọi RTT trung bình (bộ điều khiển thời gian). Đây là một thúc đẩy quan trọng bởi cần thiết theo dõi kết quả của quyết định điều khiển trƣớc đó trƣớc khi thử một điều khiển mới. Ví dụ, nếu bộ định tuyến báo hiệu cho nguồn tăng lên kích thƣớc cửa sổ của chúng, nó sẽ chờ đợi để thấy bao nhiêu băng thông dƣ thừa trƣớc khi gọi nguồn tăng lên lần nữa. Bộ định tuyến duy trì một điều khiển ƣớc lƣợng thời gian cho mỗi đƣờng liên kết đƣợc thiết lập bởi ƣớc lƣợng gần nhất của giá trị trung bình RTT trên đƣờng liên kết này.
Trong khoảng thời gian Timeout, bộ định tuyến cập nhập ƣớc lƣợng của nó và quyết định điều khiển của nó.
Điều khiển hiệu lực (Efficiency Controller):
Điều khiển hiệu lực mục đích tận dụng đƣờng liên kết tối đa nhất và tỷ lệ thất lạc thông tin thấp nhất. Nó chỉ chú ý đến lƣu lƣợng chung mà không quan
tâm đến kết quả công bằng. Do điều khiển hiệu lực chỉ tính toán cho các hành động chung mà không điều khiển sự thay đổi cửa sổ tắc nghẽn của từng luồng do đó yêu cầu có một sự cấp phối băng thông hợp lý giữa mỗi luồng.
Điều khiển công bằng (Fairness Controller):
Công việc của điều khiển công bằng là phân chia giá trị thông tin phản hồi tới từng gói tin riêng lẻ nhằm đạt đƣợc sự công bằng hợp lý nhất. Điều khiển công bằng dựa trên nguyên tắc của TCP dùng hội tụ tới công bằng. Cụ thể là thuật toán tăng công giảm nhân (AIMD). Ƣớc tính giá trị thông tin phản hồi cho mỗi gói tin cho phép điều khiển công bằng có hiệu lực.
Trƣờng hợp giá trị thông tin phản hồi chung là tích cực, trong trƣờng hợp này lƣợng thông lƣợng tăng lên ở tất cả các luồn là bằng nhau do đó sự thay đổi thông lƣợng của luồn thứ i bất kỳ cũng tăng một lƣợng tƣơng ứng. Điều chỉnh sự thay đổi trong cửa sổ chống tắc nghẽn tốt hơn điều chỉnh thay đổi trong thông lƣợng. Sự thay đổi kích thƣớc cửa sổ trong luồn i là sự thay đổi bởi thông lƣợng của nó nhân với RTT của luồng. Do đó sự thay đổi kích thƣớc cửa sổ chống tắc nghẽn của luồn sẽ tỷ lệ với RTT của luồng.
Xử lý thông tin phản hồi tại ngƣời gửi: Khi các gói tin đƣợc ngƣời nhận
gửi quay trở lại ngƣời gửi. Ví dụ: sự đáp lại của TCP, cwnd của ngƣời gửi đƣợc cập nhật các thông tin trong trƣờng Reverse_feedback theo công thức:
cwnd= max (cwnd + feedback*RRT*g1, MSS) (3.14)
Trong đó:
cwnd: cửa số chống tắc nghẽn hiện hành.
feedback: Trƣờng Reverse_feedback từ ngƣời nhận (có thể + hoặc -)
RTT: ƣớc lƣợng vòng lặp thời gian hiện thời.
g1: Thừa số chuyển đổi: có giá trị bằng 0.001s/ms
Khi một cwnd hiện hành không đƣợc sử dụng, XCP sẽ giảm bớt nó khi đã lỗi thời để tránh sự đột ngột xuất hiện của dữ liệu trong mạng khi ứng dụng khởi động dữ liệu là chậm. Katabi đƣa ra một thuật toán để giải quyết vấn đề này. Mỗi RTT mà ngƣời gửi không sử dụng cwnd để gửi đi thì cwnd sẽ đƣợc tính lại theo công thức:
cwnd = max (0.5 ( cwnd - k ), MSS). (3.15) Trong đó k là số byte trƣớc đây chƣa gửi đƣợc.
3.9.3. Tính thực tế của XCP
Thực hiện XCP trong hệ thống đầu cuối là tƣơng đối đơn giản. Chỉ thay đổi 1 ít trong mã nguồn của TCP phía gửi và TCP phía nhận để làm cho chúng có khả năng XCP. Trang bị bộ định tuyến với khả năng XCP khá tốn kém, sự phức tạp của XCP trong bộ định tuyến là tƣơng đối cao. Tuy nhiên, XCP là ứng cử đầy hứa hẹn trong việc cải thiện điều khiển chống tắc nghẽn trong mạng cơ sở IP trong tƣơng lai.
XCP có thể phát triển một cách nhanh chóng trong mạng cơ sở IP. Hai trƣờng hợp đƣợc phân biệt thành;
- Vài bộ định tuyến và phía nhận không có khả năng XCP.
- Sự kết hợp kết nối XCP và không XCP cùng tồn tại trong mạng.
Trong trƣờng hợp đầu tiên, XCP phía gửi phải kiểm tra rằng tất cả các bộ định tuyến trong đƣờng truyền và phía nhận có khả năng XCP. Điều này có thể thực hiện với cơ cấu XCP và IP hiện hành. Nếu chúng không có khả năng XCP, XCP phía gửi không thể sử dụng giao thức XCP và phải chuyển mạch sang giao thức truyền thông theo lối cổ truyền, chẳng hạn, TCP. Trong trƣờng hợp thứ 2, bộ định tuyến có khả năng XCP phải đƣợc xử lí bình đẳng 2 loại lƣu lƣợng. Để thực hiện, bộ định tuyến có khả năng XCP có thể phân biệt giữa lƣu lƣợng XCP và không XCP và xếp hàng chúng một cách tách biệt. Nó có thể thực hiện đƣợc với cơ cấu xếp hàng chờ xử lý cân bằng thích nghi động theo phƣơng pháp TCP- Friendly Rate Control (TFRC).