Re: [ippm] Fwd: New Version Notification for draft-mirsky-ippm-asymmetrical-pkts-00.txt

[Greg Mirsky <[e-mail]>]

Hi Ernesto,
thank you for your kind consideration of this draft. It is very interesting
to investigate and develop recommendations for performance measurement
using active methods in multicast networks. I'll be glad to work with you
on further developing STAMP extensions for multicast networks. Please find
my notes below under the GIM>> tag.

Regards,
Greg

On Tue, Jun 27, 2023 at 6:26 AM Ernesto Ruffini <[e-mail]> wrote:

> Hi Greg and Tianran,
>
>
>
> I think this is a very useful extension: it is good to have a two-way
> measuring protocol, so results are available without administrative
> overhead, but sometimes just one way is interesting.
>
> One example is multicast, where the return path (typically the uplink)
> could be less interesting to measure.
>
GIM>> Great observation!

> So it is nice to have the possibility to set the return packet as short as
> possible.
>
> Yet, if all the members of a multicast group, potentially millions,
> simultaneously reflect a packet, even if it is a small one, they can cause
> network congestion, which is not a desired outcome for a measuring protocol.
>
> The idea is not to add administrative and configuration burden: a filter
> on the Session-Reflector MAC Address.
>
> The Session-Sender sends a bitmask and an expected result. The
> Session-Reflector applies the bitmask to its interface MAC Address (the
> received packet's destination MAC Address), and if the result does not
> match the expected result, the Session-Reflector MUST NOT send a reflected
> packet.
>
GIM>> I think that the mechanism you describe is an interesting option that
seems in line with the network programming paradigm. Of course, some may
use administrative control of STAMP to selectively enable/disable test
packet reflection on a node. But the proposed approach to selectively
control the packet reflection is a useful option, in my opinion.

> In this way, a sender can decide to partition its clients into as many
> different groups as it wants, making it possible to measure all multicast
> groups, from the most crowded to the least used.
>
> I would like to hear your feedback on this.
>
> Thanks
>
>                Ernesto
>
>
>
>    Address Group sub-TLV:  A 16-octet sub-TLV that includes the
>
>       EUI-48 Address Group Mask and EUI-48 Address Group.  The Type
>
>       value is TBD.  The value of the Length field MUST be equal to 12.
>
>
>
>        0                   1                   2                   3
>
>        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>       |                     EUI-48 Address Group Mask                 |
>
>       +                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>       |                               |                               |
>
>       |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|                               |
>
>       |                       EUI-48 Address Group                    |
>
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>
>
>       The Value field consists of the following fields:
>
>
>
>       EUI-48 Address Group Mask:  A six-octet field that represents the
>
>          bitmask to be applied to the Session-Reflector MAC Address.
>
>
>
>       EUI-48 Address Group:  A six-octet field that represents the
>
>          group this TLV is addressed to.  If the Session-Reflector
>
>          applies EUI-48 Address Group Mask to its MAC Address and the
>
>          result is different from EUI-48 Address Group, then the
>
>          Session-Reflector MUST NOT send a reflected packet.
>
GIM>> Thank you for sharing your ideas. I think that the interpretation of
the EUI-48 Address Group can be slightly modified:

OLD TEXT:

... then the Session-Reflector MUST NOT send a reflected packet.

NEW TEXT:

... then the Session-Reflector MUST stop processing the received STAMP test
packet.

I think that the new sub-TLV can be present in Reflected Test Packet
Control TLV if the value of Number of the Reflected Packets is set to zero.
As a result, all STAMP-capable nodes that receive such test packets will
not send the reflected packet to the Session-Sender but still measure
one-way packet delay and detect packet loss even if an operator desires to
limit the scope of one-way measurements to reduce the use of internal
resources. WDYT?

>
>
>
>
>
>
>
> *From:* ippm <[e-mail]> *On Behalf Of *Tianran Zhou
> *Sent:* Tuesday, June 27, 2023 08:09
> *To:* Greg Mirsky <[e-mail]>
> *Cc:* IETF IPPM WG <[e-mail]>
> *Subject:* Re: [ippm] Fwd: New Version Notification for
> draft-mirsky-ippm-asymmetrical-pkts-00.txt
>
>
>
> Hi Greg,
>
>
>
> Please see inline.
>
>
>
> Tianran
>
>
>
> *From:* Greg Mirsky [mailto:[e-mail]]
> *Sent:* Tuesday, June 27, 2023 10:07 AM
> *To:* Tianran Zhou <[e-mail]>
> *Cc:* IETF IPPM WG <[e-mail]>
> *Subject:* Re: [ippm] Fwd: New Version Notification for
> draft-mirsky-ippm-asymmetrical-pkts-00.txt
>
>
>
> Hi Tianran,
>
> thank you for your questions. Please find my notes below tagged by GIM>>.
>
>
>
> Regards,
>
> Greg
>
>
>
> On Mon, Jun 26, 2023 at 5:57 PM Tianran Zhou <[e-mail]>
> wrote:
>
> Hi Greg,
>
>
>
> STAMP is to standardize TWAMP light.
>
> GIM>> I cannot find that being stated in RFC 8762
> <https://datatracker.ietf.org/doc/rfc8762/>. STAMP was designed to
> interwork with systems that support TWAMP Light in unauthenticated mode.
> That, in the view of the authors, should ease the deployment of STAMP as
> there are already many operators that use TWAMP Light in the
> unauthenticated mode in their networks. But STAMP, in my opinion, has many
> other benefits that go beyond that interworking capability. And that is its
> extensibility that has been demonstrated in RFC 8972
> <https://datatracker.ietf.org/doc/rfc8972/>, draft-ietf-ippm-stamp-srpm
> <https://datatracker.ietf.org/doc/draft-ietf-ippm-stamp-srpm/>, and
> draft-ietf-ippm-stamp-on-lag
> <https://datatracker.ietf.org/doc/draft-ietf-ippm-stamp-on-lag/> (that
> you and I have worked together)
>
>
>
> ZTR> It’s not much relevant STAMP is TWAMP light or not. What I mean is
> that STAMP is like TWAMP light, should eliminate control plane, IMHO.
>
> If you want to extend the control msg, why not to use TWAMP?
>
> GIM>> I've worked on several TWAMP extensions and learned that that is not
> an easy task. I've used the lesson learned when working with other authors
> on defining the extension mechanism for STAMP. Also, if I remember
> correctly, the IPPM WG discussed future extensions of active measurement
> protocols and, as I recall it, has reached the conclusion to encourage new
> proposals based on STAMP.
>
>
>
> ZTR> I think for STAMP, the right way is to augment the STAMP YANG model
> for this feature. I do not think STAMP defines the control plane.
>
>
>
> Best,
>
> Tianran
>
>
>
> *From:* ippm [mailto:[e-mail]] *On Behalf Of *Greg Mirsky
> *Sent:* Tuesday, June 27, 2023 4:26 AM
> *To:* IETF IPPM WG <[e-mail]>
> *Subject:* [ippm] Fwd: New Version Notification for
> draft-mirsky-ippm-asymmetrical-pkts-00.txt
>
>
>
> Dear All,
>
> a new draft describes an extension of STAMP, Reflected Test Packet Control
> TLV, that adds some interesting behaviors, including the ability for a
> Session-Sender to control test packet reflection by the Session-Reflector.
> Among the controllable parameters are the length of the reflected packet,
> the number of reflected packets transmitted in response to the received
> STAMP test packet, and the time interval between those reflected packets.
> One of the behaviors that can be achieved by using Reflected Test Packet
> Control TLV is selective suppression of Session-Reflector transmitting a
> reflected packet.
>
>
>
> I greatly appreciate your comments, questions, and suggestions, and I
> welcome cooperation.
>
>
>
> Regards,
>
> Greg
>
> ---------- Forwarded message ---------
> From: <[e-mail]>
> Date: Mon, Jun 26, 2023 at 1:14 PM
> Subject: New Version Notification for
> draft-mirsky-ippm-asymmetrical-pkts-00.txt
> To: Greg Mirsky <[e-mail]>
>
>
>
>
> A new version of I-D, draft-mirsky-ippm-asymmetrical-pkts-00.txt
> has been successfully submitted by Greg Mirsky and posted to the
> IETF repository.
>
> Name:           draft-mirsky-ippm-asymmetrical-pkts
> Revision:       00
> Title:          Performance Measurement with Asymmetrical Packets in STAMP
> Document date:  2023-06-26
> Group:          Individual Submission
> Pages:          6
> URL:
> https://www.ietf.org/archive/id/draft-mirsky-ippm-asymmetrical-pkts-00.txt
> Status:
> https://datatracker.ietf.org/doc/draft-mirsky-ippm-asymmetrical-pkts/
> Html:
> https://www.ietf.org/archive/id/draft-mirsky-ippm-asymmetrical-pkts-00.html
> Htmlized:
> https://datatracker.ietf.org/doc/html/draft-mirsky-ippm-asymmetrical-pkts
>
>
> Abstract:
>    This document describes an optional extension to a Simple Two-way
>    Active Measurement Protocol (STAMP) that enables the use of STAMP
>    test and reflected packets of variable length during a single STAMP
>    test session.  In some use cases, the use of asymmetrical test
>    packets allow for the creation of more realistic flows of test
>    packets and, thus, a closer approximation between active performance
>    measurements and conditions experienced by the monitored application.
>
>
>
>
> The IETF Secretariat
>
>