[Docs] [txt|pdf] [Tracker] [WG] [Email] [Nits]
Versions: 00 01
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]
Html markup produced by rfcmarkup 1.127, available from
https://tools.ietf.org/tools/rfcmarkup/