RE: multihoming issues via SCTP

[Iljitsch van Beijnum <iljitsch@muada.com>]

On Tue, 11 Sep 2001, Coene Lode wrote:

> > I think the main problem is that in most cases a default route will be
> > used, which is tied to one interface. That means the paths
> > originating at
> > the different interfaces are effectively identical.

> Hmm, not exactly the effect we are looking for.

I believe SCTP was originally conceived as a protocol to transport
telephony signalling. In such a context, it is possible to create a
network where this is not a problem. However, I gather that there are
people who want to do a lot more with SCTP and the Internet as a whole is
not likely to be reengineerd to eliminate this problem.


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

> > I suppose it is possible to do this, although TCP doesn't.

> It is not TCP nor SCTP that have to do selection of the source address, They
> cannot do this, it is the IP layer who has to do this.

Please keep in mind that selection of the source address and of the source
interface are not related. In TCP, the system will select the source
address matching the output interface for the first packet of an outgoing
session. Since the remote TCP expects this address to stay the same,
subsequent packets within a session all have the same source address,
regardless of the output interface.

Since it is possible in TCP to find a source address based on the output
interface for the first packet, it stands to reason that SCTP could do
this for every packet.

[heatbeats]

> You can turn it off(see also Michel's mail)

I suggest that for implementations that are deployed in regular hosts that
are expected to communicate over the Internet, heartbeats are disabled by
default.

> > I'm not saying failures won't happen, just that in most cases the
> > heartbeats won't help you. If there are only two paths,
> > you'll have to use
> > the second one when the first one fails. So why bother to see if the
> > second path is alive? You'll find out soon enough.

> In my view, if the second path is not alive then everything is allready lost
> and the net result is that I gain a lot of very, very angry customers.
> That is my view and , agreed, for some/many/most/all?(make your choice)
> applications that need not to be the case.

I don't understand.

Either the line is down or it is up. Heartbeating will not change this:
we're not talking about quantum physics, where looking at something
changes its state.

I suppose that in telephony signalling, where there the number of sessions
is very small and they stay up for very long and the data is very
important, it can make sense to immediately see when a path goes down. But
now consider a web server. It has dozens of simultaneous sessions, and
each only lives for a few moments. Is it then sensible to send heartbeats
over dozens of alternative paths? I hardly think so: having each session
discover the same situation individually doesn't make any sense. This
should be done at a lower level, if this functionality is required. But I
that goes for all the multihoming features of SCTP, IMHO.

> > If doing something and doing nothing yield the same results,
> > the latter is preferable.

> Depends on the view taken. If you are happy which the situation as you
> described then OK, then it is better to do nothing(that is why the heartbeat
> is optional). But you will find people(like me) doing heartbeats(and yes,
> there are not many of us)

Please read what I'm saying. If not asking for anything will get yo a cup
of tea. And if asking for a cup of coffee will get you a cup of tea also.
Is it then worth the trouble asking for coffee?

> Seems like we are in between a rock and a hard place. Maybe I'll try to come
> up with something.

Not really. Have a look at http://www.muada.com/sctp.gif

[1st drawing] It describes a situation where host A communicates with host
B and both networks have to routers and connect to two ISPs. As you can
see, the default makes all the output traffic go over one connection:

Red:	A1 -> ISP W -> ISP Y -> B3
Orange:	B3 -> ISP Y -> ISP W -> A1
Blue:	A1 -> ISP W -> ISP Z -> B4
Cyan:	B3 -> ISP Y -> ISP X -> A2

[2nd drawing] Then, if the 1 interface on A fails, it will detect this
(hopefully) and point the default route to the other router over the other
interface. Now the orange path from B to A fails, but the red and blue
paths from A to B both still work and the cyan path from B to A as well.

[3rd drawing] Another type of failure would be where ISP W and ISP Y (if
they are the same ISP or share something) both fail. Then, two paths fail
and the remaining paths get somewhat longer than necessary, but there is
still a path in each direction.

[4th drawing] In an environment where both ends of the connections can be
controlled or coordinated, it is very easy to add static routes from A to
B over A1/B3 and A2/B4 so the paths are more diverse and have to depend
less on reliability/redundancy measures elsewhere in the network. If the
network interfaces of A and B are in the same subnet, this even happens
automatically without static routes.

Iljitsch van Beijnum