Re: [quicwg/base-drafts] Idle timeout interaction with RTO (#1429)

[ianswett <[e-mail]>]

Your last point about asymmetric-ness is important.  The Chromium implementation does something like what you described with asymmetric timeouts.

I would prefer to document a more general approach I briefly mentioned above, where you can't send new data within some time of the idle timeout, but you will continue to process and respond to incoming data until the timeout is hit, or maybe even a bit longer.  I think this works well for non-HTTP applications, whereas picking a shorter timeout on the client side only really works well for client driven apps like HTTP.

A simple approach might be: "New data must be sent with at least one RTO timeout remaining, and data should be received, processed and responded to for at least one RTO timeout after the specified idle timeout expires."?  Receiving and processing a new packet resets the idle timeout, so there's no special case necessary for sending in response to a packet received at the very end of the connection.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/1429#issuecomment-397319588