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

[Greg Mirsky <[e-mail]>]

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

On Thu, Oct 26, 2017 at 4:28 AM, Henrik Nydell <[e-mail]> wrote:

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

>
> 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)
>
GIM>> Great idea, thank you.

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

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

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

>
> 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.
>
GIM>> Thank you for the reference, will research and educate myself.

>
>
> On Mon, Oct 16, 2017 at 9:41 PM, Greg Mirsky <[e-mail]>
> wrote:
>
>> 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: <[e-mail]>
>> Date: Fri, Oct 13, 2017 at 8:56 AM
>> Subject: New Version Notification for draft-mirsky-ippm-stamp-00.txt
>> To: Gregory Mirsky <[e-mail]>, Guo Jun <[e-mail]>
>>
>>
>>
>> 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
>>
>>
>>
>> _______________________________________________
>> ippm mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/ippm
>>
>>
>
>
> --
>
>
> [image: Accedian.com]
>
> Henrik Nydell
>
> Sr Manager Global Strategy & Solutions
>
> Cell
>
> Email
>
> Skype
>
> [phone] <+46%2070%20984%2059%2092>
>
> [e-mail] <[e-mail]>
>
> 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.
>