I like the idea of reusing the channel option KEEPALIVE_TIMEOUT for this, but I am hesitant for exactly the reason that you pointed out. It would give meaning to KEEPALIVE_TIMEOUT even if keepalive is disabled by setting KEEPALIVE_TIME to infinite. Also, given the fact that TCP_USER_TIMEOUT is not supported for on all platforms, it would mean that KEEPALIVE_TIMEOUT would behave differently on different systems. On the other hand, if we isolate this as a separate parameter for only those platforms that support it, it allows us to explicitly say that it is only valid for linux kernel versions 2.6.37 and later.
TCP_USER_TIMEOUT should not have any affect on retransmits, other than shutting down the connection (which ofcourse might prevent a retransmit from taking place). I am currently of the opinion that if an application decides to change the timeout value from the default of 20 seconds, it is doing so knowingly and owns the responsibility of connections being dropped because of that. On Thursday, August 23, 2018 at 8:45:15 AM UTC-7, Eric Anderson wrote: > > Also, this stuff is pretty complex for users already. Adding *yet another* > configuration > parameter just worsens that. I'd much rather they just set one set of > parameters and we make the most use of them as we can on each platform. > > On Thu, Aug 23, 2018 at 8:43 AM Eric Anderson <[email protected] > <javascript:>> wrote: > >> I'd prefer we re-used KEEPALIVE_TIMEOUT for this. This would change the >> semantics slightly, as right now the value does nothing when KEEPALIVE_TIME >> is infinite (the default). However, it makes a lot of sense to use the same >> value for both entries because they have mostly-shared fate. The only >> difference is that keepalive goes through the remote application whereas >> TCP_USER_TIMEOUT can be triggered directly by the kernel. The kernel will >> delay ACKs to combine them or to attach them to outgoing data. So when >> sending a keepalive, I'd expect the application to influence how soon data >> is ACK'ed, so they would be transmitted on the same packet frequently. >> >> Also, KEEPALIVE_TIMEOUT is limited to no lower than 10 seconds. That is a >> very appropriate limit for TCP_USER_TIMEOUT as well, as application authors >> will commonly think "oh, a second looks good!" or "Oh, 100ms is plenty!". >> But that ignores retransmits and puts applications in a very dangerous >> position that can cause network collapse when the network slows down, even >> with datacenter networks. >> >> On Wed, Aug 22, 2018 at 1:23 PM yashkt via grpc.io < >> [email protected] <javascript:>> wrote: >> >>> This is the discussion thread for the proposal at >>> https://github.com/grpc/proposal/pull/95 >>> >>> The proposal is to provide an option to set the socket TCP_USER_TIMEOUT >>> for platforms running on Linux kernels 2.6.37 and later. >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "grpc.io" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected] <javascript:>. >>> To post to this group, send email to [email protected] >>> <javascript:>. >>> Visit this group at https://groups.google.com/group/grpc-io. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/grpc-io/4d585ee1-2dba-4895-9d55-b637a587b93d%40googlegroups.com >>> >>> <https://groups.google.com/d/msgid/grpc-io/4d585ee1-2dba-4895-9d55-b637a587b93d%40googlegroups.com?utm_medium=email&utm_source=footer> >>> . >>> For more options, visit https://groups.google.com/d/optout. >>> >> -- You received this message because you are subscribed to the Google Groups "grpc.io" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/grpc-io. To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/9726d6d8-a614-498b-b2b6-d32c1e4b3902%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
