Re: [RRG] Comparison table - LISP/APT/Ivip/TRRP

["William Herrin" <bill@herrin.us>]

On 8/24/07, Robin Whittle <rw@firstpr.com.au> wrote:
> They all have similar problems with tunneling
> overhead, fragmentation, breaking traceroute and Path MTU Discovery.

Hi Robin,

What about something like this: http://bill.herrin.us/network/trrp-via.html


>  All but Ivip, in my view, have a problem with the ETRs finding it
> extremely onerous to ensure that local source addresses are not
> spoofed in the packets they decapsulate:

I may have a deadly problem for you here: If the inner source address
is the outer source address then the fragmentation needed message will
return to the originating host instead of the ITR. Even if the
originating host accepts the size limit offered in fragmentation
needed message and retransmits with the shortened MSS, the packet
won't get there. Why? Because the ITR will add its own header to the
front of the packet, boosting the size back above the path MTU.

The only thing I see that can save outer source = inner source would
be to set the ITR's MTU to the IPv4 minimum MTU, eliminating the
possibility of downstream fragmentation needed messages. 576 bytes?
536 bytes? I forget.


> (I need to respond to Bill Herrin's message about this.)

:)

> I think that any system where packets have to wait while a query
> traverses some global system will not be acceptable.

I disagree. I assume we expect local-scope routing to behave the same
way it does now, with raw IP packets and an interior protocol
spreading the routes. If so then the systems we're talking about are
directed towards global-scope routes.

When you're trying to get to a remote host like www.google.com, you've
almost always already done a DNS or comparable lookup to get from the
name to an IP address. With TRRP you potentially do three lookups
instead: once for name to IP, once for forward IP to route and once
for return IP to route. That makes the first communication longer,
yes, but its still in the same ballpark and all three lookups benefit
from caching so that later packets between the same endpoints aren't
delayed at all.

But really, this is something we don't need to argue about. Lets put
it to the test and see what happens. If I can get half a dozen or so
volunteers, this is what I'd propose we try:

1. I'll add enough code to the proof of concept ITR to make it
field-usable. Should take me a few weeks; after all I do have a day
job too. :)
2. We'll take a /23 from the swamp that I have parked right now and
each volunteer will announce the whole /23 via BGP. That'll make it
"anycast."
3. The /23 will be broken up into subnets and two will be assigned to
each volunteer.
4. One of each volunteer's subnets will be staticly GRE tunneled to a
fixed destination. This is the "control" group and is intended to
simulate a tunnelling solution where the routing information is
pre-propagated to the ITRs.
5. The other one of each volunteer's subnets will be dropped into the
TRRP ITR and dynamically tunnelled via a DNS lookup as specified in
http://bill.herrin.us/network/trrp.html . That's our experimental
group.
6. Then we'll bang on it and see what the user-observed difference in
performance really is.

Thoughts?

> I recently corresponded with
> a knowledgeable and communicative fellow on another list who figured
> that the current growth in multihomed sites is just the middle of an
> S curve

Yikes! If anything, the growth rate of multihoming is heavily
suppressed by indirect registry requirements that you deploy 500 or so
computers before you can multihome. (PI needed to multihome, /22 with
efficient utilization needed to get PI.)

This cuts out the large and growing number of folks who have two
broadband providers in their basement or a broadband and backup dial
provider.


> I am unsure about when the rising costs of routers, if that is the
> outcome of doing nothing, will be such a problem as to convince a
> sufficiently large majority of  people (ISPs mainly, I guess) that
> something dramatic needs to be done.

I suspect Usenet and NNTP would make for a useful case study to
predict how BGP growth is likely to progress and its impact on cost
and stability. Its basically the same structure: take any message
introduced at any node and copy it to all the other nodes each of
which must reasonably index it and make it available to readers.

Regards,
Bill Herrin


-- 
William D. Herrin                  herrin@dirtside.com  bill@herrin.us
3005 Crane Dr.                        Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004

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