Subject: Re: [tram] I-D Action: draft-ietf-tram-stun-pmtud-20.txt

From: Magnus Westerlund <[email-masked]>
Date: Wed, 14 Jul 2021 15:08:20 +0000

Hi,

I have reviewed -20 and have the following feedback. 

Some of the issues have been resolved. However, my individual conclusion is
that this document would be shorter, have fewer issues if only the simple
probing was retained and defined as a RFC 8899 PL solution for UDP based
application protocols that wants DPLPMTUD and not use protocol internal
methods. This could shorten section 4 significantly. I think the alternative
is to simply declare the document dead. 

However, I would take a look at the examples of RFC 8899 PL definitions that
exists in RFC 8899, RFC9000 (QUIC) and for UDP Options
(https://datatracker.ietf.org/doc/draft-fairhurst-tsvwg-udp-options-dplpmtud
/) and rewrite Section 4 based on that and only keep the simple method. Then
rewrite intro to adjust it as RFC 8899 based, and also clarify the STUN
server on the port for the whole session aspect and the demultiplexing need.
Then section 7 also can be deleted. It would be good to have a clearer rate
limiting specification for the probe packets in section 4, as the STUN
retransmission timer gives exponential back-off, and the ICE is not really
applicable here. The probe sending implementation will have a RTT estimate
when some response has been received. Based on that one can limit the probes
to be sent only every n*RTT, possible with a MAX(n*RTT, Minimal_Interval). 

The main reason I write this is that I think RFC 8899 have resolved some
corner cases that could cause issues in a naïve implementation that think
that just getting the probe through means that one should immediately update
the MTU. And as RFC 8899 is improved this usage could also get that
improvement without a need for update. 

In addition as can be seen there are some unclarities that I think makes
implementation challenging from the current spec. 

Section 1:

   The Packetization Layer Path MTU Discovery (PMTUD) specification
   [RFC4821] describes a method to discover the Path MTU, but does not
   describe a practical protocol to do so with UDP.  Many application
   layer protocols based on the transport layer protocol UDP do not
   implement the Path MTU discovery mechanism described in [RFC4821].

Wouldn't it be better do rewrite this in relation to RFC 8899? Which doesn't
have a PL definition for UDP, and the only "competing" proposal is based on
UDP Options which have no real deployment yet and requires OS level changes.

Section 1:

   These application layer protocols can make use of the probing
   mechanisms described in this document instead of designing their own
   adhoc extension.  These probing mechanisms are implemented with
   Session Traversal Utilities for NAT (STUN), but their usage is not
   limited to STUN-based protocols.

Yes, UDP based protocols that previously haven't been using STUN can use
this mechanism, but they need to be compatible and accept the multiplexing
solution that is implied. I think that could be clarified. They also needs
the STUN Server to be deployed in the peer endpoint which could be made
clearer. It is a given for any ICE supporting application, but I find no
reference to this. I would also note that ICE (RFC 8445) once it conclude
allows the peers to stop responding to STUN request, thus this method needs
to be clear that the STUN Server needs to maintained during the whole
session lifetime to enable DPLPMTUD. 

Section 1:

   Complementary techniques can be used to discover additional network
   characteristics, such as the network path (using the STUN Traceroute
   mechanism described in [I-D.martinsen-tram-stuntrace]) and bandwidth
   availability (using the mechanism described in
   [I-D.martinsen-tram-turnbandwidthprobe]).

Is this text really relevant as written. Neither of these individual
proposal have been updated since 2015. 

Section 2:

When a
   probe succeeds with a larger size than the current PMTU, the PMTU is
   increased.

There is a point to verification. If one looks at the search algorithm
behavior it updates its probe sizes, but it doesn't conclude it searching
nor update the upper layer's MTU until the search has concluded. There are
good reasons for doing it this way and thus I would suggest reformulation. 

Section 4.1:

  The Simple Probing Mechanism uses only STUN Requests/Responses, which
   are subject to the congestion control mechanism in [RFC8489] section	
   6.2.1.  The default Rc and Rm values may be defined differently for a

   combination of the Simple Probing Mechanism and the protocol running	
   on the same port.

I would not call it a congestion control mechanism, rather a retransmission
timer mechanism. Thus a rate limiting mechanism makes more sense. 

Section 4.1.1:

   The client adds a PADDING attribute with a length that, when added to
   the IP and UDP headers and the other STUN components, is equal to the
   Selected Probe Size, as defined in [RFC4821] Section 7.3.

Why referencing RFC 4821, when RFC 8899 has simpler and clearer interface
suitable for Datagram and where the simple probe is an excellent match to
just define as PL for probing. 

Section 4.1.3:

   A client receiving a Probe Response MUST process it as specified in
   section 6.3.3 of [RFC8489] and MUST ignore the PADDING attribute.  If
   a response is received this is interpreted as a Probe Success, as
   defined in [RFC4821] Section 7.6.1.

More reliance on RFC 4821 rather than RFC 8899. 

RFC 8899 is not perfect but it handles a number of corner cases that can
occur and should produce more stable, and fewer updates to the MTU than what
RFC 4821 does. 

Section 4.2:

	   The Simple Probing Mechanism uses STUN indications, which are not

 	   subject to the congestion control mechanism in [RFC8489] section

 	   6.2.1.  As it will have to be intricately related to the protocol

 	   that runs on the same port, each implementation of the Complete

	   Probing Mechanism in association MUST define the congestion
control	
 	   that will be applied to the STUN Indications.  The default Rc and
Rm	
 	   values for the STUN Requests/Responses may be defined differently
for	
 	   a combination of the Simple Probing Mechanism and the protocol

 	   running on the same port.

Once more a full blown congestion control is not really needed here. The
point is that the PMTUD probe traffic will be a small fraction of the
application traffic, alternatively such a low rate application that it is
extremely unlikely that the probe will overload any network. I would note
that RFC 8899 do specify some normative statement about this in Section 3,
Bullet 7. 

In addition this does not really give an implementor a clear answer to what
they should implement. Some basic rate limiting would be more simple to
implement. 

My high level comment is that I don't see what the benefits of the complete
method compared to running simple probes as the PL probes in the algorithm
of RFC 8899. The only potentially benefit is that one sometime will get an
indication of a burst loss across a probe when a prior or following
application protocol packet as well as the probe is lost, indicating
potentially having loss for other reasons. I think RFC 4899 probing a
multiple times gives significant high probability that congestion or random
loss of probes will rarely affect the DPLPMTUD results. 

Section 4.2.3:

   The server creates a Report Response and adds an IDENTIFIERS
   attribute that contains the chronologically ordered list of all
   identifiers received so far.  The server MUST add the FINGERPRINT
   attribute.  The server then sends the response to the client.

This doesn't discuss what a server should do if the IDENTIFIERS attribute
does not fit in the packet. 

Section 5.1:

Based on that the peer need to keep a STUN server following this spec
running on the ports being used. Isn't the need for explicit signaling more
clear. Or is the inclusion of any STUN PMTUD attribute a sufficient
indication that the peer will not remove its STUN Server when ICE concludes?

Cheers

Magnus Westerlund

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Sun, 18 Jul 2021 07:16:01 -0700

Hi Magnus,

Thank you very much for that review.

I'll work on a response and an update to the draft in the next two weeks, probably to be uploaded after the IETF meeting.

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