ITTC © James P.G. Sterbenz Introduction to Communication...

© James P.G. SterbenzITTC

07 December 2017 © 2004–2017 James P.G. Sterbenzrev. 17.1

Introduction to Communication NetworksThe University of Kansas EECS 563

Multimedia, Traffic, and Session Control

James P.G. Sterbenz

Department of Electrical Engineering & Computer Science

Information Technology & Telecommunications Research Center

The University of Kansas

[email protected]

http://www.ittc.ku.edu/~jpgs/courses/intronets


07 December 2017 KU EECS 780 – Intro Comm Nets – MM, TM, Sess ICN-MT-2

Multimedia, Traffic, Session ControlOutline

MT.1 Multimedia applications

MT.2 Multimedia streaming and transport

MT.3 Traffic management

MT.4 Internet Service models

MT.5 Session control



Multimedia ApplicationsOverview

• Multimedia applications

– involve audio and/or video

– perhaps in addition to conventional data

• Modes of operation

– streaming

– interactive



Multimedia ApplicationsStreaming

• Streaming multimedia

– media is streamed from server to client

• not download and then play

– user may have back-channel to server to control playback

• Examples

– Dailymotion, Youtube, Netflix, Hulu Lecture AL

– IPTV: television broadcast over IP

– Internet VOD (video on demand)



Multimedia ApplicationsInteractive

• Interactive multimedia

– users communicate with using audio and/or video

– peer-to-peer interaction

• E2E or shared multicast with reflector Lecture AL

– may combine with collaborative data sharing

• document sharing or shared whiteboard

• distance learning with information access



Multimedia ApplicationsInteractive Examples

• Examples

– VoIP (voice over IP) telephony and video conferencing

• e.g. skype

– shared collaboration environments

– virtual reality interactions, e.g Second Life

– multiuser games



Multimedia Streaming Stream Transfer Mode

• Various mechanisms to start stream– explicit client request

– server push

– may or may not establish connection state

• Data flow – synchronisation and control

• embedded or

• out-of-band

REQUEST

RELEASE

CONNECT

SETUP



Multimedia StreamingInternet-Based Techniques

• Server

– source of media stream

• Client

– media player

• Transport

– end-to-end data transfer and control protocols

is TCP appropriate?



Multimedia StreamingDelay and Jitter

• Assume CBR source

– note that some codecs are VBR

constant bit

rate video

transmission

time





• Network imposes jitter

why?

constant bit

rate video

transmission

time






– variable network delay

Consequences?

constant bit

rate video

transmission

time

variable

network

delay






• Received flow no longer CBR

– implication?

constant bit

rate video

transmission

time

variable

network

delay

client video

reception




constant bit

rate video

transmission

time

variable

network

delay

client video

reception constant bit

rate video

playout at client

client playout delay

buff

ere

d

vid

eo



• Received flow no longer CBR

– receiver must buffer to compensate and playback CBR



Multimedia Streaming Client Playback Buffer

• Playback buffer absorb jitter– adds delay proportional to jitter

– may also be used to reorder if misordering permitted by TP

maximum playout point

1

application

2 3 4 6

5 6 7

playout buffer

receiving end system



Multimedia StreamingServer Operation

• Server

– match stream rate to path bandwidth

what is this?

– match stream rate to client capabilities

what is this?



Multimedia StreamingServer Operation

• Server

– match stream rate to path bandwidth

• congestion avoidance

– match stream rate to client capabilities

• flow control



Multimedia StreamingClient Operation

• Client: media player

– adaptive playout to compensate for jitter

– decompression

– error concealment

– GUI (graphical user interface)

• controls for interactivity



Multimedia StreamingInternet Transport

Is TCP appropriate for streaming?



Multimedia StreamingInternet Transport

• Transport: RTP over UDP

– avoid TCP control loop delays

– avoid TCP congestion control throttling

– UDP: datagram-based transport with loss tolerance

– RTP: synchronisation added



Multimedia Streaming ControlRTSP Overview

• RTSP: real time streaming protocol [RFC 2326]

– client-server application layer protocol

• User to control of streaming

– rewind

– fast forward

– pause

– resume

– repositioning …

• Out-of-band control

– port 554



Real-Time ProtocolOverview and Transfer Mode

• RTP: real-time protocol [RFC 3550 / STD 0064]

• Streaming of data with real-time properties

– uses UDP for basic transport

• no connection establishment

• basic end-to-end multiplexing

• no reliability

• no flow or congestion control

– adds real-time support fields

• sequence number

• timestamp

• source identifiers



Real-Time ProtocolSegment Format

• Encapsulated in UDP• RTP header

– version = 02– P: padding bytes at end– X: extension header– CC: CSRC count [4b]– PT: payload type [7b]– sequence # [16b]– timestamp [32b]

• resolution app dependent

– source identifiers• SSRC• CSRC (mixed in)

destination port #source port#

length checksum

CSRC list: contributing source ids

. . .

optional padding

application payload

SSRC: synchronisation source id

timestamp

sequence #02 P X CC PT

#B pad



Real-Time ProtocolRTP Payloads

• PT: payload type– [www.iana.org/assignments/rtp-parameters]

• Payload formats and encodings

– specified in various RFCs

– audio: RFC 3551, etc.

– video: RFC 2250, etc.



Real-Time ProtocolControl Protocol Overview

• RTCP: real-time control protocol [RFC 3550 / STD 0064]

• Protocol to control and synchronise RTP streams

– monitoring quality of service to scale bandwidth

– convey participant status information

• periodically transmits RTCP control packets to others

• RTCP packet

– contains sender and/or receiver reports

– report statistics useful to application

• # packets sent, # packets lost, interarrival jitter, …

• Feedback can be used to control performance

– sender may modify transmission based on feedback



Multimedia Streaming and TransportTraffic Management

MS.1 Multimedia applications

MS.2 Multimedia streaming and transport



MS.3 Session Control



Network Layer ControlHybrid Layer/Plane Cube

Layer 3:

traffic management incontrol plane

significant interaction with management plane

Layer 4:

interacts with L3 traffic mgtphysical

MAC

link

network

transport

session

application

L1

L7

L5

L4

L3

L2

L1.5

data plane control plane

management plane

socialL8

virtual linkL2.5



Network LayerService and Interfaces

• Network layer 3 is above link layer 2

– addressing : network layer identifier for end systems (hosts)

– forwarding : transfers packets hop-by-hop

• using link layer services

• network layer responsible for determining which next hop

– routing : determination of path to forward packets

– signalling : messages to control network layer behaviour

– traffic management : actions to manage E2E service quality

• Network layer service to transport layer (L4)

– deliver TPDUs to destination transport entity



Network LayerService Model and Traffic Management

• Service model describes

– service the network provides for end-to-end data transfer

• Traffic management– actions the network takes to manage this service

• Conflicting goals

– sufficient resources to deliver required service to users

– minimise network resource use to keep costs low

• Components

– congestion control and avoidance

– resource provisioning and (perhaps) QoS



Traffic CharacteristicsService Models

• Networks provide a service model to applications

• Best effort

– no service guarantees to application

• Probabilistic guarantees

– statistical guarantees of performance parameters

• Absolute guarantees

– guarantees of performance parameters



Traffic CharacteristicsService Models: Best Effort

• Best effort


– only “best effort” attempt to eventually deliver packets

• Resource allocation

– over provisioning to provide reasonable service

– no resource allocation to individual flows

– may schedule among flows for fairness



Traffic CharacteristicsTraffic Parameters

Traffic parameters?



Traffic CharacteristicsTraffic Parameters

• Throughput or rate

• Delay

• Jitter: delay variance

• Reliability

• Delivery order



Traffic CharacteristicsThroughput or Rate

• Main parameters– peak rate rp

– average rate ra

– burstiness (peak to average ratio or max burst size)

rp

ra bursty

uniform

time



Traffic CharacteristicsJitter

• Jitter: delay variance around mean delay– dmin is the minimum path delay

– additional delay due to variable queueing and processing

de

lay d

istr

ibu

tio

n

1

0delay

no jitter low jitter high jitter

d d ddmin



Traffic CharacteristicsTraffic Classes

• The traffic class specifies the characteristics of a flow

– constant bit rate (CBR)

• specified as a single rate

– variable bit rate

• specified as (peak rate, average rate, burstiness)

– best effort

• a desired minimum rate may be specified

• Mechanisms to support traffic classes

– over-provisioning

– QoS mechanisms



Congestion ControlDefinitions

• Flow control

– control transmission to avoid overwhelming receiver

– this is a exclusively a transport layer function lecture TL

• Congestion control

– control transmission to avoid overwhelming network paths

– this is a network layer function

• that may interact with the transport or application layers



Congestion ControlIdeal Network

offered load

ideal

ca

rrie

d lo

ad

offered load

ideal

1.0

dela

y

throughput delay

• Ideal network:

– throughput: carried load = offered load (45° line)

– zero delay (flat line)

Why isn’t this possible?



Congestion ControlReal Network

• Delay can’t be zero: speed-of-light

– delay through network channels

– delay along paths in network nodes

• Throughput can’t be infinite

– channel capacity limits bandwidth

– switching rate of components limits bit rate



Congestion ControlDesired Real Network Behaviour

knee

offered load

ideal 1.0

1.0

ca

rrie

d lo

ad

offered load 1.0

dela

y knee

throughput

dmin

delay

• Desired network:

– carried load = offered load up to share of capacity

what happens to delay?



Congestion ControlConsequences of Congestion

• Delay increases– due to packet queuing in network nodes

– due to retransmissions when packets overflow buffers

• finite buffers must drop packets when full

• Throughput

– levels off gradually (with real traffic)

– then decreases

• due to retransmissions when packets dropped

• particularly over multiple hops

– congestion collapse

• “cliff” of the throughput curve



Congestion ControlCongestion Control

knee cliff

offered load

ideal 1.0

1.0

ca

rrie

d lo

ad

offered load

ideal

1.0

dela

y knee

cliff

CC

throughput

dmin

delay

CC

• Congestion control reacts to congestion

– operates at the cliff of the curve to prevent collapse

What should congestion control do?



Congestion ControlLocal Action

• Local action at point of congestion

• Drops packets: discard policy

– tail drop simplest: drop packets that overflow buffers

– more intelligent policies possible

• need flow or connection state in switches

• discriminate which flows are causing congestion and penalise



Congestion ControlEnd-to-End Action

• End-to-end action: throttle source

– reduce transmission rates

– prevent unnecessary retransmissions

• Explicit congestion control

– message to signal source to throttle

• Implicit

– sender assumes that loss is due to congestion

– source throttles with tail drop of a packet

More later



Congestion ControlPreventing Congestion Collapse

• Congestion control reacts to congestion occurring

– may be too late to avoid large-scale congestion collapse

Can we do better?consider how a network node could detect congestion



Congestion ControlCongestion Avoidance

• Congestion control reacts to congestion occurring

– may be too late to avoid large-scale congestion collapse

• Congestion avoidance attempts to prevent– measure impending congestion

– detection of increasing queue occupancy

• Important with high bandwidth--delay product

– response to an event happens after more bits transferred

– it may be too late to react

• all bits causing problem may already be transmitted

• other cause of problem may have gone away



Congestion AvoidanceCongestion Avoidance

knee cliff

offered load

ideal 1.0

1.0

ca

rrie

d lo

ad

offered load

ideal

1.0

dela

y knee

cliff

CA CC

throughput

dmin

delay

CA

CC

• Congestion avoidance predicts congestion

– operates at the knee of the curve to prevent collapse

What should congestion avoidance do?



Congestion AvoidanceGoals

• Congestion avoidance

– prevent congestion from occurring

• Keep delay low– buffer occupancy 0 in steady state

– buffering needed for

• transient conditions

• traffic bursts

• Avoid buffer bloat



Congestion AvoidanceMechanisms

• Queue threshold detects impending congestion

– less than buffer size (before tail drop)

• Implicit congestion avoidance

– drop causes TCP to throttle when ACK not received

• Explicit congestion avoidance

– signal source to throttle or adjust rate



• RED: Drop packets if threshold exceeded

– if do nothing

– if drop with probability proportional to

– if drop every packet

Implicit Congestion AvoidanceAQM: Random Early Detection

minq

maxq

maxmin q q

drop

probability

qmaxmin

maxp

1



Congestion Control & AvoidanceExplicit

• Congested node signals sender to throttle

– ECN: explicit congestion notification

• Explicit signalling message

• Congestion marking of headers in packets

– ECN in IP networks



Internet ECNSignalling Message Sequence

• Capability to support ECN signalled by source

– ECT (ECN capable transport) bit in IP header

• IP router marks packet when congestion impending

– CE (congestion experienced) bit in IP header

– FECN since packets marked; receiver must reply to source

• Receiver turns around congestion notification

– ECE (ECN echo) flag in TCP header for ACKs until…

• Sender acknowledges ECE received

– CWR (congestion window reduced) bit in TCP header

0



Internet ECNIP Packet Fields

• ECN fields

– replaces part of IPv4 TOS

– b6 – b6 – DSCP

– b6: ECT – ECN capabletransport

– b7: CE – congestionexperienced payload

(= length – hl – 20B)

04 lengthhl

fragment id

TTL protocol header checksum

source address

destination address

options

(= hl – 20B)

flag frag offset

DSC

PEC

E

C

T

C

EDSCP



Internet ECNTCP Segment Flags

• Control flags (1 bit each)– CWR cong. win. reduced

– ECE ECN echo

– URG urgent data

– ACK acknowledgement

– PSH push data

– RST reset connection

– SYN connection setup

– FIN connection teardown

checksum urg data pointer

receive window

ack number

sequence number

dest port #source port #

options (variable length)

application

payload

(variable length)

HL

32 bits

CEUAPRSF

U

R

G

A

C

K

P

S

H

R

S

T

S

Y

N

F

I

N

E

C

E

C

W

R




• Capability to support ECN signalled by source– ECT (ECN capable transport) bit in IP header set to 1




IP IP

1

IP:ECT=1CE=0

TCP:ECE=0CWR=0





• IP router passes packet unmarked if no congestion– CE (congestion experienced) bit in IP header left at 0



IP IP

2

IP:ECT=1CE=0

TCP:ECE=0CWR=0






– CE (congestion experienced) bit in IP header set to 1


• Sender acknowledges ECE received3

IP:ECT=1CE=1

TCP:ECE=0CWR=0

IP IP






• Receiver turns around congestion notification– ECE (ECN echo) flag in TCP ACK header set to 1


IP:ECT=1CE=0

TCP:ECE=1CWR=0

IP IP







– ECE flag continues to be set in case ACKs dropped until…


IP IP

IP:ECT=1CE=0

TCP:ECE=1CWR=0







• Sender acknowledges ECE received– CWR (congestion window reduced) TCP flag set to 1

6

IP IP

IP:ECT=1CE=0

TCP:ECE=0CWR=1








– note that if CWR packet lost it will be retransmitted 7

IP IP

IP:ECT=1CE=0

TCP:ECE=0CWR=1







• Sender acknowledges ECE received– on receipt receiver resets ECE to 0 in subsequent ACKs

8

IP IP

IP:ECT=1CE=0

TCP:ECE=0CWR=0



Multimedia Streaming and TransportInternet Service Models








Quality of ServiceOverview

• Quality of service (QoS or QOS)

– the service model that the network provides to applications

– along with supporting mechanisms

• Recall service models:

– best effort

• no service guarantees to application

– probabilistic guarantees

• statistical guarantees of performance parameters

– absolute guarantees

• guarantees of performance parameters



Quality of ServiceBest Effort with Fairness

• Best effort


– no QoS mechanisms necessary (traditional Internet)

• Fairness

– desirable to allow fair sharing of network

• scheduling under no congestion

• discard under impending congestion

– difficult to discriminate well-behaved and misbehaving flows

• assuming IPv4 (this is why IPv6 has a flowid flowspec)

– fair mechanisms substantially more complex to implement

• but hardware advances in the 2000s make this possible



Internet Service ModelsOverview

• Best effort

– traditional service model

– IPv4 TOS field intended for service differentiation

• Traditional best effort model is being supplemented

– new congestion control mechanisms (e.g. ECN, RED)

– fair queueing

– SLAs (service level agreements)

• supported by packet classification and MPLS underlays

• Integrated services: fine-grained per flow

• Differentiated services: coarse-grained

– coarse-grained traffic differentiation



Internet Best Effort ArchitectureIPv4 Type of Service

• TOS: type of service field– intended to give hints

– almost never used• except for routing traffic

– no enforcement mechanisms

• TOS fields– 3 msb precedence

• 0–7 = normal–high priority

– 3 flag bitsD: 0/1=normal/low delay

T: 0/1=normal/high thruput

R: 0/1=normal/high reliability

– 2 lsb unused

04 lengthhl TOS

fragment id


source address

destination address

options

(= hl – 20B)

payload


flag frag offset



Internet Best Effort ArchitectureIPv6 Traffic Class and Flow Label

• Traffic class (8b)

– differentiates traffic class

– originally 4b priority

• Flow label (20b)

– identify flows for perflow traffic management

• TM never well defined

– later assumed thatDiffServ would define

06 flow labelclass

payload length hop limitnext hdrl

source address

destination address

payload

(= payload length)



Quality of ServiceMechanisms: Guaranteed Service

• Probabilistic or absolute guarantees (strong QoS)

– guarantees of performance parameters: traffic contract

– resources reserved to meet traffic contract

• Requires

– connection or flow establishment

– admission control:only permit new flows if resources available

– traffic policing to insure sources adhere to contract

• Conflicting goals:

– sufficient resources to deliver required QoS to users

– minimise network resource use to keep costs low



Internet Service ModelsIntServ Overview

• Integrated services [RFC 1633]

– fine-grained per-flow traffic management

• Mechanisms

– resource reservations in switches/routers

• assumes per packet delay is most important quality

• soft state

– flow setup using RSVP signalling protocol

– optional traffic engineering using other mechanisms

• Per flow end-to-end traffic classes

– guaranteed service

– controlled load



Internet Service ModelsRSVP Overview

• RSVP Internet signalling protocol [RFC 2205]

• Designed for IntServ signalling [RFC 2210]

• Also adapted for other signalling purposes

– e.g. RSVP-TE for MPLS path establishment [RFC 3209]



Internet Service ModelsIntServ and RSVP Discussion

• IntServ and RSVP deployment

– none in backbones

– very limited in experimental edge networks

– needed everywhere for end-to-end service

• Concerns

– scalability of maintaining per flow state [RFC 2208]

• serious challenge in 1990s

• but feasible now given advances in hardware technology

– flexibility

• only two service classes defined

• but framework allows more



Internet Differentiated ServicesDiffServ Overview

• Differentiated services [RFC 2474, 2475, 3260]

• Reaction to IntServ and RSVP

– concerns about scalability

• Coarse-grained traffic management

– emphasis on relative performance of aggregate flows

– static provisioning rather than dynamic resource reservation

– no per flow signalling like RSVP

• No definition for end-to-end traffic classes

– rather functional components that allow service provisioning



Internet DiffServFunctional Placement

• Simple functions in network core

– PHB: per hop behaviour

– avoids significant per flow state

• Relatively complex functions at edge

– flow classification

– traffic conditioning



Internet DiffServIPv4 DSCP

• DS: diff serv field

– replaces IPv4 TOS

– 6 msb – DSCP

– 2 lsb – unallocated (ECN)

• DSCP: diff serv code point– determines PHB of packet

– default: 000000

– class selector: others

– relative treatment• 111X000 > 000000

– routing precedence

– > larger DSCP smaller

04 lengthhl

fragment id


source address

destination address

options

(= hl – 20B)

payload


flag frag offset

DSCP EC



Multimedia Streaming and TransportSession Control








SessionDefinition

• Session is association among usersor application entities

– e.g. teleconference, distance learning session, game

• Participants

– end-system users or application programs

– network-embedded resources

• e.g., transcoders, audio mixers

• Topology

– set of end-to-end transport flows

– multipoint (or point-to-point if only 2 participants)



Session ControlHybrid Layer/Plane Cube

Layer 5:

session control

incontrol plane

only

physical

MAC

link

network

transport

session

application

L1

L7

L5

L4

L3

L2

L1.5

data plane control plane

management plane

socialL8

virtual linkL2.5



Session LayerSession Control Protocol

• Session protocol

– is responsible for coordination/control of application sessions

network

application

session

transport

network

link

end system

network

link

intermediate

system

network

link

intermediate

systemnetwork

link

intermediate

system

application

session

transport

network

link

end system



Session LayerService and Interfaces

• Session layer (L5) service to application layer (L7)

– establishes and maintains sessions among users/applications

– naming and addressing : to identify and locate participants

– signalling : messages to control application sessions

– may perform routing functions among session resources

– higher layer analogue of network layer services

• Session layer uses transport layer (L4) services

– a session consists of a coördinated set of end-to-end flows*

* this is not the OSI definition,

but the layer happens to be in the right place (L5)



Session Control ProtocolSession Establishment

• Establish session: signalling

– assist in location and invitation of participants

– establish one or more transport-layer associations

• flows or connections

– discovery of needed resources

• e.g. transcoders

– routing among participants and resources

– establish session state

• distributed among participants (good scalability)

• centralised in a session controller (efficient coordination)

• combination



Session Control ProtocolSession Maintenance

• Maintain session

– adjust to dynamic session group membership

• add and removal of participants

• merge and split of sessions

– initiate and terminate transport associations as needed

– add and remove resources as needed

– update session state



Session Control ProtocolSession Termination

• Terminate session

– signal termination to all participants

– teardown all transport layer flows and connections

– release resources

– remove session state



Session Control ProtocolSignalling Flow

1. Session signalling

2. Flow setup

3. Data transfer

4. Termination

CONNECT

SESS-REQUEST

SESS-ESTABLISH

SETUP

user negotiation

user initiation

end system end system user user

session establishment

connection establishment

data transfer

network



Session Initiation ProtocolOverview

• SIP (session initiation protocol)

– IETF session protocol [RFC 3261]

• Internet style signalling

– based on HTTP-like messages

– using email-like identifiers

– SDP typically used to describe media characteristics(session description protocol) [RFC 2327]

• Single component

– works with RTP but does not mandate it



Session Initiation ProtocolAssumptions and Design Goals

• Internet-based telephone video conference calls

• Addressing

– people identified by names or “e-mail addresses”

• may or may not be an actual email addres

• Support for:

– roaming

– heterogeneous IP-based devices

• Simplicity



Session Initiation ProtocolSIP Message

INVITE sip:[email protected] SIP/2.0

Via: SIP/2.0/UDP 167.180.112.24

From: sip:[email protected]

To: sip:[email protected]

Call-ID: [email protected]

Content-Type: application/sdp

Content-Length: 885

c=IN IP4 167.180.112.24

m=audio 38060 RTP/AVP 0

• Bob’s IP address unknown

– SIP servers will resolve

• Alice specifies in Via:SIP over UDP

• SDP used for sessiondescription



Session Initiation ProtocolCall Example

• Alice’s SIP INVITE message:

– port number & IP address

– PCM preferred audio encoding

• Bob’s reply message 200 OK

– his port number & IP address

– GSM preferred audio encoding

• SIP messages

– HTTP message syntax

– sent over TCP or UDP

• here sent over RTP/UDP

– default SIP port is 5060 time time

Bob's

terminal rings

Alice

167.180.112.24

Bob

193.64.210.89

port 5060

port 38060

m Law audio

GSMport 48753

INVITE [email protected]=IN IP4 167.180.112.24m=audio 38060 RTP/AVP 0port 5060

200 OK

c=IN IP4 193.64.210.89

m=audio 48753 RTP/AVP 3

ACKport 5060

[Kurose]



H.323Overview

• H.323

– ITU standard session protocol

– telephony style signalling

– integrated protocol suite for multimedia conferencing:

• signaling, registration, admission control, transport, codecs



Multimedia, Traffic, Session ControlKey Acronyms1

VoIP voice over IP

BR bit rate

RT real-time protocol

RED random early {detection | discard}

ECN explicit congestion notification

P

SP

CP

transport

streaming

control{ { }

R

C}request

clear}



Multimedia, Traffic, Session ControlKey Acronyms2

QoS quality of service

SLA service level agreement

serv services

RSVP resource reservation protocol

SIP session initiation protocol

int

diff}integrated

differentiated}



Multimedia, Traffic, Session ControlAcknowledgements

Some material in these foils comes from the textbook supplementary materials:

• Kurose & Ross,Computer Networking:

A Top-Down Approach Featuring the Internet

• Sterbenz & Touch,High-Speed Networking:

A Systematic Approach to

High-Bandwidth Low-Latency Communication

http://hsn-book.sterbenz.org

ITTC © James P.G. Sterbenz Introduction to Communication...

Documents

Transcript of ITTC © James P.G. Sterbenz Introduction to Communication...