All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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 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.