Re: [ippm] AD review of draft-ietf-ippm-stamp

[Rakesh Gandhi <[e-mail]>]

Thanks Henrik. Where does this requirement come from? Also, how do I
configure the UDP port outside the range using the TWAMP Yang model?

Thanks,
Rakesh

On Tue, Aug 6, 2019 at 11:19 AM Henrik Nydell <[e-mail]> wrote:

> There is a distinction between "must be able to send to these destination
> ports" and "must only be able to send to these destination ports"
>
> The first wording does not prohibit senders to be able to send also to
> other destination ports.
>
>
> On Tue, Aug 6, 2019 at 4:57 PM Rakesh Gandhi <[e-mail]>
> wrote:
>
>> Hi Greg,
>>
>> Many thanks for the reply.
>>
>> As there are already implementations out there where such restrictions do
>> not exist as discussed in another email thread (just forwarded them), the
>> following text with MUST is already violated. The TWAMP Yang model
>> draft-ietf-ippm-twamp-yang
>> <https://tools.ietf.org/html/draft-ietf-ippm-twamp-yang-13> should also
>> not place such restriction.
>>
>> Section 4.4
>>
>>        Thus STAMP Session-Sender MUST be able to send test
>>
>>        packets to destination UDP port number from the Dynamic and/or
>>
>>        Private Ports range 49152-65535, test management system should
>> find a
>>
>>        port number that both devices can use.
>>
>> Thanks,
>> Rakesh
>>
>> On Sat, Aug 3, 2019 at 1:05 PM Greg Mirsky <[e-mail]> wrote:
>>
>>> Hi Rakesh,
>>> my apologies for the misspelling of your name.
>>> Thank you for your kind consideration of the proposed update.
>>> Regarding the definition of the range of the valid UDP port numbers,
>>> draft-ietf-ippm-twamp-yang
>>> <https://tools.ietf.org/html/draft-ietf-ippm-twamp-yang-13> uses type
>>> dynamic-port-number as follows:
>>>      typedef dynamic-port-number {
>>>        type inet:port-number {
>>>          range 49152..65535;
>>>        }
>>>        description "Dynamic range for port numbers.";
>>>      }
>>> to specify the valid range for a sender-udp-port. The range for a UDP
>>> port number of a Session-Reflector has been specified slightly differently
>>> because it includes the well-known port 862:
>>>            leaf reflector-udp-port {
>>>              type inet:port-number {
>>>                range "862 | 49152..65535";
>>>                }
>>>              description
>>>                "The destination UDP port number used in the
>>>                 TWAMP-Test (UDP) test packets belonging to this
>>>                 test session.";
>>>            }
>>> But, as we observe, in both cases definitions include the
>>> Dynamic/Private range explicitly defined. I think that keeping STAMP
>>> specification consistent with the TWAMP, TWAMP YANG data model in
>>> particular, in the way the valid range of UDP ports is being specified, is
>>> beneficial to the STAMP document. Hope you'll agree.
>>>
>>> Regards,
>>> Greg
>>>
>>> On Fri, Aug 2, 2019 at 10:53 AM Rakesh Gandhi <[e-mail]>
>>> wrote:
>>>
>>>> Thanks Greg for considering my review comments. Good to see the
>>>> message format aligned with draft-ietf-ippm-stamp-option-tlv and using MBZ
>>>> 30. This should fix the interoperability issue between the two. This also
>>>> gives few (3) bytes for any future extensions.
>>>>
>>>> ------------------------------------------------------------------------
>>>>
>>>> You may fix the spelling of my name and another typo below:
>>>>
>>>> OLD:
>>>>
>>>> and Rakesh Gandi or their
>>>>
>>>>
>>>>
>>>> NEW:
>>>>
>>>> and Rakesh Gandhi for their
>>>>
>>>> ----------------------------------------------------------------------
>>>>
>>>>
>>>>
>>>> I did not see following comment addressed. Is that intentional?
>>>>
>>>> ------------------------------------------------
>>>>
>>>> On Tue, Jul 9, 2019 at 9:11 AM Rakesh Gandhi <[e-mail]>
>>>> wrote:
>>>>
>>>>
>>>>
>>>>     Thanks Greg for the reply.
>>>>
>>>>
>>>>
>>>>     In this case, should the draft just state that the Session-Sender
>>>> can select destination UDP port number following the guidelines specified
>>>> in [RFC6335], instead of specifying following?
>>>>
>>>>
>>>>
>>>> Section 4.4
>>>>
>>>>     Thus STAMP Session-Sender MUST be able to send test
>>>>
>>>>        packets to destination UDP port number from the Dynamic and/or
>>>>
>>>>        Private Ports range 49152-65535, test management system should
>>>> find a
>>>>
>>>>        port number that both devices can use.
>>>>
>>>> ----------------------------------------------
>>>>
>>>>
>>>> Thanks,
>>>> Rakesh
>>>>
>>>>
>>>> On Fri, Aug 2, 2019 at 1:00 PM Greg Mirsky <[e-mail]>
>>>> wrote:
>>>>
>>>>> Hi Rakesh,
>>>>> thank you for your helpful comments. We've updated the format of the
>>>>> base STAMP test packet. Appreciate your feedback on the proposed changes,
>>>>> comments and questions,
>>>>>
>>>>> Regards,
>>>>> Greg
>>>>>
>>>>> On Tue, Jul 9, 2019 at 9:27 AM Rakesh Gandhi <[e-mail]>
>>>>> wrote:
>>>>>
>>>>>> Hi Greg,
>>>>>> Regarding the size of the padding, yes, it's good to use the same
>>>>>> size payload for query and response.
>>>>>> However, the STAMP payload with TLV extension
>>>>>> (draft-mirsky-ippm-stamp-option-tlv-01) has slightly different padding size
>>>>>> (27 ( or > 29) vs. 30). Is there a way to make them compatible? Does it
>>>>>> mean that for STAMP with TLV, Server Octets is set to 1, but it says MBZ 0
>>>>>> for all 30 bytes. If the responder supports Server Octets and see the size
>>>>>> > 27, it may find the Server Octet size of 0 confusing?
>>>>>>
>>>>>> Thanks,
>>>>>> Rakesh
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Mon, Jul 8, 2019 at 7:20 PM Greg Mirsky <[e-mail]>
>>>>>> wrote:
>>>>>>
>>>>>>> Hi Shahram,
>>>>>>> thank you for the review and questions. Please find my answers below
>>>>>>> tagged GIM>>.
>>>>>>>
>>>>>>> Regards,
>>>>>>> Greg
>>>>>>>
>>>>>>> On Mon, Jul 8, 2019 at 2:02 PM Shahram Davari <
>>>>>>> [e-mail]> wrote:
>>>>>>>
>>>>>>>> HI Greg
>>>>>>>>
>>>>>>>> I read your draft and have the following questions:
>>>>>>>>
>>>>>>>> 1) Does it require any UDP/TCP port number or it reuses the one
>>>>>>>> from TWAMP? if it reuses from TWAMP then  how does the receiver
>>>>>>>> differentiate between TWAMP and STAMP?
>>>>>>>>
>>>>>>> GIM>> STAMP uses the well-known UDP port number allocated for the
>>>>>>> OWAMP-Test/TWAMP-Test Receiver port (RFC 8545) as the default destination
>>>>>>> UDP port number.. STAMP may use destination UDP port number from the
>>>>>>> Dynamic and/or Private Ports range 49152-65535.
>>>>>>>
>>>>>>>> 2) What is the benefit of STAMO compared to TWAMP?
>>>>>>>>
>>>>>>> GIM>> The work was driven by several observations, among them:
>>>>>>>
>>>>>>>    - challenges in achieving interoperability among implementations
>>>>>>>    of TWAMP-Light;
>>>>>>>    - industry interest in standardizing performance monitoring in
>>>>>>>    IP broadband access networks (TR-390);
>>>>>>>    - improve extensibility of IP performance monitoring tool to
>>>>>>>    support measurements, testing of new metrics and parameters, e.g.,
>>>>>>>    consistency of CoS in the network.
>>>>>>>
>>>>>>> 3) Why is there so much MBZ byte?
>>>>>>>>
>>>>>>> GIM>> It was agreed to make the symmetrical size of STAMP test
>>>>>>> packets the default. RFC 6038 defined it for TWAMP and TR-390 requires it
>>>>>>> to be supported by TWAMP-Light implementations.
>>>>>>>
>>>>>>>>
>>>>>>>> Thx
>>>>>>>> Shahram
>>>>>>>>
>>>>>>>> On Jul 8, 2019, at 10:17 AM, Greg Mirsky <[e-mail]>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>> Hi Mirja,
>>>>>>>> thank you for the suggested text. The new paragraph now reads as:
>>>>>>>>       Load of STAMP test packets offered to a network MUST be
>>>>>>>> carefully
>>>>>>>>       estimated, and the possible impact on the existing services
>>>>>>>> MUST
>>>>>>>>       be thoroughly analyzed before launching the test session.
>>>>>>>>       [RFC8085] section 3.1.5 provides guidance on handling network
>>>>>>>> load
>>>>>>>>       for UDP-based protocol.  While the characteristic of test
>>>>>>>> traffic
>>>>>>>>       depends on the test objective, it is highly recommended to
>>>>>>>> stay in
>>>>>>>>       the limits as provided in [RFC8085].
>>>>>>>>
>>>>>>>> If it is acceptable, I'd like to upload the updated version of
>>>>>>>> draft-ieff-ippm-stamp before the cut-off deadline.
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>> Greg
>>>>>>>>
>>>>>>>> On Mon, Jul 8, 2019 at 8:58 AM Mirja Kuehlewind <
>>>>>>>> [e-mail]> wrote:
>>>>>>>>
>>>>>>>>> Hi Greg,
>>>>>>>>>
>>>>>>>>> See below.
>>>>>>>>>
>>>>>>>>> > On 8. Jul 2019, at 16:54, Greg Mirsky <[e-mail]>
>>>>>>>>> wrote:
>>>>>>>>> >
>>>>>>>>> > Hi Mirja,
>>>>>>>>> > thank you for the reference to RFC 8085. I agree that the
>>>>>>>>> document is very much relevant and a reference to RFC 8085 in STAMP is
>>>>>>>>> useful. While reading Section 3.1.3 I came to think that the discussion and
>>>>>>>>> guidance in other sections of RFC 8085, particularly, Section 3.1.5
>>>>>>>>> Implications of RTT and Loss Measurements on Congestion Control. Would
>>>>>>>>> adding the reference to that section in the new text proposed for the
>>>>>>>>> Security Considerations section work? I'll put RFC 8085 as Informational
>>>>>>>>> reference as it is BCP.
>>>>>>>>> > NEW TEXT:
>>>>>>>>> >       Load of STAMP test packets offered to a network MUST be
>>>>>>>>> carefully
>>>>>>>>> >       estimated, and the possible impact on the existing
>>>>>>>>> services MUST
>>>>>>>>> >       be thoroughly analyzed using [RFC8085] and its Section
>>>>>>>>> 3.1.5 in
>>>>>>>>> >       particular before launching the test session...
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Not sure if “using” is the right word but otherwise fine for me.
>>>>>>>>> Or you could have a separate sentence like:
>>>>>>>>>
>>>>>>>>> “RFC8085 section 3.1.5 provides guidance on handling network load
>>>>>>>>> for UDP-based protocol. While the characteristic of test traffic depends on
>>>>>>>>> the test objective, it is highly recommended to say in the limits as
>>>>>>>>> provided in RFC8085.”
>>>>>>>>>
>>>>>>>>> Or something similar…
>>>>>>>>>
>>>>>>>>> BCP is the same maturity level as PS. So it wouldn’t be a downref.
>>>>>>>>> However, I think having this as informational ref is fine.
>>>>>>>>>
>>>>>>>>> Mirja
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> >
>>>>>>>>> > Regards,
>>>>>>>>> > Greg
>>>>>>>>> >
>>>>>>>>> > On Mon, Jul 8, 2019 at 2:37 AM Mirja Kuehlewind <
>>>>>>>>> [e-mail]> wrote:
>>>>>>>>> > Hi Greg,
>>>>>>>>> >
>>>>>>>>> > Thanks a lot for you reply. Changes are good. I wonder if it
>>>>>>>>> would be useful to provide a reference to RFC8085 because it has a lot of
>>>>>>>>> information about congestion control of UDP based traffic? It recommends to
>>>>>>>>> send not more than 1 packet per 3 seconds (if RTT is unknown). I guess it
>>>>>>>>> doesn’t make sense to require this for testing traffic, however, it could
>>>>>>>>> maybe still be a good recommendation? What do you think?
>>>>>>>>> >
>>>>>>>>> > Also I’ve just resend my review to the IPPM list, as I
>>>>>>>>> unfortunately cc’ed only the IPPM chairs instead of the whole list. Can you
>>>>>>>>> resend you proposed changes to the list, so other people are aware of these
>>>>>>>>> changes. Sorry for the unconvience.
>>>>>>>>> >
>>>>>>>>> > Mirja
>>>>>>>>> >
>>>>>>>>> >
>>>>>>>>> > > On 6. Jul 2019, at 17:46, Greg Mirsky <[e-mail]>
>>>>>>>>> wrote:
>>>>>>>>> > >
>>>>>>>>> > > Hi Mirja,
>>>>>>>>> > > thank you for your thorough review, very pointed and helpful
>>>>>>>>> comments. Please find my responses in-lined and tagged GIM>>. Attached the
>>>>>>>>> diff.
>>>>>>>>> > >
>>>>>>>>> > > Regards,
>>>>>>>>> > > Greg
>>>>>>>>> > >
>>>>>>>>> > > On Thu, Jul 4, 2019 at 9:10 AM Mirja Kuehlewind <
>>>>>>>>> [e-mail]> wrote:
>>>>>>>>> > > Hi authors, hi all,
>>>>>>>>> > >
>>>>>>>>> > > Thanks for this well-written document and very good shepherd
>>>>>>>>> write-up! I would like discuss one point before I start IETF last call.
>>>>>>>>> > >
>>>>>>>>> > > I believe this document should say something about network
>>>>>>>>> load and congestion (control). OWAMP and TWAMP discuss quite a bit sender
>>>>>>>>> scheduling, however, as this is a simplified version, so I think it could
>>>>>>>>> at least be good to put a waring in this document that packet sending
>>>>>>>>> should be somehow rate limited. I know it might be hard to provide more
>>>>>>>>> concrete guidance but at least having some discussion or warning in this
>>>>>>>>> document could be good.
>>>>>>>>> > > GIM>>  Thank you for your suggestion. Security Considerations
>>>>>>>>> section points to the fact that STAMP does not include control and
>>>>>>>>> management components:
>>>>>>>>> > >    Because of the control
>>>>>>>>> > >    and management of a STAMP test being outside the scope of
>>>>>>>>> this
>>>>>>>>> > >    specification only the more general requirement is set:
>>>>>>>>> > > adding the new text here:
>>>>>>>>> > >       Load of STAMP test packets offered to a network MUST be
>>>>>>>>> carefully
>>>>>>>>> > >       estimated, and the possible impact on the existing
>>>>>>>>> services MUST
>>>>>>>>> > >       be thoroughly analyzed before launching the test session.
>>>>>>>>> > >
>>>>>>>>> > >
>>>>>>>>> > > Another comment: You only say at the very end that a certain
>>>>>>>>> UDP port is used, which implies that STAMP runs over UDP. However, I think
>>>>>>>>> you should mention at the very beginning that this is a UDP-based protocol.
>>>>>>>>> Just to make things crystal clear.
>>>>>>>>> > > GIM>> Adding the reference to "UDP transport" into the first
>>>>>>>>> sentence of Theory of  Operations section:
>>>>>>>>> > >    STAMP Session-Sender transmits test packets over UDP
>>>>>>>>> transport toward STAMP Session-Reflector.
>>>>>>>>> > >
>>>>>>>>> > > Mirja
>>>>>>>>> > >
>>>>>>>>> > > P.S.:
>>>>>>>>> > > Nit: s/This document defines active performance measurement
>>>>>>>>> test protocol/ This document defines an active performance measurement test
>>>>>>>>> protocol/
>>>>>>>>> > > -> “an” missing
>>>>>>>>> > > GIM>> Thank you. Done.
>>>>>>>>> > > <Diff_ draft-ietf-ippm-stamp-06.txt -
>>>>>>>>> draft-ietf-ippm-stamp-07...txt.html>
>>>>>>>>> >
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>> ippm mailing list
>>>>>>>> [e-mail]
>>>>>>>> https://www.ietf.org/mailman/listinfo/ippm
>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>> ippm mailing list
>>>>>>> [e-mail]
>>>>>>> https://www.ietf.org/mailman/listinfo/ippm
>>>>>>>
>>>>>>
>
> --
>
> *Henrik Nydell*
> *Sr Product Manager*
> 1.866.685.8181
> [e-mail]
> <http://accedian.com>
> <https://www.facebook.com/accedian/>  <https://twitter.com/Accedian>
> <https://www.linkedin.com/company/accedian-networks?originalSubdomain=ca>
> <http://www.accedian.com>
> *accedian.com <http://accedian.com>*
>
> Avis de confidentialité
>
> Les informations contenues dans le présent message et dans toute pièce qui
> lui est jointe sont confidentielles et peuvent être protégées par le secret
> professionnel. Ces informations sont à l’usage exclusif de son ou de ses
> destinataires. Si vous recevez ce message par erreur, veuillez s’il vous
> plait communiquer immédiatement avec l’expéditeur et en détruire tout
> exemplaire. De plus, il vous est strictement interdit de le divulguer, de
> le distribuer ou de le reproduire sans l’autorisation de l’expéditeur.
> Merci.
>
> Confidentiality notice
>
> This e-mail message and any attachment hereto contain confidential
> information which may be privileged and which is intended for the exclusive
> use of its addressee(s). If you receive this message in error, please
> inform sender immediately and destroy any copy thereof. Furthermore, any
> disclosure, distribution or copying of this message and/or any attachment
> hereto without the consent of the sender is strictly prohibited. Thank you.
>