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

[Magnus Westerlund <[e-mail]>]

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. 

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

Cheers

Magnus Westerlund 


----------------------------------------------------------------------
Networks, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  [phone]
Torshamnsgatan 23           | Mobile [phone]
SE-164 80 Stockholm, Sweden | mailto: [e-mail]
----------------------------------------------------------------------