Re: Back to work

[Magnus Westerlund <[e-mail]>]

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