Để đánh giá tính hiệu quả của giải thuật mới DCTCP-FA, ngoài việc giữ nguyên các tính chất của giải thuật cũ DCTCP nhƣ chiều dài hàng đợi switch nhỏ, tận dụng băng thông thì cần kiểm tra thời gian truyền của luồng và chia sẻ băng thông giữa các luồng.
4.7.1 Chiều dài hàng đợi tại switch và thông lƣợng truyền
Thử nghiệm với mô hình mạng gồm các nút 1, 2, 3 … n cùng nối với 1 switch hỗ trợ ECN với ngƣỡng đánh dấu K. Các liên kết giữa các nút với switch có băng thông 100Mbps, delay 2ms. Switch có bộ nhớ đệm tối đa là 425 gói tin. Trên các nút 2,3…n ta tạo các luồng lớn cùng gửi tin đến nút 1 bằng công cụ iperf. Dựa vào các số liệu thu thập đƣợc trên switch ta biểu diễn đƣợc chiều dài hàng đợi switch theo thời gian và thông lƣợng đi qua liên kết giữa switch và nút 1.
Hình 28 – Mô hình mạng mô phỏng các nút
Giải thuật cải tiến về cốt lõi vẫn mang các đặc điểm ƣu việt của giải thuật DCTCP. Khi có tắc nghẽn, tức là chiều dài hàng đợi ở switch vƣợt ngƣỡng K, thì các Sender sẽ đƣợc thông báo và giảm tốc độ gửi xuống sao cho không gây ra tắc nghẽn. Vì vậy mức chiếm giữ hàng đợi tại switch nhỏ.
59
Hình 29 – Mức chiểm giữ hàng đợi tại Switch DCTCP-FA
Bên cạnh đó, mặc dù hàng đợi tại switch nhỏ nhƣng trong giống nhƣ DCTCP, trong giải thuật đề xuất thì khi có tắc nghẽn, các Sender không giảm cửa sổ tắc nghẽn đi một nửa nhƣ giải thuật TCP mà giảm tùy theo mức độ tắc nghẽn, cụ thể là giá trị α để chỉ ƣớc lƣợng về tình trạng tắc nghẽn trong mạng mà các Sender tính toán sau mỗi RTT. Hơn nữa tình trạng mất gói tin đƣợc giảm thiểu nên các Sender không phải dừng lại để chờ quá trình truyền lại gói tin bị mất nhƣ TCP. Vì vậy băng thông của đƣờng truyền luôn đƣợc tận dụng. Thông lƣợng này nhỏ hơn vì giải thuật đề xuất này buộc các luồng lớn truyền trong thời gian dài phải giảm cửa sổ tắc nghẽn nhiều hơn.
60
Hình 30 – Mức băng thông của giải thuật DCTCP-FA
4.7.2 Ảnh hƣởng của giá trị ngƣỡng K đến hiệu quả của giải thuật
Giá trị ngƣỡng K đóng vai trò quan trọng trong ảnh hƣởng đến hiệu quả của giải thuật. Nếu K nhỏ quá sẽ dẫn đến các Sender vừa mới tận dụng băng thông thì nhận đƣợc cảnh báo tắc nghẽn sớm dẫn đến phải giảm tốc độ gửi tin xuống dẫn đến thông lƣợng giảm. Nếu K lớn quá thì thông lƣợng tăng nhƣng không nhiều và hàng đợi dài dẫn đến gói tin phải chờ trong hàng đợi lâu hơn, ảnh hƣởng đến thời gian truyền đặc biệt là đối với các luồng nhỏ.
Để đánh giá ảnh hƣởng của ngƣỡng K đến thông lƣợng của kết nối thắt cổ chai (liên kết từ switch đến nút nhận), ta cũng thực hiện thử nghiệm với mô hình mạng gồm n nút cùng nối với switch trong đó nút 1 làm nút bên nhận còn trên n-1 nút còn lại ta tạo n-1 luồng lớn gửi đến nút 1 bằng công cụ Iperf.
Thực hiện thử nghiệm nhiều lần với n = 3 và n = 9 và tiến hành đo thông lƣợng tại kết nối thắt cổ chai, ta biểu diễn kết quả nhận đƣợc nhƣ hình vẽ:
61
Hình 31 – Ảnh hƣởng của giá trị K đến băng thông
4.7.3 Sự chia sẻ băng thông giữa các luồng
Mô hình mạng thử nghiệm gồm có 3 host (cài đặt DCTCP) cùng nối với 1 switch, 2 host làm sender, 1 host làm receiver. Trên host 1 tạo 1 luồng lớn gửi đến receiver bằng công cụ Iperf. Sau khi host 1 gửi đƣợc 1s thì trên host 2 cũng tạo 1 luồng lớn gửi đến receiver.
Kết quả trên hình cho thấy với giải thuật mới thì sự dao động (thay đổi) của cửa sổ tắc nghẽn mạnh hơn so với giải thuật DCTCP, đồng thời các luồng nhanh chóng đạt đƣợc trạng thái Fair Sharing.
0 20 40 60 80 100 120 10 15 20 25 30 35 40 45 50 55 60 65 70 Thr o ug hpu t (Mbps ) K (packet) Throughput vs K N=3 N=9
62
Hình 32 – Chia sẻ băng thông trong DCTCP-FA
4.7.4 Thời gian hoàn thành của các luồng short-flow
Một tiêu chí quan trọng khi đánh giá giải thuật quản lý tắc nghẽn có hiệu quả không chính là thời gian truyền của một luồng (Flow Completion Time hay viết tắt FCT) hay thời gian tính từ thời điểm luồng bắt đầu truyền cho đến khi kết thúc.
Trong giải thuật đề xuất thì các luồng lớn sẽ giảm cửa sổ gửi nhiều hơn để chia sẻ băng thông cho các luồng mới. Nhƣ vậy đối với các luồng nhỏ thì thời gian hoàn thành quá trình truyền sẽ giảm.
Để kiểm tra ta tiến hành thử nghiệm với mô hình 4 host cùng nối với 1 switch hỗ trợ ECN, 3 host đầu là bên gửi, host 4 là receiver. Trên host 1, host 2 ta tạo các luồng lớn gửi đến host 4 bằng công cụ IPERF. Sau thời gian 5s thì trên host 3 ta tạo 1 luồng nhỏ với kích thƣớc từ 5KB đến 500KB gửi đến host 4 bằng công cụ Wget và webserver.
Hình 33 – So sánh thời gian FCT của các luồng nhỏ
24 27 50 85 154 198 29 33 58 94 209 305 5 K B 1 0 K B 5 0 K B 1 0 0 K B 3 0 0 K B 5 0 0 K B DCTCP-F DCTCP
63
Nhƣ vậy, giải thuật cải tiến cho thời gian FCT của luồng nhỏ giảm đáng kể so với DCTCP. Nhƣ vậy giải thuật đề xuất đã thực sự đem lại hiệu quả hơn so với giải thuật DCTCP ban đầu.
4.7.5 Hiện tƣợng incast
Incast [Safe and Effective Fine-grained TCP Retransmissions for Datacenter Communication, SIGCOMM 2009] là hiện tƣợng tại một thời điểm có nhiều luồng nhỏ cùng gửi đến một nút. Hiện tƣợng này thƣờng xuất hiện trong môi trƣờng DATA CENTER, đặc biệt là các ứng dụng có dạng phân tách – kết hợp nhƣ MapReduce [MapReduce: Simplified Data Processing on Large Clusters, OSDI’04, 2004], trong đó 1 nút cha (Master) gửi 1 yêu cầu đến nhiều nút con (Slave). Các nút con sau khi tính toán thì trả về kết quả cho nút cha và nhƣ vậy trong một khoảng thời gian ngắn có nhiều luồng nhỏcùng gửi đến nút cha. Tại nút cha lúc đó xảy ra hiện tƣợng incast.
Đối với giải thuật TCP thông thƣờng thì các Bên gửi luôn có xu hƣớng tận dụng hết bộ nhớ đệm của switch nên khi hiện tƣợng incast xảy ra thì một điều chắc chắn là bộ nhớ đệm của switch bị đầy, dẫn đến hiện tƣợng mất gói. Khi mất gói xảy ra thì Bên gửi phải đợi Timeout xảy ra để gửi lại gói bị mất và nhƣ vậy thời gian truyền có thể tăng lên nhiều. Trong các ứng dụng mô hình Phân tách – kết hợp thì sau một khoảng thời gian quy định, nếu các nút con không trả về kết quả vì lí do nào đấy thì nút cha sẽ tổng hợp kết quả mà không cần đến các nút chậm trễ. Điều này có thể ảnh hƣởng đến chất lƣợng của kết quả tổng hợp và nhƣ vậy ảnh hƣởng đến chất lƣợng của ứng dụng sử dụng mô hình phân tách – kết hợp này.
Với giải thuật DCTCP hay giải thuật mới đề xuất thì ta luôn duy trì hàng đợi nhỏ tại switch nên bộ nhớ đệm của switch vẫn còn để dự phòng khi hiện tƣợng incast xảy ra. Để khảo sát hiện tƣợng incast, ta thực hiện thử nghiệm với mô hình gồm n nút cùng nối với 1 switch, trong đó nút 1 làm nút bên nhận và trên n-1 nút còn lại sẽ tạo ra các luồng gửi đến nút 1. Cụ thể tại nút 2 và nút 3, ta tạo các luồng lớn bằng công cụ Iperf. Còn từ nút 4 đến nút n ta tạo các luồng nhỏ bằng công cụ wget kết hợp với
64
Webserver. Sau khi các luồng lớn đã truyền đƣợc 5s thì các luồng nhỏ tiến hành truyền đi.
Thực hiện thử nghiệm với n=35 và biểu diễn số liệu, ta đƣợc kết quả nhƣ hình vẽ.
Hình 34 – Hành đợi Switch khi có Incast
Trên hình vẽ ta thấy khi tại thời điểm 5s thì chiều dài hàng đợi tăng đột ngột là do các luồng nhỏ đồng thời gửi. Vì mức chiếm giữ hàng đợi nhỏ nên khi hiện tƣợng incast xảy ra thì các luồng nhỏ cũng không bị mất gói.
4.8 Kết luận
Trong chƣơng 4 ta đã cài đặt giải thuật đề xuất DCTCP-FA vào mã nguồn nhân Linux và tiến hành các thử nghiệm mô phỏng để đánh giá hiệu quả của nó. Giải thuật DCTCP-FA vẫn kế thừa những tính chất của DCTCP đồng thời tăng khả năng chia sẻ băng thông giữa các luồng và cải thiện đƣợc thời gian truyền của luồng.
65
KẾT LUẬN VÀ HƢỚNG PHÁT TRIỂN CỦA LUẬN VĂN
Kết quả của luận văn:
Trình bày giải thuật quản lý tắc nghẽn trong giao thức TCP và giải thuật điển hình cho môi trƣờng Data Center là DCTCP đồng thời chỉ ra đƣợc những ƣu, nhƣợc điểm của nó.
Đề xuất đƣợc phƣơng án cải tiến giải thuật DCTCP theo hƣớng có chỉ định sự ƣu tiên giữa các luồng gửi để tăng cƣờng khả năng chia sẻ băng thông của đƣờng truyền đồng thời giảm đƣợc thời gian truyền.
Tìm hiểu mã nguồn giải thuật quản lý tắc nghẽn của giao thức TCP trong nhân Linux, công cụ mô phỏng Mininet.
Tìm hiểu mã nguồn giải thuật quản lý tắc nghẽn trong TCP của nhân Linux, Cài đặt giải thuật đề xuất vào mã nguồn của nhân Linux và tiến hành thực nghiệm mô phỏng kiểm tra mức độ cải thiện của giải thuật.
Hạn chế của luận văn:
Phƣơng án đề xuất là cải tiến của giải thuật đã có, mặc dù cho hiệu quả hơn song chƣa hẳn là bƣớc đột phá.
Thực nghiệm đánh giá không đƣợc thực hiện trên hệ thống vật lý thật có qui mô lớn mà chỉ thực hiện nhờ công cụ mô phỏng trên máy tính với mức độ mô phỏng những điều kiện, tình huống xảy ra trong môi trƣờng Data Center. Luận văn mới chỉ khảo sát một số biến thể của DCTCP để so sánh, đánh giá
tính hiệu quả với giải thuật đề xuất. Hƣớng phát triển của luận văn:
Giải thuật cải tiến cũng nhƣ giải thuật ban đầu sử dụng tính năng ECN có mặt trên các switch/router hiện đại với chính sách quản lý hàng đợi RED hay WRED hết sức đơn giản với một tham số làm ngƣỡng đánh dấu K. Vì vậy, ta có thể tiếp tục nghiên cứu mở rộng với mối quan hệ giữa K, DSCP để tối ƣu hóa băng thông sử dụng.
Các giải thuật đã trình bày đƣa ra cách thức quản lý tắc nghẽn tùy theo mức độ tắc nghẽn đã cho thấy những hiệu quả đem lại nhƣ chiều dài hàng đợi của switch nhỏ, giảm thiểu mất gói mà vẫn tận dụng tối đa băng thông. Tuy nhiên để xác định đƣợc mức độ tắc nghẽn cần có sự hỗ trợ của tính năng ECN mà không phải bất cứ switch nào cũng tích hợp. TCP Vegas cũng đƣa ra phƣơng pháp dự đoán mức độ tắc nghẽn dựa trên quan sát sự thay đổi của thời gian RTT, tuy nhiên chỉ áp dụng trong môi trƣờng mạng WAN bởi trong môi trƣờng Data Center thì thời gian RTT nhỏ cỡ µs nên ƣớc lƣợng có thể
66
không chính xác. Vì vậy, có thể áp dụng giải thuật quản lý tắc nghẽn tùy theo mức độ tắc nghẽn trong môi trƣờng mạng WAN thông thƣờng trong đó mức độ tắc nghẽn đƣợc xác định dựa vào biến đổi trong thời gian RTT.
67
TÀI LIỆU THAM KHẢO
[1] Mohammad Alizadeh, Albert Greenberg, David A. Maltz, Jitendra Padhye, Parveen Patel, Balaji Prabhakar, Sudipta Sengupta, and Murari Sridharan, “Data Center TCP (DCTCP)”, SIGCOMM 2010.
[2] Floyd, S., and Jacobson, V., “Random Early Detection Gateways for Congestion Avoidance”, IEEE/ACM Transactions on Networking, V.1 N.4, August 1993.
[3] Vamanan, Balajee, Hasan, Jahangir, Vijaykumar, “Deadline-Aware Datacenter TCP (D2TCP)”, T.N. ACM SIGCOMM Computer Communication Review vol. 42 issue 4 September 24, 2012. p. 115-126.
[4] Cisco, “WRED Explicit Congestion Notification”, Nov 21, 2012
[5] K.K. Ramakrishnan, S. Floyd, and D. Black, “The Addition of Explicit Congestion Notification (ECN) to IP”, RFC 3168, Proposed Standard, September 2001.
[6] Vijay Vasudevan et al., “Safe and Effective Fine-grained TCP Retransmissions for Datacenter Communication”, SIGCOMM 2009
[7] J. Dean, S. Ghemawat, “MapReduce: Simplified Data Processing on Large Clusters”, OSDI’04, 2004.
[8] Miguel Rio, Mathieu Goutelle, Tom Kelly, Richard Hughes-Jones, JeanPhilippe Martin-Flatin, Yee-Ting Li, “A Map of the Networking Code in Linux Kernel“, Technical Report DataTAG-2004-1, 31 March 2004
[9] Ying-Dar Lin, Ren-Hung Hwang, Fred Baker, “Computer Networks: An Open Source Approach”, published by McGraw Hill, Feb 2011.
[10] Peterson L. L. and Davie B. S. , Computer Networks: A Systems Approach, 2nd ed., Mogran-Kaufmann, 1999.
[11] Sammer Seth, M. Ajaykumar Venkatesulu, “TCP/IP Architecture, Design and Implementation in Linux”, IEEE Computer Society Publications.
68
[12] James F. Kurose, Keith W. Ross, Computer Networking: A Top-Down Approach, 6th edition, Pearson Education 2013.
[13] ECN, http://en.wikipedia.org/wiki/Explicit_Congestion_Notification [14] Iperf, https://iperf.fr/
[15] Linux Kernel Documentation, http://kernel.org/doc/Documentation
[16] Mininet, https://github.com/mininet/mininet/wiki/Introduction-to-Mininet [17] DSCP, http://en.wikipedia.org/wiki/Differentiated_services
[18] WRED, http://en.wikipedia.org/wiki/Weighted_random_early_detection [19] Cloud Computing , http://en.wikipedia.org/wiki/Cloud_computing [20] Paul Stryer, “Understanding Data Centers and Cloud Computing”
69
PHỤ LỤC
Các bƣớc cài đặt giải thuật quản lý tắc nghẽn DCTCP vào nhân Linux
cd /usr/src wget http://www.kernel.org/pub/linux/kernel/v3.0/linux-3.2.18.tar.bz2 tar -xjf linux-3.2.18.tar.bz2 cd linux-3.2.18 patch -p1 < /path/to/mininet_tests/dctcp/0001-Updated-DCTCP-patch-for- 3.2-kernels.patch make menuconfig
Enable DCTCP via `make menuconfig':
Networking support: → Networking options → DCTCP: Data Center TCP processors=`grep -c ^processor /proc/cpuinfo`
export CONCURRENCY_LEVEL=$processors make-kpkg clean
time fakeroot make-kpkg --verbose --initrd --append-to-version=-dctcp kernel_image kernel_headers cd /usr/src sudo dpkg -i linux-image-3.2.18-dctcp_3.2.18-dctcp- 10.00.Custom_amd64.deb sudo dpkg -i linux-headers-3.2.18-dctcp_3.2.18-dctcp- 10.00.Custom_amd64.deb sudo update-grub2 sudo reboot
Các bƣớc cài đặt công cụ Mininet.
sudo apt-get install git
git clone https://github.com/mininet/mininet cd mininet/util
sudo ./install.sh –a
Dữ liệu export
0.000547697 10.0.0.2:55167 10.0.0.1:5001 32 0xcfa74f99 0xcfa6c7d9 24 20 156672 7 0.000739930 10.0.0.3:40830 10.0.0.1:5001 32 0x53a7e236 0x53a7a9a6 10 7 64000 7 0.002545709 10.0.0.2:55167 10.0.0.1:5001 44 0xcfa76091 0xcfa6d8d1 24 20 155648 7
70 0.002779358 10.0.0.1:5001 10.0.0.3:40830 1480 0xe0f7fa51 0xe0f7fa51 10 2147483647 14848 51 0.003038258 10.0.0.2:55167 10.0.0.1:5001 52 0xcfa76639 0xcfa6d8d1 24 20 156672 7 0.003309801 10.0.0.1:5001 10.0.0.2:55167 1480 0x4062269d 0x4062269d 10 2147483647 14848 20 0.003839973 10.0.0.2:55167 10.0.0.1:5001 44 0xcfa76be1 0xcfa6d8d1 24 20 156672 7 0.004237725 10.0.0.3:40830 10.0.0.1:5001 32 0x53a80f76 0x53a7d6e6 10 7 64000 6 0.004246264 10.0.0.2:55167 10.0.0.1:5001 32 0xcfa79379 0xcfa70611 24 20 156672 7 0.004259414 10.0.0.3:40830 10.0.0.1:5001 32 0x53a8151e 0x53a7dc8e 10 7 64000 6 0.004274823 10.0.0.2:55167 10.0.0.1:5001 44 0xcfa7a471 0xcfa71cb1 24 20 155648 7 0.004800453 10.0.0.1:5001 10.0.0.3:40830 1480 0xe0f7fa51 0xe0f7fa51 10 2147483647 14848 51 0.005813959 10.0.0.3:40830 10.0.0.1:5001 44 0x53a82616 0x53a7e7de 11 7 64000 5