Path Aware Networking: Obstacles to Deployment (A Bestiary of Roads Not Taken)
Note: This ballot was opened for revision 14 and is now closed.
Ballot question: "Is this draft ready for publication in the IRTF stream?"
Comment (2020-12-23 for -14) Sent
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.
Comment (2020-12-22 for -14) Sent
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.