Re: Back to work

[Gorry Fairhurst <[e-mail]>]

See below.

> On 3 Nov 2020, at 16:41, Magnus Westerlund <magnus.westerlund=[e-mail]> wrote:
> 
> 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

This seems correct, the new path is likely the same in this case, and to me also there does not seem a large penalty for assuming a previously valid PLPMTU. In this respect The PLPMTU can be handled in a different way to CC, because for CC, it seems more likely that the path capacity might have changed over time.

A conservative approach would of course avoid black holes completely by resetting the MPS. I agree it would then be appropriate in that case to still retain the Size of the last PLPMTU as the initial target size to search for using DPLPMTUD (the spec does not prevent that).

Gorry