PANRG S. Dawkins, Ed. Internet-Draft Huawei Technologies Intended status: Informational March 19, 2018 Expires: September 20, 2018 Path Aware Networking: A Bestiary of Roads Not Taken draft-dawkins-panrg-what-not-to-do-00 Abstract At the first meeting of the proposed Path Aware Networking Research Group, Oliver Bonaventure led a discussion of our mostly-unsuccessful attempts to exploit Path Awareness to achieve a variety of goals, over the past decade. At the end of that discussion, the research group agreed to catalog and analyze these ideas, to extract lessons for network researchers. This document contains that catalog and analysis. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on September 20, 2018. Copyright Notice Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must Dawkins Expires September 20, 2018 [Page 1] Internet-Draft What Not To Do March 2018 include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. 1. Introduction At IETF 99, the proposed Path Aware Networking Research Group [PANRG] held its first meeting [PANRG-99], and the first presentation in that session was "A Decade of Path Awareness" [PATH-Decade]. At the end of this discussion, two things were abundantly clear. o The Internet community has accumulated considerable experience with many Path Awareness ideas over a long period of time, and o Although some Path Awareness ideas have been successfully deployed (for example, Differentiated Services, or DiffServ [RFC2475]), most of these ideas haven't seen widespread adoption. The reasons for this non-adoption are many and varied. The meta-lessons from this experience are o Path Aware Networking is more Research than Engineering, so establishing an IRTF Research Group for Path Aware Networking is the right thing to do [RFC7418], and o Cataloging and analyzing our experience to learn the reasons for non-adoption is a great first step for the proposed Research Group. This document contains that catalog and analysis. 1.1. About this Document This document is not intended to include every idea about Path Aware Networking that we can find. Instead, we include enough ideas to provide background for new lessons to guide researchers in their work, in order to add those lessons to Section 2. There is no shame to having your idea included in this document. We were trying to engineer something that was research. The document editor started with a subsection on his own idea. The only shame is not learning from experience, and not sharing that experience with other networking researchers and engineers. This document is being built collaboratively. To contribute your experience, please send a Github pull request to https://github.com/panrg/draft-dawkins-panrg-what-not-to-do. Dawkins Expires September 20, 2018 [Page 2] Internet-Draft What Not To Do March 2018 Discussion of contributed experiences should take place on the PANRG mailing list. 2. Summary of Lessons Learned This section summarizes the Lessons Learned from the contributed sections in Section 4. o The benefit of Path Awareness has to be great enough to overcome entropy for already-deployed devices. The colloquial American English expression, "If it ain't broke, don't fix it" is in full flower on today's Internet. o If intermediate devices along the path can't be trusted, it's difficult to rely on intermediate devices to drive changes to behaviors. o If operators can't charge for a Path Aware technology in order to recover the costs of deploying it, the benefits must be really significant. 3. Template for Contributions There are many things that could be said about the Path Aware networking technologies that have been developed. For the purposes of this document, contributors are requested to provide o the name of a technology, including an abbreviation if one was used o if available, a long-term pointer to the best reference describing the technology o a short description of the problem the technology was intended to solve o a short description of the reasons why the technology wasn't adopted o a short statement of the lessons that researchers can learn from our experience with this technology. 4. Contributions The editor has added some suggested subsections as a starting place, but others are solicited and welcome. Dawkins Expires September 20, 2018 [Page 3] Internet-Draft What Not To Do March 2018 4.1. Integrated Services (IntServ) and follow-on Technologies (NSIS) Write-up of Integrated Services (IntServ) [RFC1633] and follow-on Technologies (NSIS) [RFC5974] Your description could be here. 4.2. Triggers for Transport (TRIGTRAN) TCP [RFC0793] has a well-known weakness - the end-to-end flow control mechanism has only a single signal, the loss of a segment, and semi- modern TCPs (since the late 1980s) have interpreted the loss of a segment as evidence that the path between two endpoints has become congested enough to exhaust buffers on intermediate hops, so that the TCP sender should "back off" - reduce its sending rate until it knows that its segments are now being delivered without loss [RFC2581]. More modern TCPs have added a growing array of strategies about how to establish the sending rate [RFC5681], but when a path is no longer operational, TCPs can wait many seconds before retrying a segment, even if the path becomes operational while the sender is waiting to retry. The thinking in Triggers for Transport was that if a path completely stopped working because its first-hop link was "down", that somehow TCP could be signaled when the first-hop link returned to service, and the sending TCP could retry immediately, without waiting for a full Retransmission Time Out (RTO). Two TRIGTRAN BOFs were held, at IETF 55 [TRIGTRAN-55] and IETF 56 [TRIGTRAN-56], but this work was not chartered, and the reasons why provide several useful lessons for researchers. o TRIGTRAN triggers are only provided when the first-hop link is "down", so TRIGTRAN triggers couldn't replace normal TCP retransmission behavior if the path failed because some link further along the network path was "down". So TRIGTRAN triggers added complexity to an already complex TCP state machine, and didn't allow any existing complexity to be removed. o The state of the art in the early 2000s was that TRIGTRAN triggers were assumed to be unauthenticated, so they couldn't be trusted to tell a sender to "speed up", only to "slow down". This reduced the benefit to implementers. o intermediate forwarding devices required modification to provide TRIGTRAN triggers, but operators couldn't charge for TRIGTRAN triggers, so there was no way to recover the cost of modifying, testing, and deploying updated intermediate devices. Dawkins Expires September 20, 2018 [Page 4] Internet-Draft What Not To Do March 2018 4.3. SHIM6 Write-up of SHIM6 [RFC5533] Your description could be here. 5. Security Considerations This document describes ideas that were not adopted and widely deployed on the Internet, so it doesn't affect the security of the Internet. If this document meets its goals, we may develop new ideas for Path Aware Networking that would affect the security of the Internet, but those effects will be described in the corresponding RFCs for those ideas. 6. IANA Considerations This document makes no requests of IANA. 7. Acknowledgements The section on Triggers for Transport (TRIGTRAN) was provided by Spencer Dawkins. Review comments were provided by (your name could be here). 8. Informative References [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, DOI 10.17487/RFC0793, September 1981, . [RFC1633] Braden, R., Clark, D., and S. Shenker, "Integrated Services in the Internet Architecture: an Overview", RFC 1633, DOI 10.17487/RFC1633, June 1994, . [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, DOI 10.17487/RFC2475, December 1998, . [RFC2581] Allman, M., Paxson, V., and W. Stevens, "TCP Congestion Control", RFC 2581, DOI 10.17487/RFC2581, April 1999, . Dawkins Expires September 20, 2018 [Page 5] Internet-Draft What Not To Do March 2018 [RFC5533] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming Shim Protocol for IPv6", RFC 5533, DOI 10.17487/RFC5533, June 2009, . [RFC5974] Manner, J., Karagiannis, G., and A. McDonald, "NSIS Signaling Layer Protocol (NSLP) for Quality-of-Service Signaling", RFC 5974, DOI 10.17487/RFC5974, October 2010, . [RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion Control", RFC 5681, DOI 10.17487/RFC5681, September 2009, . [RFC7418] Dawkins, S., Ed., "An IRTF Primer for IETF Participants", RFC 7418, DOI 10.17487/RFC7418, December 2014, . [NOTE_WELL] "IETF Note Well", n.d., . [PANRG-99] "Path Aware Networking Research Group - IETF-99", July 2017, . [PATH-Decade] Bonaventure, O., "A Decade of Path Awareness", July 2017, . [PANRG] "Path Aware Networking Research Group (Home Page)", n.d., . [TRIGTRAN-55] "Triggers for Transport BOF at IETF 55", July 2003, . [TRIGTRAN-56] "Triggers for Transport BOF at IETF 56", November 2003, . Author's Address Spencer Dawkins (editor) Huawei Technologies Email: spencerdawkins.ietf@gmail.com Dawkins Expires September 20, 2018 [Page 6]