RE: [ippm] Comments on draft-ietf-ippm-framework-compagg-00

Anura Jayasumana <anura@engr.colostate.edu> Wed, 22 March 2006 02:48 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLtOV-0002Ix-Jc; Tue, 21 Mar 2006 21:48:19 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLtLn-0000QQ-QT for ippm@ietf.org; Tue, 21 Mar 2006 21:45:32 -0500
Received: from eagle.acns.colostate.edu ([129.82.100.90] helo=eagle.colostate.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLtLm-0000GE-AS for ippm@ietf.org; Tue, 21 Mar 2006 21:45:31 -0500
Received: from engr.colostate.edu (goku.engr.colostate.edu [129.82.224.16]) by eagle.colostate.edu (AIX5.1/8.11.6p2/8.11.0) with ESMTP id k2M2jTo917182; Tue, 21 Mar 2006 19:45:29 -0700
Received: from webmail.colostate.edu (csunts4.acns.colostate.edu [129.82.100.135]) by engr.colostate.edu (8.11.7p1+Sun/8.11.7) with ESMTP id k2M2jSs14317; Tue, 21 Mar 2006 19:45:28 -0700 (MST)
X-WebMail-UserID: anura@mail.engr.colostate.edu
Date: Tue, 21 Mar 2006 19:45:25 -0700
From: Anura Jayasumana <anura@engr.colostate.edu>
To: "Philip F. Chimento Jr." <vze275m9@verizon.net>
X-EXP32-SerialNo: 00002247, 00002264
Subject: RE: [ippm] Comments on draft-ietf-ippm-framework-compagg-00
Message-ID: <4428D33A@webmail.colostate.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Mailer: Infinite Mobile Delivery (Hydra) SMTP v3.62.01
X-Spam-Score: 1.1 (+)
X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5
X-Mailman-Approved-At: Tue, 21 Mar 2006 21:48:18 -0500
Cc: ippm <ippm@ietf.org>
X-BeenThere: ippm@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF IP Performance Metrics Working Group <ippm.ietf.org >
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ippm>, <mailto:ippm-request@ietf.org ?subject=unsubscribe>
List-Post: <mailto:ippm@ietf.org >
List-Help: <mailto:ippm-request@ietf.org ?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ippm>, <mailto:ippm-request@ietf.org ?subject=subscribe>
Errors-To: ippm-bounces@ietf.org

>===== Original Message From "Philip F. Chimento Jr." <vze275m9@verizon.net> 
=====
>Hi Anura:
>You can add means, whether the relevant RVs are dependent or not, so
>average delays add.
>Higher order statistics, as you point out, do not add simply.
>Convolution ASSUMES that the RVs are independent.
>
>
>Regards,
>Phil Chimento

Phil,
Yes, you are right.  Based on very limited results we have for delay, it looks 
like the delays are independent if the inter-packet gaps of the stream is 
large; when ipg is small, such as with a burst, the delays appear to be highly 
correlated. This is when convolution breaks down. 
Cheers!
AJ

>
>On Mar 21, 2006, at 12:31, Anura Jayasumana wrote:
>
>>
>>
>> Henk Uijterwaal wrote:
>>> Phil,
>>>
>>> The problem that I have with this section is that it doesn't give me
>>> very strong or concrete reasons for why I want to combine metrics.
>>>
>>> Suppose I have a path A-B-C.  I'm interested in the delays between
>>> them.
>>> Now, I can measure all 3 (A-B, B-C and A-B-C) separately.
>>> However, if
>>> there is a way to add up the delays between A-B and B-C, and get the
>>> overall delay, then i can see myself some work and diskspace.  In
>>> general,
>>> I'd be interested in the minimum set of measurements that still gives
>>> me information about the entire network.
>>>
>>>  Section 5.1: The problem here is that piece-wise measurements do
>>> not necessarily combine. IPDV and re-ordering are examples where one
>>> subsection of a network can "undo" what a previous one has done.
>>> Putting these together in a straightforward way doesn't give you the
>>> right answer.
>>
>> With delays,  if the packet delays in the two networks are not
>> correlated, it is still possible to measure statistics of  delays
>> of segments and combine them to provide end-to-end delay
>> statistics.  When delays are correlated, it becomes necessary to
>> measure correlation as well.... which would be more complex.
>> Reordering is somewhat of a harder problem. But, when  captured
>> using RD (reorder density), you can combine the reordering in
>> different segments and still come up with end-to-end reordering.
>> Combination is done using
>> convolution, which would be the case for delay also.  One thing
>> going for RD is the fact that reordering in two network segments
>> are less likely to be correlated compared to delay.  We have
>> carried out many mesurements on Internet, planet-lab, simulations,
>> etc., and are yet to see a case where it did not work - for
>> reordering.
>> (See http://www.cnrl.colostate.edu/packet_reorder.html )
>> Cheers!
>> AJ
>>
>>>
>>> I agree but can't we just say so?
>>>
>>> Henk
>>>
>>>
>>> ---------------------------------------------------------------------
>>> ---------
>>> Henk Uijterwaal                           Email: henk.uijterwaal
>>> (at)ripe.net
>>> RIPE Network Coordination Centre          http://
>>> www.amsterdamned.org/~henk
>>> P.O.Box 10096          Singel 258         Phone: +31.20.5354414
>>> 1001 EB Amsterdam      1016 AB Amsterdam  Fax: +31.20.5354445
>>> The Netherlands        The Netherlands    Mobile: +31.6.55861746
>>> ---------------------------------------------------------------------
>>> ---------
>>>
>>> 1160438400. Watch this space...
>>>
>>> _______________________________________________
>>> ippm mailing list
>>> ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm
>>
>> Anura P. Jayasumana
>> Professor, Electrical & Computer Engineering
>>                            and Computer Science
>> Department of Electrical and Computer Engineering
>> Colorado State University
>> Fort Collins, CO 80523
>> Phone: (970) 491-7855
>> Fax: (970) 491-2249
>> Email: <Anura.Jayasumana@Colostate.edu>
>
>
>_______________________________________________
>ippm mailing list
>ippm@ietf.org
>https://www1.ietf.org/mailman/listinfo/ippm


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