Transcript Internet Service Models and their implications on SLA design

Internet Service Models and their
implications on SLA design.
Panos Gevros
University of Cambridge
TAPAS Project Meeting
Newcastle 5/9/02
Goal
– Provide a brief overview of
• what the capabilities/limitations of the current Internet
infrastructure/service are
• what applications/middleware engineering should expect
from a network provider
• the ongoing research work in new resource management
models for the Internet
• a potential overlap of the work on network SLAs with the
concept of contract from other fields (economics/finance).
Outline
– Network Service (why the ability to differentiate is
relevant SLAs).
– Current Best Effort Service
– Integrated Services
– Differentiated Services
– Open Issues with DiffServ
• SLAs
• composition of end-to-end services
• multicast
– Research in new resource management models.
Network Service (1)
– Network SLAs imply ability to offer different levels
(classes) of network service (performance being
the differentiating factor).
– We intend to investigate QoS and service
differentiation mechanisms/models and identify
their effect on the design of SLAs.
• Review of standard Service Models (ietf)
• Look for new Service Models (research).
– A viable service model for the Internet which
incorporates Classes of Service is still an open
research issue.
Network Service (2)
– Demand for network service = demand for data
transmission.
– Elementary form of “user” at the network level is
the flow: a directional stream of packets between
two communicating endpoints (fields in the packet
headers: src_addr, src_port, dest_addr, dest_port,
protocol_id).
– At a higher level “users” may be human end-users
or organisations (ISPs)
– still associated with flows.
Best Effort Internet Service (1)
– loose service description.
– unreliable datagram service,
– lack of performance guarantees (packets can be
delayed, misordered, lost).
– adaptive mechanisms are used (in the transport
protocols) for regulating access to network
resources (bandwidth).
– Universally deployed TCP congestion avoidance
and control paradigm
– restrict the scope in which interacting networking
entities can achieve performance goals.
Best Effort Internet Service (2)
– Goal:
• accommodate multiple QoS requirements,
• offer performance guarantees or
• a more concrete service description.
– Can we do better than Best Effort
• Integrated Services (intserv)
• Differentiated Services (diffserv).
– The scope of interaction is still restricted.
IntServ Concepts (1)
– An application (source) requests specific service
(explicit signaling, RSVP) before sending data,
informing the network of its traffic profile (Rspec).
– The network
• does admission control test (available resources request size + administrative restrictions)
• if successful reserves resources to meet application
requirements as long as the source traffic remains within
each profile.
– The signaling protocol (RSVP), the reservation
mechanisms and the underlying routing protocols
are all orthogonal.
IntServ Concepts (2)
– Needs per-flow state in the routers.
– Reservations are unidirectional.
– Scales well with multicast (receiver-driven
reservations)
– Does not scale well with large number of flows.
– Comes in two flavours :
• Controlled Load ( RFC2211, best effort in a lightly utilised
network).
• Guaranteed Service (RFC2212, guaranteed bandwidth
and bounded delay).
– http://www.ietf.org/html.charters/intserv-charter.html
DiffServ Concepts (1)
– Push state complexity to the edges of the network
keep packet handling in the core simple (improved
scalability over IntServ).
– Focus mainly on packet-level behavior and the
definition of building blocks and not on the services
that can be composed.
– The building blocks used in a service description
are:
• Per Hop Behaviours (PHBs) (description of packet
treatment and are independent from implementation
mechanism).
• Classification, Metering, Marking, Shaping, Dropping
(description of traffic conditioning).
DiffServ Concepts (2)
– DiffServ is described in RFC2475
– Five PHBs have been defined
• EF Expedited Forwarding (low delay) RFC2598.
• AF1 … AF4 Assured Forwarding (low loss) RFC2597.
– http://www.ietf.org/html.charters/diffserv-charter.html
Open Issues with DiffServ models
– The standardisation of SLAs.
– The feasibility of offering a consistent service
across interconnected networks (“end-to-end”
service).
– Multicast poses some interesting challenges in a
Diffserv environment.
Service Level Agreements (1)
– An SLA is usually a bilateral agreement - a contract
between a service provider and a customer which
specifies the services and their performance (using
some QoS metric).
– QoS metrics (defined for a link or a path):
• bandwidth
• loss rate,
• delay (and possibly jitter)
– The metrics should be precisely defined (units,
measurement methods etc.)
Service Level Agreements (2)
– The technical part of the SLA is the so called
Service Level Specification (SLS).
– The SLS parameters involve:
• Topological Scope (between which domains, point-topoint, point-to-multipoint)
• Flow descriptor (unique identification of the packet stream
covered by the SLA)
• Traffic descriptor (traffic envelope, in/out of profile
packets, e.g token bucket shaper)
• excess treatment (Remark? Reshape? Drop?)
• service schedule (time of day)
• service availability (Maximum downtime - is a popular
metric defined pcm, pa).
Composing end-to-end services (1)
– In DiffServ it is not a requirement for an application
to signal the network before sending data.
– However in order to provide an end-to-end service
all the domains along a path must cooperate.
– A domain is usually represented by a Bandwidth
Broker (BB) which receives resource allocation
requests from entities inside it and/or BBs on
neighboring domains.
– The BB changes the router configuration of the
edge or the core routers of its domain as a
response to the requests it receives.
Composing end-to-end services (2)
– Premium Service is a popular service based on
the EF PHB (point-to-point, low latency, zero loss, at a
specified transfer rate with any excess being discarded,
useful e.g for IP-telephony)
– The QBone Design Team of the Internet2 initiative
attempted to offer the Qbone Premium Service
(QBPS) on Internet2.
– The effort was “indefinitely postponed due to
technical difficulties” ...
– Not a very good sign for DiffServ deployment
DiffServ and multicast (1)
– Problems:
• Difficulty in predicting network resource requirements
(single ingress multiple egress nodes)
• Dynamic group membership becomes problematic.
• With multicast packet replication all packets get the
same DS codepoint (multicast replication is part of the
forwarding process).
• Group Heterogeneity with respect to the QoS
requirements of the group members. (Ideally members
with more modest QoS requirements should be able to
participate in groups where other participants use better
service classes - problematic for charging).
DiffServ and multicast (2)
– Three approaches:
• Edge + Core routers both are multicast-capable - on
join/leave all the routers update their state (“zero state” in
the core routers? may be justifiable for very few multicast
flows)
• Only Edge routers are multicast-capable - the same
packet may cross the same link more than once
(depending on the number of from-ingress-to-egress
paths the link belongs to). May be o.k. for sparse groups
(packet replication in the core is unusual).
• Encapsulation-based - the tree structure is
encapsulated in the packet, the core routers do not
require per-group state but they should know how to
interpret the embedded information in the packet header.
Research in new service models(1)
– Service Differentiation based on end-point
adaptation possibly assisted by feedback
mechanisms in the routers (ECN).
– Theoretical work by Kelly et al.
– Work for the Internet paradigm work by Crowcroft
et al (MulTCP).
– Dynamic allocation and pricing of bandwidth at the
edges of a Diffserv domain (bandwidth auctions
and peering agreements work by Semret, Lazaar
et al Columbia).
Research in new service models (2)
– Try to simplify SLA for the User-Provider interface
ideally with end-to-end semantics (parametrised
transport protocols with statistical guarantees).
• capacity of the access line
• “aggressiveness” of the transport behaviour.
– Provider-Provider SLAs through peering
arrangements (taking into account the different
transport behaviours).
– Investigate the potential of Relative Service
Differentiation.
– Investigate the issue of value associated with a
given contract.
Research in new service models (3)
– View an SLA not as a reservation but as a potential
for allowing reservations.
– An analogy comes from the world of financial
contracts, options, futures etc. (e.g a “call” option
gives the owner the right -not the obligation- to
buy a certain quantity of the underlying asset shares of stock- at given time and price,
potentially realising a profit).
– There is a huge body of work on structuring and
pricing option contracts ...