Re: [quicwg/base-drafts] MSS Clamping Support (#3330)

[Matt Corallo <[e-mail]>]

I’m not sure if it’s discussed in the PLPMTUD RFC, but one relatively simple thing that would improve the state of QUIC is to instruct endpoints they SHOULD NOT use any data-carrying frames for PMTUD and SHOULD NOT send any data-carrying frames which total over 1280 until they have completed PMTUD. This would force endpoints to use 1280-MTU frames until they’ve used some ping/noncritical/non-latency-critical frames to do PMTUD, avoiding the usual issues with timeout-based PMTUD by sending “dummy” traffic that doesn’t block real flows.

(Again I’m basing this on a relatively high-level understanding of QUIC and having read the MSS section, let me know if this of way off base).

> On Jan 9, 2020, at 10:46, ianswett <[e-mail]> wrote:
> 
> 
> If a smaller MTU is faster, but it's larger than the 1200 byte UDP payload minimum, you could clamp to the performance optimal size for QUIC flows and let them figure it out with PLPMTUD if they implement it.
> 
> Ideally, clients can remember what the MTU was from last time they connected to a given hostname, and use that to speed future PMTU. Similarly, clients could try to determine the max MTU that ever works for any non-local connection and use that as an upper bound. But both of those are optimizations.
> 
> I agree with @martinthomson that I can't think of any change that would help the situation that's in scope for QUIC v1.
> 
> —
> You are receiving this because you authored the thread.
> Reply to this email directly, view it on GitHub, or unsubscribe.


-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/3330#issuecomment-572672307