Applications, Flexibility, and Differential Services

1
Applications, Flexibility, and Differential
Services

• John Wroclawski
• MIT Laboratory for Computer Science
• jtw_at_lcs.mit.edu

2
What are we trying to do here?

• Give users higher assurance of adequate
  application performance.
• When? When they need it.
• Give different users differing access to network
  resources.
• When? When resource demand exceeds supply.
• Allow networks customers and providers to
  understand ( monitor) what theyve agreed to.

3
What functions are needed(to provide network
QoS)?

• Admission control - some way to limit usage
  relative to resources.
• Packet scheduling - some way to treat different
  packets differently.
• Classifier mechanism - some way to sort packets
  into different treatment groups.
• Policies and rules for allocating resources.

4
A Differential Services Domain
Externally Visible Service
Core Network ElementPHB
Edge Element Profile Meter
5
Concatenated Domains
6
A Bigger Picture

• The important thing is quality of service that
  application delivers to the user.
• Network is pretty much along for the ride.

7
Applications and Performance

• Non-Adaptive
• Demands some minimum level of performance from
  infrastructure
• Does not work better if more
• No feedback loop

• Adaptive
• Adjusts to capabilities of infrastructure
• Contains some form of feedback loop

Performance WonderfulTerrible
8
Many (types of) Applications can be Adaptive

• TCP-based applications.
• Reliable multicast applications.
• Many audio and video communication applications.
• The Internet community is very good at this.
  Theyve had to be
• (Notable examples from Van J. and Steve M.)

9
Adaptive Applications and Network QoS
Range of Operation

• Same application - different performance in
  different circumstances.
• Occasional (network QoS) burbles may be
  acceptable.

With QoS
Without QoS
10
Sometimes the Application Can Help

• Two approachs to controlling resource usage of
  adaptive applications
• Network operates independently of app.
• Network control uses application feedback loop.
  (as today with non-QoS Internet)
• Potentially less mechanism in network.
• Scalable - computation control at edge.
• Trust-but-verify vs cop-on-every-corner.

11
A Service-Rich Infrastructure?

• Reasons to design infrastructure that supports a
  rich, highly flexible, easily evolvable set of
  externally visible services
• Meet different user usage patterns for
  applications (particularly adaptive).
• Operate effectively as part of application-network
  integrated system.
• Point of service provider competition?

12
But

• It wont do to have to replace your network every
  time you want to offer your customers a different
  service.
• It would be better not to require global
  agreement on every service to be offered.
• Perhaps differential services can help.

13
Diff-serv Revisited

• Three places for mechanism
• Per-hop (the point of congestion).
• Mechanism controls scheduling during congestion,
  etc.
• Profile meters - at boundaries between domains.
• Mechanism verifies usage patterns, tags packets,
  shapes flows, logs usage, etc. Enforces
  allocations and rules.
• End node -- source and destination.
• Generates/sinks traffic, may participate in
  control.

14
Translating Mechanism to Result

• Behavior of a domain function of
• Per-hop (scheduling) behavior.
• Profile Meters behavior.
• Together these form control mechanism 1.
• Result experienced by user function of
• Concatenated behavior of network domains.
• Adaptive behavior of end-node protocols and
  application.
• Together these form control mechanism 2.

15
A Key Point (Goal)

• These parts, working together, can implement a
  flexible range of user-visible QoS services from
  small set of core-network mechanisms.
• Not a 1-1 correspondence between core-network
  mechanisms (PHBs) and services offered.
• Many services from same core mechanism
  (flexibility)
• Different mechanisms for same external service
  (efficiency implementability)

16
Allocated Capacity Profiles

• The next few slides present some example PHB and
  profile meters that implement a range of services
  from simple mechanisms.
• This set of ideas have been called allocated
  capacity profiles, assured service, or expected
  capacity profiles.
• Focus here on service mechanisms and results.
  Policy and resource management concepts from
  Vans talk apply here too.

17
RIO (aka WRED) Mechanism

• Packets marked in or out.
• Out packets are preferentially dropped.
• Averaging behavior allows graceful control.

18
A Simple Service

• Fixed-capacity bulk data link (just b/w).
• RIO PHB at routers.
• Profile Meter at network boundary measures rate,
  marks in to limit, drops above limit.
• Result is high assurance of transmitting up to
  rate X, no ability to send more.
• Assumes that network provider has capacity to
  back the customers profile.

19
A Higher-Level Service

• Control of applications achieved data rate.
• How fast does TCP run over a path?
• Hard to say. Depends on available capacity, RTT,
  other factors.
• Implementation
• (Same) RIO PHB.
• TCP-aware profile meter.

20
TSW Profile Meter

• Goal cause TCP congestion feedback mechanism to
  control data transmission rate.
• Strategy
• Monitor average rate.
• Allow for TCPs hunting behavior.
• Desperately avoid slow-start.

21
Reno TCP Allocation
RED Queues
RIO-TSW Allocation
22
Split Meter Improves Performance

• These results are for profile meters in the
  first-hop routers.
• Substantially better results are possible with a
  split meter (RTT information available).

Host TCP (marks)
Router (verifies)
23
Sender and Receiver Profiles

• So far, weve discussed control by sender
• For many internet uses, value is to receiver
• Important alternative allows receiver to specify
  a service profile

Network
Sender
Sender Profile
Receiver
Receiver Profile
24
A Receiver-Based TCP Service

• Goal is to allow receiver to control allocation
  of resources to different senders in a scalable
  way.
• Important requirement - receiver does not have to
  subdivide and signal profile to senders.
• Dual of sender scheme - tag if congestion in net
  (ECN), profile at receiver ignore indicators if
  capacity is present.

25
Receiver-Based Details

• Sender or boundary tags as receiver-pays.
• RIO drops as if in, marks as if out.
• Receiver profile meter drops marked packets using
  same algorithm as in sender case.

26
Reno TCP Allocation (Rcvr)
RED Queues
RIO-TSW Allocation
27
Interdomain Profile Metering
Different types of Profile Meter atdifferent
pointsin the net.
HOST
METER INDIVIDUAL FLOWS
VERIFY HOST BEHAVIOR
PUBLIC INTERNET
CAMPUS NETWORK
VERIFY AGGREGATE BEHAVIOR
METER AGGREGATE BEHAVIOR
28
Some Further Examples
Router mechanism
Profile meter mechanism
Resulting service
Queue with higher priority than other queues.
Token buffer with constant rate output.
Emulation of fixed capacity circuit.
Tags packets in or dropped based on rate
Queue with RIO dropper.
Fixed bandwidth allocation.
TCP application performance allocation.
Tags packets in or out based on TCP function
Classification based on addresses.
Favoring of selected traffic during overload.
Tweaked from DDC IETF Dec 97
Not an end-to-end service, but built from
mechanism.
29
More of the Picture

• We have been talking about the mechanisms used to
  implement resource control. To fully describe a
  service two other things must be considered.
• Scope of the commitment.
• Strength of the commitment.
• Both of these are tightly tied to provisioning or
  admission control strategy used.

30
Scoping the Assurance

• End-to-End
• Customers and applications
• Access Cloud
• Content Providers,ISP Dreams
• Destination Sets
• VPN Providers Customers

Destination
Access
Destination Set
Inter-Provider
31
Profiles and Provisioning

• Selling a profile is a commitment by the provider
  to the customer that sufficient capacity is
  available to back the profile.
• Its easier to do this for some kinds of scopes
  than for others.
• But the other kinds of scopes are useful too.
• gt Different levels of assurance.
• OK for many classes of applications.

32
Differing levels of assurance

• Expected Capacity profiles depend on the
  statistics of traffic flows and suitable
  provisioning.
• ISP can monitor flow of in packets, provision
  accordingly.
• Profile creates an expectation that service will
  be provided, not guarantee.
• Possible for access or similar scope while
  still allowing high allocation of network
  resources.
• Not well suited to certain classes of service.

33
Stronger Assurances

• A higher level of assurance requires tighter
  binding from a profile to bandwidth along a path.
• Makes most sense to a specific destination.
• Two approaches
• Long term commitment -- use central planning.
• On demand -- use bandwidth broker.
• Modified RSVP - setup is light-weight -- no
  per-flow classification in middle of network.

34
Summary

• Differential services approaches may give us the
  ability to implement a service-rich network
  without undue complexity cost.
• This may lead to greater application performance
  and network efficiency.
• Delivered service in this model is represented by
  a profile, which captures function, scope, and
  degree of assurance.
• A number of points in that space are useful.