Status: Lecture
Page 1
File name: IP_QoS_01
Originator: A. Kassler
IP QoS issuesIP QoS issues
From IntServ to DiffServ to Adaptive QoS Mangement
Status: Lecture
Page 2
File name: IP_QoS_01
Originator: A. Kassler
AgendaAgenda
• QoS and IP networks• IntServ• DiffServ• Adaptive QoS Management
Status: Lecture
Page 3
File name: IP_QoS_01
Originator: A. Kassler
QoS enabling a NetworkQoS enabling a Network
• Goals– Improve network service perceived by applications– Give the network administrator control over network
resource usage– These are really the same
• If there were infinite network resources, QoS would not be necessary– but - there are congestion points– QoS is about deciding what traffic gets access to
resources at these points
Status: Lecture
Page 4
File name: IP_QoS_01
Originator: A. Kassler
How can this be achieved?How can this be achieved?
• Correlate packets with traffic sources– sending user, receiving user, application– classify according to common fields in packet headers
• Give certain traffic preferential access to resources at congestion points– reserve adequate capacity on transmit interfaces– bypass queues on transmit interfaces– extra buffer space in network elements
Status: Lecture
Page 5
File name: IP_QoS_01
Originator: A. Kassler
Specifying traffic: Tspec Specifying traffic: Tspec
IDEA: call must describe traffic that it will inject into net
leaky bucket proposal: traffic entering net filtered by leaky bucket regulator:
• B: maximum burst size • r: average rate • amount traffic entering over any interval of length t, less than b + rt
Status: Lecture
Page 6
File name: IP_QoS_01
Originator: A. Kassler
Token BucketToken Bucket
Possible token bucket uses: – shaping, policing, marking
• delay pkts from entering net (shaping) • drop pkts that arrive without tokens (policing
function) • let all pkts pass through, mark pkts: those
with tokens, those without • network drops pkts without tokens in time of
congestion (marking)
Status: Lecture
Page 7
File name: IP_QoS_01
Originator: A. Kassler
Traffic classesTraffic classes
• Networks should match offered service to source requirements (corresponds to utility functions)
• Example: telnet requires low bandwidth and low delay – utility increases with decrease in delay– network should provide a low-delay service– or, telnet belongs to the low-delay traffic class
• Traffic classes encompass both user requirements and network service offerings
Status: Lecture
Page 8
File name: IP_QoS_01
Originator: A. Kassler
Traffic classes - detailsTraffic classes - details
• A basic division: guaranteed service and best effort– like flying with reservation or standby
• Guaranteed-service– utility is zero unless app gets a minimum level of
service quality• bandwidth, delay, loss
– open-loop flow control with admission control– e.g. telephony, remote sensing, interactive multiplayer
games
• Best-effort– send and pray– closed-loop flow control– e.g. email, net news
Status: Lecture
Page 9
File name: IP_QoS_01
Originator: A. Kassler
GS vs. BE (cont.)GS vs. BE (cont.)
• Degree of synchrony– time scale at which peer endpoints interact– GS are typically synchronous or interactive
• interact on the timescale of a round trip time• e.g. telephone conversation or telnet
– BE are typically asynchronous or non-interactive• interact on longer time scales• e.g. Email
• Sensitivity to time and delay– GS apps are real-time
• performance depends on wall clock
– BE apps are typically indifferent to real time• automatically scale back during overload
Status: Lecture
Page 10
File name: IP_QoS_01
Originator: A. Kassler
Traffic subclasses (roadmap)Traffic subclasses (roadmap)
• ATM Forum – based on
sensitivity to bandwidth
– GS • CBR, VBR
– BE• ABR, UBR
• IETF– based on
sensitivity to delay– GS
• intolerant • tolerant
– BE• interactive burst • interactive bulk• asynchronous bulk
Status: Lecture
Page 11
File name: IP_QoS_01
Originator: A. Kassler
ATM Forum GS subclassesATM Forum GS subclasses
• Constant Bit Rate (CBR)– constant, cell-smooth traffic– mean and peak rate are the same– e.g. telephone call evenly sampled and
uncompressed– constant bandwidth, variable quality
• Variable Bit Rate (VBR)– long term average with occasional bursts– try to minimize delay– can tolerate loss and higher delays than CBR– e.g. compressed video or audio with constant
quality, variable bandwidth
Status: Lecture
Page 12
File name: IP_QoS_01
Originator: A. Kassler
ATM Forum BE subclassesATM Forum BE subclasses
• Available Bit Rate (ABR)– users get whatever is available– zero loss if network signals (in RM cells) are
obeyed– no guarantee on delay or bandwidth
• Unspecified Bit Rate (UBR)– like ABR, but no feedback– no guarantee on loss– presumably cheaper
Status: Lecture
Page 13
File name: IP_QoS_01
Originator: A. Kassler
IETF GS subclassesIETF GS subclasses
• Tolerant GS– nominal mean delay, but can tolerate “occasional” variation– not specified what this means exactly– uses controlled-load service
• controlled load: "a QoS closely approximating the QoS that same flow would receive from an unloaded network element, but uses admission control to assure that this service is received even when the network element is overloaded." even at “high loads”, admission control assures a source that its service “does not suffer”
– it really is this imprecise!
• Intolerant GS– need a worst case delay bound– equivalent to CBR+VBR in ATM Forum model
Status: Lecture
Page 14
File name: IP_QoS_01
Originator: A. Kassler
IETF BE subclassesIETF BE subclasses
• Interactive burst– bounded asynchronous service, where bound is
qualitative, but pretty tight• e.g. paging, messaging, email
• Interactive bulk– bulk, but a human is waiting for the result– e.g. FTP
• Asynchronous bulk– junk traffic– e.g netnews
Status: Lecture
Page 15
File name: IP_QoS_01
Originator: A. Kassler
Some points to ponderSome points to ponder
• The only thing out there is CBR and asynchronous bulk!
• These are application requirements. There are also organizational requirements (link sharing)
• Users needs QoS for other things too!– billing– privacy– reliability and availability
Status: Lecture
Page 16
File name: IP_QoS_01
Originator: A. Kassler
Time scalesTime scales
• Some actions are taken once per call– tell network about traffic characterization and request
resources– in ATM networks, finding a path from source to destination
• Other actions are taken during the call, every few round trip times– feedback flow control
• Still others are taken very rapidly,during the data transfer– scheduling– policing and regulation
• Traffic management mechanisms must deal with a range of traffic classes at a range of time scales
Status: Lecture
Page 17
File name: IP_QoS_01
Originator: A. Kassler
Summary of mechanisms at each Summary of mechanisms at each time scaletime scale
• Less than one round-trip-time (cell-level)– Scheduling and buffer management– Regulation and policing– Policy routing (datagram networks)
• One or more round-trip-times (burst-level)– Feedback flow control– Retransmission– Renegotiation
Status: Lecture
Page 18
File name: IP_QoS_01
Originator: A. Kassler
Summary (cont.)Summary (cont.)
• Session (call-level)– Signaling– Admission control– Service pricing– Routing (connection-oriented networks)
• Day– Peak load pricing
• Weeks or months– Capacity planning
Status: Lecture
Page 19
File name: IP_QoS_01
Originator: A. Kassler
RenegotiationRenegotiation
• An option for guaranteed-service traffic• Static descriptors don’t make sense for many
real traffic sources– interactive video
• Multiple-time-scale traffic– burst size B that lasts for time T– for zero loss, descriptors (P,0), (A, B)
• P = peak rate, A = average
– T large => serving even slightly below P leads to large buffering requirements
– one-shot descriptor is inadequate
Status: Lecture
Page 20
File name: IP_QoS_01
Originator: A. Kassler
Renegotiation (cont.)Renegotiation (cont.)
• Renegotiation matches service rate to traffic• Renegotiating service rate about once every
ten seconds is sufficient to reduce bandwidth requirement nearly to average rate– works well in conjunction with optimal
smoothing
• Fast buffer reservation is similar– each burst of data preceded by a reservation
• Renegotiation is not free– signaling overhead– call admission ?
• perhaps measurement-based admission control
Status: Lecture
Page 21
File name: IP_QoS_01
Originator: A. Kassler
SignalingSignaling
• How a source tells the network its utility function
• Two parts– how to carry the message (transport)– how to interpret it (semantics)
• Useful to separate these mechanisms• call setup protocol needed
– to perform call admission– to reserve resources at each router on end-end
path
Status: Lecture
Page 22
File name: IP_QoS_01
Originator: A. Kassler
Signaling semanticsSignaling semantics
• Classic scheme: sender initiated• SETUP, SETUP_ACK, SETUP_RESPONSE• Admission control• Tentative resource reservation and
confirmation• Simplex and duplex setup• Doesn’t work for multicast
Status: Lecture
Page 23
File name: IP_QoS_01
Originator: A. Kassler
Resource translationResource translation
• Application asks for end-to-end quality• How to translate to per-hop requirements?
– E.g. end-to-delay bound of 100 ms– What should be bound at each hop?
• Two-pass– forward: maximize (denial!)– reverse: relax– open problem!
Status: Lecture
Page 24
File name: IP_QoS_01
Originator: A. Kassler
Resource ControlResource Control
• Tasks– Admission Control Tests
at connection setup• enough capacity for new
connection• all existing connections
should keep their QoS– Reservation of resources
at connection setup– Scheduling of resources
during runtime• similar to processor
scheduling– Release of resources
Ban
dbre
ite
Zeit
Rest
Verb 2
Verb 1
maximale Netzkapazität
Status: Lecture
Page 25
File name: IP_QoS_01
Originator: A. Kassler
Link Layer: critical QoS Link Layer: critical QoS componentcomponent
Buffering and bandwidth: the scare resources • cause of loss and delay • Scheduler as example for resource controller
– packet scheduling discipline, buffer management will determine loss, delay seen by a call
– Scheduling disciplines:• FCFS • Fair Queuing (FQ) • Weighted Fair Queueing (WFQ)
Outgoing link
router
Link level packet schedulingincoming links
Status: Lecture
Page 26
File name: IP_QoS_01
Originator: A. Kassler
Scheduling: FCFSScheduling: FCFS
• FCFS (First Come First Served) oder FIFO– packets are processed according to their arrival time– buffer overflow-> packets are lost
• congestion control at the endpoints of the network necessary– in todays internet IP routers. TCP deals with congestion
control– Advantage: simple to implement– Disadvantage: No QoS guarantees, because it does not
distinguish between packet priorities• FCFS and Priorities
– several queues with different priorities– within each queue: FCFS– highest priority queue served first– no guarantees within each priority class
Status: Lecture
Page 27
File name: IP_QoS_01
Originator: A. Kassler
Scheduling: Fair QueueingScheduling: Fair Queueing
• Idea: Fairness. Each flow gets same amount of bandwidth
• Advantages: – misbehaving source does
not influence other flows
• Problems:– many queues– Insufficient algorithm: service
rate depends on packet size
• Guarantees minimal throughput
Outgoing link
Flow 1 pkts
Flow N pkts
Per Flowpacket Queues
Round-robin service: • assume fixed length pkts, N sessions • session i gets to send 1 pkt each "turn" • if session i has no pkt, i+1 gets chance
Status: Lecture
Page 28
File name: IP_QoS_01
Originator: A. Kassler
Scheduling: WFQScheduling: WFQ
• Variant of Fair Queueing:– share per bandwidth varies between flows; negotiated at
set-up– Possible implementation: (virtual clock)
• TimeStamp: each packet is associated with a timestamp that determines planed sending time
– first packet: connection setup time– other packets: increment timestamp by time difference that matches
the average negotiated bandwidth of the flow (act_Packetsize/bandwidth)
• what packets are sent first?– Inspect timestamps. Sent packets with minimum time first
– Advantage: individual bandwidth share per flow– Disadvantage: Overhead due to scheduling– WFQ guarantees minimal throughput and miximal delay
Status: Lecture
Page 29
File name: IP_QoS_01
Originator: A. Kassler
IP v 4 HeaderIP v 4 Header
• QoS in IP-Datagrams– Described by TOS-
Byte• Priority• Delay• Throughput• Reliability
– RFC 791: do not use TOS
– IPv4 can not provide QoS
4-bit version
4-bit hdrlength
8-bit type of serv.(TOS)
16-bit total length (in bytes)
16-bit identification3-bit flags
13-bit fragment offset
8-bit time to live(TTL)
8-bit protocol 16-bit header checksum
32-bit source IP address
32-bit destination IP address
Options (if any)
data
Prio DelayTP Rel CU CU
Status: Lecture
Page 30
File name: IP_QoS_01
Originator: A. Kassler
Changes to Ipv4: Changes to Ipv4: • 128 bit addresses (so we don't 128 bit addresses (so we don't
run out of IP addresses) run out of IP addresses) • header simplification (faster header simplification (faster
processing) processing) • more support for type of service more support for type of service
– priorities priorities – flow identifier: identifiy packets flow identifier: identifiy packets
in a connection in a connection
• securitysecurity Notes: Notes: • no fragmentation in network no fragmentation in network
– packet too big generates ICMP error to source packet too big generates ICMP error to source – source fragmentation via extension header source fragmentation via extension header
• no checksum (already done at transport and data link layer) no checksum (already done at transport and data link layer)
IPv6IPv6DS field (DiffServ)
Status: Lecture
Page 31
File name: IP_QoS_01
Originator: A. Kassler
AgendaAgenda
• QoS and IP networks• IntServ• DiffServ• Adaptive QoS Management
Status: Lecture
Page 32
File name: IP_QoS_01
Originator: A. Kassler
Integrated Services ModelIntegrated Services Model
Layer 3
Layer 2
RSVPIntServ
ISSLL
3 Working Groups
Status: Lecture
Page 33
File name: IP_QoS_01
Originator: A. Kassler
IntServ ArchitectureIntServ Architecture
• RSVP (Resource Reservation Protocol)– Generic Mechanisms– Dynamic, per flow– p-2-p and multicast
• IntServ (Integrated Services)– Layer 3 in each entity– classes of service for each flow
• Guaranteed• Controlled Load• Best Effort
Status: Lecture
Page 34
File name: IP_QoS_01
Originator: A. Kassler
IntServ ArchitectureIntServ Architecture
• ISSLL (Integrated Services over a Specific Link Layer)– ISSLOW (Slow Links)
• Header Compression• Priority Packets
– IS802• uses 802.1p tagging
– ISATM• ATM QoS
– If no Definition for link layer• Layer 3 packet scheduling
Status: Lecture
Page 35
File name: IP_QoS_01
Originator: A. Kassler
IntServ ArchitectureIntServ Architecture
• What IntServ does NOT:– provide packet forwarding or format specification
• still IPv4, IPv6
– routing• no QoS routing
– Admission control in the network• if not enough resources, use best effort class
Status: Lecture
Page 36
File name: IP_QoS_01
Originator: A. Kassler
Internet signaling transport: Internet signaling transport: RSVPRSVP
• Main motivation is to efficiently support multipoint multicast with resource reservations– large numbers of heterogeneous receivers – heterogeneity in available bandwidth to receiver – heterogeneity in receiver QoS demands (differing
delay requirements) • Progression
– Unicast– Naive multicast– Intelligent multicast– Naive multipoint multicast– RSVP
Status: Lecture
Page 37
File name: IP_QoS_01
Originator: A. Kassler
RSVP in shortRSVP in short
• Host-network-host Signaling Protocol– who am I? (user ID, application ID)– how can you recognize my packets? – what do I want? (service type, quantity)– what part of the network will I impact?
• Useful for any persistent traffic flows– quantitative (Intserv)– qualitative
• Admission control and topology awareness enable stricter guarantees
• Unifies other QoS mechanisms
Status: Lecture
Page 38
File name: IP_QoS_01
Originator: A. Kassler
RSVPRSVP
• When no reservation is needed, no change to internet• Receiver initiated
– scalability – heterogeneity, each receiver chooses IntServ class
• Reservation state per group, instead of per connection• PATH and RESV messages• PATH sets up next hop towards source(s)
– no reservations at this point
• RESV makes reservation• Travel as far back up as necessary
– how does receiver know of success?• DSBM: Designated Subnet Bandwidth Manager for 802 type
networks
Status: Lecture
Page 39
File name: IP_QoS_01
Originator: A. Kassler
Filters and Soft StateFilters and Soft State
• Filters – Allow receivers to separate reservations– Fixed filter
• receive from exactly one source
– Dynamic filter• dynamically choose which source is allowed to use
reservation
• Soft State– State in switch controllers (routers) is
periodically refreshed– On a link failure, automatically find another route– will go away if not "refreshed" by receivers
Status: Lecture
Page 40
File name: IP_QoS_01
Originator: A. Kassler
Sender sends Tspec out on multicast tree in PATH message
Receiver sends RESV message back up tree:
• contains senders Tspec and receiver QoS requirement (Rspec)
• routers along reverse path reserve resources needed to satisfy receiver's QoS
Call Setup in RSVPCall Setup in RSVP
Sender
Receiver 1
R4
R2
R3
R5R1
Path
RESV
Status: Lecture
Page 41
File name: IP_QoS_01
Originator: A. Kassler
RSVP: Multicast
Multiple receivers: • may have different QoS requirements • resource reservations merged as RESV travels
upstream • resources must be allocated to satisfy strictest
demands of downstream receivers – e.g.: receiver 1 first reserves resources for 100
ms max delay – if receiver 2 QoS is 200 ms max delay, no new
resources at R2, R1 – if receiver 2 QoS is 50 ms, more resources
needed at R2, R1
Status: Lecture
Page 42
File name: IP_QoS_01
Originator: A. Kassler
Multiple ReceiversMultiple Receivers
Sender
Receiver 1
R4
R2
R3
R5R1
RESVReceiver 2
RESV
RESV(merged)
Status: Lecture
Page 43
File name: IP_QoS_01
Originator: A. Kassler
Multiple SendersMultiple Senders
Can handle multiple senders as well: – different "styles" of resource reservation
• e.g., reserve enough resources in case all senders simultaneous
• resource enough resources for two simultaneous senders
• can dynamically determine which of N streams is forwarded downstream (switching within the network)
Status: Lecture
Page 44
File name: IP_QoS_01
Originator: A. Kassler
Example Data Handling & RSVP SignalingExample Data Handling & RSVP Signaling
SwitchedNetwork
(in-house)
SmallRoutedNetwor
k(ISP)
LargeRoutedNetwork(Core)
ATMNetwork
End-to-end RSVP signaling
Sender
Receiver
Status: Lecture
Page 45
File name: IP_QoS_01
Originator: A. Kassler
RSVP DrawbacksRSVP Drawbacks
• QoS guarantees– every router has to use RSVP and Resource
Reservation
• Scalability– Context per flow in each router, even if no reservation
is requested• the RESV message must follow the same path than the
PATH message• Internet Routing is asymetrical
– per packet classification in router
Status: Lecture
Page 46
File name: IP_QoS_01
Originator: A. Kassler
Renegotiation problemsRenegotiation problems
• Static descriptors don’t make sense for interactive sources or multiple-time scale traffic
• Renegotiation matches service rate to traffic• Renegotiation is not free- incurs a signaling
overhead • Open questions
– when to renegotiate?– how much to ask for?– admission control?– what to do on renegotiation failure?
Status: Lecture
Page 47
File name: IP_QoS_01
Originator: A. Kassler
AgendaAgenda
• QoS and IP networks• IntServ• DiffServ• Adaptive QoS Management
Status: Lecture
Page 48
File name: IP_QoS_01
Originator: A. Kassler
Differentiated Services ModelDifferentiated Services Model
Edge Router (Ingress)• verify conformance (shape/tag/drop)• assigns label to packet
DiffServ Cloud
Receiver
Sender• establishes TOS• can control bitrate to assure QOS
Edge Router
(Egress)
• Better than Best Effort• In-Band Signalling (Packet Header)• Complexity shifted towards Edge Router• Simple Charging (Service Level Agreement)
Status: Lecture
Page 49
File name: IP_QoS_01
Originator: A. Kassler
DiffServ in shortDiffServ in short
• Aggregate traffic handling mechanism• Defines a small number of per-hop behaviours
(PHBs) supported in routers– invoked by per-packet marking
• Concatenation of ‘hops’, with admission control, can provide useful services across the DiffServ cloud
• Very scaleable– no inherent signaling– little state required
Status: Lecture
Page 50
File name: IP_QoS_01
Originator: A. Kassler
Class-based QoS• Internet model requires per session state at each router
– 1000s - 1000000s of flows
• reluctance on part of network admins to accept
• Differentiated service model: 3+ classes– Premium service:
• high scheduling priority - aggregate peak rate allocation - low delay
– Assured service: • high buffer priority => lower loss
– Best effort service: • the usual
Status: Lecture
Page 51
File name: IP_QoS_01
Originator: A. Kassler
DiffServ classes RFC 2597, 2598DiffServ classes RFC 2597, 2598
Service class Short Name DSCP ControlledPremium Service (Expedited Forwarding) EF 101110 YesHigh Priority HP 111000 NoPriority P 100000 NoBest Effort BE 000000 NoAssured Service Class 1 Drop Prec Low AF11 001010 NoAssured Service Class 1 Drop Prec Medium AF12 001100 NoAssured Service Class 1 Drop Prec High AF13 001110 NoAssured Service Class 2 Drop Prec Low AF21 010010 NoAssured Service Class 2 Drop Prec Medium AF22 010100 NoAssured Service Class 2 Drop Prec High AF23 010110 NoAssured Service Class 3 Drop Prec Low AF31 011010 NoAssured Service Class 3 Drop Prec Medium AF32 011100 NoAssured Service Class 3 Drop Prec High AF33 011110 NoAssured Service Class 4 Drop Prec Low AF41 100010 NoAssured Service Class 4 Drop Prec Medium AF42 100100 NoAssured Service Class 4 Drop Prec High AF43 100110 No
Higher Drop Precedence dropped first
Gold
Bronze
Silver
Status: Lecture
Page 52
File name: IP_QoS_01
Originator: A. Kassler
DSCP FiledDSCP Filed
• DS field = ex-Tos Field for IPv4 (rfc 791) • Traffic Class octet for IPv6
• --> DS field both in IPv4 and IPv6 header
• DSCP : Differentiated Service Code Point = 6 bits• CU: Currently Unused = 2 bits
DSCPDSCP CUCUDS DS fieldfield
IP Precedence
Status: Lecture
Page 53
File name: IP_QoS_01
Originator: A. Kassler
Differentiated ServicesDifferentiated Services
PHB: Per Hop BehaviorPHB: Per Hop Behavior• Congestion-MgmtCongestion-Mgmt• Queuing+SchedulingQueuing+Scheduling > RED, WFQ,...> RED, WFQ,...
PHB: Per Hop BehaviorPHB: Per Hop Behavior• Congestion-MgmtCongestion-Mgmt• Queuing+SchedulingQueuing+Scheduling > RED, WFQ,...> RED, WFQ,...
CORECORECORECOREEDGEEDGEEDGEEDGE EDGEEDGEEDGEEDGE
Simple Simple TasksTasks
Simple Simple TasksTasks ComplexComplex
TasksTasksComplexComplex
TasksTasks
Traffic Traffic Classification,Classification,
Policing, Policing, ShapingShaping
Traffic Traffic Classification,Classification,
Policing, Policing, ShapingShaping
DataDSCP
Status: Lecture
Page 54
File name: IP_QoS_01
Originator: A. Kassler
DiffServ Architecture (simplified)DiffServ Architecture (simplified)
• Classifier– Behavior Aggregate (BA): only DSCP
(index into PHB table). Policy dictates configuration of PHB
– Multifield (MF), other header info (Port, Protocol, DA, SA)
• Marker– add DSCP if empty– add DSCP as mapped from RSVP-
Params– map DSCP <-> IP-TOS– change DSCP according to local policy– can apply traffic shaping
• Meter– statistics
• Conditioner– applies PHB– queue selection and
treatment– policing– packet dropping– authentication for Admission
Control
Marker
IP packetsclassifier
Meter
ConditionerBackbone
Edge
Status: Lecture
Page 55
File name: IP_QoS_01
Originator: A. Kassler
Service Level Agreement (SLA)Service Level Agreement (SLA)
• SLA– between border networks– defines traffic profile– establishes policy criteria– traffic will be policed and smoothed at egress points
according to the SLA– “out of profile” traffic at ingress point have no
guarantees
Status: Lecture
Page 56
File name: IP_QoS_01
Originator: A. Kassler
TradeOffTradeOff
• QoS mechanisms range in complexity– processing overhead– state overhead– not referring to complexity of usage here
• Generally, at a given level of complexity, the network administrator can tradeoff:– efficiency with which network resources are used– strictness (tightness) of QoS guarantees
Status: Lecture
Page 57
File name: IP_QoS_01
Originator: A. Kassler
AgendaAgenda
• QoS and IP networks• IntServ• DiffServ• Adaptive QoS Management
Status: Lecture
Page 58
File name: IP_QoS_01
Originator: A. Kassler
MotivationMotivation• Stream Tailoring as QoS enforcement
mechanism– to match different receivers QoS
req.• processing power• network connection properties
– match different receivers vis. req.• temporal domain• spatial domain• frequency domain• combinations/transcoders• error resilience (seg./re-assembly)
– influences Bandwidth– influences QoS– Different Scenarios
• VoD• Realtime Conferences
Temporal Filtering
Spatial Filtering
Frequency Filtering
Combi Filtering
Status: Lecture
Page 59
File name: IP_QoS_01
Originator: A. Kassler
QoS related TasksQoS related Tasks
• Support– quality enhanced multimedia communication using a QoS-
Framework
– Multicast scenarios
– Mobility (Session-Mobility)
– Adaptivity (Transparent vs. Adaptive)
– Heterogenity (end hosts, network characteristics
– Fairness-Policies (IETF Policy Framework)
– simple, yet powerful API (QoS-API)
– different media qualities (Videoconference vs. S-VHS)
• Use networkspezific QOS Mechanisms
• media stream adaptation in network and end hosts
• user friendly interface for QoS specification
Status: Lecture
Page 60
File name: IP_QoS_01
Originator: A. Kassler
Adaptive QoS MiddlewareAdaptive QoS Middleware
Adaptive EndsystemAdaptive Services
QoS Requirement
QoS Specification
Distributed QoS Architecture • Mobility• Adaptivity• Heterogenity
QoSMonitoring
QoS Mechanisms/Negotiation
Application
Active Netwerk, provides QoS (IntServ, DiffServ,...) and Adaptation
ProtocolLayers
NetworkSubsystem
Media Processors
Qo
S-M
ana
gem
ent
User
Application
ProtocolLayers
NetworkSubsystem
Media Processors
Qo
S-M
ana
gem
ent
User
Adaptive EndsystemAdaptive Services
Status: Lecture
Page 61
File name: IP_QoS_01
Originator: A. Kassler
QoS in mobile networks + FilteringQoS in mobile networks + Filtering
Main goal: support adaptive media streaming given soft end-to-end QoS
requirements
adaptive media filtering, media scaling and media transcoding at the end-systems and inside the net under given QoS requirements
to serve heterogeneous and moving receivers
Objectives: FAST (real-time streaming) Scalable System (support several users simultaneously) Scalable Bandwidth Adaptation (wireless + wired users) Support for broad range of adaptation mechanisms (different QoS wishes) Configurable (for different receivers and scenarios) Chainable (Filterchain) Robust (protect wireless transmission if desired)
Filters bridge Heterogenity Gap inherent to Wireless Communication
Status: Lecture
Page 62
File name: IP_QoS_01
Originator: A. Kassler
Usage ScenarioUsage Scenario
Base Station
VoD ServerRouter
1.436 mbpsfull quality
1.436 mbps full quality
F
1.182 mbps lower Quality
F78 kbps
FFF
78 kbps
36 kbps
32.2 kbps
25.2 kbps
78 kbps
78 kbps
Q
Q
Q
Q
Q
Q Q
QQoS Framework
FMedia Filter
Mobile Subnet with Wireless Proxy Server • Multimedia Adaptation Services
• Error Control (local re-transmit)• Policy-Control
Core-Net
QPolicyServer
Q
Admission Control
Q
Wireless Proxy ServerF
F
F
Top Related