Subject: RE: [Tsvwg] SCTP ULIDs / association id return values

From: "Coene, Lode" <[email-masked]>
Date: Thu, 26 Jan 2006 19:04:59 +0100

Mark,
 
If I understand you correctly, you are talking about an identifier that
can be used for referals... And which can be send to a remote peer, if I
understand that correctly...
Ahh That why you were talking about the recvmsg
The association Id is purely local(and therefore has no use being send
to a remote peer for referrals)
 
Further comments inline...

________________________________

	From: Mark Butler [mailto:[email-masked]] 
	Sent: donderdag 26 januari 2006 4:16
	To: Coene, Lode
	Cc: [email-masked]
	Subject: Re: [Tsvwg] SCTP ULIDs / association id return values

	Coene, Lode wrote:

		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...

	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.   
	 
	Well, if the receive address is not stable, then the UDP
application have a big problem anyhow
	The question is a stable identifier of the remote peer,
preferably not based on the IP address but on something else. 
	That would require some new form of namespace such as might be
proposed in the SHIM(If I understand that correctly)  or a simplere
approach may be to use teh FQDN(a DNS name)
	But from the stuff that I've seem in the SCTP sockets, it is
pretty easy to get information from the remote peer about which is
presently reachable .; Just send the retrieved one address or all
addresses as referral to the peer and the peer can try to set up the
association to any of the addresses(even sending INIT in pararlllel to
all of the IP addresses and the first that gets back to the local SCTP
is the winner)... 
	The case that you are describing here is more a slow address
change(measured in minutes), and then during those x minutes all those
addresses are reachable.. 

		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....

	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.   
	I assume this a an ULP ID made up of IP address+portnumber as
you first proposed in the thread...
	Looks like translating the write on that socket is going to be
rather costly: you have to keep a mapping table of all your remote peer
with those ULP id's around...independant from the associations.... 
	
	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.

		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... 

	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. 

		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....

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

			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. 

	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? 
	 
	Well converting association ID into association descriptors and
then preallocating them ain't a great solution.. 
	Most Operating systems folks would think as : yet another scheme
to eat up memory resources...
	I am perfectly happy to wait for the association ID untill the
INIT_ACK or the COOKIE_ACK comes back...(be it via connectx or COMUP)

		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.

	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. 
	 
	actually you are asking to turn everything to a one-to-one
interface style and then you would only need a
filedescriptor(unfortunaly, I don't think a firedescriptor can be
refered to a remote peer, so that doesn't solve the referal problem...)
	I myself seems to be a one-to-many interface stylist. I was
trully suprised at finding out that TCP only does a one-to-one interface
style.. That means that servers receving lots of TCP connections(or
sending) have to look for lots and lots of filedescriptors. It is a
daunting and admirable possition to be in for TCP folks...

		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)

	You are right on this point, as far as I can tell.  Thanks for
your comments.
	
	 - Mark
	 
	Thank you for your comments.. It has become clearer to me what
you want...
	I Need some more thinking to figure out if this is actually
possible...
	 
	Yours sincerly,
	Lode  

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

---

From: Mark Butler <[email-masked]>
Date: Sat, 28 Jan 2006 09:07:23 -0700

Coene, Lode wrote:

> Mark,
>  
> If I understand you correctly, you are talking about an identifier 
> that can be used for referals... And which can be send to a remote 
> peer, if I understand that correctly...
>     ------------------------------------------------------------------------
>
>     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? 
>      
>     I am perfectly happy to wait for the association ID untill
>     the INIT_ACK or the COOKIE_ACK comes back...(be it via connectx or
>     COMUP)
>
I should say association ids, not association descriptors as the 
language in the latter is ambiguous between the identifier and the 
internal structure.  However, an association TCB is normally created on 
the first send, creating it a few microseconds earlier would not use any 
extra resources and would solve a lot of problems, making such an 
ability a good candidate for standardization.  I am told FreeBSD already 
has this ability...

>     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 should say association id, not association descriptor.  Referral is 
not an issue here - for that you generally need real addresses.

>     I myself seems to be a one-to-many interface stylist. I was trully
>     suprised at finding out that TCP only does a one-to-one interface
>     style.. That means that servers receving lots of TCP
>     connections(or sending) have to look for lots and lots of
>     filedescriptors. It is a daunting and admirable possition to be in
>     for TCP folks...
>
Well other than inefficiencies involved with using select()/poll(), a 
separate socket descriptor / socket structure is usually a marginal 
amount of additional overhead above the connection / association TCB in 
the first place. Association ids just move the abstraction down a 
level.  One or both have to be translated from integers to internal 
pointers on every call. 

 - Mark