Subject: [Tsvwg] Sockets API suggestion concerning sctp_assoc_t

From: Anders Torger <[email-masked]>
Date: Tue, 10 May 2005 20:44:26 +0200

One problem with sctp_assoc_t is that there is no clear definition of 
what the values can be.

The only thing I can find out from draft-ietf-tsvwg-sctpsocket-10.txt is 
that zero is not a valid value for an association, but any other value 
may be.

It would be great if the API draft would specify some facts/rules about 
sctp_assoc_t and association ID. I *think* this is true, and I'd like 
that it was mentioned more clearly in the draft:

 - sctp_assoc_t is an integer of unspecified size and may be signed or 
   unsigned
 - a valid association has an id != 0 (that is both positive and
   negative sctp_assoc_t are valid values).
 - a one-to-one socket has no association id
 - a peeled off socket will lose its association id (the file descriptor
   should be used for future reference), and the old id may be
   immediately re-used by a new one-to-many association.

In lksctp, it seems like one-to-one sockets have an association id 
anyway, which is equal to the file descriptor value, while in Solaris 
10 a random value is provided as association id in events on one-to-one 
sockets.

I would prefer if the API draft would specify that the OS must set the 
association id to zero in returned events for one-to-one sockets 
instead of allowing it to contain a random value like in Solaris 10, or 
something that might be usable like in lksctp. This will make the API 
safer (=bugs in user code is easier detected).

When mixing one-to-many and one-to-one sockets there can often be a need 
to provide a single space of handles for associations to upper layers 
within the application. Handles which work for both one-to-many sockets 
and one-to-one sockets, and does not change at peeloff. This is a bit 
of a pain, since file descriptor values can collide with association id 
values, and association id is lost at peeloff. But I don't think there 
is much one can do about it. Virtual handles unrelated to file 
descriptors and sctp_assoc_t combined with a lookup table is necessary 
for that.

I had an idea that one could define rules for sctp_assoc_t such that 
valid one-to-many association ids would be outside the range of valid 
file descriptors, and give one-to-one sockets an association id equal 
to the file descriptor value, and that way provide a single handle 
space without the need for virtual handles and lookup tables in 
user-space. However, it breaks with peeloff, since then the association 
id would have to change. Therefore my suggestion is simply to clarify 
what the current rules are.

/Anders Torger

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

---

From: Sridhar Samudrala <[email-masked]>
Date: Wed, 11 May 2005 14:38:19 -0700

I think sctp-impl is the right mailing list for SCTP implementation
specific discussions. So i am adding sctp-impl to the CC list.

I would like to clarify how associd is currently defined and 
implemented in linux SCTP(lksctp).
- sctp_assoc_t is defined as signed 32 bit value.
- The valid values of associd are 1-0x7fffffff.
- They don't have any relationship with file descriptors.
- All associations have a associd irrespective of whether they belong
  to 1-1 or 1-many style sockets.
- The associd will not change when the association is peeled-off to
  a different socket.

Thanks
Sridhar

---

From: Anders Torger <[email-masked]>
Date: Wed, 11 May 2005 23:58:23 +0200

Ok, but if I have understood the API draft correctly, it is not possible 
to get or access a one-to-one socket with an sctp_assoc_t, thus the 
association id would be hidden for the user.

It seems to me however, that in lksctp, the association id is indeed 
visible in (for example) notifications for one-to-one sockets, although 
it says in the API draft that the value should be "ignored". On Solaris 
10, a seemingly random value is delivered instead.

I would prefer the lksctp model, or that the value is set to zero. In 
any case, it is not clear how it should work in the API draft.

I also like the model where sctp_assoc_t is signed, and that only 
positive values are valid associations, in that way looking a bit like 
file descriptors, and making it possible to make functions that return 
sctp_assoc_t giving either a valid (>0), undefined (=0) or error (<0) 
as result.

It is also nice that the association id is kept at peeloff, avoiding 
that the id would be re-used by another one-to-many association before 
the original socket has closed. Also this is not specified how it 
should work in the API draft.

/Anders Torger

On Wednesday 11 May 2005 23.38, Sridhar Samudrala wrote:
> >One problem with sctp_assoc_t is that there is no clear definition
> > of what the values can be.
> >
> >The only thing I can find out from
> > draft-ietf-tsvwg-sctpsocket-10.txt is that zero is not a valid
> > value for an association, but any other value may be.
> >
> >It would be great if the API draft would specify some facts/rules
> > about sctp_assoc_t and association ID. I *think* this is true, and
> > I'd like that it was mentioned more clearly in the draft:
> >
> > - sctp_assoc_t is an integer of unspecified size and may be signed
> > or unsigned
> > - a peeled off socket will lose its association id (the file
> > descriptor should be used for future reference), and the old id may
> > be immediately re-used by a new one-to-many association.
> >
> >anyway, which is equal to the file descriptor value, while in
> > Solaris 10 a random value is provided as association id in events
> > on one-to-one sockets.
> >
> >I would prefer if the API draft would specify that the OS must set
> > the association id to zero in returned events for one-to-one
> > sockets instead of allowing it to contain a random value like in
> > Solaris 10, or something that might be usable like in lksctp. This
> > will make the API safer (=bugs in user code is easier detected).
> >
> >When mixing one-to-many and one-to-one sockets there can often be a
> > need to provide a single space of handles for associations to upper
> > layers within the application. Handles which work for both
> > one-to-many sockets and one-to-one sockets, and does not change at
> > peeloff. This is a bit of a pain, since file descriptor values can
> > collide with association id values, and association id is lost at
> > peeloff. But I don't think there is much one can do about it.
> > Virtual handles unrelated to file descriptors and sctp_assoc_t
> > combined with a lookup table is necessary for that.
> >
> >valid one-to-many association ids would be outside the range of
> > valid file descriptors, and give one-to-one sockets an association
> > id equal to the file descriptor value, and that way provide a
> > single handle space without the need for virtual handles and lookup
> > tables in user-space. However, it breaks with peeloff, since then
> > the association id would have to change. Therefore my suggestion is
> > simply to clarify what the current rules are.
> >
> >/Anders Torger
> >

---

From: Peter Lei <[email-masked]>
Date: Wed, 11 May 2005 17:20:41 -0500

> specific discussions. So i am adding sctp-impl to the CC list.

The following are also true for our BSD stack, except that
sctp_assoc_t is an unsigned, non-zero 32-bit value.

regards,
--peter

> I would like to clarify how associd is currently defined and implemented 
> in linux SCTP(lksctp).
>> The only thing I can find out from draft-ietf-tsvwg-sctpsocket-10.txt 
>> is that zero is not a valid value for an association, but any other 
>> value may be.
>>
>> about sctp_assoc_t and association ID. I *think* this is true, and I'd 
>> like that it was mentioned more clearly in the draft:
>>
>> 10 a random value is provided as association id in events on 
>> one-to-one sockets.
>>
>> instead of allowing it to contain a random value like in Solaris 10, 
>> or something that might be usable like in lksctp. This will make the 
>> API safer (=bugs in user code is easier detected).
>>
>> layers within the application. Handles which work for both one-to-many 
>> sockets and one-to-one sockets, and does not change at peeloff. This 
>> is a bit of a pain, since file descriptor values can collide with 
>> association id values, and association id is lost at peeloff. But I 
>> don't think there is much one can do about it. Virtual handles 
>> unrelated to file descriptors and sctp_assoc_t combined with a lookup 
>> table is necessary for that.
>>
>> user-space. However, it breaks with peeloff, since then the 
>> association id would have to change. Therefore my suggestion is simply 
>> to clarify what the current rules are.
>>
>> /Anders Torger
>>

---

From: Randall Stewart <[email-masked]>
Date: Thu, 12 May 2005 05:49:41 -0400

Anders:

I will also add a couple of items.. in addition to
what Peter said in his subsequent posting... this time
I read all the posts before replying :-D

So we have these true for BSD

  - The valid values of associd are 1-0xffffffff. (This is different)
--- And-----
  - Association id's are time-waited... this means that an associd
    will NOT be reused for 2 MSL's after the association has been
    terminated.
  - We do, currently, have an issue with assoc-id's that we need to
    discuss (has Kacheong mentioned earlier but I have been to busy
    to get to :-D) which is when an association restarts it will
    experience a associd change...  I won't go in to why, I will save
    it for the other thread :-D

> association id would be hidden for the user.

Unfortunately there are notes in the document that specify that
the assoc-id is ignored for 1-2-1.. but I think this restriction
should be removed. To me, it would make more sense from an
application point of view to be able to have an assoc-id
even on 1-2-1 sockets..

In order to get the association id of any assoc I have always
used the SCTP_PEER_ADDR_PARAMS with one of the assoc's addresses.
This then returns an assoic-id.. kind of a handy way to
translate the address ---> assoc_id :-)

> 10, a seemingly random value is delivered instead.
It would also be visiable in BSD as well.. in all cases we populate
this field... notifications, options etc...

> any case, it is not clear how it should work in the API draft.
It seems to me having the field is a good thing..

> sctp_assoc_t giving either a valid (>0), undefined (=0) or error (<0) 

Hmm.. I see your point... but this seg-way's in to how an implementation
uses the assoc-id... and so join me on the other thread to voice
your concerns (hopefully you are on the sctp-impl list)...

> should work in the API draft.
Hmm. yes maybe more specific info is needed... lets have the
other conversation and see where we end up at :-D

R

-- 
Randall Stewart
803-345-0369 <or> 815-342-5222(cell)