A Reference Path and Measurement Points for Large-Scale Measurement of Broadband Performance
draft-ietf-ippm-lmap-path-07

[Ballot discuss]
1.
The charter says:
The WG will seek to develop new metrics and models to more accurately
characterize the network paths under test and/or the performance of
transport and application layer protocols on these paths.

However, the work seems to be targeting LMAP only.
It looks like some LMAP work is done in IPPM. Looking at the authors list, the same set of people is involved in both IPPM and LMAP, so that's minor issue. However, my primary concern :is this reference path is for LMAP ONLY? This is what the title says.
I understand that the primary audience for now is LMAP, but hopefully it could be reused somewhere else in the future for access network

Why not?

OLD Title: A Reference Path and Measurement Points for LMAP

NEW Title: A Reference Path and Measurement Points
Or
NEW Title: A Reference Path and Measurement Points for Access Networks

OLD abstract:

    This document defines a reference path for Large-scale Measurement of Broadband Access Performance (LMAP) and measurement points for commonly used performance metrics. Other similar measurement projects may also be able to use the extensions described here for measurement point location.

NEW abstract:

    This document defines a reference path for measurement points for commonly used performance metrics, such as Large-scale Measurement of Broadband Access Performance (LMAP).

Btw,  I would add to the abstract:

  The purpose is to create an efficient way to describe the location of
  the measurement point(s) used to conduct a particular measurement.


Some more changes might be required as well. For example: The scope of this memo is to define a reference path for LMAP activities with sufficient level of detail to determine the location of different measurement points along a path without ambiguity.

2. What if I want to add an extra element type in the reference path in section 4?
For example, a service type for service chaining: physical versus virtual
For example, I need to make the distinction between ISP-managed and subscribed-managed measurement agents on the subscriber device
Are the types extensible? How? This should be specified.

3. From my discussion with Brian Trammell (just on, on the two points above), I realized that the reference path could be used in future performance metric definition. Some text should be added.

[Ballot comment]

- I'm wondering if this works ok for a scenario where I use
my phone as a hotspot? From one POV there could then be 2
subscriber devices in the ref. path (with diff service
providers) and I'm not sure if that's allowed or not by
section 4. (Actually it might mean that network number 0
isn't a good plan?)

- How is this intended to be used when tunnels of various
kinds are in use? E.g. we've deployed stuff using openvpn a
number of times and it might be good if this stuff could be
used for measuring such deployments.

- Good that you have the privacy consideration here and the
pointer to the framework draft. (Which I've not read yet,
sorry.) That pointer means that privacy does need to
be substantively dealt with in the framework, but I
guess that'll be fine.

[Ballot comment]
I'd like to thank Elwyn for the Gen-ART review and authors for addressing the issues. However, the edits I believe are still to be applied to a -06. Is a new version forthcoming?

[Ballot discuss]
I just have a question on the security considerations section to see why there are no security considerations and why the described path is only a privacy issue.  Maybe this is fine, but I think there are some possible security considerations, please let me know if I am missing something that prevents this from being an issue.

In the referenced framework draft, the list of privacy-sensitive items in 8.2 makes sense.  Since the reference path is the path traversed by a flow of data (if I have the definition correct per the other questions), couldn't an attacker use the path information to perform a DoS or other attack at one or more points along the path?  Wouldn't this be both a security and privacy consideration?  I can see that all of the information about a device in the path could reveal privacy related data, but the host information could be used to take out (DoS) or compromise a point in the network as well.

Current text:
  When considering privacy of those involved in measurement or those
  whose traffic is measured, there is sensitive information
  communicated to recipients of the network diagrams illustrating paths
  and measurement points described above.  We refer the reader to the
  privacy considerations described in the Large Scale Measurement of
  Broadband Performance (LMAP) Framework [I-D.ietf-lmap-framework],
  which covers active and passive measurement techniques and supporting
  material on measurement context.

Perhaps adding in a sentence between those to highlight that attacks, such as DoS or other attacks, are possible along the Reference Path or identified measurement points.

[Ballot comment]
For the first paragraph of the Security Considerations, did you intend to say that there is no threat to an implementer of this draft?  It sounds odd to say there is none for the reader and the Internet.  Although with my question above, maybe this changes a bit more (or is deleted with a consideration added in the second paragraph).

[Ballot comment]
Tiny point: we're really trying to get away from "this memo" stuff... Can you call it a document instead?

I had the same problem as Adrian with the definition of "reference path", and I'm glad to see that Al is working on that.  For the record, here's the comment I'd composed offline, before I saw that conversation:
I'm not a performance metrics guy, I don't know what a "reference path" is, and there's no citation for it, though it's in the document title, abstract, introduction, and purpose and scope section.  I thought I could find it in RFC 2330, but it's not there ("path" alone is).  Where can I find a definition?  Please provide a reference and citation on first use in the intro.

[Ballot comment]
I have no objection to the publication of this document, but I really
struggled to get a grasp of the term "reference path". It seems
to be a fundamental term in sections 1 and 2, but doesn't get a lot of
explanation until section 3.1.

But even 3.1 is hard I suggested for me to grapple with.

  A reference path is a serial combination of routers, switches, links,
  radios, and processing elements that comprise all the network
  elements traversed by each packet between the source and destination
  hosts.  The reference path is intended to be equally applicable to
  all networking technologies, therefore the components are generically
  defined, but their functions should have a clear counterpart or be
  obviously omitted in any network technology.

I think may be it is your use of articles (definite vs. indefinite) and
plurals (singular vs plural) that has me confused.

"A reference path" or "The reference path"?

"traversed by each packet" or "traversed by a packet" or "traversed by
each packet in a flow"?

"The reference is intended" or "A reference path is intended"?

When you say "all networking technologies" in the context of "the path
of a packet" I wonder whether all networking technologies know what a
packet is.

I do wonder whether this key term could be defined in a clearer and
more comprehensible way.

Furthermore, the discussion in Section 4 seems to be discussion far
wider scoped elements in the reference path than is implied in the
section 3.1 definition (networks and access devices versus router,
switches, links and radios).

IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-ippm-lmap-path-05, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any IANA actions.

While it is helpful for the IANA Considerations section of the document to remain in place upon publication, if the authors prefer to remove it, IANA doesn't object.

If this assessment is not accurate, please respond as soon as possible.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (A Reference Path and Measurement Points for LMAP) to Informational RFC


The IESG has received a request from the IP Performance Metrics WG (ippm)
to consider the following document:
- 'A Reference Path and Measurement Points for LMAP'
  as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2014-08-22. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This document defines a reference path for Large-scale Measurement of
  Broadband Access Performance (LMAP) and measurement points for
  commonly used performance metrics.  Other similar measurement
  projects may also be able to use the extensions described here for
  measurement point location.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-ippm-lmap-path/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-ippm-lmap-path/ballot/


No IPR declarations have been submitted directly on this I-D.

1. Summary

The document shepherd is Brian Trammell.
The responsible Area Director is Spencer Dawkins.

  This document defines a reference path for Large-scale Measurement of
  Broadband Access Performance (LMAP) and measurement points for
  commonly used performance metrics.  The methods for measurement point
  location may be applicable to similar measurement projects using the
  extensions described here.

It is an IPPM document as the reference path is intended to be used in metric definitions and other guidance on how to use and deploy IPPM metrics in an LMAP context.

The intended status is Informational.

2. Review and Consensus

The document has had broad review within the IPPM and LMAP working groups. Many comments were received during first WGLC resulting in a substantial revision and a second WGLC. There is consensus within the IPPM working group (including participants from LMAP) to publish the document.

3. Intellectual Property

No IPR disclosures have been filed. All authors confirm that they have no undisclosed knowledge on IPR on the document.

4. Other Points

There are no downrefs. There are no IANA considerations, though the reference path described by this document may be referenced from the metrics registry currently under development within the working group.