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: 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 E07B8126CD8 for <quic@ietfa.amsl.com>; Sat, 20 Jan 2018 22:10:47 -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=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 zEVtEQ4fRIrh for <quic@ietfa.amsl.com>; Sat, 20 Jan 2018 22:10:45 -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 5EB19126C83 for <quic@ietf.org>; Sat, 20 Jan 2018 22:10:45 -0800 (PST)
Received: from xsmtp31.mail2web.com ([168.144.250.234] helo=xsmtp11.mail2web.com) by mx6.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from <huitema@huitema.net>) id 1ed8q2-0007HL-GJ for quic@ietf.org; Sun, 21 Jan 2018 07:10:43 +0100
Received: from [10.5.2.16] (helo=xmail06.myhosting.com) by xsmtp11.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from <huitema@huitema.net>) id 1ed8pz-0002x8-QY for quic@ietf.org; Sun, 21 Jan 2018 01:10:40 -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"
Subject: Re: [tsvwg] Adoption call: draft-fairhurst-tsvwg-datagram-plpmtud-02 to end 10th January 2018
X-Originating-IP: 168.144.250.234
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: EX5BVjFpneJeBchSMxfU5il7EG9TbWSGhDGl5JbJQMoXv9krsgRhBn0ayn6qsUc7A2kcKDr1fzRm ksYYe0sWHrgNzB/4Jkrw1eDLcif59fvr1TWd95YLbTMNwzaw0iTwB98yDTitFWvbHwz9vKZpm2Ea bzmM/1VynIZUVImbQiuZ3JKVmi72ocgY5kMQSjs7Pk8VxOtUn7O9m8cCuN8HIa1B2N+xwNIm4bky rJMaAA8yXDZ4EHnDt87IyrZAC2/gfn4eyCwIWdDDlFG98+9qd+BFwYDEPnet1tXHsknHYhhwbzpt P1hS4Kj7E/EWE1j8sESBnZ29929fqpFFzBN0ceyPnEGyyfS0ggcDdodDMKpYg9ruAKOoPnwmy4wG 8XtJqWVYNxS4myu1gxnHJBnmumz49PzUWhdE3zEeQF2k5bdHrh2h0Pu50H7NzHw6NK3VYL8jvyeW A9EsRvV6CqjePBKOhcObZXWnkEw+6F9CGyYW9UNFgzCqKDXesOntN1zD9IUJ5y4fZBwzmfWaECTh P/oQ1EzuEfiLKxxAy46D0GjGvVLPSj+Hlyh2mculO/W8NktFVcl6hrIDm43UklXgo0rGkb5OztVl OoF8rUUHwR1JLObs/ksVBOHvEAgSr8kA+RIanNskcVaAsgQvWYhIsUONoJfh+XjGSeeT90H/uIFb b4HHKRuIHoQeG0jQmHnJeoPXVyRORlQAvrAqTChPtGbjO41FyBEqIaDudcVplPEfgkCmu0AbpCDt lYGBUhlWN4ZNH6v0KsokFeP+Z5h4BvfFcHV2tQAVqGdj/zM7G/GWbjl4MpjTNPMnYcbh6U8Z5ft9 Iz0WDtXlRni5HCCJM9Qvlo9UV7vdWttsewtXKowaEO652uo+6xHVEn43gl09gN9PtOEBx/RKpFEr HkJ0VfjEzm1SsR8v3aJbN/NZfa/pGyl0Yc/hSh4fhbFqiL7w
X-Report-Abuse-To: spam@quarantine5.antispamcloud.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/LqC8HOaqjxADHWiFrQAR9TavKfg>
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: Sun, 21 Jan 2018 06:10:48 -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