Re: [tram] The way forward for draft-ietf-tram-stun-pmtud

Dan Wing <> Fri, 20 March 2020 23:57 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A125B3A0F96; Fri, 20 Mar 2020 16:57:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id X5RD9GlFhJrB; Fri, 20 Mar 2020 16:57:18 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::42c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6F1953A0F9A; Fri, 20 Mar 2020 16:57:18 -0700 (PDT)
Received: by with SMTP id l184so4111757pfl.7; Fri, 20 Mar 2020 16:57:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=QZ7wqQ5GeWk3ZGck/efrXcXNl1kw86CUQQG+vLyAURg=; b=d7fk1584DCb3Trh3q+Ruoq/GmjC+MjZnM7xr++agz/xgvt4Sc11GmgE/hJ7zUmdWge dGwOM6F43hE/WAiec9CrJ4Sst4qkdP1N+bD8LETspOePgXEri7y8QGgEmVL9KF7osMC4 4TaCarnEFVSFOOFFWIClwqAO7BwX7vJS2oEvfjeOcZjQCmeFZrHhofqAO+j5TH5NzvUf dGLwQTt1YXkNzrmKG8e76Ao+Q2iOuGU9DEoe+7ZA1xwy++cQz5MT7DM2d3P/poPRW/cm F8ekRv8LO66U9Qu1tHzQwAgtfw5SfqCDzX5+1HUPDhOqyQuet7JmhYtaJfhxulQVAQPr skbg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=QZ7wqQ5GeWk3ZGck/efrXcXNl1kw86CUQQG+vLyAURg=; b=mvNeogHPrZBIQEWchT+H32zOr5NV8gAULOwL+8RkbnLYIswLkucmZZqHUW/geYWSZB fbzti9v6GRHKYuZwOQtd78gNFBbc+czyvskZ6VBCbNL/bxkExslmmqeMqcbCCFTAAKdl JxVwV3lwsuNbiZp+uaRZF7IaOrQZFlbGdNSGhcoBI6p9HKj967126Brb6yKIhT/VYHfO 7ywfhQdnkafwhlsUNiL3a25ZEmekYeHlg74fIBnjXRaAJr4iIR6OXMgKZDON9B55obE3 mHlM3RKER9JHZLX9YSTCO2ns7JMcZeUm3oudzVETh3QrFovaoGKVRM825H/cYiyvPWxn dRLQ==
X-Gm-Message-State: ANhLgQ3y3cK2sxydD3IsByBmzHKLEube8qsLDbxjyQud1iWjMoRmoxij /b2ejruF5DgdsghKmBTYUYHxK08S
X-Google-Smtp-Source: =?utf-8?q?ADFU+vuEFdd6J1ePu3OqMhNIVz37iKTlfDEoCcWBt8yj?= =?utf-8?q?rgM2J0GhE5et1fTE7CNcYuagrWDga1tC5g=3D=3D?=
X-Received: by 2002:a63:d003:: with SMTP id z3mr10663723pgf.448.1584748637705; Fri, 20 Mar 2020 16:57:17 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id ep7sm5636453pjb.24.2020. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 20 Mar 2020 16:57:16 -0700 (PDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.\))
From: Dan Wing <>
In-Reply-To: <>
Date: Fri, 20 Mar 2020 16:57:14 -0700
Cc: Magnus Westerlund <>, "" <>, "" <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <>
To: Marc Petit-Huguenin <>
X-Mailer: Apple Mail (2.3608.
Archived-At: <>
Subject: Re: [tram] The way forward for draft-ietf-tram-stun-pmtud
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 20 Mar 2020 23:57:22 -0000

Excellent review, Marc.

An "mtr"-like implementation would be illegal per tsvwg-datagram-plpmtud.  When I was at Cisco I spec'd something that worked like 'mtr' to find biggest MTU, based on your earlier STUN PLPMTUD, which was aggressive like 'mtr' -- not simplistic like 'traceroute'.  The justification we used for being aggressive is we were same aggressiveness as the RTP stream, once it started.  So the bandwidth was already present on the network, the only difference was the ICMPs being generated along the path, and we were gentle to not use the same TTL in succession (to avoid hitting each router's rate limits or saturate their CPUs).  I don't know if this turned into an implemented feature in a product, though.

But I have to say I like 'mtr' all the time, and an mtr-like tool to find where large packets are dropped would be useful.  Nobody much has time for traceroute even with -w 1 and -q 1.


> On Mar 20, 2020, at 8:36 AM, Marc Petit-Huguenin <> wrote:
> As one of the authors of stun-pmtud, I agreed that from now on it should be based on tsvwg-datagram-plpmtud and we are working on the edits for that.
> That said I do not think that tsvwg-datagram-plpmtud itself is in a place where it can be blindly used as the basis for stun-pmtud.  My review is available there:
> On 3/20/20 3:19 AM, Magnus Westerlund wrote:
>> draft-ietf-tram-stun-pmtud (
>> has take a lot of
>> time in trying to resolve the IESG comments from the IESG evaluation that
>> occurred in September 2018. 
>> Due to the slow progress I took over the document from Spencer Dawkins as
>> responsible AD and I did my own AD evaluation of it when there was progress in
>> December. One aspect I wasn't particular happy with was it loose relationship to
>> any specification on how one uses the defined probing to actually determine the
>> working path MTU. In the meantime TSVWG has also made progress on its
>> specification for how to perform PATH MTU discovery for datagram pacektization
>> layers ( document is ready for IESG evaluation. 
>> After discussion with the authors I strongly believe the right way forward for
>> the STUN PMTUD document is to define itself as a packetization layer using the
>> TSVWG defined algorithm. On the high level this appears fairly straight forward
>> and primarily requires clarification on how the drafts current mechanism are
>> used for probing, and detection of black holes, etc. Due to the nature of this
>> method of performing probing the requirements and interaction with the
>> application UDP protocol may need a bit further clarification. I also thing the
>> WG need to consider if all the different implementation options should remain or
>> some simplification is need. 
>> Due to the changes in the document the above will result in I will send the
>> document back to the WG. I don't see this as resulting in any significant
>> additional steps as there would still be need for determining WG and IETF
>> consensus to these changes prior to a new IESG evaluation that anyway would be
>> needed due to the turn over of IESG members.
>> Cheers
>> Magnus Westerlund 
> -- 
> Marc Petit-Huguenin
> Email:
> Blog:
> Profile:
> _______________________________________________
> tram mailing list