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

[Esteban Carisimo <[e-mail]>]

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
PhD student at CoNexDat (UBA-CONICET)
http://cnet.fi.uba.ar/esteban_carisimo/en

El 1/3/17 a las 12:23, MORTON, ALFRED C (AL) escribió:
> 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:[e-mail]] On Behalf Of Esteban Carisimo
>> Sent: Wednesday, March 01, 2017 10:02 AM
>> To: [e-mail]
>> Subject: Re: [ippm] I: I-D Action: draft-ietf-ippm-alt-mark-04.txt
>>
>> 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)
>> 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=
>>
>> El 1/3/17 a las 8:13, Fioccola Giuseppe escribió:
>>> 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:[e-mail]] Per conto di internet-
>> [e-mail]
>>> Inviato: mercoledì 1 marzo 2017 12:01
>>> A: [e-mail]
>>> Cc: [e-mail]
>>> Oggetto: [ippm] I-D Action: draft-ietf-ippm-alt-mark-04.txt
>>>
>>>
>>> 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://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=
>>> There's also a htmlized version available at:
>>> 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=
>>> A diff from the previous version is available at:
>>> 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.
>>> Internet-Drafts are also available by anonymous FTP at:
>>> 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=
>>> _______________________________________________
>>> ippm mailing list
>>> [e-mail]
>>> 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.
>>> _______________________________________________
>>> ippm mailing list
>>> [e-mail]
>>> 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=
>>
>> _______________________________________________
>> ippm mailing list
>> [e-mail]
>> 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=