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

From: "Coene, Lode" <[email-masked]>
Date: Wed, 25 Jan 2006 16:06:56 +0100

Some comments below...

> >>>
> >>>> 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 association id is exactly used for that. The problem 
> with the   
> >>> addresses is, that they can change
> >>> over time and they could even move from an association to 
> another   
> >>> when ADD-IP is used. So it is a bad
> >>> idea to use something, which is not constant over the 
> lifetime of  
> >>> an  association for identifying an
> >>> association.
> >>
> >>
> >> I left out something important - sendto(2) would always translate  
> >> from the specified address (the "upper layer id") to the active  
> >> address.  Those two translations are adequate to handle the  
> >> multihoming aliasing problem.
> >
> > Yes, I assumed this. But the assoc_id just does what you want...
> >
> >>
> >>
> >> For mobile SCTP, sendto()/recvfrom() programming style 
> does not  work 
> >> correctly without handling address change events. The only  change 
> >> that matters here is when the peer has vacated the 
> original  address, 
> >> requiring a new upper layer id assignment (to prevent  
> conflicts with 
> >> other clients occupying the old address).  Other  address 
> changes can 
> >> be ignored, because the stack would translate  in both 
> directions in 
> >> the same manner as shim6.
> >
> > I do not get the point here. The stuff is not mobile SCTP 
> related. It  
> > is just that an IP-address does not identify
> > an association during the lifetime of the association. The  
> > association id is exactly designed for it.

Mark, If the ulp identifier changes, the moment the primary path fo the
multihomed association  changes, then the ulp identifier is NO longer
constant during the complete lifetime of the association...
I have to find that association again .. probably based on IP address
info and change the saved ulp identifer... So it isn't constant to the
application anymore...
Dn't forget, the bindx call can remove the IP address from the socket
without invalidating the socket. Bindx can also add a new IP address....

The fact that the association id is presently a positive non-zero value
that does not change as long a the assoc is active, gives the
application designer a big advantage: SHIM changes, SCTP change,
renumbering may happen all under me, and I am blissfully unaware of
it... 
On the other had if I want to do path changes in SCTP, well I take my
association id, get the relevant info from SCTP for this particular
association and then do the magic with setsockopt()(still using the
assoc Id)

Conclusion: our ulp identifier is already among us,((maybe) cleaverly )
disguised as the association id....
> 
> 
> Well, if there is no mobility, then converting to only one address on 
> receive (and the reverse if no association id is specified) 
> ULP has all 
> benefits and no downside.  The main benefit would be improved 
> portability of UDP applications to SCTP.  That said, association ids 
> would be much more useful if you could pre-allocate them.  
> Something like:
> 
>    int sctp_get_assoc_id(int sd, uint32_t * assoc_id);
> 
> Then you would not have to send the first message, wait for a 
> matching 
> COMM_UP event, and extract the association id for later use. 

Well that was something that intrigued me...
If I did the connectx(), the function call was held up till something
came from the remote peer(I am not sure if it returned on the INIT_ACK
or the COOKIE_ACK... I wasn't tracing it to the microsecond you know...)
but it waited. In the SCTP(www.sctp.de -> sctplib) that I wrote my
application first for, there the associate(= connectx) did the same
thing but returned the assoc id upon completing the associate(connectx)
call. So the connectx does not return the assoc id to the caller at this
present moment. (at least not in lksctp that I am working with...)
One of the reasons why this might be implemented this way is that a
sctp_send...() can setup and tear down a association in this one call,
and it does NOT return a assoc id either. So there is some consistency
among the NOT returning of the assoc id.

I would prefer to have the connectx return a association id, as it would
indeed make some application code in the COMM_UP notification
redundant...
I am open to reasons why this migth not be possible(such as my
hypothesis above)

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

Yours sincerely,
Lode

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

---

From: Mark Butler <[email-masked]>
Date: Wed, 25 Jan 2006 20:16:25 -0700

>info and change the saved ulp identifer... So it isn't constant to the
I am not suggesting replacing the association id, just making the 
receive address as stable as possible. A pretty good sized group of  UDP 
applications use the address for a variety of things (including 
referrals) and they will not port cleanly if the address is changing 
unnecessarily, or if a send to an inactive address is not routed to an 
active one.  Granted, they will not work properly with mobile SCTP 
peers, but they do not work with  mobile UDP peers without application 
level assistance either. 

>without invalidating the socket. Bindx can also add a new IP address....
Adding new addresses would be transparent. So would removing any of the 
addresses except for the initial address. If the initial address is 
removed, there are two strategies.  One is to keep translating writes on 
that socket as before, the other is to start returing errors. 

Unlike shim6, an address conflict would only arise if a new peer 
initiated an association to the same one-to-many socket using the same 
address and port as the first one vacated.  That is sufficiently 
unlikely that it would be best to keep translating the initial address 
to the first association until a conflict actually occured, at which 
point the second association would take over the address.  Naturally, 
anyone writing a sendto() style application understands that an address 
is not going to be good forever.

>renumbering may happen all under me, and I am blissfully unaware of
I agree - the association id is proper for session based applications.  
However there are applications that can benefit from path failover and 
congestion control that are not session based.   Any application that 
does not have a natural idea of a session is almost certainly going to 
need SCTP_AUTOCLOSE. Where SCTP_AUTOCLOSE is set, the association id 
will become invalid at  arbitrary times, while the address or its 
translation is still good.

If you want to make SCTP behave like UDP with path failover and 
congestion control, just enable PR-SCTP and SCTP_AUTOCLOSE and set 
sinfo_timetolive to a sufficiently low value and Max.Burst and RTO.Min 
to sufficiently high ones, and translate addresses as I have suggested.  
If you want DCCP style sessions do the same with one-to-one sockets (or 
association ids on one-to-many sockets) and turn autoclose off.

>disguised as the association id....
The problem is that the association id is not portable, persistent, or 
referrable.  The address usually is.

>but it waited. 
That is proper behavior for a TCP-style connect().  The applications I 
am talking about would auto-initiate associations using sendto() or 
sendmsg().  However, it would certainly be nice if connectx returned the 
association id.  There is also no particular reason to make connect() or 
connectx()  block on a one-to-many style socket. 

The association id is available immediately - in fact there ought to be 
a call to get association ids ahead of time, for auto-initiating 
associations with sctp_sendmsg().  After all you can get socket 
descriptors before connect() why not association descriptors?

>In the SCTP(www.sctp.de -> sctplib) that I wrote my
By default associations never go away unless they are closed remotely or 
there is an error. SCTP_AUTOCLOSE is there to make them gracefully 
shutdown after a timeout.  So connectx() could return an association id 
(and without breaking the ABI either).  Speaking of association ids, 
they should be changed to be signed values like socket and file 
descriptors, so that -1 can signal an error.  int32_t instead of 
uint32_t inside structures.

>I am open to reasons why this migth not be possible(such as my
You are right on this point, as far as I can tell.  Thanks for your 
comments.

 - Mark