Transcript QoS Networking Requirements

TAPAS EB/IAB Meeting
Cambridge, 8/7/02
• QoS Networking requirements
• WP3 D7- APIs for QoS Contaners
• WP3 D8 QoS Aware Group Communicatins Systems
• Inputs
• D5 – Architecture for Application Hosting
• D1 (Application Hosting, from Adesso)
• D2 – Specification Language for SLAs (c.f. Tequila)
DigiComm II-1
Context:Service Provisioning
• ASP is in an ISP environment.
• Classical Distributed Systems assume a LAN, a
Private WAN, or VPN, without interference from
other traffic (I.e. 100% protection).
• Expensive solution – use of public networks (e.g.
common Internet services) is lower cost and more
global. Use of VPN is an option, but an expensive
one anyhow, given current VPN provisioning…
• Contrast with Web Services and Content Service
providers…
DigiComm II-2
Web and Content Service Providers…
• Expectation of Web Services Provider is really
just storage plus best effort – basically, an ISP plus
some diskspace on some servers…not relevant
(NB Care – term “Web Services” now common
place for middleware such as SOAP and
WSDL…not same thing – they are relevant to
TAPAS of course!)/
• Goal of CSP (e.g. Akamai, Inktomi etc) is to
optimise Web Services over multiple ISPs –
useful, but still orthogonal to ASP requirements
DigiComm II-3
QoS Network Requirements
• Typical replicated database access protocols
assume a FIFO, time bounded, signaled error
network service.
• TCP doesn’t do this. Even if the IP layer does (c.f.
an EF PHB), link failure leads to lengthy timeout
before notification and recovery – TCP friendly
multicast transport doesn’t either…
• SCTP and PGM have modes that do work
appropriately for unicast and multicast
respectively
DigiComm II-4
QoS APIs
• QoS APIs for IP are basically 3 fold:
• Subscription
• Signalled
• Class based
• TCP and related transport don’t offer a direct api – but use
of socket options offers an out of band. Also, RSVP is a
possibility either from within applications, or via a proxy
with a Remote Management interface.
• QoS API Parameters are rather inefficient for multiparty
applications (lists)
DigiComm II-5
QoS Vertical Cut…
• What we really need is a novel form of identifier –
basically, we need a way to create this, togetehr with
associated resources (a VPN, with a VPNid= - perhaps a
new IP Net Number/prefix – esp. with IPv6, this is really
quite easy).
• The second thing is that exhaustive listing of QoS
parameters for all sender/revceiver pairs (n^2) seems
redundant – we want to say :
• For all tx,rx in this VPN, set protected capacity to x, delay
bound to y (or 95%ile to p) and availability
(MTBF/MTTR) to f/r…in one single call!
DigiComm II-6
QoS Assurance
• We need assurance about a VPN – we need to know there’s
no denial or theft of service (to some given confidence
limit!)
• Needs appropriate access control, auth, and secure usage
• Needs measures when things fail (SLAs include penalties –
viz reailway operator companies’ refunds!)
• Multi-path (and level 2 resilience) techniques need some
thought: Does application need to monitor alternate paths
line? Or can network transparently offer this? I think both,
subjedt to price
DigiComm II-7
QoS services and application-level
service interfaces
Review of existing technologies
DigiComm II-8
IP “service”
• IP datagram service:
• datagrams are subject to loss, delay, jitter, mis-ordering
• Performance: no guarantees
• Integrated Services:
• new QoS service-levels
• Differentiated Services:
• class of service (CoS)
• User/application may need to signal network
• User/application may need to signal other parts of
application
DigiComm II-9
Questions
• Can we do better than best-effort?
• What support do real-time flows need in the
network?
• What support can we provide in the network?
• QoS for many-to-many communication?
• Application-level interfaces?
• Signalling
DigiComm II-10
INTSERV
DigiComm II-11
Questions
• What support do we need form the network to
give QoS capability to the Transport layer?
• How can we control congestion in the network?
• How can we support legacy network protocols
over the Internet?
DigiComm II-12
Integrated services
•
Need:
1. service-levels
2. service interface –
signalling protocol
3. admission control
4. scheduling and queue
management in routers
• Scenario:
• application defines servicelevel
• tells network using
signalling
• network applies admission
control, checks if
reservation is possible
• routers allocate and control
resource in order to honour
request
DigiComm II-13
INTSERV
• http://www.ietf.org/html.charters/intserv-charter.html
• Requirements for Integrated Services based on IP
• QoS service-levels:
•
•
•
•
current service: best-effort
controlled-load service (RFC2211)
guaranteed service (RFC2212)
other services possible (RFC2215, RFC2216)
• Signalling protocol:
• RSVP (RFC2205, RFC2210)
DigiComm II-14
INTSERV service templates
• Describe service semantics
• Specifies how packets with a given service should
be treated by network elements along the path
• General set of parameters
• <service_name>.<parameter_name>
• both in the range [1, 254]
• TSpec: allowed traffic pattern
• RSpec: service request specification
DigiComm II-15
Some INTSERV definitions
• Token bucket (rate, bucket-size):
• token bucket filter: total data sent  (rt + b)
• Admission control:
• check before allowing a new reservation
• Policing:
• check TSpec is adhered to
• packet handling may change if TSpec violated (e.g.
degrade service-level, drop, mark, etc.)
• Characterisation parameters: local and composed
DigiComm II-16
Token bucket (recap)
Token bucket
• Three parameters:
data
• b: bucket size [B]
• r: bucket rate [B/s or b/s]
• p: peak rate [B/s or b/s]
tokens, rate r
• Bucket fills with tokens at
rate r, starts full
• Tokens allow transmission
• Burst allowed at rate p:
b
• data sent < rt + b
• (Also m and M)
peak rate, p
DigiComm II-17
General INTSERV parameters
• NON_IS_HOP (flag): no QoS support
• NUMBER_OF_IS_HOPS: QoS-aware hop count
• AVAILABLE_PATH_BANDWIDTH
• MINIMUM_PATH_LATENCY
• PATH_MTU
• TOKEN_BUCKET_TSPEC:
• r (rate), b (bucket size), p (peak rate)
m (minimum policed unit), M (maximum packet size)
DigiComm II-18
Controlled-load service
• Best-effort under unloaded conditions:
• probabilistic guarantee
• Invocation parameters:
• TSpec: TOKEN_BUCKET_TSPEC
• RSpec: none
• Admission control:
• Class-Based Queuing (CBQ), priority and best-effort
• Policing:
• not defined (e.g. treat as best-effort)
DigiComm II-19
Guaranteed service [1]
• Assured data rate with bounded-delay
• deterministic guarantee
• no guarantees on jitter
• Invocation parameters:
• TSpec: TOKEN_BUCKET_TSPEC
• RSpec: R (rate), S (delay slack term, s)
• Admission control:
• Weighted Fair Queuing (WFQ)
• Policing:
• drop, degrade to best-effort, reshape (delay)
DigiComm II-20
Guaranteed Service [2]
• End-to-end delay bound:
• maximum delay
• based on fluid flow model
• fluid flow model needs
error terms for IP packets
• Error terms:
• each router holds C and D
• C [B]: packet serialisation
• D [s]: transmission
through node
• Composed values:
• CSUM and DSUM
(b  M )( p  R) ( M  CSUM )

 DSUM
R( p  r )
R
( M  CSUM )
delay 
 DSUM
R pr
R
delay 
pRr
DigiComm II-21
RSVP
DigiComm II-22
INTSERV: RSVP [1]
• Provides signalling:
• user-to-network
• network-to-network
• Traffic information – FlowSpec:
• TSpec
• sent through network
• AdSpec (optional)
• Receiver confirms reservation:
• uni-directional reservation
DigiComm II-23
INTSERV: RSVP [2]
• Two-pass, with soft-state:
• sender: Path message
S
A
• NEs hold soft-state until
Resv, PathTear or time-out
• receiver(s): Resv message TSpec (+RSpec)
• sender: PathTear
• receiver(s): ResvTear
• soft-state refreshed using
Path and Resv
• Composed QoS params:
• AdSpec for path
merge
point
Path
Resv
B
DigiComm II-24
Reservation types and merging
• FilterSpec: style of
reservation
• Fixed-filter (FF):
• FilterSpec required
• distinct sender reservation
• explicit sender selection
• Wildcard-filter (WF):
• FilterSpec not required
• shared sender reservation
• wildcard sender selection
• Shared-explicit (SE):
• FilterSpec required
• shared sender reservation
• explicit sender selection
• Merging reservation info:
• merging allows aggregation
of reservation information
• merging not possible across
styles
• merging possible for
reservations of the same
style – use maximum
DigiComm II-25
Reservations about reservations
• Two-pass – one reservation may “block” another:
• PathErr and ResvErr
• Need to hold a lot of soft-state for each receiver
• Extra traffic due to soft-state refreshes
• Heterogeneity limitations:
• same service-level
• Router failure:
• QoS degrades to best-effort, need to re-negotiate QoS
• Applications and routers need to be RSVP aware:
• legacy applications
• Charging
DigiComm II-26
DIFFSERV
DigiComm II-27
DIFFSERV
• http://www.ietf.org/html.charters/diffserv-charter.html
• Differentiated services:
• tiered service-levels
• service model (RFC2475)
• simple packet markings (RFC2474)
• Packets marked by network, not by application:
• will support legacy applications
• Simpler to implement than INTSERV:
• can be introduced onto current networks
DigiComm II-28
Service Level Agreements
• Not (necessarily) per-flow:
• aggregate treatment of packets from a “source”
• Service classes:
• Premium (low delay) - EF (RFC2598)
• Assured (high data rate, low loss) - AF (RFC2597)
• Service level agreement (SLA):
• service level specification (SLS)
• policy between user and provider - policing at ingress
• service provided by network (end-system unaware)
DigiComm II-29
Scope of DIFFSERV
DIFFSERV
Internet
INTSERV
IP host
customer premises
network
customer premises
network
IP router
DigiComm II-30
DIFFSERV classification [1]
• Packet marking:
• IPv4 ToS byte or IPv6 traffic-class byte
• DS byte
• Traffic classifiers:
• multi-field (MF): DS byte + other header fields
• behaviour aggregate (BA): DS field only
• DS codepoint: values for the DS byte
• Aggregate per-hop behaviour (PHB):
• aggregate treatment within network
DigiComm II-31
DIFFSERV classification [2]
IPv4 header
0
8
16
identification
0
31
24
version hdr len type of service
time to live
IPv6 header
version
total length
flags
protocol
fragment offset
8
16
traffic
class
payload length
31
24
flow label
next
header
hop
limit
header checksum
source address
source address
destination address
destination address
DIFFSERV and ECN bits
0
1
2
3
4
DIFFSERV codepoint (DSCP)
5
6
7
ECN
DigiComm II-32
DIFFSERV PHBs
• Specify rate/delay in SLS
• Expedited Forwarding (EF) (RFC2598):
• virtual leased line (VLL) service
• data rate specified in SLS
• low delay, low jitter, low loss
• Assured Forwarding (AF) (RFC2597):
• 4 classes (1-4)
• 3 levels of drop precedence per class (1-3)
• AF11 - “best”, AF43 - “worst”
DigiComm II-33
DIFFSERV traffic conditioning
• Traffic conditioners:
• meter
• marker
• shaper/dropper
traffic conditioners
meter
• Metering of traffic:
• in-profile
• out-of profile
marker
dropper/shaper
marker
dropper/shaper
packet
classifier
meter
• Re-marking:
• new DS codepoint
• Shape/drop packets
packets
control information
DigiComm II-34
DIFFSERV service invocation
• At subscription:
• per user/user-group/site/customer
• multi-field, policy-based
• Within organisation:
• per application/user/user-group
• use ad hoc tools or network management system
• behaviour aggregate or multi-field possible
• Dynamically using RSVP: IETF work in progress
DigiComm II-35
Problems with DIFFSERV
• No standard for SLAs:
• same DS codepoints could be used for different
services by different providers
• different providers using the same PHBs may have
different behaviour
• need end-to-end/edge-to-edge semantics
• Lack of symmetry:
• protocols such as TCP (ideally) require symmetric QoS
• Multicast:
• support for multi-party, symmetric communication?
DigiComm II-36
INTSERV and DIFFSERV [1]
• Complimentary:
• DIFFSERV: aggregate, per customer/user/user-group/application
• INTSERV: per flow
• For example:
• INTSERV reservations within DIFFSERV flows (work in progress)
DIFFSERV class identified by DS codepoint
individual application
flows
using INTSERV
DigiComm II-37
INTSERV and DIFFSERV [2]
INTSERV
DIFFSERV
signalling
from application
granularity
flow
mechanism
destination address,
protocol and port
number
end-to-end
network management,
application
flow, source, site
(aggregate flows)
packet class
(other mechanisms
possible)
between networks, endto-end
scope
DigiComm II-38
Application-level signalling
DigiComm II-39
User-to-network
• Telco network:
• common channel signalling (CCS)
• separate data path and signalling path
• equipment designed to handle data and signalling
separate
• IP:
• RSVP carried in IP packets along data path
• scaling issues (RFC2208)
• need aggregated signalling towards the core (use
INTSERV with DIFFSERV?)
DigiComm II-40
User-to-user signalling
•
•
•
•
•
Call/session set-up
Capabilities exchange
Directory services
PBX-like facilities
Application-level
signalling supported by
network
• MMUSIC IETF WG:
• application architecture
• SDP
• SIP (now has its own WG)
• H.323:
• umbrella document for
existing standards
• uses ITU and IETF
standards
• currently more mature than
MMUSIC work
• wide support available (e.g.
Microsoft NetMeeting)
• IMTC:
www.imtc.org
DigiComm II-41
Summary
• Need QoS mechanisms for IP
• Per flow:
• INTSERV
• RSVP
• does not scale well, hard to provision
• Customer/provider services:
• DIFFSERV
• still maturing
• Support for application: RTP and signalling
DigiComm II-42
Scheduling, Queue Management, and
Network Calculis
• Scheduling mechanisms
• work-conserving vs. non-work-conserving
•
•
•
•
Scheduling requirements
Scheduling dimensions
Queue management
Congestion control
DigiComm II-43
Network Calculus
• Take fair service curve familiy of schedulers, plus
leaky bucket or TCP constrained sources, and
derive bounds on queues, and other properties.
• Not necessarily directly useable for Multi-source
traffic, (correlated sources) but we can try.
• Not obvious for real world (utilisation for typical
schedulers is around 5% (actually 1/max hop
count, which given hops are up to 20, is 5%).
DigiComm II-44
Net Calc
• Having said that, we should try to derive a model
for replicated service (a la Padhye) and then see if
we can work out a solution
• Alternative might be to derive fixed point solution
(c.f. Gibbens work) – might be possible too…
• Goal is to get delay distribution or bound, given
load and provisioned capacity and queue
management/.scheduler (or in extreme, just
FIFO!)
DigiComm II-45
Routing for Integrated Services
DigiComm II-46
New routing requirements
• Multiparty communication:
•
•
•
•
•
•
•
conferencing (audio, video, whiteboard)
remote teaching
multi-user games
networked entertainment – “live broadcasts”
(distributed simulations)
(software distribution)
(news distribution)
• Support for QoS in routing
• Support for Multi-path for high avaialbility
DigiComm II-47
Questions
• How can we support multiparty communication?
• How can we provide QoS support in routing?
DigiComm II-48
Many-to-many communication:
IP multicast
DigiComm II-49
Group communication using IP
• Many-to-many:
• many senders and receivers
• host group or multicast
group
• One transmission, many
receivers
• Optimise transmissions:
• e.g. reduce duplication
• Class D IP address:
• 224.0.0.0 - 239.255.255.255
• not a single host interface
• some addresses reserved
• Applications:
•
•
•
•
•
conferencing
software update/distribution
news distribution
mutli-player games
distributed simulations
• Network support:
• LAN
• WAN (Internet routers)
• scoped transmission: IP
TTL header field
DigiComm II-50
IP multicast and IGMP
• Features of IP multicast:
• group of hosts
• Class D address
• leaf nodes (hosts) and
intermediate nodes (routers)
• dynamic membership, leafinitiated join
• non-group member can
A
send to group
• multicast capable routers
• local delivery mechanism B
network
The multicast capable router listens in
multicast promiscuous mode so that it can
pick up all mulitcast packets for relay off
the LAN if required.
C has sent report with destination address
X so if A and B want to become members,
the do not need to send an IGMPREPORT
• IGMP: group membership
control
C
C wishes to join group X, so sends
IGMPREPORT (after random timeout)
periodic IGMPQUERY
from router
DigiComm II-51
QoS-based routing
DigiComm II-52
What is QoS-based routing?
• Traditional routing:
• destination address chooses path/route
• routers have one “optimal” path to destination
• routing metrics are single values
• QoS routing:
•
•
•
•
multiple paths possible
alternative paths have different QoS properties
routing updates include QoS parameter information
use destination address, source address, ToS, etc.
• RSVP/INTSERV/DIFFSERV:
• signalling may still be required
DigiComm II-53
IPv4 ToS byte
• IPv4 header – ToS byte:
• 3-bit precedence, P
• 4-bit ToS
• Precedence:
• 000: lowest
• 111: highest
• ToS – flags:
•
•
•
•
•
1xxx: minimise delay
x1xx: maximise throughput
xx1x: maximise reliability
xxx1: minimise cost (£)
0000: “normal” service
0
3
7
15
31
VER IHL ToS byte
0
2
P
Total length
6 7
ToS
0
• Not widely used:
• no global agreement
• (some use in Intranets)
• RFC1349 – now historic:
• superseded by DIFFSERV
• not compatible with ECN
DigiComm II-54
Multi-metric routing
• Use multiple metrics:
•
•
•
•
minimum delay path
maximum throughput path
maximum reliability path
minimum cost path
• Example – OSPF:
• QoS parameters passed in
link-state packets
• ToS byte used in IPv4
• multiple executions of
shortest-path algorithm
• Sequential filtering:
• filter paths using metrics
• Granularity of QoS:
• can be per-flow, but
requires much state in
routers
• Router overhead:
•
•
•
•
more per packet processing
larger router updates
more state at routers
possibility of instability
during routing updates
DigiComm II-55
Route pinning and path pinning
• Dynamic routing:
• path change  QoS change
• Keep route fixed for flow?
Route pinning
• Ensure that route is fixed
while packet forwarding
in progress
• Disrupts normal routing
behaviour
• May cause congestion
conditions
Path pinning
• Allow route to change:
• existing flows remain on
fixed path
• new flows use new route
• Allow different paths for
different flows:
• pin separate flows to
separate paths
• Inconsistency:
• could affect stability if flow
is long lived
• (Use of RSVP?)
DigiComm II-56
Intra-domain routing
•
•
•
•
Can use agreed single/multiple metrics
Allow autonomy in domains to remain
Should indicate disruptions to QoS along a path
Must accommodate best-effort traffic:
• no modification to existing, best-effort applications
• Optionally support multicast:
• allow receiver heterogeneity and shared reservations
• Still a research issue
DigiComm II-57
Inter-domain
• Must be scaleable
• QoS-routing should not be highly dynamic:
• few router updates, relatively small amounts of
information
• may have to rely on traffic engineering and capacity
planning
• Must not constrain intra-domain routing
mechanisms
• Allow QoS information aggregation
• Optionally support multicast
DigiComm II-58
QoS-based routing for multicast
• Reliable multicast:
• retransmissions from sender does not scale
• research issue
• QoS for multicast:
•
•
•
•
•
•
need to support widely/sparsely dispersed groups
dynamic membership changes
must scale across domains (across AS boundaries)
should allow heterogeneity in group
support for shared reservations
research issue
DigiComm II-59
Multipath
• Can use OSPF-ECM or OMP,
• Can have very fast convergence (e.g. using
incremental OSPF or similar)
• Other types of multihoming involve modified
application (application layer pinging, or DNS
rotaries and redirect and NAT)
• We need to do some thinking… … …
DigiComm II-60
Summary
• Many-to-many communication:
• IP multicast
• DVMRP, MOSPF, CBT, PIM
• conferencing example
• QoS-based routing:
•
•
•
•
multi-metric
route/path pinning
intra-domain and inter-domain
QoS-based routing for multicast
DigiComm II-61
Overall Summary TAPAS Net QoS Req
• Want QoS assurance
• QoS includes multiparty, as part of source model,
and high availaibility as part of QoS parameters…
• Would like t ostay independent of network details,
but do want to have mathematically derived proofs
for some cases as exemplars.
• Want a revised QoS API (both simpler and more
powerful!)
• Questions?
DigiComm II-62