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

Marc Petit-Huguenin <petithug@acm.org> Sat, 21 March 2020 16:09 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 A5B4F3A147F; Sat, 21 Mar 2020 09:09:38 -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 0OjnzcmMaNB1; Sat, 21 Mar 2020 09:09:36 -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 2298E3A147D; Sat, 21 Mar 2020 09:09:36 -0700 (PDT)
Received: from [IPv6:2601:648:8400:8e7d:9c7a:a692:a184:fea5] (unknown [IPv6:2601:648:8400:8e7d:9c7a:a692:a184:fea5]) (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 0A5BBAE4CD; Sat, 21 Mar 2020 17:09:32 +0100 (CET)
To: Dan Wing <danwing@gmail.com>
Cc: Magnus Westerlund <magnus.westerlund=40ericsson.com@dmarc.ietf.org>, "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>
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: <55b50d50-472a-ab1b-4b71-3801d84ab23e@acm.org>
Date: Sat, 21 Mar 2020 09:09:30 -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: <0835E458-538D-4713-9238-7F2A241FAE1C@gmail.com>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="812eE0P0VgziHMdfuD5q8he34QEPsmcC0"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tram/E2YF9EXoIEG2-ugiBsdZuOKoLt4>
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: Sat, 21 Mar 2020 16:09:39 -0000

Thanks Dan.

During that review I looked a little bit at the literature out there on Path MTU discovery, and I could not find much.  That made me think that perhaps it would be useful to design a small STUN Usage that could reuse or even be collocated with TURN servers and that would act as the server part of stun-pmtud, for the purpose of testing various algorithms on real networks.  Here's a sketch on how that would work:

1. We reuse the Allocate/Permission from TURN, adding a new Attribute that, instead of requesting a port for relaying, requests a port for PLPMTUD testing.  The XOR-MAPPED-ADDRESS returned is used to set the permission on the allocated port, so we drop any packets coming from somewhere else.

2. On the allocated port we run an instance of the server side of the complete probing mechanism from stun-pmtud.  That means that we store the sequence numbers found in all UDP packets received, including probes, in a list.  When we receive a Report Request, we send back that list and clear it.

3. On the client side we first do the allocation dance, including authentication, then we request permission for the mapped IP address received in the Allocate response.  We then send UDP packets with sequence numbers to the relayed address and port, interspersed with probes packets (according to the algorithm under test).  Periodically and, again, according to the algorithm under test, the client retrieves the list of packets received for processing.

As the algorithms are all implemented on the client side, that would permit to test a fair number of algorithms and validate or invalidate some of the assumptions in RFC 4821 and tsvwg-datagram-plpmtud.

Thoughts?

On 3/20/20 4:57 PM, Dan Wing wrote:
> 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.
> 
> -d
> 
> 
>> On Mar 20, 2020, at 8:36 AM, Marc Petit-Huguenin <petithug@acm.org> 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:
>>
>> https://mailarchive.ietf.org/arch/msg/last-call/-ed9xXlcZyapPNZpUV7ShWtN0K8/
>>
>>
>> On 3/20/20 3:19 AM, Magnus Westerlund wrote:
>>> TRAM WG,
>>>
>>> draft-ietf-tram-stun-pmtud (
>>> https://datatracker.ietf.org/doc/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 (https://datatracker.ietf.org/doc/draft-ietf-tsvwg-datagram-plpmtud/).This 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 
>>> TSV AD
>>>
>>>
>>>
>>


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