Subject: Re: Concerns about exported numbers

From: [email-masked] (Fred Baker)
Date: Fri, 19 Jan 1996 10:09:49 -0800

At 10:04 AM 1/19/96, Ashish Mehra wrote:
>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.

I don't recall saying that I would reorder the traffic in this case.

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

This is very application dependent. It is true that pitching video traffic
at this point might be a good thing. But suppose that you are using RSVP to
guarantee an NFS stream certain characteristics? Chopping NFS's hands off
for sending too fast isn't going to be very productive. Better to use the
queuing mechanisms to give it some back pressure than to force it to
retransmit and therefore use even more bandwidth.

I would suggest that RSVP is potentially useful for something besides A/V
traffic, and if we lose sight of that we will significantly limit its
usefulness.

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
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 13:24:03 -0500 (EST)

> I don't recall saying that I would reorder the traffic in this case.

I am a little confused here. How would you treat excess traffic as best-effort
and allow future compliant traffic to continue, without inadvertently
reversing the order of packet transmissions on that flow? May be I 
am missing something here - please explain. 

> traffic, and if we lose sight of that we will significantly limit its

Good point. My suggestion is more applicable to streams where excessively
delayed data loses its utility. If all data must be transported to the 
receiver, some queueing would be good, i.e., do not drop but allow
flow/stream to receive best-effort service. I would argue that in this
case it would also be reasonable to throttle the traffic on this stream
until the outstanding "excess" traffic clears the best-effort queues.

I agree the best policy to employ is application (and transport-protocol)
dependent.