Subject: Differential Services?

From: "Eom Jong Hoon" <[email-masked]>
Date: Tue, 18 Nov 1997 09:36:17 +0900

What means Differential Services?
I understand the Controlled-Load Service.
But I haven't been heart  Differential Services.
Is there anyone to explain Differential Services?

Jonghoon

---

From: Jon Crowcroft <[email-masked]>
Date: Tue, 18 Nov 1997 09:12:20 +0000

In missive <[email-masked]>, Eom Jong Hoon excl

Jonghoon

I havn't seen an agreed  definition on this list

in my view
Differentiated Services
refers to a thin/lightweight approach to providing some improvement to
the Internet "Best Effort" service
1/ without defining explicit performance parameters 
2/ without defining explicit parameters to be exchanged through
signaling

instead, typically, relative performance is defined between a small
number of services, signalied with a small, fixed number of classes,
indicated via TOS bits....

What makes Differentiated Service different from Type of Service?

a/ network economic theory and measurement based admission control
has moved along somewhat, and it is possible for a provider to define
an actual contracted service (i.e. with target performance QoS
parameters) even when the user does not explicitly ask for them,
through intelligent profiling of users, and through network
dimensioning.

b/ it is then possible to offer Int-serv classes (certainly Controlled
Load, possibly even Guaranteed Service) for a limited subset of users
in a mixed (multiserice) network, through subscription to profiles,
plus measurement admission and service selection by ToS bits....

An as yet unresolved piece of the architecture is how to offer this
over multiple provider paths - in the architectures presented at the
Munich IETF, a pirce of this part of the problem was referred to as a
Bandwidth Broker by Van Jacobson (who incidentally is giving a talk on
this on the Mbone on Nov 25....) 

It is entirely possible to use (modified) pieces of RSVP to install
profiles and the RSVP Policy work is similar to (or re-useable
component for) the broker....

but this all needs a lot more specification

things not yet resolved (at all)

1/  Do we need to agree semantics of ToS bits (in Pv4, and define ones
for IPv6), and if so, how many? - request precedence bits,
delay preference bits, drop preference, marking, congestion 
experienced bit, even reliabilty and pricing bits have been discussed
2/ how to refine RSVP for this if appropriate
3/ the broker
4/ security consequences (if ToS bits are not visible because of ipsec
sealing of header)
5/ tunnel consequences
6/ ISSL considerations (e.g. level two can help a lot if it has
similar TOS bits, as per SMDS, Frame Relay and some ATM (e.g. CLP)
bits....

and probably a few more...
 cheers

   jon