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

[Ernesto Ruffini <[e-mail]>]

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.

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.

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.

 

 

 

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] <mailto:[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] <mailto:[e-mail]> ] On Behalf Of Greg Mirsky
Sent: Tuesday, June 27, 2023 4:26 AM
To: IETF IPPM WG <[e-mail] <mailto:[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] <mailto:[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] <mailto:[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