Subject: RE: Speed field in RTSP

From: Eric Fleischman <[email-masked]>
Date: Wed, 2 Apr 1997 11:03:31 -0800

Rob Lanphier wrote on Sunday, March 30, 1997 9:39 AM:

	>Let's say that you have a stream that takes far less than the
available
	>bandwidth, and you would like to buffer up a large portion of
the stream
	>while the network is clear, so that you can scale back later
when the
	>network is congested.

What you are proposing is that a human - working in human time - can
somehow determine future network states and can do so with adequate
foresight to instruct streaming engines to correctly handle those events
(i.e., you also must account for the latencies for your commands to
reach the server and be executed by the server). I can't imagine how
this could possibly work in real life. Thus, this idea is fatally flawed
due to the required human involvement.

However, even if humans weren't involved, the idea would still be
problematical. This is because application layer protocols lack the
insight to know what is happening at the network layer to transparently
enable what you desire. Should you add in heuristics at the application
layer to discern network layer states, the granularity of those
heuristics are such that there is a high probability that the state has
changed. Adaptive mechanisms put at the application layer (RTCP) at best
can respond to prolonged situations determined via statistical sampling
- not to local transients. This makes application layer "control" only
able to accurately respond to statistically stable, macro events.

There is the inherent problem of not knowing the future and therefore
not knowing how to interpret data rate "spikes" -- including how long
they will endure and when new spikes will occur. On what basis could an
application layer entity ever discern that the "network is currently
clear"? At best, it can discern that the network was clear a short while
ago or that it has been statistically "clear" of late.

	>There are other uses for this, but rather than getting into
those, please
	>explain why non-RSVP routers care what the data rate is.  Also
please
	>explain why variable bitrates are not good from a
"good-netizen" point of
	>view.  The reason why I ask is because we've taken heat before
as "non net
	>friendly" for *not* responding to network conditions, and now
you are
	>alarmed by the mechanism which would allow for that.

This is not a router issue unless (and until) network resources become
so saturated that packets are dropped or unacceptably delayed.

It is rather a network management issue. Here's a part of the problem:
applications using TCP have some sensibility to network conditions
(e.g., throttling back under certain conditions). Applications using UDP
are not sensitive to network conditions. Thus, when mixed together, UDP
traffic has a natural tendency to "gobble up" the available bandwidth.
Network managers therefore try to enact corporate network policies to
ensure that the data which is most valuable to the corporation actually
gets through. This frequently means explicit attempts to limit the
bandwidth taken by isochronous traffic.

End users are rarely versed in corporate network policies. Your plan
gives end users the willy-nilly ability to arbitrarily consume network
bandwidth as they see fit. This ability would directly thwart the
efforts of network managers. The natural response to this occurring
would be for senior management to ban such products as being "Bad
Network Citizens" until such a time as they could be ensured to behave
responsibly.