Draft: draft-ietf-quic-transport

Commentary: This makes idle timeout symmetric by stating that a peer will close the connection at or soon after the idle timeout expires , creating clear expectations of idle timeout behavior . This also renames the transport parameter idletimeout to maxidle_timeout for clarity . Takes some of the improved text from 
 and I filed a new issue ( ) for your comments on the existing idle timeout text . I hope all of those comments can be addressed in an editorial PR . 
 This is failing due to a QPACK error , but I believe the PR is done . As noted above , I opened for the many comments about the existing text . I can take a stab at this , but I 'd like to do that separately from this design change . 
 In I received a number of comments on the existing text from and . This is an issue to track improving that text in a separate PR . One suggestion was to introduce an ITO(Idle Timeout ) acronym . 
 thinks cognitive load is increased by ITO and it 's not that much shorter , so let 's not do that . 
 As it stands , the idle timeout period is used by both QUIC endpoints , and may be made available to the application but , it 's not clear how an endpoint should determine this value , it 's not explicitly stated that the min(server , client ) should be used , it 's not explicitly stated that this min value should be communicated to the application , which needs it to determine how often to send PINGs . A straw proposal is to use 30 seconds as the default idle timeout period , and state the other two points explicitly in the transport and http drafts . 
 I disagree with this . In total , but for various reasons . Endpoints have their own rules about how long they are willing to wait , so any recommendation is a bad idea . The min(client , server ) thing is not necessary . You might note that this is a natural consequence of the design , but this is a unilateral thing . If you want to wait longer , you can . This is particularly important in cases where connections are garbage - collected rather than reaped on a timer . In those cases , idle timeouts can be much longer on one end than the other if the short timer is GC'd . The endpoint that does GC might hold the connection alive much longer , and even initiate new activity on that connection well after its advertised timeout . This can be different to what endpoints might choose to do about keep NAT bindings alive . Keepalives are sent to keep bindings alive on paths and . Paths are not connections . 
 The recommendation is not for how long an endpoint is willing to wait , but a default recommendation for general purpose QUIC implementations . We have default recommendations in both the transport and the recovery draft based on best known practices . My suggestion for using 30 seconds as the default is based on GQUIC experience . The min ( ) thing is important IMO . Again , this is not a requirement , but keeping and trying a connection after you believe the peer to have closed it potentially wastes an RTT . HTTP connections using TCP do this all the time , and incur an RTT of delay . I 'm not suggesting that we do n't accommodate implementations that want to keep connections open for past the timeout period , but it 's worth explicitly noting the cost of using a potentially dead connection . For an unconstrained implementation , what value do you see in continuing with a connection after it is likely to have been discarded by the peer ? Endpoints need to keep not only NAT bindings alive but also potentially QUIC state at the peer alive . If a server is taking time to generate a response and there is a risk of the idle timeout closing the connection before the server sends a response . The application ( HTTP ) knows this , and is expected to send PINGs to keep the connection open , but without knowledge of the idle timeout at the peer , it has to guess how often to send a PING . 
 Yep , do n't think we need to recommend anything . min ( ) is not helpful except as a warning - and we already have that warning .  is an entirely different thing . Applications might decide to engage keepalives to keep paths active , or the connection as a whole , but the model should be that the application asks the transport to stay active and the transport manages that ( because only it knows about multiple paths and so on ) . 
 I think we have a corner case . Consider a case where the server advertises idle - timeout of 10 seconds and the client advertises 5 seconds . Should a client use a connection that has been idle for 6 seconds to send new requests ? The client can , if we require servers to keep the connection state open for the timeout it advertised ( i.e. 10 seconds ) regardless of the value advertised by the client . The client should not , if we think that the server is allowed to drop the connection after min ( ) seconds . Do we clearly state which way the server should behave in this example ? 
 makes a very good point . If we 're ok with the server looking at the client transport parameters and sending an idle timeout in it 's transport params that may be a function of the client 's , then this may not be a real issue , but if we truly want transport params to be unilateral advertisements , then this is a problem . I agree that the NAT timeout issue is totally separate , and I 'd like to keep this issue away from that if possible . 
 I like formulation of the min ( ) , but I do n't think we need to state what the server or client should do , rather we note the cost of using a dead connection . ( I 'm not opposed to saying that the endpoints should not use potentially dead connections , but I do n't think it 's necessary . ) The discussion on PINGs is not about NATs , to be clear . The text we have right now on keeping connections alive with PINGs leaves it up to the application to decide when to send a PING . Without knowing when this connection might be closed by QUIC underneath due to an idle timeout , when should the application send a PING ? I believe there 's a problem here that QUIC " negotiates " its idle timeout with the peer ( I know does n't agree , but an endpoint does need to figure out how to use the peer 's value ) , and HTTP is expected to keep the connection alive based on whether requests are pending or not , but we do n't talk anywhere about the interaction between the two . 
 To clarify , my point is that the logic the endpoint uses for detecting a potentially dead connection depends on if the peer is allowed to use min ( ) for determining how long the connection state needs to be maintained by the peer . 
 Conflating keep - alive with timeout is problematic due to hysteresis . You need to send keep alive at perhaps half the timeout interval , and if you do , the connection will not timeout , which is against the idea of a timeout . 
 Discussed in London ; Hum favoured exploring a solution with the min of the two sides . to write a PR to compare to push to master^H^H^H^HPR . 
 Discussed in Cupertino , reaffirmed as the solution . Folks should review now . ( Reason for : API observation ; no API to expose the case where ENOPEER ) . 
 suggested renaming the transport param to maxidletimeout to make it clearer that each peer is expressing its  . 
 I have suggestions for parts that did not read well to me , but otherwise LGTM.One more comment
Paragraph (version B):
An endpoint that sends packets near the end of the idle timeout
period risks having those packets discarded if its peer enters the
draining state before the packets arrive.  If a peer could time out
within a Probe Timeout (PTO; see Section 6.2.2 of QUIC-RECOVERY), it
is advisable to test for liveness before sending any data that cannot
be retried safely.  Note that it is likely that only applications or
application protocols will know what information can be retried.
Paragraph (version B):
The max idle timeout is a value in milliseconds that is encoded as
an integer; see (idle-timeout).  Idle timeout is disabled when
both endpoints omit this transport parameteter or specify a value
of 0.