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

From: Matt Corallo <[email-masked]>
Date: Wed, 08 Jan 2020 20:57:15 -0800

Forgive me if I didn't manage to dig up some relevant spec portion, I'm new around here :).

>From what I can find, it looks like there is no way to do any kind of simple MSS clamping as a middlebox in quic. PMTU is great in theory, but, sadly, rarely works in practice (at least if you have to support lots of potential endpoints) - ICMP failure indication is just unreliable (yay poor "security" advice), and while probing with timeouts is great, there is a significant delay associated with doing so, wasting header overhead or time waiting for MTU discovery. Even worse, sometimes links (eg modern VPNs) can have a high MTU (eg 1500) but actually *using* that MTU has worse performance than not as it creates fragmented encrypted frames. Thus, in today's internet, most routers (including iptables, Cisco iOS and JunOS) have first-class support for clamping the MSS to some lower value, which doesn't have any of the associated pitfalls. Is there any way to allow an on-path device to provide MSS information or does this fall into the "middleboxes must not edit anything about the packet flow, only ECN is allowed to provide informtion to endpoints" category?

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

---

From: Martin Thomson <[email-masked]>
Date: Wed, 08 Jan 2020 22:30:06 -0800

The [section on PMTUD](https://quicwg.org/base-drafts/draft-ietf-quic-transport.html#name-icmp-packet-too-big-message) addresses this point.  In addition to PLPMTUD, we also describe how to use ICMP.

The answer we have does allow the path to send signals, but it doesn't allow for packet modification in any way.  In short, if the ICMP message gets through AND it contains enough information that the endpoint can be assured that the sender was on-path, then it can be used.

That's probably not an especially satisfactory answer, but I believe that is the state of the protocol and at this stage it would require significant effort to change - in the core protocol.

If there is a high path MTU but smaller packets would exhibit better performance, we currently have no answer.  That doesn't mean it is impossible to design a solution, but that would have to go through the endpoints and we don't currently have a way to do that.  One would need to be defined.  I suspect that the chances of getting that in for QUIC version 1 approaches zero, but this is work that can proceed independently.

Defining a generic IP-layer capability that protocols like QUIC could benefit from would be my suggested approach.  After all, I'm sure that the WebRTC folks would be thrilled to learn how to reduce latency or throughput for video on links that have these characteristics.

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

---

From: Matt Corallo <[email-masked]>
Date: Wed, 08 Jan 2020 22:34:48 -0800

Right, the question is in large part motivated by the common wisdom that “PMTUD just doesn’t work well enough to be relied on “, which appears to match my own experience - too many poorly-designed middleboxes drop ICMP (cause, you know, security, or something). I suppose this means in practice things will just run at 1280 with timeout-based PMTUD for long-running flows/common endpoints?

> On Jan 9, 2020, at 01:29, Martin Thomson <[email-masked]> wrote:
> 
> 
> The section on PMTUD addresses this point. In addition to PLPMTUD, we also describe how to use ICMP.
> 
> —
> 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-572412878

---

From: ianswett <[email-masked]>
Date: Thu, 09 Jan 2020 07:46:30 -0800

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 are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/3330#issuecomment-572620038

---

From: Matt Corallo <[email-masked]>
Date: Thu, 09 Jan 2020 09:41:28 -0800

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 <[email-masked]> wrote:
> 
> 

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

---

From: ianswett <[email-masked]>
Date: Thu, 09 Jan 2020 09:46:10 -0800

Take a look at https://www.ietf.org/id/draft-ietf-tsvwg-datagram-plpmtud-12.html#name-plpmtu-probe-packets

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

---

From: Matt Corallo <[email-masked]>
Date: Thu, 09 Jan 2020 10:35:36 -0800

Right, I suppose I was suggesting something a little stricter in the QUIC context - because a major goal of QUIC is to improve the latency seen by an eyeball it is a bit more than a MAY to use non-eyeball-critical frames for PMTUD. In any case, glad its at least called out...probably makes sense for future protocols to have an on-path-editable MSS field.

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

---

From: Igor Lubashev <[email-masked]>
Date: Mon, 13 Jan 2020 07:31:42 -0800

@TheBlueMatt The selection of which frames to use for MPTUD probes could be left to the implementations. I doubt that implementations that go into trouble of implementing PLPMTUD would be naive enough to not think carefully of this issue.

In fact, I think data frames could be better for MPTUD probes than useless PING/PADDING in some cases.  Imagine having two streams at different priorities ready to transmit.  You can send high-priority stream's data using known-good packet sizes, while fill your PMTUD probes with low-priority stream's data.

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

---

From: "Philipp S. Tiesel" <[email-masked]>
Date: Tue, 14 Jan 2020 05:29:00 -0800

I guess the right approach for this is to postpone it and solve it later by defining QUICv3 over PLUS and make MSS management a feature of PLUS.

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

---

From: Martin Thomson <[email-masked]>
Date: Tue, 14 Jan 2020 15:39:12 -0800

Proposal: quicv2 (on the basis that this might happen elsewhere, as an extension, or in a new version).

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

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 20 Jan 2020 18:44:37 -0800

I don't think we need to go through the consensus process here; we can just triage it as out of scope.

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

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 20 Jan 2020 18:44:39 -0800

Closed #3330.

-- 
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#event-2964674122