Re: [ippm] Adoption call for draft-mirsky-ippm-stamp-option-tlv

Hi Rakesh,

I am not clear why the direct loss test need to be hardware friendly.
It seems the STAMP is end to end over UDP. It could be CPU processing.

Tianran

From: ippm [mailto:ippm-bounces@ietf.org] On Behalf Of Rakesh Gandhi
Sent: Monday, July 15, 2019 10:48 PM
To: Tommy Pauly <tpauly=40apple.com@dmarc.ietf.org>
Cc: draft-mirsky-ippm-stamp-option-tlv@ietf.org; IETF IPPM WG <ippm@ietf.org>
Subject: Re: [ippm] Adoption call for draft-mirsky-ippm-stamp-option-tlv

Hi Authors,
There were couple of items discussed on the mailing list and have added them below for convenience. Like to see them addressed in the adopted draft.

Thanks,
Rakesh

------------------------------
Regarding the size of the padding, yes, it's good to use the same size payload for query and response.
However, the STAMP payload with TLV extension (draft-mirsky-ippm-stamp-option-tlv-01) has slightly different padding size of 30 MBZ vs 27 ( or > 29)in draft-ietf-ippm-stamp. Is there a way to make them compatible? Does it mean that for STAMP with TLV, Server Octets is set to 1, but it says MBZ 0 for all 30 bytes.. If the responder supports Server Octets and see the size > 27, it may find the Server Octet size of 0 confusing?

--------------------------

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.

<RG> Revised format looks like following:

       0                   1                   2                   3
       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                        Sequence Number                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                          Timestamp                            |
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Error Estimate        |                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
      |                                                               |
      |                                                               |
      |                         MBZ (30 octets)                       |
      |                                                               |
      |                                                               |
      |                                                               |
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    Direct Measurement Type    |           Length              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |             Session-Sender Tx counter  (S_TxC)                |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |             Session-Reflector Rx counter  (R_RxC)             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |             Session-Reflector Tx counter  (R_TxC)             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |             Type              |           Length              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      ~                            Value                              ~
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

On Mon, Jul 8, 2019 at 6:53 PM Tommy Pauly <tpauly=40apple.com@dmarc.ietf.org<mailto:40apple.com@dmarc.ietf.org>> wrote:
Hello IPPM,

This message begins an adoption call for draft-mirsky-ippm-stamp-option-tlv, "Simple Two-way Active Measurement Protocol Optional Extensions”. The document has been discussed on the list recently, with good input and reviews from the group. We’d like to get the working group’s input on if this document should be adopted and worked on by the group.

The current status and text of the document can be found here:

https://datatracker.ietf.org/doc/draft-mirsky-ippm-stamp-option-tlv/
https://tools.ietf.org/html/draft-mirsky-ippm-stamp-option-tlv-05

Please respond to this email by Tuesday, July 23 to indicate whether or not you think IPPM should adopt and work on the extensions and extension mechanism described in this draft.

Best,
Tommy (as IPPM co-chair)
_______________________________________________
ippm mailing list
ippm@ietf.org<mailto:ippm@ietf.org>
https://www.ietf.org/mailman/listinfo/ippm