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

[Greg Mirsky <[e-mail]>]

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)

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

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