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

Marc Petit-Huguenin <petithug@acm.org> Wed, 01 April 2020 11:19 UTC

Return-Path: <petithug@acm.org>
X-Original-To: tram@ietfa.amsl.com
Delivered-To: tram@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B2583A0952; Wed, 1 Apr 2020 04:19:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.441
X-Spam-Level:
X-Spam-Status: No, score=-0.441 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_NONE=0.793, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no 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 gzL3ltgl-aRE; Wed, 1 Apr 2020 04:19:23 -0700 (PDT)
Received: from implementers.org (unknown [92.243.22.217]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 985A83A094B; Wed, 1 Apr 2020 04:19:23 -0700 (PDT)
Received: from [IPv6:2601:648:8400:8e7d:842b:f0ce:5d32:93a] (unknown [IPv6:2601:648:8400:8e7d:842b:f0ce:5d32:93a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "Marc Petit-Huguenin", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id 013DEAE00A; Wed, 1 Apr 2020 13:19:19 +0200 (CEST)
To: Magnus Westerlund <magnus.westerlund@ericsson.com>, "danwing@gmail.com" <danwing@gmail.com>
Cc: "draft-ietf-tram-stun-pmtud@ietf.org" <draft-ietf-tram-stun-pmtud@ietf.org>, "tram@ietf.org" <tram@ietf.org>
References: <4fe71c73687e94e7256b8b5a311dd82c65df6be0.camel@ericsson.com> <c2d6e050-814b-0051-e46a-9197378e8173@acm.org> <0835E458-538D-4713-9238-7F2A241FAE1C@gmail.com> <55b50d50-472a-ab1b-4b71-3801d84ab23e@acm.org> <bc8937165a479389a0070c2e6460aa8c6b29ae44.camel@ericsson.com> <2dac6e94-3e49-2ed3-c777-3cb3ca159d93@acm.org> <458f3f896e7f8a913aaa09ba3be63b6a71e1b3e8.camel@ericsson.com>
From: Marc Petit-Huguenin <petithug@acm.org>
Autocrypt: addr=petithug@acm.org; prefer-encrypt=mutual; keydata= mQINBE6Mh9wBEADrUEDZChteJbQtsHwZITZExr7TAqT7pniNwhBX3nFgd+FrV3lsLKJ1rym2 52MAYpubXEJZGzMp6uCCAnROWbtmQbOm8z/jHnjxHhPqfuYCYPpAQqu8K/Sc194Rp37krMwB jz32yr7+gvWLzRgQGKIh9d2mzy8QLMETVWWQWGb6fEfpOxXo0wumN1rc/275kZwOu44JIPGg zbgwZdnEqYOUUa18K9MXeRDoWbwDISP30CvKuZDwD14lbBE3o7tBQrU9uoMhE7eFlTjbsCox qoubI2tZSuOTF8mRXjPmNrRGtf9mYkQnOB7y6qy/QxmOVMq4IRtHzOYIm/EZ6NTodcpZQHOM 2v6B6YK9uKrYrapSpJzn4f9oU7alT31Y3o2hOlxAWDQ16+Dd1MOPYsKQXOwY1/ihm4PTjiJ8 ud8yPzy7c+BSVs5wkBU6QuLNIgZHrrxdn+KxM+F/oAVtfzO7XzVoeOcXyWi3/CHL5pgoBruY enIF/RrRuplpy09pvZjmFPNfqKBYJGnqpQuqsQwO7LsFqDqfY2EuHg+KsGN1XuN+jxXc48/1 gCnKw7ALSPWEb7g25wD6KfiZTAcyRTG8LePNFQKhw61LbIWmkw9EaVLyXvwPTc1iCSc0dDT/ pcT/z+8xrWOyWGZNZAjR584NlDpKollbItcxYtFcYZkvTCmOVwARAQABtCZNYXJjIFBldGl0 LUh1Z3VlbmluIDxwZXRpdGh1Z0BhY20ub3JnPokCOAQTAQgAIgIbIwYLCQgHAwIGFQgCCQoL BBYCAwECHgECF4AFAlfy11wACgkQKcRFldZqfsRWqBAAu/61DGo+j38UefTKnEse0mftPBXa S4lre7vknn33MI0L5QXmiM8zRs9FOKSuXPx0EV+JhI4pWZGW/2MJPuyifXHvnIChcdGInN8J GBdTLZSOgdDFZL9msO+QUsvMA8ZUsqlKOEcVL1NyoLupblCWNq4fYhBCx1zDwX9LZSuGn8lZ Mk8a4QFGoR6dWKaOxeCwnoquW5IK1CfRIhYjHfQMjA5gY0H46F0iCqBaFF/S7krQwIJd0XN4 YbSL4KOrWuxtgQ+iH/iaxxBXgJ1blBNRzXaWJBF4PHv23nSnEzWO17j+uVMaHJu7ycYEf8T9 pVc0xcok1BM2rCrNE5FUFAzsUtAtBZEEK6sSIeOhRG93uD/Hv1hrWzEwf+Z7B1tVQLCQQ4kL 7wyS7SXI/JTuW2xTEGCmwMeWYGERdkgsatmx4zi5nVHDjt3/mlPMj4L+u05SkI2iV4W6xxU1 jHlBIJDs7AVM0dsxzTyIPf2Sz843WyHuBgkoCskxGfOwlkZzDX9rwcWRKal1wjy1w/25LsBY U50INandw3UbrS2I73VX8ARI8uOWZrW7uzRLf8EmuPhtSQ35ThmdoNSgGMP9EXwNgzi/i+5G hbX5KbrSLG9SITFJEcJA4tnwu3nqmBh7D7vbd5ln5X7rmqPdyjidt0zcSjvuaBA+nkmakA4A O+choWy5Ag0EToyH3AEQAL+LguHhcSDCL/IevdcvH/5/fzO2fmuuTxdGwrZZSm7l6/HD2Ira h6Wpa1LvVeRbnsRq8k6O8/i3wVapEoQPmNY3vjWfXaJb8R4vHcqgcxw9N9jhZa+mvGJk9+cI ilDyPzHRBBID4d/3oFKQCQ4Y2SIkO66znPhfBOS2f2AU7AtXHhVEyj6WsLK6boEMcj7j+w5a es2nZam0jhgoz+4DQem4uk8outrRlboGnZN7A2kCNuy39UeOp7BpvQ95IKcJCIeSoiJt2A4B NPQroqhW0zGn9Y9FJ9UiZ9YIeNPYbscUxxvrD+OU9Jv67hW0v3KfvoIKDwVKpO3MW6o+1teS Gt1KCSz+CvGJCvIxfCk7S5K5SBne7ZNKz7rkGXYIzlyr7ZoEgRHmqGmcK/sHTS4e6g2pQQrR USkspyqLZl5Uzmg7yI5oGBL0aHTzYdDkkOKMRXYnl7ivBeNtGcniGqlONLJxpbwec8j7hLRq pXFuepbtPqX/GefuK8rdo+ppEqpRJ50cJTegchTfWfSjn5/mG1B4Oz9OnOcBEeTLO729n0K9 BeTx1pmisD6P/fyrqZZTozDwVEi7Wo9AOaqWOhuTe8L0FlFIk6fc/yM0wzvDWP7sNrevEYHK V9rd+Yc/Jjt293J4uayrt6DNMmSkAw3nlBq3uK5d54J0FAsAUcsE/W2/ABEBAAGJAh8EGAEI AAkCGwwFAlfy11wACgkQKcRFldZqfsSQyA/+Kx3eWtKyb/y35TjgtjT/Hrtw+aIpr1uK97LA ln1j5m7+lQ/jh0/rvSZjs+YQMYLqVGI8oaaF/u+qrokkU6pfrhVZ49D1BmmSTMBSYgnBDYqZ yZ+uzQnnDYt/mpo2OLbl9BhuifR5QXLp43cE1FIhyDT46wfse5tNZ+ll4m4HtXuTw4W3b4cP Hto10260Mki7hXbkDMZ+icBFDMkrrZyYHSnBhelzIM7XnY7A/XZdulfFcDXEcZhAFEv3ylJs xTnGwzDyP1VAdBFL3hpP1CqfP1Kti4hKcxXZYbIgTSsBjcYbPchw3ktUTU29I/nWKH5gmD+q wFizyhtt8Qhl6U67OdZ/XbRGBXs/7tlYJIGiGZyG7IQtDOX0PsVd+6WRcDdFqkpBwYkxU8gd iCeW+YTQ5d8mXXPT2dhFAeK2hCFa2+IdaXvH8ovjZpTMeKstHrWJUDaSqQ4GFT676DbDyqtm P6Ul9cjGVtXIs64FWqR9wrbwBH1GuIHhDmG9sN5AkyB9mxXaEG3uG4E6qQeedtIKC6p+ebAs aTGgztFWMJDC8LUznu7B0oyWxNVoE/RGt5mesOeAtqYr6Jtdh7unyk8BYP1y4e+SSMwvtwh+ 69tJwNhGYbOJrdX34tXNAKb6r/rFRjVJm+sPPs5ok7LddvV35o+Fho0LRNDsioDV3HytlhA=
Message-ID: <43035d40-05ce-693c-eb88-04bf1f9617b2@acm.org>
Date: Wed, 1 Apr 2020 04:19:17 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <458f3f896e7f8a913aaa09ba3be63b6a71e1b3e8.camel@ericsson.com>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="SByMSLpNkAP8Ccniu9oAAQIH12cr5RGzG"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tram/Zh1GEw8CL0EdLrjjTWkyjUyZpzk>
Subject: Re: [tram] The way forward for draft-ietf-tram-stun-pmtud
X-BeenThere: tram@ietf.org
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." <tram.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tram>, <mailto:tram-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tram/>
List-Post: <mailto:tram@ietf.org>
List-Help: <mailto:tram-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tram>, <mailto:tram-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 01 Apr 2020 11:19:25 -0000

Hi Magnus,

On 4/1/20 4:03 AM, Magnus Westerlund wrote:
> On Mon, 2020-03-30 at 05:49 -0700, Marc Petit-Huguenin wrote:
>> Hi Magnus,
>>
>> On 3/23/20 8:40 AM, Magnus Westerlund wrote:
>>> Hi Marc,
>>>
>>> Yes, you are correct that draft-ietf-tsvwg-datagram-plpmtud has a specific
>>> scope. It is targeting a single path used by the transport protocol between
>>> two
>>> peers. When you go beyond that use case the document may not give you
>>> answers.
>>> The TSVWG needs to discuss your last call comments. 
>>>
>>> If the goal of the usage is different than finding the actual working PMTU
>>> for
>>> the current packet flow then other considerations come into play. And yes,
>>> the
>>> protocol definitions in the stun-pmtud document could be used for a
>>> different
>>> purpose. I think you even can implement the tie in without really making it
>>> more
>>> complicated for another document to use the STUN-PMTUD mechanism. 
>>
>> I think that the reasonable thing to do in stun-pmtud is to consider tsvwg-
>> datagram-plpmtud as just one algorithm of what RFC 4821 permits.  We need to
>> add how stun-pmtud is answering the points in 6.1, probably in a new section
>> by itself.
> 
> I think that is fine. What I am really where asking for was to ensure that it is
> clear how one use stun-pmtud as a packetization layer for the algorithm intsvwg-datagram-plpmtud. 

That's definitively the plan we put together in our recurrent authors call last Monday.  Expect a new version of stun-pmtud soon.

> 
>>
>>>
>>> Marc, can you uplevel the below desription from mechanisms to what you see
>>> as
>>> goals with the proposal.  Soley as a tool for investigation, or as mechanism
>>> for
>>> diagnostics, measurements or probing what capabilities exists prior to
>>> actual
>>> demand for its usage? 
>>
>> That proposal is purely for collecting results on various PLPMTUD algorithms
>> for UDP protocols, to be able to make informed decisions in a future version
>> of RFC 4821.  Another questions I could not find answers to is how often does
>> a PMTU change in the network.  A tool based on that proposal would help
>> collect answers for that too.
>>
>> A tool implemented on top of that proposal would:
>>
>> - Implement the protocol in the proposal itself, to allocate a port and
>> collect reports.
>> - Implement as many PLPMTUD algorithms as possible on the client side.
>> - Implement as many UDP protocol behaviors as possible on the client side (on
>> the server side, the UDP packets are simply dropped).  By behavior, I mean how
>> regular packets are generated and sent to the other side (basically
>> establishing size and timing patterns).
>>
>> Then the client can continuously try the cartesian product of the PLPMTUD
>> algorithms and the UDP protocol patterns on a set of servers that implement
>> the protocol proposed.  With enough clients and servers we could get some hard
>> numbers on the reality of PLPMTUD.
> 
> I think this is an interesting research question that can greatly benefit future
> evolution of the IETF recommendations. However, I don't see a need for
> publication in an standards track document to document more then the basic
> building blocks. And are you actually proposing any changes to the current
> document that relates to the above? 

No, if I see some interest in that proposal (which is not the case currently) I'll write a separate draft.

Thanks.

-- 
Marc Petit-Huguenin
Email: marc@petit-huguenin.org
Blog: https://marc.petit-huguenin.org
Profile: https://www.linkedin.com/in/petithug