Subject: [Diffserv] Part 2: FWD: response to comments to draft-charny-ef-definition-00

From: Anna Charny <[email-masked]>
Date: Tue, 25 Jul 2000 22:59:43 -0400

Part 2 (continuation of prev message)

> >Thus SLAs employing it can only talk of average rate over an
> >unspecified interval and its behavior under aggregation & disaggregation
> >is at best complex. If, however, you measure the worst case R() then
> >constrain the input rates such that I(T)+R(T) <= 1 packet, you get
> >something that both has an explicit jitter bound for SLAs and has a very
> >simple algebraic structure under aggregation (described in detail in the
> >VW PDB document). This constraint is the same as saying there's at most
> >one packet entering + in the router when measured over a packet time at
> >the configured output link rate. I.e., this is exactly the definition in
> >RFC 2598.
>
>There is an underlying assumption here that RFC 2598 actually does imply 
>that I(T)+R(T) is less than one packet for any implementable scheduler 
>(such as priority queue). There is some disagreement on this subject - in 
>fact we believe that it does not. But again, this issue is best discussed 
>in the context of the
>VW draft, and so I suggest we do just that, but in a separate message.

> >Note that in the spirit of IETF standards being about how to
> >build real networks, this is a statement about something concrete and
> >measurable
>
>Actually, that is precisely the intent of the our draft and our new 
>definition. We find puzzling how building real networks with something 
>concrete and measurable can be done with a specification that cannot be 
>formally implemented - which is the state of RFC 2598, as we see it.
>  >(the balance between the average input & output flow rates)
> >not a theoretical statement about how an abstract output queue service
> >discipline might interact with a hypothetical "continuously backlogged"
> >arrival pattern.
>
>I am not sure what you mean here at all. Our proposed definition does not 
>actually say anything about continuously backlogged arrival pattern. It is 
>defined by a recursion
>based on the concrete times when packets arrive to the device and when 
>they leave the device.  It is easily and explicitly measurable, since all 
>you need to do is to record the arrival times and the departure times. 
>Perhaps you misunderstood it?

> >Using the SHOULD as a MUST to deploy the VW PDB is completely
> >intentional.
>
>This does cause a problem if the definition of EF PHB in the rfc is not 
>formally implementable, doesn't it?  If you cannot implement something that
>strictly conform to the definition, what does a MUST mean in this context?

> > If a domain is providing circuit replacement
> >jitter is important. If the domain EF usage has other, less critical
> >jitter demands, then the use of the SHOULD is probably
> >sufficient. We assume the "user beware" meaning of SHOULD
> >from RFC 2119, that is, "violate this if you know what you're
> >doing and only if you know what you're doing."
>
>The way you translate what you have just said into the context of our 
>draft  is to choose the value of the latency term E. If you want to 
>minimize jitter, then you take a scheduler such as priority queue which 
>has the smallest E.   If you "know what you are doing" and can afford 
>larger jitter, you take a scheduler with larger E (such as some WFQ-like 
>scheduler with an efficient implementation.   So VW would be "EF with E 
>less than X" where X is some small number .   Just as I said before, we 
>have NOT changed any underlying intuition. Nor did we change any possible 
>implementations. All we did was to provide mathematical rigor to the 
>definition while actually making all the implementations listed already in 
>RFC 2598 strictly compliant with known degree of deviation from 
>"ideal"  rather than approximately compliant with unknown degree of 
>approximation accuracy., which is the current state of RFC 2598.
> >2. About the 50% limit and compliant schedulers
>
> >The 50% is a theoretical upper limit for mixed traffic
> >beyond which the "EF bound" cannot be met.
>
>It is not true that 50% limit is a necessary condition to getting a strict 
>jitter bound for a given configuration.
>There are many configurations where you can have utilization greater than 
>50% and yet have a very tight jitter bound (e.g. the ef bound). In fact, 
>our draft gives precisely such an example.  Hence, it is not true that 50% 
>is a theoretical limit in any configuration.

> >It is not an
> >intended or recommended operating region. The definition of
> >the EF PHB  says nothing about a 50% link bandwidth limit.
>
>Quite true - the 50% limit for RFC 2598 is not mentioned in the RFC 
>itself. Rather it  *follows* from it, as in fact is correctly noted in the 
>VW draft
> >Draft-charny-ef-definition-00 seems to have inverted this
> >theoretical upper limit to a constraint which must be
> >met by a scheduler in order to be EF compliant.
>
>I do not think that is what we said at all! Again, the 50% limit is NOT a 
>theoretical upper bound.   What we said in our draft was that even if you 
>do not need a 50% limit for your particular configuration because you can 
>get your desired tight bound at higher operating points for your network, 
>the EF definition of RFC 2598 will force you to reduce your operating 
>point JUST TO BE COMPLIANT - rather than to meet your jitter bounds. That 
>is what we mean by saying that the definition in the RFC  may restrict 
>utilization unnecessarily.

> >On the
> >contrary, the operating region for any EF compliant packet
> >scheduler is determined by the configuration for which it meets
> >the EF definition. The amount of a link that can
> >be allocated to EF (below the theoretical limit) depends in
> >large part on scheduler properties (specifically, granularity).
> >Our group at Cisco produced two reports on
> >this (one by Kedar), pointers to which were given to the
> >Cisco co-authors on the draft, so they know our thinking
> >on this. We are hoping to make some of this material
> >public soon, but it's not difficult to work out.
>
>Well, I am not sure how to discuss this. Regardless of the relevance of 
>the properties of any internal Cisco schedulers to our draft, the Cisco 
>co-authors of the draft did not share Cisco internal information neither 
>with the other co-authors, nor with the rest of the audience of this list. 
>It might be best to defer this discussion until relevant information does 
>become public.
>
>Furthermore, evaluation of the impact of the link utilization on the 
>resulting delay bound, while is very important, was outside the scope of 
>RFC 2598 and consequently was out of the scope of our draft.  I suggest it 
>should be discussed in the context of  the VW draft.
>
>Aside from this, I would like to point out that our draft gives a very 
>concrete and formal way of evaluating the impact of "granularity" of  the 
>scheduler on the resulting properties of a a system implementing EF 
>PHB.  The impact of the scheduling granularity and link utilization is 
>also discussed in substantial detail in 
>ftp://ftpeng.cisco.com/ftp/acharny/aggregate_delay_bounds_v4.ps . It is 
>important to understand that the limit on the operation point in all this 
>work comes due to the desire to find the operating point (in terms of a 
>bound on link utilization)  that will work for *all* topologies satisfying 
>this operation point.  Hence, if anything, it should be views as a 
>*sufficient* condition for small bounds. But it is certainly not 
>necessary!  In contrast, the 50% limitation on the link bandwidth is a 
>necessary condition for the Ef definition of RFC 2598 - and hence not 
>honoring it even when it is not necessary for jitter bound will lead to 
>immediate  violation of the EF definition.
> >In section 1.2.3 of draft-charny-ef-definition-00,
> >the third paragraph proposes that it is "unnecessarily
> >limiting" to have a configured rate of EF that does not
> >exceed 50% of the link bandwidth. The paragraph
> >after this points out that if the 50% is exceeded (a
> >violation of the EF PHB,
>
>Are you saying that the EF definition implies the 50% limit? That is what 
>we are saying as well

> > though apparently permitted by
> >the PHB these 13 co-authors propose),
>
>yes, our definition does in fact allow it. I think (although I am guessing 
>here) that you may be confusing the rate as measured over a small 
>short-term interval
>and the configured rate.  The definition of RFC 2598 constraints the 
>configured rate, whereas our definition allows configured rate to be 
>100%.  A non-preemptive scheduling implies that unless the configured rate 
>is less than 50%, there may exist an interval of length 2MTU where the EF 
>aggregate got only 50% service rate. Since RFC 2598 disallows that, this 
>is the cause of the limitation on the *configured rate*. Our definition 
>does not place any such requirement. It accounts for the time to transmit
>a non-Ef packet by the latency term E, and can have any configured rate 
>you want.

> >a TDM circuit cannot
> >meet the "EF bound".  This is a curious bit of discussion,
> >as it is unclear how it relates to RFC 2598. Instead it
> >appears to be a cautionary for the PHB the 13 co-authors
> >are proposing.
>
>Not quite sure what you mean here. perhaps you can elaborate?
> >3. Latency through a network node
>
> >Section 1.2.2 of draft-charny-ef-definition raises concerns
> >about latency through a router. RFC 2598 intentionally says
> >nothing about latency through the box. In most cases, this
> >is not all that critical as latency can be dealt with. In
> >cases where it is critical, operational measurements will
> >determine whether a particular envisioned service will or
> >will not work. If it will not work, this will provide the
> >kind of competitive pressure to get network boxes that do
> >have low enough latency provided the desired latency is
> >technologically achievable.
>
>The reason we discuss the router latency is that most of the real world 
>devices have such latency (variable or fixed). The examples we demonstrate 
>can occur whether or not the latency is variable . However, as we show in 
>the draft,  RFC 2598 would declare a device with latency as non-compliant. 
>We fell this is a problem.
>We also feel that a router which can be described as  a perfect output 
>buffered device with a fixed small internal delay and a PQ implemented at 
>the output is perfectly suitable for an EF implementation. This 
>contradiction leads us to believe that this is an issue that needs to be 
>corrected.

> >If the desired latency bound
> >is not technologically achievable, it's probably best to
> >rethink the service.
>
>Quite so.  I am afraid this comment is applied to VW draft as well. Let is 
>discuss it there.
> >Latency really doesn't appear to be a problem for 21st century
> >high speed routers. We are aware of several Cisco emerging
> >hardware platforms that are quite adequate for a wide range
> >of uses and assume that other vendors can say the
> >same. Since we don't know the particular characteristics
> >that a provider wants ahead of time and we don't know just
> >how far router technology can be pushed over the next few
> >years and we do know that latency is less critical than
> >jitter for the uses we envisioned (see for example
> >draft-ietf-diffserv-vw-pdb-00), we believe that our approach
> >in RFC 2598 is the correct one.
>
>Well, I think we pointed out many more problems that that of the internal 
>router latency in the definition of RFC 2598 (such as formal 
>unimplementability of the definition, for example). We propose 
>something  that fixes those problems, and also fixes the latency issue as 
>well.  So I am not sure that latency is the decisive point here - although 
>I disagree with you that it is not an important one.

> >By the way, the example of 1.2.2 does appear to be EF compliant.
>
>I do not think so.  The configured rate in the example is greater than the 
>input rate,  there is always at least one packet in the router, but the 
>output rate is less than the configured rate.  That is not really 
>compliant, is it?

> >Finally, we request that interested parties *read* RFC2598. The
> >body of the RFC (without the appendix) is not terribly long or
> >difficult reading. Similarly, with draft-ietf-diffserv-vw-pdb.
>
>
>Since certainly all of the authors of this draft spent long hours studying 
>RFC 2598 we are assuming this comment is addressed to the rest of the 
>mailing list?
>
>Regards,
>Anna Charny
>         >Van Jacobson
>    >    Kathie Nichols
>     >   Kedar Poduri
>
>_______________________________________________
>diffserv mailing list
>[email-masked]
>http://www1.ietf.org/mailman/listinfo/diffserv
>Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/
>
>
>
>---------------------------------------
>Anna Charny
>Cisco Systems, Inc
>300 Apollo Drive
>Chelmsford, MA  01824
>Tel. (978)-244-8172
>Fax (978)-244-8126

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

_______________________________________________
diffserv mailing list
[email-masked]
http://www1.ietf.org/mailman/listinfo/diffserv
Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 26 Jul 2000 09:41:18 -0500

Anna Charny wrote:
...
> >RFC 2598 we are assuming this comment is addressed to the rest of the

Anna, I think the point here is that the proponents of what I am calling
EF-Jacobson believe that the proponents of what I am calling
EF-Charny have a fundamental misunderstanding of EF-Jacobson, rather
than that you have literally not read the RFC. We need to get to
the bottom of this mutual misunderstanding, and we haven't done so yet.
So far you are talking across each other.

There are certainly people who claim to have implemented RFC 2598
without any particular difficulty, so this is not a one-sided debate.
I would actually like some of those implementors to speak up.

    Brian

---

From: Anna Charny <[email-masked]>
Date: Wed, 26 Jul 2000 11:51:31 -0400

Brian,

>So far you are talking across each other.

Talking across each other certainly does seem to be a problem.  I have 
tried to the best of my ability to explain our position and our motivation.
At the risk of sending jumbo messages,  I have tried to pinpoint  exactly 
what we disagree with in the technical response we have received.  I am 
hoping we can also receive some technical statements which pinpoint the 
technical errors in what we are saying.

For example, I have carefully read all the responses in the draft, but it 
is still not clear to me still why you, Kathie and Van think we
are defining a different PHB.   I certainly may be slow, but  perhaps 
someone would kindly reiterate, in the case I missed some fundamental argument.
One (and the only) argument that was given by Kathie is that our definition 
does not yield as tight bounds as the definition of the EF RFC. In my 
response to Kathie's comments I tried to argue that it is not so. Did I 
fail to make this argument properly? Did I say something that was unclear 
or wrong?    No one has responded to  those arguments yet...

It seems to me that the best way of sorting out the differences would be to 
step away from the statements that sound like "opinions" to pinpointing the 
areas of concrete technical disagreement in what  the interested parties 
say in the draft or on the list.   I would urge all participants of this 
discussion to try to do so.  If any of the statements I made sound like 
unfounded opinions, I would be happy to learn what they are and would 
certainly attempt to explain why I think so.

>I would actually like some of those implementors to speak up.

The point here is not what implementation to choose to implement the 
"spirit of EF".  We think that under different circumstances we can choose 
the schedulers listed in the implementation section of the RFC, as well as 
many other schedulers that satisfy the common intuition (if such thing 
exists) of what EF should be.  However, the point we were making was that 
these schedulers, while being perfectly reasonable as far as our intuition 
goes (and hopefully, since this schedulers are listed in the RFC, they also 
correspond to the author's intuition,  are NOT *formally* compliant to the 
definition of the RFC.  The fact that someone says  "we implement EF"  only 
makes sense if they actually do, in a verifiable manner.   We have argued 
that  the "traditional" schedulers that are widely assumed to "implement 
EF"  (such as PQ) formally do not comply with the definition of the 
RFC.  Do you disagree with any of the reasoning we use in the draft to 
demonstrate this? If so, can you tell us exactly what you disagree with - 
that would certainly help getting to the core of the 
differences.  Otherwise, what does your statement above mean?

Regards,
Anna