cs 414 - spring 2012 cs 414 – multimedia systems design lecture 18 – multimedia transport...

CS 414 - Spring 2012

CS 414 – Multimedia Systems Design Lecture 18 – Multimedia Transport Subsystem (Part 3)

Klara Nahrstedt

Spring 2012


HW1 due March 1 Midterm: MONDAY, March 5, 11-11:50 in class Midterm: 1 side of cheat-sheet + calculator Midterm Material:

MP1 Question(s) (see TA’s lecture on MP1) until Friday, February 24, Lectures 1-16 Multimedia Coding and Content Processing Book

Chapter 2, 3, 5, 7 Multimedia Systems Book

Chapter 2

Administrative

Covered Aspects of Multimedia

Image/VideoCapture

MediaServerStorage

Transmission

CompressionProcessing

Audio/VideoPresentationPlaybackAudio/Video

Perception/ Playback

Audio InformationRepresentation

Transmission

AudioCapture

A/V Playback

Image/Video InformationRepresentation

Multimedia Transmission Networks


What we will talk today Establishment Phase

Negotiation, Translation Admission, Reservation

Transmission Phase Traffic Shaping

Stream Shapes – Strongly/Weakly Regular, Strongly/Weakly Periodic, Asynchronous, Synchronous, Isochronous Streams

Isochronous Traffic Shaping – Leaky Bucket Shaping Bursty Traffic – Token Bucket

Rate Control Error Control


CLASSIFICATION, MARKING AND TRAFFIC SHAPING


Limitations of Isochronous Traffic Shaping In case of (r,T)-smooth traffic shaping, one

cannot send packet larger than r bits long, i.e., unless T is very long, the maximum packet size may be very small.

The range of behaviors is limited to fixed rate flows

Variable flows must request data rate equal to peak rate which is wasteful


Isochronous Traffic Shaping with Priorities Idea: if a flow exceeds its rate, excess packets are

given lower priority If network is heavily loaded, packets will be

preferentially dropped Decision place to assign priority

At the sender – Classification and Marking Application classifies and marks its own packets since application

knows best which packets are less important

In the network (policing) Network marks overflow packets with lower priority


Shaping Bursty Traffic Patterns (Token Bucket)


Token Bucket The effect of TB is different than Leaky Bucket (LB) Consider sending packet of size b tokens (b<β):

Token bucket is full – packet is sent and b tokens are removed from bucket

Token bucket is empty – packet must wait until b tokens drip into bucket, at which time it is sent

Bucket is partially full – let’s consider B tokens in bucket; if b ≤ B then packet is sent immediately, Else wait for remaining b-B tokens before being sent.


Comparison between TB and LBToken Bucket Simple Leaky Bucket

TB permits burstiness, but bounds it LB forces bursty traffic to smooth out

Burstiness is bounded as follows:- Flow never sends more than β+τ*ρ tokens worth of data in interval τ and - Long-term transmission rate will not exceed ρ

Flow never sends faster than ρ worth of packets per second

TB does not have discard or priority policy

LB has priority policy

TB more flexible LB is rigid

TB is easy to implement-Each flow needs counter to count tokens, - each flow needs timer to determine when to add new tokens to the counter

LB is easy to implement


Token Bucket Limitation Difficulty with policing

At any time the flow is allowed to exceed rate by number of tokens Reasoning

At any period of time, flow is allowed to exceed rate ρ by β tokens If network tries to police flows by simply measuring their traffic

over intervals of length τ, flow can cheat by sending β+τ*ρ tokens of data in every interval.

Flow can send data equal to 2β+2τ*ρ tokens in the interval 2τ and it is supposed to send at most β+2τ*ρ tokens worth of data


Token Bucket with Leaky Bucket Rate Control TB allows for long bursts and if the bursts

are of high-priority traffic, they may interfere with other high-priority traffic

Need to limit how long a token bucket sender can monopolize network


Composite Shaper


Composite Shaper Combination of token bucket with leaky bucket Good policing

But remains hard, although confirming that the flow’s data rate does not exceed C is easy

More complexity for implementation Each flow requires two counters and two timers

(one timer and one counter for each bucket)


QUEUING


Queuing and Queue Management Every traffic management needs QUEUE

MANAGEMENT (QM) Statistical versus Deterministic Guarantees Conservation of Work

QM schemes differentiate if they are work conserving or not Work conserving system – sends packet once the server has

completed service (examples – FIFO, LIFO) Non-work conserving scheme – server waits random amount

of time before serving the next packet in queue, even if packets are waiting in the queue


Rate Control

Multimedia networks use rate-based mechanisms (conventional networks use window-based flow control and FIFO)


Work-conserving schemes Non-work-conserving schemes

Fair Queuing Jitter Earliest-Due-Date

Virtual Clock Stop-and-Go

Delay Earliest-Due-Data Hierarchical Round-Robin

Earliest Due Date (EDD) [Ferrari]

Based on Earliest Deadline First Scheduling Policy

EDD works for periodic message models Packet has end-to-end deadline Di

EDD partitions end-to-end deadline Di into local deadlines Di,k during connection establishment procedure


Delay EDD

Upon arrival of Packet j of connection i:Determine effective arrival time:

aei,j = max(ae

i,j-1 + pi, ai,j)

Stamp packet with local deadline: di,j = ae

i,j + Di,k

Process packets in EDF order Delay EDD is greedy Problem with EDD: jitter


Weighted Fair Queuing


WFQ vs FQ Both in WFQ and FQ, each data flow has a separate FIFO

queue. In FQ, with a link data rate of R, at any given time the N

active data flows (the ones with non-empty queues) are serviced simultaneously, each at an average data rate of

R / N. Since each data flow has its own queue, an ill-behaved flow (who has

sent larger packets or more packets per second than the others since it became active) will only punish itself and not other sessions.

WFQ allows different sessions to have different service shares. If N data flows currently are active, with weights w1,w2...wN, data flow number i will achieve an average data rate of R * wi/(w1+w2+…+wn)


Class-based WFQ


PQ – Priority Queue

Comparison between WFQ and Jitter Control WFQ guarantees packet delay less than a given

value D, but as long as delay is within bound it does not guarantee what the delay will be

Example: send packet at time t0 over a path whose minimum delay is d WFQ guarantees that packet arrives no later than

t0+d, but packets can arrive any time t0+ x between

[t0+d, t0+D] . x is jitter


Jitter Control Non-Work-Conserving Schemes


Implementation of Stop-and-Go


Jitter-EDD Delay-EDD: does not control jitter. This has effect on buffer

requirements. Jitter-EDD is non-greedy. Jitter-EDD maintains Ahead Time ahi,j, which is the difference

between local relative deadline Di,k-1 and actual delay at switch k-1.

Ahead time is stored in packet header Upon receiving j-th packet of connection i with ahi,j at time ai,j:

Calculate ready time at switch k: ae

i,j=max(aei,j-1 + pi , ai,j)

ri,j = max(ae i,j , ai,j + ahi,j)

Stamp packet with deadline di,j=ri,j+Di,k and process according to EDF starting from ready time ri,j.


ERROR CONTROL: AVOIDANCE, DETECTION, CORRECTION


Congestion Avoidance via Random Early Drop(Active Queue Management)

RED = Random Early Drop

Refined RED based on IP packet preference is Weighted RED (WRED)

Error Detection Ability to detect the presence of errors

caused by noise or other impairments during transmission from sender to receiver Traditional mechanisms: check-summing, PDU

sequencing Checksum of a message is an arithmetic sum of message code words

of a certain word length (e.g., byte) CRC – Cyclic Redundancy Check – function that takes as input a data

stream of any length and produces as output a value (commonly a 32-bit integer) – can be used as a checksum to detect accidental alteration of data during transmission or storage

Multimedia mechanisms: byte error detection at application PDU, time detection

Design of Error Correction Codes Automatic repeat-request (ARQ)

Transmitter sends the data and also an error detection code, which the receiver uses to check for errors, and requests retransmission for erroneous data

The receiver sends ACK (acknowledgement of correctly received data)

Forward Error Correction (FEC) Transmitted encodes the data with an error-correcting

code (ECC) and sends the coded msg. No ACK exists.


Error Control Error Correction

Traditional mechanisms: retransmission using acknowledgement schemes, window-based flow control

Multimedia mechanisms: Go-back-N Retransmission Selective retransmission Partially reliable streams Forward error correction Priority channel coding Slack Automatic Repeat Request


Go-back-N Retransmission


Jitter Control in Slack Automatic Repeat Request Scheme


Conclusion Establishment Phase

Negotiation, Translation Admission, Reservation

Transmission Phase Traffic Shaping

Isochronous Traffic Shaping Shaping Bursty Traffic

Rate Control Error Control

Next: Case Studies of Multimedia Protocols


cs 414 - spring 2012 cs 414 – multimedia systems design lecture 18 – multimedia transport...

Documents

traffic shaping cs

administrative slide

wasteful cs

lower priority cs

tsmooth traffic

klara nahrstedt spring

multimedia coding

leaky bucket