CMPT 771
InternetArchitecture and
Protocols
Transport Layer
Issues
Spring 2015
CMPT771 Transport Layer
1
Transport Layer Issues
Contents:
 overview principles
behind transport
layer services:




multiplexing/demultipl
exing
reliable data transfer
flow control
congestion control
 TCP Performance analysis
 Transport protocols for
media applications
CMPT771 Transport Layer
2
But first,
a general overview of networks (and the Internet)
Telecommunication
networks
Circuit-switched
networks
FDM
TDM
Packet-switched
networks
Networks
with VCs
Datagram
Networks
CMPT771 Transport Layer
3
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, III
1996
President of the Chicago Chapter of the Internet Society
CMPT771 Transport Layer
Copyright 2002, William F. Slater, III, Chicago, IL, USA
4
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
CMPT771 Transport Layer
5
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
CMPT771 Transport Layer
6
Internet Evolution/Organization
CMPT771 Transport Layer
7
ISO 7-layer reference model
application
application
transport
presentation
network
session
link
physical
CMPT771 Transport Layer
8
Internet protocol stack
 application: supporting network
applications

FTP, SMTP, STTP
application
 transport: host-host data transfer
 TCP, UDP
transport
 network: routing of datagrams from
network
source to destination

IP, routing protocols
 link: data transfer between
neighboring network elements

link
physical
PPP, Ethernet
 physical: bits “on the wire”
CMPT771 Transport Layer
9
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)
CMPT771 Transport Layer
10
Why the Internet ?
 Why not other networks ?
- Telephone
- Wireless networks
- Optical networks
…
 I have two reasons …
CMPT771 Transport Layer
11
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
CMPT771 Transport Layer
12
Transport layer – the other side of the door
host or
server
host or
server
process
controlled by
app developer
process
socket
socket
TCP with
buffers,
variables
Internet
TCP with
buffers,
variables
controlled
by OS
 API: (1) choose transport protocol; (2) set parameters
CMPT771 Transport Layer
13
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
transport
network
data link
physical
network
data link
physical
network
data link
physical
network
data link
physical
network
data link
physical
network
data link
physical
application
transport
network
data link
physical
CMPT771 Transport Layer
14
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.
CMPT771 Transport Layer
15
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. RTSP/RTP/RTCP
CMPT771 Transport Layer
16
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

32 bits
source port #
dest port #
other header fields
application
data
(message)
TCP/UDP segment format
CMPT771 Transport Layer
17
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
CMPT771 Transport Layer
18
Connection-oriented demux
P2
P3
SP: 80
SP: 80
DP: 9157
DP: 5775
SP: 9157
client
IP: A
DP: 80
P1
P1
P4
SP: 5775
server
IP: C
DP: 80
Client
IP:B
CMPT771 Transport Layer
19
Connection-oriented demux
 TCP socket identified
by 4-tuple:




source IP address
source port number
dest IP address
dest port number
Q:
 Why use 4-tuple?
 recv host uses all four
values to direct
segment to appropriate
socket
CMPT771 Transport Layer
20
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
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
CMPT771 Transport Layer
21
UDP: User Datagram Protocol
 “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
[RFC 768]
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
CMPT771 Transport Layer
22
UDP: more
 often used for streaming
multimedia apps
 loss tolerant
 rate sensitive
 other UDP uses
 DNS – why ?
Length, in
bytes of UDP
segment,
including
header
 reliable transfer over UDP:
add reliability at
application layer
 application-specific
error recovery!
32 bits
source port #
dest port #
length
checksum
Application
data
(message)
UDP segment format
CMPT771 Transport Layer
23
Demux:
Connection vs Connection-less
Multi-party video conference
CMPT771 Transport Layer
24
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. RTSP/RTP/RTCP
CMPT771 Transport Layer
25
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)
CMPT771 Transport Layer
26
Reliable data transfer: getting started
rdt_send(): called from above,
(e.g., by app.). Passed data to
deliver to receiver upper layer
send
side
udt_send(): called by rdt,
to transfer packet over
unreliable channel to receiver
deliver_data(): called by
rdt to deliver data to upper
receive
side
rdt_rcv(): called when packet
arrives on rcv-side of channel
CMPT771 Transport Layer
27
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

CMPT771 Transport Layer
28
rdt2.0: channel with bit errors
rdt_send(data)
snkpkt = make_pkt(data, checksum)
udt_send(sndpkt)
rdt_rcv(rcvpkt) &&
isNAK(rcvpkt)
Wait for
Wait for
call from
ACK or
udt_send(sndpkt)
above
NAK
rdt_rcv(rcvpkt) && isACK(rcvpkt)
L
sender
receiver
rdt_rcv(rcvpkt) &&
corrupt(rcvpkt)
udt_send(NAK)
Wait for
call from
below
rdt_rcv(rcvpkt) &&
notcorrupt(rcvpkt)
extract(rcvpkt,data)
deliver_data(data)
udt_send(ACK)
CMPT771 Transport Layer
29
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
CMPT771 Transport Layer
30
rdt2.1: sender, handles garbled ACK/NAKs
rdt_send(data)
sndpkt = make_pkt(0, data, checksum)
udt_send(sndpkt)
rdt_rcv(rcvpkt) &&
( corrupt(rcvpkt) ||
Wait
for
Wait for
isNAK(rcvpkt) )
ACK or
call 0 from
udt_send(sndpkt)
NAK 0
above
rdt_rcv(rcvpkt)
&& notcorrupt(rcvpkt)
&& isACK(rcvpkt)
rdt_rcv(rcvpkt)
&& notcorrupt(rcvpkt)
&& isACK(rcvpkt)
L
rdt_rcv(rcvpkt) &&
( corrupt(rcvpkt) ||
isNAK(rcvpkt) )
udt_send(sndpkt)
L
Wait for
ACK or
NAK 1
Wait for
call 1 from
above
rdt_send(data)
sndpkt = make_pkt(1, data, checksum)
udt_send(sndpkt)
CMPT771 Transport Layer
31
rdt2.1: receiver, handles garbled ACK/NAKs
rdt_rcv(rcvpkt) && notcorrupt(rcvpkt)
&& has_seq0(rcvpkt)
rdt_rcv(rcvpkt) && (corrupt(rcvpkt)
extract(rcvpkt,data)
deliver_data(data)
sndpkt = make_pkt(ACK, chksum)
udt_send(sndpkt)
rdt_rcv(rcvpkt) && (corrupt(rcvpkt)
sndpkt = make_pkt(NAK, chksum)
udt_send(sndpkt)
rdt_rcv(rcvpkt) &&
not corrupt(rcvpkt) &&
has_seq1(rcvpkt)
sndpkt = make_pkt(ACK, chksum)
udt_send(sndpkt)
sndpkt = make_pkt(NAK, chksum)
udt_send(sndpkt)
Wait for
0 from
below
Wait for
1 from
below
rdt_rcv(rcvpkt) && notcorrupt(rcvpkt)
&& has_seq1(rcvpkt)
rdt_rcv(rcvpkt) &&
not corrupt(rcvpkt) &&
has_seq0(rcvpkt)
sndpkt = make_pkt(ACK, chksum)
udt_send(sndpkt)
extract(rcvpkt,data)
deliver_data(data)
sndpkt = make_pkt(ACK, chksum)
udt_send(sndpkt)
CMPT771 Transport Layer
32
rdt 2.1 in action
sender
send pkt0
receiver
pkt
ACK
rcv ACK0
send pkt1
pkt
ACK
rcv ACK1
send pkt0
pkt
ACK
rcv pkt0
send ACK0
rcv pkt1
send ACK1
rcv pkt0
send ACK0
a) operation with no corruption
sender
send pkt0
receiver
pkt
ACK
rcv pkt0
send ACK0
rcv ACK0
pkt
send pkt1 X (corrupted)
rcv pkt1
send NAK1
NAK
rcv NAK1
resend pkt1
pkt
ACK
rcv pkt1
send ACK1
b) packet corrupted
CMPT771 Transport Layer
33
rdt 2.1 in action (cont)
receiver
sender
send pkt0
pkt
rcv pkt0
ACK send ACK0
(corrupted) X
rcv ACK0
pkt
resend pkt0
rcv pkt0
send ACK0
ACK
rcv ACK0
send pkt1
pkt
ACK
rcv pkt1
send ACK1
c) ACK corrupted
CMPT771 Transport Layer
34
rdt2.2: a NAK-free protocol
rdt_send(data)
sndpkt = make_pkt(0, data, checksum)
udt_send(sndpkt)
rdt_rcv(rcvpkt) &&
( corrupt(rcvpkt) ||
Wait for
Wait for
isACK(rcvpkt,1) )
ACK
call 0 from
0
udt_send(sndpkt)
above
sender FSM
fragment
rdt_rcv(rcvpkt) &&
(corrupt(rcvpkt) ||
has_seq1(rcvpkt))
udt_send(sndpkt)
Wait for
0 from
below
rdt_rcv(rcvpkt)
&& notcorrupt(rcvpkt)
&& isACK(rcvpkt,0)
receiver FSM
fragment
L
rdt_rcv(rcvpkt) && notcorrupt(rcvpkt)
&& has_seq1(rcvpkt)
extract(rcvpkt,data)
deliver_data(data)
sndpkt = make_pkt(ACK1, chksum)
udt_send(sndpkt)
CMPT771 Transport Layer
35
rdt 2.2 in action
sender
send pkt0
receiver
pkt0
ACK0
rcv ACK0
send pkt1
pkt1
ACK1
rcv ACK1
send pkt0
pkt0
ACK0
rcv pkt0
send ACK0
rcv pkt1
send ACK1
rcv pkt0
send ACK0
a) operation with no corruption
sender
send pkt0
receiver
pkt0
ACK0
rcv pkt0
send ACK0
rcv ACK0
pkt1
send pkt1
X (corrupted)
rcv pkt1
send ACK0
ACK0
rcv ACK0
resend pkt1
pkt1
ACK1
rcv pkt1
send ACK1
b) packet corrupted
CMPT771 Transport Layer
36
rdt 2.2 in action (cont)
sender
send pkt0
receiver
pkt0
rcv pkt0
ACK0 send ACK0
(corrupted) X
rcv ACK0
pkt0
resend pkt0
rcv pkt0
send ACK0
ACK0
rcv ACK0
send pkt1
pkt1
ACK1
rcv pkt1
send ACK1
c) ACK corrupted
CMPT771 Transport Layer
37
rdt3.0 channels with errors and loss
rdt_send(data)
sndpkt = make_pkt(0, data, checksum)
udt_send(sndpkt)
start_timer
rdt_rcv(rcvpkt)
L
rdt_rcv(rcvpkt)
&& notcorrupt(rcvpkt)
&& isACK(rcvpkt,1)
rdt_rcv(rcvpkt) &&
( corrupt(rcvpkt) ||
isACK(rcvpkt,0) )
timeout
udt_send(sndpkt)
start_timer
rdt_rcv(rcvpkt)
&& notcorrupt(rcvpkt)
&& isACK(rcvpkt,0)
stop_timer
stop_timer
timeout
udt_send(sndpkt)
start_timer
L
Wait
for
ACK0
Wait for
call 0from
above
L
rdt_rcv(rcvpkt) &&
( corrupt(rcvpkt) ||
isACK(rcvpkt,1) )
Wait
for
ACK1
Wait for
call 1 from
above
rdt_send(data)
sndpkt = make_pkt(1, data, checksum)
udt_send(sndpkt)
start_timer
rdt_rcv(rcvpkt)
L
Sender
CMPT771 Transport Layer
38
rdt3.0: Poor performance
sender
receiver
first packet bit transmitted, t = 0
last packet bit transmitted, t = L / R
first packet bit arrives
last packet bit arrives, send ACK
RTT
ACK arrives, send next
packet, t = RTT + L / R
stop and wait
Sender sends one packet,
then waits for receiver
response
Stop-and-Wait
U
sender
=
L/R
RTT + L / R
CMPT771 Transport Layer
39
Performance of rdt3.0
 example: 1 Gbps link, 15 ms e-e prop. delay, 1KB packet:
Ttransmit =
U




L (packet length in bits)
8kb/pkt
=
R (transmission rate, bps)
109 b/sec
sender
=
L/R
RTT + L / R
=
.008
30.008
= 8 microsec
= 0.00027
microsec
onds
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
CMPT771 Transport Layer
40
Pipelined protocols
Pipelining: sender allows multiple, “in-flight”, yet-tobe-acknowledged pkts


range of sequence numbers must be increased
buffering at sender and/or receiver
CMPT771 Transport Layer
41
Pipelining: increased utilization
sender
receiver
first packet bit transmitted, t = 0
last bit transmitted, t = L / R
first packet bit arrives
last packet bit arrives, send ACK
last bit of 2nd packet arrives, send ACK
last bit of 3rd packet arrives, send ACK
RTT
ACK arrives, send next
packet, t = RTT + L / R
U
=
sender
3*L/R
RTT + L / R
=
.024
30.008
Increase utilization
by a factor of 3
= 0.0008
microsecon
ds
 Two generic forms of pipelined protocols: go-Back-N,
selective repeat
CMPT771 Transport Layer
42
Go-Back-N
Sender:
 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

CMPT771 Transport Layer
43
GBN: sender extended FSM
rdt_send(data)
L
base=1
nextseqnum=1
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)
Wait
rdt_rcv(rcvpkt)
&& corrupt(rcvpkt)
timeout
start_timer
udt_send(sndpkt[base])
udt_send(sndpkt[base+1])
…
udt_send(sndpkt[nextseqnum-1])
rdt_rcv(rcvpkt) &&
notcorrupt(rcvpkt)
base = getacknum(rcvpkt)+1
If (base == nextseqnum)
stop_timer
else
start_timer
CMPT771 Transport Layer
44
GBN: receiver extended FSM
default
udt_send(sndpkt)
L
Wait
expectedseqnum=1
sndpkt =
make_pkt( 0, ACK, chksum )
rdt_rcv(rcvpkt)
&& notcurrupt(rcvpkt)
&& hasseqnum(rcvpkt,expectedseqnum)
extract(rcvpkt,data)
deliver_data(data)
sndpkt = make_pkt(expectedseqnum,ACK,chksum)
udt_send(sndpkt)
expectedseqnum++
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 #
CMPT771 Transport Layer
45
GBN in
action
CMPT771 Transport Layer
46
GBN: sender extended FSM
rdt_send(data)
L
base=1
nextseqnum=1
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)
Wait
rdt_rcv(rcvpkt)
&& corrupt(rcvpkt)
timeout
start_timer
udt_send(sndpkt[base])
udt_send(sndpkt[base+1])
…
udt_send(sndpkt[nextseqnum-1])
rdt_rcv(rcvpkt) &&
notcorrupt(rcvpkt)
base = getacknum(rcvpkt)+1
If (base == nextseqnum)
stop_timer
else
start_timer
CMPT771 Transport Layer
47
Receiver
Sender
GBN in
action
send pkt0
send pkt1
send pkt2
send pkt3
Cumulative ACK
rcv ACK0
send pkt4
rcv ACK1
send pkt5
(loss)X
(loss)X
(loss)X
rcv pkt0
send ACK0
rcv pkt1
send ACK1
rcv pkt2
send ACK2
rcv pkt3
send ACK3
rcv pkt4
send ACK4
rcv pkt5
send ACK5
rcv ACK5
send pkt6
send pkt7
send pkt8
send pkt9
CMPT771 Transport Layer
48
Receiver
Sender
GBN in
action
send pkt0
send pkt1
send pkt2
send pkt3
Cumulative ACK
rcv ACK0
send pkt4
rcv ACK1
send pkt5
(loss)X
(loss)X
(loss)X
rcv pkt0
send ACK0
rcv pkt1
send ACK1
rcv pkt2
send ACK2
rcv pkt3
send ACK3
rcv pkt4
send ACK4
rcv pkt5
send ACK5
rcv ACK5
send pkt6
send pkt7
send pkt8
send pkt9
CMPT771 Transport Layer
49
Sender
send pkt0
GBN in
action
Premature
timeout
send pkt1
send pkt2
Receiver
rcv pkt0
send ACK0
rcv pkt1
send ACK1
send pkt3
rcv ACK0
rcv pkt3,discard
send ACK1
send pkt4
rcv ACK1
rcv pkt2
send ACK2
rcv pkt4,discard
send ACK2
send pkt5
pkt2 timeout
send pkt2,3,4,5
rcv pkt5,discard
send ACK2
CMPT771 Transport Layer
50
Sender
send pkt0
GBN in
action
Premature
timeout
send pkt1
send pkt2
Receiver
rcv pkt0
send ACK0
rcv pkt1
send ACK1
send pkt3
rcv ACK0
rcv pkt3,discard
send ACK1
send pkt4
rcv ACK1
rcv pkt2
send ACK2
rcv pkt4,discard
send ACK2
send pkt5
pkt2 timeout
send pkt2,3,4,5
rcv pkt5,discard
send ACK2
CMPT771 Transport Layer
51
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
CMPT771 Transport Layer
52
Selective repeat: sender, receiver windows
CMPT771 Transport Layer
53
Selective repeat
sender
data from above :
receiver
pkt n in [rcvbase, rcvbase+N-1]
 if next available seq # in
 send ACK(n)
timeout(n):
 in-order: deliver (also
window, send pkt
 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 #
 out-of-order: buffer
deliver buffered, in-order
pkts), advance window to
next not-yet-received pkt
pkt n in
[rcvbase-N,rcvbase-1]
 ACK(n)
otherwise:
 ignore
CMPT771 Transport Layer
54
Selective repeat in action
CMPT771 Transport Layer
55
Selective repeat:
dilemma
Example:
 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 ?
CMPT771 Transport Layer
56
Go Back N vs. Selective Repeat
 Efficiency
 No loss
 Loss
• Bursty loss
• Sporadic loss
 Resource consumption
 Buffer space
 Timer
• How to implement multi-timers ?
CMPT771 Transport Layer
57
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
CMPT771 Transport Layer
58
TCP: Overview
RFCs: 793, 1122, 1323, 2018, 2581
 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
socket
door
application
writes data
application
reads data
TCP
send buffer
TCP
receive buffer
 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
socket
door
segment
CMPT771 Transport Layer
59
TCP: Overview
 End-to-end, unicast:
 one sender, one receiver
RFCs: 793, 1122, 1323, 2018, 2581
Multicast
Unicast
Broadcast
OR
Anycast
CMPT771 Transport Layer
60
TCP segment structure
32 bits
URG: urgent data
(generally not used)
ACK: ACK #
valid
PSH: push data now
(generally not used)
RST, SYN, FIN:
connection estab
(setup, teardown
commands)
Internet
checksum
(as in UDP)
source port #
dest port #
sequence number
acknowledgement number
head not
UA P R S F
len used
checksum
Receive window
Urg data pnter
Options (variable length)
counting
by bytes
of data
(not segments!)
# bytes
rcvr willing
to accept
application
data
(variable length)
CMPT771 Transport Layer
61
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 ?
CMPT771 Transport Layer
62
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
CMPT771 Transport Layer
63
TCP ACK generation
[RFC 1122, RFC 2581]
Event at Receiver
TCP Receiver action
Arrival of in-order segment with
expected seq #. All data up to
expected seq # already ACKed
Delayed ACK. Wait up to 500ms
for next segment. If no next segment,
send ACK
Arrival of in-order segment with
expected seq #. One other
segment has ACK pending
Immediately send single cumulative
ACK, ACKing both in-order segments
Arrival of segment that
partially or completely fills gap
Immediate send ACK, provided that
segment starts at lower end of gap
Arrival of out-of-order segment
higher-than-expect seq. # .
Gap detected
Immediately send duplicate ACK,
indicating seq. # of next expected byte
CMPT771 Transport Layer
64
Fast Retransmit
 Time-out period may be relatively long:
 eRTT+4DevRTT
 long delay before resending lost packet
 Solution: Fast Retransmit
 Hint: GBN
CMPT771 Transport Layer
65
GBN in
action
CMPT771 Transport Layer
66
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-toback
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
CMPT771 Transport Layer
67
Fast retransmit algorithm:
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
}
a duplicate ACK for
already ACKed segment
fast retransmit
CMPT771 Transport Layer
68
TCP Round Trip Time and Timeout
Q: how to estimate RTT?
 SampleRTT: measured time from segment transmission
until ACK receipt
One RTT sample
CMPT771 Transport Layer
69
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
SampleRTT
RTT: gaia.cs.umass.edu to fantasia.eurecom.fr
350
300
RTT (milliseconds)

250
200
150
100
1
8
15
22
29
36
43
50
57
64
71
78
85
92
99
106
time (seconnds)
SampleRTT
Estimated RTT
CMPT771 Transport Layer
70
TCP Round Trip Time and Timeout
EstimatedRTT =
(1- )*
EstimatedRTT + *SampleRTT
 typical value:  = 0.125
 influence of past sample decreases exponentially fast

Exponential weighted moving average
CMPT771 Transport Layer
71
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. RTSP/RTP/RTCP
CMPT771 Transport Layer
72
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!
CMPT771 Transport Layer
73
Approaches towards congestion control
Two broad 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
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
CMPT771 Transport Layer
74
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
CMPT771 Transport Layer
75
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
CMPT771 Transport Layer
76
1. TCP AIMD
additive increase:
increase CongWin by
1 MSS every RTT in
the absence of loss
events: probing
multiplicative decrease :
cut CongWin in half
after loss event
congestion
window
24 Kbytes
16 Kbytes
8 Kbytes
Sawtooth
time
Long-lived TCP connection
CMPT771 Transport Layer
77
2. TCP Slow Start
 When connection begins,
CongWin = 1 MSS


Example: MSS = 500 bytes
& RTT = 200 msec
initial rate = 20 kbps
 When connection begins,
increase rate exponentially
fast until first loss event
 available bandwidth may
be >> MSS/RTT

desirable to quickly ramp
up to respectable rate
CMPT771 Transport Layer
78
2. TCP Slow Start (more)
 When connection


Host B
RTT
begins, increase rate
exponentially until
first loss event:
Host A
double CongWin every
RTT
done by incrementing
CongWin for every ACK
received
 Summary: initial rate
is slow but ramps up
exponentially fast
time
CMPT771 Transport Layer
79
3. Refinement (TCP Reno)
Philosophy:
 After 3 dup ACKs:
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
 CongWin
• 3 dup ACKs indicates
network capable of
delivering some segments
• timeout before 3 dup
ACKs is “more alarming”
TCP versions:
Tahoe -> Reno -> Sack
Vegas, Westwood …
(Nevada)
CMPT771 Transport Layer
80
Q: Threshold: When will
exponential increase
switch to linear?
A: When CongWin gets to
1/2 of its value before
timeout.
congestion window size
(segments)
Refinement (more)
Implementation:
 Variable Threshold
 At a loss event, Threshold
is set to 1/2 of CongWin
just before loss event
14
TimeOut
12
10
TCP
Reno
8
6
threshold
4
TCP
Tahoe
2
0
1
2 3
4 5 6 7 8 9 10 11 12 13 14 15
Transmission round
Series1
Series2
CMPT771 Transport Layer
81
TCP congestion behavior (1)
TimeOut
12
10
(segments)
congestion window size
14
8
6
threshold
4
2
0
1
2
3
4
5
6
7
8
9
10
11
12
13 14
15
Transmission round
Series1
Series2
CMPT771 Transport Layer
82
TCP congestion behavior (2)
3 Dup Ack
12
10
(segments)
congestion window size
14
8
6
threshold
4
TCP
Tahoe
2
0
1
2
3
4
5
6
7
8
9
10
11
12
13 14
15
Transmission round
Series1
Series2
CMPT771 Transport Layer
83
TCP congestion behavior (3)
3 Dup Ack
TCP
Reno
12
10
(segments)
congestion window size
14
8
6
threshold
4
TCP
Tahoe
2
0
1
2
3
4
5
6
7
8
9
10
11
12
13 14
15
Transmission round
Series1
Series2
CMPT771 Transport Layer
84
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.
CMPT771 Transport Layer
85
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
CMPT771 Transport Layer
86
TCP Fairness
Fair: 1. Equal share
2. Full utilization
Goal: if K TCP sessions share same bottleneck link
of bandwidth R, each should have average rate of
R/K
TCP connection 1
TCP
connection 2
bottleneck
router
capacity R
CMPT771 Transport Layer
87
TCP AIMD
additive increase:
increase CongWin by
1 MSS every RTT in
the absence of loss
events: probing
multiplicative decrease :
cut CongWin in half
after loss event
congestion
window
24 Kbytes
16 Kbytes
8 Kbytes
Sawtooth
time
Long-lived TCP connection
CMPT771 Transport Layer
88
Why is TCP fair?
Two competing sessions:
 Additive increase gives slope of 1, as throughout increases
 multiplicative decrease decreases throughput proportionally
R
equal bandwidth share
loss: decrease window by factor of 2
congestion avoidance: additive increase
loss: decrease window by factor of 2
congestion avoidance: additive increase
Connection 1 throughput R
CMPT771 Transport Layer
89
Why is TCP fair?
Known:
x0>y0
y
R
x=y
(x0/2+Δ/2, y0/2+Δ/2)
(x0+Δ, y0+Δ)
(x0+Δ/2, y0+Δ/2)
(x0,y0)
Connection 1 throughput R
x
CMPT771 Transport Layer
90
Why is TCP fair?
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.
R
x=y
Connection 1 throughput R
CMPT771 Transport Layer
91
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. RTSP/RTP/RTCP
CMPT771 Transport Layer
92
Internet multimedia: simplest approach
 audio or video stored in file
 files transferred as HTTP object


received in entirety at client
then passed to player
audio, video not streamed:
 no, “pipelining,” long delays until playout!
CMPT771 Transport Layer
93
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)
CMPT771 Transport Layer
94
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
CMPT771 Transport Layer
95
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
CMPT771 Transport Layer
96
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
CMPT771 Transport Layer
97
Objective: TCP-friendly
“long-term throughput does not exceed the throughput
of a conformant TCP connection under the same conditions”
non-TCP
TCP
non-TCP
Internet
TCP
CMPT771 Transport Layer
98
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
CMPT771 Transport Layer
99
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
CMPT771 Transport Layer
100
Rate or Equation based
 Question
 Given observed parameters of a path, what’s R, the longterm 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 ?
CMPT771 Transport Layer
101
Performance evaluation
Typical Methods
 Measurement

Ping, traceroute
 Simulation
 Ns-2
 Analytical modeling
 Math
CMPT771 Transport Layer
102
TCP Throughput Equation




Round-trip delay T
Packet size L
Loss event rate q
Retransmission timeout TRTO ~ 4T
L
R =
T
2q
3q
+ T R T O (3
)q(1 + 32q2 )
3
8
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.
CMPT771 Transport Layer
103
TCP Throughput Equation: Simplified Version




Round-trip delay T
Packet size L
Loss rate q
Retransmission timeout TRTO
~ 4T
L
R =
T
2q
3q
+ T R T O (3
)q(1 + 32q2 )
3
8
1.22L
R »
T q
CMPT771 Transport Layer
104
Derivation (1)
Focus on AIMD in steady-state only



Round-trip delay T
Packet size L
Loss event rate q
(N - 1)
R =
L
To
•In one cycle (T0), cwnd grows until a
maximum valueW, then a loss is encountered,
which reduces cwnd to W/2 .
N ? To ?
Assume N packets are sent in one cycle
CMPT771 Transport Layer
105
Derivation (2)
W
T0 =
T
2
N =
To W
ò0
(t )
3
dt = W
T
8
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
q = 1/ N
Þ W = 2
Þ R =
2 1
3 q
(N - 1)
L =
T0
1
( - 1)
q
L »
T
2 1
T
3 q
3
L
2
q
If q is small (<5%)
(N - 1)
R =
L
To
Assume N packets are sent in one cycle
CMPT771 Transport Layer
106
Beyond Congestion Control: Client-side operations
Media Player
 jitter removal
 decompression
 error concealment
 graphical user interface
w/ controls for interactivity
CMPT771 Transport Layer
107
Jitter Removal: Client Buffering
variable
network
delay
client video
reception
constant bit
rate video
playout at client
buffered
video
constant bit
rate video
transmission
client playout
delay
time
CMPT771 Transport Layer
108
Client Buffering
constant
drain
rate, d
variable fill
rate, x(t)
buffered
video
 Client-side buffering, playout delay compensate
for network-added delay, delay jitter
 Q: How to determine the playout delay ?
CMPT771 Transport Layer
109
Case Study: Real-time interactive applications
 PC-2-PC phone

instant messaging services
are providing this
 PC-2-phone
Going to now look at a
PC-2-PC Internet phone
example in detail
Dialpad
 Net2phone
 Phone-2-Phone
 videoconference with
Webcams

CMPT771 Transport Layer
110
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.
CMPT771 Transport Layer
111
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.
CMPT771 Transport Layer
112
Delay Jitter
variable
network
delay
(jitter)
client
reception
constant bit
rate playout
at client
buffered
data
constant bit
rate
transmission
client playout
delay
time
 Consider the end-to-end delays of two consecutive packets:
difference can be more or less than 20 msec
CMPT771 Transport Layer
113
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
CMPT771 Transport Layer
114
Fixed Playout Delay
• 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’
packets
loss
packets
generated
packets
received
playout schedule
p' - r
playout schedule
p-r
time
r
p
p'
CMPT771 Transport Layer
115
Internet Phone: Fixed Playout Delay
 Tradeoff for q:


large q: less packet loss
small q: better interactive experience
packets
loss
packets
generated
packets
received
playout schedule
p' - r
playout schedule
p-r
time
r
p
p'
CMPT771 Transport Layer
116
Adaptive Playout Delay, I
 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.
t i  timestamp of the ith packet
ri  the time packet i is received by receiver
p i  the time packet i is played at receiver
ri  t i  network delay for ith packet
d i  estimate of average network delay after receiving ith packet
Dynamic estimate of average delay at receiver:
di  (1  u)di 1  u( ri  ti )
where u is a fixed constant (e.g., u = .01).
CMPT771 Transport Layer
117
Adaptive playout delay II
Also useful to estimate the average deviation of the delay, vi :
vi  (1  u)vi 1  u | ri  ti  di |
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:
pi  ti  di  Kvi
where K is a positive constant.
Remaining packets in talkspurt are played out periodically
CMPT771 Transport Layer
118
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.
CMPT771 Transport Layer
119
How to deal with packet loss ?
 Network loss
 Delay loss
 ARQ ?
 Non-realtime
CMPT771 Transport Layer
120
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
CMPT771 Transport Layer
121
Recovery from packet loss – FEC (2)
 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
CMPT771 Transport Layer
122
Recovery from packet loss – FEC (3)
2nd FEC scheme
• “piggyback lower
quality stream”
• send lower resolution
audio stream as the
redundant information
• for example, nominal
stream PCM at 64 kbps
and redundant stream
GSM at 13 kbps.
• Whenever there is non-consecutive loss, the
receiver can conceal the loss.
• Can also append (n-1)st and (n-2)nd low-bit rate
chunk
CMPT771 Transport Layer
123
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
CMPT771 Transport Layer
124
 Q: Does Interleaving reduce error rate ?
CMPT771 Transport Layer
125
More Error Recovery (1)
 Advanced error detection and correction codes

(n, k, 2s +1) Reed Solomon Code:
k
2s
n
Based on Galois Field (GF, a finite field)
Can detect 2s errors
Can correct s errors
Generally can correct  erasures and b errors if
 + 2b  2s
 Digital fountain – Tornado code
CMPT771 Transport Layer
126
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
CMPT771 Transport Layer
127
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. RTSP/RTP/RTCP
CMPT771 Transport Layer
128
Beyond UDP: Protocol Stack for Streaming
RTSP
UDP/RTP/RTCP
CMPT771 Transport Layer
129
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
CMPT771 Transport Layer
130
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
CMPT771 Transport Layer
131
RTSP Example
Scenario:
 metafile communicated to web browser
 browser launches player
 player sets up an RTSP control connection, data connection to
streaming server
CMPT771 Transport Layer
132
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>
CMPT771 Transport Layer
133
RTSP Operation
CMPT771 Transport Layer
134
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
CMPT771 Transport Layer
135
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 “inband” channels use different
port numbers.
RTSP messages are also sent outof-band:
 RTSP control messages use
different port numbers than
the media stream: out-ofband.

Port 554
 The media stream is
considered “in-band”.
CMPT771 Transport Layer
136
RTSP vs. HTTP
 Out-of-band – in band
 Stateful - stateless
CMPT771 Transport Layer
137
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
CMPT771 Transport Layer
138
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
CMPT771 Transport Layer
139
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.
CMPT771 Transport Layer
140
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
•Payload
•Payload
•Payload
•Payload
•Payload
type 0: PCM mu-law, 64 kbps
type 3, GSM, 13 kbps
type 7, LPC, 2.4 kbps
type 26, Motion JPEG
type 31. H.261
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.
CMPT771 Transport Layer
141
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.
CMPT771 Transport Layer
142
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.
CMPT771 Transport Layer
143
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

 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
report statistics useful to
application
CMPT771 Transport Layer
144
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.
CMPT771 Transport Layer
145
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.
CMPT771 Transport Layer
146
Confused ?!
RTSP: Real-Time Streaming Protocol
RTP: Real-Time (transport) Protocol
RTCP: 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/
CMPT771 Transport Layer
147
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
CMPT771 Transport Layer
148