Subject: Re: A tunneling proposal

From: Ramakrishna Gummadi <[email-masked]>
Date: Mon, 16 Jul 2001 14:40:48 -0700 (PDT)

> Tunnels can fix some types of failures, but they can't fix every type of
> failure, like routing problems that affect the entire ISP. This kind of
> multihoming is clearly inferior to the regular IPv4 way.
>

One of the  primary goals of tunneling, I think, is to make *existing*
connections that use transports such as UDP and TCP survive a partial
outage within the ISP.
I hypothesize that the only scenario where tunneling for TCP
and UDP fails is when the entire ISP is affected in a major way.
If one uses SCTP, or some other transport with
ability to support multiple addresses per connection, one can deal with
this problem completely.

True, regular IPv4  multihoming can provide this facility only because
end-hosts use a
single non-aggregatable address that is announced in the DFZ.
If hosts were to use multiple addresses, regular IPv4 multihoming can not
provide connection survivability for TCP and UDP even in the face of a
partial outage.

It all depends on what the first priority is---if it is scalability, then,
I think, to make TCP/UDP survive all failures, one needs an approach like
GxSE, which affects the IP layer. If you are willing to be less than
perfect, and don't want to change the host stacks, tunnels may be a good
choice, especially when applications can use SCTP to get the
required reliability.

-ramki

---

From: "R.P. Aditya" <[email-masked]>
Date: Mon, 16 Jul 2001 15:17:54 -0700

> choice, especially when applications can use SCTP to get the

one of the main problems with the tunnel approach (and I'm not saying there is
indeed a currently practical or better way) is that it requires a degree of
cooperation between ISP-A and ISP-B, which also means that the "decision" is
made independently of the end-network. It moves the redundancy from a "local"
solution up the AS hierarchy, which is what the *LA design was about. One of
the desireable features of current IPv4 multihoming is the ability to solve
for "local" connectivity loss (local-loop/router failure) via "local"
redundancy.

Unfortunately, apart from GxSE or some other "overlay" address scheme that
embeds "real-world" (read geographical) information, you can't fully
compensate for the loss of routing state information that a path-aggregated
DFZ presents and expect to preserve the desireable IPv4 multihoming
characteristics (cf. jabley's survey).

Adi

---

From: Ramakrishna Gummadi <[email-masked]>
Date: Mon, 16 Jul 2001 15:25:14 -0700 (PDT)

> for "local" connectivity loss (local-loop/router failure) via "local"

I am not certain this is the case. The tunnel will be initiated only at
the request of the multihomed site that detects problems with the other
ISP, say ISPB. In any case, remember that one end of the tunnel has to be
terminated
at the site's border router. The other end should be terminated within
ISPB, but where exactly this is done can be made a performance-optimizing
criterion from the perspective of ISPA who has to carry the tunneled
traffic. In any case, since it involves only the site's ISPs, I think this
setting up a tunnel may indeed by feasibly, although it may not be optimal
in every scenario.

-ramki

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 17 Jul 2001 01:13:57 +0200 (West-Europa (zomertijd))

> connections that use transports such as UDP and TCP survive a partial

Yes, tunnels can be useful for this.

> single non-aggregatable address that is announced in the DFZ.

Well, maybe this is just the way things will have to be.

Is there a known limit to the number of routes in the global routing
table? I know bad things started to happen at about 4000 and 10000, but
obviously those problems have been solved. Routers run just fine with 100,000
routes at present, and unless I'm mistaken, the most common types of router
have CPUs and memory that are well below what most of us have in our desk top
PCs.

On top of that, each route takes a LOT of memory: 240 bytes for the routing 
table and for each peer route in the BGP table in a Cisco.

If we can both increase memory and decrease the route/BGP table entry size by
an order of magnitude, we should be able to run with a global routing table
of 10,000,000 routes. That's about the entire IPv4 space as individual /24's.

Link speeds are high enough, and if route lookups are implemented as
variations of binary search they are of an order log(n) so going from 10e5 to
10e7 should be just a 40% slowdown. The only thing that might be a problem is
processing so many routes when BGP sessions come up.

I think it's worth it to look at this, because with CIDR it is pretty much
impossible to efficiently route traffic: many locations are hidden behind
aggregates. Someone in Chicago has to choose between routing traffic for the
aggregate to the west coast or the east coast, and in either case some
traffic will have gone in the wrong direction.

Iljitsch van Beijnum

---

From: "Jon (Taz) Mischo" <[email-masked]>
Date: Tue, 17 Jul 2001 20:20:50 -0500 (CDT)

> have CPUs and memory that are well below what most of us have in our desk top

My PC has 768M of RAM, which is unusual.  Most have 256M or less, and I
wouldn't want multiple full BGP feeds on a router with under 256M.

> processing so many routes when BGP sessions come up.

Wow...you sure are optimistic.

-- 
        "Be liberal in what you accept,
      and conservative in what you send."
--Jon Postel (1943-1998) RFC 1122, October 1989