Also, https://github.com/grpc/proposal/blob/master/A8-client-side-keepalive.md specifies that KEEPALIVE_TIME is restricted to 10 seconds, but doesn't seem to impose a similar restriction on KEEPALIVE_TIMEOUT
On Thursday, August 23, 2018 at 10:21:08 AM UTC-7, [email protected] wrote: > > 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]> 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]> 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]. >>>> 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/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/325acccc-f910-49fe-b90e-f0fc0bfb76fa%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
