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

[David Farber <dave () farber net>]

Begin forwarded message:

> From: Dave CROCKER <dcrocker () bbiw net>
> Date: November 5, 2008 1:56:20 PM EST
> To: dave () farber net
> Cc: 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 
> >
> Subject: Re: [IP] the undead urban myth of the LOC/EID split
>
> 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




-------------------------------------------
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