Draft: draft-ietf-quic-manageability

Commentary: Sect 4.8 : Reducing the timeout on UDP NATs “ Reducing the timeout on UDP NATs might be tempting in light of this property , but not all QUIC server deployments will be robust to rebinding . ” so now , I did not understand what was being discouraged here . Is this somehow linked to section 4.6 ’s discussion of holding state ? ( perhaps related to issue ) 
 Yes , this is connected to the advise in section 4.1 but I agree this could be clarified . can you have a look at this ? 
 I can certainly write up something here , but I think we should decide what the actual guidance is before I write it . The NAT UDP timeout is traditionally short ; should it be ( 1 ) even shorter ; ( 2 ) remain the same ; or ( 3 ) become longer ? A legacy NAT that is not parsing QUIC headers at all can probably leave the timeout as it is ; QUIC should be pretty robust to NAT rebindings for several reasons , and we do n't want to mess with existing UDP flows . Maybe my " do n't use connection ID at all " guidance has an exception ? A QUIC - aware NAT that detects QUIC via a consistent CID field could use a even shorter timeout . But ultimately we 're somewhat stuck by " QUIC is robust to NAT rebinding but sometimes it is n't . " So I would propose that we recommend that UDP timeouts remain the same . I could be convinced that NATs could reduce the timeout even further if they 're reasonably sure the flow is QUIC . What do people think ? 
 There is also text about NAT time - outs in section 4.8 ( see also issue ) , recommending a longer timeout than UDP . If this recommendation is not right , please comment there . I was pinging you ( because you wrote the sentence cited here and wanted to see if we can actually better align it with section 4.8 . 
 Shorter NAT timeouts hurt applications where either side can initiate communication , since once the NAT times out , only one side can initiate communication . Hanging GETs are the typical example in HTTP , but I expect this could be a much larger issue in non - HTTP use cases . The only solution is to send packets(ie : PINGs ) to keep the NAT active . I think 2 minutes is reasonable . Expecting anything longer without some explicit endpoint - to - path signaling seems overly optimistic to me , but I could be wrong . 
 I agree the language is inconsistent and I am happy to write it up . I would just like clear consensus on what it should say . I 'm registering 's comment as " keep the UDP timeout as it is " 
 If you look at section 4.1 . , the problem is that RFC4787 says MUST NOT be less than 2 minutes but in reality it 's usually only 30 or 15 seconds . So I think  says 2 ( or more ) minutes are fine but only 30 sec as often used for UDP is not . Therefore I think it 's important to make the point that will with QUIC is even more reasonable to use 2 minutes or more because it 's connection - oriented and you can be sure that when you see the handshake from both ends that those ends are actually trying to have a valid communication . Please note that I also have created PR to align the language correctly to RFC4787 in section 4.1 .. So if you want to change something in section 4.1 . please use as starting point . 
 I agree with point that for QUIC it 's even more reasonable to actually use at least 2 minutes because it 's connection - oriented . I do n't have any evidence the timeout is commonly under 30 seconds , but it is commonly less than 2 minutes . We have seen extremely short timeouts , and it 's believed these are NATs that are running close to saturation so the idle timeout shrinks very low . But it 's hard to know for sure . 
 OK so the message here is , " yes QUIC is ' robust ' to NAT rebinding but still do n't reduce the timeout . " This might be sound advice , but it seems like a bit of waste given our effort surrounding NAT rebinding . I have to think about this some more , but I suppose whatever value we recommend here turns into an effective bound on the QUIC idle timeout in real deployments . I 'll just wait till lands to make changes . 
 It would seem OK to motivate suggesting an increase in the NAT timeout , but saying this is " because it 's connection - oriented " ... is n't really enough . Other UDP protocols can also be connection oriented and they might also have observable closing packets - to release the NAT state under normal usage . I think the rationale just needs a little explanation , perhaps in terms of the benefits to QUIC of a larger NAT timeout . 
 I am happy to take this issue but am glad that put this on the agenda to discuss . I guess I 'll wait till after 110 to write a PR ? 
 no , if you can propose some concrete text that would be helpful for the meeting . It 's only that we wo n't merge before the meeting . 
 I am not sure about 's concerns about one endpoint being blocked from restarting the connection . Having throught it through more , I 'll make these assertions : is a tension between the most endpoint - friendly choice ( infinite timeouts ! ) and what implementers are actually willing to do . A ridiculous requirement is likely to be ignored , so being as generous as possible , given QUIC 's salutary features , would be wise . how hard we 've made it for intermediaries , it would be good internet citizenship to give them something that makes their lives easier if it does n't compromise performance or privacy . really do need to make sure that ( UDP timeout 3 PTO ) for all plausible PTO values , as this is the minimum idle timeout . problem is arguably solved by judicious use of the idle timeout . If we set a reasonably low recommended idle - timeout for clients and servers ( which can be different ! ) , and put the recommended UDP timeout above that value , a few things happen : ( a ) the server can discard state relatively quickly ( b ) if the server ca n't handle NAT rebinding , it can set an aggressive idle - timeout ( c ) in general , it 's the client that will try to keep connections alive ( d ) the client will be aware of the minimum of the two timeouts -- if they want the connection to survive , they will send PINGs when necessary according to 10.1 of quic - transport . ( e ) IIUC , both client - side and server - side NAT / Firewalls will accept " new " connections if initiated by the client . So I 'm recommending the following : " intermediary UDP timeout " should be the smallest possible value that is always  . Someone tell me what the number is ! 10 seconds ? should set an idle - timeout value that is a bit less than the recommended intermediary UDP timeout unless they are sure they are n't behind a NAT . should set an idle - timeout according to the following principles : ( a ) if known to not be robust to rebinding ( i.e load balanced without QUIC - LB ) , just below the intermediary UDP timeout . This is true whether the server knows if it is behind a NAT or not ( b ) otherwise , use any value you want Thoughts ? If people agree with this logic , I 'll revise the PR or write another one . 
 I disagree with your suggestion of recommending a NAT timeout smaller than 2 minutes . I 'd prefer something along the lines of previous suggestion of really try to use 2 minutes and we can add text about how clients will have to use PINGs if the timeout is too short , if that 's helpful . 5 minute long hanging GETs are a common thing today , and WebTransport may make the case where either side initiates communication more common . Longer timeouts are n't hard , they just require state . Special cases for QUIC are more difficult . This is not always good for either application performance or CPU(ie : more handshakes ) . Agreed , but that 's not my concern as much as the server 's inability to contact the client . The client does n't know what the NAT timeout is , which seems like the important thing here . I 'm not sure what you mean by server - side NAT / Firewalls ? There 's no  to PTO , so  is technically an infinite value . But if you 're assuming typical RTTs on the existing internet with a  in the seconds , it 's ~9 RTT . 2 g has an RTT in the 2 second range , so if we assume RTTs above 4 seconds are uncommon , then you 'd be recommending 36 seconds . 
 Sure , my language was imprecise . The model here is that we propose a standard NAT timeout that they can live with it , and clients can set idle - timeouts based on the assumption that NATs are following it . I 'm referring to things devices in the server infrastructure that rewrite the source address and port on inbound packets to make sure all outbound packets are routed correctly . I understand . Although I 'm not going to insist on this , a standard on the order of 30 - 45 seconds would meet the objective quite well . 
 Sect 4.1 : This contains a statement on the recommendations for middleboxes and NATs , that I ca n’t understand , and this concerns me . i.e. to me , the present text suggests that the advice in BCP 127 ( aka RFC4787 ) should be changed for QUIC . I do n’t recall this being discussed - was it ? I do n’t actually follow the rationale that says this follows from QUIC being connection - oriented . If the connection close was visible to the device , and it could release state - then this might make sense , but that is n’t exactly what is explained . I ’m left unsure how a “ QUIC - aware ” middlebox is supposed to track this state . I 'm also unsure how say a NAPT could know the traffic was QUIC , is this suggesting a port - based change . I think I need to understand this proposal . 
 Actually we do n't change the recommendation of  as it says " A NAT UDP mapping timer MUST NOT expire in less than two minutes " However , we cite this wrongly , which is now addressed in PR . The reason for recommending longer time - outs for QUIC is because you can be sure that there is handshake and the other end did confirm its willingness to communicate . Of course having a stopping indication would be better but we do n't have it . We do n't recommend a specific value , nor do we say one should use equally long timers as for TCP . However , given you know there is valid communication on - going between the two peers a longer timer ( of at least a couple if minutes ) would probably be useful in a lot of cases . Do we need more text here ? do you want to propose something ? Or should I ? Otherwise we can also discuss this at the next meeting !
Paragraph (version A):
RFC4787 recommends a 2 minute timeout interval for UDP.  However,
timers can be lower, in the range of 15 to 30 seconds.  In contrast,
RFC5382 recommends a timeout of more than 2 hours for TCP, given that
TCP is a connection-oriented protocol with well-defined closure
semantics.  For network devices that are QUIC-aware, it is
recommended to also use longer timeouts for QUIC traffic, as QUIC is
connection-oriented.  As such, a handshake packet from the server
indicates the willingness of the server to communicate with the
client.
Paragraph (version B):
RFC4787 requires a timout that is not less than 2 minutes for most
UDP traffic.  However, in pratice, timers are often lower, in the
range of 15 to 30 seconds.  In contrast, RFC5382 recommends a timeout
of more than 2 hours for TCP, given that TCP is a connection-oriented
protocol with well-defined closure semantics.  For network devices
that are QUIC-aware, it is recommended to also use longer timeouts
for QUIC traffic, as QUIC is connection-oriented.  As such, a
handshake packet from the server indicates the willingness of the
server to communicate with the client.