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

[Ernesto Ruffini <[e-mail]>]

Hi Greg,

Please find my comments inline marked with ER>>

Regards,

               Ernesto

 

 

From: Greg Mirsky <[e-mail]> 
Sent: Wednesday, June 28, 2023 02:52
To: Ernesto Ruffini <[e-mail]>
Cc: Tianran Zhou <zhoutianran=[e-mail]>; IETF IPPM WG <[e-mail]>
Subject: Re: [ippm] Fwd: New Version Notification for draft-mirsky-ippm-asymmetrical-pkts-00.txt

 

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?

 

ER>> I proposed Layer 2 with the following two use cases in mind: a random selection of reflectors, just not to generate too much traffic: masks like 0x0000000000FF; a selection of specific CPE vendors, that usually have a specific NICs: masks like 0xFFFFFF000000; of course the two could be merged. Filtering by IP could be useful for example if you have a specific IPv6 subnet dedicated to 6rd and want to test it, and I’m sure there are other better examples. So, yes: very good point.

 

Regards,

Greg

 

On Tue, Jun 27, 2023 at 3:10 PM Greg Mirsky <[e-mail] <mailto:[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] <mailto:[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?

 

ER>> I’m not sure I understood, so let me rephrase both approaches. My idea was: the Session-Reflector does all what STAMP requires it to do, so for example measure one-way metrics, but it doesn’t send an answer if it’s requested not to, either because the Reflected Packets parameter is zero, or because it is not in the right Group. You are saying that if a Session-Reflector is not in the right Group it should behave as if the packet was corrupt and ignore it. I think I like them both, no special preference: if you receive an email that “is not intended for you” (just like some add at the end of their emails), do you still read it and, if useful, learn from it? In this case I would say “why not? You intentionally sent it to me!”, but would not blame if you just discard it.


 

 

 

From: ippm <[e-mail] <mailto:[e-mail]> > On Behalf Of Tianran Zhou
Sent: Tuesday, June 27, 2023 08:09
To: Greg Mirsky <[e-mail] <mailto:[e-mail]> >
Cc: IETF IPPM WG <[e-mail] <mailto:[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] <mailto:[e-mail]> ] 
Sent: Tuesday, June 27, 2023 10:07 AM
To: Tianran Zhou <[e-mail] <mailto:[e-mail]> >
Cc: IETF IPPM WG <[e-mail] <mailto:[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