CMPT771 Transport Layer 1 Transport Layer Issues Spring 2015 CMPT 771 InternetArchitecture and Protocols

CMPT771 Transport Layer 1

Transport Layer Issues

Spring 2015

CMPT 771 InternetArchitecture and

Protocols


Transport Layer Issues

Contents: overview principles

behind transport layer services: multiplexing/

demultiplexing reliable data

transfer flow control congestion control

TCP Performance analysis

Transport protocols for media applications


But first, a general overview of networks (and the Internet)

Telecommunicationnetworks

Circuit-switchednetworks

FDM TDM

Packet-switchednetworks

Networkswith VCs

DatagramNetworks


What Is the Internet? A network of networks, joining many government,

university and private computers together and providing an infrastructure for the use of E-mail, bulletin boards, file archives, hypertext documents, databases and other computational resources

The vast collection of computer networks which form and act as a single huge network for transport of data and messages across distances which can be anywhere from the same office to anywhere in the world.

Written by William F. Slater, III1996President of the Chicago Chapter of the Internet Society

Copyright 2002, William F. Slater, III, Chicago, IL, USA


What is the Internet?

The largest network of networks in the world. Uses TCP/IP protocols and packet switching . Runs on any communications substrate.

From Dr. Vinton Cerf, Co-Creator of TCP/IP


Brief History of the Internet

1968 - DARPA (Defense Advanced Research Projects Agency)

contracts with BBN (Bolt, Beranek & Newman) to create ARPAnet

1970 - First five nodes: UCLA Stanford UC Santa Barbara U of Utah, and BBN

1974 - TCP specification by Vint Cerf 1984 – On January 1, the Internet with its 1000 hosts

converts en masse to using TCP/IP for its messaging


Internet Evolution/Organization


ISO 7-layer reference model

application

presentation

session

application

transport

network

link

physical


Internet protocol stack

application: supporting network applications FTP, SMTP, STTP

transport: host-host data transfer TCP, UDP

network: routing of datagrams from source to destination IP, routing protocols

link: data transfer between neighboring network elements PPP, Ethernet

physical: bits “on the wire”

application

transport

network

link

physical


Internet Standardization Process

All standards of the Internet are published as RFC (Request for Comments) but not all RFCs are Internet Standards ! available: http://www.ietf.org Till now: RFC7026 (3635 Sept 2003/7439 Jan 2015)

A typical (but not the only) way of standardization: Internet draft RFC Proposed standard Draft standard (requires 2 working implementations) Internet standard (declared by Internet Architecture

Board)


Why the Internet ?

Why not other networks ? - Telephone - Wireless networks - Optical networks …

I have two reasons …


Outline

1. Transport-layer services

2. Multiplexing and demultiplexing

3. Connectionless transport: UDP

4. Principles of reliable data transfer

5. Connection-oriented transport: TCP

6. TCP congestion control

7. TCP fairness and delay performance

8. TCP friendly control 9. RTP/RTCP


Transport layer – the other side of the door

process

TCP withbuffers,variables

socket

host orserver

process

TCP withbuffers,variables

socket

host orserver

Internet

controlledby OS

controlled byapp developer

API: (1) choose transport protocol; (2) set parameters


Transport services and protocols provide logical

communication between app processes running on different hosts

transport protocols run in end systems send side: breaks

app messages into segments, passes to network layer

rcv side: reassembles segments into messages, passes to app layer

application

transportnetworkdata linkphysical

application

transportnetworkdata linkphysical

networkdata linkphysical



networkdata linkphysicalnetwork

data linkphysical

logical end-end transport


Transport vs. network layer

network layer: logical communication between devices Point-to-point

transport layer: logical communication between processes/end-hosts relies on and enhances, network layer services also called “End-to-End”

J. Saltzer, D. Reed, and D. Clark. End-to-end arguments in system design. ACM Transactions on Computer Systems, 2(4):277--288, 1984.


Outline








8. TCP friendly control 9. RTSP/RTP/RTCP


How demultiplexing works host receives IP datagrams

each datagram has source IP address, destination IP address

each datagram carries 1 transport-layer segment

each segment has source, destination port number (recall: well-known port numbers for specific applications)

host uses IP addresses & port numbers to direct segment to appropriate socket

source port # dest port #

32 bits

applicationdata

(message)

other header fields

TCP/UDP segment format


Connection-oriented demux

TCP socket identified by 4-tuple: source IP address source port number dest IP address dest port number

recv host uses all four values to direct segment to appropriate socket



ClientIP:B

P2

client IP: A

P1P1P3

serverIP: C

SP: 80

DP: 9157

SP: 9157

DP: 80

SP: 80

DP: 5775

SP: 5775

DP: 80

P4





Q: Why use 4-tuple?





Examples: Server host may

support many simultaneous TCP sockets: each socket identified

by its own 4-tuple

Web servers have different sockets for each connecting client non-persistent HTTP will

have different socket for each request


UDP: User Datagram Protocol [RFC 768]

“ no frills,” “bare bones” Internet transport protocol

“best effort” service, UDP segments may be: lost delivered out of order

to app connectionless:

no handshaking between UDP sender, receiver

each UDP segment handled independently of others

Why is there a UDP? no connection

establishment (which can add delay)

simple: no connection state at sender, receiver

small segment header no congestion control:

UDP can blast away as fast as desired


UDP: more

often used for streaming multimedia apps loss tolerant rate sensitive

other UDP uses DNS – why ?

reliable transfer over UDP: add reliability at application layer application-specific

error recovery!


32 bits

Applicationdata

(message)

UDP segment format

length checksumLength, in

bytes of UDPsegment,including

header


Demux: Connection vs Connection-less

Multi-party video conference


Outline










Principles of Reliable data transfer

important in app., transport, link layers top-10 list of important networking topics!

characteristics of unreliable channel will determine complexity of reliable data transfer protocol (rdt)


Reliable data transfer: getting started

sendside

receiveside

rdt_send(): called from above, (e.g., by app.). Passed data to deliver to receiver upper layer

udt_send(): called by rdt,to transfer packet over unreliable channel to

receiver

rdt_rcv(): called when packet arrives on rcv-side of channel

deliver_data(): called by rdt to deliver data to

upper


Reliable data transfer: getting started

We’ll: incrementally develop sender, receiver

sides of reliable data transfer protocol (rdt) What result in unreliability ?

Bit error Packet loss – congestion Delay – too long


rdt2.0: channel with bit errors

Wait for call from above

snkpkt = make_pkt(data, checksum)udt_send(sndpkt)

extract(rcvpkt,data)deliver_data(data)udt_send(ACK)

rdt_rcv(rcvpkt) && notcorrupt(rcvpkt)

rdt_rcv(rcvpkt) && isACK(rcvpkt)

udt_send(sndpkt)

rdt_rcv(rcvpkt) && isNAK(rcvpkt)

udt_send(NAK)

rdt_rcv(rcvpkt) && corrupt(rcvpkt)

Wait for ACK or NAK

Wait for call from below

sender

receiverrdt_send(data)


rdt2.0 has a fatal flaw!

What happens if ACK/NAK corrupted?

sender doesn’t know what happened at receiver!

What to do? sender NAKs receiver’s

ACK/NAK? What if sender NAK corrupted?

retransmit, assuming it is NAK …

but this might cause retransmission of correctly received pkt!

- packet duplications !

Handling duplicates: sender adds sequence

number to each pkt sender retransmits current

pkt if ACK/NAK garbled receiver discards (doesn’t

deliver up) duplicate pkt


rdt2.1: sender, handles garbled ACK/NAKs

Wait for call 0 from above

sndpkt = make_pkt(0, data, checksum)udt_send(sndpkt)

rdt_send(data)

Wait for ACK or NAK

0 udt_send(sndpkt)

rdt_rcv(rcvpkt) && ( corrupt(rcvpkt) ||isNAK(rcvpkt) )


rdt_send(data)

rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && isACK(rcvpkt)

udt_send(sndpkt)

rdt_rcv(rcvpkt) && ( corrupt(rcvpkt) ||isNAK(rcvpkt) )

rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && isACK(rcvpkt)

Wait for call 1 from

above

Wait for ACK or NAK 1


rdt2.1: receiver, handles garbled ACK/NAKs

Wait for 0 from below

sndpkt = make_pkt(NAK, chksum)udt_send(sndpkt)

rdt_rcv(rcvpkt) && not corrupt(rcvpkt) && has_seq0(rcvpkt)

rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && has_seq1(rcvpkt)

extract(rcvpkt,data)deliver_data(data)sndpkt = make_pkt(ACK, chksum)udt_send(sndpkt)


rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && has_seq0(rcvpkt)

extract(rcvpkt,data)deliver_data(data)sndpkt = make_pkt(ACK, chksum)udt_send(sndpkt)

rdt_rcv(rcvpkt) && (corrupt(rcvpkt)

sndpkt = make_pkt(ACK, chksum)udt_send(sndpkt)

rdt_rcv(rcvpkt) && not corrupt(rcvpkt) && has_seq1(rcvpkt)

rdt_rcv(rcvpkt) && (corrupt(rcvpkt)

sndpkt = make_pkt(ACK, chksum)udt_send(sndpkt)

sndpkt = make_pkt(NAK, chksum)udt_send(sndpkt)


rdt 2.1 in action

send pkt0rcv pkt0send ACK0

rcv ACK0send pkt1

rcv pkt1send ACK1

rcv ACK1send pkt0

rcv pkt0send ACK0

pkt

ACK

pkt

ACK

pkt

ACK

a) operation with no corruption

sender receiver


rcv ACK0send pkt1

send NAK1

rcv NAK1resend pkt1

rcv pkt1send ACK1

pkt

ACK

pkt

NAK

pkt

ACK

X (corrupted)

b) packet corrupted

rcv pkt1

sender receiver


rdt 2.1 in action (cont)


resend pkt0rcv pkt0send ACK0

rcv ACK0send pkt1

rcv pkt1send ACK1

pkt

ACK

pkt

ACK

pkt

ACK

(corrupted) X

c) ACK corrupted

rcv ACK0

sender receiver


rdt2.2: a NAK-free protocol

Wait for call 0 from above


rdt_send(data)

udt_send(sndpkt)

rdt_rcv(rcvpkt) && ( corrupt(rcvpkt) || isACK(rcvpkt,1) )

rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && isACK(rcvpkt,0)

Wait for ACK0

sender FSMfragment


rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && has_seq1(rcvpkt) extract(rcvpkt,data)deliver_data(data)sndpkt = make_pkt(ACK1, chksum)udt_send(sndpkt)

rdt_rcv(rcvpkt) && (corrupt(rcvpkt) || has_seq1(rcvpkt))

udt_send(sndpkt)

receiver FSMfragment


rdt 2.2 in action


rcv ACK0send pkt1

rcv pkt1send ACK1

rcv ACK1send pkt0

rcv pkt0send ACK0

pkt0

ACK0

pkt1

ACK1

pkt0

ACK0

a) operation with no corruption

sender receiver


rcv ACK0send pkt1

send ACK0

rcv ACK0resend pkt1

rcv pkt1send ACK1

pkt0

ACK0

pkt1

ACK0

pkt1

ACK1

b) packet corrupted

X (corrupted)rcv pkt1

sender receiver


rdt 2.2 in action (cont)


resend pkt0rcv pkt0send ACK0

rcv ACK0send pkt1

rcv pkt1send ACK1

pkt0

ACK0

pkt0

ACK0

pkt1

ACK1

c) ACK corrupted

(corrupted) Xrcv ACK0

sender receiver


rdt3.0 channels with errors and loss

sndpkt = make_pkt(0, data, checksum)udt_send(sndpkt)start_timer

rdt_send(data)

Wait for ACK0

rdt_rcv(rcvpkt) && ( corrupt(rcvpkt) ||isACK(rcvpkt,1) )

Wait for call 1 from

above

sndpkt = make_pkt(1, data, checksum)udt_send(sndpkt)start_timer

rdt_send(data)


rdt_rcv(rcvpkt) && ( corrupt(rcvpkt) ||isACK(rcvpkt,0) )


stop_timer

stop_timer

udt_send(sndpkt)start_timer

timeout

udt_send(sndpkt)start_timer

timeout

rdt_rcv(rcvpkt)

Wait for call 0from

above

Wait for ACK1

rdt_rcv(rcvpkt)

Sender


rdt3.0: Poor performance

first packet bit transmitted, t = 0

sender receiver

RTT

last packet bit transmitted, t = L / R

first packet bit arriveslast packet bit arrives, send ACK

ACK arrives, send next packet, t = RTT + L / R

U sender

= L / R

RTT + L / R

Stop-and-Wait

Sender sends one packet, then waits for receiver response

stop and wait


Performance of rdt3.0

example: 1 Gbps link, 15 ms e-e prop. delay, 1KB packet:

Ttransmit

= 8kb/pkt109 b/sec

= 8 microsec

U sender: utilization – fraction of time sender busy sending 1KB pkt every 30 msec -> 33kB/sec thruput over 1 Gbps link network protocol limits use of physical resources! microsec = 10-6sec millisec=ms=10-3s Gb, Mb, Kb

U sender

= .008

30.008 = 0.00027

microseconds

L / R

RTT + L / R =

L (packet length in bits)R (transmission rate, bps)

=


Pipelined protocols

Pipelining: sender allows multiple, “in-flight”, yet-to-be-acknowledged pkts range of sequence numbers must be increased buffering at sender and/or receiver


Pipelining: increased utilizationfirst packet bit transmitted, t = 0

sender receiver

RTT

last bit transmitted, t = L / R

first packet bit arriveslast packet bit arrives, send ACK

ACK arrives, send next packet, t = RTT + L / R

last bit of 2nd packet arrives, send ACKlast bit of 3rd packet arrives, send ACK

U sender

= .024

30.008 = 0.0008

microseconds

3 * L / R

RTT + L / R =

Increase utilizationby a factor of 3

Two generic forms of pipelined protocols: go-Back-N, selective repeat


Go-Back-NSender: k-bit seq # in pkt header “window” of up to N, consecutive unack’ed pkts allowed –

sliding window

ACK(n): ACKs all pkts up to, including seq # n - “cumulative ACK” may deceive duplicate ACKs (see receiver)

timer for the packet of send_base timeout(n): retransmit pkt n and all higher seq # pkts in window


GBN: sender extended FSM

Waitstart_timerudt_send(sndpkt[base])udt_send(sndpkt[base+1])…udt_send(sndpkt[nextseqnum-1])

timeout

rdt_send(data)

if (nextseqnum < base+N) { sndpkt[nextseqnum] = make_pkt(nextseqnum,data,chksum) udt_send(sndpkt[nextseqnum]) if (base == nextseqnum) start_timer nextseqnum++ }else refuse_data(data)

base = getacknum(rcvpkt)+1If (base == nextseqnum) stop_timer else start_timer


base=1nextseqnum=1



GBN: receiver extended FSM

ACK-only: always send ACK for correctly-received pkt with highest in-order seq # may generate duplicate ACKs need only remember expectedseqnum

out-of-order pkt: discard (don’t buffer) -> no receiver buffering! Re-ACK pkt with highest in-order seq #

Wait

udt_send(sndpkt)

default

rdt_rcv(rcvpkt) && notcurrupt(rcvpkt) && hasseqnum(rcvpkt,expectedseqnum)

extract(rcvpkt,data)deliver_data(data)sndpkt = make_pkt(expectedseqnum,ACK,chksum)udt_send(sndpkt)expectedseqnum++

expectedseqnum=1sndpkt = make_pkt( 0, ACK, chksum )


GBN inaction


GBN: sender extended FSM

Waitstart_timerudt_send(sndpkt[base])udt_send(sndpkt[base+1])…udt_send(sndpkt[nextseqnum-1])

timeout

rdt_send(data)

if (nextseqnum < base+N) { sndpkt[nextseqnum] = make_pkt(nextseqnum,data,chksum) udt_send(sndpkt[nextseqnum]) if (base == nextseqnum) start_timer nextseqnum++ }else refuse_data(data)

base = getacknum(rcvpkt)+1If (base == nextseqnum) stop_timer else start_timer


base=1nextseqnum=1



GBN inaction

Cumulative ACK


rcv ACK0


rcv ACK1

Sender Receiver

send pkt2

send pkt3

rcv pkt3send ACK3

send pkt4

send pkt5

send pkt6

send pkt7

send pkt8

send pkt9

rcv pkt2send ACK2

rcv pkt4send ACK4

send ACK5rcv pkt5

rcv ACK5

(l oss)X

( l oss)X

( l oss)X


GBN inaction

Cumulative ACK


rcv ACK0


rcv ACK1

Sender Receiver

send pkt2

send pkt3

rcv pkt3send ACK3

send pkt4

send pkt5

send pkt6

send pkt7

send pkt8

send pkt9

rcv pkt2send ACK2

rcv pkt4send ACK4

send ACK5rcv pkt5

rcv ACK5

(l oss)X

( l oss)X

( l oss)X


GBN inaction

Premature timeout


rcv ACK0


rcv ACK1

Sender Receiver

send pkt2

send pkt3

rcv pkt3,discardsend ACK1

send pkt4

send pkt5

pkt2 timeoutsend pkt2,3,4,5

rcv pkt2send ACK2rcv pkt4,discardsend ACK2

send ACK2rcv pkt5,discard


GBN inaction

Premature timeout


rcv ACK0


rcv ACK1

Sender Receiver

send pkt2

send pkt3

rcv pkt3,discardsend ACK1

send pkt4

send pkt5

pkt2 timeoutsend pkt2,3,4,5

rcv pkt2send ACK2rcv pkt4,discardsend ACK2

send ACK2rcv pkt5,discard


Selective Repeat

receiver individually acknowledges all correctly received pkts buffers pkts, as needed, for eventual in-order

delivery to upper layer

sender only resends pkts for which ACK not received sender timer for each unACKed pkt

sender window N consecutive seq #’s again limits seq #s of sent, unACKed pkts


Selective repeat: sender, receiver windows


Selective repeat

data from above : if next available seq # in

window, send pkt

timeout(n): resend pkt n, restart

timer

ACK(n) in [sendbase,sendbase+N]:

mark pkt n as received if n smallest unACKed

pkt, advance window base to next unACKed seq #

senderpkt n in [rcvbase, rcvbase+N-

1]

send ACK(n) out-of-order: buffer in-order: deliver (also

deliver buffered, in-order pkts), advance window to next not-yet-received pkt

pkt n in [rcvbase-N,rcvbase-1]

ACK(n)

otherwise: ignore

receiver


Selective repeat in action


Selective repeat: dilemmaExample: seq #’s: 0, 1, 2, 3 window size=3

receiver sees no difference in two scenarios!

incorrectly passes duplicate data as new in (a)

Q: what relationship between seq # size and window size? Will this happen in GBN ?


Go Back N vs. Selective Repeat

Efficiency No loss Loss

• Bursty loss• Sporadic loss

Resource consumption Buffer space Timer

• How to implement multi-timers ?


Outline










TCP: Overview RFCs: 793, 1122, 1323, 2018, 2581

full duplex data: bi-directional data flow

in same connection

connection-oriented: handshaking

(exchange of control msgs) init’s sender, receiver state before data exchange

flow controlled: sender will not

overwhelm receiver

End-to-end, unicast: one sender, one receiver

reliable, in-order byte steam: no “message

boundaries”

Pipelined (not stop-wait): TCP congestion and flow

control set window size send & receive buffers

socketdoor

T C Psend buffer

T C Preceive buffer

socketdoor

segm ent

applicationwrites data

applicationreads data


TCP: Overview RFCs: 793, 1122, 1323, 2018, 2581

End-to-end, unicast: one sender, one receiver

OR

Unicast

BroadcastBroadcast

Multicast

Anycast


TCP segment structure


32 bits

applicationdata

(variable length)

sequence number

acknowledgement numberReceive window

Urg data pnterchecksum

FSRPAUheadlen

notused

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 willingto accept

countingby bytes of data(not segments!)

Internetchecksum

(as in UDP)


TCP Connection Setup

Three way handshake:

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

Q: Is 3-way handshake perfect ?


TCP reliable data transfer

TCP creates rdt service on top of IP’s unreliable service

Pipelined segments Cumulative acks TCP uses single

retransmission timer

Retransmissions are triggered by: timeout events duplicate acks

Initially consider simplified TCP sender: ignore duplicate acks ignore flow control,

congestion control


TCP ACK generation [RFC 1122, RFC 2581]

Event at Receiver

Arrival of in-order segment withexpected seq #. All data up toexpected seq # already ACKed

Arrival of in-order segment withexpected seq #. One other segment has ACK pending

Arrival of segment that partially or completely fills gap

Arrival of out-of-order segmenthigher-than-expect seq. # .Gap detected

TCP Receiver action

Delayed ACK. Wait up to 500msfor next segment. If no next segment,send ACK

Immediately send single cumulative ACK, ACKing both in-order segments

Immediate send ACK, provided thatsegment starts at lower end of gap

Immediately send duplicate ACK, indicating seq. # of next expected byte


Fast Retransmit

Time-out period may be relatively long: eRTT+4DevRTT long delay before resending lost packet

Solution: Fast Retransmit Hint: GBN


GBN inaction


Fast Retransmit

Time-out period may be relatively long: eRTT+4DevRTT 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


event: ACK received, with ACK field value of y if (y > SendBase) { SendBase = y if (there are currently not-yet-acknowledged segments) start timer } else { increment count of dup ACKs received for y if (count of dup ACKs received for y = 3) { resend segment with sequence number y }

Fast retransmit algorithm:

a duplicate ACK for already ACKed segment

fast retransmit


TCP Round Trip Time and TimeoutQ: how to estimate RTT?

SampleRTT: measured time from segment transmission until ACK receipt

One RTT sample


TCP Round Trip Time and Timeout Problem 2:

SampleRTT will vary -> atypical Need the trend of RTT: history –> future average several recent measurements, not just

current SampleRTTRTT: 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

isec

onds

)

SampleRTT Estimated RTT


TCP Round Trip Time and TimeoutEstimatedRTT = (1- )* EstimatedRTT + *SampleRTT

typical value: = 0.125 influence of past sample decreases exponentially fast

Exponential weighted moving average


Outline










Principles of Congestion Control

Congestion: informally: “too many sources sending too

much data too fast for network to handle” Solution

Sender controls sending rate

different from flow control! Flow control: not overwhelm receiver Congestion control: not overwhelm network

another top-10 problem!


Approaches towards congestion control

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:

End-end congestion control:

no explicit feedback from network

congestion inferred from end-system observed loss, delay

approach taken by TCP

Fast, accurate, but expensive


TCP Congestion Control

end-end control (no network assistance) sender limits transmission: LastByteSent-LastByteAcked

CongWin

RcvWindow?

min { rcwWindow, CongWin } CongWin is dynamic, function of

perceived network congestion Too high a rate -> congestion Too low a rate -> low network utilization


TCP Congestion Control

How does sender perceive congestion? loss event TCP sender reduces rate (CongWin) after loss

event

Loss event = timeout or 3 duplicate acks

three mechanisms: AIMD (additive increase multiplicative decrease) slow start conservative after timeout events


1. TCP AIMD

8 Kbytes

16 Kbytes

24 Kbytes

time

congestionwindow

multiplicative decrease : cut CongWin in half after loss event

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

Long-lived TCP connection

Sawtooth


2. TCP Slow Start

When connection begins, CongWin = 1 MSS Example: MSS = 500

bytes & RTT = 200 msec initial rate = 20 kbps

available bandwidth may be >> MSS/RTT desirable to quickly ramp

up to respectable rate

When connection begins, increase rate exponentially fast until first loss event


2. TCP Slow Start (more)

When connection begins, increase rate exponentially until first loss event: double CongWin every

RTT done by incrementing CongWin for every ACK received

Summary: initial rate is slow but ramps up exponentially fast

Host A

one segment

RTT

Host B

time

two segments

four segments


3. Refinement (TCP Reno) After 3 dup ACKs:

CongWin is cut in half window then grows linearly

But after timeout event: CongWin instead set to 1 MSS; window then grows exponentially to a Threshold, then grows linearly

• 3 dup ACKs indicates network capable of delivering some segments• timeout before 3 dup ACKs is “more alarming”

Philosophy:

Tahoe -> Reno -> Sack

TCP versions:

Vegas, Westwood …(Nevada)


Refinement (more)Q: Threshold: When will

exponential increase switch to linear?

A: When CongWin gets to 1/2 of its value before timeout.

Implementation: Variable Threshold At a loss event, Threshold

is set to 1/2 of CongWin just before loss event

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

es

tio

n w

ind

ow

siz

e

(se

gm

en

ts)

Series1 Series2

threshold

TCPTahoe

TCPReno

TimeOut


TCP congestion behavior (1)

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

es

tio

n w

ind

ow

siz

e

(se

gm

en

ts)

Series1 Series2

threshold

TimeOut



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

es

tio

n w

ind

ow

siz

e

(se

gm

en

ts)

Series1 Series2

threshold

TCPTahoe

3 Dup Ack



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

es

tio

n w

ind

ow

siz

e

(se

gm

en

ts)

Series1 Series2

threshold

TCPTahoe

TCPReno

3 Dup Ack


Summary: TCP Congestion Control (Reno) When CongWin is below Threshold, sender in

slow-start phase, window grows exponentially.

When CongWin is above Threshold, sender is in congestion-avoidance phase, window grows linearly.

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.

V. Jacobson, Congestion Avoidance and Control. Proceedings of ACM SIGCOMM '88, Aug. 1988.


Outline










Fair: 1. Equal share 2. Full utilizationGoal: 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


TCP AIMD

8 Kbytes

16 Kbytes

24 Kbytes

time

congestionwindow

multiplicative decrease : cut CongWin in half after loss event

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

Long-lived TCP connection

Sawtooth


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


Why is TCP fair?

R

RConnection 1 throughputConnect

ion 2

th

roughput

x=y

x

y

(x0,y0)

(x0+Δ, y0+Δ)

(x0/2+Δ/2, y0/2+Δ/2)

Known: x0>y0

(x0+Δ/2, y0+Δ/2)


Why is TCP fair?

R

R

x=y

Connection 1 throughputConnect

ion 2

th

roughput

D.M. Chiu and R. Jain, "Analysis of the Increase and Decrease Algorithms for Congestion Avoidance in Computer Networks,"

Computer Networks and ISDN Systems, pp. 1-14, 1989.


Outline










Internet multimedia: simplest approach

audio, video not streamed: no, “pipelining,” long delays until playout!

audio or video stored in file files transferred as HTTP object

received in entirety at client then passed to player


Internet multimedia: naïve streaming approach

browser GETs metafile browser launches player, passing metafile player contacts server (HTTP) server streams audio/video to player (HTTP/TCP)


Streaming Multimedia: UDP or TCP?

TCP rate fluctuates due to TCP congestion control

Saw-tooth behavior larger playout delay

smooth TCP delivery rate/retransmission HTTP/TCP passes more easily through firewalls

UDP short playout delay (2-5 seconds) lower overhead smoothed rate error recovery

Not 100%, but real-time


Problem with UDP: Unresponsive Flows

Unresponsive flows Do not use congestion control, and in particular, do not

reduce their load on the network when subjected to packet drops

Results self-interference: link capacity < stream drop own

packets• typical for residential access links

mutual interference: multiple streams competing for bottleneck bandwidth

• loss as congestion indicator rude streams push aside polite ones

Example: TCP competing with unresponsive UDP TCP flows reduce sending rates in response to congestion Uncooperative UDP flows capture the available bandwidth Unfair to TCP, or even starve TCP


Re-engineering the network, or hosts ?

Deployment of packet scheduling disciplines in routers to isolate each flow (next chapter) Re-engineer the Internet

End-to-end congestion control and use of incentives Re-engineer the hosts

Pricing mechanisms All three approaches are not mutually

exclusive


Objective: TCP-friendly

TCP TCP

Internetnon-TCP

non-TCP

“ long-term throughput does not exceed the throughput of a conformant TCP connection under the same conditions”


TCP-friendly congestion control

Two common approaches: rate-based: control rate of traffic window-based: limit number of unacknowledged

packets• window size controls rate, so related

Careful: ≠ flow control = prevents end-system buffer overflow however, window-based control can be used for both


Window-based ?

Window control not really appropriate for multimedia applications: time-scale too short (~ RTT) constantly switch codecs

visible or audible transitions may start or drop below minimum codec rate

Flow control not needed since receiver will need to process data at the nominal (codec) rate


Rate or Equation based

Question Given observed parameters of a path, what’s R, the

long-term throughput of a TCP flow, as if it is running over this path ?

Solution Ensure that the sending rate is no more than T

• TCP Friendly Rate Control (TFRC) and many variations Sub-questions

What are the parameters ? How to estimate them ? T as a function of the parameters ?


Performance evaluation

Typical Methods Measurement

Ping, traceroute

Simulation Ns-2

Analytical modeling Math


TCP Throughput Equation

Round-trip delay T Packet size L Loss event rate q Retransmission timeout TRTO ~

4T

22 3(3 ) (1 32 )

3 8RTO

LR

q qT T q q

=+ +

Padhye, J., Firoiu, V., Towsley, D., and Kurose, J., Modeling TCP Throughput: a Simple Model and its Empirical Validation, UMASS CMPSCI Tech Report TR98-008,

Feb. 1998.


TCP Throughput Equation: Simplified Version

Round-trip delay T Packet size L Loss rate q Retransmission timeout

TRTO ~ 4T

22 3(3 ) (1 32 )

3 8RTO

LR

q qT T q q

=+ +

1.22LR

T q»


Derivation (1)

Round-trip delay T Packet size L Loss event rate q

Focus on AIMD in steady-state only

•In one cycle (T0), cwnd grows until a maximum valueW, then a loss is encountered, which reduces cwnd to W/2 .

( 1)

o

NR L

T-

=

Assume N packets are sent in one cycle

? ?oN T


Derivation (2)In one cycle (T0), cwnd grows until a maximum valueW, then a loss is encountered, which reduces cwnd to W/2 . •Exactly a full window is sent per round trip time T, thus the window increases by one packet per T

0 2W

T T=

( 1)

o

NR L

T-

=

Assume N packets are sent in one cycle

2

0

( ) 38

oT W tN dt W

T= =ò

1/q N=

2 12

3W

qÞ =

0

1 3( 1)( 1) 2

2 13

LN qR L LT T q

Tq

--

Þ = = »If q is small (<5%)


Beyond Congestion Control: Client-side operations

jitter removal decompression error concealment graphical user interface

w/ controls for interactivity

Media Player


constant bit rate videotransmission

Cum

ula

tive

data

time

variablenetwork

delay

client videoreception

constant bit rate video playout at client

client playoutdelay

bu

ffere

dvid

eo

Jitter Removal: Client Buffering


Client Buffering

Client-side buffering, playout delay compensate for network-added delay, delay jitter

Q: How to determine the playout delay ?

bufferedvideo

variable fillrate, x(t)

constant drainrate, d


Case Study: Real-time interactive applications

PC-2-PC phone instant messaging services

are providing this PC-2-phone

Dialpad Net2phone

Phone-2-Phone videoconference with

Webcams

Going to now look at a PC-2-PC Internet phone example in detail


Interactive Multimedia: Internet Phone

Introduce Internet Phone by way of an example

speaker’s audio: alternating talk spurts, silent periods. 64 kbps during talk spurt

pkts generated only during talk spurts 20 msec chunks at 8 Kbytes/sec: 160 bytes data

application-layer header added to each chunk.

Chunk+header encapsulated into UDP segment.

application sends UDP segment into socket every 20 msec during talkspurt.


Internet Phone: Packet Loss and Delay

network loss: IP datagram lost due to network congestion (router buffer overflow)

delay loss: IP datagram arrives too late for playout at receiver delays: processing, queueing in network; end-system

(sender, receiver) delays typical maximum tolerable delay: 400 ms

loss tolerance: depending on voice encoding, losses concealed, packet loss rates between 1% and 10% can be tolerated.


constant bit ratetransmission

Cum

ula

tive

data

time

variablenetwork

delay(jitter)

clientreception

constant bit rate playout at client

client playoutdelay

bu

ffere

ddata

Delay Jitter

Consider the end-to-end delays of two consecutive packets: difference can be more or less than 20 msec


Internet Phone: Fixed Playout Delay

Receiver attempts to playout each chunk exactly q msecs after chunk was generated. chunk has time stamp t: play out chunk at t+q . chunk arrives after t+q: data arrives too late for

playout, data “lost” Tradeoff for q:

large q: less packet loss small q: better interactive experience


Fixed Playout Delay

packets

tim e

packetsgenerated

packetsreceived

loss

r

p p '

playout schedulep' - r

playout schedulep - r

• Sender generates packets every 20 msec during talk spurt.• First packet received at time r• First playout schedule: begins at p• Second playout schedule: begins at p’


Internet Phone: Fixed Playout Delay

Tradeoff for q: large q: less packet loss small q: better interactive experience

packets

tim e

packetsgenerated

packetsreceived

loss

r

p p '

playout schedulep' - r

playout schedulep - r


Adaptive Playout Delay, I

packetith receivingafter delay network average of estimated

acketpith for delay network tr

receiverat played is ipacket timethep

receiverby received is ipacket timether

packetith theof timestampt

i

ii

i

i

i

Dynamic estimate of average delay at receiver:

)()1( 1 iiii trudud

where u is a fixed constant (e.g., u = .01).

Goal: minimize playout delay, keeping late loss rate low Approach: adaptive playout delay adjustment:

Estimate network delay, adjust playout delay at beginning of each talk spurt.

Silent periods compressed and elongated. Chunks still played out every 20 msec during talk spurt.


Adaptive playout delay II

Also useful to estimate the average deviation of the delay, vi :

||)1( 1 iiiii dtruvuv

The estimates di and vi are calculated for every received packet, although they are only used at the beginning of a talk spurt.

For first packet in talk spurt, playout time is:

iiii Kvdtp

where K is a positive constant.

Remaining packets in talkspurt are played out periodically


Adaptive Playout, III

Q: How does receiver determine whether packet is first in a talkspurt?

If no loss, receiver looks at successive timestamps. difference of successive stamps > 20 msec -->talk spurt

begins. With loss possible, receiver must look at both time stamps

and sequence numbers. difference of successive stamps > 20 msec and sequence

numbers without gaps --> talk spurt begins.


How to deal with packet loss ?

Network loss Delay loss ARQ ?

Non-realtime


Recovery from packet loss – FEC (1)

forward error correction (FEC): simple scheme for every group of n chunks create a redundant

chunk by exclusive OR-ing the n original chunks send out n+1 chunks, increasing the bandwidth by

factor 1/n. can reconstruct the original n chunks if there is at

most one lost chunk from the n+1 chunks



Playout delay needs to be fixed to the time to receive all n+1 packets

Tradeoff: increase n, less bandwidth waste increase n, longer playout delay increase n, higher probability that 2 or more

chunks will be lost



2nd FEC scheme• “piggyback lower quality stream” • send lower resolutionaudio stream as theredundant information• for example, nominal stream PCM at 64 kbpsand redundant streamGSM at 13 kbps.

• Whenever there is non-consecutive loss, thereceiver can conceal the loss. • Can also append (n-1)st and (n-2)nd low-bit ratechunk


Recovery from packet loss - Interleaving

Interleaving chunks are broken

up into smaller units for example, 4 5 msec units per

chunk Packet contains small units from

different chunks

if packet is lost, still have most of every chunk

has no redundancy overhead but adds to playout delay


Q: Does Interleaving reduce error rate ?


More Error Recovery (1)

Advanced error detection and correction codes

Digital fountain – Tornado code

(n, k, 2s +1) Reed Solomon Code:k 2s

Based on Galois Field (GF, a finite field)Can detect 2s errorsCan correct s errorsGenerally can correct erasures and errors if

+ 2 2s

n


More Error Recovery (2)

Joint source-channel coding Shannon’s coding theory

Performance• Joint source-channel coding = separate coding

But … infinite block length So … infinite delay

Channel estimation Adaptive source coding – channel aware


Outline










Beyond UDP: Protocol Stack for Streaming

UDP/RTP/RTCP

RTSP


User Control of Streaming Media: RTSP

HTTP Does not target multimedia content No commands for fast forward, etc. HTTP streaming ? DASH ?

RTSP: RFC 2326 Client-server application layer protocol. For user to control display: rewind, fast forward, pause,

resume, repositioning, etc…Real-time Streaming Protocol


RTSP (Real-Time Streaming Protocol)

What it doesn’t do: does not define how audio/video is encapsulated for

streaming over network does not restrict how streamed media is transported; it

can be transported over UDP or TCP does not specify how the media player buffers

audio/video


RTSP Example

Scenario: metafile communicated to web browser browser launches player player sets up an RTSP control connection, data connection

to streaming server


Metafile Example

<title>Twister</title> <session> <group language=en lipsync> <switch> <track type=audio e="PCMU/8000/1" src = "rtsp://audio.example.com/twister/audio.en/lofi"> <track type=audio e="DVI4/16000/2" pt="90 DVI4/8000/1" src="rtsp://audio.example.com/twister/audio.en/hifi"> </switch> <track type="video/jpeg" src="rtsp://video.example.com/twister/video"> </group> </session>


RTSP Operation


RTSP Exchange Example C: SETUP rtsp://audio.example.com/twister/audio RTSP/1.0 Transport: rtp/udp; compression; port=3056; mode=PLAY

S: RTSP/1.0 200 1 OK Session 4231

C: PLAY rtsp://audio.example.com/twister/audio.en/lofi RTSP/1.0 Session: 4231 Range: npt=0- normal playback time

C: PAUSE rtsp://audio.example.com/twister/audio.en/lofi RTSP/1.0 Session: 4231 Range: npt=37

C: TEARDOWN rtsp://audio.example.com/twister/audio.en/lofi RTSP/1.0 Session: 4231

S: 200 3 OK


RTSP: out of band control

FTP uses an “out-of-band” control channel:

A file is transferred over one TCP connection.

Control information (directory changes, file deletion, file renaming, etc.) is sent over a separate TCP connection.

The “out-of-band” and “in-band” channels use different port numbers.

RTSP messages are also sent out-of-band:

RTSP control messages use different port numbers than the media stream: out-of-band.

Port 554

The media stream is considered “in-band”.


RTSP vs. HTTP

Out-of-band – in band Stateful - stateless


Real-Time Protocol (RTP)

RTP specifies a packet structure for packets carrying audio and video data

RFC 1889. RTP packet provides

payload type identification packet sequence numbering timestamping


RTP runs on top of UDP

RTP libraries provide a transport-layer interface that extend UDP:

• port numbers, IP addresses• payload type identification• packet sequence numbering• time-stamping

Interoperability: If two Internet phone applications run RTP, then they are able to work together


RTP Example

Consider sending 64 kbps PCM-encoded voice over RTP.

Application collects the encoded data in chunks, e.g., every 20 msec = 160 bytes in a chunk.

The audio chunk along with the RTP header form the RTP packet, which is encapsulated into a UDP segment.

RTP header indicates type of audio encoding in each packet sender can change

encoding during a conference.

RTP header also contains sequence numbers and timestamps.


RTP Header

Payload Type (7 bits): Indicates type of encoding currently being used. If sender changes encoding in middle of conference, sender informs the receiver through this payload type field.

•Payload type 0: PCM mu-law, 64 kbps•Payload type 3, GSM, 13 kbps•Payload type 7, LPC, 2.4 kbps•Payload type 26, Motion JPEG•Payload type 31. H.261•Payload type 33, MPEG2 video

Sequence Number (16 bits): Increments by one for each RTP packet sent, and may be used to detect packet loss and to restore packet sequence.


RTP Header (2)

Timestamp field (32 bytes long). Reflects the sampling instant of the first byte in the RTP data packet. For audio, timestamp clock typically increments by one for

each sampling period (for example, each 125 usecs for a 8 KHz sampling clock)

if application generates chunks of 160 encoded samples, then timestamp increases by 160 for each RTP packet when source is active. Timestamp clock continues to increase at constant rate when source is inactive.

SSRC field (32 bits long). Identifies the source of the RTP stream. Each stream in a RTP session should have a distinct SSRC.


RTP and Quality-of-Service

RTP does not provide any mechanism to ensure timely delivery of data or provide other quality of service guarantees.

RTP encapsulation is only seen at the end systems: it is not seen by intermediate routers. Routers providing best-effort service do not make any

special effort to ensure that RTP packets arrive at the destination in a timely matter.


Real-Time Control Protocol (RTCP)

Works in conjunction with RTP.

Each participant in RTP session periodically transmits RTCP control packets to all other participants.

Each RTCP packet contains sender and/or receiver reports

report statistics useful to application

Statistics include number of packets sent, number of packets lost, interarrival jitter, etc.

Feedback can be used to control performance Sender may modify its

transmissions based on feedback


RTCP Packets

Receiver report packets: fraction of packets lost,

last sequence number, average interarrival jitter.

Sender report packets: SSRC of the RTP stream,

the current time, the number of packets sent, and the number of bytes sent.

Source description packets: e-mail address of sender,

sender's name, SSRC of associated RTP stream.

Provide mapping between the SSRC and the user/host name.


Synchronization of Streams

RTCP can synchronize different media streams within a RTP session.

Consider videoconferencing app for which each sender generates one RTP stream for video and one for audio.

Timestamps in RTP packets tied to the video and audio sampling clocks not tied to the wall-clock

time

Each RTCP sender-report packet contains (for the most recently generated packet in the associated RTP stream):

timestamp of the RTP packet

wall-clock time for when packet was created.

Receivers can use this association to synchronize the playout of audio and video.


Confused ?!

RTSP: Real-Time Streaming ProtocolRTP: Real-Time (transport) ProtocolRTCP: Real-Time Control Protocol

Q: Who controls (sending rate, FEC settings, …)

RTP ? RTCP ?

More on later…

Henning Schulzrinne, RTP website http://www.cs.columbia.edu/~hgs/rtp/


What’s hot/difficult now?

TCP/UDP penetration Firewall/NAT STUN ? HTTP streaming ?

Wireless mobile TCP Different loss/error patterns Energy Mobility/multihome

Ultra high speed networks Slow TCP ? TCP incast TCP in a data center Virtualization

Documents

CMPT771 Transport Layer 1 Transport Layer Issues Spring 2015 CMPT 771 InternetArchitecture and Protocols