Re: [tsvwg] DPLPMTU (was RE: design assumptions - draft-ietf-udp-options - trying to see the bigger picture)
Gorry Fairhurst <gorry@erg.abdn.ac.uk> Fri, 19 July 2019 08:13 UTC
Return-Path: <gorry@erg.abdn.ac.uk>
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 0337D12015D for <tsvwg@ietfa.amsl.com>; Fri, 19 Jul 2019 01:13:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=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 W22UZVV_a26l for <tsvwg@ietfa.amsl.com>; Fri, 19 Jul 2019 01:13:09 -0700 (PDT)
Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [IPv6:2001:630:42:150::2]) by ietfa.amsl.com (Postfix) with ESMTP id 1D21F12015B for <tsvwg@ietf.org>; Fri, 19 Jul 2019 01:13:08 -0700 (PDT)
Received: from gorry-mac.erg.abdn.ac.uk (unknown [IPv6:2001:630:42:110:c9aa:9b60:bca2:acaf]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id 8393C1B00161; Fri, 19 Jul 2019 09:13:04 +0100 (BST)
To: mohamed.boucadair@orange.com, "C. M. Heard" <heard@pobox.com>
Cc: TSVWG <tsvwg@ietf.org>
References: <787AE7BB302AE849A7480A190F8B93302FA84143@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
From: Gorry Fairhurst <gorry@erg.abdn.ac.uk>
Message-ID: <0e35d38d-fb51-1391-08c2-664dff8228a0@erg.abdn.ac.uk>
Date: Fri, 19 Jul 2019 09:13:02 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:60.0) Gecko/20100101 Thunderbird/60.7.2
MIME-Version: 1.0
In-Reply-To: <787AE7BB302AE849A7480A190F8B93302FA84143@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
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/tsvwg/pIVz2Z_mZ-Js21C6ovsxqIwIvXA>
Subject: Re: [tsvwg] DPLPMTU (was RE: design assumptions - draft-ietf-udp-options - trying to see the bigger picture)
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.29
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: Fri, 19 Jul 2019 08:13:11 -0000
Thanks: We do need to check that, Gorry On 19/07/2019 06:32, mohamed.boucadair@orange.com wrote: > Hi Mike, Gorry, all, > > (Focusing on the DPLPMTU part) > > How the pieces are structured/described in the two documents is broken. > > udp-options has a normative dependency on DPLPMTU I-D to specify how this would work, but that document does not elaborate on the processing of UDP options. > > Cheers, > Med > >> -----Message d'origine----- >> De : tsvwg [mailto:tsvwg-bounces@ietf.org] De la part de Gorry Fairhurst >> Envoyé : jeudi 18 juillet 2019 18:16 >> À : C. M. Heard >> Cc : TSVWG >> Objet : Re: [tsvwg] design assumptions - draft-ietf-udp-options - trying >> to see the bigger picture >> >> On 18/07/2019, 16:46, C. M. Heard wrote: >>> On Thu, Jul 18, 2019 at 3:39 AM Gorry Fairhurst wrote: >>>> For DPLPMTU (#6) the complexity is in another spec (which seems >> correct >>>> to me). I'd be interested whether a separate spec of Frag is also one >>>> way to ensure we get experience with the core spec, and then consider >>>> how to design Frag (#5, #8). >>> For DPLPMTU the complexity is in another spec, but the tools that UDP >>> options provide for it are in the base spec. Those tools are: >>> >>> - padding for probe packets >>> - request option >>> - response option >>> >>> The request and response options are pretty straightforward, but the >>> details of how padding will be accommodated may well depend on what >>> packet format we converge to for providing other things, especially >>> FRAG. >> DPLPMTUD works best with *just* padding packets (i.e. that carry no >> payloads or fragments). It's just so much easier to run the algorithm.
- [tsvwg] DPLPMTU (was RE: design assumptions - dra… mohamed.boucadair
- Re: [tsvwg] DPLPMTU (was RE: design assumptions -… Gorry Fairhurst