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

From: Shahram Davari <[email-masked]>
Date: Thu, 14 Dec 2000 09:00:43 -0800

Demir,

I think the industry's understanding of EF is what is in RFC-2598, which is a rate-based service in which the arrival rate is less than departure rate in small intervals. Since the language used in RFC-2598 was not very accurate, in the sense that it didn't cover some valid scenarios, the work group's intent was to lay a clear definition that covers those valid scenarios, and  at the same time does not deviate from the industry's understanding of EF. So the intent was to keep the EF PHB behavior but to give a more accurate definition. 

Yours,
-Shahram 

> -----Original Message-----
> From: demir [mailto:[email-masked]]
> Sent: Thursday, December 14, 2000 12:44 PM
> To: Nabil Seddigh
> Cc: Brian E Carpenter; Diff Serv
> Subject: Re: [Diffserv] Yesterday's EF discussion
> 
> 
> Nabil,
> > However, there is another group of people to consider. I'm 
> thinking of
> > the multitudes of developers, product  managers, network engineers,
> > sales, marketting folks etc  who are not on this list. It 
> has taken a
> > while to get terms like EF and AF socialized, understood 
> and adopted.
> > IMHO, adding a new name may cause more confusion than clarification.
> 
> I agree with above statements. However, what is their understanding of
> "EF"; yet, there is no "agreement" in Diffserv group on "EF"?
> 
> Alper K. Demir
> 
> 
> _______________________________________________
> 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

_______________________________________________
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: Brian E Carpenter <[email-masked]>
Date: Thu, 14 Dec 2000 11:31:40 -0600

Demir,

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

   Brian

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

---

From: demir <[email-masked]>
Date: Thu, 14 Dec 2000 09:28:52 -0800 (PST)

Shahram,
I am not sure if what you stated was the industry's understanding. Let me
quote something taken from "The `Virtual Wire' Per-Domain Behavior" draft
(you can see the same info at RFC 2598): 
"[RFC2598] describes a diffserv PHB called expedited forwarding 
(EF) intended for use in building a scalable, low loss, low 
latency, low jitter, assured bandwidth, end-to-end service that 
appears to the endpoints like an unshared, point-to-point connection or
`virtual wire.'"
I assume, that was the "industry's understanding" of EF. What
happened? It was claimed that this "rate-based" definition was not enough
to define such services in a "expedited" manner. As a result, there has
been discussions: one "delay-oriented expedited" approach, other "delay
variance-oriented expedited" aproach. What "expedited" meant is "low
jitter" (RFC-2598). There is a tendency to "use" B. Davie and
draft-charny's (and group's) this "delay-oriented" approach cause it has
roots to "rate".
If this "delay-oriented" approach will have the "EF" name, it would be
VERY VERY confusing (I know they are just names).
My suggestion is: To keep EF for its "low-jitter" expedition. Forget about
old "rate-oriented" "EF" and all "rate" related names. Use a different
name for the new one (my suggestion is: "Destined Forwarding").

P.S. "assured bandwidth"'s 'A' is not the same as "assured
forwarding's" 'A'. It would be better to use another word for "assured
bandwidth"'s 'A'.

Alper K. Demir

---

From: Jon Crowcroft <[email-masked]>
Date: Thu, 14 Dec 2000 17:43:16 +0000

1/ there is no ONE industry so this is wrong - the EF resolution
show of hands in the room  chose to take an interpretation of the rfc which 
is as you say - however, people should remember that there was acutally a very 
complex rich argument behind Van's original model which we've now lost - the model
was not a CBR service (classic telco industry) with a rate but delay and delay jtter
"to be defined"....because Van, unlike some of you, had considered the entire business case
for an IP provider from the user requirement, down to the wire and routers.....

If you are an ISP that owns your level 2 network (like many of the incumebbent telos that have succesfully
deployed IP too), there's ZERO need to offer this new service as an IP level implemented service.
if you are not, then its ggonna be hard to in some cases - van's service and phb (flawed as the explanation was)
did actually have abusiness case - the colour aware "compromise" might be pulled out to do this perhaps, but its
not the same PHB or the same VW combinastion that you seem to think industry understands, so we necessarily will have
at least 2 PHBs and i believe at least two services

i dont care what they are called personally, as brian said, goo and bar would do nicely
(actually i have a hard time understanding the word "expedtited" anyhow, let alone speliong it:-)

btw:
the nearest i can think of the service, PDB, and colour blind spec being used ffor is some thing frame relay folks call
committed information rate...

 >>> http://www2.ietf.org/mail-archive/working-groups/diffserv/curr

 cheers

   jon

---

From: Geoff Huston <[email-masked]>
Date: Fri, 15 Dec 2000 06:18:25 +1100

>do we change the name or not?

I'd suggest that while 'EF' may have a certain meaning to many here on
this list, to many others its still 'expedited forwarding', which as a
pair of words is not the full story with this intended service.

You want to hear from those who have been observers so far?
ok - I believe it would be appropriate to change the name!

thanks,

    Geoff

---

From: Dave McDysan <[email-masked]>
Date: Thu, 14 Dec 2000 19:15:19 -0500

I would like to keep the name EF for the Charny compromise for the reasons
stated in prior Emails. None of the name changers present a compelling
argument.

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).

Dave

> From: [email-masked] [mailto:[email-masked]]On Behalf
> Of Brian E Carpenter
> Sent: Thursday, December 14, 2000 12:32 PM
> To: demir
> Cc: Diff Serv
> http://www2.ietf.org/mail-archive/working-groups/diffserv/current/
maillist.html

---

From: Anna Charny <[email-masked]>
Date: Thu, 14 Dec 2000 20:53:41 -0500

Brian,

I  believe the new document replacing the RFC 2598 should keep the name EF.
I have nothing to add to the arguments already expressed on the list.

Anna

---------------------------------------
Anna Charny
Cisco Systems, Inc
300 Apollo Drive
Chelmsford, MA  01824
Tel. (978)-244-8172
Fax (978)-244-8126

---

From: Constantinos <[email-masked]>
Date: Thu, 14 Dec 2000 20:03:58 -0600 (CST)

> do we change the name or not?

I guess I was in the silent majority for a while..

My opinion is to not change the name. It is a rather major change
to abandon the EF term, now that the working group should be 
approaching the end of its tasks.

Regarding the EF issue in general: Whether the issue that came up 
with the EF RFC is important for the industry or not, it remains to
be seen. If there is indeed a problem of interoperable implementations
and strictly verifiable SLAs, then the EF PHB will not be used,
and later on, a Diffserv II working group for instance, may attempt 
a different definition/term/architecture. If on the other hand the
router vendors and the network providers start using the EF PHB
then our concerns about it may prove to be unimportant.

Just my 2 cents,
 
-- 

Constantinos

----

http://www.cae.wisc.edu/~dovrolis

---

From: demir <[email-masked]>
Date: Fri, 15 Dec 2000 05:47:32 -0800 (PST)

This "compromise" has two parts:
D(j) < B/R  + E_p  (color-aware) - Delay constraint 
d(j) < F(j) + E_a  (color-blind) - Rate  constraint
F(j) = MAX(a(j),MIN(d(j-1),F(j-1))) + L(j)/R

1) In this "specific" choice on "delay constraint" and "rate constraint" 
"Efficiency" of "delay constraint" depends on the choice of R that also
will have an impact on the choice of B where both choices will have an
impact on "loss rate". Is it okay to "standardize" this by Diffserv group?
  Note: If so, 
        i) It seems to me that defining B as:
           B = SIGMA Bi, where Bi is the B of the ith input interface
           would provide some "flexibility".
        ii) Above relations should be clarified

2) "Rate constraint" reminds me discussions on "Fair Queuing". I believe,
there are other ways to achieve "rate constraints" of EF in short-time
scales. In this specific choice, "packet scale MAX-MIN rate guarantee R
with latency E_a" is chosen. Is it okay to standardize this "rate
constraint" by Diffserv group? (RFC-2598 has already achieved this)

3) It seems it is okay to "formulize" "delay constraint" by Diffserv
group. I don't have any problem with accepting this. The choice of B will
give lots of "flexibility"( Still, I believe, as an RFC this should left
to implementations. There are "references". Let me relate this to AF
PHB. I know they are intended for different purposes. I already said I
don't have any problem of accepting this. AF doesn't standardize RIO,
RED. However, it gives RIO, RED as a "specific" mechanism. I don't assume
that someone who is supporting AF will come up with new mechanism to
"replace" RIO other than someone from academia. RED is on the way to be
accepted as AQM universally. However, for this new proposal, neither is on
the way to be accepted as universally.

4) isn't this new proposal  something new defined (more "expedited" than
RFC-2598)?

My 2 cents,

Alper K. Demir

---

From: John Schnizlein <[email-masked]>
Date: Fri, 15 Dec 2000 13:00:17 -0500

At 07:15 PM 12/14/2000 -0500, Dave McDysan wrote:
>
>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.

John

---

From: Dave McDysan <[email-masked]>
Date: Mon, 18 Dec 2000 09:37:04 -0500

This was the text in RFC 2598 that I was referring to:

   If the EF PHB is implemented by a mechanism that allows unlimited
   preemption of other traffic (e.g., a priority queue), the
   implementation MUST include some means to limit the damage EF traffic
   could inflict on other traffic (e.g., a token bucket rate limiter).
   Traffic that exceeds this limit MUST be discarded. This maximum EF
   rate, and burst size if appropriate, MUST be settable by a network
   administrator (using whatever mechanism the node supports for non-
   volatile configuration). The minimum and maximum rates may be the
   same and configured by a single parameter.

Dave

> From: John Schnizlein [mailto:[email-masked]]
> Sent: Friday, December 15, 2000 1:00 PM
> To: Dave McDysan
> Cc: Diff Serv
> Subject: RE: [Diffserv] Yesterday's EF discussion
> 
>