Subject: RE: Two new Internet-Drafts submitted

From: "Tony Hain (Exchange)" <[email-masked]>
Date: Fri, 22 Oct 1999 10:53:46 -0700

Kathie & Brian,

What this definition provides is an elevation of the Default BA to one step
above the strictly defined Best Effort service. In that context it is new.

Brian was calling for more deployment experience before defining something
new, but I have been in several meetings recently where there will be no
deployments until a service behavior is defined which treats existing
traffic (the Default BA) as protected from the new background traffic
service. We are at a deadlock without this spec.

In a perfect world you could argue that all traffic needs to be marked
appropriately, but the deployed net isn't perfect. It is incumbent on the
new service to provide the hooks to work around the legacy traffic, so
elevating the default behavior requires the definition of LBE, unless you
want to rework all the previous text to change 'best effort' to 'default
behavior'. 

Tony

 -----Original Message-----
From: 	Kathleen Nichols [mailto:[email-masked]] 
Sent:	Thursday, September 23, 1999 10:00 AM
To:	Brian E Carpenter
Cc:	[email-masked]
Subject:	Re: Two new Internet-Drafts submitted

Right. With this definition, LBE requires a "certain share". Since
that would mean non-starvation (if you have a share, no matter how
small, you aren't starved), then I think this PHB doesn't really
add anything new.

	Kathie

Brian E Carpenter wrote:
> 
> Thanks for the clarification.
> 
> RFC 2474 says nothing about link shares for the default PHB.
> It just says that default traffic gets whatever is left when
> all other PHBs have been satisfied, subject to a fuzzy
> non-starvation rule. I still don't see how that leaves any space
> for LBE, or any useful application.
> 
>    Brian
> 
> Roland Bless wrote:
> >
> > Brian Carpenter said:
> > > I must confess I have a deep intellectual problem with LBE. Since the
> > > definition of BE seems to me to mean "whatever is left after all
> > > other PHBs have been satisfied", then the capacity available
> > > for LBE is identically zero.
> >
> > No, that's not the LBE PHB definition from the draft. There are some
> > examples for its usage given in the draft. Maybe I should have better
> > used another name for this PHB if it's so confusing for people. To quote
> > the LBE PHB definition from the draft:
> >
> > "The LBE PHB is essentially defined by its relation to the default PHB:
> > an LBE packet is of minor relative importance compared to a best-effort
> > packet.  Thus, in case of contention for bandwidth (i.e., a congestion
> > situation), packets receiving best-effort treatment preempt packets of
> > the LBE behavior aggregate down to a certain share.  This share must be
> > considerably lower than that of the best-effort BA, but should not be
> > equal to zero in order to retain a low portion of LBE traffic even when
> > best-effort traffic takes up all available residual bandwidth.
> > Therefore, a minimum configured bandwidth share for LBE traffic exists
> > as a lower bound that guarantees transport of LBE packets even in case
> > of congestion.  On the other hand, this bound also constitutes an upper
> > limit for the share of LBE traffic during congestion.  This upper bound
> > may be static, that is, fixed in relation to the overall available
> > bandwidth on a particular link (a constant value for 100-Y in Fig. 2),
> > or it may be dynamic, i.e., fixed relative to the BE traffic share, thus
> > variable in relation to the overall available bandwidth, because BE
> > traffic may consume resources currently not used by other BAs (a dynamic
> > value for Y that depends on the amount of BE traffic; corresponding to a
> > constant ratio of (100-Y)/(100-X) in Fig. 2)."
> 
> --
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> Brian E Carpenter (IAB Chair)
> Program Director, Internet Standards & Technology, IBM Internet Div
> On assignment for IBM at http://www.iCAIR.org
> Non-IBM email: [email-masked]

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 22 Oct 1999 16:36:47 -0500

Tony,

That entirely begs the question by assuming that there *is*
a "new background service". The requirements I hear treat today's
traffic as the background and are looking for new services to raise
specific traffic types above the background, and certainly
that's what the deployments I am aware of are doing.

However there is no reason for this to be a block to deployment
in networks that believe that LBE is useful.
That's exactly what the EXP/LU code points are for. 

    Brian

Tony Hain (Exchange) wrote:
> _______________________________________________
> diffserv mailing list
> [email-masked]
> http://www.ietf.org/mailman/listinfo/diffserv
> Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/

Program Director, Internet Standards & Technology, IBM

---

From: Grenville Armitage <[email-masked]>
Date: Fri, 22 Oct 1999 21:12:24 -0700

> service. We are at a deadlock without this spec.

What's this "new background traffic" ?

What types of 'existing traffic' are more important than this
new background traffic? All types? Or just some subsets?

> want to rework all the previous text to change 'best effort' to 'default

I dont see that at all. In _practice_ (as opposed in an I-D) you
would take the 'important' legacy traffic and remark it as it
enters the newly minted DiffServ domain - remark it to some suitable
AF class that has 'better than Default BA' performance. Voila,
the default BA is then available for the "new background traffic"
to use.

Why is the problem any harder to solve than that?

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

---

From: "Jamel H. Sadok" <[email-masked]>
Date: Sat, 23 Oct 1999 09:33:20 -0200 (EDT)

> Why is the problem any harder to solve than that?

It may  be that many users won't be able to *afford*  the price of
remarking their existing legacy traffic  to a suitable AF class and yet
would still like to see their "ïmportant traffic" differenciated from
backgound traffic.

Are we correct  in assuming that  all users are going to be  able
"costwise"  to remark their traffic  into AF class?  I think that even
from a practical deployment point of view this is not  going to  be the
case! 

Jamel

---

From: Grenville Armitage <[email-masked]>
Date: Sat, 23 Oct 1999 08:19:04 -0700

> from a practical deployment point of view this is not  going to  be the

Why should the 'user' be remarking at all?  This 'user' supplies
traffic to a service provider, who is the one charged with
responsibility for treating existing BE traffic better than some
new mythical 'background traffic'. Given that the SP has deployed
a DiffServ domain, remarking on ingress is part of the SP equipment's
functionality.

(I'm assuming you mean 'price' in the sense of cost of equipment.
If you're talking about charges an SP might levy to perform
remarking, then we've just headed out into space were the oxygen
levels are very low and the hypothetical levels are way too high...)

cheers,
gja

---

From: "Jamel H. Sadok" <[email-masked]>
Date: Sat, 23 Oct 1999 15:52:41 -0200 (EDT)

> a DiffServ domain, remarking on ingress is part of the SP equipment's

Strictly speaking,  remarking  is  done  on ingress.  Considering that
this is done according  to pre-established per user/domains SLAs you may
say that  the user (which  may be a neighboring domain) is
also (ulimatly)  responsible for the decision. 

I have a problem  getting to  terms with the idea  that an existing
domain would need to establish some AF SLAs  in order to forward
its existing BE traffic. Is this  a  conensus or  am  I missing the
point? IMHO, I would rather think that todays
traffic would be tomorrow's default  and let  AF handle the new higher
priority stuff. That  way if my  domain is A-DiffServ it may go on for a
while (life as normal). 

Jamel

---

From: Grenville Armitage <[email-masked]>
Date: Sun, 24 Oct 1999 11:32:28 -0700

> On Sat, 23 Oct 1999, Grenville Armitage wrote:
	[..]
> Strictly speaking,  remarking  is  done  on ingress.

I'm aware of that, oddly enough.

>  Considering that

I think this is going down a rat hole. Suggest you go back to
the start of the thread to understand my response. Fundamentally
I agree - today's traffic is tomorrow's default. But some people
are arguing for a 'lower than best effort' class, and I'm not
buying it yet. Especially since, coming full circle, a DiffServ
capable ISP _could_ emulate the required differential behavior 
(between BE and LBE) by using an AF class to handle "today's"
BE traffic better than tomorrow's "background" traffic. This
can be transparent to the existing customers.

cheers,
gja

---

From: "Albert Manfredi" <[email-masked]>
Date: Sun, 24 Oct 1999 16:41:40 -0400

----- Original Message -----
From: Jamel H. Sadok <[email-masked]>

> Strictly speaking,  remarking  is  done  on ingress.  Considering
> that this is done according  to pre-established per user/domains
> SLAs you may say that  the user (which  may be a neighboring
> domain) is also (ulimatly)  responsible for the decision.
>
> domain would need to establish some AF SLAs  in order to
> forward its existing BE traffic. Is this  a  conensus or  am  I
> missing the point? IMHO, I would rather think that todays
> traffic would be tomorrow's default  and let  AF handle the new
> higher priority stuff. That  way if my  domain is A-DiffServ it
> may go on for a while (life as normal).

I have to echo Grenville's points. Seems to me that marking and
remarking are going to possibly occur at the ingress and egress of
any diffserv domain, and perhaps even at the interface _between_
diffserv domains (domains which use different conventions for
assigning AF classes, for example). And that while one might expect
all current Internet traffic to be sent as BE in a diffserv domain,
there's no reason to mandate that it must be so.

The idea that today's normal IP traffic would somehow be granted
more priority than some notional "background" traffic yet to be
defined leaves me a little skeptical too, but who cares? Any
diffserv domain should be able to handle this new concept with
relative ease, assuming there's any way to differentiate
"background" traffic from "regular legacy IP BE traffic" at the
diffserv ingress.

One way to differentiate such traffic for an ISP which has dial-in
users would be to use caller-ID to see who is dialing in. (Chuckle)
But this wouldn't work too well with cable modems or ADSL, as these
are being deployed today.

Bert
[email-masked]

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 25 Oct 1999 10:54:32 -0500

You say in part:

> its existing BE traffic. 

Indeed. There isn't any particular reason to do this. If you want
to raise some of your traffic above the default service (i.e. class
selector 0) you could simply use, e.g., class selector 1
if your ISP is willing to support it. A rather trivial MF classifier
in the host or a border router will be enough. People seem to
think that because AF and EF are defined, they must be used.
Not at all - that's why we included the backwards compatible
class selectors in RFC 2474.

That's why I don't understand Tony Hain's argument that the absence
of "LBE" is a roadblock; it's trivial to mark or remark traffic
that needs a little better than default treatment. In fact it's
running code where I sit.

   Brian

---

From: Rogerio de Carvalho Andrade <[email-masked]>
Date: Mon, 25 Oct 1999 17:30:54 -0200

> are being deployed today.

	I believe that, if you want/need to differentiate some flows in
dedicated lines (cable modems, ADSL, etc), you should do it by identifying
the IP address of the privilegied user(s)... However, it has a high coast,
in resource/management terms, hasn't it? (they usually use DHCP, too...)

> [email-masked]

[]'s

-- 
Rogerio de Carvalho Andrade
Analista de Suporte - Embrapa - DIN
 mailto:[email-masked]
Mestrando em Ciencia da Computacao - UFPE - DI
 mailto:[email-masked]