IETF Logo Mail Archive

Re: [tsvwg] Adoption call: draft-fairhurst-tsvwg-datagram-plpmtud-02 to end 10th January 2018

Michael Tuexen <Michael.Tuexen@lurchi.franken.de> Wed, 10 January 2018 18:57 UTC

Return-Path: <Michael.Tuexen@lurchi.franken.de>
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 313AB127023; Wed, 10 Jan 2018 10:57:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.61
X-Spam-Level:
X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
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 yX05TtvDGR7N; Wed, 10 Jan 2018 10:57:29 -0800 (PST)
Received: from drew.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18A6C1200B9; Wed, 10 Jan 2018 10:57:29 -0800 (PST)
Received: from [10.0.3.2] (unknown [212.201.121.94]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTPSA id 2533672106C12; Wed, 10 Jan 2018 19:57:25 +0100 (CET)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\))
Subject: Re: [tsvwg] Adoption call: draft-fairhurst-tsvwg-datagram-plpmtud-02 to end 10th January 2018
From: Michael Tuexen <Michael.Tuexen@lurchi.franken.de>
In-Reply-To: <4123465B-CFE2-410E-BE1D-E09DC189F280@huitema.net>
Date: Wed, 10 Jan 2018 19:57:22 +0100
Cc: Gorry Fairhurst <gorry@erg.abdn.ac.uk>, "Black, David" <David.Black@dell.com>, "Eggert, Lars" <lars@netapp.com>, "tsvwg@ietf.org" <tsvwg@ietf.org>, QUIC WG <quic@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <9493C5B9-A79E-4311-8C07-67E14564B1ED@lurchi.franken.de>
References: <CE03DB3D7B45C245BCA0D243277949362FE164EB@MX307CL04.corp.emc.com> <9837331A-76DF-4137-9612-CC653E869553@netapp.com> <5A563390.8050403@erg.abdn.ac.uk> <4123465B-CFE2-410E-BE1D-E09DC189F280@huitema.net>
To: Christian Huitema <huitema@huitema.net>
X-Mailer: Apple Mail (2.3445.5.20)
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/xit5lenNXkkdBR6oMdH2tAPocso>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <quic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic>, <mailto:quic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic/>
List-Post: <mailto:quic@ietf.org>
List-Help: <mailto:quic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic>, <mailto:quic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 10 Jan 2018 18:57:32 -0000

> On 10. Jan 2018, at 19:22, Christian Huitema <huitema@huitema.net> wrote:
> 
> 
>> On Jan 10, 2018, at 5:38 AM, Gorry Fairhurst <gorry@erg.abdn.ac.uk> wrote:
>> ...
>> 
>> I suspect someone could use the final method with QUIC - since it's also a UDP-based transport. I don' knopw of anyone planning PMTUD for QUIC - please get in touch if that is on your radar.
> 
> The initial packets in QUIC are sent with min IPv6 MTU. During the initial exchange, the nodes send the maximum packet size that they might accept. QUIC does not specify the actual probing algorithm but does specify that PMTU is per path.
> 
> Several QUIC implementations do PMTUD already, building simple probes with QUIC's Ping and Padding frames. Probes are then encrypted, and sent as QUIC packets in UDP with segmentation turned off. If the probe packet is acknowledged, the applications know that this much MTU can be sent.
Your description of the probe packets is the one we have in mind. It just needs to be specified.
The more interesting part of the document is the way (when and which size) you probe,
not how you probe.
> 
> Note the encrypted part. Replacing such mechanisms by a clear text exchange is not desirable.
And not intended...

Best regards
Michael
> 
> -- Christian Huitema

v2.23.0 | Report a Bug | By Email