KU EECS 780 – Communication Networks – End-to-End Transport
– 1 –
© James P.G. SterbenzITTCCommunication Networks
The University of Kansas EECS 780End-to-End Transport
© 2004–2007 James P.G. Sterbenz21 February 2011
James P.G. Sterbenz
Department of Electrical Engineering & Computer ScienceInformation Technology & Telecommunications Research Center
The University of Kansas
http://www.ittc.ku.edu/~jpgs/courses/nets
rev. 11.0 © 2004–2011 James P.G. Sterbenz
21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-2
© James P.G. SterbenzITTC
End-to-End TransportOutline
TL.1 Transport services and interfacesTL.2 End-to-end functions and mechanismsTL.3 Internet transport protocolsTL.4 Multipoint communication and reliable multicast
KU EECS 780 – Communication Networks – End-to-End Transport
– 2 –
21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-3
© James P.G. SterbenzITTC
End-to-End TransportTL.1 Services and Interfaces
TL.1 Transport services and interfacesTL.2 End-to-end functions and mechanismsTL.3 Internet transport protocolsTL.4 Multipoint communication and reliable multicast
21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-4
© James P.G. SterbenzITTC
Transport LayerHybrid Layer/Plane Cube
Layer 4:end-to-enddata transferin data and control planes
physicalMAC
link
networktransport
sessionapplication
data plane control plane
plane
management
social
virtual link
L1
L7L5L4L3
L2L1.5
L8
L2.5
KU EECS 780 – Communication Networks – End-to-End Transport
– 3 –
21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-5
© James P.G. SterbenzITTC
Transport LayerMotivation
Why do we need a transport protocol?
Mapp
Mapp
ES1
CPU
ES2
CPU
21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-6
© James P.G. SterbenzITTC
Transport LayerIdeal Network Model
• Ideal network model– zero end-to-end delay– unlimited end-to-end bandwidth– perfect end-to-end transmission (no errors)
But what?
Mapp
Mapp
D = 0
R = ∞
ES1
CPU
ES2
CPU
KU EECS 780 – Communication Networks – End-to-End Transport
– 4 –
21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-7
© James P.G. SterbenzITTC
Transport LayerIdeal Network Model and Motivation
• 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
Mapp
Mapp
D
R
ES1
CPU
ES2
CPU
21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-8
© James P.G. SterbenzITTC
Transport LayerTransport Association Definition
• 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
networkCPU
M app
end system
intermediatesystem
CPU
M app
end system
KU EECS 780 – Communication Networks – End-to-End Transport
– 5 –
21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-9
© James P.G. SterbenzITTC
Transport LayerEnd-to-End Protocol
• Transport protocol– is responsible for end-to-end transfer of a TPDU– note to Bell-heads: not layer 2 “transport network”
network
application
session
transport
network
link
end system
network
link
intermediatesystem
network
link
intermediatesystemnetwork
link
intermediatesystem
application
session
transport
network
link
end system
21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-10
© James P.G. SterbenzITTC
Transport LayerService 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
KU EECS 780 – Communication Networks – End-to-End Transport
– 6 –
21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-11
© James P.G. SterbenzITTC
Transport LayerService 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 NET-TL-12
© James P.G. SterbenzITTC
Transport LayerTypes 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
KU EECS 780 – Communication Networks – End-to-End Transport
– 7 –
21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-13
© James P.G. SterbenzITTC
Transport LayerService 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
network layer
transport layer
application layer
network layer
transport layer
ADU ADU
ADU THADUH T TPDU
21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-14
© James P.G. SterbenzITTC
Transport LayerFunctional Placement
• Transport layer functionality only in end system– host software or– network interface (NIC)
switch
TPDUs
end system
network interface
mem CPU
frames
end system
network interface
memCPU
framespacket
KU EECS 780 – Communication Networks – End-to-End Transport
– 8 –
21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-15
© James P.G. SterbenzITTC
Transport LayerEnd-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 NET-TL-16
© James P.G. SterbenzITTC
End-to-End vs. Hop-by-HopEnd-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 netis not possible
paraphrased from [Saltzer, Reed, Clark 1981]
KU EECS 780 – Communication Networks – End-to-End Transport
– 9 –
21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-17
© James P.G. SterbenzITTC
End-to-End vs. Hop-by-HopEnd-to-End Arguments
• 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
f -1 f
f1 f3-1f3f2
-1f2f1-1
g g′′′ g′′ g′
21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-18
© James P.G. SterbenzITTC
End-to-End vs. Hop-by-HopEnd-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]
KU EECS 780 – Communication Networks – End-to-End Transport
– 10 –
21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-19
© James P.G. SterbenzITTC
End-to-End vs. Hop-by-HopHop-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 NET-TL-20
© James P.G. SterbenzITTC
End-to-End vs. Hop-by-HopPerformance 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 mwireless LANUniv. Kansas
100 mfiber LAN
Univ. Sydney
15 000 kmfiber WAN
KU EECS 780 – Communication Networks – End-to-End Transport
– 11 –
21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-21
© James P.G. SterbenzITTC
End-to-End vs. Hop-by-HopPerformance 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?
• 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
100 mwireless LANUniv. Kansas
100 mfiber LAN
Univ. Sydney
15 000 kmfiber WAN
21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-22
© James P.G. SterbenzITTC
End-to-End vs. Hop-by-HopSecurity
• 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
KU EECS 780 – Communication Networks – End-to-End Transport
– 12 –
21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-23
© James P.G. SterbenzITTC
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 NET-TL-24
© James P.G. SterbenzITTC
End-to-End TransportTL.2 Functions and Mechanisms
TL.1 Transport services and interfacesTL.2 End-to-end functions and mechanisms
TL.2.1 Framing and multiplexingTL.2.2 State management and transfer modesTL.2.3 Reliability and error controlTL.2.4 Transmission control
TL.3 Internet transport protocolsTL.4 Multipoint communication and reliable multicast
KU EECS 780 – Communication Networks – End-to-End Transport
– 13 –
21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-25
© James P.G. SterbenzITTC
E2E Functions and MechanismsTL.2.1 Framing and Multiplexing
TL.1 Transport services and interfacesTL.2 End-to-end functions and mechanisms
TL.2.1 Framing and multiplexingTL.2.2 State management and transfer modesTL.2.3 Reliability and error controlTL.2.4 Transmission control
TL.3 Internet transport ProtocolsTL.4 Multipoint communication and reliable multicast
21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-26
© James P.G. SterbenzITTC
E2E FramingStructure 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)
KU EECS 780 – Communication Networks – End-to-End Transport
– 14 –
21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-27
© James P.G. SterbenzITTC
E2E FramingApplication Layer Framing
transport layer fragmentation
ADU
MTU
TPDU
ADU ADU
TPDU TPDU TPDU
TPDU
ADU ADU
TPDU TPDU TPDU
ADU
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 NET-TL-28
© James P.G. SterbenzITTC
E2E MultiplexingApplication and Transport Layer
• Multiplexing– application
• inter-application coordination
– transport• applications
sharing network interface
– network• end systems
sharing switch– MAC and link
• interfaces sharing medium
a4 pb ADU a4 pc ADU
host4 TPDU TPDU
host3
a3 pa ADUTPDU
NPDUs
network muxing
a3 pa ADU a4 pc ADUa4 pb ADU
host2
pa ADUappx
pb ADUappy
a4 pb ADU
pb ADU appb
pc ADU appc
pc ADUappz
network demuxing
pa ADU appa
transport muxing
transport demuxing
a4 pc ADU
host1
a3 pa ADUTPDU TPDU
TPDU
KU EECS 780 – Communication Networks – End-to-End Transport
– 15 –
21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-29
© James P.G. SterbenzITTC
E2E Functions and MechanismsTL.2.2 Transfer Modes and State Management
TL.1 Transport services and interfacesTL.2 End-to-end functions and mechanisms
TL.2.1 Framing and multiplexingTL.2.2 State management and transfer modesTL.2.3 Reliability and error controlTL.2.4 Transmission control
TL.3 Internet transport protocolsTL.4 Multipoint communication and reliable multicast
21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-30
© James P.G. SterbenzITTC
E2E Functions and MechanismsTransport Protocol Service Categories
• Transfer mode– connectionless datagram– connection-oriented– transaction– continuous media streaming
• Reliability– loss tolerance
• Delivery order– ordered– unordered
• Traffic characteristics
KU EECS 780 – Communication Networks – End-to-End Transport
– 16 –
21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-31
© James P.G. SterbenzITTC
E2E State ManagementControl Loops
Alternatives?
21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-32
© James P.G. SterbenzITTC
E2E State ManagementControl Loops
• Open loop– control parameters– no feedback
Alternative?
Open loop
parameters
data
KU EECS 780 – Communication Networks – End-to-End Transport
– 17 –
21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-33
© James P.G. SterbenzITTC
E2E State ManagementControl Loops
• Open loop– control parameters– no feedback
• Closed loop– initial parameters– feedback
• dynamic adaptation
Open loop
parameters
data
Closed loop
initial parameters
data
E2E feedback
21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-34
© James P.G. SterbenzITTC
E2E State ManagementControl Loops
• Open loop– control parameters– no feedback
• Closed loop– initial parameters– feedback
• dynamic adaptation
• Closed loopwith HBH feedback
• Nested control loops
Open loop
parameters
data
Nested control loops
initial parameters
data
E2E feedback
receiver sender
Closed loop with HBH feedback
HBH feedback
initial parameters
data
E2E feedback
Closed loop
initial parameters
data
E2E feedback
HBH loop HBH loop
KU EECS 780 – Communication Networks – End-to-End Transport
– 18 –
21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-35
© James P.G. SterbenzITTC
E2E State ManagementOpen- 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 NET-TL-36
© James P.G. SterbenzITTC
E2E State ManagementHard vs. Soft
• Hard state– explicitly established and released– deterministic– delay to establish and memory to maintain
Alternative?
KU EECS 780 – Communication Networks – End-to-End Transport
– 19 –
21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-37
© James P.G. SterbenzITTC
E2E State ManagementHard 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 NET-TL-38
© James P.G. SterbenzITTC
E2E State ManagementHard 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
KU EECS 780 – Communication Networks – End-to-End Transport
– 20 –
21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-39
© James P.G. SterbenzITTC
E2E State ManagementAssumed 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 NET-TL-40
© James P.G. SterbenzITTC
E2E State ManagementImpact of Data Rate
• Transmission delay proportional to data rateWhat happens when data rate increases?
slow
tRTT
SETUP
RELEASE
ACK
tp
td
KU EECS 780 – Communication Networks – End-to-End Transport
– 21 –
21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-41
© James P.G. SterbenzITTC
E2E State ManagementImpact of Data Rate
• Transmission delay proportional to data rate
• Connection shortening+ transmission delay decreases– but signalling delay constant
slow fast
ACK
RELEASE
tRTT
SETUP
RELEASE
ACK
tp
td
SETUP
21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-42
© James P.G. SterbenzITTC
E2E State ManagementImpact of Data Rate
• Transmission delay proportional to data rate
• Connection shortening+ transmission delay decreases– but signalling delay constant
• E2E signalling– significant fraction of time– connection shortening not
proportional to Δ date rate
slow high-speed fast
~1.5tRTT
~2.5tRTT ACK
RELEASE ACK
RELEASE
tRTT
SETUP
RELEASE
ACK
tp
td
tp
td→0
SETUP SETUP
KU EECS 780 – Communication Networks – End-to-End Transport
– 22 –
21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-43
© James P.G. SterbenzITTC
E2E State ManagementImpact of Latency
• Transmission delayand path delay proportional to lengthWhat happens when length increases?
short links
ACK
RELEASE
SETUP
21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-44
© James P.G. SterbenzITTC
E2E State ManagementImpact of Path Length
• Transmission delayand path delay proportional to length
• Connection lengthening– path delay increases– signalling delay increases
• E2E signalling– state open longer– denial of resource to others
short links long links
SETUP
ACK
RELEASE
SETUP
ACK
RELEASE
KU EECS 780 – Communication Networks – End-to-End Transport
– 23 –
21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-45
© James P.G. SterbenzITTC
E2E Transfer ModesAlternatives
• End-to-end transfer modes– datagram– connection– stream– transaction
21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-46
© James P.G. SterbenzITTC
E2E Transfer ModesDatagram
• Independent PDUs– each has fully self-describing header– no end-to-end flow state needed to forward
tp+td
KU EECS 780 – Communication Networks – End-to-End Transport
– 24 –
21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-47
© James P.G. SterbenzITTC
E2E Transfer Modes Connection
• Explicit connection setup– 3-way handshake
SETUP / CONNECT / ACKwhy?
~tRTT
ACK
RELEASE
CONNECT
SETUP
~1.5tRTT
~tRTT
tr
21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-48
© James P.G. SterbenzITTC
E2E Transfer Modes Connection
• Explicit connection setup– 3-way handshake
SETUP / CONNECT / ACK– both side have been acknowledged
• 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
~tRTT
ACK
RELEASE
CONNECT
SETUP
~1.5tRTT
~tRTT
tr
KU EECS 780 – Communication Networks – End-to-End Transport
– 25 –
21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-49
© James P.G. SterbenzITTC
E2E Transfer ModesTransport and Network Connections
• Transport connections– required over
• connectionless L3• path with any
connectionlesssubnetwork
– may exploit• connection-oriented L3
SETUPCONNECT
network layer
end system
transport layer
connection-orientednetwork
network layer
end system
transport layer
setup-req
network layer connection
connectionless network
network layer
transport layer SETUPCONNECT
network layer
transport layer
transport layer connection
network layer
transport layer SETUPCONNECT
network layer
transport layer
connection-oriented subnetwork
connectionlesssubnetwork
heterogeneous subnetworks
21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-50
© James P.G. SterbenzITTC
E2E Transfer Modes Connection State Machine
• ConnectionState Machine– send/receive paths
• States– idle– establishing
• install state– initialising
• stateconvergence
– steady state– closing
• release state
initialising
idle
steady state-
closing closing
establishing
CONNECTfrom net
requested
receiveSETUPfrom net
originateSETUPrequest
issueCONNECT
ACKfrom net
RELEASEfrom net
RELEASEfrom app
issueSETUP
issueRELEASE
issueRELEASE
KU EECS 780 – Communication Networks – End-to-End Transport
– 26 –
21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-51
© James P.G. SterbenzITTC
E2E Transfer Modes Media Stream
• Various mechanisms to start stream– explicit client request– server push– may or may not establish connection state
• Data flow – synchronisation and control
• embedded or• out-of-band
More about this in Lecture MS
REQUEST
RELEASE
CONNECT
SETUP
21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-52
© James P.G. SterbenzITTC
E2E Transfer Modes Transaction
• Transaction request– may or may not establish connection state– explicit release of connection state optional
• Data returned• Overlap to reduce latency
– request/response with control
• Recall: this is not how HTTP over TCP works
REQUEST
RELEASE
tr
RESPONSE
KU EECS 780 – Communication Networks – End-to-End Transport
– 27 –
21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-53
© James P.G. SterbenzITTC
E2E Functions and MechanismsTL.2.3 Reliability and Error Control
TL.1 Transport services and interfacesTL.2 End-to-End functions and mechanisms
TL.2.1 Framing and multiplexingTL.2.2 State management and transfer modesTL.2.3 Reliability and error controlTL.2.4 Transmission control
TL.3 Internet transport protocolsTL.4 Multipoint communication and reliable multicast
21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-54
© James P.G. SterbenzITTC
E2E Error ControlTypes of Errors
What are the types of errors?
KU EECS 780 – Communication Networks – End-to-End Transport
– 28 –
21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-55
© James P.G. SterbenzITTC
E2E Error ControlTypes of Errors
• Bit errors• Packet errors
types?
21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-56
© James P.G. SterbenzITTC
E2E Error ControlTypes of Errors
• Bit errors• Packet errors
– packet loss– fragment loss– burst loss– packet misordering– packet insertion– packet duplication
KU EECS 780 – Communication Networks – End-to-End Transport
– 29 –
21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-57
© James P.G. SterbenzITTC
E2E Error ControlCauses of Bit Errors
• Bit errorscauses?
21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-58
© James P.G. SterbenzITTC
E2E Error ControlCauses 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
KU EECS 780 – Communication Networks – End-to-End Transport
– 30 –
21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-59
© James P.G. SterbenzITTC
E2E Error ControlCauses of Packet Loss
• Packet losscauses?
21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-60
© James P.G. SterbenzITTC
E2E Error ControlCauses of Packet Loss
• Packet loss– network buffer overflow or intentional drop
more in lecture TQ– transport protocol packet discard when bit error
KU EECS 780 – Communication Networks – End-to-End Transport
– 31 –
21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-61
© James P.G. SterbenzITTC
E2E Error ControlCauses of Packet Loss
• Packet loss– network buffer overflow or intentional drop
more in lecture TQ– transport protocol packet discard when bit error
• Packet fragment losscauses?impact?
21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-62
© James P.G. SterbenzITTC
E2E Error ControlCauses 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
KU EECS 780 – Communication Networks – End-to-End Transport
– 32 –
21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-63
© James P.G. SterbenzITTC
E2E Error ControlCauses of Packet Burst Loss
• Packet burst losscauses?
21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-64
© James P.G. SterbenzITTC
E2E Error ControlCauses 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
KU EECS 780 – Communication Networks – End-to-End Transport
– 33 –
21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-65
© James P.G. SterbenzITTC
E2E Error ControlCauses of Packet Misordering
• Packet misorderingcauses?
21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-66
© James P.G. SterbenzITTC
E2E Error ControlCauses 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
KU EECS 780 – Communication Networks – End-to-End Transport
– 34 –
21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-67
© James P.G. SterbenzITTC
E2E Error ControlCauses of Packet Insertion
• Packet insertionmeaning?causes?
21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-68
© James P.G. SterbenzITTC
E2E Error ControlCauses 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
KU EECS 780 – Communication Networks – End-to-End Transport
– 35 –
21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-69
© James P.G. SterbenzITTC
E2E Error ControlCauses of Packet Duplication
• Packet duplicationcauses?
21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-70
© James P.G. SterbenzITTC
E2E Error ControlCauses of Packet Duplication
• Packet duplication– retransmission but original still arrives
KU EECS 780 – Communication Networks – End-to-End Transport
– 36 –
21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-71
© James P.G. SterbenzITTC
E2E Error ControlImpact 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 NET-TL-72
© James P.G. SterbenzITTC
E2E Error ControlARQ Closed Loop Retransmission
• Automatic repeat request (ARQ)– PDUs are retransmitted for reliable transfer
• Acknowledgments are used to request retransmissionalternatives?
KU EECS 780 – Communication Networks – End-to-End Transport
– 37 –
21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-73
© James P.G. SterbenzITTC
E2E Error ControlARQ 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 NET-TL-74
© James P.G. SterbenzITTC
E2E Error ControlARQ 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?
KU EECS 780 – Communication Networks – End-to-End Transport
– 38 –
21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-75
© James P.G. SterbenzITTC
0
E2E Error ControlClosed Loop Retransmission: Stop-and-Wait
• Each TPDU is acknowledged
1
21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-76
© James P.G. SterbenzITTC
E2E Error ControlClosed Loop Retransmission: Stop-and-Wait
• Each TPDU is acknowledged0
0
2
KU EECS 780 – Communication Networks – End-to-End Transport
– 39 –
21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-77
© James P.G. SterbenzITTC
E2E Error ControlClosed Loop Retransmission: Stop-and-Wait
• Each TPDU is acknowledged– subsequent TPDU waits on previous ACK
disadvantages?
0
0
3
A0
21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-78
© James P.G. SterbenzITTC
E2E Error ControlClosed Loop Retransmission: Stop-and-Wait
• Each TPDU is acknowledged– subsequent TPDU waits on previous ACK
• significant delay and underutilisation• 1 RTT per TPDU• serious penalty in long-delay environment
0
0
A0
1tack
4
KU EECS 780 – Communication Networks – End-to-End Transport
– 40 –
21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-79
© James P.G. SterbenzITTC
E2E Error ControlClosed Loop Retransmission: Stop-and-Wait
• Each TPDU is acknowledged– subsequent TPDU waits on previous ACK
• significant delay and underutilisation• 1 RTT per TPDU• serious penalty in long-delay environment
– sender timer tack fires if ACK not receivedissues?
0
0
A0
1tack
5
21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-80
© James P.G. SterbenzITTC
1
E2E Error ControlClosed Loop Retransmission: Stop-and-Wait
• Each TPDU is acknowledged– subsequent TPDU waits on previous ACK
• significant delay and underutilisation• 1 RTT per TPDU• serious penalty in long-delay environment
– sender timer tack fires if ACK not received• too conservative: issues?• too aggressive: issues?
0
0
A0
1tack
6
KU EECS 780 – Communication Networks – End-to-End Transport
– 41 –
21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-81
© James P.G. SterbenzITTC
1
E2E Error ControlClosed Loop Retransmission: Stop-and-Wait
• Each TPDU is acknowledged– subsequent TPDU waits on previous ACK
• significant delay and underutilisation• 1 RTT per TPDU• serious penalty in long-delay environment
– sender timer tack fires if ACK not received• too conservative: unnecessary delay• too aggressive: spurious retransmissions
0
0
A0
1tack
7
1
21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-82
© James P.G. SterbenzITTC
E2E Error ControlClosed Loop Retransmission: Stop-and-Wait
• Each TPDU is acknowledged– subsequent TPDU waits on previous ACK
• significant delay and underutilisation• 1 RTT per TPDU• serious penalty in long-delay environment
– sender timer tack fires if ACK not received• too conservative: unnecessary delay• too aggressive: spurious retransmissions
How can we do better?
0
0
A0
1
1
A1
tack
1
8
KU EECS 780 – Communication Networks – End-to-End Transport
– 42 –
21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-83
© James P.G. SterbenzITTC
E2E Error ControlClosed Loop Retransmission: Go-Back-n
• Go-back-n : pipeline transmissions 0
1
21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-84
© James P.G. SterbenzITTC
E2E Error ControlClosed Loop Retransmission: Go-Back-n
• Go-back-n : pipeline transmissions + multiple TPDUs simultaneously in flight 0
0
2
1
A0
KU EECS 780 – Communication Networks – End-to-End Transport
– 43 –
21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-85
© James P.G. SterbenzITTC
2
E2E Error ControlClosed Loop Retransmission: Go-Back-n
• Go-back-n : pipeline transmissions + multiple TPDUs simultaneously in flight
• TPDUs are sequentially acknowledged
0
0
3
1
A0
1
A1
tack
21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-86
© James P.G. SterbenzITTC
3
2
E2E Error ControlClosed Loop Retransmission: Go-Back-n
• Go-back-n : pipeline transmissions + multiple TPDUs simultaneously in flight
• TPDUs are sequentially acknowledgedhow is TPDU loss detected?
0
0
4
1
A0
1
A1
tack
KU EECS 780 – Communication Networks – End-to-End Transport
– 44 –
21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-87
© James P.G. SterbenzITTC
4
3
2
E2E Error ControlClosed Loop Retransmission: Go-Back-n
• Go-back-n : pipeline transmissions + multiple TPDUs simultaneously in flight
• TPDUs are sequentially acknowledgedo previous ACK retransmitted for
• subsequent TPDUs after loss• out of sequence TPDU
0
0
5
1
A0
1
A1
tack
A1
21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-88
© James P.G. SterbenzITTC
5
4
3
2
E2E Error ControlClosed Loop Retransmission: Go-Back-n
• Go-back-n : pipeline transmissions + multiple TPDUs simultaneously in flight
• TPDUs are sequentially acknowledgedo previous ACK retransmitted for
• subsequent TPDUs after loss• out of sequence TPDU
o sender timer fires if ACK not receivedimplication?
0
0
6
1
A0
1
A1
tack
A1
A1
KU EECS 780 – Communication Networks – End-to-End Transport
– 45 –
21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-89
© James P.G. SterbenzITTC
2
5
4
3
2
E2E Error ControlClosed Loop Retransmission: Go-Back-n
• Go-back-n : pipeline transmissions + multiple TPDUs simultaneously in flight
• TPDUs are sequentially acknowledgedo 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
0
7
1
A0
1
A1
tack
A1
A1
A1
21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-90
© James P.G. SterbenzITTC
3
A2
2
5
4
3
2
E2E Error ControlClosed Loop Retransmission: Go-Back-n
• Go-back-n : pipeline transmissions + multiple TPDUs simultaneously in flight
• TPDUs are sequentially acknowledgedo 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
0
8
1
A0
1
A1
tack
A1
A1
A1 2
KU EECS 780 – Communication Networks – End-to-End Transport
– 46 –
21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-91
© James P.G. SterbenzITTC
4
3
A2
2
5
4
3
2
E2E Error ControlClosed Loop Retransmission: Go-Back-n
• Go-back-n : pipeline transmissions + multiple TPDUs simultaneously in flight
• TPDUs are sequentially acknowledgedo 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
0
9
1
A0
1
A1
tack
A1
A1
A1 2
3
A3
21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-92
© James P.G. SterbenzITTC
5
4
3
A2
2
5
4
3
2
E2E Error ControlClosed Loop Retransmission: Go-Back-n
• Go-back-n : pipeline transmissions + multiple TPDUs simultaneously in flight
• TPDUs are sequentially acknowledgedo 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
0
10
1
A0
1
A1
tack
A1
A1
A1 2
3
A3
A4
4
KU EECS 780 – Communication Networks – End-to-End Transport
– 47 –
21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-93
© James P.G. SterbenzITTC
6
5
4
3
A2
2
5
4
3
2
E2E Error ControlClosed Loop Retransmission: Go-Back-n
• Go-back-n : pipeline transmissions + multiple TPDUs simultaneously in flight
• TPDUs are sequentially acknowledgedo 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
0
11
1
A0
1
A1
tack
A1
A1
A1 2
3
A3
A4
4
5
A5
21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-94
© James P.G. SterbenzITTC
6
5
4
3
A2
2
5
4
3
2
E2E Error ControlClosed Loop Retransmission: Go-Back-n
• Go-back-n : pipeline transmissions + multiple TPDUs simultaneously in flight
• TPDUs are sequentially acknowledgedo 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
0
12
1
A0
1
A1
tack
A1
A1
A1 2
3
A3
A4
4
5
A56
KU EECS 780 – Communication Networks – End-to-End Transport
– 48 –
21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-95
© James P.G. SterbenzITTC
E2E Error ControlClosed Loop Retransmission: Go-Back-n
• Go-back-n : pipeline transmissions + multiple TPDUs simultaneously in flight
• TPDUs are sequentially acknowledgedo 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
A0
A1
A1
0
1
2
3
4
5
6
2
3
4
5
6
A1
A2
A3
A4
A5
A1
0
1
2
3
5
4
tack
13
21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-96
© James P.G. SterbenzITTC
E2E Error ControlClosed Loop Retransmission: Go-Back-n
• Optimisation possible for go-back-n?
A0
A1
A1
0
1
2
3
4
5
6
2
3
4
5
6
A1
A2
A3
A4
A5
A1
0
1
2
3
5
4
tack
KU EECS 780 – Communication Networks – End-to-End Transport
– 49 –
21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-97
© James P.G. SterbenzITTC
E2E Error ControlClosed Loop Retransmission: Go-Back-n
• Optimisation go-back-ntimer the only way to detect loss?
A0
A1
A1
0
1
2
3
4
5
6
2
3
4
5
6
A1
A2
A3
A4
A5
A1
0
1
2
3
5
4
tack
21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-98
© James P.G. SterbenzITTC
E2E Error ControlClosed Loop Retransmission: Fast Retransmit
• Fast retransmit– optimisation for go-back-n
0
1
KU EECS 780 – Communication Networks – End-to-End Transport
– 50 –
21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-99
© James P.G. SterbenzITTC
E2E Error ControlClosed Loop Retransmission: Fast Retransmit
• Fast retransmit– optimisation for go-back-n 0
0
2
1
A0
21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-100
© James P.G. SterbenzITTC
2
E2E Error ControlClosed Loop Retransmission: Fast Retransmit
• Fast retransmit– optimisation for go-back-n 0
0
3
1
A0
1
A1
tack
KU EECS 780 – Communication Networks – End-to-End Transport
– 51 –
21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-101
© James P.G. SterbenzITTC
3
2
E2E Error ControlClosed Loop Retransmission: Fast Retransmit
• Fast retransmit– optimisation for go-back-n 0
0
4
1
A0
1
A1
tack
21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-102
© James P.G. SterbenzITTC
4
3
2
E2E Error ControlClosed Loop Retransmission: Fast Retransmit
• Fast retransmit– optimisation for go-back-n
• Assume several duplicate ACKs are loss
0
0
5
1
A0
1
A1
tack
A1
KU EECS 780 – Communication Networks – End-to-End Transport
– 52 –
21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-103
© James P.G. SterbenzITTC
2
5
4
3
2
E2E Error ControlClosed Loop Retransmission: Fast Retransmit
• Fast retransmit– optimisation for go-back-n
• Assume several duplicate ACKs are losso even if timer hasn’t yet fired
0
0
6
1
A0
1
A1
tack
A1
A1
21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-104
© James P.G. SterbenzITTC
3
A2
2
5
4
3
2
E2E Error ControlClosed Loop Retransmission: Fast Retransmit
• Fast retransmit– optimisation for go-back-n
• Assume several duplicate ACKs are losso even if timer hasn’t yet fired+ recovers from loss more quickly
0
0
7
1
A0
1
A1
tack
A1
A1
A12
KU EECS 780 – Communication Networks – End-to-End Transport
– 53 –
21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-105
© James P.G. SterbenzITTC
43
A2
2
5
4
3
2
E2E Error ControlClosed Loop Retransmission: Fast Retransmit
• Fast retransmit– optimisation for go-back-n
• Assume several duplicate ACKs are losso even if timer hasn’t yet fired+ recovers from loss more quickly
0
0
8
1
A0
1
A1
tack
A1
A1
A123
A3
21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-106
© James P.G. SterbenzITTC
543
A2
2
5
4
3
2
E2E Error ControlClosed Loop Retransmission: Fast Retransmit
• Fast retransmit– optimisation for go-back-n
• Assume several duplicate ACKs are losso even if timer hasn’t yet fired+ recovers from loss more quickly
0
0
9
1
A0
1
A1
tack
A1
A1
A123
A3A4
4
KU EECS 780 – Communication Networks – End-to-End Transport
– 54 –
21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-107
© James P.G. SterbenzITTC
6
543
A2
2
5
4
3
2
E2E Error ControlClosed Loop Retransmission: Fast Retransmit
• Fast retransmit– optimisation for go-back-n
• Assume several duplicate ACKs are losso even if timer hasn’t yet fired+ recovers from loss more quickly
0
0
10
1
A0
1
A1
tack
A1
A1
A123
A3A4
45
A5
21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-108
© James P.G. SterbenzITTC
6
543
A2
2
5
4
3
2
E2E Error ControlClosed Loop Retransmission: Fast Retransmit
• Fast retransmit– optimisation for go-back-n
• Assume several duplicate ACKs are losso even if timer hasn’t yet fired+ recovers from loss more quickly
0
0
11
1
A0
1
A1
tack
A1
A1
A123
A3A4
45
A56
KU EECS 780 – Communication Networks – End-to-End Transport
– 55 –
21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-109
© James P.G. SterbenzITTC
E2E Error ControlClosed Loop Retransmission: Fast Retransmit
• Fast retransmit– optimisation for go-back-n
• Assume several duplicate ACKs are losso even if timer hasn’t yet fired+ recovers from loss more quickly– still suffers from go-back-n inefficiencies
12
6
543
A2
2
5
4
3
2
0
0
1
A0
1
A1
tack
A1
A1
A123
A3A4
45
A56
21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-110
© James P.G. SterbenzITTC
E2E Error ControlClosed Loop Retransmission: Delayed ACK
• Delayed ACKo optimisation for go-back-n
• Aggregate several ACKs+ reduces ACK traffic+ allows some receiver resequencing
• within ACK aggregation quantum
KU EECS 780 – Communication Networks – End-to-End Transport
– 56 –
21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-111
© James P.G. SterbenzITTC
E2E Error ControlClosed 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 NET-TL-112
© James P.G. SterbenzITTC
E2E Error ControlClosed 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
KU EECS 780 – Communication Networks – End-to-End Transport
– 57 –
21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-113
© James P.G. SterbenzITTC
E2E Error ControlClosed Loop Retransmission: Selective Repeat
• Selective repeato all TPDUs acknowledged
1
0
21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-114
© James P.G. SterbenzITTC
E2E Error ControlClosed Loop Retransmission: Selective Repeat
• Selective repeato all TPDUs acknowledged 0
0
2
1
A0
KU EECS 780 – Communication Networks – End-to-End Transport
– 58 –
21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-115
© James P.G. SterbenzITTC
2
E2E Error ControlClosed Loop Retransmission: Selective Repeat
• Selective repeato all TPDUs acknowledged 0
0
3
1
A0
1
A1
tack
21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-116
© James P.G. SterbenzITTC
3
2
E2E Error ControlClosed Loop Retransmission: Selective Repeat
• Selective repeato all TPDUs acknowledged 0
0
4
1
A0
1
A1
tack
KU EECS 780 – Communication Networks – End-to-End Transport
– 59 –
21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-117
© James P.G. SterbenzITTC
4
3
2
E2E Error ControlClosed Loop Retransmission: Selective Repeat
• Selective repeato all TPDUs acknowledged
– Missequenced TPDUso acknowledged and held at receiver
0
0
5
1
A0
1
A1
tack
A3
3
21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-118
© James P.G. SterbenzITTC
5
4
3
2
E2E Error ControlClosed Loop Retransmission: Selective Repeat
• Selective repeato all TPDUs acknowledged
• Missequenced TPDUso TPDUs held and reordered at receiver– increases receiver complexity
0
0
6
1
A0
1
A1
tack
A3
3
A4
43
KU EECS 780 – Communication Networks – End-to-End Transport
– 60 –
21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-119
© James P.G. SterbenzITTC
2
5
4
3
2
E2E Error ControlClosed Loop Retransmission: Selective Repeat
• Selective repeato all TPDUs acknowledged
• Missequenced TPDUso TPDUs held and reordered at receiver– increases receiver complexity
• Lost TPDUso selectively retransmitted
0
0
7
1
A0
1
A1
tack
A3
3
A4
43
543
A5
21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-120
© James P.G. SterbenzITTC
62
5
4
3
2
E2E Error ControlClosed Loop Retransmission: Selective Repeat
• Selective repeato all TPDUs acknowledged
• Missequenced TPDUso TPDUs held and reordered at receiver– increases receiver complexity
• Lost TPDUso selectively retransmitted+ no go-back-n latency penalty– requires more receiver buffer space
0
0
8
1
A0
1
A1
tack
A3
3
A4
43
543
A5
A2
5432
KU EECS 780 – Communication Networks – End-to-End Transport
– 61 –
21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-121
© James P.G. SterbenzITTC
762
5
4
3
2
E2E Error ControlClosed Loop Retransmission: Selective Repeat
• Selective repeato all TPDUs acknowledged
• Missequenced TPDUso TPDUs held and reordered at receiver– increases receiver complexity
• Lost TPDUso selectively retransmitted+ no go-back-n latency penalty– requires more receiver buffer space
0
0
9
1
A0
1
A1
tack
A3
3
A4
43
543
A5
A2
5432
A6
6
21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-122
© James P.G. SterbenzITTC
8762
5
4
3
2
E2E Error ControlClosed Loop Retransmission: Selective Repeat
• Selective repeato all TPDUs acknowledged
• Missequenced TPDUso TPDUs held and reordered at receiver– increases receiver complexity
• Lost TPDUso selectively retransmitted+ no go-back-n latency penalty– requires more receiver buffer space
0
0
10
1
A0
1
A1
tack
A3
3
A4
43
543
A5
A2
5432
A6
6
A7
7
KU EECS 780 – Communication Networks – End-to-End Transport
– 62 –
21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-123
© James P.G. SterbenzITTC
9
8762
5
4
3
2
E2E Error ControlClosed Loop Retransmission: Selective Repeat
• Selective repeato all TPDUs acknowledged
• Missequenced TPDUso TPDUs held and reordered at receiver– increases receiver complexity
• Lost TPDUso selectively retransmitted+ no go-back-n latency penalty– requires more receiver buffer space
• A2A Delay and bandwidth reduced
0
0
11
1
A0
1
A1
tack
A3
3
A4
43
543
A5
A2
5432
A6
6
A7
87
A8
21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-124
© James P.G. SterbenzITTC
E2E Error ControlClosed Loop Retransmission: Periodic State
• Selective ACK blockso bit vectors can aggregate ACKs+ significant reduction in control packets+ simple receiver implementation possible
5
4
6
7
0
1
A01_3
0
1
2
3
2
8
9
7–2
8
9 A4567
~1.5tRTT
3
43
543
6543
765543
A2
KU EECS 780 – Communication Networks – End-to-End Transport
– 63 –
21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-125
© James P.G. SterbenzITTC
E2E Error ControlImpact 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-126
© James P.G. SterbenzITTC
E2E Error ControlClosed Loop Retransmission: Comparison
0
0
A0
1
1
A1
tack
1
A0
A1
A1
0
1
2
3
4
5
6
2
3
4
5
6
A1
A2
A3
A4
A5
A1
0
1
2
3
5
4
tack
9
8762
5
4
3
2
0
0
1
A0
1
A1
tack
A3
3
A4
43
543
A5
A2A6
6
A7
87
A8
5
4
6
7
0
1
A01_3
0
1
2
3
2
8
9
7–2
8
9 A4567
~1.5tRTT
3
43
543
6543
76543
A2
KU EECS 780 – Communication Networks – End-to-End Transport
– 64 –
21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-127
© James P.G. SterbenzITTC
E2E Error ControlOpen Loop
• Open loop error controlo some applications do not need guaranteed reliability
examples?
21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-128
© James P.G. SterbenzITTC
E2E Error ControlOpen Loop
• Open loop error controlo 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?
KU EECS 780 – Communication Networks – End-to-End Transport
– 65 –
21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-129
© James P.G. SterbenzITTC
E2E Error ControlOpen Loop
• Open loop error controlo 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 NET-TL-130
© James P.G. SterbenzITTC
E2E Error ControlOpen Loop
• Open loop error controlo 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
KU EECS 780 – Communication Networks – End-to-End Transport
– 66 –
21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-131
© James P.G. SterbenzITTC
E2E Error ControlHybrid Open/Closed-Loop Control
• Hybrid open loop with closed loop when necessarywhy?
21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-132
© James P.G. SterbenzITTC
E2E Error ControlHybrid 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
KU EECS 780 – Communication Networks – End-to-End Transport
– 67 –
21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-133
© James P.G. SterbenzITTC
E2E Functions and MechanismsTL.2.4 Transmission Control
TL.1 Transport services and interfacesTL.2 End-to-end functions and mechanisms
TL.2.1 Framing and multiplexingTL.2.2 State management and transfer modesTL.2.3 Reliability and error controlTL.2.4 Transmission control
TL.3 Internet transport protocolsTL.4 Multipoint communication and reliable multicast
21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-134
© James P.G. SterbenzITTC
E2E Transmission ControlDefinitions: Flow Control
• Flow control– control transmission to avoid overwhelming receiver– end-to-end control
KU EECS 780 – Communication Networks – End-to-End Transport
– 68 –
21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-135
© James P.G. SterbenzITTC
E2E Transmission ControlDefinitions: 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 NET-TL-136
© James P.G. SterbenzITTC
E2E Transmission ControlDefinitions: 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 (see [Krishnan 2004])
KU EECS 780 – Communication Networks – End-to-End Transport
– 69 –
21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-137
© James P.G. SterbenzITTC
E2E Transmission ControlImpact 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 NET-TL-138
© James P.G. SterbenzITTC
E2E Transmission ControlOpen-Loop Rate Control
• Initial negotiation– admission control limits traffic to available resources
admissioncontrol
KU EECS 780 – Communication Networks – End-to-End Transport
– 70 –
21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-139
© James P.G. SterbenzITTC
E2E Transmission ControlOpen-Loop Rate Control
• Initial negotiation– admission control limits traffic to available resources– receiver negotiates what it can accept (flow control)
admissioncontrol
receivernegotiation
21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-140
© James P.G. SterbenzITTC
E2E Transmission ControlOpen-Loop Rate Control
• 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
admissioncontrol
receivernegotiation
ratescheduling
ratepolicing
conforming traffic
KU EECS 780 – Communication Networks – End-to-End Transport
– 71 –
21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-141
© James P.G. SterbenzITTC
E2E Transmission ControlOpen-Loop Rate Control
• 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
admissioncontrol
receivernegotiation
ratescheduling
ratepolicing
conforming trafficexcess traffic
21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-142
© James P.G. SterbenzITTC
E2E Transmission ControlOpen-Loop Rate Control Parameters
• Main parameters– peak rate rp
– average rate ra
– burstiness (peak to average ratio or max burst size)
• Derived parameters– jitter
rp
ra bursty
uniform
time
KU EECS 780 – Communication Networks – End-to-End Transport
– 72 –
21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-143
© James P.G. SterbenzITTC
E2E Transmission ControlOpen-Loop Rate Control: Connections
• Requires connection establishment(dis)advantages?
21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-144
© James P.G. SterbenzITTC
E2E Transmission ControlOpen-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 admittedlecture TQ
KU EECS 780 – Communication Networks – End-to-End Transport
– 73 –
21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-145
© James P.G. SterbenzITTC
E2E Transmission ControlClosed-Loop Flow and Congestion Control
networkcongestion control
packet scheduling
flow control
• Flow control– sender–receiver
• Congestion control– sender–network
• Packet scheduling Lecture TQ
21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-146
© James P.G. SterbenzITTC
E2E Transmission ControlClosed-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
KU EECS 780 – Communication Networks – End-to-End Transport
– 74 –
21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-147
© James P.G. SterbenzITTC
Congestion ControlIdeal Network
offered load
ideal
carr
ied
load
offered load
ideal
1.0
dela
y
throughput delay
• 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 NET-TL-148
© James P.G. SterbenzITTC
Congestion ControlReal 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
KU EECS 780 – Communication Networks – End-to-End Transport
– 75 –
21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-149
© James P.G. SterbenzITTC
Congestion ControlDesired Real Network Behaviour
knee
offered load
ideal1.0
1.0
carr
ied
load
offered load 1.0
dela
y
knee
throughput
dmin
delay
• 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 NET-TL-150
© James P.G. SterbenzITTC
Congestion ControlCauses 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)
KU EECS 780 – Communication Networks – End-to-End Transport
– 76 –
21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-151
© James P.G. SterbenzITTC
Congestion ControlInfinite Buffers / No Retransmission
• Congestion whenoffered load → link capacity
• Infinite buffers– queue length
builds to infinity– d → ∞
discuss why in lecture TQ
offered load
ideal
1.0
dela
y
knee
dmin
delay
21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-152
© James P.G. SterbenzITTC
Congestion ControlFinite Buffers with Retransmission
• Finite buffers cause packet loss– retransmissions contribute to offered load
• assuming reliable protocol
– throughput curve levels off
KU EECS 780 – Communication Networks – End-to-End Transport
– 77 –
21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-153
© James P.G. SterbenzITTC
Congestion ControlMultihop Network
• Multiple hops– downstream packet loss– upstream transmission wasted
21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-154
© James P.G. SterbenzITTC
Congestion ControlConsequences 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
KU EECS 780 – Communication Networks – End-to-End Transport
– 78 –
21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-155
© James P.G. SterbenzITTC
Congestion ControlLocal 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 NET-TL-156
© James P.G. SterbenzITTC
Congestion ControlEnd-to-End Action
• End-to-end action• Throttle source
– reduce transmission rates– prevent unnecessary retransmissions
• Types– explicit– implicit
KU EECS 780 – Communication Networks – End-to-End Transport
– 79 –
21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-157
© James P.G. SterbenzITTC
Congestion ControlCongestion Avoidance and Control
knee cliff
offered load
ideal1.0
1.0
carri
ed lo
ad
offered load
ideal
1.0
dela
y
knee
cliff
CA CC
throughput
dmin
delay
CA
CC
• 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 NET-TL-158
© James P.G. SterbenzITTC
E2E Transmission ControlClosed-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
KU EECS 780 – Communication Networks – End-to-End Transport
– 80 –
21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-159
© James P.G. SterbenzITTC
E2E Transmission ControlClosed-Loop Control: Window Size
• Window size criticalwhat happens withincreasing bandwidth?
A0
A1
0
1
A2
5
slow path
0
1
2
3
4
5
6
A3
A4
A5
2
3
4
5
6
21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-160
© James P.G. SterbenzITTC
E2E Transmission ControlClosed-Loop Control: Window Size
• Window size critical– big enough to fill pipe
How to determine size?
A0
A1
0
1
A2
5
slow path fast path
0
1
2
3
A0A1A2A3
A4A5A6A7
4
5
6
A3
A4
A5
2
3
4
5
6
0 1 2 3
4 5 6 7
8 9 1011
4 5 6 7
0 1 2 3
8 9 10 11
12
A8A9
A10A11
KU EECS 780 – Communication Networks – End-to-End Transport
– 81 –
21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-161
© James P.G. SterbenzITTC
E2E Transmission ControlClosed-Loop Control: Initialisation
• Slow start initialisation– increase window until path loaded
• Critical parameters– initial window size– rate of increase
Tradeoffs?
A0
A1
A2
A3
A4
A5
A6
0
3
4
5
6
0
1
2
1
2
3
4
5
6
7
8
7
8
9
10
9
10
11
12
11
12
13
14
13
14
15
A7
A8
A9
A10
A11
A12
13
14
15
16
17
18
19
20
21
20
21
18
19
10
11
12
13
14
15
16
17
A4
A5
A6
A0
A1
A2
A3
0
1
2
3
0
1
2
3
4
5
4
5
6
7
6
7
8
9
8
9
10
11
12
A7
A8
A9
A10
A11
A12
A10
A13
A14
A15
A16
A17
tRTT
tRTT
tRTT
21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-162
© James P.G. SterbenzITTC
E2E Transmission ControlClosed-Loop Control: Initialisation
• Slow start initialisation– increase window until path loaded
• Critical parameters– initial window size– rate of increase
• Tradeoffs– conservative on high bw-×-delay:
• multiple round trips• never get to full rate for transactions
– aggressive:• induced congestions
A0
A1
A2
A3
A4
A5
A6
0
3
4
5
6
0
1
2
1
2
3
4
5
6
7
8
7
8
9
10
9
10
11
12
11
12
13
14
13
14
15
A7
A8
A9
A10
A11
A12
13
14
15
16
17
18
19
20
21
20
21
18
19
10
11
12
13
14
15
16
17
A4
A5
A6
A0
A1
A2
A3
0
1
2
3
0
1
2
3
4
5
4
5
6
7
6
7
8
9
8
9
10
11
12
A7
A8
A9
A10
A11
A12
A10
A13
A14
A15
A16
A17
tRTT
tRTT
tRTT
KU EECS 780 – Communication Networks – End-to-End Transport
– 82 –
21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-163
© James P.G. SterbenzITTC
E2E Congestion ControlClosed-Loop Control: Steady State
• AIMD steady state– additive-increase slowly increases rate
• increment window
– multiplicative-decrease quickly throttles with congestion• divide window when packet lost
additive increase
multiplicative decrease
time
rate
congestion detection
21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-164
© James P.G. SterbenzITTC
E2E Congestion ControlAIMD Fairness and Stability
• AIMD– R = available bandwidth– initial bandwidth share I– AI: both increase
• until loss beyond R– MD: both decrease
• half way to origin• halve window size
– trajectory toward ideal• intersection of R and equal
[based on Kurose fig. 3.53]
equal bandwidth
shareR
Flo
w 1
thro
ugh p
ut
RFlow 2 throughput
I
ideal
KU EECS 780 – Communication Networks – End-to-End Transport
– 83 –
21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-165
© James P.G. SterbenzITTC
E2E Congestion ControlClosed-Loop Control
• Initialisation phase: slow start• Steady-state phase: AIMD
AI
time
MD
send
ing
rate
slow start
steady state phase initialisation
congestion detection
21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-166
© James P.G. SterbenzITTC
E2E Congestion ControlClosed-Loop Implicit Control
• Implicit control– missing ACK assumed to be congestion
good assumption?
KU EECS 780 – Communication Networks – End-to-End Transport
– 84 –
21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-167
© James P.G. SterbenzITTC
E2E Congestion ControlClosed-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 NET-TL-168
© James P.G. SterbenzITTC
E2E Congestion ControlClosed-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 channelwhy?
KU EECS 780 – Communication Networks – End-to-End Transport
– 85 –
21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-169
© James P.G. SterbenzITTC
E2E Congestion ControlClosed-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 NET-TL-170
© James P.G. SterbenzITTC
E2E Congestion ControlClosed-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?
KU EECS 780 – Communication Networks – End-to-End Transport
– 86 –
21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-171
© James P.G. SterbenzITTC
E2E Congestion ControlClosed-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 NET-TL-172
© James P.G. SterbenzITTC
E2E Congestion ControlClosed-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
KU EECS 780 – Communication Networks – End-to-End Transport
– 87 –
21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-173
© James P.G. SterbenzITTC
E2E Transmission ControlClosed-Loop Control: Steady State
• Implicit control– standard– with fast retransmit
• Explicit control– ECN
tack
implicit explicit fast retransmit
A7
A7
A7
A7
A7
13
14
15
16
8
9
10
11
12
11
12
9
10
8
A4
A5
A6
A0
A1
A2
A3
0
1
2
3
0
1
2
3
4
5
4
5
6
7
6
7
9
10
11
12
A7
A7
A7
A7
A8
A9
8
A71
A72
A7313
14
8
9
10
11
12
13
14
11
12
9
10
8
A4
A5
A6
A0
A1
A2
A3
0
1
2
3
0
1
2
3
4
5
4
5
6
7
6
7
9
10
11
12
A7
A7
A7
A8
A9
8
12
13
13
14
15
16
17
18
19
20
21
A4
A5
A6
A0
A1
A2
A3
0
1
2
3
0
1
2
3
4
5
4
5
6
7
6
7
9
10
11
12 11
12
9
10
8
13
14
ECN8
18
19
16
17
15
20
21
A7
A8
A9
A10
A11
A12
A13
A14
A15
A16
A17
A18
A10
A11
21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-174
© James P.G. SterbenzITTC
E2E Transmission ControlHybrid 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
KU EECS 780 – Communication Networks – End-to-End Transport
– 88 –
21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-175
© James P.G. SterbenzITTC
Transport LayerTL.3 Internet Transport Protocols
TL.1 Transport Services and interfacesTL.2 End-to-end functions and mechanismsTL.3 Internet transport protocols
TL.3.1 UDPTL.3.2 RTP introductionTL.3.3 TCP
TL.4 Multipoint communication and reliable multicast
21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-176
© James P.G. SterbenzITTC
Internet Transport ProtocolsHistory
• 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
KU EECS 780 – Communication Networks – End-to-End Transport
– 89 –
21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-177
© James P.G. SterbenzITTC
Internet Transport ProtocolsOverview
• 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 NET-TL-178
© James P.G. SterbenzITTC
Internet Transport ProtocolsImportant Examples
signallingproposed for wireless
reliable data transfer with no congestion control
low connection setup overhead for transactions
real-time synchronisation(typically over UDP)
socket access to unreliable IP datagrams
reliable data transfer with congestion control
Function
proposed standard
experimental
experimental
standards track
standard
standard
Status
RFC 0908reliable data protocolRDP
RFC 2960stream control transmission protocolSCTP
RFC 1644TCP for transactionsT/TCP
RFC 3550STD 0064real-time protocolRTP
RFC 0768STD 0006
user datagram protocolUDP
RFC 0793STD 0007
transmission control protocolTCP
RefNameProtocol
KU EECS 780 – Communication Networks – End-to-End Transport
– 90 –
21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-179
© James P.G. SterbenzITTC
Internet Transport ProtocolsTL.3.1 UDP
TL.1 Transport services and interfacesTL.2 End-to-end functions and mechanismsTL.3 Internet transport protocols
TL.3.1 UDPTL.3.2 RTP introductionTL.3.3 TCP
TL.4 Multipoint communication and reliable multicast
21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-180
© James P.G. SterbenzITTC
User Datagram ProtocolOverview 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
KU EECS 780 – Communication Networks – End-to-End Transport
– 91 –
21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-181
© James P.G. SterbenzITTC
User Datagram ProtocolSegment Format and Multiplexing
• Relatively small header– source and destination port– length [B] including header– checksum
• Multiplexing: UDP socket– dest (IP addr, port#)
• Demux– receiver passes to port#
• source addr, port irrelevant– negotiated or well-known– may use source port to reply
destination port #source port#
length checksum
application payload(= length – 8B)
21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-182
© James P.G. SterbenzITTC
User Datagram ProtocolMultiplexing
• Interface to IP: protocol mux/demux (UDP=17)• Interface to application: port mux/demux
app iTCPport n
app jTCPport x
TCPport y
UDPport z
TCP TCP UDP
transport demux (IP protocol id)
port demux
network demux (IP address)
pd pd
06 17
KU EECS 780 – Communication Networks – End-to-End Transport
– 92 –
21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-183
© James P.G. SterbenzITTC
User Datagram ProtocolError Detection
• Recall E2E arguments: error check must be done E2E• Error checking: checksum
– sequence of 16-bit integers– binary addition
• carry overflows wrapped; • 1’s complement of sum
1110011001100110+1101010101010101
destination port #source port#
length checksum
application payload(= length – 8B)
21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-184
© James P.G. SterbenzITTC
User Datagram ProtocolError Detection
• Recall E2E arguments: error check must be done E2E• Error checking: checksum
– sequence of 16-bit integers– binary addition
• carry overflows wrapped; • 1’s complement of sum
1110011001100110+110101010101010111011101110111011
destination port #source port#
length checksum
application payload(= length – 8B)
KU EECS 780 – Communication Networks – End-to-End Transport
– 93 –
21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-185
© James P.G. SterbenzITTC
User Datagram ProtocolError Detection
• Recall E2E arguments: error check must be done E2E• Error checking: checksum
– sequence of 16-bit integers– binary addition
• carry overflows wrapped; • 1’s complement of sum
1110011001100110+110101010101010111011101110111011
1011101110111100
destination port #source port#
length checksum
application payload(= length – 8B)
21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-186
© James P.G. SterbenzITTC
User Datagram ProtocolError Detection
• Recall E2E arguments: error check must be done E2E• Error checking: checksum
– sequence of 16-bit integers– binary addition
• carry overflows wrapped; • 1’s complement of sum
1110011001100110+110101010101010111011101110111011
10111011101111000100010001000011
destination port #source port#
length checksum
application payload(= length – 8B)
KU EECS 780 – Communication Networks – End-to-End Transport
– 94 –
21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-187
© James P.G. SterbenzITTC
User Datagram ProtocolError Detection
• Recall E2E arguments: error check must be done E2E• Error checking: checksum
– sequence of 16-bit integers– binary addition
• carry overflows wrapped; • 1’s complement of sum
1110011001100110+110101010101010111011101110111011
10111011101111000100010001000011
– sender computes+inserts– receiver compute+compares– weak protection [RFC 3385]
• No retransmission at L4
destination port #source port#
length checksum
application payload(= length – 8B)
21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-188
© James P.G. SterbenzITTC
User Datagram ProtocolFlow 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
KU EECS 780 – Communication Networks – End-to-End Transport
– 95 –
21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-189
© James P.G. SterbenzITTC
User Datagram ProtocolTypical Applications
• Typical application: multimedia streamingwhy?
21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-190
© James P.G. SterbenzITTC
User Datagram ProtocolTypical Applications
• Typical application: multimedia streaming– loss tolerant– rate sensitive (do not adapt well to TCP congestion control)– research community considering alternatives
KU EECS 780 – Communication Networks – End-to-End Transport
– 96 –
21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-191
© James P.G. SterbenzITTC
User Datagram ProtocolTypical 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 NET-TL-192
© James P.G. SterbenzITTC
Internet Transport ProtocolsTL.3.2 RTP Introduction
TL.1 Transport services and interfacesTL.2 End-to-end functions and mechanismsTL.3 Internet transport protocols
TL.3.1 UDPTL.3.2 RTP introductionTL.3.3 TCP
TL.4 Multipoint communication and reliable multicast
KU EECS 780 – Communication Networks – End-to-End Transport
– 97 –
21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-193
© James P.G. SterbenzITTC
Real-Time ProtocolOverview 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 NET-TL-194
© James P.G. SterbenzITTC
Real-Time ProtocolSegment 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)
• resolution app dependent– source identifiers
• SSRC• CSRC (mixed in)
destination port #source port#
length checksum
CSRC list: contributing source ids. . .
optional padding
application payload
SSRC: synchronisation source id
timestamp
sequence #02 P X CC PT
#B pad
KU EECS 780 – Communication Networks – End-to-End Transport
– 98 –
21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-195
© James P.G. SterbenzITTC
Real-Time ProtocolRTP 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 NET-TL-196
© James P.G. SterbenzITTC
Real-Time ProtocolControl Protocol Overview
• RTCP: real-time control protocol [RFC 3550 / STD 0064]– monitoring quality of service– convey participant status information
KU EECS 780 – Communication Networks – End-to-End Transport
– 99 –
21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-197
© James P.G. SterbenzITTC
Internet Transport ProtocolsTL.3.3 TCP
TL.1 Transport services and interfacesTL.2 end-to-end functions and mechanismsTL.3 Internet transport protocols
TL.3.1 UDPTL.3.2 RTP introductionTL.3.3 TCP
TL.4 Multipoint communication and reliable multicast
21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-198
© James P.G. SterbenzITTC
Transmission Control ProtocolOverview
• TCP: transmission control protocolRFC 0793 / STD 0007+ RFC 1122 implementation requirements+ RFC 1323 high performance extensions+ RFC 2018 SACK (selective acknowledgements)+ RFC 2581 congestion control+ RFC 3168 ECN (explicit congestion notification)
• IANA defines name/number space for some fields– Internet Assigned Numbers Authority: www.iana.org/numbers.html
– protocol types for IP (TCP = 06)– option kinds– well known port numbers
KU EECS 780 – Communication Networks – End-to-End Transport
– 100 –
21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-199
© James P.G. SterbenzITTC
Transmission Control ProtocolTransfer 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-200
© James P.G. SterbenzITTC
Transmission Control ProtocolSegment Format: Overview1
• Relatively large header– fixed length & position fields– variable length options– header length4b in Bytes
• = 40 + |options| B
• Variable length payload• Options
– may not be present(details later)
• Checksum on entire segment– same algorithm as UDP
checksum urg data pointerreceive window
ack numbersequence number
dest port #source port #
[options (variable length)]
applicationpayload
(variable length)
flagsHL
32 bits
HL
KU EECS 780 – Communication Networks – End-to-End Transport
– 101 –
21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-201
© James P.G. SterbenzITTC
Transmission Control ProtocolSegment Format: Overview2
• 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)
checksum urg data pointerreceive window
ack numbersequence number
dest port #source port #
options (variable length)
applicationpayload
(variable length)
HL
32 bits
CEUAPRSF
URG
ACK
PSH
RST
SYN
FIN
ECE
CWR
21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-202
© James P.G. SterbenzITTC
Transmission Control ProtocolSegment Format: No Options
• Header with no options– 20B long
checksum urg data pointerreceive window
ack numbersequence number
dest port #source port #
applicationpayload
(variable length)
flags20
32 bits
20B
KU EECS 780 – Communication Networks – End-to-End Transport
– 102 –
21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-203
© James P.G. SterbenzITTC
Transmission Control ProtocolSegment Format: No Options Nor Data
• Entire segment– 20B long
• Example:– ACKs– significant fraction
of Internet packets40Bwhy?
checksum urg data pointerreceive window
ack numbersequence number
dest port #source port #
flags20
32 bits
20B
21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-204
© James P.G. SterbenzITTC
Transmission Control ProtocolSegment Format: Options
• Options– standardised extensions– experimental use
• Used for– control: negotiation in SYN– data: alternate processing
• Format (max 40B total)– kind1B (assigned by IANA)– length1B
– option fields (variable)
checksum urg data pointerreceive window
ack numbersequence number
dest port #source port #
options (variable length)
applicationpayload
(variable length)
flagsHL
32 bits
20B
≤40B
KU EECS 780 – Communication Networks – End-to-End Transport
– 103 –
21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-205
© James P.G. SterbenzITTC
Transmission Control ProtocolSelected Options
• Selected TCP options http://www.iana.org/assignments/tcp‐parameters00 end of option list01 no operation (for padding)02 MSS (max. segment size)03 window scale factor04 SACK permitted05 SACK blocks08 timestamp
21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-206
© James P.G. SterbenzITTC
Transmission Control ProtocolSegment Format: Multiplexing
• Socket: 5-tuple– ⟨sp, sa, dp, da, prot⟩
• Sender multiplexing– assign source port #– network: IP address
• Receiver demultiplexing– network: IP address– IP: protocol #
• UDP = 17• TCP = 06
– TCP: destination port #determines receiving app
checksum urg data pointerreceive window
ack numbersequence number
dest port #source port #
options (variable length)
applicationpayload
(variable length)
flagsHL
KU EECS 780 – Communication Networks – End-to-End Transport
– 104 –
21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-207
© James P.G. SterbenzITTC
Transmission Control ProtocolMultiplexing
• Interface to IP: protocol mux/demux (TCP = 06)• Interface to application: port mux/demux
app iTCPport n
app jTCPport x
TCPport y
UDPport z
TCP TCP UDP
transport demux (IP protocol id)
port demux
network demux (IP address)
pd pd
06 17
21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-208
© James P.G. SterbenzITTC
Transmission Control ProtocolConnection Management: Segment Format
• Flags define segment type– ACK segment
• ACK for SYN or FIN• SYNACK may be
piggybacked• ACK for data
– RST (reset) segment• e.g. bad port received
– SYN (synchronise) segment• connection setup
– FIN (finish) segment• connection release
checksum urg data pointerreceive window
ACK numbersequence number
dest port #source port #
options (variable length)
applicationpayload
(variable length)
CEUAPRSFHL
KU EECS 780 – Communication Networks – End-to-End Transport
– 105 –
21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-209
© James P.G. SterbenzITTC
data segments
data segments
Transmission Control ProtocolConnection Management: Setup
• Three way handshake– “client” and “server”1. SYN (init seq#) →
• randomised for security2. ← SYNACK (init seq#)
• randomised for security• after buffer allocation• SYN flood vulnerability
3. ACK →– buffer allocation– segment may include data– client may send more
4. server may return data
net
SYN (ISNs)
ACK
SYN(ISNc)ACK
FIN
ACK
FIN
ACK
bufferalloc
bufferalloc
estab.state
C S
21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-210
© James P.G. SterbenzITTC
data segments
data segments
Transmission Control ProtocolConnection Management: Teardown
• Two two-way handshakes– each independent half-close– may occur simultaneously
• full close– ACK can’t be piggybacked
• Client closes socket1. FIN →2. ← ACK– timed wait before close
• Server closes socket1. ← FIN2. ACK →
net
SYN
ACK
SYNACK
FIN
ACK
FIN
ACK
bufferfree
bufferfree
C S
twait
closed
KU EECS 780 – Communication Networks – End-to-End Transport
– 106 –
21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-211
© James P.G. SterbenzITTC
Transmission Control ProtocolRFC 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 NET-TL-212
© James P.G. SterbenzITTC
Transmission Control ProtocolActual Connection State Machine
[Sewell] http://www.cl.cam.ac.uk/users/pes20/Netsem
KU EECS 780 – Communication Networks – End-to-End Transport
– 107 –
21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-213
© James P.G. SterbenzITTC
Transmission Control ProtocolSegment 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• Receive window
– # unACKed bytes
checksum urg data pointerreceive window
ACK numbersequence number
dest port #source port #
options (variable length)
applicationpayload
(variable length)
HL CEUAPRSF
21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-214
© James P.G. SterbenzITTC
Transmission Control ProtocolUnidirectional Data Transfer
net
SYN (ISNs)
ACK
SYN(ISNc)ACK
C S
1
• Data is sequence of bytes– number by byte #
(not segment #)
KU EECS 780 – Communication Networks – End-to-End Transport
– 108 –
21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-215
© James P.G. SterbenzITTC
data segment (MSS bytes)SN=?
Transmission Control ProtocolUnidirectional Data Transfer
net
SYN (ISNs)
ACK
SYN(ISNc)ACK
C S
2
• Data is sequence of bytes– number by byte #
(not segment #)– each segment ≤ MSS B
• Sequence numbers– byte # in byte stream
of 1st byte in segment
21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-216
© James P.G. SterbenzITTC
data segment (MSS bytes)SN=ISNs
Transmission Control ProtocolUnidirectional Data Transfer
net
SYN (ISNs)
ACK
SYN(ISNc)ACK
C S
ACK AN=?
3
• Data is sequence of bytes– number by byte #
(not segment #)– each segment ≤ MSS B
• Sequence numbers– byte # in byte stream
of 1st byte in segment
• ACK numbers– seq # of next byte expected
KU EECS 780 – Communication Networks – End-to-End Transport
– 109 –
21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-217
© James P.G. SterbenzITTC
data segment (MSS bytes)SN=ISNs
Transmission Control ProtocolUnidirectional Data Transfer
net
SYN (ISNs)
ACK
SYN(ISNc)ACK
C S
ACK AN=ISNs+MSS
data segment (MSS bytes)SN=?
4
• Data is sequence of bytes– number by byte #
(not segment #)– each segment ≤ MSS B
• Sequence numbers– byte # in byte stream
of 1st byte in segment
• ACK numbers– seq # of next byte expected
21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-218
© James P.G. SterbenzITTC
data segment (MSS bytes)SN=ISNs
Transmission Control ProtocolUnidirectional Data Transfer
net
SYN (ISNs)
ACK
SYN(ISNc)ACK
C S
ACK AN=ISNs+MSS
data segment (MSS bytes)SN=ISNs+MSS
ACK AN=?
5
• Data is sequence of bytes– number by byte #
(not segment #)– each segment ≤ MSS B
• Sequence numbers– byte # in byte stream
of 1st byte in segment
• ACK numbers– seq # of next byte expected– cumulative ACKs
KU EECS 780 – Communication Networks – End-to-End Transport
– 110 –
21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-219
© James P.G. SterbenzITTC
data segment (MSS bytes)SN=ISNs
Transmission Control ProtocolUnidirectional Data Transfer
net
SYN (ISNs)
ACK
SYN(ISNc)ACK
C S
ACK AN=ISNs+MSS
data segment (MSS bytes)SN=ISNs+MSS
ACK AN=ISNs+2MSS
6what next?
• Data is sequence of bytes– number by byte #
(not segment #)– each segment ≤ MSS B
• Sequence numbers– byte # in byte stream
of 1st byte in segment
• ACK numbers– seq # of next byte expected– cumulative ACKs
21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-220
© James P.G. SterbenzITTC
data segment (MSS bytes)SN=ISNs+2MSS
data segment (MSS bytes)SN=ISNs
Transmission Control ProtocolUnidirectional Data Transfer
net
SYN (ISNs)
ACK
SYN(ISNc)ACK
C S
ACK AN=ISNs+MSS
data segment (MSS bytes)SN=ISNs+MSS
ACK AN=ISNs+2MSS
7what next?
• Data is sequence of bytes– number by byte #
(not segment #)– each segment ≤ MSS B
• Sequence numbers– byte # in byte stream
of 1st byte in segment
• ACK numbers– seq # of next byte expected– cumulative ACKs
KU EECS 780 – Communication Networks – End-to-End Transport
– 111 –
21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-221
© James P.G. SterbenzITTC
data segment (MSS bytes)SN=ISNs+2MSS
data segment (MSS bytes)SN=ISNs
Transmission Control ProtocolUnidirectional Data Transfer
net
SYN (ISNs)
ACK
SYN(ISNc)ACK
C S
ACK AN=ISNs+MSS
data segment (MSS bytes)SN=ISNs+MSS
ACK AN=ISNs+2MSS
8ACK AN=ISNs+3MSS
• Data is sequence of bytes– number by byte #
(not segment #)– each segment ≤ MSS B
• Sequence numbers– byte # in byte stream
of 1st byte in segment
• ACK numbers– seq # of next byte expected– cumulative ACKs
• Out of order arrival– implementation specific
21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-222
© James P.G. SterbenzITTC
data segment (MSS bytes)SN=ISNs
Transmission Control ProtocolBidirectional Data Transfer
net
SYN (ISNs)
ACK
SYN(ISNc)ACK
C S
ACK AN=ISNs+MSS
1what next?
• Data both directions– ACKs returned both ways
KU EECS 780 – Communication Networks – End-to-End Transport
– 112 –
21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-223
© James P.G. SterbenzITTC
data segment (MSS bytes)SN=ISNc
data segment (MSS bytes)SN=ISNs
Transmission Control ProtocolBidirectional Data Transfer
net
SYN (ISNs)
ACK
SYN(ISNc)ACK
C S
ACK AN=ISNs+MSS
2what next?
• Data both directions– ACKs returned both ways– may be piggybacked
21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-224
© James P.G. SterbenzITTC
data segment (MSS bytes)SN=ISNc
data segment (MSS bytes)SN=ISNs
Transmission Control ProtocolBidirectional Data Transfer
net
SYN (ISNs)
ACK
SYN(ISNc)ACK
C S
ACK AN=ISNs+MSS
3
data segment (MSS bytes)SN=ISNs+MSS
ACK AN=ISNc+MSS
what next?
• Data both directions– ACKs returned both ways– may be piggybacked– delayed ACK waits briefly
KU EECS 780 – Communication Networks – End-to-End Transport
– 113 –
21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-225
© James P.G. SterbenzITTC
data segment (MSS bytes)SN=ISNc
data segment (MSS bytes)SN=ISNs
Transmission Control ProtocolBidirectional Data Transfer
net
SYN (ISNs)
ACK
SYN(ISNc)ACK
C S
ACK AN=ISNs+MSS
4
data segment (MSS bytes)SN=ISNs+MSS
ACK AN=ISNc+MSS
• Data both directions– ACKs returned both ways– may be piggybacked– delayed ACK waits briefly
• Bidirectional stream– data segments– piggybacked ACKs
21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-226
© James P.G. SterbenzITTC
Transmission Control ProtocolSegment Format: Push
• Push– PSH flag set– receiver should immediately
send to application– don’t wait to fill buffer– example use: telnet
• avoid buffering delay
checksum urg data ptrreceive window
ACK numbersequence number
dest port #source port #
options (variable length)
applicationpayload
(variable length)
CEUAPRSFHL
KU EECS 780 – Communication Networks – End-to-End Transport
– 114 –
21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-227
© James P.G. SterbenzITTC
Transmission Control ProtocolSegment Format: Urgent Mode
• Urgent mode– URG flag set, urgent pointer
• Urgent data range– sn + up points to last byte
• Example uses– interrupt for telnet, rlogin– FTP abort
why?
checksum urg data ptrreceive window
ACK numbersequence number
dest port #source port #
options (variable length)
applicationpayload
(variable length)
CEUAPRSFHL
21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-228
© James P.G. SterbenzITTC
Transmission Control ProtocolWindow-Based Feedback Control
• Windowing used for a combined:– error control– flow control– congestion control
• Window limits amount of unACKed data transmitted
KU EECS 780 – Communication Networks – End-to-End Transport
– 115 –
21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-229
© James P.G. SterbenzITTC
Transmission Control ProtocolError 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 NET-TL-230
© James P.G. SterbenzITTC
Transmission Control ProtocolError 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)
KU EECS 780 – Communication Networks – End-to-End Transport
– 116 –
21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-231
© James P.G. SterbenzITTC
Transmission Control ProtocolSegment 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
– each block:• seq num of 1st byte• seq num of last byte +1
– ACK semantics unchanged
checksum urg data pointerreceive window
ack numbersequence number
dest port #source port #
applicationpayload
(variable length)
flagsHL
32 bits
seq num after last byteseq num of 1st byte
05 len0101
21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-232
© James P.G. SterbenzITTC
Transmission Control ProtocolError 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
KU EECS 780 – Communication Networks – End-to-End Transport
– 117 –
21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-233
© James P.G. SterbenzITTC
Transmission Control ProtocolTimeout
How to set TCP timeout value?
21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-234
© James P.G. SterbenzITTC
Transmission Control ProtocolTimeout
• 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?
KU EECS 780 – Communication Networks – End-to-End Transport
– 118 –
21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-235
© James P.G. SterbenzITTC
Transmission Control ProtocolTimeout
• 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 NET-TL-236
© James P.G. SterbenzITTC
Transmission Control ProtocolRound 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
KU EECS 780 – Communication Networks – End-to-End Transport
– 119 –
21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-237
© James P.G. SterbenzITTC
Transmission Control ProtocolRTT Estimate Example
RTT: gaia.cs.umass.edu to fantasia.eurecom.fr
100
150
200
250
300
350
1 8 15 22 29 36 43 50 57 64 71 78 85 92 99 106
time (seconds)
RTT
(milli
seco
nds)
SampleRTT Estimated RTT
21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-238
© James P.G. SterbenzITTC
Transmission Control ProtocolFast 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
KU EECS 780 – Communication Networks – End-to-End Transport
– 120 –
21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-239
© James P.G. SterbenzITTC
data inbuffer
spareroom
Transmission Control ProtocolFlow 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
from IP to application
RcvWindow
21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-240
© James P.G. SterbenzITTC
Transmission Control ProtocolCongestion 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
KU EECS 780 – Communication Networks – End-to-End Transport
– 121 –
21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-241
© James P.G. SterbenzITTC
Transmission Control ProtocolCongestion Control
• Initialisation phase: slow start• Steady-state phase: AIMD
AI
time
MD
send
ing
rate
slow start
steady state phase initialisation
congestion detection
21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-242
© James P.G. SterbenzITTC
Transmission Control ProtocolCongestion 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
KU EECS 780 – Communication Networks – End-to-End Transport
– 122 –
21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-243
© James P.G. SterbenzITTC
Transmission Control ProtocolExplicit Congestion Notification
• Network nodes setcongestion indication– hist. ICMP source quench– ECN bits in IP header
• TCP reacts– uses flags for signalling
more in lecture TQ
checksum urg data pointerreceive window
ACK numbersequence number
dest port #source port #
options (variable length)
applicationpayload
(variable length)
CEUAPRSFHL
21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-244
© James P.G. SterbenzITTC
Transmission Control ProtocolCongestion 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
KU EECS 780 – Communication Networks – End-to-End Transport
– 123 –
21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-245
© James P.G. SterbenzITTC
Transmission Control ProtocolHigh-Bandwidth-×-Delay Optimisations
• High bandwidth-×-delay paths (long fat pipes)problem?
21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-246
© James P.G. SterbenzITTC
Transmission Control ProtocolHigh-Bandwidth-×-Delay Optimisations
• High bandwidth-×-delay paths (long fat pipes)– problem: large number of bits in flight
Implications to TCP?
KU EECS 780 – Communication Networks – End-to-End Transport
– 124 –
21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-247
© James P.G. SterbenzITTC
Transmission Control ProtocolHigh-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 NET-TL-248
© James P.G. SterbenzITTC
Transmission Control ProtocolHigh-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
KU EECS 780 – Communication Networks – End-to-End Transport
– 125 –
21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-249
© James P.G. SterbenzITTC
Transport LayerTL.4 Multipoint Communication
TL.1 Transport services and interfacesTL.2 End-to-end functions and mechanismsTL.3 Internet transport protocolsTL.4 Multipoint communication and reliable multicast
21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-250
© James P.G. SterbenzITTC
E2E Multipoint CommunicationMotivation for E2E Multicast
• End-to-end multicast is necessary if:• Network layer multicast not available
why?
• Reliability is neededwhy?
KU EECS 780 – Communication Networks – End-to-End Transport
– 126 –
21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-251
© James P.G. SterbenzITTC
E2E Multipoint CommunicationMotivation 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 multicastapplication-layer multicast
21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-252
© James P.G. SterbenzITTC
E2E Multipoint CommunicationClosed Loop Retransmission: Multicast
• ACK implosion: ACK suppression neededo NAKs (negative ACKs) with liveness pollingo localised hop-by-hop buffering and retransmission– significant reduction of traffic on relatively reliable links
R
6
ACK
ACK×2ACK×2
ACK×4
ACKACK×6
R
6
NAK
NAK
NAK
NAK×2
31 2 4 31 2 4
ACKACK
ACK
5ACK
NAK
5NAK
KU EECS 780 – Communication Networks – End-to-End Transport
– 127 –
21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-253
© James P.G. SterbenzITTC
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 NET-TL-254
© James P.G. SterbenzITTC
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 toHigh-Bandwidth Low-Latency Communicationhttp://hsn‐book.sterbenz.org