Marten Seemann

There's currently some convoluted logic to calculate the keep alive interval, that we'd need to change if we remove this logic: https://github.com/quic-go/quic-go/blob/2dca400b5c16e956710c87120577497c1381dab9/connection.go#L1781 Not sure what to do about this. Maybe...

Sounds reasonable, but we need to be very careful to expose something that's actually useful. The bandwidth estimate is very dependent on the congestion controller in use. For example, with...

You might want to ask that question in some iOS developer forum.

@xf-yang This is wrong. The UDP has absolutely nothing to do with the OS UDP receive buffer.

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

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

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...

It's not clear how this interacts with 0-RTT. The safest option would be to just send the 0-RTT data on the first connection, and treat subsequent connections as "0-RTT rejected"....

That doesn't work. `protocol.MaxPacketBufferSize` defines the maximum buffer size, so if you want to allow for larger packets on IPv4, you'd have to increase the value of the constant.

> So rather than using the constant directly they could issue a call to a new function, `protocol.FamilyMaxPacketBufferSize(family AddressFamily)` or similar. At which place would that be necessary?