Subject: RE: [Diffserv] Possible compromise between EFRESOLVE and draft-ch arny

From: "Manfredi, Albert E" <[email-masked]>
Date: Sun, 10 Dec 2000 17:53:53 -0500

Anna Charny wrote:

> Alessio Casati wrote:

> > > - non-FIFO treatment of EF will typically lead to a large 
> value of S
> > >
> >It appears this concern was addressed on the list and
> >multiple voices supported that this point was not valid.
> >As such we don't need to discuss about this further.
> 
> Do you mean to say that it is not true that devices with 
> non-FIFO treatment 
> will have large S, or that it is not important that they have large S?
> 
> I would also like to point out that  there were also multiple 
> voices on the 
> list that supported the opinion that this point was valid, so 
> I suggest 
> that we need to address this question
> with a more technical discussion.

I'm afraid I don't understand the controversy regarding S.

EFRESOLVE states that EF is defined as an aggregate flow for which the
difference between minimum possible delay and the maximum possible delay is
bounded by some number S X MTU transfer time when the arrival rate of this
incoming EF aggregate flow is specified as R.

The underlying idea of EF, whether we can state this or no, has always been
(has it not?) to support a service similar to CBR, or approaching CBR, for
an aggregate flow. So S will determine how CBR-like this EF flow will be.

If some non-FIFO schedulers will result in large values of S, seems to me
that those schedulers are simply not ideal for EF use. Why is this an issue?

> We are concerned, however, that the 
> decision of the 
> team to use the  input rate only makes it difficult to generalize the 
> definition to a device with a range of interface speeds in a 
> way meaningful 
> in the diffserv environment. While it is possible that we 
> misunderstand how 
> you plan to address this issue, we have not been able to get any 
> clarification of this (and in fact at least two members of 
> your team have 
> acknowledged that such generalization is not obvious).
> 
> It may help if you can give the answer to the following questions.
> Can you please let us know what is the maximum input rate R 
> that a device 
> can support in the case of multiple speeds of  interfaces, 
> when the device 
> is just characterized by a single value of R  (your draft 
> says that this is 
> the speed of the slowest interface - do you believe it is 
> correct?).

Wouldn't the total EF arrival rate at the box be R? And if so, if the speed
of the slowest egress >= R, then haven't we guaranteed that the delay
variation will remain bounded?

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: demir <[email-masked]>
Date: Sun, 10 Dec 2000 22:37:38 -0800 (PST)

What is the "limit" of EF's (EFRESOLVE's) "misterious" properties that is
"stepped further" whenever a new argument is made? (I know EFRESOLVE is
only a draft).

> an aggregate flow. So S will determine how CBR-like this EF flow will be.

Where is this underlying idea stated?

> that those schedulers are simply not ideal for EF use. Why is this an issue?

To me, it seems that "EF" dominates everything. It seems without
understanding "EF", one can not implement Diffserv-compatible boxes/other
PHBs. (I am aware of the your argument saying that: then forget these
scheduler, that's diffserv. If that is the case then Diffserv 
dominates a box, is this "scalable"?). Everything will depend on "EF". 

Alper K. Demir

---

From: "Bill Courtney" <[email-masked]>
Date: Mon, 11 Dec 2000 06:50:07 -0800

Hi Bert,

> an aggregate flow. So S will determine how CBR-like this EF flow will be.

The controversy is based on the fact, as two or three earlier posts
have established, that *perfectly fine schedulers* can have values of S
that are orders of magnitude greater than the values for *less
desirable schedulers*. (See, for example, some of Jon Bennett's
mailings from near the time of efresolve's release.) By "perfectly
fine," I mean schedulers that introduce little or no jitter or delay,
and by "less desirable," I mean schedulers that introduce more
jitter. Jon's examples and other similar difficulties with S are by no
means exotic or unusual examples.

So, S does not provide a useful measure of the worth of a
scheduler (i.e., large values might mean anything), and a
value of S can be found for almost every scheduler. Thus,
efresolve offers us a definition that admits virtually
everything and fails to make any useful distinction among
the things it admits.

> that those schedulers are simply not ideal for EF use. Why is this an
issue?

The large values of S may have nothing to do with the
usefulness of those schedulers for EF, or they may.
It depends on the scheduler. Thus, S is a very poor
discriminator.

I, too, am mystified as to why there is still an issue.
I would have thought that efresolve would have been
discarded as an irredeemably failed attempt long ago.

Cheers,
Bill

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 11 Dec 2000 10:10:41 -0600

We decided a couple of weeks ago that
a) the EFRESOLVE S should be renamed Scale instead of Score
b) it is not a figure of merit but merely a bound that must exist as a finite value

So I suggest we stop asking the same question repeatedly.

  Brian Carpenter
  diffserv co-chair

---

From: demir <[email-masked]>
Date: Mon, 11 Dec 2000 09:22:49 -0800 (PST)

Brian,
I think whatever name EFRESOLVE uses for S other than B, it is not for
"intended expedite" which is not clear yet. As long as this "finite
bound" S remains bounding "delay variance" (D(i) - E(i)), EF PHB will
dominate every other PHBs and every diffserv-compatible box. That means
without understanding EF, it won't be possible to implemet other PHBs
(currently, there is no problem with AF, but there could be others). May
be instead of Expedited PHB, "Entry" point PHB for Diffserv :) would be a
better choice :) If that is fine with Diffserv, then there is no need to
discuss futher.

Alper K. Demir

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 11 Dec 2000 13:16:54 -0500

In order to get this result, you have to use "jitter or delay" relative to 
something different than what we believe the purpose of EF uses it to mean.
It is certainly true that if what one cares about is the proportional 
distortion of substreams of the aggregated EF, one can get highly 
desireable results that have a large S.
There are many contexts (including those where one has chosen to accept 
very large bursts) where a large S device is perfectly acceptable.

However, I have not yet seen any example of a situation where, for the 
purposes that most of us understand EF to be for, a small S device will be 
worse than a large S device.  That does not mean it will be better, but I 
have to disagree with Bill's assertion that these smaller S devices are 
"less desirable" schedulers.  They may not be any better for the actual 
environmental problem.  That is why it is hard to decide whether to say 
that S is a figure of merit or not.
But that does not mean that it is not a useful description as this message 
attempts to suggest.

Yours,
Joel M. Halpern

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 11 Dec 2000 13:35:17 -0500

I am not sure what you are getting at.
Assume we have an EF RFC (new, old, different, ...).  Why would this 
"dominate every other PHBs and every diffserv compatible box".  A device is 
not and will not be required to implement / support EF.  That is up to the 
implementor.  It is likely the case that support EF will have an impact on 
the design of a device if the implementor has chosen to support it.  But 
that does not mean that it dominates or even affects every 
diffserv-compatible box.  No particular PHBs are mandatory to implement.
Yours,
Joel M. Halpern

At 09:22 AM 12/11/00 -0800, demir wrote:
> > > > difference between minimum possible delay and the maximum possible 
> delay
> > > is
> > > Archive: 
> http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html
> >
> > Archive: 
> http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html
> >
>
>
>Archive: 
>http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html

---

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

Joel,
> diffserv-compatible box.  No particular PHBs are mandatory to implement.

What I mean by "domination" is "degree of impact". I was refering to
EFRESOLVE. If it is not implemented, there is no "impact", degree=0 (no
domination). It is "obivious" that EF PHB will have an impact on any
Difserv box. I don't think that "degree of impact" will be the same for
new, old, or different. And I added, if that is fine with Diffserv, there
is no need to discuss (I believe this shouldn't be okay).

Alper K. Demir