Download End-to-End Communication - ITTC

KU EECS 780 – Communication Networks – End-to-End Transport
© James P.G. Sterbenz
ITTC
Communication Networks
The University of Kansas EECS 780
End-to-End Transport
James P.G. Sterbenz
Department of Electrical Engineering & Computer Science
Information Technology & Telecommunications Research Center
The University of Kansas
[email protected]
http://www.ittc.ku.edu/~jpgs/courses/nets
21 February 2011
rev. 11.0
© 2004–2007 James P.G. Sterbenz
© 2004–2011 James
P.G. Sterbenz
ITTC
© James P.G. Sterbenz
End-to-End Transport
Outline
TL.1
TL.2
TL.3
TL.4
Transport services and interfaces
End-to-end functions and mechanisms
Internet transport protocols
Multipoint communication and reliable multicast
21 February 2011
KU EECS 780 – Comm Nets – E2E Transport
–1–
NET-TL-2
KU EECS 780 – Communication Networks – End-to-End Transport
ITTC
© James P.G. Sterbenz
End-to-End Transport
TL.1 Services and Interfaces
TL.1
TL.2
TL.3
TL.4
Transport services and interfaces
End-to-end functions and mechanisms
Internet transport protocols
Multipoint communication and reliable multicast
21 February 2011
KU EECS 780 – Comm Nets – E2E Transport
ITTC
NET-TL-3
© James P.G. Sterbenz
Transport Layer
Hybrid Layer/Plane Cube
management
data plane
L8
L7
L5
L4
L3
L2.5
L2
L1.5
L1
control plane
social
application
session
transport
network
virtual link
link
MAC
physical
21 February 2011
p
l
a
n
e
KU EECS 780 – Comm Nets – E2E Transport
–2–
Layer 4:
end-to-end
data transfer
in data and
control planes
NET-TL-4
KU EECS 780 – Communication Networks – End-to-End Transport
ITTC
© James P.G. Sterbenz
Transport Layer
Motivation
CPU
CPU
M
app
M
app
ES1
ES2
Why do we need a transport protocol?
21 February 2011
KU EECS 780 – Comm Nets – E2E Transport
ITTC
NET-TL-5
© James P.G. Sterbenz
Transport Layer
Ideal Network Model
CPU
R= ∞
CPU
M
app
M
app
ES1
ES2
D=0
• Ideal network model
– zero end-to-end delay
– unlimited end-to-end bandwidth
– perfect end-to-end transmission (no errors)
But what?
21 February 2011
KU EECS 780 – Comm Nets – E2E Transport
–3–
NET-TL-6
KU EECS 780 – Communication Networks – End-to-End Transport
ITTC
© James P.G. Sterbenz
Transport Layer
Ideal Network Model and Motivation
R
CPU
CPU
M
app
M
app
ES1
ES2
D
• Real networks are not ideal
• Need an end-to-end protocol to
– handle delay between communicating systems
– control transmission rate for bandwidth-limited paths
– perform error recovery
21 February 2011
KU EECS 780 – Comm Nets – E2E Transport
ITTC
NET-TL-7
© James P.G. Sterbenz
Transport Layer
Transport Association Definition
CPU
network
intermediate
system
CPU
M app
M app
end system
end system
• Transport association between end systems
– transport connection in the case of connection state
– transport flow in the case of soft state or stateless
– may be point-to-point or multipoint
21 February 2011
KU EECS 780 – Comm Nets – E2E Transport
–4–
NET-TL-8
KU EECS 780 – Communication Networks – End-to-End Transport
ITTC
© James P.G. Sterbenz
Transport Layer
End-to-End Protocol
application
application
session
session
transport
network
transport
network
network
network
link
link
link
link
end system
intermediate
system
intermediate
system
end system
network
link
intermediate
system
network
• Transport protocol
– is responsible for end-to-end transfer of a TPDU
– note to Bell-heads: not layer 2 “transport network”
21 February 2011
KU EECS 780 – Comm Nets – E2E Transport
ITTC
NET-TL-9
© James P.G. Sterbenz
Transport Layer
Service and Interfaces1
• Transport layer (L4) service to application layer (L7)
• Transfer PDU E2E (end-to-end)
– sender: encapsulate ADU into TPDU and transmit
– receiver: receive TPDU and decapsulate into ADU
• Multiplexing to application on end system
• Optional reliability:
– error checking/correction/retransmission
– need depends on application
– may be done application-to-application (A2A)
• Flow control between end systems
– assistance for network congestion control
21 February 2011
KU EECS 780 – Comm Nets – E2E Transport
–5–
NET-TL-10
KU EECS 780 – Communication Networks – End-to-End Transport
ITTC
© James P.G. Sterbenz
Transport Layer
Service and Interfaces2
• Transport layer uses service of network layer (L3)
– network layer establishes a path through the network
• Transport mechanisms depend on L3 service
–
–
–
–
datagrams vs. connections
best effort vs. QOS
error characteristics
strength and symmetry of connectivity
What are the Internet assumptions & service model?
21 February 2011
KU EECS 780 – Comm Nets – E2E Transport
ITTC
NET-TL-11
© James P.G. Sterbenz
Transport Layer
Types of Transport Protocols
• Spectrum of transport protocol specialisation
– general purpose
• e.g. TCP (almost)
– functionally partitioned
• e.g. ISO TP0–4
– application-oriented
• e.g. RTP
– special purpose
• Software engineering and implementation choice
21 February 2011
KU EECS 780 – Comm Nets – E2E Transport
–6–
NET-TL-12
KU EECS 780 – Communication Networks – End-to-End Transport
ITTC
© James P.G. Sterbenz
Transport Layer
Service and Interfaces
• Transport PDU encapsulates application data unit
– ADU: application data unit
– TPDU: transport protocol data unit (segment if TCP or UDP)
– TPDU = header + ADU + opt. trailer (protocol dependent)
application layer
application layer
ADU
ADU
transport layer
H
ADU
transport layer
T
TPDU
H
network layer
21 February 2011
ADU
T
network layer
KU EECS 780 – Comm Nets – E2E Transport
ITTC
NET-TL-13
© James P.G. Sterbenz
Transport Layer
Functional Placement
end system
CPU
end system
mem
mem
TPDUs
switch
network
interface
frames
packet
CPU
network
interface
frames
• Transport layer functionality only in end system
– host software or
– network interface (NIC)
21 February 2011
KU EECS 780 – Comm Nets – E2E Transport
–7–
NET-TL-14
KU EECS 780 – Communication Networks – End-to-End Transport
ITTC
© James P.G. Sterbenz
Transport Layer
End-to-End vs. Hop-by-Hop
• Transport layer is E2E analog of HBH link layer
– link layer (L2) transfers frames HBH
– network layer (L3) determines the path of hops
21 February 2011
KU EECS 780 – Comm Nets – E2E Transport
ITTC
NET-TL-15
© James P.G. Sterbenz
End-to-End vs. Hop-by-Hop
End-to-End Arguments
•
The end-to-end arguments (1st half)
•
Some functions can be correctly and completely
implemented only at the endpoints of a
communication association
Providing these functions as features in the net
is not possible
•
paraphrased from [Saltzer, Reed, Clark 1981]
21 February 2011
KU EECS 780 – Comm Nets – E2E Transport
–8–
NET-TL-16
KU EECS 780 – Communication Networks – End-to-End Transport
ITTC
© James P.G. Sterbenz
End-to-End vs. Hop-by-Hop
End-to-End Arguments
f -1
f
g
g′
f1
f1-1
g′′
f2
f2-1
g′′′
f3
f3-1
• Hop-by-Hop functions do not compose end-to-end
– between HBH boundaries, function f is defeated (g)
• e.g. error control: errors may occur within switches
• e.g. encryption: cleartext within switches may be snooped
• These functions must be done E2E
– doing them HBH is redundant , and may lower performance
21 February 2011
KU EECS 780 – Comm Nets – E2E Transport
ITTC
NET-TL-17
© James P.G. Sterbenz
End-to-End vs. Hop-by-Hop
End-to-End Arguments
•
The end-to-end arguments (2nd half)
– performance enhancement corollary
•
Functions should be duplicated hop-by-hop if there
is an overall (end-to-end) performance benefit
paraphrased from [Saltzer, Reed, Clark 1981]
21 February 2011
KU EECS 780 – Comm Nets – E2E Transport
–9–
NET-TL-18
KU EECS 780 – Communication Networks – End-to-End Transport
ITTC
© James P.G. Sterbenz
End-to-End vs. Hop-by-Hop
Hop-by-Hop Performance Enhancement
• E2E Argument (1st half) says what must be E2E
• HBH Performance enhancement (2nd half)
– functions should duplicated HBH if overall E2E benefit
• Analysis is required to determine cost/benefit
– added functionality in net may add overhead not offset
21 February 2011
KU EECS 780 – Comm Nets – E2E Transport
ITTC
NET-TL-19
© James P.G. Sterbenz
End-to-End vs. Hop-by-Hop
Performance Enhancement Example
• E2E vs. HBH error control for reliable communication
– E2E argument says error control must be done E2E
• e.g. E2E ARQ (error check code and retransmit if necessary
– but should HBH error control also be done?
100 m
wireless LAN
15 000 km
fiber WAN
Univ. Kansas
21 February 2011
100 m
fiber LAN
Univ. Sydney
KU EECS 780 – Comm Nets – E2E Transport
– 10 –
NET-TL-20
KU EECS 780 – Communication Networks – End-to-End Transport
ITTC
© James P.G. Sterbenz
End-to-End vs. Hop-by-Hop
Performance Enhancement Example
• E2E vs. HBH error control for reliable communication
– E2E argument says error control must be done E2E
• e.g. E2E ARQ (error check code and retransmit if necessary
– but should HBH error control also be done?
100 m
wireless LAN
15 000 km
fiber WAN
100 m
fiber LAN
Univ. Kansas
Univ. Sydney
• Effect of high loss rate on wireless link
– ~250 ms RTT retransmission for every corrupted packet
• Error control on wireless link reduces to ~1μs RTT
– shorter control loop results in dramatically lower E2E delay
21 February 2011
KU EECS 780 – Comm Nets – E2E Transport
ITTC
NET-TL-21
© James P.G. Sterbenz
End-to-End vs. Hop-by-Hop
Security
• Security and information assurance must be E2E
– information in the clear inside network nodes not secure
• Justification for HBH security mechanisms
– link security may be good enough for some
• wireless link encryption for WEP (wire equivalent protection)
note: 802.11 WEP not strong enough
– subnetwork or edge-to-edge security for VPNs
• assures enterprise security across open network…
…but not individual flow security
21 February 2011
KU EECS 780 – Comm Nets – E2E Transport
– 11 –
NET-TL-22
KU EECS 780 – Communication Networks – End-to-End Transport
ITTC
© James P.G. Sterbenz
End-to-End vs. Hop-by-Hop
E2E Argument Misinterpretations
• E2E-only
– do not replicate E2E services or features HBH
– violates HBH performance enhancement corollary
• Everything E2E
– implement as many services or feature E2E as possible
– misstatement of Internet design philosophy:
simple stateless network for resilience and survivability
21 February 2011
KU EECS 780 – Comm Nets – E2E Transport
ITTC
NET-TL-23
© James P.G. Sterbenz
End-to-End Transport
TL.2 Functions and Mechanisms
TL.1 Transport services and interfaces
TL.2 End-to-end functions and mechanisms
TL.2.1
TL.2.2
TL.2.3
TL.2.4
Framing and multiplexing
State management and transfer modes
Reliability and error control
Transmission control
TL.3 Internet transport protocols
TL.4 Multipoint communication and reliable multicast
21 February 2011
KU EECS 780 – Comm Nets – E2E Transport
– 12 –
NET-TL-24
KU EECS 780 – Communication Networks – End-to-End Transport
ITTC
© James P.G. Sterbenz
E2E Functions and Mechanisms
TL.2.1 Framing and Multiplexing
TL.1 Transport services and interfaces
TL.2 End-to-end functions and mechanisms
TL.2.1
TL.2.2
TL.2.3
TL.2.4
Framing and multiplexing
State management and transfer modes
Reliability and error control
Transmission control
TL.3 Internet transport Protocols
TL.4 Multipoint communication and reliable multicast
21 February 2011
KU EECS 780 – Comm Nets – E2E Transport
ITTC
NET-TL-25
© James P.G. Sterbenz
E2E Framing
Structure and Fields
• Delimits TPDU
– physical layer is coded bit stream
– receiver needs to delimit frames
• Header: how to process the TPDU
– protocol processing options
– demultiplexing fields: destination application identifier
• typically called port (Internet protocol suite terminology)
• ISO TSAPA: transport service access point address
• Trailer: what to do with the TPDU once arrived
– error check (CRC or checksum) for reliability
• most transport protocols have this in the header (e.g. TCP)
21 February 2011
KU EECS 780 – Comm Nets – E2E Transport
– 13 –
NET-TL-26
KU EECS 780 – Communication Networks – End-to-End Transport
ITTC
© James P.G. Sterbenz
E2E Framing
Application Layer Framing
ADU
ADU
TPDU
TPDU
TPDU
TPDU
MTU
transport layer fragmentation
ADU
ADU
TPDU
ADU
TPDU
ADU
TPDU
TPDU
application layer framing
• ALF (application layer framing)
– matching ADU to TPDU structure
– eliminates fragementation/reassembly overhead
– may be more efficient TPDU structure
21 February 2011
KU EECS 780 – Comm Nets – E2E Transport
ITTC
NET-TL-27
© James P.G. Sterbenz
E2E Multiplexing
Application and Transport Layer
transport muxing
• Multiplexing
appx
pa ADU
– application
• inter-application
coordination
– transport
pb ADU
appy
appz
pc ADU
host1
TPDU
TPDU
a3 pa ADU a4 pc ADU
host2
TPDU
a4 pb ADU
network muxing
• applications
sharing network
interface
– network
a3 pa ADU
NPDUs
a4 pb ADU
network demuxing
• end systems
sharing switch
a3 pa ADU
TPDU
host3
– MAC and link
a4 pb ADU a4 pc ADU
TPDU
TPDU
host4
• interfaces
sharing medium
21 February 2011
a4 pc ADU
appa
pa ADU
appb
pb ADU
pc ADU
appc
transport demuxing
KU EECS 780 – Comm Nets – E2E Transport
– 14 –
NET-TL-28
KU EECS 780 – Communication Networks – End-to-End Transport
ITTC
© James P.G. Sterbenz
E2E Functions and Mechanisms
TL.2.2 Transfer Modes and State Management
TL.1 Transport services and interfaces
TL.2 End-to-end functions and mechanisms
TL.2.1
TL.2.2
TL.2.3
TL.2.4
Framing and multiplexing
State management and transfer modes
Reliability and error control
Transmission control
TL.3 Internet transport protocols
TL.4 Multipoint communication and reliable multicast
21 February 2011
KU EECS 780 – Comm Nets – E2E Transport
ITTC
NET-TL-29
© James P.G. Sterbenz
E2E Functions and Mechanisms
Transport Protocol Service Categories
• Transfer mode
–
–
–
–
connectionless datagram
connection-oriented
transaction
continuous media streaming
• Reliability
– loss tolerance
• Delivery order
– ordered
– unordered
• Traffic characteristics
21 February 2011
KU EECS 780 – Comm Nets – E2E Transport
– 15 –
NET-TL-30
KU EECS 780 – Communication Networks – End-to-End Transport
ITTC
© James P.G. Sterbenz
E2E State Management
Control Loops
Alternatives?
21 February 2011
KU EECS 780 – Comm Nets – E2E Transport
ITTC
NET-TL-31
© James P.G. Sterbenz
E2E State Management
Control Loops
parameters
• Open loop
data
– control parameters
– no feedback
Open loop
Alternative?
21 February 2011
KU EECS 780 – Comm Nets – E2E Transport
– 16 –
NET-TL-32
KU EECS 780 – Communication Networks – End-to-End Transport
ITTC
© James P.G. Sterbenz
E2E State Management
Control Loops
parameters
• Open loop
data
– control parameters
– no feedback
Open loop
initial parameters
• Closed loop
E2E feedback
data
– initial parameters
– feedback
Closed loop
• dynamic adaptation
21 February 2011
KU EECS 780 – Comm Nets – E2E Transport
NET-TL-33
ITTC
© James P.G. Sterbenz
E2E State Management
Control Loops
parameters
• Open loop
data
– control parameters
– no feedback
Open loop
initial parameters
• Closed loop
data
– initial parameters
– feedback
Closed loop
initial parameters
E2E feedback
HBH feedback
• dynamic adaptation
data
• Closed loop
with HBH feedback initial parameters
data
• Nested control loops
sender
21 February 2011
E2E feedback
Closed loop with HBH feedback
E2E feedback
HBH loop
Nested control loops
KU EECS 780 – Comm Nets – E2E Transport
– 17 –
HBH loop
receiver
NET-TL-34
KU EECS 780 – Communication Networks – End-to-End Transport
ITTC
© James P.G. Sterbenz
E2E State Management
Open- vs. Closed-Loop
• Open-loop control
– use when possible to eliminate control loop latency
• particularly for high bandwidth-×-delay product networks
• Closed-loop feedback control
– use when necessary, e.g. reliability
– aggressiveness of closed-loop control
• rapid enough to system converges
• not too aggressive avoid instability and oscillations
21 February 2011
KU EECS 780 – Comm Nets – E2E Transport
ITTC
NET-TL-35
© James P.G. Sterbenz
E2E State Management
Hard vs. Soft
• Hard state
– explicitly established and released
– deterministic
– delay to establish and memory to maintain
Alternative?
21 February 2011
KU EECS 780 – Comm Nets – E2E Transport
– 18 –
NET-TL-36
KU EECS 780 – Communication Networks – End-to-End Transport
ITTC
© James P.G. Sterbenz
E2E State Management
Hard vs. Soft
• Hard state
– explicitly established and released
– deterministic
– delay to establish and memory to maintain
• Soft state
– established and removed as needed and memory allows
– robust to failures
– if not explicitly established, delay to accumulate
21 February 2011
KU EECS 780 – Comm Nets – E2E Transport
ITTC
NET-TL-37
© James P.G. Sterbenz
E2E State Management
Hard vs. Soft
• Hard state
– explicitly established and released
– deterministic
– delay to establish and memory to maintain
• Soft state
– established and removed as needed and memory allows
– robust to failures
– if not explicitly established, delay to accumulate
• Stateless
– (essentially) no state
21 February 2011
KU EECS 780 – Comm Nets – E2E Transport
– 19 –
NET-TL-38
KU EECS 780 – Communication Networks – End-to-End Transport
ITTC
© James P.G. Sterbenz
E2E State Management
Assumed Initial Conditions
• Improve performance of closed-loop control
– rapid convergence to steady state
• Assume initial conditions
– normal or common case
– past behaviour
– current network state (requires network dials)
21 February 2011
KU EECS 780 – Comm Nets – E2E Transport
ITTC
NET-TL-39
© James P.G. Sterbenz
E2E State Management
Impact of Data Rate
• Transmission delay
proportional to data rate
tRTT
SETUP
What happens when data
rate increases?
tp
td
ACK
RELEASE
slow
21 February 2011
KU EECS 780 – Comm Nets – E2E Transport
– 20 –
NET-TL-40
KU EECS 780 – Communication Networks – End-to-End Transport
ITTC
© James P.G. Sterbenz
E2E State Management
Impact of Data Rate
• Transmission delay
proportional to data rate
• Connection shortening
tRTT
SETUP
SETUP
tp
+ transmission delay decreases
– but signalling delay constant
td
ACK
RELEASE
ACK
RELEASE
slow
21 February 2011
fast
KU EECS 780 – Comm Nets – E2E Transport
NET-TL-41
ITTC
© James P.G. Sterbenz
E2E State Management
Impact of Data Rate
• Transmission delay
proportional to data rate
• Connection shortening
tRTT
SETUP
SETUP
~1.5tRTT
SETUP
tp
tp
+ transmission delay decreases
– but signalling delay constant
~2.5tRTT
• E2E signalling
ACK
td→0
td
ACK
– significant fraction of time
– connection shortening not
proportional to Δ date rate
RELEASE
RELEASE
ACK
RELEASE
slow
21 February 2011
KU EECS 780 – Comm Nets – E2E Transport
– 21 –
fast
high-speed
NET-TL-42
KU EECS 780 – Communication Networks – End-to-End Transport
ITTC
© James P.G. Sterbenz
E2E State Management
Impact of Latency
SETUP
• Transmission delay
and path delay
proportional to length
What happens when
length increases?
ACK
RELEASE
short links
21 February 2011
KU EECS 780 – Comm Nets – E2E Transport
NET-TL-43
ITTC
© James P.G. Sterbenz
E2E State Management
Impact of Path Length
SETUP
• Transmission delay
and path delay
proportional to length
• Connection lengthening
– path delay increases
– signalling delay increases
SETUP
ACK
RELEASE
• E2E signalling
– state open longer
– denial of resource to others
ACK
RELEASE
short links
21 February 2011
KU EECS 780 – Comm Nets – E2E Transport
– 22 –
long links
NET-TL-44
KU EECS 780 – Communication Networks – End-to-End Transport
ITTC
© James P.G. Sterbenz
E2E Transfer Modes
Alternatives
• End-to-end transfer modes
–
–
–
–
datagram
connection
stream
transaction
21 February 2011
KU EECS 780 – Comm Nets – E2E Transport
ITTC
NET-TL-45
© James P.G. Sterbenz
E2E Transfer Modes
Datagram
• Independent PDUs
– each has fully self-describing header
– no end-to-end flow state needed to forward
21 February 2011
KU EECS 780 – Comm Nets – E2E Transport
– 23 –
tp+td
NET-TL-46
KU EECS 780 – Communication Networks – End-to-End Transport
ITTC
© James P.G. Sterbenz
E2E Transfer Modes
Connection
• Explicit connection setup
– 3-way handshake
SETUP / CONNECT / ACK
why?
SETUP
~tRTT
~1.5tRTT
CONNECT
ACK
tr
~tRTT
RELEASE
21 February 2011
KU EECS 780 – Comm Nets – E2E Transport
ITTC
NET-TL-47
© James P.G. Sterbenz
E2E Transfer Modes
Connection
• Explicit connection setup
– 3-way handshake
SETUP / CONNECT / ACK
– both side have been acknowledged
SETUP
~tRTT
~1.5tRTT
CONNECT
ACK
tr
~tRTT
• Data flow
– PDUs need connection or flow identifier
• used by nodes to look up state
• Release of resources and state
– explicit RELEASE
– time out state
21 February 2011
RELEASE
KU EECS 780 – Comm Nets – E2E Transport
– 24 –
NET-TL-48
KU EECS 780 – Communication Networks – End-to-End Transport
ITTC
© James P.G. Sterbenz
E2E Transfer Modes
Transport and Network Connections
• Transport connections
– required over
end system
end system
transport layer
transport layer
setup-req
• connectionless L3
• path with any
connectionless
subnetwork
SETUP
network layer
connection-oriented
network
network layer
CONNECT
network layer connection
SETUP
transport layer
transport layer
CONNECT
connectionless
network
network layer
– may exploit
network layer
transport layer connection
• connection-oriented L3
SETUP
transport layer
transport layer
CONNECT
connectionless
subnetwork
network layer
network layer
connection-oriented
subnetwork
heterogeneous subnetworks
21 February 2011
KU EECS 780 – Comm Nets – E2E Transport
NET-TL-49
ITTC
© James P.G. Sterbenz
E2E Transfer Modes
Connection State Machine
• Connection
State Machine
– send/receive paths
• States
– idle
– establishing
originate
SETUP
request
establishing
issue
SETUP
– initialising
– steady state
– closing
requested
issue
CONNECT
initialising
CONNECT ACK
from net from net
• install state
• state
convergence
receive
SETUP
from net
idle
RELEASE
from app
steady -state
closing
issue
RELEASE
RELEASE
from net
closing
issue
RELEASE
• release state
21 February 2011
KU EECS 780 – Comm Nets – E2E Transport
– 25 –
NET-TL-50
KU EECS 780 – Communication Networks – End-to-End Transport
ITTC
© James P.G. Sterbenz
E2E Transfer Modes
Media Stream
SETUP
• Various mechanisms to start stream
CONNECT
– explicit client request
– server push
– may or may not establish connection state
REQUEST
• Data flow
– synchronisation and control
• embedded or
• out-of-band
More about this in Lecture MS
21 February 2011
RELEASE
KU EECS 780 – Comm Nets – E2E Transport
ITTC
NET-TL-51
© James P.G. Sterbenz
E2E Transfer Modes
Transaction
• Transaction request
REQUEST
– may or may not establish connection state
– explicit release of connection state optional
tr
RESPONSE
• Data returned
• Overlap to reduce latency
– request/response with control
RELEASE
• Recall: this is not how HTTP over TCP works
21 February 2011
KU EECS 780 – Comm Nets – E2E Transport
– 26 –
NET-TL-52
KU EECS 780 – Communication Networks – End-to-End Transport
ITTC
© James P.G. Sterbenz
E2E Functions and Mechanisms
TL.2.3 Reliability and Error Control
TL.1 Transport services and interfaces
TL.2 End-to-End functions and mechanisms
TL.2.1
TL.2.2
TL.2.3
TL.2.4
Framing and multiplexing
State management and transfer modes
Reliability and error control
Transmission control
TL.3 Internet transport protocols
TL.4 Multipoint communication and reliable multicast
21 February 2011
KU EECS 780 – Comm Nets – E2E Transport
ITTC
NET-TL-53
© James P.G. Sterbenz
E2E Error Control
Types of Errors
What are the types of errors?
21 February 2011
KU EECS 780 – Comm Nets – E2E Transport
– 27 –
NET-TL-54
KU EECS 780 – Communication Networks – End-to-End Transport
ITTC
© James P.G. Sterbenz
E2E Error Control
Types of Errors
• Bit errors
• Packet errors
types?
21 February 2011
KU EECS 780 – Comm Nets – E2E Transport
ITTC
NET-TL-55
© James P.G. Sterbenz
E2E Error Control
Types of Errors
• Bit errors
• Packet errors
–
–
–
–
–
–
packet loss
fragment loss
burst loss
packet misordering
packet insertion
packet duplication
21 February 2011
KU EECS 780 – Comm Nets – E2E Transport
– 28 –
NET-TL-56
KU EECS 780 – Communication Networks – End-to-End Transport
ITTC
© James P.G. Sterbenz
E2E Error Control
Causes of Bit Errors
• Bit errors
causes?
21 February 2011
KU EECS 780 – Comm Nets – E2E Transport
ITTC
NET-TL-57
© James P.G. Sterbenz
E2E Error Control
Causes of Bit Errors
• Bit errors
– flaky hardware
– wireless channels
• noise and interference
– optical channels
• long-haul fiber links engineered on margin with FEC
• control of amplifier and regenerator cost
More in lecture PL
21 February 2011
KU EECS 780 – Comm Nets – E2E Transport
– 29 –
NET-TL-58
KU EECS 780 – Communication Networks – End-to-End Transport
ITTC
© James P.G. Sterbenz
E2E Error Control
Causes of Packet Loss
• Packet loss
causes?
21 February 2011
KU EECS 780 – Comm Nets – E2E Transport
ITTC
NET-TL-59
© James P.G. Sterbenz
E2E Error Control
Causes of Packet Loss
• Packet loss
– network buffer overflow or intentional drop
more in lecture TQ
– transport protocol packet discard when bit error
21 February 2011
KU EECS 780 – Comm Nets – E2E Transport
– 30 –
NET-TL-60
KU EECS 780 – Communication Networks – End-to-End Transport
ITTC
© James P.G. Sterbenz
E2E Error Control
Causes of Packet Loss
• Packet loss
– network buffer overflow or intentional drop
more in lecture TQ
– transport protocol packet discard when bit error
• Packet fragment loss
causes?
impact?
21 February 2011
KU EECS 780 – Comm Nets – E2E Transport
ITTC
NET-TL-61
© James P.G. Sterbenz
E2E Error Control
Causes of Packet Loss
• Packet loss
– network buffer overflow or intentional drop
more in lecture TQ
– transport protocol packet discard when bit error
• Packet fragment loss
– loss of a piece of a fragmented packet
– effect: error multiplication
• loss of a fragment in net generally results in entire packet loss
21 February 2011
KU EECS 780 – Comm Nets – E2E Transport
– 31 –
NET-TL-62
KU EECS 780 – Communication Networks – End-to-End Transport
ITTC
© James P.G. Sterbenz
E2E Error Control
Causes of Packet Burst Loss
• Packet burst loss
causes?
21 February 2011
KU EECS 780 – Comm Nets – E2E Transport
ITTC
NET-TL-63
© James P.G. Sterbenz
E2E Error Control
Causes of Packet Burst Loss
• Packet burst loss
– network buffer overflow during congestion
• with high rate flow having adjacent (non-interleaved) packets
more in lecture TQ
– wireless channel fades
more in lecture PL
21 February 2011
KU EECS 780 – Comm Nets – E2E Transport
– 32 –
NET-TL-64
KU EECS 780 – Communication Networks – End-to-End Transport
ITTC
© James P.G. Sterbenz
E2E Error Control
Causes of Packet Misordering
• Packet misordering
causes?
21 February 2011
KU EECS 780 – Comm Nets – E2E Transport
ITTC
NET-TL-65
© James P.G. Sterbenz
E2E Error Control
Causes of Packet Misordering
• Packet misordering
– multiple paths through switch or network
– non-deterministic paths through switch or network
– path reconfiguration
• after failure
• due to mobility
• due to load balancing
more in lecture NL
21 February 2011
KU EECS 780 – Comm Nets – E2E Transport
– 33 –
NET-TL-66
KU EECS 780 – Communication Networks – End-to-End Transport
ITTC
© James P.G. Sterbenz
E2E Error Control
Causes of Packet Insertion
• Packet insertion
meaning?
causes?
21 February 2011
KU EECS 780 – Comm Nets – E2E Transport
ITTC
NET-TL-67
© James P.G. Sterbenz
E2E Error Control
Causes of Packet Insertion
• Packet insertion
– undetectable header error
• packet appears that was destined elsewhere
– long packet life
• packet with same destination and sequence number still in net
21 February 2011
KU EECS 780 – Comm Nets – E2E Transport
– 34 –
NET-TL-68
KU EECS 780 – Communication Networks – End-to-End Transport
ITTC
© James P.G. Sterbenz
E2E Error Control
Causes of Packet Duplication
• Packet duplication
causes?
21 February 2011
KU EECS 780 – Comm Nets – E2E Transport
ITTC
NET-TL-69
© James P.G. Sterbenz
E2E Error Control
Causes of Packet Duplication
• Packet duplication
– retransmission but original still arrives
21 February 2011
KU EECS 780 – Comm Nets – E2E Transport
– 35 –
NET-TL-70
KU EECS 780 – Communication Networks – End-to-End Transport
ITTC
© James P.G. Sterbenz
E2E Error Control
Impact of High Speed
• Bandwidth-×-delay product increases
– fixed duration error event larger relative impact
– closed-loop reaction occurs later in terms of # bits sent
• Sequence numbers
– sequence numbers wrap if sequence space too small
• causes packet duplication
21 February 2011
KU EECS 780 – Comm Nets – E2E Transport
ITTC
NET-TL-71
© James P.G. Sterbenz
E2E Error Control
ARQ Closed Loop Retransmission
• Automatic repeat request (ARQ)
– PDUs are retransmitted for reliable transfer
• Acknowledgments are used to request retransmission
alternatives?
21 February 2011
KU EECS 780 – Comm Nets – E2E Transport
– 36 –
NET-TL-72
KU EECS 780 – Communication Networks – End-to-End Transport
ITTC
© James P.G. Sterbenz
E2E Error Control
ARQ Closed Loop Retransmission
• Automatic repeat request (ARQ)
– PDUs are retransmitted for reliable transfer
• Acknowledgments are used to request retransmission
– ACK: positive acknowledgement
– NAK (or NACK): negative acknowledgement
tradeoff?
21 February 2011
KU EECS 780 – Comm Nets – E2E Transport
ITTC
NET-TL-73
© James P.G. Sterbenz
E2E Error Control
ARQ Closed Loop Retransmission
• Automatic repeat request (ARQ)
– PDUs are retransmitted for reliable transfer
• Acknowledgments are used to request retransmission
– ACK: positive acknowledgement
– NAK (or NACK): negative acknowledgement
– tradeoff between error rate and predictability
Simplest ARQ mechanism?
21 February 2011
KU EECS 780 – Comm Nets – E2E Transport
– 37 –
NET-TL-74
KU EECS 780 – Communication Networks – End-to-End Transport
ITTC
© James P.G. Sterbenz
E2E Error Control
Closed Loop Retransmission: Stop-and-Wait
• Each TPDU is acknowledged
0
1
21 February 2011
KU EECS 780 – Comm Nets – E2E Transport
ITTC
NET-TL-75
© James P.G. Sterbenz
E2E Error Control
Closed Loop Retransmission: Stop-and-Wait
• Each TPDU is acknowledged
0
0
2
21 February 2011
KU EECS 780 – Comm Nets – E2E Transport
– 38 –
NET-TL-76
KU EECS 780 – Communication Networks – End-to-End Transport
ITTC
© James P.G. Sterbenz
E2E Error Control
Closed Loop Retransmission: Stop-and-Wait
• Each TPDU is acknowledged
0
– subsequent TPDU waits on previous ACK
disadvantages?
0
A0
3
21 February 2011
KU EECS 780 – Comm Nets – E2E Transport
ITTC
NET-TL-77
© James P.G. Sterbenz
E2E Error Control
Closed Loop Retransmission: Stop-and-Wait
• Each TPDU is acknowledged
0
– subsequent TPDU waits on previous ACK
• significant delay and underutilisation
• 1 RTT per TPDU
• serious penalty in long-delay environment
0
A0
tack
1
4
21 February 2011
KU EECS 780 – Comm Nets – E2E Transport
– 39 –
NET-TL-78
KU EECS 780 – Communication Networks – End-to-End Transport
ITTC
© James P.G. Sterbenz
E2E Error Control
Closed Loop Retransmission: Stop-and-Wait
• Each TPDU is acknowledged
0
– subsequent TPDU waits on previous ACK
• significant delay and underutilisation
• 1 RTT per TPDU
• serious penalty in long-delay environment
0
A0
tack
1
– sender timer tack fires if ACK not received
issues?
5
21 February 2011
KU EECS 780 – Comm Nets – E2E Transport
ITTC
NET-TL-79
© James P.G. Sterbenz
E2E Error Control
Closed Loop Retransmission: Stop-and-Wait
• Each TPDU is acknowledged
0
– subsequent TPDU waits on previous ACK
• significant delay and underutilisation
• 1 RTT per TPDU
• serious penalty in long-delay environment
0
A0
tack
1
– sender timer tack fires if ACK not received
• too conservative: issues?
• too aggressive: issues?
1
6
21 February 2011
KU EECS 780 – Comm Nets – E2E Transport
– 40 –
NET-TL-80
KU EECS 780 – Communication Networks – End-to-End Transport
ITTC
© James P.G. Sterbenz
E2E Error Control
Closed Loop Retransmission: Stop-and-Wait
• Each TPDU is acknowledged
0
– subsequent TPDU waits on previous ACK
• significant delay and underutilisation
• 1 RTT per TPDU
• serious penalty in long-delay environment
0
A0
tack
1
– sender timer tack fires if ACK not received
• too conservative: unnecessary delay
• too aggressive: spurious retransmissions
1
1
7
21 February 2011
KU EECS 780 – Comm Nets – E2E Transport
ITTC
NET-TL-81
© James P.G. Sterbenz
E2E Error Control
Closed Loop Retransmission: Stop-and-Wait
• Each TPDU is acknowledged
0
– subsequent TPDU waits on previous ACK
• significant delay and underutilisation
• 1 RTT per TPDU
• serious penalty in long-delay environment
0
A0
tack
1
– sender timer tack fires if ACK not received
• too conservative: unnecessary delay
• too aggressive: spurious retransmissions
How can we do better?
1
1
A1
8
21 February 2011
KU EECS 780 – Comm Nets – E2E Transport
– 41 –
NET-TL-82
KU EECS 780 – Communication Networks – End-to-End Transport
ITTC
© James P.G. Sterbenz
E2E Error Control
Closed Loop Retransmission: Go-Back-n
• Go-back-n : pipeline transmissions
0
1
21 February 2011
KU EECS 780 – Comm Nets – E2E Transport
ITTC
NET-TL-83
© James P.G. Sterbenz
E2E Error Control
Closed Loop Retransmission: Go-Back-n
• Go-back-n : pipeline transmissions
0
+ multiple TPDUs simultaneously in flight
1
0
A0
2
21 February 2011
KU EECS 780 – Comm Nets – E2E Transport
– 42 –
NET-TL-84
KU EECS 780 – Communication Networks – End-to-End Transport
ITTC
© James P.G. Sterbenz
E2E Error Control
Closed Loop Retransmission: Go-Back-n
• Go-back-n : pipeline transmissions
+ multiple TPDUs simultaneously in flight
• TPDUs are sequentially acknowledged
0
tack
1
0
2
1
A0
A1
3
21 February 2011
KU EECS 780 – Comm Nets – E2E Transport
ITTC
NET-TL-85
© James P.G. Sterbenz
E2E Error Control
Closed Loop Retransmission: Go-Back-n
• Go-back-n : pipeline transmissions
+ multiple TPDUs simultaneously in flight
• TPDUs are sequentially acknowledged
how is TPDU loss detected?
0
tack
A0
1
0
2
1
3
A1
4
21 February 2011
KU EECS 780 – Comm Nets – E2E Transport
– 43 –
NET-TL-86
KU EECS 780 – Communication Networks – End-to-End Transport
ITTC
© James P.G. Sterbenz
E2E Error Control
Closed Loop Retransmission: Go-Back-n
• Go-back-n : pipeline transmissions
+ multiple TPDUs simultaneously in flight
• TPDUs are sequentially acknowledged
o previous ACK retransmitted for
• subsequent TPDUs after loss
• out of sequence TPDU
0
tack
A0
A1
1
0
2
1
3
4
A1
5
21 February 2011
KU EECS 780 – Comm Nets – E2E Transport
ITTC
NET-TL-87
© James P.G. Sterbenz
E2E Error Control
Closed Loop Retransmission: Go-Back-n
• Go-back-n : pipeline transmissions
+ multiple TPDUs simultaneously in flight
• TPDUs are sequentially acknowledged
o previous ACK retransmitted for
• subsequent TPDUs after loss
• out of sequence TPDU
o sender timer fires if ACK not received
0
tack
A0
A1
1
0
2
1
3
4
5
A1
A1
implication?
6
21 February 2011
KU EECS 780 – Comm Nets – E2E Transport
– 44 –
NET-TL-88
KU EECS 780 – Communication Networks – End-to-End Transport
ITTC
© James P.G. Sterbenz
E2E Error Control
Closed Loop Retransmission: Go-Back-n
• Go-back-n : pipeline transmissions
+ multiple TPDUs simultaneously in flight
• TPDUs are sequentially acknowledged
o previous ACK retransmitted for
• subsequent TPDUs after loss
• out of sequence TPDU
o sender timer fires if ACK not received
• reset transmission beginning at lost TPDU
0
tack
A0
A1
1
0
2
1
3
4
5
A1
2
A1
A1
7
21 February 2011
KU EECS 780 – Comm Nets – E2E Transport
ITTC
NET-TL-89
© James P.G. Sterbenz
E2E Error Control
Closed Loop Retransmission: Go-Back-n
• Go-back-n : pipeline transmissions
+ multiple TPDUs simultaneously in flight
• TPDUs are sequentially acknowledged
o previous ACK retransmitted for
• subsequent TPDUs after loss
• out of sequence TPDU
o sender timer fires if ACK not received
• reset transmission beginning at lost TPDU
0
tack
A0
A1
1
0
2
1
3
4
5
A1
2
A1
3
2
A1
A2
8
21 February 2011
KU EECS 780 – Comm Nets – E2E Transport
– 45 –
NET-TL-90
KU EECS 780 – Communication Networks – End-to-End Transport
ITTC
© James P.G. Sterbenz
E2E Error Control
Closed Loop Retransmission: Go-Back-n
• Go-back-n : pipeline transmissions
+ multiple TPDUs simultaneously in flight
• TPDUs are sequentially acknowledged
o previous ACK retransmitted for
• subsequent TPDUs after loss
• out of sequence TPDU
o sender timer fires if ACK not received
• reset transmission beginning at lost TPDU
0
tack
A0
A1
1
0
2
1
3
4
5
A1
2
A1
3
2
A1
4
3
A2
A3
9
21 February 2011
KU EECS 780 – Comm Nets – E2E Transport
ITTC
NET-TL-91
© James P.G. Sterbenz
E2E Error Control
Closed Loop Retransmission: Go-Back-n
• Go-back-n : pipeline transmissions
+ multiple TPDUs simultaneously in flight
• TPDUs are sequentially acknowledged
o previous ACK retransmitted for
• subsequent TPDUs after loss
• out of sequence TPDU
o sender timer fires if ACK not received
• reset transmission beginning at lost TPDU
0
tack
A0
A1
1
0
2
1
3
4
5
A1
2
A1
3
2
A1
4
3
5
4
A2
A3
A4
10
21 February 2011
KU EECS 780 – Comm Nets – E2E Transport
– 46 –
NET-TL-92
KU EECS 780 – Communication Networks – End-to-End Transport
ITTC
© James P.G. Sterbenz
E2E Error Control
Closed Loop Retransmission: Go-Back-n
• Go-back-n : pipeline transmissions
+ multiple TPDUs simultaneously in flight
• TPDUs are sequentially acknowledged
o previous ACK retransmitted for
• subsequent TPDUs after loss
• out of sequence TPDU
o sender timer fires if ACK not received
• reset transmission beginning at lost TPDU
0
tack
A0
A1
1
0
2
1
3
4
5
A1
2
A1
3
2
A1
4
3
5
4
A2
A3
5
6
A4
A5
11
21 February 2011
KU EECS 780 – Comm Nets – E2E Transport
ITTC
NET-TL-93
© James P.G. Sterbenz
E2E Error Control
Closed Loop Retransmission: Go-Back-n
• Go-back-n : pipeline transmissions
+ multiple TPDUs simultaneously in flight
• TPDUs are sequentially acknowledged
o previous ACK retransmitted for
• subsequent TPDUs after loss
• out of sequence TPDU
o sender timer fires if ACK not received
• reset transmission beginning at lost TPDU
disadvantages?
0
tack
A0
A1
1
0
2
1
3
4
5
A1
2
A1
3
2
A1
4
3
5
4
A2
A3
A4
5
6
6
A5
12
21 February 2011
KU EECS 780 – Comm Nets – E2E Transport
– 47 –
NET-TL-94
KU EECS 780 – Communication Networks – End-to-End Transport
ITTC
© James P.G. Sterbenz
E2E Error Control
Closed Loop Retransmission: Go-Back-n
• Go-back-n : pipeline transmissions
+ multiple TPDUs simultaneously in flight
• TPDUs are sequentially acknowledged
o previous ACK retransmitted for
• subsequent TPDUs after loss
• out of sequence TPDU
o sender timer fires if ACK not received
• reset transmission beginning at lost TPDU
– significant loss penalty for high bw-×-delay
• go back and retransmit all since loss
• many unneeded retransmissions
• significant additional delay
21 February 2011
0
tack
A0
A1
1
0
2
1
3
4
5
A1
2
A1
3
2
A1
4
3
5
4
A2
A3
5
6
A4
6
A5
13
KU EECS 780 – Comm Nets – E2E Transport
ITTC
NET-TL-95
© James P.G. Sterbenz
E2E Error Control
Closed Loop Retransmission: Go-Back-n
• Optimisation possible for go-back-n?
0
tack
A0
A1
1
0
2
1
3
4
5
A1
2
A1
3
2
A1
4
3
5
4
A2
A3
A4
5
6
6
A5
21 February 2011
KU EECS 780 – Comm Nets – E2E Transport
– 48 –
NET-TL-96
KU EECS 780 – Communication Networks – End-to-End Transport
ITTC
© James P.G. Sterbenz
E2E Error Control
Closed Loop Retransmission: Go-Back-n
• Optimisation go-back-n
timer the only way to detect loss?
0
tack
A0
A1
1
0
2
1
3
4
5
A1
2
A1
3
2
A1
4
3
5
4
A2
A3
5
6
A4
6
A5
21 February 2011
KU EECS 780 – Comm Nets – E2E Transport
ITTC
NET-TL-97
© James P.G. Sterbenz
E2E Error Control
Closed Loop Retransmission: Fast Retransmit
• Fast retransmit
0
– optimisation for go-back-n
1
21 February 2011
KU EECS 780 – Comm Nets – E2E Transport
– 49 –
NET-TL-98
KU EECS 780 – Communication Networks – End-to-End Transport
ITTC
© James P.G. Sterbenz
E2E Error Control
Closed Loop Retransmission: Fast Retransmit
• Fast retransmit
0
– optimisation for go-back-n
0
1
A0
2
21 February 2011
KU EECS 780 – Comm Nets – E2E Transport
ITTC
NET-TL-99
© James P.G. Sterbenz
E2E Error Control
Closed Loop Retransmission: Fast Retransmit
• Fast retransmit
0
– optimisation for go-back-n
tack
1
0
2
1
A0
A1
3
21 February 2011
KU EECS 780 – Comm Nets – E2E Transport
– 50 –
NET-TL-100
KU EECS 780 – Communication Networks – End-to-End Transport
ITTC
© James P.G. Sterbenz
E2E Error Control
Closed Loop Retransmission: Fast Retransmit
• Fast retransmit
0
– optimisation for go-back-n
tack
A0
1
0
2
1
3
A1
4
21 February 2011
KU EECS 780 – Comm Nets – E2E Transport
ITTC
NET-TL-101
© James P.G. Sterbenz
E2E Error Control
Closed Loop Retransmission: Fast Retransmit
• Fast retransmit
0
– optimisation for go-back-n
• Assume several duplicate ACKs are loss
tack
A0
A1
1
0
2
1
3
4
A1
5
21 February 2011
KU EECS 780 – Comm Nets – E2E Transport
– 51 –
NET-TL-102
KU EECS 780 – Communication Networks – End-to-End Transport
ITTC
© James P.G. Sterbenz
E2E Error Control
Closed Loop Retransmission: Fast Retransmit
• Fast retransmit
0
– optimisation for go-back-n
• Assume several duplicate ACKs are loss
o even if timer hasn’t yet fired
tack
A0
A1
1
0
2
1
3
4
5
A1
A1
2
6
21 February 2011
KU EECS 780 – Comm Nets – E2E Transport
ITTC
NET-TL-103
© James P.G. Sterbenz
E2E Error Control
Closed Loop Retransmission: Fast Retransmit
• Fast retransmit
0
– optimisation for go-back-n
• Assume several duplicate ACKs are loss
o even if timer hasn’t yet fired
+ recovers from loss more quickly
tack
A0
A1
1
0
2
1
3
4
5
A1
A1
A1
2
3
2
A2
7
21 February 2011
KU EECS 780 – Comm Nets – E2E Transport
– 52 –
NET-TL-104
KU EECS 780 – Communication Networks – End-to-End Transport
ITTC
© James P.G. Sterbenz
E2E Error Control
Closed Loop Retransmission: Fast Retransmit
• Fast retransmit
0
– optimisation for go-back-n
• Assume several duplicate ACKs are loss
o even if timer hasn’t yet fired
+ recovers from loss more quickly
tack
A0
A1
1
0
2
1
3
4
5
A1
A1
A1
2
3
2
4
3
A2
A3
8
21 February 2011
KU EECS 780 – Comm Nets – E2E Transport
ITTC
NET-TL-105
© James P.G. Sterbenz
E2E Error Control
Closed Loop Retransmission: Fast Retransmit
• Fast retransmit
0
– optimisation for go-back-n
• Assume several duplicate ACKs are loss
o even if timer hasn’t yet fired
+ recovers from loss more quickly
tack
A0
A1
1
0
2
1
3
4
5
A1
A1
A1
2
3
2
4
3
5
4
A2
A3
A4
9
21 February 2011
KU EECS 780 – Comm Nets – E2E Transport
– 53 –
NET-TL-106
KU EECS 780 – Communication Networks – End-to-End Transport
ITTC
© James P.G. Sterbenz
E2E Error Control
Closed Loop Retransmission: Fast Retransmit
• Fast retransmit
0
– optimisation for go-back-n
• Assume several duplicate ACKs are loss
o even if timer hasn’t yet fired
+ recovers from loss more quickly
tack
A0
A1
1
0
2
1
3
4
5
A1
A1
A1
2
3
2
4
3
5
4
A2
A3
5
6
A4
A5
10
21 February 2011
KU EECS 780 – Comm Nets – E2E Transport
ITTC
NET-TL-107
© James P.G. Sterbenz
E2E Error Control
Closed Loop Retransmission: Fast Retransmit
• Fast retransmit
0
– optimisation for go-back-n
• Assume several duplicate ACKs are loss
o even if timer hasn’t yet fired
+ recovers from loss more quickly
tack
A0
A1
1
0
2
1
3
4
5
A1
A1
A1
2
3
2
4
3
5
4
A2
A3
A4
5
6
6
A5
11
21 February 2011
KU EECS 780 – Comm Nets – E2E Transport
– 54 –
NET-TL-108
KU EECS 780 – Communication Networks – End-to-End Transport
ITTC
© James P.G. Sterbenz
E2E Error Control
Closed Loop Retransmission: Fast Retransmit
• Fast retransmit
0
– optimisation for go-back-n
• Assume several duplicate ACKs are loss
o even if timer hasn’t yet fired
+ recovers from loss more quickly
– still suffers from go-back-n inefficiencies
tack
A0
A1
1
0
2
1
3
4
5
A1
A1
A1
2
3
2
4
3
5
4
A2
A3
5
6
A4
6
A5
12
21 February 2011
KU EECS 780 – Comm Nets – E2E Transport
ITTC
NET-TL-109
© James P.G. Sterbenz
E2E Error Control
Closed Loop Retransmission: Delayed ACK
• Delayed ACK
o optimisation for go-back-n
• Aggregate several ACKs
+ reduces ACK traffic
+ allows some receiver resequencing
• within ACK aggregation quantum
21 February 2011
KU EECS 780 – Comm Nets – E2E Transport
– 55 –
NET-TL-110
KU EECS 780 – Communication Networks – End-to-End Transport
ITTC
© James P.G. Sterbenz
E2E Error Control
Closed Loop Retransmission: Go-Back-n
• Go-back-n
̶
̶
fast retransmit and delayed ACK help slightly
but still significant delay penalty for losses
Alternative?
21 February 2011
KU EECS 780 – Comm Nets – E2E Transport
ITTC
NET-TL-111
© James P.G. Sterbenz
E2E Error Control
Closed Loop Retransmission: Selective Repeat
• Go-back-n
̶
̶
fast retransmit and delayed ACK help slightly
significant delay penalty for losses
• Alternative
− don’t go back: selective repeat
21 February 2011
KU EECS 780 – Comm Nets – E2E Transport
– 56 –
NET-TL-112
KU EECS 780 – Communication Networks – End-to-End Transport
ITTC
© James P.G. Sterbenz
E2E Error Control
Closed Loop Retransmission: Selective Repeat
• Selective repeat
0
o all TPDUs acknowledged
1
21 February 2011
KU EECS 780 – Comm Nets – E2E Transport
ITTC
NET-TL-113
© James P.G. Sterbenz
E2E Error Control
Closed Loop Retransmission: Selective Repeat
• Selective repeat
0
o all TPDUs acknowledged
1
0
A0
2
21 February 2011
KU EECS 780 – Comm Nets – E2E Transport
– 57 –
NET-TL-114
KU EECS 780 – Communication Networks – End-to-End Transport
ITTC
© James P.G. Sterbenz
E2E Error Control
Closed Loop Retransmission: Selective Repeat
• Selective repeat
0
o all TPDUs acknowledged
tack
1
0
2
1
A0
A1
3
21 February 2011
KU EECS 780 – Comm Nets – E2E Transport
ITTC
NET-TL-115
© James P.G. Sterbenz
E2E Error Control
Closed Loop Retransmission: Selective Repeat
• Selective repeat
0
o all TPDUs acknowledged
tack
A0
1
0
2
1
3
A1
4
21 February 2011
KU EECS 780 – Comm Nets – E2E Transport
– 58 –
NET-TL-116
KU EECS 780 – Communication Networks – End-to-End Transport
ITTC
© James P.G. Sterbenz
E2E Error Control
Closed Loop Retransmission: Selective Repeat
• Selective repeat
0
o all TPDUs acknowledged
– Missequenced TPDUs
o acknowledged and held at receiver
tack
A0
A1
1
0
2
1
3
3
4
A3
5
21 February 2011
KU EECS 780 – Comm Nets – E2E Transport
ITTC
NET-TL-117
© James P.G. Sterbenz
E2E Error Control
Closed Loop Retransmission: Selective Repeat
• Selective repeat
0
o all TPDUs acknowledged
• Missequenced TPDUs
o TPDUs held and reordered at receiver
– increases receiver complexity
tack
A0
A1
1
0
2
1
3
3
4
5
43
A3
A4
6
21 February 2011
KU EECS 780 – Comm Nets – E2E Transport
– 59 –
NET-TL-118
KU EECS 780 – Communication Networks – End-to-End Transport
ITTC
© James P.G. Sterbenz
E2E Error Control
Closed Loop Retransmission: Selective Repeat
• Selective repeat
0
o all TPDUs acknowledged
• Missequenced TPDUs
o TPDUs held and reordered at receiver
– increases receiver complexity
• Lost TPDUs
o selectively retransmitted
tack
A0
A1
1
0
2
1
3
3
4
5
A3
A4
43
543
2
A5
7
21 February 2011
KU EECS 780 – Comm Nets – E2E Transport
ITTC
NET-TL-119
© James P.G. Sterbenz
E2E Error Control
Closed Loop Retransmission: Selective Repeat
• Selective repeat
0
o all TPDUs acknowledged
• Missequenced TPDUs
o TPDUs held and reordered at receiver
– increases receiver complexity
• Lost TPDUs
o selectively retransmitted
+ no go-back-n latency penalty
– requires more receiver buffer space
tack
A0
A1
1
0
2
1
3
3
4
5
A3
A4
A5
43
543
2
6
5432
A2
8
21 February 2011
KU EECS 780 – Comm Nets – E2E Transport
– 60 –
NET-TL-120
KU EECS 780 – Communication Networks – End-to-End Transport
ITTC
© James P.G. Sterbenz
E2E Error Control
Closed Loop Retransmission: Selective Repeat
• Selective repeat
0
o all TPDUs acknowledged
• Missequenced TPDUs
o TPDUs held and reordered at receiver
– increases receiver complexity
• Lost TPDUs
o selectively retransmitted
+ no go-back-n latency penalty
– requires more receiver buffer space
tack
A0
A1
1
0
2
1
3
3
4
5
A3
A4
A5
43
543
2
6
5432
7
6
A2
A6
9
21 February 2011
KU EECS 780 – Comm Nets – E2E Transport
ITTC
NET-TL-121
© James P.G. Sterbenz
E2E Error Control
Closed Loop Retransmission: Selective Repeat
• Selective repeat
0
o all TPDUs acknowledged
• Missequenced TPDUs
o TPDUs held and reordered at receiver
– increases receiver complexity
• Lost TPDUs
o selectively retransmitted
+ no go-back-n latency penalty
– requires more receiver buffer space
tack
A0
A1
1
0
2
1
3
3
4
5
A3
A4
A5
43
543
2
6
5432
7
6
8
7
A2
A6
A7
10
21 February 2011
KU EECS 780 – Comm Nets – E2E Transport
– 61 –
NET-TL-122
KU EECS 780 – Communication Networks – End-to-End Transport
ITTC
© James P.G. Sterbenz
E2E Error Control
Closed Loop Retransmission: Selective Repeat
• Selective repeat
0
o all TPDUs acknowledged
• Missequenced TPDUs
o TPDUs held and reordered at receiver
– increases receiver complexity
• Lost TPDUs
o selectively retransmitted
+ no go-back-n latency penalty
– requires more receiver buffer space
• A2A Delay and bandwidth reduced
tack
1
0
2
1
3
A0
3
A1
4
5
43
A3
543
2
A4
A5
6
5432
7
6
8
7
A2
8
A6
9
A7
A8
11
21 February 2011
KU EECS 780 – Comm Nets – E2E Transport
NET-TL-123
ITTC
© James P.G. Sterbenz
E2E Error Control
Closed Loop Retransmission: Periodic State
• Selective ACK blocks
0
o bit vectors can aggregate ACKs
+ significant reduction in control packets
+ simple receiver implementation possible
~1.5tRTT
1
0
2
1
3
3
4
A01_3
5
43
6
543
7
6543
765543
2
A4567
A2
21 February 2011
KU EECS 780 – Comm Nets – E2E Transport
– 62 –
8
7–2
9
8
9
NET-TL-124
KU EECS 780 – Communication Networks – End-to-End Transport
ITTC
© James P.G. Sterbenz
E2E Error Control
Impact of Increasing Data Rate
• Bandwidth-×-delay product increases
– fixed duration error event larger relative impact
– reaction to errors decreases in terms of number of bits sent
• Sequence numbers
– sequence numbers wrap if sequence space too small
• causes packet misinsertion
21 February 2011
KU EECS 780 – Comm Nets – E2E Transport
NET-TL-125
ITTC
© James P.G. Sterbenz
E2E Error Control
Closed Loop Retransmission: Comparison
0
0
0
tack
A0
A0
tack
A1
1
0
2
1
3
tack
A0
A1
4
5
1
A2
1
A3
A4
A1
21 February 2011
A5
0
2
1
2
A4
4
3
A5
5
4
3
5
6
0
2
1
3
3
4
4
43
A01_3
543
2
5
43
6
543
7
6543
76543
6
7
6
2
8
7
8
7–2
8 A4567
9
8
A2
A7
1
3
A6
6
~1.5tRTT
3
5
2
A1
1
A3
A1
A1
0
0
1
9
A2
9
A8
KU EECS 780 – Comm Nets – E2E Transport
– 63 –
NET-TL-126
KU EECS 780 – Communication Networks – End-to-End Transport
ITTC
© James P.G. Sterbenz
E2E Error Control
Open Loop
• Open loop error control
o some applications do not need guaranteed reliability
examples?
21 February 2011
KU EECS 780 – Comm Nets – E2E Transport
ITTC
NET-TL-127
© James P.G. Sterbenz
E2E Error Control
Open Loop
• Open loop error control
o some applications do not need guaranteed reliability
• applications that are tolerant to some loss
• real-time or interactive delay requirements
+ eliminates control loop latency for recovery
–
–
Mechanisms?
21 February 2011
KU EECS 780 – Comm Nets – E2E Transport
– 64 –
NET-TL-128
KU EECS 780 – Communication Networks – End-to-End Transport
ITTC
© James P.G. Sterbenz
E2E Error Control
Open Loop
• Open loop error control
o some applications do not need guaranteed reliability
• applications that are tolerant to some loss
• real-time or interactive delay requirements
+ eliminates control loop latency for recovery
–
–
• Forward error correction (FEC)
– block codes: per block recovery
– convolutional codes: continuous over window
– erasure codes: coding over redundant packets
disadvantages?
21 February 2011
KU EECS 780 – Comm Nets – E2E Transport
ITTC
NET-TL-129
© James P.G. Sterbenz
E2E Error Control
Open Loop
• Open loop error control
o some applications do not need guaranteed reliability
• applications that are tolerant to some loss
• real-time or interactive delay requirements
+ eliminates control loop latency for recovery
– requires additional end-systems bandwidth & processing
– requires additional network bandwidth
• Forward error correction (FEC)
– block codes: per block recovery
– convolutional codes: continuous over window
– erasure codes: coding over redundant packets
21 February 2011
KU EECS 780 – Comm Nets – E2E Transport
– 65 –
NET-TL-130
KU EECS 780 – Communication Networks – End-to-End Transport
ITTC
© James P.G. Sterbenz
E2E Error Control
Hybrid Open/Closed-Loop Control
• Hybrid open loop with closed loop when necessary
why?
21 February 2011
KU EECS 780 – Comm Nets – E2E Transport
ITTC
NET-TL-131
© James P.G. Sterbenz
E2E Error Control
Hybrid Open/Closed-Loop Control
•
•
•
•
Hybrid open loop with closed loop when necessary
Statistical error bound with FEC
Retransmission only when FEC doesn’t correct
Appropriate for
– high latency and bandwidth-×-delay paths
– asymmetric bandwidth paths
– intermittent and episodically connected channels
21 February 2011
KU EECS 780 – Comm Nets – E2E Transport
– 66 –
NET-TL-132
KU EECS 780 – Communication Networks – End-to-End Transport
ITTC
© James P.G. Sterbenz
E2E Functions and Mechanisms
TL.2.4 Transmission Control
TL.1 Transport services and interfaces
TL.2 End-to-end functions and mechanisms
TL.2.1
TL.2.2
TL.2.3
TL.2.4
Framing and multiplexing
State management and transfer modes
Reliability and error control
Transmission control
TL.3 Internet transport protocols
TL.4 Multipoint communication and reliable multicast
21 February 2011
KU EECS 780 – Comm Nets – E2E Transport
ITTC
NET-TL-133
© James P.G. Sterbenz
E2E Transmission Control
Definitions: Flow Control
• Flow control
– control transmission to avoid overwhelming receiver
– end-to-end control
21 February 2011
KU EECS 780 – Comm Nets – E2E Transport
– 67 –
NET-TL-134
KU EECS 780 – Communication Networks – End-to-End Transport
ITTC
© James P.G. Sterbenz
E2E Transmission Control
Definitions: Congestion Control
• Flow control
– control transmission to avoid overwhelming receiver
– end-to-end control
• Congestion control
– control transmission to avoid overwhelming network paths
21 February 2011
KU EECS 780 – Comm Nets – E2E Transport
ITTC
NET-TL-135
© James P.G. Sterbenz
E2E Transmission Control
Definitions: Implicit vs. Explicit
• Flow control
– control transmission to avoid overwhelming receiver
– end-to-end control
• Congestion control
– control transmission to avoid overwhelming network paths
– network control with end-to-end assistance (throttling)
• Types
– explicit relies on congestion information from nodes
• allows decoupling of error, flow, and congestion mechanisms
– implicit assumes loss is congestion
• bad assumption in wireless networks
21 February 2011
(see [Krishnan 2004])
KU EECS 780 – Comm Nets – E2E Transport
– 68 –
NET-TL-136
KU EECS 780 – Communication Networks – End-to-End Transport
ITTC
© James P.G. Sterbenz
E2E Transmission Control
Impact of Increasing Data Rate
• Bandwidth-×-delay product increases
– response to an event happens after more bits transferred
– it may be too late to react
• all bits causing problem may already be transmitted
• cause of problem may have already gone away
Alternative?
21 February 2011
KU EECS 780 – Comm Nets – E2E Transport
ITTC
NET-TL-137
© James P.G. Sterbenz
E2E Transmission Control
Open-Loop Rate Control
admission
control
• Initial negotiation
– admission control limits traffic to available resources
21 February 2011
KU EECS 780 – Comm Nets – E2E Transport
– 69 –
NET-TL-138
KU EECS 780 – Communication Networks – End-to-End Transport
ITTC
© James P.G. Sterbenz
E2E Transmission Control
Open-Loop Rate Control
admission
control
receiver
negotiation
• Initial negotiation
– admission control limits traffic to available resources
– receiver negotiates what it can accept (flow control)
21 February 2011
KU EECS 780 – Comm Nets – E2E Transport
ITTC
NET-TL-139
© James P.G. Sterbenz
E2E Transmission Control
Open-Loop Rate Control
admission
control
rate
scheduling
rate
policing
receiver
negotiation
conforming traffic
• Initial negotiation
– admission control limits traffic to available resources
– receiver negotiates what it can accept (flow control)
• Steady state
– policing enforces traffic contract from transmitter
21 February 2011
KU EECS 780 – Comm Nets – E2E Transport
– 70 –
NET-TL-140
KU EECS 780 – Communication Networks – End-to-End Transport
ITTC
© James P.G. Sterbenz
E2E Transmission Control
Open-Loop Rate Control
admission
control
rate
scheduling
rate
policing
receiver
negotiation
conforming traffic
excess traffic
• Initial negotiation
– admission control limits traffic to available resources
– receiver negotiates what it can accept (flow control)
• Steady state
– policing enforces traffic contract from transmitter
• excess traffic may be marked and passed if capacity available
21 February 2011
KU EECS 780 – Comm Nets – E2E Transport
ITTC
NET-TL-141
© James P.G. Sterbenz
E2E Transmission Control
Open-Loop Rate Control Parameters
rp
uniform
ra
bursty
time
• Main parameters
– peak rate rp
– average rate ra
– burstiness (peak to average ratio or max burst size)
• Derived parameters
– jitter
21 February 2011
KU EECS 780 – Comm Nets – E2E Transport
– 71 –
NET-TL-142
KU EECS 780 – Communication Networks – End-to-End Transport
ITTC
© James P.G. Sterbenz
E2E Transmission Control
Open-Loop Rate Control: Connections
• Requires connection establishment
(dis)advantages?
21 February 2011
KU EECS 780 – Comm Nets – E2E Transport
ITTC
NET-TL-143
© James P.G. Sterbenz
E2E Transmission Control
Open-Loop Rate Control: Connections
• Requires connection establishment
– overhead and delay for connection setup
• optimistic establishment or fast reservations ameliorate
+ QOS guarantees possible in steady state
+ feedback control loops not needed during transmission
+ network stability less dependent on congestion control
• unless resources significantly overbooked
– some connections may not be admitted
lecture TQ
21 February 2011
KU EECS 780 – Comm Nets – E2E Transport
– 72 –
NET-TL-144
KU EECS 780 – Communication Networks – End-to-End Transport
ITTC
© James P.G. Sterbenz
E2E Transmission Control
Closed-Loop Flow and Congestion Control
congestion
control
flow
control
network
packet
scheduling
• Flow control
– sender–receiver
• Congestion control
– sender–network
• Packet scheduling Lecture TQ
21 February 2011
KU EECS 780 – Comm Nets – E2E Transport
ITTC
NET-TL-145
© James P.G. Sterbenz
E2E Transmission Control
Closed-Loop Flow Control
• Feedback from receiver to limit rate
• Window to limit amount of unacknowledged data
– static window
• based on initial negotiation or assumption
– dynamic window
• renegotiated based on receiver buffer availability
• may be combined with congestion control
21 February 2011
KU EECS 780 – Comm Nets – E2E Transport
– 73 –
NET-TL-146
KU EECS 780 – Communication Networks – End-to-End Transport
ITTC
© James P.G. Sterbenz
Congestion Control
Ideal Network
delay
ideal
delay
carried load
throughput
ideal
offered load
1.0
offered load
• Ideal network:
– throughput: carried load = offered load (45° line)
– zero delay (flat line)
Why isn’t this possible?
21 February 2011
KU EECS 780 – Comm Nets – E2E Transport
ITTC
NET-TL-147
© James P.G. Sterbenz
Congestion Control
Real Network
• Delay can’t be zero: speed-of-light
– delay through network channels
– delay along paths in network nodes
• Throughput can’t be infinite
– channel capacity limits bandwidth
– switching rate of components limits bit rate
21 February 2011
KU EECS 780 – Comm Nets – E2E Transport
– 74 –
NET-TL-148
KU EECS 780 – Communication Networks – End-to-End Transport
ITTC
© James P.G. Sterbenz
Congestion Control
Desired Real Network Behaviour
throughput
1.0
delay
ideal
carried load
knee
delay
knee
dmin
offered load
offered load
1.0
1.0
• Desired network:
– carried load = offered load up to share of capacity
what happens to delay?
21 February 2011
KU EECS 780 – Comm Nets – E2E Transport
ITTC
NET-TL-149
© James P.G. Sterbenz
Congestion Control
Causes of Congestion
• Congestion when offered load → link capacity
• Best effort
– occurs whenever load is high
• Probabilistic guarantees
– occurs when load exceeds resource reservations
• Absolute guarantees
– can’t happen (in theory)
21 February 2011
KU EECS 780 – Comm Nets – E2E Transport
– 75 –
NET-TL-150
KU EECS 780 – Communication Networks – End-to-End Transport
ITTC
© James P.G. Sterbenz
Congestion Control
Infinite Buffers / No Retransmission
• Congestion when
offered load → link capacity
• Infinite buffers
ideal
discuss why in lecture TQ
21 February 2011
knee
delay
– queue length
builds to infinity
– d→∞
delay
dmin
offered load
1.0
KU EECS 780 – Comm Nets – E2E Transport
ITTC
NET-TL-151
© James P.G. Sterbenz
Congestion Control
Finite Buffers with Retransmission
• Finite buffers cause packet loss
– retransmissions contribute to offered load
• assuming reliable protocol
– throughput curve levels off
21 February 2011
KU EECS 780 – Comm Nets – E2E Transport
– 76 –
NET-TL-152
KU EECS 780 – Communication Networks – End-to-End Transport
ITTC
© James P.G. Sterbenz
Congestion Control
Multihop Network
• Multiple hops
– downstream packet loss
– upstream transmission wasted
21 February 2011
KU EECS 780 – Comm Nets – E2E Transport
ITTC
NET-TL-153
© James P.G. Sterbenz
Congestion Control
Consequences of Congestion
• Delay increases
– due to packet queuing in network nodes
– due to retransmissions when packets overflow buffers
• finite buffers must drop packets when full
• Throughput
– levels off gradually (with real traffic)
– then decreases
• due to retransmissions when packets dropped
• particularly over multiple hops
– congestion collapse
• “cliff” of the throughput curve
21 February 2011
KU EECS 780 – Comm Nets – E2E Transport
– 77 –
NET-TL-154
KU EECS 780 – Communication Networks – End-to-End Transport
ITTC
© James P.G. Sterbenz
Congestion Control
Local Action
• Local action at point of congestion
• Drops packets: discard policy
– tail drop simplest: drop packets that overflow buffers
– more intelligent policies possible
• need flow or connection state in switches
• discriminate which flows are causing congestion and penalise
21 February 2011
KU EECS 780 – Comm Nets – E2E Transport
ITTC
NET-TL-155
© James P.G. Sterbenz
Congestion Control
End-to-End Action
• End-to-end action
• Throttle source
– reduce transmission rates
– prevent unnecessary retransmissions
• Types
– explicit
– implicit
21 February 2011
KU EECS 780 – Comm Nets – E2E Transport
– 78 –
NET-TL-156
KU EECS 780 – Communication Networks – End-to-End Transport
ITTC
© James P.G. Sterbenz
Congestion Control
Congestion Avoidance and Control
throughput
1.0
knee
delay
ideal
cliff
cliff
carried load
CC
delay
knee
CA
offered load
CA
ideal
CC
dmin
1.0
offered load
1.0
• Congestion control: operation at the cliff
• Congestion avoidance: operation at the knee
– detect and correct impending congestion before the cliff
21 February 2011
KU EECS 780 – Comm Nets – E2E Transport
ITTC
NET-TL-157
© James P.G. Sterbenz
E2E Transmission Control
Closed-Loop Congestion Control
• Feedback from network to limit rate
• Required unless open loop with hard reservations
• Window to limit amount of unacknowledged data
– dynamic window
– conservation of packets in the network
– self clocking: ACKs determine the transmission of new data
21 February 2011
KU EECS 780 – Comm Nets – E2E Transport
– 79 –
NET-TL-158
KU EECS 780 – Communication Networks – End-to-End Transport
ITTC
© James P.G. Sterbenz
E2E Transmission Control
Closed-Loop Control: Window Size
• Window size critical
0
what happens with
increasing bandwidth?
0
1
1
A0
2
A1
5
3
A2
4
A3
5
A4
6
2
3
4
5
6
A5
slow path
21 February 2011
KU EECS 780 – Comm Nets – E2E Transport
NET-TL-159
ITTC
© James P.G. Sterbenz
E2E Transmission Control
Closed-Loop Control: Window Size
• Window size critical
0
1
2
3
0
– big enough to fill pipe
0
How to determine size?
1
1
A0
2
2
A1
3
5
A2
4
A0
A1
A2
A3
4
5
6
7
3
4
A3
5
A4
A5
A6
A7
5
A4
6
6
A5
slow path
21 February 2011
KU EECS 780 – Comm Nets – E2E Transport
– 80 –
8
9
10
11
A8
A9
A10
A11
0
1
2
3
4
5
6
7
8
9
10
11
12
fast path
NET-TL-160
KU EECS 780 – Communication Networks – End-to-End Transport
ITTC
© James P.G. Sterbenz
E2E Transmission Control
Closed-Loop Control: Initialisation
• Slow start initialisation
0
– increase window until path loaded
• Critical parameters
A0
A0
A1
1
2
tRTT
– initial window size
– rate of increase
1
2
A2
tRTT
A3
A4
A5
A6
A7
A8
A9
A10
A11
A12
A2
A3
A4
A1
Tradeoffs?
21 February 2011
0
0
tRTT
A5
3
4
3
5
4
6
5
6
A6
A7
A8
A9
7
A10
8
7
A11
9
8
A12
10
9
A10
11
10
A13
12
11
A14
13
12
A15
14
13
A16
15
14
A17
1
0
2
1
3
2
3
4
5
4
6
5
7
6
8
7
9
8
10
9
11
10
12
11
13
12
14
13
15
14
16
15
17
16
18
17
19
18
20
19
21
20
21
KU EECS 780 – Comm Nets – E2E Transport
NET-TL-161
ITTC
© James P.G. Sterbenz
E2E Transmission Control
Closed-Loop Control: Initialisation
• Slow start initialisation
0
– increase window until path loaded
• Critical parameters
A0
A0
A1
1
2
tRTT
– initial window size
– rate of increase
1
2
A2
tRTT
A3
– conservative on high bw-×-delay:
• multiple round trips
• never get to full rate for transactions
– aggressive:
A4
A5
A6
A7
A8
A9
A10
A11
• induced congestions
A12
KU EECS 780 – Comm Nets – E2E Transport
– 81 –
A2
A3
A4
A1
• Tradeoffs
21 February 2011
0
0
tRTT
A5
3
4
3
5
4
6
5
6
A6
A7
A8
A9
A10
7
8
7
A11
9
8
A12
10
9
A10
11
10
A13
12
11
A14
13
12
A15
14
13
A16
15
14
A17
1
0
2
1
3
2
3
4
5
4
6
5
7
6
8
7
9
8
10
9
11
10
12
11
13
12
14
13
15
14
16
15
17
16
18
17
19
18
20
19
21
20
21
NET-TL-162
KU EECS 780 – Communication Networks – End-to-End Transport
ITTC
© James P.G. Sterbenz
E2E Congestion Control
Closed-Loop Control: Steady State
additive
increase
congestion detection
rate
multiplicative
decrease
time
• AIMD steady state
– additive-increase slowly increases rate
• increment window
– multiplicative-decrease quickly throttles with congestion
• divide window when packet lost
21 February 2011
KU EECS 780 – Comm Nets – E2E Transport
NET-TL-163
ITTC
© James P.G. Sterbenz
E2E Congestion Control
AIMD Fairness and Stability
• AIMD
• until loss beyond R
– MD: both decrease
• half way to origin
• halve window size
equal
bandwidth
share
R
Flow 1 throughput
– R = available bandwidth
– initial bandwidth share I
– AI: both increase
ideal
– trajectory toward ideal
I
• intersection of R and equal
Flow 2 throughput
R
[based on Kurose fig. 3.53]
21 February 2011
KU EECS 780 – Comm Nets – E2E Transport
– 82 –
NET-TL-164
KU EECS 780 – Communication Networks – End-to-End Transport
ITTC
© James P.G. Sterbenz
E2E Congestion Control
Closed-Loop Control
initialisation
steady state phase
congestion detection
sending rate
AI
slow
start
MD
time
• Initialisation phase: slow start
• Steady-state phase: AIMD
21 February 2011
KU EECS 780 – Comm Nets – E2E Transport
ITTC
NET-TL-165
© James P.G. Sterbenz
E2E Congestion Control
Closed-Loop Implicit Control
• Implicit control
– missing ACK assumed to be congestion
good assumption?
21 February 2011
KU EECS 780 – Comm Nets – E2E Transport
– 83 –
NET-TL-166
KU EECS 780 – Communication Networks – End-to-End Transport
ITTC
© James P.G. Sterbenz
E2E Congestion Control
Closed-Loop Implicit Control
• Implicit control
– missing ACK assumed to be congestion
– reasonable when all losses are due to congestion
• fiber optic channels connected by reliable switches
21 February 2011
KU EECS 780 – Comm Nets – E2E Transport
ITTC
NET-TL-167
© James P.G. Sterbenz
E2E Congestion Control
Closed-Loop Implicit Control
• Implicit control
– missing ACK assumed to be congestion
– reasonable when all losses are due to congestion
• fiber optic channels connected by reliable switches
– performs poorly when significant losses in channel
why?
21 February 2011
KU EECS 780 – Comm Nets – E2E Transport
– 84 –
NET-TL-168
KU EECS 780 – Communication Networks – End-to-End Transport
ITTC
© James P.G. Sterbenz
E2E Congestion Control
Closed-Loop Implicit Control
• Implicit control
– missing ACK assumed to be congestion
– reasonable when all losses are due to congestion
• fiber optic channels connected by reliable switches
– performs poorly when significant losses in channel
• mobile wireless links
• under-provisioned CDMA (including optical CDMA)
21 February 2011
KU EECS 780 – Comm Nets – E2E Transport
ITTC
NET-TL-169
© James P.G. Sterbenz
E2E Congestion Control
Closed-Loop Implicit Control
• Implicit control
– missing ACK assumed to be congestion
– reasonable when all losses are due to congestion
• fiber optic channels connected by reliable switches
– performs poorly when significant losses in channel
• mobile wireless links
• under-provisioned CDMA (including optical CDMA)
Alternatives?
21 February 2011
KU EECS 780 – Comm Nets – E2E Transport
– 85 –
NET-TL-170
KU EECS 780 – Communication Networks – End-to-End Transport
ITTC
© James P.G. Sterbenz
E2E Congestion Control
Closed-Loop Explicit Control
• Explicit control
– explicit congestion notification (ECN)
• throttle with ECN message
– some decoupling of error and congestion control
• throttle before packet loss
• not sufficient for lossy wireless link
21 February 2011
KU EECS 780 – Comm Nets – E2E Transport
ITTC
NET-TL-171
© James P.G. Sterbenz
E2E Congestion Control
Closed-Loop Explicit Control
• Explicit control
– explicit congestion notification (ECN)
• throttle with ECN message
– some decoupling of error and congestion control
• throttle before packet loss
• not sufficient for lossy wireless link
– not sufficient for discrimination of corrupted packets
• ELN (explicit loss notification) necessary
more in lecture TQ
21 February 2011
KU EECS 780 – Comm Nets – E2E Transport
– 86 –
NET-TL-172
KU EECS 780 – Communication Networks – End-to-End Transport
ITTC
© James P.G. Sterbenz
E2E Transmission Control
Closed-Loop Control: Steady State
• Implicit control
– standard
– with fast retransmit
• Explicit control
A0
A1
A2
A3
A4
A5
– ECN
A6
A7
tack
A7
A7
A7
A7
A7
A7
A7
A7
A8
A9
implicit
fast retransmit
0
0
0
1
0
1
0
1
0
2
1
2
1
2
1
3
2
3
2
3
2
3
4
5
4
6
5
7
6
8
7
9
A0
A1
A2
A3
A4
A5
A6
10
A71
3
4
5
4
6
5
7
6
8
7
9
10
11
11
12
12
A72
13
A73
14
15
A7
16
A7
8
A7
9
8
10
9
11
10
12
11
A8
A9
A10
A11
A0
4
A2
A3
A4
A5
ECN
A6
A9
13
A10
A11
8
A12
9
8
10
9
11
10
12
11
13
12
14
12
5
4
6
5
7
6
8
7
9
A8
A13
A14
A15
A16
A17
A18
13
KU EECS 780 – Comm Nets – E2E Transport
ITTC
3
A1
A7
14
12
21 February 2011
explicit
8
10
9
11
10
12
11
13
12
14
13
15
14
16
15
17
16
18
17
19
18
20
19
21
20
21
NET-TL-173
© James P.G. Sterbenz
E2E Transmission Control
Hybrid Control
• Dynamic rate control
– open-loop rate control modified by network feedback
• example: ATM ABR
• Pacing to reduce burstiness
– sender base rate control augments closed-loop control
– window transmission spread over RTT
– options
• pace initial window, allow ACK self clocking to take over
• periodic repacing to compensate for ACK compression
• continuous pacing
21 February 2011
KU EECS 780 – Comm Nets – E2E Transport
– 87 –
NET-TL-174
KU EECS 780 – Communication Networks – End-to-End Transport
ITTC
© James P.G. Sterbenz
Transport Layer
TL.3 Internet Transport Protocols
TL.1 Transport Services and interfaces
TL.2 End-to-end functions and mechanisms
TL.3 Internet transport protocols
TL.3.1 UDP
TL.3.2 RTP introduction
TL.3.3 TCP
TL.4 Multipoint communication and reliable multicast
21 February 2011
KU EECS 780 – Comm Nets – E2E Transport
ITTC
NET-TL-175
© James P.G. Sterbenz
Internet Transport Protocols
History
• ARPANET / Internet transport protocol history
–
–
–
–
–
NCP (network control program) original ARPANET protocol
replaced with TCP in 1977
TCP split from IP in 1978
UDP added in 1980
RTP RFC published 1996
21 February 2011
KU EECS 780 – Comm Nets – E2E Transport
– 88 –
NET-TL-176
KU EECS 780 – Communication Networks – End-to-End Transport
ITTC
© James P.G. Sterbenz
Internet Transport Protocols
Overview
• UDP: user datagram protocol [RFC 0768 / STD 0006]
– basic end-to-end multiplexing and error checking
– no error, flow, or congestion control
• RTP: real-time protocol [RFC 3550 / STD 0064]
– support for end-to-end real-time synchronisation
– typical implementations run over UDP
• TCP: transmission control protocol [RFC 0793 / STD 0007]
– connection-oriented reliable byte-stream protocol
– full error, flow, and congestion control
21 February 2011
KU EECS 780 – Comm Nets – E2E Transport
ITTC
NET-TL-177
© James P.G. Sterbenz
Internet Transport Protocols
Important Examples
Protocol
Name
Function
Status
Ref
TCP
transmission control
protocol
reliable data transfer with
congestion control
standard
RFC 0793
STD 0007
UDP
user datagram
protocol
socket access to unreliable
IP datagrams
standard
RFC 0768
STD 0006
RTP
real-time protocol
real-time synchronisation
(typically over UDP)
standards
track
RFC 3550
STD 0064
T/TCP
TCP for transactions
low connection setup
overhead for transactions
experimental
RFC 1644
RDP
reliable data protocol
reliable data transfer with
no congestion control
experimental
RFC 0908
SCTP
stream control
transmission protocol
signalling
proposed for wireless
proposed
standard
RFC 2960
21 February 2011
KU EECS 780 – Comm Nets – E2E Transport
– 89 –
NET-TL-178
KU EECS 780 – Communication Networks – End-to-End Transport
ITTC
© James P.G. Sterbenz
Internet Transport Protocols
TL.3.1 UDP
TL.1 Transport services and interfaces
TL.2 End-to-end functions and mechanisms
TL.3 Internet transport protocols
TL.3.1 UDP
TL.3.2 RTP introduction
TL.3.3 TCP
TL.4 Multipoint communication and reliable multicast
21 February 2011
KU EECS 780 – Comm Nets – E2E Transport
ITTC
NET-TL-179
© James P.G. Sterbenz
User Datagram Protocol
Overview and Transfer Mode
• UDP: user datagram protocol [RFC 0768 / STD 0006]
• Basic access to Internet datagram transfer mode
– no connection establishment
• each UDP segment handled independently
• no connection setup penalty
• no connection state to maintain
– basic end-to-end multiplexing
– no reliability
– no flow or congestion control
21 February 2011
KU EECS 780 – Comm Nets – E2E Transport
– 90 –
NET-TL-180
KU EECS 780 – Communication Networks – End-to-End Transport
ITTC
© James P.G. Sterbenz
User Datagram Protocol
Segment Format and Multiplexing
• Relatively small header
– source and destination port
– length [B] including header
– checksum
source port#
length
destination port #
checksum
• Multiplexing: UDP socket
– dest (IP addr, port#)
• Demux
– receiver passes to port#
• source addr, port irrelevant
application payload
(= length – 8B)
– negotiated or well-known
– may use source port to reply
21 February 2011
KU EECS 780 – Comm Nets – E2E Transport
ITTC
NET-TL-181
© James P.G. Sterbenz
User Datagram Protocol
Multiplexing
app j
app i
TCP
port n
pd
TCP
TCP
port x
TCP
port y
port demux
TCP
UDP
port z
pd
UDP
06
17
transport demux (IP protocol id)
network demux (IP address)
• Interface to IP: protocol mux/demux (UDP=17)
• Interface to application: port mux/demux
21 February 2011
KU EECS 780 – Comm Nets – E2E Transport
– 91 –
NET-TL-182
KU EECS 780 – Communication Networks – End-to-End Transport
ITTC
© James P.G. Sterbenz
User Datagram Protocol
Error Detection
• Recall E2E arguments: error check must be done E2E
• Error checking: checksum
– sequence of 16-bit integers
– binary addition
source port#
destination port #
length
checksum
• carry overflows wrapped;
• 1’s complement of sum
1110011001100110
+1101010101010101
application payload
(= length – 8B)
21 February 2011
KU EECS 780 – Comm Nets – E2E Transport
ITTC
NET-TL-183
© James P.G. Sterbenz
User Datagram Protocol
Error Detection
• Recall E2E arguments: error check must be done E2E
• Error checking: checksum
– sequence of 16-bit integers
– binary addition
source port#
destination port #
length
checksum
• carry overflows wrapped;
• 1’s complement of sum
1110011001100110
+1101010101010101
11011101110111011
application payload
(= length – 8B)
21 February 2011
KU EECS 780 – Comm Nets – E2E Transport
– 92 –
NET-TL-184
KU EECS 780 – Communication Networks – End-to-End Transport
ITTC
© James P.G. Sterbenz
User Datagram Protocol
Error Detection
• Recall E2E arguments: error check must be done E2E
• Error checking: checksum
– sequence of 16-bit integers
– binary addition
source port#
destination port #
length
checksum
• carry overflows wrapped;
• 1’s complement of sum
1110011001100110
+1101010101010101
11011101110111011
1011101110111100
21 February 2011
application payload
(= length – 8B)
KU EECS 780 – Comm Nets – E2E Transport
ITTC
NET-TL-185
© James P.G. Sterbenz
User Datagram Protocol
Error Detection
• Recall E2E arguments: error check must be done E2E
• Error checking: checksum
– sequence of 16-bit integers
– binary addition
source port#
destination port #
length
checksum
• carry overflows wrapped;
• 1’s complement of sum
1110011001100110
+1101010101010101
11011101110111011
1011101110111100
0100010001000011
21 February 2011
application payload
(= length – 8B)
KU EECS 780 – Comm Nets – E2E Transport
– 93 –
NET-TL-186
KU EECS 780 – Communication Networks – End-to-End Transport
ITTC
© James P.G. Sterbenz
User Datagram Protocol
Error Detection
• Recall E2E arguments: error check must be done E2E
• Error checking: checksum
– sequence of 16-bit integers
– binary addition
source port#
destination port #
length
checksum
• carry overflows wrapped;
• 1’s complement of sum
1110011001100110
+1101010101010101
11011101110111011
1011101110111100
0100010001000011
– sender computes+inserts
– receiver compute+compares
– weak protection [RFC 3385]
application payload
(= length – 8B)
• No retransmission at L4
21 February 2011
KU EECS 780 – Comm Nets – E2E Transport
ITTC
NET-TL-187
© James P.G. Sterbenz
User Datagram Protocol
Flow Control and Congestion Control
• No flow control
– sender blasts; may overwhelm receiver
• No congestion control
– sender may congest network
– no mechanism for sender to back off
21 February 2011
KU EECS 780 – Comm Nets – E2E Transport
– 94 –
NET-TL-188
KU EECS 780 – Communication Networks – End-to-End Transport
ITTC
© James P.G. Sterbenz
User Datagram Protocol
Typical Applications
• Typical application: multimedia streaming
why?
21 February 2011
KU EECS 780 – Comm Nets – E2E Transport
ITTC
NET-TL-189
© James P.G. Sterbenz
User Datagram Protocol
Typical Applications
• Typical application: multimedia streaming
– loss tolerant
– rate sensitive (do not adapt well to TCP congestion control)
– research community considering alternatives
21 February 2011
KU EECS 780 – Comm Nets – E2E Transport
– 95 –
NET-TL-190
KU EECS 780 – Communication Networks – End-to-End Transport
ITTC
© James P.G. Sterbenz
User Datagram Protocol
Typical Applications
• Typical application: multimedia streaming
– loss tolerant
– rate sensitive (do not adapt well to TCP congestion control)
– research community considering alternatives
• Other applications: network control protocols
– e.g. DNS
21 February 2011
KU EECS 780 – Comm Nets – E2E Transport
ITTC
NET-TL-191
© James P.G. Sterbenz
Internet Transport Protocols
TL.3.2 RTP Introduction
TL.1 Transport services and interfaces
TL.2 End-to-end functions and mechanisms
TL.3 Internet transport protocols
TL.3.1 UDP
TL.3.2 RTP introduction
TL.3.3 TCP
TL.4 Multipoint communication and reliable multicast
21 February 2011
KU EECS 780 – Comm Nets – E2E Transport
– 96 –
NET-TL-192
KU EECS 780 – Communication Networks – End-to-End Transport
ITTC
© James P.G. Sterbenz
Real-Time Protocol
Overview and Transfer Mode
• RTP: real-time protocol [RFC 3550 / STD 0064]
• Streaming of data with real-time properties
– uses UDP for basic transport
•
•
•
•
no connection establishment
basic end-to-end multiplexing
no reliability
no flow or congestion control
– adds real-time support fields
• sequence number
• timestamp
• source identifiers
More in Lecture MS
21 February 2011
KU EECS 780 – Comm Nets – E2E Transport
ITTC
NET-TL-193
© James P.G. Sterbenz
Real-Time Protocol
Segment Format
• Encapsulated in UDP
• RTP header
–
–
–
–
–
–
–
version = 02
P: padding bytes at end
X: extension header
CC: CSRC count (4b)
PT: payload type (7b)
sequence # (16b)
timestamp (32b)
source port#
length
02 P X CC
checksum
PT
sequence #
timestamp
SSRC: synchronisation source id
CSRC list: contributing source ids
...
• resolution app dependent
– source identifiers
• SSRC
• CSRC (mixed in)
21 February 2011
destination port #
application payload
optional padding
KU EECS 780 – Comm Nets – E2E Transport
– 97 –
#B pad
NET-TL-194
KU EECS 780 – Communication Networks – End-to-End Transport
ITTC
© James P.G. Sterbenz
Real-Time Protocol
RTP Payloads
• PT: payload type
– [www.iana.org/assignments/rtp-parameters]
• Payload formats and encodings
– specified in various RFCs
– audio: RFC 3551, etc.
– video: RFC 2250, etc.
21 February 2011
KU EECS 780 – Comm Nets – E2E Transport
ITTC
NET-TL-195
© James P.G. Sterbenz
Real-Time Protocol
Control Protocol Overview
• RTCP: real-time control protocol [RFC 3550 / STD 0064]
– monitoring quality of service
– convey participant status information
21 February 2011
KU EECS 780 – Comm Nets – E2E Transport
– 98 –
NET-TL-196
KU EECS 780 – Communication Networks – End-to-End Transport
ITTC
© James P.G. Sterbenz
Internet Transport Protocols
TL.3.3 TCP
TL.1 Transport services and interfaces
TL.2 end-to-end functions and mechanisms
TL.3 Internet transport protocols
TL.3.1 UDP
TL.3.2 RTP introduction
TL.3.3 TCP
TL.4 Multipoint communication and reliable multicast
21 February 2011
KU EECS 780 – Comm Nets – E2E Transport
ITTC
NET-TL-197
© James P.G. Sterbenz
Transmission Control Protocol
Overview
• TCP: transmission control protocol
RFC 0793 / STD 0007
+
+
+
+
+
RFC
RFC
RFC
RFC
RFC
1122
1323
2018
2581
3168
implementation requirements
high performance extensions
SACK (selective acknowledgements)
congestion control
ECN (explicit congestion notification)
• IANA defines name/number space for some fields
–
–
–
–
Internet Assigned Numbers Authority:
protocol types for IP (TCP = 06)
option kinds
well known port numbers
21 February 2011
www.iana.org/numbers.html
KU EECS 780 – Comm Nets – E2E Transport
– 99 –
NET-TL-198
KU EECS 780 – Communication Networks – End-to-End Transport
ITTC
© James P.G. Sterbenz
Transmission Control Protocol
Transfer Mode and Characteristics
• Connection-oriented transfer mode
– latency of connection setup
– connection state must be maintained on each end system
• Point-to-point full-duplex
– reliable byte stream: no message boundaries
– pipelined transfer (not just stop-and-wait)
• Flow control
– will not overwhelm receiver
• Congestion control
– attempt to avoid congesting network
– implicit and optional ECN
21 February 2011
KU EECS 780 – Comm Nets – E2E Transport
NET-TL-199
ITTC
© James P.G. Sterbenz
Transmission Control Protocol
Segment Format: Overview1
• Relatively large header
32 bits
• Variable length payload
• Options
[options (variable length)]
source port #
dest port #
– fixed length & position fields
sequence number
– variable length options
ack number
– header length4b in Bytes
HL HL
flags receive window
• = 40 + |options| B
checksum urg data pointer
– may not be present
(details later)
• Checksum on entire segment
– same algorithm as UDP
21 February 2011
application
payload
(variable length)
KU EECS 780 – Comm Nets – E2E Transport
– 100 –
NET-TL-200
KU EECS 780 – Communication Networks – End-to-End Transport
ITTC
© James P.G. Sterbenz
Transmission Control Protocol
Segment Format: Overview2
C
W
R
E
C
E
U
R
G
A
C
K
P
S
H
R
S
T
S
Y
N
F
I
N
32 bits
• Control flags (1 bit each)
–
–
–
–
–
–
–
–
CWR
cong. win. reduced
ECE
ECN echo
URG
urgent data
ACK
acknowledgement
PSH
push data
RST
reset connection
SYN
connection setup
FIN
connection teardown
(details later)
21 February 2011
source port #
dest port #
sequence number
ack number
HL CEUAPRSF receive window
checksum
urg data pointer
options (variable length)
application
payload
(variable length)
KU EECS 780 – Comm Nets – E2E Transport
ITTC
NET-TL-201
© James P.G. Sterbenz
Transmission Control Protocol
Segment Format: No Options
• Header with no options
– 20B long
32 bits
source port #
dest port #
sequence number
ack number
20B 20
flags receive window
checksum
urg data pointer
application
payload
(variable length)
21 February 2011
KU EECS 780 – Comm Nets – E2E Transport
– 101 –
NET-TL-202
KU EECS 780 – Communication Networks – End-to-End Transport
ITTC
© James P.G. Sterbenz
Transmission Control Protocol
Segment Format: No Options Nor Data
• Entire segment
32 bits
source port #
dest port #
sequence number
ack number
20B 20
flags receive window
checksum
urg data pointer
– 20B long
• Example:
– ACKs
– significant fraction
of Internet packets
40B
why?
21 February 2011
KU EECS 780 – Comm Nets – E2E Transport
NET-TL-203
ITTC
© James P.G. Sterbenz
Transmission Control Protocol
Segment Format: Options
• Options
•
32 bits
source port #
dest port #
– standardised extensions
sequence number
– experimental use
ack number
Used for
20B HL
flags receive window
– control: negotiation in SYN
checksum
urg data pointer
– data: alternate processing
• Format (max 40B total)
≤40B
– kind1B (assigned by IANA)
– length1B
– option fields (variable)
21 February 2011
options (variable length)
application
payload
(variable length)
KU EECS 780 – Comm Nets – E2E Transport
– 102 –
NET-TL-204
KU EECS 780 – Communication Networks – End-to-End Transport
ITTC
© James P.G. Sterbenz
Transmission Control Protocol
Selected Options
• Selected TCP options
http://www.iana.org/assignments/tcp‐parameters
00 end of option list
01 no operation (for padding)
02 MSS (max. segment size)
03 window scale factor
04 SACK permitted
05 SACK blocks
08 timestamp
21 February 2011
KU EECS 780 – Comm Nets – E2E Transport
ITTC
NET-TL-205
© James P.G. Sterbenz
Transmission Control Protocol
Segment Format: Multiplexing
• Socket: 5-tuple
– assign source port #
– network: IP address
source port #
dest port #
sequence number
ack number
HL
flags receive window
checksum
urg data pointer
• Receiver demultiplexing
options (variable length)
– 〈sp, sa, dp, da, prot〉
• Sender multiplexing
– network: IP address
– IP: protocol #
• UDP
• TCP
= 17
= 06
– TCP: destination port #
determines receiving app
21 February 2011
application
payload
(variable length)
KU EECS 780 – Comm Nets – E2E Transport
– 103 –
NET-TL-206
KU EECS 780 – Communication Networks – End-to-End Transport
ITTC
© James P.G. Sterbenz
Transmission Control Protocol
Multiplexing
app j
app i
TCP
port n
TCP
port x
pd
TCP
port y
port demux
TCP
TCP
UDP
port z
pd
UDP
06
17
transport demux (IP protocol id)
network demux (IP address)
• Interface to IP: protocol mux/demux (TCP = 06)
• Interface to application: port mux/demux
21 February 2011
KU EECS 780 – Comm Nets – E2E Transport
ITTC
NET-TL-207
© James P.G. Sterbenz
Transmission Control Protocol
Connection Management: Segment Format
• Flags define segment type
– ACK segment
• ACK for SYN or FIN
• SYNACK may be
piggybacked
• ACK for data
source port #
dest port #
sequence number
ACK number
CEUAPRSF receive window
HL
checksum
urg data pointer
options (variable length)
– RST (reset) segment
• e.g. bad port received
– SYN (synchronise) segment
• connection setup
– FIN (finish) segment
application
payload
(variable length)
• connection release
21 February 2011
KU EECS 780 – Comm Nets – E2E Transport
– 104 –
NET-TL-208
KU EECS 780 – Communication Networks – End-to-End Transport
ITTC
© James P.G. Sterbenz
Transmission Control Protocol
Connection Management: Setup
•
C
Three way handshake
– “client” and “server”
1. SYN (init seq#) →
•
SYN (ISNs)
buffer
alloc
randomised for security
2. ← SYNACK (init seq#)
•
•
•
S
net
buffer
alloc
SYN(ISNc)ACK
ACK
data segments
randomised for security
after buffer allocation
SYN flood vulnerability
estab.
state
data segments
FIN
ACK
3. ACK →
– buffer allocation
– segment may include data
– client may send more
ACK
FIN
4. server may return data
21 February 2011
KU EECS 780 – Comm Nets – E2E Transport
ITTC
NET-TL-209
© James P.G. Sterbenz
Transmission Control Protocol
Connection Management: Teardown
•
–
–
each independent half-close
may occur simultaneously
–
ACK can’t be piggybacked
•
•
SYN
data segments
Client closes socket
data segments
21 February 2011
FIN
ACK
buffer
free
twait
Server closes socket
1. ← FIN
2. ACK →
S
net
SYNACK
ACK
full close
1. FIN →
2. ← ACK
– timed wait before close
•
C
Two two-way handshakes
FIN
ACK
buffer
free
closed
KU EECS 780 – Comm Nets – E2E Transport
– 105 –
NET-TL-210
KU EECS 780 – Communication Networks – End-to-End Transport
ITTC
© James P.G. Sterbenz
Transmission Control Protocol
RFC 0793 State Machine
+---------+ ---------\
active OPEN
| CLOSED |
\
----------+---------+<---------\
\
create TCB
|
^
\
\ snd SYN
passive OPEN |
|
CLOSE
\
\
------------ |
| ---------\
\
create TCB |
| delete TCB
\
\
V
|
\
\
+---------+
CLOSE
|
\
| LISTEN |
---------- |
|
+---------+
delete TCB |
|
rcv SYN
|
|
SEND
|
|
----------|
|
------|
V
+---------+
snd SYN,ACK /
\
snd SYN
+---------+
|
|<---------------------------------->|
|
|
SYN
|
rcv SYN
|
SYN
|
|
RCVD |<-----------------------------------------------|
SENT |
|
|
snd ACK
|
|
|
|------------------------------------|
|
+---------+
rcv ACK of SYN \
/ rcv SYN,ACK
+---------+
|
-------------|
|
----------|
x
|
|
snd ACK
|
V
V
| CLOSE
+---------+
| ------| ESTAB |
| snd FIN
+---------+
|
CLOSE
|
|
rcv FIN
V
------|
|
------+---------+
snd FIN /
\
snd ACK
+---------+
| FIN
|<---------------------------------->| CLOSE |
| WAIT-1 |-----------------|
WAIT |
+---------+
rcv FIN \
+---------+
| rcv ACK of FIN
------|
CLOSE |
| -------------snd ACK
|
------- |
V
x
V
snd FIN V
+---------+
+---------+
+---------+
|FINWAIT-2|
| CLOSING |
| LAST-ACK|
+---------+
+---------+
+---------+
|
rcv ACK of FIN |
rcv ACK of FIN |
| rcv FIN
-------------- |
Timeout=2MSL -------------- |
| ------x
V
-----------x
V
\ snd ACK
+---------+delete TCB
+---------+
------------------------>|TIME WAIT|------------------>| CLOSED |
+---------+
+---------+
21 February 2011
KU EECS 780 – Comm Nets – E2E Transport
ITTC
NET-TL-211
© James P.G. Sterbenz
Transmission Control Protocol
Actual Connection State Machine
[Sewell] http://www.cl.cam.ac.uk/users/pes20/Netsem
21 February 2011
KU EECS 780 – Comm Nets – E2E Transport
– 106 –
NET-TL-212
KU EECS 780 – Communication Networks – End-to-End Transport
ITTC
© James P.G. Sterbenz
Transmission Control Protocol
Segment Format: Sequence and Window
• Sequence #
– forward data transfer
– 1st byte # in segment
• ACK number
–
–
–
–
reverse acknowledgements
seq # of next byte expected
if ACK flag set
data segment may
piggyback ACK
source port #
dest port #
sequence number
ACK number
CEUAPRSF receive window
HL
checksum
urg data pointer
options (variable length)
application
payload
(variable length)
• Receive window
– # unACKed bytes
21 February 2011
KU EECS 780 – Comm Nets – E2E Transport
NET-TL-213
ITTC
© James P.G. Sterbenz
Transmission Control Protocol
Unidirectional Data Transfer
• Data is sequence of bytes
C
– number by byte #
(not segment #)
net
S
SYN (ISNs)
SYN(ISNc)ACK
ACK
1
21 February 2011
KU EECS 780 – Comm Nets – E2E Transport
– 107 –
NET-TL-214
KU EECS 780 – Communication Networks – End-to-End Transport
ITTC
© James P.G. Sterbenz
Transmission Control Protocol
Unidirectional Data Transfer
• Data is sequence of bytes
C
– number by byte #
(not segment #)
– each segment ≤ MSS B
S
net
SYN (ISNs)
SYN(ISNc)ACK
ACK
data segment (MSS bytes)
SN=?
• Sequence numbers
– byte # in byte stream
of 1st byte in segment
2
21 February 2011
KU EECS 780 – Comm Nets – E2E Transport
NET-TL-215
ITTC
© James P.G. Sterbenz
Transmission Control Protocol
Unidirectional Data Transfer
• Data is sequence of bytes
– number by byte #
(not segment #)
– each segment ≤ MSS B
C
S
net
SYN (ISNs)
SYN(ISNc)ACK
ACK
data segment (MSS bytes)
SN=ISNs
• Sequence numbers
ACK AN=?
– byte # in byte stream
of 1st byte in segment
• ACK numbers
– seq # of next byte expected
3
21 February 2011
KU EECS 780 – Comm Nets – E2E Transport
– 108 –
NET-TL-216
KU EECS 780 – Communication Networks – End-to-End Transport
ITTC
© James P.G. Sterbenz
Transmission Control Protocol
Unidirectional Data Transfer
• Data is sequence of bytes
C
– number by byte #
(not segment #)
– each segment ≤ MSS B
S
net
SYN (ISNs)
SYN(ISNc)ACK
ACK
data segment (MSS bytes)
SN=ISNs
• Sequence numbers
ACK AN=ISNs+MSS
– byte # in byte stream
of 1st byte in segment
data segment (MSS bytes)
SN=?
• ACK numbers
– seq # of next byte expected
4
21 February 2011
KU EECS 780 – Comm Nets – E2E Transport
NET-TL-217
ITTC
© James P.G. Sterbenz
Transmission Control Protocol
Unidirectional Data Transfer
• Data is sequence of bytes
– number by byte #
(not segment #)
– each segment ≤ MSS B
C
S
net
SYN (ISNs)
SYN(ISNc)ACK
ACK
data segment (MSS bytes)
SN=ISNs
• Sequence numbers
ACK AN=ISNs+MSS
– byte # in byte stream
of 1st byte in segment
data segment (MSS bytes)
SN=ISNs+MSS
• ACK numbers
– seq # of next byte expected
– cumulative ACKs
ACK AN=?
5
21 February 2011
KU EECS 780 – Comm Nets – E2E Transport
– 109 –
NET-TL-218
KU EECS 780 – Communication Networks – End-to-End Transport
ITTC
© James P.G. Sterbenz
Transmission Control Protocol
Unidirectional Data Transfer
• Data is sequence of bytes
C
– number by byte #
(not segment #)
– each segment ≤ MSS B
S
net
SYN (ISNs)
SYN(ISNc)ACK
ACK
data segment (MSS bytes)
SN=ISNs
• Sequence numbers
ACK AN=ISNs+MSS
– byte # in byte stream
of 1st byte in segment
data segment (MSS bytes)
SN=ISNs+MSS
• ACK numbers
ACK AN=ISNs+2MSS
– seq # of next byte expected
– cumulative ACKs
6
what next?
21 February 2011
KU EECS 780 – Comm Nets – E2E Transport
NET-TL-219
ITTC
© James P.G. Sterbenz
Transmission Control Protocol
Unidirectional Data Transfer
• Data is sequence of bytes
– number by byte #
(not segment #)
– each segment ≤ MSS B
C
SYN (ISNs)
SYN(ISNc)ACK
ACK
data segment (MSS bytes)
SN=ISNs
• Sequence numbers
ACK AN=ISNs+MSS
– byte # in byte stream
of 1st byte in segment
data segment (MSS bytes)
SN=ISNs+MSS
• ACK numbers
– seq # of next byte expected
– cumulative ACKs
ACK AN=ISNs+2MSS
data segment (MSS bytes)
SN=ISNs+2MSS
what next?
21 February 2011
S
net
KU EECS 780 – Comm Nets – E2E Transport
– 110 –
7
NET-TL-220
KU EECS 780 – Communication Networks – End-to-End Transport
ITTC
© James P.G. Sterbenz
Transmission Control Protocol
Unidirectional Data Transfer
• Data is sequence of bytes
C
– number by byte #
(not segment #)
– each segment ≤ MSS B
SYN (ISNs)
SYN(ISNc)ACK
ACK
data segment (MSS bytes)
SN=ISNs
• Sequence numbers
– byte # in byte stream
of 1st byte in segment
ACK AN=ISNs+MSS
data segment (MSS bytes)
SN=ISNs+MSS
• ACK numbers
– seq # of next byte expected
– cumulative ACKs
ACK AN=ISNs+2MSS
data segment (MSS bytes)
SN=ISNs+2MSS
• Out of order arrival
ACK AN=ISNs+3MSS
– implementation specific
21 February 2011
S
net
8
KU EECS 780 – Comm Nets – E2E Transport
NET-TL-221
ITTC
© James P.G. Sterbenz
Transmission Control Protocol
Bidirectional Data Transfer
C
• Data both directions
S
net
– ACKs returned both ways
SYN (ISNs)
SYN(ISNc)ACK
ACK
data segment (MSS bytes)
SN=ISNs
ACK AN=ISNs+MSS
what next?
21 February 2011
KU EECS 780 – Comm Nets – E2E Transport
– 111 –
1
NET-TL-222
KU EECS 780 – Communication Networks – End-to-End Transport
ITTC
© James P.G. Sterbenz
Transmission Control Protocol
Bidirectional Data Transfer
C
• Data both directions
S
net
– ACKs returned both ways
– may be piggybacked
SYN (ISNs)
SYN(ISNc)ACK
ACK
data segment (MSS bytes)
SN=ISNs
ACK AN=ISNs+MSS
data segment (MSS bytes)
SN=ISNc
2
what next?
21 February 2011
KU EECS 780 – Comm Nets – E2E Transport
NET-TL-223
ITTC
© James P.G. Sterbenz
Transmission Control Protocol
Bidirectional Data Transfer
C
• Data both directions
– ACKs returned both ways
– may be piggybacked
– delayed ACK waits briefly
S
net
SYN (ISNs)
SYN(ISNc)ACK
ACK
data segment (MSS bytes)
SN=ISNs
ACK AN=ISNs+MSS
data segment (MSS bytes)
SN=ISNc
ACK AN=ISNc+MSS
data segment (MSS bytes)
SN=ISNs+MSS
what next?
21 February 2011
KU EECS 780 – Comm Nets – E2E Transport
– 112 –
3
NET-TL-224
KU EECS 780 – Communication Networks – End-to-End Transport
ITTC
© James P.G. Sterbenz
Transmission Control Protocol
Bidirectional Data Transfer
C
• Data both directions
– ACKs returned both ways
– may be piggybacked
– delayed ACK waits briefly
• Bidirectional stream
S
net
SYN (ISNs)
SYN(ISNc)ACK
ACK
data segment (MSS bytes)
SN=ISNs
ACK AN=ISNs+MSS
– data segments
– piggybacked ACKs
data segment (MSS bytes)
SN=ISNc
ACK AN=ISNc+MSS
data segment (MSS bytes)
SN=ISNs+MSS
4
21 February 2011
KU EECS 780 – Comm Nets – E2E Transport
ITTC
NET-TL-225
© James P.G. Sterbenz
Transmission Control Protocol
Segment Format: Push
• Push
– PSH flag set
– receiver should immediately
send to application
– don’t wait to fill buffer
– example use: telnet
source port #
dest port #
sequence number
ACK number
HL CEUAPRSF receive window
checksum
urg data ptr
options (variable length)
• avoid buffering delay
application
payload
(variable length)
21 February 2011
KU EECS 780 – Comm Nets – E2E Transport
– 113 –
NET-TL-226
KU EECS 780 – Communication Networks – End-to-End Transport
ITTC
© James P.G. Sterbenz
Transmission Control Protocol
Segment Format: Urgent Mode
• Urgent mode
– URG flag set, urgent pointer
• Urgent data range
– sn + up points to last byte
• Example uses
source port #
dest port #
sequence number
ACK number
HL CEUAPRSF receive window
checksum
urg data ptr
– interrupt for telnet, rlogin
– FTP abort
why?
21 February 2011
options (variable length)
application
payload
(variable length)
KU EECS 780 – Comm Nets – E2E Transport
ITTC
NET-TL-227
© James P.G. Sterbenz
Transmission Control Protocol
Window-Based Feedback Control
• Windowing used for a combined:
– error control
– flow control
– congestion control
• Window limits amount of unACKed data transmitted
21 February 2011
KU EECS 780 – Comm Nets – E2E Transport
– 114 –
NET-TL-228
KU EECS 780 – Communication Networks – End-to-End Transport
ITTC
© James P.G. Sterbenz
Transmission Control Protocol
Error Control: Original Go-Back-N
• TCP provides reliable byte stream
• Cumulative ACKs using window: go-back-n
– byte number rather than segment number
• Corrupted data
– checksum fails
• Packet loss in network
– timeout events
– triple duplicate ACKS (fast retransmit)
21 February 2011
KU EECS 780 – Comm Nets – E2E Transport
ITTC
NET-TL-229
© James P.G. Sterbenz
Transmission Control Protocol
Error Control: SACK
• TCP provides reliable byte stream
– cumulative ACKs perform poorly if loss rate not very low
– cumulative ACKs limit ability to reorder
• Selective ACKs [RFC2018]
– selective repeat ARQ mechanism
• used in conjunction with cumulative ACK mechanisms
– SACK byte range in TCP header option
• Retransmissions triggered by:
– holes in SACK ranges (SACK is positive ACK)
21 February 2011
KU EECS 780 – Comm Nets – E2E Transport
– 115 –
NET-TL-230
KU EECS 780 – Communication Networks – End-to-End Transport
ITTC
© James P.G. Sterbenz
Transmission Control Protocol
Segment Format: SACK Options
• SACK permitted negotiation
– kind=4 in SYN
• SACK ranges
– kind = 05
• after kind=01 NOP pads
– length = 8n+2 B
for n SACK blocks
• max of 3 SACK blocks
– assuming another option
32 bits
source port #
dest port #
sequence number
ack number
HL
flags receive window
checksum
urg data pointer
01
01
05
len
seq num of 1st byte
seq num after last byte
– each block:
• seq num of 1st byte
• seq num of last byte +1
– ACK semantics unchanged
21 February 2011
application
payload
(variable length)
KU EECS 780 – Comm Nets – E2E Transport
ITTC
NET-TL-231
© James P.G. Sterbenz
Transmission Control Protocol
Error Control: SACK Operation
• Capability announced with SYN
– SACK permitted option 5
• Cumulative ACKs as before
– ACK byte in last segment
– with no missing prior segments
• Selective ACKs
– sent only when non-contiguous
segments received
– indicate byte range received
– holes between SACK blocks
indicate missing byte ranges
21 February 2011
KU EECS 780 – Comm Nets – E2E Transport
– 116 –
NET-TL-232
KU EECS 780 – Communication Networks – End-to-End Transport
ITTC
© James P.G. Sterbenz
Transmission Control Protocol
Timeout
How to set TCP timeout value?
21 February 2011
KU EECS 780 – Comm Nets – E2E Transport
ITTC
NET-TL-233
© James P.G. Sterbenz
Transmission Control Protocol
Timeout
• How to set TCP timeout value?
– longer than RTT, but RTT varies
– too short: premature timeout; unnecessary retransmissions
– too long: slow reaction to segment loss
Implication?
21 February 2011
KU EECS 780 – Comm Nets – E2E Transport
– 117 –
NET-TL-234
KU EECS 780 – Communication Networks – End-to-End Transport
ITTC
© James P.G. Sterbenz
Transmission Control Protocol
Timeout
• How to set TCP timeout value?
– longer than RTT, but RTT varies
– too short: premature timeout; unnecessary retransmissions
– too long: slow reaction to segment loss
• Need a good estimate of RTT
21 February 2011
KU EECS 780 – Comm Nets – E2E Transport
ITTC
NET-TL-235
© James P.G. Sterbenz
Transmission Control Protocol
Round Trip Time Estimate
• RTT Estimate
– sample RTTsamp:
measured time from segment transmission until ACK receipt
– ignore retransmissions
• Estimated RTTest is smoothed
– average several recent measurements
– EWMA: exponentially weighted moving average
• influence of past sample decreases exponentially
– RTTest = (1–α) RTTest + α RTTsamp
• typical value: α = 0.125
21 February 2011
KU EECS 780 – Comm Nets – E2E Transport
– 118 –
NET-TL-236
KU EECS 780 – Communication Networks – End-to-End Transport
ITTC
© James P.G. Sterbenz
Transmission Control Protocol
RTT Estimate Example
RTT: gaia.cs.umass.edu to fantasia.eurecom.fr
RTT (milliseconds)
350
300
250
200
150
SampleRTT
Estimated RTT
100
1
8
15
22
29
36
43
50
57
64
71
78
85
92
99
106
time (seconds)
21 February 2011
KU EECS 780 – Comm Nets – E2E Transport
ITTC
NET-TL-237
© James P.G. Sterbenz
Transmission Control Protocol
Fast Retransmit
• Time-out period often too long
– long delay before resending lost packet
• Detect lost segments via duplicate ACKs
– sender often sends many segments back-to-back
– if lost there will likely be many duplicate ACKs
• If sender receives 3 duplicate ACKs
– 4th identical ACK
– assume that segment after ACKed data was lost
21 February 2011
KU EECS 780 – Comm Nets – E2E Transport
– 119 –
NET-TL-238
KU EECS 780 – Communication Networks – End-to-End Transport
ITTC
© James P.G. Sterbenz
Transmission Control Protocol
Flow Control
• Sender matches transmission rate to receiver
– receive window dynamically adjusted
• Receiver advertises its window
– transmitted in each TCP segment header
• Sender limits unACKed data to receive window size
RcvWindow
from IP
21 February 2011
spare
room
data in
buffer
to application
KU EECS 780 – Comm Nets – E2E Transport
ITTC
NET-TL-239
© James P.G. Sterbenz
Transmission Control Protocol
Congestion Control
• Slow start to probe capacity
• Implicit congestion control
– lack of expected ACK assumed to be congestion-based loss
– sender halves congestion window (AIMD)
• Recovery
– then retransmits (go-back-n or SACK block)
– begins increase of congestion window (AIMD)
• 1 MSS (max. segment size) every RTT
21 February 2011
KU EECS 780 – Comm Nets – E2E Transport
– 120 –
NET-TL-240
KU EECS 780 – Communication Networks – End-to-End Transport
ITTC
© James P.G. Sterbenz
Transmission Control Protocol
Congestion Control
initialisation
steady state phase
congestion detection
sending rate
AI
slow
start
MD
time
• Initialisation phase: slow start
• Steady-state phase: AIMD
21 February 2011
KU EECS 780 – Comm Nets – E2E Transport
ITTC
NET-TL-241
© James P.G. Sterbenz
Transmission Control Protocol
Congestion Control Optimisations
• Fast recovery
– 1/2 congestion window after 3dupACK rather than slow start
• RED: random early detection (discard) [Floyd 1993]
– discard packets when router queue threshold exceeded
– throttle TCP source earlier before congestion occurs
more in Lecture TQ
• ECN: explicit congestion notification [Floyd 1994]
– use IP ECN to trigger multiplicative decrease
21 February 2011
KU EECS 780 – Comm Nets – E2E Transport
– 121 –
NET-TL-242
KU EECS 780 – Communication Networks – End-to-End Transport
ITTC
© James P.G. Sterbenz
Transmission Control Protocol
Explicit Congestion Notification
• Network nodes set
congestion indication
– hist. ICMP source quench
– ECN bits in IP header
• TCP reacts
– uses flags for signalling
source port #
dest port #
sequence number
ACK number
CEUAPRSF receive window
HL
checksum
urg data pointer
options (variable length)
more in lecture TQ
application
payload
(variable length)
21 February 2011
KU EECS 780 – Comm Nets – E2E Transport
ITTC
NET-TL-243
© James P.G. Sterbenz
Transmission Control Protocol
Congestion Control Implementations
• Tahoe
– slow start and congestion avoidance algorithms
– fast retransmit after triple duplicate ACKs
• Reno – widely implemented
– Tahoe +
– fast recovery
• NewReno [Floyd 1999]
– Reno +
– partial ACK recovery
21 February 2011
KU EECS 780 – Comm Nets – E2E Transport
– 122 –
NET-TL-244
KU EECS 780 – Communication Networks – End-to-End Transport
ITTC
© James P.G. Sterbenz
Transmission Control Protocol
High-Bandwidth-×-Delay Optimisations
• High bandwidth-×-delay paths (long fat pipes)
problem?
21 February 2011
KU EECS 780 – Comm Nets – E2E Transport
ITTC
NET-TL-245
© James P.G. Sterbenz
Transmission Control Protocol
High-Bandwidth-×-Delay Optimisations
• High bandwidth-×-delay paths (long fat pipes)
– problem: large number of bits in flight
Implications to TCP?
21 February 2011
KU EECS 780 – Comm Nets – E2E Transport
– 123 –
NET-TL-246
KU EECS 780 – Communication Networks – End-to-End Transport
ITTC
© James P.G. Sterbenz
Transmission Control Protocol
High-Bandwidth-×-Delay Optimisations
• High bandwidth-×-delay paths (long fat pipes)
– problem: large number of bits in flight
• Implications to TCP
–
–
–
–
max window size is 64KB (why? ) (problem? )
packet loss has significant impact on goodput
only one RTT measurement per window
sequence numbers limited to 32 bit (problem? )
21 February 2011
KU EECS 780 – Comm Nets – E2E Transport
ITTC
NET-TL-247
© James P.G. Sterbenz
Transmission Control Protocol
High-Bandwidth-×-Delay Optimisations
• High bandwidth-×-delay paths (long fat pipes)
– problem: large number of bits in flight
• Modifications [RFC 1323]
–
–
–
–
window scale option (kind=3)
SACK [RFC 2018]
timestamp option (kind=8) enables RTT per segment
PAWS uses timestamp to detect duplicate seq. numbers
(protection against wrapped sequence numbers)
more about this in EECS 881
21 February 2011
KU EECS 780 – Comm Nets – E2E Transport
– 124 –
NET-TL-248
KU EECS 780 – Communication Networks – End-to-End Transport
ITTC
© James P.G. Sterbenz
Transport Layer
TL.4 Multipoint Communication
TL.1
TL.2
TL.3
TL.4
Transport services and interfaces
End-to-end functions and mechanisms
Internet transport protocols
Multipoint communication and reliable multicast
21 February 2011
KU EECS 780 – Comm Nets – E2E Transport
ITTC
NET-TL-249
© James P.G. Sterbenz
E2E Multipoint Communication
Motivation for E2E Multicast
• End-to-end multicast is necessary if:
• Network layer multicast not available
why?
• Reliability is needed
why?
21 February 2011
KU EECS 780 – Comm Nets – E2E Transport
– 125 –
NET-TL-250
KU EECS 780 – Communication Networks – End-to-End Transport
ITTC
© James P.G. Sterbenz
E2E Multipoint Communication
Motivation for E2E Multicast
• End-to-end multicast is necessary if:
• Network layer multicast not available
– intradomain multicast limited
– interdomain multicast not available
lecture NL
• Reliability is needed
– recall end-to-end arguments
– options:
transport-layer multicast
application-layer multicast
21 February 2011
KU EECS 780 – Comm Nets – E2E Transport
NET-TL-251
ITTC
© James P.G. Sterbenz
E2E Multipoint Communication
Closed Loop Retransmission: Multicast
R
R
ACK
ACK×6
NAK×2
6
ACK×4
ACK
6
NAK
NAK
ACK
5
ACK×2
ACK
1
5
NAK
ACK×2
ACK
2
ACK
3
NAK
NAK
4
1
2
3
4
• ACK implosion: ACK suppression needed
o NAKs (negative ACKs) with liveness polling
o localised hop-by-hop buffering and retransmission
– significant reduction of traffic on relatively reliable links
21 February 2011
KU EECS 780 – Comm Nets – E2E Transport
– 126 –
NET-TL-252
KU EECS 780 – Communication Networks – End-to-End Transport
ITTC
© James P.G. Sterbenz
Further Reading
• W. Richard Stevens,
TCP/IP Illustrated, Volume 1: The Protocols,
Addison-Wesley, Reading MA, 1994.
• Michael Welzl,
Network Congestion Control,
John Wiley, Chichester UK, 2005.
21 February 2011
KU EECS 780 – Comm Nets – E2E Transport
ITTC
NET-TL-253
© James P.G. Sterbenz
Acknowledgements
Some material in these foils comes from the textbook
supplementary materials:
• Kurose & Ross,
Computer Networking:
A Top-Down Approach Featuring the Internet
• Sterbenz & Touch,
High-Speed Networking:
A Systematic Approach to
High-Bandwidth Low-Latency Communication
http://hsn‐book.sterbenz.org
21 February 2011
KU EECS 780 – Comm Nets – E2E Transport
– 127 –
NET-TL-254