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

Christian Huitema <huitema@huitema.net> Mon, 22 January 2018 04:42 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 7DABF1241F8 for <quic@ietfa.amsl.com>; Sun, 21 Jan 2018 20:42:42 -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 W6Y2EC9BjEg0 for <quic@ietfa.amsl.com>; Sun, 21 Jan 2018 20:42:40 -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 EA3BF12704A for <quic@ietf.org>; Sun, 21 Jan 2018 20:42:39 -0800 (PST)
Received: from xsmtp06.mail2web.com ([168.144.250.232]) by mx36.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from <huitema@huitema.net>) id 1edTwK-0006nc-6S for quic@ietf.org; Mon, 22 Jan 2018 05:42:37 +0100
Received: from [10.5.2.17] (helo=xmail07.myhosting.com) by xsmtp06.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from <huitema@huitema.net>) id 1edTwI-000109-A4 for quic@ietf.org; Sun, 21 Jan 2018 23:42:35 -0500
Received: (qmail 9234 invoked from network); 22 Jan 2018 04:42:32 -0000
Received: from unknown (HELO [192.168.200.68]) (Authenticated-user:_huitema@huitema.net@[72.235.171.77]) (envelope-sender <huitema@huitema.net>) by xmail07.myhosting.com (qmail-ldap-1.03) with ESMTPA for <quic@ietf.org>; 22 Jan 2018 04:42:32 -0000
To: =?UTF-8?Q?Mikkel_Fahn=c3=b8e_J=c3=b8rgensen?= <mikkelfj@gmail.com>, 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> <838694fc-bfb6-9804-b8fa-ad7aa47e5472@huitema.net> <CAN1APdfiUTbnW2SrE_DXB2bOWqjd5GKjmZwEF11pBsHh9HHxZQ@mail.gmail.com> <CAN1APddumrZPELjeFR5hnwP3CuGUNyzZ_rZy=UJHqEZh0iZcWA@mail.gmail.com>
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: <150452ec-ba36-f88a-4c29-013fea99c9c2@huitema.net>
Date: Sun, 21 Jan 2018 18:42:27 -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: <CAN1APddumrZPELjeFR5hnwP3CuGUNyzZ_rZy=UJHqEZh0iZcWA@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------BF4705958E1D67DBB5B8A056"
Subject: Re: [tsvwg] Adoption call: draft-fairhurst-tsvwg-datagram-plpmtud-02 to end 10th January 2018
X-Originating-IP: 168.144.250.232
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.28)
X-Recommended-Action: accept
X-Filter-ID: EX5BVjFpneJeBchSMxfU5r3d1FEZaJyy6RdGXSw7HVoXv9krsgRhBn0ayn6qsUc7A2kcKDr1fzRm ksYYe0sWHrgNzB/4Jkrw1eDLcif59ftEU8aM6MfxYCcR8Fh3AbpAB98yDTitFWvbHwz9vKZpm/D1 Ad4OAlzgsEH8ABk9OXtfZdf1siwYNJirk4ABKayRZsQEbaxxISMHgJxrdMdSS4B6hVJPXxgisa+g wkHvC+PVG1YjIrFRKhESMT/tU1Dx+IHaAZrg1ulFniksjLYqZxdG5bOwa1rOgT+89+/XFrGt2tce crpXRY6fm8RXptyzavERpop5LF7RavHozgbn9XzprFRbpFQTOcEGeQOY3IcDlgJpEbxunV7tCPNi PQvHQpVRoYcix47lJTuKsG8TgnDHFRDF834rtLc6Wv9Yj+vBPX9bzGJi0ycLbiOUDEySIK/1NH5T HMtlYvyHAYGOGheVSH7cGoIH3Vd41lbD31Xq4ax6KvrI/nhOyr4XmBA0QaRU5G7TB9RBnrQ7zv+k CoMUI2V1gIW0H5wha94dZjfHJ9u0kPRauioqi6k0R8EPx6JvzKixj8PC+OqalCFkmpH+vpUDIZeJ XjrpEEsmd+8wbu9lcViFVxDhGp2PwufGcyNBJprCgmabT8JgPqpM5rXFXkQEnTC9rKm30SFEfAxD bFosV7q/YY6M+t085tvsRb/dy1Din9mPcafaVFLA8lz1pRXWhjh9fdbl44I0Df0tN9eq0V0hlrWD EiOHLhiBnVLUE5wQMuDWRk3qAUSk9R3h1vgDbEdmhrg3iVBpdRa29tyIytZRvp0Gut3t97wmGpIO PepTCxFMvIavjx/iA3YOJbgNLT0Ix6mdJEErnNhWBb39uS1TjWG2Inx+Ts2QvrhVVD6SNHfaCiIW OOQAkvVDEoFOK6EAWKQ3WFIxRUtYANHDTJAVnZcGvok0a1Vj
X-Report-Abuse-To: spam@quarantine5.antispamcloud.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/TcoXA_Mf_6yDCUXqAKx1MrCTVZc>
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: Mon, 22 Jan 2018 04:42:42 -0000


On 1/20/2018 11:50 PM, Mikkel Fahnøe Jørgensen wrote:
> Here is a Fibonacci variant the grows slower.
> Not sure it is any better, but the intention is to avoid probing very
> large packets too early.
> It could probably be applied recursively to avoid bin search altogether.
> The same idea might be applicable to reducing the congestion window as
> opposed to doubling or halving.
>
> /* Fibonacci variant */
> /* roughly like this - untestet */
> unit = 10 /* min probe increment */
> a = minPMTU / unit
> b = maxPMTU / unit
> k1 = initDelta /* 1 or larger, e.g. a / 4 */
> k0 = 0
> while a + k0 <= b
>   k2 = k0 + k1
>   n = binsearch(a + k0, min(a + k1 - 1, b), unit)
>   if n return n
>   k0 = k1
>   k1 = k2
> end
> /* binsearch probes multiples of unit and calls
>    updatePMTUEstimate(n) whenever n is a larger
>    valid probe than previously reported */
>
Yes, there are multiple ways to go about sending probes. In the QUIC
case, the peer sends its own version of MAX MTU during the handshake. So
what I did was simply try the peer's MTU, and if that fail do a binary
search between that and the initial value. The peer MTU is typically
between 1470 and 1500, so the binary search converges very quickly.

There are certainly ways to do better, especially if the peer sets its
own MTU to some large value, e.g. in a data center environment. For
example, one could have a table of probability of finding some
particular MTU. And then apply logic based on how much the connection
wants to send, what it costs to send a probe, and what is the likely
gain if the probe succeeds. You could use that to choose the next probed
value. Or to decide to stop probing if no plausible next value can bring
a potential gain. Or to send several probes in parallel...

-- Christian Huitema