RE: [ippm] comments on draft-ietf-ippm-multimetrics-03.txt

Hello Emile,

thinking about it, my intention is to mix spatial and multicast metrics. Maybe your draft could mention the possibility for this kind of joint evaluation. The required data collection is specified by your draft and what I propose is more a different kind of correlation to express results than a different kind of measurement. My operator will always ask me, what's the benefit of a new tool to him. And separating spatial and multicast metrics may not always be a convincing argument to him. But I also understand and appreciate that you base your draft on existing metric specifications wherever possible. I also don't think, that you should deviate from applying existing metric definitions.

Two more comments in line.

Regards,

Ruediger

> The spatial result matrix proposed by the authors is a good idea. It may
> additionally be compared against another option:
> 
> current:   R1dT1     R1DT2     R1DT3    ...R1DT
> 
> additional: T0-R1dT1    R1DT2-R1dT1    R1DT3-R1dT2  .....R1DT-R1dTn-1
> R1DT (as an additioinal line)
> 

[ES] This looks like a stream of delay variations experienced by the 
receiver R1: it is an end-to-end metric which looks like 
"Type-P-One-way-ipdv-Poisson-stream" defined in 
http://tools.ietf.org/html/rfc3393#section-3.1.

[RG] No, it is a decomposition into delays per measurement point to 
measurement segment.

> The second table may help to identify multicast tree sections inducing
> delay variations and constant delay more clearly (T0 = probe sending time,
> all numbers in [ms]).
> 
> R1dT1     R1DT2     R1DT3    R1DT4
> T0+5        T0+7      T0+8     T0+12
> T0+7        T0+9      T0+10    T0+14
> T0+6        T0+8      T0+9     T0+13
> 
> could also be expressed as
> 
> R1dT1-T0    R1DT2-R1dT1    R1DT3-R1dT2   R1DT4-R1dT3   R1DT4
>    5             2              1             4              12
>    7             2              1             4              14
>    6             2              1             4              13
> 

[ES] I apologize; I don't see where the multicast sections on the figure above are. 
[RG] True, it is several delay mesurements of a single stream. The intent is the 
display of information - the section R1dT1-T0 produces delay varioation, 
which is easily visible by this kind of evaluation.

> Another point to be discussed would be the spatial distribution of packet
> loss. A packet loss close to the source of a multicast tree has a
> different impact than a packet loss close to a receiver. I can't provide a
> good proposal now and I respect that providing a "single" metric may
> collide with the aim of identifying the cause of a problem fast.
> 

The draft defines spatial and multicast metrics. It does not mix these metrics to provide statistics for investigate the performance of a multicast tree. My thinking is that spatial distribution of packet loss in a multicast tree has to be build on the top Type-P-Spatial-Packet-loss-Vector. 

Regards
Emile

_______________________________________________
ippm mailing list
ippm@ietf.org 
https://www1.ietf.org/mailman/listinfo/ippm