Subject: RE: [Diffserv] Yesterday's EF discussion

From: Jay Wang <[email-masked]>
Date: Wed, 13 Dec 2000 12:29:18 -0800

Juha,

I respectfully disagree with your proposition. Regardless of how 
we define these PHBs, I am sure that every box vender would have 
a description of their underneath mechanisms (such as classifier, 
meter, shaper, scheduler, etc) that support Diffserv available to 
its customers.  By tuning all the knobs, the customers can surely 
create different services within the capacity allowed by the system.  
However, this does not necessarily imply that well defined PHBs are 
useless. For Diffserv (and more generally QoS as a whole) to be 
accepted by the service provider community and the general public, 
complexity in deploying, engineering, and using QoS-enabled services 
has to be minimized. I thing some well known and well defined PHBs that 
"wrap" around the underneath mechanisms in the routers/switches provide 
the first step toward that objective. The question is how do we do it 
right and I think this is what the WG has been trying hard to achieve.

Regards, 

- Jay

----------------------------------
Jay Wang,	Cosine Communications
Voice: (650) 628-4296	Fax: (509) 694-6065

> -----Original Message-----
> From: Juha Heinanen [mailto:[email-masked]]
> Sent: Wednesday, December 13, 2000 11:48 AM
> To: Brian E Carpenter
> Cc: Diff Serv
> Subject: [Diffserv] Yesterday's EF discussion
> 
> 
> Brian E Carpenter writes:
> 
>  >    What should the name of the PHB be?
>  >      Chair's proposal: Defined Rate (DR). I believe that 
> after this long
>  >      and confusing discussion, it would be wise to retire 
> the previous name.
> 
> if i implement an af class by assigning it to a wfq of a 
> certain weight,
> it defines a rate for that class.  does this mean that by proper
> admission control to that class, i can in fact implement using an af
> class a service that is equivalent to a service that would result if i
> would be using the dr phb instead?  if so, do we really need 
> (for other
> than political reasons) ef or this new thing?
> 
> this brings me back to a point that i have made before, i.e., i feel
> that the whole phb concept is not that useful.  what is useful is the
> description of the actual (queuing, droping, policing, etc.) 
> mechanisms
> that the routers may implement and a way to validate them.  a well
> documented list of such mechanisms including their 
> parametrization would
> be to the buyer of a router a much more useful thing than a claim that
> the router implements a certain list of phbs.
> 
> -- juha
> 
> _______________________________________________
> diffserv mailing list
> [email-masked]
> http://www1.ietf.org/mailman/listinfo/diffserv
> Archive: 
> http://www2.ietf.org/mail-archive/working-groups/diffserv/curr
ent/maillist.html

---

From: "Nabil Seddigh" <[email-masked]>
Date: Wed, 13 Dec 2000 19:18:24 -0500 (EST)

In message "[Diffserv] Yesterday's EF discussion", Brian E Carpenter
writes:

>     Chair's proposal: Defined Rate (DR). I believe that after this
long
>     and confusing discussion, it would be wise to retire the previous
name.

Somehow DR sounds like a better name for a PDB.
If it is decided that the "EF" name be retired, would suggest picking
a name that's reflective of some kind of forwarding treatment.
e.g. XF (Express Forwarding), LDJ (Low Delay Jitter Forwarding)
etc

Controversy aside, there's a lot of paper work out there with the name
EF on it. Is there any way to escape without changing the name?

Best,
Nabil Seddigh

_______________________________________________
diffserv mailing list
[email-masked]
http://www1.ietf.org/mailman/listinfo/diffserv
Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Thu, 14 Dec 2000 10:21:12 -0500

Brian E Carpenter wrote:

> Nabil,
> 
> The issue is what is least confusing to the user community - 
> a new definition
> with the old name, or a new name? I'm interested in opinions.

My vote is to stay with EF, unless the group really wants to change EF into
something that truly addresses only jitter (which I think would be unwise).

Expedited implies that all delays are controlled, exactly as EFRESOLVE
describes. Maybe some other class of EF service, which truly addresses
jitter rather than delay, might be given a different name.

Bert

---

From: Justin Fletcher <[email-masked]>
Date: Thu, 14 Dec 2000 10:37:00 -0800

> Demir,
 >
 > You've made your point. I'd like to hear from the silent majority:
 > do we change the name or not?
 >
 >    Brian

Keep the name.  The issue has been what is EF, not the definition of a
new behaviour.

Justin Fletcher
[email-masked]

---

From: "Lemaire, Tom" <[email-masked]>
Date: Thu, 14 Dec 2000 13:42:56 -0500

Well said.  I would agree that keeping the name EF
is the path of least confusion.

Tom Lemaire
Unisphere Networks

-----Original Message-----
From: Scott Brim [mailto:[email-masked]]
Sent: Thursday, December 14, 2000 1:15 PM
To: [email-masked]
Subject: RE: [Diffserv] Yesterday's EF discussion

I also think that while there may be some confusion for a while, it's
much better to keep the name EF.  There are multiple interpretations of
"EF", but only below a certain threshold of detail.  Those who know the
differences and would be concerned by them are also those who would not
be confused by calling whatever we produce EF.  Those who are farther
from the issues only know what EF is *for*, which has not changed.  They
are not concerned about the details, they often would feel uncomfortable
when presented with them, and we would have to bother them with those
details in order to explain the new name to them.  The new name helps
those who don't need it and potentially causes us trouble with those who
might.

..Scott

_______________________________________________
diffserv mailing list
[email-masked]
http://www1.ietf.org/mailman/listinfo/diffserv
Archive:
http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.h
tml

---

From: "Ralph Santitoro" <[email-masked]>
Date: Thu, 14 Dec 2000 18:01:20 -0500

I agree with those in favor of keeping the 'EF' name.  My reasons are as
follows:

1) The goal of the WG (as discussed at the Pittsburgh meeting) was to "fix"
RFC 2598 and -not- to create a new PHB (supporting info already posted to
the DiffServ list).  Given this, a new name will imply a new PHB.

2) Given that the 'EF' PHB (RFC 2598) was a proposed standard for about a
year before it was challenged, vendors have already implemented their
interpretation of  the 'EF' PHB and its associated 'EF' DSCP.  Therefore,
the 'EF' term is proliferated in a variety of product literature,
whitepapers, marketing literature, engineering documentation, training
courseware and device/service configuration tools.  Note that the 'EF' name
and EF PHB/DSCP definition has been around for at least 2 years and has been
an RFC for 1.5 years.

3) The 'EF' term has been socialized for the last 2 years to network
managers and the marketplace in general.  Given the new term is meant to
have the same "intended" behavior that 'EF' was to provide, this new term
will create more confusion than clarification for those who are not as close
to the subtle details discussed in the WG.  Scott's posting below further
articulates my point.

.... Ralph

-----Original Message-----
From: Scott Brim [mailto:[email-masked]]
Sent: Thursday, December 14, 2000 10:15 AM
To: [email-masked]
Subject: RE: [Diffserv] Yesterday's EF discussion

..Scott

---

From: Jon Bennett <[email-masked]>
Date: Thu, 14 Dec 2000 21:23:07 -0500

> 
> At 02:11 PM 12/14/2000 -0500, Jon Bennett wrote:
> >... our assertion all along has been that what we wrote in 
> >draft-charny is what 2598 'says' regardless of what Van 'meant'
> >to say. 
> >And that what it 'says' has been implemented  by a lot of people
> >already. 
> 
> Could you provide some details about who has "implemented" EF?
> 
> What exactly do you mean by "implemented"?
> 
> John

Well you know that's an interesting question, perhaps you should go ask
those who are claiming to be implementing or deploying EF what it is that
they meant;

For starters there is this Abilene press release that says they are
implementing EF on Cisco routers.
http://www.internet2.edu/abilene/qos/announcement.html

And there is a nice article in Cisco's Packet magazine about it as well
http://www.cisco.com/warp/public/784/packet/apr00/netizens.html

And the IOS 12.1 release docs are quite clear that EF is supported, its the
second RFC on the list.
http://www.cisco.com/warp/public/cc/general/bulletin/software/general/1189_p
p.htm

Since I see from your e-mail address that you work at Cisco, presumably you
can figure out who inside your company actually knows what Cisco's EF
implementation is like and ask them about it.

Of course it you don't know anyone in Cisco who is working with EF you could
ask one of the WG co-chairs, since I see from this talk about the testing of
EF at iCAIR that Brian Carpenter is listed as one of the collaborators
http://www.internet2.edu/qos/houston2000/proceedings/Mambretti/20000209-QoS2
000-Mambretti.pdf
And he's listed on the conference program next to this talk so he must know
all about it
http://sss.advanced.org/meetings/houston2000/

let me know if that answers your question, or if you would like me to
explain further...

jon

---

From: Toyanne Lauriston <[email-masked]>
Date: Fri, 15 Dec 2000 04:16:37 -0500

I believe the Charny-compromise should be called EF.  It builds on the EF
definition as described in the EF RFC.  It is unfortunate that the EF RFC
was written such that it was open to misinterpretation of the authors'
intent but that is water under the bridge.  Changing the name now will
introduce unnecessary confusion. 

Toyanne

-----Original Message-----
From: Brian E Carpenter [mailto:[email-masked]]
Sent: December 14, 2000 12:32 PM
To: demir
Cc: Diff Serv
Subject: Re: [Diffserv] Yesterday's EF discussion

Demir,

   Brian

demir wrote:
> 
> Shahram,
> I am not sure if what you stated was the industry's understanding. ...

---

From: ROBERTS James FTRD/DAC/ISS <[email-masked]>
Date: Fri, 15 Dec 2000 14:09:06 +0100

I think "expedited forwarding" is a more appropriate description for what is
defined than "defined rate". 

In my view the essential parameters of the PHB are the bounds E_a and E_p
rather than the rate R. This is true at least for an implementation using
priority queuing.

My choice would therefore be to keep the name EF.

Jim

---

From: John Schnizlein <[email-masked]>
Date: Fri, 15 Dec 2000 12:46:21 -0500

At 06:01 PM 12/14/2000 -0500, Ralph Santitoro wrote: 
>... vendors have already implemented their interpretation of  
>the 'EF' PHB and its associated 'EF' DSCP.  
>Therefore, the 'EF' term is proliferated in a variety of product 
>literature, whitepapers, marketing literature, engineering documentation, 
>training courseware and device/service configuration tools.

Which vendors?
What do you mean by "implemented"?
Whitepapers and marketing literature should follow (not restrict)
the standards language. I do not know a vendor that does otherwise.

John

---

From: Jon Bennett <[email-masked]>
Date: Fri, 15 Dec 2000 13:03:49 -0500

Brian,

> > Question to the chair, given that I said our intentions 
> were "to obsolete
> > RFC 2598" what was it that you were clarifying?  Or were 
> you just worried I
> > didn't know 'to obsolete' meant?
> 
> This snip from your earlier note seemed to me to suggest that 
> you thought
> I might be suggesting *not* to obsolete 2598, which was not 
> what I meant to imply:
> 
>   "I submit that leaving RFC 2598 unchanged as
>    the EF PHB and introducing draft-charny as the FOO PHB 
> besides violating the
>    WG charter is simply to ignore the consensus of the room." 

Ah I see, I was using the word 'unchanged' in an ambiguous manner, I was
just referring to changing the definition of EF from 2598 to the new RFC we
are going to write, not with changing the text of 2598. I was confused by
what you said since I assumed that given the frequency that I have been
quoting RFC 2026 over the last week or so that you would have known that I
knew you don't change an existing RFC....... you obsolete it.

jon

---

From: Jon Bennett <[email-masked]>
Date: Fri, 15 Dec 2000 16:08:35 -0500

John,

> >For me, Expedited Forwarding is an easy to explain reference to 
> >priority queuing, which by all accounts is a viable implementation 
> >of this PHB (with limits to protect other traffic, as stated 
> in 2598).
> 
> Yes, I suspect this interpretation of "implementation" is all 
> there is. I begs the question of how these implementations depend 
> on a rate guarantee over a fixed interval. Last time I looked, 
> priority queuing just drains the high priority queue at line rate.

Ok, let me explain to you why EF or any other PHB can't be "just priority
queueing" at least not if you want to build equipment that does anything
else beyond just doing EF. Consider the following issues, all of which are
considerations for me in the equipment I am building.

A) If you are building equipment to support "open access" i.e. multiple ISPs
sharing the same box, then you will have say 16 ISPs sharing the uplink back
to the network, each of these ISPs will want its own EF PHB, they are not
going to want to share a single EF PHB, and you can't service one ISP at
higher priority than another, so your service for the EF PHB will be based
on a bandwidth share of the output link and not based on priority access to
it.

B) If you are building equipment to support more than one instance of the EF
PHB at a time (within a single ISP's traffic) as you might want to do to
support different rate EF traffic or you have some EF traffic which is low
bandwidth/low jitter EF and some which is high bandwidth/moderate jitter EF.
In order to prevent the low jitter EF from making all other EF traffic into
high jitter traffic, the scheduling between the different EF PHBs can not be
done by strict priority but has to be by bandwidth shares.

C) If you are building equipment to support both Diffserv EF and Intserv GS
in the same device, and have many ports and/or channelized ports with EF
traffic you can not service the EF traffic with strict priority over the GS
traffic without impacting the delay/error bounds of the GS traffic. In
particular without route pinning for the EF traffic it would be impossible
to make any guarantees to the GS traffic because variations in the EF
routing could reduce the capacity below that needed to support existing GS
reservations unless rate based scheduling was used instead of priority
scheduling.

I could go on listing items, but the basic point is that in an actual
multi-service operated under real requirements, you can't go and say "EF has
the highest priority of all traffic", you can say "EF has the highest
priority of all traffic, within a given slice of the link bandwidth", and
that means we are talking about a rate based behavior and not a priority
behavior.

jon

---

From: "Fulu Li" <[email-masked]>
Date: Fri, 15 Dec 2000 17:02:11 -0500

Did you miss this email?
      
http://www2.ietf.org/mail-archive/working-groups/diffserv/current/msg02677.h
tml

 Regards,

Fulu Li

---

From: Martha Zimet <[email-masked]>
Date: Fri, 15 Dec 2000 15:15:28 -0800

I wish to add my vote to keeping the 'EF' name for the following
reasons:

1. A new name will imply a new PHB, which is contrary to what I
thought the recent WG goals were (e.g. fix and not re-create). 

2. Since the 'EF' PHB (RFC 2598) was a proposed standard for a length
of time, like other vendors, we have already implemented our version
of the 'EF' PHB and its corresponding DSCP based on our understanding
of the RFC.  This is realized in our current Nokia IPRG products,
network management infrastructure, documentation, training classes,
etc. 

3. Changing the name will be the most confusing to the those who are
not well versed in the underlying semantics in the first place.  In
addition, it will cause added overhead to those of us who are involved
in explaining and socializing diffserv in our respective corporate
environments.

Regards,

/martha

---

From: "Casati, Alessio (Alessio)" <[email-masked]>
Date: Sat, 16 Dec 2000 02:07:46 -0000

Couple of quick comments.

> thought the recent WG goals were (e.g. fix and not re-create). 
It appears that we do have a new PHB (or a couple
of them sold in the guise of one). At least this
is the conclusion the author of the PHB itself
came to, as faced with the proposal in the
charny and its "compromise ".

> network management infrastructure, documentation, training classes,
Implementing the EF DSCP must have been quite a 
deed :). Now, ideally you should comply with what
PHBs diffserv WG define. If names change
this should not matter if you comply with the
definition. The definition has changed. Your
implementation may or may not comply with it
(or display or not good values of E_a nd E_p).
Effectively, you may have designed your box
without caring about E_a or E_p as currently
defined. Good luck :).

> not well versed in the underlying semantics in the first place.
> 
The relation between the PHB name and its semantics happens to
be quite vague (what would you guess if somebody teels you
"assured forwarding"?)

>   In
well, this will really be the challenge that the
thing from the group of twelve will come with :).
It will first require putting folks thru some
discrete math classes. This opens up a whole new market
on its own :).

alessio

> http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist
> .html
>

---

From: "Casati, Alessio (Alessio)" <[email-masked]>
Date: Sat, 16 Dec 2000 02:56:19 -0000

Bruce, 

The consensus in the meeting-room was clear.
On the other hand this needs to be evaluated
thouroughly by the list (which is what the WG is, 
not the meeting-room). As such, some discussion
can still take place without you be entitled to
call this "ignoring WG consensus". WG consensus is now
being evaluated. This according to the IETF rules we 
(and you as well)know.

In the process of generating the replacement of
2598, a name that best fits the behaviour may be 
used. Practical considerations may suggest keeping
EF. Precision may not. 

alessio

> ----------
> From: 	Bruce Davie[SMTP:[email-masked]]
> 
> 
> One observation that I might make about the current debate on re-naming EF
> is that it resembles the debate in front of the WG on Tuesday. Proponents
> of
> EFRESOLVE are basically saying "draft-charny is a fine PHB definition, it
> just isn't EF" which is exactly what they said on Tuesday. I believe the
> WG
> voted to reject that position when it voted in favor of adopting
> draft-charny as the basis for a replacement for RFC 2598. So we seem to be
> simply rehashing an argument that was settled on Tuesday, with the same
> proponents on both sides. As has already been said, this is simply
> ignoring
> the WG consensus.
> 
> Bruce
> 
> 
>

---

From: "Casati, Alessio (Alessio)" <[email-masked]>
Date: Sat, 16 Dec 2000 07:08:47 -0000

> We have argued in SD that the definition we propose describes two
> different 
> *aspects* of the same behavior, rather than two different behaviors. Both 
> aspects of the behavior are useful in evaluating the quality of EF 
> implementations. In particular if you are interested in knowing just what 
> time scale your scheduler is providing the configured rate to the EF 
> aggregate (as RFC 2598 implied), E_a is of interest, while if you ask the 
> question about the delay of delay-variation bound for a given packet given
> 
> the constraints on the input traffic (as desired in EFRESOLVE), the 
> parameter of interest is E_p. These are simply two *measurements* of a 
> device, not two different devices. The fact that you may want two 
> parameters to describe the same behavior does not mean that you have two 
> different behaviors.
> 
To my understanding, since Bruce stated:

> under our "color-aware" definition when the offered
> load to an output is bounded by rate R and burst  size B, the maximum
> per-packet delay is B/R + E_p

the only interesting parameter is E_p, since this is giving the timescale up
to the crossover rate R (above R we don't mind, since we are outside
any conceivable EF use).

> I must tell you that whether or not one designed the box with E_a and E_p 
> in mind, the box, once built, will have
> some values of these parameters.
> 
This is obvious, an axiom :), but a vendor may spend time
and care to go on the market with stuff that better fit the new def,
isn't it?

>   If you want to use this device to build a 
> service which is quantifiable in terms of its worst case behavior, (as the
> 
> working group decided it wants the service to be described),  then you'd 
> better know how to reason about your device quantitatively. The knowledge 
> of the two  parameters E_a and E_p will enable you to do exactly that: 
> reason quantitatively about  exactly what service you can actually 
> provide.  To the best of my understanding, the parameter S in EFRESOLVE 
> definition had a rather similar purpose.
> 
S simply tells you how many packet times at the
expected input rate the delay variation bound is. A very
different purpose. If the expected rate changes, S changes.
the goal is to keep S*MTU/R at or below the desired value. 
I already stated my opinion on S many times.

>  For strict 
> FIFO schedulers E_p is strictly equal to E_a and so the compromise 
> definition does not add any extra complexity in that case.  We intend to 
> provide additional implementation guidance for non-FIFO devices as we
> write 
> the text of the replacement RFC.
> 
Implementation guidance? Probably you didn't want to say so :).
I would be reluctant to suggest you add implementation guidance.

> I think the difficulty of mathematics involved in our definition does not 
> exceed the level of mathematics involved in a leaky bucket policer, or any
> 
> of  the rate-based schedulers which are well understood in the 
> industry.  So I truly think you are giving far less credit to the people
> in 
> the WG than they deserve. 
> 
On the other hand, just for politeness, I would please ask if you 
could refrain from personal comments on my respect on the 
individuals of this WG. The humor underlying my statement on
supposed corporate environments math hardhips was clear 
(as it was in Bruce's message).

>  On the other hand,  a certain minimal level of 
> mathematical precision seems unavoidable if any quantifiable worst case 
> guarantees are desired at all
> 
I think we can/should come up with simpler, smaller, definition.

>  - and the working group clearly stated its 
> interest in such worst case guarantees. 
> 
I Agree, but a worst case bound on delay variation does not require
a system of discrete time equations to be defined, nor
a catalogue of E_a for some possible schedulers to be disseminated in
the industry as part of this PHB def. Laudable, yet unnecessary,
exercise. It should be an informational thing only, to be
published distinctly from this PHB definition.

regards

alessio

---

From: John Schnizlein <[email-masked]>
Date: Mon, 18 Dec 2000 10:25:25 -0500

At 05:02 PM 12/15/2000 -0500, Fulu Li wrote: 
>
> Did you miss this email? 
>      
>http://www2.ietf.org/mail-archive/working groups/diffserv/current/msg02677.html 

No, I did not miss it.
I am familiar with how Cisco supports the deployment of EF.
I am familiar with the diffserv testbed in Internet-2.
I do not see any dependence on the particular (mis)interprestation
of of Van's intended bound on delay variance in either.

My question seeks implementations that require a rate bound.

John

---

From: "Casati, Alessio (Alessio)" <[email-masked]>
Date: Mon, 18 Dec 2000 23:18:11 -0000

> . If you wish I can start posting 
> > > references to allthe Internet2 project documentation that specifies
> the
> BANDWIDTH broker
> > > operation and the SLA guarantees in terms of RATES and not 
> > > in terms of jitter, would you like me to do that?
> > > 
> > No, thanks. We can try and discuss anyway.
> 
> That's odd, why is it that you would not want me to do so? 
> 
If you like it better,
please post references. 

> > The SLA is a service level specification 
> > stipulated between two diffserv domains. 
> > Rate is a service level parameter, valid at 
> > the edge. Nothing can be said about the rate 
> > configured (if no PQ is used) within the domain, and that the rate 
> > guarantee per se is what is needed within  the domain. 
> 
> As for nothing being able to be said about rate unless PQ is
> used,
> 
(please re-read, I said that when no PQ is used, it's hard to tell which
rate will be used some hops in the net based on a rate offered at the
ingress
of the net)

[snip]

> > The way this is possible is via PHB that allows 
> > aggregation of a number of customer networks 
> > in a way that they do not affect one another. 
> > This is possible via a PHB
> > that provides strict guarantees in terms 
> > of delay variation across a hop.  
> > This is the only way that allows aggregation
> > without uncontrolled burst accumulation, 
> > that would result in the service not being delivered 
> > end to end to the customer network
> > asking for a "virtual wire".
> 
> Your argument is both circular and untrue. It has been shown that with
> FIFO/PQ service that you do not have control over the burst accumulation
> on
> a local level , and that only through network level controls can you
> achieve
> such control. 
> 
the network is made of hops and boundary devices.
here we are saying what is needed at the hop level.

> So a PHB can not make the guarantees that you want, this is a
> proven fact. 
> 
Yeah, but if you pick the wrong PHB...
Gotta be careful.

>  Repeated assertions by you to the contrary can not change
> this.
> 
Especially If I don't make them.

> No, the low jitter is an end-to-end SERVICE, the provisioning of an output
> rate IS the essence of the PHB as the RFC says.
> 
> 
OK, so why your Internet2 SLAs did not mention the
jitter? You stated that... Go at the top of this message.
This is becoming a sad story to tell.

alessio