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

[Gonzalo Camarillo <[e-mail]>]

Hi Felipe, authors,

what is the current status of this?

Cheers,

Gonzalo

> -----Original Message-----
> From: Felipe Garrido (fegarrid) <[e-mail]>
> Sent: Wednesday, October 28, 2020 18:05
> To: Gonzalo Camarillo <[e-mail]>; Magnus
> Westerlund <[e-mail]>; [e-mail];
> [e-mail]
> Cc: [e-mail]
> Subject: Re: [tram] A few comments on draft-ietf-tram-stun-pmtud-17.txt
> 
> Hi Gonzalo,
> 
> We are finalizing the last set of changes to address some additional
> comments and will be publishing a new version of the draft shortly.
> 
> Thanks,
> -Felipe
> 
> On 10/22/20, 8:38 AM, "Gonzalo Camarillo"
> <[e-mail]> wrote:
> 
>     Authors, Magnus,
> 
>     what is the status of this?
> 
>     Cheers,
> 
>     Gonzalo
> 
>     > -----Original Message-----
>     > From: Magnus Westerlund <[e-mail]>
>     > Sent: Tuesday, September 22, 2020 14:41
>     > To: [e-mail]; [e-mail]; [e-mail]
>     > Cc: [e-mail]
>     > Subject: Re: [tram] A few comments on draft-ietf-tram-stun-pmtud-17.txt
>     >
>     > 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]
>     > ----------------------------------------------------------------------
>     >
>