ITTC © James P.G. Sterbenz Communication...

© James P.G. SterbenzITTC

03 October 2016 © 2004–2016 James P.G. Sterbenzrev. 16.0

Communication NetworksThe University of Kansas EECS 780

End-to-End Transport

James P.G. Sterbenz

Department of Electrical Engineering & Computer Science

Information Technology & Telecommunications Research Center

The University of Kansas

[email protected]

http://www.ittc.ku.edu/~jpgs/courses/nets


03 October 2016 KU EECS 780 – Comm Nets – E2E Transport NET-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

TL.4 Multipoint communication and reliable multicast



End-to-End TransportTL.1 Services and Interfaces







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



Transport LayerMotivation

Why do we need a transport protocol?

Mapp

Mapp

ES1

CPU

ES2

CPU



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



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



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

intermediate

systemCPU

M app

end system



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



Transport LayerService and Interfaces1

• Transport layer (L4) service to application layer (L7)

• Transfer PDU (protocol date 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



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?



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



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



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



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



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]




• 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




• 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




• 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]



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



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 m

wireless LANUniv. Kansas

100 m

fiber LANUniv. Sydney

15 000 km

fiber WAN



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 m

wireless LANUniv. Kansas

100 m

fiber LANUniv. Sydney

15 000 km

fiber WAN



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



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



End-to-End TransportTL.2 Functions and Mechanisms



TL.2.1 Framing and multiplexing

TL.2.2 State management and transfer modes

TL.2.3 Reliability and error control

TL.2.4 Transmission control





E2E Functions and MechanismsTL.2.1 Framing and Multiplexing







TL.3 Internet transport Protocols




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)



E2E MultiplexingConcepts

• Multiple applications use a particular TP

• Applications multiplexed into sending TP

– need to identify which application

why?



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



E2E Functions and MechanismsTL.2.2 Transfer Modes and State Management











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



E2E State ManagementControl Loops

Alternatives?




• Open loop

– control parameters

– no feedback

Alternative?

Open loop

parameters

data




• Open loop


– no feedback

• Closed loop

– initial parameters

– feedback

• dynamic adaptationdata




• Open loop


– no feedback

• Closed loop


– feedback

• dynamic adaptation

Open loop

parameters

data

Closed loop

initial parameters

data

E2E feedback




• Open loop


– no feedback

• Closed loop


– 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



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



E2E State ManagementHard vs. Soft

• Hard state

– explicitly established and released

– deterministic

– delay to establish and memory to maintain

Alternative?




• Hard state


– deterministic


• Soft state

– established and removed as needed and memory allows

– robust to failures

– if not explicitly established, delay to accumulate




• Hard state


– deterministic


• Soft state

– established and removed as needed and memory allows

– robust to failures

– if not explicitly established, delay to accumulate

• Stateless

– (essentially) no state



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)



E2E State ManagementImpact of Data Rate

• Transmission delay proportional to data rate

What happens when data rate increases?

slow

tRTT

SETUP

RELEASE

ACK

tp

td





• Connection shortening+ transmission delay decreases

– but signalling delay constant

slow fast

ACK

RELEASE

tRTT

SETUP

RELEASE

ACK

tp

td

SETUP





• Connection shortening+ transmission delay decreases

– but signalling delay constant

• E2E signalling– significant fraction of time

– connection shortening notproportional to Δ date rate

slow high-speed fast

~1.5tRTT

~2.5tRTT ACK

RELEASE ACK

RELEASE

tRTT

SETUP

RELEASE

ACK

tp

td

tp

td0

SETUP SETUP



E2E State ManagementImpact of Path Length

• Transmission delayand path delay proportional to length

What happens when path length increases?

short links

ACK

RELEASE

SETUP



E2E State ManagementImpact of Path Length

• Transmission delayand path delay proportional to length

• Connection lengthening– path delay increases

– signalling delay increases

• E2E signalling– open state longer

– denial of resource to others

short links long links

SETUP

ACK

RELEASE

SETUP

ACK

RELEASE



E2E Transfer ModesAlternatives

• End-to-end transfer modes– datagram

– connection

– stream

– transaction



E2E Transfer ModesDatagram

• Independent PDUs– each has fully self-describing header

– no end-to-end flow state needed to forward

tp+td



E2E Transfer Modes Connection

• Explicit connection setup– 3-way handshake

SETUP / CONNECT / ACK

why?

~tRTT

ACK

RELEASE

CONNECT

SETUP

~1.5tRTT

~tRTT

tr



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



E2E Transfer ModesTransport and Network Connections

• Transport connections

– required over

• connectionless L3

• path with anyconnectionlesssubnetwork

– may exploit

• connection-oriented L3

SETUP CONNECT

network layer

end system

transport layer

connection-oriented network

network layer

end system

transport layer

setup-req

network layer connection

connectionless network

network layer

transport layer SETUP

CONNECT

network layer

transport layer

transport layer connection

network layer

transport layer SETUP

CONNECT

network layer

transport layer

connection-oriented

subnetwork

connectionless subnetwork

heterogeneous subnetworks



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



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



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



E2E Functions and MechanismsTL.2.3 Reliability and Error Control


TL.2 End-to-End functions and mechanisms









E2E Error ControlTypes of Errors

What are the types of errors?




• Bit errors

types?

• Packet errors

types?




• Bit errors

• Packet errors

– packet loss

– fragment loss

– burst loss

– packet misordering

– packet insertion

– packet duplication



E2E Error ControlCauses of Bit Errors

• Bit errors

causes?



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



E2E Error ControlCauses of Packet Loss

• Packet loss

causes?




• Packet loss

– network buffer overflow or intentional drop

more in Lecture TQ

– transport protocol packet discard when bit error




• Packet loss


more in Lecture TQ


• Packet fragment losscauses?

impact?




• Packet loss


more in Lecture TQ


• 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

– rare in Internet since router fragmentation rarely enabled



E2E Error ControlCauses of Packet Burst Loss

• Packet burst loss

causes?



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



E2E Error ControlCauses of Packet Misordering

• Packet misorderingcauses?



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



E2E Error ControlCauses of Packet Insertion

• Packet insertionmeaning?

causes?



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



E2E Error ControlCauses of Packet Duplication

• Packet duplicationcauses?



E2E Error ControlCauses of Packet Duplication

• Packet duplication

– retransmission but original still arrives



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



E2E Error ControlARQ Closed Loop Retransmission

• Automatic repeat request (ARQ)

– TPDUs are retransmitted for reliable transfer

• Acknowledgments are used to request retransmission

alternatives?







– ACK: positive acknowledgement

– NAK (or NACK): negative acknowledgement

tradeoff?







– ACK: positive acknowledgement

– NAK (or NACK): negative acknowledgement

– tradeoff between error rate and predictability

Simplest ARQ mechanism?



0

E2E Error ControlClosed Loop Retransmission: Stop-and-Wait

• Each TPDU is acknowledged

1




• Each TPDU is acknowledged0

0

2





– subsequent TPDU waits on previous ACK

disadvantages?

0

0

3

A0






• significant delay and underutilisation

• 1 RTT per TPDU

• serious penalty in long-delay environment

0

0

A0

1tack

4







• 1 RTT per TPDU


– sender timer tack fires if ACK not received

issues?

0

0

A0

1tack

5



1





• 1 RTT per TPDU



• too conservative: issues?

• too aggressive: issues?

0

0

A0

1tack

6



1





• 1 RTT per TPDU



• too conservative: unnecessary delay

• too aggressive: spurious retransmissions

0

0

A0

1tack

7

1







• 1 RTT per TPDU



• too conservative: unnecessary delay

• too aggressive: spurious retransmissions

How can we do better?

0

0

A0

1

1

A1

tack

1

8



E2E Error ControlClosed Loop Retransmission: Go-Back-n

• Go-back-n : pipeline transmissions0

1




• Go-back-n : pipeline transmissions

+ multiple TPDUs simultaneously in flight 0

0

2

1

A0



2



+ multiple TPDUs simultaneously in flight

• TPDUs are sequentially acknowledged

0

0

3

1

A0

1

A1

tack



3

2





how is TPDU loss detected?

0

0

4

1

A0

1

A1

tack



4

3

2





o previous ACK retransmitted for

• subsequent TPDUs after loss

• out of sequence TPDU

0

0

5

1

A0

1

A1

tack

A1



5

4

3

2








o sender timer fires if ACK not received

implication?

0

0

6

1

A0

1

A1

tack

A1

A1



2

5

4

3

2









• reset transmission beginning at lost TPDU

0

0

7

1

A0

1

A1

tack

A1

A1

A1



3

A2

2

5

4

3

2










0

0

8

1

A0

1

A1

tack

A1

A1

A1 2



4

3

A2

2

5

4

3

2









• reset transmission beginning at lost TPDUs

0

0

9

1

A0

1

A1

tack

A1

A1

A1 2

3

A3



5

4

3

A2

2

5

4

3

2










0

0

10

1

A0

1

A1

tack

A1

A1

A1 2

3

A3

A4

4



6

5

4

3

A2

2

5

4

3

2










0

0

11

1

A0

1

A1

tack

A1

A1

A1 2

3

A3

A4

4

5

A5



6

5

4

3

A2

2

5

4

3

2










disadvantages?

0

0

12

1

A0

1

A1

tack

A1

A1

A1 2

3

A3

A4

4

5

A56












– 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




• 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




• 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



E2E Error ControlClosed Loop Retransmission: Fast Retransmit

• Fast retransmit– optimisation for go-back-n

0

1




• Fast retransmit

– optimisation for go-back-n 0

0

2

1

A0



2


• Fast retransmit


0

3

1

A0

1

A1

tack



3

2


• Fast retransmit


0

4

1

A0

1

A1

tack



4

3

2


• Fast retransmit

– optimisation for go-back-n

• Assume several duplicate ACKs are loss

0

0

5

1

A0

1

A1

tack

A1



2

5

4

3

2


• Fast retransmit



o even if timer hasn’t yet fired

0

0

6

1

A0

1

A1

tack

A1

A1



3

A2

2

5

4

3

2


• Fast retransmit




+ recovers from loss more quickly

0

0

7

1

A0

1

A1

tack

A1

A1

A12



4

3

A2

2

5

4

3

2


• Fast retransmit





0

0

8

1

A0

1

A1

tack

A1

A1

A12

3

A3



5

4

3

A2

2

5

4

3

2


• Fast retransmit





0

0

9

1

A0

1

A1

tack

A1

A1

A12

3

A3

A4

4



6

5

4

3

A2

2

5

4

3

2


• Fast retransmit





0

0

10

1

A0

1

A1

tack

A1

A1

A12

3

A3

A4

4

5

A5



6

5

4

3

A2

2

5

4

3

2


• Fast retransmit





0

0

11

1

A0

1

A1

tack

A1

A1

A12

3

A3

A4

4

5

A56




• Fast retransmit





– 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



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




• Go-back-n fast retransmit and delayed ACK help slightly

but still significant delay penalty for losses

Alternative?



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




• Selective repeato all TPDUs acknowledged

1

0




• Selective repeat

o all TPDUs acknowledged 0

0

2

1

A0



2




0

3

1

A0

1

A1

tack



3

2




0

4

1

A0

1

A1

tack



4

3

2



o all TPDUs acknowledged

– Missequenced TPDUs

o acknowledged and held at receiver

0

0

5

1

A0

1

A1

tack

A3

3



5

4

3

2




• Missequenced TPDUs

o TPDUs held and reordered at receiver

– increases receiver complexity

0

0

6

1

A0

1

A1

tack

A3

3

A4

43



2

5

4

3

2







• Lost TPDUs

o selectively retransmitted

0

0

7

1

A0

1

A1

tack

A3

3

A4

43

543

A5



6

2

5

4

3

2







• Lost TPDUs


+ 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



7

6

2

5

4

3

2







• Lost TPDUs




0

0

9

1

A0

1

A1

tack

A3

3

A4

43

543

A5

A2

5432

A6

6



8

7

6

2

5

4

3

2







• Lost TPDUs




0

0

10

1

A0

1

A1

tack

A3

3

A4

43

543

A5

A2

5432

A6

6

A7

7



9

8

7

6

2

5

4

3

2







• Lost TPDUs




• 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



E2E Error ControlClosed Loop Retransmission: Periodic State

• Selective ACK blocks

o bit vectors can aggregate ACKs

+ significant reduction in control packets

+ simple receiver implementation possible



E2E Error ControlImpact of Increasing Data Rate


– fixed duration error event larger relative impact

– reaction to errors decreases in terms of number of bits sent


– sequence numbers wrap if sequence space too small

• causes packet misinsertion



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



E2E Error ControlOpen Loop

• Open loop error controlo some applications do not need guaranteed reliability

examples?





• applications that are tolerant to some loss

• real-time or interactive delay requirements

+ eliminates control loop latency for recovery

–

–

Mechanisms?








–

–

• Forward error correction (FEC)– block codes: per block recovery

– convolutional codes: continuous over window

– erasure codes: coding over redundant packets

disadvantages?








– 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



E2E Error ControlHybrid Open/Closed-Loop Control

• Hybrid open loop with closed loop when necessary

why?



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



E2E Functions and MechanismsTL.2.4 Transmission Control











E2E Transmission ControlDefinitions: Flow Control

• Flow control

– control transmission to avoid overwhelming receiver

– end-to-end control



E2E Transmission ControlDefinitions: Congestion Control

• Flow control



• Congestion control

– control transmission to avoid overwhelming network paths



E2E Transmission ControlDefinitions: Implicit vs. Explicit

• Flow 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])



E2E Transmission ControlImpact of Increasing Data Rate


– 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?



E2E Transmission ControlOpen-Loop Rate Control

• Initial negotiation

– admission control limits traffic to available resources

admission

control






– receiver negotiates what it can accept (flow control)

admission

control

receiver

negotiation







• Steady state

– policing enforces traffic contract from transmitter

admission

control

receiver

negotiation

rate

scheduling

rate

policing

conforming traffic







• Steady state

– policing enforces traffic contract from transmitter

• excess traffic may be marked and passed if capacity available

admission

control

receiver

negotiation

rate

scheduling

rate

policing

conforming traffic

excess traffic



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



E2E Transmission ControlOpen-Loop Rate Control: Connections

• Requires connection establishment

(dis)advantages?



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 admitted

lecture TQ



E2E Transmission ControlClosed-Loop Flow and Congestion Control

network congestion control

packet scheduling

flow control

• Flow control

– sender–receiver


– sender–network

• Packet scheduling Lecture TQ



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





– 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





• Steady state

– dynamic window: receive window varies over time

– receiver adjusts with time-varying available buffer space

receive window



E2E Transmission ControlClosed-Loop Congestion Control

• Feedback from network to limit transmission rate


– dynamic window

• adjusted based on network state





– amount of unacknowledged data can be sent into network

• maintained as congestion window at sender

• initial conservative default

ECN

transmission

schedulingAQM

receive window





– amount of unacknowledged data can be sent into network

• Data transfer

– congestion window adjusted to adapt to congestion

ECN

transmission

schedulingAQM

receive window



Congestion ControlIdeal Network

offered load

ca

rrie

d lo

ad

offered load 1.0

de

lay

throughput delay

• Ideal network

throughput characteristics?

delay characteristics?




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?



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




offered load

ideal

ca

rrie

d load

offered load

ideal

1.0

dela

y

throughput delay

• Desired network:

what happens to carried load?



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?



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)



Congestion ControlInfinite Buffers / No Retransmission

• Congestion whenoffered load link capacity

• Infinite buffers

– queue lengthbuilds to infinity

– d

discuss why in Lecture TQ

offered load

ideal

1.0

de

lay knee

dmin

delay



Congestion ControlFinite Buffers with Retransmission

• Finite buffers cause packet loss

– retransmissions contribute to offered load

• assuming reliable protocol

– throughput curve levels off



Congestion ControlMultihop Network

• Multiple hops

– downstream packet loss

– upstream transmission wasted



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



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



Congestion ControlEnd-to-End Action

• End-to-end action

• Throttle source

– reduce transmission rates

– prevent unnecessary retransmissions

• Types

– explicit

– implicit



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




• Feedback from network to limit rate

• Required unless open loop with hard reservations


– dynamic window

– conservation of packets in the network

– self clocking: ACKs determine the transmission of new data



E2E Transmission ControlClosed-Loop Control: Initialisation

• Initial small window sent

– assume 1 TPDU

1

0





– assume 1 TPDU

– TPDU acknowledged

0

0

2

A0





– assume 1 TPDU


• Window doubled

– TPDU + one more sent

0

0

3

1

A0

2





– assume 1 TPDU


• Window doubled


– TPDUs acknowledged

0

0

4

1

A0

2 1

2

A1

A2



3

4

5

6



– assume 1 TPDU


• Window doubled


– TPDUs acknowledged

• Window doubled again

– TPDUs + one more/ACK sent

0

0

5

1

A0

2 1

2

A1

A2




• 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






– 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






• 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



E2E Transmission ControlClosed-Loop Control: Window Size

• Window size critical

what 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



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

A0 A1 A2 A3

A4 A5 A6 A7

4

5

6

A3

A4

A5

2

3

4

5

6

0 1 2 3

4 5 6 7

8

9

10

11

4

5

6

7

0

1

2

3

8 9

10 11

12

A8 A9

A10 A11



E2E Congestion ControlClosed-Loop Control

• Initialisation phase: slow start

Steady-state phase?

time

se

nd

ing

ra

te

slow start

steady state phase initialisation



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



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



E2E Congestion ControlClosed-Loop Control


• Steady-state phase: AIMD

AI

time

MD

se

nd

ing r

ate

slow start





E2E Congestion ControlClosed-Loop Implicit Control

• Implicit control

– missing ACK assumed to be congestion

good assumption?






– reasonable when all losses are due to congestion

• fiber optic channels connected by reliable switches








– performs poorly when significant losses in channel

why?









• mobile wireless links

• under-provisioned CDMA (including optical CDMA)









• mobile wireless links

• under-provisioned CDMA (including optical CDMA)

Alternatives?



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 EECS 882



E2E Congestion ControlClosed-Loop 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



E2E Transmission ControlClosed-Loop Control: Steady State


– standard

– with fast retransmit


– ECN



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



Transport LayerTL.3 Internet Transport Protocols

TL.1 Transport Services and interfaces



TL.3.1 UDP

TL.3.2 RTP introduction

TL.3.3 TCP




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



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



Internet Transport ProtocolsImportant Examples

Protocol Name Function Status Ref

TCPtransmission control

protocolreliable data transfer with

congestion controlstandard

RFC 0793STD 0007

UDPuser datagram

protocolsocket access to unreliable

IP datagramsstandard

RFC 0768STD 0006

RTP real-time protocolreal-time synchronisation

(typically over UDP)

standards track

RFC 3550STD 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 standard

RFC 2960



Internet Transport ProtocolsTL.3.1 UDP




TL.3.1 UDP


TL.3.3 TCP




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



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)



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



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


length checksum

application payload

(= length – 8B)







1110011001100110

+1101010101010101

11011101110111011


length checksum

application payload

(= length – 8B)







1110011001100110

+1101010101010101

11011101110111011

1011101110111100


length checksum

application payload

(= length – 8B)







1110011001100110

+1101010101010101

11011101110111011

1011101110111100

0100010001000011


length checksum

application payload

(= length – 8B)







1110011001100110

+1101010101010101

11011101110111011

1011101110111100

0100010001000011

– sender computes+inserts– receiver compute+compares– weak protection [RFC 3385]

• No retransmission at L4


length checksum

application payload

(= length – 8B)



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



User Datagram ProtocolTypical Applications

• Typical application: multimedia streaming

why?





– loss tolerant

– rate sensitive (do not adapt well to TCP congestion control)

– research community considering alternatives





– loss tolerant

– rate sensitive (do not adapt well to TCP congestion control)

– research community considering alternatives

• Other applications: network control protocols

– e.g. DNS



Internet Transport ProtocolsTL.3.2 RTP Introduction




TL.3.1 UDP


TL.3.3 TCP




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



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)


length checksum

CSRC list: contributing source ids

. . .

optional padding

application payload

SSRC: synchronisation source id

timestamp

sequence #02 P X CC PT

#B pad



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.



Real-Time ProtocolControl Protocol Overview

• RTCP: real-time control protocol [RFC 3550 / STD 0064]

– monitoring quality of service

– convey participant status information



Internet Transport ProtocolsTL.3.3 TCP


TL.2 end-to-end functions and mechanisms


TL.3.1 UDP


TL.3.3 TCP




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



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



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



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)


receive window

ack number

sequence number


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



Transmission Control ProtocolSegment Format: No Options

• Header with no options– 20B long


receive window

ack number

sequence number


application

payload

(variable length)

flags20

32 bits

20B



Transmission Control ProtocolSegment Format: No Options Nor Data

• Entire segment– 20B long

• Example:– ACKs

– significant fractionof Internet packets40B

why?


receive window

ack number

sequence number


flags20

32 bits

20B



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)


receive window

ack number

sequence number



application

payload

(variable length)

flagsHL

32 bits

20B

40B



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



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


receive window

ack number

sequence number



application

payload

(variable length)

flagsHL



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



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


receive window

ACK number

sequence number



application

payload

(variable length)

CEUAPRSFHL



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

FIN

ACK

buffer

alloc

buffer

alloc

estab.

state

C S



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



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 |

+---------+ +---------+



Transmission Control ProtocolActual Connection State Machine

[Sewell] http://www.cl.cam.ac.uk/users/pes20/Netsem



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


receive window

ACK number

sequence number



application

payload

(variable length)

HL CEUAPRSF



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 #)



data segment (MSS bytes)

SN=?


net

SYN (ISNs)

ACK

SYN(ISNc)ACK

C S

2



– each segment MSS B


– byte # in byte streamof 1st byte in segment




SN=ISNs


net

SYN (ISNs)

ACK

SYN(ISNc)ACK

C S

ACK AN=?

3






• ACK numbers





SN=ISNs


net

SYN (ISNs)

ACK

SYN(ISNc)ACK

C S

ACK AN=ISNs+MSS


SN=?

4






• ACK numbers





SN=ISNs


net

SYN (ISNs)

ACK

SYN(ISNc)ACK

C S

ACK AN=ISNs+MSS


SN=ISNs+MSS

ACK AN=?

5






• ACK numbers


– cumulative ACKs




SN=ISNs


net

SYN (ISNs)

ACK

SYN(ISNc)ACK

C S

ACK AN=ISNs+MSS


SN=ISNs+MSS

ACK AN=ISNs+2MSS

6what next?






• ACK numbers


– cumulative ACKs




SN=ISNs+2MSS


SN=ISNs


net

SYN (ISNs)

ACK

SYN(ISNc)ACK

C S

ACK AN=ISNs+MSS


SN=ISNs+MSS

ACK AN=ISNs+2MSS

7what next?






• ACK numbers


– cumulative ACKs




SN=ISNs+2MSS


SN=ISNs


net

SYN (ISNs)

ACK

SYN(ISNc)ACK

C S

ACK AN=ISNs+MSS


SN=ISNs+MSS

ACK AN=ISNs+2MSS

8

ACK AN=ISNs+3MSS

• Data is sequence of bytes– number by byte #

(not segment #)


• 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




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




SN=ISNc


SN=ISNs


net

SYN (ISNs)

ACK

SYN(ISNc)ACK

C S

ACK AN=ISNs+MSS

2what next?



– may be piggybacked




SN=ISNc


SN=ISNs


net

SYN (ISNs)

ACK

SYN(ISNc)ACK

C S

ACK AN=ISNs+MSS

3


SN=ISNs+MSS

ACK AN=ISNc+MSS

what next?




– delayed ACK waits briefly




SN=ISNc


SN=ISNs


net

SYN (ISNs)

ACK

SYN(ISNc)ACK

C S

ACK AN=ISNs+MSS

4


SN=ISNs+MSS

ACK AN=ISNc+MSS




– delayed ACK waits briefly

• Bidirectional stream

– data segments

– piggybacked ACKs



Transmission Control ProtocolSegment Format: Push

• Push

– PSH flag set

– receiver should immediatelysend to application

– don’t wait to fill buffer

– example use: telnet

• avoid buffering delay

checksum urg data ptr

receive window

ACK number

sequence number



application

payload

(variable length)

CEUAPRSFHL



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 ptr

receive window

ACK number

sequence number



application

payload

(variable length)

CEUAPRSFHL



Transmission Control ProtocolWindow-Based Feedback Control

• Windowing used for a combined:– error control

– flow control

– congestion control

• Window limits amount of unACKed data transmitted



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)



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)



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


receive window

ack number

sequence number


application

payload

(variable length)

flagsHL

32 bits

seq num after last byte

seq num of 1st byte

05 len0101



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



Transmission Control ProtocolTimeout

How to set TCP timeout value?




• 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?




• 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



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



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

iseconds)

SampleRTT Estimated RTT



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



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



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



Transmission Control ProtocolCongestion Control


• Steady-state phase: AIMD

AI

time

MD

sendin

g r

ate

slow start





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



Transmission Control ProtocolExplicit Congestion Notification

• Network nodes setcongestion indication

– hist. ICMP source quench

– ECN bits in IP header

• TCP reacts

– uses flags for signalling


receive window

ACK number

sequence number



application

payload

(variable length)

CEUAPRSFHL



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



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 since Vista



Transmission Control ProtocolHigh-Bandwidth--Delay Optimisations

• High bandwidth--delay paths (long fat pipes)

problem?





– problem: large number of bits in flight

Implications to TCP?






• 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? )






• 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



Transport LayerTL.4 Multipoint Communication







E2E Multipoint CommunicationMotivation for E2E Multicast

• End-to-end multicast is necessary if:

• Network layer multicast not available

why?

• Reliability is needed

why?



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 multicast

application-layer multicast



E2E Multipoint CommunicationClosed Loop Retransmission: Multicast

• ACK implosion: ACK suppression needed

o NAKs (negative ACKs) with liveness polling

o localised hop-by-hop buffering and retransmission

– significant reduction of traffic on relatively reliable links

R

6

ACK

ACK2 ACK2

ACK4

ACK ACK6

R

6

NAK

NAK

NAK

NAK2

3 1 2 4 3 1 2 4

ACK ACK

ACK

5

ACK NAK

5

NAK



Transport LayerFurther Reading and Additional References

• 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.



Transport LayerAcknowledgements

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

ITTC © James P.G. Sterbenz Communication...

Documents

Transcript of ITTC © James P.G. Sterbenz Communication...