Re: the undead urban myth of the LOC/EID split

[David Farber <dave () farber net>]

Begin forwarded message:

From: Jon Crowcroft <Jon.Crowcroft () cl cam ac uk>
Date: November 5, 2008 5:51:33 PM EST
To: Dave CROCKER <dcrocker () bbiw net>
Cc: dave () farber net, ip <ip () v2 listbox com>, Tony Lauck <tlauck () madriver com 
>, John Day <jeanjour () comcast net>, Richard Bennett <richard () bennett com 
>, Jon Crowcroft <Jon.Crowcroft () cl cam ac uk>, John Wroclawski <jtw () isi edu 
>, Jon.Crowcroft () cl cam ac uk
Subject: Re: [IP] the undead urban myth of the LOC/EID split

teemu koponen implemented exactly this as part of his thesis in
helsinki (starte with scott shenker and others)

i suggest people look at what has been done recenly by young people
(working code)

I also suggest that a 4B node cell phone system is more worthy of
study than the 1B internet these days if you are interested in
scaleable mobile system supprt. before the 3GPP people break it, that
is:)



In missive <4911EC54.2060200 () bbiw net>, Dave CROCKER typed:

> > For IP, if you wish...
> >
> >
> > Dave, et al,
> >
> > Fascinating and disheartening thread, consistent with the history  
> > of this topic.
> >  Loc/EID seems to be the third-rail of networking discussion.   
> > Experienced,
> > thoughtful folk, mostly talking past each other.
> >
> > But snippets of the comments suggest a way to make progress:
> >
> >
> > --------------------------------------------------------------------------
> >
> > > From: Tony Lauck <tlauck () madriver com>
> > ...
> > > In my opinion, there is sufficient complexity in the network layer  
> > > to
> > > keep protocol experts, router vendors, and exploitative carriers  
> > > busy
> > > for at least another generation. Therefore anything that can be  
> > > pulled
> > > out of the network layer should be.
> > >
> > > The ID function can be done by the end system without regard to  
> > > network
> > > layer addressing.
> > --------------------------------------------------------------------------
> >
> > > From: John Day <jeanjour () comcast net>
> > ...
> > > With a structure like this, mobility is nothing more than dynamic
> > > multihoming.
> > ...
> > >    But what we are seeing is that multihoming is
> > > becoming very widespread and I don't think we have seen anything  
> > > near
> > > the end of it.
> > --------------------------------------------------------------------------
> >
> > > From: Richard Bennett <richard () bennett com>
> > >    I feel I can say with reasonable confidence that
> > > "Patterns in Network Architecture" is the most important book on  
> > > network
> > > protocols in general and the Internet in particular ever written.
> > ...
> > >   Readers, even the uninitiated, should take
> > > away from the book an appreciation for the fact that network
> > > architecture is as much a political exercise as a technical one, and
> > > always has been.
> > >
> > > At a time when public policy makers are literally inundated with  
> > > opinion
> > > about the Internet's design and social implications, it's  
> > > important to
> > > peel away the metaphors and  analogies and take a look at how it  
> > > really
> > > works, what it does, what it doesn't do, what it could do a lot  
> > > better,
> > > and how it got the way it is.
> > --------------------------------------------------------------------------
> >
> >
> > The Internet had perhaps a million users when IPng became a serious  
> > effort, 15
> > years ago.  That's not an installed base to ignore.  We have over a  
> > billion now.
> > Anyone looking to enhance things with a better Loc/EID model either  
> > builds
> > upon  that reality or will be trying to boil an ocean.  Replacing  
> > existing
> > addressing with an entirely new Loc/EID addressing architecture  
> > requires boiling
> > the Internet ocean.  (Given global warming, perhaps it looks like  
> > boiling an
> > ocean is actually possible, but not one we should embrace.)
> >
> > I suggest we defer history discussion, since it consistently invites
> > distracting, contentious debate about the details and ultimately it  
> > doesn't
> > offer much insight about how to proceed. Good for haggling over  
> > beer, but not
> > for trying to make progress developing a technical enhancement.
> >
> > Standardization is a process of getting one or more diverse  
> > communities of
> > people -- groups of groups -- to agree on something.  Interesting  
> > social
> > decision-making processes inherently entail "politics".   
> > Participants develop
> > competing preferences and seek to have their own preferences  
> > prevail, for
> > whatever reason, selfish or ideal.  We like to think of engineering  
> > debate as
> > objective, but it is a human process and the human process of  
> > resolving
> > different preferences is politics.  The politics can be clean and  
> > simple, or not.
> >
> > But since the word politics is so distracting, let's re-cast it as  
> > "juggling
> > requirements and design trade-offs".
> >
> > Except that specific 'requirements', and community consensus about  
> > them, are
> > exactly what has been missing. We really do not have a concise,  
> > compelling
> > statement about market requirements for new splitting of Loc/EID  
> > constructs and
> > we certainly do not have community agreement on those requirements.
> >
> > That is what motivated my selections, above, starting with Tony  
> > Lauck's
> > observation about complexity:  The network layer really does work  
> > well.  I mean
> > *really* well. As "experiments" or "prototypes" go, IPv4 has  not  
> > done all that
> > badly.  Not too many technologies scale over that many years and  
> > that many
> > orders of magnitude of population size and performance speeds.
> >
> > To that end, an IP Address makes an entirely credible Locator and  
> > we should
> > leave it alone.  We can go a very long way farther by simply  
> > declaring that the
> > existing IPv* mechanisms define the network Locator.  In terms of  
> > the global
> > Internet, it gets packets delivered from one resource to another.   
> > If we think
> > we need other Locators, they are independent of the current one,  
> > and the case
> > for them needs to be clear and compelling.  I haven't see one yet.   
> > Have you?
> >
> > Given vague or missing requirements, it's easy to say that the need  
> > for an EID
> > is also satisfied:  Domain names.  Maybe URNs (but no, not URLs.)   
> > So, we've had
> > a credible Loc/EID split ever since we've had hostnames.
> >
> > You don't like those choices?  Then define concrete requirements  
> > that mandate
> > something different.  The requirements must be in terms of real- 
> > world, end-user
> > capabilities and uses, not just an assertion of that a particular  
> > mechanism is
> > needed.  What do end-users want to do that they can't do now, and  
> > how will those
> > mechanisms permit it, and where is the market demand demonstrating  
> > those needs?
> >
> > And therein lies the real failure of the last 15 or more years of  
> > Loc/EID
> > effort:  Most have entailed proposing generic mechanisms,  
> > satisfying vague
> > goals, without serious requirements specification or developing  
> > serious,
> > market-driven constituency about them.
> >
> > In the IETF, mobility and multihoming are entirely independent  
> > efforts.  In
> > fact, *multiple* independent efforts, since they are also split  
> > between IPv4 and
> > IPv6.
> >
> > The current tendency is to formulate proposals that require  
> > substantial
> > infrastructure changes, to the network layer, to NATs, and so on.   
> > Given a
> > sufficiently compelling market pull, that might work, but we don't  
> > have it, and
> > I'm betting we won't. That's why these efforts are lingering on for  
> > years but
> > gaining little apparent traction.
> >
> > Some types of mobility and some types of multihoming are entirely  
> > different from
> > each other.  But much of the space of each really represents two  
> > sides of the
> > same coin.  This has been observed a number of times over the  
> > years, but the
> > implication has been lost:  We can have a single solution satisfy  
> > useful
> > scenarios of mobility and useful scenarios of multihoming.
> >
> > We can further have those solutions require no change to the  
> > existing Internet
> > network-layer infrastructure.  None!
> >
> > The hard question is what layer or sub-layer to place it at. A shim  
> > layer,
> > between network and transport, is the obvious choice, but it's  
> > problematic.
> > Unfortunately, the prevalence of stateful NATs really means that  
> > the new
> > mechanism needs to be above the transport layer.
> >
> > So... Take the core requirement as supporting mild forms of  
> > mobility and
> > multihoming.  Not fast or extremely frequent changes.  Assume that  
> > probabilities
> > are high that a next packet will travel over the same path as the  
> > previous path.
> > Assume that clients are potentially mobile, but not servers.  This  
> > sounds like
> > heresy to purists, but actually covers most existing or emerging  
> > scenarios...
> > including P2P.  Current P2P applications go through stable servers.
> >
> > Assume that a client can find a server through the DNS and  
> > establish an
> > association (connection, session, whatever) through existing  
> > means.  This
> > reduces the task to one of sustaining the association across IP  
> > Address
> > transitions.
> >
> > The DNS remains the discovery mechanism.  If the association uses a  
> > contextual
> > transport, like TCP, set up a new connection.  NATs are now happy;  
> > they merely
> > see another connection.
> >
> > The variant between mobility and multihoming is that additional  
> > associations are
> > sequential or only slightly overlapping, for mobility, but likely  
> > to be mostly
> > overlapping for multihoming.
> >
> > What remains is establishing that an exchange with a different IP  
> > Address -- and
> > possibly different TCP connection -- has the same application  
> > context as another
> > association.  Work on this has been done and seems to be entirely  
> > tractable,
> > using computational, transient, context-defining EIDs.
> >
> > So, how to add this mechanism to the Internet?  And how to do it  
> > without
> > modifying any of the existing data transfer infrastructure?
> >
> > Here's an 'experiment' that would be easy and fairly cheap to  
> > conduct:
> >
> >     Define this 'resumption' protocol as an extension to SSL/TLS.   
> > SSL/TLS is
> > a session-layer mechanism with good bones for this sort of  
> > enhancement.
> >
> >     Add the mechanism to the major libraries for SSL/TLS.
> >
> >     Re-install those libraries in existing applications.
> >
> >     Any client/server mechanism that uses SSL/TLS now supports
> > mobility/multihoming.
> >
> > Do I really think it's that trivial?  Of course not.  But do I  
> > think it entails
> > relatively straightforward engineering and refinement with this  
> > order of effort?
> > Yup.
> >
> > It would be a very modest project to create, deploy and use.  And  
> > it would
> > support meaningful new activities.
> >
> > d/
> > --
> >
> >  Dave Crocker
> >  Brandenburg InternetWorking
> >  bbiw.net

cheers

  jon





-------------------------------------------
Archives: https://www.listbox.com/member/archive/247/=now
RSS Feed: https://www.listbox.com/member/archive/rss/247/
Powered by Listbox: http://www.listbox.com