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

[Magnus Westerlund <[e-mail]>]

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.

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



> ---
> “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)
> 
> ---
> Section 7.  Rev-18 also introduces quite a few typos - but I assume a 
> spelling checker will find and help correct these.
> ---
> 
> 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. 

Cheers

Magnus Westerlund 


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