Subject: Re: [Tsvwg] Sockets API suggestion concerning sctp_assoc_t

From: Randall Stewart <[email-masked]>
Date: Fri, 03 Jun 2005 12:30:13 -0400

Kacheong Poon wrote:
> Randall Stewart wrote:
> 
>> 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..
> 
> 
> 
> I disagree (-:  The sctp_assoc_t was originally added because of
> performance reason for 1-N style socket.  1-1 style socket does not
> have this issue.  I don't see why we need to force 1-1 style
> socket to assign an assoc_id to the association the socket controls.
> In fact, an implementation may not even choose to support 1-N style
> socket.  Requiring it to have an extra assoc ID, which does not have
> any meaning conceptually, with a 1-1 style socket is not a good
> design.
> 
> 
> 
I strongly disagree with this.. Basically mixing the two
styles is the whole point of something like peel-off. And
having a uniform identifier is a good thing... so I the
app writer can setup one assoc-ID into a hash table.. for example
and then whenever I receive something.. no matter what FD it
comes in on.. I can hash to find my state machine or whatever
and then do my thing with the message...

We added it NOT because of performance.. but because you may
get a different socket address in each receive... and
I would think you may have the same issue in the tcp model
if you let the address go up the socket too...

The idea was along the lines of what Keith Moore is proposing
to do some research on.. some sort of identifier that can
be used to represent the peer during the association.. outside
of the socket address... Thats not performance... IMO

R

-- 
Randall Stewart
ITD - Cisco Systems Inc.
803-345-0369 <or> 815-342-5222 (cell)

---

From: Randall Stewart <[email-masked]>
Date: Fri, 03 Jun 2005 12:31:29 -0400

Kacheong Poon wrote:
> Anders Torger wrote:
> 
>> 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.
> 
> 
> 
> This is correct.  After all, an implementation may only support 1-1
> style socket.  And the type sctp_assoc_t may be defined as anything.
> 
> 
>> 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.
> 
> 
> 
> By zero, I presume that you are referring to something like
> SCTP_ASSOC_INVALID as suggested in my previous email.  As a
> caller should not use or even check the value of assoc_id field
> if the socket is 1-1 style, the value should not matter.  I
> guess initialization it to a value is a good idea.
> 
> 
>> 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.
> 
> 
> 
> By specifying this, we will unnecessarily restrict how an implementation
> handles an assoc ID.  After an association is peeled off from a 1-N
> style socket, it will be controlled under a 1-1 style socket.
> Logically, the two sockets are separate entity and do not need to share
> anything.  Requiring the original assoc ID not be used until the 1-1
> style socket is closed means that the two sockets are linked in a
> special (SCTP only) way.  I guess what we should specify is that after
> sctp_peeloff() is called, the caller should disassociate the association
> with the original assoc ID.
> 

Why.. no matter where the assocaition was peeled off from or is.. the
fact that it is association X should not change... I should be able
to recognize the receive came from X.. giving me one universal handle
I can use.

R

---

From: Kacheong Poon <[email-masked]>
Date: Mon, 06 Jun 2005 19:43:45 +0800

> styles is the whole point of something like peel-off. And

Randy, remember the dinner when sctp_peel_off() was introduced?
And remember the reason why sctp_peel_off() was introduced?
I don't remember what food I ordered, but I remember the
issue I raised with 1-N style socket and La Monte (not sure...)

> and then do my thing with the message...

But the socket API already has this in place, the socket
descriptor in 1-1 style SCTP socket.  An app writer can
use it to do exactly the above things.  The SCTP assoc_id
conceptually lives under a socket descriptor.  If we look at
this issue from a system perspective, it is really a bad design
to force the assoc_id to be on the same level as a socket
descriptor.  The reason is that a socket descriptor is in the
same class as other descriptors, file, pipe, ...  And all the
other components of the system treat these descriptors the
same way.  We cannot ask them to do the same thing to an SCTP
assoc_id.

I'd recommend an app writer who wants to use both 1-N and 1-1
style socket in the same app to find out the mechanism in the
target system on handling multiple clients waiting on multiple
objects.  I believe this is the major reason why an app writer
chooses the 1-N style socket.  There are existing mechanisms
to do this in most systems, say kqueue in FreeBSD, I/O Completion
Port in AIX, or Event Port in Solaris.  And those mechanisms can
operate on all descriptors, not just socket descriptors.

> get a different socket address in each receive... and

And what is the problem if each receive comes from a different
address (I am assuming "socket address" above means peer address)?
Performance problem (-:  Assuming that there is no assoc_id at
all.  An app knows all the peer addresses (if the socket API does
not allow this, we have a problem...) of an association.  So an
app can use the receive address and port to know exactly which
association a message is for.  The assoc_id is not needed.  Hey,
I am the person who was pushing the use of assoc_id for 1-N style

> if you let the address go up the socket too...

If an app uses the 1-1 style SCTP socket, there is already
a 1-1 mapping from a socket descriptor to an SCTP association.
There is no reason to have another one.  The additional one
serves no purpose in 1-1 style socket.  And there is no problem
in sending up the receive address for 1-1 style socket.

> of the socket address... Thats not performance... IMO

Is Keith Moore on the sctp-impl list?  I don't know what his
research is so I cannot comment.  But if an app uses 1-1 style
socket, there is already an unique identifier for each
association, the socket descriptor.  There is no need to use
IP address (again I am assuming that "socket address" above
means peer address).  If Keith is on the list, maybe he can
comment on what he is trying to do and people can suggest
different ways to do it.

-- 

						K. Poon.
						[email-masked]

---

From: Kacheong Poon <[email-masked]>
Date: Mon, 06 Jun 2005 19:54:45 +0800

> to recognize the receive came from X.. giving me one universal handle

Since the SCTP assoc_id lives logically under a socket descriptor,
after sctp_peel_off() is called, the SCTP assoc_id has no meaning
under the new socket descriptor.  Look at it another way.  Suppose
an app has two 1-N style sockets opened.  Each 1-N style socket
can have its own set of SCTP assoc_id space.  This means that the
same sctp_assoc_id X can be assigned under both 1-N style sockets.

Internally, the SCTP protocol control block of an SCTP association
does not change after sctp_peel_off().  The issue here is that the
socket layer is not the same as the SCTP layer, unless we are mixing
them together.  As long as we want to allow implementors to have
a clean separation of layers, we should not force an implementation
to keep the SCTP assoc_id of an association after sctp_peel_off()
is called.

-- 

						K. Poon.
						[email-masked]

---

From: Randall Stewart <[email-masked]>
Date: Mon, 06 Jun 2005 08:14:14 -0400

> proposed the sctp_peel_off() call.  The issue was performance (-:

So.. yes.., when I want to have a socket read directly by
some thread.. this made it so I could have a blocking
reader INSTEAD of a reader that must distribute... in
a threaded model that is...

But I don't want to have to force apps to associate
a bunch of socket id's to different associations...I would
rather let app writers have options... they can decide
what they want to use.. having one consistent thing
seems like a GOOD thing to me...
> conceptually lives under a socket descriptor.

So now if I peel something off I am tracking two different
things... this seems odd to me..

   If we look at
> same way.  We cannot ask them to do the same thing to an SCTP

I don't see it that way.. the socket lets me determine that
I need to read something.. after reading from a socket that
may or may not be enough information for an app writer
to determine what piece of code needs to be activiated.
It never can be conclusive since the association may
be talking about multiple things (especially when one
cosiders streams)... so even the assoc-id is not
going to always be conclusive.. it just gives another
tool that can be used to apportion the state in
the app.... and having a consistent one is a
good thing..

> I am the person who was pushing the use of assoc_id for 1-N style

I just don't like forcing an app writer to use two different
mechanisms.. what is wrong with having an association id that
is consistent... An app may or may not use it.. in fact
if I remember right this very discussion started because
an app writer WANTED to use the assoc-id in both
a mix of one-2-one and one-2-many styles.. since someone
wants to do this that should be a clue in itself...

It costs little to nothing, and it makes sense...
Doing otherwise seems to me to be a bad-design...

> comment on what he is trying to do and people can suggest

Its something that is not out yet... he is just beginning looking
into this...

aka the use of something else besides socket-addresses to identify
a peer... SCTP is on his list (but I don't think hes on this one :-D) 
and also HIP :-D

R

---

From: Randall Stewart <[email-masked]>
Date: Mon, 06 Jun 2005 08:23:08 -0400

> Since the SCTP assoc_id lives logically under a socket descriptor,

Are you not talking about your implementation here? Just because
you implemented in solaris so that an assoc-id is logically
"under" a socket descriptor does not necessarily represent
how it is implemented in other O/S's... thats just your interpretation.
Mine obviously is different (and maybe even Sridhar's as well
since Linux and BSD seem to behave similarly).

> under the new socket descriptor. 

In solaris .. maybe.. not in Linux and BSD...

  Look at it another way.  Suppose
> same sctp_assoc_id X can be assigned under both 1-N style sockets.

Not in BSD.. maybe in Solaris.. but not in BSD... I made it
universally unique and complete with aging.. so I could
address the assoc-id reuse issue.. I still have some things
to work out in it (aka restart) .. but it is unique across
the system for BSD.. and possibly linux?? Sridhar???

> to keep the SCTP assoc_id of an association after sctp_peel_off()

Just because I provide a unique identifier for the app does NOT
means I am mixing the layers... it just means I am providing
a service.. a uniq id per association..

R

---

From: Kacheong Poon <[email-masked]>
Date: Tue, 07 Jun 2005 00:43:44 +0800

> seems like a GOOD thing to me...

 From an application point of view, what is the difference
between a bunch of socket descriptors and a bunch of
SCTP assoc_id?  If an app wants to deal with multiple
associations at the same time, it has to deal with more
than one SCTP handles irregardless of the socket style the
app uses.  The issue we are talking here only happens when
an app tries to mix the two different socket styles.  And
this mixing happens because of performance issue....

I don't think it is a good thing to mix things in the
first place.  Anyway, the current socket draft does not
prevent an app to do this.  There is really nothing to fix
here.  Anders Torger already mentioned this.

> things... this seems odd to me..

An app writer does not need to do sctp_peel_off() for 1-1
style socket.  What I am trying to say is that if an app
writer really needs to do sctp_peel_off(), maybe the app
should not use 1-N style socket in the first place.  It
should use 1-1 style socket for all SCTP associations.
Then there is no issue at all.

> the app.... and having a consistent one is a

That's why we have stream id.  The way the draft is written
currently, we have a very consistent hierarchal view of SCTP
associations.  In the 1-1 style socket, a socket descriptor
represents an association.  Then under that association, there
can be multiple streams, which are represented by different
stream ids.  In the 1-N style socket, a socket descriptor
represents a bunch of associations.  And each association is
represented by an assoc_id.  Each stream in an association is
represented by a stream id.

The current proposal is to force 1-1 style socket to have
an SCTP assoc_id.  This breaks the above nice hierarchal view
and is not a good design choice.  What is the point of having
redundant representation of the same thing, association in
this case?

> Doing otherwise seems to me to be a bad-design...

Firstly, we are not forcing an app writer to use two different
mechanisms.  The app writer chooses to mix the two socket
styles, which IMHO is a bad thing.  OTOH, the current proposal
forces an SCTP socket API implementor to mix two logically
separated representations together and breaks the nice hierarchal
view mentioned above.

> a peer... SCTP is on his list (but I don't think hes on this one :-D) 

What is meant by "socket-addresses" above?  Outside a system,
a socket means nothing.  Within a system, a 1-1 style socket in
a process identifies a peer.

-- 

						K. Poon.
						[email-masked]

---

From: Sridhar Samudrala <[email-masked]>
Date: Mon, 06 Jun 2005 09:54:07 -0700

> the system for BSD.. and possibly linux?? Sridhar???

Yes, In linux implementation also. the associd's are unique across the 
system
and they do not change when an association is peeled off.

But i think it is OK for an implementation to have a per-socket associd 
spaces
for 1-N style sockets  as all the SCTP APIs do need a socket descriptor to
identify an association.

Thanks
Sridhar

---

From: Kacheong Poon <[email-masked]>
Date: Tue, 07 Jun 2005 01:11:21 +0800

> since Linux and BSD seem to behave similarly).

Note that I always try to separate implementation and the
specification.  Randy's BSD implementation is correct under
the current specification.  But this does not mean that the
specification forces that all implementations have to follow
the same way.  This is the good point of the current draft (-:

But I should note that the whole draft is centered on the
single concept, a socket.  This is the socket API after all (-:
We never mention more than one socket in each of the calls,
except for sctp_peel_off().  If you ask me, it is obvious that
sctp_assoc_id logically lives under a socket.

If we get rid of sctp_peel_off(), I guess everyone will be

> the system for BSD.. and possibly linux?? Sridhar???

Note that aging is not required to handle the assoc_id reuse
issue as explained in the draft.

> a service.. a uniq id per association..

The SCTP protocol control block address (assuming an in kernel
implementation) uniquely identifies an association.  I guess this
is true for all kernel SCTP implementations (-:  I am not saying
that the BSD impl uses that (I don't know as I have never looked
at the code).  What I am trying to say is that having such an
identifier is not necessary for the API to work.

-- 

						K. Poon.
						[email-masked]

---

From: Kacheong Poon <[email-masked]>
Date: Thu, 09 Jun 2005 23:22:09 +0800

Anders Torger wrote:

> In the same way, when I see undefined values in structs and similar, as 
> for SCTP assoc_id in some situations in Solaris, I think this is 
> 'wierdnix', returning a confusing value or produce strange behaviour 
> and when someone complains say "ha! it says *may* in the standard". A 
> tighter standard would avoid such things.

I have already fixed this issue in Solaris' 1-1 style socket.  It is
now always 0 in all notifications.

> However, it is mostly a matter of taste, and I'm just expressing my 
> humble opinion -- rather make it easy for API users than overly 
> flexible API implementors.

Note that this is not about flexibility.  The sctp_assoc_id is
defined for 1-N style socket.  If an implementation chooses to
support only 1-1 style socket, there is really no point of
having the sctp_assoc_id at all.  It is a bad design of the spec
if it requires 1-1 style socket to have sctp_assoc_id defined
uniquely for each socket...

> The standard answer for those that do not want to change is "it *is* 
> easy to use, it is just your code that sucks" (with a slightly 
> different wording), but I think that in most cases it is rather easy to 
> come to a settlement of what behaviour that really is the easier for 
> the API user. However, if a current 'less-easy' behaviour is "good 
> enough" or not is indeed a matter of opinion.
> 
> My opinion is that the current Linux/BSD use of assoc id is indeed 
> simpler than the one in Solaris, and I think it is worth making the 
> standard specify assoc id behaviour in more detail to secure consistent 
> and easy-to-use behaviour on all platforms.

I don't have a problem requiring the sctp_assoc_id to be filled
in with a fixed value, say 0, for 1-1 style socket.  But requiring
each 1-1 style socket to have an unique sctp_assoc_id is bad.  I
guess the whole issue comes from sctp_peel_off().  As I said, I
strongly recommend app writer not to mix the two different SCTP
socket styles.  If an app really needs 1-1 style socket, it may as
well just use 1-1 style socket only.  It can do all the things 1-N
style can do.

-- 

						K. Poon.
						[email-masked]

---

From: Randall Stewart <[email-masked]>
Date: Thu, 09 Jun 2005 17:24:39 -0400

> and easy-to-use behaviour on all platforms.

Anders:

I agree with you completely.. but I have one comment and then
a summary:

First the comment.. we are not making a standard here.. the socket-api
will be, when finished, an informational RFC.. so its NOT a standard.
To get it to be a standard I think it would have to be sent to
POSIX or one of those types of orgs :-D

Now So far I have seen:

Against having assoc-id for one-2-one style:

Kacheong Poon

For having one-2-one style have an assoc-id

Anders Toger
Qiaobing Xie
Shridhar (I am assuming here since he implemented it that way)
Peter Lei (same assumption above)
Randall Stewart

---------------------------------

Others that have NOT voiced an opinion.. please do so.. For
those that  I may have mis-interpreted.. speak up and
say so..

At the "end" of the voting process we will change the
document one way or another..

R

---

From: Randall Stewart <[email-masked]>
Date: Thu, 09 Jun 2005 17:29:50 -0400

Ahh.. I bounced too. by NOT including external.cisco.com..

So never mind.. but I do want this to post so here
it is :-D

R

Randall Stewart wrote:
> Anders:
> 
> Not sure why this bounced.. I aplogize... and if
> you off-line forward a copy to me (of the bounce) I
> will take it up with IT..
> 
> 
> 
> Anders Torger wrote:
> 
>> (my mails to sctp-impl is bouncing)
>>
>> On Thursday 09 June 2005 17.22, you wrote:
>>
>> There is one point as I see it - porting of code is simpler. Sure, it 
>> may be strange to use assoc id instead of fd for 1-1 sockets, but I 
>> don't think the API should decide that for the user. Requiring the API 
>> to provide an association id regardless of the type of socket is nice 
>> clean design, I think. Should the implementation only support 1-1 
>> sockets, the sctp_assoc_id could for example simply be equal to the 
>> file descriptor of the socket, so it is easy to provide.
>>
> 
> I whole heartedly AGREE with you.. it IS good design in my mind :-D
> 
>> So I guess I humbly disagree - but you are the standard authors, not me.
> 
> 
> I too am one of the "standards" authors (even though this is
> an informational RFC.. not a standard).. and so is Qiaobing, and
> I believe that two out of the five authors agree with you..
> 
> I, as yet, have not heard from La Monte OR Michael Tuexen... Please
> co-authors at least speak up on the list.. and other
> opinions are also welcome  please :-D
> 
> R
> 
>>
>>
>>> I guess the whole issue comes from sctp_peel_off().  As I said, I
>> Yes, sctp_peeloff() complicates things, (probably *a lot* in the 
>> implementation) but I do think it is an important function. In the 
>> application I work on it is highly desirable - a server with 
>> potentially thousands of clients, so 1-N sockets are useful for that, 
>> but among those clients, there are some long-term which require good 
>> flow control, and thus these are peeled off to a 1-1 socket.
>> /Anders Torger
>>
> 
>

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 9 Jun 2005 15:27:04 -0600

Randall,

I am against having assoc-id for 1:1 style sockets.

--brian

> Against having assoc-id for one-2-one style:

Brian Bidulock

-- 
Brian F. G. Bidulock    ¦ The reasonable man adapts himself to the ¦
[email-masked]    ¦ world; the unreasonable one persists in  ¦
http://www.openss7.org/ ¦ trying  to adapt the  world  to himself. ¦
                        ¦ Therefore  all  progress  depends on the ¦
                        ¦ unreasonable man. -- George Bernard Shaw ¦

---

From: "Peter Lei (peterlei)" <[email-masked]>
Date: Thu, 09 Jun 2005 16:32:35 -0500

Randall Stewart wrote:
>> standard specify assoc id behaviour in more detail to secure
>> consistent and easy-to-use behaviour on all platforms.
> 
> 
> Anders:
> 

No assumption needed... :-)  All assocs in our implementations
have a unique assoc_id no matter what programming model is used,
and that is my preference as well.

regards,
--peter

---

From: "Peter Lei (peterlei)" <[email-masked]>
Date: Thu, 09 Jun 2005 16:33:50 -0500

regards,
--peter

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 9 Jun 2005 16:58:27 -0600

Anders,

Because it is a sockets interface and the 1:1 model is closest to
the current POSIX standards.

IMO the 1:N model is a new API, separate from sockets, and bears no
resemblance to any standard. (Why can you not use poll(2)?)

I do not agree with pushing a non-standard element onto a
standards(-based) interface.  But then, I also do not subscribe to
the sockets-draft model at all (primarily because the 1:1 model
deviates unnecessarily from the POSIX standard).  IMO, requiring
assoc-id would push the 1:1 model farther from the POSIX standard.

It is my opinion, for what it's worth.

BTW, if you want a look at a different approach, see:

  http://www.openss7.org/man/man2html?7+sctp

--brian

On Fri, 10 Jun 2005, Anders Torger wrote:

> I'm just curious, do you have a reason why?
> 
> I think I forgot to mention one of the stronger reason why assoc-id 
> should be present for both 1:1 and 1:N sockets. Actually, the initial 
> discussion from my point of view was about whether assoc-id should be 
> undefined or set to zero, but I realize that it would be considerably 
> better to require that assoc-id is present and valid, as Randall 
> suggests.
> 
> In our application, we had the same code for handling notification 
> events for 1:1 sockets and 1:N sockets, since we haven't read the 
> drafts for the informational RFC (I shall try not saying 
> 'standard' :-)) all that good, and just went along with what worked. 
> This was on Linux. However, when the code was compiled for Solaris, it 
> broke, because assoc ids where undefined for 1:1 sockets, and thus we 
> had to make two separate cases in the code for 1:1 sockets and 1:N 
> sockets, where the code previously was shared. Not good.
> 
> I don't think that "one generally shouldn't mix 1:1 and 1:N sockets in 
> the same application" is a strong enough argument for *not* providing a 
> valid assoc id. And I don't see how this feature would severly 
> complicate the internal design of the API implementation.
> 
> /Anders Torger

---

From: Sridhar Samudrala <[email-masked]>
Date: Thu, 09 Jun 2005 18:00:25 -0700

> Shridhar (I am assuming here since he implemented it that way)

I have implemented it this way, but i don't see a need to make it a 
requirement for
an implementation to have associd for 1-1 style sockets.  It should be 
OK for a
1-1 style association to have an associd of 0.
If we change our implementation to have per socket associd space, then 
it would
be simpler to make associd as 0 for all 1-1 style sockets. Otherwise, 
when we do a
peeloff,  we have to release the old associd and assign a new one.

Thanks
Sridhar

---

From: Randall Stewart <[email-masked]>
Date: Fri, 10 Jun 2005 08:13:56 -0400

> peeloff,  we have to release the old associd and assign a new one.

An informational RFC cannot make ANY MUST or Requirments.. its
only that.. informational. So no matter which we pick.. its never
a requirement..

R

---

From: Randall Stewart <[email-masked]>
Date: Mon, 13 Jun 2005 18:03:48 -0400

Brian:

Just a thought on this objection...

> assoc-id would push the 1:1 model farther from the POSIX standard.

I don't get how having an assoc-id available to a 1:1 style
socket pushes it into anything... the reason being that
if you do nothing you CANNOT get an assoc-id. In order
to get such a critter you MUST go in and use
sctp_recvmsg after setting up events (data i/o) so
you can get the sndrcvinfo structure.

As to socket options, I don't see that a 1:1 model requires
an assoc-id even though one exists.. I know the BSD code does
not pay attention to the assoc-id when setting/getting options..
so if its there.. its ignored...

All that having such a thing does is to allow a uniform
method of viewing all of your associations for those few
apps that actually go to the trouble to turn on the assoc-id
in the events and use the extend calls..

Overall.. since you must do something extra .. I don't see
how this changing anything in POSIX...

R

---

From: Kacheong Poon <[email-masked]>
Date: Tue, 14 Jun 2005 23:34:28 +0800

Replying to Anders' bounced email to sctp-impl.

Anders Torger wrote:

> clean design, I think. 

I think we should look at things from both sides.  The API provides
a specified service to an application.  An app can make use of it
in the specified way.  It is not like the API is trying to decide
how an app should be written.  For example, a system provides the
memcpy() call.  An app can decide to use it or to have its own
version of memcpy().  The system provided API does not decide
what an app should use.

> Should the implementation only support 1-1 

I don't think redundancy is a good thing.  BTW, a socket descriptor
is not unique in a system.  If an app does assume the semantics of
sctp_assoc_t in the current KAME BSD SCTP code, it will simply break
in a stack which duplicates the socket descriptor in the sctp_assoc_t
field.  And if later on the implementers of that stack want to add
1-N style socket, it will also break code because some apps may have
already assumed that the sctp_assoc_t field in 1-1 style socket is
equal to the socket descriptor.

I don't know if Anders is on the sctp-impl list or not.  I have pointed
out the current consistent hierarchical view of SCTP association using
socket and sctp_assoc_t.  Duplicating an sctp_assoc_t in 1-1 style
socket just breaks the consistent view.  And it does not add any
information to the 1-1 style socket user.  It is not a clean design.

> flow control, and thus these are peeled off to a 1-1 socket. 

If your app does want to use 1-1 style socket, I recommend to just
use it instead of mixing the two styles.  If there is a feature which
the 1-1 style socket does not have, please bring it up.  Or if there
is an issue of using 1-1 style socket, please also bring it up to
the list.  There are existing app which handles thousands of TCP
clients using socket.  I believe the same thing can be done for SCTP
with 1-1 style socket.

-- 

						K. Poon.
						[email-masked]

---

From: Kacheong Poon <[email-masked]>
Date: Tue, 14 Jun 2005 23:43:25 +0800

> For having one-2-one style have an assoc-id

I think Qiaobing's concern is if the draft is not clear, it may
affect portability.  I believe he is OK with one way or the
other as long as it is clear.  This means that using a fixed
constant in the sctp_assoc_t field for 1-1 style socket
notification should be OK.

Qiaobing, please speak up in case I have misinterpreted you.

> document one way or another..

What I hope is we can reach a rough consensus.  "Voting" is
not really a good way to handle things in a mailing list.  What
qualifies a "vote?"  Instead of spending time deciding that,
I hope we can reach a consensus and move on.  Whatever the
change, I also hope that it won't break existing running apps.

-- 

						K. Poon.
						[email-masked]

---

From: Kacheong Poon <[email-masked]>
Date: Tue, 14 Jun 2005 23:54:13 +0800

> better to require that assoc-id is present and valid, as Randall 

If SCTP_INVALID_AID, probably 0 in all impls, is used in the
sctp_assoc_t field of 1-1 style socket notification, is it
still a problem?

> sockets, where the code previously was shared. Not good.

I think as long as sctp_assoc_t is defined in 1-1 style socket,
your code should work in both 1-1 and 1-N style socket with a
simple if statement.  Isn't this true?

> complicate the internal design of the API implementation.

IMHO, it is not a clean design to duplicate information in an
API.  For example, if the open() call returns two handles which
point to the same thing to the caller, do you think that it is
a bad design?

-- 

						K. Poon.
						[email-masked]

---

From: Kacheong Poon <[email-masked]>
Date: Wed, 15 Jun 2005 00:03:10 +0800

> so if its there.. its ignored...

This is exactly why sctp_assoc_t is simply redundant info
for 1-1 style socket.  Why do you still want a 1-1 style
socket implementation to have an unique sctp_assoc_t field
in the notification?

> in the events and use the extend calls..

The current draft has a uniform way of providing handles to
SCTP association in both 1-1 and 1-N style socket.  There
is no inconsistency.  The only catch is that it just specifies
that the sctp_assoc_t field should be ignored in 1-1 style
socket.  It may be better to define SCTP_INVALID_AID and
use it to fill in the sctp_assoc_t field.

-- 

						K. Poon.
						[email-masked]