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

ianswett <> Thu, 09 January 2020 15:46 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 874C61202A0 for <>; Thu, 9 Jan 2020 07:46:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.596
X-Spam-Status: No, score=-6.596 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_IMAGE_ONLY_28=1.404, 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 wAoVyt7z5cSl for <>; Thu, 9 Jan 2020 07:46:31 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C78AC120831 for <>; Thu, 9 Jan 2020 07:46:31 -0800 (PST)
Date: Thu, 09 Jan 2020 07:46:30 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1578584790; bh=n5OKbHNCcvCi656uYQnTpZx/WD6hvufQlo5rHd3i4Fo=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=fcg+mRp62EDzNXWYfG33R4VW31xYW7009n9WEV6q+biH7xv8MSPch1sn5gMmLOZ26 K9srAQniiFyY6HsQRcm67huTyykw08WybQOCAo8iIaSC+lCp6xfZBMKM/4jIZoge/3 te0Jrqz4GdxKx1YCi2CHNzf/ytl45P0DnuyfH46s=
From: ianswett <>
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_5e174ad6e32c3_1ae03ff90c6cd96036989"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: ianswett
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 15:46:36 -0000

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: