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

[Greg Mirsky <[e-mail]>]

Hi, Ernesto et al.,
thinking some more about the proposed sub-TLV that can be used to define a
sub-set of responding Session-Reflectors. You propose a filter based on
Layer 2 information. Do you see a benefit of adding Layer 3-based sub-TLV
with IP Prefix and Prefix Length?

Regards,
Greg

On Tue, Jun 27, 2023 at 3:10 PM Greg Mirsky <[e-mail]> wrote:

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