netdev - Re: [PATCH] TCP_USER_TIMEOUT: a new socket option to specify max timeout before a TCP connection is aborted

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]

Date:	Mon, 30 Aug 2010 13:25:02 -0700 (PDT)
From:	David Miller <davem@...emloft.net>
To:	hkchu@...gle.com
Cc:	eric.dumazet@...il.com, hannemann@...s.rwth-aachen.de,
	hagen@...u.net, lars.eggert@...ia.com, netdev@...r.kernel.org
Subject: Re: [PATCH] TCP_USER_TIMEOUT: a new socket option to specify max
 timeout before a TCP connection is aborted

From: Jerry Chu <hkchu@...gle.com>
Date: Sun, 29 Aug 2010 23:54:48 -0700

> On Sun, Aug 29, 2010 at 9:19 PM, David Miller <davem@...emloft.net> wrote:
>> From: Jerry Chu <hkchu@...gle.com>
>> Date: Sun, 29 Aug 2010 17:23:05 -0700
>>
>>> Personally I think as an API, it's easier for an application to
>>> grasp the concept of a time quantity than # of
>>> retransmissions. (E.g., how will an app determine it needs 10
>>> retries vs 20 retries?)
>>
>> Conversely how can the user grasp how many actual attempts will
>> be made if backoff is employed?
>>
>> It's very easy to under-cap the number of actual packet send
>> attempts that will be made specifying just a timeout, in the
>> presence of backoff.
> 
> My previous statement presumes applications care less about exactly
> how many times retransmission attempts have been made because
> that's more of "implementation detail" for a reliable transport. But I can
> see one can argue either way effectively so I'm ok with both. If people
> prefer timeout in # of retries then it just needs to be converted to time
> units when used in conjunction with the USER TIMEOUT option (and
> one can readily use the existing "retransmits_timed_out()" function,
> although the latter presents only an approximation).

I was just saying that it can result in unexpected situations.  The
user can increase and increase the timeout they use, but to no effect
because due to backoff the increase isn't adding any more probes at
all.

In any event, I've applied your patch, let's see how this goes.

Thanks!
--
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