Re: [ippm] draft-duffield-ippm-burst-loss-metrics-01

["DUFFIELD, NICHOLAS G (NICK)" <duffield at research.att.com>]

Vinayak,

Thanks for reading the draft. Responses are inline below:

> -----Original Message-----
> From: ippm-bounces at ietf.org [mailto:ippm-bounces at ietf.org] On Behalf 
> Of Vinayak Hegde
> Sent: Thursday, November 05, 2009 7:48 AM
> To: Yaakov Stein
> Cc: IETF IPPM WG
> Subject: Re: [ippm] draft-duffield-ippm-burst-loss-metrics-01
> 
> On Sun, Nov 1, 2009 at 8:05 PM, Yaakov Stein <yaakov_s at rad.com> wrote:
> > I read the aforementioned draft with interest, as I believe that it 
> > is important to have a way of quantifying the burstiness of packet loss.
> [Snip]
> 
> I agree to what Yaakov has said with regards to time. When I think for 
> burstiness, I would like to have a metric which can be scaled to 
> multiple packets in succession, so while this draft might start with a 
> pair of packets, it might be inadequate. The reason being, I would 
> like to have a better sample with higher resolution of measurement.
> Quantification of bursty loss will be more accurate in terms of 
> percentage when more packets are involved in succession. Also the 
> order of loss of individual packets in a stream (a bunch of packets 
> used for measurement) might not be important, what would matter is the 
> aggregate sample such as there was a loss of 1 packet on average when 
> 10 bursts of 10 packets were used as compared to a loss of 1 loss-pair 
> per 10 loss-pair packets.
> 

I think we draft authors may have created some unmet expectations as to what this draft is trying to achieve, by too liberal use of the term "burstiness". A more accurate idea of the work would be conveyed by saying it defines "loss episode metrics", specifically, the average length of loss episodes, and the average number of loss episodes per unit time.

The focus on time is because we want to relate the durations of episodes to the temporal requirements of applications. Metrics scaled by packet count rather than time are not so useful because the packet rates of probe and application traffic are in general different.

A great advantage of using average loss episode metrics (duration and frequency) is that they do not require measurement of complete loss bursts (nor loss patterns as in RFC 3357). They only require measurement of the frequencies of the 4 possible outcomes from two successive packets, and these can be estimated from sampling. 

If there is WG interest is trying to formulate metrics which capture general multipacket statistical detail of loss episodes, this could be considered as a different WG item. This would be necessary for metrics of loss episodes other than the average properties (e.g. variance of episode duration). However, that is outside the scope of this draft, which is the simplest increment from RFC 2680 that provides metrics that inform of properties loss episodes, instead of just an average packet loss rate. 


> The only counterexample that I can think of is when some packets are 
> more important that others and there is a periodic 'SYNC' packet send 
> in a stream. The loss of the SYNC packet would be higher as compared 
> to other packets if it is a periodic loss every X interval.
> 
> Additional comments:
> 
> In section 4., a geometric distribution is mentioned. It is not clear 
> to me why a geometric distribution might be used between successive 
> time (exponential backoff/damping oscillations). any precedent for 
> this ?
> 

The probes (= packet pairs) are sampling the bi-packet outcomes. So you can think of the geometric distribution as giving rise to (discrete) Poisson probing at the packet pair level, analogous to the single packet Poisson probing for one-way loss measurement in RFC 2680. Geometric sampling in general is described in RFC 2330.

> In section 4.3 / 4.4 What are the use cases for m <= n Why would m be 
> <= n is not immediately clear.

Consider a set of evenly spaced times at which probe pairs could be sent. From these times and (random) subset of size m <= n is selected, e.g., by means of the geometric sampling just discussed.

> 
> In section 4.7 Should there be a reference to asymmetric losses ? For 
> example in a video conferencing app with two participant there is loss 
> in one direction but not the other leading to loss in video/audio 
> quality.

The metrics in the draft are one way metrics.

> 
> In section 5.1 Why is there a differentiation between (1,0) and (0,1) 
> packets. In burstiness, shouldn't the aggregate statistics matter  and 
> not the order of loss ?


In estimating the frequencies of episodes from the samples, it is more accurate to count both the "episode start" samples (0,1) and the "episode end" samples (1,0).


> 
> Finally the selection function is mentioned in several places in the 
> draft. A couple of examples of each with real-life scenarios could be 
> useful.

OK; we will elaborate in next version.


> 
> -- Vinayak

Nick

> _______________________________________________
> ippm mailing list
> ippm at ietf.org
> https://www.ietf.org/mailman/listinfo/ippm