IETF Logo Mail Archive

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

Christian Huitema <huitema@huitema.net> Sun, 21 January 2018 06:10 UTC

Return-Path: <huitema@huitema.net>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC83C127241 for <tsvwg@ietfa.amsl.com>; Sat, 20 Jan 2018 22:10:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable 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 wuwZTEjnOhCV for <tsvwg@ietfa.amsl.com>; Sat, 20 Jan 2018 22:10:49 -0800 (PST)
Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D5E5126DED for <tsvwg@ietf.org>; Sat, 20 Jan 2018 22:10:49 -0800 (PST)
Received: from xsmtp02.mail2web.com ([168.144.250.215]) by mx6.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from <huitema@huitema.net>) id 1ed8q7-0007KY-0J for tsvwg@ietf.org; Sun, 21 Jan 2018 07:10:47 +0100
Received: from [10.5.2.16] (helo=xmail06.myhosting.com) by xsmtp02.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from <huitema@huitema.net>) id 1ed8q0-0001Q8-VT for tsvwg@ietf.org; Sun, 21 Jan 2018 01:10:45 -0500
Received: (qmail 25705 invoked from network); 21 Jan 2018 06:10:37 -0000
Received: from unknown (HELO [192.168.200.68]) (Authenticated-user:_huitema@huitema.net@[72.235.171.77]) (envelope-sender <huitema@huitema.net>) by xmail06.myhosting.com (qmail-ldap-1.03) with ESMTPA for <quic@ietf.org>; 21 Jan 2018 06:10:37 -0000
To: Michael Tuexen <Michael.Tuexen@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> <9493C5B9-A79E-4311-8C07-67E14564B1ED@lurchi.franken.de>
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>
From: Christian Huitema <huitema@huitema.net>
Message-ID: <838694fc-bfb6-9804-b8fa-ad7aa47e5472@huitema.net>
Date: Sat, 20 Jan 2018 20:10:34 -1000
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <9493C5B9-A79E-4311-8C07-67E14564B1ED@lurchi.franken.de>
Content-Type: multipart/alternative; boundary="------------D0A2405547FB08E6C3809962"
X-Originating-IP: 168.144.250.215
X-AntiSpamCloud-Domain: xsmtpout.mail2web.com
X-AntiSpamCloud-Username: 168.144.250.0/24
Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com
X-AntiSpamCloud-Outgoing-Class: unsure
X-AntiSpamCloud-Outgoing-Evidence: Combined (0.25)
X-Recommended-Action: accept
X-Filter-ID: EX5BVjFpneJeBchSMxfU5il7EG9TbWSGhDGl5JbJQMoXv9krsgRhBn0ayn6qsUc7AxcDYLQWPWOw vKJpm+ErX61PdOWeIW8R8TgUu5HhPnJC7BfLwPAprJgXEz+mTa2DTGulXfuaNr1V9B1E4+3dI5VM iIKmvXxtALVuD1NjPz5fZdf1siwYNJirk4ABKayRZsQEbaxxISMHgJxrdMdSS4B6hVJPXxgisa+g wkHvC+PVG1YjIrFRKhESMT/tU1Dx+IHaAZrg1ulFniksjLYqZxdG5bOwa1rOgT+89+/XFrGt2tce crpXRY6fm8RXptyzavERpop5LF7RavHozgbn9XzprFRbpFQTOcEGeQOY3IcDlgJpEbxunV7tCPNi PQvHQpVRoYcix47lJTuKsG8TgnDHFRDF834rtLc6Wv9Yj+vBPX9bzGJi0ycLbiOUDEySIK/1NH5T HMtlYvyHAYGOGheVSH7cGoIH3Vd41lbD31VgwWqLoIJoKisE2LaVktjkoBooiqCtwqmCSyE26E80 CcIIa9pF9PUqqEB2bD5cBVrh9PobrbwB1Jj4vRnvuFdQKx3Zprq3ZEpafGy+zLjUntilh9dvYvV/ 5Pg3UZt3l4cobM5+AwD0A5qDgSPsXJ3GYnRqIO2TPU1F0bSG6T2DJZnHEeB4hpRrmo/duzUUp/Kk srS1edYbOHZeK24FwQY9Ur/FmUv0D+GzhBYicKWDwnLYM3A6BXfvel8OEFDbU529jj6VuEkkQiOd 2CLFCAI+G45OmBNdsUklj47JM2Zh1oj2lB9TLiDMfXuvSrucRXry8B6sEcpHNQcjlAOoToGvpsib JQz6bCR19sO/++nnSqCDBedeB75TJ0VuxRY+unEnaeycva4NRXu2m3j3Y8zB9xGo0bndvIE+SDBs cm+vLiZuZ5OAUoGBziSYFLZuu6wTRhJez+ibxiREoUwadL3g
X-Report-Abuse-To: spam@quarantine5.antispamcloud.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/ku9xEmJ9usXdCz_pAsOha4h-4YQ>
Subject: Re: [tsvwg] Adoption call: draft-fairhurst-tsvwg-datagram-plpmtud-02 to end 10th January 2018
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsvwg/>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 21 Jan 2018 06:10:51 -0000

On 1/10/2018 8:57 AM, Michael Tuexen wrote:

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

Since you mentioned it, I implemented "application level" PMTUD in my
implementation of QUIC (https://github.com/private-octopus/picoquic).
Basic "probe" strategy. Start with the min value (from IPv6), then learn
the peer-supported value during the handshake (standard QUIC), then send
probes to perform a binary search between min and max. Stop the binary
search if the range of search is less than 10 bytes. No ICMP dependency.
Some overhead, but that is amortized by sending a dozen packets or so at
the maximum size instead of the default size.

-- Christian Huitema

v2.23.0 | Report a Bug | By Email