netdev - Re: [PATCH] TCP_FAILFAST: a new socket option to timeout/abort a connection quicker

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <AANLkTik5N=j-2NQRFFktOs7gfDEU=Gdrva4fw6BKRqxT@mail.gmail.com>
Date:	Wed, 25 Aug 2010 18:49:35 -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

On Wed, Aug 25, 2010 at 3:59 PM, Hagen Paul Pfeifer <hagen@...u.net> wrote:
> * Jerry Chu | 2010-08-25 13:20:52 [-0700]:
>
>>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?
>
> Well, currently I am not sure if this is the best idea. Your implementation
> address the local timeout, user's can tweak their local timeout. UTO on the
> other hand provides functionality to tweak peer's timeout. I will use your

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

> timeout implementation (see the comments below) if I receive a TCP UTO options
> message, but via setsockopt TCP_UTO I try to modify peer's TCP timeout. Local
> and remote RTO of them must not necessarily coherent.  For example the local
> RTO can be larger as the remote RTO.
>
> My idea is that TCP_UTO should be used for the remote part. Another option
> should be taken for the local part, no matter if TCP_UTO will overwrite the
> local part too if the local timeout if smaller as the announced timeout.

Ok. How about TCP_USER_TIMEOUT, which clearly refers to the local timeout?
(Is it useful to elevate it to SO_USER_TIMEOUT?)

You can call yours TCP_UTO and the key differentiator is 'O' (referring to a TCP
option).

>
> TCP_REMOTE_UTO and TCP_LOCAL_RTO, ... no idea at the moment! ;(
>
> Any ideas on that?
>
>>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.
>
> 2^32 / (1000 * 60 * 60 * 24) > 22 days -> great!
>
>>>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, ...
>>
>>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.
>
> Sounds good for me! I mean I must see working code for final conclusion, but
> the basic components are good. And sorry for the naming, Jerry - it was not
> intention!

Ok, will send a new patch soon (but please comment on the above and naming).

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