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

Gorry Fairhurst <> Wed, 10 January 2018 15:39 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 555F212D862; Wed, 10 Jan 2018 07:39:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id FXp2wHXeUCDN; Wed, 10 Jan 2018 07:39:32 -0800 (PST)
Received: from ( [IPv6:2001:630:241:204::f0f0]) by (Postfix) with ESMTP id BE1C212751F; Wed, 10 Jan 2018 07:39:32 -0800 (PST)
Received: from Gs-MacBook-Pro.local ( []) by (Postfix) with ESMTPA id 43C021B00062; Wed, 10 Jan 2018 15:38:56 +0000 (GMT)
Message-ID: <>
Date: Wed, 10 Jan 2018 15:38:56 +0000
From: Gorry Fairhurst <>
Organization: University of Aberdeen
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: "Eggert, Lars" <>
CC: "Black, David" <>, QUIC WG <>, "" <>
Subject: Re: [tsvwg] Adoption call: draft-fairhurst-tsvwg-datagram-plpmtud-02 to end 10th January 2018
References: <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: <>
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 10 Jan 2018 15:39:34 -0000

On 09/01/2018, 11:11, Eggert, Lars wrote:
> Hi,
> would someone clarify what the intended relationship of the mechanism 
> described in the document and QUIC is? For example, is the intention 
> here that QUIC should implement this,  is this unrelated, or anything 
> in between?
The work originates from updates to the IPv6 base spec, and the need to 
consider how to do PLPMTUD for transports other than TCP.  There's 
practical code for UDP-Options, and SCTP, and that is presently evolving 
with the Spec.

I suspect someone could use the final method with QUIC - since it's also 
a UDP-based transport. I don' knopw of anyone planning PMTUD for QUIC - 
please get in touch if that is on your radar.
> Asking, because if there is an intended relationship, it would be good 
> to discuss this sooner rather than later.
> Thanks,
> Lars
Best wishes,
>> On 2017-12-15, at 7:27, Black, David < 
>> <>> wrote:
>> I’m tardy in getting to this action item from the TSVWG meeting in 
>> Singapore …
>> The TSVWG chairs are considering adoption of the draft
>> "Packetization Layer Path MTU Discovery for Datagram Transports".
>> This draft has been discussed at the previous IETF meeting and on the 
>> list, and the chairs are now looking for input from the group to help 
>> inform whether TSVWG should adopt this draft.
>> * Please send an email to this list if you would like to see this 
>> work adopted in TSVWG, or you have comments on the suitability for 
>> adoption.
>> * Please indicate if you are willing to REVIEW such a document during 
>> its development.
>> Please send all notes of support/comments to the TSVWG list or the WG 
>> chairs by the date above.
>> Best wishes,
>> David and Wes.
>> (TSVWG Co-Chairs) [Gorry is recused from this adoption decision, as 
>> he is an author of this draft.]
>> [The time period for this adoption call is longer than usual to allow 
>> for the winter holidays – may yours be joyous!]
>> Abstract
>>    This document describes a robust method for Path MTU Discovery
>>    (PMTUD) for datagram Packetization layers.  The method allows a
>>    Packetization layer (or a datagram application that uses it) to probe
>>    an network path with progressively larger packets to determine a
>>    maximum packet size.  The document describes as an extension to RFC
>>    1191 and RFC 8201, which specify ICMP-based Path MTU Discovery for
>>    IPv4 and IPv6.  This provides functionally for datagram transports
>>    that is equivalent to the Packetization layer PMTUD specification for
>>    TCP, specified in RFC4821.