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

From: Robin Whittle <[email-masked]>
Date: Tue, 18 Mar 2008 13:27:03 +1100 (EST)

Here is a better attempt at the two different questions which I think
different people are asking regarding "incremental deployment".

Joel Halpern wrote (msg 833):

> One small aspect that I think I am seeing here is the same words 
> ("incrementally deployable") being used to describe two different 
> concepts. I may be confused, but it looks to me like:
>
> (1) Deployable incrementally without disruption: 
>
>       This means that a portion of the net (host, site ISP, 
>       whatever) can deploy the system without losing capability 
>       or connectivity. A flag day is not necessary in order to 
>       get the system operational.
>
> (2) Deployment incremental incentives: 
>
>       This sounds like what Robin is asking for, and is related 
>       to a bunch of work I have seen from folks like Dr. Odlyzko 
>       on the economic incentives that are needed to drive deployment.
>       It includes analysis of issues like when do folks need 
>       positive return on new technologies to cause them to deploy.
>
> They are both valid concerns. But I think they are two different 
> dimensions.

OK.  (1) means there is presumably some net positive incentive, without
requiring everyone else to adopt the system.  However, this doesn't
distinguish what I am looking for.

(2) mentions some of what I am seeking, but is not a complete statement.

I think the question Tony is asking regarding "incremental deployment":

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

is something like:

  (3)  Can the technology be introduced one host at a time, one
       network at at time etc. without disrupting other networks
       - and produce some benefits for those who adopt it?

This rules out any technology which requires total (or at least very
widespread) adoption before it becomes useful to anyone.  (I think the
term "flag day" relates to somehow forcing or inducing everyone to
adopt the technology all at once, because that is the only way it could
produce any net benefits.)

Here are two roughly equivalent questions I ask:

  (4)  Could the technology achieve widespread adoption without some
       kind of "jump start", in which a large proportion (or all)
       of the hosts, networks etc. were somehow made to adopt it?

  (5)  Is the technology likely to be widely or completely adopted
       purely due to the immediate benefits adoptors receive?  
       (That is no external inducements, forcible deployment etc.
       and assuming the technology has the potential to be useful
       to everyone.)

This leads to further questions, which get down to the guts of things:

  (6)  Do the benefits to each early adoptor depend on the proportion
       of other users who have adopted it?

If the answer to this is "yes" then I would say the technology is not
"incrementally deployable".  For instance, IPv6 and LISP without Proxy
Tunnel Routers (PTRs).

The question which distinguishes my notion of "incrementally deployable" is:

  (7)  Does the technology provide full, or at least highly substantial
       benefits to early adoptors, irrespective of how many other 
       people (hosts, networks etc.) adopt it?

If the answer is "yes", then I would say the technology is incrementally
adoptable, and the answers for this technologies to the other questions
are (4) Yes, (5) Yes and (6) No.

For instance Ivip or LISP with PTRs.

Question (3) doesn't ask what I am asking with (4), (5) or (6).

I think the two most distilled forms of questions which represent
Tony's view and mine are something like:

  (8)  Can the technology be deployed incrementally (not all at once,
       starting with one user, two, 1000, 2000 etc.), generating at
       least some positive benefit for those who make the effort and
       pay the expense of adoption?  

This means that the technology doesn't need to be ubiquitously adopted
to provide at least some benefit, and that any disruption it causes is
less than whatever benefit it provides.

My guess is that (8) is what Tony is asking.

My use of the term "incrementally deployable" is actually shorthand for
something more involved:

  (9)  Is the technology fully or widely deployable in a purely 
       incremental fashion?  

For this to be true, the answer to (6) would have to be "yes".

  - Robin

--
to unsubscribe send a message to [email-masked] 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

---

From: Robin Whittle <[email-masked]>
Date: Wed, 19 Mar 2008 04:02:15 +1100

Oops, I fluffed the last line in:

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

> My use of the term "incrementally deployable" is actually
> shorthand for something more involved:
>

Should be:

  For this to be true, the answer to (6) would have to be "no":

>   (6)  Do the benefits to each early adoptor depend on the
>        proportion of other users who have adopted it?
>
> If the answer to this is "yes" then I would say the technology
> is not "incrementally deployable".  For instance, IPv6 and LISP
> without Proxy Tunnel Routers (PTRs).

 - Robin

---

From: <[email-masked]>
Date: Thu, 20 Mar 2008 15:46:53 -0000

I think a useful way of posing the question is something like:

What's the minimum deployment where the benefit for the party deploying
is greater than the party's cost/pain?

I think this form of the question is useful, because it encourages some
rough guesses. For instance: proxy ITRs in the core have some cost, how
much is this & therefore how widely would ivip/lisp/etc have to be
deployed before the net benefit was positive? Just some guesses within
an order of magnitude or two would be interesting. 

(Robin, this is similar to your question 8, but recognises that it may
be OK for the first deployers to get a net dis-benefit, eg they might be
subsidised. It's also less restrictive than your Qu 6, recognising that
the benefit may increase as more users adopt it, but this may be ok if
the benefit becomes positive before the deployment is too big.)

phil

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Robin
> Whittle
> Sent: 18 March 2008 02:27
> To: 'Routing Research Group'
> Cc: Xu Xiaohu
> Subject: Re: [RRG] What does incremental deployment mean - 2 questions
> 
> The question which distinguishes my notion of "incrementally
deployable"
> is:

---

From: Robin Whittle <[email-masked]>
Date: Fri, 21 Mar 2008 13:54:53 +1100

Hi Philip,

> is greater than the party's cost/pain?

The answer is quantitative, so it doesn't work as a definition of
"incrementally deployable" on its own, unless you define some
threshold to turn the quantity into a "Yes" or a "No".

I would say that if the answer to your question is zero - no-one
else has deployed it - *and* the benefit was not just positive, but
initially substantial and generally unrelated to how many other
people deploy it - then the system would be "incrementally
deployable" by my definition.

I look forward to Tony's response and to other people writing about
their understanding of "incrementally deployable".

I realise that my interpretation of these two words is actually
quite complex - while I wrongly assumed everyone else understood it
the same way I did.

Still, I think my definition:

   For this to be true, the answer to

   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.

  - Robin

---

From: "Tony Li" <[email-masked]>
Date: Thu, 20 Mar 2008 20:36:24 -0700

|I look forward to Tony's response and to other people writing about
|their understanding of "incrementally deployable".

I liked Joel Halpern's characterization.  I thought he said it all.

Tony

---

From: Robin Whittle <[email-masked]>
Date: Fri, 21 Mar 2008 15:18:30 +1100

> I liked Joel Halpern's characterization.  I thought he said it all.

OK, in "Re: [RRG] Mobility, update rates & charging per update"
2008-03-17:

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

Joel wrote:

   One small aspect that I think I am seeing here is the same
   words ("incrementally deployable") being used to describe two
   different concepts.  I may be confused, but it looks to me like:

(1)  Deployable incrementally without disruption:  This means that
     a portion of the net (host, site ISP, whatever) can deploy the
     system without losing capability or connectivity.  A flag day
     is not necessary in order to get the system operational.

(2)  Deployment incremental incentives:  This sounds like what Robin
     is asking for, and is related to a bunch of work I have seen
     from folks like Dr. Odlyzko on the economic incentives that are
     needed to drive deployment.    It includes analysis of issues
     like when do folks need positive return on new technologies to
     cause them to deploy.

and you initially wrote, in "RE: [RRG] Hosts, DFZ, purity &
incremental deployment" (2008-03-17):

   I would consider anything that could be rolled out one host at
   a time without breaking anything as being the maximal amount
   of incremental deployability.

This initial statement of yours seems to be compatible with Joel's
(1), but not to mention the more restrictive criteria in (2), which
is much closer to the way I use the term "incrementally deployable".

So I am unclear to what extent you embrace Joel's (2), and I am not
sure to what extent you embrace my even more restrictive, and I
think useful, definition in:

with the last word "yes" changed to a "no".

I think we need an agreed understanding of "incrementally
deployable" since it is one of the requirements in the RRG Design Goals:

  http://tools.ietf.org/html/draft-irtf-rrg-design-goals-01

 - Robin

---

From: Randall Atkinson <[email-masked]>
Date: Fri, 21 Mar 2008 03:33:35 -0700

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.

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

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.

Ran
[email-masked]

---

From: Randall Atkinson <[email-masked]>
Date: Fri, 21 Mar 2008 03:52:17 -0700

Robin,

  I think there are 2 separate questions.  I agree with Joel's first proposition.
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.

  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.

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

Ran

---

From: Robin Whittle <[email-masked]>
Date: Sat, 22 Mar 2008 10:23:21 +1100

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:

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

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

> systems.  In short, the two key properties of incrementally
> deployable are that
>

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.

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

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

---

From: Randall Atkinson <[email-masked]>
Date: Sat, 22 Mar 2008 04:24:19 -0700

Robin,

  As near as I can tell, everyone else already converged on a working
definition for "incrementally deployable" -- and that definition is not
consistent with your personal definition.  Further, I haven't seen any
recent support for your broader definition from others, though perhaps
I've misplaced a note someplace.

  I will also note that conversations in the hallway in Philadelphia
lead me to believe that many (possibly most) RG members do believe
that several proposals on the table (including LISP, but not limited
to LISP) are incrementally deployable.

Ran

---

From: "ext Robin Whittle" <[email-masked]>
Date: Sat, 22 Mar 2008 10:23:21 +1100

Hi Randall,

   3.10. Deployability

is what could be called

or: