Path Aware Networking: A Bestiary of Roads Not Taken
draft-dawkins-panrg-what-not-to-do-00

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,
              <https://www.rfc-editor.org/info/rfc793>.

   [RFC1633]  Braden, R., Clark, D., and S. Shenker, "Integrated
              Services in the Internet Architecture: an Overview",
              RFC 1633, DOI 10.17487/RFC1633, June 1994,
              <https://www.rfc-editor.org/info/rfc1633>.

   [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,
              <https://www.rfc-editor.org/info/rfc2475>.

   [RFC2581]  Allman, M., Paxson, V., and W. Stevens, "TCP Congestion
              Control", RFC 2581, DOI 10.17487/RFC2581, April 1999,
              <https://www.rfc-editor.org/info/rfc2581>.

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, <https://www.rfc-editor.org/info/rfc5533>.

   [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,
              <https://www.rfc-editor.org/info/rfc5974>.

   [RFC5681]  Allman, M., Paxson, V., and E. Blanton, "TCP Congestion
              Control", RFC 5681, DOI 10.17487/RFC5681, September 2009,
              <https://www.rfc-editor.org/info/rfc5681>.

   [RFC7418]  Dawkins, S., Ed., "An IRTF Primer for IETF Participants",
              RFC 7418, DOI 10.17487/RFC7418, December 2014,
              <https://www.rfc-editor.org/info/rfc7418>.

   [NOTE_WELL]
              "IETF Note Well", n.d., <https://www.ietf.org/about/note-
              well.html>.

   [PANRG-99]
              "Path Aware Networking Research Group - IETF-99", July
              2017, <https://datatracker.ietf.org/meeting/99/sessions/
              panrg>.

   [PATH-Decade]
              Bonaventure, O., "A Decade of Path Awareness", July 2017,
              <https://datatracker.ietf.org/doc/slides-99-panrg-a-
              decade-of-path-awareness/>.

   [PANRG]    "Path Aware Networking Research Group (Home Page)", n.d.,
              <https://irtf.org/panrg>.

   [TRIGTRAN-55]
              "Triggers for Transport BOF at IETF 55", July 2003,
              <https://www.ietf.org/proceedings/55/239.htm>.

   [TRIGTRAN-56]
              "Triggers for Transport BOF at IETF 56", November 2003,
              <https://www.ietf.org/proceedings/56/251.htm>.

Author's Address

   Spencer Dawkins (editor)
   Huawei Technologies

   Email: spencerdawkins.ietf@gmail.com

Dawkins                Expires September 20, 2018               [Page 6]