Re: [net-next PATCH v4 1/3] net: TCP thin-stream detection

["Ilpo Järvinen" <ilpo.jarvinen@helsinki.fi>]

On Sun, 21 Feb 2010, Pavel Machek wrote:

> Hi!
> 
> > +After analysing a large number of time-dependent interactive
> > +applications, we have seen that they often produce thin streams
> > +and also stay with this traffic pattern throughout its entire
> > +lifespan. The combination of time-dependency and the fact that the
> > +streams provoke high latencies when using TCP is unfortunate.
> > +
> > +In order to reduce application-layer latency when packets are lost,
> > +a set of mechanisms has been made, which address these latency issues
> > +for thin streams. In short, if the kernel detects a thin stream,
> > +the retransmission mechanisms are modified in the following manner:
> > +
> > +1) If the stream is thin, fast retransmit on the first dupACK.
> > +2) If the stream is thin, do not apply exponential backoff.
> 
> 2) seems very dangerous/unfair. If network  congestion is caused just
> by thin streams, will the network just fall apart?

...Network will not fall apart. Two possible cases:

a) cwnd > 1 segment, on RTO the window is reduced, thus the sender backs 
off regardless of exponential backoff.
b) All flows have window of 1 already... Well, what do you suggest? I'd 
say that obviously the network is seriously underprovisioned for the 
workload and since the bottleneck can only serve some of them anyway 
dropping the rest, no useless work gets done at the bottleneck. RTT 
estimator then gets a new samples whenever a flow belongs into the lucky 
group. In case any unnecessary retransmission happened (if there was 
very dramatic and sudden increase transient in the workload) they won't 
happen thereafter (unless we increase the workload toward infinity).

...Thus no problem of "falling apart".

-- 
 i.