Re: [ippm] Questions on draft-morton-ippm-capacity-metric-protocol-01

Hi Al,
while evaluating the suitability of STAMP, have you considered using a new
STAMP extension to query the Session-Reflector? In RFC 8792 there are
several examples of using STAMP extension to retrieve information fro the
Session-Reflector. Do you think that could be a viable option for the IP
Maximum Capacity test?

Regards,
Greg

On Fri, Oct 22, 2021 at 4:23 PM MORTON JR., AL <acmorton@att.com> wrote:

> Hi Rüdiger,
>
> Many thanks for your review and comments!
> Please see replies below, [acm]
>
> Al
>
> > -----Original Message-----
> > From: Ruediger.Geib@telekom.de <Ruediger.Geib@telekom.de>
> > Sent: Thursday, October 21, 2021 5:54 AM
> > To: MORTON JR., AL <acmorton@att.com>
> > Cc: ippm@ietf.org
> > Subject: AW: [ippm] Questions on
> draft-morton-ippm-capacity-metric-protocol-01
> >
> > Hi Al,
> >
> > A standardized protocol to request a standardized access bandwidth
> measurement
> > is a generic requirement and I appreciate your initiative. As a person
> not
> > personally implementing software, some high level comments on the doc
> only:
> >
> > 2.  Scope, Goals, and Applicability, last sentence:
> >
> >    "The primary application of the protocol described here is the same as
> >    in Section 2 of [RFC7479] where:"
> >
> > That's a mis-quote, isn't it? You target another RFC, don't you?
> [acm]
> Yes, that's a typo it is 7497.
>
> > From numbers I guessed:
> > https://urldefense.com/v3/__https://www.rfc-
> > editor.org/rfc/rfc7497.html*section-2__;Iw!!BhdT!y6i-
> > TyjWraBDT2trFoyuIFq4w_HAiM69YBGudRqV6CYCfy0IwpDrcJsftMK9$
> [acm]
> right!
> >
> > I started with a minor issue, as it points to RFC7497. The latter RFC
> contains
> > the following statement:
> > https://urldefense.com/v3/__https://www.rfc-
> > editor.org/rfc/rfc7497.html*section-7__;Iw!!BhdT!y6i-
> > TyjWraBDT2trFoyuIFq4w_HAiM69YBGudRqV6CYCfy0IwpDrcJC4OWUG$
> > "Current IETF standardized test protocols (... [RFC5357 - TWAMP]..) do
> not
> > possess the asymmetric size generation capability with two-way testing."
> [acm]
> Right, we have a different problem with TWAMP and others, described below.
> >
> > Adding a brief section to draft-morton-ippm-capacity-metric-protocol
> > discussing why e.g. TWAMP (or a simplified version) isn't applied or
> rather
> > enhanced for the measurement protocol may be useful. If existing IETF
> IPPM
> > measurement control protocols don't offer any benefits justifying their
> > adaption for a capacity-metric-protocol, the section will be brief. If
> there's
> > pro and con, what's worth adding functionality to TWAMP and what's the
> "cost"
> > (in terms of work and changes) may be worth some words. Should inclusion
> of a
> > capacity-metric-protocol to TWAMP be worth a thought, a few words on
> required
> > features and changes (a sketch on what to add) may be useful. I'm not a
> TWAMP
> > expert, I excuse if my comment doesn't apply.
> [acm]
> No problem, I thought about this before writing this draft. It comes down
> to these four points (which I will add in the Intro):
>
>    Although there are several test protocol already available for
>    support and manage active measurements, this protocol is a major
>    departure from their operation:
>
>    1.  UDP transport is used for all setup, test activation, and control
>        messages, and for results feedback (not TCP), simplifying
>        operations.
>
>    2.  TWAMP and STAMP use the philosophy that one host is a Session-
>        Reflector, sending test packets every time they receive a test
>        packet.  This protocol supports a one-way test with periodic
>        status messages returned to the sender.
>
>    3.  OWAMP supports one-way testing with results Fetch at the end of
>        the test session.  This protocol supports a one-way test and
> requires
>        periodic status messages returned to the sender to support the
>        load adjustment search algorithm.
>
>    4.  The security features of OWAMP and TWAMP have been described as
>        "unusual", to the point that IESG approved their use while also
>        asking that these methods not be used again.  Further, the *WAMP
>        approach to security is over 15 years old at this time.
>
> I concluded that any attempt to enhance OWAMP or others would be time
> wasted. We have a unique use-case here.
>
> thanks,
> Al
>
> >
> > Regards,
> >
> > Ruediger
> >
> > -----Ursprüngliche Nachricht-----
> > Von: ippm <ippm-bounces@ietf.org> Im Auftrag von MORTON JR., AL
> > Gesendet: Mittwoch, 20. Oktober 2021 00:32
> > An: IETF IPPM WG <ippm@ietf.org>
> > Betreff: [ippm] Questions on
> draft-morton-ippm-capacity-metric-protocol-01
> >
> > Hi IPPM,
> >
> > Len Ciavattone and I am looking for some feedback on our protocol [0]
> designed
> > to help measure the Maximum IP-Layer Capacity Metric (which will be
> published
> > as an RFC shortly).
> >
> > We are asking folks to take a look at the draft, because we are fairly
> sure
> > you will have some questions!
> >
> > One area where we know more development is required is the Modes of
> operation,
> > which essentially describes how the different aspects/exchanges of the
> > protocol will be made secure. This is pretty-much a green-field in our
> > specification, so suggestions are very welcome.  Section 10 currently
> > describes the different modes that we imagined to be useful (A through F
> > below), but practical aspects of any proposed solution might indicate
> modes
> > that should be combined, split-up, or new modes.
> >
> > So, please give the draft and/or the list below a look, and let us know
> what
> > you think.
> >
> > thanks!
> > Al
> >
> >
> > [0]
> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-
> > morton-ippm-capacity-metric-protocol-01.txt__;!!BhdT!y6i-
> > TyjWraBDT2trFoyuIFq4w_HAiM69YBGudRqV6CYCfy0IwpDrcGmC1X4M$
> >
> >    3.  Client-server authentication and integrity protection for
> >        feedback messages conveying measurements is RECOMMENDED.  To
> >        accomodate different host limitations and testing circumstances,
> >        different modes of operation are recommended:
> >
> >  A. Un-authenticated mode (for all phases) AND  B. OPTIONAL
> Authenticated set-
> > up only
> > SHA-256 HMAC time-window verification (5 min time stamp verification)
> (could
> > add silent failure option)
> >
> >      -=-=-=-=-=-=-=-=-=-
> >
> >  C. Encrypted setup and test-activation
> > (currently using OpenSSL Library, so KISS, but may be too slow for test
> > packets)
> >
> >      -=-=-=-=--=- Old/low-power host performance impacts -=-=-=-=-=-=-
> >
> >  D. Encrypted feedback messages
> >
> >  E. Integrity protection for test packets SHA-256 HMAC
> >
> >  F. Encrypted test packets (maybe also valuable to defeat compression on
> > links)
> >
> > _______________________________________________
> > ippm mailing list
> > ippm@ietf.org
> >
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ippm__;!!Bhd
> > T!y6i-TyjWraBDT2trFoyuIFq4w_HAiM69YBGudRqV6CYCfy0IwpDrcPzob7Gi$
>
> _______________________________________________
> ippm mailing list
> ippm@ietf.org
> https://www.ietf.org/mailman/listinfo/ippm
>