Hi Marten, Thanks for sharing your observation.
Since peer A doesn’t get an ACK for the PMTUD probe packet, it should send a loss probe packet to trigger an ACK. I assume, in your case, there are no data available to transmit or retransmit. Thus, the loss probe contains only a PING frame, which should be small enough to reach peer B. Does this makes sense? If so, there is only a limited time where peer A and peer B have a large disagreement about the end of the idle period. This is the time between peer A sending the PMTUD probe packet and peer B receiving the loss probe packet. Timo > On 13. May 2022, at 12:01, Marten Seemann <[email protected]> wrote: > > I ran into an unexpected interaction between DLPMTUD and QUIC's idle timeout > in my implementation. I've implemented the "Probing using padding data" > described in the DLPMTUD draft: I send a single PING frame and then use > PADDING frames to achieve the desired probe packet size. > > Assume that you're sending MTU probe packets on a timer, and that timer fires > a long timer after the connection became idle (but before the idle timeout). > Peer A will therefore send a probe packet to its peer, B. Since the probe > packet is ack-eliciting, this resets the idle timeout timer for A. It now > happens that the probe packet is too large for the path, and the packet is > dropped. Therefore, B's idle timeout is not reset, and A and B will have a > large disagreement about the start and end of the idle period. > > This root cause of this disagreement is that MTU probe packets are treated > differently than other ack-eliciting packets from a loss recovery standpoint: > they are not retransmitted, but their loss is interpreted as a signal that > the path doesn't support that particular MTU. > > Note that A not resetting the idle timer when sending a probe packet doesn't > solve the problem. There's another case where this fails: Assume this time > the probe packet is received by B, but the ACK for that packet is lost. Now B > will have reset its probe timer when it received the probe packet, but A will > not, leading again to a large disagreement about the start and end of the > idle period, this time in the other direction. > > I can see multiple solutions to this: > • Don't send MTU packets on a timer. Only send them when application > data is sent. This avoids sending packets during periods of quiescence (might > be good to not wake up the network interface), but it also means that we're > not using those periods of quiescence, where plenty of congestion window is > available. > • Retransmit the PING frame from the probe packet in a normal size > packet, until it is acknowledged. This is sad, since it will cause an > additional packet to be sent every time a probe packet is lost. > Any thoughts on how to best deal with this? > > Cheers, > Marten > > >
smime.p7s
Description: S/MIME cryptographic signature
