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

Matt Corallo <> Thu, 09 January 2020 17:41 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id F04721200B5 for <>; Thu, 9 Jan 2020 09:41:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -8
X-Spam-Status: No, score=-8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id H7mO5xDQJ_bY for <>; Thu, 9 Jan 2020 09:41:29 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 40592120019 for <>; Thu, 9 Jan 2020 09:41:29 -0800 (PST)
Date: Thu, 09 Jan 2020 09:41:28 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1578591688; bh=KN3NHSrkTyKxt2NP5vCLV06LOGk0gr9q6oOb154VvTM=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=rbTlGFscunn7zdjrkTnrNdjrNEz7li/P7TRZAzWO+VlrS5XXCHTqFp9/19Q5ln24k AtShWGsxynPcaodbv/3myJZLiCvi1iog6CQ2DicBeaqBK6CNfc2gxHOalhqGPCpZrm zPM6w9cQfeMIgWPai5xizh8pI5ZN2JGjgZeDmBUI=
From: Matt Corallo <>
Reply-To: quicwg/base-drafts <>
To: quicwg/base-drafts <>
Cc: Subscribed <>
Message-ID: <quicwg/base-drafts/issues/3330/>
In-Reply-To: <quicwg/base-drafts/issues/>
References: <quicwg/base-drafts/issues/>
Subject: Re: [quicwg/base-drafts] MSS Clamping Support (#3330)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5e1765c83adbc_2a2a3fa7454cd96c1668da"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: TheBlueMatt
X-GitHub-Recipient: quic-issues
X-GitHub-Reason: subscribed
X-Auto-Response-Suppress: All
Archived-At: <>
X-Mailman-Version: 2.1.29
List-Id: Notification list for GitHub issues related to the QUIC WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 09 Jan 2020 17:41:31 -0000

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