Subject: [ippm] draft-ietf-ippm-spatial-composition-07 remarks

From: Yaakov Stein <[email-masked]>
Date: Thu, 4 Dec 2008 13:25:34 +0200

Hi all,

At IETF73 I promised to look over draft-ietf-ippm-spatial-composition-07
and I have been doing so (somewhat slowly, but enjoying the read).

Although I haven't finished the whole draft yet,
I have amassed quite a few remarks, and think it best to split them up.
That way I can release the ones I already have,
and we can keep the threads separate.

This email will be on general topics and nits.

1) NIT - the contributor list should not include the authors

2) The whole idea of paths being subdivided into subpaths needs
   further clarification and most probably constaints.
   I will discuss this further in separate emails,
   but let me explain in a few words what I mean :
   A) Subpaths may be joined at a link or at a node;
      there are reasons for both
      (e.g. ITU recommends different operator domains joining at a link,
      while border routers and PWE stitching points join at nodes.
      Note that when the joining is at a node the end-to-end
      packet loss is the sum of the packet losses in the pieces
      and that of the shared node, while when the joining is at a link
      the end-to-end delay is the sum of the delays and that of the link.
      MEF studied some of the effects of this in an ad-hoc group
      called "accurate frame loss".
   B) There are frequently multiple paths between the endpoints.
      These multiple paths can all be used in at least 3 cases
      i) rerouting events
      ii) ECMP/LAG
      iii) inverse mux.
      I don't know if these mechanisms have ever been seriously discussed
      in IPPM. Their effect is more general than the spatial composition case,
      but is particularly significant for this case.

3) page 5 - the use of spatial composition may also be the reverse.
   If we know the end-to-end parameter, and that of all subpaths but one,
   then we can deduce that of the last path.

4) NIT Section 4 - "The section is organized using the same subsections
   as the individual metrics ...". Yes, that WOULD have been useful,
   but unfortunately sections 5.2 and 5.3 are missing the section
   parallelling 4.1.4 "Statistic", thus e.g. 5.2.6 maps to 4.1.7.

5) 5.1.2 (and other places) What is meant by "sufficiently LOW resolution" ?
   At first I thought that this meant course resolution, but then saw delays
   measured in microseconds. Does this actually mean "fine" resolution ?
   Does the statement mean A) course resolution to be reproducible OR
   B) fine resolution to be accurate ?

6) NIT 5.2.2 (and other places). I am sure that you thought about this,
   but I find it confusing to use the index i to mean packet number
   and afterwards the same index to mean subpath.
   I would like at least for the formula to say
   MeanDelay[i] = 1/N SUM_j=1^N FiniteDelay[i,j]
   where i = 1 to number_of_subpaths and j = 1 to number_of_packets.
   A convention I frequently use in such cases would have
   the subpath index called "s" and have it run from 1 to "S"
   and the packet index called "p" and have it run from 1 to "P".

7) NIT 5.2.5 - It would have been clearer to me to say that this composition
   means that the mean of the sum equals the sum of the means.
   However, I admit to not understanding the caveat of the continous distributions.
   When the paths contain a small number of nodes the distributions will not
   be continuous at least at the bottom, since there will be a sharply defined
   minimum delay (this sharpness disappears with a large number of nodes
   since the sum of a large number of random variables starts looking Gaussian).
   In any case, it is not obvious to me that discontinuous distributions
   do not add correctly. Can you explain ?

8) 5.2.8 Another specific case would be when there is significant delay
   in a link connecting the subpaths
   For 5.3.8 another case would be when the delay depends on packet size
   and this packet size changes when going from subpath to subpath
   as a result of encapsulation changes.

That is as far as I have gotten.
I will write up a few more emails on more in-depth remarks,
and add further short comments as I progress.

Y(J)S
_______________________________________________
ippm mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ippm

---

From: Al Morton <[email-masked]>
Date: Thu, 04 Dec 2008 08:00:18 -0500

Yaakov,

thanks for your review!

I won't get to this for a week or so,

but will reply asap.

Al

At 06:25 AM 12/4/2008, Yaakov Stein wrote:

At
IETF73 I promised to look over
draft-ietf-ippm-spatial-composition-07

and I have been doing so (somewhat slowly, but enjoying the
read).
...