TỔNG QUAN VỀ QUẢN LÝ TẮC NGHẼN TRONG GIAO THỨC
TCP/IP
Giao thức TCP/IP, ra đời vào năm 1980 từ dự án nghiên cứu của Bộ Quốc phòng Mỹ, đã trở thành chuẩn mực cho hầu hết các kết nối mạng hiện nay Tên gọi của giao thức này được đặt theo hai thành phần chính là TCP (giao thức điều khiển giao vận) và IP (giao thức liên mạng) Kiến trúc của TCP/IP tương tự như mô hình OSI nhưng chỉ bao gồm 4 lớp.
The Application Layer is responsible for managing protocols that facilitate presentation, encoding, and call management It supports various applications, including FTP (File Transfer Protocol), HTTP (Hypertext Transfer Protocol), SMTP (Simple Mail Transfer Protocol), DNS (Domain Name System), and TFTP (Trivial File Transfer Protocol).
Tầng giao vận (Transport Layer) đảm nhiệm việc truyền dữ liệu từ nguồn đến đích, thông qua hai giao thức TCP (Transmission Control Protocol) và UDP (User Datagram Protocol)
Tầng Internet (Internet Layer) chịu trách nhiệm lựa chọn đường đi tối ưu cho các gói tin, với giao thức chính được sử dụng là giao thức IP (Internet Protocol).
Tầng truy cập mạng (Network Access Layer) đóng vai trò quan trọng trong việc cung cấp các phương tiện kết nối vật lý như cáp, bộ chuyển đổi và card mạng Nó sử dụng các giao thức kết nối và truy cập đường truyền như CSMA/CD, Token Ring và Token Bus để đảm bảo việc truyền tải dữ liệu hiệu quả Tầng này cũng cung cấp các dịch vụ thiết yếu cho tầng Internet, góp phần vào sự hoạt động mượt mà của toàn bộ hệ thống mạng.
Hình 1 – Tham chiếu giữa mô hình OSI và TCP/IP
Giao thức TCP
Tầng giao vận (Transport Layer) cung cấp dịch vụ đầu cuối – truyền dữ liệu từ nguồn đến đích cho các chương trình ứng dụng Bao gồm 2 giao thức chính :
TCP (Transmission Control Protocol) : giao thức hướng kết nối, đảm bảo dữ liệu truyền tin cậy và cho phép quản lý điều khiển tốc độ truyền tin
Giao thức UDP (User Datagram Protocol) là một giao thức không kết nối và không đảm bảo độ tin cậy Thường được ứng dụng trong các lĩnh vực cho phép mất mát dữ liệu, UDP rất phù hợp cho những ứng dụng yêu cầu độ trễ thấp và các ứng dụng thời gian thực.
Hầu hết các ứng dụng mạng hiện nay sử dụng giao thức TCP để truyền tải thông tin, nhờ vào khả năng đảm bảo tính tin cậy và thứ tự của dữ liệu Bên cạnh đó, TCP còn điều chỉnh tốc độ truyền tin phù hợp với tình trạng tắc nghẽn của mạng và khả năng tiếp nhận của bên nhận.
Giao thức TCP cung cấp các chức năng khi truyền tin sau :
Truyền tin giữa các tiến trình với nhau
Quản lý lỗi của các gói tin
Đảm bảo truyền tin cậy
Điều khiển luồng và quản lý tắc nghẽn
1.2.1 Quản lý kết nối Để có thể thực hiện đƣợc những chức năng trên, TCP cần quản lý kết nối bao gồm thiết lập và kết thúc phiên kết nối giữa các tiến tình đầu cuối với nhau Mỗi kết nối đƣợc xác định bởi bộ 5 gồm: địa chỉ IP nguồn, địa chỉ IP đích, cổng nguồn, cổng đích và ID của giao thức Thiết lập một phiên kết nối không đơng giản bởi vì các hiện tượng thường gặp trong Internet như mất gói, trễ, lặp Vì vậy TCP sử dụng giao thức bắt tay 3 bước để thiết lập kết nối
Khi bắt đầu một phiên kết nối, cả tiến trình Client và Server sẽ chọn ngẫu nhiên chỉ số bắt đầu của mình Để thiết lập kết nối, Client gửi gói tin SYN chứa chỉ số cổng của Server và chỉ số bắt đầu gói tin đã chọn Server nhận gói tin SYN và phản hồi bằng gói tin (SYN + ACK) để xác nhận yêu cầu của Client và cung cấp chỉ số bắt đầu gói tin của mình Cuối cùng, Client gửi gói tin xác nhận gói tin SYN từ Server, hoàn tất quá trình thiết lập kết nối, được gọi là giao thức bắt tay 3 bước.
Hình 2 – Thiết lập phiên TCP
Để kết thúc một phiên kết nối TCP, cần sử dụng 4 gói tin Đầu tiên, tiến trình Client gửi gói tin FIN đến Server để yêu cầu kết thúc kết nối Tiếp theo, Server phản hồi bằng cách gửi gói tin ACK xác nhận gói FIN và đồng thời gửi gói tin FIN đến Client Sau khi nhận gói tin FIN từ Server, Client sẽ gửi lại gói tin ACK để xác nhận và hoàn tất quá trình kết thúc kết nối Qua đó, có thể thấy rằng kết nối TCP là song công, với dữ liệu được truyền độc lập từ Client đến Server và ngược lại.
Hình 3 – Kết thúc phiên TCP
TCP sử dụng Checksum để đảm bảo tính toàn vẹn của gói tin, cho phép quản lý lỗi cho từng gói tin Khác với UDP, nơi Checksum là tùy chọn, TCP yêu cầu Checksum là bắt buộc, giúp đảm bảo tính chất truyền tin cậy trong quá trình truyền tải.
Checksum không đủ để đảm bảo tính tin cậy và thứ tự của dữ liệu trong quá trình truyền Do các gói tin có thể bị mất, cần áp dụng kỹ thuật retransmit để gửi lại những gói tin này Hơn nữa, để xử lý tình huống các gói tin nhận không đúng thứ tự, TCP sử dụng kỹ thuật xác nhận ACK và chỉ số thứ tự, đảm bảo truyền tin cậy cho từng luồng dữ liệu.
Dữ liệu trong TCP được chia thành các Octet, mỗi Octet chứa 8 bit Số thứ tự của gói tin được xác định bởi chỉ số của Octet đầu tiên, được lưu trong trường 32 bit chỉ số thứ tự của TCP Header TCP Sender có nhiệm vụ đánh số và theo dõi các Octet đã gửi và đang chờ xác nhận Khi TCP Receiver nhận gói tin, nó sẽ phản hồi bằng gói tin ACK, trong đó trường chỉ số xác nhận chỉ rõ chỉ số của đoạn dữ liệu tiếp theo mà nó đang chờ nhận, đồng thời xác nhận rằng tất cả các Octet có chỉ số nhỏ hơn đã được nhận đầy đủ.
1.2.4 Kỹ thuật cửa sổ trƣợt
Do độ trễ truyền không ổn định, TCP Sender cần tối ưu hóa khả năng đường truyền, thích ứng với khả năng nhận của Receiver và chia sẻ băng thông với các Sender khác Để thực hiện điều này, TCP áp dụng cơ chế điều khiển luồng dựa trên cửa sổ trượt (Sliding Window).
Giao thức TCP sử dụng cơ chế điều khiển luồng và quản lý tắc nghẽn để xác định tốc độ gửi tin hợp lý Nhờ vào điều khiển luồng, TCP Sender có thể biết được băng thông mà nó có thể sử dụng mà không làm đầy bộ nhớ của Receiver Đồng thời, quản lý tắc nghẽn giúp TCP Sender chia sẻ tài nguyên mạng với các Sender khác mà không gây ra tình trạng tắc nghẽn trong mạng.
Sender duy trì một cửa sổ gửi, được xác định bởi chỉ số bắt đầu và chỉ số kết thúc, cho phép chỉ những gói tin có số thứ tự trong cửa sổ này được gửi đi Các gói tin đã gửi nhưng chưa được xác nhận sẽ được lưu trữ trong bộ nhớ gửi lại (Retransmission Buffer) Khi gói tin có chỉ số bắt đầu của cửa sổ được xác nhận, cửa sổ gửi sẽ trượt đi để tiếp tục gửi các gói tin tiếp theo.
Hình 6 – Kích thước cửa sổ trượt
Kích cỡ của cửa sổ trượt trong TCP được xác định bởi giá trị nhỏ nhất giữa cửa sổ nhận (RWND) và cửa sổ tắc nghẽn (CWND) TCP Sender luôn xem xét cả hai giá trị này để giới hạn tốc độ gửi dữ liệu Cửa sổ nhận (RWND) được thông báo bởi Receiver thông qua trường 16-bit Window Size trong TCP Header, trong khi cửa sổ tắc nghẽn (CWND) được tính toán bởi Sender.
Quản lý tắc nghẽn trong TCP
TCP Sender được thiết kế để dự đoán tắc nghẽn mạng thông qua hiện tượng mất gói Khi xảy ra mất gói, Sender sẽ giảm tốc độ gửi để tránh gây thêm mất gói, quá trình này được gọi là quản lý tắc nghẽn Mục tiêu của quản lý tắc nghẽn là tối ưu hóa việc sử dụng tài nguyên mà không làm tắc nghẽn mạng Tư tưởng chính là cho phép TCP Sender dự đoán băng thông còn trống trong kết nối từ Sender đến Receiver, từ đó điều chỉnh số lượng gói tin gửi đi một cách phù hợp.
Giao thức TCP, phát triển hơn ba thập kỷ trước, đã trải qua nhiều phiên bản để cải thiện hiệu năng Phiên bản đầu tiên, được giới thiệu vào năm 1981 trong RFC 793, chỉ bao gồm kỹ thuật điều khiển luồng dựa trên cửa sổ trượt mà không có quản lý tắc nghẽn do lưu lượng Internet lúc đó còn thấp Sau 8 năm, Van Jacobson đã giới thiệu thuật toán quản lý tắc nghẽn khi Internet bắt đầu gặp phải tình trạng tắc nghẽn, dẫn đến việc ra đời phiên bản TCP Tahoe với bốn trạng thái: Slow Start, Congestion Avoidance, Fast Retransmit và Retransmission Timeout Phiên bản TCP Reno sau đó đã mở rộng mô hình này bằng cách thêm trạng thái Fast Recovery, trở thành phiên bản phổ biến trong những năm tiếp theo.
2000 Sau đó có nhiều phiên bản khác nhau ra đời để không ngừng cải thiện hiệu năng nhƣ TCP NewReno, TCP FACK, TCP SACK, TCP Vegas
1.3.2 Mô hình quản lý tắc nghẽn của TCP Reno
TCP Sender sử dụng cửa sổ tắc nghẽn (CWND) để kiểm soát lượng dữ liệu được truyền trong một RTT (Round Trip Time), đồng thời áp dụng cửa sổ lớn nhất (MSS) để xác định giới hạn tối đa cho giá trị của CWND.
Hình 7 – Mô hình quản lý tắc nghẽn của TCP Reno
Mô hình quản lý tắc nghẽn của TCP Reno bao gồm 5 trạng thái khác nhau, với sự chuyển đổi giữa các trạng thái này được thể hiện rõ ràng.
Pha Tăng chậm (Slow Start) có mục tiêu xác định nhanh chóng lượng băng thông còn trống trong vài RTT Khi bắt đầu kết nối hoặc gặp timeout, pha Slow Start khởi động với giá trị ban đầu của CWND.
Sau khi gửi một gói tin, Sender sẽ tiếp tục tăng kích thước cửa sổ điều khiển (CWND) theo hàm mũ Cụ thể, mỗi khi nhận được một ACK, CWND sẽ tăng thêm 1 Do đó, nếu tất cả các ACK được nhận trước khi hết thời gian chờ (timeout), CWND sẽ được nhân đôi sau mỗi khoảng thời gian RTT.
The TCP Sender continues in this phase until the Congestion Window (CWND) exceeds the Slow Start Threshold (SSTHRESH) At this point, it transitions into the Congestion Avoidance phase If the sender receives three duplicate ACK packets, it then shifts to the Fast Recovery phase.
Retransmit Nếu không nhận được ACK nào trước khi timeout thì CWND bị reset về 1 và chuyển sang pha Retransmission Timeout
Giai đoạn Tránh tắc nghẽn trong giao thức TCP nhằm mục đích thăm dò băng thông một cách từ từ, đồng thời phản ứng nhanh chóng khi xảy ra tắc nghẽn Quá trình này được thực hiện theo phương pháp AIMD (tăng ít, giảm nhiều) Khi TCP Sender nhận được một ACK, nó sẽ tăng kích thước cửa sổ điều khiển (CWND) thêm 1/CWND Do đó, nếu TCP Sender nhận đủ ACK trong một khoảng thời gian RTT, CWND sẽ được tăng lên.
1 Nhƣng nếu xảy ra hiện tƣợng mất gói (nhận đƣợc 3 ACK lặp nhau) thì nó chuyển sang pha Fast retransmit Và tương tự như Slow Start nếu timeout thì nó chuyển sang pha Retransmission Timeout
Fast Retransmit (Truyền lại ngay) là quá trình gửi lại gói tin bị mất ngay lập tức mà không cần chờ timeout Gói tin ACK bị lặp có thể do mất gói, gói tin gửi đi bị lặp, hoặc gói tin nhận không đúng thứ tự Khi phát hiện mất gói, Sender sẽ gửi lại ngay khi nhận được 3 hoặc nhiều hơn ACK lặp nhau, coi đó là dấu hiệu mất gói Sau đó, TCP Sender giảm giá trị SSTHRESH xuống một nửa của CWND hiện tại và thiết lập CWND bằng giá trị SSTHRESH mới, tiếp tục chuyển sang pha Fast Recovery.
Khi xảy ra hiện tượng mất gói mà không thể xác định qua tín hiệu nhận được 3 ACK lặp lại, retransmission timeout là phương pháp cuối cùng và chậm nhất để xử lý Khi timeout xảy ra, TCP Sender sẽ giảm giá trị của SSTHRESH xuống một nửa giá trị của CWND và thiết lập lại giá trị CWND.
1 TCP Sender sau đó chuyển sang pha Slow Start Giá trị timeout phụ thuộc nhiều vào RTT và sự biến động của RTT Giá trị RTT càng biến động nhiều thì giá trị timeout càng phải lớn và nếu giá trị RTT càng ổn định thì giá trị
21 timeout càng phải sát với giá trị RTT để có thể truyền lại gói tin bị mất sớm nhất có thể
Fast Recovery is initiated after Fast Retransmit, where the SSTHRESH value is set to half of the CWND, and the CWND is adjusted to SSTHRESH plus three Each duplicate ACK signifies that another packet has been successfully transmitted to the receiver Once the ACK for the recently transmitted packet is received, the CWND is updated to match the SSTHRESH, allowing the TCP sender to transition into the Congestion Avoidance phase.
Hình 8 – Kích thước cửa sổ TCP Reno
Kết luận
Chương 1 đã trình bày tổng quan về giao thức TCP trong họ giao thức TCP/IP, nhấn mạnh rằng TCP cung cấp dịch vụ truyền tin cậy giữa bên gửi và bên nhận thông qua các chức năng quản lý lỗi, điều khiển luồng và quản lý tắc nghẽn Trong chương tiếp theo, chúng ta sẽ khám phá môi trường trung tâm dữ liệu và đánh giá hiệu quả của các giải thuật quản lý tắc nghẽn của giao thức TCP trong bối cảnh này.
GIAO THỨC TCP TRONG MÔI TRƯỜNG DATA CENTER
Môi trường Data Center và Cloud Computing
Môi trường Data Center có những đặc điểm khác biệt so với mạng WAN, với 99.91% lưu lượng là TCP và thời gian trễ RTT thường dưới 250 micro giây Các ứng dụng trong Data Center yêu cầu băng thông cao và độ trễ rất thấp, như được chỉ ra trong nghiên cứu về Data Center TCP (DCTCP) tại SIGCOMM 2010.
Các chương trình thông thường sử dụng mô hình phân tách-kết hợp, như MapReduce, để xử lý thông tin trong các ứng dụng web quy mô lớn như tìm kiếm và mạng xã hội Khi người dùng gửi truy vấn, hệ thống sẽ chia nhỏ yêu cầu và phân phối đến các nút thấp hơn, sau đó tổng hợp kết quả để trả về cho người dùng Đối với các ứng dụng tương tác, độ trễ là yếu tố quan trọng, với thời gian xử lý ở phần backend thường giới hạn trong khoảng 200-300ms.
Nhiều ứng dụng sử dụng mô hình luồng công việc phân tách-kết hợp (Partition/Aggregate), trong đó sự chậm trễ của một lớp có thể ảnh hưởng đến các lớp khác Để đảm bảo thời gian truy vấn, các nút ở lớp con cần hoàn thành nhiệm vụ trong khoảng thời gian từ 10-100ms [Data Center TCP (DCTCP), SIGCOMM 2010] Nếu thời gian phản hồi vượt quá giới hạn này, quá trình tính toán sẽ bỏ qua câu trả lời của nút đó, dẫn đến giảm chất lượng và độ chính xác của kết quả.
2.1.1 Khái niệm luồng nhỏ, luồng lớn
Khi 2 tiến trình trên 2 nút khởi tạo kết nối với nhau và bắt đầu truyền tải thông tin trên đó thì trên kết nối đó có một luồng (flow) mang thông tin từ bên gửi đến bên nhận Tùy thuộc vào kích cỡ và thời gian truyền của luồng mà ta phân biệt luồng nhỏ (short-flow) hay luồng lớn (long-flow) Các luồng nhỏ có lƣợng dữ liệu truyền nhỏ, thường thấp hơn 1MB, có thời gian truyền ngắn và thường đòi hỏi thời gian truyền của luồng là ngắn Các luồng lớn có lƣợng dữ liệu truyền lớn, thời gian truyền dài và thường yêu cầu cao về thông lượng hơn là thời gian truyền [Data Center TCP (DCTCP), SIGCOMM 2010]
2.1.2 Các tính chất của lưu lượng trong môi trường DATA CENTER
Dựa vào các kết quả rút ra đƣợc trong [Data Center TCP (DCTCP), SIGCOMM
2010], ta có nhận xét lưu lượng truyền tải (traffic) trong môi trường Data Center bao gồm:
Các truy vấn có kích cỡ từ 2KB đến 20KB,
Các tin nhắn ngắn đòi hỏi độ trễ thấp có kích cỡ từ 100KB đến 1MB,
Các luồng chạy nền trong thời gian dài yêu cầu thông lƣợng lớn có kích cỡ từ 1MB đến 100MB
Lưu lượng truy vấn (query traffic) đề cập đến các ứng dụng truy vấn Web theo mô hình phân tách-kết hợp, với các luồng truy vấn ngắn hạn và yêu cầu độ trễ rất thấp Kích thước của các luồng này thường nhỏ, với yêu cầu từ bộ phân tách đến các nút ở lớp dưới khoảng 1.6KB và phản hồi ngược lại từ 1.6 đến 2KB Trong khi đó, lưu lượng chạy nền (background traffic) bao gồm cả các luồng lớn và nhỏ.
Hình 9 – Phân phối luồng theo kích cỡ
Hình minh họa hàm phân phối xác suất PDF theo kích cỡ luồng cho thấy rằng hầu hết các luồng là nhỏ, nhưng lưu lượng chủ yếu tập trung vào các luồng lớn Các luồng này bao gồm hai dạng: luồng cập nhật dữ liệu mới đến các nút lưu trữ với kích thước từ 5KB đến 50MB, và luồng tin ngắn từ 50KB đến 1MB dùng để truyền thông tin điều khiển đến các nút con.
Hình 10 – Phân phối số lƣợng các kết nối đồng thời
Hình biểu diễn phân phối xác suất CDF cho thấy số lượng các luồng xảy ra đồng thời, với hình bên trái thể hiện tất cả các luồng và hình bên phải chỉ xét các luồng lớn hơn 1MB Kết quả cho thấy, đối với các luồng lớn, số lượng thường không vượt quá 4, mặc dù chúng có thể hoạt động trong thời gian dài và chiếm giữ một lượng lớn bộ nhớ.
ECN - Explicit Congestion Notification
Tắc nghẽn trong mạng (Network Congestion) có thể đƣợc thông tin, cảnh báo đến các bên gửi và bên nhận theo 2 loại:
Thông tin ngầm (Implicit Notification): các đầu gửi-nhận dựa trên nhiều thông tin, dấu hiệu để suy đoán ra tắc nghẽn
Thông tin rõ ràng (Explicit Notification): các đầu gửi-nhận biết rõ đang có tắc nghẽn xảy ra
Khi mạng gặp tắc nghẽn, đặc biệt tại các switch hoặc router với hàng đợi bị quá tải, các gói tin gửi đến sẽ bị loại bỏ Việc mất gói tin này dẫn đến các gói tin ACK bị trùng lặp hoặc gặp tình trạng Timeout Sender sẽ dựa vào những thông tin này để suy đoán tình trạng tắc nghẽn và có các phản ứng phù hợp.
ECN (Explicit Congestion Notification) là một tính năng trong giao thức IP được quy định trong RFC 3168, cho phép thông báo tình trạng tắc nghẽn mạng mà không cần loại bỏ gói tin Thay vì phải đoán dựa trên nhiều thông tin khác nhau, ECN cung cấp cho các bên gửi-nhận khả năng nhận diện nhanh chóng tình trạng tắc nghẽn và phản ứng kịp thời Tính năng này chỉ được sử dụng khi cả hai bên đều hỗ trợ và sẵn sàng áp dụng ECN Khi ECN được kích hoạt, các switch/router tương thích sẽ đánh dấu gói tin để thông báo về nguy cơ tắc nghẽn thay vì loại bỏ gói tin Việc sử dụng ECN yêu cầu sự hỗ trợ từ cả tầng mạng và tầng giao vận.
Hình 11 – ECN trong IP Header và TCP Header
ECN sử dung 2 bit LSB của trường DiffServ (DSCP) của phần IP Header để mã hóa bốn trạng thái:
00 – Non-ECT: không hỗ trợ truyền với ECN
10 – ECT(0): hỗ trợ truyền với ECN
01 – ECT(1): hỗ trợ truyền với ECN
11 – CE: đang bị tắc nghẽn
Khi cả hai bên gửi và nhận hỗ trợ ECN, các gói tin sẽ được đánh dấu bằng ECT(0) hoặc ECT(1) Nếu gói tin đi qua hàng đợi bị tắc nghẽn và router hoặc switch hỗ trợ ECN, trạng thái mã hóa sẽ được đặt lại thành CE để chỉ ra tình trạng tắc nghẽn.
27 bên nhận, tín hiệu tắc nghẽn đƣợc chuyển lên tầng giao vận và thông tin ngƣợc trở lại cho bên gửi biết để giảm tốc độ truyền
2.2.2 ECN trong tầng giao vận
ECN sử dụng 2 bit trong phần TCP Header, bao gồm tín hiệu ECE để thông báo tình trạng tắc nghẽn và tín hiệu CWR để xác nhận việc đã nhận tín hiệu tắc nghẽn cũng như giảm tốc độ truyền tải.
Khi nhận gói tin IP có trạng thái mã hóa CE, TCP của bên nhận sẽ thông báo tắc nghẽn cho bên gửi bằng cách thiết lập cờ ECE trong phần TCP Header của gói tin ACK Để xử lý tình huống này, bên nhận sẽ giảm tốc độ truyền tải bằng cách thu hẹp cửa sổ tắc nghẽn và thiết lập cờ CWR trong gói tin gửi đi.
Một nút sẽ tiếp tục gửi các gói tin với cờ ECE cho đến khi nó nhận đƣợc gói tin với cờ CWR
2.2.3 RED – Random Early Detection Để sử dụng tính năng ECN khi truyền tin thì yêu cầu các router/switch trung gian phải hỗ trợ ECN Các router/switch trung gian này áp dụng chính sách quản lý hàng đợi để xác định xem khi nào thì bắt đầu đánh dấu gói tin Một trong những chính sách quản lý hàng đợi đƣợc sử dụng là RED [Random Early Detection Gateways for Congestion Avoidance, IEEE/ACM Transactions on Networking, V.1 N.4]
Hình 12 – Chính sách quản lý hàng đợi RED
Chính sách đánh dấu gói tin tại router/switch dựa trên chiều dài trung bình của hàng đợi, trong đó RED thiết lập hai ngưỡng min_th và max_th Khi chiều dài trung bình hàng đợi w nằm trong khoảng (min_th, max_th), gói tin sẽ bị đánh dấu ngẫu nhiên với xác suất p Tuy nhiên, nếu w vượt quá max_th, tất cả các gói tin đến sẽ bị đánh dấu.
2.2.4 WRED - Weighted Random Early Detection
WRED hỗ trợ phát hiện tắc nghẽn sớm qua các lớp dữ liệu được phân loại theo DSCP Nó xác định giá trị min_th và max_th cho từng giá trị DSCP (IP Precedence) riêng biệt.
Hình 13 – Chính sách quản lý hàng đợi WRED
DCTCP – Giao thức TCP điển hình cho môi trường Data Center
DCTCP (Data Center TCP) là giao thức tối ưu cho TCP trong môi trường Data Center, giúp duy trì hàng đợi nhỏ tại các switch trung gian Điều này đảm bảo độ trễ thấp và giảm thiểu mất gói, đồng thời vẫn duy trì thông lượng cao với yêu cầu bộ nhớ đệm nhỏ cho switch.
Thuật toán TCP truyền thống phản ứng với tình trạng tắc nghẽn bằng cách giảm một nửa cửa sổ tắc nghẽn khi phát hiện có tắc nghẽn Ngược lại, DCTCP điều chỉnh cửa sổ tắc nghẽn dựa trên mức độ tắc nghẽn, cho phép bên gửi giảm cửa sổ một cách tương ứng với mức độ tắc nghẽn hiện tại.
DCTCP đạt hiệu quả cao nhờ vào tính năng ECN trên các switch, giúp nhận diện rõ ràng các cảnh báo về tắc nghẽn trong mạng Điều này cho phép DCTCP phản ứng nhanh chóng và kịp thời đối với tình trạng tắc nghẽn.
2.3.1 Chính sách quản lý hàng đợi tại switch
Chính sách RED trong DCTCP được thiết lập với sự đơn giản, chỉ sử dụng một tham số duy nhất là ngưỡng đánh dấu K Cụ thể, min_th và max_th đều được xác định bằng giá trị K.
Hình 14 – Chính sách hàng đợi RED cho DCTCP
Khi một gói tin đến bị đánh dấu vỡi mã CE trong phần IP Header, điều này cho thấy rằng hàng đợi bộ nhớ đệm switch đang bị tắc nghẽn vượt quá ngưỡng K Mức độ tắc nghẽn ảnh hưởng đến số lượng gói tin bị đánh dấu: tắc nghẽn nhẹ sẽ dẫn đến ít gói tin bị đánh dấu, trong khi tắc nghẽn nặng sẽ làm tăng số lượng gói tin bị đánh dấu Do đó, bên gửi có thể dựa vào số lượng gói tin bị đánh dấu để đánh giá quy mô và mức độ tắc nghẽn, từ đó đưa ra phản ứng phù hợp.
2.3.2 Kiểm tra gói tin bị đánh dấu tại bên nhận và thông báo cho bên gửi biết
Khi bên nhận nhận gói tin TCP có mã CE, nó sẽ gửi gói tin ACK với cờ ECE trong phần TCP Header đến bên gửi Quá trình này sẽ tiếp tục cho đến khi bên gửi xác nhận đã nhận thông báo bằng cách thiết lập cờ CWR.
Với giao thức DCTCP, bên nhận chỉ gửi ACK cho số lượng gói tin được đánh dấu CE, giúp bên gửi xác định chính xác số gói tin bị đánh dấu và đánh giá mức độ tắc nghẽn trong mạng.
DCTCP áp dụng kỹ thuật ACK chậm để tiết kiệm băng thông trong việc truyền tải các gói tin ACK Thay vì gửi ACK ngay lập tức, bên nhận sẽ trì hoãn việc gửi ACK.
Trong giao thức DCTCP, bên nhận có thể gộp m gói tin ACK liên tiếp để gửi, với m thường được chọn là 2 Khi nhận được 2 gói tin bị đánh dấu CE hoặc không bị đánh dấu liên tiếp, bên nhận chỉ gửi một ACK kèm theo cờ ECE hoặc không có cờ ECE Để thực hiện điều này, bên nhận cần lưu giữ hai trạng thái để quyết định việc thiết lập cờ ECE trong gói tin ACK gửi đi.
Hình 15 – Hai trạng thái thiết lập cờ ECE cho ACK
Nhƣ vậy, có 2 trạng thái CE để chỉ gói tin cuối cùng mà bên nhận nhận đƣợc có bị đánh dấu CE không
Khi trạng thái CE=0, gói tin nhận trước đó không bị đánh dấu CE Nếu bên nhận tiếp tục nhận gói tin không bị đánh dấu, trạng thái vẫn giữ CE=0 và gửi ACK mà không có cờ ECE Tuy nhiên, nếu nhận gói tin có đánh dấu CE, bên nhận sẽ gửi ACK không có cờ ECE và chuyển sang trạng thái CE=1.
Khi bên nhận ở trạng thái CE=1 và nhận gói tin có đánh dấu CE, nó sẽ tiếp tục ở trạng thái CE=1 và gửi ACK với cờ ECE để thông báo đã nhận được hai gói tin CE liên tiếp Ngược lại, nếu gói tin không bị đánh dấu CE được nhận, bên nhận sẽ gửi ngay ACK có cờ ECE và chuyển sang trạng thái CE=0.
2.3.3 Điều chỉnh kích thước cửa sổ tại bên gửi theo mức độ tắc nghẽn
Bên gửi ước lượng tỷ lệ gói tin bị đánh dấu là α, được cập nhật sau mỗi khoảng thời gian 1 RTT theo công thức: α ← (1 – g)α + gF, trong đó F là tỷ lệ gói tin bị đánh dấu CE trong khoảng thời gian 1 RTT trước đó.
Giá trị g thuộc khoảng (0,1) là trọng số mang ý nghĩa ảnh hưởng của F lên giá trị mới của α Ý nghĩa của giá trị α
Giá trị của α nằm trong khoảng (0,1) Ở đây ta xem mạng tắc nghẽn là khi hàng đợi của bộ nhớ đệm switch có chiều dài vƣợt quá ngƣỡng K
Khi chiều dài hàng đợi vượt quá ngưỡng K, switch sẽ đánh dấu CE cho các gói tin đến Sự tắc nghẽn trong mạng càng lớn, tỷ lệ gói tin bị đánh dấu càng cao, và giá trị α sẽ dần tiến gần đến 1.
Khi chiều dài hàng đợi nhỏ hơn K, switch không đánh dấu các gói tin đến, dẫn đến tỷ lệ gói tin bị đánh dấu bằng 0 Điều này có nghĩa là trong điều kiện mạng không tắc nghẽn, giá trị α sẽ giảm dần đến 0.
Nhƣ vậy có thể xem giá trị α là ƣớc lƣợng xác suất mà mạng bị tắc nghẽn
Phản ứng của bên gửi khi có tắc nghẽn
Khi sử dụng TCP với hỗ trợ ECN, nếu bên gửi nhận được ACK có cờ ECE, nó sẽ giảm cửa sổ tắc nghẽn xuống một nửa Việc giảm này chỉ diễn ra một lần trong mỗi khoảng thời gian RTT.
Đánh giá về DCTCP
Khi nhiều luồng nhỏ gửi đến một nút nhận, cổng giao tiếp với switch có thể gặp tắc nghẽn Nếu số lượng luồng rất lớn và mỗi luồng chỉ truyền một gói tin, hàng đợi của buffer switch sẽ nhanh chóng đầy Trong tình huống này, không chỉ DCTCP mà bất kỳ thuật toán quản lý tắc nghẽn nào cũng khó có thể kiểm soát lưu lượng mà không làm mất gói.
Một vấn đề của DCTCP là thời gian cần thiết để một luồng mới chia sẻ băng thông với các luồng hiện tại DCTCP duy trì mức chiếm giữ hàng đợi xung quanh ngưỡng K, dẫn đến việc luồng mới cần thời gian dài hơn để đạt tốc độ truyền ổn định so với TCP Tuy nhiên, trong môi trường Data Center, hầu hết các luồng là nhỏ và truyền trong thời gian ngắn, trong khi chỉ có một số ít luồng lớn truyền lâu hơn, do đó các luồng lớn thường được ưu tiên lưu lượng.
Lượng truyền tải trong các luồng hiện tại cao hơn nhiều so với thời gian trễ, do đó, thời gian gia nhập vào các luồng này không bị ảnh hưởng nhiều Đối với các luồng nhỏ, số lượng gói tin truyền đi ít, nên chỉ sau vài RTT, quá trình truyền đã hoàn thành Mặc dù thời gian truyền của luồng nhỏ cao hơn so với TCP, nhưng giá trị RTT trong môi trường Data Center rất nhỏ (< 250 µs), vì vậy khoảng thời gian trễ chỉ kéo dài không quá vài ms.
Kết luận
Trong chương 2, chúng tôi đã phân tích các đặc điểm nổi bật của môi trường tính toán trong Data Center và chỉ ra sự khác biệt so với mạng WAN thông thường Giao thức DCTCP, với thuật toán quản lý tắc nghẽn mới dựa trên tính năng ECN từ các router/switch hiện đại, cho thấy ưu điểm vượt trội so với giao thức TCP trong môi trường Data Center Ở chương tiếp theo, chúng tôi sẽ đề xuất các phương án cải tiến cho giao thức DCTCP.
GIẢI PHÁP CẢI TIẾN TCP TRONG MÔI TRƯỜNG DATA
Phương án cải tiến DCTCP
Trong giải thuật DCTCP, cửa sổ gửi của bên gửi được điều chỉnh dần dần dựa trên trạng thái tắc nghẽn tại switch Các luồng lớn truyền lâu dài sẽ chiếm ưu thế băng thông, và khi có luồng mới gia nhập, băng thông sẽ được chia sẻ từ từ do trạng thái ổn định (Steady State), dẫn đến thời gian truyền có thể kéo dài hơn.
Trạng thái dần dần của tham số điều chỉnh cửa sổ tắc nghẽn α được tính theo công thức α = (1-g)α + gF, với trọng số g = 1/16 Sự thay đổi giá trị α diễn ra chậm chạp, ảnh hưởng bởi tình trạng tắc nghẽn có xảy ra hay không.
Các luồng lớn kéo dài sẽ chiếm băng thông, làm giảm tốc độ truyền cho các luồng nhỏ mới tham gia Điều này dẫn đến thời gian truyền tăng lên, đặc biệt là với các luồng nhỏ Để khắc phục hạn chế của thuật toán DCTCP, cần thiết phải có sự ưu tiên khác nhau giữa các luồng, giúp chúng nhanh chóng nhận được băng thông cần thiết.
Trước khi đề xuất cải tiến cho giải thuật DCTCP, chúng ta cần xem xét một giải thuật khác có tên D2TCP (Deadline-Aware Datacenter TCP), được xây dựng dựa trên DCTCP nhưng bổ sung thêm yếu tố ưu tiên cho luồng dữ liệu.
3.1.1 Giải thuật D2TCP Độ ƣu tiên của luồng đƣợc xác định tùy thuộc vào luồng có yêu cầu thời gian deadline không Thời gian deadline là khoảng thời gian lớn nhất mà luồng phải truyền xong
Chỉ số ƣu tiên d của một luồng đƣợc xác định dựa trên thời gian deadline:
Với các luồng nhỏ yêu cầu thời gian deadline thì chỉ số ƣu tiên d > 1
Với các luồng nhỏ không yêu cầu thời gian deadline hoặc các luồng lớn không yêu cầu thời gian deadline chỉ số ƣu tiên d ≤ 1
Giá trị của d được xác định trong khoảng (1/n, n) với n là số nguyên dương
Giống như DCTCP, thuật toán D2TCP ước lượng giá trị α dựa trên xác suất hàng đợi của switch vượt ngưỡng bằng công thức α = (1-g)α + gF Khi xảy ra tắc nghẽn, thuật toán sẽ giảm cửa sổ gửi đi theo công thức cwnd = cwnd (1 - /2) Nếu d ≤ 1, giá trị sẽ lớn hơn α, trong khi nếu d > 1, giá trị sẽ nhỏ hơn α.
Đối với các luồng nhỏ có yêu cầu thời gian deadline, khi xảy ra tắc nghẽn trong mạng, tốc độ gửi tin (cửa sổ tắc nghẽn CWND) có thể được duy trì hoặc không thay đổi.
Khi xảy ra tắc nghẽn, các luồng lớn hoặc nhỏ không yêu cầu thời gian deadline sẽ giảm tốc độ gửi tin một cách đáng kể và chia sẻ băng thông đường truyền nhiều hơn, trong khi đó, sự giảm đi không đáng kể ở các luồng khác.
Giải thuật D2TCP vượt trội hơn DCTCP nhờ khả năng xác định rõ độ ưu tiên của các luồng, giúp luồng có độ ưu tiên cao nhận được nhiều băng thông hơn và giảm thời gian truyền Tuy nhiên, D2TCP yêu cầu thay đổi ở tầng giao vận, hỗ trợ ECN từ các switch và thay đổi ở tầng ứng dụng, khiến việc triển khai trở nên phức tạp Điều mong muốn là giảm thiểu sự thay đổi trong các thành phần kiến trúc mà vẫn đạt được mục tiêu DCTCP là một giải thuật nổi bật trong môi trường Data Center, mang lại hiệu quả tốt hơn so với TCP truyền thống Do đó, cần xem xét cải tiến DCTCP ở tầng giao vận mà không tác động đến các thành phần khác.
Trong giải thuật DCTCP, cần ưu tiên giữa các luồng để các luồng lớn giảm tốc độ gửi, nhường băng thông cho các luồng nhỏ, vốn yêu cầu thời gian truyền thấp Tuy nhiên, không thể xác định luồng mới là lớn hay nhỏ mà không có thông tin từ lập trình viên Giải pháp là xem luồng mới là luồng nhỏ và cấp băng thông cho nó trong một khoảng thời gian ngắn t0 Nếu luồng đó thực sự là luồng nhỏ, nó sẽ hoàn thành truyền trong thời gian ưu tiên t0; nếu là luồng lớn, từ thời điểm đó, nó sẽ không còn được ưu tiên khi truyền nữa.
Giải thuật DCTCP-F được phát triển dựa trên nguyên tắc của DCTCP, nhằm phản ứng hiệu quả với tình trạng tắc nghẽn và tập trung vào việc cải thiện khả năng chia sẻ băng thông công bằng giữa các luồng dữ liệu.
Giải thuật DCTCP yêu cầu Sender ước lượng tỷ lệ gói tin bị đánh dấu, ký hiệu là α Giá trị α được cập nhật sau mỗi khoảng thời gian 1 RTT theo công thức: α ← (1 – g)α + gF, trong đó F là tỷ lệ gói tin bị đánh dấu CE trong khoảng thời gian 1 RTT trước đó.
Giá trị g trong khoảng (0,1) đóng vai trò là trọng số, thể hiện mức độ ảnh hưởng của F đến giá trị mới của α Trong khi đó, α được hiểu là ước lượng xác suất xảy ra tình trạng tắc nghẽn trong mạng.
Dựa trên ý tưởng của hàm gamma α d với d là chỉ số ưu tiên như trong D2TCP, thuật toán DCTCP đã giới thiệu khái niệm độ ưu tiên p (Priority) cho các luồng, được xác định theo cách cụ thể.
Trong khoảng thời gian t 0 ban đầu thì luồng có độ ƣu tiên p = p max > 1
Sau khoảng thời gian t 0 đó thì độ ƣu tiên của luồng giảm dần cho đến p min > 0
Ta xác định t 0 nhƣ sau:
Theo thống kê từ nghiên cứu Data Center TCP (DCTCP) tại SIGCOMM 2010, các luồng nhỏ yêu cầu độ trễ thấp có kích thước từ 2KB đến 100KB, trong khi các luồng lớn có kích thước từ 1MB đến 100MB Điều này cho thấy rằng tại thời điểm luồng truyền đạt được 100KB dữ liệu, hiệu suất truyền tải có thể được tối ưu hóa.
Hình 17 - Sự phụ thuộc của độ ƣu tiên của luồng theo kích cỡ luồng
Kết luận
Trong chương 3, chúng ta đã xem xét các phương án cải tiến DCTCP và giới thiệu giải thuật mới DCTCP-FA, được phát triển từ ý tưởng của DCTCP-F, kết hợp với độ ưu tiên luồng và giá trị DSCP lớp 3 Ở chương tiếp theo, chúng ta sẽ tiến hành thực nghiệm mô phỏng các giải thuật này.
THỰC NGHIỆM ĐÁNH GIÁ GIẢI THUẬT DCTCP
Xử lý TCP trong nhân Linux
Trong phần Networking của nhân Linux, có hai cấu trúc dữ liệu quan trọng là sock, dùng để duy trì trạng thái của kết nối, và sk_buff, được sử dụng để lưu trữ dữ liệu cũng như trạng thái của các gói tin đến và đi.
Most of the TCP algorithm's source code is located in the net/ipv4 directory, while header files can be found in the include/linux and include/net directories The congestion control algorithm primarily resides in the following files.
tcp_input.c : làm nhiệm vụ xử lí khi có các gói tin đến
tcp_output.c: làm nhiệm vụ xử lí khi cần gửi các gói tin đi
tcp.h: khai báo các biến, hằng số
Hình 22 – Sơ đồ xử lý TCP trong nhân Linux
Khi nhận được gói tin từ tầng IP, hàm ip_local_delivery() được kích hoạt để xử lý các thủ tục TCP Giao thức liên quan đến gói tin sẽ được xác định và gọi hàm xử lý tương ứng Đối với IPv4, hàm tcp_v4_rcv() sẽ được sử dụng và sau đó gọi hàm tcp_v4_do_rcv() để tiếp tục xử lý.
Tùy thuộc vào trạng thái của kết nối, hàm tương ứng sẽ được gọi Khi kết nối đã được thiết lập (TCP_ESTABLISHED), hàm tcp_rcv_established() sẽ được kích hoạt để thực hiện các bước cần thiết.
B1: Kiểm tra checksum của gói tin, nếu không đúng thì bỏ qua
B2: Kiểm tra số thứ tự của gói tin, nếu không đúng thứ tự thì gửi đi 1 DupACK với hàm tcp_send_dupack()
B3: Kiểm tra bit RST, nếu có thì gọi hàm tcp_reset() để thiết lập lại kết nối
B4: Kiểm bit SYN, nếu có thì gọi hàm tcp_reset()
B5: Kiểm tra bit ACK, nếu có thì đây là gói tin ACK và gọi hàm tcp_ack()
B6: Kiểm tra bit URG, nếu có thì gọi hàm tcp_urg() để thông báo rằng dữ liệu đang đến là khẩn cấp
B7: Xử lí dữ liệu trong gói tin bằng cách gọi hàm tcp_data_queue()
B8: Nếu có dữ liệu cần gửi đi thì gọi hàm tcp_data_snd_check() Hàm này sẽ gọi đến tcp_write_xmit() trong file tcp_output.c
To send an ACK, utilize the function tcp_ack_snd_check() For immediate transmission, call tcp_send_ack(), while for delayed sending, use tcp_send_delayed_ack().
Thông tin về ECN được lưu trữ trong trường tp→ecn_flags Khi trường ECN trong IP Header của gói tin được thiết lập, bên nhận sẽ kích hoạt cờ ECE trong TCP Header của gói tin ACK được gửi đi.
Hàm TCP_ECN_check_ce() kiểm tra trường ECN và được gọi từ các hàm tcp_event_data_recv() và tcp_data_queue().
Trong 47 trường ECN, bit TCP_ECN_DEMAND_CWR được thiết lập trong trường tp→ecn_flags Bit này có ý nghĩa là bên nhận sẽ tiếp tục gửi các gói tin ACK kèm cờ ECE cho đến khi nhận được bit CWR trong phần TCP Header của gói tin từ bên gửi.
Khi Sender nhận gói tin ACK, nó kiểm tra cờ ECE trong phần TCP Header qua hàm TCP_ECN_rcv_ecn_echo() được gọi từ tcp_ack() Nếu cờ ECE được đặt, Sender sẽ chuyển sang trạng thái TCP_CA_CWR thông qua hàm tcp_enter_cwr() gọi từ tcp_try_to_open() Tại đây, hàm TCP_ECN_queue_cwr() sẽ thiết lập bit TCP_ECN_QUEUE_CWR trong trường hợp tp→ecn_flags.
Trong quá trình gửi gói tin mới, Sender sẽ quyết định có cần đặt cờ CWR trong TCP Header hay không bằng cách gọi hàm TCP_ECN_send() từ tcp_transmit_skb() để kiểm tra bit TCP_ECN_QUEUE_CWR trong tp→ecn_flags Sau khi gói tin được gửi với bit CWR, Sender sẽ xóa bit TCP_ECN_QUEUE_CWR trong tp→ecn_flags.
Cài đặt giải thuật cải tiến DCTCP-FA
Các giải thuật TCP được tích hợp trong phần Networking của nhân Linux, cho phép người dùng tùy chỉnh nhờ mã nguồn mở Để cài đặt giải thuật DCTCP-FA, trước tiên cần tìm hiểu về các giải thuật TCP có trong mã nguồn nhân Linux phiên bản 3.2.18.
Giống nhƣ giải thuật DCTCP, về cơ bản giải thuật mới đề xuất này giữ nguyên hầu hết các pha trong mô hình quản lý tắc nghẽn của TCP
Khi bên nhận trong giao thức TCP nhận được các gói tin có cờ CE trong phần IP Header, nó sẽ phản hồi bằng cách gửi các gói tin ACK kèm theo cờ ECE trong phần TCP Header.
48 cho đến nào khi nhận đƣợc phản hồi là cờ CWR trong phần TCP Header thông báo rằng Sender đã giảm cửa sổ tắc nghẽn
Giải thuật DCTCP-FA, tương tự như DCTCP, cho phép bên nhận gửi ACK với cờ ECE tương ứng với số lượng gói tin bị đánh dấu cờ CE trong phần IP Header Bên nhận sử dụng kỹ thuật gửi ACK gộp, nghĩa là nếu nhận được hai gói tin bị đánh dấu CE liên tiếp, chỉ gửi một ACK với cờ ECE Ngược lại, nếu nhận được hai gói tin không bị đánh dấu liên tiếp, chỉ gửi một ACK không có cờ ECE Hàm TCP_ECN_check_ce() sẽ được thay thế bằng hàm TCP_ECN_dctcp_check_ce() để kiểm tra bit CE trong phần IP Header.
Algorithm 1: TCP_ECN_dctcp_check_ce( ) if IP_flags is CE if ce_state=0 and ACK is delayed send ACK of previous packet without ECE set ce_state=1 set CWR in TCP_flags else if ce_state=1 and ACK is delayed send ACK of previous packet with ECE ce_state = 0 set not CWR in TCP_flags Để sử dụng kĩ thuật ACK gộp, một biến ce_state được sử dụng để lưu trạng thái của gói tin vừa nhận có bị đánh dấu CE trong phần IP Header không
Tính toán độ ƣu tiên
Khi nhận gói tin ACK có cờ ECE, bên nhận sẽ không giảm cửa sổ gửi đi một nửa như trong thuật toán TCP, mà thay vào đó, nó sẽ giảm theo giá trị α p, biểu thị mức độ tắc nghẽn trong mạng và độ ưu tiên của luồng.
Giá trị α đƣợc tính theo công thức: α = (1-g)α + gF, trong đó g=1/16 còn F là tỷ lệgói tin bị đánh dấu CE trong phần IP Header
Nhân Linux được phát triển bằng ngôn ngữ C, nhưng không sử dụng các thư viện chuẩn của C, dẫn đến việc một số hàm chuẩn không được hỗ trợ Do đó, các phép toán như tính toán dấu phẩy động và hàm mũ không được phép sử dụng trong nhân Linux.
Vì vậy, các giá trị của α, F, p đƣợc tính và biểu diễn theo thang 1024
Hàm tcp_ack() kiểm tra các gói tin ACK, cho phép tính toán tỷ lệ gói tin bị đánh dấu ECN thông qua tỷ lệ gói tin ACK có cờ ECE trong TCP Header Giá trị α được cập nhật sau mỗi khoảng thời gian RTT, đồng thời chúng ta cũng tính toán lượng thông tin mà luồng đã truyền (flow_size), từ đó xác định độ ưu tiên của luồng (flow_priority) Chi tiết về giải thuật được minh họa dưới đây.
Algorithm 2: tcp_ack() if TCP_flag is ECE acked_bytes_ecn += acked_bytes; acked_bytes_total += acked_bytes; flow_size += acked_bytes; if flow_size < 200KB flow_priority = pmax; else if flow_size > 1MB
50 flow_priority = pmin; else flow_priority = pmin + (pmax- pmin)(1000-pmin)/800; if RTT expired
F = ack_bytes_ecn*1024/ acked_bytes_total; alpha = alpha + (F-alpha)/16;
Khi xảy ra tắc nghẽn, bên gửi sẽ nhận các gói tin ACK được đánh dấu ECE trong phần tiêu đề TCP Trong mỗi khoảng thời gian RTT, bên gửi chỉ giảm cửa sổ tắc nghẽn một lần duy nhất thông qua hàm tcp_enter_cwr().
Giá trị của cửa sổ tắc nghẽn (cwnd) khi giảm được tính theo công thức: cwnd = cwnd (1 - α p / 2) Công thức này sử dụng xấp xỉ Bernoulli để tính toán Giải thuật minh họa cho quá trình này được trình bày dưới đây.
Algorithm 3: tcp_enter_cwr() cwnd=cwnd–cwnd*alpha/(2*(alpha+priority)-alpha*priority/512) snd_cwnd = max(cwnd,2);
Sau khi điều chỉnh mã nguồn của thuật toán TCP trong nhân Linux phiên bản 3.2.18, chúng tôi đã tạo ra một bản Patch bằng công cụ diff Bản Patch này cho phép áp dụng những thay đổi của thuật toán mới vào mã nguồn gốc Tiếp theo, chúng tôi tiến hành biên dịch mã nguồn để cài đặt thuật toán mới, tương tự như DCTCP.
Công cụ mô phỏng Mininet
Mininet là một trình giả lập mạng mạnh mẽ, cho phép người dùng dễ dàng tạo ra các thiết bị đầu cuối, switch, router và kết nối mạng Bằng cách sử dụng công nghệ ảo hóa, Mininet xây dựng một mạng hoàn chỉnh chạy trên cùng một nhân Linux, tích hợp cả các chương trình hệ thống và chương trình người dùng Mỗi host trong Mininet hoạt động tương tự như một thiết bị mạng thực thụ, mang lại trải nghiệm thực tế cho người dùng.
Máy tính ảo trong Mininet cho phép người dùng SSH vào và chạy các chương trình tùy ý, tương tự như trên một thiết bị thật Các chương trình này có khả năng gửi gói tin qua giao diện Ethernet với tốc độ kết nối và độ trễ giống như thiết bị thật Gói tin được xử lý qua các thiết bị mạng như switch và router, đồng thời có tính năng hàng đợi Khi các chương trình giao tiếp, ví dụ như iperf trên client và server trong Mininet, hiệu suất đo được tương đương với khi chạy trên máy thật.
Mininet là một công cụ mạnh mẽ cho phép tạo ra một mạng ảo giống hệt như mạng phần cứng thực tế, bao gồm các thiết bị như host, switch, router và controller Các chương trình và mã nguồn chạy trên Mininet có thể dễ dàng chuyển sang mạng phần cứng mà không gặp vấn đề gì Điều này giúp các nhà phát triển và nghiên cứu viên kiểm tra và phát triển ứng dụng mạng một cách hiệu quả, mang lại nhiều lợi ích trong việc tối ưu hóa và thử nghiệm mạng.
Nhanh chóng tạo ra một mạng đơn giản giúp người dùng dễ dàng thực hiện các thử nghiệm, chỉnh sửa và sửa lỗi một cách hiệu quả.
Người dùng có thể tạo ra các hình thái mạng khác nhau, tùy theo mục đích
Người dùng có thể chạy các chương trình thực tế trên Mininet, bao gồm mọi ứng dụng hỗ trợ Linux như Webserver, công cụ giám sát TCP và Wireshark.
Người dùng có thể chạy Mininet trên laptop, server, máy ảo hay trên đám mây
Sử dụng dễ dàng: người dùng có thể thực hiện các thí nghiệm về mạng trên Mininet sử dụng các đoạn mã Python
Mininet là một dự án mã nguồn mở
Khi sử dụng Mininet để chạy hệ thống mạng trên một máy tính đơn, người dùng sẽ cảm thấy tiện lợi, nhưng điều này cũng dẫn đến việc hạn chế tài nguyên Cụ thể, CPU và bộ nhớ phải được chia sẻ và cân bằng giữa các host và switch ảo, gây ảnh hưởng đến hiệu suất hoạt động.
Mininet chỉ sử dụng một nhân Linux duy nhất cho tất cả các host ảo, do đó không thể cấu hình mạng với các host chạy hệ điều hành hoặc nhân khác nhau.
Hiệu quả của Mininet bị hạn chế do các gói tin được chuyển qua các switch phần mềm (OpenvSwitch) chia sẻ tài nguyên CPU và bộ nhớ, dẫn đến hiệu suất thấp hơn so với thiết bị phần cứng Kết quả là tốc độ kết nối trong mạng Mininet thường bị giới hạn, với các kết nối thường sử dụng băng thông 10Mbps hoặc 100Mbps thay vì 10Gbps Để đảm bảo độ chính xác, cần phải giới hạn tài nguyên CPU cho mỗi host trong mạng.
Cài đặt môi trường thử nghiệm DCTCP
DCTCP cung cấp mã nguồn cho thuật toán quản lý tắc nghẽn thông qua bản vá nhân Linux, cho phép thử nghiệm hiệu quả của DCTCP so với TCP truyền thống Để thực hiện các thử nghiệm này, cần tiến hành theo các bước cụ thể.
Cài đặt hệ điều hành Ubuntu 12.04.4 trên máy ảo hoặc máy thật
Cài đặt giải thuật quản lý tắc nghẽn DCTCP vào nhân Linux
Sau khi khởi động lại và chọn boot vào nhân mà vừa cài đạt giải thuật DCTCP, ta cần cài đặt công cụ Mininet cho phép mô phỏng mạng.
Thực nghiệm khảo sát các tính chất của DCTCP
Để đánh giá các tính chất của DCTCP, chúng tôi thực hiện một thử nghiệm đơn giản trên mạng gồm ba nút A, B, C kết nối với một switch Trong kịch bản này, chúng tôi sẽ xem xét kích thước hàng đợi tại switch, thông lượng truyền và khả năng điều chỉnh cửa sổ tắc nghẽn của các bên gửi.
Hình 24 – Mạng mô phỏng 3 nút
Liên kết giữa switch và các nút trong mô phỏng có băng thông 100Mbps và độ trễ 2ms Để đảm bảo độ tin cậy của kết quả mô phỏng trong Mininet, cần điều chỉnh băng thông của các liên kết, sử dụng giá trị nhỏ hơn so với thực tế trong môi trường Data Center, thay vì 1Gbps hay 10Gbps.
Các liên kết giữa nút và switch có delay 2ms nên thời gian RTT giữa các nút từng đôi một là: RTT ≈ 2(2+2) = 8 ms
Switch có bộ nhớ đệm tối đa 425 gói tin và ngưỡng đánh dấu K là 30 gói tin, với kích thước mỗi gói tin là 1500 Bytes Khi chiều dài hàng đợi vượt quá ngưỡng K, các gói tin đến sẽ bị đánh dấu CE trong trường IP Header.
Trên 2 nút A, B ta tạo ra 2 luồng lớn cùng gửi đến nút C, bằng công cụ Iperf.Tổng băng thông của 2 luồng gửi lớn hơn băng thông của liên kết giữa nút C với switch nên liên kết này đƣợc gọi là Bottleneck-link (thắt cổ chai) Thời gian thực hiện là 120s, sử dụng các công cụ giám sát Monitor tích hợp sẵn trong Mininet để lưu các số liệu và biểu diễn trên đồ thị Ta nhận đƣợc các kết quả sau:
Thuật toán TCP truyền thống cho phép bên gửi kiểm tra khả năng chứa gói tin của mạng bằng cách tăng dần số lượng gói tin gửi trong một khoảng thời gian RTT cho đến khi đạt được giới hạn tối ưu.
Khi hiện tượng mất gói xảy ra, chiều dài hàng đợi đạt tối đa kích thước bộ nhớ đệm của switch, dẫn đến việc các gói tin đến bị bỏ đi Để khắc phục, Sender sẽ giảm tốc độ gửi xuống một nửa TCP Sender luôn tận dụng tối đa khả năng lưu giữ gói tin tại bộ nhớ đệm của switch, khiến chiều dài hàng đợi tại switch luôn lớn và số lượng gói tin trong hàng đợi dao động xung quanh 425 gói tin.
Hình 25 – So sánh chiều dài hàng đợi giữa TCP và DCTCP
Giải thuật DCTCP duy trì hàng đợi tại switch quanh ngưỡng K = 30 gói tin Khi hàng đợi vượt quá K, các gói tin gửi đến sẽ bị đánh dấu bởi ECN, dẫn đến việc DCTCP Sender nhận cảnh báo và giảm tốc độ gửi.
Như vậy, giải thuật DCTCP cho phép sử dụng các switch có kích thước bộ nhớ đệm nhỏ - giảm chi phí trong khi vẫn cho hiệu quả tương đương
Thuật toán TCP thông thường cho phép người gửi kiểm tra khả năng lưu trữ gói tin của switch cho đến khi bộ nhớ đệm của switch đầy, sau đó giảm tốc độ gửi đi một nửa Điều này dẫn đến việc các TCP Sender gửi nhiều gói tin, tối ưu hóa băng thông của liên kết thắt cổ chai Nhờ vậy, TCP đạt được thông lượng tối đa trong quá trình truyền tải.
Hình 26 – So sánh throughput giữa TCP và DCTCP
Giải thuật DCTCP đạt thông lượng truyền tải cao, gần 99%, tương đương với TCP thông thường nhờ vào việc duy trì mức chiếm giữ hàng đợi nhỏ tại switch Điều này giúp giảm thiểu hiện tượng mất gói và điều chỉnh mức độ giảm của cửa sổ gửi của Sender theo tình trạng tắc nghẽn tại switch.
4.5.3 Sự thay đổi kích thước của cửa sổ tắc nghẽn CWND
Thuật toán TCP thông thường cho phép Sender kiểm tra khả năng lưu trữ gói tin của switch, và khi bộ nhớ đệm của switch đầy, tốc độ gửi sẽ giảm một nửa Do đó, cửa sổ tắc nghẽn của TCP Sender có hình răng cưa để phản ánh trạng thái này.
Hình 27 – So sánh sự thay đổi cwnd của TCP và DCTCP
Giải thuật DCTCP tận dụng tính năng ECN của switch, cho phép các Sender dự đoán tình trạng tắc nghẽn một cách rõ ràng Khi xảy ra tắc nghẽn, với chiều dài hàng đợi vượt quá ngưỡng K, các Sender sẽ điều chỉnh tốc độ giảm một cách linh hoạt, thay vì giảm đột ngột như trong TCP Điều này giúp cửa sổ tắc nghẽn của DCTCP Sender thay đổi một cách đều đặn và dần dần, duy trì trạng thái ổn định.
Thực nghiệm hạn chế của giải thuật DCTCP Fair Sharing
Thuật toán TCP truyền thống giảm cửa sổ gửi đi một nửa khi nhận thông báo tắc nghẽn, tạo ra đồ thị với hình dạng răng cưa và sự thay đổi đột ngột Ngược lại, DCTCP điều chỉnh cửa sổ gói tin dựa trên mức độ tắc nghẽn, dẫn đến sự thay đổi cửa sổ gửi diễn ra đều đặn và dần dần hơn.
Sự thay đổi dần dần này làm tăng thời gian cần thiết để đạt được trạng thái Fair Sharing, tức là trạng thái mà các luồng đều nhận được băng thông như nhau Để làm rõ điều này, chúng ta sẽ tiến hành một thử nghiệm.
Mô hình mạng thử nghiệm bao gồm ba máy chủ (cài đặt DCTCP) kết nối với một switch, trong đó hai máy chủ đóng vai trò là sender và một máy chủ là receiver Trên máy chủ 1, một luồng dữ liệu lớn được gửi đến receiver bằng công cụ Iperf Sau khi máy chủ 1 gửi dữ liệu trong 5 giây, máy chủ 2 cũng bắt đầu tạo một luồng dữ liệu lớn để gửi đến receiver.
Trong 5s đầu cửa sổ tắc nghẽn của host 1 tăng dần rồi đạt trạng thái max và dao động quanh đó
Sau 5 giây, khi host 2 tham gia, cửa sổ tắc nghẽn của host 1 dần giảm, trong khi cửa sổ tắc nghẽn của host 2 tăng lên Tuy nhiên, cuối cùng cả hai vẫn không đạt được trạng thái chia sẻ công bằng (Fair-sharing).
Khi số lượng luồng lớn gia tăng, mạng dễ bị tắc nghẽn do các luồng này chiếm dụng băng thông, dẫn đến việc cần giảm cửa sổ tắc nghẽn để tạo điều kiện cho các luồng khác Tuy nhiên, trong môi trường Data Center, số lượng luồng lớn lại rất hạn chế, vì vậy việc tối ưu hóa chia sẻ băng thông trở nên quan trọng hơn bao giờ hết.
DCTCP cho phép chia sẻ băng thông chậm hơn so với TCP khi một luồng lớn chiếm ưu thế trên đường truyền Điều này dẫn đến khả năng chia sẻ băng thông cho các luồng mới bị hạn chế.
58 biệt đối với các luồng nhỏ thì điều này có thể dẫn đến việc thời gian truyền tăng lên và chất lƣợng của ứng dụng bị giảm xuống.
Thực nghiệm và đánh giá DCTCP-FA
Để đánh giá hiệu quả của giải thuật DCTCP-FA, cần đảm bảo rằng nó duy trì các đặc tính của DCTCP cũ, như chiều dài hàng đợi switch ngắn và tối ưu hóa băng thông Đồng thời, việc kiểm tra thời gian truyền của các luồng và khả năng chia sẻ băng thông giữa các luồng cũng rất quan trọng.
4.7.1 Chiều dài hàng đợi tại switch và thông lƣợng truyền
Trong thử nghiệm này, chúng tôi sử dụng một mô hình mạng với các nút 1, 2, 3,… n được kết nối đến một 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à switch có băng thông 100Mbps và độ trễ 2ms, trong khi switch có bộ nhớ đệm tối đa 425 gói tin Chúng tôi tạo ra các luồng lớn từ các nút 2, 3,… n gửi dữ liệu đến nút 1 thông qua công cụ iperf Dựa vào số liệu thu thập từ switch, chúng tôi có thể biểu diễn chiều dài hàng đợi của switch theo thời gian cùng với 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 giữ lại những ưu điểm nổi bật của DCTCP, giúp giảm thiểu tình trạng tắc nghẽn Khi hàng đợi tại switch vượt quá ngưỡng K, các Sender sẽ nhận được thông báo và tự động điều chỉnh tốc độ gửi dữ liệu để tránh gây ra tắc nghẽn, từ đó duy trì mức chiếm giữ hàng đợi tại switch ở mức thấp.
Hình 29 – Mức chiểm giữ hàng đợi tại Switch DCTCP-FA
Trong giải thuật đề xuất, khi xảy ra tắc nghẽn, các Sender không giảm cửa sổ tắc nghẽn một nửa như trong TCP, mà giảm theo mức độ tắc nghẽn thông qua giá trị α, được ước lượng sau mỗi RTT Điều này giúp giảm thiểu tình trạng mất gói tin, cho phép các Sender không phải dừng lại để chờ truyền lại gói tin như trong TCP, từ đó tối ưu hóa băng thông đường truyền Tuy nhiên, thông lượng bị ảnh hưởng do giải thuật này yêu cầu các luồng lớn phải giảm cửa sổ tắc nghẽn nhiều hơn khi truyền trong thời gian dài.
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 có ảnh hưởng quan trọng đến hiệu quả của thuật toán truyền dữ liệu Nếu K quá nhỏ, các Sender sẽ gặp cảnh báo tắc nghẽn sớm, dẫn đến giảm tốc độ gửi và giảm thông lượng Ngược lại, nếu K quá lớn, thông lượng có thể tăng nhưng không đáng kể, và hàng đợi sẽ kéo dài, làm tăng thời gian chờ cho các gói tin, đặc biệt là với các luồng nhỏ Để đánh giá tác động của ngưỡng K đến thông lượng trong kết nối thắt cổ chai (từ switch đến nút nhận), chúng tôi đã thực hiện thử nghiệm trên mô hình mạng với n nút kết nối đến switch, trong đó nút 1 là nút nhận và n-1 nút còn lại tạo ra n-1 luồng lớn gửi đến nút 1 bằng công cụ Iperf.
Thực hiện nhiều lần thí nghiệm với các giá trị n = 3 và n = 9, chúng tôi đã tiến hành đo lƣợng thông qua các kết nối thắt cổ chai Kết quả thu được được thể hiện trong hình vẽ dưới đây.
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 bao gồm ba máy chủ được cài đặt DCTCP, kết nối với một switch; trong đó, hai máy chủ hoạt động như sender và một máy chủ là receiver Máy chủ 1 tạo một luồng dữ liệu lớn gửi đến receiver bằng công cụ Iperf Sau khi máy chủ 1 gửi dữ liệu trong 1 giây, máy chủ 2 cũng bắt đầu gửi một luồng dữ liệu lớn đến receiver.
Kết quả cho thấy giải thuật mới có sự dao động 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 Chia Sẻ Công Bằng.
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 trong những tiêu chí quan trọng để đánh giá hiệu quả của giải thuật quản lý tắc nghẽn là thời gian truyền của một luồng, hay còn gọi là Thời gian Hoàn thành Luồng (FCT) Thời gian này được tính từ khoảnh khắc luồng bắt đầu truyền cho đến khi quá trình truyền hoàn tất.
Trong giải thuật đề xuất, các luồng lớn sẽ giảm cửa sổ gửi để chia sẻ băng thông với các luồng mới, giúp giảm thời gian hoàn thành quá trình truyền cho các luồng nhỏ Để kiểm tra, chúng tôi thực hiện thí nghiệm với mô hình 4 host kết nối với 1 switch hỗ trợ ECN, trong đó 3 host đầu là bên gửi và host 4 là receiver Trên host 1 và host 2, các luồng lớn được tạo ra để gửi đến host 4 bằng công cụ IPERF Sau 5 giây, trên host 3, một luồng nhỏ với kích thước từ 5KB đến 500KB được 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ỏ
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, cho thấy rằng giải thuật đề xuất mang lại hiệu quả vượt trội hơn so với DCTCP ban đầu.
Incast is a phenomenon where multiple small flows simultaneously send data to a single node, commonly observed in data center environments This issue frequently arises in applications that utilize a divide-and-conquer approach, such as MapReduce, which simplifies data processing across large clusters.
Năm 2004, hiện tượng incast xảy ra khi một nút cha (Master) gửi yêu cầu đến nhiều nút con (Slave) và nhận kết quả từ chúng trong khoảng thời gian ngắn Khi nhiều luồng dữ liệu đồng thời gửi về nút cha, bộ nhớ đệm của switch bị lấp đầy do các bên gửi cố gắng sử dụng tối đa dung lượng này Kết quả là, khi bộ nhớ đệm đầy, hiện tượng mất gói xảy ra, gây ảnh hưởng đến hiệu suất truyền tải dữ liệu.
Trong mô hình Phân tách – kết hợp, việc bên gửi phải chờ Timeout để gửi lại gói bị mất có thể làm tăng thời gian truyền Nếu sau một khoảng thời gian quy định, các nút con không trả về kết quả, 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à từ đó tác động đến hiệu suất của ứng dụng sử dụng mô hình này.
Giải thuật DCTCP giúp duy trì hàng đợi nhỏ tại switch, đảm bảo bộ nhớ đệm còn lại để đối phó với hiện tượng incast Để khảo sát incast, chúng tôi thực hiện thử nghiệm với mô hình n nút kết nối đến một switch, trong đó nút 1 là nút nhận và n-1 nút còn lại gửi luồng dữ liệu đến nút 1 Cụ thể, tại nút 2 và nút 3, chúng tôi tạo ra các luồng lớn bằng công cụ Iperf, trong khi từ nút 4 đến nút n, các luồng nhỏ được tạo ra bằng công cụ wget.
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 n5 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
Kết luận
Trong chương 4, chúng tôi đã cài đặt giải thuật DCTCP-FA vào mã nguồn nhân Linux và tiến hành thử nghiệm mô phỏng để đánh giá hiệu quả của nó Giải thuật DCTCP-FA không chỉ kế thừa các tính chất của DCTCP mà còn nâng cao khả năng chia sẻ băng thông giữa các luồng và cải thiện thời gian truyền của luồng.
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:
Bài viết này trình bày giải thuật quản lý tắc nghẽn trong giao thức TCP, tập trung vào DCTCP, một giải thuật điển hình cho môi trường Data Center DCTCP được thiết kế nhằm cải thiện hiệu suất mạng bằng cách giảm độ trễ và tăng cường khả năng sử dụng băng thông Tuy nhiên, giải thuật này cũng tồn tại một số nhược điểm như độ phức tạp trong triển khai và khả năng tương thích với các giao thức khác Việc phân tích ưu và nhược điểm của DCTCP sẽ giúp người đọc hiểu rõ hơn về ứng dụng của nó trong các hệ thống mạng hiện đại.
Đề xuất cải tiến giải thuật DCTCP nhằm chỉ định ưu tiên giữa các luồng gửi, giúp tăng cường khả năng chia sẻ băng thông của đường truyền và giảm thiểu thời gian truyền dữ liệu.
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
Nghiên cứu mã nguồn của thuật toán quản lý tắc nghẽn trong TCP trên nhân Linux, cài đặt thuật toán đề xuất vào mã nguồn và thực hiện mô phỏng để kiểm tra mức độ cải thiện của thuật toán.
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 tiến hành trên hệ thống vật lý lớn mà chỉ sử dụng công cụ mô phỏng trên máy tính, nhằm tái hiện các điều kiện và tình huống 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 và giải thuật ban đầu đều áp dụng tính năng ECN trên các switch/router hiện đại, sử dụng chính sách quản lý hàng đợi RED hoặc WRED với tham số ngưỡng K để đánh dấu Nghiên cứu có thể tiếp tục mở rộng mối quan hệ giữa K và DSCP nhằm tối ưu hóa băng thông sử dụng.
Các giải thuật quản lý tắc nghẽn đã chứng minh hiệu quả trong việc giảm chiều dài hàng đợi của switch, giảm thiểu mất gói và tối ưu hóa băng thông Để xác định mức độ tắc nghẽn, cần có sự hỗ trợ từ tính năng ECN, không phải switch nào cũng tích hợp TCP Vegas cung cấp phương pháp dự đoán tắc nghẽn dựa trên sự thay đổi của thời gian RTT, nhưng chỉ hiệu quả trong môi trường mạng WAN, do thời gian RTT trong Data Center thường rất ngắn, gây khó khăn cho việc ước lượng.
Giải thuật quản lý tắc nghẽn có thể được áp dụng tùy thuộc vào mức độ tắc nghẽn trong môi trường mạng WAN, trong đó mức độ tắc nghẽn được xác định dựa trên sự biến đổi của thời gian RTT.
