Subject: unifying diff-serve and int-serve

From: Jon Crowcroft <[email-masked]>
Date: Fri, 12 Dec 1997 13:13:32 +0000

There was a confused debate at/near the end of the int-serve
diff-serve session in the DC IETF, about the ~mechanisms" versus
"behaviours" way of building up the overall architecture........

here is a view...

so the best way to unify (or integrate) diff-serve and int-serve is to
start by differentiating them

I.
int-serv looks at packet flow behaviour at ingress and egress of each
queueing system - once you do that, you can compose a sequence
of these systems and (modulo the adspec delay accumulation) you can
get delay variance and throughput/burstiness of a flow's reservation -

(aside: it may be a modest piece of confusion that the admission tests
for the reservations for the classes of flow are worked out in terms
of WFQ  - but these are just useful for bounds from Parekh's PGPS work

basic design freedom for int-serve is for the router vendors to 
choose a queueing system, and figure out how to meet the admission
test for the that queueing system _so that_ it is equivalent to that
for WFQ;

Second basic design freedom is for ISP to choose router queueing
products based on the utilistion (for their traffic mix of classes)
they require (versus cost of routers:-)

D.
diff serve at its simplest
makes no statements about the flow behaviour
at ingress and egress, or the relative behaviour of flows - that is
entirely part of the contract between a subscriber and a provider - 

so the design freedom is now much greater for the ISP, but for a given
choice, possibly, much more specific (c.f. Van's particular business
case led to a much more specific queueing + filter behaviour)

what there is is an API to request one of a small number of different
treatments - at one extreme (forgive me if i am characterizing people
wrong) one can limit the diff-serve 'architecture' to this.....
at another extreme, one can start to specify mechanisms (remember,
these mechanisms, UNLIKE int-serve, do not have to compound together
to form a viable support for an end to end service - they are
provider-hop by provider-hop. Because of this last point, though, a
provider would like some idea of what is sourced from another
provider in many cases - so we need the idea of the filter applied to
traffic, rather than the traffic isolation function (ok, so there could be a
traffic isolation function, and both diff-serv and int-serv also can
have shapers, optionally)

a resulting difference is that the provider wide  POLICY for 
diff serve may be only only to do with allocations overall class
(hence its aggregation properties), whereas a policy w.r.t provider
wide int-serve is much more specific (not just probabily right - as
per steve's talk, the assurance levels are at different ends of the
spectrum, except that as yo uaggregaate traffic more, typically, the
assurance level of diff serve approaches that of int-serve....)

i think there is an interesting corrolary to this - to manage
policies for int-serve, one only has to manage policies for admission
at each hop, because the sequence of admissions will mean that global
traffic meets the ploicy, whereas to manage provider wide policies
for diff services, one has to manage admission at profile setup time
globally (put it simply - you _could_ do GS and CL and BE with 3 
variables at each router but if they were set inconsistently there 
would still be a set of services that would work, whereas if you get
the admission of  profiles wrong with diff serve, you could
get a system where none of the flows get the right service.....

 cheers

   jon

---

From: Jean-Yves Le Boudec <[email-masked]>
Date: Tue, 16 Dec 1997 20:59:26 +0200

At 13:13 +0000 12.12.1997, Jon Crowcroft wrote:

>globally

As was pointed out during the meeting, managing admission at profile setup
is not providnig much guarantee since even in non pathological cases there
will be converging flow problems inside a provider network.

but consider that

- today we have an internet with one single type of service

- we also have single ISP networks that offer priorities to closed user groups

thus, en mon humble opinion, the next step should be to standardize a
mechanism to support just priorities, which means a best effort service
within each priority level. Avoiding that everybody sends all of their
traffic with high priority can be done by appropriate billing. Anyhow, high
priority will be much more expensive than low priority, so if everyone uses
it no problem, ISPs will have enough money to provision large networks. Of
course, the key hard stuff is inter-ISP ot ISP to NAP agreements, since
your high priority service is of little use if you go through a carrier who
does not care. There are issues about TCP fairness and those are the ones
to be studied.

in summary, the very first mandate of a diff-serv group should be (imho) to
standardize inter-ISP agreements on how to provide priority services.
This means that we should focus on a contract at network boundary and let
the mechanisms alone.

JL

---

From: Paul Ferguson <[email-masked]>
Date: Tue, 16 Dec 1997 15:51:45 -0500

>This means that we should focus on a contract at network boundary and let

I agree, in principle, but perhaps we are using different words which
mean basically the same thing.

In essence, I'm not very fond of the phrase "standardize inter-ISP
agreements" since there is some implicit assumption that we
are going to attempt to specify the individual business models.
Now, having said that, please understand that I'm not explicitly
saying that this is what you meant (although it appears that we
continue to end up in this discussion, somehow).

ISP's define business practices, business practices define
contracts, and contracts are negotiated by humans.

The immediate need here, I believe, is to specify bit semantics.
This seems to be a topic where we all seem to both agree and
disagree. We agree on the basic principle that there should be
both "drop preference" and "delay indication", but disagree on
exactly what these should be. Personally, I don't really care,
but I believe that 1 or 2 bits for drop preference is too few;
1 bit may certainly suffice for delay indication, but I'm
certainly flexible.

The important thing here is that as an ISP, if I set the
bits on traffic in my network which I deem to be 'bronze', then
it would really be nice if the bits semantics meant the same
thing to the next-AS-hop ISP to I pass the traffic.

Now, competitiveness in the Internet being what it is, some
ISP's may not honor this, but that is a fact-of-life in any
business. Choices and business practices should not be mandatory.
The important thing is that should the next-AS-hop ISP choose
to do so, he could be assured that there is some way to interpret
the bit semantics for differential services in a consistent, and
documented, fashion.

Other stuff (e.g. ECN, dynamic interdomain negotiation) may be
interesting in the longer term, but trying to solve too many
problems in the short term will certainly extend the
deployability time frame.

This is another reason why I believe that we should collectively
conduct this work in a separate working group, namely, diffserv,
and articulate (in the charter) what problems are to be solved, and
in what time frame.

- paul

---

From: Juha Heinanen <[email-masked]>
Date: Wed, 17 Dec 1997 17:48:44 +0200

i have tried to figure out do we need to define the mechanisms and what
they could be or can we just define the services.  those in favour of
the mechanisms, could you explain to me what kind of diff-service cannot
be defined in terms of

- what are the delay/jitter and

- what are the loss

characteristics of the service.  so far i have had difficulties in
finding diff-services that could not be defined in terms of the above
two things.  therefore i'm not yet convinced that defining mechanisms is
a good idea especially if it would prevent the vendors from
differentiating their implementations.

-- juha