Q: Why not send PMTUD probe in coalesced packet?

[mxinden]

Currently we don't send a PMTUD probe in a coalesced packet:

https://github.com/mozilla/neqo/blob/ea6cde436bcf67e71deba0809978312fbf3ee734/neqo-transport/src/connection/mod.rs#L2456-L2463

Why is that?

Do we, for the sake of stability, not send probes in initial and handshake space, and thus not when coalescing spaces?

@larseggert do you recall?

If the above is true, I don't think we implement it correctly.

1. We set the PacketBuilder limit early on in output_dgram_on_path. The limit is based on whether we want to send a probe or not. Note that it does not depend on whether the packet is coalesced.

   https://github.com/mozilla/neqo/blob/ea6cde436bcf67e71deba0809978312fbf3ee734/neqo-transport/src/connection/mod.rs#L2644-L2662

2. Later on, iff it is !coalesced, we add a ping frame and mark it as a probing frame:

   https://github.com/mozilla/neqo/blob/ea6cde436bcf67e71deba0809978312fbf3ee734/neqo-transport/src/connection/mod.rs#L2455-L2464

3. As a final step, we add the actual padding based on the limit in (1), but not under the condition of !coalesced.

   https://github.com/mozilla/neqo/blob/ea6cde436bcf67e71deba0809978312fbf3ee734/neqo-transport/src/connection/mod.rs#L2496

In other words we can have a PMTUD probe limit (1), no ping and not marked as a probe (2), but still get full probe padding (3).

Given that we didn't mark the probe (2), we might attempt to send another probe right after.

[larseggert]

I don't recall why I did it this way; I think the intent might have been to wait with PMTUD until after the handshake, in order to not complicate that mechanism further.