Subject: RE: [Tsvwg] SCTP Addresses as upper layer ids

From: "Coene, Lode" <[email-masked]>
Date: Tue, 24 Jan 2006 17:45:59 +0100

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Mark Butler
> Sent: dinsdag 24 januari 2006 5:53
> To: [email-masked]
> Subject: [Tsvwg] SCTP Addresses as upper layer ids
> 
> 
> The SCTP socket draft currently describes the behavior of  
> recvmsg(2) as 
> having msg_name set to the "source transport address of the 
> user data".  
> This complicates applications that use addresses instead of 
> association 
> ids to identify peers.
> 
> There is draft layer 3 multihoming support for IPv6 based on the idea 
> that upper layer applications should only need to know about 
> the primary 
> address or "upper layer id" of each peer.  The shim6 draft 
> (*) describes 
> a shim for IPv6 that does this translation in layer 3.
> 
> I think the general idea behind this concept is useful for SCTP as 
> well.  To implement this, recvmsg(2) would always return the 
> address/port used to initiate the association with (if initiated 
> locally) or the initial source address/port (if the association was 
> initiated by the peer).  This address/port would be the "upper layer 
> id". Applications could use the upper layer id as a stable identifier 
> for the peer during the life of the association, allowing them to 
> largely be transparent to multihoming / path failover at the SCTP 
> layer.   The primary advantage of doing this over using 
> association ids 
> is protocol portability, of course.

The main problem with this approach is SCTP will see only one
address(+port),
The actual multihoming stuff with the different IP address is done in
the SHIM and is invisible to SCTP.
SCTP would be single homed with that upper layer id and below in the
SHIM layer, multiple paths may exist(with changes between the paths
based on reachability of the remote addresses). So if a path changes
during a SCTP file transfer, would that be a good idea or
not...(remember SCTP is not in charge of pathchanges and doesn't even
know if different paths exist, let alone how many, and which path
characteristics....

There is talk about exposing this stuff to the transport protocols in
general so that they know what has changed(example path change, new IP
address added or removed...) but then the questions should be : if so
much info needs to be given to the next upper layer, is this then
actually a good idea to do it in the SHIM layer? You'll end up with
twice the state(state in SCTP and state in SHIM) and no gain over the
present SCTP solution(actually it would be multihoming with reduced
functionality compared to SCTP) ADD/DELL IP would be duplicated in the
transport and network layer 

SHIM make some sense for UDP and TCP connections(no change in API to TCP
as such...) and TCP is singled homed anyway. But TCP does not need the
exposed stuff from SHIM, only UDP and SCTP may be interested in it...
UDP means the application has to add code to handle it..(Do all
applications need this.. Probably no, but some would..)
And SCTP has to add code also to handle it(the application is free to
let SCTP handle the multihoming magic or try to put some extra
application magic/logic in the choice of the paths used ....)
 
Well, I just did a port to a socket SCTP implementation and
I was damm glad that at least the sctp_sendmsg and SCTP_receivmsg had a
structure component containing  the SCTP assoc Id.
Otherwise I had to dig up the IP address everytime I had to send/receive
something
And it remains constant during the whole lifetime of the
association(independent from IPv6 renumbering, mobile endpoints and
associations containing both ipv4 and ipv6 addresses... )

> 
> Comments?
> 
>  - Mark
> 
> 
> (*) http://www.ietf.org/internet-drafts/draft-ietf-shim6-proto-03.txt
> 
> See also 
> http://www.apnic.net/community/presentations/docs/ietf/2005/20
> 050802-shim6-arch.pdf
> 

Yours sincerely,
Lode Coene

Siemens COM
atealaan 34          2200 Herentals, Belgium
E-mail: [email-masked]
Tel: +32-14-252081
Fax: +32-14-253212
> _______________________________________________
> tsvwg mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/tsvwg
> 

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

---

From: Michael Tuexen <[email-masked]>
Date: Tue, 24 Jan 2006 17:59:02 +0100

Hi Lode,

if I understood Mark correctly (please correct me if I'm wrong),
he was only talking to provide always the same address in the
recvfrom calls, not providing the SCTP stack always with the
same address.

So it is just a question about the interface SCTP/User.

And as you figured out, the assoc_id is for identifying the
association...

Best regards
Michael

---

From: Mark Butler <[email-masked]>
Date: Tue, 24 Jan 2006 14:29:16 -0700

Coene, Lode wrote:

>>Mark Butler wrote:
>>....
I understand there is already a requirement for IP multicast to be able 
to disable the shim, so I assume the same would apply for SCTP on a 
shim6 supporting host.  SCTP can do its own path management just fine 
without any support from shim6.  I am suggesting rather that SCTP stacks 
be made to behave like shim6 whether it is present or not, and on IPv4 
as well, because all the infrastructure is already there, it increases 
protocol portability, and simplifies the programming of a significant 
class of applications.

>transport and network layer 
Agreed.  The only use for shim6 for SCTP that I can see is perhaps to 
handle SCTP requests for alternate locators, so that SCTP applications 
can use the primary locator the same way TCP/UDP over shim6 would.  
However, making the SCTP stack behave as if it were a protocol using 
shim6 would be a good thing.  Considerable advantages for many 
applications, negligible costs.

 - Mark