RE: [Tsvwg] SCTP multihoming issues draft

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

Hello Arun,

>-----Original Message-----
>From: Arun Prasad [mailto:arun@netlab.hcltech.com]
>Sent: maandag 11 februari 2002 6:50
>To: Coene Lode
>Cc: Transport Area wg (E-mail); 'multi6@ops.ietf.org'
>Subject: Re: [Tsvwg] SCTP multihoming issues draft
>
>
>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..... 

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 
>appropriate action to use it best.... 
>Is the observation valid?? 

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
 
>Thanks 
>-arun 
>Coene Lode wrote: 
>The draft can be found at the IETF draft directory: 
>Multihoming issues in the Stream Control Transmission Protocol 
><draft-coene-sctp-multihome-02.txt>