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

[David Miller <davem@davemloft.net>]

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

> On Sun, Aug 29, 2010 at 9:19 PM, David Miller <davem@davemloft.net> wrote:
>> From: Jerry Chu <hkchu@google.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!