Subject: Re: [Diffserv] Intuitive EF ?

From: Grenville Armitage <[email-masked]>
Date: Wed, 26 Jul 2000 16:00:40 -0700

Anna,

Anna Charny wrote:
	[..]
> 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?

I picked that because it seemed to work for the back-of-the-envelope
analysis I did before posting my suggestion, and was observable.

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

A router introducing huge latency into the path would not sell very well
into operator networks. I'm not overly concerned with such a router.

> So if anything, I would think you meant "first bit
> received"?

No, not really. There might be an equivalent expression based
on the first bit received, but I simply can't think of one
just yet that is free from introducing a term involving the
router's own internal latencies.

>  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?"

Perhaps, but I'm not going to analyse such cases.

If I had measurement gear hooked up to a router, I'd test EF
by seeing whether EF-marked streams experienced equal or lower
jitter than all other streams. But the text in RFC2598 that's
currently under discussion makes an observation about how
the router's egress rate for EF traffic ought to appear. So
it seems reasonable to measure at the output.

> As a side note, doesn't this strike you that perhaps whatever
> intuition one might have, perhaps it is worth writing it down?)

As a side note, your I-D and email have petty undertones.
Authors always make assumptions about their audiences. One
doesn't always write down assumptions. (Of course, my assumption
about measuring from the start of an EF packet may also be wrong,
making some of this discussion moot.)

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

I dont see that the RFC needs to specify all the boundaries on
configuring different schedulers in order to have them operate
in an EF-compliant zone.  True, if there are schedulers for which
it is *never* possible to construct EF-like behavior (even allowing
for my suggested clarifications on interval start times), the RFC
ought not mention them. But have you identified such? Sounds like
you're just identifying that the RFC currently leaves scheduler
configurations as an exercise for the student.

	[..]
> >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'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                    http://members.home.net/garmitage/
Bell Labs Research Silicon Valley

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

---

From: Anna Charny <[email-masked]>
Date: Wed, 26 Jul 2000 22:39:41 -0400

Grenville,

>As a side note, your I-D and email have petty undertones.

Excuse me? Could you please explain yourself?  Name calling is not 
generally regarded an esteemed argument technique....

>doesn't always write down assumptions.

This may be  true for informal presentations, but I am not sure it is a 
merit for  a standard track specification to not explicitly state what its 
assumptions are.
As we are witnessing right now, the audience of the authors of RFC 2598 
seem to have a rather diverse set of assumptions, so it is hard to
assume that everybody will simply guess exactly what assumptions the 
authors did have.

>ought not mention them. But have you identified such?

Yes.  I believe all schedulers listed in RFC 2598 as compliant (with the 
exception of PQ), will not satisfy your definition either. For instance, 
the example of WRR output
posted recently by Jon Bennett seems to demonstrate that WRR is not 
compliant under your modified definition as well.  Yet, WRR is listed as a 
compliant scheduler. Similar examples can be given for other schedulers 
listed there, as well as many of the WFQ-like schedulers, which are not 
explicitly mentioned, but widely assumed to be compliant.

>to discussing how it didn't work to measure from the last

Ok, I'll try.

First, I  will reiterate what has been said many times already  - using the 
first bit of a packet transmitted does not solve the problem of variable 
internal router delay and hence disallows what appears to be reasonable 
implementations.  I understand that you do not think it is important, but I 
do not share your opinion.

Second,  if  you measure from the first bit sent,  then two schedulers, one 
of which sends the EF aggregate at the ideal rate without any delay, and 
the other introduces a large scheduling delay for the first packet, and 
then sends the EF queue at the ideal rate, will look exactly the same from 
the point of view of your definition.  This strikes me as a drawback, since 
the second scheduler clearly does not provide the configured rate at a 
small enough time scale, while the first scheduler is the expected ideal EF 
model.  The cause of the problem is that your definition proposal is blind 
to the initial delay.

Third, if you are observing only the packets sent, how do you distinguish 
between the following tow cases:

case 1:  configured rate 1/2, input rate 1/2,   output rate 1/4
case 2: configured rate 1/2, input rate 1/4, output rate 1/4

In the first case the router drops half the EF packets, and sends the 
remaining half ideally shaped at rate 1/4, while in the second case it just 
forwards packets as soon as it receives them. Both outputs look identical 
from the point of view of your modified definition, but the first is 
blatantly non-compliant, while we would like to call the second 
compliant?  This example indicates that in the very least you must say 
something about the input rates - which a) is not what you are proposing, 
and b) is not trivial to do,  as many of the earlier messages 
today  indicated.

Fourth, Bill's example of Ef packets first served faster than configured 
rate and then slower than configured rate will be compliant  with your 
definition if you measure from the first packet sent, so you will declare a 
scheduler which gives less than configured rate to EF over the second part 
oft his observation - which seems not what is intended.  If you restart 
your measurement every time a packet is transmitted, then, again, how would 
you determine whether a large gap in service is due to non-compliance of 
the scheduler, or simply because there were no packets to sent?

Fifth - as mentioned above most schedulers listed in RFC 2598 as compliant 
will not satisfy your definition either.

There may be more arguments, but I will stop for now in the hope that this 
might be enough.

Regards,
Anna

>gja

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

---

From: Grenville Armitage <[email-masked]>
Date: Wed, 26 Jul 2000 21:28:35 -0700

> generally regarded an esteemed argument technique....

I wasn't arguing, I was adding my own side-bar comment to
your side-bar comment. It gets tiring reading the various
ways you can say "the authors of RFC2598 should have written
it down if that's what they meant". It seems petty after awhile.
 
	[..]
> >True, if there are schedulers for which
> compliant under your modified definition as well.

Jon's example showed that we can configure WRR weights such
that the nominal "EF" class doesn't received EF behavior. That's
not quite the same as showing there are *no possible* combinations
of weights for which a WRR scheduler can provide EF behavior.
The latter proof is what I'd like to see before I'll agree
that RFC2598 shouldn't have mentioned WRR as a candidate scheduler.

	[..]
> do not share your opinion.

We do disagree on whether the router's own inherent latency needs
to be quantified in order to express the desired characteristics
of EF.

> the point of view of your definition.

I can't visualize such a second scheduler (assuming by "ideal rate"
you aren't referring to a line rate burst of back to back
buffered EF packets, in which case I can visualize such a scenario
but then can't see how "ideal" == "line" would be acceptable for the
first scheduler)

	[..]
> remaining half ideally shaped at rate 1/4,

....and the drops are being flagged by the OAM subsystem, and
we know the router is misbehaving. Clearly this isn't a test
of the router's EF behavior - its just plain broken. No conclusions
can be drawn (using anyones definitions).

	[..]
> oft his observation - which seems not what is intended.

Providing the overall jitter stays within the operator's desired
bounds, I see no problem with the scheduler speeding up and slowing
down within small time intervals of interest. I rather assumed that
was intended by RFC2598 too. Clearly I'm missing something about your
point.

>  If you restart

If there are no packets being sent, no one will complain the router
isn't providing EF behavior. If there are packets being sent, there'll
be traffic to observe.

> will not satisfy your definition either.

I didn't realize the schedulers were being certified as being compliant.
Thought RFC2598 simply noted some schedulers as having the *potential* to
support EF behavior. Perhaps I need to re-read RFC2598 too :)

cheers,
gja

---

From: Anna Charny <[email-masked]>
Date: Thu, 27 Jul 2000 08:53:27 -0400

Grenville,

>it down if that's what they meant". It seems petty after awhile.

Webster's dictionary defines
pet-ty (adj.)   1. of little importance, small, minor . 2. having or 
showing a narrow, mean character. 3. of lower rank

I am assuming that generally an I-D pointing out that an RFC is currently 
broken (and offering a fix) probably should not be viewed as being of 
little importance.  I do not think you meant our I-D is of lower rank.  So 
that must mean you found in our I-D comments of mean and narrow 
character.  We would like you to tell us specifically what they are, so 
that we can collectively work on improving our character?

Or alternatively you might just choose to apologize.

Anna

---

From: Anna Charny <[email-masked]>
Date: Thu, 27 Jul 2000 08:44:53 -0400

>that the nominal "EF" class doesn't received EF behavior.

Is there anything wrong with his weight allocation? Does it violate 
anything the RFC says is legal for EF?
How can I tell, looking at a rate allocation, whether it is legal or 
not?  How can admission control software tell it?

>That's

First of all, it is certainly true that there exists a configuration of WRR 
which works just fine - when the link is 100% allocated to EF.   On the 
other hand, the WRR behavior shown by Jon  is mostly due to the number of 
and the relative rates of the non-EF queues rather than their absolute 
rates, then for any desired value of EF configured rate which is strictly 
less than the entire link speed it is possible to take enough non-Ef queues 
and give the rate allocation for those queues that will not exceed the 
capacity left over from EF,  and will show a similar behavior 
pattern.  What  it means then is that even if there dose exist  a 
non-trivial allocation of the leftover bandwidth that does not break 
expected Ef behavior,  then the choice of a given EF configured rate that 
satisfies all the EF imposes constraints on the choice of how to share the 
remaining bandwidth among other PHBs on the link.  This means there exists 
an interdependence between EF and other PHBs.   But the RFC does not 
mention any such interdependence.  Hence, there appear to be two choices - 
one is to document the interdependence in the RFC, and the other is to 
agree that  for any given choice of EF configured rate that satisfies EF 
RFC in isolation, any the distribution of remaining bandwidth   should be 
allowed, and should not break the expected EF behavior.  The first case 
amounts to specifying legal weight combinations in the RFC. The second one 
implies that WRR is not a compliant scheduler.  Take a pick.

>[.]

A poorly designed rate-controller in a link-sharing scheduler which cannot 
serve packets faster than its rate, but which can disappear for a long time 
serving other
queues.  While obviously bad,  it will be compliant according to your 
definition.

>can be drawn (using anyones definitions).

I think you completely missed the point here. In the portion of my text 
that you cut out, I explicitly said that the first case is in fact 
blatantly broken. But you do not need OAM to tell you that - your 
definition will also decide it is broken.  What is important here is not 
that the first one is broken, but rather that your definition cannot 
distinguish between something that is blatantly broken and good, and hence 
will also decide that the second, perfectly legitimate example,  is *also 
broken*.  The reason it will decide so is that because your modification 
does not change the fact that the definition in the RFC is blind to input 
rates - all it knows is what happens on the link after the first packet 
goes out.   At the risk of repeating the same argument again and again,  I 
emphasize  that it is NOT obvious how to unambiguously capture the input 
rate. Our definition offers one way to capture it that we believe is 
non-amigos. While there may be others, they have not yet been offered. Also 
it would be good  to understand what is wrong with ours.

>isn't providing EF behavior. If there are packets being sent, there'll

Full round again... Your definition has no clue whether there are any 
packets in the queue.  It looks just at the output.  While you certainly 
may resort to *other*  means of figuring out whether the router is OK, 
those means would not be based on the EF definition.  We think it is a 
problem, because we believe it is precisely the purpose of the definition 
to allow you to tell whether an EF implementation works or not.

>support EF behavior. Perhaps I need to re-read RFC2598 too :)

I am not sure it matters whether it is called "having potential to support" 
or "compliant". I frankly do not see the difference, because to me
a scheduler which fails to deliver a service under a set of apparently 
legal bandwidth allocation between queues cannot be  listed as potential
to support the behavior, unless someone explicitly gives me the rules by 
which I can tell which allocation is legal, and which is not.

Anna

---

From: Grenville Armitage <[email-masked]>
Date: Thu, 27 Jul 2000 08:50:03 -0700

Anna Charny wrote:
	[..]
> pet-ty (adj.)   1. of little importance, small, minor .

Bingo!  It gets tiring reading the various ways you can
say "the authors of RFC2598 should have written it down
if that's what they meant". Such comments are of little
importance, small, minor after awhile.

Case closed.

gja