lkml.org 
[lkml]   [2010]   [Feb]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [net-next PATCH v4 1/3] net: TCP thin-stream detection
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.


\
 
 \ /
  Last update: 2010-02-21 23:33    [W:0.077 / U:1.464 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site