Hi,
> > > > 1) Normal NAT rebinding. The connection is idle for a long period. A > > > > good server will have reset its congestion controller due to the long > > > > idle period. > > > > > > > > The client then sends a packet (if the server does first, it'll probably > > > > disappear). Whether or not that packet is small, the server is going to > > > > be limited by the amplification limit rather than congestion control. > > > > One alternative is to kill the connection after an idle period and > > > > restart with 0RTT, but that's only superior because the client has to > > > > send a bunch of bytes. The recommendation here, I think, is that clients > > > > SHOULD send one or more full-size datagrams when restarting after a long > > > > idle period, and possibly reset its PMTU assumptions. [I can't remember > > > > what DPDLPMTUD says about idle periods] I would think reseting the PMTU discovery for a NAT rebiding case would be a bit overreaction. A NAT rebinding case would change the external port of the NAT side, which is why the server see it as a new path. However, in most cases the actual path will be identical between NAT and server, and the client to NAT path should be unchanged. ECMP routing could possibly result in a different path through some AS. However, if you deploy ECMP routing you actually have to work with that E and ensure there are some equalness. And the DPLPMTUD should take care of that if it doesn't work. What maybe one need to be a bit more careful here is not to call it "full-size" datagram, but rather focus on that we need to ensure what DPLPMTUD will work is to probe the minimal Maximum Packet Size for QUIC to work. Which is what Section 14.3 makes clear when DPLPMTUD is used. For DPLPMTUD it might make sense to trigger a search after path validation of the BASE_PLPMTU. The point is that it is critical to verify the 1200 byte limit, then one like to verify that previous known MTU (MPS) still works, then one can search for any change in the MTU. And in NAT rebinding cases, both the BASE_PLPMTU and the MPS is most likely still the same. Thus throwing away the previous knowledge of them is unnecessary, instead verification of them in sequence makes more sense as it avoid searching from BASE to previous working MPS. Cheers Magnus
smime.p7s
Description: S/MIME cryptographic signature
