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

From: "Coene, Lode" <[email-masked]>
Date: Tue, 24 Jan 2006 18:25:10 +0100

> -----Original Message-----
> From: Michael Tuexen [mailto:[email-masked]] 
> Sent: dinsdag 24 januari 2006 17:59
> To: Coene, Lode
> Cc: Mark Butler; [email-masked]
> Subject: Re: [Tsvwg] SCTP Addresses as upper layer ids
> 
> 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.

Well Mark talks about the ULP identifier in the recvfrom call, but you
could use that ULP identifier also for sending msg.. Maybe I am seeing
more in it than meets the eye....
Or is this about the providing the recvfrom with a certain "address" on
which the recvfrom has to "listen" till something comes in...???

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

Yep, but it has it consequences...

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

That wasn't that hard to figure out, was it......

> Best regards
> Michael

Yours sincerely,
Lode

Siemens COM
atealaan 34          2200 Herentals, Belgium
E-mail: [email-masked]
Tel: +32-14-252081
Fax: +32-14-253212

> 
> On Jan 24, 2006, at 5:45 PM, Coene, Lode wrote:
> 
> >
> >> -----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
> >
> 
> 

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