A One-Way Packet Duplication Metric
RFC 5560

Received changes through RFC Editor sync (changed abstract to 'When a packet is sent from one host to the other, one normally expects that exactly one copy of the packet that was sent arrives at the destination. It is, however, possible that a packet is either lost or that multiple copies arrive.

In earlier work, a metric for packet loss was defined. This metric quantifies the case where a packet that is sent does not arrive at its destination within a reasonable time. In this memo, a metric for another case is defined: a packet is sent, but multiple copies arrive. The document also discusses streams and methods to summarize the results of streams. [STANDARDS-TRACK]')

[Ballot comment]
Since you will probably need to revise the document for Jari's Discuss,
here are some nits to fix along the way.

Abstract
s/from one host to the other/from one host to another/
s/has been defined/was been defined/

Section 1.2 - Same changes as Abstract

Agree with Jari that the definition of "information fields" needs to
be moved from 2.5 to above its first use (in section 2.4).

Section 2.4 bullet 2
s/Host are/Hosts are/

Section 2.5
s/Clocks do have to be/Clocks have to be/

Sections 4.1.2 and 4.2.2
Would it help to note Tf > Ts ?

Did you reach any conclusions with IANA for section 7?
If you are respinning the document, it would be good to capture these
changes at the same time.

[Ballot discuss]
I wanted to vote Yes on this document, and gave it a detailed read. It
is in good shape. However, there was one issue that troubled me. The
document says:

  Two packets are considered identical if and only if:

  o  Both contain identical information fields.  The recipient thus
      could take either packet and use the data in an application.  The
      other packet does not contain any additional information.
  o  Both packets appear to have been sent by one and the same host, to
      one and the same destination.  Host are identified by their IP
      addresses.
  o  Both contain valid, but not necessarily identical IP header
      fields.

  ... and much later ...

  In IPv4, "information fields" refers to all data following the IPv4
  header.  The equivalent of this in IPv6 is all information following
  the IPv6 header and the hop-by-hop options header.

There are a couple of problems with this. First an editorial comment
that as a reader I would have appreciated to have seen the information
fields definition earlier (I had scanned all the references before I
realized it was defined later in the document).

Second, I would prefer to see a crisper definition. There aren't too
many fields in the IP headers, why not specify exactly what has to
be exactly as-is and what can change. My guess is:

Must be exactly as-is:
  ipv4: version, ihl, identification, src, dst, protocol
  ipv6: version, next header, source, destination
Can change:
  ipv4: tos, ttl, checksum
  ipv6: traffic class, flow label, hop limit
Not sure what I'd say:
  ipv4: total length, reserved flag bit, DF flag, options
  ipv6: payload length
Not applicable:
  ipv4: fragment offset, MF flag

Third, what about things like IPv4 Record Route or Timestamp options?
Though these might be almost non-existent in real world today, so
maybe its fine to treat them as a part of information fields.

On the IPv6 side, what about routing header type 2? These never change
on the wire, but the point at which ippm intercepts the packets matters.
RFC 3775 allows them to be processed so that the segments left field is
decremented before the rest of the packet is processed. Similarly, there
are other packet processing tasks that packets go through when being
sent or received, such as IPsec ESP encap/decap. The latter is actually
an even more interesting case from the point of view of ippm, because
a security gateway might encapsulate the packet and the receiver then
decapsulates. Do you consider the ippm as something that processes
raw packets, as they are received from the network? If so, you should
probably say this explicitly.

IANA Last Call questions/comments:

QUESTIONS:

- Do you need the Type-P-one-way-packet-duplication-fraction or
Type-P-one-way-replicated-packet-rate definitions registered anywhere?

- What do you want to be the short-hand names of your metrics?

NOTE TO AUTHOR: It would make IANA's life much easier if you could
include-by-value the text that you would like inserted
into the registry. We have attempted to guess at what
you want.

Upon approval of this document, IANA will make the following
assignments in the "IANA-IPPM-METRICS-REGISTRY-MIB DEFINITIONS"
registry at
http://www.iana.org/assignments/ianaippmmetricsregistry-mib

ietfOneWayPacketArrivalCount OBJECT-IDENTITY
STATUS current
DESCRIPTION
"Type-P-one-way-packet-arrival-count"
REFERENCE
"Reference [RFC-ippm-duplicate-07], section 2"


::= { ianaIppmMetrics [tbd] }



ietfOneWayPacketDuplication OBJECT-IDENTITY
STATUS current
DESCRIPTION
"Type-P-one-way-packet-duplication"
REFERENCE
"Reference [RFC-ippm-duplicate-07], section 3"


::= { ianaIppmMetrics [tbd] }



ietfOneWayPacketDuplicationPoissonStream OBJECT-IDENTITY
STATUS current
DESCRIPTION
"Type-P-one-way-Packet-Duplication-Poisson-Stream-"
REFERENCE
"Reference [RFC-ippm-duplicate-07], section 4.1"


::= { ianaIppmMetrics [tbd] }



ietfOneWayPacketDuplicationPeriodicStream OBJECT-IDENTITY
STATUS current
DESCRIPTION
"Type-P-one-way-Duplication-Periodic-Stream"
REFERENCE
"Reference [RFC-ippm-duplicate-07], section 4.2"


::= { ianaIppmMetrics [tbd] }



We understand the above to be the only IANA Action for this document.

Document shepherd writeup for draft-ietf-ippm-duplicate-06.txt, as required
by rfc4858, and specfied in the 17-Sep-2008 version of .

    (1.a) Who is the Document Shepherd for this document? Has the
          Document Shepherd personally reviewed this version of the
          document and, in particular, does he or she believe this
          version is ready for forwarding to the IESG for publication?

The document shepherd is Matt Zekauskas
The document shepherd has personally reviewed this document and
believes this version is read for forwarding to the IESG for
publication.

    (1.b) Has the document had adequate review both from key WG members
          and from key non-WG members? Does the Document Shepherd have
          any concerns about the depth or breadth of the reviews that
          have been performed?

I believe the document has received sufficent review from key WG
members.  I don't believe there are key non-WG members that need to
review the document; I did ask Dave Thalor about IPv6 terminology to
make sure we were consistent.  I have no concerns about the depth or
breadth of reivews for this document.

    (1.c) Does the Document Shepherd have concerns that the document
          needs more review from a particular or broader perspective,
          e.g., security, operational complexity, someone familiar with
          AAA, internationalization or XML?

no.

    (1.d) Does the Document Shepherd have any specific concerns or
          issues with this document that the Responsible Area Director
          and/or the IESG should be aware of? For example, perhaps he
          or she is uncomfortable with certain parts of the document, or
          has concerns whether there really is a need for it. In any
          event, if the WG has discussed those issues and has indicated
          that it still wishes to advance the document, detail those
          concerns here. Has an IPR disclosure related to this document
          been filed? If so, please include a reference to the
          disclosure and summarize the WG discussion and conclusion on
          this issue.

I know of no unusual conerns of which the AD and IESG in general should
be aware.

I know of no IPR disclosures related to this document.

    (1.e) How solid is the WG consensus behind this document? Does it
          represent the strong concurrence of a few individuals, with
          others being silent, or does the WG as a whole understand and
          agree with it?

I believe this document fills a missing hole in the IPPM metrics, and there
is fairly broad consensus for this document.  There have been reviews and
comment by the vocal members.

    (1.f) Has anyone threatened an appeal or otherwise indicated extreme
          discontent? If so, please summarise the areas of conflict in
          separate email messages to the Responsible Area Director. (It
          should be in a separate email because this questionnaire is
          entered into the ID Tracker.)

no.

    (1.g) Has the Document Shepherd personally verified that the
          document satisfies all ID nits? (See
          http://www.ietf.org/ID-Checklist.html and
          http://tools.ietf.org/tools/idnits/). Boilerplate checks are
          not enough; this check needs to be thorough. Has the document
          met all formal review criteria it needs to, such as the MIB
          Doctor, media type and URI type reviews?

Yes, however one reference currently in the "informative" catagory
should be moved to normative based on the last revision.  See next.

    (1.h) Has the document split its references into normative and
          informative? Are there normative references to documents that
          are not ready for advancement or are otherwise in an unclear
          state? If such normative references exist, what is the
          strategy for their completion? Are there normative references
          that are downward references, as described in [RFC3967]? If
          so, list these downward references to support the Area
          Director in the Last Call procedure for them [RFC3967].

The references are split into normative and non-normative.  However,
the last revision moved one reference [RFC3432] from "Informative" to
"Normative".  We discussed this with our AD, and believe that it can
be corrected either in updates based on comments from the IETF-wide
last call, or during the RFC editing process.  There are no "downard
references" nor references to drafts.

    (1.i) Has the Document Shepherd verified that the document IANA
          consideration section exists and is consistent with the body
          of the document? If the document specifies protocol
          extensions, are reservations requested in appropriate IANA
          registries? Are the IANA registries clearly identified? If
          the document creates a new registry, does it define the
          proposed initial contents of the registry and an allocation
          procedure for future registrations? Does it suggest a
          reasonable name for the new registry? See [RFC5226]. If the
          document describes an Expert Review process has Shepherd
          conferred with the Responsible Area Director so that the IESG
          can appoint the needed Expert during the IESG Evaluation?

The IANA consideration section exists, and is consistent with the
metrics registry rquiremetns it references.

    (1.j) Has the Document Shepherd verified that sections of the
          document that are written in a formal language, such as XML
          code, BNF rules, MIB definitions, etc., validate correctly in
          an automated checker?

There are no such sections.

    (1.k) The IESG approval announcement includes a Document
          Announcement Write-Up. Please provide such a Document
          Announcement Write-Up? Recent examples can be found in the
          "Action" announcements for approved documents. The approval
          announcement contains the following sections:

          Technical Summary
            Relevant content can frequently be found in the abstract
            and/or introduction of the document. If not, this may be
            an indication that there are deficiencies in the abstract
            or introduction.

When a packet is sent from one host to the other, one normally
expects that exactly one copy of the packet that was sent arrives
at the destination.  It is, however, possible that a packet is
either lost or that multiple copies arrive.  This document defines
a metric for the case where a packet is sent, but multiple copies
arrive.  The document also discusses streams and methods to
summarize the results of streams.


          Working Group Summary
            Was there anything in WG process that is worth noting? For
            example, was there controversy about particular points or
            were there decisions where the consensus was particularly
            rough?

This document was suggested when creating a succint summary of IPPM
metrics for reporting to users; this was one that was missing from the
IPPM metric suite.  There is consensus that this is the right definition.
There has been some question as to whether the definition is crisp and
unambiguous for both IPv4 and IPv6, and the document has been modified
to address those concerns.

          Document Quality
            Are there existing implementations of the protocol? Have a
            significant number of vendors indicated their plan to
            implement the specification? Are there any reviewers that
            merit special mention as having done a thorough review,
            e.g., one that resulted in important changes or a
            conclusion that the document had no substantive issues? If
            there was a MIB Doctor, Media Type or other expert review,
            what was its course (briefly)? In the case of a Media Type
            review, on what date was the request posted?

I know of no current implementations that claim to implement this metric.
However, vendors in the working group have read and agreed with the
specification.