[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [rrg] Constraints on a solution - "incrementally deployable" again

Hi Robin,

Thanks very much for the detailed response. Further thoughts inline.

On Apr 16, 2009, at 1:22 AM, Robin Whittle wrote:


Short version:    Responding to Tom Vest's concern about how the
                 constraints on widespread adoption of a scalable
                 routing solution seem to preclude widespread
                 adoption of IPv6.

Hi Tom,

Regarding my suggested text:

 http://www.ietf.org/mail-archive/web/rrg/current/msg04815.html

you wrote:
FWIW I like what's here. However, if we subsequently find ourselves in a world where IPv6 remains undeployed, and (possession of) IPv4 continues 
to represent a critical bottleneck to nontrivial participation in the
routing system, then most/all of the maxims below would seem to be
largely or exclusively relevant to "incumbent" IPv4 holders.


I tried to describe the constraints as I saw them.  The pressure to
retain existing applications and stacks is extremely strong - surely
too strong in the foreseeable future to allow widespread voluntary
adoption of a solution which required extensive stack or application
changes.

I didn't refer to the possibility of adopting a completely new kind
of new address space (IPv6 instead of IPv4) and the required new ISP
connectivity to support it, as would be the case if the solution
involved IPv6 or some other alternative to IPv4.

That would be precluded by the points:

  2 & 3 - Hosts with the IPv6 address only get multihoming etc. with
          communication with other IPv6 hosts.  Because the solution
          presumably only provides benefits for IPv6 communications,
          it fails to meet this constraint that it "fully supports
          communications with all hosts - including all hosts in
          non-upgraded networks."  since, during adoption, most
          hosts in non-upgraded networks are IPv4 hosts.

  4 & 5   Most end-user networks which want multihoming do not, at
          present, have all their hosts and applications fully ready
          for IPv6.
If I'm interpreting correctly, it seems that you agree with my original surmise, i.e., that the idea of "incremental deployability" as originally specified is completely consistent with an absolute prerequisite of (what is likely by the earliest feasible moment of applicability to be) "ownership" of IPv4 addresses.
This may be less problematic, I suppose, if the intent is to scope the proposed recommendations as "institutional-level incremental deployability for current ( aka 'incumbent') routing system participants" -- and that scope is made explicit in the text.
However, I originally interpreted the text more broadly, c.f., as guidelines intended to facilitate "deployability" more generally, toward the presumptive, pragmatic goal of real-world deployment. It seems to me that the only domain of conceivable relevance to "deployability" as defined by RRG is a built environment that is, as a practical matter, composed wholly of deployed routing protocols that derive (and/or are deprived of) much if not all of their value by virtue of the presence/absence of extra-institutional "network effects." An additional, perhaps contingent but nevertheless inescapable feature of the real-world deployability environment is the absolute need for one specific kind of quantity constrained protocol number resource (unique IPv4), the availability of which will shortly become (at the very least) highly uncertain for anyone who does not already have it.
To my mind at least, this particular combination of environmental factors -- i.e., the centrality of specific, established network effects plus the de facto inaccessibility of those effects to any aspiring routing system participant that does not possess a specific, scarce, and potentially unobtainable legacy protocol-defined input -- imposes some hard constraints on any set of RRG "incremental deployability" recommendations. The network effects factor effectively makes the utility of any purely institution-level specification of "incremental deployability" highly dubious -- or alternately wholly contingent on the accommodation of those network effects at the individual institution (i.e., routing system participant) level. However, recognition of the real-world correlates of those network effects entails coming to terms with the inescapable quantitative/ demographic constraints that are inherent in IPv4.
My own short version: explicitly acknowledge possession IPv4 as an absolute prerequisite, and institutional-level deployability as the intended scope of the proposed incrementalism recommendations. Alternately, modify as necessary to explicitly accommodate incremental deployment paths that are not contingent on possession of IPv4. 



However, perhaps something needs to be added to the text to address
your concern about how the scope of text seems to be within the
current IPv4 situation, rather than looking beyond it.
That is indeed my principled concern, based on the last couple of years of work and research. 
More (just a little) on that below...



If I'm not
off-base in this observation, it would have two troubling implications. 
First, it suggests that this particular vision of incremental
deployability foregoes, if not excludes, one of the key drivers of
technology change in other sectors -- i.e., the possibility of early
adoption led by aspiring new entrants, in this case aspiring routing
services providers.


I understand you are referring to IPv6 being promoted by existing or
new ISPs who have a vision for IPv6 and promote its adoption.

IPv6 adoption remains glacial:

 http://bgp.potaroo.net/v6/v6rpt.html

       BGP advertised   Autonomous
       prefixes         Systems

 IPv4  219603           25296
 IPv6     855             741

I can't imagine the majority of current Internet users adopting it
any time soon.


Actually we are in full agreement on this point. My intuitions are
(1) that IPv6 will not be adopted by enough parties to become viable as a stand-alone extension to IPv4 for any entity that does not *also* possess IPv4, or exclusive beneficial use rights thereto. By implication, any set of prescriptions that defines "incremental deployability" without some consideration of the absolute finitude, and likely increasing non-availability of unique IPv4 address resources, will embed and thereby (potentially) perpetuate the requirement for IPv4.
(2) that the present effort to scope "incremental deployability" is at least partially motivated by the desire to reduce the odds that future RRG efforts will encounter deployability impediments similar in form and/or impact to those that have been revealed by the IPv6 experience.
The speculations below about how IPv6 might or might be deployed in the future are interesting, and might merit further discussion off- list, but are not relevant to the concerns I've expressed here. 


Perhaps in the future it will be adopted for fixed networks in
countries where IPv4 space is in too-short supply.  However, I think
that any such service would need IPv4 connectivity to be useful - so
IPv6 addresses for the hosts is not the whole story - the hosts still
need to tunnel to some IPv4 proxy server or whatever, so they can
function on the IPv4 Internet.

The most likely scenario I can imagine for large-scale adoption of
IPv6 is in mobile networks - 3G cellphone networks and whatever they
develop into.  AFAIK, this has not occurred to any substantial degree
yet.

I agree that the constraints as I wrote them seem to preclude
widespread adoption of IPv6, except perhaps in some future mobile
networks where direct connectivity to IPv4 hosts is for some reason
not required.  I think the text reflects the reality, however
unfortunate the reality is for the migration to IPv6.



Second, while the recommendations should, if
followed, increase the odds of the associated technology being widely
deployed, it would still leave the fate of the technology in question to 
be determined absolutely by "incumbent" routing system participants.


Since we (the RRG, the IETF etc.) have no coercive powers, I agree
that the fate of a particular network is absolutely determined by
those who are running and using the network.
While I think I understand your point here, it seems to me that this particular phrasing is orthogonal to any relationship between RRG and incremental deployability. Granted, the IETF has no coercive powers. Of course, the fate of anything/everything outside of the scope of candidate future routing protocols is beyond RRG's ambit. These undeniable facts would clearly support an assertion like:
"...the fate of a particular *network protocol* is absolutely determined by those who are using, or who would be able and willing to use that particular protocol."
However, extrapolating beyond that to the fate of "a particular network" would only make sense if that "particular network" is *not* the environment that imposes deployability criteria (i.e., not the Internet as it exists concurrently), or else if one as prepared to concede the above points (i.e., possession of IPv4 is assumed, and should be understood as an absolute prerequisite for anyone who hopes to use this "incremental deployability" formula to actually deploy something). 


I see our task as requiring the development of a new form of address
space, with all the supporting protocols and software for routers and
other network elements, which will solve the scaling problem if
widely deployed.  Then we need to make that system so attractive that
it will be widely adopted by most end-user networks which want
multihoming etc. - even though they may neither know or care about
the scalability problem, bloated DFZ route numbers etc.  We need to
show it works, that people can make money using it and generally
promote it.  However, only if it works really well will it be widely
enough adopted to solve the routing scalability problem.
I agree, but I think these claims only reinforce my point. Given our structural dependence on decentralized, privately incentivized action as the only vehicle for protocol deployment, your "so attractive" benchmark can only be understood in relative/comparative terms. Thus, regardless of the specific virtues of the hypothetical future network protocol candidate, the actual attractiveness hurdle for existing routing system participants will be defined by the private, individual operator-level benefits that the candidate protocol provides *over and above* the alternatives, including other candidate solutions that offer higher short-term private benefits (profits) and/or lower short- term direct costs -- as well as the ever-present option of just sticking with the status quo.
By contrast, the attractiveness hurdle for aspiring ("non-incumbent") routing system participants will be all of the above *plus* the cost of acquiring IPv4. In the near future, that could well imply that deployment of any kind, incremental or otherwise, will only be possible for entities that have achieved a favorable outcome in negotiations to purchase scarce, non-substitutable IPv4 space from a competitor -- i.e., from a routing services provider that knows that the sale will, by definition, enable the buyer to enter the routing services market and thus become a potential direct competitor. The history of competition in industries in which "bottleneck" (essential + non-substitutable) inputs play a central role suggests that that hurdle could be very, very high.
I don't think that RRG is responsible for the fact that IPv4 will soon impose these and other bottleneck effects on incremental deployability, or on the Internet more generally. However, I have reason to believe that it may be extremely difficult (i.e., approaching impossible) to define *any* routing protocol that might satisfy that attractiveness test for existing routing system participants -- and perhaps absolutely impossible to define an acceptable solution that does not *also* reproduce the same general demographic constraints that IPv4 will impose.
This is why I feel strongly that any RRG statement on "incremental deployability" should not explicitly or implicitly assume possession of IPv4 as a prerequisite. My own idiosyncratic experiences lead me to believe that the deployability of any/all future RRG outputs may absolutely dependent on the ability of non-incumbents to lead and drive the adoption dynamic (more on this below). I don't expect the official RRG "incremental deployability" guidelines to adopt this stance, but neither could I support guidelines which are not equally applicable to all potential adopters, regardless of their access to IPv4. 



In this specific sense, a future technology that satisfies all of the
requirements for "incremental deployability" might still end up getting effectively "vetoed," in the way that (some say) IPv6 has been vetoed. 

I am trying not to ascribe any particular meaning to "incremental
deployability".

I don't agree that IPv6 has been "vetoed".  It has been available for
10 years or more an almost no-one really wants it, for the simple
reasons that it doesn't provide connectivity to the great majority of
hosts and that for most people, it provides no benefit over IPv4.
In the real-world Internet where the provider-level value of a routing protocol is dictated by inter-provider network effects, an "abstain" vote by enough participants is equivalent to a system -wide veto. However, I didn't intend to use that term to imply anything more than what you stated in your response... 


Before I even attempt to suggest what kind of extensions or
modifications might serve to remedy this perceived "incumbent bias" I'd 
be very interested in hearing reactions from others...


I think the term "incumbent bias" implies an unreasonable resistance
to change.
The perception of "incumbent bias" does not arise if the enumerated "incremental deployability" recommendations are not in fact contingent on possession of IPv4. By implication, an official position of "remaining agnostic" on this question would be appropriate IFF the final "incremental deployability" recommendations would be *equally* relevant, applicable to, and adoptable by both IPv4 haves and have-nots. 


I don't think it is unreasonable that the great majority of Internet
users want and need a continuing service which enables them to
communicate with every other Internet host used by other similar people. 

The IPv4 Internet is by far the biggest and most significant IT
system which has ever existed.  In a free country, there would be no
demand for a service which failed to connect to even 1 or 2% of
hosts.  An IPv6-only service fails to connect to nearly 100% of hosts.

This is no fault of IPv6 - its just that no-one has figured out how
to remain IPv4 compatible while upgrading to another network.  It
could be done, in principle - but only by radically rewriting all
applications to use a new stack.  Even then, it would be a complex
and error-prone business trying to retain functionality running on
one or the other network exclusively, or using them both at the same
time.
Again, we're in full agreement on these particulars, but as above I don't think that our agreement on these points is germane to the question at hand. 



Here is a potential addition to the text, but I think this is taking
the scope of the piece beyond the constraints to adoption, and into
some additional goals we might have regarding the long-term
development of the Net:

               The above text attempts to summarise the real-world
               constraints on a scalable routing solution.  It
               appears that these constraints create a very high
               barrier to migration of significant numbers of
               existing end-user networks from IPv4 to an IPv6
               service, either with or without retaining their
               IPv4 address space.

               It follows that even if IPv6 had a scalable routing
               solution, that the barriers to mass adoption of it
               would remain so high as to preclude a mass migration
               from IPv4.

               Our goal is to solve the routing scaling problem
               in both the IPv4 and IPv6 Internets - and for the
               foreseeable future, the problem only manifests in
               the IPv4 Internet.

               Perhaps an additional goal of a scalable routing
               solution would be - by some methods yet to be
               determined - to facilitate adoption of an alternative
               to IPv4 such as IPv6 which is a more promising
               basis for accommodating very large numbers of
               individual hosts, many of which are expected to be
               mobile devices.

Maybe something like this could be a footnote.
I would go further than you and suggest that the proposed amendment has nothing at all to do with incremental deployment.
I would much prefer to see the text explicitly acknowledge the fact of an IPv4 prerequisite, and all that it implies for incremental deployability, and deployability more generally. That said, what I would *most* like to see is some reformulation that illuminates possible incremental deployability paths that do not proceed from an assumption of possession of IPv4. 

****
So... for those who've gotten this far, I actually have reasons for believing that this modification is critically important. My personal experience is a one factor -- I helped to build out and "peer up" what was briefly a "Tier One" ISP, with most of my hands-on experience accumulated in the course of building out in parts of the world where artificially imposed IP addressing constraints were a common tool used by locally dominant operators. But much more apropos is the tentative findings of an ongoing 5+ year research project (first began as my prospective doctoral dissertation), which suggests that the Internet is at root a new kind of "liquidity system," one that is limited in scope to packetize-able things and which builds on a largely static "attachment" mechanism rather than the more dynamic "payment" mechanism of that older and more familiar liquidity system (i.e., the global system of monetary instruments, financial flows, credit creation, etc.).
On this interpretation, the deployability of any future routing/ addressing protocol is likely to raise the same issues and impose the same challenges that many economies have experienced in the past when trying to integrate a new currency, or migrate from one currency to another. The existence of sovereign authority as a driver of currency migration makes some historical cases less relevant than others, but history reveals that even sovereign power cannot assure a successful liquidity system adaptation under some conditions. This shouldn't be altogether surprising, since the "circulating medium of exchange" (ala"money") was not originally invented so much as recognized post facto -- following its "emergence", usually in the form of some pretty-but-not-terribly-useful naturally occurring factor, as a widely acceptable, hence "fungible," temporary proxy for the thing(s) that aspiring buyers and sellers are actually trying to obtain. But to the main point, the most directly relevant historical cases are those in which sovereign power was not relevant, because the monetary liquidity system was not governed by a national treasury or central bank, but rather was largely self-coordinating through decentralized, limited, voluntary, private incentive-driven coordination mechanisms -- typically called "banker's clubs." Structurally and functionally, the monetary liquidity arrangements that characterized these so-called "free banking" periods bear an extremely strong resemblance to routing and addressing-related features of the TCP/IP-based Internet. And that's cause for serious concern. 

Anyone's who's still interested can find more details here:
http://tinyurl.com/IPliquidity

Tom

Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.