Messages in this thread | | | Date | Mon, 22 Feb 2010 00:31:27 +0200 (EET) | From | "Ilpo Järvinen" <> | Subject | Re: [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.
| |