Subject: RE: SCTP multihoming issues draft

From: Coene Lode <[email-masked]>
Date: Wed, 6 Feb 2002 16:21:58 +0100

-----Original Message-----
From: Tim Chown [mailto:[email-masked]]
Sent: Wednesday, February 06, 2002 3:31 PM
To: Coene Lode
Cc: Transport Area wg (E-mail); SIGTRAN (E-mail); [email-masked]'
Subject: Re: SCTP multihoming issues draft

>On Wed, 6 Feb 2002, Coene Lode wrote:
>
>> If by then end of next week, no further issues have been identified, then
I
>> would ask for this draft to be moved to informational.
>
>Does the draft have to only consider two network interfaces for the
>multihoming issues?   In IPv6, as you point out, each interface can have
>more than one IPv6 address (and addresses of many scopes), so the simplest
>multihoming case for IPv6 is a host (endpoint) with one interface, 
>recieving two different /64 prefix RAs, and thus having two IPv6 addresses
>from two different providers.   The dual interface scenario may be useful 
>of course, e.g. when considering wired and air interfaces.

It considers any configuration with multiple interface cards or one
interface card with multiple addresses(in both cases possibly going to
infinity:-)
The examples are for multiple interface cards as that was the first use we
thougth of.

>
>When you say "it is recommended that IP addresses in a multihomed endpoint 
>be assigned IP endpoints from different TLA's to ensure against network 
>failure", this would be the default case for IPv6.  
>
Great, that is a plus for letting SCTP run on IPv6
>
>
>For IPv6, delete section 2.3 :-)

Unfortunaly, I have also to describe the present situation with IPv4 which
as you can derive from paragraph 2.3 is less than ideal. The last sentence
is a gentle push for people NOT to use IPv4 NAT boxes if people really want
to use multihoming. The result should be to use IPv6 for such cases.

>
>In general, more consideration could be given for IPv6, perhaps?  (you 
>did cc multi6 :-)   If I've misinterpreted the text, perhaps the title
>of the draft needs revision?

Well, this draft has to address all possibilities whether I(and my
comrades-in-arms) like them or not. And the issue of multihoming of SCTP in
IPv4 networks together with NAT's is one of them. That's why the TSVWG and
SIGTRAN are on also.

And if this issue list makes that more people would use IPv6 networks in
real situation, ,that would certainly make IPv6 proponents happy.(besides
the SCTP folks)

>Best wishes,
>Tim

yours sincerly,
Lode

---

From: Coene Lode <[email-masked]>
Date: Tue, 12 Feb 2002 12:18:16 +0100

Hello Randy,

> From: Randall Stewart [mailto:[email-masked]]
> Sent: maandag 11 februari 2002 14:54
> To: Arun Prasad
> Cc: Coene Lode; Transport Area wg (E-mail); [email-masked]'
> Subject: Re: [Tsvwg] SCTP multihoming issues draft
> 
> 
> Arun:
> 
> I don't think we need to have a host become
> routing aware as section 2.2 seems to imply to
> some degree. Some clever work with the routing
> system in the host can alleviate the problem that
> Lode is mentioning here I think..

Maybe the section is not clear enough. 
And a bit biased too. At least, I need to rephrase "downloading the routing
tables" sentences.  Stay tuned for the next iteration.

> 
> For example in our BSD work we have now the ability
> of the routing system to have multiple default routes
> and a method to lookup a route via an alternate interface.
> We probably need to expand this to actually look at the gateway
> and not the interface.. but for now we use interface :/
> 
> This allows the sctp stack to call 
> 
> rtalloc_alternate(dst,old_route);
> 
> which then trys to give a route out a different interface if
> necessary hunting up the routing tree.
> 
> With this change we then get:
> 
> A) The host only needs to know about the edge routes available
>    via its multiple default routes.
> 
> B) Full use of the multi-homing provided without injection
>    of static routes as the v4 side does now...
> 
> C) Host only knows about the default routes and possibly
>    some special routes applied by the local administrator...
> 
> R

yours sincerly,
Lode

> 
> Arun Prasad wrote:
> > 
> > hi Coene,
> >     Regarding the below section in the draft,
> >     2.2 SCTP multihoming and the size of routing tables
> >     what are we trying to achieve....   section 2.1 basically
> > explained the restrictions
> > of SCTP's multihoming feature due to existing IP 
> architecture....  The
> > problems
> > are well sorted out, and one solution I get from that is,   changing
> > the Source
> > Ip address for the packets send ( periodically, if the 
> acknowledgemnet
> > for it is
> > not reaching the endpoint,) from a multihomed endpoint....
> >     But regarding section 2.2,  SCTP could do nothing about it (
> > because its
> > basically IP's restriction or the restriction of the currect routing
> > architecture....)
> > SCTP defines some rules or features, using them properly is the
> > responsiblity of the
> > Application which uses it (it may the administrator of the system
> > also...) ..  This
> > each of them using it can implement their own ways to get 
> the maximum
> > from use
> > of multihoming feature of SCTP......
> >       Will it not make SCTP more heavy, if we try to load 
> it with more
> > and more
> > sub features like this... and it will make it more dependent on the
> > existing architecture
> > which will make the maintanance tough.....
> >     But definitely we should be spelling out the problems or
> > restrictions of the
> > multihoming feature of SCTP, with which the users of SCTP users will
> > do
> > appropriate action to use it best....
> > 
> > Is the observation valid??
> > 
> > Thanks
> > -arun
> > 
> > Coene Lode wrote:
> > 
> > > Previous week, the draft on SCTP multihoming issues was published.
> > >
> > > Apart from some editorial changes concerning author list and
> > > missing/wrong
> > > page numbers,
> > > the only major change is a sentence added at the end of paragraph
> > > 2.3 SCTP
> > > multihoming and Network Adress Translators(NAT):
> > > "It should be noted that the NAT box becomes a single
> > >     point-of-failure in this case, as ALL the paths of the SCTP
> > >     association have to go through that single NAT box."
> > > Theoretical it is possible to let all the different paths run
> > > through
> > > different NAT boxes, but then the NAT boxes would never 
> know exactly
> > > when to
> > > teardown/terminate the association as the terminate or abort takes
> > > only one
> > > of the paths(and there are other difficulties, such as the
> > > heartbeats
> > > ...etc...) So in practical terms this sentence should be 
> correct. If
> > > you
> > > feel otherwise, please let me know and I'll remove or add 
> something
> > > to it to
> > > make everything clear.
> > >
> > > The draft can be found at the IETF draft directory:
> > > Multihoming issues in the Stream Control Transmission Protocol
> > > <draft-coene-sctp-multihome-02.txt>
> > >
> > > If by then end of next week, no further issues have been 
> identified,
> > > then I
> > > yours sincerly
> > > Lode Coene
> > > _______________________________________________
> > > tsvwg mailing list
> > > [email-masked]
> > > https://www1.ietf.org/mailman/listinfo/tsvwg
> > 
> > --
> > ****************************************************************
> > V.Arun Prasad
> > HCL Technologies Ltd.
> > 51, Jawaharlal Nehru Road,
> > Ekkattuthangal,
> > Guindy Industrial Estate,
> > Chennai - 600097.
> > 
> > Contact # : 9144 - 2334174
> >             9144 - 2334181
> >             extn : 233
> > ****************************************************************
> > 
> 
> -- 
> Randall R. Stewart
> [email-masked] 815-342-5222 (cell phone)
>

---

From: Coene Lode <[email-masked]>
Date: Tue, 12 Feb 2002 12:18:09 +0100

Hello Arun,

>From: Arun Prasad [mailto:[email-masked]]
>Sent: maandag 11 februari 2002 6:50
>To: Coene Lode
>Cc: Transport Area wg (E-mail); [email-masked]'
>    what are we trying to achieve....   section 2.1 basically explained the
restrictions 
>of SCTP's multihoming feature due to existing IP architecture....  The
problems 
>are well sorted out, and one solution I get from that is,   changing the
Source 
>Ip address for the packets send ( periodically, if the acknowledgemnet for
it is 
>    But regarding section 2.2,  SCTP could do nothing about it ( because
its 
architecture....) 
responsiblity of the 
>Application which uses it (it may the administrator of the system also...)
..  This 
>each of them using it can implement their own ways to get the maximum from
use 
>      Will it not make SCTP more heavy, if we try to load it with more and
more 
existing architecture 
>which will make the maintanance tough..... 

That is true. But some of the features would be far more usable if some
things(like NAT's) didn't exist in the first place. And according to the
end-to-end pricniple, it is better to put some complexity in the the
endnode, than to put it in the network: I concede that this is more a
filosofical discussion, but as the NAT section shows, such boxes are not
that helpfull.

>    But definitely we should be spelling out the problems or restrictions
of the 
>multihoming feature of SCTP, with which the users of SCTP users will do 

That is indeed a correct observation. 
This draft tries to spell out problems or restrictions of the multihoming
feature of SCTP.
Some of those problems can be evaded in SCTP but others need to be solved in
IP (or somewhere else). That is not my call to make. 

yours sincerly,
Lode