Subject: RE: [Diffserv] need for clear definition of "assurance" in EF

From: "Manfredi, Albert E" <[email-masked]>
Date: Mon, 11 Dec 2000 10:37:56 -0500

Alper Demir wrote:

> In Introduction of EF PHB, the "assured bandwidth" phrase is 
> used. I think
> this is misleading and "inaccurate". In AF, assurance is 
> "different levels
> of forwarding assurances for IP packets received from a customer DS
> domain". Where as, to me, in EF, "assured bandwidth" has 
> different meaning  
> ("available"?) (you might say that "assured" bandwidth makes it
> assured bandwidth. However "assured" forwarding in AF doesn't make it
> assured forwarding (assuming "underprovisioned" and/or "traffic
> conditioning" failure). 
> I agree they are just "words". It would be nicer to make 
> words clear to
> understand.
> I have already made my point on providing "assurance" level 
> for EF if one
> choses to use it (fundamental change :) However, it seems it's okay to
> change EF's constraint from "rate" to "delay", "delay 
> variance". What is
> the limit of "expedited"? "no delay", "no delay variance" :) 
> for a packet?
> "philosophical" change is fine, but "fundamental" is not fine?

Perhaps I'm reading more into this than I should, but I believe that the
practical difference between EF and AF is that EF is intended as a means of
making the Link Layer provide CBR-like services, e.g. for UDP flows, whereas
AF is meant to use TCP feedback mechanisms to provide a continuum of
"assurances," from best effort to something that could be essentially the
same as EF.

Bert

_______________________________________________
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: Mon, 11 Dec 2000 10:29:34 -0600

Hi,

This discussion is getting off target, in fact it seems more like
one for the diffserv-interest list.

   Brian

demir wrote:
> That is an "interesting" intention. It seems both AF and EF PHB have
> already picked their "transport" protocol. What if I use "TCP-friendly
> rate adaptive" protocol based on UDP and want to get a service based on AF
> PHB or I use TCP and ask for a service based on EF PHB (I have no idea
> why? for reliability?)? I have mentioned that it is not a good idea to
> "embed" services into PHBs. The respose was that EF is intended for
> "expedition". I don't have any problem with accepting that (still
> believing that this should also be avoided if there is a network-dependent
> parameter cause a PDB can achieve this goal anytime, everywhere). Now,
> there is another property of EF assumes "CBR-traffic" meaning what kind of
> traffic EF is expecting? There are alot of "mistery" behind EF PHB.
> 
> Alper K. Demir
>

---

From: demir <[email-masked]>
Date: Mon, 11 Dec 2000 07:57:41 -0800 (PST)

Alper K. Demir

---

From: Grenville Armitage <[email-masked]>
Date: Tue, 12 Dec 2000 12:23:24 -0800

demir wrote:
	[..]
> already picked their "transport" protocol.

No, they haven't. Bert is observing that the key behavior
provided by AF is three levels of drop precedence (quite useful
to TCP or TCP-like congestion control algorithms) while the behavior
desired of EF is predictably bounded delay variance (useful for
loss-intolerant or non-reactive apps).

cheers,
gja

---

From: demir <[email-masked]>
Date: Tue, 12 Dec 2000 12:56:21 -0800 (PST)

Grenville,
I don't have any problem accepting the fact that what apps is more
suitable for what PHBs. My point was that it doesn't seem reasonable to
relate "transport" protocols to them. I agree, there is a trend on
that. It is a matter of choice that should be left to apps. I understand
your points.

Alper K. Demir