tìm hiểu giao thức quick vegas, tcp westwood và rovegas trên mạng internet

Cụm từviết tắt Cụm từ đầy đủ tương ứng dạng tiếng Anh Cụm từ đầy đủ tương ứng dạng tiếng Việt ACK Acknowledgment Gói tin hồi đáp BaseRTT Base Round Trip Time Thời gian khứ hồi cực tiểu c

ĐẠI HỌC HUẾ

TRƯỜNG ĐẠI HỌC KHOA HỌC HUẾ

TRẦN ĐÌNH NGỌC THANH

TÌM HIỂU GIAO THỨC QUICK VEGAS, TCP WESTWOOD

VÀ ROVEGAS TRÊN MẠNG INTERNET

CHUYÊN NGÀNH : KHOA HỌC MÁY TÍNH

MÃ SỐ : 60.48.01

LUẬN VĂN THẠC SĨ KHOA HỌC

CÔNG NGHỆ THÔNG TIN

NGƯỜI HƯỚNG DẪN KHOA HỌCPGS.TS VÕ THANH TÚ

Huế, 2013

Tôi xin cam đoan:

Những nội dung trong luận văn này là do tôi thực hiện dưới sựhướng dẫn trực tiếp của PGS.TS Võ Thanh Tú

Mọi tham khảo dùng trong luận văn đều được trích dẫn rõ ràng vàtrung thực tên tác giả, tên công trình, thời gian, địa điểm công bố

Mọi sao chép không hợp lệ, vi phạm quy chế đào tạo, hay gianlận, tôi xin chịu hoàn toàn trách nhiệm

Tác giả

Trần Đình Ngọc Thanh

quan tâm giúp đỡ, chỉ bảo kịp thời và đã tận tình hướng dẫn

em trong việc hoàn thành luận văn này

Em xin gửi lời cảm ơn Quý Thầy Cô trong khoa Côngnghệ thông tin trường Đại học Khoa học Huế, đã cung cấp,truyền đạt kiến thức cho em trong suốt quá trình học tập tạitrường

Qua đây, em cũng xin gửi lời cảm ơn đến Phòng đào tạosau đại học thuộc Trường Đại học Khoa học Huế đã hỗ trợ vàtạo điều kiện thuận lợi cho chúng em trong suốt khóa học

Xin chân thành cảm ơn các anh chị em lớp cao học Khoahọc máy tính khoá 2011-2013 và các bạn bè đã luôn bêncạnh, động viên, khuyến khích trong suốt thời gian học tập vàthực hiện đề tài

Cuối cùng, em xin gửi cảm ơn đến gia đình, chính vì có

sự hỗ trợ từ phía gia đình mà em yên tâm học tập tốt

Xin chân thành cảm ơn!

Huế, tháng 10 năm 2013

Tác giảTrần Đình Ngọc Thanh

Trang phụ bìa

Lời cam đoan

Lời cảm ơn

Mục lục

Danh mục các chữ viết tắt

Danh mục các bảng

Danh mục các hình vẽ

MỞ ĐẦU 1

1 Lí do chọn đề tài 1

2 Mục đích nghiên cứu 1

3 Phương pháp nghiên cứu 2

4 Ý nghĩa khoa học và thực tiễn của đề tài 2

5 Cấu trúc của luận văn 2

CHƯƠNG 1 4

TỔNG QUAN VỀ ĐIỀU KHIỂN TRÁNH TẮC NGHẼN 4

1.1.Nguyên nhân tắc nghẽn 4

1.2.Các cơ chế điều khiển tắc nghẽn 6

1.2.1 Cơ chế bắt đầu chậm 7

1.2.2 Cơ chế tránh tắc nghẽn 8

1.2.3 Cơ chế phát lại nhanh 9

1.2.4 Cơ chế phục hồi nhanh 10

1.3.Các hạn chế và yếu tố ảnh hưởng đến TCP 11

1.3.1.Hạn chế của TCP 11

1.3.2 Các yếu tố ảnh hưởng đến TCP 11

1.4.Một số cải tiến của TCP đã được đề xuất 14

1.4.1.TCP Tahoe 14

1.4.2.TCP Reno 14

1.4.3.TCP Vegas 16

1.5.Kết luận chương 1 19

CHƯƠNG 2 20

WESTWOOD, ROVEGAS, QUICK VEGAS TRÊN MẠNG INTERNET .20

2.1 Giao thức TCP Westwood 20

2.1.1 Cơ chế hoạt động 21

2.1.2 Thuật toán ước tính băng thông 22

2.1.3 Thuật toán tính ngưỡng ssthresh 27

2.1.3.1 Thuật toán sau khi nhận n ACK trùng lặp 28

2.1.3.2 Thuật toán sau khoảng thời gian timeout 29

2.2 Giao thức RoVegas 32

2.2.1 Cơ chế hoạt động 32

2.2.2 Phân tích trên Vegas 33

2.2.2.1 Mạng đối xứng ( k ≤ 1 ) 34

2.2.2.2 Mạng bất đối xứng ( k > 1 ) 35

2.2.3 Phân tích trên RoVegas 36

2.2.3.1 Mạng đối xứng (k<=1) 36

2.3 Giao thức QuickVegas 38

2.3.1 Cơ chế hoạt động 38

2.3.2 Giai đoạn khởi động chậm 39

2.3.3 Giai đoạn tránh tắc nghẽn 41

2.4 Kết luận chương 2 43

CHƯƠNG 3 45

MÔ PHỎNG VÀ ĐÁNH GIÁ HIỆU NĂNG MỘT SỐ GIAO THỨC 45

3.1.Đánh giá mô phỏng 45

3.1.1.Giả thiết và thiết lập thông số ban đầu cho quá trình mô phỏng 45

3.1.2.Phân tích kết quả TCP Westwood 46

3.1.2.1.Kịch bản 1 46

3.1.2.2.Kịch bản 2 49

3.2.Kết luận chương 3 52

Phân tích mô phỏng vẫn còn hạn chế là chưa đánh giá sâu về thông lượng trên đường truyền, đánh giá về giá trị ước tính băng thông BWE của TCP Westwood để làm sáng tỏ bản chất hoạt động của TCP Westwood 52

KẾT LUẬN VÀ HƯỚNG PHÁT TRIỂN 53

PHỤ LỤC

Cụm từ

viết tắt

Cụm từ đầy đủ tương ứng dạng tiếng Anh

Cụm từ đầy đủ tương ứng dạng tiếng Việt

ACK Acknowledgment Gói tin hồi đáp

BaseRTT Base Round Trip Time Thời gian khứ hồi cực tiểu

của kết nối CWND Congestion Window Cửa sổ tắc nghẽn

IP Internet Protocol Giao thức Internet

NCP Network Control Protocol Giao thức điều khiển mạng

truyền thông TCP NewVegas OMNeT++ Objective Modular Network

Testbed in C++ Phần mềm mô phỏng mạng

PC Personal Computer Máy tính cá nhân

FTP File Transport Protocol

truyền thông TCP Reno

RTT Round Trip Time Thời gian khứ hồi của kết nối RWND Receiver Window Cửa sổ trạm nhận gói tin

SMSS Sent Maximum Segment Size Kích thước tối đa gói tin đã gửi

cửa sổ tắc nghẽn

TCP Transmission Control Protocol Giao thức điều khiển

truyền thông

truyền thông TCP-Vegas NED Network Control Protocol Ngôn ngữ mô tả mô hình mạng BDP Bandwidth-Delay Product Tính bằng tích số của độ rộng

BWE Bandwidth Estimation Giá trị ước tính băng thông

3.1 Bảng 3.1: Số gói tin nhận ở kịch bản 1

Error: Referen ce source not found

3.2 Bảng 3.2: Mất gói tin ở hàng đợi

Error: Referen ce source not found

3.3 Bảng 3.3: Số gói tin còn ở hàng đợi sau thời gian giả lập 1s

Error: Referen ce source not found 3.4 Bảng 3.4: Số gói tin nhận ở kịch bản 1 Error:

Referen ce source

3.5 Bảng 3.5: Mất gói tin ở hàng đợi

Referen ce source not found

3.6 Bảng 3.6: Số gói tin còn ở hàng đợi sau thời gian giả lập 1s

Error: Referen ce source not found

Số hiệu

1.1 Hình 1.1: Sơ đồ biến đổi lưu lượng của TCP

Error: Referen ce source not found

1.2 Hình 1.2: Cơ chế bắt đầu chậm, kích thước cửa sổ tăng theo hàm mũ

Error: Referen ce source not found

1.3 Hình 1.3: Cơ chế bắt đầu chậm và tránh tắc nghẽn

Error: Referen ce source not found

1.4 Hình 1.4: Cơ chế truyền lại nhanh dựa trên duplicate ACKs

Error: Referen ce source not found

1.5 Hình 1.5: Cơ chế phục hồi nhanh

Error: Referen ce source not found 1.6 Hình 1.6: Mô hình kết nối yêu cầu - đáp (request-response) Error:

1.7 Hình 1.7: Sơ đồ hoạt động của TCP Tahoe

Referen ce source not found

1.8 Hình 1.8: Sơ đồ điều khiển tắc nghẽn của TCP Reno

Error: Referen ce source not found

2.1 Hình 2.1: Sơ đồ điều khiển tắc nghẽn của TCP Westwood

Error: Referen ce source not found

2.2 Hình 2.2: Mô hình phân tích RoVegas

Error: Referen ce source not found 2.3 Hình 2.3: Kích thước cửa sổ và độ dài hàng đợi nút cổ chai của

Vegas với k=2

Error: Referen ce source not

2.4 Hình 2.4: Kích thước cửa sổ và độ dài hàng đợi nút cổ chai của

RoVegas với k=2

Referen ce source not found

2.5 Hình 2.5: Điều khiển cửa sổ của TCP Vegas

Error: Referen ce source not found

2.6 Hình 2.6: Diễn biến cửa sổ tắc nghẽn của Vegas và Quick Vegas

trong giai đoạn khởi động chậm

Error: Referen ce source not found

3.1 Hình 3.1: Mô hình phân tích mô phỏng TCP Westwood

Error: Referen ce source not found

3.2 Hình 3.2: Quá trình mô phỏng TCP Westwood và UDP

Error: Referen ce source not found 3.3 Hình 3.3: Kết thúc quá trình mô phỏng kịch bản 1 Error:

Referen ce

3.4 Hình 3.4: Biểu đồ kích thước cửa sổ TCP Westwood thay đổi

theo thời gian

Referen ce source not found

3.5 Hình 3.5: Biểu đồ đo thời gian RTT

Error: Referen ce source not found

3.6 Hình 3.6: Quá trình mô phỏng TCP Westwood và TCP Reno

Error: Referen ce source not found

3.7 Hình 3.7: Kết thúc quá trình mô phỏng kịch bản 2

Error: Referen ce source not found

3.8 Hình 3.8: Biểu đồ kích thước cửa sổ TCP Westwood thay đổi

theo thời gian

Error: Referen ce source not found 3.9 Hình 3.9: Biểu đồ đo thời gian RTT Error:

MỞ ĐẦU

1 Lí do chọn đề tài

Sự phát triển không ngừng các dịch vụ truyền thông đa phương tiệntrên mạng máy tính hiện nay đòi hỏi cơ sở hạ tầng và công nghệ truyền thôngcần phải đáp ứng để đảm bảo chất lượng dịch vụ Điều này đồng nghĩa vớiviệc nghiên cứu nhằm nâng cao kỷ thuật truyền thông, đặc biệt là những cảitiến về cơ chế điều khiển tránh tắc nghẽn của giao thức TCP đã đem lại hiệunăng mạng rõ rệt

Giao thức TCP Vegas là một trong những giao thức cải tiến của giaothức TCP được Brakmo đề xuất thuật toán vào năm 1994 Nó là một phiênbản cải tiến của giao thức TCP Reno và có thể đạt được thông lượng cao hơn

từ 37% đến 71% so với TCP Reno trên Internet Tuy nhiên, hiện nay TCPVegas vẫn chưa được sử dụng rộng rãi trên Internet vì vẫn còn một số hạn chếnhất định trong việc xác định các tham số ảnh hưởng trong từng thời điểmnhất định Vì vậy, để tăng hiệu quả đường truyền, đây là vấn đề mở mà các

nhà nghiên cứu rất quan tâm Do vậy tôi chọn đề tài “ Tìm hiểu giao thức Quick Vegas, TCP Westwood và RoVegas trên mạng Internet ” nhằm đạt

đến mục tiêu này

2 Mục đích nghiên cứu

- Tìm hiểu vấn đề về nguyên nhân tắc nghẽn và các phương pháp điềukhiển tránh tắc nghẽn

- Phân tích ưu nhược điểm của giao thức TCP, đặc biệt là TCP Vegas

- Tìm hiểu về nguyên lý hoạt động và các đặc tính nâng cao hiệu năngcủa giao thức TCP Westwood, RoVegas, Quick Vegas

- Cài đặt, mô phỏng

3 Phương pháp nghiên cứu

– Phương pháp luận: Phân tích, tổng hợp để tìm hiểu lý thuyết về cơ

chế hoạt động của các giao thức TCP, TCP Reno, TCP Vegas làm cơ sở chohướng cải tiến của giao thức TCP Westwood, RoVegas, QuickVegas

– Phương pháp mô phỏng: Xây dựng mô hình mô phỏng trên

OMNET++ để đánh giá hiệu năng của một số giao thức tìm hiểu

4 Ý nghĩa khoa học và thực tiễn của đề tài

Mô hình TCP/IP đã được nghiên cứu và phát triển trên mạng Internettrong một thời gian dài, việc truyền thông tin cậy, tránh mất mát thông tin trênđường truyền là điều mà người sử dụng quan tâm đến Tuy nhiên, Internetđược xem như là một môi trường không đồng nhất, chính vì vậy cần có những

cơ chế điều khiển tránh tắc nghẽn để giảm những sai sót không đáng có Ví dụnhư, một trạm nguồn TCP có thể điều khiển cửa sổ hoặc giảm luồng các góitin đến bằng cách điều chỉnh gói báo nhận ACK để đáp ứng với những thayđổi của mạng nhằm mục đích tăng công suất mạng

Hiện nay đã có các bộ giao thức cải tiến của TCP như TCP Tahoe, TCPReno, TCP Vegas đã được ứng dụng sử dụng trong thực tế Tuy nhiên, cácgiao thức cải tiến này cũng xuất phát từ TCP nên không tránh khỏi vẫn cònmắc phải một số hạn chế Chính vì vậy, việc nghiên cứu kỹ giao thức TCP lànền tảng để cải tiến thành các bộ giao thức mới, ứng dụng vào thực tế, làhướng nghiên cứu của các nhà khoa học hiện nay và trong tương lai

5 Cấu trúc của luận văn

Luận văn được chia làm ba chương như sau:

 Chương 1 - Tổng quan về điều khiển tránh tắc nghẽn

Trong chương này tôi trình bày các kiến thức tổng quan về nguyên lýđiều kiển tắc nghẽn trên mạng Internet Trong đó tập trung tình bày và phân

tích vấn đề cơ chế hoạt động cơ bản của giao thức TCP, TCP Reno, TCPVegas làm cơ sở lý thuyết cho hướng cải tiến ở chương 2.

 Chương 2 – Cơ chế điều khiển tắc nghẽn của giao thức TCPWestwood, RoVegas, Quick Vegas trên mạng Internet

Với chương này, tôi tiến hành phân tích cơ chế, nguyên lý hoạt độngcủa giao thức TCP Westwood, RoVegas và Quick Vegas

 Chương 3 – Mô phỏng và đánh giá hiệu năng một số giao thức

Ở chương này, luận văn giới thiệu sơ lược phần mềm mô phỏngOmnet++ Nội dung còn lại tập trung cài đặt một số giao thức cải tiến củaTCP ở chương 2 và tiến hành đánh giá các kết quả mô phỏng

CHƯƠNG 1 TỔNG QUAN VỀ ĐIỀU KHIỂN TRÁNH TẮC NGHẼN

Giao thức TCP điều khiển tần suất truyền bằng cách giới hạn số gói xácnhận ACK được truyền Trong mỗi phiên làm việc, độ lớn cửa sổ phát w là

số gói dữ liệu chưa có gói xác nhận ACK trả lời tương ứng Một cách lýtưởng, khi không có sự mất mát dữ liệu do tắc nghẽn trên đường truyền thì độlớn cửa sổ phát càng lớn càng tốt Khi một kết nối được thiết lập, độ lớn cửa

sổ truyền ban đầu là thấp, sau đó tăng dần lên nhằm tránh tắc nghẽn Quátrình tăng liên tục cho đến khi w đạt giá trị tối đa, tức là khi gặp lỗi hay khinhận được gói xác nhận ACK yêu cầu phát lại, hay quá thời gian chờ tối đacho phép Khi đó, độ lớn cửa sổ phát sẽ được giảm và quá trình truyền lại bắtđầu một chu kỳ mới

Chúng ta sẽ xem xét các nguyên nhân tắc nghẽn và các thuật toán điềukhiển lưu lượng cơ bản, hợp thành cơ chế điều khiển lưu lượng trong giao thứcTCP đó là: khởi động chậm (slow start), tránh tắc nghẽn (congestion avoidance),phát lại nhanh và phục hồi nhanh (fast retransmit and fast recovery) và các giaothức cải tiến cơ bản như TCP Tahoe, TCP Reno, TCP Vegas

- Bộ đệm ở các hàng đợi quá nhỏ [1] Nếu bộ nhớ không đủ dung lượng

để lưu chúng thì một số gói tin sẽ bị mất Việc tăng dung lượng bộ nhớ đệmlên sẽ có ích, nhưng Nagle(1987) cho rằng nếu các router có lượng nhớ khôngxác định thì sự tắc nghẽn chẳng tốt hơn tí nào mà ngược lại trở nên xấu đi do

số bản sao được gửi tăng lên, làm tăng lượng thông tin ở nơi nhận tin

- Tần suất lỗi mạng cao và độ trễ lớn [1] Đối với mạng cố định, việc

mất gói tin do lỗi đường truyền hiếm khi xảy ra Mất gói tin đồng nghĩa vớiviệc xảy ra tắc nghẽn ở các nút (router) trong mạng Cơ chế điều khiển chốngtắc nghẽn của TCP sẽ căn cứ vào sự kiện mất gói và kiểm tra trễ quá time-out

để xác định tắc nghẽn trong mạng TCP không có khả năng phân biệt giữamất gói do đường truyền hay mất gói do tắc nghẽn, mỗi khi xảy ra các hiệntượng trên TCP giảm tốc độ truyền Điều đó không còn phù hợp với truyềnthông di động vì hiệu suất đường truyền sẽ bị hạ thấp Một vấn đề khác cótính không đồng nhất giữa mạng di động và mạng cố định là tốc độ truyềnkênh di động thấp hơn nhiều so với mạng cố định Vì vậy, phần truy cập vôtuyến sẽ luôn là chỗ nghẽn cổ chai đối với một kết nối giữa thuê bao di động

và một đầu cuối ở mạng cố định Ngoài ra, hiệu ứng băng thông không đốixứng cũng có tác động lớn đến truy nhập Internet Băng thông theo hướng từmáy cố định tới máy di động thường lớn hơn nhiều băng thông theo chiềungược lại Hiệu ứng này làm cho trễ theo hai chiều truyền khác nhau

Hình 1.1: Sơ đồ biến đổi lưu lượng của TCP

Trên hình biểu thị sự thay đổi lưu lượng của TCP Khi máy chủ truyềncác gói tin vào mạng con Trong vòng lượng thông tin có thể truyền tốt thì cácgói tin này sẽ được truyền đi, ngoại trừ vài gói tin bị hỏng do lỗi truyền và sốgói tin được truyền đi tương ứng với số gói tin chuyển đến Tuy nhiên, khi sốlượng gói tin tăng lên, những router không còn khả năng điều chỉnh, đánh mấtchúng Điều này có khuynh hướng làm cho vấn đề trầm trọng hơn khi lượnglưu thông quá cao, sự truyền bị phá bỏ hoàn toàn và hầu như không có gói tinnào được truyền đi

1.2.Các cơ chế điều khiển tắc nghẽn

Khi một kết nối được thiết lập, độ lớn cửa sổ truyền ban đầu là thấp,sau đó tăng dần lên nhằm tránh tắc nghẽn Quá trình sẽ tăng liên tục cho đếnkhi w đạt đến giá trị tối đa, tức là khi gặp lỗi hay khi nhận được gói báo nhậnACK yêu cầu phát lại, hay quá thời gian chờ tối đa cho phép Khi đó, độ lớncửa sổ phát sẽ được giảm và quá trình truyền lại bắt đầu một chu kỳ mới [1]

Việc tránh tắc nghẽn có thể căn cứ vào thời gian khứ hồi gói tin RTT(Round trip time: thời gian bắt đầu phát gói dữ liệu cho đến khi nhận được trảlời) hoặc lượng dữ liệu đưa vào mạng để biết tắc nghẽn sắp xảy ra nếu khôngcan thiệp

Số gói tin

giao nhận

Giới hạn truyền thông cực đại

Mong muốn Thực tế (xảy

ra tắc nghẽn)

Lý tưởng (số gói tin gửi = số gói tin nhận)

Số gói tin gửi đi

Nếu hàng đợi bộ định tuyến (Router) đang tăng, thời gian đợi tăng vàRTT tăng, căn cứ vào RTT hiện tại sẽ biết được tắc nghẽn sắp xảy ra Xácđịnh RTT trung bình, nếu RTTht > RTTtb thì giảm cwnd(1/8) Ngược lại thìtăng cửa sổ tắc nghẽn cwnd lên một gói cực đại.

1.2.1 Cơ chế bắt đầu chậm

Để tránh tắc nghẽn mạng ngay từ đầu, trạm gửi sẽ phát với cửa sổ tắcnghẽn (CWND) bằng 1, mỗi khi nhận được thông báo trả lời ACK (báonhận), CWND được tăng thêm gấp đôi (2, 4, 8, 16 ) cho đến khi xuất hiệntắc nghẽn mạng [1]

Giai đoạn khởi động chậm kết thúc khi cửa sổ tắc nghẽn CWND đạtđến ngưỡng xác định trước (ssth)

1.2.2 Cơ chế tránh tắc nghẽn

Khi có hiện tượng tắc nghẽn, thể hiện ở sự quá thời gian trễ (time-out)hoặc nhận các ACK trùng lặp số hiệu (Duplicated ACK) thì:

+ Giá trị ngưỡng được thiết lập lại: ssth(t) = CWND /2

+ Giá trị của CWND được thiết lập lại là: CWND = 1

+ Phát lại các gói tin bị mất theo yêu cầu của trạm nhận

Khi nhận được thông báo ACK (giảm tắc nghẽn):

+ Nếu CWND < ssth, thuật toán bắt đầu chậm được thực hiện lại

+ Nếu CWND >= ssth, thuật toán tránh tắc nghẽn được thực hiện: giátrị CWND được tăng 1/CWND với mỗi thông báo ACK nhận được (tăngtuyến tính để không rơi lại vào tắc nghẽn)

Hình 1.3: Cơ chế bắt đầu chậm và tránh tắc nghẽn

Tăng theo hàm mũ Tránh tắc nghẽn

Giá trị ngưỡng (ssth)

Giá trị mong muốn

Giá trị tối đa

Segment bị mất Segment bị mất Segment bị mất

1.2.3 Cơ chế phát lại nhanh

TCP thực hiện phát một gói dữ liệu khi nhận được thông báo NAK (thusai) hoặc được đồng hồ quản lý phát lại được kích hoạt (time-out) Nếu chờtime-out mới phát lại gây ra số gói phát lại nhiều (hoặc đòi hỏi bộ đệm phíathu lớn để giữ tạm các gói sai số thứ tự), điều đó dễ gây ra tắc nghẽn Cơ chếphát lại nhanh cho phép phát lại không cần chờ time-out, trong trường hợpnhận được hơn ba thông báo ACK lặp lại (duplicated ACK), nghĩa là có gói

dữ liệu bị mất, cần phát lại [1]

Hình 1.4: Cơ chế truyền lại nhanh dựa trên duplicate ACKs

Trạm gửi Trạm nhận

Gói dữ liệu 1 Gói dữ liệu 2 Gói dữ liệu 3 Gói dữ liệu 4

Gói dữ liệu 6

Truyền lại gói dữ liệu 3

Gói dữ liệu 5

ACK 1 ACK 2

ACK 2

ACK 6

ACK 2 ACK 2

x

1.2.4 Cơ chế phục hồi nhanh

Cơ chế này được thực hiện sau cơ thế phát lại nhanh [1] và nó hoạtđộng như sau:

+ Ứng với mỗi thông báo ACK trùng lặp được nhận ở trạm gửi, cửa sổtắc nghẽn được tăng thêm: CWND = CWND + 1* SMSS

+ Thực hiện phát một gói dữ liệu, nếu thỏa mãn: w = min {CWND,RWND}

+ Sau khi nhận được thông báo trả lời ACK không bị lặp lại, nghĩa làmột gói dữ liệu mới đã được nhận đúng, TCP thiết lập lại giá trị CWND đượcgiữ trong trường ssth và thực hiện việc phát bình thường trở lại với qui tắc:

w = min { CWND, RWND }

Cơ chế phục hồi nhanh tránh cho lưu lượng dữ liệu trong kết nối TCP

bị thay đổi đột ngột và đảm bảo thông lượng dữ liệu đạt được phù hợp với bốicảnh thực tế việc phát, thu có lỗi

Thuật toán phát lại và phục hồi nhanh có nhược điểm:

Segment bị mất Segment bị mất Segment bị mất

Việc phát lại các gói bị lỗi dẫn đến phát lại gói dữ liệu đó được phátthành công trước đó và khi thuật toán này không thành công phải chờ time-out để phát lại, khi đó độ lớn cửa sổ phát bằng 1.Vì vậy, thay vì chờ time-out

ta dựng ngay thuật toán phát lại giống như trong giai đoạn khởi động chậm

- Chưa có khả năng nhận biết sự nghẽn mạng với lỗi bit do đường truyền

- Thời gian để đạt được thông lượng tối đa của đường truyền còn dài

1.3.2 Các yếu tố ảnh hưởng đến TCP

Khi có sự mất cân bằng tài nguyên, như khi tốc độ các gói tin đến cao

mà tốc độ xử lý tại hàng đợi của máy tính trung tâm thấp (nguyên nhân tăng

độ trễ, phải truyền tải lại), làm giảm hiệu năng Hoặc sau phục hồi hệ thống,các máy trạm đồng thời truy cập đến máy trung tâm làm tăng tải, nên phải cóchiến lược đồng bộ hiện tượng quá tải phù hợp Trong giao thức TCP cũng đã

có những cơ chế điều khiển luồng cũng như kiểm soát lỗi, nhưng trong môitrường mạng bất đối xứng đã tỏ ra kém hiệu quả Vì vậy, các nhà nghiên cứuInternet đã đề nghị những cơ chế để cải tiến TCP như sau:

- Tăng kích thước cửa sổ với một tốc độ không phụ thuộc RTT [1]: tức

là cần phải tính toán sao cho RTT nhỏ Tuy nhiên, điều này không tạo điềukiện dễ dàng cho việc chọn tốc độ tăng kích thước cửa sổ để mạng hoạt độngtốt trên phạm vi rộng của RTT Nếu tốc độ tăng là nhỏ hơn so với tốc độ hiện

tại thì các liên kết sẽ chậm, còn nếu tốc độ là quá nhanh thì số gói tin mất sẽlớn khi có nhiều liên kết đang hoạt động và RTT sẽ lớn.

- Điều chỉnh kích thước cửa sổ theo độ trễ lúc không có lỗi [1]: tập

trung vào việc so sánh RTT với RTT cực tiểu dựa trên số gói tin chuyển điđược ý tưởng ở đây là tăng độ đo RTT theo kích thước hàng đợi trong bộđịnh tuyến Khó khăn trên thực tế là việc ước lượng RTT theo thời gian đợitại thời điểm bắt đầu của một kết nối Nếu tất cả trạm nguồn sử dụng cơ chếnày thì sẽ giảm nguy cơ tắc nghẽn

- Đánh dấu các gói tin ở bộ định tuyến [1]: khi có dấu hiệu tắc nghẽn

cho đến khi gói tin rơi (ECN: thông báo rõ tắc nghẽn) để cho trạm nhận gửithông báo ngược lại đi theo các gói ACK Cơ chế này rất được ưu chuộng, vì

nó dùng để ra hiệu cho trạm nguồn hạ thấp kích thước cửa sổ và thực hiệnviệc truyền lại các gói tin hỏng

- Cải tiến bộ định tuyến [1] có các chương trình hỗ trợ cho việc thôngbáo rõ tốc độ truyền tin xác định, nên bộ định tuyến phức tạp hơn Một đềxuất là đánh dấu nhãn gói tin nếu nó có khả năng gây ra lỗi mất gói tin trongtương lai Điều đó có nghĩa là, khi các gói tin đến, bộ định tuyến phải dự báo

về gói tin này, hoặc là sẽ bị rơi hoặc là gói tin đó sẽ đến sau Sự quyết địnhphải dựa trên tải hiện hành của bộ định tuyến

- Xây dựng cơ chế điều khiển lỗi [1] cho những liên kết nhiều lỗi.Đây là 5 đề xuất chính để cải thiện lưu thông trên mạng Tuy nhiên mỗiphương pháp có những ưu và khuyết điểm riêng dựa trên mô hình cài đặt

Vì vậy, trong chương này, tôi chỉ đi sâu phân tích những giải pháp cótác động mạnh trong điều khiển tắc nghẽn, đặc biệt là các phương pháp tránhtắc nghẽn hữu dụng trong môi trường bất đối xứng về băng thông, tỷ lệ gói tinđược truyền và độ trễ Cụ thể như sau:

- Xử lý nhanh các gói tin đến tại nút mạng, dựa trên chiến lược quản lýhàng đợi thích hợp và cải tiến giao thức ở đầu cuối cho các mô hình mạng đápứng với hiệu suất cao.

- Có thể tăng, giảm thời gian đáp ACK để điều chỉnh lưu lượng gói tinđến Đo các tham số mạng liên quan và theo dõi quá trình thực hiện dựa trên

sơ đồ hình 1.4, đặt tầng quan sát tại máy trạm để theo dõi chu kỳ của các quátrình thực hiện trên mạng Dùng Timer để biết được gói tin cần bao lâu đểđược báo nhận của RTT từ khi bắt đầu yêu cầu gói tin đến cho đến lúc nhậnđược đáp ứng trả lời Đồng thời, ghi lại biến cố xảy ra (dựa vào trình tự ACK)như là hiện tượng mất gói tin

- Thiết kế hệ thống phải đảm bảo lưu lượng truyền tối đa nhưng khôngdẫn đến tắc nghẽn, không để xảy ra hiện tượng thắt nút do sự chênh lệch tốc

độ trong thiết kế mạng Intranet Đặc biệt xử lý tốc độ cao tại vị trí các nútmạng trung tâm qua kết nối bộ định tuyến truyền đi Internet để thực hiện hiệusuất tốt hơn

Hình 1.6: Mô hình kết nối yêu cầu - đáp (request-response)

1.4 Một số cải tiến của TCP đã được đề xuất

1.4.1 TCP Tahoe

Giao thức điều khiển tắc nghẽn TCP Tahoe [1] là giao thức TCP kếthợp với ba cơ chế “bắt đầu chậm”, “tránh tắc nghẽn” và “phát lại nhanh” Đặctrưng của TCP Tahoe là khi phát hiện mất gói dữ liệu thông qua việc nhận 3gói ACK lặp lại, trạm gửi phát lại gói dữ liệu bị mất đặt cwnd bằng 1 gói dữliệu và khởi động quá trình “bắt đầu chậm” Cơ chế “phát lại nhanh” khôiphục chờ “time-out”, cho phép tăng đáng kể thông lượng và hiệu suất sử dụngkênh kết nối TCP Hoạt động của TCP Tahoe như sau:

Hình 1.7: Sơ đồ hoạt động của TCP Tahoe

Phát lại gói, cwnd=1

Hình 1.8: Sơ đồ điều khiển tắc nghẽn của TCP Reno

Khi dữ liệu bị mất hay quá thời gian chờ ACK, TCP Reno đặt lại cửa

sổ phát bằng 1, sử dụng cơ chế phát lại nhanh (Fast retransmission) và khôiphục nhanh (Fast recovery), trạm gửi sẽ đi vào giai đoạn khôi phục nhanh (xéttrường hợp một gói lỗi) sau khi nhận được một giá trị ngưỡng của số báonhận ACK lặp bằng 3 Khi số báo nhận lặp đạt đến ngưỡng trạm gửi sẽ phátlại 1 gói dữ liệu, sau đó giảm cửa sổ tắc nghẽn cwnd xuống còn một nửa Sau

đó cứ mỗi lần nhận được 1 ACK, trạm gửi lại gửi đi 1 gói dữ liệu

Thuật toán TCP Reno

B1: Khi nhận được gói báo nhận ACK

Bắt đầu chậm Phục hồi

nhanh

timeout all ACK

cwnd=cwnd+1

dup ACK ACK

ACK

B2: Khi nhận được 3 gói lặp ACK

Threshold:=W(t)/2;

W(t):=W(t)/2;

Thực hiện thuật toán phát và phục hồi nhanh

B3: Khi quá thời gian cho phép

Threshold:=W(t)/2;

W(t)=1;

Trong quá trình truyền khi gặp lỗi thì giá trị ngưỡng thay đổi theo công

thức:Threshold = max(Flight size/2, 2*SMSS), trong đó Flight size là số gói

tin đã gửi nhưng chưa nhận ACK SMSS là độ lớn tối đa gói tin gửi

So với TCP Tahoe, TCP Reno cải thiện đáng kể hiệu năng về thônglượng nếu chỉ có nhiều nhất là 1 gói dữ liệu bị loại trong các gói dữ liệu củamột cửa sổ Tuy nhiên, hiệu năng của TCP Reno sẽ giảm trầm trọng nếu trongmột cửa sổ có trên một gói dữ liệu bị loại

1.4.3 TCP Vegas

Ý tưởng then chốt của TCP Vegas [1] là ngăn ngừa các segments bịmất trong quá trình truyền thông và tránh tắc nghẽn mạng TCP Vegas điềukhiển kích thước cửa sổ tắc nghẽn bằng cách theo dõi các RTT (Round TripTime) RTT là thời gian được tính từ khi một segment được gửi đi từ trạmphát đến trạm nhận, cho đến khi trạm phát nhận được segment hồi đáp ACK,chứa thông tin về segment đó được nhận thành công Nếu thời gian của cácRTT được theo dõi tăng, thì TCP Vegas nhận biết mạng sắp bị tắc nghẽn vàthực hiện cơ chế tránh tắc nghẽn Nếu thời gian của các RTT giảm thì TCPVegas nhận biết mạng được khai thông và TCP Vegas thực hiện cơ chế tăngkích thước cửa sổ để tận dụng thông lượng của đường truyền Trong quá trìnhđiều khiển truyền thông, TCP Vegas sử dụng các cơ chế : Cơ chế cửa sổ trượt,

cơ chế bắt đầu chậm, tránh tắc nghẽn, phát lại nhanh, phục hồi nhanh và cơ

chế điều khiển truyền thông của nó Cơ chế bắt đầu chậm được TCP Vegas sửdụng khi bắt đầu một kết nối Cơ chế phát lại nhanh và phục hồi nhanh đượcthực hiện khi nó nhận được 1 hoặc 3 segments ACK trùng lặp số hiệu.

•Thuật toán TCP Vegas thực hiện như sau:

Ký hiệu:

RTT: là thời gian khứ hồi hiện tại của kết nối ;

BaseRTT: là giá trị nhỏ nhất của các RTT được theo dõi ;

CWND : là cửa sổ tắc nghẽn của trạm phát;

α, β và γ: là các tham số thường được thiết lập tương ứng là: 1, 3 và 1;

∆ : Độ lệch giữa thông lượng mong đợi với thông lượng thực tế.B1: Khi nhận được gói báo nhận ACK

BaseRTT

* RTT

CWND BaseRTT

Thực hiện thuật toán phát lại nhanh và phục hồi nhanh;

B3: Khi quá thời gian cho phép (time out)

Threshold=CWND/2; CWND = 1;

Trong quá trình truyền khi gặp lỗi thì giá trị ngưỡng thay đổi theo công thức:

Threshold = max(Flight size/2, 2*SMSS)

•Ảnh hưởng của các tham số trong thuật toán Vegas

Vegas dựa vào sự quan sát các RTT để điều khiển truyền thông Các

tham số như: độ trễ d của đường truyền, độ trễ D của các RTT (D = d + thời gian trễ trên bộ đệm) và việc thiết lập các giá trị α, β Các tham số trên có

ảnh hưởng lớn đến việc điều khiển truyền thông của Vegas trên mạng [4]

Các tham số α, β thường được chọn là 1 và 3 (hoặc là 2 và 4) Vegas

tăng kích thước cửa sổ lên 1 khi − CWND< α

nguyên phần cứng của mạng Giá trị ban đầu của α, β ảnh hưởng rất lớn đến

sự cạnh tranh của Vegas

Nhiều nghiên cứu đã chỉ ra một số thiếu sót của Vegas và đề xuất cảitiến để khắc phục các thiếu sót đó, tăng năng lực cạnh tranh của Vegas vànâng cao chất lượng truyền thông Các cải tiến của Vegas nhằm vào việc cảitiến cách quản lý hàng đợi sao cho có thời gian D của RTT là nhỏ nhất trênđường truyền và cải tiến cách thiết lập các giá trị α, β

Hiện nay Vegas vẫn chưa được sử dụng rộng rãi trên mạng Internet, vìvẫn còn một số hạn chế trong việc xác định giá trị của các tham số ảnh hưởngứng với từng thời điểm khác nhau của mạng Vấn đề mở này rất có ý nghĩatrong tối ưu hóa truyền thông mà các nhà nghiên cứu quan tâm và cũng là lý

do để tôi nghiên cứu trong luận văn này

1.5 Kết luận chương 1

Tóm lại, chương này tôi đã trình bày nội dung cơ bản về mạng Internettrong đó tập trung vào hoạt động của TCP, các nguyên nhân, nguyên lý điềukhiển tắc nghẽn và các cơ chế điều khiển tránh tắc nghẽn trên mạng Đồngthời trình bày những hạn chế của TCP, những giải pháp để cải tiến trong quátrình hoạt động của TCP, từ đó trình bày chi tiết các giao thức TCP Tahoe,TCP Reno, TCP NewReno, TCP Vegas Trong đó, cải tiến của giao thức TCPVegas là hướng tiếp cận chính của luận văn sẽ được trình bày trong chươngtiếp theo

2.1 Giao thức TCP Westwood

Thuật toán điều khiển tắc nghẽn được sử dụng trong giao thức TCP/IP

là cơ chế cửa sổ trượt sử dụng sự mất gói tin để phát hiện tắc nghẽn Đặc biệt,các hệ thống cuối thăm dò các trạng thái mạng bằng cách tăng dần cửa sổ củacác gói tin đang tồn tại trong mạng cho đến khi mạng trở nên tắc nghẽn và rơicác gói tin Ban đầu, mức tăng theo cấp số nhân trong giai đoạn bắt đầu chậm.Giai đoạn này dự định là nhanh chóng lấy các băng thông sẵn có Khi kíchthước cửa sổ đạt đến một ngưỡng bắt đầu chậm (ssthresh) thì trở thành tăngtuyến tính Đó là mong muốn thiết lập ngưỡng giá trị xấp xỉ với “chia sẻ côngbằng” của kết nối Giá trị tối ưu cho ngưỡng bắt đầu chậm tương ứng với cácphân đoạn trong lượt gửi trong một đường truyền khi tốc độ TCP bằng vớibăng thông sẵn có, tức là khi cửa sổ truyền của nó bằng kết quả độ trễ băngthông sẵn có

Khi sự mất mát được phát hiện hoặc thông qua gói ACK trùng lặp,hoặc thông qua thời gian time out, kết nối phục hồi bằng cách thu hẹp cửa sổtắc nghẽn của nó Nếu sự mất mát được xác định bởi ACK trùng lặp, TCP

Reno thực hiện cơ chế phục hồi nhanh bằng cách phát lại các phân đoạn bịmất và giảm 1/2 cửa sổ tắc nghẽn Nếu sự mất xảy ra bởi thời gian time-out,cửa sổ tắc nghẽn thiết lập lại 1 Trong cả hai trường hợp, sau khi cửa sổ tắcnghẽn được thiết lập lại, kết nối cần nhiều thời gian khứ hồi để khôi phục hiệunăng Vấn đề này càng trầm trọng hơn khi sự mất mát xảy ra ngẫu nhiên hoặckhông thường xuyên Mất mát ngẫu nhiên ở đây được định nghĩa là mất mátkhông do sự tắc nghẽn ở liên kết nút cổ chai Chúng phổ biến trong sự hiệndiện của các kênh không dây Trong trường hợp này, sự xuất hiện đột ngộtcác phân đoạn bị mất bị hiểu nhầm bởi TCP nguồn như là một dấu hiệu củatắc nghẽn, và xử lý bằng cách thu hẹp cửa sổ của trạm phát Hành động nhưvậy, rõ ràng là không làm giảm bớt tình trạng mất ngẫu nhiên và nó chỉ đơnthuần là kết quả thông qua biến đổi.

Giao thức TCP Westwood được đặt ra để giải quyết hạn chế này Nóthiết lập một ngưỡng khởi đầu chậm và một cửa sổ tắc nghẽn phù hợp vớihiệu năng mạng đo tại thời điểm tắc nghẽn xảy ra Đặc biệt, TCP Westwoodgiới thiệu một cơ chế phục hồi nhanh để tránh thu nhỏ quá mức của cửa sổ tắcnghẽn sau sự kiện tắc nghẽn bằng cách đưa vào giá trị ước lượng đầu cuối củabăng thông sẵn có Lợi thế của cơ chế được đề xuất này là trạm phát TCPphục hồi nhanh sau những mất mát thông tin, đặc biệt là trên các kết nối vớithời gian khứ hồi lớn, hoặc chạy trên các liên kết không dây, nơi sự mất mátkhông thường xuyên

2.1.1 Cơ chế hoạt động

Cơ chế hoạt động TCP Westwood tương tự TCP Reno đã giới thiệu ởchương 1 nhưng có cải tiến ở giai đoạn phục hồi nhanh Nó sử dụng việc ướctính băng thông sẵn có và ước lượng băng thông để phục hồi nhanh hơn, do

đó đạt được thông lượng cao hơn

TCP Westwood đưa ra hai khái niệm cơ bản: ước lượng đầu cuối củabăng thông sẵn có, cách ước tính để thiết lập các ngưỡng khởi đầu chậm vàcửa sổ tắc nghẽn.

Ý tưởng chung là sử dụng ước lượng băng thông BWE để thiết lập cửa sổtắc nghẽn (cwin) và ngưỡng bắt đầu chậm(ssthresh) sau sự kiện tắc nghẽn Vai trò

cơ bản của cwin và ssthresh trong kiểm soát tắc nghẽn TCP là cwin được tăng lên

và giảm xuống để tìm độ trễ băng thông được miêu tả bằng ssthresh.

Hình 2.1: Sơ đồ điều khiển tắc nghẽn của TCP Westwood

2.1.2 Thuật toán ước tính băng thông

Một giả định cơ bản của thiết kế TCP, mạng là một "hộp đen" Kết quả

là, một TCP nguồn có thể không nhận được bất kỳ thông tin phản hồi tắcnghẽn rõ ràng từ mạng và chỉ dựa vào thông tin phản hồi ngầm như thời gianchờ, các ACK trùng lặp, đo thời gian khứ hồi RTT Trong công việc này, tôigiới thiệu một thông tin phản hồi ngầm mới được sử dụng để tránh tắc nghẽn

Fast retransmission

Retransmission timout

Congestion avoidance

Slow start Fast recovery

timeou t all ACK

timeou t

timeou t

cwnd ≥ ssthresh

start

send missing packet

non-dup ACK

≥ 3 dup ACK

≥ 3 dup ACK cwnd=cwnd+1 cwnd=cwnd+1/cwnd

cwnd=BWE*RTT mi

n

dup ACK ACK

ACK

Tôi tìm hiểu “ nguồn” thực hiện một ước tính đầu cuối của băng thông sẵn códọc theo kết nối TCP bằng cách đo tốc độ ACK hồi đáp Đối với ước tínhnhư vậy có ý nghĩa, “nguồn” phải có khả năng để dự đoán số lượng dữ liệuchuyển giao cho trạm nhận theo thời gian Các giao thức TCP cung cấp chotrạm nhận thông báo bên nhận của trạm phát một phân đoạn bằng ACK, mangmột dấu hiệu các phân đoạn đã nhận Khi một ACK được nhận bởi nguồn, nócho biết một số lượng dữ liệu tương ứng với một gói tin cụ thể được truyền đãđược chuyển tới điểm đến Nếu quá trình truyền dẫn không bị ảnh hưởng bởimất mát, thường thì trung bình các dữ liệu được chuyển giao tính theo lần cáckết quả ước tính hợp lý của băng thông hiện tại được sử dụng bởi nguồn.

Khi nhận các ACK trùng lặp, chúng được tính vào ước lượng băngthông và một ước tính mới cần phải được tính ngay sau sự tiếp nhận củachúng Tuy nhiên, nguồn không là nơi đảm bảo chắc chắn phân đoạn gây raviệc truyền tải các gói ACK trùng lặp, vì vậy nó không thể cập nhật dữ liệuđược tính bằng kích thước của phân đoạn đó Do đó trong kết nối đang diễn rakích thước trung bình của phân đoạn gửi xa nên được sử dụng, cho phépchỉnh sửa khi ACK tích lũy kế tiếp được nhận

Điều quan trọng cần chú ý là ngay sau khi sự kiện tắc nghẽn, xảy ra bởitime-out hoặc n ACKs trùng lặp, băng thông được sử dụng bởi kết nối đúngbằng với băng thông sẵn có tối đa tới kết nối đó Điều này được khẳng địnhbởi thực tế các gói tin bị rớt, là dấu hiệu cho thấy bộ đệm gần bão hòa Trướckhi sự kiện tắc nghẽn, băng thông sử dụng ít hơn hoặc bằng với băng thôngsẵn có bởi vì TCP nguồn vẫn còn thăm dò hiệu năng của mạng Điều quantrọng là sử dụng bộ lọc tần số thấp để có được các thành phần tần số thấp củabăng thông sẵn có Vì vậy nó rất hữu ích để theo dõi chỉ các thành phần tần sốthấp của băng thông sẵn có Trong chương trình này, ước lượng băng thông

được thực hiện bằng cách sử dụng một bộ lọc tấn số thấp, được mô tả bởiđoạn mã sau:

Đoạn mã ước lượng băng thông:

if (ACK is received)

sample_BWE[k]=(acked*pkt_size*8)/(now - lastacktime);

BWE[k]=(19/21)*BWE[k-1]+(1/21)*

(sample_BWE[k]+sample_BWE[k-1]); Endif

Trong đó:

acked: số lượng của các phân đoạn được thừa nhận bởi ACK gần nhất pkt_size: kích thước phân đoạn theo byte.

now: thời gian tại thời điểm hiện tại

lastacktime: thời gian ACK trước đó đã nhận được.

k,(k-1): giá trị hiện tại và trước đó của biến.

BWE: số đo bộ lọc tầng số thấp của băng thông sẵn có.

Bộ lọc được thu được bằng cách quyết định lệnh đầu tiên qua bộ lọctầng số thấp sử dụng quy tắc hình thang và bằng cách giả sử tỷ lệ giữa mộthằng thời gian với thời gian gốc bằng 10

Cuối cùng ước lượng băng thông được chuyển thành kích thước cửa sổ

thích hợp như cwin = BWE*RTT min , RTT min là thời gian khứ hồi nhỏ nhất đượctính toán bởi TCP nguồn(và được sử dụng để thiết lập thời gian timeout)

Trong phần này, tôi thực hiện ước lượng băng thông sẵn có tại TCPnguồn để giảm thiểu và định vị việc sửa đổi của TCP ở phía trạm phát Rõràng băng thông sẵn có dọc theo một kết nối TCP có thể được đánh giá ở phía

trạm nhận bằng cách sử dụng cùng một thủ tục lọc Sau đó, thông tin phản hồinày có thể được cung cấp trở lại thông qua các nguồn ACKs bằng cách thiết

lập trường AdvertisedWindow:

AdvertisedWindow:= min(AdvertisedWindow, RT T*BWE)

Một mặt, sự lựa chọn này có lợi thế lớn của sự ước lượng băng thôngthô đối với việc mất ACKs dọc theo đường trở về Thật vậy, mất ACKs, tức

là, dọc theo các kết nối TCP không đối xứng, có thể ảnh hưởng không tốt đếnước lượng băng thông tại nguồn Mặt khác, nó sẽ yêu cầu việc sửa đổi củaTCP nhận, trong khi sự lựa chọn đặt ước lượng băng thông tại trạm phát chỉ

ưu tiên khía cạnh trạm phát bởi sự thi hành của giao thức mới

•Những ảnh hưởng của độ trễ và ACKs lũy tích đối với BWE.

Sự kết hợp của ACKs trễ và tích lũy có khả năng gây cản trở quá trìnhước lượng băng thông Ví dụ: Giả sử một kết nối chuyển thành công các phânđoạn tới số 99, và 100 cho tới 109 thì bị mất do tắc nghẽn đột ngột Nếu cửa

sổ phát vào thời điểm đó là đủ lớn để gửi thêm 20 phân đoạn, và tắc nghẽnđược khai thông, các phân đoạn có thứ tự từ 110 đến 129 sẽ được chuyểnthành công và sẽ gây ra một loạt 20 ACKs trùng lặp Theo thuật toán ướclượng băng thông, mỗi DUPACK nhận được kích hoạt một bản cập nhậtBWE Trong trường hợp nhận 3 DUPACKs, TCP sẽ thiết lập cơ chế “FastReTransmist” và sẽ gửi lại các gói dữ liệu có thứ tự từ 100 trở đi Giả sử mấtmát không xảy ra, nơi nhận sẽ đáp lại những phân đoạn được gửi bằng cáchđưa ra 5 ACKs trễ (tương ứng với 10 phân đoạn từ 100 tới 109) và 1 ACKtích lũy(công nhận các phân đoạn từ 110 đến 129, mà nó nhận được và đượclưu trữ) Rõ ràng, nếu qui định giả trên được áp dụng đúng, ước lượng băngthông sẽ tăng vọt lên do sự tiếp nhận ACK liên tục ở nguồn, một trong số đó

chỉ thừa nhận 20 phân đoạn Do đó, giá trị của acked trong giả thiết phải được

chọn lựa cẩn thận Ví dụ này nhấn mạnh hai khía cạnh quan trọng của quátrình ước lượng băng thông:

+ Nguồn phải theo dõi số lượng DUPACKs nó đã nhận được trước khi

dữ liệu mới được thừa nhận;

+ Nguồn có thể phát hiện ACKs bị trễ và điều chỉnh phù hợp

Hai vấn đề này được trình bày bởi thủ tục AckedCount, chi tiết dưới

đây, hiển thị một tập các thao tác được thực hiện khi nhận được một ACK,

xác định chính xác acked Biến chính là accounted_for dùng để theo dõi các

DUPACK được nhận Khi một ACK nhận được, số lượng của các phân đoạn

nó nhận lần đầu tiên xác định (cumul_ack) Nếu cumul_ack là bằng 0, thì

ACK nhận là một DUPACK và tính như là 1 phân đoạn đối với BWE; đếm

DUPACK cũng được cập nhật Nếu cumul_ack lớn hơn 1, ACK nhận được

hoặc là một ACK trễ hoặc một ACK tích lũy sau một sự kiện truyền lại, trongtrường hợp đó, số lượng các đoạn ACKed được kiểm tra đối với các phân

đoạn được đếm (accounted_for) Nếu ACK nhận được công nhận ít hơn hoặc

cùng một số phân đoạn dự kiến, điều đó có nghĩa "mất tích" phân đoạn đượcphát hiện khi DUPACKs được nhận, và chúng không được tính lần hai NếuACK được nhận thừa nhận các phân đoạn nhiều hơn so với dự kiến, có nghĩamặc dù một phần trong số chúng đã phát hiện theo cách của DUPACKs, phầncòn lại được thừa nhận tích lũy bởi ACK hiện tại, do đó, ACK hiện tại chỉ nênđược tính như sự tích lũy các phân đoạn được thừa nhận Cần lưu ý rằng điều

kiện cuối cùng ước lượng một cách chính xác độ trễ ACKs là (cumul_ack = 2