Re: [ippm] AD review of draft-ietf-ippm-stamp

"MORTON, ALFRED C (AL)" <acm@research.att.com> Sun, 11 August 2019 16:24 UTC

Return-Path: <acm@research.att.com>
X-Original-To: ippm@ietfa.amsl.com
Delivered-To: ippm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00EC1120D93; Sun, 11 Aug 2019 09:24:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.499
X-Spam-Level:
X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VlJwQmh2o_6O; Sun, 11 Aug 2019 09:23:08 -0700 (PDT)
Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB58F1208CC; Sun, 11 Aug 2019 02:14:12 -0700 (PDT)
Received: from pps.filterd (m0049297.ppops.net [127.0.0.1]) by m0049297.ppops.net-00191d01. (8.16.0.27/8.16.0.27) with SMTP id x7B94p91025973; Sun, 11 Aug 2019 05:14:09 -0400
Received: from tlpd255.enaf.dadc.sbc.com (sbcsmtp3.sbc.com [144.160.112.28]) by m0049297.ppops.net-00191d01. with ESMTP id 2uaav9c2y7-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 11 Aug 2019 05:14:08 -0400
Received: from enaf.dadc.sbc.com (localhost [127.0.0.1]) by tlpd255.enaf.dadc.sbc.com (8.14.5/8.14.5) with ESMTP id x7B9E64f037378; Sun, 11 Aug 2019 04:14:07 -0500
Received: from zlp30494.vci.att.com (zlp30494.vci.att.com [135.46.181.159]) by tlpd255.enaf.dadc.sbc.com (8.14.5/8.14.5) with ESMTP id x7B9E2u6037313 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 11 Aug 2019 04:14:02 -0500
Received: from zlp30494.vci.att.com (zlp30494.vci.att.com [127.0.0.1]) by zlp30494.vci.att.com (Service) with ESMTP id D8BB34009E78; Sun, 11 Aug 2019 09:14:02 +0000 (GMT)
Received: from clpi183.sldc.sbc.com (unknown [135.41.1.46]) by zlp30494.vci.att.com (Service) with ESMTP id 951FD4009E74; Sun, 11 Aug 2019 09:14:02 +0000 (GMT)
Received: from sldc.sbc.com (localhost [127.0.0.1]) by clpi183.sldc.sbc.com (8.14.5/8.14.5) with ESMTP id x7B9E2nC013106; Sun, 11 Aug 2019 04:14:02 -0500
Received: from mail-green.research.att.com (mail-green.research.att.com [135.207.255.15]) by clpi183.sldc.sbc.com (8.14.5/8.14.5) with ESMTP id x7B9DsJH012714; Sun, 11 Aug 2019 04:13:55 -0500
Received: from exchange.research.att.com (njbdcas1.research.att.com [135.197.255.61]) by mail-green.research.att.com (Postfix) with ESMTP id 8059FE3894; Sun, 11 Aug 2019 05:11:55 -0400 (EDT)
Received: from njmtexg4.research.att.com ([fe80::8cd:baa3:219e:5bd4]) by njbdcas1.research.att.com ([fe80::8c6b:4b77:618f:9a01%11]) with mapi id 14.03.0468.000; Sun, 11 Aug 2019 05:13:54 -0400
From: "MORTON, ALFRED C (AL)" <acm@research.att.com>
To: Greg Mirsky <gregimirsky@gmail.com>, "Rakesh Gandhi (rgandhi)" <rgandhi@cisco.com>
CC: "draft-ietf-ippm-stamp@ietf.org" <draft-ietf-ippm-stamp@ietf.org>, "Mirja Kuehlewind" <ietf@kuehlewind.net>, IPPM Chairs <ippm-chairs@ietf.org>, "IETF IPPM WG" <ippm@ietf.org>
Thread-Topic: [ippm] AD review of draft-ietf-ippm-stamp
Thread-Index: AQHVNZ0amQo6PNCyFk2ZRVsFWcmbE6bBI+aAgAAWDYCAAD6oAIAAJQuAgAAPUwCAACEDgIAs2sYAgAATHACAACGlgIAB7dkAgADlwACAAGZlgIABFYaAgABFygCAAE6EgIABqGCAgABz5OA=
Date: Sun, 11 Aug 2019 09:13:00 +0000
Message-ID: <4D7F4AD313D3FC43A053B309F97543CFA0ADB4D3@njmtexg4.research.att.com>
References: <B617B303-6EBE-4E3B-AE5C-1438FF1C5D7F@kuehlewind.net> <CA+RyBmVEmKQu=LGp9eVT+x5e01LCSk_A4tQD=RE8Ett-R35BVg@mail.gmail.com> <11938018-8A65-483B-8176-A6E1C2A265A3@kuehlewind.net> <CA+RyBmX=Jx2yXrMXu4Y2VKX36iKphymb1Hkyfy0XhPGFmsUGzQ@mail.gmail.com> <B8047CA0-2F5E-48F8-9BE4-3FA41D742F12@kuehlewind.net> <CA+RyBmXPCe7TZQqPgsKsVnifZDG8O8wGafDn-nzYfGpx2OiaXQ@mail.gmail.com> <F167C330-76F4-48FC-B720-415CA190239C@broadcom.com> <CA+RyBmVtfXcwqu1RH-1JXnhpCZcbGgm30ubKGctUPnLNJCgVZQ@mail.gmail.com> <CAMZsk6e-bcFNz327p_u6KEHV2qnJUytPwPmJVgXxEWbzsQr9OA@mail.gmail.com> <CA+RyBmW01TgyXPAk3OGhdKqDTszkf0KzT+dDVTdaEhFu7GA7-Q@mail.gmail.com> <CAMZsk6eUOTxjWy=r62SNvSLzOe8KGQ8CGgbW-H2uoLgDPmPsTA@mail.gmail.com> <CA+RyBmUfB-d18A5OJ2rG9naFE+0HjXehf13Nt4D2z2do-wHBDw@mail.gmail.com> <CAMZsk6eRG0OCY_6ZRacm9+cL=YsdjUQRXXcxA8mTA=PYs5CTVw@mail.gmail.com> <CA+RyBmVEVK10=3ULnRgyOzHKb3AWaHmisKoaHqocAYXM4w_ADg@mail.gmail.com> <E549477E-0320-41AD-8741-1898F37F6AA3@cisco.com> <CA+RyBmXNWnY=GVxz2kGFT+KheQxfexTgj8_iQqA0LZzcqM_fOQ@mail.gmail.com> <13DEB6E4-DF8C-491F-94B6-1D8CD46B3618@cisco.com> <CA+RyBmUEKDrtupSnSQvMmpM6ioGBbzo-70XZdhan=si4WHzQKA@mail.gmail.com> <6A5DC26F-A582-4C02-86A4-A1F20834B27B@cisco.com> <CA+RyBmWphGJcwRkyNqs87u3yu+1Qi=0GeoT10Aqd9+Qp2wDx7A@mail.gmail.com>
In-Reply-To: <CA+RyBmWphGJcwRkyNqs87u3yu+1Qi=0GeoT10Aqd9+Qp2wDx7A@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [188.10.176.229]
Content-Type: multipart/alternative; boundary="_000_4D7F4AD313D3FC43A053B309F97543CFA0ADB4D3njmtexg4researc_"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-08-11_04:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1906280000 definitions=main-1908110104
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/-X_zUr4kPXWk13Ml83qe-mYPAME>
Subject: Re: [ippm] AD review of draft-ietf-ippm-stamp
X-BeenThere: ippm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF IP Performance Metrics Working Group <ippm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ippm>, <mailto:ippm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ippm/>
List-Post: <mailto:ippm@ietf.org>
List-Help: <mailto:ippm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ippm>, <mailto:ippm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 11 Aug 2019 16:24:06 -0000

Agree with Greg, -2 on mentioning System Ports, other than 862.

Al

From: ippm [mailto:ippm-bounces@ietf.org] On Behalf Of Greg Mirsky
Sent: Saturday, August 10, 2019 6:14 PM
To: Rakesh Gandhi (rgandhi) <rgandhi@cisco.com>
Cc: draft-ietf-ippm-stamp@ietf.org; Mirja Kuehlewind <ietf@kuehlewind.net>et>; IPPM Chairs <ippm-chairs@ietf.org>rg>; IETF IPPM WG <ippm@ietf.org>
Subject: Re: [ippm] AD review of draft-ietf-ippm-stamp

Hi Rakesh,
please review the updated diff and the working version of the draft. Do you think that the changes address your and Henrik's comments on the use of UDP port numbers in STAMP? You'll notice that the use of the System ports is not mentioned. I believe that this range of port numbers should not be used. What do you think?
Much appreciate your comments, suggestions.

Regards,
Greg

On Fri, Aug 9, 2019 at 1:55 PM Rakesh Gandhi (rgandhi) <rgandhi@cisco.com<mailto:rgandhi@cisco.com>> wrote:
Thanks Greg for the updates. Changes look good to me..
One outstanding issue with the Port range being discussed in another thread.
Thanks,
Rakesh


From: Greg Mirsky <gregimirsky@gmail.com<mailto:gregimirsky@gmail.com>>
Date: Friday, August 9, 2019 at 12:26 PM
To: "=SMTP:rgandhi@cisco. com" <rgandhi@cisco.com<mailto:rgandhi@cisco.com>>
Cc: Rakesh Gandhi <rgandhi.ietf@gmail.com<mailto:rgandhi.ietf@gmail.com>>, IPPM Chairs <ippm-chairs@ietf.org<mailto:ippm-chairs@ietf.org>>, Mirja Kuehlewind <ietf@kuehlewind.net<mailto:ietf@kuehlewind.net>>, IETF IPPM WG <ippm@ietf.org<mailto:ippm@ietf.org>>, "draft-ietf-ippm-stamp@ietf.org<mailto:draft-ietf-ippm-stamp@ietf.org>" <draft-ietf-ippm-stamp@ietf.org<mailto:draft-ietf-ippm-stamp@ietf.org>>
Subject: Re: [ippm] AD review of draft-ietf-ippm-stamp

Hi Rakesh, Henrik, et al.,
I've updated the working version of the draft. Attached, please find the diff and the current copy of the document. Please let me know if I've captured all the changes we've discussed.
On the question Rakesh has asked. These recommendations are part of Section 4.4 that details aspects of STAMP interoperability with TWAMP Light implementations. All the normative language used in that section is not applicable to the scenario when both systems support STAMP protocol.

Regards,
Greg

On Fri, Aug 9, 2019 at 5:05 AM Rakesh Gandhi (rgandhi) <rgandhi@cisco..com<mailto:rgandhi@cisco.com>> wrote:
Hi Greg,
Thanks for considering my comments. Please see replies inline with <RG>..

From: Greg Mirsky <gregimirsky@gmail.com<mailto:gregimirsky@gmail.com>>
Date: Thursday, August 8, 2019 at 3:40 PM
To: "=SMTP:rgandhi@cisco. com" <rgandhi@cisco.com<mailto:rgandhi@cisco.com>>
Cc: Rakesh Gandhi <rgandhi.ietf@gmail.com<mailto:rgandhi.ietf@gmail.com>>, IPPM Chairs <ippm-chairs@ietf.org<mailto:ippm-chairs@ietf.org>>, Mirja Kuehlewind <ietf@kuehlewind.net<mailto:ietf@kuehlewind.net>>, IETF IPPM WG <ippm@ietf.org<mailto:ippm@ietf.org>>, "draft-ietf-ippm-stamp@ietf.org<mailto:draft-ietf-ippm-stamp@ietf.org>" <draft-ietf-ippm-stamp@ietf.org<mailto:draft-ietf-ippm-stamp@ietf.org>>
Subject: Re: [ippm] AD review of draft-ietf-ippm-stamp

Hi Rakesh,
many thanks for your comments.

  *   I've updated MBZ to "MAY be zeroed on transmit and MUST be ignored on receipt".
<RG> Thanks.

  *   I think that the fact RFC 7750 is not mentioned in this document should be interpreted as "not supported". If you believe that something should be said explicitly, would the following be acceptable
“[RFC7750] is supported by optional extension specified in [I-D.ietf-ippm-stamp-option-tlv].”
<RG> Yes, thanks.
<RG> BTW, I see following two texts for the timestamp format in Section 4.4. Is there a reason why the Reflector only supports NTP and it is MUST whereas Sender has the flexibility with NTP and PTP with SHOULD?
"The Session-Sender SHOULD use the default format for its timestamps - NTP. And it MAY use PTPv2 timestamp format.
<snip>
“The Session-Reflector MUST be set to use the default format for its timestamps, NTP.”
Thanks,
Rakesh

Attached are, as usual, diff and the updated working version.

Much appreciate your help and commitment to making STAMP useful and practical.

Regards,
Greg

On Thu, Aug 8, 2019 at 6:24 AM Rakesh Gandhi (rgandhi) <rgandhi@cisco..com<mailto:rgandhi@cisco.com>> wrote:
Thank you Greg for the updates. They look good, I have couple of comments:

  1.  I did not see the updates for the first bullet (1) below regarding MBZ in the updated draft. Assuming it is pending.
  2.  It should still say something for the RFC 7750. Without any guidance, it can be implemented as specified in RFC 7750.

Thanks,
Rakesh


From: ippm <ippm-bounces@ietf.org<mailto:ippm-bounces@ietf.org>> on behalf of Greg Mirsky <gregimirsky@gmail.com<mailto:gregimirsky@gmail.com>>
Date: Wednesday, August 7, 2019 at 7:43 PM
To: Rakesh Gandhi <rgandhi.ietf@gmail.com<mailto:rgandhi.ietf@gmail.com>>
Cc: IPPM Chairs <ippm-chairs@ietf.org<mailto:ippm-chairs@ietf.org>>, Mirja Kuehlewind <ietf@kuehlewind.net<mailto:ietf@kuehlewind.net>>, IETF IPPM WG <ippm@ietf.org<mailto:ippm@ietf.org>>, "draft-ietf-ippm-stamp@ietf.org<mailto:draft-ietf-ippm-stamp@ietf.org>" <draft-ietf-ippm-stamp@ietf.org<mailto:draft-ietf-ippm-stamp@ietf.org>>
Subject: Re: [ippm] AD review of draft-ietf-ippm-stamp

Hi Rakesh,
thank you for your kind consideration of my responses and very pointed questions. Please find my follow-up notes in-line below under GIM>> tag.

Regards,
Greg

On Tue, Aug 6, 2019 at 11:15 AM Rakesh Gandhi <rgandhi.ietf@gmail.com<mailto:rgandhi.ietf@gmail.com>> wrote:
Hi Greg,
Thanks for your reply. Please see inline <RG>...

On Tue, Aug 6, 2019 at 12:14 PM Greg Mirsky <gregimirsky@gmail.com<mailto:gregimirsky@gmail.com>> wrote:
Hi Rakesh,
thank you for pointing to these two RFCs. Please consider my thoughts:

  *   (1) RFC 7820 is Experimental and, as I understand, the proposed solution is not seen kindly by the security experts, and for a good reason. As you've correctly pointed out, STAMP in unauthenticated mode may easily support the technique described in RFC 7820. But I'm not sure we have to do that in the base specification. What we can do is to relax language on MBZ and drop "MUST be zeroed on transmission" leaving "MUST be ignored on receipt". What do you think?
<RG> Ok with that.


  *   (2) I appreciate your interest in RFC 7750 (as one of co-authors). We've decided to support this functionality in an extension to STAMP. Class of Service TLV fully supports the functionality defined in RFC 7750 and offers the ability to instruct the Session-Reflector which DSCP value it must use for the reflected STAMP packet. Thus CoS marking consistency is verified in forward and reverse directions.
<RG> In that case, draft may say RFC7750 method is not supported by STAMP?
GIM>> Though it is not part of the base specification, the ability to test the consistency of CoS mapping on a path between STAMP Session-Sender and Session-Reflector is supported by using the Class of Service TLV. And since it has been recently adopted by IPPM WG, I don't think that such a statement will be helpful to an implementor of STAMP.
Also, I think the draft dropped supporting the server octet [RFC6038], right? If so, following text needs updating?
   o  (3) Packet Padding (reflected) is an optional variable length field..
      The length of the Packet Padding (reflected) field MUST be equal
      to the value of the Server Octets field (Figure 2).  If the value
      is non-zero, the Session-Reflector MUST copy number of octets
      equal to the value of Server Octets field starting with the Server
      Octets field.
GIM>> I'm sorry you've had an older working version of the draft. Attached is the current version and the text has been removed. Could you let me know if this change is acceptable?

Thanks,
Rakesh


Best regards,
Greg

On Tue, Aug 6, 2019 at 8:06 AM Rakesh Gandhi <rgandhi.ietf@gmail..com<mailto:rgandhi.ietf@gmail.com>> wrote:
Hi Greg,
Couple of additional comments on the draft:
There are TWAMP extensions for Checksum complement in RFC 7820 and DSCP-ECN in RFC 7750. Good to add some text for STAMP if they can be supported or not supported. I can see they can be supported as following, and should not break anything:

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                        |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|                        Transmit Timestamp                     |

|                                                               |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|         Error Estimate        |           MBZ                 |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|                      Receive Timestamp                        |

|                                                               |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|                      Sender Sequence Number                   |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|                      Sender Timestamp                         |

|                                                               |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|      Sender Error Estimate    |           MBZ                 |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|  Sender TTL   | S-DSCP-ECN    | Checksum Complement           |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Thanks,
Rakesh

On Mon, Jul 8, 2019 at 10:07 PM Greg Mirsky <gregimirsky@gmail.com<mailto:gregimirsky@gmail.com>> wrote:
Hi Rakesh,
thank you for your question. In my experience, some implementations of TWAMP-Light have taken the liberty to allow using UDP port numbers outside the Dynamic/Private range. I believe that is not the right decision. In the note of IANA's Service Name and Transport Protocol Port Number Registry we read:

 Service names and port numbers are used to distinguish between different
 services that run over transport protocols such as TCP, UDP, DCCP, and
 SCTP.

 Service names are assigned on a first-come, first-served process, as
 documented in [RFC6335].

 Port numbers are assigned in various ways, based on three ranges: System
 Ports (0-1023), User Ports (1024-49151), and the Dynamic and/or Private
 Ports (49152-65535); the difference uses of these ranges is described in
 [RFC6335]. According to Section 8.1.2 of [RFC6335], System Ports are
 assigned by the "IETF Review" or "IESG Approval" procedures described in
 [RFC8126]. User Ports are assigned by IANA using the "IETF Review" process,
 the "IESG Approval" process, or the "Expert Review" process, as per
 [RFC6335]. Dynamic Ports are not assigned.

 The registration procedures for service names and port numbers are
 described in [RFC6335].

 Assigned ports both System and User ports SHOULD NOT be used without
 or prior to IANA registration.

My interpretation is that ports in System and User ranges, even if not yet assigned, must not be used without following the assignment process. Thus, regardless of whether a number had not yet been assigned to a service, it must not be used as the destination UDP port number. Also, consider operational issues if a new service is assigned a new port number from the User Ports range. One day the number was "free" and tomorrow it may be assigned. Handling such a scenario will add complexity while benefits are, in my opinion, questionable.

Regards,
Greg

On Mon, Jul 8, 2019 at 5:09 PM Rakesh Gandhi <rgandhi.ietf@gmail..com<mailto:rgandhi.ietf@gmail.com>> wrote:
Hi Greg,

Why limit the UDP port range to 49152-65535? Any free UDP port can be used, no?

Thanks,
Rakesh


On Mon, Jul 8, 2019 at 7:20 PM Greg Mirsky <gregimirsky@gmail.com<mailto:gregimirsky@gmail.com>> wrote:
Hi Shahram,
thank you for the review and questions. Please find my answers below tagged GIM>>.

Regards,
Greg

On Mon, Jul 8, 2019 at 2:02 PM Shahram Davari <shahram.davari@broadcom.com<mailto:shahram.davari@broadcom.com>> wrote:
HI Greg

I read your draft and have the following questions:

1) Does it require any UDP/TCP port number or it reuses the one from TWAMP? if it reuses from TWAMP then  how does the receiver differentiate between TWAMP and STAMP?
GIM>> STAMP uses the well-known UDP port number allocated for the OWAMP-Test/TWAMP-Test Receiver port (RFC 8545) as the default destination UDP port number.. STAMP may use destination UDP port number from the Dynamic and/or Private Ports range 49152-65535.
2) What is the benefit of STAMO compared to TWAMP?
GIM>> The work was driven by several observations, among them:

  *   challenges in achieving interoperability among implementations of TWAMP-Light;
  *   industry interest in standardizing performance monitoring in IP broadband access networks (TR-390);
  *   improve extensibility of IP performance monitoring tool to support measurements, testing of new metrics and parameters, e.g., consistency of CoS in the network.
3) Why is there so much MBZ byte?
GIM>> It was agreed to make the symmetrical size of STAMP test packets the default. RFC 6038 defined it for TWAMP and TR-390 requires it to be supported by TWAMP-Light implementations.

Thx
Shahram

On Jul 8, 2019, at 10:17 AM, Greg Mirsky <gregimirsky@gmail.com<mailto:gregimirsky@gmail.com>> wrote:

Hi Mirja,
thank you for the suggested text. The new paragraph now reads as:
      Load of STAMP test packets offered to a network MUST be carefully
      estimated, and the possible impact on the existing services MUST
      be thoroughly analyzed before launching the test session.
      [RFC8085] section 3.1.5 provides guidance on handling network load
      for UDP-based protocol.  While the characteristic of test traffic
      depends on the test objective, it is highly recommended to stay in
      the limits as provided in [RFC8085].

If it is acceptable, I'd like to upload the updated version of draft-ieff-ippm-stamp before the cut-off deadline.

Regards,
Greg

On Mon, Jul 8, 2019 at 8:58 AM Mirja Kuehlewind <ietf@kuehlewind.net<mailto:ietf@kuehlewind.net>> wrote:
Hi Greg,

See below.

> On 8. Jul 2019, at 16:54, Greg Mirsky <gregimirsky@gmail.com<mailto:gregimirsky@gmail.com>> wrote:
>
> Hi Mirja,
> thank you for the reference to RFC 8085. I agree that the document is very much relevant and a reference to RFC 8085 in STAMP is useful. While reading Section 3.1.3 I came to think that the discussion and guidance in other sections of RFC 8085, particularly, Section 3.1.5 Implications of RTT and Loss Measurements on Congestion Control. Would adding the reference to that section in the new text proposed for the Security Considerations section work? I'll put RFC 8085 as Informational reference as it is BCP.
> NEW TEXT:
>       Load of STAMP test packets offered to a network MUST be carefully
>       estimated, and the possible impact on the existing services MUST
>       be thoroughly analyzed using [RFC8085] and its Section 3.1.5 in
>       particular before launching the test session.....


Not sure if “using” is the right word but otherwise fine for me. Or you could have a separate sentence like:

“RFC8085 section 3.1.5 provides guidance on handling network load for UDP-based protocol. While the characteristic of test traffic depends on the test objective, it is highly recommended to say in the limits as provided in RFC8085.”

Or something similar…

BCP is the same maturity level as PS. So it wouldn’t be a downref. However, I think having this as informational ref is fine.

Mirja



>
> Regards,
> Greg
>
> On Mon, Jul 8, 2019 at 2:37 AM Mirja Kuehlewind <ietf@kuehlewind.net<mailto:ietf@kuehlewind.net>> wrote:
> Hi Greg,
>
> Thanks a lot for you reply. Changes are good. I wonder if it would be useful to provide a reference to RFC8085 because it has a lot of information about congestion control of UDP based traffic? It recommends to send not more than 1 packet per 3 seconds (if RTT is unknown). I guess it doesn’t make sense to require this for testing traffic, however, it could maybe still be a good recommendation? What do you think?
>
> Also I’ve just resend my review to the IPPM list, as I unfortunately cc’ed only the IPPM chairs instead of the whole list. Can you resend you proposed changes to the list, so other people are aware of these changes. Sorry for the unconvience.
>
> Mirja
>
>
> > On 6. Jul 2019, at 17:46, Greg Mirsky <gregimirsky@gmail.com<mailto:gregimirsky@gmail.com>> wrote:
> >
> > Hi Mirja,
> > thank you for your thorough review, very pointed and helpful comments. Please find my responses in-lined and tagged GIM>>. Attached the diff.
> >
> > Regards,
> > Greg
> >
> > On Thu, Jul 4, 2019 at 9:10 AM Mirja Kuehlewind <ietf@kuehlewind.net<mailto:ietf@kuehlewind.net>> wrote:
> > Hi authors, hi all,
> >
> > Thanks for this well-written document and very good shepherd write-up! I would like discuss one point before I start IETF last call.
> >
> > I believe this document should say something about network load and congestion (control). OWAMP and TWAMP discuss quite a bit sender scheduling, however, as this is a simplified version, so I think it could at least be good to put a waring in this document that packet sending should be somehow rate limited. I know it might be hard to provide more concrete guidance but at least having some discussion or warning in this document could be good.
> > GIM>>  Thank you for your suggestion. Security Considerations section points to the fact that STAMP does not include control and management components:
> >    Because of the control
> >    and management of a STAMP test being outside the scope of this
> >    specification only the more general requirement is set:
> > adding the new text here:
> >       Load of STAMP test packets offered to a network MUST be carefully
> >       estimated, and the possible impact on the existing services MUST
> >       be thoroughly analyzed before launching the test session.
> >
> >
> > Another comment: You only say at the very end that a certain UDP port is used, which implies that STAMP runs over UDP. However, I think you should mention at the very beginning that this is a UDP-based protocol. Just to make things crystal clear.
> > GIM>> Adding the reference to "UDP transport" into the first sentence of Theory of  Operations section:
> >    STAMP Session-Sender transmits test packets over UDP transport toward STAMP Session-Reflector.
> >
> > Mirja
> >
> > P.S.:
> > Nit: s/This document defines active performance measurement test protocol/ This document defines an active performance measurement test protocol/
> > -> “an” missing
> > GIM>> Thank you. Done.
> > <Diff_ draft-ietf-ippm-stamp-06.txt - draft-ietf-ippm-stamp-07.....txt.html>
>
_______________________________________________
ippm mailing list
ippm@ietf.org<mailto:ippm@ietf.org>
https://www.ietf.org/mailman/listinfo/ippm<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_ippm&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=jFjYqNADrDEqVvXPflbULUsKg7B5HwREGTlXhcStmto&s=bPh6MiQMjWWYualzxQVH4MX9nVqjPthfyTAtd1XOYbE&e=>

_______________________________________________
ippm mailing list
ippm@ietf.org<mailto:ippm@ietf.org>
https://www.ietf.org/mailman/listinfo/ippm<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_ippm&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=jFjYqNADrDEqVvXPflbULUsKg7B5HwREGTlXhcStmto&s=bPh6MiQMjWWYualzxQVH4MX9nVqjPthfyTAtd1XOYbE&e=>