CHƯƠNG II : ĐIỀU KHIỂN TẮC NGHẼN CHO GIAO THỨC TCP
2.2. Thông báo tắc nghẽn rõ ràng do mạng hỗ trợ và Kiểm soát tắc nghẽn dựa
dựa trên độ trễ
Kể từ khi tiêu chuẩn hóa ban đầu về khởi động chậm và tránh tắc nghẽn vào cuối những năm 1980 [RFC 1122], TCP đã triển khai hình thức kiểm sốt tắc nghẽn đầu cuối mà chúng ta đã tìm hiểu: người gửi TCP khơng nhận được chỉ báo tắc nghẽn rõ ràng nào từ lớp mạng và thay vào đó gây ra tắc nghẽn thơng qua mất gói được quan sát. Gần đây, các phần mở rộng cho cả IP và TCP [RFC 3168] đã được đề xuất, thực hiện và triển khai cho phép mạng báo hiệu rõ ràng sự tắc nghẽn cho người gửi và người nhận TCP. Ngoài ra, một số biến thể của giao thức kiểm soát tắc nghẽn TCP đã được đề xuất để suy ra tắc nghẽn bằng cách sử dụng gói được đo trì hỗn.
NHĨM 13
Báo hiệu điều khiển và kết nối Chương II: Điều khiển tắc nghẽn cho giao thức TCP
Chúng ta sẽ xem xét cả kiểm soát tắc nghẽn do mạng hỗ trợ và dựa trên độ trễ trong phần này.
Thông báo tắc nghẽn rõ ràng ECN
Thông báo tắc nghẽn rõ ràng là hình thức kiểm sốt tắc nghẽn do mạng hỗ trợ được thực hiện trong Internet. Như trong Hình 2.6, cả TCP và IP đều có liên quan. Ở lớp mạng, hai bit (với 4 giá trị có thể) trong trường loại dịch vụ của tiêu đề sơ đồ dữ liệu IP được sử dụng cho ECN.Một cài đặt của các bit ECN được bộ định tuyến sử dụng để chỉ ra rằng bộ định tuyến đang gặp sự cố tắc nghẽn.
Hình 2.6: Thơng báo tắc nghẽn rõ ràng: được hỗ trợ bởi mạng điều khiển tắc nghẽn.
Dấu hiệu tắc nghẽn này sau đó được chuyển trong sơ đồ IP được đánh dấu đến máy chủ đích, sau đó thơng báo cho máy chủ gửi, như thể hiện trong Hình 2.6 [RFC 3168] khơng cung cấp định nghĩa về thời điểm bộ định tuyến bị tắc nghẽn; quyết định đó là lựa chọn cấu hình do nhà cung cấp bộ định tuyến thực hiện và do nhà khai thác mạng quyết định. Tuy nhiên, bit chỉ báo tắc nghẽn có thể được thiết lập để báo hiệu sự khởi đầu của tắc nghẽn đối với quá trình gửi trước khi xảy ra mất mát thực sự. Cài đặt thứ hai của các bit
NHÓM 13
ECN được máy chủ gửi sử dụng để thông báo cho các bộ định tuyến rằng người gửi và người nhận có khả năng ECN và do đó có khả năng thực hiện hành động để đáp ứng với tắc nghẽn mạng do ECN chỉ định.
Trong Hình 2.6, khi TCP trong máy chủ nhận nhận được thông báo tắc nghẽn ECN thông qua sơ đồ dữ liệu, TCP trong máy chủ nhận sẽ thông báo cho TCP trong máy chủ gửi về thông báo tắc nghẽn bằng cách cài đặt bit ECE trong phân đoạn TCP ACK từ người nhận đến người gửi. Khi đến lượt người gửi TCP tương tác với ACK có tắc nghẽn bằng cách giảm một nửa cửa sổ tắc nghẽn, vì nó tương tác với một phân đoạn bị mất bằng cách sử dụng truyền lại nhanh và đặt bit CWR trong tiêu đề của lần truyền tiếp theo phân đoạn người gửi gửi đến người nhận TCP.
Các giao thức lớp truyền tải khác ngồi TCP cũng có thể sử dụng ECN được báo hiệu bởi lớp mạng. Giao thức kiểm soát tắc nghẽn Datagram (DCCP) cung cấp chi phí thấp,kiểm sốt tắc nghẽn dịch vụ không đáng tin cậy như UDP dùng ECN. DCTCP (Trung tâm Dữ liệu TCP) và DCQCN (Thơng báo tắc nghẽn lượng tử hóa của Trung tâm Dữ liệu) được thiết kế đặc biệt cho các mạng trung tâm dữ liệu, cũng sử dụng ECN. Các phép đo Internet gần đây cho thấy việc triển khai các khả năng ECN ngày càng tăng trong các máy chủ phổ biến cũng như trong các bộ định tuyến dọc theo đường dẫn đến các máy chủ đó.
Kiểm sốt tắc nghẽn dựa trên độ trễ
Như tìm hiểu về ECN ở trên rằng một bộ định tuyến bị tắc nghẽn có thể đặt bit thơng báo tắc nghẽn để báo hiệu sự cố tắc nghẽn bắt đầu cho người gửi trước đầy bộ đệm gây ra các gói tin bị mất tại bộ định tuyến đó. Điều này cho phép người gửi giảm tốc độ gửi ban đầu, trước khi mất gói tin, để tránh mất hoặc truyền lại gói tin có giá trị. Cách tiếp cận tránh tắc nghẽn thứ hai áp dụng cách tiếp cận dựa trên độ trễ để cũng chủ động phát hiện sự khởi đầu của tắc nghẽn trước xảy ra mất gói tin.
Trong TCP Vegas ,người gửi ước lượng RTT của đường dẫn đến nguồn đích cho tất cả các gói được thừa nhận. Cho phép RTTmin là mức tối thiểu của các phép đo này ở người gửi; điều này xảy ra khi đường dẫn khơng bị chặn và các gói gặp phải độ trễ xếp NHÓM 13
Báo hiệu điều khiển và kết nối Chương II: Điều khiển tắc nghẽn cho giao thức TCP
hàng tối thiểu. Nếu kích thước cửa sổ tắc nghẽn của TCP Vegas là cwnd, thì tốc độ thơng lượng chưa được kiểm tra sẽ là cwnd /RTTmin. Trực giác đằng sau TCP Vegas là nếu thông lượng thực tế do người gửi đo gần với giá trị này, tốc độ gửi TCP có thể được tăng lên vì (theo định nghĩa và theo phép đo) đường dẫn chưa bị tắc nghẽn. Tuy nhiên, nếu thông lượng thực tế do người gửi đo nhỏ hơn đáng kể so với tốc độ thông lượng không bị tắc nghẽn, đường dẫn sẽ bị tắc nghẽn và người gửi Vegas TCP sẽ giảm tốc độ gửi.
Thơng tin chi tiết có thể được tìm thấy trong TCP Vegas hoạt động theo trực giác mà người gửi TCP nên “Giữ cho đường ống vừa đầy, nhưng không đầy hơn ” “Giữ cho đường ống ln đầy” có nghĩa là các liên kết (đặc biệt là liên kết nút cổ chai đang hạn chế thông lượng của kết nối) luôn bận rộn trong việc truyền tải, thực hiện cơng việc hữu ích; "nhưng khơng đầy hơn" có nghĩa là khơng có gì để đạt được (ngoại trừ tăng độ trễ) Nếu các hàng đợi lớn được phép tích tụ trong khi đường ống được giữ đầy đủ.
Giao thức kiểm soát tắc nghẽn BBR được xây dựng dựa trên các ý tưởng trong TCP Vegas và kết hợp các cơ chế cho phép nó cạnh tranh cơng với những người gửi TCP non-BBR. Báo cáo rằng vào năm 2016, Google đã bắt đầu sử dụng BBR cho tất cả lưu lượng TCP trên mạng B4 riêng của mình kết nối các trung tâm dữ liệu của Google, thay thế CUBIC. Nó cũng đang được triển khai trên Google và Máy chủ web của YouTube. Các giao thức kiểm soát tắc nghẽn TCP dựa trên độ trễ khác bao gồm TIMELY cho các mạng trung tâm dữ liệu và Compound TCP (CTPC) và FAST cho các mạng đường dài và tốc độ cao.