Re: [RRG] What does incremental deployment mean - 2 questions

[Robin Whittle <rw@firstpr.com.au>]

Short version:      We either need to rewrite the "incrementally
                    deployable" part of the RRG Design Goals in
                    much more explicit detail or reach consensus on
                    exactly what this term means in this document.

                    I propose a fuller definition of what I think
                    the RRG criteria should be, and contrast that
                    with a more broad ranging "Economic Incentives"
                    criteria from Randall which involves assessing
                    the full future commercial and regulatory
                    environment, in addition to the technology
                    itself.



Hi Randall,

Thanks for all you wrote in your two messages:

> Earlier, Robin Whittle wrote:
> % Still, I think my definition:
> %
> %   (9)  Is the technology fully or widely deployable in a purely
> %        incremental fashion?
> %
> %   For this to be true, the answer to
> %
> %   (6)  Do the benefits to each early adoptor depend on the
> %        proportion of other users who have adopted it?
> %
> %   would have to be "no" (or perhaps "not to a strong degree").
> %
> % is a much more stringent and useful for the RRG than the
> % definition % which I think Tony used.
>
> I disagree with all of the quoted text above, including the claim
> of greater utility for the unusual definition above.

OK - (9) above is a short version of a fuller meaning I had ascribed
to "incrementally deployable", without realising that it is quite
different from how a lot of other people understand the term.

I won't try to convince people they should change their use of this
term, but I am adamant we need to either rewrite the Design Goals to
replace "incrementally deployable" with a much more explicit and
useful definition - or reach consensus on exactly what
"incrementally deployable" means for us.

   3.10. Deployability

   Since solutions that are not deployable are simply academic
   exercises, solutions are required to be deployable from a
   technical perspective.  Furthermore, given the extensive
   deployed base of today's Internet, a solution is required
   to be incrementally deployable.


Clearly, the meaning I was using needs to have another name.

A fuller form of (9), from:

  http://psg.com/lists/rrg/2008/msg00846.html

is what could be called

   "No significant barriers to widespread deployment due to
    initially low uptake rate, or disruption of existing practices"

or:

   "The zero (or relatively low) critical mass criteria for
    ubiquitous deployment on an incremental basis without
    outside inducements"


  (10) The technology must be able to be introduced without
       disrupting existing practices.  After some low
       specified level of initial deployment, ideally zero,
       everyone (or at least most people) who deploys the
       technology receives benefits (maybe net benefits in
       some short enough time-frame after accounting for
       one-off purchase and installation costs) which are
       not only positive, but substantial and likely to
       attract many other end-users to the technology.
       For this to be true, the benefits received must not
       depend much or at all on what proportion of other
       users have adopted the technology.  Therefore, if the
       technology would be fundamentally attractive to many,
       most or all end-users once deployed by most or all
       end-users, it would also be attractive enough to the
       very first (or after some low, specified, level of
       adoption) to actually become widely deployed via a purely
       incremental means, without inducements or a major up-front
       deployment before any end-users gain significant benefits.

This is what I always thought everyone meant by "incrementally
deployable".  Sorry the above reads like a piece of legislation.

I think this criteria is extremely well suited to our problem of
finding an architecture which will naturally be widely adopted -
since we can't pay, force or cajole anyone into adopting it.

I think the RRG really needs to define an architecture which looks
like it would meets this criteria.  If we can't do this, then we
also need to consider what inducements, up-front outside investment
to get things going etc. would be required for the architecture to
be widely enough adopted to substantially solve the routing scaling
problem.


> Among other things, that definition is significantly different
> from the IETF community's common-use meaning for "incrementally
> deployable".  The common meaning is that "incrementally
> deployable" is the inverse of "flag day transition required".

OK - I accept that there is a wide range of views about what
"incrementally deployable" means, and that for many or most people
it means something less stringent than my (9) or (10).


> I think Brian Carpenter captured the essence of the common meaning
> for "incrementally deployable" when he talked about the ability of
> an upgraded system to continue to communicate with non-upgraded
> systems.  In short, the two key properties of incrementally
> deployable are that
>
> (A) Upgraded systems can use some mechanism to still communicate
>     with non-upgraded systems (and non-upgraded systems can still
>     communicate with upgraded systems using the older
>     mechanisms).
>
> (B) No Flag Day transition is required.

OK.  I think this is a very useful definition.  However, it is not
as exacting as my (9) or (10) and I think it is not as useful for
the RRG.

For instance, LISP without PTRs satisfies (A) and (B), but most
people on the list, as far as I know, regarded pre-PTR LISP as not
"incrementally deployable".

Here is how pre-PTR LISP satisfies the above:

   Networks A and B convert to LISP, and hosts in A or B could still
   initiate sessions and communicate normally with hosts in networks
   C and D which have no LISP ITRs etc.  (A|B) --> (C|D)

   When a host in C or D initiates a session with a host in A or B,
   the communication works fine, but the hosts in A and B and the
   networks A and B themselves gain no benefits from pre-PTR LISP.
   In order for this (A|B) <- (C|D) reachability to work, A and B
   somehow need to maintain existing address and routing
   arrangements.  To do this while also using the LISP arrangements
   could be tricky or impossible, but is likely at least to be
   unwieldy.

   When a host in either A or B communicates with a host in either
   B or A respectively, the end-users and/or networks at both ends
   gain the full benefits of LISP.

So, while pre-PTR LISP meets the (A)-(B) criteria above, it is still
a long way from meeting my (9) or (10) criteria, which I maintain is
the bare minimum we need for the new routing and addressing
architecture.

The two problems with pre-PTR LISP are:

1 - Having to maintain old arrangements with the new to maintain
    reachability from non-upgraded networks.

2 - Assuming reasonably random patterns of communication, the fact
    that the net benefits received are in direct proportion to the
    proportion of other networks which have upgraded to LISP.

Point 1 could be prohibitively costly or unwieldy.  Assuming it was
not, point 2 is the real killer - initial adoptors gain very few
benefits.  If 0.1% of networks adopt it, it helps them with 0.1% of
their traffic.

Since a primary purpose of LISP or any other solution the RRG could
recommend is to provide robust multihoming, and since multihoming
would not work for hosts in A or B for any communication (no matter
which end initiated it) with with hosts in C or D, robust
multihoming can only be achieved once 100% of networks adopt pre-PTR
LISP.

Adding PTRs to LISP solves this problem.  (I don't think LISP-NAT
does the job at all.)


Ivip - or LISP with PTRs (assuming LISP would work nicely, which I
don't think it will) - satisfies your criteria above but also
satisfies (9) and (10):

   Networks A and B convert to Ivip - meaning that there are ITRs
   and ETRs in this network.  As part of this, end-users of these
   networks use micronets in MABs from one or more RUASes, and
   each such RUAS runs a sufficiently large set of "Open ITRs in the
   DFZ" to handle packets from non-upgraded networks, tunnelling them
   with optimal or generally highly optimal paths to wherever the
   ETRs are for any end-user with Ivip-mapped address space.

   Hosts in end-user networks which use ETRs in A and B can
   communicate with any host in A, B, C or D or in Ivip-mapped
   end-user networks in A or B, with communications being initiated
   by either host, and the first-mentioned hosts, and their end-user
   networks will gain the full benefits of Ivip: multihoming and
   portability. (TE is not explicit - but real-time control of
   mapping of individual micronets down to single IP addresses
   should be a good tool for incoming traffic load sharing, provided
   the traffic can be split over a few IP addresses.)

The two problems 1 and 2 above do not apply at all.

So the very first end-user gains the full benefits of the scheme -
and so does the second.  It would be grand if 99% of end-users
adopted the scheme, but that wouldn't improve the benefits to any
one end-user.  In short, the full benefits are available to even the
earliest adoptors - and there is no awkward requirement to
simultaneously maintain an older approach to retain compatibility
with non-upgraded networks.


> I think there are 2 separate questions.  I agree with Joel's first proposition.

   http://psg.com/lists/rrg/2008/msg00833.html

> I'd simplify greatly Joel's second proposition.
> 
> The first proposition is the commonly used existing meaning for "incrementally
> deployable".  This is purely technical and refers to the ability of upgraded
> and non-upgraded systems/routers/hosts to communicate among themselves.

I will call this your "Economic Incentives Criteria":

> The second proposition is in fact hard to measure or quantify, but is
> really a question of whether there are sufficient economic incentives
> for a new approach to become widely deployed over time.  This last
> ought to be kept separate from the technical question in the first proposition.
> So I'd suggest we refer to this as "having sufficient economic incentives
> to be widely deployed".  Someone else can devise a clear (and different
> from 'incrementally deployable') short name, if desired.

I think this is an important question, with a much broader scope
than my (9) or (10).

To evaluate a technology according to your criteria, it would be
necessary to look not just at the technology, but at every aspect of
the future commercial environment.  This is beyond our expertise and
impossible for anyone since crystal balls are unreliable.

For instance, if all major OS vendors agreed to add the technology
for free, and this lead to the technology achieving a high enough
mass for it to become "critical", then the technology in this
setting would meet your criteria.

I am thinking of runaway reactions in atomic fission, where there is
a sufficiently large mass of fissile fuel, such as plutonium, given
all its physical characteristics, which means that for every fission
reaction, more than 1.000 of the two neutrons released in each
reaction hits a suitable nucleus in the fissile material to generate
another fission reaction.

Any technology which meets my (9) or (10) has a zero critical mass -
a zero base of adoption above which end-users will increasingly
adopt the system purely based on their own gains, and without any
outside inducement.  Alternatively, (10) might include some
specified, but relatively low, level of adoption above which this
occurs.

You could easily have a technology with a moderately high or very
high critical deployment level according to (10) (and therefore not
meeting the criteria, since it needs to be zero or relatively low)
which would not meet your Economic Incentives Criteria in one
commercial or regulatory environment but which would meet it in some
other environment.

If, in a coordinated act of mercy - euthanasia for a terminally ill
technology - regulators and legislators all over the world
prohibited the transmission of IPv4 packets within their countries,
- IPv6 would suddenly meet your criteria and be ubiquitously adopted
within a year!  (Still, isolated pockets of IPv4 hosts would
communicate via secret IPv6 tunnels . . .)


>   Note that the second questions answers will likely vary based upon the
> class of architecture chosen.  To give a simple example, for an approach
> relying on router upgrades, any major router vendor might be in a position
> to greatly reduce the economic incentive to upgrade by simply not offering
> upgraded routers in a timely manner.  Similarly, for an approach relying
> upon host upgrades, any major proprietary OS vendor might be in a
> position to have the same drag on the economics.
> 
> (Open source system upgrades can be offered by 3rd parties; there is
> no major router vendor with open source, whilst Linux and BSD are
> both major host OSs and open source.)

I think the RRG's criteria needs to closely resemble my (10).
Anything less stringent would allow us to create an architecture
which will not be sufficiently attractive to early adoptors to ever
achieve substantial rates of adoption.

We can't evaluate a technology in terms of the Economic Incentives
Criteria you suggest, because that depends very largely on the
intentions and future actions of regulators, large commercial
operators etc.

If the new routing and addressing architecture satisfies (10) with a
zero critical deployment level, then if the architecture is any good
at all, it will be a hit and will gain widespread adoption - without
any intervention by regulators or companies with lots of resources.

If we can't create an architecture which satisfies something like
(10) then I think we need to say so, and indicate what sort of
regulatory or pump-priming commercial support would be required to
get the system widely enough adopted that its "critical mass" would
be reached - and so it would then be naturally widely adopted by
many more end-users without further inducements.

I think Ivip meets (or will meet, once properly developed) my (10)
criteria, with a zero critical mass of initial adoption before each
early adoptor gets the full benefits.

I think money could be made implementing one or more Ivip-like
systems without waiting for IETF standardisation - especially for
mobility.  However, it would be best if the IETF standardised
something like Ivip, so a single global system develops rapidly
after that, rather than a mess of proprietary systems.

 - Robin              http://www.firstpr.com.au/ip/ivip/



--
to unsubscribe send a message to rrg-request@psg.com with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg