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

Tom Jones <tom@erg.abdn.ac.uk> Thu, 25 January 2018 10:41 UTC

Return-Path: <tom@erg.abdn.ac.uk>
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 8BC8612D967; Thu, 25 Jan 2018 02:41:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 5Nra79a4boWQ; Thu, 25 Jan 2018 02:41:06 -0800 (PST)
Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [IPv6:2001:630:241:204::f0f0]) by ietfa.amsl.com (Postfix) with ESMTP id 7DB4B126CBF; Thu, 25 Jan 2018 02:41:06 -0800 (PST)
Received: from auth2-smtp.messagingengine.com (auth2-smtp.messagingengine.com [66.111.4.228]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id 7BFC91B001CF; Thu, 25 Jan 2018 10:41:04 +0000 (GMT)
Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailauth.nyi.internal (Postfix) with ESMTP id B9E7E216CA; Thu, 25 Jan 2018 05:41:00 -0500 (EST)
Received: from frontend2 ([10.202.2.161]) by compute7.internal (MEProxy); Thu, 25 Jan 2018 05:41:00 -0500
X-ME-Sender: <xms:PLRpWkCm3BRPfmESkEmmqPWHLUW5xk5dM0DnUGupB0IlSK2XVT8vwA>
Received: from tom-desk.erg.abdn.ac.uk (tom-desk.erg.abdn.ac.uk [139.133.204.4]) by mail.messagingengine.com (Postfix) with ESMTPA id C785124640; Thu, 25 Jan 2018 05:40:59 -0500 (EST)
Date: Thu, 25 Jan 2018 10:40:57 +0000
From: Tom Jones <tom@erg.abdn.ac.uk>
To: Christian Huitema <huitema@huitema.net>
Cc: Mikkel =?iso-8859-1?Q?Fahn=F8e_J=F8rgensen?= <mikkelfj@gmail.com>, Michael Tuexen <michael.tuexen@lurchi.franken.de>, Gorry Fairhurst <gorry@erg.abdn.ac.uk>, "tsvwg@ietf.org" <tsvwg@ietf.org>, QUIC WG <quic@ietf.org>
Subject: Re: [tsvwg] Adoption call: draft-fairhurst-tsvwg-datagram-plpmtud-02 to end 10th January 2018
Message-ID: <20180125104057.GA9797@tom-desk.erg.abdn.ac.uk>
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> <150452ec-ba36-f88a-4c29-013fea99c9c2@huitema.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <150452ec-ba36-f88a-4c29-013fea99c9c2@huitema.net>
User-Agent: Mutt/1.9.2 (2017-12-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/SVmh6ilb5-wNRzxOSqII2cc90HA>
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: Thu, 25 Jan 2018 10:41:10 -0000

On Sun, Jan 21, 2018 at 06:42:27PM -1000, Christian Huitema wrote:
> 
> 
> 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.

Thanks for the comment, this is an interesting approach we probably need
some discussion of the probe size search algorithm in the draft. 

Is the ~1500 value something you have manually configured or have you
found it from the host? maxdgram on my machine is 9216. 

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

RFC1191 suggested a table with some common values. I would try:

	- validating the base ~1280
	- probing for ~1500
	- if that works probing for the Max MTU from the peer

then falling back to a search algorithm to close the gap if it is a
sensible size.

- [tj]