Subject: [ippm] Fwd: New work relating to delay variation in AVT

From: Matthew J Zekauskas <[email-masked]>
Date: Mon, 19 Mar 2007 07:41:32 -0400

This was apparently deleted along with with the usual junk in the mail
held queue.  My apologies.

--Matt

--------

Subject: New work relating to delay variation in AVT
From: "Tom-PT Taylor" <[email-masked]>
Date: Thu, 15 Mar 2007 11:52:20 -0400
To: [email-masked]
CC: Dave Singer <[email-masked]>, Colin Perkins <[email-masked]>,
Roni Even <[email-masked]>

A recent I-D by Morton dealing with delay variation made me aware of
IPPM interest in this topic. For that reason I direct your attention to
draft-ietf-avt-rtp-toffset-05.txt which, for RTP packets, provides the
means to separate delay variation introduced at the source host from
that introduced in the intervening transport network. This draft has
passed WGLC and is being forwarded to the IESG for approval. If you have
comments, please submit them as IETF Last Call comments to the IESG.

Thanks,
Tom Taylor
AVT co-chair

_______________________________________________
ippm mailing list
[email-masked] 
https://www1.ietf.org/mailman/listinfo/ippm

---

From: "Geib, Ruediger" <[email-masked]>
Date: Mon, 26 Mar 2007 11:05:14 +0200

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

---

From: "Alan Clark" <[email-masked]>
Date: Mon, 26 Mar 2007 05:17:12 -0500

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:[email-masked]] 
Sent: Monday, March 26, 2007 4:05 AM
To: [email-masked]
Cc: [email-masked]
Subject: [ippm] comments on draft-ietf-ippm-multimetrics-03.txt

Hi Matt,

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:

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

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

Section 2.7
Add the marked word:

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.

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

First time for me to see a "sum" symbol edited by text only. Funny and great
;-)

Regards,

Ruediger

Rüdiger Geib