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

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

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.

On 7/14/21 8:08 AM, Magnus Westerlund wrote:
> 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
> 


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