On Apr 19, 2009, at 11:26 AM, Robin Whittle wrote:
Short version: Long reply to Tom Vest, discussing his concerns
about IPv4, even with a scalable routing solution,
hitting the limits of its address range and so
causing difficulties for aspiring new ISPs.
The same issues are covered more concisely in the
footnote to the draft list of constraints.
Also, some discussion of the TTR Mobility approach
in the hope that people will read it and so not be
so alarmed at the mention of mobility with scalable
routing. I first described this in June 2007 and
this full description, with diagrams, has been
available for 8 months:
http://www.firstpr.com.au/ip/ivip/TTR-Mobility.pdf
Hi Tom,
The list of constraints due to the need for voluntary adoption is at:
http://www.firstpr.com.au/ip/ivip/RRG-2009/constraints/
I have added a second last paragraph which mentions some of your
concerns. As I discuss here and in the Footnote at the above page, I
think your concerns are important but that there is no need to change
the list itself. I intend it to be a factual list of constraints we
can all agree to - even if some of them seem to be at odds with a
truly satisfactory outcome in terms of endless address space and the
avoidance of barriers to new entrants.
Here is a reply to your message in the "Constraints on a solution
..." thread. Thanks again for your thoughtful discussion and
constructive suggestions. You wrote:
Constraints imposed by the need for voluntary adoption *
A successful solution to the routing and addressing
scaling problem is tightly constrained by the need
for it to be voluntarily adopted, over a period of *
years, by the great majority of end-user networks *
of all sizes who want or need multihoming, inbound
traffic engineering and/or portability of their
address space between ISPs.
Thanks once again Robin.
My concerns would be fully covered if the above language were changed
slightly...
A successful solution to the routing and addressing
scaling problem is tightly constrained by the need
for it to be both accessible to, and voluntarily adopted by
the great majority of established and aspiring end-user
networks who want or need multihoming, inbound
traffic engineering and/or portability of their address
space between ISPs. Because this voluntary adoption may
occur over a period of years, the benefits of the solution
itself should be broadly accessible to all end-user networks,
regardless of their size or legacy (pre-solution) protocol
endowments.
I have amended the text to:
be both accessible to, and voluntarily adopted by
and I hope you will find that the new second-last paragraph at least
partially mentions your concerns.
The benefits resulting from the best imaginable
solution for IPv4 may be limited by shortage of IPv4
space and resulting difficulties for new networks in
gaining this space. While no such restrictions exist
with IPv6, constraints similar to 2, 3, 4 and 5 are
likely to continue to be a barrier to widespread
migration to IPv6.
Hi Robin,
Thanks for taking (what must have been considerable) time to reply in
detail.
The above two modifications do, indeed, adequately reflect the
concerns I expressed.
I want the list of constraints to be a terse description of things we
all (ideally) agree are true. The focus is on what is needed for
end-user networks and their ISPs to adopt the solution.
As a statement of fact, this text does not assume that there is a
solution which will meet all these constraints. I think there will
be solutions which meet them all in IPv4 - but I agree that during '
adoption and in the decades to come, no matter how ubiquitously the
scalable routing solution is adopted and how well it works, the
address space shortage is likely to limit the IPv4 Internet's
capacity to provide multihoming etc. for all end-user networks which
want it.
Of course I agree on this point, but this particular goal was never
explicitly stated, nor implied, nor even contemplated by me.
The idea that merely "wanting it" -- i.e., full access to all of the
'rights, privileges, and responsibilities' that are enjoyed by direct
participants in the Internet's routing subsystem -- is or should be by
itself sufficient for any institution to lay claim to a share of that
system's finite carrying capacity -- fundamentally contradicts the
findings of my own personal experience and research (maybe common
sense too, if I presumed to know what that was).
More precisely stated, the implications of my recent work suggests
that the very nature of the constraints that dictate the requirement
for "incremental deployability" are *the same* structural constraints
that absolutely dictate that any/every conceivable current and future
routing system that could ever be adopted and deployed in this manner
will -- inevitably, necessarily -- embody some set of features that
ultimately make all such systems vulnerable to some version of *the
same* systemic risks to which the current system is vulnerable, namely:
-- "inflation" (c.f., generalized/cumulative/direct impact of
individual demands on routing system carrying capacity that are borne
by all/other participants in that routing system)
-- "deflation" (c.f., generalized/cumulative impact of non-
availability of routing system capacity and/or address resources,
which manifests as diminished growth potential for existing
participants and a progressive barrier to the emergence of potential
new participants)
-- "stagnation" (c.f., generalized/cumulative impact of non-
availability of "standard"/"DFZ" routing system capacity and/or
"standard"/uniform address resources, which manifests as a progressive
degradation of and loss of confidence in the consistency/
predictability of precisely those "network effects" that make a
shared, inter-domain routing system so valuable to its direct
participants, as well as to indirect stakeholders).
Another way of putting this is that the specific problems that RRG is
trying to solve are actually just specific manifestations of more
general risks -- risks that are *not* primarily or exclusively an
artifact of current routing and addressing technology. Rather, these
risks are a natural, organic, and (probably) largely unavoidable
feature of *all* liquidity mechanisms -- i.e., all "technically
mediated exchange systems." They are unavoidable because a necessary
condition of possibility for the existence/emergence of such mediated
exchange systems is the prior existence of a population of diverse,
independent, often competing economic agents (individuals,
institutions, etc.), members of which might often enjoy opportunities
to productively interact with one another, but for the existence of
various "transactional frictions" (foregoing details on this for now).
"Liquidity system" and/or "technical medium of exchange" are the
interchangeable terms that I've adopted [1] to describe the thing that
emerges in some (not all) situations, which is functionally
distinguished by its capacity to reduce if not eliminate those
frictions for all participants who voluntarily adopt it -- thereby
becoming participating members in that particular liquidity system.
The intrinsic friction-reducing benefits of participation (growth,
profit, etc.) attracts and retains participants within that system,
which creates/strengthens incentives for system participants to
interact with each other ever more intensively (producing as a result
the devision of labor, specialization, etc.). However, those same
benefits also have the organic effect of intensifying competition
between system participants, which eventually results in their
becoming aware of the liquidity mechanism itself, and its possible
uses as a strategic, (anti)competitive tool.
I'll spare the list the rest of the evolving story. Those interested
can find more of it is on my personal website (links below).
In any event, I wholeheartedly share RRG's ambition to contribute to
the alleviation these problems. The story above explains why systems
like ours need liquidity mechanisms, and what benefits they confer --
and risks they impose -- on those systems that are lucky enough to
have one. However, that "need" does not entail that it will be
fulfilled. Obviously, another absolute condition of possibility is the
existence of some candidate mechanism(s) that is capable of initiating
and sustaining this liquidity process over time. Not all candidate
liquidity mechanisms are created equal, and I think of RRG's core
mandate as the definition of the "best possible" successor liquidity
mechanism for the Internet that we have inherited -- with "best
possible" defined as (max. [probability of adoption * probability of
sustainability, given known structural and exogenous risks]). That
said, I do not believe that the problems that RRG is trying to solve
are amenable to any complete or final "solution" -- nor even to much
symptomatic relief unless the root cause(s) of the problems are
recognized and addressed directly.
And that brings me back to the point of departure, Robin, which was
the contrast between "desire" or (self-asserted) "need" vs.
*eligibility*. It seems to me that the formula that made it possible
for the last RRG-relevant domain-wide solution (CIDR) to "work" --
i.e., to be both (1) accepted by, at least, the minimum set of parties
required to get started, and (2) to continue to be regarded as
tolerable/acceptable by the majority of direct, indirect, and aspiring
stakeholders thereafter -- involved three key ingredients:
1. The idea that there is a (i.e., at least one) technically
justifiable/defensible set of criteria that can be used to determine
an institution's "eligibility" to consume some share of the common/
default routing system's finite carrying capacity. To maximize
sustainability over time, these criteria should establish a link
between individual-level demand for participation and the potential
system-wide benefits of allocating a share of finite system carrying
capacity to the aspiring participant.
2. To further maximize sustainability over time, eligibility criteria
should be responsive to changing conditions, e.g., an expansion of the
system's finite carrying capacity should be reflected in the
corresponding eligibility criteria. That makes eligibility criteria
management dependent on the active participation of those who are
closest to the implementation technologies and practices.
3. These eligibility criteria should, in both principle and practice,
form the primary basis for allocating finite routing system carrying
capacity. Achieving this in a sustainable way is only possible if the
eligibility criteria are administered, and the associated resources
distributed, through some neutral, transparent mechanism that is
substantially insulated from the competitive dynamics that govern most
direct interactions between existing liquidity system participants. In
other words, the allocation mechanism must be insulated from the very
dynamics that make the liquidity system itself so valuable, and which
make the potential risks and consequences of liquidity system capture,
collapse, or premature obsolescence so severe.
So, to your point about not being able to "provide multihoming etc.
for all end-user networks which want it," I respond that that is not a
realistic goal, given the joint constraints of technology and human
nature. I seriously doubt that it ever will be, because in an
uncertain world full of real and/or potential competitors, people will
always "want" more than they currently "need," and nothing short of
infinite carrying capacity or a change in human nature can remedy
that. However, I believe with even greater seriousness that we must
aspire to preserve -- or barring that possibility to recreate with the
shortest humanly possible interruption -- those three conditions, and
the kind of "eligibility-based" system admission process that results
when those conditions are in place.
I believe this strongly because the history of liquidity systems past
suggests that if those conditions are not sustained or restored in
(effectively no) time, whatever endures may not be redeemable, or
worth redeeming for that matter, and in any event system maintenance
by then is then likely to have become someone else's problem. Just as
the "need" for a liquidity mechanism like TCP/IP does not guarantee
that one will emerge and be widely adopted, neither does that need
guarantee that an existing mechanism will endure, or in enduring
superficially ("in form only") continue to provide those substantive
benefits that make liquidity systems so valuable, and so vanishingly
rare in the wild.
Monetary liquidity systems have come and gone in the past -- but the
ones that have both "gone" and subsequently "come back" have almost
universally been backed by sovereign power -- and 100% of those were/
are exclusively national in scope. What that portends for the future
of our own, first-of-its kind, extra-territorial, attachment-based
liquidity mechanism is left as a exercise for the reader.
Note: To prevent the weight of this message from giving the Internet a
hernia, I've split out comments on the footnote next in a separate
message, to follow shortly.
Thanks again for your responsiveness...
TV
[1] The terms come a newish subfield of academic/operational
macroeconomic research that focuses on topics like the origin of
"money" and the sustainable management of monetary systems, most of
whose leading contributors seem to be current or former commercial
banking professionals or central bank/monetary policy decision makers.
Definition and comparison of "technical media of exchange" aka
"liquidity mechanisms":
http://www.eyeconomics.com/eyecononomics.com/MoEDdefined.html
Expected consequences of the looming transition in Internet "liquidity
mechanisms":
http://www.eyeconomics.com/eyecononomics.com/NetStagflationPaper.html
_______________________________________________
rrg mailing list
[email protected]
http://www.irtf.org/mailman/listinfo/rrg
