protocols without qos support

ProtocolsProtocolswithout QoS Supportwithout QoS Support

20/9 - 2004

INF 5070 – Media Servers and Distribution Systems:

2004 Carsten Griwodz & Pål Halvorsen

INF5070 – media servers and distribution systems

Overview

Non-QoS protocols:

Transport level protocols

Application layer protocols

Signaling protocols



Requirements for Continuous Media

Acceptable delay

Seconds in asynchronous on-demand applications

Milliseconds in synchronous interpersonal communication

Acceptable jitter

Milliseconds at the application level

Tolerable buffer size for jitter compensation

Delay and jitter include retransmission, error-correction, ...



Requirements for Continuous Media

Acceptable continuity

Streams must be displayed in sequence

Streams must be displayed at acceptable, consistent quality

Acceptable synchronity

Intra-media: time between successive packets must be conveyed to receiver

Inter-media: different media played out at matching times



Basic Techniques Delay and jitter

Reservation (sender, receiver, network) Buffering (receiver) Scaling (sender)

Continuity Real-time packet re-ordering (receiver) Loss detection and compensation Retransmission Forward error correction Stream switching (encoding & server)

Synchronity Fate-sharing and route-sharing (networks with QoS-support) Time-stamped packets (encoding) Multiplexing (encoding, server, network) Buffering (client) Smoothing (server)



QoS vs. Non–QoS Approaches Internet without network QoS support

Internet applications must cope with networking problems Application itself or middleware "Cope with" means either …

o … “adapt to” which must deal with TCP-like service variationso … “don’t care about” which is considered “unfair” and cannot work with

TCP

Internet with network QoS support Application must specify their needs Internet infrastructure must change – negotiation of QoS

parameters Routers need more features

Keep QoS-related information Identify packets as QoS-worthy or not Treat packets differently keep routing consistent



TCP/IP Protocol stack Has only 4 layers IP is central Nothing must compete with IP at

the network layer There is no QoS support Routing is transparent for the

application Transport-unrelated functions

are application-layer tasks

Protocols for Non–QoS Approaches

Transport LayerTransport Layer

Application LayerApplication Layer

Network LayerNetwork Layer

Physical LayerPhysical LayerVarious Not a concern

No flexibility – IP is THE protocol IPv4 IPv6

Limited flexibility UDP TCP New developments

Complete freedom Compatibility is an application

issue

Traditional Transport Layer Approaches



User Datagram Protocol (UDP) Described in

Internet Engineering Note 88

Request for Comments 768 Internet Standard 6

Connection-less Unreliable Unordered Datagram-oriented Uncontrolled

Optionally checksummed

Often used in multimedia streaming applications – can build whatever needed on top

Simple add pseudo-header (UDP/IP) calculate checksum finish header send to IP

No... ... guarantees ... fairness ...



Transmission Control Protocol (TCP)

Described in Internet Engineering Note 2 Request for Comments 793 Internet Standard 7

Connection-oriented Reliable Ordered Stream-oriented Flow-controlled Checksummed

Complex compared to UDP

High fraction of today’s traffic is TCP-based, e.g., electronic mail web file transfers ...

We need to know some details about the TCP behavior/traffic we’ll briefly look at TCP ... ...retransmission timeouts ...congestion control ...friendliness



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

usually, = 0.125 [RFC 2988]

sender receiver

Initially, EstimatedRTT is based on packets sent during “handshake” operation (connection setup), e.g., 3

rou

nd

1

The following RTTs are calculated using the formula abovetaking one SampleRTT each round: - going slightly up if EstimatedRTT < SampleRTT - going slightly down if EstimatedRTT > SampleRTT - e.g. ( = 0.5 ):

2) EstimatedRTT = .5 * 3 + .5 * 3 = 3

3) EstimatedRTT = .5 * 3 + .5 * 5 = 4

4) EstimatedRTT = .5 * 4 + .5 * 1 = 2.5

RTT6543

21

time

rou

nd

2ro

un

d 3

rou

nd

4

NOTE: the next RTT isnot necessarily ready before the corresponding round starts (and we startsending the next packets)



TCP Retransmission Timeout The EstimatedRTT is used for the retransmission timer –

timeout interval should be ≥ estimatedRTT – avoiding unnecessary retransmissions but not too much larger – slow retransmit, large delay margin should be large when lot of fluctuations, otherwise small

Additionally, TCP uses RTT variation – deviated RTT: DevRTT = (1 - ) * DevRTT + * | SampleRTT – EstimatedRTT |, usually, = 0.25

Retransmission interval given byTimeoutInterval = EstimatedRTT + 4 * DevRTT

Modifications timeout interval doubling each timeout (form of congestion

control) fast retransmission – three duplicate ACKs (decrease delay)



TCP Congestion Control TCP limit sending rate as a function of

perceived network congestion little traffic – increase sending rate much traffic – reduce sending rate

Congestion algorithm has three major “components”: additive-increase, multiplicative-decrease (AIMD) slow-start reaction to timeout events



TCP Congestion Control sender receiver Initially, the CONGESTION

WINDOW is 1 MSS (message segment size)

rou

nd

1ro

un

d 2

rou

nd

3ro

un

d 4

sent packetsper round(congestion window)

time

16

8

4

2

1

Then, the size increases by 1 for each received ACK (until a threshold is reached or an ACK is missing)



TCP Congestion Control

16

8

4

2

1

Normally, the threshold is 65 K

sent packetsper round

(congestion window)

time

40

20

10

5

80

15

30

25

35

75

55

45

50

65

60

70

Losing a single packet (TCP Tahoe): threshold drops to halve CONGESTION WINDOW CONGESTION WINDOW back to 1Losing a single packet (TCP Reno): threshold drops to halve CONGESTION WINDOW CONGESTION WINDOW back to new threshold



TCP Congestion Control Alternatives

Why alternatives? Improve throughput and variance

Early TCP implementations did little to minimize network congestion

Loss indication forces setting new congestion window threshold to half of the last congestion window size

But …o … what else to conclude from the loss?o … which packets to retransmit?




Original TCP not in use

TCP Tahoe TCP Reno TCP New-Reno

standard TCP headers

TCP SACK (Selective Acknowledgements) TCP FACK (Forward Acknowledgements)

must use a TCP option RFC 2018 “TCP Selective Acknowledgment Options”



TCP Congestion Control Alternatives• TCP/IP Header Format for TCP Tahoe, Reno and New Reno

Destination AddressSource address

Time to live Protocol Header checksumIdentification DM Fragment offset

Version IHL Type of service Total lengthPRE ToS

Data

OptionsSource port Destination port

Sequence numberPiggyback acknowledgement

THL

THL – TCP header lengthU: URG – urgentA: ACK – acknowledgementP: PSH – pushR: RST – resetS: SYN – syncF: FIN – finalize

F Advertised windowSRPAUunusedChecksum Urgent pointer

IP header

TCP header



THL F Advertised windowSRPAUunused


• TCP/IP Header Format for TCP SACK and FACK

Destination AddressSource address

Time to live Protocol Header checksumIdentification DM Fragment offset

Version IHL Type of service Total lengthPRE ToS

Data

OptionsSource port Destination port

Sequence numberPiggyback acknowledgement

Checksum Urgent pointer

IP header

TCP header

5 SACK opt. len. Left edge 1st block, bits 31-16Left edge 1st block, bits 15-0Right edge 1st block, bits 31-16

Right edge 1st block, bits 15-0Left edge 2nd block, bits 31-16Left edge 2nd block, bits 15-0

Right edge last block, bits 15-0

……

5 SACK opt. len.Left edge 1st block

Right edge 1st block

Right edge last block…

Left edge: first sequence number of a block of received packet after a lostpacket

Right edge: first sequence number AFTERthat block

Only 40 bytes TCP options allowed, therefore never more than 4 blocks reported at once

Sequence number of packet that triggered ACK must be in first block unless it is in the sequence number field

Always use as many blocks as possible




Feature Original TCP

Tahoe RenoNew-Reno

SACK FACK

Retransmission strategy

Go back-n

Retransmit lost packet, continue after last sent

By SACK blk

Slow start No Yes Yes Yes Yes Yes

Congestion avoidance

No Yes Yes Yes Yes Yes

Fast retransmit

No Yes Yes Yes Yes Yes

Fast recovery

No No Yes (3 duplicate ACKs)

Stay in f. rec. No No No Yes Yes

Consider gaps

In flight packet estimation

By TCP sequence number By 1st SACK blk

Cong. window halving

Immediately Linear decrease



Simulation results

Sequence number development

0

100

200

300

400

500

600

700

800

900

1000

0 5 10 15 20Time (s)

Seq

uenc

e nu

mbe

r (s

egm

ent n

umbe

r)

TCP New Reno

SACK TCP

FACK TCP

Lossy transfer with small delays (link: 500kbps, 105ms delay):



TCP Congestion Control TCP congestion control is based on the notion

that the network is a “black box” – congestion indicated by a loss

Sufficient for best-effort applications, but losses might severely hurt traffic like audio and video streams congestion indication can enable features like

quality adaptation

Use active queue management to detect congestion



Random Early Detection (RED) Random Early Detection (discard/drop) (RED)

uses active queue management

Drops packet in an intermediate node based on average queue length exceeding a threshold TCP receiver reports loss in ACK sender applies MD

Current Internet RED restricted to packet drop as congestion indication,

but could also only indicate congestion setting

congestion experienced (CE) bit in packet header



Early Congestion Notification (ECN) Early Congestion Notification (ECN) - RFC 2481

an end-to-end congestion avoidance mechanism implemented in routers and supported by end-systems not multimedia-specific, but very TCP-specific two IP header bits used

ECT - ECN Capable Transport, set by sender CE - Congestion Experienced, may be set by router

Extends RED if packet has ECT bit set

ECN node sets CE bit TCP receiver sets ECN bit in ACK sender applies multiple decrease (AIMD)

else Act like RED



Early Congestion Notification (ECN)

Effects Congestion is not oscillating - RED & ECN ECN-packets are never lost on uncongested links Receiving an ECN mark means

TCP window decrease No packet loss No retransmission

Tail drop

RED

ECN



TCP Friendliness

RTT

wRs

max

A TCP connection’s throughput is bounded

wmax - maximum retransmission window size

RTT - round-trip time

The TCP send rate limit is

21, ww

In case of loss in an RTT:

In case of no loss:

1, ww

Congestion windows size changes

AIMD algorithm additive increase, multiple

decrease

TCP is said to be fair Streams that share a path

will reach an equal share

That’s not generally true Bigger RTT

higher loss probability per RTT slower recovery

Disadvantage for long-distance traffic



TCP Friendliness A protocol is TCP-friendly if

Colloquial: It long-term averagethroughput is not bigger than TCP’s

Formal: Its arrival rate is at mostsome constant over the square rootof the packet loss rate

Thus, if the rule is not violated …

… the AIMD algorithm with ≠ 1/2 and ≠ 1 is still TCP-friendly

… TCP-friendly protocols may probe for available bandwidth faster than TCP adapt to bandwidth changes more slowly than TCP use different equations or statistics, i.e., not AIMD not use slow start (i.e., don’t start with w=0)

CpRr P – packet loss rate

C – constant value

Rr – packet arrival rate



Comparison of Non-QoS Philosophies

Pro UDP Pro TCPScalable due to multicast Proxies, caches and reflectors

are beneficial anyway, can replace multicast

ISPs dislike multicast

Fasteronly one end-to-end delay for packet delivery

Existing optimization is for TCProuters, firewall, OS network stacks

Application controls retransmission No need to handle retransmissions

Scalable codecs are needed anyway Losslesscodecs don’t need additional loss resistance

Small buffers possibleif loss is handled gracefully

TCP-friendlinesscan be implemented (end-to-end)

variations of the algorithm possible

TCP-friendly without additional work

Works through firewalls

One-fits-all protocol possibleon-demand, quasi-broadcasting, conferencing

Most applications are on-demand



Using Standard Protocols

Over UDP Over TCPAlternative Transport

RTPReal Time Protocol

IETF std, supported by ITU-T & Industry

RTP in RTSP over TCPstandardized worst-case

fallbackfirewall-friendly

SCTPStream Control Transmission

ProtocolIETF RFC, supported by

telephone industry

RLMTCP-friendly, needs fine-

grained layered video"Progressive Download" or

"HTTP Streaming"application-level prefetching

and bufferingtrivial, cheap, firewall-friendly

DCCPDatagram Congestion Control

ProtocolIETF RFC, driven by TCP-friendliness researchers

SR-RTPTCP-friendly with RTP/UDP

needs special encoding (OpenDivX)

VDPVideo Datagram Protocol

Research, for Vosaic

Priority Progress Streamingneeds special encoding

needs special routers for ’multicast’

PRTP-ECNPartially reliable transport

protocol using ECNResearch, Univ. Karlstad

MSPMedia Streaming Protocol

Research, UIUC

RTP: An Application Layer Approach



Real-time Transport Protocol (RTP) Real-time Transport Protocol (RTP) – RFC 1889

Designed for requirements of real-time data transport NOT real-time NOT a transport protocol

Two Components: Real-Time Transport Protocol (RTP) RTP Control Protocol (RTCP)

Provides end-to-end transport functions Scalable in multicast scenarios Media independent Mixer and translator support RTCP for QoS feedback and session information



Real-time Transport Protocol (RTP) No premise on underlying

resources layered above transport

protocol no reservation / guarantees

Integrated with applications

RTP follows principles of Application Level

Framing and

Integrated Layer Processing

UDP

IPv4/6

EthernetAAL5ATM

ST-2

RTP RTCP

mediaencapsulation

application

TCP

ATM



RTP Control Protocol (RTCP) Companion protocol to RTP (tight integration with RTP)

Monitoring of QoS of application performance

Feedback to members of a group about delivery quality, loss, etc. Sources may adjust data rate Receivers can determine if QoS problems are local or network-wide

Loose session control Convey information about participants Convey information about session relationships

Automatic adjustment to overhead report frequency based on participant count

Typically, “RTP does ...” means “RTP with RTCP does ...”



RTP RTP services are:

Sequencing Synchronization Payload identification QoS feedback and session information …

RTP supports Multicast in a scalable way Mixers and translators to adapt to bandwidth limitations Generic real-time media and changing codecs on the fly Encryption

RTP is not designed for: Reliable delivery QoS provision or reservation



RTP Quality Adaptation

Component interoperations for control of quality Evaluation of sender and receiver reports Modification of encoding schemes and parameters Adaptation of transmission rates Hook for possible retransmissions (outside RTP)

Application

RTCP RTP

Decoding

Application

UDP/IP UDP/IP

RTCPRTP

Encoding



RTP Packet Format

Typical IETF RFC bit-exact representation

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |V=2|P|X| CC |M| PT | SEQ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TST | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | synchronization source (SSRC) identifier | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | contributing source (CSRC) identifiers | | .... |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| header extension |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| payload (audio, video, ...) || .... |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

a byte

a longword (32 bit)



RTP Packet Format




Header extension bitTrue if header extension is

present

Version number, always 2Padding indicator bit

if set, number of padding bytes is in last byte of payload

4 bit CSRC count, indicates the number of contributing sources in the header

Marker bitMeaning depends on payload

profile, e.g. frame boundary

7 bit payload typeAllows identification of the payload’s

content type



RTP Packet Format




16 bit sequence number(ordering and loss

detection)

Several 32 bit CSRCContribution source identifier, the number is

indicated by CCA mixer copies the original sources’ SSRCs

here

32 bit timestamp (synchronization)

32 bit SSRCSynchronization source identifier, a random

number identifying the senderHeader extension, multiples of

32 bit



RTP Packet Format Relatively long header (>40 bytes)

large overhead when carrying small payloads header compression other means to reduce bandwidth (e.g. silence

suppression)

No length field exactly one RTP packet carried in UDP packet can use TCP or ATM AAL5, if do-it-yourself packaging

Header extensions for payload specific fields possible specific codecs error recovery mechanisms



RTCP Packets

Several RTCP packets carried in one compound packet RTCP Packet Structure

SR Sender Report (statistics from active senders:bytes sent estimate rate)

RR Receiver Report (statistics from receivers)

SDES Source Descriptions (sources as “chunks” withseveral items like canonical names, email,

location,...)

BYE explicit leave

APP extensions, application specific

R SR / RR BYESDES APP

Compound (UDP) Packet



RTP Mixer

Mixes reconstructed streams into a single stream

Reconstructs constant spacing generated by sender

Resynchronizes incoming packets

New synchronization source value (SSRC) stored in packet

Incoming SSRCs are copied into the contributing synchronization source list (CSRC)

Forwards the mixed packet stream

Useful for example in conference bridges



RTP Translator

Translation between protocols e.g., between IP and ST-2 Two types of translators are installed

Translation between encoding of data e.g. for reduction of bandwidth without adapting sources

No resynchronization in translators SSRC and CSRC remain unchanged

ATM UDP

ProtocolTranslator

MPEGSource

MPEGSink

H.263Sink

ProfileTranslator



RTP Identifiers

S1 S3

S2 S4

M1 M2T1 R1

S1:10

S2:1

M1:33 (10,1)

M1:33 (10,1)

S4:13

S4:13

S3:19

M2:17 (19,13,33)

SSRC chosen by sender S1

Translators keep SSRCs and CSRCs

SSRC chosen by mixer M1

CSRCs from mixed sources S1 and S2

CSRCs contain previous SSRCs, but not previous CSRCs



Protocol Development

Changes and extensions to RTP

Scalability on very large multicast groups

Congestion Control

Algorithms to calculate RTCP packet rate

Several profile and payload formats

Efficient packetization of Audio / Video

RTCP-based retransmission

Loss / error recovery

Other Application Layer Approaches



Progressive Download In-band in long-running HTTP response

Plain file for the web server Even simpler than FTP No user interactions – start, stop, ...

If packet loss is ... ... low – rate control by back-pressure from client ... high – client’s problem

Applicability Theoretical

For very low-bit-rate codecs For very loss-intolerant codecs

Practical All low-volume web servers



Progressive Download

TCP Stack TCP Stack

Decoder

Receive buffer

Web server

Network (uncongested)

Backpressure !

Serves requested files as quickly as possible

Can recreate timing from media file

Accepts buffer underruns



Progressive Download

TCP Stack TCP Stack

Decoder

Receive buffer

Web server

Network (congested)

Retransmission

Timeout



Priority Progress Streaming Unmodified TCP (other transports conceivable) Unmodified MPEG-1 video-in (other encoding formats

conceivable)

Real-time video processing Convert MPEG to Spatially Scalable MPEG (SPEG) – 10-25%

overhead Packetize SPEG to separate by frame and by SNR quality step

More variations conceivable: color, resolution Assign priorities to SPEG packets

Dynamic utility curves indicate preference for frame or SNR dropping Write SPEG packets in real-time into reordering priority progress

queue

Queues are long Much longer than TCP max window Dynamically adjustment allows fast start and dynamic growth With longer queues

Total delay is increased High priority packets win more often



Priority Progress Streaming

Smoothing buffer

MPEG decoderViewer

TransparentOS Issues

TCP Net

bottlenecksslow TCP down

TCP

SPEG transcoderbuffer size to accountfor priority reordering& TCP backpressure

Priority Progess Queue

SPEG transcoder

MPEG file

Priority MapperTiming Generator

High priority

Medium priority

Low priorityTo TCP

Priority Progress Queue

Packets to send



Receiver-driven Layered Multicast (RLM)

Requires IP multicast layered video codec

(preferably exponential thickness)

Operation Each video layer is one IP multicast group Receivers join the base layer and extension layers If they experience loss, they drop layers (leave IP multicast

groups) To add layers, they perform “join experiments”

Advantages Receiver-only decision Congestion affects only sub-tree quality Multicast trees are pruned, sub-trees have only necessary traffic

Sender

Router

Receiver




Requires IP multicast layered video codec

(preferably exponential thickness)

Operation Each video layer is one IP multicast group Receivers join the base layer and extension layers If they experience loss, they drop layers (leave IP multicast

groups) To add layers, they perform "join experiments“

Advantages Receiver-only decision Congestion affects only sub-tree quality Multicast trees are pruned, sub-trees have only necessary traffic

Sender

Router

Receiver




Layer size considerations Adaptations are in steps of 1 layer Big layers

Join experiments have huge impact Quality changes are very visible

Small layers Many addresses are used Multicast routing effort is high Fair share is hard to achieve (don’t release bandwidth quickly

enough) Exponential layer sizes

Bad enough Best possible mix

Other problems Synchronization problems PIM-SM removes sub-trees quickly

Join and leave operations are very slow



Stream Control Transmission Protocol (SCTP)

Stream Control Transmission Protocol RFC2960, IETF Standards Track &

SCTP Unreliable Data Mode Extension (draft-ietf-tsvwg-usctp-00.txt)

Features Connection-oriented Message-oriented Reliable (with extension also: unreliable, partially reliable) Fully ordered, unordered, partially ordered delivery Multi-homed

Origin Signaling protocol for SS7 transport over IP networks Players

Motorola, Cisco, Siemens, Nortel Networks, Ericsson, Telcordia, UCLA, ACIRI




Connection Management 4-way handshake for setup Always bi-directional association (no one-way teardown) Up to 216-1 streams per direction and association Cookie exchange against man-in-the-middle attack

Association

This side is dual-homed

Streams

Association endpoints

Stream to idle destination addressOnly HEARTBEAT messages

Stream to active destinationaddress




SCTP packets Consist of one or more chunks Chunks are bundled automatically

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Source Port Number | Destination Port Number |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Verification Tag |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Checksum |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Chunk Type | Chunk Flags | Chunk Length |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\ \/ Chunk Value /\ \+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Chunks: DATA SACK INIT ABORT SHUTDOWN HEARTBEAT ERROR ECNE CWR & responses




Deadlines Applications can give deadline

for packet sending Once sent, delivery is

guaranteed (retransmission) Reliability

Sender and receiver window are computed

per stream in bytes changed per stream as in TCP

Arrival is reported by SACK chunks

SACK chunks are piggybacked contain ranges of packets

Retransmission not before 4th missing report always before new packets

Delivery Sender can specify

unordered delivery per packet

Unreliable transport – V1 Proposed extension Max. number of retransmissions

specified per stream 0 is legal

Ordered and unreliable is possible

Unreliable transport – V2 Proposed extension Sender demands ACKs

Receiver must ACK Even if packets were not

received

Unreliable, unordered, implicitly TCP-friendly transport protocol



Datagram Congestion Control Protocol (DCCP)

Datagram Congestion Control Protocol Under development http://www.ietf.org/html.charters/dccp-charter.html

Transport Protocol Offers unreliable delivery Low overhead like UDP Applications using UDP can easily change to this new protocol

Accommodates different congestion control Congestion Control IDs (CCIDs)

Add congestion control schemes on the fly Choose a congestion control scheme TCP-friendly Rate Control (TFRC) is included

Half-Connection Data Packets sent in one direction



Datagram Congestion Control Protocol (DCCP)

Congestion control is plugable One proposal is TCP-Friendly Rate Control (TFRC)

Equation-based TCP-friendly congestion control Receiver sends rate estimate and loss event history Sender uses models of SACK TCP to compute send rate

)321()83

3,1min(32

1

2ppbp

tbp

RTT

T

RTO

Steady state TCP send rate Loss

probability

Number of packets ack’d by one ACK

Retransmission timeout



Selective Retransmission-RTP (SR-RTP)

Features Relies on a layered video codec Supports selective retransmission Uses congestion control to choose number of video layers

Congestion Manager Determines the permitted send rate at the sender Uses TCP-friendly algorithm for rate computation

Knowledge about encoding Required at sender to select video layers to send Required at receiver to

decode at correct rate send NAKs




UDP Stack UDP Stack

Decoder

Smoothing buffer

MPEG-4 server

Network

SR-RTPRTCP

SR-RTPRTCP

CongestionManager

RTCP reportIncludes loss information

Forwarding to theCongestion Manager

Update allowedBandwidthfor stream

Transmission schedule ofa layered video

Retransmission demand




Binomial Congestion Control Provides a generalization of TCP AIMD

Congestion window size wt depends on losses per RTT

TCP’s AIMD: = 1, = .5, k = 0 and l = 1

k + l = 1: binomial congestion control is TCP friendly

0, kt

tRTTt www

Increase

10, ltRTTt ww

Decrease




AIMD

SQRT

SQRT Special case of binomial congestion

control k=0.5, l=0.5 Name because w0.5 = sqrt(w)

Effect of SQRT Average bandwidth is like TCP’s Maximum is lower SQRT covers a step function with

less steps

AIMD

SQRT

Signaling Protocols



Signaling Protocols Applications differ:

media delivery controlled by sender or receiver sender and receiver “meet” before media delivery

Signaling should reflect different needs media-on-demand:

receiver controlled delivery of content explicit session setup

Internet telephony and conferences: bi-directional data flow, live sources (mostly) explicit session setup, mostly persons at both ends

Internet broadcast sender announces multicast stream no explicit session setup



Real-Time Streaming Protocol (RTSP)

Internet media-on-demand select and playback streaming media from server similar to VCR, but

potentially new functionality integration with Web security varying quality

need for control protocol start, stop, pause, …

Control protocol from MPEG committee RTSP is also usable for

Near video-on-demand (multicast) Live broadcasts (multicast, restricted control

functionality) ...



RTSP Approach In line with established Internet protocols

Similar to HTTP 1.1 in style Uses URLs for addressing:

rtsp://video.server.com:8765/videos/themovie.mpg Range definitions Proxy usage Expiration dates for RTSP DESCRIBE responses Other referenced protocols from Internet (RTP, SDP)

Functional differences from HTTP Data transfer is separate from RTSP connection

typically via RTP unlike “HTTP streaming”

Server maintains state – setup and teardown messages

Server as well as clients can send requests



RTSP Features Rough synchronization

Media description in DESCRIBE response Timing description in SETUP response Fine-grained through RTP sender reports

Aggregate and separate control of streams possible

Virtual presentations Server controls timing for aggregate sessions RTSP Server may control several data (RTP) servers

Load balancing through redirect at connect time Use REDIRECT at connect time

Caching Only RTSP caching (stream state) so far Data stream caching is under discussion



RTSP Methods

OPTIONSC S

determine capabilities of server/clientC S

DESCRIBE C S get description of media stream

ANNOUNCE C S announce new session description

SETUP C S create media session

RECORD C S start media recording

PLAY C S start media delivery

PAUSE C S pause media delivery

REDIRECT C S redirection to another server

TEARDOWN C S immediate teardown

SET_PARAMETER

C S change server/client parameter

GET_PARAMETER

C S read server/client parameter



media server

RTSP Operation Integration with other real-time and multimedia

protocols

HTTPserver

RTSPserver

datasource

web browser

AVsubsystem

RTSPplug-in

HTTP GETpresentation description file

RTSP SETUPRTSP OK

RTSP PLAYRTSP OK

RTP AUDIO

RTP VIDEO

RTSP TEARDOWNRTSP OK

The End:Summary



Summary

Non-QoS protocols: Transport level protocols

UDP TCP ...

Application layer protocols RTP Priority progress streaming RLM DCCP ...

Signaling protocols RTSP

Next time, we look at protocols supporting QoS



Some References1. Charles Krasic, Jonathan Walpole, Wu-chi Feng: "Quality-Adaptive Media Streaming by Priority

Drop", 13th International Workshop on Network and Operating Systems Support for Digital Audio and Video (NOSSDAV 2003), June 2003

2. Charles Krasic, Jonathan Walpole: "Priority-Progress Streaming for Quality-Adaptive Multimedia", ACM Multimedia Doctoral Symposium, Ottawa, Canada, October 2001

3. Kurose, J.F., Ross, K.W.: “Computer Networking – A Top-Down Approach Featuring the Internet”, 2nd ed. Addison-Wesley, 2003

The RFC repository maintained by the IETF Secretariat can be found at http://www.ietf.org/rfc.htmlThe following RFCs might be interesting with respect to this lecture:

RFC 793: Transmission Control Protocol RFC 2988: Computing TCP's Retransmission Timer RFC 768: User Datagram Protocol RFC 2481: A Proposal to add Explicit Congestion Notification (ECN) to IP RFC 1889: RTP: A Transport Protocol for Real-Time Applications RFC 1890: RTP Profile for Audio and Video Conferences with Minimal Control RFC 2960: Stream Control Transmission Protocol RFC 2326: Real Time Streaming Protocol

Appendix



Partially Reliable Transport Protocol using Early Congestion Notification (PRTP-ECN)

Research Nearly TCP-friendly Receiver-only extension to TCP

Media streaming applications can accept some packet loss Media streaming applications prefer small delay and jitter

TCP

WebServer

serves files as

Net TCP

quickly as possible

prefetchbuffer

decoder

viewer

if full, stop reading(TCP backpressure)

application specifiesacceptablelevel of loss

in case of lossacknowledge receiptbut set ECN mark



Partially Reliable Transport Protocol using Early Congestion Notification (PRTP-ECN)

PRTP-ECN is nearly TCP-friendly PRTP-ECN sender applies AIMD exactly like TCP On an unloaded link

All packets arrive the receiver PRTP-ECN behaves like TCP

Some retransmissions are prevented Send window is less frequently filled More frequent claiming of the share Higher goodput (effective throughput)

Note This receiver manipulation has been used before

PRTP-ECN is its friendly use TCP-Daytona is the unfriendly use It does not set the ECN mark The result is a TCP stack for denial-of-service attacks



Session Initiation Protocol (SIP) Lightweight generic signaling protocol Internet telephony and conferencing

call: association between number of participants signaling association as signaling state at endpoints

(no network resources) several “services” needed

Name translation User location Feature negotiation Call control Changing features



SIP Basics call user re-negotiate call parameters forwarding (manual and automatic) call center supports personal mobility (change of terminal)

through proxies or redirection terminate / transfer calls ASCII (readable) protocol – SIP vs. H.323

similarities (request/response, proxies ...) differences (server state, server may initiate actions ...)

control, location and media description (via SDP) extensible towards

usage for IP-IP, POTS-IP, inter-gateway interaction with firewalls, billing system, ...

Different modes proxy mode redirect mo



SIP Operation – Proxy Mode

Proxy forwards requests possibly in parallel to several hosts cannot accept or reject call useful to hide location of callee

location server

Site A

User with

1. Invite u@domain

7. OK

“symbolic name”8. ACK u@domain

11. OK

2. W

he

re?

3. u

ser

@h

os

t

Site B

4. Invite user@host

6. OK

5. “Ring”

calls another

9. ACK user@host

10. OKProxy Mode



SIP Operation – Redirect Mode

location server

Site A

User with

1. Invite u@domain1

4. Moved temporarily

“symbolic name”

5. ACK u@domain1

2. W

her

e?

3.d

om

ain

2

calls another

Redirect Mode

Site B

6. Invite user@domain2

7. OK

7. “Ring”

8. ACK user@domain2

Location: user@domain2



SIP – Methods Basic Methods (RFC 2543):

TABLE Additional Methods (partially standardized):

INFO: carry information between User Agents REFER: ask someone to send an INVITE to another

participant SUBSCRIBE: request to be notified of specific event NOTIFY: notification of specific event

protocols without qos support

Documents

different media

distribution systemsprotocols

distribution systemsqos

qos supportrouting

network qos supportapplication

nottreat packets

successive packets

network layerthere