Subject: Re: Concerns about exported numbers

From: [email-masked] (Fred Baker)
Date: Fri, 19 Jan 1996 06:25:00 -0800

At 1:10 AM 1/16/96, Jon Crowcroft wrote:
>explicitly, for controlled load, we would like _all packets dropped_
>to be part of the specification.....or at least some fixed
>behaviour...

I would suggest that we do this (this is what I do). I believe that this is
pretty much how the specification reads...

measure the traffic rate using a token bucket, and treat excess traffic as
if it had been classified as best effort traffic in the first place. If
that means that it would experience excessive delay and therefore be
dropped, or would be marked by RED, so be it.

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Suppose you were an idiot.  And suppose you were a [politician].
But I repeat myself. -- Mark Twain

---

From: Ashish Mehra <[email-masked]>
Date: Fri, 19 Jan 1996 10:04:21 -0500 (EST)

> dropped, or would be marked by RED, so be it.

If the goal was to preserve the *order* of packet transmissions on
a given flow/session, then treating excess traffic as best-effort
traffici while allowing other (compliant) traffic on that flow to 
proceed may violate this requirement. Maintaining the order of packet 
transmissions may be necessary to reduce buffering/playback delays
at the receiver, and would help reduce the reaction time of end-to-end
reliability protocols such as TCP. 

If progress on the flow is throttled until the outstanding excess traffic
clears the best-effort queue (s), this needlessly penalizes compliant traffic.

It seems that dropping excess traffic at the point of violation is
reasonable. Any comments?

Ashish

---

From: Jon Crowcroft <[email-masked]>
Date: Fri, 19 Jan 1996 16:59:12 +0000

>reasonable. Any comments?

agree ...  though mandating order ing is not needed, however, for
network load adaptive applications, the loss at the receiver ought to
be as ordered as possible w.r.t the legal contracted delivery....
to enable the adaption to be timeley...

 jon

---

From: Ashish Mehra <[email-masked]>
Date: Fri, 19 Jan 1996 13:15:36 -0500 (EST)

> to enable the adaption to be timeley...

An intermediate approach would be to allow excess traffic to receive
best-effort service as long as there is no outstanding compliant
traffic on this flow. This might be useful for certain kinds of connections,
especially when violations of traffic specification are short-term
in nature. For example, for bursty low-rate sessions, there may be
sufficient gap between bursts to squeeze "excess" (non-compliant)
traffic through. 

This does increase implementation complexity though, since the 
link shaping and scheduling modules need to maintain a little
more per-flow intelligence. For example, it must now be possible to
identify "excess" traffic on a per-flow basis.

Ashish

---

From: [email-masked] (John Krawczyk)
Date: Fri, 19 Jan 96 14:54:31 EST

Haven't we been here before?  The reason the specs were changed from
the original "drop non-conformant traffic" position was because,
otherwise, you can create a denial of service for best-effort
receivers by making a too-small reservation.  (check the mail archive
for details).

-jj