Allow applications to specify MaxPacketBufferSize

[chungthuang]

Some applications might want to use a MaxPacketBufferSize that is less than 1452 bytes. For example, some networks might have middle boxes that adds extra encapsulation before reaching the server. To support this, maybe we can add a new option to Config. Then we can pass it to TransportParameters to advertise the value to the peer.

@marten-seemann I'm happy to open a PR, but I have some questions about other places using MaxPacketBufferSize. I see it is also used in buffer_pool and stream frames. What is the implication if the advertised maxUDPPayloadSize is different from size of the buffer pool and stream frames?

[marten-seemann]

This is already possible. You can disable DPLPMTUD and set the initial packet size.

[chungthuang]

Can you point me to how to set the initial packet size when DPLPMTUD is disabled? The doc says If unavailable or disabled, packets will be at most 1280 bytes in size.

[marten-seemann]

Looks like we didn't properly update the document the documentation when we introduced Config.InitialPacketSize...

[joliveirinha]

@marten-seemann to be clear, we don't want to disable PMTU Discovery.

To be clear, what we really want is for the server to advertise a maximum packet size that it is willing to receive. Today, this value is hardcoded as a constant of MaxPacketBufferSize.

The reason why we want to do this, is because we don't want clients to exceed that value when doing PMTU discovery because it is possible that during the QUIC connection lifetime, that the PMTU decreases due to packet re-routing associated to how our anycast network works.

Since PMTU doesn't support today the capability of decreasing in such event of MTU changing over time, then we need to guarantee that the server advertises the maximum value that it can receive packets in the event that a change happens.

So, that it is the reason why we would like to make this configurable for the receiving side.
For the sending side (from server perspective) we also want the server to continue due PTMU discovery for the client.

[marten-seemann]

Got it, so #4558 doesn't fix your issue (#3955).

While I understand that maxing max_udp_payload_size configurable would allow you to better work around that issue, I'm don't we should introduce additional API surface to do that. I'd much rather get #3955 fixed once and for all, and have PMTUD work out of the box, without any need for intervention via quic.Config options.

[chungthuang]

In our case we actually need the packet size to be slightly lower than the MTU of the network, because we need additional encapsulation to reroute packets. So I don't think PMTUD can account for the additional encapsulation.

[joliveirinha]

@marten-seemann I agree with you that #3955 would fix the issue.

However, we are in a tight schedule here and I am not sure when that one would be fixed.
That said, do you think it would be possible for us to meet somewhere in the middle?

For instance, would you be ok with reading the value that we want to advertise from an ENV variable? (os.GetEnv()), and use that to advertise here: https://github.com/quic-go/quic-go/blob/master/connection.go#L301
Of course we would need to do a max(os.GetEnv(), protocol.MaxPacketBufferSize)

This way, it wouldn't be on the public API but it would allow us to configure it, until #3955 is addressed.
What do you think?

[chungthuang]

Hi @marten-seemann, I've opened a PR to add max UDP payload size in the config. Can you review it and see if that's a reasonable workaround until #3955 is addressed?