DPLPMTUD events

[marten-seemann]

While DPLPMTUD is optional, there's an entire section about it in QUIC transport.

Minimal support for this in qlog would define an event mtu_increased for every increase of the MTU:

{
     new_mtu: uint16
}

I don't think we need a separate event for the sending of an MTU probe packet, but we should probably standardize a trigger for this. Suggestion: mtu_probe.

Open question: Do we want a separate failure event? Failure would be either the loss of an MTU probe packet, or (for implementations that pay attention to ICMP packets) the receipt of an ICMP Packet Too Big (PTB) message.

[rmarx]

I agree it would be useful to have this information in qlog.

In terms of design, as always there are several options:

1. have separate events for this (mtu_updated, mtu_probe_sent, mtu_probe_lost, etc.)
2. integrate them into existing events( triggers on packet_sent and packet_lost, new mtu field in metrics_updated)
3. a combination of these approaches (which is what you suggest IIUC)

This is imo a good example of where we need clear design guidelines on how to add new information/events to qlog.

[marten-seemann]

Revisiting this after a long time:

• mtu_probe_sent is problematic, as this would essentially be a copy of the normal packet_sent event (it is allowed, although not recommended, to just send normal application data as a probe packet). The trigger seems to be the best solution here
• mtu_updated needs to be a separate event, there's just no way we can reasonably collapse this into an acknowledgment event
• mtu_probe_lost is what I'm still undecided about. This logically belongs to the regular packet_lost event, we'd just need a way to attach "oh and by the way, this was a MTU probe packet". In fact, it would be really useful to have it on that event, since the congestion control implications are very different for lost MTU packets (i.e., you wouldn't decrease your cwnd).

[marten-seemann]

The trigger seems to be the best solution here

I have to disagree with myself here. The sending of the packet might have been triggered by something else, it's just that the stack decided to send a probe packet.

I suggest:

1. Add a isMTUProbePacket optional bool on the packet_sent and packet_lost events.
2. Add a mtu_updated event.

[LPardue]

Supporting DPLPMTUTD events seems important to cover in the base specs.