Draft: draft-ietf-quic-manageability

Commentary: This PR replaces ( while retaining the semantics of all of its changes ) ; no longer merges due to major changes to the NAT and Connection ID text . 
 as well 
 Should RFC7857 also be cited ? ( NAT update BCP ) Should RFC4787 also be cited ? ( behaviour for UDP NAT ) 
 Not sure . We cite RFC4787 in the manageability doc . In this doc we refer to RFC8085 instead which then refers to RFC4787 . I 'd say that 's about right . However , I 'm open to add more information if people think that 's helpful . If so , what more do we need to say where ? 
 In 3.5 the ID currently states : " According to a 2010 study ( [ Hatonen10 ] ) , UDP applications can assume that any NAT binding or other state entry can expire after just thirty seconds of inactivity . " Whereas in RFC 4787 ( BCP ) Requirement 6 states : " REQ-5 : A NAT UDP mapping timer MUST NOT expire in less than two minutes , unless REQ-5a applies . a ) For specific destination ports in the well - known port range ( ports 0 - 1023 ) , a NAT MAY have shorter UDP mapping timers that are specific to the IANA - registered application running over that specific destination port . b ) The value of the NAT UDP mapping timer MAY be configurable . c ) A default value of five minutes or more for the NAT UDP mapping timer is RECOMMENDED . " I suggest we directly refer to this RFC before or after the above sentence , before the ID then continues in the next sentence to discuss the topic of keep alive ( aka RFC8085 ) . 
 There was always a reference to RFC4787 . Text is { { ? RFC4787 } } requires a timeout 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 . What else should be ? 
 I suggested changing the latter from " 15 to 30 seconds " to " 30 seconds to 1 minute , " or something like  's quote : " According to a 2010 study ( [ Hatonen10 ] ) , UDP applications can assume that any NAT binding or other state entry can expire after just thirty seconds of inactivity . " 
 When I review " experience " reported in OPS drafts , I usually try to avoid wording that might convey the IETF endorses the reported behaviour , rather than be aware of the reported behaviour . I suggest this is one of these cases . So suggest a style something like : { { ? RFC4787 } } requires a timeout that is not less than 2 minutes for most UDP traffic . However , protocols traversing NATs should be aware of systems using lower values , in the range of 15 to 30 seconds . A study in 2010 study ( [ Hatonen10 ] ) , reported that UDP applications can experience that NAT binding or other state entries expire after just thirty seconds of inactivity . 
 There is new proposed text on this part in PR - Can review and comment any proposed changes there ... ? 
 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 ! 
 Some suggestions , but overall quite good .
Paragraph (version B):
Even though QUIC has explicitly been designed tolerate NAT
rebindings, decreasing the NAT timeout is not recommended, as it may
negatively impact application performance or incentivize endpoints to
send very frequent keep-alive packets.  Instead it is recommended,
even when lower timers are used for other UDP traffic, to use a timer
of at least two minutes for QUIC traffic.
Paragraph (version B):
While QUIC has no clear network-visible end-of-connection signal and
therefore does require timer-based state removal, the QUIC handshake
indicates confirmation by both ends of a valid bidirectional
transmission.  If state is removed too early, this could lead to
black-holing of incoming packets after a short idle period.  To
detect this situation, a timer at the client needs to expire before a
re-establishment can happen (if at all), which would lead to
unnecessary long delays in an otherwise working connection.
Paragraph (version B):
Furthermore, not all endpoints use routing architectures where
connections will survive a port or address change.  So even when the
client revives the connection, a NAT rebinding can cause a routing
mismatch where a packet is not even delivered to the server that
might support address migration.  For these reasons, the limits in
RFC4787 are important to avoid black-holing of packets (and hence
avoid interrupting the flow of data to the client), especially where
devices are able to distinguish QUIC traffic from other UDP payloads.