Re: [tram] A few comments on draft-ietf-tram-stun-pmtud-17.txt

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

Hi,

I took over the primary co-editor role on that draft, so updates and discussions should be more timely from now on.

This email responds to both Gorry and Magnus comments, and the response mirrors the modifications made in draft-ietf-tram-stun-pmtud-20, published just before this email.

Let me know if you have any more comments, and how we can make progress on this draft.

Thanks.

On 9/22/20 4:41 AM, Magnus Westerlund wrote:
> Hi,
> 
> 
> Great to see progress on this. I think this is clearly a step in the right
> direction. However, I think there are a couple of integration points that needs
> a bit more clarification.
> 
> On Mon, 2020-09-14 at 18:04 +0100, Gorry Fairhurst wrote:
>> Thanks for this new revision! It indeed answers many of the issues that
>> were identified.
>>
>> I do still see a few things left that the WG should decide upon, and
>> hope this helps:
>> ---
>> The text says this:"A client MUST NOT send a probe if it does not have
>> knowledge that the server supports this specification.  This is done
>> either by external signalling or by a mechanism specific to the UDP
>> protocol to which PMTUD capabilities are added or by one of the
>> mechanisms specified in Section 5."
>> - This looks like a strong requirement without saying why this is a
>> "MUST NOT".
>> - I don't actually understand how this is determined in this spec and
>> how this can be extened to other protocols.
> 
> Isn't this as case of SHOULD NOT send, and the probing will fail if there are no
> responses per the RFC 8899 process? Likely this can quite simply be connected so
> that there are handling when the signalling has failed to correctly handle this.

My concern with SHOULD NOT is that implementers understand it as MAY, and  so there will be no longer any difference between "that server does not support that protocol" and "that server supports that protocol but the STUN packets are somehow blocked".  Worse case the client can be blocklisted for being a bad netizen.

I changed the text to:

"To be able to determine the reason STUN messages may be blocked, a
   client MUST NOT send a probe if it does not have knowledge that the
   server supports this specification."

> 
>> ---
>> In section 7:
>> This section has added a section that is a cross-reference to sections
>> in DPLPMTUD. This does seem like a useful addition (and appropriate).
>> Currently this doesn’t really seem to me to have enough detail 
to
>> clearly see how the two sets of text relate, one might have to read both
>> to figure out the details, and if that’s the case, maybe it could be
>> helpful tp be explained up front in the intriduction?

Added this at the end of the paragraph:

"                        [...] The text in this section must
   be compared side-by-side with [RFC8899] to understand the
   relationship between the two."


>> ---
>> DPLPMTUD contains guidance on flow control and congestion control. This
>> doesn’t describe the implications of probing on flow control control.
>> I’m not sure the current text is enough: 8. Probing and flow control:
>> This requirement is out of scope and is not discussed in this document.
>> - Do probe packets count as credit to an upper layer protocol using this
>> method?  Here are there options: One could be to explain how this is
>> done, the easiest mighht be to explain the usage in STUN does not
>> require this, or the third: defer to DPLPMTUD saying this applies.
> 
> So to my understanding the STUN probing traffic will be rate controlled.
> However, to what rate is not that clear. I don't know if the interaction between
> the RFC 8899 state machine and process and this mechanism to judge how that
> bounds the prob transmission. My impression would be that for simple probing
> mechanism RFC 8899 search will trigger the transmission of partiular probe size,
> and retry it Rc times if response is not arriving timely. These retransmission
> would be controlled by the RTO in STUN. While probing for an additional 
size
> would be governed by RFC 8899 search requesting probing of a new size. Which I
> don't find any given limit to. But, it will not result in more than one 
packet
> per RTT unless actual path RTT > RTO (500 ms).

I think that is up to each implementation of this draft to decide what kind of rate control they want to impose, much like ICE did when reusing the STUN Binding usage.  I added this as a new paragraph at the end of 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."

and this at the end of 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."

> 
> 
> 
>> ---
>> “9.  Shared PLPMTU state: This requirement is out of scope and 
is not
>> discussed in this document.”
>> - Why is 9. out of scope? ... what does the method do with the (PL)PMTU
>> value that it discovers? How is this made available to a user of the
>> method and is the method cached in way?
>>
>> - How does the method relate to the cached value of PMTUD at the sender,
>> if that is already running on a platform, doesn't this new method mean
>> than the PMTU cache and PTB-updates have to be over-ridden, as is the
>> case when using DPLPMTUD with other protocol stacks?
>>
>> - Also is it that the discovered (PL)PMTU value can never be cached by
>> another usage of STUN? (I may have misunderstood)

This bullet text replaced with:

"9.  Shared PLPMTU state: An implementation follows the same
       guidelines to share state than in [RFC8899]."

>>
>> ---
>> Section 7.  Rev-18 also introduces quite a few typos - but I assume a
>> spelling checker will find and help correct these.
>> ---

Done.

>>
>> That leaves Section 5:
>>
>> I still don’t yet see changes in this version to section 5:
>>
>>    
“The PMTUD mechanism described in this document is 
intended to be used
>>      by any UDP-based protocols that do not have built-in PMTUD
>>      capabilities, irrespective of whether those UDP-based protocols are
>>      STUN-based or not. "
>> - Please see comments made in the previous last call, about this ID not
>> defining this for other UDP-based protocols. At the moment it still says
>> this ID applies to other uses of UDP (which I did not see explained, nor
>> do I think this is needed). To me, much of the spec proposed seems to me
>> to rely upon the STUN multiplexing to sepearate the probe packets from
>> data, to receive feedback and to introduce padding.
>> - Please discuss the expected scope of the spec with your WG AD, and
>> suggest how to best take section 5 forward.
>>
> 
> On this issues, my view is that this document tries to oversell its capability.
> The probe method can be combined with UDP based protocols that can be
> multiplexed with STUN on the same port. The considerations that went into RFC
> 7983 does need to be considered here in relation to if one can deploy this type
> of probing messages. So I think you need to make this applicability clearer.
> 

STUN was designed to be multiplexed with other protocols on the same port.  Section 7 of RFC 8489 introduces the FINGERPRINT attribute, which is
to be used when the probability of misidentifying a packet is not low enough.  So, for all intents and purpose, the mechanisms described in our draft should work with any UDP protocol -- after all this is the exact reason why we chose STUN for this work.

The issues with RFC 7983 applies only if the FINGERPRINT attribute is not
used (which, when RFC 7983 is used with ICE, is present, see RFC 8445 section 7.2.4).

So I added this paragraph at the end of section 4:

"The FINGERPRINT mechanism described in section 7 of [RFC8489] MUST be
   used for both probing mechanisms."

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