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

[Tianran Zhou <[e-mail]>]

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