Re: [ippm] R: FW: New Version Notification for draft-chen-ippm-coloring-based-ipfpm-framework-05.txt

["J. Ignacio Alvarez-Hamelin" <[e-mail]>]

Hi Fioccola, All

You are right about the mean and its simplicity. Nevertheless, here it is 
a reference to compute median without memory:

   Jain, Raj, and Imrich Chlamtac. "The P 2 algorithm for dynamic
   calculation of quantiles and histograms without storing observations."
   Communications of the ACM 28.10 (1985): 1076-1085.


Briefly, this article propose to compute min, p/2, p, (1+p)/2, max; where 
for p=0.5 is standard quartile computation. For each new value it makes a 
simple calculation and estimates the p value using just these 5 previous 
values.

Thank you for pointing out the draft-tempia-ippm-p3m-02.


Best regards,

 	J.Ignacio

On Thu, 28 Jan 2016, Fioccola Giuseppe wrote:

> "i'm not sure if the whole IPPM WG list received my email so i'm sending a copy"
>
> Hi J.Ignacio, All
> many thanks for your comments.
> I agree with you: the median value is a better estimator than the average value, but I take the opportunity to clarify why we choose the average delay.
> Your understanding is right, the average delay is a smart way to calculate the delay.
> It is simple to calculate because the network devices update the average timestamp for each received marking packet and don't need to collect any timestamp, so it greatly reduces the number of timestamps that have to be collected by the management system.  On the other hand, it only gives one measure for the duration of the block and it doesn't give the minimum, maximum and median delay values. This limitation could be overcome by reducing the duration of the block (f.i. from 5 minutes to a few seconds) by means of an highly optimized implementation of the method.
> But if we want to know more about the statistic distribution of delay values, the other approach can be considered: you can periodically mark packets in the IP flow, the timestamps have to be collected by the management system, that can calculate the minimum, the maximum and the median delay values.
> What do you think?
>
> I suggest you to read also draft-tempia-ippm-p3m-02, that is the companion document of draft-chen-ippm-coloring-based-ipfpm-framework-05, where the different alternatives for the delay calculation are explained.
>
> Best Regards,
>
> Giuseppe
>
> -----Messaggio originale-----
> Da: ippm [mailto:[e-mail]] Per conto di J. Ignacio Alvarez-Hamelin
> Inviato: mercoledì 27 gennaio 2016 14:04
> A: [e-mail]
> Oggetto: Re: [ippm] FW: New Version Notification for draft-chen-ippm-coloring-based-ipfpm-framework-05.txt
>
> Hi Math,
>
> also inline answers
>
> On Wed, 27 Jan 2016, Mach Chen wrote:
>
>> Hi J.Ignacio,
>>
>> Thanks for your review and the comments!
>>
>> Please see my response inline...
>>
>>> -----Original Message-----
>>> From: ippm [mailto:[e-mail]] On Behalf Of J. Ignacio
>>> Alvarez-Hamelin
>>> Sent: Tuesday, January 26, 2016 5:37 AM
>>> To: Mach Chen
>>> Cc: [e-mail]
>>> Subject: Re: [ippm] FW: New Version Notification for
>>> draft-chen-ippm-coloring-based-ipfpm-framework-05.txt
>>>
>>> Hi IPPMers,
>>>
>>>
>>> I have just read this draft version, and below are my comments.
>>
>> Thanks!
>>
>>>
>>>
>>> Page 4:
>>>
>>>    "An additional method consists in taking into account the average arrival
>>>     time of the packets within a single block (i.e. the same block of
>>>     markers used for packet loss measurement)." and the following
>>> sentences...
>>>
>>> Since packet delay is highly variable (e.g., self-similar traffic at
>>> Internet edges), I suggest to use the median instead of average; this
>>> *estimator* will be less biased by rare events.
>>
>> Good suggestion, but sometime people may just want average, maybe both can be mentioned here. How do you think?
>
>
> Yes, I agree, we can mention both (I know that average seems simpler, but I was thinking on that the average is a biased estimator while the median is not).
>
>
>>>
>>>
>>>
>>> Page 5:
>>>
>>>    "Type of Service (TOS)"
>>>
>>> Should be: "Type of Service (ToS)"
>>
>> OK.
>>
>>>
>>>
>>>
>>> Page 8:
>>>
>>>    "This
>>>     requires that the upstream and downstream MAs having a certain time
>>>     synchronization capability (e.g., supporting the Network Time
>>>     Protocol (NTP) [RFC5905], or the IEEE 1588 Precision Time Protocol
>>>     (PTP) [IEEE1588].)  The PN is calculated as the modulo of the local
>>>     time (when the counts or timestamps are read) and the interval of the
>>>     marking time period."
>>>
>>> It could be interesting to include a brief comment about precision of
>>> both methods (because the errors of the one-way measurements depend
>>> on timestamp precision).
>>
>> I do not have the figures at hand, we'd appreciate if you or someone
>> else can provide the figures, then we may add this information to
>> document as reference.
>>
>>> Even though NTP and PTP synchronization methods are widely accepted,
>>> this document may consider forthcoming novel methods.
>>
>> IMHO, NTP and PTP are just two examples, this document does not exclude any other methods.
>>
>> Do you have a specific method in mind? Or just want to give an rough description here.  How about this? To add an "etc" at the end.
>>
>> (e.g., supporting the Network Time
>>     Protocol (NTP) [RFC5905], or the IEEE 1588 Precision Time Protocol
>>     (PTP) [IEEE1588], etc.)
>
>
> Yes, I think this should be good. Perhaps we can also add a comment to get an idea about their precision like:
>   Using NTP one can get precision aground milliseconds while PTP can
>   achieve microseconds (and nanoseconds while it is used in a LAN).
>
>
>
>
>>
>> Thanks,
>> Mach
>>
>
> Thanks to you
>
>>>
>>>
>>>
>>> Best regards,
>>>
>>>          J.Ignacio
>>>
>>> _______________________________________________________________
>>>
>>> CONICET and Facultad de Ingeniería, Universidad de Buenos Aires Av.
>>> Paseo Colón 850 - C1063ACV - Buenos Aires - Argentina
>>> [phone] / 4343-2775  ext 299
>>> e-mail: [e-mail]
>>> web: http://cnet.fi.uba.ar/ignacio.alvarez-hamelin/
>>> _______________________________________________________________
>>>
>>>
>>>
>>> On Mon, 25 Jan 2016, Mach Chen wrote:
>>>
>>>> Hi IPPMers,
>>>>
>>>> This update is just to keep the document alive. We received some
>>>> comments
>>> offline, we'd appreciate that there will be more people who could
>>> spend some time to review the draft and send the comments.
>>>>
>>>> Thanks,
>>>> Mach
>>>>
>>>> -----Original Message-----
>>>> From: [e-mail] [mailto:[e-mail]]
>>>> Sent: Monday, January 25, 2016 11:01 AM
>>>> To: Mach Chen; Greg Mirsky; Vero Zheng; Mach Chen; Giuseppe Fioccola
>>>> Subject: New Version Notification for
>>>> draft-chen-ippm-coloring-based-ipfpm-framework-05.txt
>>>>
>>>>
>>>> A new version of I-D,
>>>> draft-chen-ippm-coloring-based-ipfpm-framework-05.txt
>>>> has been successfully submitted by Mach(Guoyi) Chen and posted to
>>>> the IETF
>>> repository.
>>>>
>>>> Name:               draft-chen-ippm-coloring-based-ipfpm-framework
>>>> Revision:   05
>>>> Title:              IP Flow Performance Measurement Framework
>>>> Document date:      2016-01-24
>>>> Group:              Individual Submission
>>>> Pages:              16
>>>> URL:
>>> https://www.ietf.org/internet-drafts/draft-chen-ippm-coloring-based-i
>>> pfpm-fra
>>> mework-05.txt
>>>> Status:
>>> https://datatracker.ietf.org/doc/draft-chen-ippm-coloring-based-ipfpm
>>> -framew
>>> ork/
>>>> Htmlized:
>>> https://tools.ietf.org/html/draft-chen-ippm-coloring-based-ipfpm-fram
>>> ework-0
>>> 5
>>>> Diff:
>>> https://www.ietf.org/rfcdiff?url2=draft-chen-ippm-coloring-based-ipfp
>>> m-frame
>>> work-05
>>>>
>>>> Abstract:
>>>>   This document specifies a measurement method, the IP flow performance
>>>>   measurement (IPFPM).  With IPFPM, data packets are marked into
>>>>   different blocks of markers by changing one or more bits of packets.
>>>>   No additional delimiting packet is needed and the performance is
>>>>   measured in-service and in-band without the insertion of additional
>>>>   traffic.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> 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
>>>>
>>
>
> 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://www.ietf.org/mailman/listinfo/ippm
>