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

From: Magnus Westerlund <[email-masked]>
Date: Fri, 20 Mar 2020 10:19:46 +0000

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

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Fri, 20 Mar 2020 08:36:45 -0700

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/

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

---

From: Dan Wing <[email-masked]>
Date: Fri, 20 Mar 2020 16:57:14 -0700

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 <[email-masked]> wrote:
> 
> _______________________________________________
> tram mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tram

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Sat, 21 Mar 2020 09:09:30 -0700

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?

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 23 Mar 2020 15:40:26 +0000

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. 

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? 

Cheers

Magnus Westerlund

On Sat, 2020-03-21 at 09:09 -0700, Marc Petit-Huguenin wrote:
> 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?
> 
> > 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
> > 
> > 
> > > 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:
> > > 
> > > 
> > > > layers (
> > > > https://datatracker.ietf.org/doc/draft-ietf-tsvwg-datagram-plpmtud/).This
> > > >  document is ready for IESG evaluation. 
> > > > 
-- 
Cheers

Magnus Westerlund 

----------------------------------------------------------------------
Networks, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Torshamnsgatan 23           | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Mon, 30 Mar 2020 05:49:03 -0700

Hi Magnus,

> 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.

> diagnostics, measurements or probing what capabilities exists prior to actual

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.