Subject: New Year's Exploration: Changing the Internet's Infrastructure

From: Dave CROCKER <[email-masked]>
Date: Fri, 31 Dec 2010 06:56:46 -0800

Folks,

Feliz Año Nuevo!

One of the lessons of efforts such as IPv6 and DNSSEC should be that making 
changes to the global infrastructure of the Internet is extremely difficult. 
The technical details are difficult -- especially if the change seeks to work 
with an existing base of functionality -- and the administration and operation 
details are difficult.  And the time it takes to achieve critical mass is quite 
long.

However we continue to hear claims and see design efforts that are based on the 
view that changing the infrastructure is easier than changing end-systems.[1] 
The fact that the infrastructure is controlled by far fewer actors and 
organizations makes it natural to assume that this preference is well-founded 
and correct.

But does the Internet's track record substantiate this view?

So I would like to ask for folks to help the community develop some concrete 
information about this, by adding entries and comments to the IETF's Outcomes Wiki:

    <http://trac.tools.ietf.org/misc/outcomes/>[2]

If there is a piece of work that was targeting change to the infrastructure or 
the creation of new infrastructure, please add an entry for it to the wiki. 
This will provide an explicit statement about the history and degree of success 
of that effort.

Congestion control, mobility, multipath, multicasting, new transport, MIME, etc. 
Anything that enables higher-level capabilities.

Some infrastructure changes are designed for the router level of things and some 
are designed for host-level.  But they provide underlying services that can then 
be used for better performance, reliability, or control or to make new 
applications viable.

My expectation is that we are going to find that such efforts are difficult, no 
matter where they are put, but I suspect we will find that the ones destined for 
the router level of things are the hardest.

Prove me wrong by adding entries to the Outcomes wiki that show otherwise...

Or prove me correct.

Having clarity about this topic could make for a pretty good start of the new 
year...

d/

[1]  Serious pursuit of this topic requires some agreement about the definition 
of "infrastructure" and quite possibly agreement on "end-system".  For now, 
let's just say that infrastructure is anything that provides services to a layer 
above.  That makes TCP a kind of infrastructure service.  But, then, the 
environment for controlling it is quite different, since it sits in hosts, not 
routers.  So perhaps we need some additional constructs for the "venue" of 
infrastructure service?.

[2]  We might discover that it will help to add a column to the wiki's tables. 
That's fine to explore on the wiki's mailing list:

      <https://www.ietf.org/mailman/listinfo/ietf-outcomes>

Given footnote [1], an example of a change might be a column that notes where 
the service resides in terms of Internet architecture.  Granularity that 
distinguishes more than just host-vs-router might be helpful, since the 
Internet's range of "tussle" boundaries has grown more complex, given the 
operational reality of PCs, servers, organizational nets, local ISPs and transit 
nets...

In the absence of agreements to make changes, use the Comments column in the 
wiki, for recording information that might warrant a new column in the table.

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: Masataka Ohta <[email-masked]>
Date: Sat, 01 Jan 2011 00:13:41 +0900

Dave CROCKER wrote:

> However we continue to hear claims and see design efforts that are based 
> on the view that changing the infrastructure is easier than changing 
> end-systems.[1]

Wrong.

The fact that the major application on the Internet easily and
smoothly changed from FTP to HTTP is the counter proof.

It is a proven fact that upgrading end systems is trivially easy.

Note also that IPv6 and DNSSEC require to *CHANGE* *BOTH* of the
infrastructure and the end-systems and that many, if not most,
end systems are IPv6 capable.

							Masataka Ohta

---

From: "Richard L. Barnes" <[email-masked]>
Date: Fri, 31 Dec 2010 12:38:37 -0500

Hey Dave,

I admire your desire for "clarity" on this subject, but fear you will be disappointed.

ISTM that the success of changes to the infrastructure depends on the value those changes deliver to participants in the Internet economy -- i.e., the pain of the problem they solve.  Your two examples are actually very appropriate here: IPv6 and DNSSEC both moved very slowly until (1) people started to not have enough numbers to grow their networks, and (2) Dan Kaminsky put the fear of God in people.

So the question is rather how many problems there are in the current infrastructure that cause people enough pain to do something.  I think there are at least a couple (improving BGP security, for example), and the number will probably slowly shrink over time, but in the long run, I expect there will ultimately always be a few big things that need to be done that can't be done in end systems.

--Richard 

On Dec 31, 2010, at 9:56 AM, Dave CROCKER wrote:

> Folks,
> 
> Feliz Año Nuevo!
> 
> One of the lessons of efforts such as IPv6 and DNSSEC should be that making changes to the global infrastructure of the Internet is extremely difficult. The technical details are difficult -- especially if the change seeks to work with an existing base of functionality -- and the administration and operation details are difficult.  And the time it takes to achieve critical mass is quite long.
> 
> However we continue to hear claims and see design efforts that are based on the view that changing the infrastructure is easier than changing end-systems.[1] The fact that the infrastructure is controlled by far fewer actors and organizations makes it natural to assume that this preference is well-founded and correct.
> 
> So I would like to ask for folks to help the community develop some concrete information about this, by adding entries and comments to the IETF's Outcomes Wiki:
> 
> If there is a piece of work that was targeting change to the infrastructure or the creation of new infrastructure, please add an entry for it to the wiki. This will provide an explicit statement about the history and degree of success of that effort.
> 
> Congestion control, mobility, multipath, multicasting, new transport, MIME, etc. Anything that enables higher-level capabilities.
> 
> Some infrastructure changes are designed for the router level of things and some are designed for host-level.  But they provide underlying services that can then be used for better performance, reliability, or control or to make new applications viable.
> 
> My expectation is that we are going to find that such efforts are difficult, no matter where they are put, but I suspect we will find that the ones destined for the router level of things are the hardest.
> 
> Having clarity about this topic could make for a pretty good start of the new year...
> 
> 
> d/
> 
> 
> [1]  Serious pursuit of this topic requires some agreement about the definition of "infrastructure" and quite possibly agreement on "end-system".  For now, let's just say that infrastructure is anything that provides services to a layer above.  That makes TCP a kind of infrastructure service.  But, then, the environment for controlling it is quite different, since it sits in hosts, not routers.  So perhaps we need some additional constructs for the "venue" of infrastructure service?.
> 
> 
> [2]  We might discover that it will help to add a column to the wiki's tables. That's fine to explore on the wiki's mailing list:
> 
> Given footnote [1], an example of a change might be a column that notes where the service resides in terms of Internet architecture.  Granularity that distinguishes more than just host-vs-router might be helpful, since the Internet's range of "tussle" boundaries has grown more complex, given the operational reality of PCs, servers, organizational nets, local ISPs and transit nets...
> 
> In the absence of agreements to make changes, use the Comments column in the wiki, for recording information that might warrant a new column in the table.
> 
> -- 
> 
>  Dave Crocker
> _______________________________________________
> Ietf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf

---

From: John Leslie <[email-masked]>
Date: Fri, 31 Dec 2010 13:38:43 -0500

Richard L. Barnes <[email-masked]> wrote:
> 
> ISTM that the success of changes to the infrastructure depends on the
> value those changes deliver to participants in the Internet economy...
> So the question is rather how many problems there are in the current
> infrastructure that cause people enough pain to do something.

   Indeed -- _an_ interesting question... but perhaps not phrased quite
right: in truth, there are an arbitrarily large number of problems that
cause _somebody_ enough pain to do something.

> I think there are at least a couple (improving BGP security, for
> example), and the number will probably slowly shrink over time,
> but in the long run, I expect there will ultimately always be a few
> big things that need to be done that can't be done in end systems.

   Start from the end: there _will_ be a number of things that shouldn't
be done in end systems. End systems _really_don't_ want to worry about
the route packets follow -- at most they want to worry about delay,
jitter, and order of delivery. But they _will_ work with whatever tools
are available to ameliorate such worries.

   The number of problems will most surely _increase_ over time, not
shrink.

   BGP security is a _dreadful_ example. It conflates weaknesses of the
original design with issues entirely out-of-scope of the original design.
And the original design was seriously flawed by defining algorithms
instead of meanings.

   Nonetheless, the example does serve to illustrate a weakness of IETF
process -- that it's much easier to get traction on small fixes to
parts of the problem than on migration to a design which avoids the
problems.

   BTW, I find it interesting to see how little of the work originating
in the Security area has gained traction. I wonder to what extent this
results from:

- cycles being expended on cross-area reviews;

- recommending IPsec whether or not it could be deployed for the use;

- the inherent complexity of key infrastructure?

--
John Leslie <[email-masked]>