Subject: Re: [Diffserv] EF with Drop ?

From: Joerg Diederich <[email-masked]>
Date: 10 Nov 1999 21:45:32 +0100

Grenville Armitage writes:

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

The intention of describing the example services in the draft was to
motivate, why in our opinion the current PHBs cannot be used to create
such services. I tried to separate services and behaviors strictly but
there may be places in the draft where I did not succeed with
this. Could you please be more concrete at which places you think
services and behaviors have been mixed? Is it only where we state
that AF cannot been used (as you mention below)?

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

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

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

In my understanding, the fundamental difference between EF and AF is
that services built with EF relies heavily on traffic conditioning at
the network's boundary so that excess traffic and (almost all)
congestion within the EF BA is kept out of the network. In contrast,
services built with AF let excess traffic enter the network and use
buffer management means at each network to handle congestion within
each AF class.

In my eyes, you _can_ apply the same traffic conditioning actions to
packets marked for an AF class as to packets marked for EF so that you
model EF using AF. In this way, you simply do not need the buffer
management from AF since almost no queues arise. And if you do so, you
get 'EF with two drop precedences' so that you do not need EFD
anymore.

But then, you could in my opinion also ask why you need EF at all
since you can create Premium Service the same way using an
over-provisioned AF class with appropriate small buffers, strict
traffic conditioning etc, However, you will in my opinion end up with
almost the same statements on the buffer size, how to dimension the
link capacities etc as stated in the EF RFC.

I assume that there already was some discussion on this point but I
don't know, since I haven't been in the DiffServ working group from
the beginning. Since both, EF and AF, are on the standard track, I
assume that there was consensus that it is useful to have both
separate. I would agree with this since both RFCs use fundamentally
different principles (EF: let excess traffic out to avoid congestion
vs. AF: let excess traffic in and handle congestion).

However, I definitely do not want to be the initiator of a discussion,
which has (probably) already taken place some time ago. 

Thus, the EFD draft assumes that EF should be used to build a
low-delay service such as Premium service and we want to build a
service with _exactly_ the same delay characteristics as Premium
service using EF but allowing dropping. I do not think that you can
achieve the delay requirement by using AF for BELD traffic and EF
for Premium service simultaneously.

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

I agree with you, but since we assume that EF is used (or should be
used) to built low-delay services which rely on avoidance of
congestion by traffic conditioning (see above), AF seems to be not the
right way to implement a low-delay service which allows dropping but
does not allow congestion.

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

Same for me, since I am very probably not the best and most experienced
'DiffServer' :-) However, I am glad to get some input about this draft
and I am looking forward to discussing it further to improve it.

Ciao,

/J"org

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

---

From: Juha Heinanen <[email-masked]>
Date: Tue, 16 Nov 1999 21:33:52 +0200 (EET)

> get 'EF with two drop precedences' so that you do not need EFD

you can implement a behavior that is atleast close to ef by using an af
queue with a large weight (in order to guarantee low delay) and by
policing traffic at the ingress so that only green packets are allowed
to the network.

implementing an ef like behavior with drop is a bit more complicated
though, since i don't want the yellow packets to get all the bandwidth
that would be granted to them because of the large weight of the af
queue.  so what is needed in this case is red that starts to kick in not
when the queue size exceeds a threshold (which it never does), but when
the arrival rate of packets to that queue exceed a threshold.  for
example, if i want the "low delay with drop" packets not to consume more
than 20 mbps of a link's capacity, i would start dropping yellow packets
when the arrival rate of the packets exceeds 10 mbps.

 > the beginning. 

there was discussion about this, but to me it was more important to get
af done than to spend my time fighting against ef.

 > for Premium service simultaneously.

the customers don't care about af or ef.  they care about services and
it is my business which phbs i use to implement them.  the phbs used in
my network to implement a service don't need to be the same that the
next network is using.
 > does not allow congestion.

see above for an implementation that uses an af class with red and
results in a low delay service with drop.  is there something wrong with
it?  what else you would need?

-- juha

---

From: John Wroclawski <[email-masked]>
Date: Wed, 17 Nov 1999 18:28:47 -0500

>it?  what else you would need?

Juha,

I suspect I'm missing your point here, but this doesn't make sense to me:

- if there is sufficient b/w available to the AF class to carry the 
traffic, it will go & there isn't much reason to drop it.

- if there is insufficient b/w to carry the traffic for whatever 
reason, it will queue, and if you would rather drop it than queue it 
you should be able to accomplish this by setting the AF parameters 
appropriately (small q size, short averaging interval.

So I'm not quite sure what is to be gained by specifically watching 
rate rather than q size.

(I believe this is pretty much what Grenville said in this thread 
some msgs ago..)

-john

---

From: Joerg Diederich <[email-masked]>
Date: Fri, 19 Nov 1999 14:22:53 +0100

Juha Heinanen writes:

Juha> Joerg Diederich writes:
>> In my eyes, you _can_ apply the same traffic conditioning actions
>> to packets marked for an AF class as to packets marked for EF so
>> that you model EF using AF. In this way, you simply do not need the
>> buffer management from AF since almost no queues arise. And if you
>> do so, you get 'EF with two drop precedences' so that you do not
>> need EFD anymore.

Juha> you can implement a behavior that is atleast close to ef by
Juha> using an af queue with a large weight (in order to guarantee low

I agree. As you said, you are _implementing_ the externally observable
forwarding treatment, the EF RFC describes, with the same _mechanisms_
you implement the AF PHB by tuning the parameter of the concrete AF
implementation (e.g., WFQ).

Thus, IMO the distinction between the AF PHB and the EF PHB in
separate RFCs is necessary as it is done now, no matter how you
_implement_ both.

Juha> delay) and by policing traffic at the ingress so that only green
Juha> packets are allowed to the network.

I thought that using traffic policing at the ingress does not belong
to a per-hop behavior but to the construction of a service? Is it
possible that here services and PHBs got confused (your sentence
sounds to me more like 'you can construct a service that is at least
close to Premium service by using the AF PHB, implemented with WFQ
with a large weight, and by policing traffic...')?  (I really don't
like to be so 'stubborn' on terminology issues and wording, but I
think this is the main point why we do not agree whether there is a
need for an EFD PHB or not. See my comments below.)

Juha> implementing an ef like behavior with drop is a bit more
Juha> complicated though, since i don't want the yellow packets to get
Juha> all the bandwidth that would be granted to them because of the
Juha> large weight of the af queue.  so what is needed in this case is
Juha> red that starts to kick in not when the queue size exceeds a
Juha> threshold (which it never does), but when the arrival rate of
Juha> packets to that queue exceed a threshold.  for example, if i
Juha> want the "low delay with drop" packets not to consume more than
Juha> 20 mbps of a link's capacity, i would start dropping yellow
Juha> packets when the arrival rate of the packets exceeds 10 mbps.

Following my comments above, I agree that it may be possible to
_implement_ the EFD PHB using the same means of implementing AF
classes with special set of parameters, such as you propose. However,
the externally observable forwarding treatment is in my opinion
substantially different from the one described in the AF
RFC. Therefore, I think it is valueable to have the EFD PHB described
in a separate document.

Furthermore, as you said, it may be complicated to implement the EFD
PHB using AF queues (I cannot jugde this since I do not have that much
implementation experience with AF as you have). I have not implemented
the EFD PHB yet, but I think that there is a good chance that the
implementation I have in mind is less complicated. However, this is
speculation and a discussion about it must be delayed until I have
first results to present on simulation / implementation experience.
Also, a discussion of how to implement certain PHBs may be outside the
scope of this working group(?).

>> don't know, since I haven't been in the DiffServ working group from

Juha> there was discussion about this, but to me it was more important
Juha> to get af done than to spend my time fighting against ef.

I guess, most of us suffer from having too many problems to solve and
too less time to spend :-) Thanks for the information.

>> for Premium service simultaneously.

Juha> the customers don't care about af or ef.  they care about
Juha> services and it is my business which phbs i use to implement
Juha> them.  the phbs used in my network to implement a service don't
Juha> need to be the same that the next network is using.

Jep. The customers do not care about DS at all, they would be
perfectly satisfied with IntServ, DiffServ or whatsoever, if it
provides the service they want. 

But, ISPs using DS may care about PHBs. They are in my view the ones
for which the PHB standardization is targeted. For the development of
DiffServ, it is very useful to have several DS nodes from different
vendors which can interoperate within an ISP's domain using the
standardized PHBs (not necessarily the same DSCPs, since the mapping
DSCP - PHB will be configurable on each DS node). Each vendor may use
different implementations of the standardized PHBs and the market will
decide which vendor did the implementation job best.

Otherwise, (if you look at a DS domain with nodes from a single vendor
only), you do not need to standardize PHBs at all since the
construction of domain-wide services from PHBs and TC is a purely DS
domain local matter and the concatenation of DS domains is done on the
service level (although standardized PHBs (and DSCPs) avoid re-marking
at domain boundaries and may be useful in this case as well since they
make the implementation of DS boundary nodes easier).

>>  I agree with you, but since we assume that EF is used (or should
>> be used) to built low-delay services which rely on avoidance of
>> congestion by traffic conditioning (see above), AF seems to be not
>> the right way to implement a low-delay service which allows
>> dropping but does not allow congestion.

Juha> see above for an implementation that uses an af class with red
Juha> and results in a low delay service with drop.  is there
Juha> something wrong with it?  what else you would need?

As I said, your proposal for the mechanisms to _implement_ the EFD PHB
may be ok for constructing BELD service. However, there may be other
implementations but I cannot judge if they are better, easier to
maintain, better to implement, faster etc. 

To summarize my argumentation: my main point is that I do not think
that the description of the externally observable forwarding
treatment, as described in the EFD draft, is covered by the AF RFC (as
I said in my last email, they differ fundamentally in their concepts:
EF/EFD tries to avoid congestion using traffic conditioning means
while AF tries to deal gracefully with congestion using active buffer
management). Therefore, I think there is a need to describe EFD
separately.

/J"org
----
J"org Diederich
Institute of Operating Systems and Computer Networks, 
Technical University Braunschweig, Germany
Email: [email-masked]