Message-ID: <AANLkTi=B4gtLxfDnJOuXUCoA79bV4c0cgSn+y36N0iRb@mail.gmail.com>
Date:	Wed, 25 Aug 2010 13:20:52 -0700
From:	Jerry Chu <hkchu@...gle.com>
To:	Hagen Paul Pfeifer <hagen@...u.net>
Cc:	Arnd Hannemann <hannemann@...s.rwth-aachen.de>,
	Eric Dumazet <eric.dumazet@...il.com>,
	ilpo.jarvinen@...sinki.fi, davem@...emloft.net,
	netdev@...r.kernel.org
Subject: Re: [PATCH] TCP_FAILFAST: a new socket option to timeout/abort a
 connection quicker

Hi Hagen,

On Wed, Aug 25, 2010 at 1:21 AM, Hagen Paul Pfeifer <hagen@...u.net> wrote:
>
> On Tue, 24 Aug 2010 15:13:44 -0700, Jerry Chu <hkchu@...gle.com> wrote:
>> On Tue, Aug 24, 2010 at 9:28 AM, Hagen Paul Pfeifer <hagen@...u.net>
> wrote:
>
>> So it looks like the user timeout can be used in either senario
> (shortening
>> or lengthening) and in both cases is a lower bound, i.e., the connection
>> should abort at or shortly after the specified user timeout.
>>
>> In this case does it make sense to combine the two? Will your TCP_UTO
>> patch be ready anytime soon?
>>
>> Again an alternative is to allow configuring tcp_retries2 and
> TCP_RTO_MAX
>> directly. I'm open to suggestion but we'd like to get something in
> sooner.
>
> Hello Chu! My Idea: you provide functionality to modify the user timeout.
> The interface should be generic enough to allow small as well as large - up
> to 22 days - values.

Ok, let's try to finalize the API signature so our apps folks can program to it
now and don't have to change it later when we have a more complete
implementation involving the TCP option as well.

What should we call this new option? TCP_UTO or TCP_USERTIMEOUT
or else?

It will take a single argument of unsigned int in milliseconds
(right?) that specifies
"user_timeout". The first retransmit timer pops after user_timeout will cause
the connection to be aborted and ETIMEOUT to be returned.

The RTO backoff code is largely intact. I've added some small tweak when
user_timeout is small to allow for a couple of more retries.

>This interface should be sufficient for you and later
> for me. Afterwards I provide an patch which apply on your groundwork. My
> patch handle TCP UTO specific functionality like TCP option protocol
> handling functionality, socket option, permissions, lower- and upper
> bounds, ...

Sounds good - you will provide all the missing details as described in RFC5482.

>
> Did you check interactions with other TCP timers like keep-alive timer?

The keepalive timer is driven off a different timer sk_timer than
icsk_retransmit_timer
so as far as code is concerned they are separate (and I don't see any
interaction
between the two).

But RFC5482 does contain the following paragraph:

4.2. TCP Keep-Alives

   Some TCP implementations, such as those in BSD systems, use a
   different abort policy for TCP keep-alives than for user data.  Thus,
   the TCP keep-alive mechanism might abort a connection that would
   otherwise have survived the transient period without connectivity.
   Therefore, if a connection that enables keep-alives is also using the
   TCP User Timeout Option, then the keep-alive timer MUST be set to a
   value larger than that of the adopted USER TIMEOUT.

At this moment I'm not inclined to muck with the keepalive code (although
the change could be simple) so I'll leave this case for you to handle.

>
> Today in the evening I will focus on TCP Quick ACK modifications. After
> that I am in the Alps for vacation for 5 days. Later on I will work on the
> patch (the patch is in a good state, modification and testing should
> consume only 2 evenings - hopefully ;-).
>
> Cherry, is this ok for you?

Sound good (and it's Jerry, not the girlish Cherry :) Oh, please comment on
my plan above.

Jerry

>
> Hagen
>
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists