Lớp vận chuyển và giao thức UDP, TCP

1
Lớp vận chuyển và giao thức UDP, TCP

2
Các kiểu chuyển tiếp dữ liệu

3
 Lớp vận chuyển
Lớp vận chuyển – giám sát và chuyển tiếp dữ liệu của các tiến trình xử lý hoặc
Transport Layer các chương trình lớp ứng dụng trên máy tính này sang máy
tính khác trong mạng.
 Mở rộng chức năng của tầng mạng và cho phép thiết lập
kênh tuyền thông logic giữa các tiến trình lớp ứng dụng

4
 Các chức năng của lớp vận chuyển
(1) Đóng gói Với dữ liệu được phát sinh từ các chương trình lớp ứng dụng,
Packetizing lớp vận chuyển cần phải đáp ứng xử lý để chuyển tiếp gói tin.
1) Chia nhở các gói tin lớn thành các phần nhỏ để phân lớp mạng có thể
xử lý.
2) Thêm phần tiêu đề vào mỗi gói tin chứa các phần dữ liệu được chia
để phía thu có thể tái ghép lại.
(2) Điều khiển kết nối Hỗ trợ bởi một số giao thức trong họ giao thức TCP/IP
Connection Control
(3) Đảm bảo tính tin cậy Hai kiểu chuyển tiếp gói tin giữa các trình ứng dụng của
Reliability lớp vận chuyển:
1) Dịch vụ hướng kết nối - connection oriented (TCP)
Thiết lập kết nối
Điều khiển luồng
Chuyển tiếp và thu nhận gói tin theo đúng thứ tự
Điều khiển lỗi
Điều khiển tắc nghẽn
2) Dịch vụ không hướng kết nối - connectionless (UDP)
Không đảm bảo tính tin cậy, chuyển tiếp gói tin không theo thứ tự
Giới gian tính năng trong điều khiển lỗi 5
 Các chức năng của lớp vận chuyển
(4) Addressing Địa chỉ lớp ứng dụng (địa chỉ cổng) dùng để phân biệt giữa các
tiến trình xử lý lớp trên đang thực hiện truyền thông dữ liệu.

client – demand service server – provide service

Cơ chế đánh địa chỉ cổng cho phép ghép luồng và tách luồng dữ liệu cho các ứng dụng lớp trên 6
Ghép luồng và tách luồng dữ liệu cho
các ứng dụng lớp trên

7
 Địa chỉ cổng

Địa chỉ cổng Giá trị nguyên 16-bit từ 0 đến 65,535 được dùng trong các giao thức
(chỉ số cổng) truyền thông TCP hoặc UDP để định danh về mặt logic cho các kết nối
 Các địa chỉ phổ biến (0–1023) – được ấn định cho các ứng dụng mạng
phổ biến và được quản lý bởi ICANN (Internet Corporation for
Assigned Names and Numbers) –được sử dụng bởi hệ điều hành cho
ứng dụng chạy trên các máy chủ đáp ứng nhiều kết nối
 (e.g. FTP = 21, TELNET = 23, HTTP = 80, etc.)
 Các địa chỉ đã được đăng ký (1024 – 49,151) – chỉ định bởi ICANN –
thông thường được sử dụng cho các ứng dụng phía đầu cuối người
dung có kết nối với các máy chủ trên mạng;
 Dải địa chỉ động (49,152 – 65,535) – dải giá trị địa chỉ cổng dự phòng,
có thể được sử dụng trong những giao thức hay chương trình truyền
thông riêng mà không cần đăng ký

8
Giao thức truyền thông UDP

UDP
message UDP

UDP segment

UDP
header

UDP
header

9
 Giao thức truyền thông UDP

Giao thức vận chuyển Là giao thức lớp vận chuyển không hướng kết nối và không
UDP đảm bảo tính tin cậy (không điều khiển luồng và giới hạn
việc kiểm tra dữ liệu) . UDP không thêm bất cứ xử lý nào
với các dịch vụ ở lớp IP, ngoại trừ cho phép cơ chế xử lý
ghép/tách các luồng dữ liệu truyền thông

Các ưu điểm chính 1) Không cần thiết lập kết nối giữa các hệ thông đầu cuối.
Với giao thức TCP cần có xứ thiết lập kêt nối “bắt tay 3 bước” trước khi
truyền nhận các gói dữ liệu  trễ thiết lập.

2) Không kiểm soát trạn thái kết nối – xử lý phần thông tiêu đề đơn giản.
Với giao thức TCP cần quản lý trạng thái kết nối ở mỗi hệ thông đầu cuối và
quản lý các thông tin khác như các chỉ số các gói dữ liệu truyền và nhận,
chỉ số các gói tin báo nhận ACK
3) Phần thông tin tiêu đề ngắn – chỉ có 8-byte.
So với giao thức TCP, phần thông tin tiêu đề là 20-bytes

4) Không điều khiển luồng và điều khiển tắc nghẽn – UDP có thể gửi các gói
nhanh nhất có thể.
 ứng dụng tốt trong các dịch vụ truyền dữ liệu thời gian thực.
10
 Cấu trúc gói tin UDP
Gói tin UDP 8 byte tiêu đề + dữ liệu lớp ứng dụng

header = 4 fields
only, each
consisting of 2
bytes

Chiều dài tổng Chỉ định kích thước của gói tin UDP bao gồm cả phần tiêu đề và tải
trong
16 bits ⇒ giá trị max có thể là 65,535 bytes; tuy nhiên do sự giới hạn về
tài nguyên bộ nhớ được phép cấp phát của hệ điều hành nên gói tin
UDP có kích thước tối đa là 8192
Chuỗi kiểm tra Chỉ dùng để xác định lỗi với dữ liệu trong gói tin UDP (header +
data)
 Việc tính toán kiểm tra được tùy chọn! - Nếu không cần tính, dữ
liệu thết lập cho trường này là các bít 0
 Nếu có lỗi được xác định, bản tin được bỏ qua và khong có xử nào
được thực hiện tiếp sau. 11
Tính Checksum cho phần tiêu đề của gói tin UDP

12
 Giao thức truyền thông UDP

Các ứng dụng giao thức UDP

1) UDP được dùng để truyền các gói tin quản lý mạng, ví dụ SNMP và DNS
• Các ứng dụng quản lý mạng thường được thực hiện khi hệ thống mạng gặp một
số vấn đề khi hoạt động, ví dụ như gặp phải tình trạng “tắc nghẽn”
2) UDP phù hợp với các ứng dụng truyền thông theo mô hình “yêu cầu” – “đáp
ứng” có tính định thời, không đòi hỏi nhiều về điều khiển luồng và lỗi
• ví dụ như Echo, Daytime,…
3) UDP thường được sử dụng trong các ứng dụng truyền thông đa phương tiện
yêu cầu thời gian thực
• Các ứng dụng đa phương tiện yêu cầu về tốc độ, độ trễ, tuy vậy vẫn chập nhận
một số lượng lỗi gói nhất định.
4) UDP phù hợp với các ứng dụng quảng bá (multicast hoặc broadcast)
• Giao thức TCP chỉ hỗ trợ ứng dụng truyền thông điểm – điểm, đơn hướng
(unicast)

13
Địa chỉ cổng của các ứng dụng chạy trên giao thức UDP

14
 Giao thức truyền thông TCP
Giao thức điều khiển truyền dẫn Là giao thức lớp vận chuyển có các thuộc tính sau:
TCP Định hướng kết nối: giữa các hệ thống đầu cuối phải bắt tay “handshake”
trước khi thực hiện truyền thông

Điều khiển luồng

Tính tin cậy = dữ liệu được sắp xếp + điều khiển lỗi: điều khiển lỗi
trong TCP bao gồm cả cơ chế xác định lỗi, xác định thứ tự và tinh sao chép
của các gói dữ liệu được xử lý.

Tính liên tục: Nếu dữ liệu bị chuyển tiếp sai và vượt quá thời gian cho phép
TCP sẽ cảnh báo với hệ thống và ngắt kết nối

Điều khiển tắc nghẽn: TCP giới hạn số lượng dữ liệu được chuyển tải
trong mạng nằm trong khả năng chuyển tải của mạng.

Kết nối điểm – điểm: kết nối TCP được thiết lập giữa hai phía phát và
phía thu theo tính chất một – một.

Truyền dẫn song công: xử lý phát và nhận độc lập, và dữ liệu truyển tải
theo hai hướng đồng thời. 15
 Giao thức truyền thông TCP
Cấu trúc gói tin TCP

16
 Cấu trúc gói tin TCP

Chỉ số phân đoạn dữ liệu Trường thông tin 32-bit, giúp cho xử lý phía thu xác định
Sequence Numbet được vị trí của byte đầu tiên trong mỗi bản tin (segment)

Chỉ số báo nhận Trường thông tin 32-bit – chỉ định vị trí của byte kế tiếp cần
được truyền đi ở phía phát

Chiều dài tiêu đề Trường thông tin 4-bit , là giá trị bội số của 4, chỉ định kích
thước (số byte) của phần thông tin tiêu đề
Reserved Trường thông tin 6-bit , trường thông tin dữ phòng (chứa
dùng)

Window Size Trường thông tin 16-bit , chỉ định kích thước của phần dữ
liệu trong bản tin TCP

17
 Cấu trúc gói tin TCP

Chuỗi kiểm tra trường thông tin 16 bit – sử dụng để xác định lỗi thành phần dữ
liệu trong gói tin TCP bao gồm (header + data) + 96-bit để đảm
bảo tính chính xác cho các xử lý, tính toán tiếp theo.
phần giả tiêu đề chứa một số trường thông tin trong phần tiêu đề gói
tin IP gồm: địa chỉ nguồn và địa chỉ đích, giao thức và chiều dài phân đoạn
dữ liệu. Phần giả tiêu đề này sẽ giúp xử lý chuyển tiếp nhầm bởi phân lớp
IP.
phần tiêu đề giả ngẫu nhiên giúp tránh xử lý với gữ liệu bị chuyển tiếp
nhầm ở lớp IP

Urgent Pointer – trường thông tin 16 bit – chỉ định vị trí (thứ tự) của byte cuối cùng trong khối
dữ liệu cần được truyền.

Options – có thể mở rộng lên 40 byte để mang thêm các thông tin dùng cho các quá trình xử lý
điều khiển luồng/ điều khiển tắc nghẽn …

Padding – các bít chèn, cách ly giữa phần thông tin tiêu đề và dữ liệu, được thiết lập là các bít 0
18
Cấu trúc gói tin TCP

19
 Các giá trị cờ điều khiển

Flag Miêu tả

Nếu bít được thiết lập, Xử lý thu nhận sẽ phân tích trường thông tin con trỏ
URG “urgent pointer”, để sử dụng khi dữ liệu cần đọc ra theo thứ tự trong chương
trình xử lý ở phía thu nhận
ACK Bít được thiết lập để báo nhận không lỗi với gói tin nhận được.

Nếu bít được thiết lập, phía nhận cần chuyển tiếp phân đoạn gói tin IP tới
PSH chương trình thu nhận phía thu ngay lập tức, không cần chờ cho đến khi bộ
đệm thu nhận được điền đầy
Nếu bít được thiết lập, sẽ báo hiệu phía thu bằng phía gửi đang thực hiện
RST ngắt kết nối và tất cả dữ liệu truyền thông đã được chuyển vào bộ đệm để xử
lý.

Khi bít được thiết lập, báo hiệu rằng phía phát đang thực hiện đồng bộ kết
SYN nối. Bít được sử dụng trong quá trình thiết lập kết nối giữa phía phát và phía
thu.

FIN Nếu thiết lập, báo hiệu phía thu rằng phía phát đã nhận được bít cuối cùng
của luồng dữ liệu TCP hiện tại.
20
 Chuyển tiếp luồng theo giao thức TCP

– Không giống với UDP, TCP là giao thức “thiên hướng dòng dữ liệu”
(stream-oriented’ protocol)
• TCP cho phép xử lý chuyển tiếp dữ liệu như một “luồng” (dòng) byte (với cả
ở phía phát và phía thu nhận)
• TCP thiết lập môi trường để các xử lý/ứng dụng lớp trên kết nối truyền
thông dữ liệu với nhau qua một đối tượng ảo, được gọi là một “đường ống”
(tube); xử lý phát sẽ ghi (xuất) dữ liệu vào đường ống, còn phía thu sẽ đọc dữ
liệu từ đường ống

21
 Các bộ đệm dữ liệu TCP
Xử lý TCP cần các bộ đệm để chứa dữ liệu – Xử lý phía phát và phía thu truyền và
thu nhận dữ liệu với tốc độ không giống nhau

Phân mảnh TCP

TCP Segment

 TCP nhóm một byte truyền thông vào

trong một phân mảnh, đồng thời thêm
phần tiêu đề trước dữ liệu trong mỗi
phân mảnh.
 Các phân mảnh TCP không cần có
kích thước giống nhau 22
 Điều khiển thiết lập kết nối theo giao thức TCP

Thiết lập kết nối Các tranh TCP phải thiết lập kết nối trước khi gửi đi dữ liệu của
mình, thông qua quá trình thiết lập kết nối bắt tay ba bước.
TCP
“Three-Way Handshake”:
(1) máy trạm gửi bản tin yêu cầu kết nối SYN cho server, kèm theo
các thông tin:
• Source and Destination Port – chỉ định địa chỉ cổng (chỉ số cổng)
truyền thông
• SYN = 1
• Sequence Number = client_seq – thiết lập giá trị ngẫu nhiên
• Không mang theo dữ liệu!!!

Cấp phát bộ
đệm dữ liệu

Cấp phát bộ
đệm dữ liệu
ACK = Client seq + Client TCP
Length

23
 Điều khiển thiết lập kết nối theo giao thức TCP

Quá trình bắt tay 3 bước (tiếp)

(2) khi server nhận được bản tin yêu cầu kết nối SYN, nó sẽ cấp phát bộ nhớ và
thiết lập các biến xử lý kết nối, và gửi bản tin báo hiệu chấp nhận kết nối
(SYNACK) cho phía
máy trạm có yêu cầu.
• SYN = 1
• Sequence Number = server_seq
• ACK = client_seq + 1 (chỉ +1 vì chưa có dữ liệu nào được truyền)

(3) khi phía máy trạm nhận được bản tin SYNACK, nó cũng cấp phát bộ nhớ và
thiết lập các biến cho xử lý truyền thông, và gửi lại bản tin báo nhận (ACK)
• SYN = 0 – kết nối đã được thiết lập!
• Sequence Number = client_seq + 1
• ACK = server_seq + 1

24
 Điều khiển thiết lập kết nối theo giao thức TCP

Máy trạm A (client) yêu cầu kết nối với A’s port B’s port
máy chủ B (server) …
A’s Initial Sequence Number

Acknowledgment

20 0 Flags Advertised window

Checksum Urgent pointer

Options (variable)

Các cờ : SYN
FIN
RST
PSH
URG
ACK
25
 Điều khiển thiết lập kết nối theo giao thức TCP

B chấp nhận yêu cầu kết nối từ A, và phản B’s port A’s port
hồi gói tin, chờ các gói dữ liệu tiếp theo…
B’s Initial Sequence Number
… A nhận gói tin phản hồi từ B, chuẩn bị A’s ISN plus 1
kết nối với B …
20 0 Flags Advertised window

Checksum Urgent pointer

Options (variable)

Các cờ : SYN
FIN
RST
PSH
URG
ACK
26
 Điều khiển thiết lập kết nối theo giao thức TCP

A xác nhận lại với B bằng 1 gói dữ liệu A’s port B’s port
và bắt đầu truyền thông dữ liệu…
Sequence number
… Khi B nhận được xác nhận từ A, cũng
B’s ISN plus 1
bắt đầu quá trình truyền thông dữ liệu…
20 0 Flags Advertised window

Checksum Urgent pointer

Options (variable)

Các cờ : SYN
FIN
RST
PSH
URG
ACK
27
 Điều khiển truyền thông theo giao thức TCP

Giản đồ chuyển trạng thái của máy trạm và máy

chủ TCP trong xử lý truyền thông

dotted lines = server, solid lines = client 28

 Điều khiển truyền thông theo giao thức TCP

Các trạng thái xử lý

Tên trạng thái Miêu tả chức năng và ý nghĩa
CLOSED Không có một kết nối nào đang được thiết lập trước đó

LISTEN S Máy chủ chờ yêu cầu kết nối từ phía các máy trạm.

SYN-SENT C Một yêu cầu kết nối được gửi đi; chờ báo nhận.

SYN-RCVD S Một yêu cầu kết nối được nhận về.

ESTABLISHED Kết nối đã được thiết lập, tiến hành quá trình truyền thông.

FIN-WAIT-1 C Lớp úng dụng được yêu cầu đóng kết nối.

FIN-WAIT-2 C Hệ thống đầu cuối chấp nhận đóng kết nối.

TIME-WAIT C Trạng thái chờ và truyền lại các bản tin để đóng kết nối hoàn toàn.

CLOSE-WAIT S Máy chủ chờ thông báo từ lớp ứng dụng để đóng kết nối.

LAST-ACK S Máy chủ đạng chờ bản tin báo nhận ACK cuối cùng để đóng kết nối.
29
 Điều khiển truyền thông theo giao thức TCP

Chuỗi xử lý của máy trạm TCP

(1) Máy trạm TCP thiết lập ban đầu ở trạng thái CLOSED .

(2) Ở trạng thái này, máy trạm TCP có thể nhận một yêu cầu
mở “cổng truyền thông” từ các chương trình lớp trên để
thu nhận dữ liệu.
Ngay sau đó, bản tin (segment) SYN được
gửi tới máy chủ TCP và chuyển vào trạng
thái SYN-SENT.

(3)Trong khi ở trạng thái SYN-SENT, máy trạm

TCP có thể nhận được bản tin SYN+ACK từ
một máy chủ TCP kết nối. Ngay sau đó, nó
sẽ gửi một bản tin ACK cho máy chủ TCP và
chuyển vào trạng thái ESTABLISHED, cho
truyền nhận dữ liệu. Máy trạm TCP có thể ở
trạng thái này trong một thời gian dài trong
suôt quá trình truyền thông dữ liệu.

(4)Ở trạng thái ESTABLISHED, máy trạm TCP

có thể nhận một bản tin yêu cầu đóng (ngắt)
kết nối tử chương trình ứng dụng lớp trên của
send & receive
máy trạm. Ngay sau đó nó sẽ gửi một bản tin FIN
receive only
cho máy chủ TCP đang kết nối và chuyển vào trạng
thái FIN-WAIT-1. 30
 Điều khiển truyền thông theo giao thức TCP
Chuỗi xử lý của máy trạm TCP
(5)Khi ở trạng thái FIN-WAIT-1, nếu nhận được
bản tin ACK từ phía máy chủ, máy trạm sẽ
chuyển sang trạng thái FIN-WAIT-2, và
không gửi đi bản tin báo hiệu tiếp theo nào.
Truyền thông giữa 2 máy được
kêt thúc, kết nối được ngắt từ một chiều

(6)Máy trạm TCP vẫn ở trạng thái FIN-WAIT-2

và chở cho máy chủ TCP đóng kết nối đầu
cuối. Khi máy trạm nhận được bản tin
FIN từ phía máy chủ nó sẽ gửi lại bản tin
ACK và chuyển về trạng thái TIME-WAIT.

(7)Khi ở trạn thái TIME-WAIT, Máy trạm TCP định thời đợi một khoảng thời gian.
Khoảng thời gian đợi “TIME-WAIT” được thiết lập gấp đôi so với thời gian sống dài nhất
của một gói tin trong mạng (maximum segment lifetime) (2MSL). Máy trạm vẫn ở trạng
thái này trước khi đóng hẳn kết nối để chắc chắn rằng bản tin ACK được gửi tới máy chủ.
nếu do một nguyên nhân nào bản tin FIN gửi từ phía máy chủ không được nhận ở máy trạm
thì các bản tin ACK sẽ được gửi lại, và việc thiết lập định thời sẽ thực hiện lại để đảm bảo
đảm bảo rằng tất cả các bản tin được trao đổi trước đó được xóa bởi mạng 31
Chuỗi xử lý của máy chủ TCP
Thông thường, máy chủ TCP có thể ở bất cứ trạng thái nào
Trong 11 trạng thái chỉ định. Tuy nhiên thông thường máy
chủ có thể ở tại một trạng thái trong chuỗi xử lý sau:

(1) Máy chủ TCP ở trạng thái CLOSED.

(2)Khi ở trạng thái này, máy trạm TCP có thể
nhận một yêu cầu kích hoạt một cổng
truyền thông từ các chương trình ứng dụng
lớp trên. Sau đó máy chủ sẽ chuyển sang
trạng thái LISTEN.
(3)Trong khi ở trạng thái này LISTEN, máy chủ
có thể nhận được bản tin từ phía máy trạm.
Ngay sau đó nó sẽ gửi lại một bản tin
SYN + ACK cho máy trạm và chuyển sang
trạng thái SYN-RCVD
(4)Khi ở trạng thái SYN-RCVD, máy chủ
có thể nhận một bản tin ACK từ phía máy
trạm để chuyển sang trạng thái tiếp send & receive
theo ESTABLISHED. Máy trạm và máy chủ
TCP sẽ ở trạng thái này trong một thời gian dài
send only 32
để truyền nhận dữ liệu.
 Điều khiển truyền thông theo giao thức TCP
Chuỗi xử lý của máy chủ TCP

(5) Trong khi ở trạng thái ESTABLISHED, Máy

chủ TCP
có thể nhận được bản tin FIN từ phía máy
trạm để báo
hiệu cần kết thúc truyền thông và cắt kết nối.
Khi đó máy chủ sẽ gửi lại bản tin ACK
cho máy trạm có yêu cầu và chuyển
sang trạng thái CLOSE-WAIT.
(6)Trong khi ở trạng thái CLOSE-WAIT, máy
chủ TCP sẽ chờ cho đến khi nhận được yêu
cầu đóng kết nối từ chương trinh ứng dụng
lớp trên và sau đó máy chủ sẽ gửi cho máy
trạm bản tin FIN và chuyển sang trạng
thái LAST-ACK.
(7)Khi ở trạng thái LAST-ACK, Máy chủ
sẽ chờ nhận bản tin ACK cuối cùng từ
phía máy trạm và đóng kết nối, chuyển
về chế độ CLOSED. 33
Điều khiển ngắt kết nối trong TCP

34
Truyền thông dữ liệu theo giao thức TCP
 Chuỗi xử lý
truyền thông
theo giao thức
TCP

receiving buffer
deallocated
sending buffer
deallocated

receiving buffer
deallocated

sending buffer
deallocated

36
37
TCP “Stream of Bytes” Service

Byte 80
Byte 3
Byte 2
Byte 1
Byte 0
Byte 80
Byte 3
Byte 2
Byte 1
Byte 0
Host A

Host B

38
 …Emulated Using TCP
“Segments”
Host A Byte 0
Byte 1
Byte 2
Byte 3

Byte 80

Segment sent when:

TCP Data 1. Segment full (Max Segment Size),
2. Not full, but times out, or
3. “Pushed” by application.

TCP Data
Host B
Byte 0
Byte 1
Byte 2
Byte 3

Byte 80

39
 TCP Segment
IP Data
TCP Data (segment) TCP Hdr IP Hdr

• IP packet
– No bigger than Maximum Transmission Unit (MTU)
– E.g., up to 1500 bytes on an Ethernet
• TCP packet
– IP packet with a TCP header and data inside
– TCP header is typically 20 bytes long
• TCP segment
– No more than Maximum Segment Size (MSS) bytes
40
– E.g., up to 1460 consecutive bytes from the stream
 Sequence Number
Host A
ISN (initial sequence number)

Byte 81

Sequence
TCP Data
number = 1st
byte

TCP Data
Host B

41
 Initial Sequence Number (ISN)
• Sequence number for the very first byte
– E.g., Why not a de facto ISN of 0?
• Practical issue
– IP addresses and port #s uniquely identify a connection
– Eventually, though, these port #s do get used again
– … and there is a chance an old packet is still in flight
– … and might be associated with the new connection
• So, TCP requires changing the ISN over time
– Set from a 32-bit clock that ticks every 4 microseconds
– … which only wraps around once every 4.55 hours!
• But, this means the hosts need to exchange ISNs
42
Figure 23.22 Sliding window

A sliding window is used to make transmission more efficient as well as

to control the flow of data so that the destination does not become
overwhelmed with data. TCP sliding windows are byte-oriented.
 Example 23.4

What is the value of the receiver window (rwnd) for host A if the receiver, host B,
has a buffer size of 5000 bytes and 1000 bytes of received and unprocessed data?

Solution
The value of rwnd = 5000 − 1000 = 4000. Host B can receive only 4000 bytes of
data before overflowing its buffer. Host B advertises this value in its next
segment to A.

What is the size of the window for host A if the value of rwnd is 3000 bytes and
the value of cwnd is 3500 bytes?

Solution
The size of the window is the smaller of rwnd and cwnd, which is 3000 bytes.

23.44
 Example 23.6

Figure 23.23 shows an unrealistic example of a sliding window. The sender has sent bytes
up to 202. We assume that cwnd is 20 (in reality this value is thousands of bytes). The
receiver has sent an acknowledgment number of 200 with an rwnd of 9 bytes (in reality
this value is thousands of bytes). The size of the sender window is the minimum of rwnd
and cwnd, or 9 bytes. Bytes 200 to 202 are sent, but not acknowledged. Bytes 203 to 208
can be sent without worrying about acknowledgment. Bytes 209 and above cannot be sent.
 Note

Some points about TCP sliding windows:

❏ The size of the window is the lesser of rwnd and
cwnd.
❏ The source does not have to send a full window’s
worth of data.
❏ The window can be opened or closed by the
receiver, but should not be shrunk.
❏ The destination can send an acknowledgment at
any time as long as it does not result in a shrinking
window.
❏ The receiver can temporarily shut down the
window; the sender, however, can always send a
segment of 1 byte after the window is shut down.
23.46
 Figure 23.24 Normal operation

23.47
 Figure 23.25 Lost segment

23.48
 Figure 23.26 Fast retransmission

23.49
 23-4 SCTP

Stream Control Transmission Protocol (SCTP) is a

new reliable, message-oriented transport layer
protocol. SCTP, however, is mostly designed for
Internet applications that have recently been
introduced. These new applications need a more
sophisticated service than TCP can provide.
Topics discussed in this section:
SCTP Services and Features
Packet Format
An SCTP Association
Flow Control and Error Control
23.51
SCTP is a message-oriented, reliable protocol that combines the best
features of UDP and TCP.

Table 23.4 Some SCTP applications

Figure 23.27 Multiple-stream concept

An association in SCTP can involve multiple streams.

Figure 23.28 Multihoming concept

SCTP association allows multiple IP addresses for each end.

In SCTP, a data chunk is numbered using a TSN.

To distinguish between different streams, SCTP uses an SI.

To distinguish between different data chunks belonging to the same

stream, SCTP uses SSNs.
Figure 23.29 Comparison between a TCP segment and an SCTP packet

TCP has segments; SCTP has packets.

In SCTP, control information and data information are carried in

separate chunks.
 Figure 23.30 Packet, data chunks, and streams

23.56
 Data chunks are identified by three items: TSN, SI, and SSN.
TSN is a cumulative number identifying the association; SI defines the
stream; SSN defines the chunk in a stream.

In SCTP, acknowledgment numbers are used to acknowledge only data

chunks;
control chunks are acknowledged by other control chunks if necessary.

Figure 23.31 SCTP packet format

Figure 23.32 General header

In an SCTP packet, control chunks come before data chunks.

Table 23.5 Chunks

 A connection in SCTP is called an association.

No other chunk is allowed in a packet carrying an INIT or INIT ACK

chunk.
A COOKIE ECHO or a COOKIE ACK chunk can carry data chunks.

Figure 23.33 Four-way handshaking

 Figure 23.34 Simple data transfer

In SCTP, only DATA

chunks
consume TSNs;
DATA chunks are the only
chunks
that are acknowledged.

23.60
Figure 23.35 Association termination

The acknowledgment in SCTP defines the cumulative TSN, the TSN of

the last data chunk received in order.
Figure 23.36 Flow control, receiver site

Figure 23.37 Flow control, sender site

 Figure 23.38 Flow control scenario

23.63
 Figure 23.39 Error control, receiver site

Figure 23.40 Error

control, sender site
 Flow Control
 Some Points about TCP’s Sliding Windows:

 A sliding window is used to make transmission more efficient as well

as to control the flow of data so that the destination does not become
overwhelmed with data.

 It is called Selective Repeat ARQ.

 Built on top of go-back-n ARQ
 Accepts segments out of order, but error free
 Repeat transmission of only selective segments

 TCP’s sliding windows are byte oriented. TCP is a stream-oriented

protocol. Data is presented as streams of characters.
 The window size specifies the receiver’s current buffer size.
 The source does not have to send a full window’s worth of data.
 The size of the window can be increased or decreased by the
destination.
 The destination can send an acknowledgment at any time.
K. Salah
 TCP Sliding Window

K. Salah
 Corrupted Segment

K. Salah
 Lost Acknowledgement

K. Salah
•
Congestion Control
Remember flow control is between Sender and Receiver, and Congestion Control takes care of
congestion in the intermediate nodes (routers).
• To avoid congestion collapse (I.e., network throughput to be zero), receiver controls the window size.
• Allowed_Window =Min(receiver_advertisement, congestion_window)
– Host can inject into the network as many segments as the receiver_advertisement (I.e. window
size of the receiver) allows.
– Congestion_window is for controlling congestion at the intermediate router
– Initially congestion_window = receiver MSS
• Congestion Avoidance is a combination of:
– Slow-Start and Additive Increase:
• Whenever starting traffic on a new connection or increasing traffic after a period of
congestion, start the congestion window at the size of a single segment and
increase the congestion window by one segment each time an acknowledgement
arrives.
• In order to avoid increasing the window size too quickly (I.e. exponential increase)
and causing more congestion, apply additive increase, meaning only increase
window size by 1 after the size reaches the threshold. Initially threshold = ½
receiver_advertisement.
– Multiplicative Decrease
• Upon loss of a segment, reduce the congestion window down to one segment,
and threshold = ½ last allowed window size.

K. Salah
 QoS Metrics

• Reliability: Lack of reliability means losing a packet or acknowledgement,

which entails retransmission
• Delay: Source-to-destination delay.
• Jitter: Variation in delay for packets belonging to the same flow.
• Bandwidth: bits per second

K. Salah
 6
TCP Flow Control

Network Flow Control – regulates the amount of data a source can send
before receiving an acknowledgment from the
destination
• extreme case 1: send byte by byte ⇒ to slow
• extreme case 2: send all data ⇒ overwhelm
receiver
• solution: speed matching service – rate at which
sender application is sending is matched against
rate at which receiving application is receiving
 7
TCP Flow Control (cont.)
TCP Flow Control – controls amount of buffer data that sender can send to
receiver at any particular time, using ‘sliding window’
principle
• SLIDING WINDOW – spans a portion of sending buffer
containing bytes that host can safely send to other side
without worrying that it might overwhelm receiver
• window’s left pointer moves as host sends more bytes
• window’s right pointer moves as host receives new
acknowledgment

What is max size of sliding window?! How is it determined?!

Max window size

sender buffer
 8
TCP Flow Control (cont.)
Receive Window – variable used to give sender an idea of how much free
buffer space is available at the receiver
• during connection establishment receiver allocates a
receive buffer – buffer size = RcvBuffer (such allocation,
in fact, happens both on client and server side)
• as receiver receives bytes that are correct and in sequence,
it places them in receive buffer ⇒ spare room in buffer =
RcvWindow = RcvBuffer – [Last Byte Received – Last Byte
Read]
• receiver advertises available space in receive buffer by
placing RcvWindow in ‘window size’ field of TCP headers
• RcvWindow value can be changed at any point during
communication - ‘window size’ field is adjusted accordingly

last byte received last byte read

spare room for new correct, in-order,
unacknowledged data acknowledged data

receiver buffer
 9
TCP Flow Control (cont.)
Sender Window – sliding window over sender buffer – must be of receive
window (RcvWindow) size!
• by keeping amount of unacknowledged data ≤ RcvWindow
sender is assured that it is not overflowing the receiver

sender buffer

Expending Sender Window – if application reads data faster than it comes

in ⇒ RcvWindow increases ⇒ new ‘window
size’ value can be relayed to sender resulting
in sender window expansion

sender buffer
 10
TCP Flow Control (cont.)

Shrinking Sender Window – if application reads data slower than it comes

in ⇒ RcvWindow decrease ⇒ receiver must
inform sender to shrink its sender window size

sender buffer

Closing Sender Window – if receiver buffer is totally full ⇒ RcvWindow = 0

⇒ sender must entirely close its sender window
• now, suppose receiver does not have anything
to send back to sender ⇒ sender cannot learn
if/when receive window ‘opens’
solution: sender sends 1-byte segments to make
receiver re-announce receive window size –
RcvWindow is sent only as part of header
carrying new data and/or acknowledgment!
 11
TCP Flow Control (cont.)
Example [ TCP window size adjustment ]
What is the value of the receiver window (RcvWindow) for host A if the receiver,
host B, has a buffer of size 5,000 and 1,000 bytes of received and unprocessed data?
Solution:
RcvWindow = 5,000 – 1,000 = 4,000. Host B can receive only 4,000 bytes of data
before overflowing its buffer. Host B advertises this value in its next segment to A.

Example [ TCP window size adjustment ]

In the figure below, the sender receives a packet with an acknowledgment value of
206 and RcvWindow of 12. The host has not sent any new bytes. Show the new window.

Solution:
window size = 12
 12
TCP Flow Control (cont.)

Silly Window Syndrome – (SWS) phenomenon occurs as a result of

1) a transmitter immediately sends out very small
amounts of data – SWS by Sender
2) recipient advertises window sizes that are too
small – SWS by Receiver
• basic TCP sliding window technique does NOT
set minimum size on transmitted segments ⇒
this can result in a situation where many small
inefficient segments are sent, rather than a
smaller number of larger ones

Example [ SWS by Sender ]

Suppose a TCP client is receiving data from the sending application in blocks of 10
bytes. How long should the client wait before sending data?
(a) send right away ⇒ 10 bytes data + 40 bytes TCP/IP header ⇒ 400% overhead
(b) wait for more data ⇒ may have to wait too long ⇒ may considerably delay
receiving application
 13
TCP Flow Control (cont.)
Example [ SWS by receiver ]

This diagram shows one example

of how the phenomenon known
as TCP silly window syndrome
can arise.

The client is trying to send data

as fast as possible to the server,
which is very busy and cannot
clear its buffers promptly.

Each time the client sends data

the server reduces its receive
window.

The size of the messages the

client sends shrinks until it is
only sending very small,
inefficient segments.

source: http://www.tcpipguide.com/free/t_TCPSillyWindowSyndromeandChangesTotheSlidingWindow.htm
 14
TCP Flow Control (cont.)
SWS by Sender – occurs if sending application creates data slowly (e.g.
1 byte at a time), and TCP immediately sends data ⇒
considerable network overhead! (20 byte IP + 20 byte TCP)

Client Telnet: send a key header byte

41 bytes header Server Telnet: acknowledge

40 bytes

header Server Telnet: after processing data

update RcvWindw
40 bytes

SWS by Sender – Nagle’s Solution:

Avoidance (a) as long as there is no un-ACK data outstanding in the
buffer, data can be immediately send – even if only 1 byte
(b) while there is un-ACK data, all subsequently segments
are held in the buffer until
(b.1) previous segment is acknowledged (fast network)
(b.2) enough data have accumulated to fill a max-size
segment (slow network)
• advantage: algorithm self-adjusts to traffic load
• disadvantage: should be disabled in interactive applications
 15
TCP Flow Control (cont.)
SWS by Receiver:
Receive Window Size = 0 receiver’s buffer is full

application reads 1 byte

room for one more byte

inform sender
new RcvWindow sent
header
data from sender
header byte new byte arrives

receiver’s buffer is full

SWS by Receiver 1) Clark’s Solution: send an ACK as soon as data arrives

with RcvWindow = 0 as long as
(a) half the buffer frees up, or
(b) enough space for maximum size segment

2) Delayed Acknowledgments: do NOT ACK segments

immediately – wait until decent amount of space available
• advantage: less traffic than with Clark’s Solution
• disadvantage: delayed ACKs may force sender to retransmit
 16
TCP Error Control
TCP Error Control – TCP delivers entire stream to application program on
the other end reliably
• no lost segments
• no corrupted segments
• no duplicated segments
• all segments in order

TCP
TCPError
ErrorControl
Controlprovides
providesservice
servicefor
fordetecting
detectingcorrupted
corruptedsegments,
segments,lost
lost
segments, duplicated and out-of-order segments.
segments, duplicated and out-of-order segments.

Special Tools for (a) sequence numbers – enable detection of lost, out-of
TCP Error Control -order or duplicate segments on receiver side
(b) checksum – enables detection of corrupted segments
on receiver’s side

(c) acknowledgment enable error control

on sender side
(d) timers
• TCP sender starts one timer for each segment sent
(theoretically – see Kurose, pp. 239); if corresponding
ACK does not arrive before timer expires segment is
considered lost or corrupted and must be retransmitted
 18
TCP Error Control (cont.)
Example [ TCP error control – normal operation ]

sender
receiver
 19
TCP Error Control (cont.)
Detection of Lost, 1) receiver detects
(a) lost and out-of-order segments by receiving seg.
Out-Of-Order and with higher sequence numbers than expected
Corrupted Segments • action: discard out-of-order segments?

(b) corrupted segments - immediately using checksum

• action: discard corrupted segment

2) sender detect lost, out-of-order and corrupted seg.

by NOT receiving their ACKs within Time-out interval
• action: retransmit

Rule 3

Rule 4
 20
TCP Error Control (cont.)
Receiver Action on simply discard segments – ineffective
Detecting Lost and keep segments but do not send any ACK – ineffective
(must wait entire Time-out to receive missing segment)
Out-of-Order Segments: keep segment and reacknowledge last in-order byte
Fast Retransmit received ⇒ enables fast retransmit

Example [ TCP error control – fast retransmit ]

(a) receiver - on every out-of-order seg.

acknowledge the last in-order byte
received
(b) sender - in case that 3 duplicate ACKs
are received immediately retransmit the
missing segment (fast retransmit) even
if the segment’s timer has not expired;
then proceed with fast recovery ...
(Kurose, pp. 245!)

Why should we wait for (atleast) 3 duplicate ACK before initiating‘fact recovery’?!
 21
TCP Error Control (cont.)
Detection of Lost 1) receiver detects lost acknowledgments by receiving
Acknowledgments duplicate segments
• action: resend acknowledgement, discard duplicate

2) sender detects lost acknowledgments

(a) if corresponding timer expires, as in lost segments
(sender cannot tell the difference between a lost segment
and a lost ACK – the same recovery mechanism applies)
(b) may not even notice a lost acknowledgment - TCP
uses cumulative acknowledgment system, so each
ACK is confirmation that everything up to the byte
specified
 22
TCP Error Control (cont.)
Example [ TCP error control – lost ACK scenario ]

Host A Host B Host A Host B

Seq=92
, 8 byt Seq=92
es da ta , 8 bytes da
ta
=100 100
ACK Seq=1 0 CK=
A
0, 20
timeout X bytes data
loss timeout X
Seq=92
loss
, 8 bytes data
ACK=120

=100
ACK

time
time Cumulative ACK
lost ACK scenario scenario
Sender notices lost acknowledgments if its packets are sent
timeout (or more) time units apart.
23
 24
TCP Error Control (cont.)
TCP Timers

detects checks detects used in

missing 0-size idle connection
ACKs windows clients termination

Time-waited – during connection termination, connection is held limbo for

Timer time-waited period (usually 2*MSL) to make sure that all packets
created by this connection have died off (see pp. 30 earlier lecture)
MSL ≈ 120 [sec] – may depend on OS implementation

Keep-alive – timer used in some implementations to prevent a long idle

Timer connection between two TCPs (usually 2h)
• each time server hears from client, it resets this timer
• if server does not hear from client in 2h, it sends a probe segment;
if there is no response in 10 probes, 75 sec apart, server terminates
connection
 25
TCP Error Control (cont.)
Persistence – timer used to correct 0-size receive window deadlock (see pp. 10)
Timer • assume:
(a) sender receives and ACK with RcvWindow = 0
(b) sender stops transmission
(c) receiver eventually frees buffer and sends and ACK with
non-zero RcvWindow, but this ACK gets lost!

• consequence: deadlock – sender may wait forever!

• SOLUTION: each time a sender gets a 0-window segment it starts

persistence timer
(a) if timer goes off send a probe segment with only 1-byte of data
(b) probe segments alert receiving TCP that acknowledgment may
have got lost and should be resent

• initially persistence timer = 2*RTT = retransmission timer; after

that it is doubled until reaching 60 sec; finally one probe every
60 sec …
 26
TCP Error Control (cont.)
Retransmission – determines how long to wait for ACK of a previously sent
segment before retransmission
Timer / Timeout
(RTO) • depends on distance and network congestion ⇒ different
for each connection, may change during connection-lifetime
estimated accounts for irregularities in the network

RTO RTT  Δ(RTT), or simply RTO ≈2 *RTT

RTT ≈ t(ACKreceived)- t(data sent)

Initiating TCP Responding TCP

T1 Data Tx Data Propagation

Ack Tx Data Processing

Ack Propagation
Ack Processing
T2 Round-Trip Time (RTT)~ = T2 – T1

Calculation – TCP determines approximate RTT between devices and adjusts

it over time to compensate for increases and decreases
• does not use a single number – instead, uses dynamic / adaptive
formulas that employ a sequence of earlier observations of RTT
 27
TCP Error Control (cont.)
Average / Smoothed RTT Update Formulas

estimated observed
K1 easier to calculate –
1) Simple Average 1 not necessary to
ARTT(K 1)  ∑RTT(i)
K 1 i1
calculate entire
summation

K 1
ARTT(K 1)  ARTT(K) RTT(K 1)
K 1 K 1

• drawback: gives equal weight to each observation

• solution: give greater weight to more recent instances since they are more
likely to reflect future behavior

2) Exponential (Smoothed) SRTT(K 1) α ⋅SRTT(K)(1−α)⋅RTT(K 1)

Average
• 0<α<1 ⇒ smaller values of α give greater weight to more recent observations
• α=0.5 ⇒ last 4-5 observations matter, α=0.85 ⇒ last 10 observations matter
 29
TCP Error Control (cont.)
Karn’s Algorithm – assume an ACK has arrived after retransmission of a
TCP segment – does this ACK correspond to the
original or retransmitted segment?!
• the source cannot distinguish between two cases
• misinterpreatation can cause RTT to be set much too
high or much too low
• solution – Karn’s Algorithm: do not update the value
of ARTT with RTTs measured for retransmitted segments
 30
Exercise

1. In _________________ data are sent or processed at a very inefficient rate,

such as 1 byte at a time.
(a) Nagle’s syndrome
(b) silly window syndrome
(c) sliding window syndrome
(d) delayed acknowledgment.

2. Suppose Host A sends two TCP segments back to back to Host B over a TCP
connection. The first segment has a sequence number 90, the second segment
has sequence number 110.
(a) How much data is in the first segment?
(b) Suppose that the first segment is lost but the second segment arrives at
B. In the ACK that Host B sends to Host A, what will be the ACK number?
 1

TCP: Congestion Control

Required reading:
Kurose 3.6, 3.7

CSE 4213, Fall 2006

Instructor: N. Vlajic
 2
Congestion Control
Network Congestion – occurs if network load (number of packets sent to
network) is greater than network capacity (number
of packets network can handle)
• too many sources sending too much data too fast
for network to handle

Network Congestion 1) long packet delays due to long queueing delays

Manifestations in router buffers
2) lost packets (decreased throughput) due to buffer
overflow at routers

Congestion Control – set of mechanisms and techniques to control network

congestion and keep overall traffic load below network
capacity
 3
Congestion Control (cont.)
Example [ network / congestion performance measures ]

How can you explain the exponential increase in delay as load approaches capacity
and the exponential decrease in throughput as load exceeds capacity?

Network load has a “positive feedback” effect on network delay increase and
network throughput decrease.

1) When a packet is delayed, the source, not receiving the acknowledgment, retransmits
the packet, which makes the queues longer and delays (i.e. congestion) worse!
2) When the load exceeds the capacity, the queues become full and the routers have to
discard some packets. More discarded packets ⇒ more retransmitted packets ⇒
less room for regular (non-retransmitted) packets in queues ⇒ lower throughput
 4
Congestion Control (cont.)
Approaches Towards 1) network assisted congestion control – also known
Congestion Control as explicit congestion control
• network-layer components (e.g. routers) provide
explicit feedback to end systems about congestion
state in the network – feedback could be sent in
either direction:
(a) from a network router directly back to the sender
(b) a network router marks a field in a packet flowing
from the sender to the receiver; upon receipt of
the marked field the receiver notifies the sender …
• example: ATM rate-based congestion control

Congestion Control (cont.)
Approaches Towards
Congestion Control
(cont.)
5
2) end-to-end congestion control – also known as
implicit congestion control
• network-layer provides NO explicit support for
congestion-control purposes
• end system infers congestion based on observed
network behavior (e.g. packet loss, delay, etc.)
• example: TCP window-based congestion control
(e.g. TCP packet loss is taken as an indication of
network congestion and TCP decreases its sending
window size accordingly)

TCP must use end-to-end congestion control, since the IP layer provides no explicit
feedback to the end systems regarding network congestion.
 6
TCP Congestion Control
Causes of 1) receiver is overwhelmed with data and drops packets, or
receiver sends new RcvWindow – flow control problem
Packet Loss in
• solution: sender should decrease sending rate
TCP/IP Networks
2) a router on the path between sender and receiver is
congested and drops packets – congestion control problem
• solution: sender should decrease sending rate
flow and error control together determine senders behavior!!!

In TCP, the sender’s window size should be controlled not only by the receive
window size (RcvWindow) but also by congestion in the network.
This was ignored in our earlier discussion on TCP Flow Control.

Congestion Window – (CongWin) imposes indirect constraint on rate at

which TCP sender can send traffic into network
• amount of unacknowledged data may not exceed
minimum of CongWin and RcvWindow !!!

actual window size ≤ min{ RcvWindow, CongWin }

 7
TCP Congestion Control (cont.)

CongWin

RcvWindow

Sending buffer

Approximate sender’s rate,

assuming negligible loss and
transmission delay, and
RcvWindow > CongWin.
CongWin By adjusting the value of
rate ≈ [bps] CongWin, the sender can
RTT adjust the rate at which it sends
data into its connection.

CongWin is a dynamic parameter –

its value changes as a function of perceived network congestion.
 8
TCP Congestion Control (cont.)

How is CongWin 1) on every “loss event” ⇒ reduce CongWin

size controlled? 2) on every received ACK ⇒ increase CongWin
• increase in CongWin is self- clocking – if ACKs arrive
at slow rate, CongWin will be increased at slow rate;
if ACKs arrive at high rate, CongWin will be increased
more quickly

How is congestion – a TCP sender assumes there is congestion on path

“loss event” between itself and destination if a TCP segment gets
lost/dropped (so called “loss event”) indicated through
perceived?
(a) timeout – packet lost, nothing came through after
(b) receipt of three duplicate ACKs (fast retransmit) –
packet lost, but some subsequent packets arrived successfully

TCP Congestion – detailed algorithm that TCP sender uses to regulate its
sending rate – has 3 major components:
Control Algorithm
1) slow start
2) additive increase
congestion avoidance
3) multiplicative decrease
 9
TCP Congestion Control (cont.)

Slow Start • when TCP connection begins, CongWin is typically initialized to

1 [MSS] ⇒ initial sending rate = MSS/RTT
• for each acknowledged segment, sender increases its CongWin
by 1 MMS ⇒ CongWin value is doubled every RTT ⇒ CongWin
grows exponentially
• “slow start” refers to fact that initial rate is slow but it rumps up
exponentially

Slowstart algorithm
initialize: Congwin = 1 [MSS]
until (loss event OR CongWin > threshold) {
for each segment ACKed Congwin++ }

Slow-start algorithm works effectively for initializing a connection – it enables

the TCP sender to determine quickly a reasonable window size for connection.
 10
TCP Congestion Control (cont.)

Congestion Avoidance 1) set CongWin = 1 [MSS] and perform Slow Start

until CongWin = threshold (see step 3) )
(Additive Increase)
2) Additive Increase:for CongWin > threshold
increase CongWin by 1 [MSS] every RTT
3) Multiplicative Decrease: on “loss event” cut
threshold in half (threshold = CongWin/2) and
go to 1) – back to Slow Start

Congestion Avoidance
/* slowstart is over */
/* CongWin > threshold */
until (loss event) { 1
for every CongWin segments ACKed CongWin++ }
threshold = Congwin/2
Congwin = 1 [MSS]
perform Slowstart

Slow Start vs. Additive Increase – after a certain point

it may be unwise to keep increasing the congestion window exponentially,
since overshoot could be significant.
 11
TCP Congestion Control (cont.)

Example [ TCP congestion control ]

timeout
 12
TCP Congestion Control (cont.)
Early-version TCP (Tahoe) • early TCP unconditionally cuts CongWin
vs. New-version TCP (Reno) to 1 MSS
• newer TCP cancels slow-start phase after
a 3-duplicate ACK – instead, does fast
retransmit, and fast recovery: set threshold
= CongWin/2, CongWin = threshold, and
continue with Additive Increase
(3-duplicate ACKs indicate that network is
Loss event: capable of delivering at least some packets)
3 dup ACKs
Timeout

14
12 Reno TCP
10 if (loss event = timeout) {
8 CongWin = 1 [MSS]
6
1
perform Slowstart }
(segments) if (loss event = 3-duplicate ACK) {
4 threshold CongWin = threshold
2 window size
congestion perform linear increase }
0
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
Transmission round
 13
TCP Congestion Control (cont.)

TCP Sender Congestion Control – Overview

Event State TCP Sender Action Commentary

ACK receipt Slow Start CongWin = CongWin + MSS, Resulting in a doubling of
for previously (SS) if (CongWin > Threshold) CongWin every RTT
unacked data set state to “Congestion
Avoidance”
ACK receipt Congestion CongWin = CongWin+MSS * Additive increase, resulting in
for previously Avoidance (MSS/CongWin) increase of CongWin by 1
unacked data (CA) MSS every RTT
Loss event SS or CA Threshold = CongWin/2, Fast recovery, implementing
detected by CongWin = Threshold, multiplicative decrease.
triple duplicate Set state to “Congestion CongWin will not drop below 1
ACK Avoidance” MSS.
Timeout SS or CA Threshold = CongWin/2, Enter slow start
CongWin = 1 MSS,
Set state to “Slow Start”
Duplicate ACK SS or CA Increment duplicate ACK count CongWin and Threshold not
for segment being acked changed
 14
TCP Congestion Control (cont.)

TCP Fairness – if K TCP connections share same bottleneck link (R [bps])

Goal each should get 1/N of link capacity (R/N [bps])
• TCP congestion control mechanism DOES provide equal
share of bottleneck link’s bandwidth among competing
TCP connections

TCP connection 1

TCP bottleneck
router
connection 2
capacity R

Example [ TCP fairness ]

Assume 2 TCP connections share a single link of transmission rate R. The two connections
have the same MSS and RTT , and they have a large amount of data to send.
No other TCP or UDP connection traverse the shared link!
 15
TCP Congestion Control (cont.)
Connection 2 throughput
Additive increase gives the
R same slope of 1 to both
throughputs.
equal
bandwidth Multiplicative decrease
share decreases throughputs
proportionally .

D
B

full bandwidth utilization line

C both connections enter
CongWin 2 A additive increase

CongWin 1
R
Connection 1 throughput

A: initially 2 connections consume throughput less than R ⇒ no packet loss; both connections
increase their CongWin by 1 [MSS] every RTT as a result of congestion avoidance
(note: joint throughput proceeds along a 45-degree line indicating equal increase for both conn.)

B: joint throughput exceeds R ⇒ CongWin-s must be cut to ½ of its size

C: joint bandwidth use is again less than R ⇒ two connections increase their throughputs
along a 45-degree line
The two connections will converge to ‘equal bandwidth share line’
regardless of the initial position of point A.
 16
TCP Congestion Control (cont.)

TCP Fairness – TCP connections with smaller RTT are able to grab available
and RTT bandwidth more quickly as it becomes free and thus enjoy
larger throughputs than connections with larger RTTs

TCP Fairness – nothing prevents TCP applications from opening parallel TCP
and Parallel connections between 2 hosts and thereby obtaining a larger
fraction of bandwidth in congested link
Connections

TCP Fairness – UDP provides no congestion control – applications running

and UDP over UDP (e.g. multimedia) do not cooperate with other
connections nor adjust their transmission rates appropriately
• active research area:development of congestion-control
mechanisms for Internet that prevent non-cooperative UDP
behavior
 Characteristic / 17
Description UDP TCP
Full-featured protocol that allows
Simple, high-speed, low-functionality
applications to send data reliably
General Description “wrapper” that interfaces applications to the
without worrying about network layer
network layer and does little else.
issues.
Protocol Connection-oriented; connection must
Connection Setup Connectionless; data is sent without setup.
be established prior to transmission.
Data Interface To Message-based; data is sent in discrete Stream-based; data is sent by the
Application packages by the application. application with no particular structure.
Reliability and Unreliable, best-effort delivery without Reliable delivery of messages; all data is
Acknowledgments acknowledgments. acknowledged.

Retransmissions Not performed. Application must detect lost Delivery of all data is managed, and lost
data and retransmit if needed. data is retransmitted automatically.
Features Provided Flow control using sliding windows;
to Manage Flow of None window size adjustment heuristics;
Data congestion avoidance algorithms.
Overhead Very low Low, but higher than UDP
Transmission
Speed Very high High, but not as high as UDP

Data Quantity Small to moderate amounts of data (up to a Small to very large amounts of data (up
Suitability few hundred bytes) to gigabytes)

Types of Applications where data delivery speed Most protocols and applications
Applications That matters more than completeness, where sending data that must be received
Use The Protocol small amounts of data are sent; or where reliably, including most file and
multicast/broadcast are used. message transfer protocols.
Well-Known
FTP, Telnet, SMTP, DNS, HTTP, POP,
Applications and Multimedia applications, DNS, BOOTP, DHCP, NNTP, IMAP, BGP, IRC, NFS (later
Protocols TFTP, SNMP, RIP, NFS (early versions)
versions)

source: http://www.tcpipguide.com/free/t_SummaryComparisonofTCPIPTransportLayerProtocolsUDP.htm
Example [ TCP congestion control - Final Exam, Fall 2004] 18
Consider a TCP flow that sends 7 packets . Assume the TCP source experiences exactly one
packet loss before finishing the transmission. Let:
• Threshold = 10;
• d denote the one-way propagation delay between the source and the receiver;
• RTO denote the TCP retransmission timeout;
• T denote the total time it takes the source to transmit all packets.

Determine which packet has to be dropped to result in maximum T. Compute T in both cases
as a function of d and RTO.
Note: Assume the TCP connection has been fully established prior to sending the 7 packets
in question. Also, the TCP implements both fast recovery and fast retransmission.

cwnd = 1 1 cwnd = 1 1
Ack=2 1 1
Ack=2
cwnd = 2 2,3 cwnd = 2 2,3
1_3 123
RTO Ack=2
Ack=3,4
cwnd = 4
4,5,6,7
cwnd = 1 123_567
2 Ack=4,4,4
123 cwnd = 2
Ack=4 4
cwnd = 2 1234567
4,5 Ack=8
12345
cwnd = 4 Ack=5,6
6,7
1234567
Ack=7,8
T = 4*(2d) = 8d

T = RTO + 4*(2d) = RTO + 8d

 Example 23.3

The bytes of data being transferred in each connection are numbered by

TCP.
The numbering starts with a randomly generated number.

The following shows the sequence number for each

segment:

23.113
 TCP Connection-Oriented Demux
• TCP socket identified by 4-tuple:
– source IP address
– source port number
– dest IP address
– dest port number

• recv host uses all four values to direct segment to

appropriate socket
– server can easily support many simultaneous TCP sockets:
different connections/sessions are automatically separated
into different sockets
 TCP Multiplexing
• A TCP connection is specified by a 4-tuple
– (source IP address, source port, destination IP address,
destination port)
• TCP allows multiplexing of multiple connections between end
systems to support multiple applications simultaneously
• Arriving segment directed according to connection 4-tuple

1 2 ... m 1 2 ... n 1 2 ... k

TCP TCP TCP

IP IP IP

(A, 6234, B, 80) B C

A
(A, 5234, B, 80) (C, 5234, B, 80)
 Connection-Oriented Demux

P1 P4 P5 P6 P2 P1P3

SP: x
DP: 25
S-IP: B
D-IP: S

SP: x SP: y
client DP: 25 DP: 25 Client
server
IP: A S-IP: A
IP: S S-IP: B IP:B
D-IP: S D-IP: S

116
 Flow Control
• Buffer limitations & speed mismatch can
result in loss of data that arrives at
destination
• Receiver controls rate at which sender
transmits to prevent buffer overflow
Application

Transport segments buffer used

buffer
advertised buffer available = B
window size < B
 Congestion Control
• Available bandwidth to destination varies with
activity of other users
• Transmitter dynamically adjusts transmission rate
according to network congestion as indicated by
RTT (round trip time) & ACKs
• Elastic utilization of network bandwidth
Application

Transport segments

RTT buffer buffer

Estimation ACKS
 28
TCP Connection Control (cont.)
TCP Connection – allows devices to deal with problem situations, such as
Resetting half-open connection or receipt of unexpected messages
• to use this feature, device detecting the problem sends a
TCP segment with RST flag set to 1
• receiving device either returns to LISTEN state (server), or
closes connection and returns to CLOSED state (client)

TCP Resetting (a) Denying a Connection

Examples The client TCP has requested a connection to a nonexistant
port. The server TCP sends a segment with its RST bit set,
to annul the request.

(b) Terminating an Idle Connection

TCP on one side discovers that TCP on the other side has
been idle for a long time, so it sends an RST segment to
destroy the connection. (see “timers”, next lecture)

(c) Aborting a Connection

One TCP wants to abort a connection due to an abnormal
situation. So, it sends an RST segment to the other TCP
to close the connection.
 Điều khiển thiết lập kết nối theo giao thức TCP

Denying a connection ]

Aborting a connection ]
 How Long Should Sender Wait?
• Sender sets a timeout to wait for an ACK
– Too short: wasted retransmissions
– Too long: excessive delays when packet lost
• TCP sets timeout as a function of the RTT
– Expect ACK to arrive after an “round-trip time”
– … plus a fudge factor to account for queuing
• But, how does the sender know the RTT?
– Can estimate the RTT by watching the ACKs
– Smooth estimate: keep a running average of the RTT
• EstimatedRTT = a * EstimatedRTT + (1 –a ) * SampleRTT
– Compute timeout: TimeOut = 2 * EstimatedRTT
121
 A Flaw in This Approach
• An ACK doesn’t really acknowledge a transmission
– Rather, it acknowledges receipt of the data
• Consider a retransmission of a lost packet
– If you assume the ACK goes with the 1st transmission
– … the SampleRTT comes out way too large
• Consider a duplicate packet
– If you assume the ACK goes with the 2nd transmission
– … the Sample RTT comes out way too small
• Simple solution in the Karn/Partridge algorithm
– Only collect samples for segments sent one single time
122
 Fast Retransmission
• Better solution possible under sliding window
– Although packet n might have been lost
– … packets n+1, n+2, and so on might get through
• Idea: have the receiver send ACK packets
– ACK says that receiver is still awaiting nth packet
• And repeated ACKs suggest later packets have arrived
– Sender can view the “duplicate ACKs” as an early hint
• … that the nth packet must have been lost
• … and perform the retransmission early
• Fast retransmission
– Sender retransmits data after the triple duplicate ACK
123
 Effectiveness of Fast Retransmit
• When does Fast Retransmit work best?
– Long data transfers
• High likelihood of many packets in flight
– High window size
• High likelihood of many packets in flight
– Low burstiness in packet losses
• Higher likelihood that later packets arrive successfully
• Implications for Web traffic
– Most Web transfers are short (e.g., 10 packets)
• Short HTML files or small images
– So, often there aren’t many packets in flight
– … making fast retransmit less likely to “kick in”
– Forcing users to like “reload” more often… 
124