Subject: [RRG] Consensus? Users will not adopt solutions which result in "split-system" functionality

From: Robin Whittle <[email-masked]>
Date: Sun, 25 May 2008 19:30:13 +1000

I am perplexed by several things at this late stage in the RRG
discussion - 19 months after RAWS, 10 months before our deadline,
and after four or five map-encap proposals (LISP-NERD, LISP-ALT,
APT, Ivip and TRRP) have been described in sufficient detail for
there to be robust critiques made of their practicality.

1 - We have achieved consensus on very little:

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

2 - We are now being asked to decide whether or not certain
    parts of the design space might contain the preferred
    solution, such as Six/One Router as in the "Translation"
    part of the space, as opposed to LISP etc. in the
    map-encap part.  Yet we are being discouraged from discussing
    actual proposals:  http://psg.com/lists/rrg/2008/msg01285.html

3 - I think the five map-encap proposals were all predicated on the
    assumptions (which is reasonable to me, and presumably to
    the other developers) that host changes are not practical
    and that we must solve the IPv4 routing scaling problem
    directly - but now I find that these two assumptions are
    not agreed to by some folks, and they are not part of
    what we have "consensus" on.

So I feel the need to backtrack even further and suggest we achieve
consensus (actually, "rough consensus" I think) on some more
fundamental things before we can make decisions about which sectors
of the design space might contain the solution the RRG should recommend.

The first of these proposals is in this email.  Other messages deal
with other things which I thought we agreed on, and which I think we
must agree on, if we are to make much further progress towards
achieving consensus on where the best solution might lie.

First of all, I want to state some things I think we all agree on -
a series of limitations on "our" ability to encourage or force
anyone to adopt a solution to the routing scaling problem:

  1 - The IETF has little persuasive influence on the actions of
      of the end-user networks, ISPs etc. who must implement any
      technical solution to the routing scaling problem.

  2 - Likewise, the RIRs.  Likewise the RRG.  None of us have
      anything more than the ability to present some arguments and
      make a case to other parties - although the IETF can develop
      some protocols etc. and the RIRs could work together to
      administer address space to help facilitate adoption of
      the new technologies.

  3 - Since any solution which is widely enough deployed to solve
      the routing scaling problem must be deployed by end-users etc.
      acting in their own short to medium term interests, we need to
      devise a solution which will be enthusiastically adopted by
      many and later most end-users, ISPs etc.  In order for this
      to occur, they must gain genuine, direct, benefits over and
      above their costs, risks and disruption etc.  The fact that
      they would be reducing (or not expanding) the DFZ routing
      table is not such a benefit.

      (However, to the extent that end-users are able to use a new
      form of address space which does not contribute to the routing
      scaling problem, it is possible that ISPs, RIRs etc. may be
      able to supply this space at a lower cost than is currently
      possible.)

Based on the above, which I think we all agree on, here is the point
of this message:  Can we form consensus on the following?

Short version:

   ISPs, end-user networks and end-users will not adopt solutions
   which result in "split-system" functionality - at least not
   to the very high levels of adoption we need in order to solve
   the routing scaling problem.

   So any solution to the routing scaling problem must provide
   clear benefits to all of the network when it is adopted - not
   some complex to administer patchwork of benefit and no benefit.

Long version:

   In order for our solution to be attractive, it must result in
   immediate benefits.  This includes the requirement that the
   benefits be system-wide, clear and unambiguous - resulting in
   minimal extra complexity, and in significant immediate benefits
   which are measurable in ways which lead to greater reliability,
   better performance etc. - all "bankable" aspects of system
   performance.  (That is, direct, useful, benefits to those who
   adopt the new technology.)

   This would be impossible if the solution only provided a
   half-baked set of benefits.  For instance, if either or both
   of the points below were true, the new technology would
   introduce such complexities that it would never be widely
   adopted by most end-user networks, ISPs etc. acting in their
   own immediate interest:

   1 - The solution can only be applied to a subset of their
       network.  For instance, but not limited to:

           The solution involves host OS changes, but it is
           impossible, impractical or too costly to upgrade
           all hosts in this way.

           The solution involves changes to applications -
           and it will never be possible to upgrade all
           applications, because some are no longer maintained.

       Therefore, in adopting the solution, the end-user network
       ISP etc. would find their network to be only partially
       benefiting, and would be burdened with the added complexity
       of having to remember which parts of their system work with
       the new solution and which don't.

       For instance, if robust multihoming, portability of
       address space, TE etc. only works for some of their
       hosts, some parts of their network, some of their
       applications and not others, then this will be such an
       additional burden of complexity that far too few
       end-users etc. would actually adopt the solution in
       order for the solution to make a sufficiently big impact
       on the routing scalability problem.

   2 - Even if an entire network could be upgraded completely
       (including reliable, easy, secure, upgrades to all hosts)
       then if the benefits only arise when communicating with
       other upgraded networks, hosts, applications etc. then
       the solution will not produce sufficient benefits to
       "early" adoptors for it to be widely enough adopted
       to make the required impact on the routing scalability
       problem.

       "Early" means the first adoptor, the first thousand adoptors
       and in some senses every adopter as long as some potential
       adoptors have not yet done so.

       The reason for this is that as long as there is less than
       100% adoption, and as long as benefits only materialize when
       communicating with upgraded networks, hosts, applications
       etc. there will always be a "split-system" situation, in
       which the benefits are partial.

       Since the benefits concern reliability of reachability - in
       multihoming and portability (changing to another ISP)
       situations - very few end-users will invest in the costs and
       disruption in order to achieve benefits for only a subset
       of their traffic.  This is true if the subset is 90%, and
       even more true if it is 10%. 1% or 0.01%, which would be the
       case initially.

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

--
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: Randall Atkinson <[email-masked]>
Date: Sun, 25 May 2008 04:47:15 -0700

Robin,

  Most of your stated beliefs here about "reality" are inconsistent
with my own prior experience in Network Engineering for a
multi-continent ISP,  inconsistent with my prior work on a very
large all-continents private IP network, and inconsistent with
my experience in enterprise IP networks.

  It is perhaps not surprising that since my experience
is so inconsistent with your assertions, then I don't reach
the same conclusions that you have reached.

  Given the charter at hand, which is for the Routing RG to
propose an architecture to the IETF rather than to endorse
some specific engineering proposal, it is not at all surprising
to me that the Routing RG has followed its charter and has
not focused on trying to select a specific engineering proposal.

  More generally, I'd encourage you to try to raise the "altitude"
of your discussions -- less about specific detailed proposals, less
about *engineering* tradeoffs (both of which are IETF responsibility,
not IRTF responsibility), and more focus about the *architectural*
tradeoffs to hand.

Cheers,

Ran Atkinson
[email-masked]

---

From: Robin Whittle <[email-masked]>
Date: Sun, 25 May 2008 23:06:15 +1000

Hi Randall,

> the same conclusions that you have reached.

OK.

> not focused on trying to select a specific engineering proposal.

I understand this.  In order to arrive at that architecture some
questions are being asked, such as whether or not to consider
translation schemes.  In order to come to a reliable answer about
that, or any other decision to include or exclude a class of
potential solutions, I think it is necessary to look at at any
detailed proposals in that class.  Other people may think a decision
can be made reliably without considering such low-level details.

In one of my messages I do discuss a translation approach to the
routing scaling problem in a purely theoretical manner (without
reference to Six/One Router) and argue that this class of solution
can only be useful with multiple sets of address space - which is
not feasible with IPv4.

> not IRTF responsibility), and more focus about the *architectural*

In my view the path to the best design involves a lot of work with
low level details - trying one combination and then another, trying
to find a set which works really well together.  I am not rushing
into implementation, as the LISP folks seem keen to do.

I am considering low-level details such as PMTUD:

  http://www.firstpr.com.au/ip/ivip/pmtud-frag/

that every map-encap scheme needs to consider.  Fred Templin is the
other person who has tackled this difficult area in meaningful
detail.  So far, the LISP team have only a cursory and I think
inadequate approach to PMTUD, and there is nothing in APT or TRRP
which considers it.

One could design a building in sweeps of aesthetic and broad
functional design, and leave the details to engineers to sort out.

However the best buildings are achieved by simultaneously
considering many lower-level aspects of the design, such as exactly
where the air is going to flow, where the services are going to be
installed and maintained, where the light is going to fall at
various times of the day and year, how noise from the
airconditioning affects those inside and outside the building etc.

I have a proposal to solve the routing scaling problem, and as far
as I know, you don't.  I would really appreciate you and others
criticising my proposal.  While there is a lot more work to do on
it, some key parts of it are described in enough detail for you to
critique it in meaningful detail:

  http://www.firstpr.com.au/ip/ivip/
  http://www.firstpr.com.au/ip/ivip/Ivip-summary.pdf
  http://tools.ietf.org/html/draft-whittle-ivip-arch-01
  http://tools.ietf.org/html/draft-whittle-ivip-db-fast-push-00

Some people prefer to operate from a high altitude.  I try to
consider all levels at once.

  - Robin

---

From: "William Herrin" <[email-masked]>
Date: Tue, 27 May 2008 00:11:07 -0400

> 1 - We have achieved consensus on very little:

Too true! So, let me turn the question on it's head:

1. What are the important, answerable questions for which we have
failed to find consensus? In other words, what important questions are
we still arguing about which have a factual answer but we don't have a
consensus on what that answer is?
2. Why is each question important?
3. How can we go about researching each question in order to find the answer?

For example:

Question: Is it permissible to have a transmission delay on the first
packet, as seen in TRRP? This has a factual answer. There is some
number of milliseconds beneath which the user never notices the delay.
There is some number of seconds above which the user is consistently
disappointed by the network performance. And there is a gray zone
between the two. We can design an experiment which lets us determine
what those numbers are.

Why is it important: If a first-packet delay is unacceptable, this
excludes virtually every pull-cache mapping system from consideration,
including TRRP and one of the LISPs.

How do we test: Build a router that simulates the delay
characteristics expected of TRRP. Install it in a den of net geeks on
their Internet link. Observe.

Simulation characteristic: If no packets for this packet's destination
have been transmitted in the past 15 minutes, delay this packet by X
ms. Otherwise, transmit immediately.

Experiment methodology: Instruct the users to inform you if they
believe the network is running slow. Have the software pick a new
delay each day. Each day there is a 50% chance that X=0. If it's not
zero then pick a random value between 50 and 2000 milliseconds. Don't
look at the numbers until after the test is over (double-blind). At
the end of the test, compute the correlation between user complaints
and the delay values that the machine logged.

Regards,
Bill Herrin

-- 
William D. Herrin ................ [email-masked] [email-masked]
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004