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

[Gonzalo Camarillo <[e-mail]>]

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]
> ----------------------------------------------------------------------
>