Subject: Re: interim meetings? (controlled load)

From: [email-masked] (John Wroclawski)
Date: Tue, 27 Feb 1996 14:40:08 -0400

Curtis,

I'm rereading your notes about controlled-load. It seems to me that there
are some misunderstandings about what the spec says.

At 10:34 PM 2/9/96, Curtis Villamizar wrote:
>In message <[email-masked]>, John Wroclawski writes:
>
>>    The third is horrible for almost any type of traffic (take some
>>    portion of the traffic and delay it, delivering it out of order).
>>
>> Well, no. Given an end-to-end delay curve like that, a realtime
>> application could easily choose a playback point which used only the
>> non-delayed packets, if it wanted to. A different listener in the same
>> session (perhaps the one which is making the archive recording,
>> instead of being interactive) might choose a point which used as many
>> pkts as possible, reordered or not.
>
>I did not hear consensus for this at the meeting.  I heard a lot of
>discussion and a lot of disagreement.

Consensus for what? The above is a description of fact - a listener could
do that. I gather that you think the c-l spec demands this behavior. It
does not. You seem to think that I believe it is the only "right" behavior
for a c-l service. I don't.

In fact, I think the delay-some-and-reorder behavior is the least desirable
of the overprofile behaviors allowed by the c-l spec. When I wrote the
spec, I seriously considered disallowing it completely. I decided not to,
because it is very cheap to implement, and it is acceptable in one
particular circumstance - the case where someone is designing a network
where c-l service will be used only for certain real-time applications.

This is the point of the evaluation criteria in the service specs. We
recognize that with performance-oriented specs like this any implementation
will have some tradeoffs. We have to give the people buying the equipment
enough information to make a decent choice. In a note about your b==0 idea
you suggested that some vendors might not support your b==0 function, but
that you wouldn't buy their product. Just right! A similar thing applies
here. I wouldn't expect you, as a general service provider, to buy c-l
routers that didn't meet your needs - and the eval criteria make sure you
will have that information.

That said, it might yet make sense to disallow this reordering behavior. I
consider it a close judgement call between disallowing it and allowing it
with a warning label.

>> As an aside, this notion that the b term is not useful for TCP traffic
>> is dubious. b is more or less buffer size. If I want a reservation
>> that just gives my TCP a "floor" rate r, I use that r and a big
>> (delay*bw) bucket b and let the tcp run as fast as it can. If I'm
>> happy with a (cheaper?) reservation for a fixed-rate transfer, I use
>> my r and a smaller b, and clamp the window size of my TCP down a bit.
>
>This is really annoying since I sent a long message about this and you
>didn't bother to reply.
>
>As an example, imagine I sit at an SCC and I'd like to get 30 Mb/s
>through a 44 Mb/s pipe, but would settle for 1 Mb/s if that was my
>fair share.  I set r according to the minimum rate and b according to
>the delay bandwidth if I actually got 30 Mb/s.  What I don't realize
>is a dozen or so other people do the same thing at the same time.  The
>router is required to give me that buffering before dropping.  On the
>other hand if there were two such users who both set b according to
>the 1 Mb/s d*bw, TCP performance would be quite poor (too little
>buffering and TCP don't get along - proven empirically many times).

Two things, one for each of your points.

First, c-l is not a guaranteed service. If you have accepted a bunch of
flows with low rate r and large burst/buffer size b, you are well within
your rights to statistically allocate shared buffering to the pool of flows
- if they all happen to burst at the same time, you'll lose, but that won't
happen very often because (if the flows are in profile) large bursts and
low average rates means wide spacing between bursts. If a flow goes out of
profile, of course, you have no obligation to give it the b it asked for -
if buffers are short, you may give it whatever you can.

Second, the controlled-load b term sets a minimum expectation on the
buffering, not a maximum. The c-l spec does not say that packets which
don't fit in b are discarded. In fact, it says the opposite.

>> Again, we are talking about what happens to traffic which is
>> over-reservation when the network is overloaded. It's -expected- to
>> get poor service, and if it's adaptive it's expected to back off.
>
>No kidding.  Reservations in an underutilized network is not very
>interesting.  Making things only work well for that case isn't very
>interesting either.

Actually, we -are- talking about reservations in an underutilized network.
In a fully utilized network, over-reservation flows will just lose. The
thing we are talking about is what happens when the network is enough
underutilized that a flow should reasonably get more of something than its
reservation would give it.

>You may want to support 3 behaviors:
>
>	1.  the one you have (delay non-conformant)
>	2.  police and drop
>	3.  what I described as b==0

Again, c-l does not require behavior 1. I think you are confusing "give
best-effort service to over-profile flows" with "put all of the
over-profile packets from each flow into a separate best-effort queue". The
spec says the first. It does not mean the second. If you are reading those
as the same thing, it is a (useful) comment on the clarity of the spec, not
on what is being specified.

c-l disallows behavior 2, for reasons we've talked about before. It favors
behavior 3, b==0 or not. As discussed above, it also allows behavior 1, but
does not look that kindly on it.

More about this coming in a reply to Roch's note.

                -john

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 28 Feb 1996 23:45:40 -0500

> consider it a close judgement call between disallowing it and allowing it

If there is no way to ask for this behaviour or not ask for it and no
way to determine if a router is doing this reordering, then it isn't
possible to determine if you will get usable service.

I think the only alternative you offer is to drop non-conformant
traffic.  That's also not very good for elastic traffic.

> if buffers are short, you may give it whatever you can.

This use of CL with elastic traffic isn't clear in the draft.  I also
question whether the added information that a flow intends to exceed
its rate indefinitely if it can would be useful.

With elastic traffic (TCP) and a low minimum, the intention is to
exceed the profile by as much as you can without causing drop.  If you
set b==0, then you have indicated a flow that intends to overfill its
profile and wants a lot of buffering with feedback.  If you have a
flow with b=X, it intends to limit traffic to a given rate (r) except
for bursts not to exceed "b", so you might be inclinded to avoid
dropping these.

> don't fit in b are discarded. In fact, it says the opposite.

There is still no way for an elastic flow to know what to specify for
"b".

> reservation would give it.

What I'm talking about is utilizing the network to its limit, but
specifying reservation that are within the network's limits.

Consider an example.  You have 44 Mb/s.  10 real time flows come along
and want 1 Mb/s each with some buffering "b" each.  10 elastic flows
come by and ask for a minimum of 1 Mb/s each.  They really are capable
of 10 Mb/s each if there were no congestion.  The real time flows
should see no loss at all if conformant.  The elastic flows should
settle at 3.4 Mb/s each or better if the real time flows don't use
their entire 1 Mb/s each (ideal world - perfect fairness - I don't
expect to really see perfect fairness).

> does not look that kindly on it.

1. That's not at all clear in the spec.

2. Not knowing if you'll get the "b" you ask for is fine for elastic,
but not very good for real time.

3. There is no way for a TCP connection to estimate "b" without
knowing both the rate it will actually get and the RTT .

> More about this coming in a reply to Roch's note.

I still think you need to change the spec.

Curtis