Re: [ippm] Fwd: WGLC for Spatial Composition of Metrics

Donald McLachlan <Donald.McLachlan@crc.ca> Wed, 14 April 2010 16:49 UTC

Return-Path: <Donald.McLachlan@crc.ca>
X-Original-To: ippm@core3.amsl.com
Delivered-To: ippm@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 755E428C2A9 for <ippm@core3.amsl.com>; Wed, 14 Apr 2010 09:49:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.002
X-Spam-Level:
X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DQIjPfWg05lC for <ippm@core3.amsl.com>; Wed, 14 Apr 2010 09:49:49 -0700 (PDT)
Received: from mailgate01.crc.ca (mailgate01.crc.ca [142.92.160.36]) by core3.amsl.com (Postfix) with ESMTP id C4EB03A67EC for <ippm@ietf.org>; Wed, 14 Apr 2010 09:49:48 -0700 (PDT)
Received: from mail01.crc.ca ([142.92.39.50]) by mailgate01.crc.ca (8.13.8/8.13.8) with ESMTP id o3EGnaCJ005054 for <ippm@ietf.org>; Wed, 14 Apr 2010 12:49:38 -0400
Received: from [142.92.34.101] (janus.dgrc.crc.ca [142.92.34.101]) by mail01.crc.ca (8.13.8/8.13.8) with ESMTP id o3EGnRAW026014; Wed, 14 Apr 2010 12:49:38 -0400
Message-ID: <4BC5F215.1050009@crc.ca>
Date: Wed, 14 Apr 2010 12:49:25 -0400
From: Donald McLachlan <Donald.McLachlan@crc.ca>
User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.9.1.7) Gecko/20100115 Lightning/1.0b1 Thunderbird/3.0.1
MIME-Version: 1.0
To: ippm@ietf.org
References: <4BC59297.5080807@ripe.net>
In-Reply-To: <4BC59297.5080807@ripe.net>
Content-Type: multipart/alternative; boundary="------------030404090205070708090201"
X-Scanned-By: MIMEDefang 2.65 on 142.92.160.36
X-Scanned-By: MIMEDefang 2.65 on 142.92.39.50
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (mailgate01.crc.ca [142.92.160.36]); Wed, 14 Apr 2010 12:49:40 -0400 (EDT)
Subject: Re: [ippm] Fwd: WGLC for Spatial Composition of Metrics
X-BeenThere: ippm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF IP Performance Metrics Working Group <ippm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ippm>, <mailto:ippm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ippm>
List-Post: <mailto:ippm@ietf.org>
List-Help: <mailto:ippm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ippm>, <mailto:ippm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 14 Apr 2010 16:49:50 -0000

Henk et al,

Below are the comments I provided to Al Morton (slightly edited and 
minus 1 comment) on version 10 of the draft.

Don


-------- Original Message --------
Subject: 	Re: 
http://tools.ietf.org/wg/ippm/draft-ietf-ippm-spatial-composition/
Date: 	Tue, 06 Apr 2010 16:44:46 -0400
From: 	Donald McLachlan <Donald.McLachlan@crc.ca>
To: 	Al Morton <acmorton@att.com>



Hi Al,

I hope (at least some of) the following comments are useful.

Don


Section 2.1.  First sentence. It reads:
    [...] between the source and the destination of the interest.
Should it maybe read:
    [...] between the source and the destination of interest.

Section 3.1.  4'th bullet.  Ref to possible future work of another
working group.  Thus inaccessible to the reader. ...

Section 4.1.8.1, Section 5.2.6 (and possibly others.)  Question. Is it
possible that (e.g. policy based routing or MPLS) could put pkts from A
to C into different priority queues, than it would put pkts from A to B
and from B to C, thus invalidating the composite metric results?

Section 4.1.9.  I don't like the example given.  In the example given I
expect any change in one-way delay is more likely due to the time taken
for the (possibly heavily loaded) CPU to encrypt/decrypt the packets
than just due to the change in the length of the packet.  Not only that,
but IMO, encrypting changes the definition of packets of type-P.  While
it would be mundane, I think saying ping (or OWAMP) packets of length L1
versus ping (or OWAMP) packets of L2 is a better example of packets of
different length.

Section 4.1.10. Should "similar" be quantified.  E.g. same DCSP, proto,
similar length, encryption, etc?  Otherwise might DPI or policy affect
routing or queuing, etc?

Section 5.2 (or all of "chapter" 5) Poisson vs. Periodic streams.
Question.  While I understand the theoretical differences with using
Poisson versus Periodic streams.  In practice, has anyone ever measured
one-way delay across an Internet path with both stream types and
obtained statistically similar/different results? Is this chapter
proposing that one can perform Poisson OWD measurements on one sub-path
and periodic OWD measurements on a second sub-path and combine them to
form a sane composite full-path metric?  If so, that should be more
clearly stated.  If not, that should be stated.

Section 5.2.6.  Maybe replace bi-modal with multi-modal?

Section 5.2.9. Even if the sub-path distribution is (multi) modal, if
the sub-path is part of the real path, wouldn't the sample delays on the
full path be subject to the same (multi-)modal delays of the sub-path?
In which case is this really an issue?

Section 6.1.4.  Question.  Would it also be possible to use a similar
method to measure sub-path burst lost length, and combine them to obtain
an empirical loss-length probability?

Section 7.1.1, third bullet.  Not only length in bits, but Type-P, the
definition of which should maybe include DCSP, proto, src port, dst
port, encryption, etc.  IMO, anything which might change how the packet
might be handled by routers along the path should be specified.  Maybe
this comment should be applied to Section 4.1.1 instead, and would thus
covered by the first sentence of this Section, "In addtion to the
parameters of section 4.1.1:".

Section 7.1.1, fourth bullet. Section 7.1 says
Type-P-One-way-pdv-refmin-Poisson/Periodic-Stream.  This bullet refers
to packet pairs - which is IPDV.  If what is intended is IPDV, then the
idea of min delay does not apply.  If what is intended is PDV, then
packet pairs does not apply.

Assuming what is wanted is PDV, might I suggest:

F, a selection function unambiguously defining the packets from
      the stream that are selected for the computation of
      this metric.  F(packet), MUST
      have a valid Type-P-Finite-One-way-Delay less than Tmax (in other
      words, excluding packets which have undefined one-way delay) and
      MUST have been transmitted during the interval T, Tf.  F(min_packet) MUST be the packet with the
      minimum valid value of Type-P-Finite-One-way-Delay for the stream,
      in addition to the criteria for F(packet).  If multiple
      packets have equal minimum Type-P-Finite-One-way-Delay values,
      then the value for the earliest arriving packet SHOULD be used.


Section 7.1.4, last sentence.  Doesn't the PDV applicability statement
speak of %-iles, or P.99?  Was it a conscious decision to change the
nomenclature to Quantile?  (That said I prefer Quantile over %-ile and P.99).