Chapter 3 Transport Layer Chapter 3: Transport Layer Our goals: - - PowerPoint PPT Presentation

1

Chapter 3: Transport Layer Chapter 3 Transport Layer

Our goals:



d t d i i l

 l

n b t t nsp t

 understand principles

behind transport layer services:

 learn about transport

layer protocols in the Internet: y

 multiplexing/

demultiplexing

 reliable data transfer  UDP: connectionless

transport, unreliable delivery of segments

 reliable data transfer  flow control  congestion control  TCP: connection-oriented

transport, reliable delivery

• f byte stream

Transport Layer (SSL) 3-1 10/17/2017

2

Chapter 3 outline Chapter 3 outl ne

 3.1 Transport-layer  3.5 Connection-oriented

p y services

 3.2 Multiplexing and

d lti l i transport: TCP

 segment structure  reliable data transfer

demultiplexing

 3.3 Connectionless

transport: UDP

 reliable data transfer  flow control  connection management

tran p rt D

 3.4 Principles of

reliable data transfer

 3.6 Principles of

congestion control

 3 7 TCP congestion

(my slides for Section 3.4 do not follow Kurose & Ross)

 3.7 TCP congestion

control

Transport Layer (SSL) 3-2

Kurose & Ross)

10/17/2017

3

Transport services and protocols Transport serv ces and protocols

 provide logical communication

between app processes on

application transport network data link physical

between app processes on different hosts

 transport protocol runs in

end systems (primarily)

phys cal

end systems (primarily)

 send side: breaks app

messages into segments, passes to network layer passes to network layer

 rcv side: reassembles

segments into messages, passes to app layer

application transport network data link physical

passes to app layer

Transport Layer (SSL) 3-3 10/17/2017

4

Internet transport-layer protocols

 unreliable, unordered

datagram delivery by UDP

application transport network d li k

datagram delivery by UDP

 no-frills extension of “best-

effort” IP

data link physical network data link physical network data link physical

 reliable, in-order byte

delivery by TCP

 connection setup

network d li k network data link physical

 connection setup  flow control  congestion control

i il bl

network data link h i l network data link physical data link physical application transport network

 services not available:

 delay guarantees  bandwidth guarantees

physical data link physical

Transport Layer (SSL) 3-4

g

10/17/2017

5

Chapter 3 outline Chapter 3 outl ne

 3.1 Transport-layer  3.5 Connection-oriented

p y services

 3.2 Multiplexing and

d lti l i transport: TCP

 segment structure  reliable data transfer

demultiplexing

 3.3 Connectionless

transport: UDP

 reliable data transfer  flow control  connection management

tran p rt D

 3.4 Principles of

reliable data transfer

 3.6 Principles of

congestion control

 3 7 TCP congestion  3.7 TCP congestion

control

Transport Layer (SSL) 3-5 10/17/2017

6

Multiplexing/demultiplexing Multiplexing/demultiplexing

deliver received segments Demultiplexing at rcv host: gather data from multiple Multiplexing at send host:

/th d k t

deliver received segments to correct sockets sockets, encapsulate data with header (later used for demultiplexing)

application P1 application application P2 P3 P4 P1 process/thread socket transport network transport network transport network link physical link physical link physical

Transport Layer (SSL) 3-6

host 1 host 2 host 3

10/17/2017

7

How demultiplexing works m p g

32 bits

 host receives IP datagrams  It uses IP addresses in layer-

source port # dest port #

y 3 header & port numbers in layer-4 header to direct segment to appropriate

• ther header fields

socket application data (message) ( g ) TCP/UDP segment format

Transport Layer (SSL) 3-7 10/17/2017

8

Connectionless demultiplexing Connect onless demult plex ng

 UDP socket identified by  IP datagrams from  UDP socket identified by

two-tuple: (dest IP address, dest port number)

 IP datagrams from

different sources directed to same UDP k t

 When host receives UDP

segment: socket segment:

 directs UDP segment to

socket with destination port number number

Transport Layer (SSL) 3-8 10/17/2017

9

Connection-oriented demux Connect on or ented demux

 Server has welcome and  Server may support

connection sockets

 welcome socket is

identified by server’s IP dd d

y pp many simultaneous TCP connection sockets with clients:

address and a port number  TCP connection socket

id tifi d b 4 t l

 each connection socket

and the welcome socket have the same port b i s h st

identified by 4-tuple:

 source IP address  source port number

number in server host

 receiving host uses all

four values to direct segment to appropriate

 dest IP address  dest port number

segment to appropriate connection socket

Transport Layer (SSL) 3-9 10/17/2017

10

Connection-oriented demux ( t) (cont)

P1 P1 P2 P3 P4 SP: 5775 DP: 80 D IP C S-IP: B

Client client

SP: 9157 DP: 80 SP: 9157 DP: 80 D-IP:C

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

DP: 80 DP: 80 D-IP:C S-IP: A D-IP:C S-IP: B

Transport Layer (SSL) 3-10 10/17/2017

11

Chapter 3 outline Chapter 3 outl ne

 3.1 Transport-layer  3.5 Connection-oriented

p y services

 3.2 Multiplexing and

d lti l i transport: TCP

 segment structure  reliable data transfer

demultiplexing

 3.3 Connectionless

transport: UDP

 reliable data transfer  flow control  connection management

tran p rt D

 3.4 Principles of

reliable data transfer

 3.6 Principles of

congestion control

 3 7 TCP congestion  3.7 TCP congestion

control

Transport Layer (SSL) 3-11 10/17/2017

12

UDP: User Datagram Protocol [RFC 768] g [ ]

 “best effort” service, UDP

segments (aka datagrams) b

Length, in bytes of UDP segment including header

may be:

 lost  delivered out of order

g g source port #

• dest. port #

32 bits

to appl

 connectionless:

 no handshaking between

length checksum

no handshak ng between UDP sender, receiver

 each UDP segment

handled independently Application data p y

• f others

data (message)

Transport Layer (SSL) 3-12

UDP segment format

10/17/2017

13

UDP (more)

 suitable for interactive

streaming multimedia applications

Adv nt s f UDP

pp

 loss tolerant  min rate required

 other UDP uses e g

Advantages of UDP

 no congestion control: UDP

can blast away as fast as d i d  other UDP uses, e.g.

 DNS  SNMP

desired

 small segment header  no connection

 DHCP

 reliable transfer over

UDP? establishment (which can add delay)

 simple: no connection state

t d i

add reliability in application layer

 application-specific

at sender, receiver

Transport Layer (SSL) 3-13

pp p f error recovery

10/17/2017

14

Internet checksum

S nd : Sender:

 treat segment as a

sequence of 16-bit i t

Receiver:

 compute 1’s complement sum

integers (with checksum field

initialized to zero)

 add integers using 1’s

complement arithmetic

• f received segment (checksum

field included)

 check if computed sum equals

si t 1’s: complement arithmetic and take 1’s complement

• f the sum

 put result as checksum

sixteen 1’s:

 NO - error detected  YES - no error detected

 put result as checksum

value into checksum field

 detail: pseudoheader

consisting of protocol no IP

But maybe errors nonetheless? More later ….

consisting of protocol no., IP addresses, segment length field (again) included in checksum calculation

Transport Layer (SSL) 3-14 10/17/2017

15

Internet Checksum Example

N

 Notes

 In ones complement arithmetic, a negative integer -x is

represented as the complement of x, i.e., each bit of x is p p , , inverted

 When adding numbers, a carryout from the most

significant bit needs to be added to the result g

 Example: add two 16-bit integers

1 1 1 1 0 0 1 1 0 0 1 1 0 0 1 1 0 1 1 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 1 1 0 1 1 1 0 1 1 1 0 1 1 1 0 1 1 1 1 1 1 1 1 1 1 1 1 1 1 wraparound sum

Transport Layer (SSL) 3-15

1 1 0 1 1 1 0 1 1 1 0 1 1 1 1 0 0 1 0 1 0 0 0 1 0 0 0 1 0 0 0 0 1 1 checksum

10/17/2017

16

Chapter 3 outline Chapter 3 outl ne

 3.1 Transport-layer  3.5 Connection-oriented

p y services

 3.2 Multiplexing and

d lti l i transport: TCP

 segment structure  reliable data transfer

demultiplexing

 3.3 Connectionless

transport: UDP

 reliable data transfer  flow control  connection management

tran p rt D

 3.4 Principles of

reliable data transfer

 3.6 Principles of

congestion control

 3 7 TCP congestion

(my slides do not follow Kurose & Ross)

 3.7 TCP congestion

control

Transport Layer (SSL) 3-16 10/17/2017

17

Principles of Reliable data transfer p f f

 important in application, transport, link layers  top-10 list of important networking topics!  top-10 list of important networking topics!

Transport Layer (SSL) 3-17 10/17/2017

18

Principles of Reliable data transfer p f f

 important in app., transport, link layers  top-10 list of important networking topics!  top 10 list of important networking topics!  characteristics of unreliable channel will determine

Transport Layer (SSL) 3-18

 characteristics of unreliable channel will determine

complexity of reliable data transfer protocol (rdt)

10/17/2017

19

Principles of Reliable data transfer p f f

 important in app., transport, link layers  top-10 list of important networking topics!  top 10 list of important networking topics!  characteristics of unreliable channel will determine

Transport Layer (SSL) 3-19

 characteristics of unreliable channel will determine

complexity of reliable data transfer protocol (rdt)

10/17/2017

20

Channel Abstractions Channel Abstract ons

 Lossy FIFO channel  Lossy FIFO channel

 delivers a subsequence in FIFO order  example: delivery service provided by a

p y p y physical link

L d i d li i (LRD)

 Lossy, reordering, duplicative (LRD)

channel

 x mpl : d liv

s vic p vid d b IP b

 example: delivery service provided by IP or by

UDP protocol

Transport Layer (SSL) 3-20 10/17/2017

21

Stop-and-wait ARQ (automatic repeat request)

 Error-free operation

S d Sender Time Receiver

ack ack

Transport Layer (SSL) 3-21 10/17/2017

22

Stop-and-wait ARQ

R f

 Retransmission after timeout  Recovery from loss of frame

ti t Sender timeout retransmission Ti Error Time R i

k

Transport Layer (SSL) 3-22

Receiver

ack

10/17/2017

23

Stop and wait ARQ Stop-and-wait ARQ

R t i i

 Retransmission

after timeout to recover from

Sender timeout retransmission

recover from loss of ack

 Receiver gets

Time E

 Receiver gets

duplicate frame

 Sequence number

Error

q needed in frame

Receiver

Transport Layer (SSL) 3-23 10/17/2017

24

Stop-and-wait ARQ

S b l d d i k

 Sequence number also needed in ack

timeout retransmission Sender thinks this is an ack for frame 1 Sender

1

Time Time Receiver Error

ack ack

Transport Layer (SSL) 3-24 10/17/2017

25

Stop-and-wait ARQ

 Operation with 1-bit sequence numbers in

frames and acks

Discard Sender timeout

1 1

timeout ACK ACK Time R i Error

Transport Layer (SSL) 3-25

Receiver

10/17/2017

26

Alternating-Bit Protocol

Sender P1 (initial state = 1a) Receiver P2 (initial state 1a) Sender P1 (initial state = 1a)

1b

• A1

+D1 Receiver P2 (initial state = 1a)

1a 1b

+A1

• D0

accept data

1a

• A1

+D0

• A1

+D1

4b 4a 2a 2b

• D1

+A1 +A0

• D0

+A1

• D0

timeout timeout

msgs in transit

 Sender and Receiver specified by

2a 4b 4a 2b

deliver data deliver data

3b 3a

• D1

+A0 D0

accept data m

 Sender and Receiver specified by

communicating finite-state machines

 Notation for edge labels

3a

• A0

+D1 A0 D0

• m

send m essage m +m receive m essage m if it is waiting to be received

3b

• A0

+D0

Protocol state space is

Transport Layer (SSL) 3-26

waiting to be received

10/17/2017

Protocol state space is infinite

27

Alternating-Bit Protocol (cont.) Alternat ng B t Protocol (cont.)

 Assertion: If Sender and Receiver  Assertion: If Sender and Receiver

communicate via lossy FIFO channels, the alternating-bit protocol provides reliable in-order data delivery.

 Assumption: A frame is retransmitted

infinitely many times if it is lost infinitely many times.

N A l l i i ll d i d Note: A real protocol is typically designed to retransmit a fixed number of times (say k).

Transport Layer (SSL) 3-27 10/17/2017

28

Stop-and-wait ARQ performance analysis

Tf

Sender

2τ + TA + TP Ti Time

Receiver

T TA

ack

Transport Layer (SSL) 3-28

TP τ τ

10/17/2017

29

1

probability transmission is unsuccessful Prob[success after transmissions] for 1,2,... (1 )

i i

P b i i b P P

−

= = =

Average number of transmissions per frame

1(1

)

i i

b P P = −

1 1 1 1

(1 )

i i i i

f

N i b i P P

∞ ∞ − = = ∞

= = −

  

1 1

(1 ) (1 ) (1 )

i i i i

P i P d d P P P P

− = ∞ ∞

= − = =

  

1 2

(1 ) (1 ) 1 1 (1 ) (1 ) 1 (1 )

i i

P P P P dP dP d P P dP P P

= =

= − = − = − = −

 

2

( ) ( ) 1 (1 ) 1 1

f

dP P P N P − − = = −

Transport Layer (SSL) 3-29

1 P

10/17/2017

30

Timeout duration T > 2τ +TA +TP Each unsuccessful transmission uses Tf + T E h f l t i i Each successful transmission uses Tf + 2τ + TA + TP Average time per frame Average time per frame (Nf – 1) (Tf +T) + (Tf + 2τ + TA + TP) Max utilization (throughput) of stop-and-wait

• Max. utilization (throughput) of stop and wait

U

f

T P = ( ) 2 1

f f A P

P T T T T T P τ + + + + + −

Transport Layer (SSL) 3-30 10/17/2017

31

Propagation delay versus transmission time

U ≅ T f

Assume P = 0, TA = 0, TP = 0

(upper bound)

U ≅ T f + 2τ = 1 = 1 where a = τ

( pp )

1 + 2τ T f 1 + 2a where a T f

N t

d i s t a n c e p r o p a g a t i o n s p e e d

τ

=

Note:

f r a m e l e n g t h t r a n s m i s s i o n r a t e

f

T =

Transport Layer (SSL) 3-31 10/17/2017

32

Performance of AB protocol

 AB protocol works, but performance degrades for

channels with large delay-bandwidth product

 example: 1 Gbps link, 15 ms prop. delay, 1KByte packet Ttransmit = 8Kbits 10**9 bits/sec= 8 microsec U = 8 microsec 30008 microsec = 0.00027 th protocol limits use of available bandwidth  Note: If the sender and receiver are connected by the

 the protocol limits use of available bandwidth

Transport Layer (SSL) 3-32

Internet, then is the end-to-end Internet delay

10/17/2017

τ

33

Pipelined protocols

Pi li i d ll l i l “i fli h ” Pipelining: sender allows multiple, “in-flight”, yet-to- be-acknowledged packets

 range of sequence numbers must be increased

g q

 buffering at sender and/or receiver

 Pipelined protocols: (i) concurrent logical channels

(used in ARPANET), (ii) sliding window protocol (TCP)

Transport Layer (SSL) 3-33

( ), ( ) g p ( )

10/17/2017

34

Sliding Window Protocol Sl d ng W ndow Protocol

 Consider an infinite array, Source, at the

d d i fi it Si k t th sender, and an infinite array, Sink, at the receiver.

send window

Source: 1 2 a–1 a s–1 s

send window acknowledged unacknowledged

Source:

P1 Sender received r + RW – 1

Sink:

next expected P2 Receiver

1 2

r delivered receive window RW i i d i

Transport Layer (SSL) 3-34

RW receive window size SW send window size (s - a ≤ SW)

10/17/2017

35

Sliding Windows in Action Sl d ng W ndows n Act on

 Data unit r has just been received by P2

 Receive window slides forward  Receive window slides forward

 P2 sends cumulative ack with sequence

number it expects to receive next (r+3) number it expects to receive next (r+3)

1 2 a–1 a s–1 s

send window

Source: P1 Sender

unacknowledged acknowledged

Sender r+3 1 2

r r + RW – 1

Sink: P2 Receiver

next expected

Transport Layer (SSL) 3-35

delivered receive window

Receiver 10/17/2017

36

Sliding Windows in Action Sl d ng W ndows n Act on

 P1 has just received cumulative ack with

3 t t d b r+3 as next expected sequence number

 Send window slides forward

1 2 a–1 a s–1 s

send window

Source: P1 Sender

acknowledged r + RW – 1 next expected

1 2

r delivered receive window

Sink: P2 Receiver Transport Layer (SSL) 3-36

delivered receive window

10/17/2017

37

Sliding Window protocol

 Functions provided

 error control (reliable delivery)  in-order delivery  flow and congestion control (by varying send

i d i ) window size)  TCP uses cumulative acks (needed for correctness)  Oth

ki d f k

 Other kinds of acks (to improve performance)

 selective nack  selective ack (TCP SACK)  selective ack (TCP SACK)  bit-vector representing entire state of receive

window (in addition to first sequence number of

Transport Layer (SSL) 3-37

( q window)

10/17/2017

38

Sliding Windows for Lossy FIFO Channels

A ll b f bi i k h d f

 A small number of bits in packet header for

sequence number

 Necessary and sufficient condition for correct  Necessary and sufficient condition for correct

• peration: SW + RW ≤ MaxSeqNum

 Necessity:

RW receive window size SW send window size

P1 Sender 1 2 a–1 a

send window

Source:

SW send window size

acknowledged unacknowledged

Sink:

next expected

P2 Receiver 1 2

delivered

Sink:

p receive window

Transport Layer (SSL) 3-38 10/17/2017

39

Sliding Windows for Lossy FIFO Ch l Channels

 Sufficiency can only  Interesting special  Sufficiency can only

be demonstrated by using a formal

 Interesting special

cases

 SW = RW = 1

method to prove that the protocol provides li bl i d

alternating-bit protocol

 SW = 7 RW = 1

reliable in-order

• delivery. See

Shankar and Lam

 SW = 7, RW = 1

• ut-of-order arrivals

not accepted, e.g., HD

Shankar and Lam, ACM TOPLAS, Vol. 14, No. 3, July 1992.

HDLC

 SW = RW

Transport Layer (SSL) 3-39

, , y

10/17/2017

40

Sliding Windows for LRD Channels Sl d ng W ndows for LRD Channels

 Assumption: Packets have bounded lifetime L  Assumption: Packets have bounded lifetime L  Be careful how fast sequence numbers are

consumed (i.e., by arrival of data to be sent m ( , y f into network) (send rate)× L < MaxSeqNum

 TCP

 32-bit sequence numbers  counts bytes  assumes that datagrams will be discarded by IP

if too old

Transport Layer (SSL) 3-40

if too old

10/17/2017

41

Sliding Window Protocol Performance Analysis

 Assumpti ns

Go to slide 3 46

 Assumptions

 ack transmission time is negligible, TA = 0  receiver processing time is negligible, TP = 0

Go to slide 3-46

p g g g ,

P

 send window size is W

Tf Tf

.

WTf 2τ

ACK

WTf 2τ

. . .

2τ

f

. . . . .

time

(b) WT < 2τ + T (a) WT > 2τ + T

Transport Layer (SSL) 3-41

(b) WTf < 2τ + Tf (a) WTf > 2τ + Tf

10/17/2017

42

Performance for Error-Free Channels rformanc for Error Fr hann s

 Maximum utilization

U = 1 WT f > 2τ +Tf WTf     

D f

f

Tf + 2τ WT f ≤ 2τ +Tf   

 Define a = τ/Tf

1 W > 2a+ 1    U = W 1+ 2a W ≤ 2a+ 1      

W=1 is special case of alternating-bit protocol

Transport Layer (SSL) 3-42 10/17/2017

43

Performance Analysis for Error- Prone Channels Prone Channels

 Define Nf = Average number of transmissions per frame  Maximum utilization

U = 1 N f W > 2a+1 W/ N     

 To determine Nf for two cases

W/ N f 1+ 2a W ≤ 2a+1   

m

f f

 Selective repeat (optimistic performance)  Go-back-N (pessimistic performance)

Transport Layer (SSL) 3-43 10/17/2017

44

Performance Analysis of Error-Prone Channels

P = probability a transmission is unsuccessful

 S l

ti p t (

b d U)  Selective repeat (-> upper bound on U)

N f = 1 1− P U = 1− P W > 2a+ 1    

 Go-back-N (-> lower bound on U)

U = W(1−P) 1+ 2a W ≤ 2a+ 1    

 Go back N ( > lower bound on U) Each lost frame requires the retransmission of N frames where 1 ≤ N ≤ W

Transport Layer (SSL) 3-44 10/17/2017

45

 With probability (1 P)Pi a frame requires

Go-back-N (cont.)

i ∞



 With probability (1–P)Pi, a frame requires

1+iN transmissions to succeed, for i=0,1,...

1

(1 ) (1 ) (1 ) (1 )

i f i i i

N iN P P P P NP P i P

= ∞ ∞ −

= + − = − + −

  

( ) ( ) 1 (1 )

i i i i

d NP P P dP

= = ∞ =

= + −

  

1 1 (1 ) 1 1

i

dP d NP P dP P

=

= + − −

2

1 1 (1 ) (1 ) 1 NP P P NP = + − − = +

Transport Layer (SSL) 3-45

1 1 P = + −

10/17/2017

46

For 2

f f

WT T τ > +

From previous slide

Go-back-N (cont.)

Go to slide 3-41

Case (a)

What is N ?

For 2 2

f f f f

WT T NT T τ τ > + ≅ +

1 1

f

NP N P = + −

Case (a)

1 2 (1 2 ) 1 2 1 2 1 N a a P P P aP aP N ≅ + + − + + + = + = = 1 1 1 1

f

N P P P = + = = − − − F 2 WT T ≤

(b)

For 2

f f

WT T N W τ ≤ + =

Case (b)

1 1 1 1

f

WP P WP N P P − + = + = − −

Transport Layer (SSL) 3-46 10/17/2017

47

 Recall (f

lid 3 43) From previous slide

Go-back-N (cont.)

 Recall (from slide 3-43)

U 1 N f W > 2a+1    

1 2 1

f

aP N P + = −

From previous slide

U =

f

W/ N f 1+ 2a W ≤ 2a+1    

1 1

f

P WP N P − + = −

 Maximum utilization

 1 2 1 1 2 P W a aP U −  > +  +  =  (1 ) 2 1 (1 2 )(1 ) U W P W a a P WP =  −  ≤ + + − +  

Transport Layer (SSL) 3-47

( )( )  

10/17/2017

48

Chapter 3 outline Chapter 3 outl ne

 3.1 Transport-layer  3.5 Connection-oriented

p y services

 3.2 Multiplexing and

d lti l i transport: TCP

 segment structure  reliable data transfer

demultiplexing

 3.3 Connectionless

transport: UDP

 reliable data transfer  flow control  connection management

tran p rt D

 3.4 Principles of

reliable data transfer

 3.6 Principles of

congestion control

 3 7 TCP congestion  3.7 TCP congestion

control

Transport Layer (SSL) 3-48 10/17/2017

49

TCP: Overview

RFCs: 793, 1122, 1323, 2018, 2581  reliable, in-order byte

steam service

 connection-oriented

 handshaking initializes

sender receiver state

 no “message boundaries”  send and receive

buffers sender, receiver state before data exchange  point-to-point  pipelined

 send window size

determined by TCP

 two sender-receiver pairs  bi-directional data flows in

same connection determined by TCP congestion and flow control  MSS: maximum segment

size

 less than MTU of directly  less than MTU of directly

connected network

socket door TCP TCP socket door application writes data application reads data

Transport Layer (SSL) 3-49

send buffer receive buffer

segment

10/17/2017

50

TCP segment structure

P1 P2 Send  Receive Receive  Send

source port # dest port #

32 bits URG: urgent data (generally not used) ACK # count by bytes

• f data

sequence number acknowledgement number

Receive window

F S R P A U

head not

ACK # valid PSH h d t

• f data

(not segments) count in 32-bit words Receive window Urg data pnter checksum

F S R P A U

len used

Options (variable length)

PSH: push data now (generally not used) RST, SYN, FIN: # bytes rcvr willing to accept

application Options (variable length)

, , connection estab. (setup, teardown commands)

Control info for pp data (variable length)

Internet checksum (as in UDP)

both forward and reverse data transfers

Transport Layer (SSL) 3-50 10/17/2017

51

TCP seq. #’s and ACKs TCP seq. # s and ACKs

• Seq. #

 sequence number of

Host A Host B

q m f first byte in segment’s data ACK

User types ‘C’ host ACKs i t f

 seq # of next byte

expected from other side

receipt of ‘C’, echoes back ‘C’

 cumulative ACK

Q: how receiver handles

host ACKs receipt

• f echoed

‘C’

Q: how receiver handles

• ut-of-order segments?

TCP spec doesn’t say, up to implementor

‘C’

time

Transport Layer (SSL) 3-51

to implementor simple telnet scenario

10/17/2017

52

TCP Round Trip Time and Timeout

Q: how to set TCP timeout value?

Q: how to estimate RTT?

 SampleRTT: measured time from

 longer than RTT

 but RTT varies, may be

too short or too long

 SampleRTT: measured time from

segment transmission until ACK receipt

 ignore retransmissions

too short or too long  too short: premature

timeout

 ignore retransmissions

 SampleRTT will vary, want

estimated RTT “smoother” l t

 unnecessary

retransmissions

 t

l sl ti

 average several recent

measurements, not just current SampleRTT  too long: slow reaction

to segment loss

Transport Layer (SSL) 3-52 10/17/2017

53

TCP Round Trip Time and Timeout

EstimatedRTT = (1- α)*EstimatedRTT + α*SampleRTT  Exponentially weighted moving average  influence of past sample decreases

p p exponentially fast

 typical value: α = 0.125

Transport Layer (SSL) 3-53 10/17/2017

54

Example RTT estimation: p

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

350 300 250 T (milliseconds) 150 200 RT 100 1 8 15 22 29 36 43 50 57 64 71 78 85 92 99 106 time (seconnds)

Transport Layer (SSL) 3-54

time (seconnds) SampleRTT Estimated RTT

10/17/2017

55

Setting the timeout interval

 EstimtedRTT plus “safety margin”

 large variation in EstimatedRTT -> larger safety  large variation in EstimatedRTT > larger safety

margin  estimate how much SampleRTT deviates from  estimate how much SampleRTT deviates from

EstimatedRTT and update DevRTT = (1-β)*DevRTT + β*|SampleRTT-EstimatedRTT|

(typically, β = 0.25)

TimeoutInterval = EstimatedRTT + 4*DevRTT Then set timeout interval:

Transport Layer (SSL) 3-55 10/17/2017

56

Chapter 3 outline Chapter 3 outl ne

 3.1 Transport-layer  3.5 Connection-oriented

p y services

 3.2 Multiplexing and

d lti l i transport: TCP

 segment structure  reliable data transfer

demultiplexing

 3.3 Connectionless

transport: UDP

 reliable data transfer  flow control  connection management

tran p rt D

 3.4 Principles of

reliable data transfer

 3.6 Principles of

congestion control

 3 7 TCP congestion  3.7 TCP congestion

control

Transport Layer (SSL) 3-56 10/17/2017

57

TCP reliable data transfer TCP rel able data transfer

 TCP creates reliable  Retransmissions are

service on top of IP’s unreliable service triggered by:

 timeout events

 Cumulative acks

 duplicate acks

 Initially consider  TCP uses single

retransmission timer

 Initially consider

simplified TCP sender:

 ignore duplicate acks  ignore flow control,

congestion control

Transport Layer (SSL) 3-57 10/17/2017

58

Sliding Window Protocol

At the sender, a will be pointed to by SendBase, and s by NextSeqNum and s by NextSeqNum

1 2 a–1 a s–1 s send window Source: P1 S d 1 2 a 1 a s 1 s acknowledged unacknowledged Sender r + RW – 1

next expected

P2 Receiver 1 2 r received d li d i i d r + RW – 1 Sink:

next expected

delivered receive window

RW receive window size SW send window size (s - a ≤ SW)

Transport Layer (SSL) 3-58

SW send window size (s - a ≤ SW)

10/17/2017

59

TCP

NextSeqNum = InitialSeqNum SendBase = InitialSeqNum loop (forever) { switch(event)

TCP sender

(simplifi d)

( ) event: data received from application above and send window has enough room create TCP segment with sequence number NextSeqNum (simplified) g q q if (timer currently not running) start timer pass segment to IP NextSeqNum = NextSeqNum + length(data) q q g ( ) event: timer timeout retransmit not-yet-acknowledged segment with smallest sequence number q start timer event: ACK received, with ACK field value = y if (y > SendBase) {

Note:

• y > SendBase

d t

(y ) { SendBase = y if (there are currently not-yet-acknowledged segments) start timer; else stop timer

means new data ack’ed

Transport Layer (SSL) 3-59

p } } /* end of loop forever */

10/17/2017

60

TCP: retransmission scenario (1)

Host A Host B SendBase = 92 meout

X lost ACK scenario

= 92

loss

tim

X lost ACK scenario

restart timer for seq= 92 SendBase = 100 Stop timer

Transport Layer (SSL) 3-60

time

10/17/2017

61

TCP retransmission scenario (2) m ( )

Host A Host B SendBase meout

Cumulative ACK scenario

SendBase = 92

loss

Seq 92 tim

X Cumulative ACK scenario

SendBase = 120 Stop timer

time

Transport Layer (SSL) 3-61 10/17/2017

62

TCP: retransmission scenario (3)

Host A Host B

premature timeout scenario

SendBase= 92 92 timeout restart timer for Seq=9 Sendbase 100 seq= 92 restart timer for seq= 100 SendBase = 120 = 100 stop timer

time

SendBase = 120 timer What does Host A

Transport Layer (SSL) 3-62

time

10/17/2017

do here?

63

Fast Retransmit

 Time-out period often

relatively long:  If sender receives 3

duplicate ACKs for

relatively long

 long delay before

resending lost packet  Detect lost segments

duplicate ACKs for the same data, it supposes that

 Detect lost segments

via duplicate ACKs

 Sender often sends

supposes that segment after ACKed data was

many segments back-to- back

 If segment is lost,

h ll l k l

lost:

 fast retransmit:

resend se ment

there will likely be many duplicate ACKs.

resend segment before timer expires

Transport Layer (SSL) 3-63 10/17/2017

64

Host A Host B

X

ent

X

• r 2nd segm

timeout fo

time R di t ft t i l d li t ACK

Transport Layer (SSL) 3-64

Resending a segment after triple duplicate ACK without waiting for timeout

10/17/2017

65

Fast retransmit algorithm:

t ACK i d ith ACK fi ld l event: ACK received, with ACK field value = y if (y > SendBase) { SendBase = y if (there is a not yet acknowledged segment) if (there is a not-yet-acknowledged segment) start timer } else { else { increment count of dup ACKs received for y if (count of dup ACKs received for y = 3) { resend segment with sequence number y g q y reset timer for y

}

a duplicate ACK for already ACKed segment fast retransmit

Transport Layer (SSL) 3-65

already ACKed segment

10/17/2017

66

Chapter 3 outline Chapter 3 outl ne

 3.1 Transport-layer  3.5 Connection-oriented

p y services

 3.2 Multiplexing and

d lti l i transport: TCP

 segment structure  reliable data transfer

demultiplexing

 3.3 Connectionless

transport: UDP

 reliable data transfer  flow control  connection management

tran p rt D

 3.4 Principles of

reliable data transfer

 3.6 Principles of

congestion control

 3 7 TCP congestion  3.7 TCP congestion

control

Transport Layer (SSL) 3-66 10/17/2017

67

TCP Flow Control F

receiver: explicitly informs sender of (dynamically sender won’t overrun

flow control

y y changing) amount of free buffer space

 RcvWindow field in

receiver’s buffers by transmitting too much, too fast TCP segment header sender: keeps amount of sender keeps amount of transmitted, unACKed data less than most recently received y RcvWindow value

buffer at receive side of a TCP connection

Transport Layer (SSL) 3-67 10/17/2017

68

Chapter 3 outline Chapter 3 outl ne

 3.1 Transport-layer  3.5 Connection-oriented

p y services

 3.2 Multiplexing and

d lti l i transport: TCP

 segment structure  reliable data transfer

demultiplexing

 3.3 Connectionless

transport: UDP

 reliable data transfer  flow control  connection management

tran p rt D

 3.4 Principles of

reliable data transfer

 3.6 Principles of

congestion control

 3 7 TCP congestion  3.7 TCP congestion

control

Transport Layer (SSL) 3-68 10/17/2017

69

TCP Connection Management

Three way handshake

 initialize TCP variables

 seq. #s  buffers flow control

Step 1: client end system sends

TCP SYN control segment to server initial seq number

 buffers, flow control

info (e.g. RcvWindow) server - initial seq number chosen at random

Step 2: server end system

Active participant Passive participant Step

server end system receives SYN, replies with SYNACK control segment

 allocates buffers

p p (client) (server)

 specifies server-to-receiver

initial seq. # (chosen at random)

Step 3: client end system

replies with ack # (likely

piggybacked in segment with app

Transport Layer (SSL) 3-69

data)

10/17/2017

70

TCP Connection Management (cont ) TCP Connection Management (cont.)

Closing a connection:

client server

client closes socket

Step 1: client end system

d TCP FIN t l

client server

close sends TCP FIN control message to server

Step 2: server receives

close

Step 2: server receives

FIN, replies with ACK. Later no more data to wait

• send. It closes connection,

sends FIN. l s d timed w

Transport Layer (SSL) 3-70

closed

10/17/2017

71

TCP Connection Management (cont ) TCP Connection Management (cont.)

Step 3: client receives FIN,

replies with ACK and

client server

p enters “timed wait”

 will respond with ACK

to a retransmitted FIN

client server

close

(due to loss of previous ACK)

Step 4: server receives

ACK Its connection is close

• ACK. Its connection is

closed. Step 5: client closes connection at the end of wait closing connection at the end of timed wait

Note: protocol spec allows

i lt FIN l s d timed w

closed

Transport Layer (SSL) 3-71

simultaneous FINs

10/17/2017

closed

72

Chapter 3 outline Chapter 3 outl ne

 3.1 Transport-layer  3.5 Connection-oriented

p y services

 3.2 Multiplexing and

d lti l i transport: TCP

 segment structure  reliable data transfer

demultiplexing

 3.3 Connectionless

transport: UDP

 reliable data transfer  flow control  connection management

tran p rt D

 3.4 Principles of

reliable data transfer

 3.6 Principles of

congestion control

 3 7 TCP congestion  3.7 TCP congestion

control

Transport Layer (SSL) 3-72 10/17/2017

73

Principles of Congestion Control p f g

Congestion: Congestion:

 informally: “too many sources sending too much

data too fast for network to handle”

 different from flow control  manifestations:

l d l ( i i t b ff )

 long delays (queueing in router buffers)  lost packets (buffer overflow at routers)

 a top 10 problem!  a top-10 problem!

Transport Layer (SSL) 3-73 10/17/2017

74

Causes/costs of congestion: scenario

 four senders  multi-hop paths

λin

Q: what happens as and increase at every λ'in

 Timeout & retransmit

increase at every sender?

Host A λin : original data

positive feedback  instability

finite shared output li k b ff

in

g λ'in : original data plus retransmitted data

link buffers

Host B

λout

Transport Layer (SSL) 3-74 10/17/2017

75

Causes/costs of congestion: scenario

Host A

λout

Host B

Cost of congestion

 when a packet is dropped, any upstream transmission

capacity used for that packet was wasted capacity used for that packet was wasted

 behavior on right side of above graph called

congestion collapse

Transport Layer (SSL) 3-75

g p

10/17/2017

76

Approaches towards congestion control pp g

End-to-end congestion control: Network-assisted congestion control: control:

 no explicit feedback

from network

g

 routers provide feedback

to end systems

 congestion inferred

from end-system’s

• bserved loss (or delay)

 single bit indicating

congestion, e.g., SNA, DECbit, ATM

• bserved loss (or delay)

 approach taken by TCP

DECbit, ATM

 TCP/IP explicit

congestion notification (ECN) (ECN)

 explicit sending rate

for sender

Transport Layer (SSL) 3-76

for sender

10/17/2017

77

Chapter 3 outline Chapter 3 outl ne

 3.1 Transport-layer  3.5 Connection-oriented

p y services

 3.2 Multiplexing and

d lti l i transport: TCP

 segment structure  reliable data transfer

demultiplexing

 3.3 Connectionless

transport: UDP

 reliable data transfer  flow control  connection management

tran p rt D

 3.4 Principles of

reliable data transfer

 3.6 Principles of

congestion control

 3 7 TCP congestion  3.7 TCP congestion

control

Transport Layer (SSL) 3-77 10/17/2017

78

TCP Congestion Control

 end-to-end control (no network

assistance)

 sender limits transmission:

How does sender determine CongWin?

 loss event = timeout  sender limits transmission: LastByteSent-LastByteAcked ≤ CongWin  Roughly the send buffer’s  loss event timeout

• r 3 duplicate acks

 TCP sender reduces

CongWin after a loss

 Roughly, the send buffer s

CongWin after a loss event three mechanisms:

l

h h

CongWin /

where CongWin is in bytes

λ

 slow start  reduce to 1 segment

after timeout event AIMD ( dditi

i

throughput ≤ CongWin

RTT bytes/sec

and throughput is λ'in in slide 3-74

 AIMD (additive increase

multiplicative decrease) Note: For now consider RcvWindow to be very large such that the send window size is l t C Wi Th f d t d d d ti l i th t tb k

Transport Layer (SSL) 3-78

equal to CongWin. They are referred to as rwnd and cwnd, respectively, in the textbook.

10/17/2017

79

TCP Slow Start TCP Slow Start

 Probing for usable bandwidth  Probing for usable bandwidth  When connection begins CongWin = 1 MSS  When connection begins, CongWin = 1 MSS

 Example: MSS = 500 bytes & RTT = 200 msec  initial rate = 2500 bytes/sec = 20 kbps

y p  available bandwidth may be >> MSS/RTT

y

 desirable to quickly ramp up to a higher rate

Transport Layer (SSL) 3-79 10/17/2017

80

TCP Slow Start (more)

 When connection

begins, increase rate exponentially until

Host A Host B

exponentially until first loss event or “threshold”

d bl i

RTT

 double CongWin every

RTT

 done by incrementing

CongWin by 1 MSS for CongWin by 1 MSS for every ACK received  Summary: initial rate

is slow but ramps up is slow but ramps up exponentially fast

time

Transport Layer (SSL) 3-80 10/17/2017

81

Congestion avoidance state & responses to loss events responses to loss events

Q: If no loss, when should the exponential increase switch to linear?

12 14

size

TCP Reno

3 dup ACKs switch to linear? A: When CongWin gets to current value of threshold

6 8 10

n window s

egments)

Reno

Implementation:

 For initial slow start,

h h ld l

2 4

congestion

(se

threshold TCP Tahoe

threshold is set to a large value (e.g., 64 Kbytes)

 Subsequently, threshold is

bl

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

Transmission round

variable

 At a loss event, threshold is

set to 1/2 of CongWin just b f l

Tahoe Reno Notes: 1. For simplicity, CongWin is in number of

Transport Layer (SSL) 3-81

before loss event

segments in the above graph. 2. Reno’s window inflation and deflation steps (details) omitted

10/17/2017

82

Rationale for Reno’s Fast Recovery f F y

 After 3 dup ACKs:

 CongWin is cut in half

 3 dup ACKs indicate g f (multiplicative decrease)

 window then grows linearly

(additive increase)  3 dup ACKs indicate

network capable of delivering some segments

(add t ve ncrease)

 But after timeout event:

 CongWin is set to 1 MSS

instead;  timeout occurring

before 3 dup ACKs is

instead;

 window then grows

exponentially to a threshold, then grows linearly

before 3 dup ACKs is “more alarming”

then grows linearly Additive Increase Multiplicative Decrease (AIMD)

Transport Layer (SSL) 3-82 10/17/2017

83

TCP Reno (example scenario) ( mp )

CongWin Timeout 3 dupACKs

halved

th sh ld h d

Initial slow start

t

threshold reached during slow start

3 dupACKs during slow start before reaching initial threshold

3-84 Transport Layer (SSL)

f g

10/17/2017

84

Summary: TCP Congestion Control (Reno) Summary TCP Congestion Control (Reno)

 When CongWin is below Threshold, sender in

slow-start phase window grows exponentially (until slow-start phase, window grows exponentially (until

loss event or exceeding threshold).  When CongWin is above Threshold, sender is in  When CongWin is above Threshold, sender is in

congestion-avoidance phase, window grows linearly.

 When a triple duplicate ACK occurs Threshold  When a triple duplicate ACK occurs, Threshold

set to CongWin/2 and CongWin set to Threshold.

 When timeout occurs, Threshold set to

CongWin/2 and CongWin is set to 1 MSS.

Transport Layer (SSL) 3-84 10/17/2017

85

AIMD in steady state (when no timeout)

multiplicative decrease: cut CongWin in half after loss event (3 dup additive increase: increase CongWin by 1 MSS every RTT in after loss event (3 dup acks) 1 MSS every RTT in the absence of any loss event: probing

24 Kbytes congestion window

What limits the average window size (or throughput)?

16 Kbytes 8 Kbytes

Transport Layer (SSL) 3-85

time

Long-lived TCP connection

10/17/2017

86

TCP Throughput limited by loss rate

 TCP

th h t ( i t ) f

 TCP average throughput (approximate) of

send buffer under AIMD in terms of loss rate L rate, L 1.22 bytes/second MSS throughput RTT L × =

where MSS is number of bytes per segment  Example: 1500-byte segments, 100ms RTT,

p y g to get 10 Gbps throughput, loss rate needs to be very low L = 2·10-10

 New version of TCP needed for high-speed

l

Transport Layer (SSL) 3-86

applications

10/17/2017

87

Is TCP fair?

Two competing sessions: Two competing sessions:

 Additive increase gives slope of 1, as window size increases  multiplicative decrease reduces window size to half  multiplicative decrease reduces window size to half

(proportionally)

W

l i d i

W

equal window size

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

Transport Layer (SSL) 3-87

W

Connection 1 window size

10/17/2017

88

Is TCP fair?

Fairness goal: if K TCP sessions share same bottleneck link of bandwidth R, each should have t f R/K average rate of R/K

TCP connection 1 bottleneck bottleneck router capacity R TCP connection 2

AIMD only provides convergence to same window size, not necessarily same throughput rate

Transport Layer (SSL) 3-88 10/17/2017

89

No fairness in practice

UDP

 Some multimedia apps use

UDP instead of TCP. They

Parallel TCP connections

 nothing prevents an app

from opening parallel

UDP instead of TCP. They

 can tolerate packet

loss,

 do not want rate

from opening parallel connections between 2 hosts.

 Web browsers do this  do not want rate

throttled by congestion control – send at constant rate

 Web browsers do this

constant rate

Transport Layer (SSL) 3-89 10/17/2017

90

Chapter 3: Summary Chapter 3 Summary

 principles behind transport

layer services:

 instantiation and

implementation in the layer services:

 multiplexing,

demultiplexing implementation in the Internet

 UDP

p g

 reliable data transfer  connection management

Next:

 TCP  flow control  congestion control

 leaving the network

“edge” (application, transport layers) transport layers)

 into the network

“core”

Transport Layer (SSL) 3-90 10/17/2017