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

Rakesh Gandhi <rgandhi.ietf@gmail.com> Tue, 09 July 2019 13:11 UTC

Return-Path: <rgandhi.ietf@gmail.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 D02C0120152; Tue, 9 Jul 2019 06:11:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.702
X-Spam-Level:
X-Spam-Status: No, score=-0.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, PDS_NO_HELO_DNS=1.295, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 20vfFZSQHEfl; Tue, 9 Jul 2019 06:11:53 -0700 (PDT)
Received: from mail-lj1-x232.google.com (mail-lj1-x232.google.com [IPv6:2a00:1450:4864:20::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 39E2112012D; Tue, 9 Jul 2019 06:11:53 -0700 (PDT)
Received: by mail-lj1-x232.google.com with SMTP id 16so19469707ljv.10; Tue, 09 Jul 2019 06:11:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=9Qe2Zst86iGKCPo+80HvV+tc6ololdgTzPq/AyEVB3M=; b=eGzla3/iTtFkESWm2AxbfWzsLUiEDSehNLPt5XtXygRICslAifVM+EX7UIjtcGgwRr gNrbqf3RdoB6nqUsw1k6aavfKsXKpDphnTRsIZ9Mjg8lpF5+TP9cSNq8gB7lc9svvf23 tuAw3w8i9Hnc7hgJwpW4+KAifRg7MN+WOqpko9AZtYYk+qDgATI6lLO/JbqsLCoY/8Hq BjV42KMMxrr4LJ9KlED7veH3Wi9H9U7e/6m8cK6AyWqA5rKZ4yFeCzqhefwajXK8bYF2 hNldq9/57CYLFeBI+X4mutDHrfXWD0xrJRK3ppxu4VH6jNnwXQnIB/fXCeFPtUHKbujU ZhGQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=9Qe2Zst86iGKCPo+80HvV+tc6ololdgTzPq/AyEVB3M=; b=Z3CIg96TOrPQ+OtHFEpTDGHpXksETuy8PODBBFnznfap8/kP1PWgpoLlmErdty+gXB SZhZKXQFDU+uHHOsSauC1mwg6DEDAEJELGIfWL8Qj6ur521E6+xrsbiL8Krz0/61I96G wm4N8f1Cp0vR93GjUIizoq9qvb2zMdt4hmDkx4CNOxfqavQHxA++BFnvPjPFmDaVPDQ/ 6moQfc7btMYf8BwUm2iagF9KhvM+2Nbu3qGyLIeXfpF2k/wzCaGyA1j+IdjN0EuCQyOQ s/3qR9zka0xCGLWvqEInWeMT3gJ85NJETPv1OmO/O2ocjsSD/wm59VJY3iVFoiWtSo4W YbzA==
X-Gm-Message-State: APjAAAVm9XqUIJz9dr8gCV2ITQxTmCWlLe0E+fbXP/5CuEDDWm1KlwmI EwyhULSLy12gqbBmXrHrX2ZAKOeGQs7yCiW+2A==
X-Google-Smtp-Source: APXvYqwar0s6bvXF9GjQe10ADlogu6H89j0fnc4Xh9eBlaC065loBoyVMvYUVDCHOB5TMnqZL+Jx8kJOYqcASeUOsTI=
X-Received: by 2002:a2e:93c8:: with SMTP id p8mr13784845ljh.6.1562677911217; Tue, 09 Jul 2019 06:11:51 -0700 (PDT)
MIME-Version: 1.0
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>
In-Reply-To: <CA+RyBmW01TgyXPAk3OGhdKqDTszkf0KzT+dDVTdaEhFu7GA7-Q@mail.gmail.com>
From: Rakesh Gandhi <rgandhi.ietf@gmail.com>
Date: Tue, 9 Jul 2019 09:11:39 -0400
Message-ID: <CAMZsk6cEhTQ57PkGD4C8DbK1dCeYghe+x7nQMv4TOtqNhFYzbA@mail.gmail.com>
To: Greg Mirsky <gregimirsky@gmail.com>
Cc: Shahram Davari <shahram.davari@broadcom.com>, draft-ietf-ippm-stamp@ietf.org, IPPM Chairs <ippm-chairs@ietf.org>, Mirja Kuehlewind <ietf@kuehlewind.net>, IETF IPPM WG <ippm@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000cbe96c058d3f4de2"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/o48XxBwslMbwsPmcMh5928BgHOc>
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: Tue, 09 Jul 2019 13:11:57 -0000

Thanks Greg for the reply.

In this case, should the draft just state that the Session-Sender can
select destination UDP port number following the guidelines specified in
[RFC6335], instead of specifying following?

Thus STAMP Session-Sender MUST be able to send test
   packets to destination UDP port number from the Dynamic and/or
   Private Ports range 49152-65535, test management system should find a
   port number that both devices can use.

Thanks,

Rakesh


On Mon, Jul 8, 2019 at 10:07 PM Greg Mirsky <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>
> 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> 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> 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> 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>
>>>> wrote:
>>>>
>>>>> Hi Greg,
>>>>>
>>>>> See below.
>>>>>
>>>>> > On 8. Jul 2019, at 16:54, Greg Mirsky <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>
>>>>> 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>
>>>>> 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> 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
>>>> https://www.ietf.org/mailman/listinfo/ippm
>>>>
>>>>
>>>> _______________________________________________
>>> ippm mailing list
>>> ippm@ietf.org
>>> https://www.ietf.org/mailman/listinfo/ippm
>>>
>>