From: Arnd Hannemann <hannemann@nets.rwth-aachen.de>
To: Lars Eggert <lars.eggert@nokia.com>
Cc: Jerry Chu <hkchu@google.com>, Hagen Paul Pfeifer <hagen@jauu.net>,
Eric Dumazet <eric.dumazet@gmail.com>,
"ilpo.jarvinen@helsinki.fi" <ilpo.jarvinen@helsinki.fi>,
"davem@davemloft.net" <davem@davemloft.net>,
"netdev@vger.kernel.org" <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:12:24 +0200 [thread overview]
Message-ID: <4C7613D8.2040705@nets.rwth-aachen.de> (raw)
In-Reply-To: <3CD6E1F6-9143-43B9-A6D2-9B09F18C9C2E@nokia.com>
Hi Lars,
Am 26.08.2010 08:01, schrieb Lars Eggert:
> On 2010-8-26, at 4:49, Jerry Chu wrote:
>
>> Yes on a 2nd look RFC5482 seems more complex than I originally thought, allowing
>> many different combinations of local/adv/remote UTO... Are they really
>> useful, e.g.,
>> why allowing USER_TIMEOUT to be different from ADV_UTO?? My original thought
>> was the local UTO will always be the same as the one advertised to
>> remote so only
>> one API will be needed plus bunch of flags for ENABLED, CHANGEABLE...
>>
>
> 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?
Best regards,
Arnd
next prev parent reply other threads:[~2010-08-26 7:39 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 [this message]
2010-08-26 7:42 ` Hagen Paul Pfeifer
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=4C7613D8.2040705@nets.rwth-aachen.de \
--to=hannemann@nets.rwth-aachen.de \
--cc=davem@davemloft.net \
--cc=eric.dumazet@gmail.com \
--cc=hagen@jauu.net \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).