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: Mikkel Fahnøe Jørgensen <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) >> > >> > >>
- Fwd: TSVAREA agenda for IETF-106 Lars Eggert
- Re: Fwd: TSVAREA agenda for IETF-106 Mikkel Fahnøe Jørgensen
- DPLPMTUD - searching algorithm Gorry Fairhurst
- Re: DPLPMTUD - searching algorithm Mikkel Fahnøe Jørgensen