From: Hagen Paul Pfeifer <hagen@jauu.net>
To: Arnd Hannemann <hannemann@nets.rwth-aachen.de>
Cc: Lars Eggert <lars.eggert@nokia.com>, Jerry Chu <hkchu@google.com>,
Eric Dumazet <eric.dumazet@gmail.com>,
<ilpo.jarvinen@helsinki.fi>, <davem@davemloft.net>,
<netdev@vger.kernel.org>
Subject: Re: [PATCH] TCP_FAILFAST: a new socket option to timeout/abort a connection quicker
Date: Thu, 26 Aug 2010 09:42:36 +0200 [thread overview]
Message-ID: <721573f62ad1c200e14e446297ebefed@localhost> (raw)
In-Reply-To: <4C7613D8.2040705@nets.rwth-aachen.de>
On Thu, 26 Aug 2010 09:12:24 +0200, Arnd Hannemann wrote:
>> USER_TIMEOUT is what is locally used for a connection (i.e., takes into
>> account what the remote peer advertised and what we'd like to use),
while
>> ADV_UTO is (only) what we'd like to use and are advertising.
>>
>> (Yes, we initially thought we could make the mechanism simpler, but
then
>> we started to think through all the corner cases...)
>>
>
> But from the application point of view it is enough to request a
> specific UTO
> as a socket option, (which will then get announced via ADV_UTO), right?
> Is there any reason, (besides local policy) to not abort the connection
> locally
> after the time the application specified via the above mentioned socket
> option?
The original USER_TIMEOUT (RFC 793) functionality boils down to Jerry's
TCP_FAILFAST patch. This _per see_ has no correlation with the ADV_UTO.
Likely that the ADV_UTO will update the USER_TIMEOUT too. I change my
position from day to day: artificially limit the mechanism and provide a
per see "clever" mechanism and keep both values coherent or provide all
freedom to the user.
Hagen
next prev parent reply other threads:[~2010-08-26 7:42 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-08-24 6:20 [PATCH] TCP_FAILFAST: a new socket option to timeout/abort a connection quicker H.K. Jerry Chu
2010-08-24 6:44 ` Eric Dumazet
2010-08-24 8:04 ` Arnd Hannemann
2010-08-24 9:10 ` Hagen Paul Pfeifer
2010-08-24 14:58 ` Arnd Hannemann
2010-08-24 16:28 ` Hagen Paul Pfeifer
2010-08-24 22:13 ` Jerry Chu
2010-08-25 8:21 ` Hagen Paul Pfeifer
2010-08-25 20:20 ` Jerry Chu
2010-08-25 22:59 ` Hagen Paul Pfeifer
2010-08-26 1:49 ` Jerry Chu
2010-08-26 6:01 ` Lars Eggert
2010-08-26 7:12 ` Arnd Hannemann
2010-08-26 7:42 ` Hagen Paul Pfeifer [this message]
2010-08-26 7:27 ` Hagen Paul Pfeifer
2010-08-24 21:56 ` Jerry Chu
2010-08-24 20:47 ` Jerry Chu
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=721573f62ad1c200e14e446297ebefed@localhost \
--to=hagen@jauu.net \
--cc=davem@davemloft.net \
--cc=eric.dumazet@gmail.com \
--cc=hannemann@nets.rwth-aachen.de \
--cc=hkchu@google.com \
--cc=ilpo.jarvinen@helsinki.fi \
--cc=lars.eggert@nokia.com \
--cc=netdev@vger.kernel.org \
/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.