Path Aware Networking: Obstacles to Deployment (A Bestiary of Roads Not Taken)
draft-irtf-panrg-what-not-to-do-19

(Via drafts-eval@iana.org): IESG/Authors/ISE:

The IANA Functions Operator has reviewed draft-irtf-panrg-what-not-to-do-16 and has the following comments:

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

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

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

Thank you,

Amanda Baber
Lead IANA Services Specialist

IRSG poll completed with support for publication. I'll put this into Waiting for Document Shepherd, while the authors and RG chairs decide if they feel an update is needed in response to Dave Oran's comments.

[Ballot comment]
Both after a final review, and as an RG chair who watched this document develop: this work is the result of two years of discussion and consideration of the history of path-aware-like approaches in the Internet; it is fairly comprehensive in scope (another Yes ballot references missing multicast, which I believe was intentional out of respect for the rabbithole that represents) and extracts useful lessons both for the research group as well as for the wider Internet protocol engineering community with respect to the wider space of transport-network cooperation. It is ready for publication in its current form.

[Ballot comment]
I'm in favor of publishing this, and the comments below don't need to be considered before advancing the document.
I gave it a detailed reading and if we decide to work on a -bis version in the future here are a few things I think could be improved upon:

- Things that measure paths and things that constrain paths are kind of mixed together. While you need to measure paths in order to have reasonable mechanisms to select/constrain them, the reverse is not necessarily the case.

- There's a minor mis-characterization of INTServ as requiring state in every intermediary. Intserv can work through a node that doesn't keep state, as long as that node is extremely unlikely to be a bottleneck. Also, it would be helpful here and in some other places to tease apart things that require data plane state only, control plane state only, or both.

- Associated with path awareness is the question of whether a mechanism supports admission control of endpoints/applications. One of the motivations of INTServ and a number of other architectures (e.g. DETnet) is the ability to "say no" to an application based on resource availability on a path *before* the application tries to inject traffic onto that path and discovers the path does not have the capacity to sustain enough utility to meet the application's minimum needs. The question of whether admission control is needed comes up over and over again, but we have learned a few useful lessons that, while covered implicitly in some of the lessons learned of the document, might be explained explicitly:
    * We have gained a lot of experience with application-based adaptation since the days where applications just injected traffic in-elastically unto the network. Such adaptations seem to work well enough that admission control is of less value to these applications
    * There are end-to-end measurement techniques that can steer traffic at layer 7 rather than layer 3 (CDNs, multi-CDNs like Conviva, etc.)
    * Often, applications don't actually know enough about their admission control threshold to be able to ask accurately for the resources they need and attempts to help them haven't gotten anywhere (e.g. the multi-TSPEC additions to RSVP to attempt to mirror codec selection by applications).

- There's no discussion of multicast in the document. Not a serious omission, but perhaps useful to add in the future.

- Some of the history explained here could shed light on more fundamental aspects of the IP protocol architecture. If path awareness continues to be of interest to the community, understanding what is "baked into IP" and what is not could be helpful. One deep example is path asymmetry. Many things about path awareness (and QoS as well) are made vastly more difficult when paths are asymmetric. One could define ways to add symmetry constraints to IP rather than try over and over to work in its absence. There may be some useful insight here as well from the choice by the CCNx and NDN protocol architectures to enforce path symmetry: path awareness and path selection become substantially easier to attain.

Waiting for confirmation from Mallory Knodel that -14 addresses her IRSG review comment, and from the RG chairs that they're happy for this to advance to IRSG ballot.

1. Summary
The document shepherd is Jen Linkova. The IRTF Chair is Colin Perkins.

The document provides an overview and and analysis of  past efforts to develop and deploy Path Aware techniques, most of which were unsuccessful or at most partially successful, in order to extract insights and lessons for path-aware networking researchers.

2. Review and Consensus
The document has been thoughtful reviewed by the RG. It passed the RG Last Call. All comments received during the previous review cycles and the RGLC are addressed in the -12 version of the document.
The research group is quite sure that publishing this document as an informational RFC will be a useful reference for future work in the PANRG as well as other RGs and IETF WGs.

3. Intellectual Property
Each author has confirmed conformance with BCP 78/79. There are no IPR disclosures on the document.

4. Other Points
There are no normative references in this document. The document introduces no new security considerations.
There is no default shepherd writeup template for the IRTF stream