DPLPMTUD - searching algorithm

Gorry Fairhurst <gorry@erg.abdn.ac.uk> Tue, 12 November 2019 17:10 UTC

Return-Path: <gorry@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 0F3C01200DB for <quic@ietfa.amsl.com>; Tue, 12 Nov 2019 09:10:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=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 HjAt_oVgqJs2 for <quic@ietfa.amsl.com>; Tue, 12 Nov 2019 09:10:10 -0800 (PST)
Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [137.50.19.135]) by ietfa.amsl.com (Postfix) with ESMTP id 70CA3120836 for <quic@ietf.org>; Tue, 12 Nov 2019 09:10:10 -0800 (PST)
Received: from gorry-mac.erg.abdn.ac.uk (unknown [IPv6:2001:630:42:110:a065:fd0e:a1dc:e8bc]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id 1ADC11B0017A; Tue, 12 Nov 2019 17:10:01 +0000 (GMT)
Subject: DPLPMTUD - searching algorithm
To: =?UTF-8?Q?Mikkel_Fahn=c3=b8e_J=c3=b8rgensen?= <mikkelfj@gmail.com>, Lars Eggert <lars@eggert.org>, QUIC IETF mailing list <quic@ietf.org>
References: <3015EFF3-A0C6-4725-A13B-CAE4F1E5F9D1@kuehlewind.net> <F613BAC3-8744-49CB-8860-8652F7DA56ED@eggert.org> <CAN1APde49R0Dgfdf1k7h=Gfcu=Ny-zgP9s+G9qhnUj+FET5UYw@mail.gmail.com>
From: Gorry Fairhurst <gorry@erg.abdn.ac.uk>
Message-ID: <27d2c910-bb06-23b3-7bfa-aba4008792f7@erg.abdn.ac.uk>
Date: Tue, 12 Nov 2019 17:09:56 +0000
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:60.0) Gecko/20100101 Thunderbird/60.8.0
MIME-Version: 1.0
In-Reply-To: <CAN1APde49R0Dgfdf1k7h=Gfcu=Ny-zgP9s+G9qhnUj+FET5UYw@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/iHHVi1ORWBAiZd4QtKQGezIw-Bk>
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:10:15 -0000

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