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

From: Al Morton <[email-masked]>
Date: Mon, 31 May 2010 08:32:13 -0400

Don,

I've answered a few questions below, otherwise the
diff between 11 and 12 should allow you to easily find
text to address your comments.

thanks again,
Al

At 12:49 PM 4/14/2010, Donald McLachlan wrote:
>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
>...
>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.

I clarified this example, and addressed the A-B-C policy routing
issue in section 4.1.9

>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.

Both the above addressed in section 4.1.10

>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?

Yes the multi-modal dist result is one symptom of path instability.

>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?

It seems like this might work for certain sub/complete path
burst statistics, but haven't really investigated this possibility.

>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:".

Type-P is now an explicit parameter in 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.
PDV still uses packet pairs, but one of the packets in the pair
is always the same (the packet with the minimum delay)

>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.

I used (current packet) and (min_delay packet)

>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).

Both terms have been used in different venues.
There was a stray "IPDV" in there, though.