Subject: Controlled-Load comments 2/28/96 12:07:23

From: "Roch Guerin ((914) 784-7038)" <[email-masked]>
Date: Mon, 4 Mar 96 10:11:50 EST

Reference:  Your note of Wed, 28 Feb 1996 12:07:23 -0400

John, a few quick (will try to keep it shorter this time) comments in
response to your last note.  As you said, I think that we share common
views on several aspects, but still have some differences on a few
others.

> ....  deleted stuff  .....

>Controlled load does not claim to explicitly address this class. There are
>several reasons, one of which is lame.

Fully agree, but i think that such a class is needed, which is why I
wanted to bring it our explicitly.  This being said I also fully agree
with the first three reasons you mention for why C-L did not address it.

> ....  deleted stuff  .....

>Considering these issues, I decided that CL should not specifically support
>this case. Since the case is a simplification of the others, I suspect
>it'll work reasonably well anyway.

> ....  deleted stuff  .....

Here, I am not sure I fully agree with that.  In particular, this will
depend on what you decide to do with *excess* traffic in C-L.  For
example, if traffic that C-L deems excess is buffered and delayed until
it can be transmitted, then yes, it should work reasonably well.
However, if excess traffic is either dropped or sent as best-effort,
then no, it wont work reasonably well.  Since which behavior is to
be used is not specified in C-L, you cannot really say that it will
work well for non-adaptive and conformant traffic.

>
>B. Non-Adaptive and Non-conformant (or not necessarily Conformant)
>------------------------------------------------------------------

> ....  deleted stuff  .....

>although I'll point out that the criticality of
>identifying excess traffic completely accurately depends on what you do
>with it afterwords.
>Getting it just right is more important if you are then going to drop it
>immediately than if you are going to buffer it in-order, say.

Absolutely.

> ....  deleted stuff  .....

>there is a fourth option; buffer and send
>them in-order as long as the actual experienced delay is not excessive.

I think this is similar to option a). below, where you replace *as long
as buffer space is available* with *as long as delay is acceptable*.
This is, I agree with you, the more benign handling of the 3 and the one
which has the least requirements on how accurate you are in identifying
excess traffic.  However, it may not be appropriate in many cases.

> ....  deleted stuff  .....

>This raises the question of -why- the non-conformance occurred. Since we
>are talking here about non-rate-adaptive applications, the usual cause of
>overload will be that too many sources sent something at once through a
>shared reservation. The expectation in this case is that the flow will
>receive poor service - either higher transient delay or packet loss. The
>expectation is also that the overload situation is transient - eventually
>the extra people will stop talking, or whatever, and the congestion will
>clear.
>
>If the reservation is too small for the number of continually sending
>sources (say it is smaller than a single source, for clarity) and the
>network does not have enough excess capacity to send the traffic with low
>delay, the delay will get high and the dropper will start dropping pkts.
>That is an expected and acceptable result.

> ....  deleted stuff  .....

Some comments here as I think that you are assuming a specific approach
wrt handling of excess traffic, namely delay and then drop.  As mentioned
above, this is not the only possibility.  For example, the bandwidth
allocated to the C-L class may no be enough to sink all the excess
traffic, but some of it could be accommodated at a lower priority such
as best effort.  This clearly depends how you implement your bandwidth
allocation to different classes, but is not an unreasonable scenario.

> ....  deleted stuff  .....

>The choices are immediately dropping all excess traffic, sending the excess
>traffic in-order as long as there is enough b/w, and sending the excess
>traffic out-of-band by putting it into a separate best-effort queue.
>
>The C-L spec specifies that you can't do immediate dropping for the same
>reasons given above - denial of service to best-effort receivers and so on.
>Either of the latter two choices are allowed.

I don't think that C-L specifies you can't do immediate dropping, at
least not based on my reading of the doc.  Specifically it says:

  ... it is permissible either to degrade the service delivered to all
  the flow's packets equally, or to sort the flow's packets into a
  conformant set and a nonconformant set and deliver different levels
  of service to the two sets.

To me, this states that I could use a strict conformance test, e.g., a
token bucket, and decide to drop packets that fail the conformance check.
The following paragraph that states that

   ... it is desirable for network elements at points within the
   interior of the network (but *not* at edge traffic entry points) to
   enforce *slightly* relaxed traffic parameters to accommodate packet
   burst somewhat larger than the actual TSpec.

is much too vague to be of much use, even though it points to the right
direction.  Also, I think that the statement that reshaping it NOT
allowed does make much sense.  I believed I went over that extensively
in the first note I sent you a while ago, but the bottom line is that
if you actually are willing to buffer packets, up to a point, while they
wait to be sent out at the reserved rate, then you are actually doing
reshaping.  I don't think you want to prohibit such a behavior, so
including such a statement does not seem to be really in agreement with
the goals of C-L.  As a matter of fact I believe you have something like
that in mind, when you say in your note:

>The other option is to send the pkts in-band as long as there is b/w to do
>so, and drop them otherwise. The question now becomes how and how fast you
>need to start dropping.

Bottom line is that if you don't drop but buffer, then you reshape...

> ....  deleted stuff  .....

>If I were Juha or perhaps you, I would have said that "enough b/w to do so"
>means "fair share". I didn't, because I have some worries about the
>definition and implementability of that phrase. But I would say that that
>is the ideal.

Buffering and bandwidth are closely related.  If bandwidth becomes tight,
you'll see queue sizes go up even when all traffic is conformant (that's
actually one of the reasons while I don't think that the C-L characterization
of emulating an *unloaded* network is a very meaningful one).  They'll go up
even faster if you are nonconformant and try to send more traffic than your
reserved rate.  So, buffer sizes are in general the means for you to detect
that available bandwidth is becoming insufficient, irrespective of whether you
are allocating a fair share or not.  So, I'd actually rather focus on buffers
than bandwidth as the mechanism to detect excess traffic and/or trigger
specific action on excess packets.  The issue then becomes, when do you start
applying any such actions, i.e., above which buffer level.  This is the main
issue, irrespective of which buffer management technique, e.g., RED, you use.

> ....  deleted stuff  .....

>However, as I argued above, I think that
>the controlled-load usage pattern for this class of source allows for
>transient delay events and so on under overload, so I am prepared to let
>you use something like RED to manage the excess b/w.
>
>The above paragraphs are what the C-L spec intends to say. As I said to
>Curtis, if you think it says something drastically different, then there is
>a problem with the wording of the spec.

C-L sorts of allows the buffering, but as I mentioned above I have a
problem with the wording, in that I don't think it is specific enough to
ensure adequate performance under the different scenarios that need to be
considered.  One can either make the C-L specs more specific so that
they spell out things more precisely, or introduce other specs that will
address that.

> ....  deleted stuff  .....
>
>Now, the question is how much the mechanisms needed to implement this
>differ from those implementing the non-rate-adaptive non-conformant case.

I think that the main difference is in terms of how accurate you have to
be with the buffering before deciding that packets are excess traffic.

> ....  deleted stuff  .....
>
>Now here we differ. I would say that rather than buffering "as long as
>buffer space is available", you should run RED or similar, to allow
>transient buffering while pushing back to cause adaptation against
>long-term overload.
>
>Further, I suggested above that this sort of buffer management was also
>acceptable for the non-adaptive case, given the sources of over-profile
>behavior in that case. So the basic structure of the queue management can
>be the same.

Agreed that the basic buffer management structure can be the same for
the two cases.

>The open question is whether the specific parameters of this buffer
>management algorithm are similar enough for the two cases that you can just
make them the same. There is some reason to think that it is, because the
>RTT of a TCP connection and the response time people will accept for
>non-adaptive congestion management (basically a human factors question) are
>of the same timescale. If the parameters can be the same, we are back to
>the situation where the service provided for the two cases is identical.

This where I think we do differ as I don't really believe you can have
the same rules and parameters in the two cases.

> ....  deleted stuff  .....

>The network element is managing (at least) two resources, b/w and buffer space.
>They are somewhat orthogonal. If you want to -ensure- decent performance
>(assuming b/w is available) you have to ask the router to allocate you some
>buffers. This is a resource reservation as much as reserving b/w is; you
>are asking the router to preferentially allocate you something.
>
>If you are willing to take your chances on the router's buffer pool as well
>as the b/w, then you don't need to ask for much b; you'll get whatever is
>available. This is what C-L says today.

As I mentioned earlier, I don't really consider buffer and bandwidth
as orthogonal resources.  They are closely coupled, even if you can
and probably should decouple their reservation.

> ....  deleted stuff  .....
>
>Well, which arriving packets to subject to the unreserved-resource buffer
>allocation competition. But yes, basically. This does not differ from the
>non-adaptive case.

Again, I think this is where we differ.

> ....  deleted stuff  .....
>
>C-L does not address this, or more precisely it does not take advantage of
>the garanteed conformance because of shared-reservation and
>bes-effort-receiver issues. For what it's worth, Guaranteed-Delay is a
>fairly close match. But if it turns out that C-L is inadequate for this
>class of application, I think a new service should be defined.

I think that unless C-L defines more precisely what is excess traffic
and how it is to be handled, i.e., pick one specific approach or gives
the option to specify one, it wont do too well for this kind of traffic.
Guaranteed Service is certainly a close match.  The only issue here is
whether one needs a service class with slightly less stringent
guarantees than Guaranteed Service.

> ....  deleted stuff  .....
>
>I argued above that in either case the way to do this is to do it with an
>active buffer management algorithm such as RED, which allows transient
>overload, keeps average buffer use & delay low, and deals brutally with
>overload by non-adaptive sources. I suggested that it seems quite possible
>that the parameters of this algorithm could be identical for the two cases,
>although if it turned out that they weren't there would then be a need to
>distinguish between the two.

Ditto vs where I think we differ.

>Finally, I claimed that of the two options
>
>>  a. Delay and drop, i.e., preserve ordering,
>>  b. Send as best effort, i.e., do not necessarily preserve ordering.
>
>the second was fairly consistantly less desirable, in the sense that any
>application which wanted it could also use the first choice, while the
>opposite was not true. This suggests that making it an application option
>(and thus asking everyone implement both) might not be necessary, although
>allowing it with a warning label (for use in those networks being designed
>for one type of application) would make sense.

I think this is another point of difference as depending on how you
manage your bandwidth for the C-L (and other) class, option b. may
actually be quite desirable.  In particular, if you are limiting the
amount of bandwidth that C-L can grab, in order to avoid that it
starves the best effort class.

Roch