Subject: RE: [Diffserv] Intuitive EF ?

From: Shahram Davari <[email-masked]>
Date: Wed, 26 Jul 2000 08:40:42 -0700

Hi Grenville,

>-----Original Message-----
>From: Grenville Armitage [mailto:[email-masked]]
>Sent: Wednesday, July 26, 2000 2:59 AM
>To: DiffServ
>Subject: [Diffserv] Intuitive EF ?
>
>
>
>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.
>

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

>Re-analyzing sections 1.2.1 and 1.2.2 using my interpretation of
>"average" results in everything working out fine (apparently).
>

1.2.1 works fine, but 1.2.2 DOES NOT. For example consider the time interval
of 4T to 6T which is 3T that starts with an EF bit (consistent with you
interpretation). This time interval (3T) is greater than 2T (which is the
time interval to send an MTU size packet at configured rate C/2). Now during
this time interval only one EF packet has been sent (the one at time 4T). So
the average rate during this interval is MTU/3T = C/3 which is less than C/2
which was the configured rate. Do you have any other intuition
interpretations for this example?

Regards,

-Shahram

>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).
>
>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? (And why would this require "global clock
>synchronization" as implied by the opening paragraph of
>section 1.3 ?)
>
>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" :-)
>
>cheers,
>gja
>
>_______________________________________________
>diffserv mailing list
>[email-masked]
>http://www1.ietf.org/mailman/listinfo/diffserv
>Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/
>

_______________________________________________
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 12:13:00 -0500

> Hi Grenville,
...
> An RFC which is subject to intuitive interpretations leads to

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

   Brian

---

From: Grenville Armitage <[email-masked]>
Date: Wed, 26 Jul 2000 10:37:27 -0700

Shahram,

Shahram Davari wrote:
	[..]
> interpretations for this example?

I have no problem with 1.2.2. The source stream shows EF packets
every 3T, the output stream shows EF packets every 3T, and there
doesn't appear to be any jitter added.

My intuition (which seems to be born out by most router designs) is
that packets can't go out if they haven't yet arrived. So this
example where, by design, the source EF stream is running at less
than 'configured rate' is simply wonderful - underutilized EF class,
great, no problem, we can sleep easy.

cheers,
gja
________________________________________________________________________
Grenville Armitage                    http://members.home.net/garmitage/
Bell Labs Research Silicon Valley

---

From: "Brijesh Kumar" <[email-masked]>
Date: Wed, 26 Jul 2000 12:35:43 -0400

> From: [email-masked]
> [mailto:[email-masked]]On Behalf
> Of Shahram Davari

And what are those interoperability issues exactly? I think you meant
something else (all those horrendous performance implications etc.
described in the draft;-)).

> >"average" results in everything working out fine (apparently).

If you pick up any arbitrary interval then of course definition is not
valid. But you do agree that if 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, it
fixes the problem in the 1.2.1 in your draft.

> time interval to send an MTU size packet at configured rate
> C/2).

As the draft points out, the underlying reason for this problem is
that the scheduler cannot forward EF traffic faster than it arrives.
However, it can be easily seen that the existence of internal delay
causes one packet to be inside the router at all times.

While the addition of the condition that EF aggregate must receive its
configured rate only when the EF aggregate is backlogged may not
suffice in this case, but  adding a more explicit condition that the
configured rate is only achievable when EF aggregate arrival rate
exceeds (or equal to (?)) the configured rate should remove the
problem described in the 1.2.2. Let us see what you have against these
two simple conditions.

Cheers,

--brijesh
Ennovate Networks Inc.