Subject: RE: [Tsvwg] Re: SCTP multihoming issues draft

From: Coene Lode <[email-masked]>
Date: Fri, 8 Feb 2002 16:43:04 +0100

> -----Original Message-----
> From: Pekka Savola [mailto:[email-masked]]
> Sent: vrijdag 8 februari 2002 15:47
> To: Andreas Jungmaier
> Cc: Coene Lode; Transport Area wg (E-mail); SIGTRAN (E-mail)
> Subject: Re: [Tsvwg] Re: SCTP multihoming issues draft
> 
> 
> On Fri, 8 Feb 2002, Andreas Jungmaier wrote:
> > > Abstract
> > >     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.
> > >
> > > ==> what are "host routing tables" ?
> > 
> > I suppose that is what you get when you type in "netstat 
> -rn" on a decent
> > unix machine. Anyway, this is probably confusing: it should 
> probably say
> > something like "...and how the SCTP multihoming interacts 
> with routing"
> > since that is what is of concern here: the interface 
> between a transport
> > protocol and the network layer.
> 
> That seems more sane, or 'routing tables on hosts'.

OK, will be updated, no problem

> 
> > >     It might be usefull to explore ways where no routing 
> tables are
> > >
> > > ==> on a generic note: it seems to me there is a need for 
> routing tables
> > > on hosts only if one wants to optimize the paths: one is 
> used by default,
> > > and if it fails, just (try to) switch to the next one, right?
> > 
> > Any host that has an IP address has some routing tables. 
> Richard Stevens 
> > has put that nicely in his "TCP/IP Illustrated, Vol.1 - The 
> Protocols", 
> > chapter 9. That's recommended reading :-)
> 
> I know my Stevens very well, thank you.
> 
> If you read the draft around that place, you'll notice the 
> question was 
> about SCTP hosts somehow having to dump routing tables _from 
> a router_ on 
> hosts to make sensible decisions.  My belief is that 
> "regular" routing 
> table (ie. basically about 4 routes) is enough.

That migh be the case for host A talking with host B for most of the time.
In case of a webserver, you a lot of host X's with different addresses
coming together on a host A. How will that host A make a descision which
outgoing interface/link to choose?
Default routes will be of no help. Maybe educated guesses for loadsharing
purposes may be used but then be sure that for a connection from A to Xi ,
take for every packet the same path! Otherwise, the congestion control
algorithms may go haywire(feedback would be erronous). If that happen, then
we have really entered dangerous territory.
> 
> > > 2.3 SCTP multihoming and Network Adress Translators(NAT)
> > >
> > > ==> this very same problem will come up with single-homed 
> NAT's too (need
> > > to be able to do ALG translation), right?  Can be deleted.
> > 
> > What exactly can be deleted ?
> 
> Whole section 2.3.  Or perhaps, some considerations might be  
> preservable.
> 

To me the section makes a point(a vital one). 

> > Well, actually that section probably has not taken consideration at 
> > all of single-homed NATs (which in turn is not something 
> that comes to 
> > mind at once when talking about a NAT). 
> >
> > This is needed because single-homed _SCTP_ works together 
> with NATs nicely 
> > (because no multiple IP addresses are carried inside the 
> SCTP packets in the 
> > association setup phase), but multi-homed SCTP carries 
> these IP addresses 
> > inside the INIT and INIT ACK chunks, so something needs to 
> be tweaked in
> > that case.
> 
> If you use IP+SCTP, NAT still has to support rewriting the 
> port numbers 
> and IP numbers.  Therefore I gather NAT will have to be 
> modified anyway 
> cope with the fact.  This will probably include going into 
> INIT/INIT ACK 
> chunks, no?  
> 
> Anyway, multihoming through _one_ NAT seems rather stupid.  
> Via different 
> NAT boxes it might even make a little sense.

Well, that would be a really hard one. The INIT goes only through one NAT
box(one path),
the boxes on the other path can only guess on one or more paths of a SCTP
association running through them. That is the really difficult part. The
DATA chunk could be used for that, but what happens if the association is
terminated: the ABORT/TERMINATE also does not pass through all paths. So all
those NAT boxes never know when to kill off  a SCTP path/association. A
watch for heartbeat may help but then it has to guess the heartbeat timer,
which can goes from milliseconds to hours. The basic problem is : NAT boxes
have to staore state for the SCTP association that passes through them.:
they don't know when the association starts(except for the lucky one which
let the INIT through) nor do they know when the association is
terminated(except for the lucky one which let the ABORT/TERMINATE chunk
through, and that might not be the same box which let through the INIT
chunk): because the NAT boxes have to gues what the endpoint is up to, they
will either (a) screw up the association(dropping heartbeats or data) or (b)
screw up the NAT box(got zillions of SCTP paths going through but I don't
know which ones are still active)

conclusion:
NAT boxes are not really helpfull. a conclusion that has be debated over and
over again. 
OK , this section is just a addition to discussion about NAT boxes in
general. 
From here on, the discussion will degenerate in a filosofical discussion
about NAT boxes.
So I stop.

> 
> -- 
> Pekka Savola                 "Tell me of difficulties surmounted,
> Netcore Oy                   not those you stumble over and fall"
> Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords
> 

Yours sincerly,
Lode Coene

_______________________________________________
tsvwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tsvwg

---

From: Pekka Savola <[email-masked]>
Date: Fri, 8 Feb 2002 18:04:17 +0200 (EET)

On Fri, 8 Feb 2002, Coene Lode wrote:
> > If you read the draft around that place, you'll notice the question
> > was about SCTP hosts somehow having to dump routing tables _from a
> > router_ on hosts to make sensible decisions.  My belief is that
> > "regular" routing table (ie. basically about 4 routes) is enough.
> 

I'm assuming the said webserver is multihomed, and inbound traffic is 
distributed by some mechanism (e.g. more specific BGP advertisements to 
some destinations).

> we have really entered dangerous territory.

Please note that I don't see a clear possibility of ensuring completely
aligned inbound/outbound traffic as you can (almost) never be sure how far
the advertisments for the other interface go.

Currently, I believe this is just "solved" by common load-balancing 
by every packet/destination, or the webserver participates in routing 
system, by e.g. receiving more specific routes to some destinations.  I 
think the latter option is rather rare.

But you're treading into a territory that is a general problem with 
multihomed systems already: nothing new to SCTP AFAICS; as such, I don't 
see how SCTP would be any different from current practise.