Thực tế cho thấy xcp hoạt động rất kém trong môi trường có các nonfxcp router. Do đó ta xét một phiên bản mở rộng của XCP gọi là XCPfi trong kịch bản này.
Thuật toán XCPfi giới thiệu hai dòng hàm chính: một là phát hiện ra khi một XCP packet đã đi xa thông qua một đám mây nonfXCP hai là đưa vào trong trương mục (acount)của băng thông sẵn có trong đám mây nonfXCP giá trị ước tính phản hồi.
5.1.1 Cấu trúc và thuật toán của XCPEi trong các router .
5.1.1.1 Sự phát hiện các nonfXCP cloud: XCPfi nhận diện các nonfXCP bằng cách sử dụng TTL counter. Yêu cầu của XCPfi là đòi hỏi tất cả các router trên mạng hổ trợ các hoạt động TTL bình thường, khi một XCP packet gặp một nonfXCP giá trị TTL couter bị giảm. sau đó thêm vào một trường mới trong XCP packet header (tách biệt với ID header) tên là xcp tll, trường này chỉ giảm bởi duy nhất các router XCPfi. TTL và xcp tll có giá trị ban đầu bởi người gửi và có giá trị bằng nhau. Trên đường truyền cùng một mạng allfXCPnetwork, TTL và trường xcp tll luôn có giá trị giống nhau. Khi một router XCPfi nhận một packet cùng với trường TTL nhỏ hơn trường xcp tll, nó có thể kết luận packet đã đi thông qua một non –XCP cloud. Sau khi xử lý gói tin, router XCPfi sẽ cập nhật xcp tll = TLL để ẩn dấu nonfXCP cloud này khi tới các router XCPf i khác và nhận diện các nonfXCP cloud mới nếu chúng có mặt trên đường truyền dữ liệu. Giải pháp đơn giản này, không đòi hỏi một thông điệp đặc biệt nào giữa các router và các xử lý liên quan là rất nhỏ.
5.1.1.2 Nhận diện các router đỉnh XCPfi( XCPfi adge).
Khi một nonfXCP cloud được phát hiện bởi một router XCPfi, XCPfi yêu cầu nhận dạng của router XCPfi trước đó mà nonfXCP cloud này đã được biết. Mục đích XCPfi sẽ sau đó cố gắng xác định băng thông sẵn có giữa 2 router XCPfi có vị trí là hai đỉnh của nonfXCP cloud. Để mà tìm hiểu theo hướng ngược lại router đỉnh XCPfi, thêm vào một trường mới trong XCP packet header tên là Last xcp router mục đích chứa đựng địa chỉ IP của router XCPfi xử lý XCP packet gần nhất. XCPfi router sẽ dễ dàng đặt giá trị IP của nó trong trường này trước khi gửi packet. Trên con đường này,
khi một nonfXCP cloud được nhận biết bởi một XCPfi couter, router này tự động hiểu XCPfi router nào nằm ở đỉnh đối diện với nó qua nonfXCP cloud. Giải pháp này đơn giản và không phụ thuộc vào thông điệp đặc biệt nào giữa các XCPfi router và CPU sử dụng cho xử lý thêm vào trường này giữ ở nhỏ nhất.
5.1.1.3 Xác định băng thông “cổ chai”.
Xét XCPfikf1 và XCPfik là hai router đỉnh của nonfXCP cloud. Thiết kế một quy trình băng thông ước lượng tại router XCPfikf1. Khi đó XCPfik gửi một yêu cầu tới XCPfikf1 và chờ đợi một tin báo nhận của yêu cầu đó trong một kỳ hạn thời gian Xcp req timout. Nếu tin báo nhận này không đến thì quy trình sẽ khởi động lại từ đầu. Sau ba lần yêu cầu không có kết quả, XCPfik kết thúc và đường giữa XCPfik và XCPf ikf1 bị phá vỡ. Quy trình băng thông ước lượng sẽ chỉ khởi động lại khi thu nhận một gói mới từ XCPfikf1. Bây giờ, trong khoảng nhận một yêu cầu, XCPfikf1 sẽ chấp nhận yêu cầu và cố gắng tìm giá trị băng thông hiệu lực,BWkf1,k ở giữa XCPfikf1 và XCPfik. Nhiều thuật toán được đề xuất để giải quyết việc này (ví dụ: packet pair, paket train,…). Sau khi thu được băng thông BWkf1,k, XCPfikf1 sẽ gửi nó tới XCPfik và sẽ thêm một trương mục (acounter) vào trong một bảng băm cơ sở (hash table based ) trên địa chỉ IP của XCPfikf1 sau đó ghi lại băng thông hiệu lực giữa XCPfikf1 và XCPfik. Sau đó quy trình băng thông ước lượng sẽ thi hành một cách định kỳ nhất định. Quy trình này sẽ ngừng sau một thời gian XCPfikf1 kém hoạt động và tương ứng với một trương mục (entry) trong hash table bị xoá giữ cho bảng băm nhỏ tới mức có thể. Chú ý rằng, quan trọng ở chổ XCPfik dự trữ băng thông hiệu lực còn XCPfikf1 thì không,bởi vì XCPfikf1 không có khả năng phân biệt giữa các dòng đi xuyên suốt nonf XCP cloud tới XCPfik.
5.1.1.4 XCPfi router ảo
Khi XCPfik nhận một packet đi qua một nonfXCP cloud, và nếu một mục nhập hiệu lực BWkf1,k tồn tại trong bảng băm, XCPfik sẽ sử dụng một couter ảo, XCPivk tới xử lý một giá trị thông tin phản hồi và phản chiếu điều kiện trong nonfXCP cloud. Mục đích của router ảo là mô phỏng một XCP router cùng với đường link ảo kêt nối từ XCPfik có dung lượng là băng thông hiệu lực tìm thấy trong nonfXCP cloud. Hình 3 cho thấy cấu trúc hợp lý của XCPik router cùng với một router ảo cho mỗi nonfXCP cloud. Chúng ta có thể thấy router ảo như một thực thể hợp lý thay thế cho nonfXCP cloud. Công thức cho tính toán giá trị thông tin phản hồi trong XCPiv:
Quy tắc cho bố trí α và β giống như cho XCP. Rtt và Q theo thứ tự là RTT trung bình và kích thước hàng đợi liên tục trong XCPfi router nơi chứa đựng các router XCPi ảo. Trong công thức (1) BWkf1,k thay thế S trong công thức cũ của XCP cho nên router ảo không cần biết số lượng giá trị lưu lượng đầu vào.
Một router XCP"i cùng với một router ảo cho mỗi non"XCP cloud.
5.1.2 XCPEi, cấu trúc trong endEhosts
Triển khai không đối xứng, hoạt động tốt ở xung quanh người nhận
Một triển khai của XCP là cả nguồn hoặc đích hay cả hai không kết nối trực tiếp với một XCP router.
Ví dụ ở hình trên cho ta thấy một kịch bản phát triển không đối xứng: Các XCPfi router được triển khai xung quanh người nhận và một nonfXCP cloud triển khai gần người nhận. Trong trường hợp này, một số bộ phận của thuật toán phải được sự hổ trợ của endfhosts. Nếu vị trí của XCPfi nằm bên cạnh người nhận (hình 4). Người gửi phải có khả năng tạo dựng một quy trình băng thông ước lượng trong lúc tiếp thu một yêu cầu từ XCPfi trước đó trên đường truyền. Khi XCPfi router có vị trí bên cạnh người gửi, người nhận có thể hành động giống như một XCPfi router bằng cách thực thi cả hai nonfXCP cloud phát hiện được và tính toán thông tin phản hồi hoặc nếu không sử dụng giải pháp này thì có thể đòi hỏi XCPfi router gần đây nhất thực thi một giá trị thông tin phản hồi tương ứng tới giá trị của nonfXCP cloud “cổ chai”.
5.2.1 Triển khai phát triển xung quanh các nonEXCP cloud
Kịch bản đầu tiên của XCPfi kiểm tra bao gồm một triển khai phát triển đối xứng 2 XCP cloud được kết nối với nhiều XCP router. Hình 3 cho thấy cwnd ở người gửi và thông lượng của người nhận. Như kết quả mô phỏng cho thấy cwnd và thông lượng đều cho kết quả ổn định và giống hệt nhau khi so sánh với kịch bản allfXCP. Mặc dù không nhìn thấy thời gian timeout hay packet bị thất lạc, router XCPfi ảo trong R1 và R2 cho thấy băng thông sẵn dùng trong nonfXCP cloud do đó tính toán được giá trị thông tin phản hồi tối ưu nhất. Kết quả này cho thấy XCPfi có đạt được hiệu quả trong mạng hỗn tạp.
Cwnd và thông lượng trong triển khai phát triển
5.2.2 Kịch bản phân nhánh: 1 nonEXCP cloud phục vụ n đường XCP
Trong kịch bản này: hình 11 cho thấy một cấu trúc mạng cùng với một nonf XCP cloud kết nối với 2 đường XCP. Hình 12 cho thấy XCP một lần nữa chia sẽ công bằng 50 Mb đường link thành 25 Mb cho mỗi dòng.
cwnd và thông lượng trong mạng phân nhánh
5.2.3 Sự không ổn định của ước lượng băng thông
Thực tế cho thấy băng thông ước lượng được tìm thấy bởi các router không hoàn toàn chính xác. Có thể xem ở các hình dưới. Tăng dung lượng tất cả các đường link lên 10 lần để so sánh giữa XCPfi với TCP trên mạng đường truyền tốc độ cao và với băng thông sẵn dùng là không đúng với thực tế. Đánh giá ngẫu nhiên băng thông hiệu lực cao hơn hoặc thấp hơn một giá trị 10% hoặc 20%.
a) Thông lượng cho TCP b) XCP"i " Sender i "10%
c) Thông lượng cho XCP"i – Sender i – 10%
e) Thông lượng cho XCP"i – Sender j – 20%
f) Packet bị bỏ rơi XCP"i"20%
Các hình trên cho thấy thông lượng cho người gửi thứ i và j là chính xác và ước lượng băng thông hiệu lực, nhìn vào hình b) có thể thấy TCP không có năng lực trong việc thiết lập giá trị ước lượng băng thông hiệu lực đường link ”cổ chai” dung lượng là 300Mbps và 100Mbps người gửi i và j gửi lần lượt được là 327Mbytes và 172Mbytes trong 20s. Trong khi đó XCPfi với 10% và 20% ước lượng lỗi vẫn thực thi tốt, người gửi i và j gửi lần lượt là 690Mbytes và 182Mbytes với 10% lỗi, 590Mbytes và 187Mbytes với 20% lỗi. Nếu làm một so sánh giữa XCPfi với 0% lỗi (ước lượng là chính xác) người gửi i và j sẽ lần lượt gửi được là 670 Mbytes và 244 Mbytes.
Kết quả chính của sự đánh giá băng thông hiệu lực chính xác là các packet bị bỏ rơi và các thời gian timeout. Có thể nhận thấy ở hình c) ở trường hợp này, băng thông ước lượng luôn cao hơn kết quả băng thông hiệu lực thực tế.
5.3 Một số phương pháp điều khiển chống tắc nghẽn mới
Một số phương pháp điều khiển chống tắc nghẽn mới được đề xuất trên cơ sở cải tiến các phương pháp truyền thống, cụ thể ở đây:
5.3.1 Phương pháp EWA và FEWA
Phương pháp EWA (Explicit Window Adaptation) dùng thông báo một cách rõ ràng đến phía gửi về băng thông còn khả dụng của các đường ra bằng cách sử dụng cơ chế điều khiển lưu lượng giống như trong TCP để truyền thông tin phản hồi từ các bộ định tuyến đến phía gửi. Bên trong bộ định tuyến EWA thông tin phản hồi được tính toán định kỳ dựa trên đánh giá dung lượng rỗi hiện tại của hàng đợi
trong bộ định tuyến nhân với một biến α. α tuỳ thuộc vào giá trị khởi tạo và kích thước hàng đợi hiện tại.
Công thức tính như sau:
Sending window = max {MSS, α.log2 (B"Qi).MSS}
và được điều khiển theo thuật toán AIMD. EWA. Phương pháp này cho các kết quả hoạt động tốt trong các bộ định tuyến có tải lớn, nhưng có một số vấn đề trong các bộ định tuyến hoạt động ở dưới mức tải trong hầu hết thời
gian. Lý do nằm ở việc tính toán α, nó đặt quá nhiều vào trọng tải trước đó của bộ định tuyến, vì vậy không thể phản ứng lại đủ nhanh đối với những thay đổi lớn của các điều kiện tải.
Chính vì hạn chế đó EWA mờ (FEWA – Fuzzy EWA) đã phát triển, khác với EWA cũ chủ yếu ở việc tính toán α. FEWA sử dụng một bộ điều khiển mờ để tính α dựa theo giá trị hiện tại và một giá trị gần nhất của bộ đệm bộ định tuyến. Với các thay đổi này trong việc tính toán phản hồi bên trong bộ định tuyến, hiệu suất từ đầu cuối đến đầu cuối có thể đạt được lớn hơn so với EWA.
5.3.2 Phương pháp ETCP
Ý tưởng của ETCP (Enhanced TCP) là sử dụng phản hồi FEWA (dựa trên sự thích ứng với cửa sổ điều khiển lưu lượng f AWND) để tính cửa sổ gửi mới (SWND). ETCP phía gửi không thực hiện chu trình bắt đầu chậm (slow start) và chống tắc nghẽn (congestion avoidance), mà bắt đầu với một cửa sổ
gửi khởi tạo và cập nhật cửa sổ gửi theo các cách sau:
Nếu cửa sổ gửi hiện tại lớn hơn cửa sổ điều khiển lưu lượng thì cửa sổ gửi mới được thiết lập bằng cửa sổ điều khiển lưu lượng: SWND ← AWND.
Nếu cửa sổ gửi hiện tại nhỏ hơn cửa sổ điều khiển lưu lượng thì cửa sổ gửi được tính như sau:
SWND←SWND.(AWND/SWND)1/SWND
Với tính toán này cửa sổ gửi của phía gửi ETCP được tăng theo hàm mũ để tiệm cận với cửa sổ điều khiển lưu lượng. Với các thay đổi nhỏ này có thể thu được sự cải thiện đáng kể về khả năng thực hiện.
Phân bổ băng thông hợp lý cho TCP (FBAfTCP) (Fair Bandwidth Allocation for TCP) là một phương pháp điều khiển lưu lượng TCP dựa trên thông tin phản hồi về mạng được cung cấp bởi CSFQ (CorefStateless Fair Queueing). CSFQ nhằm mục đích đạt được một sự phân bổ băng thông hợp lý trong bộ định tuyến mà không yêu cầu sự tính toán cho mỗi luồng hoặc trạng thái mỗi luồng trong bộ định tuyến lõi của một miền CSFQ. Sự tính toán trên mỗi luồng và trạng thái được giới hạn bởi các bộ định tuyến nằm ở biên, nó ước lượng tốc độ đến của mỗi luồng đưa vào miền, và dán nhãn thông tin này vào mỗi gói. Các bộ định tuyến lõi tính toán băng thông hợp lý chia sẻ cho tất cả các luồng dựa trên tốc độ đến và chuyển tiếp. Các gói mà nhãn của nó chỉ ra tốc độ luồng vượt quá sự chia sẻ băng thông hợp lý sẽ bị xoá gói.
Trong kiến trúc của CSFQ, các bộ định tuyến nằm ở biên sẽ xoá các nhãn khỏi các gói khi mà chúng rời khỏi miền CSFQ. FBAfTCP sao chép nhãn vào mào đầu IP, vì thế giữ giá trị chia sẻ hợp lý ở biên của miền CSFQ và chuyển chúng trên tất cả các đường tới đầu cuối. Dựa trên thông tin này, FBAfTCP phía nhận cung cấp phản hồi đến phía gửi bằng cách thiết lập kích thước cửa sổ thông báo để giá trị chia sẻ hợp lý và thời gian vòng truyền (RRT). Vì thế, tốc độ đầu ra của phía gửi được giới hạn một cách hiệu quả bởi băng thông nút cổ chai của bộ định tuyến trong miền CSFQ. FBAf TCP có thể làm tăng sự bình đẳng giữa các luồng đồng thời cải thiện khả năng hoạt động với việc tránh mất gói TCP (điều khiển FBAfTCP ngăn ngừa khả năng tăng tốc độ vượt quá dung lượng sẵn sàng).
5.3.4 Phương pháp QSETCP
QSfTCP (Quick Start TCP) đã được đề xuất năm 2002 bởi Jain và Floyd như là một cách để tăng cửa sổ khởi tạo của một kết nối TCP. Trong thủ tục thiết lập kết nối TCP (TCP SYN và TCP SYN/ACK) phía gửi TCP chèn một yêu cầu bắt đầu nhanh (Quick Start Request) vào gói TCP nó chính là tốc độ khởi tạo mà phía gửi muốn truyền. Mỗi bộ định tuyến dọc theo đường truyền xác nhận liệu nó có thể đáp ứng yêu cầu lưu lượng mới này. Nếu nó có thể đáp ứng yêu cầu mới này thì nó sẽ truyền yêu cầu QS đi, ngược lại nó sẽ giảm tốc độ dữ liệu đến một giá trị phù hợp. Để làm được điều đó bộ định tuyến cần thiết phải giám sát sự khác nhau của trọng tải hiện tại và dung lượng sẵn sàng và những yêu cầu QS trong thời gian gần đây. Khi yêu cầu QS (QS request) tới TCP phía nhận, một đáp ứng QS (QS response) tương ứng được tạo ra và chèn vào một thông báo nhận được gửi trở về phía gửi. Nhận được đáp ứng QS, phía gửi điều chỉnh cửa sổ chống tắc nghẽn khởi tạo theo tốc độ dữ liệu chỉ ra trong đáp ứng QS. Để tránh lưu lượng bùng phát, phía gửi tăng dữ liệu từng bước vào cửa sổ
khởi tạo. QSTCP đòi hỏi tất cả các bộ định tuyến, phía gửi và phía nhận hỗ trợ khởi tạo nhanh (QS). Cơ chế này được dựa trên một bộ đếm bước truyền (hop) nó tương tự như bộ đếm bước truyền trong giao thức IP (dựa trên trường Timeftoflive).
KẾT LUẬN
Trong đồ án này em trình bày cụ thể một giao thức mới XCP với những tính năng vượt trội của nó. Qua một thời gian tìm hiểu về giao thức XCP với sự hướng dẫn của thầy Nguyễn Hà Dương và các thầy cô khác đồ án tốt nghiệp của em đã được hoàn thành. Đồ án tốt nghiệp đề tài này mang nặng về lý thuyết liên quan đến sự hoạt động của giao thức XCP và cơ chế chống tắc nghẽn của nó. cụ thể em đã làm được các yêu cầu của đề tài đó là:
f Giới thiệu giao thức điều khiển chống tắc nghẽn XCP và cấu trúc của nó. f Cơ chế hoạt động của giao thức XCP