|
Hi Rüdiger, Thanks for your comments. See my answers inline. > > 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) > 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. > 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 > I apologize; I don't see where the
multicast sections on the figure above are. > 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 at ietf.org https://www1.ietf.org/mailman/listinfo/ippm