RE: multihoming issues via SCTP

[Coene Lode <Lode.Coene@siemens.atea.be>]

Some comments below.

> -----Original Message-----
> From: Iljitsch van Beijnum [mailto:iljitsch@muada.com]
> Sent: maandag 10 september 2001 17:17
> To: Coene Lode
> Cc: 'tsvwg@ietf.org'; 'multi6@ops.ietf.org'
> Subject: Re: multihoming issues via SCTP
> 
> 
> On Mon, 10 Sep 2001, Coene Lode wrote:
> 
> > This document describes issues of the Stream Control Transmission
> > Protocol (SCTP)[RFC2960] in regard to multihoming on the 
> Internet. It
> > explores cases where through situations in the internet, single
> > points-of-failure can occur even when using multihoming and what the
> > impact is of multihoming on the host routing tables.
> 
> The main problem is the idea of paths from an interface on 
> one host to an
> interface on another host. This could work if the hosts are 
> both connected
> to two networks that are not interconnected, but not on anything
> resembling the Internet.
> 
> For instance, consider host A having interface 1 connected to 
> ISP X and
> interface 2 to ISP Y. By coincidence host B it is 
> communicating with, is
> connected to the same ISPs, but the other way around: 
> interface 1 to Y and
> interface 2 to X. So now host A tries to connect to host B 
> over interface
> 1, ISP X, ISP Y and interface 1 of host B (A1->X->Y-B1) and also
> A2->Y->X->B2. This should work just fine, although two ISPs 
> instead of one
> in each path may not give the best possible performance.
> 
> But now there are three ways in which the connection can 
> fail: either of
> the ISPs may fail, or the connection between them.
> 
> This means there have to be more paths:
> 
> A1->X->Y->B1
> A1->X->B2
> A2->Y->B1
> A2->Y->X->B2

yes,  but does routing allow them to be used? We got the impression that at
a certain time you can have only one path through the network for a certain
destination address. 

> 
> However, this assumes both that the output interface stays 
> the same over
> the life time of a connection and that the end host is the 
> one making the
> decision how packets are routed to the outside. Both are 
> unlikely.

Well, but that is how it is done with SCTP. SCTP specifies the destination
address  and IP should try to route based on that IP address to B. If B1 is
taken as destination address then the source address should be the
corresponding A1(and that is something done by IP in host A). Host A has to
make a routing decision based on the destination address whether it likes it
or not.

> If an
> output interface fails, hosts may simply reroute outgoing 
> packets over the
> other interface. 

That is a possibility, but that depends on who finds it first. If SCTP
detects that the interface has gone(via the heartbeats that aren't
acknowledge), then it will changeover to another destination address(thus
taking the other interface)
If on the other hand routing finds this, then routing will reroute
everything over the other interface(but with the same destination address as
before(and giving SCTP the impression that the path presently used is still
up: so SCTP has been fooled into believing that both paths are still up) 
The question for me is: Does it happen that the host changes it routing
tables?

> And in most cases, routers will reroute packets over
> another path if a connection to an ISP fails. So the other 
> side will often
> still see incoming traffic from a remote address that is no longer
> reachable for outgoing packets.

Uhh, doesn't that mean that then the alternate address should be used
instead of the original addresses? 
And as far as I understand something from routing and routing protocols,
doesn't that take time? 
The fact is that I come from a background where rerouting(around failures)
is immediate and we don't wait for routing protocol till they found some
route around. In such a configuration, using the concept of paths through
the network is indeed a stupid concept, as there are in theory a infinite
number of paths through the network(every router has 2 or more routes
towards a certain destination at any time). But that is not what we have
been told what routing does in IP networks. Changing routes in IP networks
seem to involve first searching for them and waiting for it till the routing
protocol converges. And it is during that convergence faze that the packets
will be routed to probably the middle of nowhere(or better said: they are
dropped)
If I happen to be wrong in this assesment, then let me know. That would mean
that we could sleep better, put our trust in routing  and that all the work
in SCTP concerning multihoming wasn't really necessary.

> 
> Also, I don't like the idea of a protocol sending keepalives 
> over a path
> it is otherwise not using. This is a waste of resources and 
> can trigger
> inefficient use of different kinds of caches. 

Well the alternate routes are not only used for heartbeats, but if the SACK
don't get back, then the alternative routes are used for the SACK, so they
are not really idle in the strictest sense of the word.
What about caches: well caches (in my very humble opinion) shouldn't be
there in the first place, especially the implicit ones, as you point out,
they will contain irrelevant info. Well good, if they contain irrelevant
info, what the hell are they doing anyway in may path apart from having
absolutely no idea what is going on. The same is applicable for NAT's, that
is also for SCTP not such a nice sight, especially if the SCTP multihoming
is involved.

> Also, it won't 
> do much good
> unless there are three or more paths of which at least two fail, a
> situation that is not likely to be very common.

Murphy law: Failures of links, interfaces and routers will happen.(once upon
a time, we believed this tale that failures wouldn't happen, but then
reality and a lot of users thought us otherwise)

> 
> Iljitsch van Beijnum
> 

Yours sincerly,
Lode