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

Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com> Sun, 21 January 2018 09:50 UTC

Return-Path: <mikkelfj@gmail.com>
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 88B39124239; Sun, 21 Jan 2018 01:50:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Level:
X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 oeO3q0_0xlS2; Sun, 21 Jan 2018 01:50:30 -0800 (PST)
Received: from mail-it0-x234.google.com (mail-it0-x234.google.com [IPv6:2607:f8b0:4001:c0b::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E4C41201F8; Sun, 21 Jan 2018 01:50:30 -0800 (PST)
Received: by mail-it0-x234.google.com with SMTP id 68so6660602ite.4; Sun, 21 Jan 2018 01:50:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=CLm0fKvh23szIeaCKf8WY+OmJ+IgiRrQdPlo/abD7H0=; b=Pi6tdFcNLHY5EFyBLVLlc8Rd7S7hOgq7a0fudMuUzjzYG7ytXd+oVVoPOWY/J5NfhF ElJeGM39LQi3/DIhC+O6TC/uWJO155rcADR343IZk+SVCJX9YwBskOx89l0m4qX1Ksfx +cfVtkjFxqyFHmMJk15kNWenEs0p65WBZ0D6o8IxsafE40qqOLT4CUc4DuJSWe9MiAOW wKjRRUQs9W+2e+68BgSOhjqish1+w2IBWtd9SWjX24At87aWGVTLtaYeo5S98jQU9yYf /iHBHQJ15MMYDLRV/7+UK6Yv1gw+K1bg46UNgHVQ44Dr/oEzurHZoaxUTzoP+KXX+cYU 63PA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=CLm0fKvh23szIeaCKf8WY+OmJ+IgiRrQdPlo/abD7H0=; b=pFYBvm6wfsvC1AAGWHfqDjqX5l8dsOCN3iO88LlgnV6cjAPG01YVsMhRByM4GukkJj wGeHNj1NFSyyv1pn1r1Yf8iyzDOldIU0xkqfhfdA8GicoJ7q66xAHzuVtrdxBcc9NMTv oJs/AUn47nuiv4d5Ur1QBkDH5ifr9AwbHOyX5h1JD2ZndoGhq5TzGC5HW03IC25Zq4nL HsocV8GL+M+LEmoVdIeecmSYrTH+2/Br+kBdp5rMJG+zsM+7/srCf5MsKCHAry3PDq8+ u0ohnD3Edzj6pZU2ZE/+ocfB46MkROxmonevV32yvL0PhgpcrQIvn3bc4i3hFXdxgqVY ofng==
X-Gm-Message-State: AKwxytfX68747GPc/El7kKg+CZqUc5VKqhxUbvLwnKlDpmw6LqtaonR5 vIKVb+E8XqgBkhPcNzRiWdaHCusYthb+/RaNlVM=
X-Google-Smtp-Source: AH8x2267rljw79xUqIJ3esxJu7tPe0KiFiAL3cEswXIGTtRf/Q6/an3S0Kh1113wTGN8HC2W/K3PA6xN2G+rZdjCVmc=
X-Received: by 10.36.189.129 with SMTP id x123mr2752657ite.31.1516528229648; Sun, 21 Jan 2018 01:50:29 -0800 (PST)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Sun, 21 Jan 2018 01:50:28 -0800
From: Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com>
In-Reply-To: <CAN1APdfiUTbnW2SrE_DXB2bOWqjd5GKjmZwEF11pBsHh9HHxZQ@mail.gmail.com>
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>
X-Mailer: Airmail (420)
MIME-Version: 1.0
Date: Sun, 21 Jan 2018 01:50:28 -0800
Message-ID: <CAN1APddumrZPELjeFR5hnwP3CuGUNyzZ_rZy=UJHqEZh0iZcWA@mail.gmail.com>
To: Christian Huitema <huitema@huitema.net>, Michael Tuexen <michael.tuexen@lurchi.franken.de>
Cc: Gorry Fairhurst <gorry@erg.abdn.ac.uk>, "Black, David" <david.black@dell.com>, QUIC WG <quic@ietf.org>, "Eggert, Lars" <lars@netapp.com>, "tsvwg@ietf.org" <tsvwg@ietf.org>
Content-Type: multipart/alternative; boundary="94eb2c196d286b8f990563463e38"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/z4JK0yMkuGsP3alA7oTLYXKsjfg>
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 09:50:33 -0000

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 */

Kind Regards,
Mikkel Fahnøe Jørgensen


On 21 January 2018 at 09.28.32, Mikkel Fahnøe Jørgensen (mikkelfj@gmail.com)
wrote:


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



How you considered exponential search where you start with a conservative
limit for the upper bound, then exponentially increase that limit until
maxPMTU. It is not faster than binary search if each size is equally
likely, but that is probably not true.
I assume it would use less bandwidth if the max is much larger than the
typical PMTU, and allow the application to start using larger MTU’s earlier
since early guesses are more likely to succeed.

/* roughly like this - untestet */
a = minPMTU
b = maxPMTU
k = initDelta /* 1 or larger, e.g. minPMTU / 4 */
while a <= b
  k = min(a + k, b) - a
  n = binsearch(a, a + k - 1)
  if n return n
  a = a + k /* this doubles the search range */
end
return not found

https://en.wikipedia.org/wiki/Exponential_search