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

Matt Corallo <notifications@github.com> Thu, 09 January 2020 04:57 UTC

Return-Path: <noreply@github.com>
X-Original-To: quic-issues@ietfa.amsl.com
Delivered-To: quic-issues@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE2E112024E for <quic-issues@ietfa.amsl.com>; Wed, 8 Jan 2020 20:57:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.596
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DtQZf1sOsmSW for <quic-issues@ietfa.amsl.com>; Wed, 8 Jan 2020 20:57:16 -0800 (PST)
Received: from out-4.smtp.github.com (out-4.smtp.github.com [192.30.252.195]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE103120169 for <quic-issues@ietf.org>; Wed, 8 Jan 2020 20:57:15 -0800 (PST)
Received: from github-lowworker-45eca55.ac4-iad.github.net (github-lowworker-45eca55.ac4-iad.github.net [10.52.25.70]) by smtp.github.com (Postfix) with ESMTP id 37400C60B24 for <quic-issues@ietf.org>; Wed, 8 Jan 2020 20:57:15 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1578545835; bh=6LGcp712YxKgR6ynLiNm1YtDn8+8A8uBCbwgU7SrY4Q=; h=Date:From:Reply-To:To:Cc:Subject:List-ID:List-Archive:List-Post: List-Unsubscribe:From; b=rfUqrxRjIWulMQjEG33iWsG7lA9aJDZQUe3ojpvxrCgZw/Qubjy73/JRYhNl1dW3x l0t4nqo1SIz6ejD2Pss8DQtxyS6xUNHk1mwT7M3d7+U8tLjsu9Pcz3QA0PsoEbs6Bx aCVZeJJZkwoD4n9VQ28GW8zhmfkloLJIdHRc9QRI=
Date: Wed, 08 Jan 2020 20:57:15 -0800
From: Matt Corallo <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK4LQJMDNDCNGIPSLTF4EPSSXEVBNHHCBHS6CE@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/3330@github.com>
Subject: [quicwg/base-drafts] MSS Clamping Support (#3330)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5e16b2ab28a39_46983fd1e10cd968853d5"; 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
X-GitHub-Recipient-Address: quic-issues@ietf.org
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/9MmX7GKcpjqWiGvYVvywvtDf1JU>
X-BeenThere: quic-issues@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Notification list for GitHub issues related to the QUIC WG <quic-issues.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic-issues>, <mailto:quic-issues-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic-issues/>
List-Post: <mailto:quic-issues@ietf.org>
List-Help: <mailto:quic-issues-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic-issues>, <mailto:quic-issues-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 09 Jan 2020 04:57:18 -0000

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