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

[Marc Petit-Huguenin <[e-mail]>]

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: [e-mail]
Blog: https://marc.petit-huguenin.org
Profile: https://www.linkedin.com/in/petithug