lkml.org 
[lkml]   [2009]   [Nov]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 1/3] net: TCP thin-stream detection
Arnd Hannemann wrote:
> Both mechanism prevent retransmission timeouts, thereby reducing latency.
> Who cares, that they were motivated by performance?

The essence of motivation is that there exist an incentive for performing an
action. If the motivation for fast retransmitting earlier is to keep the cwnd
open for a greedy application with small time-dependency, the question may be
posed whether it is worth the effort of the proposed changes. With the
thin-stream applications, we have confirmed that this is very often an
indication of time-dependent/interactive applications (like SSH-text sessions,
RDP, sensor networks, stock trading systems, interactive games etc). We have
further shown that such applications are prone to lag upon retransmissions due
to the inadequacies of TCP to deal with thin streams. We have also shown that
by performing the proposed adjustments, we can drastically improve the
situation.

Since we now know that the modifications can drastically improve the user
experience, the motivation/incentive for implementing the modifications is
increased.

> I agree, that you are more aggressive, and that your scheme may have
> latency advantages, at least for the Limited Transmit case. And there are
> probably good reasons for your proposal. But I really think you should
> bring your proposal up in IETF TCPM WG. I have the feeling that there are
> a lot of corner cases we didn't think of.
>
> One example: Consider standard NewReno non-SACK enabled flow:
> For some reasons two data packets get reordered.
> The TCP sender will produce a dupACK and an ACK.
> The dupACK will trigger (because of your logic) a spurious retransmit.
> The spurious retransmit will trigger a dupACK.
> This dupACK will again trigger a spurious retransmit.
> And this game will continue, unless a packet is dropped by coincidence.

Such an effect will be extremely rare. It will depend on the application
producing an extremely even flow of packets with just the right
interarrival time, and also on reordering of data (which also will
happen very seldom when the number of packets in flight are so low).
Even though it can happen, the data flow will progress (with spurious
retransmissions). The effect will stop as soon as the application sends
more than 4 segments in an RTT (which will disable the thin-stream
modifications) or less than 1 (which will cause all segments to be
successfully ACKed), or if, as you say, a packet is dropped.

I will be thankful for more input on eventual corner cases and also on
test cases that we may perform to evaluate the modifications for
scenarios that are of concern.

Best regards,
Andreas






\
 
 \ /
  Last update: 2009-11-05 14:37    [W:0.040 / U:0.716 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site