Upload
lykhuong
View
213
Download
0
Embed Size (px)
Citation preview
© 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
http://www.ittc.ku.edu/~jpgs/courses/intronets
© James P.G. SterbenzITTC
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
© James P.G. SterbenzITTC
07 December 2017 KU EECS 780 – Intro Comm Nets – MM, TM, Sess ICN-MT-3
Multimedia ApplicationsOverview
• Multimedia applications
– involve audio and/or video
– perhaps in addition to conventional data
• Modes of operation
– streaming
– interactive
© James P.G. SterbenzITTC
07 December 2017 KU EECS 780 – Intro Comm Nets – MM, TM, Sess ICN-MT-4
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)
© James P.G. SterbenzITTC
07 December 2017 KU EECS 780 – Intro Comm Nets – MM, TM, Sess ICN-MT-5
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
© James P.G. SterbenzITTC
07 December 2017 KU EECS 780 – Intro Comm Nets – MM, TM, Sess ICN-MT-6
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
© James P.G. SterbenzITTC
07 December 2017 KU EECS 780 – Intro Comm Nets – MM, TM, Sess ICN-MT-7
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
© James P.G. SterbenzITTC
07 December 2017 KU EECS 780 – Intro Comm Nets – MM, TM, Sess ICN-MT-8
Multimedia StreamingInternet-Based Techniques
• Server
– source of media stream
• Client
– media player
• Transport
– end-to-end data transfer and control protocols
is TCP appropriate?
© James P.G. SterbenzITTC
07 December 2017 KU EECS 780 – Intro Comm Nets – MM, TM, Sess ICN-MT-9
Multimedia StreamingDelay and Jitter
• Assume CBR source
– note that some codecs are VBR
constant bit
rate video
transmission
time
© James P.G. SterbenzITTC
07 December 2017 KU EECS 780 – Intro Comm Nets – MM, TM, Sess ICN-MT-10
Multimedia StreamingDelay and Jitter
• Assume CBR source
• Network imposes jitter
why?
constant bit
rate video
transmission
time
© James P.G. SterbenzITTC
07 December 2017 KU EECS 780 – Intro Comm Nets – MM, TM, Sess ICN-MT-11
Multimedia StreamingDelay and Jitter
• Assume CBR source
• Network imposes jitter
– variable network delay
Consequences?
constant bit
rate video
transmission
time
variable
network
delay
© James P.G. SterbenzITTC
07 December 2017 KU EECS 780 – Intro Comm Nets – MM, TM, Sess ICN-MT-12
Multimedia StreamingDelay and Jitter
• Assume CBR source
• Network imposes jitter
• Received flow no longer CBR
– implication?
constant bit
rate video
transmission
time
variable
network
delay
client video
reception
© James P.G. SterbenzITTC
07 December 2017 KU EECS 780 – Intro Comm Nets – MM, TM, Sess ICN-MT-13
Multimedia StreamingDelay and Jitter
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
• Assume CBR source
• Network imposes jitter
• Received flow no longer CBR
– receiver must buffer to compensate and playback CBR
© James P.G. SterbenzITTC
07 December 2017 KU EECS 780 – Intro Comm Nets – MM, TM, Sess ICN-MT-14
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
© James P.G. SterbenzITTC
07 December 2017 KU EECS 780 – Intro Comm Nets – MM, TM, Sess ICN-MT-15
Multimedia StreamingServer Operation
• Server
– match stream rate to path bandwidth
what is this?
– match stream rate to client capabilities
what is this?
© James P.G. SterbenzITTC
07 December 2017 KU EECS 780 – Intro Comm Nets – MM, TM, Sess ICN-MT-16
Multimedia StreamingServer Operation
• Server
– match stream rate to path bandwidth
• congestion avoidance
– match stream rate to client capabilities
• flow control
© James P.G. SterbenzITTC
07 December 2017 KU EECS 780 – Intro Comm Nets – MM, TM, Sess ICN-MT-17
Multimedia StreamingClient Operation
• Client: media player
– adaptive playout to compensate for jitter
– decompression
– error concealment
– GUI (graphical user interface)
• controls for interactivity
© James P.G. SterbenzITTC
07 December 2017 KU EECS 780 – Intro Comm Nets – MM, TM, Sess ICN-MT-18
Multimedia StreamingInternet Transport
Is TCP appropriate for streaming?
© James P.G. SterbenzITTC
07 December 2017 KU EECS 780 – Intro Comm Nets – MM, TM, Sess ICN-MT-19
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
© James P.G. SterbenzITTC
07 December 2017 KU EECS 780 – Intro Comm Nets – MM, TM, Sess ICN-MT-20
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
© James P.G. SterbenzITTC
07 December 2017 KU EECS 780 – Intro Comm Nets – MM, TM, Sess ICN-MT-21
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
© James P.G. SterbenzITTC
07 December 2017 KU EECS 780 – Intro Comm Nets – MM, TM, Sess ICN-MT-22
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
© James P.G. SterbenzITTC
07 December 2017 KU EECS 780 – Intro Comm Nets – MM, TM, Sess ICN-MT-23
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.
© James P.G. SterbenzITTC
07 December 2017 KU EECS 780 – Intro Comm Nets – MM, TM, Sess ICN-MT-24
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
© James P.G. SterbenzITTC
07 December 2017 KU EECS 780 – Intro Comm Nets – MM, TM, Sess ICN-MT-25
Multimedia Streaming and TransportTraffic Management
MS.1 Multimedia applications
MS.2 Multimedia streaming and transport
MT.3 Traffic management
MT.4 Internet Service models
MS.3 Session Control
© James P.G. SterbenzITTC
07 December 2017 KU EECS 780 – Intro Comm Nets – MM, TM, Sess ICN-MT-26
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
© James P.G. SterbenzITTC
07 December 2017 KU EECS 780 – Intro Comm Nets – MM, TM, Sess ICN-MT-27
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
© James P.G. SterbenzITTC
07 December 2017 KU EECS 780 – Intro Comm Nets – MM, TM, Sess ICN-MT-28
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
© James P.G. SterbenzITTC
07 December 2017 KU EECS 780 – Intro Comm Nets – MM, TM, Sess ICN-MT-29
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
© James P.G. SterbenzITTC
07 December 2017 KU EECS 780 – Intro Comm Nets – MM, TM, Sess ICN-MT-30
Traffic CharacteristicsService Models: Best Effort
• Best effort
– no service guarantees to application
– 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
© James P.G. SterbenzITTC
07 December 2017 KU EECS 780 – Intro Comm Nets – MM, TM, Sess ICN-MT-31
Traffic CharacteristicsTraffic Parameters
Traffic parameters?
© James P.G. SterbenzITTC
07 December 2017 KU EECS 780 – Intro Comm Nets – MM, TM, Sess ICN-MT-32
Traffic CharacteristicsTraffic Parameters
• Throughput or rate
• Delay
• Jitter: delay variance
• Reliability
• Delivery order
© James P.G. SterbenzITTC
07 December 2017 KU EECS 780 – Intro Comm Nets – MM, TM, Sess ICN-MT-33
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
© James P.G. SterbenzITTC
07 December 2017 KU EECS 780 – Intro Comm Nets – MM, TM, Sess ICN-MT-34
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
© James P.G. SterbenzITTC
07 December 2017 KU EECS 780 – Intro Comm Nets – MM, TM, Sess ICN-MT-35
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
© James P.G. SterbenzITTC
07 December 2017 KU EECS 780 – Intro Comm Nets – MM, TM, Sess ICN-MT-36
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
© James P.G. SterbenzITTC
07 December 2017 KU EECS 780 – Intro Comm Nets – MM, TM, Sess ICN-MT-37
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?
© James P.G. SterbenzITTC
07 December 2017 KU EECS 780 – Intro Comm Nets – MM, TM, Sess ICN-MT-38
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
© James P.G. SterbenzITTC
07 December 2017 KU EECS 780 – Intro Comm Nets – MM, TM, Sess ICN-MT-39
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?
© James P.G. SterbenzITTC
07 December 2017 KU EECS 780 – Intro Comm Nets – MM, TM, Sess ICN-MT-40
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
© James P.G. SterbenzITTC
07 December 2017 KU EECS 780 – Intro Comm Nets – MM, TM, Sess ICN-MT-41
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?
© James P.G. SterbenzITTC
07 December 2017 KU EECS 780 – Intro Comm Nets – MM, TM, Sess ICN-MT-42
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
© James P.G. SterbenzITTC
07 December 2017 KU EECS 780 – Intro Comm Nets – MM, TM, Sess ICN-MT-43
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
© James P.G. SterbenzITTC
07 December 2017 KU EECS 780 – Intro Comm Nets – MM, TM, Sess ICN-MT-44
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
© James P.G. SterbenzITTC
07 December 2017 KU EECS 780 – Intro Comm Nets – MM, TM, Sess ICN-MT-45
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
© James P.G. SterbenzITTC
07 December 2017 KU EECS 780 – Intro Comm Nets – MM, TM, Sess ICN-MT-46
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?
© James P.G. SterbenzITTC
07 December 2017 KU EECS 780 – Intro Comm Nets – MM, TM, Sess ICN-MT-47
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
© James P.G. SterbenzITTC
07 December 2017 KU EECS 780 – Intro Comm Nets – MM, TM, Sess ICN-MT-48
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
© James P.G. SterbenzITTC
07 December 2017 KU EECS 780 – Intro Comm Nets – MM, TM, Sess ICN-MT-49
• 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
© James P.G. SterbenzITTC
07 December 2017 KU EECS 780 – Intro Comm Nets – MM, TM, Sess ICN-MT-50
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
© James P.G. SterbenzITTC
07 December 2017 KU EECS 780 – Intro Comm Nets – MM, TM, Sess ICN-MT-51
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
© James P.G. SterbenzITTC
07 December 2017 KU EECS 780 – Intro Comm Nets – MM, TM, Sess ICN-MT-52
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
© James P.G. SterbenzITTC
07 December 2017 KU EECS 780 – Intro Comm Nets – MM, TM, Sess ICN-MT-53
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
© James P.G. SterbenzITTC
07 December 2017 KU EECS 780 – Intro Comm Nets – MM, TM, Sess ICN-MT-54
Internet ECNSignalling Message Sequence
• Capability to support ECN signalled by source– ECT (ECN capable transport) bit in IP header set to 1
• IP router marks packet when congestion impending
• Receiver turns around congestion notification
• Sender acknowledges ECE received
IP IP
1
IP:ECT=1CE=0
TCP:ECE=0CWR=0
© James P.G. SterbenzITTC
07 December 2017 KU EECS 780 – Intro Comm Nets – MM, TM, Sess ICN-MT-55
Internet ECNSignalling Message Sequence
• Capability to support ECN signalled by source
• IP router passes packet unmarked if no congestion– CE (congestion experienced) bit in IP header left at 0
• Receiver turns around congestion notification
• Sender acknowledges ECE received
IP IP
2
IP:ECT=1CE=0
TCP:ECE=0CWR=0
© James P.G. SterbenzITTC
07 December 2017 KU EECS 780 – Intro Comm Nets – MM, TM, Sess ICN-MT-56
Internet ECNSignalling Message Sequence
• Capability to support ECN signalled by source
• IP router marks packet when congestion impending
– CE (congestion experienced) bit in IP header set to 1
• Receiver turns around congestion notification
• Sender acknowledges ECE received3
IP:ECT=1CE=1
TCP:ECE=0CWR=0
IP IP
© James P.G. SterbenzITTC
07 December 2017 KU EECS 780 – Intro Comm Nets – MM, TM, Sess ICN-MT-57
Internet ECNSignalling Message Sequence
• Capability to support ECN signalled by source
• IP router marks packet when congestion impending
• Receiver turns around congestion notification– ECE (ECN echo) flag in TCP ACK header set to 1
• Sender acknowledges ECE received4
IP:ECT=1CE=0
TCP:ECE=1CWR=0
IP IP
© James P.G. SterbenzITTC
07 December 2017 KU EECS 780 – Intro Comm Nets – MM, TM, Sess ICN-MT-58
Internet ECNSignalling Message Sequence
• Capability to support ECN signalled by source
• IP router marks packet when congestion impending
• Receiver turns around congestion notification
– ECE flag continues to be set in case ACKs dropped until…
• Sender acknowledges ECE received5
IP IP
IP:ECT=1CE=0
TCP:ECE=1CWR=0
© James P.G. SterbenzITTC
07 December 2017 KU EECS 780 – Intro Comm Nets – MM, TM, Sess ICN-MT-59
Internet ECNSignalling Message Sequence
• Capability to support ECN signalled by source
• IP router marks packet when congestion impending
• Receiver turns around congestion notification
• Sender acknowledges ECE received– CWR (congestion window reduced) TCP flag set to 1
6
IP IP
IP:ECT=1CE=0
TCP:ECE=0CWR=1
© James P.G. SterbenzITTC
07 December 2017 KU EECS 780 – Intro Comm Nets – MM, TM, Sess ICN-MT-60
Internet ECNSignalling Message Sequence
• Capability to support ECN signalled by source
• IP router marks packet when congestion impending
• Receiver turns around congestion notification
• Sender acknowledges ECE received
– note that if CWR packet lost it will be retransmitted 7
IP IP
IP:ECT=1CE=0
TCP:ECE=0CWR=1
© James P.G. SterbenzITTC
07 December 2017 KU EECS 780 – Intro Comm Nets – MM, TM, Sess ICN-MT-61
Internet ECNSignalling Message Sequence
• Capability to support ECN signalled by source
• IP router marks packet when congestion impending
• Receiver turns around congestion notification
• 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
© James P.G. SterbenzITTC
07 December 2017 KU EECS 780 – Intro Comm Nets – MM, TM, Sess ICN-MT-62
Multimedia Streaming and TransportInternet Service Models
MS.1 Multimedia applications
MS.2 Multimedia streaming and transport
MT.3 Traffic management
MT.4 Internet Service models
MS.5 Session Control
© James P.G. SterbenzITTC
07 December 2017 KU EECS 780 – Intro Comm Nets – MM, TM, Sess ICN-MT-63
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
© James P.G. SterbenzITTC
07 December 2017 KU EECS 780 – Intro Comm Nets – MM, TM, Sess ICN-MT-64
Quality of ServiceBest Effort with Fairness
• Best effort
– no service guarantees to application
– 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
© James P.G. SterbenzITTC
07 December 2017 KU EECS 780 – Intro Comm Nets – MM, TM, Sess ICN-MT-65
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
© James P.G. SterbenzITTC
07 December 2017 KU EECS 780 – Intro Comm Nets – MM, TM, Sess ICN-MT-66
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
TTL protocol header checksum
source address
destination address
options
(= hl – 20B)
payload
(= length – hl – 20B)
flag frag offset
© James P.G. SterbenzITTC
07 December 2017 KU EECS 780 – Intro Comm Nets – MM, TM, Sess ICN-MT-67
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)
© James P.G. SterbenzITTC
07 December 2017 KU EECS 780 – Intro Comm Nets – MM, TM, Sess ICN-MT-68
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
© James P.G. SterbenzITTC
07 December 2017 KU EECS 780 – Intro Comm Nets – MM, TM, Sess ICN-MT-70
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
© James P.G. SterbenzITTC
07 December 2017 KU EECS 780 – Intro Comm Nets – MM, TM, Sess ICN-MT-71
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]
© James P.G. SterbenzITTC
07 December 2017 KU EECS 780 – Intro Comm Nets – MM, TM, Sess ICN-MT-72
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
© James P.G. SterbenzITTC
07 December 2017 KU EECS 780 – Intro Comm Nets – MM, TM, Sess ICN-MT-73
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
© James P.G. SterbenzITTC
07 December 2017 KU EECS 780 – Intro Comm Nets – MM, TM, Sess ICN-MT-74
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
© James P.G. SterbenzITTC
07 December 2017 KU EECS 780 – Intro Comm Nets – MM, TM, Sess ICN-MT-75
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
TTL protocol header checksum
source address
destination address
options
(= hl – 20B)
payload
(= length – hl – 20B)
flag frag offset
DSCP EC
© James P.G. SterbenzITTC
07 December 2017 KU EECS 780 – Intro Comm Nets – MM, TM, Sess ICN-MT-76
Multimedia Streaming and TransportSession Control
MS.1 Multimedia applications
MS.2 Multimedia streaming and transport
MT.3 Traffic management
MT.4 Internet Service models
MS.5 Session Control
© James P.G. SterbenzITTC
07 December 2017 KU EECS 780 – Intro Comm Nets – MM, TM, Sess ICN-MT-77
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)
© James P.G. SterbenzITTC
07 December 2017 KU EECS 780 – Intro Comm Nets – MM, TM, Sess ICN-MT-78
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
© James P.G. SterbenzITTC
07 December 2017 KU EECS 780 – Intro Comm Nets – MM, TM, Sess ICN-MT-79
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
© James P.G. SterbenzITTC
07 December 2017 KU EECS 780 – Intro Comm Nets – MM, TM, Sess ICN-MT-80
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)
© James P.G. SterbenzITTC
07 December 2017 KU EECS 780 – Intro Comm Nets – MM, TM, Sess ICN-MT-81
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
© James P.G. SterbenzITTC
07 December 2017 KU EECS 780 – Intro Comm Nets – MM, TM, Sess ICN-MT-82
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
© James P.G. SterbenzITTC
07 December 2017 KU EECS 780 – Intro Comm Nets – MM, TM, Sess ICN-MT-83
Session Control ProtocolSession Termination
• Terminate session
– signal termination to all participants
– teardown all transport layer flows and connections
– release resources
– remove session state
© James P.G. SterbenzITTC
07 December 2017 KU EECS 780 – Intro Comm Nets – MM, TM, Sess ICN-MT-84
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
© James P.G. SterbenzITTC
07 December 2017 KU EECS 780 – Intro Comm Nets – MM, TM, Sess ICN-MT-85
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
© James P.G. SterbenzITTC
07 December 2017 KU EECS 780 – Intro Comm Nets – MM, TM, Sess ICN-MT-86
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
© James P.G. SterbenzITTC
07 December 2017 KU EECS 780 – Intro Comm Nets – MM, TM, Sess ICN-MT-87
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
© James P.G. SterbenzITTC
07 December 2017 KU EECS 780 – Intro Comm Nets – MM, TM, Sess ICN-MT-88
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]
© James P.G. SterbenzITTC
07 December 2017 KU EECS 780 – Intro Comm Nets – MM, TM, Sess ICN-MT-89
H.323Overview
• H.323
– ITU standard session protocol
– telephony style signalling
– integrated protocol suite for multimedia conferencing:
• signaling, registration, admission control, transport, codecs
© James P.G. SterbenzITTC
07 December 2017 KU EECS 780 – Intro Comm Nets – MM, TM, Sess ICN-MT-90
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}
© James P.G. SterbenzITTC
07 December 2017 KU EECS 780 – Intro Comm Nets – MM, TM, Sess ICN-MT-91
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}
© James P.G. SterbenzITTC
07 December 2017 KU EECS 780 – Intro Comm Nets – MM, TM, Sess ICN-MT-92
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