Subject: RE: [Diffserv] Intuitive EF ?

From: Shahram Davari <[email-masked]>
Date: Wed, 26 Jul 2000 11:41:38 -0700

Hi,

>-----Original Message-----
>From: Brijesh Kumar [mailto:[email-masked]]
>Sent: Wednesday, July 26, 2000 2:34 PM
>To: 'Shahram Davari'; 'Grenville Armitage'; 'DiffServ'
>Subject: RE: [Diffserv] Intuitive EF ?
>
>
>
>
>> -----Original Message-----
>> From: Shahram Davari [mailto:[email-masked]]
>>
>>
>> Although your proposed statement removes the problem of 1.2.2, but
>it
>> creates another problem.
>
>OK so you agree that both problems (1.2.1 and 1.2.2) that are
>described in the draft can solved by adding simple text explanations
>to EF draft.
>
>> And that is RFC-2598 conformance
>> definition then
>> can't be applied to any flow at all. Because:
>>
>> 1) IF the arrival rate is greater than the configured rate
>> then you can't
>> deliver EF-PHB, because you will have packet loss in the router.
>
>That is implied by the service definition that uses this PHB. So it is
>not a problem.
>
>> 2) If the arrival rate is smaller than the configured rate,
>> then as you said
>> the conformance definition of RFC-2598 does not apply.
>
>As others have pointed out, except wordings in the RFC, it is
>perfectly nice condition to have.
>

This is not a nice, but a MUST have condition for EF.

>Basically, adding 4-6 line text clarifications to RFC 2598 may
>suffice. However, you did a good analytical job in defining the
>problems in the draft.
>
>Cheers,
>
>--brijesh
>Ennovate Networks Inc.
>

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

---

From: Bill Courtney <[email-masked]>
Date: Wed, 26 Jul 2000 11:46:09 -0700

Hello,

In response to the commentary below, I'd like to put a little emphasis on
Brian's comment. Brian has made the point that conformance is not the
IETF's concern, but providing vendors with boundary conditions is. I agree,
and I think we should make these conditions as simple and clear as we can.

I don't want to speak for Shahram, but I think I share his concern. A
PHB definition must offer the vendor a description against which he
can evaluate his forwarding behavior. Else, how can the vendor advertise
the product's capabilities with respect to the PHB? 

If a PHB description does not provide a clear description, but instead 
leaves important aspects as intuitions, then the vendor cannot evaluate performance
with any certainty. He will, at some point, make the decision that whatever 
his box is doing is pretty much in the ballpark, and will advertise compliance. 
Along comes a consumer trying to string together a critical service out of 
this heterogeneous collection of interpretations. (Not just different 
implementations, which is perfectly OK, but different interpretations of 
what external behavior is acceptable and what is not. Some of these 
interpretations will contradict others.) An already difficult networking 
problem becomes completely intractable. Nobody involved has kind words to 
say about DiffServ.

Perhaps I'm getting the principle of the thing mixed up with the practice,
so let me just say this: We should strive to reduce ambiguity about what is
and what is not proposed PHB. We need not develop elaborate conformance
criteria, but we should wave our hands in the air as little as possible, and
preferably not at all.

Shahram wrote

> ...
> > An RFC which is subject to intuitive interpretations leads to
> > interoperability issues.
> 

Later, Brian wrote in response

> However, PHB definitions are rather different from protocol
> specifications. The only "protocol" content of a PHB
> definition is the recommended DSCP value and that is
> totally objective with no possible errors of interpretation.
> 
> It isn't, as far as I can see, an interoperability issue whether
> all the schedulers along the path of an EF packet behave rigidly
> the same. Since the IETF concerns itself with wire protocol 
> interoperability, not with conformance, my assumption has always
> been that scheduler details should be left to individual
> vendors, within boundary conditions set by the PHB definitions.
> 
> Thanks for bringing this point up. It suggests to me that
> much of the current discussion is actually irrelevant to the IETF
> standards track (and possibly that RFC 2598 errs by being too
> specific).

Bill Courtney
TRW, Network System Engineering
-----

Only the mediocre person is always at his best.
                                             Tom & Ray Magliozzi

---------------------------------------------------------------------

---

From: Jon Bennett <[email-masked]>
Date: Wed, 26 Jul 2000 15:42:05 -0400

> vendors, within boundary conditions set by the PHB definitions.

Without the *ability* to test for conformance, interoperability of
independently created implementations will be a matter of chance, rather
than a product of good engineering.

>    Brian

Actually I do not believe this is the case.

RFC 2457   An Architecture for Differentiated Services
...
3.  Per-Hop Behavior Specification Guidelines
...
   G.9:  Each PHB specification should include a section specifying
   minimal conformance requirements for implementations of the PHB
   group.  This conformance section is intended to provide a means for
   specifying the details of a behavior while allowing for
   implementation variation to the extent permitted by the PHB
   specification.  This conformance section can take the form of rules,
   tables, pseudo-code, or tests.

I think the confusion here is that when some people ask for an unambiguous
definition that they can test, people envision some sort of 'conformance
certification' process. which is NOT what people are asking for. what we
would like is for a definition which does not require us to keep asking how
it should be interpreted under 'this' condition, or 'that' condition. This
doesn't really seem like a lot to ask?

jon

---

From: Shahram Davari <[email-masked]>
Date: Wed, 26 Jul 2000 12:57:33 -0700

Hi,

>From: Rajesh Talpade [mailto:[email-masked]]
>Sent: Wednesday, July 26, 2000 3:47 PM
>To: [email-masked]
>Cc: [email-masked]; [email-masked];
>[email-masked]; [email-masked]; [email-masked]
>Subject: Re: [Diffserv] Intuitive EF ?
>
>
>> Hi,
>> 
>> I think you didn't get it. There are only 2 possibilities:
>> 
>> 1) Arrival rate is greater than configured rate.
>> 2) Arrival rate is less than configured rate.
>> 
>> The first case is already precluded from EF-PHB, according 
>to RFC-2598, in
>> other words if arrival rate is greater than the configured 
>rate you can't
>> provide EF behavior. 
>
>
>and what i commented was that if arrival rate is indeed greater than
>configured rate over a sustained period, you can't really provide
>any behavior, can u ? apart from packet loss, of course ? :-)
>
>

Yes you can provide other behaviors, such as AF-PHB, in which you
intentionally accept oversubscription, to take advantage of statistical
Muxing. 

-Shahram

>
>
>rajesh.
>
>
>
>
>-- 
>Rajesh R. Talpade [email-masked] 973 829-4261
>Telcordia Technologies 
>

---

From: Anna Charny <[email-masked]>
Date: Wed, 26 Jul 2000 15:55:29 -0400

I realized I forgot to send this to the list...

>Date: Wed, 26 Jul 2000 08:37:36 -0400
>To: Grenville Armitage <[email-masked]>
>From: Anna Charny <[email-masked]>
>Grenville,
>At 11:58 PM 7/25/00 -0700, you wrote:
>
>>Okay, so I'm reading section 1 of draft-charny-ef-definition-00.txt
>>and the phrase "intuitive" arises many times. Here's another outside
>>observer's "intuition" about the salient text in RFC 2598:
>>
>>  "It SHOULD average at least the configured rate when measured over
>>   any time interval equal to or longer than the time it takes to send
>>   an output link MTU sized packet at the configured rate."
>>
>>Whenever I read this (and surrounding) text, I assumed the following:
>>
>>         - It is descriptive of externally visible behavior
>>         - It is not descriptive of specific scheduler implementation
>>         - The "average" is measured from the first bit of an
>>           EF packet belonging to the EF class under consideration.
>>
>>This third point appears critical
>
>>  I never saw the problems raised in
>>section 1.2.1 of draft-charny-ef-definition-00.txt since my
>>definition of "average" doesn't involve an interval with arbitrary
>>start/stop times.
>
>
>>  The start time is always fixed to be the moment
>>the first bit of an EF packet is transmitted, and the stop time
>>is arbitrary and greater than MTU/C beyond the start time. To me
>>this was always the intuitive interpretation of RFC2598's intent.
>>
>>Re-analyzing sections 1.2.1 and 1.2.2 using my interpretation of
>>"average" results in everything working out fine (apparently).
>>
>>I suspect the phrase "..over any time interval.." is a little
>>confusing. In draft-charny-ef-definition-00.txt it is apparently
>>interpreted to mean that the averaging can be done over an interval
>>with any start and any stop time (subject to the constraint of
>>stop time being at least MTU/C later than the start time). To me
>>it was more intuitive to assume that only the size of the interval
>>was "any" (subject to the same minimum of MTU/C), but that the
>>start time was synchronized to the transmission of packets in the
>>EF stream in some manner (since, afterall, it is the egressing
>>behavior as perceived by EF traffic that's being expressed here).
>
>Well,  I would like to make a few points here.
>
>The first one is that clearly your intuition differs from the intuition of 
>the 13 authors of the draft. That is not bad - it just indicates that the 
>text is open to different interpretations.    So how do we resolve the 
>difference?  One way may be  to put enough mathematical rigor into the 
>definition so that it leaves no room for different interpretations.  We 
>thought it might not be a bad idea, as long as the physical devices that 
>are expected to implement the old definition will be compliant with the 
>new one, and as long as what seems reasonably compliant transmission 
>patterns remain compliant.   (As a side note,  we were in fact hoping that 
>this would be addressed by the authors of the RFC, but unfortunately we 
>did not get any response from them, although we asked many times. So after 
>Brian has indicated on this list that whoever thinks that there is a 
>problem they should propose a solution, we set out to write the text that 
>would propose it).
>
>The second point is rather pedantic - the RFC explicitly says *any 
>interval*, and says nothing about
>starting from the first EF packet.  If the intention was in fact to count 
>starting from the first EF packet, then why wasn't it written in the RFC?
>
>The third point is that even if you do start with the very first EF 
>packet, then I am not sure why you want to start from the first bit of a 
>p[acket being transmitted rather than received?  Suppose that you receive 
>a packet at time zero and start transmitting it a year later, at which 
>point you transmit it at the ideal rate. This seems not to be the intended 
>EF behavior, because you were depriving the EF queue any service at all 
>for a very long time. So if anything, I would think you meant "first bit 
>received"?  But then wouldn't it be better to say "last bit received, 
>because you cannot usually do anything with the packet until you get it 
>all?"  As a side note, doesn't this strike you that perhaps whatever 
>intuition one might have, perhaps it is worth writing it down?) . So let's 
>take, just for the sake of an example, the possible interpretation of 
>starting from the last bit of packet received.  Let's look at the 
>following example: Configured rate R=C/3, input rate is also C/3,  (C is 
>line speed) the time to send a packet at  line speed is T.  Let the first 
>MTU-size packet fully arrive at time t_1=0, the second at time t_2= 3T, 
>the third at  t_3 =6.  The packets leave as they come, since there is no 
>contention in this example.  Let's look at the interval (0, 5).  It starts 
>with the first EF packet. It is longer than MTU/C.  So we should see the 
>amount of service given to EF equal to (length of interval) x (configured 
>rate) = 5/3 MTU. But we only saw 2 MTU.
>
>Of course everyone in their clear mind understands that the reason for 
>that is that the router cannot serve more packets then have arrived to 
>it.  So what's the big deal? Maybe we should just say so in the RFC as a 
>pedant-repellent? Might be a good idea :-).  But if you think about it, 
>this "intuitive" statement that you can't forward faster than you get 
>traffic in, you may realize it is actually  rather vague when you start 
>putting it into a definition. How do you measure the input rate? Over 
>which interval? Longer than MTU/R starting with the first packet? The 
>first packet ever (how do you know if you start looking  now when was the 
>first?) or the first packet coming to an empty queue?  The latter looks 
>promising. So we looked at it, and hit the problem with the internal 
>routing delay.  The reason we hit is is that just like you, we believed that
>
>>- It is descriptive of externally visible behavior
>
>So observing that router from the outside  all we know is when packets 
>come in and when they come out. We do not actually know whether the packet 
>got in is already in the output queue or not. So once it got in, we start 
>our observation, and if we are to follow the decision that we must measure 
>over any period starting from the first packet of every busy period, we 
>should continue this observation until "the queue" actually becomes empty. 
>But the only way we would know that, is if we count the stuff that cam out 
>and determine it is equal (and not less) than the stuff that came 
>in.  Turns out that is a problem, because as we show in the draft,  if 
>input rate is less than configured rate, then, due to the internal delay, 
>it might happen that
>
>1) the router seems always to have a packet inside
>2) the output rate is strictly less than the configured rate.
>
>Which brings us full circle back - the reason is the input rate is less 
>than the configured rate! But just exactly how do  we measure it?
>
>This difficulty is just one example of several we struggled with when we 
>worked on trying to put rigor into intuitively obvious. At the end of this 
>exercise we formulated a definition which seems to us to have the 
>necessary rigor to address the above (and all other) issues we stumbled 
>over.  Perhaps there are other solutions - we are certainly interested in 
>them. But something must be done to avoid the source of ambiguity in a 
>specification that is expected to become a standard - don't you agree?
>
>
>>Now, maybe I'm just being mathematically challenged (perhaps that
>>makes me IETF-compliant ;)  But I like the thought that RFC2598 isn't
>>necessarily as internally contradictory as it might seem. What am I
>>missing here?
>
>Well, I hope of my explanation above helped you understand some of the 
>issues here. Aside from that, there is another issue in the RFC, which is
>the list of compliant schedulers.  For example, consider WRR.  An EF 
>packet arriving to an empty queue may wait for multiple packets of each 
>other queue before it is transmitted.  Depending on the relative rates of 
>the queues, this number of non-EF packets can be quite large.  So if you 
>look at the definition in the RFC formally, in the (long) interval between 
>the time when the first EF packet arrived and when it got sent, the Ef 
>aggregate did not receive the service required.  In this case one needs to 
>bring in the restriction of allowed configured rates for this scheduler, 
>which is nowhere in the RFC. To me, that is a problem, because the spec is 
>supposed to be complete enough so that the implementor could look at his 
>implementation, look at the spec, and unambiguously decide whether his 
>implementation is compliant or not.
>
>So how do you address this issue? Do you put in the sec the rate 
>restriction for any possible scheduler? That might be difficult. Or do you 
>leave it up to the implementor to understand the limitations on rate that 
>would cause schedulers to be compliant  to the definition given? That is a 
>possibility, but then either you need to remove WRR (as well as *all* 
>other schedulers in the implementation section) from the RFC,  or say that 
>there IS such a restriction that you need to go figure out ? But then is 
>such restriction on the rate really necessary, or is it just a side-effect 
>of the chosen definition?  We belive that it is the latter...
>
>  You may further choose to introduce a "fudge factor" - but exactly how 
> big?  For example 5-10% fudge suggested in the VW draft certainly is not 
> enough to address this issue of WRR or the other schedulers.  Another 
> alternative might be to attempt to formulate your definition in such a 
> way that schedulers that you think should be more or less compliant 
> remain such. That is what we tried to do - the latency term in our 
> definition makes it possible for all the listed schedulers to be 
> compliant, and by looking at the latency term you can tell just how 
> "good" the implementation is.  And this definition does not impose the 
> rate restriction at all....
>
>
>>If I'm being an idiot, hopefully draft-charny-ef-definition-01.txt
>>will contain additional new text documenting and rebutting my version
>>of "average" :-)
>
>We would appreciate your input of what such text might be.  I attempted to 
>explain some of our motivation above. It would be useful to know if that 
>attempt was successful.
>If not, it would be useful to understand exactly what in the above 
>arguments is unclear or exactly  what you disagree with.
>
>Thanks in advance for your input,
>Anna
>>cheers,
>>gja
>>

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

---

From: "Casati, Alessio (Alessio)" <[email-masked]>
Date: Wed, 26 Jul 2000 20:54:08 +0100

Well, the history of EF has been quite controversial and
we had certainly passionate debates a long ago right on the
fuzzyness of the definition.

What is intuitive of EF is that it's hard to have a sharp 
definition of it as sop far attempted.

What the router behaviour should be? Probably describing the behaviour in
terms of rates is the wrong approach, since we see all these 
troubles the delay introduces.

As such, why not giving up math, and describe what a man sitting on a random

EF packet would see happening in traversing an EF compliant router?

He would arrive at an input interface, get served immediately with no 
queuing, or with a very low probability he would see one or two packets 
in front of him. He would find himself  switched to the output 
port and with no queuing (or very unlikely one or two packets) be sent to
out 
to the next hop.

What if more then two or three packets would like to queue? drop could be a
good decision so that network generated burstiness could be dampened and
never build up hop by hop.
Drop of course gets logged and reported to the performance measurement
subsystem.

Does it sound good as far as the definition is concerned? 
(of course what scheduling policy could achieve this is outside the 
scope of the definition, which by itself is a model).

Does anybody want to define EF along this way (It could be a very short
RFC)?

alessio

---

From: Anna Charny <[email-masked]>
Date: Wed, 26 Jul 2000 16:08:17 -0400

>definition of it as sop far attempted.

Alessio,

Since we would like to think that we offered just that "sharp" or at least 
strict definition in our draft,  your comment  must mean you have found 
some flaw in the definition we offer in our draft. Would you perhaps tell 
us what it is?

Anna

---

From: Shahram Davari <[email-masked]>
Date: Wed, 26 Jul 2000 13:26:35 -0700

Hi,

Let me summarize the fixes that have been suggested so far:

1) Start time of conformance measurement should not be arbitrary, but should
start from the time that the first bit of an EF packet exits the router (by
Grenville). 

2)The conformance definition does not hold if EF input rate is less than
configured rate (by Brian and Brijesh).

The first one is probably fine. The second one in not acceptable, because
this is the only condition that EF can operate in. Remember RFC-2598 says:
"its arrival rate at any node is always less than that node's configured
minimum departure rate."

The problem for the second proposal might arise from the fact that the
interval that the input rate is measured is not defined or seems to be
infinite.  

Therefore one might also think of the following fix, in which the input rate
is measured over the conformance measurement interval:

EF SHOULD average at least the configured rate when measured over any
time interval (which starts with the first bit of a packet exiting the
router) equal to or longer than the time it takes to send an output link MTU
sized packet at the configured rate, provided that the input rate during
that measurement interval is more than the configured rate.

This definition is fine as long as we have no delay in the router. Otherwise
the packets (or bytes) exiting the router during any measurement interval
(t0-t1) do not directly correspond to the packets (or bytes) entering the
router during the same interval (t0-t1). And it is almost impossible to find
the corresponding arriving interval, because the delay might not be fixed. 

So that to me means there is no easy way to fix the RFC-2598. 

-Shahram

>From: Grenville Armitage [mailto:[email-masked]]
>Sent: Wednesday, July 26, 2000 2:15 PM
>To: Shahram Davari
>Cc: DiffServ
>Since your observed conformance failure is of the form "the EF packets
>are coming out slower than the configured rate", and I firmly believe
>most router designers know packets can't come out that haven't
>already gone in, I take this scenario as intuitively part of
>the existing RFC2598 definition, and therefore conformant.
>
>There's a saying that you only need QoS architectures when there's
>contention. Perhaps we need more explicit text in RFC2598 reflecting
>that truth. It would certainly appear to remove the supposed 
>conformance
>failure in 1.2.2.
>
>cheers,
>gja
>
>Shahram Davari wrote:
>> 
>> Grenville,
>> 
>> I think you misunderstood my comment. What I am trying to say is that
>> example 1.2.2 wants to show an output stream which is intuitively EF
>> conformant (as you and I both agree) but does not fulfill 
>the conformance
>> definitions of RFC-2598 as mentioned in my email. I never 
>said there is a
>> problem with this behavior. I just pointed out that 
>according to RFC-2598
>> this flow is not EF conformant, while it should be.
>> 
>> Regards,
>> -Shahram
>	[..]
>_______________________________________________________________
>_________
>Grenville Armitage                    
http://members.home.net/garmitage/
Bell Labs Research Silicon Valley

---

From: Jon Bennett <[email-masked]>
Date: Wed, 26 Jul 2000 16:35:36 -0400

> The first case is already precluded from EF-PHB, according to 
> RFC-2598, in other words if arrival rate is greater than the configured 
> rate you can't provide EF behavior. The second case was suggested by Brian

> to be precluded as well (in order to solve one of the examples). So that 
> leaves no other traffic. Does it?

You forgot a third case...

3) Arrival rate is EXACTLY equal to the configured rate as measured
over....er... 

3) Arrival rate is EXACTLY equal to the configured rate on the
average......um

3) Arrival rate is EXACTLY equal to the configured rate.....with a 5-10%
fudge factor... nah

3) Arrival rate is EXACTLY equal to something, I'm not going to tell you
what its equal to, 
   but I would be willing to send to a couple of packets so that you can get
a good intuition 
   as to the rate that I am thinking of.....

:-)

jon

---

From: John Schnizlein <[email-masked]>
Date: Wed, 26 Jul 2000 16:30:22 -0400

At 08:54 PM 07/26/2000 +0100, Casati, Alessio (Alessio) wrote:
>.. describe what a man sitting on a random EF packet would 
>see happening in traversing an EF compliant router?

I like this - like Einstein's man on a lightspeed train.

>port and with no queuing (or very unlikely one or two packets) be sent 
>out to the next hop.
>
>What if more then two or three packets would like to queue? drop could 
>be a good decision so that network generated burstiness could be dampened 
>and never build up hop by hop.

Oops! This part is wrong for EF. The virtual wire PDB would preclude 
this happening because the aggregate of EF traffic at any point would
be policed at the edge of the domain so that only so much EF queue as
could be tranmitted (emptying the queue) within the time MTU/R is allowed.
It is not good enough to report the failure after the fact.

>Does anybody want to define EF along this way ?

It has been my impression that this is just the sort of definition
Van and Kathie have been pursuing for some time now. They have added
details to help our intuitions match up with theirs. My impression is
that some of their mathematical expressions for the behavioral results
(mistakenly) led other people to derive mathematical models, which
Brian argues are beyond the intended reach of the working group.

It has been fascinating, although not IETF-standards directed, to
puzzle over what premises in the mathematical model are responsible
for the occasional floods of discussion, clearly going past each other.

John

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Wed, 26 Jul 2000 17:34:05 -0400

> Bill Courtney wrote:
> > You will also have to add some condition about how long the 
> router can
> > delay after the EF packet arrives before the router sends 
> the first bit
> > of that packet.
> 
> I'm not sure I understand the need for this constraint. Provided the
> delay is relatively constant there isn't much more that EF requires.
> (In so far as EF aims to constrain jitter, but says nothing about
> whether EF-compliant routers can add 10ms of latency per hop, or
> 1ms, or 100us, or whatever just so long as it doesnt fluctuate too
> much, aka jitter.)

Well, you're at least also constrained by inter-packet times of EF traffic,
unless you plan on infinitely large buffers?

Bert
[email-masked]

---

From: "Casati, Alessio (Alessio)" <[email-masked]>
Date: Wed, 26 Jul 2000 23:01:52 +0100

> I like this - like Einstein's man on a lightspeed train.
Now that I think about it, I like it too.

> It is not good enough to report the failure after the fact.
Do you mean that failures should not be reported? 
On the other end reporting the failure before the fact is hard :)

I miss your point (and yes I know all what you mention
about the boundary conditions that surely will make the failure very
unlikely.)

I expect the model should be robust and stable, so doing some drop
above a configurable small threshold would only make the thing (more)
robust (of course, we may say it's a feature, and remove that from 
the standard...). I'm off.

cheers
alessio

---

From: "Kent Benson" <[email-masked]>
Date: Wed, 26 Jul 2000 17:09:37 -0500

If the aim is to comply with the intentions of the authors of RFC 2598 the
relationship between the delay through the switch and the interpacket
arrival is also important since it affects the construction of the VW PDB.
In particular, this sentence from Katie's email "Comments on
draft-charny-ef-definition-00" seems to indicate that a properly configured
EF realization should have at most a single packet from a given EF aggregate
in the router at any given time:

"This constraint [I(T)+R(T) <= 1] 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."

Perhaps this is just a subtle configuration bound.  No router can support an
EF aggregate that may have interarrival times smaller than the maximum
latency of a packet through the router.

I am not sure how to interpret this in light of nearly simultaneous arrivals
on multiple input ports or burstiness caused by upstream aggregation.  Is
there is an implicit averaging over some time interval?  Is this implied in
the "measured over a packet time at the configured output link rate" clause?
Does anyone have any intuition to share on this matter?

Kent

>From: [email-masked] [mailto:[email-masked]]On Behalf
>Of [email-masked]
>Sent: Wednesday, July 26, 2000 4:34 PM
>To: [email-masked]
>Cc: [email-masked]

---

From: Bill Courtney <[email-masked]>
Date: Wed, 26 Jul 2000 16:19:24 -0700

Kent,

I, too, wondered how a network operator could ensure that the
I(T) + R(T) <= 1 constraint could be met. Certainly, you would not
want to drop packets every time a coincidence of arrivals on
different inputs destined for the same output happened. Especially 
since the EF aggregate could be forwarded at the configured rate
with only a small queue build-up until the coincidence was worked
off. Of course, there'd be some jitter, but I don't see how anyone
could put together a domain that would avoid such coincidences no
matter what kind of policing/shaping they did at the ingress nodes.

Bill Courtney

> From: Kent Benson [mailto:[email-masked]]
> Sent: Wednesday, July 26, 2000 3:10 PM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]
> If the aim is to comply with the intentions of the authors of 
> RFC 2598 the  relationship between the delay through the switch 
> and the interpacket arrival is also important since it affects 
> the construction of the VW PDB. In particular, this sentence from 
> Katie's email "Comments on draft-charny-ef-definition-00" seems 
> to indicate that a properly configured EF realization should 
> have at most a single packet from a given EF aggregate in the 
> router at any given time:
> 
> "This constraint [I(T)+R(T) <= 1] 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."
> 
> Perhaps this is just a subtle configuration bound.  No router 
> can support an EF aggregate that may have interarrival times 
> smaller than the maximum latency of a packet through the router.
> 
> I am not sure how to interpret this in light of nearly 
> simultaneous arrivals on multiple input ports or burstiness 
> caused by upstream aggregation.  Is there is an implicit averaging 
> over some time interval?  Is this implied in the "measured over 
> a packet time at the configured output link rate" clause?

---

From: Bill Courtney <[email-masked]>
Date: Wed, 26 Jul 2000 16:42:32 -0700

Hi Grenville,

Here's a rebuttal from an earlier message that I posted. Is the
"glut & drought" possibility wrong, unlikely, or unimportant?
I don't build routers, so I probably have the most outlandish 
ideas [  :-) ], but it seems to me that the small-time-scale 
forwarding behavior is at the heart of the EF intuition.

[Limiting] measurement intervals to start at or near the time 
that the first EF bit is forwarded ... has some drawbacks.

1) The router could forward EF packets at a high rate and then
starve the EF aggregate for a while. The average rate as measured
from the forwarding of the first bit would still be equal to or
greater than the configured rate.

2) If you make the condition apply [multiple times, once for each
EF packet forwraded] stating with the time of forwarding
of the first bit of each EF packet (so that "gluts and droughts" would not
be compliant behavior), then, I can see two alternatives (maybe there're
 more):

   A) You have a very large number of averages to maintain
   B) You reset each time a new EF packet is forwarded.

In case B, you have something very much like what we proposed in the
new definition draft. 

Cheers,
Bill Courtney

----------------------------------------------------------------

> 
> I'm hoping for *your* rebuttal. Show that externally measuring
> the "average" interval from the start of a transmitted EF packet
> doesn't help to clarify the existing RFC2598 text. The discussion
> you provided above didn't do that, since you jumped immediately
> to discussing how it didn't work to measure from the last
> bit received.
> 
> cheers,
> gja
> ______________________________________________________________
> __________
> Grenville Armitage

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Thu, 27 Jul 2000 10:46:58 -0400

> From: Bill Courtney [mailto:[email-masked]]
> 
> Kent,
> 

I agree that in this situation some jitter cannot be avoided.

But the twist Grenville brings up is interesting. In the "textbook" queuing
model, the assumption is that while the box is processing one packet, other
packets aren't being processed. So as you increase latency to the same value
as packet arrival times, you will create queues approaching infinity.

Assume instead a router with multiple queues, each one of which holds just
one EF packet (for example). The router holds these packets for some long,
constant time, then transmits them downstream. Now if the packet arrival
time > T/n, where n is the number of parallel queues the router has, you can
still service all of these EF packets with minimal jitter, yet with large
latency.

So in fact routers can be holding onto many EF packets and still provide
small jitter.

This is like having traffic stacked up in multiple parallel lanes at a
traffic light, as opposed to just one lane.

Bert