Page 1
© James P.G. SterbenzITTC
25 September 2018 © 2004–2018 James P.G. Sterbenzrev. 18.1
Introduction to Communication NetworksThe University of Kansas EECS 563
End-to-End Transport
James P.G. Sterbenz
Department of Electrical Engineering & Computer Science
Information Technology & Telecommunications Research Center
The University of Kansas
[email protected]
http://www.ittc.ku.edu/~jpgs/courses/intronets
Page 2
© James P.G. SterbenzITTC
25 September 2018 KU EECS 563 – Intro Comm Nets – E2E Transport ICN-TL-2
End-to-End TransportOutline
TL.1 Transport services and interfaces
TL.2 End-to-end functions and mechanisms
TL.3 Internet transport protocols
Page 3
© James P.G. SterbenzITTC
25 September 2018 KU EECS 563 – Intro Comm Nets – E2E Transport ICN-TL-3
End-to-End TransportServices and Interfaces
TL.1 Transport services and interfaces
TL.2 End-to-end functions and mechanisms
TL.3 Internet transport protocols
Page 4
© James P.G. SterbenzITTC
25 September 2018 KU EECS 563 – Intro Comm Nets – E2E Transport ICN-TL-4
Transport LayerHybrid Layer/Plane Cube
Layer 4:
end-to-end
data transfer
in data and control planes
physical
MAC
link
network
transport
session
application
L1
L7
L5
L4
L3
L2
L1.5
data plane control plane
p
l
a
n
e
management
socialL8
virtual linkL2.5
Page 5
© James P.G. SterbenzITTC
25 September 2018 KU EECS 563 – Intro Comm Nets – E2E Transport ICN-TL-5
Transport LayerMotivation
Why do we need a transport protocol?
Mapp
Mapp
ES1
CPU
ES2
CPU
Page 6
© James P.G. SterbenzITTC
25 September 2018 KU EECS 563 – Intro Comm Nets – E2E Transport ICN-TL-6
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
Page 7
© James P.G. SterbenzITTC
25 September 2018 KU EECS 563 – Intro Comm Nets – E2E Transport ICN-TL-7
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
Page 8
© James P.G. SterbenzITTC
25 September 2018 KU EECS 563 – Intro Comm Nets – E2E Transport ICN-TL-8
Transport LayerTransport Association Definition
• Transport association between end systems– transport flow
• particularly in the case of soft state or stateless
– transport connection in the case of connection state
networkCPU
M app
end system
intermediate
systemCPU
M app
end system
Page 9
© James P.G. SterbenzITTC
25 September 2018 KU EECS 563 – Intro Comm Nets – E2E Transport ICN-TL-9
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
intermediate
system
network
link
intermediate
systemnetwork
link
intermediate
system
application
session
transport
network
link
end system
Page 10
© James P.G. SterbenzITTC
25 September 2018 KU EECS 563 – Intro Comm Nets – E2E Transport ICN-TL-10
Transport LayerService and Interfaces1
• Transport layer (L4) service to application layer (L7)
• Transfer PDU (protocol data unit) 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
Page 11
© James P.G. SterbenzITTC
25 September 2018 KU EECS 563 – Intro Comm Nets – E2E Transport ICN-TL-11
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?
Page 12
© James P.G. SterbenzITTC
25 September 2018 KU EECS 563 – Intro Comm Nets – E2E Transport ICN-TL-12
Transport LayerService and Interfaces3
• 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: low error rate, ordered delivery
– strong and symmetric connectivity
Internet assumptions & service model
Page 13
© James P.G. SterbenzITTC
25 September 2018 KU EECS 563 – Intro Comm Nets – E2E Transport ICN-TL-13
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
Page 14
© James P.G. SterbenzITTC
25 September 2018 KU EECS 563 – Intro Comm Nets – E2E Transport ICN-TL-14
Transport LayerFunctional Placement
• Transport layer functionality only in end system
– host software or
– sometimes offloaded to network interface (NIC) EECS 881
switch
TPDUs
end system
network interface
mem CPU
frames
end system
network interface
memCPU
framespacket
Page 15
© James P.G. SterbenzITTC
25 September 2018 KU EECS 563 – Intro Comm Nets – E2E Transport ICN-TL-15
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 per-link hops
Page 16
© James P.G. SterbenzITTC
25 September 2018 KU EECS 563 – Intro Comm Nets – E2E Transport ICN-TL-16
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 (only) in the network is not possible
paraphrased from [Saltzer, Reed, Clark 1981]
Page 17
© James P.G. SterbenzITTC
25 September 2018 KU EECS 563 – Intro Comm Nets – E2E Transport ICN-TL-17
End-to-End vs. Hop-by-HopEnd-to-End Arguments
• Hop-by-Hop functions do not compose end-to-end
why?
f -1
f
f1 f3-1
f3 f2-1
f2 f1-1
g g g g
Page 18
© James P.G. SterbenzITTC
25 September 2018 KU EECS 563 – Intro Comm Nets – E2E Transport ICN-TL-18
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-1
f3 f2-1
f2 f1-1
g g g g
Page 19
© James P.G. SterbenzITTC
25 September 2018 KU EECS 563 – Intro Comm Nets – E2E Transport ICN-TL-19
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]
Page 20
© James P.G. SterbenzITTC
25 September 2018 KU EECS 563 – Intro Comm Nets – E2E Transport ICN-TL-20
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
Page 21
© James P.G. SterbenzITTC
25 September 2018 KU EECS 563 – Intro Comm Nets – E2E Transport ICN-TL-21
End-to-End vs. Hop-by-HopPerformance Enhancement Example1
• E2E vs. HBH error control for reliable communication– E2E argument says error control must be done E2E
• e.g. E2E ARQ (error check code and retransmit if necessary
– but should HBH error control also be done?
100 m
wireless LANUniv. Kansas
100 m
fiber LANHK PolyU
15 000 km
fiber WAN
Page 22
© James P.G. SterbenzITTC
25 September 2018 KU EECS 563 – Intro Comm Nets – E2E Transport ICN-TL-22
End-to-End vs. Hop-by-HopPerformance Enhancement Example2
• 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
100 m
wireless LANUniv. Kansas
100 m
fiber LANHK PolyU
15 000 km
fiber WAN
Page 23
© James P.G. SterbenzITTC
25 September 2018 KU EECS 563 – Intro Comm Nets – E2E Transport ICN-TL-23
End-to-End vs. Hop-by-HopPerformance Enhancement Example3
• 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? Yes!
• 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 m
wireless LANUniv. Kansas
100 m
fiber LANHK PolyU
15 000 km
fiber WAN
Page 24
© James P.G. SterbenzITTC
25 September 2018 KU EECS 563 – Intro Comm Nets – E2E Transport ICN-TL-24
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
Page 25
© James P.G. SterbenzITTC
25 September 2018 KU EECS 563 – Intro Comm Nets – E2E Transport ICN-TL-25
End-to-End TransportFunctions and Mechanisms
TL.1 Transport services and interfaces
TL.2 End-to-end functions and mechanisms
TL.3 Internet transport protocols
Page 26
© James P.G. SterbenzITTC
25 September 2018 KU EECS 563 – Intro Comm Nets – E2E Transport ICN-TL-26
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)
– error check (CRC or checksum) for reliability
Page 27
© James P.G. SterbenzITTC
25 September 2018 KU EECS 563 – Intro Comm Nets – E2E Transport ICN-TL-27
E2E MultiplexingConcepts
• Multiple applications use a particular TP
• Applications multiplexed into sending TP
– need to identify which application
why?
Page 28
© James P.G. SterbenzITTC
25 September 2018 KU EECS 563 – Intro Comm Nets – E2E Transport ICN-TL-28
E2E MultiplexingConcepts
• Multiple applications use a particular TP
• Applications multiplexed into sending TP
– need to identify which application
– using identifier typically called a port
• TP demultiplexes TPDU (segment)
– sending to correct application
– using port number
Page 29
© James P.G. SterbenzITTC
25 September 2018 KU EECS 563 – Intro Comm Nets – E2E Transport ICN-TL-29
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
Page 30
© James P.G. SterbenzITTC
25 September 2018 KU EECS 563 – Intro Comm Nets – E2E Transport ICN-TL-30
E2E Transfer ModesAlternatives
• End-to-end transfer modes– datagram
– connection
– stream
– transaction
Page 31
© James P.G. SterbenzITTC
25 September 2018 KU EECS 563 – Intro Comm Nets – E2E Transport ICN-TL-31
E2E Transfer ModesDatagram
• Independent PDUs– each has fully self-describing header
– no end-to-end flow state needed to forward
tp+td
Page 32
© James P.G. SterbenzITTC
25 September 2018 KU EECS 563 – Intro Comm Nets – E2E Transport ICN-TL-32
E2E Transfer Modes Connection
• Explicit connection setup– 3-way handshake
SETUP / CONNECT / ACK
why?
~tRTT
ACK
RELEASE
CONNECT
SETUP
~1.5tRTT
~tRTT
tr
Page 33
© James P.G. SterbenzITTC
25 September 2018 KU EECS 563 – Intro Comm Nets – E2E Transport ICN-TL-33
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
Page 34
© James P.G. SterbenzITTC
25 September 2018 KU EECS 563 – Intro Comm Nets – E2E Transport ICN-TL-34
E2E Transfer Modes Connection State Machine
• ConnectionState Machine– send/receive paths
• States– idle
– establishing
• install state
– initialising• state
convergence
– steady state
– closing• release state
initialising
idle
steady state-
closing closing
establishing
CONNECT
from net
requested
receive
SETUP
from net
originate
SETUP
request
issue
CONNECT
ACK
from net
RELEASE
from net
RELEASE
from app
issue
SETUP
issue
RELEASE
issue
RELEASE
Page 35
© James P.G. SterbenzITTC
25 September 2018 KU EECS 563 – Intro Comm Nets – E2E Transport ICN-TL-35
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
Page 36
© James P.G. SterbenzITTC
25 September 2018 KU EECS 563 – Intro Comm Nets – E2E Transport ICN-TL-36
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
Page 37
© James P.G. SterbenzITTC
25 September 2018 KU EECS 563 – Intro Comm Nets – E2E Transport ICN-TL-37
E2E Error ControlTypes of Errors
What are the types of errors?
Page 38
© James P.G. SterbenzITTC
25 September 2018 KU EECS 563 – Intro Comm Nets – E2E Transport ICN-TL-38
E2E Error ControlTypes of Errors
• Bit errors
types?
• Packet errors
types?
Page 39
© James P.G. SterbenzITTC
25 September 2018 KU EECS 563 – Intro Comm Nets – E2E Transport ICN-TL-39
E2E Error ControlTypes of Errors
• Bit errors
• Packet errors
– packet loss
– fragment loss
– burst loss
– packet misordering
– packet insertion
– packet duplication
Page 40
© James P.G. SterbenzITTC
25 September 2018 KU EECS 563 – Intro Comm Nets – E2E Transport ICN-TL-40
E2E Error ControlCauses of Bit Errors
• Bit errors
causes?
Page 41
© James P.G. SterbenzITTC
25 September 2018 KU EECS 563 – Intro Comm Nets – E2E Transport ICN-TL-41
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
Page 42
© James P.G. SterbenzITTC
25 September 2018 KU EECS 563 – Intro Comm Nets – E2E Transport ICN-TL-42
E2E Error ControlCauses of Packet Loss
• Packet loss
causes?
Page 43
© James P.G. SterbenzITTC
25 September 2018 KU EECS 563 – Intro Comm Nets – E2E Transport ICN-TL-43
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
Page 44
© James P.G. SterbenzITTC
25 September 2018 KU EECS 563 – Intro Comm Nets – E2E Transport ICN-TL-44
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?
Page 45
© James P.G. SterbenzITTC
25 September 2018 KU EECS 563 – Intro Comm Nets – E2E Transport ICN-TL-45
E2E Error ControlCauses of Packet Loss
• Packet loss
– network buffer overflow or intentional drop
– transport protocol packet discard when bit error
Page 46
© James P.G. SterbenzITTC
25 September 2018 KU EECS 563 – Intro Comm Nets – E2E Transport ICN-TL-46
E2E Error ControlCauses of Packet Burst Loss
• Packet burst loss
causes?
Page 47
© James P.G. SterbenzITTC
25 September 2018 KU EECS 563 – Intro Comm Nets – E2E Transport ICN-TL-47
E2E Error ControlCauses of Packet Burst Loss
• Packet burst loss
– network buffer overflow during congestion
• with high rate flow having adjacent (non-interleaved) packets
– wireless channel fades
more in lecture PL
Page 48
© James P.G. SterbenzITTC
25 September 2018 KU EECS 563 – Intro Comm Nets – E2E Transport ICN-TL-48
E2E Error ControlCauses of Packet Misordering
• Packet misorderingcauses?
Page 49
© James P.G. SterbenzITTC
25 September 2018 KU EECS 563 – Intro Comm Nets – E2E Transport ICN-TL-49
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
Page 50
© James P.G. SterbenzITTC
25 September 2018 KU EECS 563 – Intro Comm Nets – E2E Transport ICN-TL-50
E2E Error ControlCauses of Packet Insertion
• Packet insertionmeaning?
causes?
Page 51
© James P.G. SterbenzITTC
25 September 2018 KU EECS 563 – Intro Comm Nets – E2E Transport ICN-TL-51
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
Page 52
© James P.G. SterbenzITTC
25 September 2018 KU EECS 563 – Intro Comm Nets – E2E Transport ICN-TL-52
E2E Error ControlCauses of Packet Duplication
• Packet duplicationcauses?
Page 53
© James P.G. SterbenzITTC
25 September 2018 KU EECS 563 – Intro Comm Nets – E2E Transport ICN-TL-53
E2E Error ControlCauses of Packet Duplication
• Packet duplication
– retransmission but original still arrives
Page 54
© James P.G. SterbenzITTC
25 September 2018 KU EECS 563 – Intro Comm Nets – E2E Transport ICN-TL-54
E2E Error ControlARQ Closed Loop Retransmission
• Automatic repeat request (ARQ)
– TPDUs are retransmitted for reliable transfer
• Acknowledgments are used to request retransmission
alternatives?
Page 55
© James P.G. SterbenzITTC
25 September 2018 KU EECS 563 – Intro Comm Nets – E2E Transport ICN-TL-55
E2E Error ControlARQ Closed Loop Retransmission
• Automatic repeat request (ARQ)
– TPDUs are retransmitted for reliable transfer
• Acknowledgments are used to request retransmission
– ACK: positive acknowledgement
– NAK (or NACK): negative acknowledgement
tradeoff?
Page 56
© James P.G. SterbenzITTC
25 September 2018 KU EECS 563 – Intro Comm Nets – E2E Transport ICN-TL-56
E2E Error ControlARQ Closed Loop Retransmission
• Automatic repeat request (ARQ)
– TPDUs 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?
Page 57
© James P.G. SterbenzITTC
25 September 2018 KU EECS 563 – Intro Comm Nets – E2E Transport ICN-TL-57
0
E2E Error ControlClosed Loop Retransmission: Stop-and-Wait
• Each TPDU is acknowledged
1
Page 58
© James P.G. SterbenzITTC
25 September 2018 KU EECS 563 – Intro Comm Nets – E2E Transport ICN-TL-58
E2E Error ControlClosed Loop Retransmission: Stop-and-Wait
• Each TPDU is acknowledged0
0
2
Page 59
© James P.G. SterbenzITTC
25 September 2018 KU EECS 563 – Intro Comm Nets – E2E Transport ICN-TL-59
E2E Error ControlClosed Loop Retransmission: Stop-and-Wait
• Each TPDU is acknowledged
– subsequent TPDU waits on previous ACK
disadvantages?
0
0
3
A0
Page 60
© James P.G. SterbenzITTC
25 September 2018 KU EECS 563 – Intro Comm Nets – E2E Transport ICN-TL-60
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
Page 61
© James P.G. SterbenzITTC
25 September 2018 KU EECS 563 – Intro Comm Nets – E2E Transport ICN-TL-61
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
issues?
0
0
A0
1tack
5
Page 62
© James P.G. SterbenzITTC
25 September 2018 KU EECS 563 – Intro Comm Nets – E2E Transport ICN-TL-62
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
Page 63
© James P.G. SterbenzITTC
25 September 2018 KU EECS 563 – Intro Comm Nets – E2E Transport ICN-TL-63
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
Page 64
© James P.G. SterbenzITTC
25 September 2018 KU EECS 563 – Intro Comm Nets – E2E Transport ICN-TL-64
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
Page 65
© James P.G. SterbenzITTC
25 September 2018 KU EECS 563 – Intro Comm Nets – E2E Transport ICN-TL-65
E2E Error ControlClosed Loop Retransmission: Go-Back-n
• Go-back-n : pipeline transmissions0
1
Page 66
© James P.G. SterbenzITTC
25 September 2018 KU EECS 563 – Intro Comm Nets – E2E Transport ICN-TL-66
E2E Error ControlClosed Loop Retransmission: Go-Back-n
• Go-back-n : pipeline transmissions
+ multiple TPDUs simultaneously in flight 0
0
2
1
A0
Page 67
© James P.G. SterbenzITTC
25 September 2018 KU EECS 563 – Intro Comm Nets – E2E Transport ICN-TL-67
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
Page 68
© James P.G. SterbenzITTC
25 September 2018 KU EECS 563 – Intro Comm Nets – E2E Transport ICN-TL-68
3
2
E2E Error ControlClosed Loop Retransmission: Go-Back-n
• Go-back-n : pipeline transmissions
+ multiple TPDUs simultaneously in flight
• TPDUs are sequentially acknowledged
how is TPDU loss detected?
0
0
4
1
A0
1
A1
tack
Page 69
© James P.G. SterbenzITTC
25 September 2018 KU EECS 563 – Intro Comm Nets – E2E Transport ICN-TL-69
4
3
2
E2E Error ControlClosed Loop Retransmission: Go-Back-n
• Go-back-n : pipeline transmissions
+ multiple TPDUs simultaneously in flight
• TPDUs are sequentially acknowledged
o previous ACK retransmitted for
• subsequent TPDUs after loss
• out of sequence TPDU
0
0
5
1
A0
1
A1
tack
A1
Page 70
© James P.G. SterbenzITTC
25 September 2018 KU EECS 563 – Intro Comm Nets – E2E Transport ICN-TL-70
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 acknowledged
o previous ACK retransmitted for
• subsequent TPDUs after loss
• out of sequence TPDU
o sender timer fires if ACK not received
implication?
0
0
6
1
A0
1
A1
tack
A1
A1
Page 71
© James P.G. SterbenzITTC
25 September 2018 KU EECS 563 – Intro Comm Nets – E2E Transport ICN-TL-71
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 acknowledged
o previous ACK retransmitted for
• subsequent TPDUs after loss
• out of sequence TPDU
o sender timer fires if ACK not received
• reset transmission beginning at lost TPDU
0
0
7
1
A0
1
A1
tack
A1
A1
A1
Page 72
© James P.G. SterbenzITTC
25 September 2018 KU EECS 563 – Intro Comm Nets – E2E Transport ICN-TL-72
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 acknowledged
o previous ACK retransmitted for
• subsequent TPDUs after loss
• out of sequence TPDU
o sender timer fires if ACK not received
• reset transmission beginning at lost TPDU
0
0
8
1
A0
1
A1
tack
A1
A1
A1 2
Page 73
© James P.G. SterbenzITTC
25 September 2018 KU EECS 563 – Intro Comm Nets – E2E Transport ICN-TL-73
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 acknowledged
o previous ACK retransmitted for
• subsequent TPDUs after loss
• out of sequence TPDU
o sender timer fires if ACK not received
• reset transmission beginning at lost TPDUs
0
0
9
1
A0
1
A1
tack
A1
A1
A1 2
3
A3
Page 74
© James P.G. SterbenzITTC
25 September 2018 KU EECS 563 – Intro Comm Nets – E2E Transport ICN-TL-74
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 acknowledged
o previous ACK retransmitted for
• subsequent TPDUs after loss
• out of sequence TPDU
o sender timer fires if ACK not received
• reset transmission beginning at lost TPDU
0
0
10
1
A0
1
A1
tack
A1
A1
A1 2
3
A3
A4
4
Page 75
© James P.G. SterbenzITTC
25 September 2018 KU EECS 563 – Intro Comm Nets – E2E Transport ICN-TL-75
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 acknowledged
o previous ACK retransmitted for
• subsequent TPDUs after loss
• out of sequence TPDU
o sender timer fires if ACK not received
• reset transmission beginning at lost TPDU
0
0
11
1
A0
1
A1
tack
A1
A1
A1 2
3
A3
A4
4
5
A5
Page 76
© James P.G. SterbenzITTC
25 September 2018 KU EECS 563 – Intro Comm Nets – E2E Transport ICN-TL-76
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 acknowledged
o previous ACK retransmitted for
• subsequent TPDUs after loss
• out of sequence TPDU
o sender timer fires if ACK not received
• reset transmission beginning at lost TPDU
disadvantages?
0
0
12
1
A0
1
A1
tack
A1
A1
A1 2
3
A3
A4
4
5
A56
Page 77
© James P.G. SterbenzITTC
25 September 2018 KU EECS 563 – Intro Comm Nets – E2E Transport ICN-TL-77
E2E Error ControlClosed Loop Retransmission: Go-Back-n
• Go-back-n : pipeline transmissions
+ multiple TPDUs simultaneously in flight
• TPDUs are sequentially acknowledged
o previous ACK retransmitted for
• subsequent TPDUs after loss
• out of sequence TPDU
o sender timer fires if ACK not received
• reset transmission beginning at lost TPDU
– significant loss penalty for high bw--delay
• go back and retransmit all since loss
• many unneeded retransmissions
• significant additional delay
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
Page 78
© James P.G. SterbenzITTC
25 September 2018 KU EECS 563 – Intro Comm Nets – E2E Transport ICN-TL-78
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
Page 79
© James P.G. SterbenzITTC
25 September 2018 KU EECS 563 – Intro Comm Nets – E2E Transport ICN-TL-79
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
Page 80
© James P.G. SterbenzITTC
25 September 2018 KU EECS 563 – Intro Comm Nets – E2E Transport ICN-TL-80
E2E Error ControlClosed Loop Retransmission: Fast Retransmit
• Fast retransmit– optimisation for go-back-n
0
1
Page 81
© James P.G. SterbenzITTC
25 September 2018 KU EECS 563 – Intro Comm Nets – E2E Transport ICN-TL-81
E2E Error ControlClosed Loop Retransmission: Fast Retransmit
• Fast retransmit
– optimisation for go-back-n 0
0
2
1
A0
Page 82
© James P.G. SterbenzITTC
25 September 2018 KU EECS 563 – Intro Comm Nets – E2E Transport ICN-TL-82
2
E2E Error ControlClosed Loop Retransmission: Fast Retransmit
• Fast retransmit
– optimisation for go-back-n 0
0
3
1
A0
1
A1
tack
Page 83
© James P.G. SterbenzITTC
25 September 2018 KU EECS 563 – Intro Comm Nets – E2E Transport ICN-TL-83
3
2
E2E Error ControlClosed Loop Retransmission: Fast Retransmit
• Fast retransmit
– optimisation for go-back-n 0
0
4
1
A0
1
A1
tack
Page 84
© James P.G. SterbenzITTC
25 September 2018 KU EECS 563 – Intro Comm Nets – E2E Transport ICN-TL-84
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
Page 85
© James P.G. SterbenzITTC
25 September 2018 KU EECS 563 – Intro Comm Nets – E2E Transport ICN-TL-85
2
5
4
3
2
E2E Error ControlClosed Loop Retransmission: Fast Retransmit
• Fast retransmit
– optimisation for go-back-n
• Assume several duplicate ACKs are loss
o even if timer hasn’t yet fired
0
0
6
1
A0
1
A1
tack
A1
A1
Page 86
© James P.G. SterbenzITTC
25 September 2018 KU EECS 563 – Intro Comm Nets – E2E Transport ICN-TL-86
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 loss
o even if timer hasn’t yet fired
+ recovers from loss more quickly
0
0
7
1
A0
1
A1
tack
A1
A1
A12
Page 87
© James P.G. SterbenzITTC
25 September 2018 KU EECS 563 – Intro Comm Nets – E2E Transport ICN-TL-87
4
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 loss
o even if timer hasn’t yet fired
+ recovers from loss more quickly
0
0
8
1
A0
1
A1
tack
A1
A1
A12
3
A3
Page 88
© James P.G. SterbenzITTC
25 September 2018 KU EECS 563 – Intro Comm Nets – E2E Transport ICN-TL-88
5
4
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 loss
o even if timer hasn’t yet fired
+ recovers from loss more quickly
0
0
9
1
A0
1
A1
tack
A1
A1
A12
3
A3
A4
4
Page 89
© James P.G. SterbenzITTC
25 September 2018 KU EECS 563 – Intro Comm Nets – E2E Transport ICN-TL-89
6
5
4
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 loss
o even if timer hasn’t yet fired
+ recovers from loss more quickly
0
0
10
1
A0
1
A1
tack
A1
A1
A12
3
A3
A4
4
5
A5
Page 90
© James P.G. SterbenzITTC
25 September 2018 KU EECS 563 – Intro Comm Nets – E2E Transport ICN-TL-90
6
5
4
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 loss
o even if timer hasn’t yet fired
+ recovers from loss more quickly
0
0
11
1
A0
1
A1
tack
A1
A1
A12
3
A3
A4
4
5
A56
Page 91
© James P.G. SterbenzITTC
25 September 2018 KU EECS 563 – Intro Comm Nets – E2E Transport ICN-TL-91
E2E Error ControlClosed Loop Retransmission: Fast Retransmit
• Fast retransmit
– optimisation for go-back-n
• Assume several duplicate ACKs are loss
o even if timer hasn’t yet fired
+ recovers from loss more quickly
– still suffers from go-back-n inefficiencies
12
6
5
4
3
A2
2
5
4
3
2
0
0
1
A0
1
A1
tack
A1
A1
A12
3
A3
A4
4
5
A56
Page 92
© James P.G. SterbenzITTC
25 September 2018 KU EECS 563 – Intro Comm Nets – E2E Transport ICN-TL-92
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?
Page 93
© James P.G. SterbenzITTC
25 September 2018 KU EECS 563 – Intro Comm Nets – E2E Transport ICN-TL-93
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
Page 94
© James P.G. SterbenzITTC
25 September 2018 KU EECS 563 – Intro Comm Nets – E2E Transport ICN-TL-94
E2E Error ControlClosed Loop Retransmission: Selective Repeat
• Selective repeato all TPDUs acknowledged
1
0
Page 95
© James P.G. SterbenzITTC
25 September 2018 KU EECS 563 – Intro Comm Nets – E2E Transport ICN-TL-95
E2E Error ControlClosed Loop Retransmission: Selective Repeat
• Selective repeat
o all TPDUs acknowledged 0
0
2
1
A0
Page 96
© James P.G. SterbenzITTC
25 September 2018 KU EECS 563 – Intro Comm Nets – E2E Transport ICN-TL-96
2
E2E Error ControlClosed Loop Retransmission: Selective Repeat
• Selective repeat
o all TPDUs acknowledged 0
0
3
1
A0
1
A1
tack
Page 97
© James P.G. SterbenzITTC
25 September 2018 KU EECS 563 – Intro Comm Nets – E2E Transport ICN-TL-97
3
2
E2E Error ControlClosed Loop Retransmission: Selective Repeat
• Selective repeat
o all TPDUs acknowledged 0
0
4
1
A0
1
A1
tack
Page 98
© James P.G. SterbenzITTC
25 September 2018 KU EECS 563 – Intro Comm Nets – E2E Transport ICN-TL-98
4
3
2
E2E Error ControlClosed Loop Retransmission: Selective Repeat
• Selective repeat
o all TPDUs acknowledged
– Missequenced TPDUs
o acknowledged and held at receiver
0
0
5
1
A0
1
A1
tack
A3
3
Page 99
© James P.G. SterbenzITTC
25 September 2018 KU EECS 563 – Intro Comm Nets – E2E Transport ICN-TL-99
5
4
3
2
E2E Error ControlClosed Loop Retransmission: Selective Repeat
• Selective repeat
o all TPDUs acknowledged
• Missequenced TPDUs
o TPDUs held and reordered at receiver
– increases receiver complexity
0
0
6
1
A0
1
A1
tack
A3
3
A4
43
Page 100
© James P.G. SterbenzITTC
25 September 2018 KU EECS 563 – Intro Comm Nets – E2E Transport ICN-TL-100
2
5
4
3
2
E2E Error ControlClosed Loop Retransmission: Selective Repeat
• Selective repeat
o all TPDUs acknowledged
• Missequenced TPDUs
o TPDUs held and reordered at receiver
– increases receiver complexity
• Lost TPDUs
o selectively retransmitted
0
0
7
1
A0
1
A1
tack
A3
3
A4
43
543
A5
Page 101
© James P.G. SterbenzITTC
25 September 2018 KU EECS 563 – Intro Comm Nets – E2E Transport ICN-TL-101
6
2
5
4
3
2
E2E Error ControlClosed Loop Retransmission: Selective Repeat
• Selective repeat
o all TPDUs acknowledged
• Missequenced TPDUs
o TPDUs held and reordered at receiver
– increases receiver complexity
• Lost TPDUs
o selectively retransmitted
+ no go-back-n latency penalty
– requires more receiver buffer space
0
0
8
1
A0
1
A1
tack
A3
3
A4
43
543
A5
A2
5432
Page 102
© James P.G. SterbenzITTC
25 September 2018 KU EECS 563 – Intro Comm Nets – E2E Transport ICN-TL-102
7
6
2
5
4
3
2
E2E Error ControlClosed Loop Retransmission: Selective Repeat
• Selective repeat
o all TPDUs acknowledged
• Missequenced TPDUs
o TPDUs held and reordered at receiver
– increases receiver complexity
• Lost TPDUs
o selectively retransmitted
+ no go-back-n latency penalty
– requires more receiver buffer space
0
0
9
1
A0
1
A1
tack
A3
3
A4
43
543
A5
A2
5432
A6
6
Page 103
© James P.G. SterbenzITTC
25 September 2018 KU EECS 563 – Intro Comm Nets – E2E Transport ICN-TL-103
8
7
6
2
5
4
3
2
E2E Error ControlClosed Loop Retransmission: Selective Repeat
• Selective repeat
o all TPDUs acknowledged
• Missequenced TPDUs
o TPDUs held and reordered at receiver
– increases receiver complexity
• Lost TPDUs
o selectively retransmitted
+ no go-back-n latency penalty
– requires more receiver buffer space
0
0
10
1
A0
1
A1
tack
A3
3
A4
43
543
A5
A2
5432
A6
6
A7
7
Page 104
© James P.G. SterbenzITTC
25 September 2018 KU EECS 563 – Intro Comm Nets – E2E Transport ICN-TL-104
9
8
7
6
2
5
4
3
2
E2E Error ControlClosed Loop Retransmission: Selective Repeat
• Selective repeat
o all TPDUs acknowledged
• Missequenced TPDUs
o TPDUs held and reordered at receiver
– increases receiver complexity
• Lost TPDUs
o selectively retransmitted
+ no go-back-n latency penalty
– requires more receiver buffer space
• A2A delay and bandwidth reduced
0
0
11
1
A0
1
A1
tack
A3
3
A4
43
543
A5
A2
5432
A6
6
A7
8
7
A8
Page 105
© James P.G. SterbenzITTC
25 September 2018 KU EECS 563 – Intro Comm Nets – E2E Transport ICN-TL-105
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
8
7
6
2
5
4
3
2
0
0
1
A0
1
A1
tack
A3
3
A4
43
543
A5
A2
A6
6
A7
8
7
A8
Page 106
© James P.G. SterbenzITTC
25 September 2018 KU EECS 563 – Intro Comm Nets – E2E Transport ICN-TL-106
E2E Transmission ControlDefinitions: Flow Control
• Flow control
– control transmission to avoid overwhelming receiver
– end-to-end control
Page 107
© James P.G. SterbenzITTC
25 September 2018 KU EECS 563 – Intro Comm Nets – E2E Transport ICN-TL-107
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
Page 108
© James P.G. SterbenzITTC
25 September 2018 KU EECS 563 – Intro Comm Nets – E2E Transport ICN-TL-108
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 network nodes
• allows decoupling of error, flow, and congestion mechanisms
– implicit assumes loss is congestion
• bad assumption in wireless networks (see [Krishnan 2004])
Page 109
© James P.G. SterbenzITTC
25 September 2018 KU EECS 563 – Intro Comm Nets – E2E Transport ICN-TL-109
E2E Transmission ControlClosed-Loop Flow and Congestion Control
• Flow control
– sender–receiver
• Congestion control
– sender–network
• Packet scheduling Lecture MT
Page 110
© James P.G. SterbenzITTC
25 September 2018 KU EECS 563 – Intro Comm Nets – E2E Transport ICN-TL-110
E2E Transmission ControlClosed-Loop Flow Control
• Feedback from receiver to limit transmission rate
– end-to-end only
• 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
Page 111
© James P.G. SterbenzITTC
25 September 2018 KU EECS 563 – Intro Comm Nets – E2E Transport ICN-TL-111
E2E Transmission ControlClosed-Loop Flow Control
• Initial negotiation
– amount of unacknowledged data can be sent to receiver
• maintained as receive window at sender
• based on assumption or value returned at connection setup
• static window does not change over life of connection
receive window
Page 112
© James P.G. SterbenzITTC
25 September 2018 KU EECS 563 – Intro Comm Nets – E2E Transport ICN-TL-112
E2E Transmission ControlClosed-Loop Flow Control
• Initial negotiation
• Steady state
– dynamic window: receive window varies over time
– receiver adjusts with time-varying available buffer space
receive window
Page 113
© James P.G. SterbenzITTC
25 September 2018 KU EECS 563 – Intro Comm Nets – E2E Transport ICN-TL-113
E2E Transmission ControlClosed-Loop Congestion Control
• Feedback from network to limit transmission rate
• Window to limit amount of unacknowledged data
– dynamic window
• adjusted based on network state
Page 114
© James P.G. SterbenzITTC
25 September 2018 KU EECS 563 – Intro Comm Nets – E2E Transport ICN-TL-114
Congestion ControlClosed-Loop End-to-End
flow control
receive window
congestion control
congestion window
• Closed loop congestion control
• Initial state
– Amount of unacked data can be sent into network
• maintained as congestion window at sender
• initial conservative default
Page 115
© James P.G. SterbenzITTC
25 September 2018 KU EECS 563 – Intro Comm Nets – E2E Transport ICN-TL-115
Congestion ControlClosed-Loop End-to-End
• Closed loop congestion control
– feedback from network necessary
flow control
receive window
congestion control
congestion window
transmission
Page 116
© James P.G. SterbenzITTC
25 September 2018 KU EECS 563 – Intro Comm Nets – E2E Transport ICN-TL-116
Congestion ControlClosed-Loop End-to-End
• Closed loop congestion control
– feedback from network necessary
– loss (data resulting in no ACK or ACK) throttles source
• tail drop when router queue is full
flow control
receive window
congestion control
congestion window
transmission
Page 117
© James P.G. SterbenzITTC
25 September 2018 KU EECS 563 – Intro Comm Nets – E2E Transport ICN-TL-117
Congestion ControlIdeal Network
offered load
ca
rrie
d lo
ad
offered load 1.0
de
lay
throughput delay
• Ideal network
throughput characteristics?
delay characteristics?
Page 118
© James P.G. SterbenzITTC
25 September 2018 KU EECS 563 – Intro Comm Nets – E2E Transport ICN-TL-118
Congestion ControlIdeal Network
offered load
ideal
ca
rrie
d 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?
Page 119
© James P.G. SterbenzITTC
25 September 2018 KU EECS 563 – Intro Comm Nets – E2E Transport ICN-TL-119
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
Page 120
© James P.G. SterbenzITTC
25 September 2018 KU EECS 563 – Intro Comm Nets – E2E Transport ICN-TL-120
Congestion ControlIdeal Network
offered load
ideal
ca
rrie
d load
offered load
ideal
1.0
dela
y
throughput delay
• Desired network:
what happens to carried load?
Page 121
© James P.G. SterbenzITTC
25 September 2018 KU EECS 563 – Intro Comm Nets – E2E Transport ICN-TL-121
Congestion ControlDesired Real Network Behaviour
knee
offered load
ideal 1.0
1.0
ca
rrie
d 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?
Page 122
© James P.G. SterbenzITTC
25 September 2018 KU EECS 563 – Intro Comm Nets – E2E Transport ICN-TL-122
Congestion ControlCauses of Congestion
• Congestion when offered load net path capacity
• Best effort
– occurs whenever load is high
• Probabilistic guarantees
– occurs when load exceeds resource reservations
• Absolute guarantees
– can’t happen (in theory)
not
Internet
service
model
Page 123
© James P.G. SterbenzITTC
25 September 2018 KU EECS 563 – Intro Comm Nets – E2E Transport ICN-TL-123
Congestion ControlInfinite Buffers / No Retransmission
• Congestion whenoffered load link capacity
• Infinite buffers
– queue lengthbuilds to infinity
– d
discuss why in Lecture MT
offered load
ideal
1.0
de
lay knee
dmin
delay
Page 124
© James P.G. SterbenzITTC
25 September 2018 KU EECS 563 – Intro Comm Nets – E2E Transport ICN-TL-124
Congestion ControlFinite Buffers with Retransmission
• Finite buffers cause packet loss
– retransmissions contribute to offered load
• assuming reliable protocol
– throughput curve levels off
Page 125
© James P.G. SterbenzITTC
25 September 2018 KU EECS 563 – Intro Comm Nets – E2E Transport ICN-TL-125
Congestion ControlMultihop Network
• Multiple hops
– downstream packet loss
– upstream transmission wasted
Page 126
© James P.G. SterbenzITTC
25 September 2018 KU EECS 563 – Intro Comm Nets – E2E Transport ICN-TL-126
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
Page 127
© James P.G. SterbenzITTC
25 September 2018 KU EECS 563 – Intro Comm Nets – E2E Transport ICN-TL-127
Congestion ControlCongestion Avoidance and Control
knee cliff
offered load
ideal 1.0
1.0
carr
ied load
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
Page 128
© James P.G. SterbenzITTC
25 September 2018 KU EECS 563 – Intro Comm Nets – E2E Transport ICN-TL-128
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
Page 129
© James P.G. SterbenzITTC
25 September 2018 KU EECS 563 – Intro Comm Nets – E2E Transport ICN-TL-129
Congestion ControlEnd-to-End Action
• End-to-end action
• Throttle source
– reduce transmission rates
– prevent unnecessary retransmissions
• Types
– explicit
– implicit
Page 130
© James P.G. SterbenzITTC
25 September 2018 KU EECS 563 – Intro Comm Nets – E2E Transport ICN-TL-130
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
Page 131
© James P.G. SterbenzITTC
25 September 2018 KU EECS 563 – Intro Comm Nets – E2E Transport ICN-TL-131
E2E Transmission ControlClosed-Loop Control: Initialisation
• Initial small window sent
– assume 1 TPDU
1
0
Page 132
© James P.G. SterbenzITTC
25 September 2018 KU EECS 563 – Intro Comm Nets – E2E Transport ICN-TL-132
E2E Transmission ControlClosed-Loop Control: Initialisation
• Initial small window sent
– assume 1 TPDU
– TPDU acknowledged
0
0
2
A0
Page 133
© James P.G. SterbenzITTC
25 September 2018 KU EECS 563 – Intro Comm Nets – E2E Transport ICN-TL-133
E2E Transmission ControlClosed-Loop Control: Initialisation
• Initial small window sent
– assume 1 TPDU
– TPDU acknowledged
• Window doubled
– TPDU + one more sent
0
0
3
1
A0
2
Page 134
© James P.G. SterbenzITTC
25 September 2018 KU EECS 563 – Intro Comm Nets – E2E Transport ICN-TL-134
E2E Transmission ControlClosed-Loop Control: Initialisation
• Initial small window sent
– assume 1 TPDU
– TPDU acknowledged
• Window doubled
– TPDU + one more sent
– TPDUs acknowledged
0
0
4
1
A0
2 1
2
A1
A2
Page 135
© James P.G. SterbenzITTC
25 September 2018 KU EECS 563 – Intro Comm Nets – E2E Transport ICN-TL-135
3
4
5
6
E2E Transmission ControlClosed-Loop Control: Initialisation
• Initial small window sent
– assume 1 TPDU
– TPDU acknowledged
• Window doubled
– TPDU + one more sent
– TPDUs acknowledged
• Window doubled again
– TPDUs + one more/ACK sent
0
0
5
1
A0
2 1
2
A1
A2
Page 136
© James P.G. SterbenzITTC
25 September 2018 KU EECS 563 – Intro Comm Nets – E2E Transport ICN-TL-136
E2E Transmission ControlClosed-Loop Control: Initialisation
• Slow start initialisation
– increase window until path loaded
– double window / RTT
• exponential growth
• not really “slow”
Critical parameters?
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
Page 137
© James P.G. SterbenzITTC
25 September 2018 KU EECS 563 – Intro Comm Nets – E2E Transport ICN-TL-137
E2E Transmission ControlClosed-Loop Control: Initialisation
• Slow start initialisation
– increase window until path loaded
– double window / RTT
• 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
Page 138
© James P.G. SterbenzITTC
25 September 2018 KU EECS 563 – Intro Comm Nets – E2E Transport ICN-TL-138
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
Page 139
© James P.G. SterbenzITTC
25 September 2018 KU EECS 563 – Intro Comm Nets – E2E Transport ICN-TL-139
E2E Congestion ControlClosed-Loop Control
• Initialisation phase: slow start
Steady-state phase?
time
se
ndin
g r
ate
slow start
steady state phase initialisation
Page 140
© James P.G. SterbenzITTC
25 September 2018 KU EECS 563 – Intro Comm Nets – E2E Transport ICN-TL-140
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
Page 141
© James P.G. SterbenzITTC
25 September 2018 KU EECS 563 – Intro Comm Nets – E2E Transport ICN-TL-141
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
share
R
R
I
ideal
Page 142
© James P.G. SterbenzITTC
25 September 2018 KU EECS 563 – Intro Comm Nets – E2E Transport ICN-TL-142
E2E Congestion ControlClosed-Loop Control
• Initialisation phase: slow start
• Steady-state phase: AIMD
AI
time
MD
se
nd
ing r
ate
slow start
steady state phase initialisation
congestion detection
Page 143
© James P.G. SterbenzITTC
25 September 2018 KU EECS 563 – Intro Comm Nets – E2E Transport ICN-TL-143
E2E Congestion ControlClosed-Loop Implicit Control
• Implicit control
– missing ACK assumed to be congestion
good assumption?
Page 144
© James P.G. SterbenzITTC
25 September 2018 KU EECS 563 – Intro Comm Nets – E2E Transport ICN-TL-144
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
Page 145
© James P.G. SterbenzITTC
25 September 2018 KU EECS 563 – Intro Comm Nets – E2E Transport ICN-TL-145
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
why?
Page 146
© James P.G. SterbenzITTC
25 September 2018 KU EECS 563 – Intro Comm Nets – E2E Transport ICN-TL-146
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
Page 147
© James P.G. SterbenzITTC
25 September 2018 KU EECS 563 – Intro Comm Nets – E2E Transport ICN-TL-147
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?
Page 148
© James P.G. SterbenzITTC
25 September 2018 KU EECS 563 – Intro Comm Nets – E2E Transport ICN-TL-148
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
Page 149
© James P.G. SterbenzITTC
25 September 2018 KU EECS 563 – Intro Comm Nets – E2E Transport ICN-TL-149
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
Page 150
© James P.G. SterbenzITTC
25 September 2018 KU EECS 563 – Intro Comm Nets – E2E Transport ICN-TL-150
Transport LayerInternet Transport Protocols
TL.1 Transport Services and interfaces
TL.2 End-to-end functions and mechanisms
TL.3 Internet transport protocols
Page 151
© James P.G. SterbenzITTC
25 September 2018 KU EECS 563 – Intro Comm Nets – E2E Transport ICN-TL-151
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
Page 152
© James P.G. SterbenzITTC
25 September 2018 KU EECS 563 – Intro Comm Nets – E2E Transport ICN-TL-152
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
Page 153
© James P.G. SterbenzITTC
25 September 2018 KU EECS 563 – Intro Comm Nets – E2E Transport ICN-TL-153
Internet Transport ProtocolsImportant Examples
Protocol Name Function Status Ref
TCPtransmission control
protocol
reliable data transfer with
congestion controlstandard
RFC 0793
STD 0007
UDPuser datagram
protocol
socket access to unreliable
IP datagramsstandard
RFC 0768
STD 0006
RTP real-time protocolreal-time synchronisation
(typically over UDP)
standards
track
RFC 3550
STD 0064
T/TCP TCP for transactionslow connection setup
overhead for transactionsexperimental RFC 1644
RDP reliable data protocolreliable data transfer with
no congestion controlexperimental RFC 0908
SCTPstream control
transmission protocol
signalling
proposed for wireless
proposed
standardRFC 2960
Page 154
© James P.G. SterbenzITTC
25 September 2018 KU EECS 563 – Intro Comm Nets – E2E Transport ICN-TL-154
Internet Transport ProtocolsTL.3.1 UDP
TL.1 Transport services and interfaces
TL.2 End-to-end functions and mechanisms
TL.3 Internet transport protocols
TL.3.1 UDP
TL.3.2 RTP introduction
TL.3.3 TCP
TL.4 Multipoint communication and reliable multicast
Page 155
© James P.G. SterbenzITTC
25 September 2018 KU EECS 563 – Intro Comm Nets – E2E Transport ICN-TL-155
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
Page 156
© James P.G. SterbenzITTC
25 September 2018 KU EECS 563 – Intro Comm Nets – E2E Transport ICN-TL-156
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)
Page 157
© James P.G. SterbenzITTC
25 September 2018 KU EECS 563 – Intro Comm Nets – E2E Transport ICN-TL-157
User Datagram ProtocolMultiplexing
• Interface to IP: protocol mux/demux (UDP=17)
• Interface to application: port mux/demux
app i
TCP
port n
app j
TCP
port x
TCP
port y
UDP
port z
TCP TCP UDP
transport demux (IP protocol id)
port demux
network demux (IP address)
pd pd
06 17
Page 158
© James P.G. SterbenzITTC
25 September 2018 KU EECS 563 – Intro Comm Nets – E2E Transport ICN-TL-158
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)
Page 159
© James P.G. SterbenzITTC
25 September 2018 KU EECS 563 – Intro Comm Nets – E2E Transport ICN-TL-159
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
11011101110111011
destination port #source port#
length checksum
application payload
(= length – 8B)
Page 160
© James P.G. SterbenzITTC
25 September 2018 KU EECS 563 – Intro Comm Nets – E2E Transport ICN-TL-160
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
11011101110111011
1011101110111100
destination port #source port#
length checksum
application payload
(= length – 8B)
Page 161
© James P.G. SterbenzITTC
25 September 2018 KU EECS 563 – Intro Comm Nets – E2E Transport ICN-TL-161
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
11011101110111011
1011101110111100
0100010001000011
destination port #source port#
length checksum
application payload
(= length – 8B)
Page 162
© James P.G. SterbenzITTC
25 September 2018 KU EECS 563 – Intro Comm Nets – E2E Transport ICN-TL-162
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
11011101110111011
1011101110111100
0100010001000011
– sender computes+inserts– receiver compute+compares– weak protection [RFC 3385]
• No retransmission at L4
destination port #source port#
length checksum
application payload
(= length – 8B)
Page 163
© James P.G. SterbenzITTC
25 September 2018 KU EECS 563 – Intro Comm Nets – E2E Transport ICN-TL-163
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
Page 164
© James P.G. SterbenzITTC
25 September 2018 KU EECS 563 – Intro Comm Nets – E2E Transport ICN-TL-164
User Datagram ProtocolTypical Applications
• Typical application: multimedia streaming
why?
Page 165
© James P.G. SterbenzITTC
25 September 2018 KU EECS 563 – Intro Comm Nets – E2E Transport ICN-TL-165
User Datagram ProtocolTypical Applications
• Typical application: multimedia streaming
– loss tolerant
– rate sensitive (do not adapt well to TCP congestion control)
– research community considering alternatives
Page 166
© James P.G. SterbenzITTC
25 September 2018 KU EECS 563 – Intro Comm Nets – E2E Transport ICN-TL-166
User Datagram ProtocolTypical Applications
• Loss-tolerant network control protocols
– e.g. DNS resolution
• Multimedia streaming when RTP-like sync not needed
– loss tolerant
– rate sensitive (do not adapt well to TCP congestion control)
– research community considering alternatives
Page 167
© James P.G. SterbenzITTC
25 September 2018 KU EECS 563 – Intro Comm Nets – E2E Transport ICN-TL-167
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
Page 168
© James P.G. SterbenzITTC
25 September 2018 KU EECS 563 – Intro Comm Nets – E2E Transport ICN-TL-168
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
Page 169
© James P.G. SterbenzITTC
25 September 2018 KU EECS 563 – Intro Comm Nets – E2E Transport ICN-TL-169
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
Page 170
© James P.G. SterbenzITTC
25 September 2018 KU EECS 563 – Intro Comm Nets – E2E Transport ICN-TL-170
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
Page 171
© James P.G. SterbenzITTC
25 September 2018 KU EECS 563 – Intro Comm Nets – E2E Transport ICN-TL-171
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 pointer
receive window
ack number
sequence number
dest port #source port #
[options (variable length)]
application
payload
(variable length)
flagsHL
32 bits
HL
Page 172
© James P.G. SterbenzITTC
25 September 2018 KU EECS 563 – Intro Comm Nets – E2E Transport ICN-TL-172
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 pointer
receive window
ack number
sequence number
dest port #source port #
options (variable length)
application
payload
(variable length)
HL
32 bits
CEUAPRSF
U
R
G
A
C
K
P
S
H
R
S
T
S
Y
N
F
I
N
E
C
E
C
W
R
Page 173
© James P.G. SterbenzITTC
25 September 2018 KU EECS 563 – Intro Comm Nets – E2E Transport ICN-TL-173
Transmission Control ProtocolSegment Format: No Options
• Header with no options– 20B long
checksum urg data pointer
receive window
ack number
sequence number
dest port #source port #
application
payload
(variable length)
flags20
32 bits
20B
Page 174
© James P.G. SterbenzITTC
25 September 2018 KU EECS 563 – Intro Comm Nets – E2E Transport ICN-TL-174
Transmission Control ProtocolSegment Format: No Options Nor Data
• Entire segment– 20B long
• Example:– ACKs
– significant fractionof Internet packets40B
why?
checksum urg data pointer
receive window
ack number
sequence number
dest port #source port #
flags20
32 bits
20B
Page 175
© James P.G. SterbenzITTC
25 September 2018 KU EECS 563 – Intro Comm Nets – E2E Transport ICN-TL-175
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 pointer
receive window
ack number
sequence number
dest port #source port #
options (variable length)
application
payload
(variable length)
flagsHL
32 bits
20B
40B
Page 176
© James P.G. SterbenzITTC
25 September 2018 KU EECS 563 – Intro Comm Nets – E2E Transport ICN-TL-176
Transmission Control ProtocolSelected Options
• Selected TCP options
http://www.iana.org/assignments/tcp-parameters
00 end of option list
01 no operation (for padding)
02 MSS (max. segment size)
03 window scale factor
04 SACK permitted
05 SACK blocks
08 timestamp
Page 177
© James P.G. SterbenzITTC
25 September 2018 KU EECS 563 – Intro Comm Nets – E2E Transport ICN-TL-177
Transmission Control ProtocolSegment Format: Multiplexing
• Socket: 5-tuple– sp, sa, dp, da, port
• 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 pointer
receive window
ack number
sequence number
dest port #source port #
options (variable length)
application
payload
(variable length)
flagsHL
Page 178
© James P.G. SterbenzITTC
25 September 2018 KU EECS 563 – Intro Comm Nets – E2E Transport ICN-TL-178
Transmission Control ProtocolMultiplexing
• Interface to IP: protocol mux/demux (TCP = 06)
• Interface to application: port mux/demux
app i
TCP
port n
app j
TCP
port x
TCP
port y
UDP
port z
TCP TCP UDP
transport demux (IP protocol id)
port demux
network demux (IP address)
pd pd
06 17
Page 179
© James P.G. SterbenzITTC
25 September 2018 KU EECS 563 – Intro Comm Nets – E2E Transport ICN-TL-179
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 pointer
receive window
ACK number
sequence number
dest port #source port #
options (variable length)
application
payload
(variable length)
CEUAPRSFHL
Page 180
© James P.G. SterbenzITTC
25 September 2018 KU EECS 563 – Intro Comm Nets – E2E Transport ICN-TL-180
data segments
data segments
Transmission Control ProtocolConnection Management: Setup
• Three way handshake– “client” and “server”
1. SYN (init seq#)
• randomised for security
2. 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
ACK
FIN
buffer
alloc
buffer
alloc
estab.
state
C S
Page 181
© James P.G. SterbenzITTC
25 September 2018 KU EECS 563 – Intro Comm Nets – E2E Transport ICN-TL-181
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. FIN
2. ACK
net
SYN
ACK
SYNACK
FIN
ACK
FIN
ACK
buffer
free
buffer
free
C S
twait
closed
Page 182
© James P.G. SterbenzITTC
25 September 2018 KU EECS 563 – Intro Comm Nets – E2E Transport ICN-TL-182
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 |
+---------+ +---------+
Page 183
© James P.G. SterbenzITTC
25 September 2018 KU EECS 563 – Intro Comm Nets – E2E Transport ICN-TL-183
Transmission Control ProtocolActual Connection State Machine
[Sewell] http://www.cl.cam.ac.uk/users/pes20/Netsem
Page 184
© James P.G. SterbenzITTC
25 September 2018 KU EECS 563 – Intro Comm Nets – E2E Transport ICN-TL-184
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 pointer
receive window
ACK number
sequence number
dest port #source port #
options (variable length)
application
payload
(variable length)
HL CEUAPRSF
Page 185
© James P.G. SterbenzITTC
25 September 2018 KU EECS 563 – Intro Comm Nets – E2E Transport ICN-TL-185
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 #)
Page 186
© James P.G. SterbenzITTC
25 September 2018 KU EECS 563 – Intro Comm Nets – E2E Transport ICN-TL-186
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 streamof 1st byte in segment
Page 187
© James P.G. SterbenzITTC
25 September 2018 KU EECS 563 – Intro Comm Nets – E2E Transport ICN-TL-187
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 streamof 1st byte in segment
• ACK numbers
– seq # of next byte expected
Page 188
© James P.G. SterbenzITTC
25 September 2018 KU EECS 563 – Intro Comm Nets – E2E Transport ICN-TL-188
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 streamof 1st byte in segment
• ACK numbers
– seq # of next byte expected
Page 189
© James P.G. SterbenzITTC
25 September 2018 KU EECS 563 – Intro Comm Nets – E2E Transport ICN-TL-189
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 streamof 1st byte in segment
• ACK numbers
– seq # of next byte expected
– cumulative ACKs
Page 190
© James P.G. SterbenzITTC
25 September 2018 KU EECS 563 – Intro Comm Nets – E2E Transport ICN-TL-190
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 streamof 1st byte in segment
• ACK numbers
– seq # of next byte expected
– cumulative ACKs
Page 191
© James P.G. SterbenzITTC
25 September 2018 KU EECS 563 – Intro Comm Nets – E2E Transport ICN-TL-191
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 streamof 1st byte in segment
• ACK numbers
– seq # of next byte expected
– cumulative ACKs
Page 192
© James P.G. SterbenzITTC
25 September 2018 KU EECS 563 – Intro Comm Nets – E2E Transport ICN-TL-192
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
8
ACK 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
Page 193
© James P.G. SterbenzITTC
25 September 2018 KU EECS 563 – Intro Comm Nets – E2E Transport ICN-TL-193
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
Page 194
© James P.G. SterbenzITTC
25 September 2018 KU EECS 563 – Intro Comm Nets – E2E Transport ICN-TL-194
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
Page 195
© James P.G. SterbenzITTC
25 September 2018 KU EECS 563 – Intro Comm Nets – E2E Transport ICN-TL-195
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
Page 196
© James P.G. SterbenzITTC
25 September 2018 KU EECS 563 – Intro Comm Nets – E2E Transport ICN-TL-196
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
Page 197
© James P.G. SterbenzITTC
25 September 2018 KU EECS 563 – Intro Comm Nets – E2E Transport ICN-TL-197
Transmission Control ProtocolWindow-Based Feedback Control
• Windowing used for a combined:– error control
– flow control
– congestion control
• Window limits amount of unACKed data transmitted
Page 198
© James P.G. SterbenzITTC
25 September 2018 KU EECS 563 – Intro Comm Nets – E2E Transport ICN-TL-198
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
• Go-back when
– corrupted data: checksum fails
– packet drops in network
• timeout events
• triple duplicate ACKS (fast retransmit)
Page 199
© James P.G. SterbenzITTC
25 September 2018 KU EECS 563 – Intro Comm Nets – E2E Transport ICN-TL-199
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)
Page 200
© James P.G. SterbenzITTC
25 September 2018 KU EECS 563 – Intro Comm Nets – E2E Transport ICN-TL-200
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 Bfor 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 pointer
receive window
ack number
sequence number
dest port #source port #
application
payload
(variable length)
flagsHL
32 bits
seq num after last byte
seq num of 1st byte
05 len0101
Page 201
© James P.G. SterbenzITTC
25 September 2018 KU EECS 563 – Intro Comm Nets – E2E Transport ICN-TL-201
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
Page 202
© James P.G. SterbenzITTC
25 September 2018 KU EECS 563 – Intro Comm Nets – E2E Transport ICN-TL-202
Transmission Control ProtocolTimeout
How to set TCP timeout value?
Page 203
© James P.G. SterbenzITTC
25 September 2018 KU EECS 563 – Intro Comm Nets – E2E Transport ICN-TL-203
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?
Page 204
© James P.G. SterbenzITTC
25 September 2018 KU EECS 563 – Intro Comm Nets – E2E Transport ICN-TL-204
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
Page 205
© James P.G. SterbenzITTC
25 September 2018 KU EECS 563 – Intro Comm Nets – E2E Transport ICN-TL-205
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
Page 206
© James P.G. SterbenzITTC
25 September 2018 KU EECS 563 – Intro Comm Nets – E2E Transport ICN-TL-206
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)
RT
T (
mill
ise
co
nd
s)
SampleRTT Estimated RTT
Page 207
© James P.G. SterbenzITTC
25 September 2018 KU EECS 563 – Intro Comm Nets – E2E Transport ICN-TL-207
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
Page 208
© James P.G. SterbenzITTC
25 September 2018 KU EECS 563 – Intro Comm Nets – E2E Transport ICN-TL-208
data in
buffer
Transmission Control ProtocolFlow Control
• Sender matches transmission rate to receiver
– receive window dynamically adjusted
• Receiver advertised its window
– transmitted in each TCP segment header
• Sender limits unACKed data to receive window size
spare
roomfrom IP to application
RcvWindow
Page 209
© James P.G. SterbenzITTC
25 September 2018 KU EECS 563 – Intro Comm Nets – E2E Transport ICN-TL-209
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
Page 210
© James P.G. SterbenzITTC
25 September 2018 KU EECS 563 – Intro Comm Nets – E2E Transport ICN-TL-210
Transmission Control ProtocolCongestion Control
• Initialisation phase: slow start
• Steady-state phase: AIMD
AI
time
MD
sendin
g r
ate
slow start
steady state phase initialisation
congestion detection
Page 211
© James P.G. SterbenzITTC
25 September 2018 KU EECS 563 – Intro Comm Nets – E2E Transport ICN-TL-211
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
lecture NL
Page 212
© James P.G. SterbenzITTC
25 September 2018 KU EECS 563 – Intro Comm Nets – E2E Transport ICN-TL-212
Transmission Control ProtocolExplicit Congestion Notification
• Network nodes setcongestion indication
– hist. ICMP source quench
– ECN bits in IP header
• TCP reacts
– uses flags for signalling
checksum urg data pointer
receive window
ACK number
sequence number
dest port #source port #
options (variable length)
application
payload
(variable length)
CEUAPRSFHL
Page 213
© James P.G. SterbenzITTC
25 September 2018 KU EECS 563 – Intro Comm Nets – E2E Transport ICN-TL-213
Transmission Control ProtocolCongestion Control Implementations
• Tahoe– slow start and congestion avoidance algorithms
– fast retransmit after triple duplicate ACKs
– slow start after any loss (3dupACK or RTO)
• Reno – widely implemented– Tahoe +
– fast recovery (MD after 3dupACK rather than SS)
• NewReno [Floyd 1999]
– Reno +
– partial ACK recovery
Page 214
© James P.G. SterbenzITTC
25 September 2018 KU EECS 563 – Intro Comm Nets – E2E Transport ICN-TL-214
Transmission Control ProtocolCongestion Control Implementations
• BIC (binary-increase TCP) [Xu 2004]
– binary search of window size during steady state– CUBIC variant is now default in Linux kernel > 2.6.19
• CTCP (compound TCP) [Tan 2005]– maintains dual AIMD and Vegas-style delay windows– default in MS-Windows Server since Vista
Page 215
© James P.G. SterbenzITTC
25 September 2018 KU EECS 563 – Intro Comm Nets – E2E Transport ICN-TL-215
Transmission Control ProtocolHigh-Bandwidth--Delay Optimisations
• High bandwidth--delay paths (long fat pipes)
problem?
Page 216
© James P.G. SterbenzITTC
25 September 2018 KU EECS 563 – Intro Comm Nets – E2E Transport ICN-TL-216
Transmission Control ProtocolHigh-Bandwidth--Delay Optimisations
• High bandwidth--delay paths (long fat pipes)
– problem: large number of bits in flight
Implications to TCP?
Page 217
© James P.G. SterbenzITTC
25 September 2018 KU EECS 563 – Intro Comm Nets – E2E Transport ICN-TL-217
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? )
Page 218
© James P.G. SterbenzITTC
25 September 2018 KU EECS 563 – Intro Comm Nets – E2E Transport ICN-TL-218
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)
Page 219
© James P.G. SterbenzITTC
25 September 2018 KU EECS 563 – Intro Comm Nets – E2E Transport ICN-TL-219
End-to-End TransportKey Acronyms1
PDU protocol data unit
TPDU transport protocol data unit
E2E end-to-end
HBH hop-by-hop
ARQ automatic repeat request
ACK acknowledgement
NAK negative ACK
AIMD additive-increase multiplicative-decrease
ECN explicit congestion notification
Page 220
© James P.G. SterbenzITTC
25 September 2018 KU EECS 563 – Intro Comm Nets – E2E Transport ICN-TL-220
End-to-End TransportKey Acronyms2
TCP transmission control protocol
UDP user datagram protocol
RTP real-time transport protocol
SYN synchronise
FIN finish
SACK selective acknowledgements
Page 221
© James P.G. SterbenzITTC
25 September 2018 KU EECS 563 – Intro Comm Nets – E2E Transport ICN-TL-221
End-to-End TransportAcknowledgements
Some material in these foils comes from the textbook supplementary materials:
• Kurose & Ross,Computer Networking:
A Top-Down Approach Featuring the Internet
• Sterbenz & Touch,High-Speed Networking:
A Systematic Approach to
High-Bandwidth Low-Latency Communication
http://hsn-book.sterbenz.org