Change:
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 added?
I suggested changing the latter from "15 to 30 seconds" to "30 seconds to 1 minute," or something like Gorry'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...? NAME NAME
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. NAME 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 don't want to mess with existing UDP flows. Maybe my "don'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 isn'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 (NAME 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.
NAME 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 NAME '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 Ian 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 NAME point that for QUIC it's even more reasonable to actually use at least 2 minutes because it's connection-oriented. I don'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 don'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" ... isn'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 NAME 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 won't merge before the meeting.
I am not sure about NAME 's concerns about one endpoint being blocked from restarting the connection. Having throught it through more, I'll make these assertions: There 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. Given 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 doesn't compromise performance or privacy. We really do need to make sure that (UDP timeout > 3 PTO) for all plausible PTO values, as this is the minimum idle timeout. NAME 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 can'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: The "intermediary UDP timeout" should be the smallest possible value that is always > 3PTO. Someone tell me what the number is! 10 seconds? Clients should set an idle-timeout value that is a bit less than the recommended intermediary UDP timeout unless they are sure they aren't behind a NAT. Servers 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 NAME 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 aren'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 doesn'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 max to PTO, so 3PTO is technically an infinite value. But if you're assuming typical RTTs on the existing internet with a max in the seconds, it's ~9 RTT. 2g 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 can’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 don’t recall this being discussed - was it? I don’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 isn’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 don't change the recommendation of RFC4748 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 don't have it. We don'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? NAME 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.

Discussion:
depending on application requirements. RFC4787 requires a timeout that is not less than 2 minutes for most <del> 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. </del> <ins> UDP traffic.  However, in practice, timers are sometimes lower, in the range of 30 to 60 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. 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. 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. 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. </ins> The QUIC header optionally contains a connection ID which can be used as additional entropy beyond the 5-tuple, if needed.  The QUIC