Papers on the Evolvability of the Internet Infrastructure:
This page maintains pointers to papers that examine the
evolvability of the Internet architecture.
One specific concern is to understand
those changes to the Internet
infrastructure that, while providing a (perhaps temporary) fix for one set
of problems, at the same time create another set of stresses, or block
other potential developments in the infrastructure.
Related web pages:
Papers about Research Questions for the Internet.
References on Layering and the Internet Architecture.
Topics so far:
- Dave Plonka,
"Embedding Globally Routable Internet Addresses Considered Harmful"
"What does this unintentional Denial-of-Service flood indicate about
the viability of some public Internet services?"
"Can the Internet routing infrastructure be improved to enable less
disruptive solutions to such problems?"
"Are incidents such as this a likely side-effect of ubiquitous,
low-cost, perhaps even disposable Internet hosts?"
John C. Klensin,
Role of the Domain Name System,
draft-klensin-dns-role-01.txt, 2001, internet-draft, work in
"Protocols tend to be deployed at a
just-past-prototype level, typically including the types of expedient
compromises typical with prototypes...
Applications that are "almost good enough" prevent
development and deployment of high-quality replacements." - Section 1.4.
Section 2, "Signs of DNS overloading": "The DNS is becoming overloaded
(semantically if not in the mechanical ability to resolve names)."
Are We Overloading the Saddlebags on an Old Horse?,
IETF, San Diego, December 2000.
Recommendations for the Design and Implementation of NAT-Tolerant Applications,
"It is the focus of this document to provide recommendations to
authors of new protocols about the effects to consider when designing
new protocols such that special handling is not required at NAT
Network Address Translator (NAT)-Friendly Application Design Guidelines,
RFC 3235, January 2002.
"While many common Internet applications will operate cleanly in
the presence of Network Address Translators, others suffer from a
variety of problems when crossing these devices. Guidelines are
presented herein to help ensure new protocols and applications will,
to the extent possible, be compatible with NAT (Network Address
MBONE Deployment Working Group.
S. Bhattacharyya et al.,
An Overview of Source-Specific Multicast(SSM) Deployment,
draft-ietf-ssm-overview-02.txt, internet draft, work in progress, 2001.
C. Diot at al,
Issues for the IP Multicast Service and Architecture,
IEEE Network, January/February 2000.
"We examine the issues that have limited the commercial
deployment of IP-multicast from the viewpoint of carriers."
P. Sharma and R. Malpani,
IP Multicast Operational Network Management:
Design, Challenges, and Experiences,
IEEE Network, March 2003.
"The lack of appropriate network management tools
for IP multicast has proven to be a major barrier
to its deployment".
- Gregory Bell,
Failure to Thrive: QoS and the Culture of Operational Networking,
LBNL, September 2003.
"Understanding the culture of operational networking can help
to illuminate the question of why QoS has floundered.
Network administrators have a well-founded aversion to complexity,
in part because they experience failures attributable
to design complexity on a regular basis."
- Brian Carpenter, Kathleen Nichols,
Differentiated Services in the Internet,
Technical Paper, February 2002.
"This disregard for the administrative boundaries of networks
flaws all four approaches listed above" [referring to IP precedence and TOS,
IBM's SNA (Systems Network Architecture), the Internet Stream Protocol
(ST), and Integrated Services].
- G. Huston,
Next Steps for the IP QoS Architecture,
RFC 2990, November 2000.
Section 3.12: "How does the widespread deployment of service-aware
networks commence? Which gets built first - host applications or network
Why Information Security is Hard - an Economic
"The management of information security is a much deeper and more
political problem than is usually realized; solutions are likely to
be subtle and partial, while many simplistic technical approaches
are bound to fail. The time has come for engineers, economists,
lawyers, and policymakers to try to forge common approaches."
Middleboxes: Taxonomy and Issues,
RFC 3234, Informational, February 2002.
This document does not directly discuss the ways that middleboxes
both enable and hinder the evolution of the Internet architecture,
but it lays down the terminology as a first step.
David D. Clark and Marjory S. Blumenthal,
Rethinking the design of the Internet: The end to end arguments vs.
the brave new world, August 2000.
"This paper looks at the Internet and the changing set of requirements
for the Internet that are emerging as it becomes more commercial, more
oriented towards the consumer, and used for a wider set of purposes...
We argue that the open, general nature of the Net, which derived from
the end to end arguments, is a valuable characteristic that encourages
innovation, and this flexibility should be preserved."
Agile Internet Evolution?
L. Williams and A. Cockburn, Agile Software Development: It's about
Feedback and Change", IEEE Computer, June 2003.
Manifesto for Agile Software Development
describes the four comparative values underlying the agile position:
individuals and interactions over processes and tools,
working software over comprehensive documentation,
customer collaboration over contract negotiation, and
responding to change over following a plan."
Proposed additions to this page can be sent to
Thanks for David Wetherall for pointers to add to this page.
Last modified: January 2008