Subject: [ippm] RE: I-D ACTION:draft-morton-ippm-composition-00.txt

From: "STEPHAN Emile RD-CORE-LAN" <[email-masked]>
Date: Tue, 2 Aug 2005 18:57:20 +0200

Hi Al,

As I explained in the WG meeting I fully agree with the scope of this draft and will contribute to this effort.

Let's start.

>From my point of view the metric currently defined in the draft is not a composition metric. Moreover it discards lost of packets from the results. So the resulting delay may be excellent event if 90% of the packets are loss.

I propose a work around which avoid redefining Type-P-One-way-Delay-Poisson-Stream and integrate packet loss in the composition:
Firstly using Type-P-One-way-Delay-Poisson-Stream <P1,T1,dt1>...<Pn,Tn,dtn>  we define a Type-P-One-way-kpi as the couple of term <dt,k> where dt is the average of delays Tn-Ti, where k is the sum of the packet loss during this interval of time T1 Tn.
Then using a list of Type-P-One-way-kpi {<dt,k> ... <dti,ki>...} computed in the consecutive segments of the path, we define the Type-P-One-way-kpi-sum as the couple of term (DT, K) where DT is the sum of the delays dti and K is the sum of the loss ki. 

Regards
Emile

Regards
Emile
> -----Message d'origine-----
> De : [email-masked] [mailto:[email-masked]]
> De la part de [email-masked]
> Envoyé : mardi 12 juillet 2005 21:50
> À : [email-masked]
> Objet : I-D ACTION:draft-morton-ippm-composition-00.txt
> 
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> 
> 
> 	Title		: Composition of Metrics
> 	Author(s)	: A. Morton
> 	Filename	: draft-morton-ippm-composition-00.txt
> 	Pages		: 11
> 	Date		: 2005-7-12
> 
>    This memo intends to define metrics that are applicable to both
>    complete paths and sub-paths, where a corresponding relationship can
>    be specified to compose the complete path metric from the sub-path
>    metrics with sufficient accuracy.  The current memo gives some
>    background and proposes wording for a Scope and Application section
>    to define this new work. The description of an example metric and
>    statistic follows.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-morton-ippm-composition-00.txt
> 
> To remove yourself from the I-D Announcement list, send a message to
> [email-masked] with the word unsubscribe in the body of the
> message.
> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
> to change your subscription settings.
> 
> 
> Internet-Drafts are also available by anonymous FTP. Login with the
> username
> "anonymous" and a password of your e-mail address. After logging in,
> type "cd internet-drafts" and then
> 	"get draft-morton-ippm-composition-00.txt".
> 
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> 
> 
> Internet-Drafts can also be obtained by e-mail.
> 
> Send a message to:
> 	[email-masked].
> In the body type:
> 	"FILE /internet-drafts/draft-morton-ippm-composition-00.txt".
> 
> NOTE:	The mail server at ietf.org can return the document in
> 	MIME-encoded form by using the "mpack" utility.  To use this
> 	feature, insert the command "ENCODING mime" before the "FILE"
> 	command.  To decode the response(s), you will need "munpack" or
> 	a MIME-compliant mail reader.  Different MIME-compliant mail readers
> 	exhibit different behavior, especially when dealing with
> 	"multipart" MIME messages (i.e. documents which have been split
> 	up into multiple messages), so check your local documentation on
> 	how to manipulate these messages.
> 
> 
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.

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

---

From: Al Morton <[email-masked]>
Date: Thu, 04 Aug 2005 13:00:46 -0400

IPPM,

Emile and I had a chance to discuss his comments at lunch today,
so here's a brief (but hopefully clear) summary.

At 12:57 PM 8/2/2005, STEPHAN Emile RD-CORE-LAN wrote:
>As I explained in the WG meeting I fully agree with the scope of this 
>draft and will contribute to this effort.
>
>Let's start.
>
> From my point of view the metric currently defined in the draft is not a 
> composition metric. Moreover it discards lost of packets from the 
> results. So the resulting delay may be excellent event if 90% of the 
> packets are loss.

The main point of defining Finite-One-way-Delay-...  was to filter
out the lost packets (whose delay is assigned to be infinity).
Otherwise, if even one packet is lost, the sum of dT below will not be
useful.

Also, the IPPM metrics are intended to be as orthogonal
as possible, so if the cause of loss is not congestion-related,
we should see the packets that arrive having some "typical" finite delay,
and the Finite one-way delay metric would describe them alone.

>I propose a work around which avoid redefining 
>Type-P-One-way-Delay-Poisson-Stream and integrate packet loss in the 
>composition:
>Firstly using Type-P-One-way-Delay-Poisson-Stream 
><P1,T1,dt1>...<Pn,Tn,dtn>  we define a Type-P-One-way-kpi as the couple of 
>term <dt,k> where dt is the average of delays Tn-Ti, where k is the sum of 
>the packet loss during this interval of time T1 Tn.
>Then using a list of Type-P-One-way-kpi {<dt,k> ... <dti,ki>...} computed 
>in the consecutive segments of the path, we define the 
>Type-P-One-way-kpi-sum as the couple of term (DT, K) where DT is the sum 
>of the delays dti and K is the sum of the loss ki.

I agree that delay and loss are very fundamental metrics of network
performance. Folks should consider always pairing these two,
or whether the results should be kept separate, recognizing
there will likely be other metrics to report.

An additional point came-up in our discussion, regarding measurement
methodology.  We should specifically address applicability of the two
primary sampling schemes (Poisson and Periodic) for every composition
metric that we define in the draft.

Al

---

From: Maurizio Molina <[email-masked]>
Date: Tue, 09 Aug 2005 15:31:35 +0100

Hi all,
reading Emile's mail I have a doubt: was there any discussion, at the
Paris meeting, on whether IPPM should consider also aggregation in space
and aggregation in time, beyond concatenation in space (which is the
focus of draft-morton-ippm-composition-00.txt)?
Personally, I think it would be beneficial to consider them all, because
they all have relevance in network operations.
Furthermore, If we had a coherent framework, we could define a
terminology and use it. For example, Emile's suggestion below would be a
concatenation in space following an aggregation in time. One of the
goals of this activity could be to understand what composition
combinations make sense and what not. Not sure if we need 3 draftts or 3
sections in the same draft, but that's minor.
Regarding the specific of Emile's proposal, I think that considering
metric correlation (e.g. delays and losses) right now, before having
established the framework, is a bit premature.
Regards,
Maurizio