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

[Rakesh Gandhi <[e-mail]>]

Hi Greg,

Why limit the UDP port range to 49152-65535? Any free UDP port can be used,
no?

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
>