Re: DPLPMTUD - searching algorithm

Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com> Tue, 12 November 2019 17:18 UTC

Return-Path: <mikkelfj@gmail.com>
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 18345120842 for <quic@ietfa.amsl.com>; Tue, 12 Nov 2019 09:18:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 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_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 fI5rHtMitWyx for <quic@ietfa.amsl.com>; Tue, 12 Nov 2019 09:17:59 -0800 (PST)
Received: from mail-yw1-xc2f.google.com (mail-yw1-xc2f.google.com [IPv6:2607:f8b0:4864:20::c2f]) (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 8B528120837 for <quic@ietf.org>; Tue, 12 Nov 2019 09:17:59 -0800 (PST)
Received: by mail-yw1-xc2f.google.com with SMTP id y18so6704894ywk.1 for <quic@ietf.org>; Tue, 12 Nov 2019 09:17:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:subject:thread-topic:thread-index:date:message-id :references:in-reply-to:accept-language:content-language :mime-version; bh=0LT2PRrGDL6a2uQNnZl5wL4ayZt3mgAFA/7gmy+14w0=; b=eLsU6fe2+haAkbLK2a0z0n58YxHpsIXp498AiYw3Blls2Gr1gVaNWSJb/OVtTWtoOr qgeOpHGlly/Chn8u4wZKixcljEPnzR9Y70uAObuhnPa6fCMcYGHFlUMhE+rbEC9tn3Pl xM6twGh5L60Wmx07HCtPw7XWrThAGIWa0BLffqax0KVDD98snt6xH26t2Y2KRT0Ziu/W zuqSM7GhFvWi8HseAlU3WsBnkiqxT9/SxxiEArH95pW8OpPFPmYW8oc2p+0AqRLEqrSX Ghkpadi2QihjYKJoRFB4tWPlrUFY9gD30VG0XgRIcgJ//wcRz8nF0Pfw6sLnQiPOBmij xtMg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:thread-topic:thread-index:date :message-id:references:in-reply-to:accept-language:content-language :mime-version; bh=0LT2PRrGDL6a2uQNnZl5wL4ayZt3mgAFA/7gmy+14w0=; b=UyMlWg41nkx3uT49/TVmwDBPN/2hbTaTZdQ7dNuZ7i31/f3WXmL6lZ3uWrnOpnCy2r iXxCfszMEcsNYiW/+2LhkkQlB0ZE4KSXUqe2zQzG6gKSe/PJA5PXGsAKLnqk+8bhDAp6 8O/qnz0Hp+2YIogWHBX2rpLW+PkxlsWOfQDMu6hWfhVeyTN50XskunOvRDLzO65yr3yP AetPomUx+gx8/zG+Gdjs8R/rmOd/Y44aaQk2d9Tt5emYtMKPt2d1hSf4C5Ar34TjL4A5 ODxyoHLguvbfbvylmLulUrQ+YvqEA5JarhFdnKB0A1jJi1OehkIcYpQocUHaVQFQHxdF tCZg==
X-Gm-Message-State: APjAAAU3dVclMmHR8tCD51JN6kIOLUECSm7W4abTVwf/5wL8OJv7d5OK EGoapvEccIBsq20q0Ew6ppQ=
X-Google-Smtp-Source: APXvYqxi+leb6jU191IWGjNlasREEZ2Y5qC1Kr6pBh90HCqFyOIT9d3mAfbTMEInfgexbbgzS66YgA==
X-Received: by 2002:a81:4104:: with SMTP id o4mr19771753ywa.353.1573579077549; Tue, 12 Nov 2019 09:17:57 -0800 (PST)
Received: from DB6PR10MB1766.EURPRD10.PROD.OUTLOOK.COM ([2603:1026:6:38::5]) by smtp.gmail.com with ESMTPSA id s18sm9096843ywk.33.2019.11.12.09.17.56 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 12 Nov 2019 09:17:56 -0800 (PST)
From: Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com>
To: Gorry Fairhurst <gorry@erg.abdn.ac.uk>, Lars Eggert <lars@eggert.org>, QUIC IETF mailing list <quic@ietf.org>
Subject: Re: DPLPMTUD - searching algorithm
Thread-Topic: DPLPMTUD - searching algorithm
Thread-Index: AQHVmXwOHXYaYEw3U0SUmiW4o80686eHxpeH
X-MS-Exchange-MessageSentRepresentingType: 1
Date: Tue, 12 Nov 2019 17:17:54 +0000
Message-ID: <DB6PR10MB17666DB39ACF173E47E89790AC770@DB6PR10MB1766.EURPRD10.PROD.OUTLOOK.COM>
References: <3015EFF3-A0C6-4725-A13B-CAE4F1E5F9D1@kuehlewind.net> <F613BAC3-8744-49CB-8860-8652F7DA56ED@eggert.org> <CAN1APde49R0Dgfdf1k7h=Gfcu=Ny-zgP9s+G9qhnUj+FET5UYw@mail.gmail.com>, <27d2c910-bb06-23b3-7bfa-aba4008792f7@erg.abdn.ac.uk>
In-Reply-To: <27d2c910-bb06-23b3-7bfa-aba4008792f7@erg.abdn.ac.uk>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-Exchange-Organization-SCL: -1
X-MS-TNEF-Correlator:
X-MS-Exchange-Organization-RecordReviewCfmType: 0
Content-Type: multipart/alternative; boundary="_000_DB6PR10MB17666DB39ACF173E47E89790AC770DB6PR10MB1766EURP_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/zvO9pV__lKDI1X7Lc5NtVyXeCNo>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.29
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: Tue, 12 Nov 2019 17:18:02 -0000

I have not tried this search with PMTU, but I have used it elsewhere such as finding the last valid record in a large file post crash.


________________________________
Fra: Gorry Fairhurst <gorry@erg.abdn.ac.uk>
Sendt: tirsdag, november 12, 2019 6:10 PM
Til: Mikkel Fahnøe Jørgensen; Lars Eggert; QUIC IETF mailing list
Emne: DPLPMTUD - searching algorithm

Many thanks - because you spotted a couple of lingering mistakes.

On 12/11/2019 13:19, Mikkel Fahnøe Jørgensen wrote:
> After fast read through the document I am a bit concerned about the
> proposed search algorithm: chose a set of sizes to progressively
> inspect until MAX is accepted or a black hole is detected.
>
This was meant to consistently say the search terminates after MAX
probes fail in succession (of any size). It then terminates without
increasing the PLPMTU. This bounds unproductive work. This was discussed
in TSVWG for an earlier revision, and various parts updated and I'll
make sure the remaining errant text reads this way before WGLC.

> Another search pattern would be to use exponential search where gaps
> become increasingly larger, but when a black hole is detected, smaller
> sizes are tested by choosing a probe size between the smallest known
> black hole and the larges known valid packet size, rather than
> stopping immediately after first black hole.
>
>
Sure - you can choose to do that.  You could decide to use any method
you like to choose a probe size when searching. I suspect you will find
more pleasure in using a simple list of preferred sizes (possibly with a
second refinement stage), but there are plenty of ways you can propose
new searches!

If you do have information from any real experiments using other search
methods, it would be fun to know - please use the TSVWG list to discuss
that.

Gorry

(I updated the subject line)

>
> Kind Regards,
> Mikkel Fahnøe Jørgensen
>
>
> On 12 November 2019 at 13.54.32, Lars Eggert (lars@eggert.org
> <mailto:lars@eggert.org>) wrote:
>
>> Note that there will be chunk of time dedicated in TSVAREA to discuss
>> how the IETF might want to split up future work on QUIC application
>> bindings and QUIC extensions and maintenance into existing and new WGs.
>>
>> Lars
>>
>> > Begin forwarded message:
>> >
>> > From: Mirja Kuehlewind <ietf@kuehlewind.net
>> <mailto:ietf@kuehlewind.net>>
>> > Subject: TSVAREA agenda for IETF-106
>> > Date: November 12, 2019 at 14:46:43 GMT+2
>> > To: tsv-area@ietf.org <mailto:tsv-area@ietf.org>
>> >
>> > Hi all,
>> >
>> > The agenda for our next tsvarea meeting is online (actually since
>> beginning of last week already):
>> >
>> > https://datatracker.ietf.org/meeting/106/materials/agenda-106-tsvarea
>> >
>> > We only have a short slot but will take some time to discuss new
>> work topics related to QUIC. The TSV ADs will meeting before the
>> session with the ART ADs and QUIC chairs and we should be able to
>> report back for that..
>> >
>> > See you soon in Singapore or remotely!
>> >
>> > Mirja and Margnus (from remote)
>> >
>> >
>>