chapter 3 outline - ida

Transport Layer 3-1

Chapter 3 outline

3.1 Transport-layer services

3.2 Multiplexing and demultiplexing

3.3 Connectionless transport: UDP

3.4 Principles of reliable data transfer

3.5 Connection-oriented transport: TCP segment structure reliable data transfer flow control connection management

3.6 Principles of congestion control

3.7 TCP congestion control

Transport Layer 3-2

TCP: Overview

full duplex data: bi-directional data flow

in same connection connection-oriented:

handshaking (exchange of control msgs)

point-to-point: one sender, one receiver

reliable: all packets delivered

pipelined: W packets are sent and

ACKed

RFCs: 793, 1122, 1323, 2018, 2581 …

Transport Layer 3-3

TCP segment structure

source port # dest port #

32 bits

application data

(variable length)

sequence number acknowledgement number

Receive window

Urg data pnter checksum F S R P A U head

len not

used

Options (variable length)

URG: urgent data (generally not used)

ACK: ACK # valid

PSH: push data now (generally not used)

RST, SYN, FIN: connection estab (setup, teardown

commands)

# bytes rcvr willing to accept

counting by bytes of data (not segments!)

Internet checksum

(as in UDP)

Transport Layer 3-4

Chapter 3 outline








Transport Layer 3-5

TCP reliable data transfer

TCP creates rdt service on top of IP’s unreliable service seq # and acks cumulative acks duplicate acks timers retransmissions pipelined segments sliding window

-> retransmissions are triggered by:

timeout events duplicate acks

Transport Layer 3-6

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

byte stream “number” of first byte in segment’s data

ACKs: seq # of next byte

expected from other side

cumulative ACK

Host A Host B

Transport Layer 3-7

TCP: retransmission scenarios Host A

premature timeout

Host B

Seq=

92 t

imeo

ut

Host A

loss

tim

eout

lost ACK scenario

Host B

X

Seq=

92 t

imeo

ut

Transport Layer 3-8

TCP retransmission scenarios (more) Host A

loss

tim

eout

Cumulative ACK scenario

Host B

X

Transport Layer 3-9

TCP Round Trip Time and Timeout

Q: 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

Q: how to estimate RTT?

SampleRTT: measured time from segment transmission until ACK receipt

SampleRTT will vary, want estimated RTT “smoother” average several recent

measurements, not just current SampleRTT

Transport Layer 3-10

Example RTT estimation: 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 (seconnds)

RTT

(mill

iseco

nds)

SampleRTT Estimated RTT



EstimatedRTT = (1- α)*EstimatedRTT + α*SampleRTT

Exponential weighted moving average influence of past sample decreases exponentially fast typical value: α = 0.125 (RFC6298)



Deviation of SampleRTT :

TimeoutInterval = EstimatedRTT + 4*DevRTT

DevRTT = (1-β)*DevRTT + β*|SampleRTT-EstimatedRTT| typically, β = 0.25 (RFC6298)

Then set timeout interval:

Example RTT estimation: cont.



Chapter 3 outline









TCP Flow Control

receive side of TCP connection has a receive buffer:

speed-matching service: matching the send rate to the receiving app’s drain rate

app process may be slow at reading from buffer

sender won’t overflow receiver’s buffer by

transmitting too much, too fast

flow control


TCP Flow control: how it works

RcvWindow - spare room

in recv buffer

rcvr advertises spare room by including value of RcvWindow in segments

sender limits unACKed data to RcvWindow guarantees receive

buffer doesn’t overflow


Chapter 3 outline









TCP Connection Management Recall: TCP sender, receiver establish

“connection” before exchanging data segments

initialize TCP variables: seq. #s buffers, flow control info (e.g. RcvWindow)

client: connection initiator

server: contacted by client


TCP Connection establishment

Step 1: client host sends TCP SYN segment to server specifies initial seq # no data

Step 2: server host receives SYN, replies with SYNACK segment server allocates buffers specifies server initial

seq. # Step 3: client receives SYNACK,

replies with ACK segment, which may contain data


TCP Connection termination Step 1: client end system sends

TCP FIN control segment to server

Step 2: server receives FIN, replies with ACK. Closes connection, sends FIN.

Step 3: client receives FIN, replies with ACK.

Enters “timed wait” - will respond with ACK to received FINs

Step 4: server, receives ACK. Connection closed.

client server

close

close

closed

tim

ed w

ait


Chapter 3 outline









Principles of Congestion Control Congestion: informally: “too many sources sending too much data

too fast for network to handle” different from flow control! manifestations: lost packets (buffer overflow at routers) long delays (queueing in router buffers)

Results in unfairness and poor utilization of network resources:

Resources utilized by dropped packets Retransmissions


Causes/costs of congestion: scenario 1 two senders, two

receivers one router,

infinite buffers no retransmission

large delays when congested

maximum achievable throughput

unlimited shared output link buffers

Host A λin : original data

Host B

λout


Causes/costs of congestion: scenario 2 one router, finite buffers sender retransmission of timed-out packet

application-layer input = application-layer output: λin = λout

transport-layer input includes retransmissions : λin λin

finite shared output link buffers

Host A

λin : original data

Host B

λout λ'in: original data, plus retransmitted data

‘


packets may get dropped at router due to full buffers

sender times out prematurely, sending two copies, both of which are delivered

Congestion scenario 2: duplicates R/2

λ out

when sending at R/2, some packets are retransmissions including duplicated that are delivered!

“costs” of congestion: more work (retrans) for given “goodput” unneeded retransmissions: link carries multiple copies of pkt

decreasing goodput

R/2 λin


Approaches towards congestion control

end-end congestion control:

no explicit feedback from network

congestion inferred from end-system observed loss, delay

approach taken by TCP

network-assisted congestion control:

routers provide feedback to end systems single bit indicating

congestion (SNA, DECbit, TCP/IP ECN, ATM)

explicit rate sender should send at

Two broad approaches towards congestion control:


Chapter 3 outline









TCP Congestion Control: Overview end-end control (no network assistance) Limit the number of packets in the network to window W Roughly,

rate =

W RTT

Bytes/sec

W is dynamic, function of perceived network congestion ACK-clocking mechanism

27


TCP Congestion Control: details

How does sender perceive congestion? loss event = timeout or 3 duplicate acks TCP sender reduces rate (cwnd) after loss event

mechanisms: (RFC5681)

AIMD slow start congestion avoidance fast retransmit


TCP AIMD: additive increase, multiplicative decrease

8 Kbytes

16 Kbytes

24 Kbytes

time

congestionwindow

approach: increase transmission rate (window size), probing for usable bandwidth, until loss occurs additive increase: increase window by 1 every

RTT until loss detected multiplicative decrease: cut window in half after

loss

time

cwnd

: con

gest

ion

win

dow

siz

e

saw tooth behavior: probing

for bandwidth

Slow Start “Slow Start” is used to

reach the equilibrium state Initially: W = 1 (slow start) On each successful ACK: W = W + 1

Exponential growth of W each RTT: W = 2 x W Enter CA when W >= ssthresh

sender cwnd

1 data segment

ACK 2

3 4

5 6 7 8

receiver

30

Congestion avoidance


Starts when W = ssthresh On each successful ACK W = W+ 1/W

Linear growth of W each RTT W = W + 1 (additive increase)

31

TCP (initial version without loss) Window

ssthresh

Reached initial ssthresh value;

Time switch to CA mode

Slow Start

32

Detecting Packet Loss Assumption: loss indicates congestion Option 1: time-out Waiting for a time-out can

be long!

Option 2: duplicate ACKs How many? At least 3.

11 12

12

12 12

Sender

10 11 12 X

13

14 15 16 17

Receiver

35


Fast Retransmit

time-out period often relatively long: long delay before

resending lost packet detect lost segments

via duplicate ACKs. sender often sends

many segments back-to-back

if segment is lost, there will likely be many duplicate ACKs.

if sender receives 3 ACKs for the same data, it supposes that segment after ACKed data was lost: fast retransmit: resend

segment before timer expires


Host A

tim

eout

Host B

X

Figure 3.37 Resending a segment after triple duplicate ACK

Fast Retransmit Immediately retransmits after 3 dupACKs without waiting for timeout Adjusts ssthresh ssthresh = W/2 Enter Slow Start (Tahoe) W = 1

36

TCP Congestion Controls Tahoe (Jacobson 1988) Slow Start

Congestion Avoidance Fast Retransmit Reno (Jacobson 1990)

Fast Recovery SACK

Vegas (Brakmo & Peterson 1994) Delay and loss as indicators of congestion

29


Refinement variable ssthresh on loss event,

ssthresh is set to 1/2 of W just before loss event

TCP Reno: Fast Recovery Objective: prevent `pipe’ from emptying after fast retransmit each dup ACK represents a packet having left the pipe (successfully received)

46

On 3 duplicate ACKs Fast retransmit and fast recovery On timeout Fast retransmit and slow start

Done with TCP congestion control mechanisms

What type of pipelining is implemented in TCP?


Recall: Pipelined Protocols

Go-back-N: N unacked packets in

pipeline – Window cumulative acks

doesn’t ack packet if there’s a gap

sender has timer for oldest unacked packet if timer expires,

retransmit all unack’ed packets

Selective Repeat: sender can have up to

N unack’ed packets in pipeline

rcvr sends individual ack for each packet

sender maintains timer for each unacked packet when timer expires,

retransmit only unack’ed packet


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

TCP connection 1

bottleneck router

capacity R

TCP connection 2

TCP Fairness


Why is TCP fair? AIMD game for 2 competing sessions: additive increase gives slope of 1, as throughout increases multiplicative decrease decreases throughput proportionally

R

R

equal bandwidth share

Connection 1 throughput

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

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


Fairness (more) Fairness and UDP multimedia apps often

do not use TCP do not want rate

throttled by congestion control

instead use UDP: pump audio/video at

constant rate, tolerate packet loss

Fairness and parallel TCP connections

nothing prevents app from opening parallel connections between 2 hosts.

web browsers do this example: link of rate R

supporting 9 connections; new app asks for 1 TCP, gets

rate R/10 new app asks for 11 TCPs,

gets R/2 !


Chapter 3: Summary principles behind transport

layer services: multiplexing,

demultiplexing reliable data transfer flow control congestion control

instantiation and implementation in the Internet UDP TCP

Next: leaving the network

“edge” (application, transport layers)

into the network “core”

TCP: seq # plot There is a beautiful way to plot and visualize the dynamics of TCP behaviour Called a “TCP Sequence Number Plot” Plot packet events (data and acks) as points in 2-D space, with time on the

horizontal axis, and sequence number on the vertical axis Example: Consider a 14-packet transfer

63

Key: X Data Packet + Ack Packet

X X X X +

X X

X X

X X X

+ + + +

+ +

+ +

+ + +

X X X +

+

Time

64

TCP: seq n plot What can it tell you?

Everything!!!

65


X X X X +

X X

X X

X X X

+ + + +

+ +

+ +

+ + +

X X X +

+

RTT

Time

66

TCP


X X X X +

X X

X X

X X X

+ + + +

+ +

+ +

+ + +

Seg. Size X

X +

X +

Time

67


X X X X +

X X

X X

X X X

+ + + +

+ +

+ +

+ + +

X X X +

+

Time TCP Connection Duration

68

Key: X Data Packet

X

+ + Ack Packet

Num Bytes

Sent

+

X X X X

X X X

X X X

+ + + +

+ + +

+ + +

X X X +

+

Time

69


X X X X +

X X

X X

X X X

+ + + +

+ +

+ +

+ + + Bytes

X X X +

+

Sec

Time

70


Access Network

Bandwidth (Bytes/Sec)

+

X X X X

X X

X X

X X X

+ + + +

+ +

+ +

+ + +

X X X +

+

Time

71


X X X X +

X X

X X

X X X

+ + + +

+ +

+ +

+ + +

Sender’s Flow Control

Window Size X

X X +

+

Time

72


TCP Slow Start

+

X X X X

X X

X X

X X X

+ + + +

+ +

+ +

+ + +

X X X +

+

Time

73


X X X X +

X X

X X

X X X

+ +

+ +

+

+

Delayed ACK

X X X

+

Time

74


Packet Loss

X X X X +

X

X + + X +

X + X +

+ + Duplicate + ACK +

X X X +

+

Time

75

Cumulative ACK


X X X X +

X

X + X +

X + X +

+ + + +

+

X +

Retransmit

X X X +

+

Time

76


X X X X +

X

X + X +

X + X +

+ + + +

+

X +

X X X +

+

Time

RTO

77

TCP: seq # plot What happens when a packet loss occurs?

Consider a 14-packet Web document For simplicity, consider only a single packet loss

78


X X X X +

X X

X X

X X X

+ + + +

+ +

+ +

+ + +

X X X +

+

Time

79


X X X X +

? X X X

X X X

+ + + +

+ + +

+ + +

X X X +

+

Time

80


X X X X +

X X X

X X X

+ + + +

X + + + +

+ + +

X X X +

+

Time

81


X X X X +

X X

X X

X X X

+ + + +

+ +

+ +

+ + +

X X X +

+

Time

82


X X X X +

X ? X X

X X X

+ + + +

+ +

+ + +

X X X +

+

Time

83


X X X X +

X

X X

X X X

+ + + +

+ X

+ + + +

+ +

X X X +

+

Time

84


X X X X +

X X

X X

X X X

+ + + +

+ +

+ +

+ + +

X X X +

+

Time

85


X X X X +

X X

X ? X +

X + X +

+ + + +

X X X +

+

Time

86


X X X X +

X + X

X X

X ++++ X + X +

+ + + +

X X X +

+

Time

87


X X X X +

X X

X X

X X X

+ + + +

+ +

+ +

+ + +

X X X +

+

Time

88


? X X +

+

Time

89


X X +

X X

+ + +

X + X +

X +

X + X + +

X

Time

90

TCP: seq # plot Main observation: “Not all packet losses are created equal”

Losses early in the transfer have a huge adverse impact on the transfer latency Losses near the end of the transfer always cost at least a retransmit timeout Losses in the middle may or may not hurt, depending on congestion window size at the time of the loss

91

chapter 3 outline - ida

Documents