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).
- [ippm] Fwd: WGLC for Spatial Composition of Metri… Henk Uijterwaal
- Re: [ippm] Fwd: WGLC for Spatial Composition of M… Al Morton
- Re: [ippm] Fwd: WGLC for Spatial Composition of M… Donald McLachlan
- Re: [ippm] Fwd: WGLC for Spatial Composition of M… Al Morton