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

From: "Casati, Alessio (Alessio)" <[email-masked]>
Date: Sat, 9 Dec 2000 14:26:01 -0000

Bruce, 

we would like to summarize the position
on the criticisms.

> Among the criticisms of EFRESOLVE were
> 
> - it doesn't define behavior of a node outside of its operating region
> 
This is a deliberate choice. We don't want to constrain
implementations behaviour outside the
operating region. Anything like drop and notify performance
management subsystem could be fine. This is more
dependent on the service goals, and this is outside
the scope of our work.
 
> - 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.

> - S is not a good figure of merit, since non-ideal scheduling and non-FIFO
> service are lumped in the same parameter; also very good devices with
> large
> number of ports will look worse than small devices with bad scheduling
> implementations
> 
The list suggested that if a box provides smart features that
handle the EF aggregate at flows level, then why not to boast it
in your brochures an claim EF++ capabilities?
Our definition is not intended to cover particular marketing needs.

> - it is not yet clear how to generalize the defintion to the multiple
> input,
> multiple output case
> 
The team considered the definition to apply to
an (input,output) pair. Any EF or non EF traffic
towards the same output interface would be considered as 
competing traffic, in order to deliver the desired behaviour.

> - it allows arbitrarily large fixed delay (which isn't visible in a figure
> of merit)
> 
Indeed, the current definition allows for it.  
Fixed delay is not a concern since it is a parameter 
evaluated by the market independent from EF
definition. We don't want to act on this.

Summarizing, we have carefully considered the
criticisms, and evaluated
the  answers above would address them.

regards,
alessio

_______________________________________________
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: Anna Charny <[email-masked]>
Date: Sat, 09 Dec 2000 10:48:52 -0500

Alessio,

>dependent on the service goals, and this is outside

Can you summarize your objections to having the behavior specified
for any operating region as a function of the parameters of this operating 
region?

Also, you say that a number of actions you specify above "would be 
fine".  Could you please explain why you are not concerned about the 
possibility that undefined behavior at some node (even it network 
management is notified, but the packets are not dropped), may result in 
cascaded undefined behavior downstream?

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

>Our definition is not intended to cover particular marketing needs.

I am not sure how your statement about smart features addresses the fact 
that S, which is advertised as a figure of merit, does not appear to be one?

Also, can you please summarize objections to actually having a figure of 
merit as part of definition?

I would also like to repeat my suggestion that in the case where opposing 
opinions have been given on the list, we refrain from using the mere fact 
of the existence of people supporting a given opinion as a proof that this 
opinion is correct.  It seems a technical argument addressing the issue 
itself might be more appropriate to resolve the differences.

>competing traffic, in order to deliver the desired behaviour.

We understand that.  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?).  Can 
you also describe how to specify the rate constraints in this case when you 
want to describe the device by multiple constraints of R, as your draft 
suggests should be possible?  I hope your answers might help clarify these 
issues.

>definition. We don't want to act on this.

This indeed can be easily fixed by simply specifying what the fixed delay is.

>the  answers above would address them.

I look forward to getting your answers to my questions above.

Best regards,
Anna

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

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

---

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

Thanks for the reply, Bill.

Bill Courtney wrote:

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

If a more "desirable scheduler" creates values of S that are orders of
magnitude greater than "less desirable schedulers," then there can only be
two possible situations that come to (my) mind:

1. The more desirable schedulers introduce a lot more delay variation than
lesser schedulers, or

2. The more desirable schedulers introduce a lot more deterministic delay
then lesser schedulers.

Perhaps we should all first agree as to what EF is for. In my view, both 1
and 2 are bad for EF, so the "lesser schedulers" are perhaps more
appropriate. Maybe "more desirable schedulers" needs to be defined better.
Or perhaps we need two variants of EF -- one that minimizes jitter at the
expense of latency, the other than minimizes latency.

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

<Chuckle>

Bert

---

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

Anna,

> for any operating region as a function of the parameters of this operating
no such objection has been raised. In fact, 
a manufacturer can do so. EFRESOLVE does not constrain this
(and if you find verbage preventing this, it would be
good so that we can have a better quality standard).
But "any" needs to be better qualified: "any operating region the
manufacturer is certifying the Box for" would be a better
wording.

> cascaded undefined behavior downstream?
It happens in real world that now and then some glitches
show up. The management subsystem detects them and
corrective actions are (or may be) taken.
The goal would be minimizing such glitches. The action taken in
response to glitches may be optimized as a function of the service
(and may be global, or local).

> with a more technical discussion.
Anna, the goal of the PHB is to bound delay variation
to the S*MTU/R value. Clearly, if the bound we are
talking about needs to be the same for FIFO or
non FIFO, S*MTU/R needs to be the same. A greater S
implies you are considering a smaller R. So, people on the
list acutely observed that the comparison was between
apples and oranges (or Apples and EF).

> that S, which is advertised as a figure of merit, does not appear to be
I also don't understand the way our definition would be subverting the
commonsense of a router buyer... I have no additional comments. 

> merit as part of definition?
S*MTU/R is  the promised bound on delay variation. It is possible to
compared S values if the values of burstiness,
Rate and MTU. Otherwise it does not make sense
(apples and oranges). I would also support that it is difficult to
obtain a "figure of merit" based on which to rank
routers. So, I would be cautious in going down this path.

> opinion is correct.  
"presidentials elections" syndrome going on here :)...

> acknowledged that such generalization is not obvious).
this is the text (by the way, nothing is obvious
in EF, and I would be scared of a definition that
would look so):

    In the absence of additional information, R 
    is assumed to be limited by the slowest interface on the device.

    In addition, an EF device may be characterized by different values of
    R for different traffic flow scenarios (for example, for traffic
    aimed at different ports, total incoming R, and possibly total per
    output port incoming R across all incoming interfaces).

So, if there are additional informations we don't imply R to be the 
same for all Input output pairs.

> the speed of the slowest interface - do you believe it is correct?). 
> 
Our draft is much more detailed than this. Please text above
for a better understanding.

>  Can 
I think I need help to understand this question
(I may misinterpret it, and I would not
like to appear to have given the wrong answer)

> This indeed can be easily fixed by simply specifying what the fixed delay
It is not the EF PHB role to define this.

> I look forward to getting your answers to my questions above.
I hope I've been sufficiently helpful. 

alessio

---

From: GARBISU Jean-Pierre FTRD/DMI/CAE <[email-masked]>
Date: Mon, 11 Dec 2000 18:05:44 +0100

so many flames that one can doubt about reaching an agreement satisfying
both camps 
you can't have two presidents ;-) but perhaps two EF "like" PHB... 
are there some supreme wise (wo)men participating to diffserv tomorrow :-)
cheers

[email-masked]

---

From: ROBERTS James FTRD/DAC/ISS <[email-masked]>
Date: Mon, 11 Dec 2000 18:51:50 +0100

> ROBERTS James FTRD/DAC/ISS wrote:
> ...
> > If, to simplify, we assume there is only EF traffic in the 
> network and the
> > routers provide perfect FIFO output queuing, is it then 
> possible to come up
> > with the "network calculus" necessary to quantify how 
> burstiness evolves
> > from node to node and how it impacts the necessary bound S? 
> Current research
> > (the previously cited paper by Charny and Le Boudec and 
> references therein)
> > would suggest this is extremely difficult or even impossible.
> 
> We are not attempting to solve research problems, and we all hopefully
> agree that this "network calculus" is a research problem. Our job is
> very limited: specify a well-defined behaviour with some measureable
> properties. Requiring that we understand all the implications of a
> non-existent network calculus for compositions of this behaviour
> is by definition impossible. So we are going to re-specify EF without
> attempting the impossible. We're engineers.
> 
>   Brian Carpenter
>   diffserv co-chair
> 
> 

It seemed to me that EFRESOLVE requires network calculus to specify what is
meant by tolerable burstiness. For instance, I think it is not sufficient to
use a token bucket if you can't predict how bucket parameters evolve as EF
flows progress through the network aggregating and splitting in a fairly
arbitrary manner. How can you measure this burstiness and if you can't, how
can the behaviour be well defined?  

It seems the modified rate guarantee definition successfully avoids the need
to specify or measure burstiness. It defines a behaviour which can be
reasonably interpreted in a literal sense as "expedited forwarding", ie, it
approximates work conserving FIFO scheduling to within the tolerance defined
by the E bounds. It looks to me like a reasonable engineering solution.

Jim

---

From: ROBERTS James FTRD/DAC/ISS <[email-masked]>
Date: Mon, 11 Dec 2000 22:14:32 +0100

> scheduling, we see that
>      S = 6.4
> 
> So, can we stop saying that we can not calculate S or that 
> all reasonable 
> schedulers give large S.
> 

A delay of 6.4 seconds _is_ large for most of the applications I was
thinking about like VoIP.

And if the burstines of the aggregate leaving the router you consider is
bounded, what about the burstiness of the particular EF pipes splitting out
from that aggregate at the next router? And the burstiness of the output
from that router? And so on? There is an exponential increase in burstiness.
Except that the first router is probably the last router in the path of
other aggregates so that it not even possible to make iterative
calculations.

It really is not simple to understand how worst case burstiness propagates,
even in the absence of non-EF traffic.

Jim

---

From: ROBERTS James FTRD/DAC/ISS <[email-masked]>
Date: Mon, 11 Dec 2000 22:20:03 +0100

I'm sorry. This was a stupid error. S is of course a number of packet times.
Jim

---

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

S is not in units of seconds.  S is in units of inverse packets (which is 
probably best thought of as dimensionless).
Yours,
Joel M. Halpern

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Mon, 11 Dec 2000 17:36:01 -0500

> from that router? And so on? There is an exponential increase 

True. That's why some on this list have been suggesting that shapers might
be required in the core of DS nets.

Bert

---

From: ROBERTS James FTRD/DAC/ISS <[email-masked]>
Date: Tue, 12 Dec 2000 10:43:16 +0100

Guven,

> I would like to believe that you are making the above
> comments in the absence of a specification on how the
> EF aggregate is formed.
> 
> Also, if micro flows are individually spaced at the
> ingress then I would like to think that we can bound
> the burstiness as a function of routers traversed
> however the splitting and merging occurs provided that
> the loading resulting at each output remains below the
> input rate R.
> 

I was referring to the calculation of worst case burstiness necessary to
define deterministic bounds. Rereading your draft from July, I imagine you
are thinking more in terms of probabilistic bounds, eg, the probability end
to end delay is greater some bound D should not exceed epsilon. I would
certainly agree that this is a more satisfactory approach. 

However, even here, I don't think it is possible to characterize burstiness
at interfaces within the network. At least not in terms of maximally sized
bursts or an envelope arrival function like that defined by a token bucket. 

This was a problem considered in the context of ATM where CBR connections
are characterized in terms of the GCRA (almost a token bucket). I am not
aware of any work successfully explaining how the GCRA parameters should
evolve as the CBR stream acquires burstiness along its path through the
network. This is an unsolved problem.
 
In your draft, if my interpretation is correct, you assume the acquired
burstiness is negligible in the sense that you can assume (M+D)/D/1 queuing
at any node to derive the statistical delay bound. In this way you do not
need to characterize burstiness in a quantifiable way. I am inclined to
agree with you and we have some work which claims more or less the same
thing. 

To justify your probabilistic arguments you assume first that the EF
aggregates only interfere with each other in FIFO queues. You then consider
the impact of non-EF packets assuming priority queuing. It seems to me
therefore that you should be agreeing with me that an EF PHB definition
allowing a clear expression of these assumptions is preferable to one which
relies on an unspecified characterization of burstiness in order to justify
deterministic bounds.
     
Jim

---

From: ROBERTS James FTRD/DAC/ISS <[email-masked]>
Date: Tue, 12 Dec 2000 10:56:02 +0100

> be required in the core of DS nets.

Exactly what would you shape? 

If you shape the whole aggregate on an incoming interface to a configured
rate, you typically add more burstiness to the component sub-aggregates
going to the different outgoing interfaces. It is the latter burstiness
which needs to be accounted for in calculating the delay bounds.  

To shape the sub-aggregates individually seems to be contrary to the
Diffserv principles.

Jim

---

From: [email-masked]
Date: Tue, 12 Dec 2000 13:21:07 -0800 (PST)

Jim,

> certainly agree that this is a more satisfactory

May be that design team should seriously consider this
approach.

> network. This is an unsolved problem.

First consider just one hop. Couldn't we simply set
the GCRA parameters as the reciprocal of  the stream
rate and the D as the tolerance? The probability that 
a given packet not complying be less than epsilon. At
multiple hops, determine the corresponding delay bound
and used that as a tolerance. Is there anything 
wrong with this thinking?
 
> agree with you and we have some work which claims

But when all micro-flows are properly controled at the
ingress, and say that they are spaced, any burstiness
is due to phase coincidences. Under the circumstances
why do we have to need to characterize the burstiness.
I do like calling this burstiness. I rather refer to
it as jitter accumulation. I suppose you refer to it
as negligible. Given my previous argument, we have a
characterization of it anyway.

In the case of the superposition of periodic arrivals
with FIFO queueing, the maximum delay is the number of
sources competing times one packet transmission time.
Irrespective of whether they are homogeneous or
heterogeneous. The former case will always have a
larger bound than the latter. Again this is over one 
hop. Now if we split the aggregate at the next hop in
such a way that a given micro flow now competes with a
new set of micro flows at the next hop, the maximum
delay over two hops can only be increased by the
number of micro flows joining in. Does this not give
us a deterministic characterization of burstiness? I
would like to conjecture that even when multiple micro
flows split together the maximum delay will not be
increased any more than the number of micro flows
joining in. I could see that this could have an impact
on the streams just joining in, in the sense that
their delay could be larger than the case of a single
hop. However, if you look at the example in Appendix F
of my draft, when the test stream takes lesser number
of hops its delay distribution actually gets better.
This may not be the exact answer you are looking for
but it may trigger some thoughts.
 
> burstiness in order to justify

I am all for such clarification. I am really amazed
how we can make things more convoluted than necessary
:-)

Cheers,
Guven.

__________________________________________________
Do You Yahoo!?
Yahoo! Shopping - Thousands of Stores. Millions of Products.
http://shopping.yahoo.com/

---

From: ROBERTS James FTRD/DAC/ISS <[email-masked]>
Date: Wed, 13 Dec 2000 18:34:49 +0100

Guven,
> May be that design team should seriously consider this

I just think the EF definition should allow provision of services with
statistical guarantees (as well as other services with deterministic
guarantees, if possible). However, it is probably not be useful to define
such services in standards and it is certainly outside the WG charter. 

Regarding your other comments, I think we should take up a discussion on
statistical performance off list. As to bounding the maximum
(deterministic)delay, the difficulty in coming up with effective engineering
procedures is amply illustrated in the Charny, Le Boudec paper. Have you
looked at this? 

Regards,
Jim

---

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

> Alessio,
> 
> "Casati, Alessio (Alessio)" wrote:
> > 
> > Bruce,
> > 
> > I would like to discuss the merits of your proposal ("compromise"),
> > to form the WG consensus on the list: in fact we may have not
> > completely understood the proposal so far, due to tight schedule
> 
> Naturally, when the proposal has been written up in the form of a PHB
> definition, we will be doing just that; that is how we reach WG
> consensus.
> 
That's granted. But stated this way seems like the WG opted
for a yet to be seen and considered PHB definition. This was not
what was written in the options you asked the WG to 
express their view on... It would have been kinda strange.

alessio