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

From: Greg Mirsky <[email-masked]>
Date: Mon, 8 Jul 2019 07:32:02 -0700

Now with IPPM WG list included.
The proposed updates to the STAMP base specification with the diff attached.

Regards,
Greg

On Sat, Jul 6, 2019 at 8:46 AM Greg Mirsky <[email-masked]> 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 <[email-masked]>
> 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.
>

---

From: Greg Mirsky <[email-masked]>
Date: Mon, 8 Jul 2019 07:54:55 -0700

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.

Regards,
Greg

On Mon, Jul 8, 2019 at 2:37 AM Mirja Kuehlewind <[email-masked]> 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 <[email-masked]> wrote:
> >
> > Hi Mirja,
> > <Diff_ draft-ietf-ippm-stamp-06.txt - draft-ietf-ippm-stamp-07.txt.html>
>
>

---

From: Mirja Kuehlewind <[email-masked]>
Date: Mon, 8 Jul 2019 17:58:51 +0200

Hi Greg,

See below.

> On 8. Jul 2019, at 16:54, Greg Mirsky <[email-masked]> 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:

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

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

---

From: Greg Mirsky <[email-masked]>
Date: Mon, 8 Jul 2019 10:17:47 -0700

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

> > 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:
> “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
> >
> > 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
> >
> >
> > > Thanks for this well-written document and very good shepherd write-up!
> I would like discuss one point before I start IETF last call.
> > >
> > > 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.

---

From: Shahram Davari <[email-masked]>
Date: Mon, 8 Jul 2019 14:02:02 -0700

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?
2) What is the benefit of STAMO compared to TWAMP?
3) Why is there so much MBZ byte?

Thx
Shahram

> On Jul 8, 2019, at 10:17 AM, Greg Mirsky <[email-masked]> wrote:
> 
> Hi Mirja,
> 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 <[email-masked] <mailto:[email-masked]>> wrote:
> Hi Greg,
> 
> See below.
> 
> > On 8. Jul 2019, at 16:54, Greg Mirsky <[email-masked] <mailto:[email-masked]>> wrote:
> > 
> > Hi Mirja,
> >       particular before launching the test session..
> 
> 
> > On Mon, Jul 8, 2019 at 2:37 AM Mirja Kuehlewind <[email-masked] <mailto:[email-masked]>> wrote:
> > Hi Greg,
> > 
> > > On 6. Jul 2019, at 17:46, Greg Mirsky <[email-masked] <mailto:[email-masked]>> wrote:
> > > 
> > > Hi Mirja,
> > > On Thu, Jul 4, 2019 at 9:10 AM Mirja Kuehlewind <[email-masked] <mailto:[email-masked]>> wrote:
> > > Hi authors, hi all,
> > > 
> > > <Diff_ draft-ietf-ippm-stamp-06.txt - draft-ietf-ippm-stamp-07..txt.html>
> > 
> 
> _______________________________________________
> ippm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ippm

---

From: Greg Mirsky <[email-masked]>
Date: Mon, 8 Jul 2019 16:14:37 -0700

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

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

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.

>> > > 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
>> > >
>> > > Thanks for this well-written document and very good shepherd
>> write-up! I would like discuss one point before I start IETF last call.
>> > >

---

From: Rakesh Gandhi <[email-masked]>
Date: Mon, 8 Jul 2019 20:09:28 -0400

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

> Hi Shahram,
> thank you for the review and questions. Please find my answers below
> tagged GIM>>.
>
> Regards,
> Greg
>
> UDP port number.. STAMP may use destination UDP port number from the
> Dynamic and/or Private Ports range 49152-65535.
>
>>> >       particular before launching the test session...
>>>
>>>
>>> > > 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
>>> > > 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
>>> > > GIM>> Adding the reference to "UDP transport" into the first
>>> sentence of Theory of  Operations section:
>>> > > <Diff_ draft-ietf-ippm-stamp-06.txt -
>>> draft-ietf-ippm-stamp-07...txt.html>
>>> >
>>>

---

From: Greg Mirsky <[email-masked]>
Date: Mon, 8 Jul 2019 19:07:37 -0700

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 <[email-masked]> 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 2:02 PM Shahram Davari <
>> [email-masked]> wrote:
>>
>>> HI Greg
>>>
>> 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

---

From: Rakesh Gandhi <[email-masked]>
Date: Tue, 9 Jul 2019 09:11:39 -0400

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

>>>>> > 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
>>>>> > 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
>>>>> > > I believe this document should say something about network load
>>>>> and congestion (control). OWAMP and TWAMP discuss quite a bit sender

---

From: Rakesh Gandhi <[email-masked]>
Date: Tue, 9 Jul 2019 09:27:30 -0400

Hi Greg,
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
(27 ( or > 29) vs. 30). 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?

Thanks,
Rakesh

---

From: Shahram Davari <[email-masked]>
Date: Tue, 9 Jul 2019 09:53:24 -0700

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 <[email-masked]> 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 <[email-masked] <mailto:[email-masked]>> wrote:
> HI Greg
> 
> 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.
> 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. 
> 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 <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> Hi Mirja,
>> [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/ippm <https://www.ietf.org/mailman/listinfo/ippm>
>

---

From: Greg Mirsky <[email-masked]>
Date: Tue, 9 Jul 2019 10:16:58 -0700

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

>>> draft-ietf-ippm-stamp-07..txt.html>
>>> >
>>>

---

From: Shahram Davari <[email-masked]>
Date: Tue, 9 Jul 2019 11:20:48 -0700

Thanks Greg,

How about the Authenticated mode packet? should the session start as unauthenticated first?

Thx
Shahram

> On Jul 9, 2019, at 10:16 AM, Greg Mirsky <[email-masked]> wrote:
> 
> Hi Shahram,
> 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 <[email-masked] <mailto:[email-masked]>> wrote:
> Thanks Greg,
> 
>> On Jul 8, 2019, at 4:14 PM, Greg Mirsky <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> Hi Shahram,

---

From: Greg Mirsky <[email-masked]>
Date: Tue, 9 Jul 2019 11:56:34 -0700

Hi Shahram,
and another great question!
Yes, there are open issues with the authenticated mode. But, on the other
hand, we don't think that STAMP is required to be able to interoperate with
TWAMP-Test node in the authenticated mode. Thus, the task of using an
extension in STAMP authenticated mode is somewhat less challenging. What do
you think?

Regards,
Greg

---

From: Mirja Kuehlewind <[email-masked]>
Date: Wed, 10 Jul 2019 13:11:15 +0200

Hi Greg, hi Rakesh,

I’m just happen to review the turnbis document which has this text: 

"In all cases, the server SHOULD only allocate ports from the range
   49152 - 65535 (the Dynamic and/or Private Port range [Port-Numbers]),
   unless the TURN server application knows, through some means not
   specified here, that other applications running on the same host as
   the TURN server application will not be impacted by allocating ports
   outside this range.  This condition can often be satisfied by running
   the TURN server application on a dedicated machine and/or by
   arranging that any other applications on the machine allocate ports
   before the TURN server application starts.”

I think something similar could also make sense for STAMP?

The MUST in the text below seems quite restrictive also to me.

Mirja

> On 9. Jul 2019, at 15:11, Rakesh Gandhi <[email-masked]> wrote:
> 
> 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?
> 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:
> 
> 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
> 
> 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 2:02 PM Shahram Davari <[email-masked]> wrote:
> HI Greg
> 
> 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.
> 	• 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. 
>> > > <Diff_ draft-ietf-ippm-stamp-06.txt - draft-ietf-ippm-stamp-07...txt.html>
>> > 
>>

---

From: Henrik Nydell <[email-masked]>
Date: Wed, 10 Jul 2019 15:51:56 +0200

Just keep in mind that in a typical TWAMP deployment today, which will
apply to STAMP eventually, the user typically runs the tests in a private
network and thus has control of what protocols run there, and should be
allowed to use any UDP source and destination ports as required. This to be
able to have simple firewall rules. I dont believe it is up to STAMP to put
limitations here, recommendations are good but careful with MUSTs.

>From my experience, 30% of users use destination port 862 UDP for TWAMP
light (same port number as is used for Twamp control TCP packets), the rest
typically a port of 4000 or higher. Source ports are common in the ranges
10000 upwards. This has been seen across many vendors of IP PM.

As a side note,
To create unique 4-tuples in a single TWAMP light responder, the UDP source
port is typically increased at the sender if there is more than one test
session between the sender-responder pair. Reason is that TOS(DSCP) is not
a good candidate for 5-tuple qualification due to DSCP may be erroneously
configured in the network, and for example always be 0 at the responder,
this is something TWAMP/STAMP want to detect/report, and not rely on for
session identification.

On Wed, 10 Jul 2019, 13:11 Mirja Kuehlewind, <[email-masked]> wrote:

> > 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
> >
> >       • improve extensibility of IP performance monitoring tool to
> support measurements, testing of new metrics and parameters, e.g.,
> consistency of CoS in the network.

-- 

Avis de confidentialité

Les
 informations contenues dans le présent 
message et dans toute pièce qui 
lui est jointe sont confidentielles et 
peuvent être protégées par le 
secret professionnel. Ces informations sont 
à l’usage exclusif de son ou
 de ses destinataires. Si vous recevez ce 
message par erreur, veuillez 
s’il vous plait communiquer immédiatement 
avec l’expéditeur et en 
détruire tout exemplaire. De plus, il vous est 
strictement interdit de 
le divulguer, de le distribuer ou de le reproduire 
sans l’autorisation 
de l’expéditeur. Merci.

Confidentiality notice

This

 e-mail message and any attachment hereto contain confidential 
information 
which may be privileged and which is intended for the 
exclusive use of its 
addressee(s). If you receive this message in error,
 please inform sender 
immediately and destroy any copy thereof. 
Furthermore, any disclosure, 
distribution or copying of this message 
and/or any attachment hereto 
without the consent of the sender is 
strictly prohibited. Thank you.

---

From: "Rakesh Gandhi (rgandhi)" <[email-masked]>
Date: Wed, 10 Jul 2019 15:31:16 +0000

Thanks Mirja and Henrik.

FWIW, I am aware of an implementation of TWAMP-Light that does not put such range limit on the destination UDP port and it is up to the operator to provision an appropriate port number.

Thanks,
Rakesh

From: ippm <[email-masked]> on behalf of Henrik Nydell <[email-masked]>
Date: Wednesday, July 10, 2019 at 9:52 AM
To: Mirja Kuehlewind <[email-masked]>
Cc: IPPM Chairs <[email-masked]>, IETF IPPM WG <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [ippm] AD review of draft-ietf-ippm-stamp

Just keep in mind that in a typical TWAMP deployment today, which will apply to STAMP eventually, the user typically runs the tests in a private network and thus has control of what protocols run there, and should be allowed to use any UDP source and destination ports as required. This to be able to have simple firewall rules. I dont believe it is up to STAMP to put limitations here, recommendations are good but careful with MUSTs.

From my experience, 30% of users use destination port 862 UDP for TWAMP light (same port number as is used for Twamp control TCP packets), the rest typically a port of 4000 or higher. Source ports are common in the ranges 10000 upwards. This has been seen across many vendors of IP PM.

As a side note,
To create unique 4-tuples in a single TWAMP light responder, the UDP source port is typically increased at the sender if there is more than one test session between the sender-responder pair. Reason is that TOS(DSCP) is not a good candidate for 5-tuple qualification due to DSCP may be erroneously configured in the network, and for example always be 0 at the responder, this is something TWAMP/STAMP want to detect/report, and not rely on for session identification.

On Wed, 10 Jul 2019, 13:11 Mirja Kuehlewind, <[email-masked]<mailto:[email-masked]>> wrote:
Hi Greg, hi Rakesh,

Mirja

> On 9. Jul 2019, at 15:11, Rakesh Gandhi <[email-masked]<mailto:[email-masked]>> wrote:
>
> On Mon, Jul 8, 2019 at 10:07 PM Greg Mirsky <[email-masked]<mailto:[email-masked]>> wrote:
> Hi Rakesh,
> On Mon, Jul 8, 2019 at 5:09 PM Rakesh Gandhi <[email-masked]<mailto:[email-masked]>> wrote:
> Hi Greg,
>
> On Mon, Jul 8, 2019 at 7:20 PM Greg Mirsky <[email-masked]<mailto:[email-masked]>> wrote:
> Hi Shahram,
> On Mon, Jul 8, 2019 at 2:02 PM Shahram Davari <[email-masked]<mailto:[email-masked]>> wrote:
> HI Greg
>
>> On Jul 8, 2019, at 10:17 AM, Greg Mirsky <[email-masked]<mailto:[email-masked]>> wrote:
>>
>> Hi Mirja,
>> On Mon, Jul 8, 2019 at 8:58 AM Mirja Kuehlewind <[email-masked]<mailto:[email-masked]>> wrote:
>> Hi Greg,
>>
>> See below.
>>
>> > On 8. Jul 2019, at 16:54, Greg Mirsky <[email-masked]<mailto:[email-masked]>> wrote:
>> >
>> > Hi Mirja,
>> > On Mon, Jul 8, 2019 at 2:37 AM Mirja Kuehlewind <[email-masked]<mailto:[email-masked]>> wrote:
>> > Hi Greg,
>> >
>> > > On 6. Jul 2019, at 17:46, Greg Mirsky <[email-masked]<mailto:[email-masked]>> wrote:
>> > >
>> > > Hi Mirja,
>> > > On Thu, Jul 4, 2019 at 9:10 AM Mirja Kuehlewind <[email-masked]<mailto:[email-masked]>> 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..
>> > >
>> [email-masked]<mailto:[email-masked]>
> [email-masked]<mailto:[email-masked]>

Avis de confidentialité

Les informations contenues dans le présent message et dans toute pièce qui lui est jointe sont confidentielles et peuvent être protégées par le secret professionnel. Ces informations sont à l’usage exclusif de son ou de ses destinataires. Si vous recevez ce message par erreur, veuillez s’il vous plait communiquer immédiatement avec l’expéditeur et en détruire tout exemplaire. De plus, il vous est strictement interdit de le divulguer, de le distribuer ou de le reproduire sans l’autorisation de l’expéditeur. Merci.

Confidentiality notice

This e-mail message and any attachment hereto contain confidential information which may be privileged and which is intended for the exclusive use of its addressee(s). If you receive this message in error, please inform sender immediately and destroy any copy thereof. Furthermore, any disclosure, distribution or copying of this message and/or any attachment hereto without the consent of the sender is strictly prohibited. Thank you.

---

From: Henrik Nydell <[email-masked]>
Date: Wed, 10 Jul 2019 17:32:55 +0200

Yes Rakesh, this is what most, if not all, existing implementations do.
There is no restriction on which ports you use, but left to the operators
to select.

On Wed, Jul 10, 2019 at 5:31 PM Rakesh Gandhi (rgandhi) <[email-masked]>
wrote:

> Thanks Mirja and Henrik.
>
>
>
> FWIW, I am aware of an implementation of TWAMP-Light that does not put
> such range limit on the destination UDP port and it is up to the operator
> to provision an appropriate port number.
>
>
>
> Thanks,
>
> Rakesh
>
>
>
>
>
> *From: *ippm <[email-masked]> on behalf of Henrik Nydell <
> [email-masked]>
> *Date: *Wednesday, July 10, 2019 at 9:52 AM
> *To: *Mirja Kuehlewind <[email-masked]>
> *Cc: *IPPM Chairs <[email-masked]>, IETF IPPM WG <[email-masked]>, "
> [email-masked]" <[email-masked]>
> *Subject: *Re: [ippm] AD review of draft-ietf-ippm-stamp
>
>
>
> To create unique 4-tuples in a single TWAMP light responder, the UDP
> source port is typically increased at the sender if there is more than one
> test session between the sender-responder pair. Reason is that TOS(DSCP) is
> not a good candidate for 5-tuple qualification due to DSCP may be
> erroneously configured in the network, and for example always be 0 at the
> responder, this is something TWAMP/STAMP want to detect/report, and not
> rely on for session identification.
>
>
>
> write-up! I would like discuss one point before I start IETF last call..
> >> > >
> Les informations contenues dans le présent message et dans toute pièce qui
> lui est jointe sont confidentielles et peuvent être protégées par le secret
> professionnel. Ces informations sont à l’usage exclusif de son ou de ses
> destinataires. Si vous recevez ce message par erreur, veuillez s’il vous
> plait communiquer immédiatement avec l’expéditeur et en détruire tout
> exemplaire. De plus, il vous est strictement interdit de le divulguer, de
> le distribuer ou de le reproduire sans l’autorisation de l’expéditeur.
> Merci.
>
> Confidentiality notice
>
> This e-mail message and any attachment hereto contain confidential
> information which may be privileged and which is intended for the exclusive
> use of its addressee(s). If you receive this message in error, please
> inform sender immediately and destroy any copy thereof. Furthermore, any
> disclosure, distribution or copying of this message and/or any attachment
> hereto without the consent of the sender is strictly prohibited. Thank you.
>

-- 
--
*Henrik Nydell*
*Sr Product Manager*
1.866.685.8181
[email-masked]
<http://accedian.com>
<https://www.facebook.com/accedian/>  <https://twitter.com/Accedian>
<https://www.linkedin.com/company/accedian-networks?originalSubdomain=ca>
<http://www.accedian.com>
*accedian.com <http://accedian.com>*

-- 

Avis de confidentialité

Les

Confidentiality notice

This

---

From: "Rakesh Gandhi (rgandhi)" <[email-masked]>
Date: Wed, 10 Jul 2019 17:57:31 +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 <[email-masked]> on behalf of Greg Mirsky <[email-masked]>
Date: Tuesday, July 9, 2019 at 1:17 PM
To: Shahram Davari <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, IPPM Chairs <[email-masked]>, Mirja Kuehlewind <[email-masked]>, IETF IPPM WG <[email-masked]>
Subject: Re: [ippm] AD review of draft-ietf-ippm-stamp

Hi Shahram,

Regards,
Greg

On Tue, Jul 9, 2019 at 9:53 AM Shahram Davari <[email-masked]<mailto:[email-masked]>> wrote:
Thanks Greg,

Thx
Shahram

On Jul 8, 2019, at 4:14 PM, Greg Mirsky <gregimirsky@gmail..com<mailto:[email-masked]>> wrote:

Hi Shahram,

Regards,
Greg

  *   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

Hi Mirja,

Regards,
Greg

See below.

Or something similar…

Mirja

---

From: Greg Mirsky <[email-masked]>
Date: Wed, 10 Jul 2019 16:00:59 -0700

Hi Rakesh,
yes, you're right. I've responded to your thoughtful questions but was late
to upload the updated version of the draft. Will do that as soon as I can.

Regards,
Greg

On Wed, Jul 10, 2019 at 10:57 AM Rakesh Gandhi (rgandhi) <[email-masked]>
wrote:

> 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 <[email-masked]> on behalf of Greg Mirsky <
> [email-masked]>
> *Date: *Tuesday, July 9, 2019 at 1:17 PM
> *To: *Shahram Davari <[email-masked]>
> *Cc: *"[email-masked]" <[email-masked]>,
> IPPM Chairs <[email-masked]>, Mirja Kuehlewind <[email-masked]>,
> IETF IPPM WG <[email-masked]>
> On Jul 8, 2019, at 4:14 PM, Greg Mirsky <gregimirsky@gmail..com
> <[email-masked]>> wrote:
>
>
>
> Hi Shahram,
>