Transport Layer3-1 Chapter 3 outline r 3.1 Transport-layer services r 3.2 Multiplexing and...

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

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)

a top-10 problem!

Transport Layer 3-3

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 Ain : original data

Host B

out

Transport Layer 3-4


one router, finite buffers sender retransmission of lost packet

finite shared output link buffers

Host A in : original data

Host B

out

'in : original data, plus retransmitted data

Transport Layer 3-5

Causes/costs of congestion: scenario 2 Ideal case:

only send a packet if buffer available:

More reasonable case: retransmit only packets that where dropped:

Realistic case: retransmit packets that where either dropped or delayed:

unnecessary retransmissions! Even larger offered load

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

pkt

'in

out

=in

=

'in

in

<

'in

in

<

Transport Layer 3-6

Causes/costs of congestion: scenario 3 four senders multihop paths timeout/retransmit

in

Q: what happens as and increase ?

in

finite shared output link buffers

Host Ain : original data

Host B

out

'in : original data, plus retransmitted data

Transport Layer 3-7


Another “cost” of congestion: when packet dropped, any “upstream” transmission capacity

used for that packet was wasted!

Host A

Host B

o

u

t

Transport Layer 3-8

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:

Transport Layer 3-9

Case study: ATM ABR congestion control

ABR: available bit rate:

“elastic service” if sender’s path

“underloaded”: sender should use

available bandwidth if sender’s path

congested: sender throttled to

minimum guaranteed rate

RM (resource management) cells:

sent by sender, interspersed with data cells

bits in RM cell set by switches (“network-assisted”) NI bit: no increase in rate

(mild congestion) CI bit: congestion

indication RM cells returned to sender

by receiver, with bits intact

Transport Layer 3-10

Case study: ATM ABR congestion control

two-byte ER (explicit rate) field in RM cell congested switch may lower ER value in cell sender’ send rate thus minimum supportable rate on

path

EFCI bit in data cells: set to 1 in congested switch if data cell preceding RM cell has EFCI set, sender sets CI

bit in returned RM cell


TCP Congestion Control end-end control (no network assistance) sender limits transmission:

congwin is dynamic, function of perceived network congestion

w segments, each with MSS bytes sent in one RTT:

throughput = w * MSS

RTT Bytes/sec

congwin


TCP congestion control:

two “phases” slow start congestion avoidance

important variables: Congwin threshold: defines

threshold between two slow start phase, congestion control phase

“probing” for usable bandwidth: ideally: transmit as fast as

possible (Congwin as large as possible) without loss

increase Congwin until loss event (congestion)

loss event: decrease Congwin, then begin probing (increasing) again

How does sender perceive congestion? Timeout 3 duplicate acks


TCP Slowstart

Double congestion window every RTT (exponential increase)

loss event: timeout (Tahoe TCP) and/or or three duplicate ACKs (Reno TCP)

initialize: Congwin = 1for (each segment ACKed) Congwin++until (loss event OR CongWin > threshold)

Slowstart algorithmHost A

one segment

RTT

Host B

time

two segments

four segments


TCP Congestion Avoidance: Tahoe

/* slowstart is over */ /* Congwin > threshold */Until (loss event) { every w segments ACKed: Congwin++}threshold = Congwin/2Congwin = 1perform slowstart

TCP Tahoe Congestion avoidance


TCP Congestion Avoidance: Reno

/* slowstart is over */ /* Congwin > threshold */Until (loss event) { every w segments ACKed: Congwin++ }threshold = Congwin/2If (loss detected by timeout) { Congwin = 1 perform slowstart }If (loss detected by triple

duplicate ACK) Congwin = Congwin/2

TCP Reno Congestion avoidance

three duplicate ACKs (Reno TCP): some segments are getting

through correctly! don’t “overreact” by decreasing

window to 1 as in Tahoe decrease window size by half


TCP Reno versus TCP Tahoe:

0

2

4

6

8

10

12

14

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

Transmission round

co

ng

est

ion

win

do

w s

ize

(s

eg

me

nts

)

Series1 Series2

threshold

TCP Tahoe

TCP Reno

Figure 3.49 (revised): Evolution of TCP’s Congestion window (Tahoe and Reno)


TCP AIMD

8 Kbytes

16 Kbytes

24 Kbytes

time

congestionwindow

multiplicative decrease: cut CongWin in half on loss event

additive increase: increase CongWin by 1 MSS every RTT in the absence of loss events: probing

Long-lived TCP connection


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

TCP connection 1

bottleneckrouter

capacity R

TCP connection 2

TCP Fairness


Why is TCP fair?

Two competing sessions: Additive increase gives slope of 1, as throughout increases multiplicative decrease decreases throughput proportionally

R

R

equal bandwidth share

Connection 1 throughputConnect

ion 2

th

roughput

congestion avoidance: additive increaseloss: decrease window by factor of 2

congestion avoidance: additive increaseloss: 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

Research area: TCP friendly

Fairness and parallel TCP connections

nothing prevents app from opening parallel cnctions between 2 hosts.

Web browsers do this Example: link of rate R

supporting 9 cnctions; new app asks for 1 TCP,

gets rate R/10 new app asks for 11 TCPs,

gets R/2 !


TCP Throughput (macroscopic view) Transfer of a very large file

long-lived TCP connection

Network is not too congested AIMD in steady state

W/2 bytes

W bytes

time

congestionwindow

Throughput = 0.75 W RTT

Each transmission period send w bytes


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”

Transport Layer3-1 Chapter 3 outline r 3.1 Transport-layer services r 3.2 Multiplexing and...

Documents

Transcript of Transport Layer3-1 Chapter 3 outline r 3.1 Transport-layer services r 3.2 Multiplexing and...