Subject: [ippm] Fwd: New Version Notification for draft-mirsky-ippm-stamp-00.txt

From: Greg Mirsky <[email-masked]>
Date: Mon, 16 Oct 2017 12:41:24 -0700

Dear All,
we've published the first version of STAMP ("Simple" Two-way Active
Measurement Protocol). Though it may be viewed as not really simple, but
STAMP is too catchy name to pass.
We greatly appreciate your reviews, comments, questions, and suggestions.
We hope to have good and productive on-list and at the IETF-100 meeting
discussion.

Kind regards,
Greg and Guo

---------- Forwarded message ----------
From: <[email-masked]>
Date: Fri, Oct 13, 2017 at 8:56 AM
Subject: New Version Notification for draft-mirsky-ippm-stamp-00.txt
To: Gregory Mirsky <[email-masked]>, Guo Jun <[email-masked]>

A new version of I-D, draft-mirsky-ippm-stamp-00.txt
has been successfully submitted by Greg Mirsky and posted to the
IETF repository.

Name:           draft-mirsky-ippm-stamp
Revision:       00
Title:          Simple Two-way Active Measurement Protocol
Document date:  2017-10-12
Group:          Individual Submission
Pages:          12
URL:            https://www.ietf.org/internet-drafts/draft-mirsky-ippm-
stamp-00.txt
Status:         https://datatracker.ietf.org/doc/draft-mirsky-ippm-stamp/
Htmlized:       https://tools.ietf.org/html/draft-mirsky-ippm-stamp-00
Htmlized:       https://datatracker.ietf.org/doc/html/draft-mirsky-ippm-
stamp-00

Abstract:
   This document describes a Two-way Active Measurement Protocol which
   enables measurement of both one-way and round-trip performance
   metrics like delay, delay variation and packet loss.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Henrik Nydell <[email-masked]>
Date: Thu, 26 Oct 2017 13:28:13 +0200

I did a quick glance through and there are some good things
- PTP timestamp as an option - Finally!
- Symmetric format
- TLV support for vendor options - May prove useful

Are you going to define how the encrypted and authenticated modes work, i.e
what encryption method and what type of authentication, or will you rely on
what was done for TWAMP and OWAMP? I haven't seen much use of the encrypted
mode out there in the field, probably because it puts load on the CPUs to
do the decryption and encryption, which may be sparse in supply in smaller
edge devices.

One useful addition would be if the Sender (and Reflector) could report
(maybe in some of the MBZ bits) if it is synchronized to
0) Free running
1) NTP
2) PTP
3) Other (GPS, PPS, Radio e t c)

Maybe some of these are already in the error estimate, but not all I
believe.

Also, if the responder could report timestamping method somehow
1) TX/RX Hardware Timestamp "close to wire"       <--- Most accurate
2) TX/RX Hardware Timestamp in recv/txm buffers  <--- Quite accurate
3) TX/RX Software Timestamp in recieve/transmit handler <--- Less accurate

On the IANA registered TLVs you are proposing to define, there are a couple
of parameters that are missing in TWAMP that could either go in as TLVs or
into the standard packet format, but then of course causing incompatibility
with existing reflectors which is not good.
- TOS (Diffserv CP) - This one is not possible to "measure" one-way with
TWAMP as the TOS field is just copied over at the Reflector. So errors in
DSCP configuration cannot be isolated to a specific direction.

- Destination/Source IP address, MAC address & Port (Can be used to detect
NAT in the Path if Reflector can report what it sees as Destination/Source
IP addresses, or detect routing changes close to the reflector, if source
mac as seen from reflector changes)

There are more ways the TLVs could be utilized, but I believe they have to
be standardized and possibly mandatory to support the standardized set,
otherwise vendor interoperability won't be able to use them of course. One
other area is within burst measurements, where TLVs could be defined to
contain burst information, so that the responder could build a burst
accordingly in the same way a sender did.

One other interresting TLV use case for my company in particular is for
multi-hop measurements where we hold a patent (
https://www.google.com/patents/EP2690823A1?cl=en) but there are certainly
other non-proprietary cases that this functionality will enable.

On Mon, Oct 16, 2017 at 9:41 PM, Greg Mirsky <[email-masked]> wrote:

> URL:            https://www.ietf.org/internet-
> drafts/draft-mirsky-ippm-stamp-00.txt
> Htmlized:       https://datatracker.ietf.org/
> doc/html/draft-mirsky-ippm-stamp-00
>
>
> Abstract:
> _______________________________________________
> ippm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ippm
>
>

-- 

Henrik Nydell

Sr Manager Global Strategy & Solutions

Cell

Email

Skype

+46 709845992

[email-masked] <[email-masked]>

h <http://linkedin.com/in/maekowalk>nydell

<http://accedian.com/> <http://blog.accedian.com/>
<https://www.linkedin.com/company/accedian-networks>
<https://twitter.com/Accedian>   <https://www.facebook.com/accedian>
<http://www.youtube.com/user/accedian>

-- 

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: Greg Mirsky <[email-masked]>
Date: Thu, 26 Oct 2017 11:38:40 -0700

Hi Henrik,
thank you for your thorough review and the most detailed and practical
comments and suggestions. Please find my answers and notes in-line tagged
GIM>>.

Regards,
Greg

> - TLV support for vendor options - May prove useful
GIM>> Thank you

>
> Are you going to define how the encrypted and authenticated modes work,
> i.e what encryption method and what type of authentication, or will you
> rely on what was done for TWAMP and OWAMP?
>
GIM>> We plan to address encrypted mode in future versions. Whether
authenticated mode is useful could be discussed as well. I think that STAMP
must support encrypted mode but I don't think that it will be on-wire
compatible with TWAMP encrypted mode.

> I haven't seen much use of the encrypted mode out there in the field,
> probably because it puts load on the CPUs to do the decryption and
> encryption, which may be sparse in supply in smaller edge devices.
>
GIM>> This is very useful information, thank you. Can add that TR-390 is
based on unencrypted mode as well.

> 3) Other (GPS, PPS, Radio e t c)
GIM>> Great idea, thank you.

> 3) TX/RX Software Timestamp in recieve/transmit handler <--- Less accurate
GIM>> We may look into mapping this and Synchronization Source to Error
Estimate values and standardize the mapping. Or have as Timestamp Source
TLV with distinct Synchronization Source and Timestamp Method fields.

>
> On the IANA registered TLVs you are proposing to define, there are a
> couple of parameters that are missing in TWAMP that could either go in as
> TLVs or into the standard packet format, but then of course causing
> incompatibility with existing reflectors which is not good.
GIM>> RFC 7750 extended TWAMP to provide DSCP monitoring mode. There was
attempt to use RFC 7750 to enable CoS test. I think that it may be easier
to achieve both with TLVs.

> mac as seen from reflector changes)
GIM>> I recall that TWAMP over NAT topic was brought in
draft-muthu-ippm-twamp-nat
<https://tools.ietf.org/html/draft-muthu-ippm-twamp-nat-00>. Perhaps single
TLV may cover all attributes.

> accordingly in the same way a sender did.
GIM>> Indeed, the intention is to create IANA registry for STAMP TLVs. I'm
not certain that some TLVs must be mandatory a I view only support of
TWAMP-compatible functions as mandatory for STAMP nodes. TLVs should not
prevent from performing what TWAMP-Test Reflector does.

> multi-hop measurements where we hold a patent (https://www.google.com/
> patents/EP2690823A1?cl=en) but there are certainly other non-proprietary
> cases that this functionality will enable.
>
GIM>> Thank you for the reference, will research and educate myself.

> +46 709845992 <+46%2070%20984%2059%2092>
>