[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [ippm] comments on draft-ietf-ippm-multimetrics-03.txt
Hi Ruediger
The AVT draft that related to MINC became RFC3611 - specifically the first
few block types defined
Regards
Alan
-----Original Message-----
From: Geib, Ruediger [mailto:Ruediger.Geib at t-systems.com]
Sent: Monday, March 26, 2007 4:05 AM
To: matt at internet2.edu
Cc: ippm at ietf.org
Subject: [ippm] comments on draft-ietf-ippm-multimetrics-03.txt
Hi Matt,
as agreed during the meeting some comments on the multimetrics draft:
The multimetric draft aims on providing verfy useful information. My
perception is, that it may benefit from more discussion on spatial multicast
measurement analysis.
MINC was a research project focused on inferring Multicast topologies from
source and end point measurements only. This would correspond to a purely
active multicast system. MINC provided evalutions of multicast tree
performance including a spatial anlysis. The results may be found under:
http://www-net.cs.umass.edu/minc/
It mentioned during the meeting that the AVT WGs extensions to RTCP
partially were made to support MINC evaluations:
http://www.ietf.org/rfc/rfc4585.txt
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)
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
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.
Editorials
Section 2.6
Don't quite understand the sentence:
"Thus, we can define the reference point as the host while the statistic
calculation will be carried out."
Section 2.7
Add the marked word:
"a network at any different time."
^^^
Section 3.2 apllies the term "connection" quite often. I'm not a multicast
expert, but is "connection" appropriate?
Section 4.1.2
"Path digest" is introduced. This expression is explained by another IPPM
document, I assume. If not, please provide a definition in this draft.
"+ dT1,..., dTn a list of delay." This is an ordered list of delay values
referring to the same packet passing different monitors. This should be
expressed more clearly.
Section 4.1.8 lists two bullet points. The first refers to a receiver, the
second to a source or to the management system. This coulöd be expressed
more clearly by adding these words.
Further,an internal delay correction is introduced here. It is not explained
anywhere.
Section 4.2.5
"o dTk.b may be observed and not dTk.a." Please explain this briefly.
4.2.10 Just a headline, no content.
First time for me to see a "sum" symbol edited by text only. Funny and great
;-)
Regards,
Ruediger
Rüdiger Geib
T-Systems Enterprise Services GmbH
Systems Integration
Rüdiger Geib
Line of Business Networks & Processes
Senior Consultant
Deutsche-Telekom-Allee 7, 64295 Darmstadt
+49 6151 937-2138 (Tel.)
http://www.t-systems.com
_______________________________________________
ippm mailing list
ippm at ietf.org
https://www1.ietf.org/mailman/listinfo/ippm
_______________________________________________
ippm mailing list
ippm at ietf.org
https://www1.ietf.org/mailman/listinfo/ippm