Subject: RE: [Diffserv] LBE using RFC 2474

From: "Yoram Bernet (Exchange)" <[email-masked]>
Date: Thu, 11 Nov 1999 05:54:40 -0800

I agree with Klaus here. 

The point is to have a barin-dead simple way of getting certain traffic to
be downgraded in priority. 

We're working with our IT group to roll out differentiated services. We have
to find the least painful way to roll this stuff out. We need to reconfigure
as few routers as possible. Those that do need reconfiguring should require
the simplest possible reconfiguration. In addition, we need to worry
(initially) about as few applications as possible. That means that the
applications that get special treatment need to be the exception, rather
than the rule.

This begs for routers that 'out of the box' just recognize an LBE mark and
downgrade it relative to other traffic. That in turn, requires standardizing
an LBE DSCP. 

Yoram

> -----Original Message-----
> From: Klaus Wehrle 
> [mailto:[email-masked]]
> Sent: Thursday, November 11, 1999 2:49 AM
> To: Brian E Carpenter
> Cc: [email-masked]; [email-masked]
> Subject: Re: [Diffserv] LBE using RFC 2474
> 
> 
> Brian E Carpenter wrote:
> 
> > Kathie and I discussed the less than best effort 
> requirement expressed
> > by some people, and concluded that this can be done using RFC 2474
> > with no change:
> 
> When you override the SHOULD  in RFC 2474, section 4.2.2.2 
> this would be a
> change ;-)
> 
> >
> > In the DSCP to PHB mapping table, map the DSCP value 0 (default)
> > to the PHB Class Selector 2. Then classify the "LBE" tarffic
> > into a BA that receives PHB Class Selector 1.
> 
> nice trick, but if an ISP do not use this mapping, the 
> LBE-traffic would
> not be treated lower than Best-Effort.
> 
> If you use a seperate Codepoint for LBE, every router can 
> distinguish it
> from BE, independant from the mapping of LBE-traffic into a BA that
> receives lower than BE.
> I think, there are enough Codepoints left, so why don't we 
> assign one to
> LBE.
> 
> If you map BE to ClassSel 2, LBE to ClassSel 1, then you can 
> map EF to the
> highest ClassSelector and we can forget RFC 2598. I think, 
> that is not was
> the people on the DiffServ-WG-list want.
> 
> I don't know, if every ISP wants to offer services, that only 
> bases on AF
> or EF or the ClassSelectors.
> 
> >
> > This usage overrides the SHOULD in RFC 2474, section 4.2.2.2,
> > but that is why we use SHOULD instead of MUST.
> 
> --------------------
> Ciao,
> Klaus
> 
> --
> 
>  Klaus Wehrle
>  Institut für Telematik, Universität Karlsruhe (TH)
>  Zirkel 2, 76128 Karlsruhe, Germany
>  Phone: +49 721 608 6414, Fax: +49 721 388097
>  mailto:[email-masked]
>  http://www.telematik.informatik.uni-karlsruhe.de/~wehrle
> 
> 
> 
> _______________________________________________
> diffserv mailing list
> [email-masked]
> http://www.ietf.org/mailman/listinfo/diffserv
> Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/
>

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 11 Nov 1999 12:51:08 -0600

Yoram,

I wouldn't expect any routers to recognise anything except default
out of the box, except maybe the high class selectors for routing
traffic.
I have running code proof that current routers from a major router
vendor default to rewriting the DSCP to zero, out of the box. So
I really think you are asking for the impossible, and routers
providing an LBE behavior aggregate will definitely need to be
configured.

That being so, there doesn't seem to be any advantage in defining
a recommended DSCP for a BA that we can construct using an existing
PHB.

  Brian

"Yoram Bernet (Exchange)" wrote:
> >  Institut fur Telematik, Universitat Karlsruhe (TH)

-- 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Brian E Carpenter (IAB Chair)
Program Director, Internet Standards & Technology, IBM 
On assignment for IBM at http://www.iCAIR.org 
Attend INET 2000: http://www.isoc.org/inet2000
Non-IBM email: [email-masked]
Ethernet address: 00-00-AC-CF-5B-82

---

From: Grenville Armitage <[email-masked]>
Date: Thu, 11 Nov 1999 14:16:39 -0800

Yoram,

> The point is to have a barin-dead simple way of getting certain traffic to be
> downgraded in priority.

Or certain other traffic to be upgraded in priority.

It appears to me that the motivating arguments boils down to the
following:

	- Many traditional applications (and their users) have been
	  lulled into experiencing Best Effort (BE) as the Actually
	  Pretty Good (APG) service.
	- Some people believe they have customers interested in a
	  service that isn't as good as the APG service they've come
	  to know (and ergo hopefully cheaper).
	- Some people have an IT department that wants to deploy some
	  new apps with 'in the background' priority so as not to
	  disturb the APG service being received by existing apps.
	- Both of the preceding points are legitimate concerns and
	  generate a demand for at least two distinct service
	  levels - APG and something less.

Our shared problem is that the APG service is being received by traffic
marked (by default or design) as BE. I can understand this has created
a conflict, since BE is _supposed_ to be the cheap-and-crappy
service.

I have a major problem with defining LBE because it cements in the
notion that BE actually isn't BE. It also implies some notion of
an APG service which to date is not being characterized anywhere
(except by circular definition of "the service that's better than
LBE", which doesn't really help much).

I also dont believe LBE is necessary. What is necessary is to
have those apps and customers who really desire an APG service
be remarked to a DSCP that will given it to them (whether a Class
Selector or AF codepoint). Leave BE as it has always been. Voila,
we have two levels of service as desired.

	[..]
> downgrade it relative to other traffic. That in turn, requires standardizing

I believe this begs for a diffserv deployment that actually uses
MF classifiers at the edges to assign DSCPs appropriately,
marking all current traffic as APG except those new services you're
worried about which can be assigned BE. Your core routers then dont
need an additional DSCP/PHB to worry about - just the existing BE,
ClassSelector, and/or AF groups.

cheers,
gja
________________________________________________________________________
Grenville Armitage                            http://mh005.infi.net/~gja
Bell Labs Research, Lucent Technologies

---

From: Michael Richardson <[email-masked]>
Date: Thu, 11 Nov 1999 17:15:20 -0500

Again, I do not understand why the problem expressed by Yoram is not
solveable by distinguishing between "DSCP == 0" and "BE"

  Why can't Yoram solve his problem by assigning DSCP==0 to be something
other than the BE queue? As one pointed out, with appropriate AF parameters,
you can get the behaviour that is wanted.

  I got silence at diffserv when I asked this. Some people commented
afterward to me that they didn't know either. Can someone answer me this? 
  The DSCP to PHB mapping is programmable by the administrator.

  If BE works for Yoram's network as it is now, then some "better" service
ought to work as well, right?

]         At IETF46 in Washington, DC  --- wireless             |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another NetBSD/notebook using, kernel hacking, security guy");  [

---

From: Michael Richardson <[email-masked]>
Date: Fri, 12 Nov 1999 09:14:08 -0500

>>>>> "Grenville" == Grenville Armitage <[email-masked]> writes:
    Grenville> I also dont believe LBE is necessary. What is necessary is to
    Grenville> have those apps and customers who really desire an APG service
    Grenville> be remarked to a DSCP that will given it to them (whether a Class
    Grenville> Selector or AF codepoint). Leave BE as it has always been. Voila,
    Grenville> we have two levels of service as desired.

  The problem is that this requires coordination for all user's of service
"X" that wanted APG, and with 200-300 distinct applications, it may not be
clear which services are most important. So, to do this right, you need
flag-days (maybe flag-months).

  This is not a way to endear diffserv to IT departments. 

  One solution is to remark all DSCP==0 traffic that arrives at any diffserv
aware router to a different code point for a period. But, why bother do that?
Just change the DSCP==0 mapping from the BE PHB to the APG PHB (whatever that 
means).

---

From: Roland Bless <[email-masked]>
Date: Thu, 18 Nov 1999 10:41:19 +0100

> solveable by distinguishing between "DSCP == 0" and "BE"

The main idea behind LBE is the following:
1.) currently the main portion of traffic is assigned to the default PHB 
    which corresponds to BE at the moment -> whatever resources are left
    after all other BAs have been served are given to BE packets.
2.) you have one or more traffic sources which are non-responsive
    and which usually would be mapped into the BE aggregate. In order
    to avoid unfairness against existing flows in the BE aggregate
    you want to limit the amount of additional traffic in case of 
    congestion.
    Therefore you push the non-responsive traffic sources in the 
    "background" by limiting their BA (maximum share). However, there is 
    also a no starvation guarantee for LBE packets (minimum share).
3.) if there is no congestion, packets in the LBE BA may also use
    unused bandwidth of any other BA.

> you can get the behaviour that is wanted.

Because you want to explicitly mark this traffic as background traffic
that is limited in its bandwidth share, so you need a specific codepoint
for LBE. Naturally, you could _implement_ LBE by mapping the DSCP==0 to
an AFx2 PHB mechanism and LBE DSCP to AFx3 PHB if this AF class
particularly fulfills the requirements of the LBE spec. But, simply
mapping the default PHB to a better PHB will not be sufficient, because
the next provider may not treat packets with DSCP == 0 in the same way.

> If BE works for Yoram's network as it is now, then some "better"
> service ought to work as well, right?

If most of the traffic that is BE today will be in this "better" service
class in the future (being not more expensive than BE), one could use 
BE as future background class. But, this is not the situation today, so 
we may use the LBE PHB to protect the current BE traffic from being 
preempted.

Regards,
 Roland
-- 
Roland Bless -- e-Mail: [email-masked]
Institute of Telematics, University of Karlsruhe, F.R. of Germany  
Zirkel 2, D-76128 Karlsruhe -- Office: Engesserstr.2 (Bld. 20.50), 1st floor
Phone: +49 721 608-6396 Fax: +49 721 388097

---

From: Paul Langille <[email-masked]>
Date: Thu, 18 Nov 1999 09:53:56 -0500

See comments below:

>     unused bandwidth of any other BA.

Roland, when I have talked about this issue I tend to approach it from a 'higher
layer'. I like the statement in your draft "Thus, it constitutes the network
equivalent to a background priority for processes in an operating system." In
broad terms one should not map default 'stuff' to the lowest priority. There may
be something (i.e. batch jobs) that one would like to run at a lower priority than
what everyone is using for the default priority. (This was the basic approach used
in 802.1P.) In my humble opinion, discussing this concept in terms of "BE" is
confusing. (Thinking out loud...I wonder if the current concept of BE needs to be
enhanced/modified to support LBE.)

> the next provider may not treat packets with DSCP == 0 in the same way.

So if I could be so bold as to summarize the issue. It IS possible to create this
behavior by mapping to AF. (Pause - Anyone disagree?) Your point is that it needs
to be standardized so that each provider will offer the same behavior. It might
help to ask if people agree with the basic model you are proposing. (OK, I'm
asking!) If yes, do you like it enough to standardize it? (It may not be easy to
obtain consensus for this question. Brian makes a good point about conserving code
points.) If there is consensus on making this standard then proceed with how to
implement it. (A lot of the discussion (IMHO) on this topic has been about your
implementation.)

            Paul

--
Paul Langille                e-mail: [email-masked]
Crescent Networks            phone: (978) 244-9002 x244
201 Riverneck Road           fax: (978) 244-9211
Chelmsford, MA 01824

---

From: Frank Kastenholz <[email-masked]>
Date: Thu, 18 Nov 1999 16:58:23 -0500

Isn't this just "RED with Penalty Box"?

---

From: Roland Bless <[email-masked]>
Date: Fri, 19 Nov 1999 11:42:00 +0100

> in 802.1P.) In my humble opinion, discussing this concept in terms of "BE" is

Good point.

> enhanced/modified to support LBE.)

I suppose that LBE PHB and default PHB maybe form a PHB group together,
because they share a common constraint. 

> behavior by mapping to AF. (Pause - Anyone disagree?) Your point is that it needs

Not only mapping, but also using appropriate parameters for AF 
derived from the LBE spec. Note that realization of the EF PHB is also
possible by using a CSC PHB if the constraints imposed by the EF spec
are met by this particular CSC PHB implementation.

> to be standardized so that each provider will offer the same behavior. It might

Right.

> implement it. (A lot of the discussion (IMHO) on this topic has been about your

This draft was a first attempt to specify the requirements we had for
our particular problem with re-marking multicast flows (see also
draft-bless-diffserv-multicast-00), but as mentioned by the examples in
the draft, there are more useful applications of it, which were also
confirmed at the meeting. Naturally, a future version will highly benefit 
from additional input or requirements.

We do not want an LBE PHB specification with unnecessary restriction for
its implementation. Therefore, as long as the requirements of the LBE spec
are met you can use various mechanisms to realize the LBE PHB (one was
using an AF PHB as basis).

Regards,
 Roland

---

From: Roland Bless <[email-masked]>
Date: Fri, 19 Nov 1999 11:52:20 +0100

> Isn't this just "RED with Penalty Box"?

Whatever you mean by "RED with Penalty Box", RED could be used very well
for implementing the LBE PHB as already mentioned in the draft in
section 2.3.

Roland

---

From: Grenville Armitage <[email-masked]>
Date: Fri, 19 Nov 1999 10:53:51 -0800

> flag-days (maybe flag-months).

Since we're talking about a transition plan here, how about an
MF classification that wild-cards almost everything to APG, except
for the few 'new' apps that require 'background' service?

cheers,
gja