Sau đây là một mô hình mạng đơn giản
f Mô hình mạng TCP:
Gồm có 2 node bottleneck (R0 và R1). Duplex link (liên kết truyền nhận dữ liệu hai chiều diễn ra đồng thời) giữa 2 nút R0 và R1có bandwidth (băng thông) = 20 Mbps, delay (thời gian trì hoãn) = 10 ms kiểu hàng đợi XCP, và 3 node khác n0, n1, n2. Duplex link giữa các node với R0 cùng có giá trị bandwidth = 20 Mbps, delay =10 ms Agent “tcp” gắn với n0, n1, n2 agent “tcp_sink” gắn với R1. Agent “tcp” có thể tạo packet với max size =1000 byte, Agent “tcp_sink” tạo và gửi packet dưới dạng ACK cho sender và giải phóng packet nhận được. Bộ khởi tạo lưu lượng “ftp” gắn với Agent “tcp”. Thời gian mô phỏng là 50 s.
f Mô hình mạng XCP: R0 R1 n0 n2 R0 R1 n0 n1 n2
Gồm có 2 node bottleneck (R0 và R1). Duplex link (liên kết truyền nhận dữ liệu hai chiều diễn ra đồng thời) giữa 2 nút R0 và R1có bandwidth (băng thông) = 20 Mbps, delay (thời gian trì hoãn) = 10 ms kiểu hàng đợi XCP, và 5 node khác n0, n1, n2, n3, n4. Duplex link giữa các node với R0 cùng có giá trị bandwidth = 20 Mbps, delay =10 ms, kiểu hàng đợi XCP Agent “xcp” gắn với các node n0, n1. Thời gian mô phỏng là 50 s.
f Mô hình mạng XCP kết hợp với TCP:
Gồm có 2 node bottleneck (R0 và R1). Duplex link (liên kết truyền nhận dữ liệu hai chiều diễn ra đồng thời) giữa 2 nút R0 và R1có bandwidth (băng thông) = 20 Mbps, delay (thời gian trì hoãn) = 10 ms kiểu hàng đợi XCP, và 5 node khác n0, n1, n2, n3, n4. Duplex link giữa các node với R0 cùng có giá trị bandwidth = 20 Mbps, delay =10 ms, kiểu hàng đợi XCP. Agent “tcp” gắn với n0 agent “tcp_sink” gắn với R1. Agent “tcp” có thể tạo packet với max size =1000 byte, Agent “tcp_sink” tạo và gửi packet dưới dạng ACK cho sender và giải phóng packet nhận được. Bộ khởi tạo lưu lượng “ftp” gắn với Agent “tcp” và nó được thiết lập cho start bắt đầu tại thời điểm 12.s. Agent “xcp” gắn với các node n0, n1, n2, n3, n4
Quá trình mô phỏng trong thời gian 50 s.
4.2.2 Kết quả với hai mô hình mô phỏng TCP và XCP
4.2.2.1 Kết quả mô hình mô phỏng TCP
R0 R1
n0
n1
n2
Ở biểu đồ trên: các dòng TCP có các màu đỏ, xanh lá cây và xanh sẫm: các dòng start tại các thời điểm lần lượt là:
Dòng thứ nhất start tại thời điểm: 0.079000000000000015 s. Dòng thứ hai start tại thời điểm: 6.0496999999999996 s. Dòng thứ ba start tại thời điểm: 12.003 s.
Dựa vào biểu đồ có thể thấy: kích thước cửa sổ của các dòng hầu như không có mối liên hệ với nhau trong hoạt động, có những lúc cùng một thời điểm kích thước cửa sổ của cả ba dòng đều tăng, và khi tăng đến mức độ nào đó, kích thước cửa sổ của mỗi dòng đều giảm đi một nữa điều này phù hợp với thuật toán điều khiển chống tắc nghẽn AIMD của TCP tuy nhiên qua đó có thể nói nên rằng không có sự phân phối hợp lý về
băng thông các dòng khi bị tắc nghẽn và không có sự tận dụng một cách hiệu quả băng thông ở các dòng.
4.2.2.2 Kết qủa mô hình mô phỏng XCP
Biểu đồ hình trên cho thấy: hai dòng XCP màu đỏ và màu xanh lá cây có xuất phát điểm khác nhau: dòng màu đỏ start tại thời điểm t1 = 0.079000000000000015 s và ổn định với kích thước cửa sổ có giá trị cwndm1 ≈ 98.000bytes khi dòng màu xanh lá cây chưa start, dòng màu xanh lá cây start tại thời điểm t2 = 6.0496999999999996 s và hội tụ ổn định với dòng màu đỏ với kích thước cửa sổ có giá trị cwndm2 ≈ 49.000 bytes. Có thể thấy kích thước cửa sổ cwndm2 = 1/2 cwndm1.
Qua biểu đồ hình trên cho thấy:
Dòng màu đỏ là biêu đồ kích thước cửa sổ của dòng XCP xuất phát đầu tiên.
Dòng màu xanh lá cây là biểu đồ kích thước cửa sổ của dòng XCP xuất phát thứ hai. Dòng màu xanh thẫm là biểu đồ kích thước cửa sổ của dòng XCP xuất phát thứ ba. Dòng màu vàng là biểu đồ kích thước cửa sổ của dòng XCP xuất phát thứ tư. Dòng màu tìm là biểu đồ kích thước cửa sổ của dòng TCP.
Khi dòng XCP đầu tiên xuất phát tại thời điểm t1 = 0.0790000000000000015 s, kích thước cửa sổ tăng lên một giá trị lớn nhất cwndm1 ≈ 50.000byte
tại thời điểm t2=3.0497000000000001 s, khi dòng XCP thứ hai xuất phát, kích thước cửa sổ của dòng đầu tiên giảm xuống và hội tụ với dòng thứ hai tại giá trị lớn nhất
cwndm2 = 1/2 cwndm1(≈25.000 byte). Tại thời điểm t3 = 6.00300000000000001, khi dòng XCP thứ ba xuất phát kích thước cửa sổ của dòng đầu tiên và dòng thứ hai giảm xuống và xu hướng hội tụ với dòng thứ ba tại giá trị lớn nhất cwndm3 = 1/3 cwndm1. Tại thời điểm t4 = 9.0565999999999995 s, khi dòng XCP thứ tư xuất phát, kích thước cửa sổ của ba dòng đầu có xu hướng hội tụ tại giá trị lớn nhất cwndm4 = 1/4 cwndm1 và các dòng này sau đó ổn định mặc dù có sự xuất hiện của dòng thứ 4 dòng TCP.
Nhận xét:
f Qua mô phỏng cho thấy, kích thước cửa sổ của các dòng XCP có xu hướng hội tụ tới cân bằng tới một giá trị cwnd tối ưu nhất. Ở trạng thái cân bằng bốn dòng XCP có kích thước cửa sổ tương đương nhau mặc dù chúng xuất phát ở các thời điểm khác nhau. Khi ở trạng thái cân bằng kích thước cửa sổ của chúng tỷ lệ nghịch với các dòng (cụ thể ở đây là kích thước cửa sổ của 2 dòng khi dần hội tụ tới cân bằng có giá trị bằng 1/2 kích thước cửa sổ lớn nhất của dòng đầu tiên).
f Đối với dòng TCP, qua mô phỏng cho thấy, kích thước cửa sổ của dòng TCP có sự dao động thất thường và không phụ thuộc vào kích thước cửa sổ của các dòng khác, hay nói cách khác dòng TCP không có mối liên hệ với các dòng khác mà chỉ tăng giảm kích thước cửa sổ theo thuật toán AIMD: ở giai đoạn không tắc nghẽn, cwnd của TCP tăng nhanh, khi bị tắc nghẽn kích thước cửa sổ giảm đi một nửa và điều này không ảnh hưởng tới sự phát triển của các dòng khác.
f Dựa vào kết quả của đồ thị cho thấy cwnd các dòng XCP dao động không rất nhỏ gần như song song với trục hoành của đồ thị do đó có thể nói độ rơi của gói tin là giảm dần và không đáng kể trong trường hợp XCP.
Có thể kết luận qua kết quả so sánh trên cho thấy XCP tận dụng băng thông hiệu lực (ở đây qua cwnd) hiệu quả và ổn định hơn so với TCP, do đó để tăng hiệu lực của XCP trong các mạng tốc độ cao cần tăng băng thông hiệu lực của băng thông trên tất cả các đường truyền.
CHƯƠNG V: PHIÊN BẢN NÂNG CAO CỦA XCP TRONG MẠNG HỖN TẠP: XCPUI
5.1 Nâng cao XCP cho liên mạng hổn tạp
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à