Subject: Re: Number of drop classes

From: "Alessio Casati" <[email-masked]>
Date: Thu, 20 Nov 1997 17:27:52 +0100

Folks,
I'm making public a private exchange with Rickard.

I would only remark that Rickard proposes to use  DP bit(s) in addition to
a In/Out bit. Am I right? In such a case I'd  suggest to better use that(those) 
bit(s) as a delay indication or spare it(them) for future use (e.g. ECN).

On 20 Nov 97 at 16:46, Rickard Janson wrote:

> Alessio,
> in my example with 2 DP levels
> the premium and casual users are "good guys" i.e. sending within
> profile but congestion appears anyway. In that case it is no way to
> discriminate traffic from the premium users from the casual users.
> Rick
> 
> 
> Alessio Casati wrote:
> 
> > Rickard,
> >
> > I would like to stress that with more DP classes you are not
> > solving neither economic network design problems nor unwanted packet drops for
> > lowest DP service users.
> > To me it resembles fighting the crime by  making it legal (sorry for
> > a similitude which maybe makes me appear harsh to you).
> >
> > Now I hope to be able to show you why. If you let people know that you are going to
> > offer them a service discriminating them only in times of congestion, then you are encouraging them
> > to try to use up as much bandwidth as possible in normal times. That is they will try to be as
> > much aggressive as they can in order to conquer as much as possible when congestion disappears.
> > On the other hand you must be able to offer a virtually loss-free service to lowest DP guys.
> > So you must leave some spare resources in order to accommodate them. What you are likely to
> > get is a network with aggressive users making it very prone to congestion. So good service is going
> > to occur only for goldest service users and economics will be likely to push providers to
> > offer a cheaper and cheaper goldest service. Eventually "natural (economic) selection"
> > will lead to roughly two desired DP (highest and lowest DP). Economics and technical reasons will
> > make these 2 DP level to result in a In/Out indication bit, because what provider will need as
> > tools for proper network operation will be a metering functionality and an aid in bad guys
> > identification.
> >
> > So, when you are able to identify bad guys (which happen to be out of profile) you can
> > give them penalty. Penalty serves as threat so that the number of bad guys is likely to
> > decrease and when the number of bad guys decreases you have a very predictable traffic
> > which makes your network easier to design and manage.
> >
> > Different rates will be viable by different Delay Indication and by the definition of profiles and
> > the corresponding meters letting the network benefit from user's congestion rensponsiveness. ECN
> > users, for instance, may be granted lower rates than non ECN ones.
> >
> > alessio
> >
> > On 20 Nov 97 at 11:05, Rickard Janson wrote:
> >
> > > Definition of only two drop classes (IN&OUT) will make the
> > > network planning more difficult than if more drop classes
> > > are defined. The reason is that it is economically impossible
> > > to allocate enough bandwidth in a complex network topology
> > > so that all IN traffic can be carried unrestricted (without
> > > drops) on all links - in a worst case (still realistic) traffic
> > > scenario.
> > > The same statement is valid even if more than two drop classes are
> > > defined (i.e. no hard garanties for a specific drop class). However,
> > > the difference is that the network behavior will be more elastic and
> > > smooth.
> > > For example (>2 DC); a premium user might loose a few packets,
> > > at the same time a casual user (low subscription charge)  experience
> > > a severe drop and the bulk file transfer halts for the time of the
> > > congestion.
> >
> > > The same example with IN/OUT DC: all users experience same
> > > drop rate (on the jammed link) if they are sending IN profile.
> > >
> > > I.e. little correlation exists between the aggregate of users
> > > IN profiles bandwidth and the actual bandwidth on a specific
> > > link in a large network.
> > >
> > > Cheers/ Rick
> > >
> > > ------------------------------------------------
> > > Rickard Janson                     Ericsson Telecom
> > > [email-masked]            +46 8 7190486
> > > ------------------------------------------------
> > >
> > >
> > >
> > >
> 
> 
> 
> 
>

---

From: Jon Crowcroft <[email-masked]>
Date: Thu, 20 Nov 1997 17:11:14 +0000

In missive <[email-masked]>, Alessio Casati excla

 >bit(s) as a delay indication or spare it(them) for future use (e.g. ECN).

i think its important to motivate what level of diff serv is trying to
be achieved in all this too-ing and fro-ing on how many
drop or precedence classes

people are expressing viewpoints without some target operating
environment (or when referreing to "experience" often it comes from
other networks with DIFFERENT application behaviours - FR for example,
and without public Internet deployment experience)....

i think some people are asking for the bellybutton bit, 
some people for 1, 2 or 3 DP bits  beyond this, 
some people for 1 or more delay preference bits
and now some for ECN (and one might start to talk about BECN or FECN:-)

this proliferation has to end somewhere, as you say, since
1/ IPv4 only has so many bits, and their behaviour is already
partially defined (and paul ferguson's draft went some ways to
accomodating both these constraints already)
2/ if you want much more, why not just WAIT FOR int-serv....?

cheers
jon

---

From: John Wroclawski <[email-masked]>
Date: Thu, 20 Nov 1997 17:43:22 -0500

>and without public Internet deployment experience)....

More on this as we get closer to the IETF, but I want to add that in my
view this is one of the first and largest questions we need to address, and
with everyone's help I plan to structure the meeting in DC in a way that
gets this question out in the open before we get tied up in specific
technical details.

Just for fun I'll further suggest that any good answer breaks into two
parts; the "now" answer and the "ever" answer. At the meeting, I will
particularly be looking for some concensus on a set of things we should do
"now" that are both immediately useful and don't impede the possible
development of "ever".

See you there. It'll be fun!

-john w.

---

From: Paul Ferguson <[email-masked]>
Date: Thu, 20 Nov 1997 18:43:04 -0500

>2/ if you want much more, why not just WAIT FOR int-serv....?

Ditto.  ;-)

- paul

---

From: Paul Ferguson <[email-masked]>
Date: Sat, 22 Nov 1997 06:55:27 -0500

At 03:58 PM 11/21/97 +0100, Alessio Casati wrote:

>
>I think there's consensus on these points, right? Too-ing and fro-ing on bits is going
>to decrease soon, I feel. I don't think it's bad for now.
>

Being an optimist on this particular topic, I expect to get some
of this out of the way at the Decemeber/IETF. I hope.

- paul

---

From: "Alessio Casati" <[email-masked]>
Date: Fri, 21 Nov 1997 15:58:34 +0100

> >2/ if you want much more, why not just WAIT FOR int-serv....?

Jon and Paul,

every user would be happy with int-serv, you both are right (and I guess you both imply
it would be a long wait). The motivation why somebody proposed diff-serv was that waiting 
for int-serv might  result in a "waiting for Godot", or at least that's what I undertood. Diff-serv 
should be regarded as the cash-cow letting a sufficient availability of financial resources
allowing ISPs to buy capacity and boxes in order deploy whatever service they
want. 

What is mainly needed NOW is to reform the Internet in something encompassing a class of service
more reliable  than plain best effort (and someone hopes more than one such a class). That would 
attract new wealthy customers for ISPs. 

What we should do right now is to make the right choices in order to make the first step diff-serv
really affordable while providing real value to providers's customers.

What we should avoid right now is to exhaust every bit we may use, unless
we recognize strict need of them all.

Trying to replace int-serv is pointless (it would require exactly the set of tools and 
functionality and have the same complexity)

alessio