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

[Greg Mirsky <[e-mail]>]

Hi Rakesh,
we're observing that the use of TLV becomes accepted in the fast path.
Overlay encapsulations with extensible headers like Geneve, GUE, and NSH
have been standardized already or will be published as Standard track RFCs
soon.

Regards,
Greg

On Mon, Jun 24, 2019 at 5:25 AM Rakesh Gandhi <[e-mail]>
wrote:

> Hi Greg,
> Thank you for the replies. However, they do not answer my comments.
> Adding a TLV for the direct-mode loss measurement for the delay
> measurement message unnecessarily overloads the message. It is not hardware
> friendly for the reasons mentioned earlier, to look for the TLV, as it may
> or may not be there. Further, the hardware will have to be capable to add
> timestamps as well as counters in the overloaded message. It is much easier
> to have a simple message for loss measurement to just carry counters as is
> done in other protocols (e.g. RFC 6374 and Y.1731).
>
> Thanks,
> Rakesh
>
>
> On Fri, Jun 21, 2019 at 4:37 AM Greg Mirsky <[e-mail]> wrote:
>
>> 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 <[e-mail]>
>> 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 <[e-mail]>
>>> 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
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/ippm
>>>>
>>>