Subject: [ippm] comments on draft-ietf-ippm-duplicate-03.txt

From: Matthew J Zekauskas <[email-masked]>
Date: Wed, 25 Jun 2008 21:43:19 -0400

Chair hat off...

1.1:
I think we should copy over the additional 2119 text from the other 
documents.  e.g. from 2680:

>    Although RFC 2119 was written with protocols in mind, the key words
>    are used in this document for similar reasons.  They are used to
>    ensure the results of measurements from two different implementations
>    are comparable, and to note instances when an implementation could
>    perturb the network.

2.4,2.5:
When talking about the IP headers not being identical, can we be more 
precise?  We'd like src,dst,proto (and I suppose identification in v4); 
is it simply TTL and the checksum that can change?

2.5: in talking about "clocks do have to be synchronized" can we give a 
bound?  I don't think it's as stringent as with one-way delay...

2.6,2.7,2.8: The references to 2680 are strong here (even before, but 
especially here), and I think that warrants 2680 being a normative 
reference (it's listed as non-normative in this draft).

5.1,5.2: I would re-word to remove the (somewhat informal) hash mark, 
and at least in 5.1, the parens don't balance.

e.g., 5.1: "(In other words, (number of packets received)/(number of 
packets sent but not lost).)"

5.2: "(In other words, (number of duplicated packets)/(number of packets 
sent but not lost).)."

or even with an ascii-art flair:
(In other words:

          number of duplicated packets
          ----------------------------------
          number of packets sent but not lost
)

refs:
The normative ref to 2680, already noted.

There must be better Y.1450 reference text.  I'm sure I can find it, but 
am rushing right now...

perhaps more before the last call close too,

--Matt

_______________________________________________
ippm mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ippm

---

From: Al Morton <[email-masked]>
Date: Wed, 25 Jun 2008 22:29:55 -0400

At 09:43 PM 6/25/2008, Matthew J Zekauskas wrote:

...There must be better Y.1450
reference text.  I'm sure I can find it, but am rushing right
now...

No names, just:

ITU-T Recommendation Y.1540 (2007), Internet protocol data
communication service – IP packet transfer and availability performance
parameters.

---

From: Henk Uijterwaal <[email-masked]>
Date: Thu, 26 Jun 2008 10:44:41 +0200

Matt, others,

> bound?  I don't think it's as stringent as with one-way delay...

I tried to do this with "uniquely determine the interval [T, T+T0] at
both sides".   If one looks at T0, then one gets an idea how accurate
the synchronization should be.   If T0 is, say, 1 day, then seconds or
minutes synchronization should be fine.  If T0 is, say, 1 second, then
you need far better synchronization.  I don't want put a number in here.
but I'm open for better wording.

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

Is one of the choices leaving the office open?
                                       Alan Greenspan on the next elections
_______________________________________________
ippm mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ippm