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

"Rakesh Gandhi (rgandhi)" <rgandhi@cisco.com> Wed, 10 July 2019 17:57 UTC

Return-Path: <rgandhi@cisco.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 AD678120656; Wed, 10 Jul 2019 10:57:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.499
X-Spam-Level:
X-Spam-Status: No, score=-14.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=GYRaNV4b; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=TBSFg/mj
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 k__bzC_FKYe0; Wed, 10 Jul 2019 10:57:39 -0700 (PDT)
Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35429120666; Wed, 10 Jul 2019 10:57:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=39519; q=dns/txt; s=iport; t=1562781458; x=1563991058; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=8hCazZYmFJrAx81hriqaEY6PmkUgIIenvodZ4vyMdts=; b=GYRaNV4bU8HrPYyiOoTNFuDqcRf6mra8nXGctkIv79EOWhjk4PVJqm1R x/ZZTksvOiFpLt7lIxTJZM9LFSdI/hQBFr+29CshcgP4ycOvBucsPIiZE a9ctAJtYqtyoVAA33dVWH66UpFjM9lhDVNDl0hieeic86PmRIq08WEDWa A=;
IronPort-PHdr: =?us-ascii?q?9a23=3AFvC+Jxyq3TzQberXCy+N+z0EezQntrPoPwUc9p?= =?us-ascii?q?sgjfdUf7+++4j5YhSN/u1j2VnOW4iTq+lJjebbqejBYSQB+t7A1RJKa5lQT1?= =?us-ascii?q?kAgMQSkRYnBZufBkT9IP7rRyc7B89FElRi+iLzPA=3D=3D?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AoAAAOJiZd/5xdJa1lGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBVgIBAQEBCwGBFC9QA2pVIAQLKIQcg0cDjkaCNiWJT415glI?= =?us-ascii?q?DVAkBAQEMAQEYAQoKAgEBhEACF4I3IzcGDgEDAQEEAQECAQVthTwMhUoBAQE?= =?us-ascii?q?BAgEBARARBAYTAQEsCwEECwIBCBEDAQIBIAcDAgICHwYLFAkIAgQBDQUigwA?= =?us-ascii?q?BgR1NAw4PAQIMomwCgTiIYHF/M4J5AQEFhQcNC4ISAwaBNAGLXheBQD+BESc?= =?us-ascii?q?ME4JMPoIaRwEBgTo1CQkMAQkCglIygiaOcoR9iGmNQkAJAoIZkBODdBuCLIc?= =?us-ascii?q?ihAyGGIQQjGVLiTaODAIEAgQFAg4BAQWBZiKBWHAVOyoBgkGBSXiDcYUUhT9?= =?us-ascii?q?ygSmMLIJSAQE?=
X-IronPort-AV: E=Sophos;i="5.63,475,1557187200"; d="scan'208,217";a="580914030"
Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 10 Jul 2019 17:57:36 +0000
Received: from XCH-ALN-008.cisco.com (xch-aln-008.cisco.com [173.36.7.18]) by rcdn-core-5.cisco.com (8.15.2/8.15.2) with ESMTPS id x6AHvaMY000494 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 10 Jul 2019 17:57:36 GMT
Received: from xhs-aln-003.cisco.com (173.37.135.120) by XCH-ALN-008.cisco.com (173.36.7.18) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 10 Jul 2019 12:57:35 -0500
Received: from xhs-rcd-001.cisco.com (173.37.227.246) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 10 Jul 2019 12:57:34 -0500
Received: from NAM03-BY2-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Wed, 10 Jul 2019 12:57:34 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=8hCazZYmFJrAx81hriqaEY6PmkUgIIenvodZ4vyMdts=; b=TBSFg/mjgfmzlJZowXOYRCXN78eoCKia1EGK8ORkOcEFdlYzWtagJ0LBlu8uWak0J6j5I45wKq/fcylGe/oc5T9xixwXWMbbfqfogLf1TdeMzTYYD2ggKXEBuEG6RRhs8/LSHKU7PM73HVDrgl2qHCJUezjQ1z7UgDOjqAeunwo=
Received: from SN6PR11MB3278.namprd11.prod.outlook.com (52.135.109.11) by SN6PR11MB3102.namprd11.prod.outlook.com (52.135.126.204) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2052.19; Wed, 10 Jul 2019 17:57:31 +0000
Received: from SN6PR11MB3278.namprd11.prod.outlook.com ([fe80::5a3:55a2:2fb2:6810]) by SN6PR11MB3278.namprd11.prod.outlook.com ([fe80::5a3:55a2:2fb2:6810%4]) with mapi id 15.20.2052.020; Wed, 10 Jul 2019 17:57:31 +0000
From: "Rakesh Gandhi (rgandhi)" <rgandhi@cisco.com>
To: Greg Mirsky <gregimirsky@gmail.com>, Shahram Davari <shahram.davari@broadcom.com>
CC: "draft-ietf-ippm-stamp@ietf.org" <draft-ietf-ippm-stamp@ietf.org>, "IPPM Chairs" <ippm-chairs@ietf.org>, Mirja Kuehlewind <ietf@kuehlewind.net>, "IETF IPPM WG" <ippm@ietf.org>
Thread-Topic: [ippm] AD review of draft-ietf-ippm-stamp
Thread-Index: AQHVNZ0+7z5WSZ7weEqWcphMhijoKabA4NeAgAAWDoCAAD6nAIAAJQyAgAEn0gCAAAaVAIABWpmA
Date: Wed, 10 Jul 2019 17:57:31 +0000
Message-ID: <A8DD6099-2473-4DBD-B592-57B2B1C67FCA@cisco.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> <F7F3E842-01B1-4DFD-BFA3-D9DDBCED7D79@broadcom.com> <CA+RyBmUcMEjOwCt_DjsbYbB1zSTx9d5_Va2kcmxpFUQmXQ7gvA@mail.gmail.com>
In-Reply-To: <CA+RyBmUcMEjOwCt_DjsbYbB1zSTx9d5_Va2kcmxpFUQmXQ7gvA@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.10.b.190609
authentication-results: spf=none (sender IP is ) smtp.mailfrom=rgandhi@cisco.com;
x-originating-ip: [2001:420:c0c4:1005::8]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 306d38d5-3373-4e9e-89b2-08d705601463
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:SN6PR11MB3102;
x-ms-traffictypediagnostic: SN6PR11MB3102:
x-ms-exchange-purlcount: 3
x-microsoft-antispam-prvs: <SN6PR11MB3102CA5144F495DEBAE8D711BFF00@SN6PR11MB3102.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0094E3478A
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(979002)(4636009)(346002)(39860400002)(136003)(366004)(376002)(396003)(189003)(199004)(54094003)(53754006)(68736007)(6116002)(446003)(2616005)(99286004)(33656002)(256004)(4326008)(606006)(11346002)(76116006)(2906002)(81166006)(14444005)(476003)(229853002)(790700001)(14454004)(486006)(71190400001)(71200400001)(6486002)(54906003)(54896002)(53546011)(9326002)(478600001)(6512007)(66446008)(66476007)(53936002)(66556008)(6246003)(236005)(6306002)(102836004)(66946007)(91956017)(81156014)(8676002)(186003)(64756008)(110136005)(86362001)(25786009)(46003)(8936002)(6436002)(58126008)(5660300002)(966005)(5024004)(6506007)(76176011)(316002)(36756003)(7736002)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1101; SCL:1; SRVR:SN6PR11MB3102; H:SN6PR11MB3278.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: CKprp0K+CW68VaUT2hLAWR5qg1eP3hta6RBM1K6RZlIlGZN+7gTfadoZSbGz9cZrxZ7oiPuQI1CsTthdVtb3Z2HKfJhoUFLAh87l90Z/8RkOELPk3N6PTUx0PUTvUJeFFAxOYD7sAmtobCGLtnOwFWebQbduCJv3WkaOX2qkZPozhE/U0LB2q1fKajx/QwBbaewLsMeAS2p4R8L3yuTl1Ve8glis3tYZUPb43aRI7UV63iI29NIC8hXs/bXJ0aTmEvOi/snfxVZ+pxyxYgOO1SoVbd5FmUZqLcVPHAu7LzJZjPk7eqIgH6/e5SQZOlK4qW5bsiVFwuod9lY1kophuDQZoOg4uc9rjJdhpqbHDDJ4FsvpeVuWwdOhGNUpSVDCkuTzrGNXoEeHy4xeS6JZTL5iXTk5hTp8Vugs6Su/NZE=
Content-Type: multipart/alternative; boundary="_000_A8DD609924734DBDB59257B2B1C67FCAciscocom_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 306d38d5-3373-4e9e-89b2-08d705601463
X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Jul 2019 17:57:31.1752 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: rgandhi@cisco.com
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR11MB3102
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.18, xch-aln-008.cisco.com
X-Outbound-Node: rcdn-core-5.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/0VXgV1STm3COaLRtmw-Q6ULcepA>
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: Wed, 10 Jul 2019 17:57:44 -0000

Hi Greg,

I do not see the procedure you mentioned below in the draft. There is only one sentence for TLV in the draft as below.

And if any of TLV-based STAMP extensions are used, the TWAMP Light Session-Reflector will view them as Packet Padding field.

Am I missing something?

Thanks,
Rakesh


From: ippm <ippm-bounces@ietf.org> on behalf of Greg Mirsky <gregimirsky@gmail.com>
Date: Tuesday, July 9, 2019 at 1:17 PM
To: Shahram Davari <shahram.davari@broadcom.com>
Cc: "draft-ietf-ippm-stamp@ietf.org" <draft-ietf-ippm-stamp@ietf.org>rg>, IPPM Chairs <ippm-chairs@ietf.org>rg>, Mirja Kuehlewind <ietf@kuehlewind.net>et>, IETF IPPM WG <ippm@ietf.org>
Subject: Re: [ippm] AD review of draft-ietf-ippm-stamp

Hi Shahram,
excellent question, thank you!
When using STAMP extensions, STAMP Session-Sender must use the basic STAMP test packet followed by a TLV. A STAMP Session-Reflector is expected to compare the value in the Length field of the UDP header with the length of the basic STAMP test packet (44 octets). If the difference is larger than the length of the UDP header, then the Session-Reflector should process STAMP TLVs following the basic STAMP test packet.

Regards,
Greg

On Tue, Jul 9, 2019 at 9:53 AM Shahram Davari <shahram.davari@broadcom.com<mailto:shahram.davari@broadcom.com>> wrote:
Thanks Greg,

How does the receiver distinguish between TWAMP and STAMP if they use the same UDP Port number?

Thx
Shahram


On Jul 8, 2019, at 4:14 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