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

["Gonzalo Salgueiro (gsalguei)" <[e-mail]>]

Hi Gonzalo - 

Sorry for the delay in response. We’ve been struggling to get in contact with Felipe. Give us a bit more time so we are able to get accurate latest status.

Cheers,

Gonzalo


> On Feb 9, 2021, at 8:34 AM, Gonzalo Camarillo <[e-mail]> wrote:
> 
> 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]
>>> ----------------------------------------------------------------------
>>> 
>> 
>