Subject: [Diffserv] EF with Drop ?

From: Grenville Armitage <[email-masked]>
Date: Tue, 09 Nov 1999 20:31:27 -0800

Hi,

Intrigued by the brief treatment in today's DiffServ meeting I had
a read of draft-dieder-diffserv-phb-efd-00.txt.

Frankly I'm a little confused. There seems to be no reason to define
a new PHB, and the document appears to mix _service_ with per hop
_behavior_.

I understand the authors desire a 'low delay, low jitter' service
that also has a best-effort style drop probability. Fair enough.
(In the I-D it is referred to as Best Effort Low Delay - BELD)
I also understand their logic when they observe that the current
EF PHB can't do the job on face value, since the EF definition says
packet drops are a BadThing(tm) rather than an acceptable event.

But I dont follow the argument about why AF cannot be used. In
the body of the document AF is dismissed by reference to Appendix B.5,
and there it simply says:

   The Best-Effort Low Delay (BELD) Service cannot be constructed from
   existing PHBs: The AF PHB allows queueing to accommodate to bursty
   traffic, leading to a higher delay. 

Now here I think lies the confusion between a PHB and a service. The
AF PHB doesn't really define queuing and scheduling parameters. It
simply allows those parameters to be set in such a way that two or
three drop thresholds are supported and meaningful. So I believe this
document is incorrect in assert that using an AF PHB necessarily
forces the resulting service to have high delay.

It appears to me that a "BELD" service as envisoned by this I-D
could be achieved using routers having only AF PHB support, in
conjunction with appropriate scheduler weights, small queue sizes,
and ingress traffic shaping onto the chosen AF class.

No doubt I'm missing something here, and would be interested
to know what it is.

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

_______________________________________________
diffserv mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/diffserv
Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/

---

From: "Albert Manfredi" <[email-masked]>
Date: Wed, 10 Nov 1999 10:11:21 -0500

Grenville,

First, how can anybody think in a hall with 300 people and with a
long list of drafts to be force-fed to this mass?

I think I agree with your point, that AF after all is nothing but a
set of PHBs with drop precedence. But one issue that might or might
not be a problem is that AF PHBs are geared toward TCP (responsive)
traffic, yes? What happens to multicast traffic? None of it is TCP,
it's hard to justify making it "drop-proof" in the general case, so
how should it be sent? Is it okay to assume that multicast can be
sent using AF PHBs?

I was thinking yesterday that if we have EF for non-responsive
flows, we might need more than one EF class to handle multicast?
Maybe that's an application for BELD?

Bert
[email-masked]

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf
> Of Grenville Armitage
> Sent: Tuesday, November 09, 1999 11:31 PM
> To: DiffServ
> Subject: [Diffserv] EF with Drop ?
>
>
> Hi,
>

---

From: Kathleen Nichols <[email-masked]>
Date: Wed, 10 Nov 1999 08:37:06 -0800

Grenville Armitage wrote:
...
> and ingress traffic shaping onto the chosen AF class.

I completely agree. Further, I think you could configure a Class
Selector the same way. Give it a short queue, control the
service rate and control the amount of the BA stamped for that CS
admitted to the network.

---

From: Roland Bless <[email-masked]>
Date: Thu, 11 Nov 1999 16:47:41 +0100

> service rate and control the amount of the BA stamped for that CS

I suppose that it is true that one could also realize the EF PHB with a
Class Selector Compliant PHB if one applies the additional constraints
of having nearly empty queues for this service due to the condition that
"the departure rate of the aggregate's packets from any diffserv node
must equal or exceed a configurable rate". From this point of view one
could argue that RFC 2598 is not a PHB specification but a SERVICE
definition, namely that of Premium Service that is described in section
1, and it could be realized by a Class Selector Compliant PHB satisfying
the additional requirements quoted above.

So if we have a description of an "externally observable forwarding
treatment applied at a differentiated services-compliant node to a
behavior aggregate" (PHB-Def.) that defines some additional requirements
compared to already existing PHBs, but one could also realize this new
behavior by extending an existing PHB with these additions, what do we 
have: a new PHB or a service definition? If the latter is true, then
RFC 2598 is a service definition and not a PHB definition.
Are there clear distinction criteria for services and PHBs?

Roland

---

From: Roland Bless <[email-masked]>
Date: Thu, 11 Nov 1999 17:30:38 +0100

Hi,

was it you that asked for how to enable other services than LBE for
multicast in the discussion of diffserv WG session 2? I wanted to
personally comment on this, but I had another discussion and you were
already gone. There are concepts mentioned in our draft how to provide
other PHBs within multicast groups. It is really not a problem for
having a MC group using the EF PHB. The problems which arise have to do
with resource usage and management mainly. The proposed LBE PHB simply
allows JOINs/GRAFTs to be processed in their usual way (as opposed to
requiring their interception) at first. So you get LBE behavior by
default, i.e., without a reservation. If there are resources provisioned
for a "better" PHB or this better PHB is requested explicitly and
corresponding resources are allotted, the branching router simply is
instructed to use another DSCP for the wanted PHB which could be EF
for example. Therefore, LBE also supports heterogeneous mc groups
to same extent.

> how should it be sent? Is it okay to assume that multicast can be

Yes, why not? Nothing prevents you from using UDP and multicast 
with AF.

> flows, we might need more than one EF class to handle multicast?

No, not IMHO. Because you'll typically have admission control and
resource management for EF, there is no problem having responsive and
non-responsive flows within the same EF BA.

> Maybe that's an application for BELD?

I don't think that's necessary.

 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: Brian E Carpenter <[email-masked]>
Date: Thu, 11 Nov 1999 12:53:35 -0600

Roland,

Need I say again that services are outside the diffserv WG charter?
We should perhaps rephrase your question in terms of behavior
aggregates, which seem to be a lot easier to identify than services.

   Brian

-- 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
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 13:29:41 -0800

> long list of drafts to be force-fed to this mass?

Dont you know? We all formulate our opinions before coming to
the meetings, and simply state them as many times as needed to
be the last speaker standing ;-)

But seriously...

> how should it be sent? Is it okay to assume that multicast can be

Sure, nothing stops AF from being used with multicast, and nothing
limits AF to TCP traffic. (It happens to be useful for bursty, latency
tolerant, and loss tolerant traffic in many envisaged deployments
but that's a different statement.)

> Maybe that's an application for BELD?

No. At least, not "BELD the PHB" but perhaps "BELD the service". Which
brings me back to my point that "BELD the service" can be supported
by "AF the PHB + appropriate provisioning and edge shaping".

cheers,
gja

---

From: Roland Bless <[email-masked]>
Date: Thu, 11 Nov 1999 23:01:20 +0100

> Need I say again that services are outside the diffserv WG charter?

No, we just wanted to know when we talk about PHBs and when not.
It was often argued that the LBE PHB is not a PHB but a service.
IMHO the LBE PHB is a PHB in relation to the PHB definition,
and we are still not convinced that this is not the case. We are
not saying (and never said, because it was already mentioned in the 
draft) that it could not be realized by an specific implementation of an
AF PHB (just as EF and CSC PHBs).

> We should perhaps rephrase your question in terms of behavior

To me it's not obvious how to do this and what the answer is.

Roland

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 12 Nov 1999 06:15:04 -0600

Roland,

We will be trying to come back to the list with a very precise
definition of how to identify and describe BAs.

   Brian

---

From: Juha Heinanen <[email-masked]>
Date: Tue, 16 Nov 1999 17:19:14 +0200 (EET)

> service rate and control the amount of the BA stamped for that CS

one way to implement a low delay service with drop is to use an af queue
with a high weight, but limiting enqueing of packets into it by running
red against a rate threshold rather than queue length threshold.

-- juha

---

From: Kathleen Nichols <[email-masked]>
Date: Wed, 17 Nov 1999 09:52:11 -0800

> red against a rate threshold rather than queue length threshold.

...so we appear to have plenty of PHBs that fit the bill....

---

From: Juha Heinanen <[email-masked]>
Date: Wed, 17 Nov 1999 02:18:35 +0200 (EET)

> Need I say again that services are outside the diffserv WG charter?

is there another wg to which they belong or can diffserv change its
charter?  the current situation is simply unbearable and will result in
countless new phb proposal when in fact they are proposing services.

-- juha