Re: [ippm] On progressing draft-mirsky-ippm-stamp-option-tlv

Hi Rakesh,
thank you for your review and comments on the STAMP option TLV draft.
Please find my answers and notes in-line tagged GIM>>.

Regards,
Greg

On Fri, Jun 21, 2019 at 1:39 AM Rakesh Gandhi <rgandhi.ietf@gmail.com>
wrote:

> Hi Greg, Authors,
>
>
>
> It is good to see the TLV extensions for STAMP. As STAMP is defined for
> carrying timestamps and sequence numbers, the TLVs should be for the
> related extensions.
>
GIM>> STAMP is defined in the draft-ietf-ippm-stamp
<https://datatracker.ietf.org/doc/draft-ietf-ippm-stamp/> as the follows:
   This document describes a Simple Two-way Active Measurement Protocol
   which enables the measurement of both one-way and round-trip
   performance metrics like delay, delay variation, and packet loss.

>
> The direct measurement TLV proposed in the draft may not be hardware
> friendly for actual data traffic loss measurement due to the need to search
> the presence of the TLV and the counter offset not always fixed due to the
> variable length payload. Also, it overloads the delay measurement probes
> just for measuring packet loss which complicates the implementation.
>
GIM>> The Direct Loss TLV is intended to immediately follow the STAMP test
packet and thus its location is known. We'll work on the text to guide
implementations to be more HW friendly and support efficient testing.

>
>
> For direct mode loss measurement, there is a simple new message defined in *draft-gandhi-spring-twamp-srpm* which is hardware friendly (just like LM using RFC 6374 using a separate message) and does not overload the existing protocol used for delay measurement.
>
> GIM>> Thank you for pointing to the draft. I've reviewed it and shared my
comments. As I've noted earlier, I believe that the proposed packet is not
backward compatible with TWAMP-Light while one of the goals of STAMP is to
be able to interwork with TWAMP-Light Session-Sender or Session-Reflector
in unauthenticated mode.

>
>
> FYI, ITU Y.1731 also defines separate DMM and LMM messages for delay and loss measurements.
>
> GIM>> Thank you for reminding us that. On the issue of reviewing existing
solutions for support of both direct and synthetic packet loss measurement,
I'll note that RFC 6374 uses the same message, Loss Measurement, for both
synthetic and direct measurement methods.

>
>
> Thanks,
>
> Rakesh
>
>
>
>
> On Thu, Jun 20, 2019 at 3:06 AM Greg Mirsky <gregimirsky@gmail.com> wrote:
>
>> Dear Chairs, et al.,
>> authors of draft-mirsky-ippm-stamp-option-tlv believe that it is stable
>> and detailed enough to ask for your consideration to start the WG Adoption
>> Poll.
>>
>> Regards,
>> Greg
>> _______________________________________________
>> ippm mailing list
>> ippm@ietf.org
>> https://www.ietf.org/mailman/listinfo/ippm
>>
>