Re: types of traffic in tcp congest control

["Anumita Biswas" <[e-mail]>]

Is it not true that overprovisioning is never a long term solution, as
bandwidth is never ever enough? As Alan says, "Usage expands to fit
network bandwidth".

Assuming that the above is true, it becomes necessary to follow one of
the below to solve the problem:
1. Continue with the present day best effort service and let congestion
happen in its non deterministic manner. Users are anyway not complaining
about the throughput they are getting today. 

2. Given that with Mice connections also congestion has been observed.
By Mice, correct me if I am wrong, we mean traffic corresponding to
typical request response type of connections, where at most 5 or 6 data
TCP packets traverse two way. These first few packets usually get going
in the slowstart phase of congestion control. And slowstart is by
definition itself non-aggressive. But if congestion is happening at this
stage itself, it clearly means that even slow start is aggressive enough
for a heavily loaded Internet. So, question is , should there be an
added term in the slow start equation that slows it down further. The
counter argument would be that, the user experience may suck as a result
of the added term.

3.  Going by a per TCP connection strategy(2 above) to reduce
congestion may not be an effective way of solving the problem. As each
individual TCP may not have the information to accurately determine the
state of the path to its destination. Logically, a third party may be in
a better position to dynamically measure bandwidth utilization and make
this information available to all the TCPs, then overall throughput may
be better. Is it worth considering separating out congestion control
from TCP Data flow and treat it as a separate protocol "building block",
(like a routing protocol perhaps) that calculates and stores information
about the state of the network in a distributed manner, which can then
be used by individual TCPs? Ofcourse, this is not backward compatible.
But if feasible, this would scale.

4. QoS is another option too. But the basis for differentiating service
would be user priority or the SLA. This model does not take into
consideration the congestion factor and hence will not be effective for
all. 

Any comments would be welcome,

thanks
Anumita

>>> Joe Touch <[e-mail]> 05/14/02 06:06AM >>>


Alan Cox wrote:
>>>A given number of Mice may consume the network and reduce effective
use of
>>>Elephants even with  Dense Wavelength Division Multiplexing in the
mix.
>>
>>Indeed, give way to mice will decrease the efficiency of the network,
but
>>gained a low queuing delay, that is a trade-off. As more real-time
>>applications are deployed to the Internet, it should be worthy.
> 
> 
> Economic reality #1: Usage expands to fit network bandwidth

Usage expands to fit available bandwidth when bandwidth is limited. 
Granted that's the case on most links (like most highways), which are 
deployed (by design) to barely keep pace with demand.

There are plenty of cases where this isn't true, however. Bandwidth can

be overprovisioned; it just usually isn't.

> Economic reality #2: People will pay more for QoS - right now via
private
> 		     IP networks

More specifically:

	People will pay more to avoid commercials and get higher
	bandwidth.

Users haven't been paying for anything sophisticated enough to call
QoS.

Joe