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

Martin Thomson <notifications@github.com> Thu, 09 January 2020 06:30 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 78C83120118 for <quic-issues@ietfa.amsl.com>; Wed, 8 Jan 2020 22:30:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.999
X-Spam-Level:
X-Spam-Status: No, score=-7.999 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_32=0.001, 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 E-foRxSzLVDF for <quic-issues@ietfa.amsl.com>; Wed, 8 Jan 2020 22:30:07 -0800 (PST)
Received: from out-20.smtp.github.com (out-20.smtp.github.com [192.30.252.203]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E448120020 for <quic-issues@ietf.org>; Wed, 8 Jan 2020 22:30:07 -0800 (PST)
Date: Wed, 08 Jan 2020 22:30:06 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1578551406; bh=TvbiB2q3IcquSkeEQMGcLrMztAI7QqpaZ+A6Cmi1Wnc=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=SgTkPU5W1zCpQNOa6QbQhfWGGwWLwAYFr9WrHpiwruT83SyC8NWiDe8Dwo8Zu4zUK YgISdVn55kaTk4QmRkqBO+dYomHvlremXxmYGDmGHzWqH8hZH5iHwXIkuiAUiw3d1X xDIj1ipuAnD2Yf4sG4lo39xTjWAtIlvZ8EgxEj3Q=
From: Martin Thomson <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJKYKE4J4YIWD7XF6KG54EP5O5EVBNHHCBHS6CE@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/572411529@github.com>
In-Reply-To: <quicwg/base-drafts/issues/3330@github.com>
References: <quicwg/base-drafts/issues/3330@github.com>
Subject: Re: [quicwg/base-drafts] MSS Clamping Support (#3330)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5e16c86e54a62_d113fe06decd9602236a8"; charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: martinthomson
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/l4IIU_SdNEIKjfuFs7KbP_-0Krc>
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 06:30:09 -0000

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