Chapter 3

Transport Layer

A note on the use of these ppt slides:

We’re making these slides freely available to all (faculty, students, readers).
They’re in PowerPoint form so you can add, modify, and delete slides
(including this one) and slide content to suit your needs. They obviously
Computer Networking:
represent a lot of work on our part. In return for use, we only ask the A Top Down Approach
following:
 If you use these slides (e.g., in a class) in substantially unaltered form, 5th edition.
that you mention their source (after all, we’d like people to use our book!) Jim Kurose, Keith Ross
 If you post any slides in substantially unaltered form on a www site, that
you note that they are adapted from (or perhaps identical to) our slides, and Addison-Wesley, April
note our copyright of this material. 2009.
Thanks and enjoy! JFK/KWR

All material copyright 1996-2009

J.F Kurose and K.W. Ross, All Rights Reserved
Transport Layer 3-1
 Chapter 3: Transport Layer
Our goals:
 understand principles  learn about transport layer
behind transport layer protocols in the Internet:
services:  UDP: connectionless
 multiplexing/ transport
demultiplexing  TCP: connection-oriented
 reliable data transfer transport
 flow control  TCP congestion control
 congestion control

Transport Layer 3-2

 Chapter 3 outline
 3.1 Transport-layer
services
 3.2 Multiplexing and
demultiplexing
 3.3 Connectionless
transport: UDP
 3.4 Principles of reliable
data transfer
 3.5 Connection-oriented
transport: TCP
 segment structure
 reliable data transfer
 flow control
 connection management
 3.6 Principles of
congestion control
 3.7 TCP congestion
control
Transport Layer 3-3
 Transport services and protocols
application
transport
 cung cấp truyền thông logic [logical network
data link
communication ] giữa các tiến trình physical

ứng dụng đang chạy trên các host

lo
gi
ca
khác nhau.

le
nd
 Các giao thức vận chuyển chạy trên

-e
nd
các host

tr
a
 Phía gửi: chia message ở tầng

ns
po
Application thành các segments,

rt
sau đó gửi các segment này application
xuống tầng Network transport
network
 Phía nhận: ráp các segments data link
physical
thành các message, sau đó gửi lên
tầng Application
 Có nhiều hơn 2 giao thức vận chuyển
để các ứng dụng mạng sd
 Internet: TCP và UDP
Transport Layer 3-4
 Transport vs. network layer
 Tầng Network: truyền
thông logic giữa các
hosts
 Tầng Transport : truyền
thông logic giữa các
tiến trình
 relies on, enhances,
network layer services
Household analogy:
12 đứa trẻ gửi thư cho 12 đứa
trẻ khác.
 Tiến trình = đứa trẻ
 Message ở tầng Ứng dụng =
thư trong phong bì
 hosts = gia đình
 Giao thức vận chuyển = Ann
và Bill
 Giao thức ở tầng mạng = Dịch
vụ bưu chính
Transport Layer 3-5
 Internet transport-layer protocols
 Vận chuyển bảo đảm application
transport
network
[reliable], đúng thứ tự [in- data link
physical
order] (TCP) network
data link

lo
network
physical

gi
 congestion control data link

ca
physical

le
 flow control

nd
-e
connection setup

nd
 network

tr
data link
 Vận chuyển ko bảo đảm

a
physicalnetwork

ns
po
data link

[unreliable], không đúng

rt
physical
network

thứ tự : UDP data link

physical network
application
transport
data link network
 no-frills extension of “best- physical data link

effort” IP physical

 Các dịch vụ ko cung cấp:

 delay guarantees
 bandwidth guarantees
Transport Layer 3-6
 Chapter 3 outline
 3.1 Transport-layer
services
 3.2 Multiplexing and
demultiplexing
 3.3 Connectionless
transport: UDP
 3.4 Principles of reliable
data transfer
 3.5 Connection-oriented
transport: TCP
 segment structure
 reliable data transfer
 flow control
 connection management
 3.6 Principles of
congestion control
 3.7 TCP congestion
control
Transport Layer 3-7
 Multiplexing/demultiplexing
Demultiplexing ở host nhận: Multiplexing ở host gửi:
Thu thập các mẩu dữ liệu từ
Chuyển segment nhận được đến
các socket, bao bọc mỗi mẩu
đúng socket
dữ liệu trong 1 gói, có gắn
thêm header (để dùng khi
= socket = process demultiplexing ở host nhận)

P3 P1
P1 P2 P4 application
application application

transport transport transport

network network network

link link link

physical physical physical

host 2 host 3
host 1
Transport Layer 3-8
 How demultiplexing works
 Host bên nhận nhận IP datagrams
 Mỗi datagram có source IP address,
32 bits
destination IP address
 Mỗi datagram mang 1 segment (là
source port # dest port #
đơn vị dữ liệu ở Tầng Transport)
 Mỗi segment có source port number, other header fields
destination port number .
 Host bên nhận sử dụng địa chỉ IP và số
hiệu port để chuyển giao segment đến
application
socket tương ứng.
data
 Hai cách demultiplexing khác nhau ứng
(message)
với cách truyền thông hướng kết nối
(connection-oriented)và phi kết nối
(connectionless)
TCP/UDP segment format

Transport Layer 3-9

 Connectionless demultiplexing
 Khi host nhận được UDP
 Tạo sockets với số hiệu port:
DatagramSocket mySocket1 = new
segment
DatagramSocket(12534);  Kiểm tra destination port
DatagramSocket mySocket2 = new number trong segment
DatagramSocket(12535);  Chuyển UDP segment đến
socket tương ứng với số
hiệu port đó.
 Socket của UDP được xác định bằng cặp:
(dest IP address, dest port number)
=> Dù các IP Datagram có khác nhau tại source IP
adress và/hoặc source port number, nhưng chúng
có cùng destination IP address và destination
port number, thì chúng cũng sẽ được chuyển đến
cùng 1 socket.

Transport Layer 3-10

 Connectionless demux (cont)
DatagramSocket serverSocket = new DatagramSocket(6428);

P2 P1
P1
P3

SP: 6428 SP: 6428

DP: 9157 DP: 5775

SP: 9157 SP: 5775

client DP: 6428 DP: 6428 Client
server
IP: A IP: C IP:B

SP: Source port number; DP: Destination port number

SP nhằm cung cấp “địa chỉ quay về”
Transport Layer 3-11
 Connection-oriented demux
 TCP socket được xác  Server host có thể cung
định bằng bộ bốn: cấp nhiều TCP socket
 source IP address đồng thời.
 source port number  Mỗi socket được xác định
 dest IP address bằng bộ bốn của chính nó.
 dest port number
 Host bên nhận sử dụng  Web server có các socket
cả 4 giá trị này để khác nhau cho mỗi client
chuyển/hướng segment kết nối đến.
tới socket tương ứng.  non-persistent HTTP sẽ có
các socket khác nhau cho
mỗi request.

Transport Layer 3-12

 Connection-oriented demux
(cont)

P1 P4 P5 P6 P2 P1P3

SP: 5775
DP: 80
S-IP: B
D-IP:C

SP: 9157 SP: 9157

client DP: 80 DP: 80 Client
server
IP: A S-IP: A
IP: C S-IP: B IP:B
D-IP:C D-IP:C
Dù cho B và A vô tình sử dụng trùng 1 SP (9157), nhưng
Server C vẫn truyền thông chính xác đến từng Client B, A
do chúng có S-IP khác nhau
Transport Layer 3-13
 Connection-oriented demux:
Threaded Web Server

P1 P4 P2 P1P3

SP: 5775
DP: 80
S-IP: B
D-IP:C

SP: 9157 SP: 9157

client DP: 80 DP: 80 Client
server
IP: A S-IP: A
IP: C S-IP: B IP:B
D-IP:C D-IP:C
Vì lý do hiệu năng, Web Server sử dụng “một processs với
nhiều socket”. Khi đó, process sử dụng các sub-process (được
gọi là thread - tiểu trình), mỗi thread phụ trách 1 socket
Transport Layer 3-14
 Chapter 3 outline
 3.1 Transport-layer
services
 3.2 Multiplexing and
demultiplexing
 3.3 Connectionless
transport: UDP
 3.4 Principles of reliable
data transfer
 3.5 Connection-oriented
transport: TCP
 segment structure
 reliable data transfer
 flow control
 connection management
 3.6 Principles of
congestion control
 3.7 TCP congestion
control
Transport Layer 3-15
 UDP: User Datagram Protocol
 Là giao thức vận chuyển đơn
giản.
 UDP segments có thể bị:
 Mất
 Chuyển giao cho các ứng
dụng ko đúng thứ tự
 Phi kết nối [connectionless]:
 Trong UDP, ko có “thủ
tục bắt tay” giữa bên gửi
và bên nhận.
 Mỗi UDP segment được
xử lý độc lập với các
segments khác.
[RFC 768]
Tại sao cần có UDP?
 Ko cần thiết lập kết nối (là
yếu tố làm chậm)
 Đơn giản: ko cần quản lý
trạng thái kết nối tại bên gửi
và bên nhận.
 Kích thước phần header nhỏ
(8 byte)
 Ko quan tâm đến sự ùn tắt
mạng
Transport Layer 3-16
 UDP: more
 Thường được các ứng dụng
streaming multimedia sử 32 bits
dụng, do chúng source port # dest port #
 Cho phép mất d/liệu length checksum
 Cần tốc độ (cao) ổn định

 Các ứng dụng khác Length, in

bytes of UDP
dùng UDP segment,
DNS including Application
 SNMP header data
 Truyền d/liệu bảo đảm với
(message)
UDP: cần bổ sung khả năng
phát hiện và sửa lỗi ở
tầng Ứng dụng. UDP segment format

Transport Layer 3-17

 UDP checksum
Mục đích: phát hiện “lỗi” (e.g., flipped bits) trong các
segment được truyền theo UDP.
 Bên gửi:
 Coi nội dung segment như
chuỗi các số nguyên 16 bit.
 Checksum: bù 1 của tổng
các số nguyên 16 bit (trong
nội dung segment)
 Bên gửi đặt trị checksum
vào trường checksum trong
UDP segment.
Bên nhận:
 Tính lại checksum của segment
nhận được.
 Kiểm tra trị tính được có bằng với
trị checksum trong segment nhận
được.
 KHÔNG BẰNG –lỗi đuợc phát
hiện
 BẰNG- không có lỗi được phát
hiện (nhưng vẫn có thể có lỗi).
Transport Layer 3-18
 Internet Checksum Example
 Ghi chú
• Khi cộng, bít nhớ ở ngoài cùng bên trái cần được
thêm vào kết quả=> tạo thành Tổng.
 Ví dụ: cộng 2 số nguyên 16-bit.

1 1 1 1 0 0 1 1 0 0 1 1 0 0 1 1 0
1 1 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1

1 1 0 1 1 1 0 1 1 1 0 1 1 1 0 1 1

Tổng 1 1 0 1 1 1 0 1 1 1 0 1 1 1 1 0 0
Checksum 1 0 1 0 0 0 1 0 0 0 1 0 0 0 0 1 1
(bù 1 của Tổng)

Transport Layer 3-19

 Chapter 3 outline
 3.1 Transport-layer
services
 3.2 Multiplexing and
demultiplexing
 3.3 Connectionless
transport: UDP
 3.4 Principles of reliable
data transfer
 3.5 Connection-oriented
transport: TCP
 segment structure
 reliable data transfer
 flow control
 connection management
 3.6 Principles of
congestion control
 3.7 TCP congestion
control
Transport Layer 3-20
 Principles of Reliable data transfer
 Là chủ đề quan trong ở tầng application, transport và link
 Nằm trong 10 chủ đề về mạng quan trọng nhất.

 Các đặc tính của kênh truyền không đáng tin cậy (unreliable
channel) sẽ quyết định độ phức tạp của giao thức truyền dữ liệu
đáng tin cậy (reliable data transfer protocol – viết tắt rdt).
Transport Layer 3-21
 Principles of Reliable data transfer
 Là chủ đề quan trọng ở tầng application, transport và link
 Nằm trong 10 chủ đề về mạng quan trọng nhất.

 Các đặc tính của kênh truyền không đáng tin cậy (unreliable
channel) sẽ quyết định độ phức tạp của giao thức truyền dữ liệu
đáng tin cậy (reliable data transfer protocol – viết tắt Transport
rdt). Layer 3-22
 Principles of Reliable data transfer
 Là chủ đề quan trong ở tầng application, transport và link
 Nằm trong 10 chủ đề quan trọng nhất về mạng máy tính.

 Các đặc tính của kênh truyền không đáng tin cậy (unreliable
channel) sẽ quyết định độ phức tạp của giao thức truyền dữ liệu
đáng tin cậy (reliable data transfer protocol – viết tắt Transport
rdt). Layer 3-23
 Reliable data transfer: getting started
rdt_send(): called from above, deliver_data(): called by
(e.g., by app.). Passed data to rdt to deliver data to upper
deliver to receiver upper layer

send receive
side side

udt_send(): called by rdt, rdt_rcv(): called when packet

to transfer packet over arrives on rcv-side of channel
unreliable channel to receiver

Transport Layer 3-24

 Reliable data transfer: getting started
Chúng ta sẽ:
 Phát triển dần giao thức truyền dữ liệu đáng tin
cậy (rdt) cho cả 2 phía truyền và nhận.
 Chỉ xem xét trường hợp truyền dữ liệu 1 chiều
 Nhưng thông tin điều khiển sẽ chạy theo cả 2 chiều!
 Sử dụng máy trạng thái hữu hạn (finite-state
machine - FSM) để mô tả bên truyền và nhận.
event causing state transition
actions taken on state transition
state: when in this
“state” next state state state
1 event
uniquely determined 2
by next event actions

Transport Layer 3-25

 Rdt1.0: reliable transfer over a reliable channel

 Giả định: Kênh truyền bên dưới truyền dữ liệu hoàn

toàn đáng tin cậy.
 Không sai bit.
 Không mất gói tin
 Có 2 FSMs riêng cho bên truyền và nhận:
 Bên truyền gửi dữ liệu xuống kênh truyền bên dưới.
 Bên nhận đọc dữ liệu từ kênh truyền bên dưới.

Wait for rdt_send(data) Wait for rdt_rcv(packet)

call from call from extract (packet,data)
above packet = make_pkt(data) below deliver_data(data)
udt_send(packet)

Bên truyền Bên nhận

Transport Layer 3-26

 Rdt2.0: channel with bit errors
 Kênh truyền bên dưới có thể truyền bit bị sai.
 Dùng checksum để phát hiện lỗi bit sai

 Vấn đề: làm thế nào để sửa lỗi:

 Xác nhận đúng(acknowledgements -ACKs): bên nhận nói rõ
cho bên gửi biết là gói tin đã được nhận đúng.
 Xác nhận lỗi: negative acknowledgements (NAKs): bên nhận
nói rõ cho bên gửi biết là gói tin nhận được đã bị lỗi.
 Bên gửi truyền lại gói tin khi nhận được NAK.
 Cơ chế mới trong rdt2.0 (beyond rdt1.0):
 Phát hiện lỗi (error detection)
 Phản hồi của bên nhận: bên nhận gửi cho bên gửi các thông
điệp xác nhận (thông điệp ACK, hoặc thông điệp NAK)

Transport Layer 3-27

 rdt2.0: FSM specification
rdt_send(data)
sndpkt = make_pkt(data, checksum)
udt_send(sndpkt)
Bên nhận
rdt_rcv(rcvpkt) &&
isNAK(rcvpkt)
Wait for Wait for rdt_rcv(rcvpkt) &&
call from ACK or udt_send(sndpkt) corrupt(rcvpkt)
above NAK
udt_send(NAK)

rdt_rcv(rcvpkt) && isACK(rcvpkt)

Wait for

call from
below
Bên truyền
rdt_rcv(rcvpkt) &&
notcorrupt(rcvpkt)
extract(rcvpkt,data)
deliver_data(data)
udt_send(ACK)

Transport Layer 3-28

 rdt2.0: operation with no errors
rdt_send(data)
sndpkt = make_pkt(data, checksum)
udt_send(sndpkt)
rdt_rcv(rcvpkt) &&
isNAK(rcvpkt)
Wait for Wait for rdt_rcv(rcvpkt) &&
call from ACK or udt_send(sndpkt) corrupt(rcvpkt)
above NAK
udt_send(NAK)

rdt_rcv(rcvpkt) && isACK(rcvpkt)

Wait for
 call from
below

rdt_rcv(rcvpkt) &&
notcorrupt(rcvpkt)
extract(rcvpkt,data)
deliver_data(data)
udt_send(ACK)

Transport Layer 3-29

 rdt2.0: error scenario
rdt_send(data)
sndpkt = make_pkt(data, checksum)
udt_send(sndpkt)
rdt_rcv(rcvpkt) &&
isNAK(rcvpkt)
Wait for Wait for rdt_rcv(rcvpkt) &&
call from ACK or udt_send(sndpkt) corrupt(rcvpkt)
above NAK
udt_send(NAK)

rdt_rcv(rcvpkt) && isACK(rcvpkt)

Wait for
 call from
below

rdt_rcv(rcvpkt) &&
notcorrupt(rcvpkt)
extract(rcvpkt,data)
deliver_data(data)
udt_send(ACK)

Transport Layer 3-30

 rdt2.0 has a fatal flaw!
Điều gì xảy ra nếu Xử lý trùng lặp gói tin:
 Bên gửi truyền lại gói tin hiện thời
ACK/NAK bị mất/lỗi? nếu như ACK/NCK bị mất/lỗi, ko thể
 Bên gửi không biết những gì nhận ra.
đã xảy ra ở bên nhận!  Bên gửi thêm 1 số thứ tự vào mỗi

 Bên gửi cần truyền lại: gói tin.

 Bên nhận vứt bỏ các gói tin bị trùng
nhưng có thể xảy ra hiện
(so số thứ tự), mà không truyền lên
tượng trùng lặp gói tin. tầng trên.

stop and wait

Bên gửi gửi 1 gói tin, sau
đó chờ bên nhận phản ứng
lại.

Transport Layer 3-31

rdt2.1: sender, handles garbled ACK/NAKs
rdt_send(data)
sndpkt = make_pkt(0, data, checksum)
udt_send(sndpkt) rdt_rcv(rcvpkt) &&
( corrupt(rcvpkt) ||
Wait for Wait for
ACK or
isNAK(rcvpkt) )
call 0 from
NAK 0 udt_send(sndpkt)
above
rdt_rcv(rcvpkt)
&& notcorrupt(rcvpkt) rdt_rcv(rcvpkt)
&& isACK(rcvpkt) && notcorrupt(rcvpkt)
&& isACK(rcvpkt)


Wait for Wait for
ACK or call 1 from
rdt_rcv(rcvpkt) && NAK 1 above
( corrupt(rcvpkt) ||
isNAK(rcvpkt) ) rdt_send(data)

udt_send(sndpkt) sndpkt = make_pkt(1, data, checksum)

udt_send(sndpkt)

Transport Layer 3-32

 rdt2.1: receiver, handles garbled ACK/NAKs
rdt_rcv(rcvpkt) && notcorrupt(rcvpkt)
&& has_seq0(rcvpkt)
extract(rcvpkt,data)
deliver_data(data)
sndpkt = make_pkt(ACK, chksum)
udt_send(sndpkt)
rdt_rcv(rcvpkt) && rdt_rcv(rcvpkt) &&
(corrupt(rcvpkt) (corrupt(rcvpkt)
sndpkt = make_pkt(NAK, chksum) sndpkt = make_pkt(NAK, chksum)
udt_send(sndpkt) udt_send(sndpkt)
Wait for Wait for
rdt_rcv(rcvpkt) && 0 from 1 from rdt_rcv(rcvpkt) &&
not corrupt(rcvpkt) && below below not corrupt(rcvpkt) &&
has_seq1(rcvpkt) has_seq0(rcvpkt)
sndpkt = make_pkt(ACK, chksum) sndpkt = make_pkt(ACK, chksum)
udt_send(sndpkt) udt_send(sndpkt)
rdt_rcv(rcvpkt) && notcorrupt(rcvpkt)
&& has_seq1(rcvpkt)

extract(rcvpkt,data)
deliver_data(data)
sndpkt = make_pkt(ACK, chksum)
udt_send(sndpkt)

Transport Layer 3-33

 rdt2.1: discussion
Bên gửi: Bên nhận:
 Số thứ tự được thêm vào  Phải kiểm tra xem liệu
gói tin. gói tin nhận được có bị
 Dùng hai giá trị (0,1) cho trùng lặp hay ko?
 Trạng thái cho biết mong
số thứ tự là đủ. Vì sao?
chờ gói tin có stt là 0 hay
 Cần phải kiểm tra lại xem 1
các xác nhận ACK/NAK có  Lưu ý: Sau khi gửi
bị lỗi không. ACK/NAK, bên nhận
 Gấp đôi số trạng thái không thể biết liệu gói tin
 ở mỗi trạng thái, phải “nhớ” ACK/NAK sau cùng có
gói tin hiện thời có số thứ đến được ở bên gửi hay
tự là 0 hay 1. không.
Transport Layer 3-34
 rdt2.2: a NAK-free protocol
 Làm việc tương tự như rdt2.1, nhưng chỉ sử dụng ACKs.
 Thay cho NAK, bên nhận có thể sử dụng ACK với số thứ
tự SAI, để tạo ra cùng tác động của như NAK trong rdt2.1
: bắt bên gửi phải truyền lại
 Bên nhận phải đưa số thứ tự vào gói tin ACK
 Việc trùng lắp ACK ở bên gửi dẫn đến cùng một hành
động như khi nhận NAK: gửi lại gói tin hiện thời .

Transport Layer 3-35

 rdt2.2: sender, receiver fragments
rdt_send(data)
sndpkt = make_pkt(0, data, checksum)
udt_send(sndpkt)
rdt_rcv(rcvpkt) &&
( corrupt(rcvpkt) ||
Wait for Wait for
ACK isACK(rcvpkt,1) )
call 0 from
above 0 udt_send(sndpkt)
sender FSM
fragment rdt_rcv(rcvpkt)
&& notcorrupt(rcvpkt)
rdt_rcv(rcvpkt) && && isACK(rcvpkt,0)
(corrupt(rcvpkt) || 
has_seq1(rcvpkt)) Wait for receiver FSM
0 from
udt_send(sndpkt) below fragment
rdt_rcv(rcvpkt) && notcorrupt(rcvpkt)
&& has_seq1(rcvpkt)
extract(rcvpkt,data)
deliver_data(data)
sndpkt = make_pkt(ACK,1, chksum)
udt_send(sndpkt) Transport Layer 3-36
 rdt3.0: channels with errors and loss
 Giả định mới: kênh
truyền bên dưới cũng
có thể làm mất gói tin
(dữ liệu hoặc ACK)
 Kỹ thuật checksum, đánh
số thứ tự, dùng ACKs, kỹ
thuật truyền lại là cần
thiết, nhưng chưa đủ
 Một cách giải quyết: bên gửi
chờ gói tin ACK một thời gian
“hợp lý”.
 Bên gửi sẽ truyền lại nếu không
nhận được gói tin ACK trong
khoảng thời gian này.
 Nếu gói tin (dữ liệu hoặc ACK) chỉ
chậm đến (chứ không mất):
 Việc truyền lại sẽ gây tình trạng
trùng lắp gói tin, nhưng sử
dụng số thứ tự sẽ xử lý được
tình trạng này.
 Bên nhận phải chỉ định số thứ
tự của gói tin ACK
 Cần đồng hồ đếm giờ.
Transport Layer 3-37
rdt3.0 sender
rdt_send(data)
rdt_rcv(rcvpkt) &&
sndpkt = make_pkt(0, data, checksum) ( corrupt(rcvpkt) ||
udt_send(sndpkt) isACK(rcvpkt,1) )
rdt_rcv(rcvpkt) start_timer 
 Wait for Wait
for timeout
call 0from
ACK0 udt_send(sndpkt)
above
start_timer
rdt_rcv(rcvpkt)
&& notcorrupt(rcvpkt) rdt_rcv(rcvpkt)
&& isACK(rcvpkt,1) && notcorrupt(rcvpkt)
stop_timer && isACK(rcvpkt,0)
stop_timer
Wait Wait for
timeout for call 1 from
udt_send(sndpkt) ACK1 above
start_timer rdt_rcv(rcvpkt)
rdt_send(data) 
rdt_rcv(rcvpkt) &&
sndpkt = make_pkt(1, data, checksum)
( corrupt(rcvpkt) || udt_send(sndpkt)
isACK(rcvpkt,0) ) start_timer


Transport Layer 3-38

rdt3.0 in action

Transport Layer 3-39

rdt3.0 in action

Transport Layer 3-40

 Performance of rdt3.0
 rdt3.0 có thể vận hành trong điều kiện thực tế, nhưng
chưa được hiệu quả.
 VD: cho đường truyền có transmission rate 1 Gbps, có độ
trễ lan truyền (prop. delay) 15 ms, với gói tin 8000 bit:
Transmission delay L 8000bits 3
d trans   9
 8 10 ms
R 10 bps
• Gọi U sender: hiệu quả dùng đường truyền = phần thời gian sử
dụng đường truyền cho việc truyền dữ liệu
L/R .008
U = = = 0.00027
sender 30.008
RTT + L / R microsec
• Với đường truyền 1 Gbps, chỉ truyền được gói tinonds
1KB sau mỗi 30
ms => tức truyền dược 33kB/sec
• Giao thức rdt3.0 làm giới hạn khả năng của đường truyền vật lý!
Transport Layer 3-41
 rdt3.0: stop-and-wait operation
Bên gửi Bên nhận
Truyền bit đầu của gói tin t = 0
Truyền bit cuối của gói tin, t = L / R

Bít đầu của gói tin đến

RTT Bít cuối đến, gửi ACK

ACK đến, gửi gói tin kế tiếp

t = RTT + L / R

L/R .008
U = = = 0.00027
sender 30.008
RTT + L / R microsec
onds

Transport Layer 3-42

 Pipelined protocols
Pipelining: bên gửi cho phép gửi nhiều gói tin cùng
lúc, dù chưa nhận được ACK.
 Vùng đánh số thứ tự phải được mở rộng thêm.
 Cần vùng đệm ở cả bên gửi và bên nhận

 Hai giao thức dạng pipeline: go-Back-N, selective repeat

Transport Layer 3-43

 Pipelining: increased utilization
Bên gửi Bên nhận
Truyền bit đầu của gói tin t = 0
Truyền bit cuối của g/tin, t = L / R

Bit đầu của gói tin 1 đến

RTT Bit cuối của gói tin thứ 1đến, gửi ACK
Bit cuối của gói tin thứ 2 đến, gửi ACK
Bit cuối của gói tin thứ 3 đến, gửi ACK
ACK đến, gửi gói tin kế
tiếp, t = RTT + L / R

Tăng hiệu quả dùng

đường truyền lên 3 lần

3*L/R .024
U = = = 0.0008
sender 30.008
RTT + L / R microsecon
ds
Transport Layer 3-44
 Pipelining Protocols
Go-back-N: tổng quan
 Bên gửi: cho phép lên đến N
gói-tin-chưa-được-xác-nhận
trong pipeline
 Bên nhận: chỉ gửi các
cumulative ACKs
 Không gửi ACK nếu các gói-tin-
dữ-liệu đến ko đúng thứ tự.
 Bên gửi: canh giờ cho gói tin
“cũ nhất” chưa-đuợc-xác-nhận
 Nếu quá giờ: truyền lại tất cả
các gói-tin-chưa-được-xác -
nhận.
Selective Repeat: tổng quan
 Bên gửi: cho phép lên đến
N gói-tin-chưa-được-xác-
nhận trong pipeline
 Bên nhận: Xác nhận cho
từng gói tin cụ thể
 Bên gửi: đếm giờ cho từng
gói tin chưa đuợc xác nhận
 Nếu quá giờ: chỉ truyền lại gói
tin chưa được xác nhận
Transport Layer 3-45
 Go-Back-N
Bên gửi:
 Sử dụng k-bit cho trường số thứ tự trong phần header gói tin
 “cửa sổ” kích thước N, cho phép có nhiều gói-tin-chưa-được-xác-nhận.

 ACK(n): xác nhận tất cả các gói tin tới số thứ tự n -“cumulative ACK”
o Có thể nhận trùng gói tin xác nhận (xem bên nhận)

 Sử dụng bộ đếm giờ (timer) cho mỗi gói tin đang truyền
 timeout(n): truyền lại gói tin n và tất cả các gói tin có số thứ tự cao
hơn đã gửi trong cửa sổ.
Transport Layer 3-46
 GBN: sender extended FSM
rdt_send(data)
if (nextseqnum < base+N) {
sndpkt[nextseqnum] = make_pkt(nextseqnum,data,chksum)
udt_send(sndpkt[nextseqnum])
if (base == nextseqnum)
start_timer
nextseqnum++
}
 else
refuse_data(data)
base=1
nextseqnum=1
timeout
start_timer
Wait
udt_send(sndpkt[base])
rdt_rcv(rcvpkt) udt_send(sndpkt[base+1])
&& corrupt(rcvpkt) …
udt_send(sndpkt[nextseqnum-
 1])
rdt_rcv(rcvpkt) &&
notcorrupt(rcvpkt)
base = getacknum(rcvpkt)+1
If (base == nextseqnum)
stop_timer
else
start_timer Transport Layer 3-47
 GBN: receiver extended FSM
default
udt_send(sndpkt) rdt_rcv(rcvpkt)
&& notcurrupt(rcvpkt)
 && hasseqnum(rcvpkt,expectedseqnum)
expectedseqnum=1 Wait extract(rcvpkt,data)
sndpkt = deliver_data(data)
make_pkt(expectedseqnum,ACK,chksum) sndpkt = make_pkt(expectedseqnum,ACK,chksum)
udt_send(sndpkt)
expectedseqnum++

 ACK-only: luôn gửi ACK cho gói tin nhận được ko bị lỗi và có
số thứ tự đúng trật tự truyền cao nhất
 Có thể phát sinh trùng lắp các gói tin ACK
 Chỉ cần nhớ biến expectedseqnum
 Với các gói tin đến sai thứ tự:
 Vứt bỏ (không lưu vào vùng đệm) -> no receiver buffering!
 Gửi lại gói tin ACK cho gói tin đến đúng thứ tự và có số thứ tự cao
nhất.
Transport Layer 3-48
GBN in
action

Transport Layer 3-49

 Selective Repeat
 Bên nhận xác nhận cho từng gói tin mà nó nhận
được chính xác.
 Sử dụng buffer.
 Bên gửi chỉ gửi lại các gói tin mà chưa được xác
nhận.
 Sử dụng bộ đếm giờ cho mỗi gói tin chưa được xác nhận.
 Cửa sổ bên gửi
 Kích thước N
 Cũng giới hạn số gói tin đã gửi nhưng đang chờ xác nhận

Transport Layer 3-50

Selective repeat: sender, receiver windows

Transport Layer 3-51

 Selective repeat
Bên gửi
Khi có data đến từ tầng trên:
 Nếu số thứ tự kế tiếp nằm
trong cửa sổ, gửi gói tin.
timeout(n):
 Gửi lại gói tin n, khởi động lại
bộ đếm giờ
ACK(n) trong cửa sổ
[sendbase,sendbase+N]:
 Đánh dấu gói tin n là đã nhận
được
 Nếu n là nhỏ nhất trong số các
gói tin chưa được ACK, dịch
chuyển cửa sổ sang phải.
Bên nhận
Gói tin n trong cửa sổ [rcvbase,
rcvbase+N-1]
 Gửi ACK(n)
 Nếu gói tin đến sai thứ tự: đưa
vô buffer
 Nếu gt đến đúng thứ tự: chuyển
giao lên tầng trên (và cũng
chuyển giao luôn các gói tin nằm
trong buffer và đúng thứ tự),
dịch chuyển cửa sổ sang phải.
Gói tin n trong [rcvbase-N,rcvbase-1]
 Xác nhận ACK(n)
Trường hợp khác
 Bỏ qua
Transport Layer 3-52
Selective repeat in action

Transport Layer 3-53

Selective repeat:
dilemma
Ví dụ:
 Vùng các stt: 0, 1, 2, 3
 Kích thước cửa sổ=3

 Bên nhận không thấy gì

khác giữa 2 kịch bản!

Q: giữa kích thước cửa sổ

và kích thước vùng số
thứ tự có mối quan hệ
gì?

Transport Layer 3-54

 Chapter 3 outline
 3.1 Transport-layer
services
 3.2 Multiplexing and
demultiplexing
 3.3 Connectionless
transport: UDP
 3.4 Principles of reliable
data transfer
 3.5 Connection-oriented
transport: TCP
 segment structure
 reliable data transfer
 flow control
 connection management
 3.6 Principles of
congestion control
 3.7 TCP congestion
control
Transport Layer 3-55
 TCP: Overview RFCs: 793, 1122, 1323, 2018, 2581
 point-to-point:
 Một gửi, một nhận  full duplex data:
 reliable, in-order byte  Truyền nhận dữ liệu 2 chiều

stream: trên cùng kết nối

 MSS: maximum segment size
 Không thể hiện được ranh giới
các gói tin (“message  connection-oriented:
boundaries”)  Nghi thức bắt tay
 pipelined: (handshaking) để trao đổi các
 Cơ chế congestion and flow msg điều khiển ( thông số
control thiết lập kích thước cửa khởi tạo bên gửi tình trạng
sổ truyền dữ liệu bên nhận) trước khi truyền
 flow controlled:
 send & receive buffers
 Bên gửi sẽ ko làm “ngập úng”

socket
applica tion
w rites data
ap plica tio n
reads data
sock et
bên nhận
door d oor
TCP TCP
send bu ffer receive bu ffer Transport Layer 3-56
se g m e n t
 TCP segment structure
32 bits
URG: urgent data counting
(generally not used) source port # dest port #
by bytes
sequence number of data
ACK: ACK #
valid acknowledgement number (not segments!)
head not
PSH: push data now len used
UA P R S F Receive window
(generally not used) # bytes
checksum Urg data pointer
rcvr willing
RST, SYN, FIN: to accept
Options (variable length)
connection estab
(setup, teardown
commands)
application
Internet data
checksum (variable length)
(as in UDP)

Transport Layer 3-57

 TCP seq. #’s and ACKs
Seq. #’s:
Host A Host B
 STTcủa byte dữ liệu đầu
tiên nằm trong segment User Seq=4
2, ACK=
(xét trên chuỗi byte) types 79, da
t a = ‘C
ACKs: ‘C’ ’
host ACKs
 STT của byte kế tiếp receipt of
được chờ đợi gửi sang = ‘C’ ‘C’, echoes
43 , data
=
từ bên gửi. =79 , ACK back ‘C’
Seq
 cumulative ACK

Q: Bên nhận xử lý các host ACKs

segments sai thứ tự như thế receipt Seq=4
nào? of echoed 3, ACK
=80
 A: Đặc tả TCP ko nói, - ‘C’
tùy thuộc vào bản cài
đặt.
time
simple telnet scenario

Transport Layer 3-58

 TCP Round Trip Time and Timeout
Q: thiết đặt giá trị TCP Q: Ước lượng RTT như thế nào?
timeout như thế nào?  SampleRTT: thời gian đo được từ
 Dài hơn RTT lúc truyền segment cho đến khi
 nhưng RTT không cố định
nhận được ACK.
 Bỏ qua việc truyền lại
 Quá ngắn: premature
timeout  SampleRTT sẽ biến động, muốn
 Truyền lại một cách ko RTT được ước lượng phải “trơn tru
cần thiết hơn”
 Tính giá trị trung bình của nhiều
 Quá dài: phản ứng ko kịp
thời khi có segment bị mất lần đo gần đó, chứ không chỉ là
giá trị SampleRTT hiện hành

Transport Layer 3-59

 TCP Round Trip Time and Timeout
EstimatedRTT = (1- )*EstimatedRTT + *SampleRTT

• Exponential weighted moving average

• influence of past sample decreases exponentially fast
• Thông thường,  = 0.125

Transport Layer 3-60

 Example RTT estimation:
RTT: gaia.cs.umass.edu to fantasia.eurecom.fr

350

300

250
RTT (milliseconds)

200

150

100
1 8 15 22 29 36 43 50 57 64 71 78 85 92 99 106
time (seconnds)

SampleRTT Estimated RTT

Transport Layer 3-61

 TCP Round Trip Time and Timeout
Thiết lập giá trị cho timeout
 Là EstimtedRTT cộng với “biên độ an toàn”
 EstimatedRTT dao động lớn -> biên độ an toàn phải lớn hơn
 trước tiên, ước lượng giá trị SampleRTT lệch cỡ bao nhiêu so với EstimatedRTT

DevRTT = (1-)*DevRTT +
*|SampleRTT-EstimatedRTT|

(thông thường,  = 0.25)

sau đó thiết lập giá trị cho timeout theo công thức

TimeoutInterval = EstimatedRTT + 4*DevRTT

Transport Layer 3-62

 Chapter 3 outline
 3.1 Transport-layer
services
 3.2 Multiplexing and
demultiplexing
 3.3 Connectionless
transport: UDP
 3.4 Principles of reliable
data transfer
 3.5 Connection-oriented
transport: TCP
 segment structure
 reliable data transfer
 flow control
 connection management
 3.6 Principles of
congestion control
 3.7 TCP congestion
control
Transport Layer 3-63
 TCP reliable data transfer
 TCP tạo rdt service trên  Việc truyền lại được
nền tảng các dịch vụ kích hoạt nhờ:
“ko đảm bảo tin cậy” IP  Sự kiện “timeout”
 Segment được truyền đi  Trùng lắp ACK
mà ko chờ ACK của  Khởi đầu, chỉ xem xét
segment trước trường hợp đơn giản:
(pipelined segments) Bên gửi:
 cumulative ACKs  Bỏ qua các ACK trùng lặp
 TCP chỉ sử dụng 1 bộ
 Bỏ qua flow control,
congestion control
đếm thời gian để quyết
định truyền lại hay ko.

Transport Layer 3-64

 TCP sender events:
Nhận được dữ liệu từ app:
 Tạo ra segment từ dữ liệu
của app và gửi xuống tầng
IP
 Field “seq #” chứa STT của
byte đầu tiên của segment,
xét trên chuỗi byte.
 Khởi động timer nếu nó
chưa chạy (xem như timer là
để tính giờ cho segment “cũ
nhất” chưa-được-xác-nhận
 Hết giờ: TimeOutInterval
Khi xảy ra timeout:
 Truyền lại segment gây ra
sự kiện timeout
 Khởi động lại timer
Nhận được ACK:
 Nếu đúng là để xác nhận
cho các segment vốn chưa
được xác nhận trước đó
 Cập nhật lại cửa sổ
 Khởi động timer nếu hiện thời
có ít nhất một segment chưa
được xác nhận
Transport Layer 3-65
NextSeqNum = InitialSeqNum
SendBase = InitialSeqNum

loop (forever) { TCP

switch(event)

event: data received from application above

sender
create TCP segment with sequence number NextSeqNum (simplified)
if (timer currently not running)
start timer
pass segment to IP
Ghi chú:
NextSeqNum = NextSeqNum + length(data)
• SendBase-1: last
event: timer timeout cumulatively
retransmit not-yet-acknowledged segment with ACKed byte
smallest sequence number Example:
start timer • SendBase-1 = 71;
y= 73, so the rcvr
event: ACK received, with ACK field value of y wants 73+ ;
if (y > SendBase) {
y > SendBase, so
SendBase = y
if (there are currently not-yet-acknowledged segments)
that new data is
start timer ACKed
}

} /* end of loop forever */

Transport Layer 3-66
 TCP: retransmission scenarios
Host A Host B Host A Host B

Seq=9 Seq=9
2, 8 b 2, 8 b y te
y te s d a s data
ta Seq=

Seq=92 timeout
1 00, 2
0 by t
es da
timeout

t a
=100
ACK 0
10
X CK=
A AC K = 120
loss
Seq=9 Seq=9
2, 8 b 2, 8 b
y t es da Sendbase y t es da
ta
ta
= 100

Seq=92 timeout
SendBase
= 120 = 120
0 K
=10 AC
ACK

SendBase
= 100 SendBase
= 120 premature timeout
time time
lost ACK scenario
Transport Layer 3-67
 TCP retransmission scenarios (more)
Host A Host B

Seq=9
2, 8 byte
s data

=100
timeout

Seq=1 A CK
00, 20
bytes
data
X
loss

SendBase C K =120
A
= 120

time
Cumulative ACK scenario

Transport Layer 3-68

 TCP ACK generation [RFC 1122, RFC 2581]

Sự kiện ở bên nhận Hành động ở bên nhận

Có segment đến với số STT đúng Trì hoãn gửi ACK. Chờ segment kế
như mong đợi. Tất cả dữ liệu tiếp trong 500 ms. Nếu ko có segment
trước segment này đều đã được nào đến, thì mới gửi ACK.
xác nhận

Có segment đến với số STT đúng Gửi ngay 1 ACK ứng với segment
như mong đợi. Còn có 1 segment vừa đến (cumulative ACK).
khác đang chờ xác nhận.

Có segment đến với số STT lớn Gửi ngay 1 ACK trong đó nêu STT
hơn STT mong đợi. Bên nhận phát của byte kế tiếp được chờ đợi
hiện trình trạng "không liên tục" (duplicate ACK)

Có segment đến để "bít khoảng Gửi ngay 1 ACK trong đó nêu STT
hở" (một phần hay toàn bộ) của byte kế tiếp được chờ đợi
Transport Layer 3-69
 Fast Retransmit
 Khoảng thời gian time-out  Nếu bên gửi nhận được
thường hơi dài: 3 ACK cho cùng dữ liệu,
 Chờ lâu (hơn cần thiết) nó giả sử rằng “segment
trước khi gửi lại gói tin bị
mất
đi sau dữ liệu đã được
 Phát hiện segment bị mất
xác nhận” bị mất:
thông qua việc nhận trùng
 fast retransmit: gửi lại
segment mà không chờ
lặp ACK
đến khi time-out.
 Bên gửi thường gửi nhiều
segment theo loạt
 Nếu 1 segment bị mất, có
khả năng có nhiều ACK
trùng lặp dành cho segment
ngay trước segment bị mất.

Transport Layer 3-70

 Host A Host B

seq # x1
seq # x2
seq # x3
ACK x1
seq # x4 X
seq # x5
ACK x1
ACK x1
ACK x1
triple
duplicate
ACKs resen
d seq
X2
timeout

time

Transport Layer 3-71

 Fast retransmit algorithm:

event: ACK received, with ACK field value of y

if (y > SendBase) {
SendBase = y
if (there are currently not-yet-acknowledged segments)
start timer
}
else {
increment count of dup ACKs received for y
if (count of dup ACKs received for y = 3) {
resend segment with sequence number y
}

a duplicate ACK for fast retransmit

already ACKed segment

Transport Layer 3-72

 Chapter 3 outline
 3.1 Transport-layer
services
 3.2 Multiplexing and
demultiplexing
 3.3 Connectionless
transport: UDP
 3.4 Principles of reliable
data transfer
 3.5 Connection-oriented
transport: TCP
 segment structure
 reliable data transfer
 flow control
 connection management
 3.6 Principles of
congestion control
 3.7 TCP congestion
control
Transport Layer 3-73
 TCP Flow Control
flow control
Bên gửi không gửi quá
 Bên nhận của kết nối
nhiều, quá nhanh, gây
TCP, có một vùng đệm nên tình trạng tràn
(receive buffer): vùng đệm bên nhận

IP
(currently)
TCP data application
 speed-matching service:
unused buffer
datagrams (in buffer) process
space Điều chỉnh tốc độ gửi phù
hợp với tốc độ “tiêu
thoát” dữ liệu (của ứng
 Các process của ứng dụng dụng) ở bên nhận.
bên nhận có thể đọc dữ liệu
từ vùng đệm chậm hơn tốc
độ dữ liệu đến.
Transport Layer 3-74
 TCP Flow control: how it works
(currently)  Bên nhận: báo cho bên
IP TCP data application
unused buffer
datagrams space
(in buffer) process gửi biết kích thước vùng
đệm chưa sử dụng bằng
rwnd cách đặt giá trị rwnd
RcvBuffer
hiện hành vào trong
(giả sử bên nhận vứt bỏ các segment header của mọi
segment đến sai thứ tự) segment gửi cho bên gửi
 Kích thước vùng đệm chưa  Bên gửi: giới hạn số

sử dụng: bytes chưa-được-xác-

= rwnd
nhận nhỏ hơn rwnd
 Đảm bảo vùng đệm bên
= RcvBuffer-[LastByteRcvd -
nhận không bị tràn
LastByteRead]

Transport Layer 3-75

 Chapter 3 outline
 3.1 Transport-layer
services
 3.2 Multiplexing and
demultiplexing
 3.3 Connectionless
transport: UDP
 3.4 Principles of reliable
data transfer
 3.5 Connection-oriented
transport: TCP
 segment structure
 reliable data transfer
 flow control
 connection management
 3.6 Principles of
congestion control
 3.7 TCP congestion
control
Transport Layer 3-76
 TCP Connection Management
Nhớ lại: Trong TCP, bên gửi và Thủ tục “Bắt-tay-3-bước” (three-
bên nhận thiết lập kết nối way handshake)
trước khi trao đổi các segments Bước 1: client gửi TCP segment SYN đến
 Khởi tạo các biến của TCP: server
 seq. #s  Chỉ định số thứ tự (seq.#) cho SYN

 buffers, flow control info segment

(e.g. RcvWindow)  Không có dữ liệu

 client: bên khởi tạo kết nối đến Bước 2: server nhận segment SYN, và trả
server lời bằng segment SYNACK
Socket clientSocket = new  server cấp phát vùng buffer
Socket("hostname","port number");  Chỉ định số thứ tự (seq.#) cho

 server: chờ client liên lạc SYNACK segment

Socket connectionSocket = Bước 3: client nhận SYNACK, trả lời bằng
welcomeSocket.accept(); segment ACK, trong segment này có
thể chứa dữ liệu

Transport Layer 3-77

 TCP Connection Management (cont.)

Thủ tục “đóng kết nối” client server

client đóng socket: close

FIN
clientSocket.close();

Bước 1: client gửi segment FIN

ACK
đến server close
FIN
Bước 2: server nhận FIN, trả lời
bằng ACK. Sau đó server báo

timed wait
ACK
hiệu đóng kết nối từ phía mình
bằng cách gửi FIN.

closed

Transport Layer 3-78

 TCP Connection Management (cont.)
Bước 3: client nhận FIN, trả lời bằng
ACK.
client server
 Vào trạng thái “timed wait”: chờ
thêm 1 thời gian (VD 30s) trước closing
khi “đóng” . Trong thời gian này có FIN
thể gửi lại ACK nếu ACK đã gửi bị
mất.

Bước 4: server nhận ACK. Kết nối được ACK

closing
đóng.
FIN
Lưu ý: với một thay đổi nhỏ, server sẽ
xử lý được tình huống có nhiều FIN

timed wait
đến đồng thời ACK

closed

closed

Transport Layer 3-79

 TCP Connection Management (cont)

TCP server
lifecycle

TCP client
lifecycle

Transport Layer 3-80

 Chapter 3 outline
 3.1 Transport-layer
services
 3.2 Multiplexing and
demultiplexing
 3.3 Connectionless
transport: UDP
 3.4 Principles of reliable
data transfer
 3.5 Connection-oriented
transport: TCP
 segment structure
 reliable data transfer
 flow control
 connection management
 3.6 Principles of
congestion control
 3.7 TCP congestion
control
Transport Layer 3-81
 Principles of Congestion Control

Congestion:
 Nôm na: “Có quá nhiều máy, gửi quá nhiều dữ liệu,
gửi nhanh quá khả năng xử lý của mạng.
 Khác với flow control!
 Biểu hiện:
 Mất gói tin (tràn vùng đệm của router)
 Kéo dài thời gian (do xếp hàng chờ tại vùng đệm
router)
 Là 1 trong 10 vấn đề được quan tâm nhất!

Transport Layer 3-82

 Causes/costs of congestion: scenario 1
Host A out
in : original data
 02 máy gửi, 02 máy
nhận
Host B unlimited shared
 Một router với bộ output link buffers

đệm không giới hạn

 Ko truyền lại gói tin
bị hỏng

 Khi truyền “hết ga”,

băng thông có thể
được khai thác tối đa
nhưng độ trễ rất lớn.
 Đây là cái giá của sự
ùn tắt.

Transport Layer 3-83

 Causes/costs of congestion: scenario 2
 Một router, bộ đệm có kích thước giới hạn
 Bên gửi truyền lại gói tin bị mất

Host A in : original data out

'in : original data, plus

retransmitted data

Host B finite shared output

link buffers

Transport Layer 3-84

 Causes/costs of congestion: scenario 2
 out=’in: tình huống lý tưởng
 out< ’in: truyền lại hiệu quả
 Việc truyền lại các gói tin bị trễ (nhưng ko phải mất) làm cho ’in trở
nên lớn hơn so với trường hợp truyền lại hiệu quả, với cùng out
R/2 R/2 R/2

R/3
out

out
out

R/4

R/2 R/2 R/2

in in in

a. b. c.
“cái giá” của sự ùn tắt:
 Truyền lại dữ liệu bị mất do tràn bộ đệm
 Truyền lại ko cần thiết các gói tin mà bên gửi “tưởng bị mất”
Transport Layer 3-85
Causes/costs of congestion: scenario 3
H 
o
s o
t
u
A
t

H
o
s
t
B

“Cái giá” của sự ùn tắt:

 Khi 1 gói tin bị mất (do tràn vùng đệm của router), bất
kỳ công sức truyền gói tin đó ở các router nằm trước
nào cũng là vô ích!

Transport Layer 3-86

 Causes/costs of congestion: scenario 3
 04 host gửi dữ liệu
 Tuyến truyền băng qua nhiều router
Q: điều gì sẽ xảy ra khi
 Sử dụng cơ chế timeout/retransmit
in và ’in gia tăng ?
Host B
Host A out
in : original data
'in : original data, plus
retransmitted data
finite shared output
link buffers

Host D R4 R1
Host C

R2

R3
Transport Layer 3-87
 Approaches towards congestion control
Có 2 cách tiếp cận để kiểm soát ùn tắt:
network-assisted congestion
end-end congestion control:
control:  Tầng mạng (cụ thể là router) cung
cấp thông tin feedback cho các host.
 Tầng mạng ko cung cấp  Sử dụng 1 bit trong các gói tin
thông tin nào về tình trạng để biểu thị trạng thái ùn tắt (VD
ùn tắt. trong mạng SNA, DECnet,
 Các host suy diễn ra sự ùn TCP/IP RFC 3168, ATM ABR)
tắt do quan sát các dấu hiệu  Thông tin có thể đến sender bằng 1
mất gói tin và thời gian bị trong 2 cách: trực tiếp từ router-
kéo dài. >sender, gián tiếp router->reveiver-
>sender
 TCP chọn cách tiếp cận này.

Transport Layer 3-88

 Case study: ATM ABR congestion control
ABR: available bit rate:
 “dịch vụ truyền dữ liệu linh
hoạt”
 Nếu đường truyền bên gửi
không bị quá tải:
 Bên gửi nên sử dụng
toàn bộ băng thông dự
phòng.
 Ngược lại:
 Bên gửi điều chỉnh mức
độ gửi tối thiểu.
RM (resource management)
cells:
 Cell~ Gói tin trong mạng ATM
 Bên gửi gửi RM cells, đan xen với
các data cells.
 Các switch thiết lập giá trị cho các
bit trong gói tin RM (có bàn tay
của tầng mạng!)
 NI bit: no increase in rate (ko
ùn tắt)
 CI bit: congestion indication
 Bên nhận gửi nguyên RM cells lại
cho bên gửi. Bên gửi sẽ biết là có
ùn tắt hay không.
Transport Layer 3-89
 Chapter 3 outline
 3.1 Transport-layer
services
 3.2 Multiplexing and
demultiplexing
 3.3 Connectionless
transport: UDP
 3.4 Principles of reliable
data transfer
 3.5 Connection-oriented
transport: TCP
 segment structure
 reliable data transfer
 flow control
 connection management
 3.6 Principles of
congestion control
 3.7 TCP congestion
control
Transport Layer 3-90
 Case study: ATM ABR congestion control

 two-byte ER (explicit rate) field in RM cell

 Switch bị ùn tắt, có thể hạ thấp giá trị ER của RM cell khi đi ngang qua switch
 Theo cách này, ER có thể được đặt thành giá trị nhỏ nhất mà tất cả các switch
trên con đường từ nguồn đến đích cho phép.
 EFCI bit in data cells: set to 1 in congested switch
 Nếu phần lớn các data cell đi trước RM cell có bit EFCI được bật lên 1, bên
nhận sẽ bật CI bit của RM cell đó lên 1 trước khi gửi RM Cell về cho bên gửi,
báo hiệu có ùn tắt.

Transport Layer 3-91

 TCP congestion control:
 Mục tiêu: Trong TCP, bên gửi cần truyền dữ liệu nhanh
nhất có thể, nhưng ko được gây ùn tắt mạng
 Q: làm thế nào để tìm ra mức truyền vừa dưới mức có thể gây
ùn tắt.
 Mỗi bên gửi tự thiết lập tốc độ truyền, dựa trên các dấu
hiệu phản hồi:
 ACK: dấu hiệu này cho biết rằng đã được nhận,
chứng tỏ mạng không bị ùn tắt. Do đó bên gửi gia
tăng tốc độ truyền.
 Mất segment: bên gửi giả định rằng nguyên nhân
mất là do mạng bị ùn tắt, do đó nó giảm tốc độ
truyền.

Transport Layer 3-92

TCP congestion control: bandwidth probing
 Thăm dò băng thông mạng (“probing for bandwidth”):
gia tăng tốc độ truyền khi còn nhận được ACK, đến khi
có sự kiện mất gói tin xảy ra thì giảm tốc độ truyền.
 Tiếp tục gia tăng tốc độ truyền khi nhận được ACK và giảm khi
thấy mất gói tin (vì bằng thông của mạng có thể thay đổi, phụ
thuộc vào các kết nối khác trong mạng)
ACKs being received,
X loss, so decrease rate
so increase rate
X
X
sending rate

X
TCP’s
X “sawtooth”
behavior

time

 Q: how fast to increase/decrease?

 details to follow
Transport Layer 3-93
 TCP Congestion Control: details
 Bên gửi giới hạn tốc độ truyền bằng việc giới hạn
lượng dữ liệu chưa-được-xác-nhận:
LastByteSent-LastByteAcked  min (cwnd,
rwnd)
 cwnd: congestion window
 rwnd: receive window
 Một cách gần đúng:
cwnd
bytes

 cwnd là thường xuyên thay đổi, phụ thuộc vào

mức độ ùn tắt của mạng mà bên gửi “nhận thức”
được. cwnd RTT
Tốc độ truyền = bytes/sec
RTT
ACK(s)

Transport Layer 3-94

 TCP Congestion Control: more details
Bên gửi giảm cwnd khi Bên gửi tăng cwnd khi
có sự kiện “mất nhận được ACK
segment”, xảy ra khi:  Giai đoạn slow-start
 Đã timeout mà  Gia tăng theo hàm
không nhận được mũ
phản hồi  Giai đoạn tránh tắc
 Giảm cwnd về 1 nghẽn
 Nhận được 3 ACK  Gia tăng tuyến tính
trùng nhau
 Giảm cwnd một nửa

Transport Layer 3-95

 TCP Slow Start
 Khi kết nối bắt đầu, cwnd = 1 MSS
 VD: MSS = 500 bytes & RTT = 200 Host A Host B
msec
=>Tốc độ truyền = 20 kbps one segm
ent

RTT
 Năng lực của đường truyền có thể lớn
hơn MSS/RTT rất nhiều lần two segm
ents
 Có nhu cầu tăng nhanh đến tốc độ
truyền phù hợp.
 Gia tăng tốc độ truyền theo hàm mũ,
four segm
cho tới khi có sự kiện “mất segment” ents
xảy ra hoặc khi chạm ngưỡng.
 Gấp đôi cwnd sau mỗi RTT
 Làm điều này bằng cách tăng cwnd
lên 1 sau mỗi lần nhận được ACK.
time

Transport Layer 3-96

 Transitioning into/out of slowstart
ssthresh: là biến lưu giá trị ngưỡng của cwnd , do TCP quản lý
 Khi “mất segment”: đặt ssthresh bằng cwnd/2
 ghi nhận lại 1 nửa giá trị cwnd vào thời điểm ùn tắt trước đó
 Khi cwnd >= ssthresh: chuyển từ slowstart sang giai đoạn tránh ùn
tắt.

duplicate ACK
dupACKcount++ new ACK
cwnd = cwnd+MSS
dupACKcount = 0
 transmit new segment(s),as allowed
cwnd = 1 MSS
ssthresh = 64 KB cwnd > ssthresh
dupACKcount = 0 slow  congestion
start timeout avoidance
ssthresh = cwnd/2
cwnd = 1 MSS
dupACKcount = 0
timeout
retransmit missing segment
ssthresh = cwnd/2
cwnd = 1 MSS
dupACKcount = 0
retransmit missing segment

Transport Layer 3-97

 TCP: congestion avoidance
 Khi cwnd > ssthresh gia AIMD
tăng cwnd tuyến tính
 ACKs: increase cwnd
• Tăng cwnd thêm 1 MSS
by 1 MSS per RTT:
sau mỗi RTT additive increase
• Đạt tới điểm ùn tắt khả dĩ
 loss: cut cwnd in half
chậm hơn slowstart (non-timeout-detected
• Cài đặt: với mỗi ACK nhận loss ): multiplicative
được decrease
cwnd = cwnd + MSS/cwnd
AIMD: Additive Increase
Multiplicative Decrease

Transport Layer 3-98

Summary: congestion control algorithm
ssthresh = ? (e,g, 64KB)
cwnd = 1 MSS
/* slow start or exponential increase */
While (No Packet Loss and cwnd < ssthresh ) {
send cwnd TCP segments
for each ACK, cwnd = cwnd + 1 MSS
}
/* congestion avoidance or linear increase */
While (No Packet Loss) {
send cwnd TCP segments
/* increase cwnd by 1 MSS when cwnd ACKs are received */
for each ACK, cwnd = cwnd + MSS/cwnd
}
ssthresh = cwnd/2
If (3 Dup ACKs) cwnd = ssthresh;
Else If (timeout) cwnd=1 MSS;
Transport Layer 3-99
 Popular “flavors” of TCP

TCP Reno
cwnd window size (in segments)

ssthresh

ssthresh

TCP Tahoe

Transmission round

Transport Layer 3-100

TCP congestion control FSM: overview

slow cwnd > ssthresh

congestion
start avoidance
loss:
timeout
loss:
timeout

loss: new ACK loss:

timeout 3dupACK
fast
loss: recovery
3dupACK

Transport Layer 3-101

 TCP congestion control FSM: details

duplicate ACK
dupACKcount++ new ACK
new ACK
.
cwnd = cwnd + MSS (MSS/cwnd)
dupACKcount = 0
cwnd = cwnd+MSS transmit new segment(s),as allowed
dupACKcount = 0
 transmit new segment(s),as allowed
cwnd = 1 MSS
ssthresh = 64 KB cwnd > ssthresh
dupACKcount = 0
slow  congestion
start timeout avoidance
ssthresh = cwnd/2
cwnd = 1 MSS duplicate ACK
dupACKcount = 0
timeout dupACKcount++
retransmit missing segment
ssthresh = cwnd/2
cwnd = 1 MSS
dupACKcount = 0
retransmit missing segment
timeout
ssthresh = cwnd/2
cwnd = 1 New ACK
dupACKcount = 0
retransmit missing segment cwnd = ssthresh dupACKcount == 3
dupACKcount == 3 dupACKcount = 0
ssthresh= cwnd/2 ssthresh= cwnd/2
cwnd = ssthresh + 3 cwnd = ssthresh + 3
retransmit missing segment retransmit missing segment
fast
recovery
duplicate ACK
cwnd = cwnd + MSS
transmit new segment(s), as allowed

Transport Layer 3-102

 Summary: TCP Congestion Control

 Khi cwnd < ssthresh, bên gửi làm việc theo slow-
start, cửa sổ cwnd tăng nhanh theo hàm mũ.
 Khi cwnd >= ssthresh, bên gửi làm việc theo
congestion-avoidance, cửa sổ cwnd tăng tuyến tính.
 Khi nhận được 3 ACK trùng nhau,
ssthresh := cwnd/2, cwnd := ssthresh
 Khi timeout xảy ra,
ssthresh := cwnd/2, cwnd := 1 MSS.

Transport Layer 3-103

 TCP throughput
 Q: Thông lượng trung bình của TCP là bao nhiêu,
tính theo kích thước cửa sổ và RTT?
• Bỏ qua giai đoạn slow start
 Gọi W là kích thước của sổ khi có sự kiện “mất
segment”.
• Khi kích thước cửa sổ là W, thông lượng là
W/RTT
• Ngay sau khi mất segment, cửa sổ giảm xuống
W/2, thông lượng giảm thành W/2RTT.
• Thông lượng trung bình: 0.75 W/RTT

Transport Layer 3-104

 TCP Futures: TCP over “long, fat pipes”

 VD: Xét kết nối TCP với segment kích thước 1500
byte, RTT= 100ms, chúng ta muốn thông lượng 10
Gbps trên kết nối TCP này.
 Cần phải có cửa sổ với kích thước W = 83,333 in-
flight segments
 Thông lượng tính theo tỷ lệ mất gói tin (loss rate L):

1.22  MSS
RTT L
 ➜ L = 2·10-10 Wow
 Phiên bản mới của TCP dành cho mạng tốc độ cao.

Transport Layer 3-105

 TCP Fairness
fairness goal: nếu có K phiên truyền TCP chia sẻ cùng
một kết nối TCP, mỗi phiên truyền có tốc độ truyền
trung bình R/K

TCP connection 1

bottleneck
TCP
router
connection 2
capacity R

Transport Layer 3-106

 Why is TCP fair?
Two competing sessions:
 Additive increase gives slope of 1, as throughout increases
 multiplicative decrease decreases throughput proportionally

R equal bandwidth share

Connection 2 throughput

loss: decrease window by factor of 2

congestion avoidance: additive increase
loss: decrease window by factor of 2
congestion avoidance: additive increase

Connection 1 throughput R

Transport Layer 3-107

 Fairness (more)
Fairness and UDP Fairness and parallel TCP
 Các ứng dụng connections
multimedia thường ko  Ko có gì ngăn cản các ứng
sử dụng TCP dụng mở nhiều kết nối song
 Ko muốn tốc độ truyền bị song giữa 2 host.
hạn chế do cơ chế  web browsers làm điều này
congestion control
 VD: một đường truyền băng
 Thay bằng UDP: thông R đang phục vụ 9 kết
 Truyền audio/video ở
nối;
một tốc độ truyền không
đổi, chấp nhận mất gói
 Nếu 1 ứd dùng 1 kết nối TCP,
tin chút đỉnh. nhận được bằng thông R/10
 Còn nếu ứd mở cùng lúc 11
kết nối TCPs, nhận được R/2 !

Transport Layer 3-108

 Chapter 3: Summary
 principles behind transport
layer services:
 multiplexing, demultiplexing
 reliable data transfer
 flow control
 congestion control
Next:
 instantiation and
 leaving the network
implementation in the Internet
 UDP “edge” (application,
 TCP
transport layers)
 into the network
“core”

Transport Layer 3-109