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
_______________________________________________
rrg mailing list
[email protected]
http://www.irtf.org/mailman/listinfo/rrg
