On Dec 29, 2008, at 5:24 AM, Robin Whittle wrote:
http://bill.herrin.us/network/rrgarchitectures.html
PHASE TWO: REJECTION
Robin, now it's time to tell us why everything but Strategy A
won't work. ;-)
I am calling for strong consensus on rejecting all strategies but A.
I agree with the reasons listed below for rejecting all strategies
but A. Our HotNets 08 paper listed some of the same objections to
Strategy B.
Lan
Strategy B
This is a host-based solution. There are two reasons I believe
this should be rejected.
1 - The most important and fundamental reason is that it pushes new
responsibilities to every host on the Net - and that these
responsibilities concern things which happen in the network -
the DFZ, the ISP(s) and perhaps the border routers of each
end-user network.
Making every host responsible for solving these problems
involves greater complexity in every host and additional
flow of packets to and from hosts in order to perform
these new functions. This adds complexity and cost to
all hosts and is a particular cost burden on hosts with
narrow, expensive, links - such as any host on a radio
link.
The unreliability and delays inherent in slower - especially
radio - links will impact the ability of these hosts to
perform these functions. So the extra management traffic and
the dependency on that traffic will be particularly burdensome
for any radio-linked host.
Most fundamentally, it is pushing the solution to a network
problem to hosts. I think this is wrong in principle, as well
as having obvious practical problems. One reason it is wrong
in principle is that a single change in the network could be
handled by a much smaller number of active elements, via
a Strategy A solution, than the potentially boundless number
of hosts which would have to handle it in a Strategy B
solution.
More here:
Fundamental objections to a host-based scalable routing
solution
http://www.irtf.org/pipermail/rrg/2008-November/000271.html
2 - The host changes which are requires are incompatible with the
need for a scalable routing solution to be introduced easily
and with substantial immediate benefits for all those who
adopt it.
It is agreed AFAIK that we can't force the solution on anyone.
So we need to develop something which most end-user networks
(and their ISPs - or potentially all networks and all hosts)
will want to adopt. They will only adopt it if it provides
substantial immediate benefits over their costs and risks.
Host changes - especially changing APIs and applications -
are extremely hard to implement. AFAIK, the benefits of
Strategy B only occur when both hosts in a session have
the upgrades. Consequently, assuming the benefits are
substantial (I might argue they are not), early adopters
only get slight benefits, since only a small fraction of
sessions, on average, are with other hosts with the
upgrades.
I could write more about this, but I think it should be
obvious to anyone that there is no way we can make a
solution attractive to everyone who needs to deploy
Strategy B, due to the inherent difficulties rewriting
applications and due to the initially very limited
proportion of hosts which will have the upgrades.
A further argument along these lines is that even if
90% of hosts were upgraded, Strategy B would provide
benefits on average to only 90% of sessions. I think
many people would find that too low when it concerns
multihoming. By contrast, some Strategy A schemes enable
benefits to 100% of sessions (LISP PTRs, Ivip OITRDs) -
since they do not require any changes in the other host
or that host's network.
Strategy C
Despite a decade or two to research such things, no-one has
come close to devising a routing system which could serve
the needs of the interdomain routing system, as BGP does
today, and which could scale to handling the number of
prefixes we need to solve the routing scaling problem.
Although we have no clear target, I think there would be
consensus that the scalable routing solution needs to
provide multihoming, TE (and I think "portability) to
at least several hundred million end-user networks.
Since there is no sign of a routing system which could
scale to this number of advertised prefixes - including
by souping up BGP in some way - I suggest we should form
a strong consensus to reject this strategy.
Further arguments include there being no chance we could
introduce a new routing system without prohibitive
disruption, and that some of the most discussed alternatives
(geographic aggregation) do not respect the business needs
of ISPs.
One of the LISP folks pointed me to a critique of "compact
routing":
On Compact Routing for the Internet
Dmitri Krioukov, kc claffy, Kevin Fall, Arthur Brady
ACM SIGCOMM CCR, v.37, n.3, p.41-52, 2007
which may be relevant in deciding to reject Strategy C.
Strategy D
This involves souping up the FIBs of routers. The routing
scaling problem might at some time involve FIB costs and
performance, but now and in the foreseeable future, the
scaling problem relates to the undesirability of trying
to make the global BGP control plane work with the
number of prefixes required (hundreds of millions) to
provide (with current techniques) the multihoming, TE
etc. needs of end-user networks in the future.
Strategy E
This is not a proposal which solves the problem to anything
like the degree we need to solve it. Its primary effect would be
to create a different set of barriers to end-user networks gaining
multihoming, TE etc. Currently the barriers are enforced by
making it hard to get PI address space and by discouraging
end-user networks from advertising too many prefixes in the DFZ.
With this proposal, they may be able to get PI space more easily,
but they would need to pay to advertise it, by the prefix.
The money would compensate ISPs who pay for the larger DFZ
routers and this would to some extent allow more prefixes to
be advertised before the ISPs faced unreasonable cost burdens.
However, this is just throwing money at the problem. Without
fundamental changes, the current BGP-based interdomain routing
system will never cope reliably with hundreds of millions of
end-user network prefixes, or with the rate of change in the
way they are advertised in order to provide TE and multihoming.
Strategy F
We should reject this, because (I believe) at least one of the
Strategy A schemes is a good solution to the problem.
- Robin
_______________________________________________
rrg mailing list
[email protected]
https://www.irtf.org/mailman/listinfo/rrg
_______________________________________________
rrg mailing list
[email protected]
https://www.irtf.org/mailman/listinfo/rrg
