cmpt771 transport layer 1 transport layer issues spring 2015 cmpt 771 internetarchitecture and...

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

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

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

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

client IP: A

P1P1P3

serverIP: C

SP: 80

DP: 9157

SP: 9157

DP: 80

SP: 80

DP: 5775

SP: 5775

DP: 80

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

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

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

a) operation with no corruption

sender receiver

rcv ACK0send pkt1

send NAK1

rcv NAK1resend pkt1

rcv pkt1send ACK1

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

(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

a) operation with no corruption

sender receiver

rcv ACK0send pkt1

send ACK0

rcv ACK0resend pkt1

rcv pkt1send 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

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

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

rdt_send(data)

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

stop_timer

udt_send(sndpkt)start_timer

timeout

udt_send(sndpkt)start_timer

timeout

rdt_rcv(rcvpkt)

Wait for call 0from

Wait for ACK1

rdt_rcv(rcvpkt)

Sender

rdt3.0: Poor performance

first packet bit transmitted, t = 0

sender receiver

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

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

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 #

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

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

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

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-

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

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

1 8 15 22 29 36 43 50 57 64 71 78 85 92 99 106

time (seconnds)

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

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

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

Host B

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

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

Transmission round

Series1 Series2

threshold

TCPTahoe

TCPReno

TimeOut

TCP congestion behavior (1)

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

Transmission round

Series1 Series2

threshold

TimeOut

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

Transmission round

Series1 Series2

threshold

TCPTahoe

3 Dup Ack

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

Transmission round

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

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

equal bandwidth share

Connection 1 throughputConnect

roughput

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

Why is TCP fair?

RConnection 1 throughputConnect

roughput

(x0,y0)

(x0+Δ, y0+Δ)

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

Known: x0>y0

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

Why is TCP fair?

Connection 1 throughputConnect

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 ~

22 3(3 ) (1 32 )

3 8RTO

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

q qT T q q

1.22LR

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 .

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

Assume N packets are sent in one cycle

( ) 38

oT W tN dt W

T= =ò

1/q N=

1 3( 1)( 1) 2

LN qR L LT T q

Þ = = »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

variablenetwork

client videoreception

constant bit rate video playout at client

client playoutdelay

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

variablenetwork

delay(jitter)

clientreception

constant bit rate playout at client

client playoutdelay

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

packetsgenerated

packetsreceived

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

packetsgenerated

packetsreceived

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

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

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

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

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 ?

cmpt771 transport layer 1 transport layer issues spring 2015 cmpt 771 internetarchitecture and...

Documents

fall 2007csci232: transport layer & tcp1 transport layer ...

transport layer: tcp - École polytechnique fédérale de...

transport layer. transport layer overview transport layer is...

transport layer function transport layer - forsiden ......

tcp friendliness cmpt771 spring 2008 michael jia

chapter 3 transport layer - school of computing and...

chapter 3 chapter 3: transport layer transport layer

transport layer

transport layer cs 3516 – computer networks. chapter 3:...

chapter 3: transport layer transport layer transport layer...

transport layer function transport layer

transport layer introduction of transport layer the...

transport layer 3-1 transport layer dr ahmad al-zubi

cos 461 fall 1997 transport layer ftphttpsmtpdnsfinger...

chapter 3 transport layer -...

transport layer chapter 3 architecture transport layer

datagram transport layer security (dtls) as a transport...

transport layer. transport layer – topics r review:...

transport layer issues - computer · pdf file1 review:...

transport layer -- may 20041 transport layer computer...