From: Eric Dumazet <eric.dumazet@gmail.com>
To: apetlund@simula.no
Cc: "Ilpo Järvinen" <ilpo.jarvinen@helsinki.fi>,
"Arnd Hannemann" <hannemann@nets.rwth-aachen.de>,
Netdev <netdev@vger.kernel.org>,
LKML <linux-kernel@vger.kernel.org>,
shemminger@vyatta.com, "David Miller" <davem@davemloft.net>
Subject: Re: [PATCH 2/3] net: TCP thin linear timeouts
Date: Thu, 29 Oct 2009 16:50:18 +0100 [thread overview]
Message-ID: <4AE9B9BA.7020207@gmail.com> (raw)
In-Reply-To: <69812160e5682c9fb4acba05bc082664.squirrel@webmail.uio.no>
apetlund@simula.no a écrit :
>> Andreas Petlund a écrit :
>> There should be a limit to linear timeouts, to say ... no more than 6
> retransmits
>> (eventually tunable), then switch to exponential backoff. Maybe your
> patch
>> already implement such heuristic ?
>>
>
> The limitation you suggest to the linear timeouts makes very good sense.
> Our experiments performed on the Internet indicate that it is extremely
> rare that more than 6 retransmissions are needed to recover. It is not
> included in the current patch, so I will include this in the next
> iteration.
>
>> True link collapses do happen, it would be good if not all streams
> wakeup
>> in the same
>> second and make recovery very slow.
>>
>
> Each stream will have its own schedule for wakeup, so such events will
> still be subject to coincidence. The timer granularity of the TCP wakeup
> timer will also influence how many streams will wake at the same time. The
> experiments we have performed on severely congested bottlenecks (link
> above) indicate that the modifications will not create a large negative
> effect. In fact, when goodput is drastically reduced due to severe
> overload, regular TCP and the LT and dupACK modifications seem to perform
> nearly identically. Other scenarios may exist where different effects can
> be observed, and I am open to suggestions for further testing.
>
>> Thats too easy to accept possibly dangerous features with the excuse of
> saying
>> "It wont be used very much", because you cannot predict the future.
>
> I agree that it is no argument to say that it won't be used much; indeed,
> my hope is that it will be used much. However, our experiments indicate no
> negative effects while showing a large improvement on retransmission
> latency for the scenario in question. I therefore think that the option
> for such an improvement should be made available for time-dependent
> thin-stream applications.
>
Thanks ! I must say I am very interested by these experiments, I am looking
forward your next iteration.
next prev parent reply other threads:[~2009-10-29 15:50 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-10-29 15:43 [PATCH 2/3] net: TCP thin linear timeouts apetlund
2009-10-29 15:50 ` Eric Dumazet [this message]
2009-10-29 20:52 ` Ilpo Järvinen
-- strict thread matches above, loose matches on Subject: below --
2009-10-30 15:27 apetlund
2009-10-30 10:48 apetlund
2009-10-30 17:33 ` Rick Jones
2009-10-30 18:11 ` William Allen Simpson
2009-11-05 13:37 ` Andreas Petlund
2009-10-29 16:54 apetlund
2009-10-29 15:19 apetlund
2009-10-29 15:14 apetlund
2009-10-27 16:31 Andreas Petlund
2009-10-27 16:56 ` Eric Dumazet
2009-10-28 12:58 ` Arnd Hannemann
2009-10-28 14:31 ` Ilpo Järvinen
2009-10-29 13:51 ` Andreas Petlund
2009-10-29 14:24 ` Eric Dumazet
2009-10-29 17:01 ` Rick Jones
[not found] ` <07CD1135-C68B-4264-8CD3-C4BC0400FDA2@simula.no>
2009-10-29 16:11 ` Arnd Hannemann
2009-10-28 3:20 ` William Allen Simpson
2009-10-29 13:50 ` Andreas Petlund
2009-10-28 14:18 ` Ilpo Järvinen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4AE9B9BA.7020207@gmail.com \
--to=eric.dumazet@gmail.com \
--cc=apetlund@simula.no \
--cc=davem@davemloft.net \
--cc=hannemann@nets.rwth-aachen.de \
--cc=ilpo.jarvinen@helsinki.fi \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=shemminger@vyatta.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.