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

[Greg Mirsky <[e-mail]>]

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