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

From: Wei Luo S <[email-masked]>
Date: Wed, 18 Oct 2017 00:57:05 +0000

Hi Greg,

It seems the STAMP is derived from TWAMP or TWAMP light. May I know the background of STAWP?

I'm fine with the basic concept of STAMP. Only one question is again the packet format of the sender and reflector. At the end of the packet, a TLV structure is added. What's the intension of adding the TLV?
Per my understand, TLV is a very flexible structure. It has great extension ability, and can carry almost all kinds of content. But it is not straightforward enough. The TLV should be encoded and decoded. And it takes byte to carry simple information, e.g. DSCP value.

The STAMP is only used for measuring the network quality. I don't see any other requirements on it until now. So I don't think the STAMP packet need a TLV structure for future extension. It makes the protocol complex. Do you think it is better to replace it with a simple capability flag and a value octet?
For example:

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | capability   | DSCP ECN value|...                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Thanks,
Wei Luo

Date: Mon, 16 Oct 2017 12:41:24 -0700

From: Greg Mirsky <[email-masked]<mailto:[email-masked]>>

To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>

Subject: [ippm] Fwd: New Version Notification for

                draft-mirsky-ippm-stamp-00.txt

Message-ID:

                <CA+RyBmWHsGN9U8Ny=[email-masked]<mailto:CA+RyBmWHsGN9U8Ny=[email-masked]>>

Content-Type: text/plain; charset="utf-8"

Dear All,

we've published the first version of STAMP ("Simple" Two-way Active Measurement Protocol). Though it may be viewed as not really simple, but STAMP is too catchy name to pass.

We greatly appreciate your reviews, comments, questions, and suggestions.

We hope to have good and productive on-list and at the IETF-100 meeting discussion.

Kind regards,

Greg and Guo

---

From: Greg Mirsky <[email-masked]>
Date: Wed, 25 Oct 2017 13:33:07 -0700

Hi Wei Luo,
thank you for your thorough review of the draft and thoughtful comments,
much appreciated.
Please find my answers and notes in-line tagged GIM>>.

Regards,
Greg

> It seems the STAMP is derived from TWAMP or TWAMP light. May I know the
GIM>> You're right. We've looked at TWAMP-Test and TWAMP Light and decided
to provide on-wire compatibility between TWAMP-Test in unauthenticated
mode/TWAMP Light with STAMP in unauthenticated mode.

>
>
> I’m fine with the basic concept of STAMP. Only one question is again the
> packet format of the sender and reflector. At the end of the packet, a TLV
> structure is added. What’s the intension of adding the TLV?
>
GIM>> We propose to use TLV to support new functions, e.g. CoS testing.
Please note that for nodes that only support TWAMP Light, TLV extension in
unauthenticated STAMP will look as padding. The extension will not work,
but the base functionality, common to both TWAMP-Test and STAMP will.

> Per my understand, TLV is a very flexible structure. It has great
> extension ability, and can carry almost all kinds of content. But it is not
> straightforward enough. The TLV should be encoded and decoded. And it takes
> byte to carry simple information, e.g. DSCP value.
>
GIM>> Absolutely agree with your conclusion - it comes at a cost.

>
>
> The STAMP is only used for measuring the network quality. I don’t see any
> other requirements on it until now. So I don’t think the STAMP packet need
> a TLV structure for future extension. It makes the protocol complex. Do you
> think it is better to replace it with a simple capability flag and a value
> octet?
>
> For example:
>
>
>
>       | capability   | DSCP ECN value|…                               |
>
GIM>> This is very interesting proposal that, I hope, we'll discuss in
Singapore and on the list. My first suggestion would be to ensure that
capability field is of variable length so that one day we won't find out
that no new capabilities can be advertised.

> From: Greg Mirsky <[email-masked]>
>
> To: "[email-masked]" <[email-masked]>
>
>                 <CA+RyBmWHsGN9U8Ny=Xam9N9M0LSpaNrAYsiBnhABG4F9f1q
> [email-masked]>
>
> we've published the first version of STAMP ("Simple" Two-way Active
> Measurement Protocol). Though it may be viewed as not really simple, but
> STAMP is too catchy name to pass.
>