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

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

Sorry, Pekka, Forgot to reply on one of your points.

> > 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?  
> 
you are 100% right. The NAT boxes has to look in the INIT/INIT ACK.(and
probably do some stuff) 

Yours sicnerly,
Lode Coene

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

---

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

Hello Arun,

>-----Original Message-----
>From: Arun Prasad [mailto:[email-masked]]
>Sent: maandag 11 februari 2002 6:50
>To: Coene Lode
>Cc: Transport Area wg (E-mail); [email-masked]'
>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>

---

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

Hello Pekka,

Sorry for the delay(some minor internal system failures:-) 

> From: Pekka Savola [mailto:[email-masked]]
> Sent: vrijdag 8 februari 2002 16:01
> To: Coene Lode
> Cc: Andreas Jungmayer (E-mail); Transport Area wg (E-mail); SIGTRAN
> (E-mail); [email-masked]'
> Subject: [Sigtran] RE: SCTP multihoming issues draft
> 
> > > ==> 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?
> > > 
> > 
> > See previous remark on routing tables.
> 
> See my reply to Andreas. (note to others: multi6 was stripped 
> from Cc:).
> 
> In short, routing table is naturally required, but the draft 
> talks about 
> the need to "download" a fuller table from edge routers on 
> hosts.  IMO 
> this is unnecessary.

the text is indeed too broad(my fault). It should be saying something
about"distributing some prefixes from the edge routers to the host". That is
far nearer to the truth.
But my favourite solution to this should be something that does NOT need "a
download" or "receiving some prefixes"(in general any solution needing to
bugger the adjacend routers) on the host. As such Randy's BSD implementation
is clearly good step in that direction.(as I could infer from his
explanation, correct me if I am wrong)

yours sincerly,
Lode

> 
> -- 
> 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
> 
> 
> 
> 
> Sigtran mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/sigtran
>

---

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]'
> 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:
> >     what are we trying to achieve....   section 2.1 basically
> > explained the restrictions
> > 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
> > 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
> >     But definitely we should be spelling out the problems or
> > restrictions of the
> > > 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.
> > >
> > > 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.
> > >
> > > yours sincerly
> > > Lode Coene
> > >
> > ****************************************************************
> > 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)
>