Subject: [ippm] I-D Action: draft-ietf-ippm-alt-mark-04.txt

From: [email-masked]
Date: Wed, 01 Mar 2017 03:01:24 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IP Performance Metrics of the IETF.

        Title           : Alternate Marking method for passive performance monitoring
        Authors         : Giuseppe Fioccola
                          Alessandro Capello
                          Mauro Cociglio
                          Luca Castaldelli
                          Mach(Guoyi) Chen
                          Lianshu Zheng
                          Greg Mirsky
                          Tal Mizrahi
	Filename        : draft-ietf-ippm-alt-mark-04.txt
	Pages           : 30
	Date            : 2017-03-01

Abstract:
   This document describes a passive method to perform packet loss,
   delay and jitter measurements on live traffic.  This method is based
   on Alternate Marking (Coloring) technique.  A report on the
   operational experiment done at Telecom Italia is explained in order
   to give an example and show the method applicability.  This technique
   can be applied in various situations as detailed in this document.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-ippm-alt-mark/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-ippm-alt-mark-04

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-ippm-alt-mark-04

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.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Fioccola Giuseppe <[email-masked]>
Date: Wed, 1 Mar 2017 11:13:59 +0000

Hi All,
This new version of draft-ietf-ippm-alt-mark addresses comments received offline by Al Morton.
Specifically we have added a note in which we suggest to calculate a high percentile of the delay instead of the maximum.
The problem with maximum delay is that it is influenced by outliers and could be misleading.
In addition the reference to RFC 5481, particularly section 6.5, has been added.

Many Thanks to Al for the precious help,

Best Regards,

Giuseppe

-----Messaggio originale-----
Da: ippm [mailto:[email-masked]] Per conto di [email-masked]
Inviato: mercoledì 1 marzo 2017 12:01
A: [email-masked]
Cc: [email-masked]
Oggetto: [ippm] I-D Action: draft-ietf-ippm-alt-mark-04.txt

Abstract:

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.

_______________________________________________
ippm mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ippm

Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie.

This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only. Dissemination, copying, printing or use by anybody else is unauthorised. If you are not the intended recipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks.

---

From: Esteban Carisimo <[email-masked]>
Date: Wed, 1 Mar 2017 12:01:30 -0300

Giuseppe,

I do support your idea of incluing percentile since maximum values could 
be misleading. Moreover, it think it is actually a very good idea to 
include a suggestion instead of saying either one of the other is the 
right way of doing it. Altough the 99.9th percentile is included in a 
previous RFC, I was wondering if the 99.9th would be meaningful for 
every network or link. However, it think it is a nice way to start 
discussing about less sensitive parameters.

Esteban Carisimo
PhD student at CoNexDat (UBA-CONICET)
http://cnet.fi.uba.ar/esteban_carisimo/en

---

From: "MORTON, ALFRED C (AL)" <[email-masked]>
Date: Wed, 1 Mar 2017 15:23:16 +0000

Hi Esteban,

If you look through RFC 5481 [0], you'll find that the idea
of a "High Percentile" is included, based on the experience
that different networks, or applications running on the
networks, have different demands.  I've used 95, 99, and
99.9 depending on the circumstances, and applying this sort of 
statistic to packet transfer is fairly well understood 
(RFC 5481 was approved in 2009 after much discussion in the IPPM WG).

I also suggest RFC 2330, section 11.3 [1] which discusses the median
and nails-down the definition of percentile for IPPM use
(there is not a universally accepted definition of percentile,
three interpretations are possible and we narrow down to one).

These two references are a good starting point for any
further discussions.

regards,
Al

[0] https://tools.ietf.org/html/rfc5481

[1] https://tools.ietf.org/html/rfc2330#section-11.3

> -----Original Message-----
> From: ippm [mailto:[email-masked]] On Behalf Of Esteban Carisimo
> Sent: Wednesday, March 01, 2017 10:02 AM
> To: [email-masked]
> Subject: Re: [ippm] I: I-D Action: draft-ietf-ippm-alt-mark-04.txt
> 
> Giuseppe,
> 
> https://urldefense.proofpoint.com/v2/url?u=http-
> 3A__cnet.fi.uba.ar_esteban-5Fcarisimo_en&d=DQIF-g&c=LFYZ-
> o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=ksehRnxmKX5kd4QUQA2LrW6ZjOz
> zg7n7QhD2I_6-x1Q&s=PPIhAtN3WQfhupyqoUqHuNvJG_MDe-D5EizhWgisivY&e=
> 
> > Specifically we have added a note in which we suggest to calculate a
> high percentile of the delay instead of the maximum.
> > https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__datatracker.ietf.org_doc_draft-2Dietf-2Dippm-2Dalt-2Dmark_&d=DQIF-
> g&c=LFYZ-
> o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=ksehRnxmKX5kd4QUQA2LrW6ZjOz
> zg7n7QhD2I_6-x1Q&s=NufcoUHHeeBrUi4UwaX45c4POeZnMB_k4AHIARjLfyw&e=
> >
> > https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__tools.ietf.org_html_draft-2Dietf-2Dippm-2Dalt-2Dmark-2D04&d=DQIF-
> g&c=LFYZ-
> o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=ksehRnxmKX5kd4QUQA2LrW6ZjOz
> zg7n7QhD2I_6-x1Q&s=6WqdeohHv1UTz0U7nI6EgiPNiNNbO8lOsAbR9zEkXuM&e=
> >
> > https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_rfcdiff-3Furl2-3Ddraft-2Dietf-2Dippm-2Dalt-2Dmark-
> 2D04&d=DQIF-g&c=LFYZ-
> o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=ksehRnxmKX5kd4QUQA2LrW6ZjOz
> zg7n7QhD2I_6-x1Q&s=YJWiIGFs3NwrQ_3uBbY6wxgIpbS8DhfZ-WRHUVa5bdA&e=
> >
> >
> > 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.
> >
> > https://urldefense.proofpoint.com/v2/url?u=ftp-
> 3A__ftp.ietf.org_internet-2Ddrafts_&d=DQIF-g&c=LFYZ-
> o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=ksehRnxmKX5kd4QUQA2LrW6ZjOz
> zg7n7QhD2I_6-x1Q&s=hQVaU10JwTjqeUKjQTEf-yQChqJ6TBAytiZ9BnRvGRY&e=
> >
> > https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_mailman_listinfo_ippm&d=DQIF-g&c=LFYZ-
> o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=ksehRnxmKX5kd4QUQA2LrW6ZjOz
> zg7n7QhD2I_6-x1Q&s=NI1_8wEhMMMtb01UikJBgRnJOxNN_bJ1obtzRSL3pAs&e=
> >
> > Questo messaggio e i suoi allegati sono indirizzati esclusivamente
> alle persone indicate. La diffusione, copia o qualsiasi altra azione
> derivante dalla conoscenza di queste informazioni sono rigorosamente
> vietate. Qualora abbiate ricevuto questo documento per errore siete
> cortesemente pregati di darne immediata comunicazione al mittente e di
> provvedere alla sua distruzione, Grazie.
> >
> > This e-mail and any attachments is confidential and may contain
> privileged information intended for the addressee(s) only.
> Dissemination, copying, printing or use by anybody else is unauthorised.
> If you are not the intended recipient, please delete this message and
> any attachments and advise the sender by return e-mail, Thanks.
> >
> > https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_mailman_listinfo_ippm&d=DQIF-g&c=LFYZ-
> o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=ksehRnxmKX5kd4QUQA2LrW6ZjOz
> zg7n7QhD2I_6-x1Q&s=NI1_8wEhMMMtb01UikJBgRnJOxNN_bJ1obtzRSL3pAs&e=
> 
> https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_mailman_listinfo_ippm&d=DQIF-g&c=LFYZ-
> o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=ksehRnxmKX5kd4QUQA2LrW6ZjOz
> zg7n7QhD2I_6-x1Q&s=NI1_8wEhMMMtb01UikJBgRnJOxNN_bJ1obtzRSL3pAs&e=

---

From: Esteban Carisimo <[email-masked]>
Date: Wed, 1 Mar 2017 12:38:19 -0300

Hi Al,

Thank you so much for the references as well as giving me some context 
about the previous work of those RFCs.

You really pointed my question when you said you had used different high 
percentiles. That is exactly what I was thinking about, some people 
might be ending up using different percentiles. However, I do not see 
that as a drawback, I think you could learn from the experience of the 
operators but it would be necessary feedback from them.

I think the discussion included in the draft it is OK.

Regards,

Esteban Carisimo