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

From: Greg Mirsky <[email-masked]>
Date: Thu, 20 Jun 2019 16:06:24 +0900

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

---

From: Rakesh Gandhi <[email-masked]>
Date: Thu, 20 Jun 2019 12:38:51 -0400

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.

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.

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.

FYI, ITU Y.1731 also defines separate DMM and LMM messages for delay
and loss measurements.

Thanks,

Rakesh

On Thu, Jun 20, 2019 at 3:06 AM Greg Mirsky <[email-masked]> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ippm
>

---

From: Greg Mirsky <[email-masked]>
Date: Fri, 21 Jun 2019 17:37:16 +0900

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

> carrying timestamps and sequence numbers, the TLVs should be for the
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.

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

---

From: Tianran Zhou <[email-masked]>
Date: Mon, 24 Jun 2019 08:59:28 +0000

Hi Greg,

Several clarification questions after reading this draft.

1. Maybe wrt to section 4. Could you please explicitly describe the mechanism to detect the existence of TLVs, in addition to the fixed message part?

2. Could you please describe the use case for each TLV you proposed? Especially the “Location TLV” and the “Class of Service TLV”. I can hardly understand why these two are useful, and how to use them to do measurement/collection.

Thanks,
Tianran

From: ippm [mailto:[email-masked]] On Behalf Of Greg Mirsky
Sent: Thursday, June 20, 2019 3:06 PM
To: IPPM Chairs <[email-masked]>; IETF IPPM WG <[email-masked]>
Cc: [email-masked]
Subject: [ippm] On progressing draft-mirsky-ippm-stamp-option-tlv

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

---

From: Rakesh Gandhi <[email-masked]>
Date: Mon, 24 Jun 2019 08:24:52 -0400

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

---

From: Greg Mirsky <[email-masked]>
Date: Mon, 24 Jun 2019 08:44:45 -0700

Hi Tianran,
thank you for your interest in the proposal on the optional extensions of
STAMP. Please find my answers in-line below tagged GIM>>.

Regards,
Greg

On Mon, Jun 24, 2019 at 1:59 AM Tianran Zhou <[email-masked]> wrote:

> 1. Maybe wrt to section 4. Could you please explicitly describe the
> mechanism to detect the existence of TLVs, in addition to the fixed message
> part?
>
GIM>> Since the length of the base STAMP packet, and the mode,
unauthenticated or authenticated, are known, the receiver of a STAMP packet
can determine if there are any TLV by comparing the length of the base
STAMP packet with the value of the Total length field of IP header.

>
>
> 2. Could you please describe the use case for each TLV you proposed?
> Especially the “Location TLV” and the “Class of Service TLV”. I can
> hardly understand why these two are useful, and how to use them to do
> measurement/collection.
>
GIM>> We'll expand the informational text for TLVs. For the Location TLV,
the use is described in the draft as follows:

   The Location TLV MAY be used to determine the last-hop addressing for
   STAMP packets including source and destination IP addresses as well
   as the MAC address of the last-hop router.  Last-hop MAC address MAY
   be monitored by the Session-Sender whether there has been a path
   switch on the last hop, closest to the Session-Reflector.  The IP
   addresses and UDP port will indicate if there is a NAT router on the
   path, and allows the Session-Sender to identify the IP address of the
   Session-Reflector behind the NAT, detect changes in the NAT mapping
   that could cause sending the STAMP packets to the wrong Session-
   Reflector.

The use case of the Class of Service TLV is the same as of RFC 7750
<https://datatracker.ietf.org/doc/rfc7750/> and
draft-bailmir-ippm-twamp-dscp-ctrl-mon
<https://www.ietf.org/archive/id/draft-bailmir-ippm-twamp-dscp-ctrl-mon-02.txt>
.

>
>
> Thanks,
>
> Tianran
>
>
>
> *From:* ippm [mailto:[email-masked]] *On Behalf Of *Greg Mirsky
> *Sent:* Thursday, June 20, 2019 3:06 PM
> *To:* IPPM Chairs <[email-masked]>; IETF IPPM WG <[email-masked]>
> *Cc:* [email-masked]
> *Subject:* [ippm] On progressing draft-mirsky-ippm-stamp-option-tlv
>
>
>
> Dear Chairs, et al.,
>

---

From: Greg Mirsky <[email-masked]>
Date: Mon, 24 Jun 2019 08:49:47 -0700

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 <[email-masked]>
wrote:

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

---

From: Rakesh Gandhi <[email-masked]>
Date: Mon, 24 Jun 2019 15:12:48 -0400

Hi Greg,
Thanks for the reply.
I think the comment is that it is much simpler to define a new message for
LM than to overload DM message + TLV to do LM. If you think there are some
cases where both DM+LM combo message is required, then you could position
this solution with fixed offset LM TLV using the DM message for that case.
Thanks,
Rakesh

On Mon, Jun 24, 2019 at 11:49 AM Greg Mirsky <[email-masked]> wrote:

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

---

From: Tianran Zhou <[email-masked]>
Date: Tue, 25 Jun 2019 03:19:18 +0000

Hi Greg，

Thanks for your reply. Please see inline.

Tianran

From: Greg Mirsky [mailto:[email-masked]]
Sent: Monday, June 24, 2019 11:45 PM
To: Tianran Zhou <[email-masked]>
Cc: IETF IPPM WG <[email-masked]>; [email-masked]
Subject: Re: [ippm] On progressing draft-mirsky-ippm-stamp-option-tlv

Hi Tianran,
thank you for your interest in the proposal on the optional extensions of STAMP. Please find my answers in-line below tagged GIM>>.

Regards,
Greg

On Mon, Jun 24, 2019 at 1:59 AM Tianran Zhou <[email-masked]<mailto:[email-masked]>> wrote:
Hi Greg,

1. Maybe wrt to section 4. Could you please explicitly describe the mechanism to detect the existence of TLVs, in addition to the fixed message part?
GIM>> Since the length of the base STAMP packet, and the mode, unauthenticated or authenticated, are known, the receiver of a STAMP packet can determine if there are any TLV by comparing the length of the base STAMP packet with the value of the Total length field of IP header.

[ztr]. OK. So，STAMP is IP based protocol? Or it’s udp based, so need to use the length in UDP header?
Anyway, it’s better to describe this information because from figure 1, people cannot deduce it.

2. Could you please describe the use case for each TLV you proposed? Especially the “Location TLV” and the “Class of Service TLV”. I can hardly understand why these two are useful, and how to use them to do measurement/collection.
GIM>> We'll expand the informational text for TLVs. For the Location TLV, the use is described in the draft as follows:

[ztr]: 1. My understanding on this paragraph is the location tlv actually includes two separate functions. One is to collect the last-hop MAC. The other is to collect the IP and port.
It seems they have very different use. Then why not split it into two TLVs? I cannot see the use case of the combination of the two parts.
2. It’s still not clear to me why we need to know “whether there has been a path switch on the last hop”. How to know this based on the source MAC? Who’s source MAC? I cannot guess on the too simple description.
3. ipv4 and ipv6 address have different length. How do I know it’s an ipv4 or ipv6 address?
4. I want to see more text on how to use IP+port to detect the NAT mapping. What’s the issue?

The use case of the Class of Service TLV is the same as of RFC 7750<https://datatracker.ietf.org/doc/rfc7750/> and draft-bailmir-ippm-twamp-dscp-ctrl-mon<https://www.ietf.org/archive/id/draft-bailmir-ippm-twamp-dscp-ctrl-mon-02.txt>.

[ztr]: Specifically, who generate the dscp1,dscp2 and ecn? based on what?

Thanks,
Tianran

From: ippm [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Greg Mirsky
Sent: Thursday, June 20, 2019 3:06 PM
To: IPPM Chairs <[email-masked]<mailto:[email-masked]>>; IETF IPPM WG <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: [ippm] On progressing draft-mirsky-ippm-stamp-option-tlv

Dear Chairs, et al.,

Regards,
Greg

---

From: Greg Mirsky <[email-masked]>
Date: Tue, 25 Jun 2019 14:48:07 -0700

Hi Tianran,
many thanks for further clarifications. Please find my answers below
in-lined tagged GIM2>>.

Regards,
Greg

On Mon, Jun 24, 2019 at 8:19 PM Tianran Zhou <[email-masked]> wrote:

> *From:* Greg Mirsky [mailto:[email-masked]]
> *Sent:* Monday, June 24, 2019 11:45 PM
> *To:* Tianran Zhou <[email-masked]>
> *Cc:* IETF IPPM WG <[email-masked]>;
> [email-masked]
> *Subject:* Re: [ippm] On progressing draft-mirsky-ippm-stamp-option-tlv
>
>
>
> Hi Tianran,
>
GIM>> Yes, you're correct, thank you. STAMP uses UDP and thus the length of
both IP and UDP headers must be included in the calculation. Hope the new
text clarifies the process:
NEW TEXT:
   A STAMP node, whether Session-Sender or Session-Reflector, receiving
   a test packet MUST determine whether the packet is a base STAMP
   packet or includes one or more TLVs.  The node MUST compare the value
   in the Total Length field of the IP header and the length of the base
   STAMP test packet in the mode, unauthenticated or authenticated based
   on the configuration of the particular STAMP test session.  If the
   difference between the two values is larger than the length of IP and
   UDP headers, then the test packet includes one or more STAMP TLVs
   that immediately follow the base STAMP test packet.

> [ztr]: 1. My understanding on this paragraph is the location tlv actually
> includes two separate functions. One is to collect the last-hop MAC. The
> other is to collect the IP and port.
>
> It seems they have very different use. Then why not split it into two
> TLVs? I cannot see the use case of the combination of the two parts.
>
GIM>> I agree that there could be practical reasons to have two TLVs. I
hope other experts in the IPPM WG will share their opinions.

> 2. It’s still not clear to me why we need to know “whether there has been
> a path switch on the last hop”. How to know this based on the source MAC?
> Who’s source MAC? I cannot guess on the too simple description.
>
GIM>> Will add a use case into the future version.

> 3. ipv4 and ipv6 address have different length. How do I know it’s an
GIM>> The value of the Length field may be used as the indicator of which
address family being used.

> mapping. What’s the issue?
GIM>> Same as for the use of MAC. Will add a use case into the future
version.

> [ztr]: Specifically, who generate the dscp1,dscp2 and ecn? based on what?
GIM2>> The explanation of the Class of Service TLV suggests that:
    o  DSCP1 - The Differentiated Services Code Point (DSCP) intended by
      the Session-Sender.  To be used as the return DSCP from the
      Session-Reflector.

   o  DSCP2 - The received value in the DSCP field at the Session-
      Reflector in the forward direction.
A new text to be added in the next update:
NEW TEXT:
   A STAMP Session-Sender that includes the Class of Service TLV sets
   the value of the DSCP1 field and zeroes the value of the DSCP2 field.
   A STAMP Session-Reflector that received the test packet with the
   Class of Service TLV MUST include the Class of Service TLV in the
   reflected test packet.  Also, the Session-Sender MUST copy the value
   of the DSCP field of the IP header of the received STAMP test packet
   and copy it into the DSCP2 field of the reflected test packet.  And,
   at last, the Session-Reflector MUST set the value of the DSCP field
   in the IP header of the reflected test packet equal to the value of
   the DSCP1 field of the test packet it received.

Does it make the intent and handling of the Class of Service TLV clearer?

---

From: Tianran Zhou <[email-masked]>
Date: Wed, 26 Jun 2019 04:22:44 +0000

Hi Greg,

Thank you very much for your clarification and taking my suggestions. Look forward to your revision.
Let’s work on this text:
NEW TEXT:

1. “Also, the Session-Sender MUST copy the value of the DSCP field of the IP header of the received STAMP test packet and copy it into the DSCP2 field of the reflected test packet.”

Please make sure it’s session-reflector not session-sender. Correct?

2. My understanding dscp1 is used for the session-sender to notify the session-reflector to use the dscp1 for the reflect message transport. If so, why not just use the configuration(i.e., YANG)?
Dscp2 is used for the session-reflector to notify the session-sender the receive packet dscp value. Why the sender need to know this, as the sender should have known this? To check if the path changed the DSCP?

Thanks,
Tianran

Sent: Wednesday, June 26, 2019 5:48 AM

Hi Tianran,
many thanks for further clarifications. Please find my answers below in-lined tagged GIM2>>.

Regards,
Greg

On Mon, Jun 24, 2019 at 8:19 PM Tianran Zhou <[email-masked]<mailto:[email-masked]>> wrote:
Hi Greg，

Tianran

From: Greg Mirsky [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Monday, June 24, 2019 11:45 PM
To: Tianran Zhou <[email-masked]<mailto:[email-masked]>>
Cc: IETF IPPM WG <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [ippm] On progressing draft-mirsky-ippm-stamp-option-tlv

Hi Tianran,

Regards,
Greg

GIM>> Yes, you're correct, thank you. STAMP uses UDP and thus the length of both IP and UDP headers must be included in the calculation. Hope the new text clarifies the process:

[ztr]: 1. My understanding on this paragraph is the location tlv actually includes two separate functions. One is to collect the last-hop MAC. The other is to collect the IP and port.
It seems they have very different use. Then why not split it into two TLVs? I cannot see the use case of the combination of the two parts.
GIM>> I agree that there could be practical reasons to have two TLVs. I hope other experts in the IPPM WG will share their opinions.
2. It’s still not clear to me why we need to know “whether there has been a path switch on the last hop”. How to know this based on the source MAC? Who’s source MAC? I cannot guess on the too simple description.
GIM>> Will add a use case into the future version.
3. ipv4 and ipv6 address have different length. How do I know it’s an ipv4 or ipv6 address?
GIM>> The value of the Length field may be used as the indicator of which address family being used.
4. I want to see more text on how to use IP+port to detect the NAT mapping. What’s the issue?
GIM>> Same as for the use of MAC. Will add a use case into the future version.

Thanks,
Tianran

Dear Chairs, et al.,

Regards,
Greg

---

From: Greg Mirsky <[email-masked]>
Date: Wed, 26 Jun 2019 14:42:16 -0700

Hi Tianran,
thank you for the great discussion. Please find my responses in-line tagged
GIM3>>.

Regards,
Greg

On Tue, Jun 25, 2019 at 9:23 PM Tianran Zhou <[email-masked]> wrote:

> 1. “Also, the Session-Sender MUST copy the value of the DSCP field of the
> IP header of the received STAMP test packet and copy it into the DSCP2
> field of the reflected test packet.”
>
>
>
GIM3>> Great catch, thank you!

>
>
> 2. My understanding dscp1 is used for the session-sender to notify the
> session-reflector to use the dscp1 for the reflect message transport. If
> so, why not just use the configuration(i.e., YANG)?
>
GIM3>> CoS re-mapping testing, in our view, does not require the use of
many test packets in the session. In fact, to test CoS may require changing
the DSCP value in the IP header and of DSCP1 in CoS TLV for each test
packet transmitted by the Session-Sender.

> Dscp2 is used for the session-reflector to notify the session-sender the
> receive packet dscp value. Why the sender need to know this, as the sender
> should have known this? To check if the path changed the DSCP?
>
GIM3>> You're right, DSCP2 returns the value of the DSCP field as received
by the Session-Reflector. Re-mapping of CoS in some use cases, for example
in mobile backhaul networks, is used technique to provide multiple
services, i.e. 2G, 3G, LTE, over the same network. But if it is
misconfigured, then it often difficult to diagnose the root cause of the
problem that is viewed as an excessive packet drop of higher level service
while packet drop for lower service packets is at a normal level.

> *Sent:* Wednesday, June 26, 2019 5:48 AM
> GIM>> Yes, you're correct, thank you. STAMP uses UDP and thus the length
> of both IP and UDP headers must be included in the calculation. Hope the
> new text clarifies the process:
>
> NEW TEXT:
>

---

From: Tianran Zhou <[email-masked]>
Date: Thu, 27 Jun 2019 07:59:17 +0000

Hi Greg,

Very interesting discussion. I am clear about the CoS TLV.

Thanks,
Tianran

Sent: Thursday, June 27, 2019 5:42 AM

Hi Tianran,
thank you for the great discussion. Please find my responses in-line tagged GIM3>>.

Regards,
Greg

On Tue, Jun 25, 2019 at 9:23 PM Tianran Zhou <[email-masked]<mailto:[email-masked]>> wrote:
Hi Greg,

2. My understanding dscp1 is used for the session-sender to notify the session-reflector to use the dscp1 for the reflect message transport. If so, why not just use the configuration(i.e., YANG)?
GIM3>> CoS re-mapping testing, in our view, does not require the use of many test packets in the session. In fact, to test CoS may require changing the DSCP value in the IP header and of DSCP1 in CoS TLV for each test packet transmitted by the Session-Sender.
Dscp2 is used for the session-reflector to notify the session-sender the receive packet dscp value. Why the sender need to know this, as the sender should have known this? To check if the path changed the DSCP?
GIM3>> You're right, DSCP2 returns the value of the DSCP field as received by the Session-Reflector. Re-mapping of CoS in some use cases, for example in mobile backhaul networks, is used technique to provide multiple services, i.e. 2G, 3G, LTE, over the same network. But if it is misconfigured, then it often difficult to diagnose the root cause of the problem that is viewed as an excessive packet drop of higher level service while packet drop for lower service packets is at a normal level.

Thanks,
Tianran

Hi Tianran,

Regards,
Greg

Tianran

Hi Tianran,

Regards,
Greg

Thanks,
Tianran

Dear Chairs, et al.,

Regards,
Greg