Thread (13 messages) 13 messages, 6 authors, 2017-08-18

Re: [PATCH v1 net] TCP_USER_TIMEOUT and tcp_keepalive should conform to RFC5482

flat view

From: Jerry Chu <hidden>
Date: 2017-08-10 03:32:43

On Wed, Aug 9, 2017 at 5:47 PM, Rao Shoaib [off-list ref] wrote:

On 08/09/2017 05:30 PM, David Miller wrote:
quoted
From: Joe Smith <redacted>
Date: Wed, 9 Aug 2017 17:20:32 -0700
quoted
Making Linux conform to standards and behavior that is logical seems
like a good enough reason.
That's an awesome attitude to have when we're implementing something
new and don't have the facility already.

But when we have something already the only important consideration is
not breaking existing apps which rely on that behavior.

That is much, much, more important than standards compliance.

If users are confused, just fix the documentation.
David,

If it was just confusion than sure fixing the documentation is fine. What if
the logic is incorrect, does not conform to the standard that is says it is
Not sure what part of logic is "incorrect" when it was a homegrown Linux API
with no need to conform with any "standard"? Note that the new API was invented
7 years ago not out of need for RFC5482. In fact I initially call the option
TCP_FAILFAST and did not even know the existence of RFC5482 until someone
around the same time proposed a UTO option specifically for RFC5482 and I
thought the two can be combined. (This is roughly the memory I can
recollect so far.)

So you see my focus back then was to devise a "failfast" option whereas RFC5482
was meant for a "failslow" case. I think that explains why I let the
option override
keepalive so a TCP connection can "fail fast" while RFC5482 4.2 tries to prevent
keepalive failure ahead of UTO, favoring "fail slow".

If we start from a clean slate then perhaps one can argue the semantic
either way
but we do not have a clean slate. For that I still slightly favor not
changing the code
because the risk of breakage is definitely non-zero and the issue you're having
seem to be only related to documentation.

Jerry
implementing and easy to fix with little or no risk of breakage.

The proposed patch changes a feature that no one uses. It also imposes the
relation ship between keepalive and timeout values that is required by the
RFC and make sense.

You are the final authority, if you say we should just fix the documentation
than that is fine.

Shoaib
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help