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

From: Shahram Davari <[email-masked]>
Date: Thu, 14 Dec 2000 07:24:19 -0800

Hi All,

Since,

1) The Charny-compromise is the closest to the RFC-2598 (as was expresses by overwhelming consensus), 
2) It is essentially the same behavior as RFC-2598 (output rate-based definition), but has a more clear definition for all possible scenarios.
3) Implementers already know and have implemented EF and its rate-based definition and therefore changing the name would create confusion.

Therefore I vote for keeping the EF name.

Yours,
Shahram Davari
Systems Engineer
Product Research Group
PMC-Sierra, Inc. (Ottawa)
Phone: (613) 271-4018
Fax:    (613) 271-7007

_______________________________________________
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: "Scott Brim" <[email-masked]>
Date: Thu, 14 Dec 2000 10:14:31 -0800

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

---

From: Grenville Armitage <[email-masked]>
Date: Thu, 14 Dec 2000 10:29:06 -0800

Shahram Davari wrote:
	[..]
> 3) Implementers already know and have implemented EF and its
> rate-based definition and therefore changing the name would
> create confusion.

This part has always intrigued me - the assertion that
people have 'implemented EF'. I'd be willing to believe
schedulers were implemented, and the implementors know
the operating ranges over which their schedulers can
provide a rate-based EF behavior. But to say all these
queue/scheduler implementations out there will suffer an
identity crisis because the target behavior is more
precisely renamed 'Defined Rate'..... unconvincing.

cheers,
gja