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

[Henrik Nydell <[e-mail]>]

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 <[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]

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