Internet Service Models and their implications on SLA design.

Panos GevrosUniversity 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-to-

point, 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 ...