Subject: Re: [Tsvwg] Event Notifications

From: Kacheong Poon <[email-masked]>
Date: Thu, 26 Feb 2009 17:23:54 +0800

Randy Stewart wrote:

> Michael so what you are proposing is that we:
> 
> 1) Keep the existing SCTP_EVENT's socket call.
> 
> 2) Add a new SCTP_SPECIFIC_EVENT socket call which takes a
>    sctp_assoc_value structure. Where the assoc-id is the
>    assoc you want the notification on. And the value is the
>    Notification id. We would type all current notifications
>    with constants e.g. SCTP_DRY_NOTIFICATION

FWIW, my original thinking was to have SCTP level socket options
like SCTP_EVENT_SEND_DRY_STATUS and the option value is struct
sctp_assoc_value.  So for each event, there is a corresponding
status option.  This is similar to other existing socket options,
SO_REUSEADDR, SO_BROADCAST, ...

> 3) I think we would want 0 to be again, future associations
>    and non-zero to be specific associations.
> 
> 
> Now this would also mean that the existing SCTP_EVENT's would have
> a slight change, which I think is ok. It would now be a short cut
> equivalent to call 9 or so individual SCTP_SPECIFIC_EVENT with
> the assoc-id set to 0. I.e. it would ONLY effect future assoc's.

This brings up a good point.  I think we need to be clear here.
For options which we've defined to use assoc_id explicitly, I
think the above 0 mean future is OK.  This is something new.
But for options, such as SO_RCVBUF, I guess the expected semantics
is to affect all associations under the control of a 1-N socket.
I believe this is how options like SO_RCVBUF on a SCTP socket is
implemented.  For SO_RCVBUF, I guess this is true in both cases
when every associations has its own buffer or all the associations
share the same buffer.

Following this thinking, the SCTP_EVENTS option should affect
all the associations under the control of a 1-N socket.  And I
guess this is what is implied in the current draft.  So I think
changing its semantics to match the individual event status
option is not a good idea.

And because of this, we may need to think about if it makes sense
to extend the meaning on the use of assoc_id in those options.  As
defined currently, 0 assoc_id means future associations.  There is
no way to apply those options to all existing associations under
a 1-N socket.  In sending, we have the SCTP_SENDALL flag to do
something like this.  I'm not sure if this is really needed.  But
it is something to consider.

-- 

						K. Poon.
						[email-masked]

---

From: Randy Stewart <[email-masked]>
Date: Thu, 26 Feb 2009 07:22:01 -0500

> SO_REUSEADDR, SO_BROADCAST, ...

Ok, so let me see. Are you advocating using specific
events with an sctp_assoc_value structure... I am find
with that. We would then just create a new socket option
for EACH event. Which I like better than creating another
structure. The only alternative I could think of would
be to "enhance" the sctp_assoc_value to be

struct sctp_assoc_value {
    sctp_assoc_t assoc_id;
    union {
          uint32_t val32;
          uint16_t val16[2];
          uint8_t  vall8[4];
    }
};

Which may pose for some an ABI issue so it might not be palatable. Now
in thinking about this we probably SHOULD have defined the structure
that way anyway to provide utmost flexibility.. but of course thats
water under the bridge.

Your way works and does not venture us down the path of changing the
sctp_assoc_value structure.. probably the best way...

> when every associations has its own buffer or all the associations

I don't think changing the SO_RCVBUF has a way of specifying
a assoc_id... so this is logical. If you cannot specify
a assoc, then its a global setting over the whole 1-M socket.
However if you are allowed to specify an assoc_id, then 0 is
for all future assoc (i.e. you are setting the default for
future associations) and setting the assoc-id specifies who
you want the option set on.

I think its important we specify this behavior, if we don't
already do so.

> option is not a good idea.

This is probably true. Since it does not give you the option
to specify an assoc-id then it definitely implies that you
have a setting on all assocs. This will be a bit more code
to implement.. but that is no big deal. Probably maintaining
current semantics is best :-)

> it is something to consider.

True. So if we go the route of having options that take an
assoc/value structure for each event, and future new event.
Then we would in effect make the original events be able to
be specified with the EVENTS option on all existing assoc's
but future events (if any our defined) would not gain that
ability.. I don't think this is a big deal. As I said
most programs set this stuff up at the beginning and do
not change it.

The sender_dry_event is a special case deal for DTLS.. so I
think we can probably live with this..

So are we all in agreement we should do as Kacheong specifies here..  
i.e.
add the

SCTP_SENDER_DRY_EVENT
...
SCTP_XXXX_EVENT

all taking a sctp_assoc_value structure?

I will agree to this Vlad, Michael, Others?? comments??

R

-----
Randall Stewart
[email-masked]

---

From: Michael Tüxen <[email-masked]>
Date: Thu, 26 Feb 2009 14:26:28 +0100

> for EACH event. Which I like better than creating another
This sounds like a good idea.
> struct sctp_assoc_value {
I suggest to keep the old structure and use for the
socket options being discussed only whether the assoc_value
is 0 or not.
> sctp_assoc_value structure.. probably the best way...
I vote for Kacheongs method.

---

From: Vlad Yasevich <[email-masked]>
Date: Thu, 26 Feb 2009 08:49:57 -0500

> most programs set this stuff up at the beginning and do

I am not sure I really like the inconsistency.  What we are saying
here is that SCTP_EVENTS socket option can completely
overwrite a singular SCTP_EVENT option, which is supposed to
be more specific that the per socket SCTP_EVENTS.

I think that the new SCTP_EVENT socket option with association id of 0
should have the same semantics as SCTP_EVENTS option (which does't take
association id).  I think that creates a much clearer API.  After all,
what really started this was the ability to set a per-association event
mask.

So, I think that the new SCTP_EVENT with an association id of 0 should
modify all associations that currently belong to the given socket.

> So are we all in agreement we should do as Kacheong specifies here.. i.e.
> add the
> 
> SCTP_SENDER_DRY_EVENT
> ...
> SCTP_XXXX_EVENT
> 

I am fine with having a separate socket option per event.

-vlad

---

From: Randy Stewart <[email-masked]>
Date: Thu, 26 Feb 2009 15:29:34 -0500

Works for me :-)

R

-----
Randall Stewart
[email-masked]

---

From: Kacheong Poon <[email-masked]>
Date: Fri, 27 Feb 2009 17:56:52 +0800

> be more specific that the per socket SCTP_EVENTS.

If we are going to have separate option per event, I guess the
SCTP_EVENTS will be obsoleted.  So I think they, SCTP_EVENTS
and the per event options, won't be used at the same time in a
new program.  So from the programming point of view, I think
this is OK.  But I guess this is not your point.

> modify all associations that currently belong to the given socket.

Understood.  But then we also need to be consistent with other
options which use assoc_id 0 to mean future associations.  I
think it is more important to use assoc_id 0 consistently than
to provide the same functionality as the current SCTP_EVENTS.
But if possible, I also think that we need to explore the
ability to set options for all associations under 1-N socket.
One possible solution to make things consistent (assoc_id 0
means the same thing for every options) and provide the
aforementioned ability is to make assoc_id 0 mean all and future
associations.  Is there another option?  If not, do we want
to make this change?

-- 

						K. Poon.
						[email-masked]

---

From: Michael Tüxen <[email-masked]>
Date: Fri, 27 Feb 2009 11:14:03 +0100

> SCTP_EVENTS will be obsoleted.  So I think they, SCTP_EVENTS
I hope so. We can even put text in the ID to make this clear.
> to provide the same functionality as the current SCTP_EVENTS.
I agree completely. assoc_id 0 should mean future assocs.
> associations.  Is there another option?  If not, do we want
What about abstracting from 0?
We could use something like
#define SCTP_FUTURE_ASSOCIATIONS 0
#define SCTP_FUTURE_AND_CURRENT_ASSOCIATIONS 0xffffffff
or whatever constants you want. The type is sctp_associd_t
anyway.
This even improves readability of the code...

---

From: Kacheong Poon <[email-masked]>
Date: Fri, 27 Feb 2009 18:24:49 +0800

> #define SCTP_FUTURE_AND_CURRENT_ASSOCIATIONS 0xffffffff

SCTP_ALL_ASSOC?

> This even improves readability of the code...

I guess this is OK for most stacks, as I don't think there
can be that many associations at the same time.  Making it
one less is fine.

-- 

						K. Poon.
						[email-masked]

---

From: Randy Stewart <[email-masked]>
Date: Fri, 27 Feb 2009 05:26:32 -0500

> associations.  Is there another option?  If not, do we want

I am not sure your question here Kacheong, are you asking
if there are other options that 0 means future assocs?

The answer is yes, I can go dig them out if you want...

In general we have always done  0 == future assoc where
an assoc id was given.

I also agree with you that the two things will be not often
used together. However I can see the utility of doing

SCTP_EVENTS option at the beginning of my program.. and then
say do

SCTP_SENDER_DRY_EVENTS on A association... then turn it back off.

This saves me adding multiple socket calls if there are several
I want to turn on all at once.

I can also see the point Vlad is making.. there is no option
IMO that this would apply to, but I can build a scenario for
a situation that mixing the two could be confusing...

Suppose I do what I would normally do

SCTP_EVENTS(...) on all the options I want at the beginning
of a program. Then later I specifically pick another specific
event and turn it on.

If I then later for some reason call SCTP_EVENTS() I could by
accident turn off the option I just turned on.

I think this is an unlikely scenario ... I think here is how we  
resolve it.

1) We specify that SCTP_EVENTS is obsoleted and discourage use.
2) We specify that if you are using SCTP_EVENTS you should only
    do so BEFORE associations are are established (at the beginning
    of your program after the socket call).
3) We specify that if you do use SCTP_EVENTS later on then the behavior
    is unspecified as to if it effects future assoc OR also ones already
    in progress.
4) We recommend using the specific EVENTS (described in a separate  
section) going
    forward.

Now as for me. Here is how I will implement it since it makes sense to
me this way.

A) XXX_EVENT will turn on/off per association or if == 0 future  
associations.
B) SCTP_EVENTS will work, but if done someplace else in the middle of  
the
    program it will only effect future associations.

I feel this is much more consistent in how the API works even if its a  
slight
tweak to SCTP_EVENTS...

R

-----
Randall Stewart
[email-masked]

---

From: Randy Stewart <[email-masked]>
Date: Fri, 27 Feb 2009 05:28:53 -0500

> This even improves readability of the code...

I guess I would be fine with that except for one issue I have.
0xffffffff can be an association id (at least in BSD). Yes I know
its unlikely.. but this means I need to take yet another exception
and remove it when generating asoc-id's.. Hmm come to think of this
it does not matter anymore.. We changed all that so that
we no longer correlate the assoc-id and the vtag..

So yeah, this works for me..

Lets do it that way..

R

-----
Randall Stewart
[email-masked]

---

From: Randy Stewart <[email-masked]>
Date: Fri, 27 Feb 2009 05:31:52 -0500

I am happy with this.. so we now only allow
4billion -2

I think that is safely big enough... but if we ever really
run in to a situation where it is not.. there is an easy way here.

Just like time_t is a type on its own... what BSD did
is in 32 bit machines time_t == 32 bits and on
64 bit machines time_t == 64 bits.

We could follow that pattern when folks want more than 4billion-2 assoc
on a socket.. i.e. you need to be on a 64 bit machine so assoc_id's just
move to 64 bit values... (I won't hold my breath for that to happen
either :-D)

R

-----
Randall Stewart
[email-masked]

---

From: Michael Tüxen <[email-masked]>
Date: Fri, 27 Feb 2009 11:39:10 +0100

>> #define SCTP_FUTURE_AND_CURRENT_ASSOCIATIONS 0xffffffff
I do not care that much about the name...
So you are suggesting SCTP_ALL_ASSOC and SCTP_FUTURE_ASSOC?

---

From: Kacheong Poon <[email-masked]>
Date: Fri, 27 Feb 2009 18:39:34 +0800

>    is unspecified as to if it effects future assoc OR also ones already

I'd like to keep the existing semantics of SCTP_EVENTS, which
means all and future so existing apps will have no problem.
And there should be no restriction on when it can be called,
as specified in the current draft.

-- 

						K. Poon.
						[email-masked]

---

From: Michael Tüxen <[email-masked]>
Date: Fri, 27 Feb 2009 11:41:49 +0100

> as specified in the current draft.
I agree. Maybe we should add a note that this socket options
will be obsoleted in the future?

---

From: Kacheong Poon <[email-masked]>
Date: Fri, 27 Feb 2009 18:45:38 +0800

> So you are suggesting SCTP_ALL_ASSOC and SCTP_FUTURE_ASSOC?

They are fine.

-- 

						K. Poon.
						[email-masked]

---

From: Vlad Yasevich <[email-masked]>
Date: Fri, 27 Feb 2009 16:12:30 -0500

>> So you are suggesting SCTP_ALL_ASSOC and SCTP_FUTURE_ASSOC?

Fine with me as well.

-vlad

---

From: Vlad Yasevich <[email-masked]>
Date: Fri, 27 Feb 2009 16:15:42 -0500

> will be obsoleted in the future?

That certain seems like where we are going with this.  I am fine
if this option is obsoleted/deprecated and we can warn people.
Once that's done, anyone using the old option in combination with
the new is doing so at their own risk.

I just thought to bring up this possibility to make sure it was
addressed.

Thanks
-vlad

---

From: Chris Benson <[email-masked]>
Date: Fri, 27 Feb 2009 13:28:34 -0800 (PST)

Vlad (and Kacheong and Michael),

> [...] suggesting SCTP_ALL_ASSOC and SCTP_FUTURE_ASSOC

Please pluralize the macro names though ...

    SCTP_ALL_ASSOCS and SCTP_FUTURE_ASSOCS

:-D

Chris Benson, Adax inc.

On Fri, 27 Feb 2009, Vlad Yasevich wrote:

>>  Date: Fri, 27 Feb 2009 16:12:30 -0500
>>  From: Vlad Yasevich <[email-masked]>
>>  To: Kacheong Poon <[email-masked]>
>>  Cc: Michael T?xen <[email-masked]>,
>>      tsvwg <[email-masked]>, Randy Stewart <[email-masked]>
>>  Subject: Re: [Tsvwg] Event Notifications
>>  
>>  > 

From: =?ISO-8859-1?Q?Michael_T=FCxen?= <[email-masked]>
To: tsvwg <[email-masked]>
Date: Thu, 5 Feb 2009 12:40:17 +0100
Cc: Robin Seggelmann <[email-masked]>
Subject: [Tsvwg] DTLS interop server available on interop.fh-muenster.de

Dear all,

Robin and myself have setup an DTLS interop server at
interop.fh-muenster.de (195.37.125.98).

It runs an echo and discard server for DTLS/UDP and
DTLS/SCTP.

The DTLS implementation use is the one from OpenSSL with
Robins bug fixes available at
http://sctp.fh-muenster.de

If you have comments, questions, found bugs or anything else
related to the above interop testing, please send an e-mail to
[email-masked] or [email-masked].

Best regards
Michael

Date: Thu, 05 Feb 2009 06:32:31 -0800
From: Caitlin Bestler <[email-masked]>
To: Transport WG <[email-masked]>
Subject: [Tsvwg] draft-ietf-sctpsocket-18: sinfo_context and successful sendmsg

This is a repost - the original went astray.
--------------------------------------------

In the current draft the sinfo_context is only specified to be
returned "back to the upper layer if an error occurs" [page 25].

RDMA interfaces typically have an option where transmit requests
will generate an explicit completion even if the operation completes
successfully.

When iWARP is implemented over SCTP sockets it would be useful to
have an option where the sinfo_context would be returned for a
specific SCTP message even when no error occurs. I would propose
that an additional sendmsg() flag be defined for this option.
The same completion mechanism as used for errors could be used,
just with a "no error" error code.

From: [email-masked]
To: [email-masked]
Date: Mon,  9 Feb 2009 07:15:01 -0800 (PST)
Cc: [email-masked]
Subject: [Tsvwg] I-D Action:draft-ietf-tsvwg-emergency-rsvp-10.txt

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Transport Area Working Group Working Group of the IETF.

	Title           : Resource ReSerVation Protovol (RSVP) Extensions for Emergency Services
	Author(s)       : F. Le Faucheur, et al.
	Filename        : draft-ietf-tsvwg-emergency-rsvp-10.txt
	Pages           : 37
	Date            : 2009-02-09

An Emergency Telecommunications Service (ETS) requires the ability to
provide an elevated probability of session establishment to an
authorized user in times of network congestion (typically, during a
crisis).  When supported over the Internet Protocol suite, this may
be facilitated through a network layer admission control solution,
which supports prioritized access to resources (e.g., bandwidth).
These resources may be explicitly set aside for emergency services,
or they may be shared with other sessions.

This document specifies extensions to the Resource reSerVation
Protocol (RSVP) that can be used to support such an admission
priority capability at the network layer.  Note that these extensions
represent one possible solution component in satisfying ETS
requirements.  Other solution components, or other solutions, are
outside the scope of this document.

The mechanisms defined in this document are applicable to controlled
environments formed by either a single administrative domain or a set
of administrative domains that closely coordinate their network
policy and network design.  The mechanisms defined in this document
can be used for a session whose path spans over such a controlled
environment in order to elevate the session establishment probability
through the controlled environment (thereby elevating the end to end
session establishment probability).

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-emergency-rsvp-10.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Message/External-body;
	name="draft-ietf-tsvwg-emergency-rsvp-10.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <[email-masked]>

--NextPart--

From: [email-masked]
To: [email-masked]
Date: Mon, 16 Feb 2009 06:15:01 -0800 (PST)
Cc: [email-masked]
Subject: [Tsvwg] I-D Action:draft-ietf-tsvwg-sctpsocket-19.txt

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Transport Area Working Group Working Group of the IETF.

	Title           : Sockets API Extensions for Stream Control Transmission Protocol (SCTP)
	Author(s)       : R. Stewart, et al.
	Filename        : draft-ietf-tsvwg-sctpsocket-19.txt
	Pages           : 87
	Date            : 2009-02-16

This document describes a mapping of the Stream Control Transmission
Protocol SCTP into a sockets API.  The benefits of this mapping
include compatibility for TCP applications, access to new SCTP
features and a consolidated error and event notification scheme.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-sctpsocket-19.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Message/External-body;
	name="draft-ietf-tsvwg-sctpsocket-19.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <[email-masked]>

--NextPart--

From: [email-masked]
To: [email-masked]
Date: Wed, 18 Feb 2009 11:15:02 -0800 (PST)
Cc: [email-masked]
Subject: [Tsvwg] I-D Action:draft-ietf-tsvwg-emergency-rsvp-11.txt

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Transport Area Working Group Working Group of the IETF.

	Title           : Resource ReSerVation Protocol (RSVP) Extensions for Emergency Services
	Author(s)       : F. Le Faucheur, et al.
	Filename        : draft-ietf-tsvwg-emergency-rsvp-11.txt
	Pages           : 37
	Date            : 2009-02-18

An Emergency Telecommunications Service (ETS) requires the ability to
provide an elevated probability of session establishment to an
authorized user in times of network congestion (typically, during a
crisis).  When supported over the Internet Protocol suite, this may
be facilitated through a network layer admission control solution,
which supports prioritized access to resources (e.g., bandwidth).
These resources may be explicitly set aside for emergency services,
or they may be shared with other sessions.

This document specifies extensions to the Resource reSerVation
Protocol (RSVP) that can be used to support such an admission
priority capability at the network layer.  Note that these extensions
represent one possible solution component in satisfying ETS
requirements.  Other solution components, or other solutions, are
outside the scope of this document.

The mechanisms defined in this document are applicable to controlled
environments.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-emergency-rsvp-11.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Message/External-body;
	name="draft-ietf-tsvwg-emergency-rsvp-11.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <[email-masked]>

--NextPart--

Date: Mon, 23 Feb 2009 16:05:34 -0500
From: Vlad Yasevich <[email-masked]>
To: Michael Tuexen <[email-masked]>,  Randall Stewart <[email-masked]>, Kacheong Poon <[email-masked]>
Cc: tsvwg <[email-masked]>
Subject: [Tsvwg] EXPLICIT_EOR api

Hi All

I've recently been asked about SCTP_EXPLICIT_EOF support on linux.
After re-rereading the spec, I realized that the text is rather sparse.

The first question that came to mind was whether this should be limited
to 1-1 sockets (as it appears to be), or should it also be available
for 1-many sockets?  If the later, the API needs to change to include
the association id.

The other thing is that we need to explain the limitation of this
option wrt. to multi-streaming.  I've had to explain to a few users
already this limitation and it considerable changed their plans.

Additionally,  since there is no signaling mechanism that lets a peer
know that this API is in use, there needs to some guidance here as well.
As it stands right now,  when the sender uses this option, the receiver
needs to reset its partial deliver point so that data gets delivered instead
of waiting to be fully reassembled, which may be a very long time.

-vlad

From: Randy Stewart <[email-masked]>
To: Vlad Yasevich <[email-masked]>
Date: Tue, 24 Feb 2009 04:37:21 -0500
Cc: Michael Tuexen <[email-masked]>, Kacheong Poon <[email-masked]>, tsvwg <[email-masked]>
Subject: Re: [Tsvwg] EXPLICIT_EOR api

On Feb 23, 2009, at 4:05 PM, Vlad Yasevich wrote:

> Hi All
>
> I've recently been asked about SCTP_EXPLICIT_EOF support on linux.
> After re-rereading the spec, I realized that the text is rather  
> sparse.
>
> The first question that came to mind was whether this should be  
> limited
> to 1-1 sockets (as it appears to be), or should it also be available
> for 1-many sockets?  If the later, the API needs to change to include
> the association id.

Hmm if you get that impression it is INCORRECT. the explicit EOR mode
should work no matter if you are one-2-one or one-2-many.

If you are on a 1-2-m socket then once you do a EOR mode on
that assoc whenever you write to that one association, until
you explicitly say "EOR" you are sending to that same stream. In
fact the BSD implementation will give you an error if you try
to change the stream number. So for example I could do

socketopt(12msd, set EOR mode, assoc1);
send("msgpart1", assoc1, stream-1);
send("mspart2", assoc1, stream-1)
send("entire msg", assoc2, stream-8);
send("mspart3", assoc1, stream-1);

If I tried
send ("msgforanotherstream", assoc1, stream-5); // ERRROR return

Until I finally do

send ("msgfinalpart", assoc1, stream-1, "EEOR");

Now once this last one is done I can send again to some
other stream

send ("newmsg", assoc1, stream-N);

For that matter I could send just like EEOR mode was off if I did:

send ("newmsg", assoc1, stream-N, "EEOR");

I should have lots of time after March 4th to look at the i-d I will
see if I can't tighten up the wording a bit :-)

>
>
> The other thing is that we need to explain the limitation of this
> option wrt. to multi-streaming.  I've had to explain to a few users
> already this limitation and it considerable changed their plans.

Yes, it needs to stated explicitly if you start sending to stream-x
until you do EOR you must send to stream-x... at least thats
the way I envisioned it. If you will until you indicate EEOR
the connection becomes no different than a TCP connection... i.e.
a stream of bytes. Hmm.. I wonder if we could lift this restriction..
I will have to think about that...

>
>
> Additionally,  since there is no signaling mechanism that lets a peer
> know that this API is in use, there needs to some guidance here as  
> well.
> As it stands right now,  when the sender uses this option, the  
> receiver
> needs to reset its partial deliver point so that data gets delivered  
> instead
> of waiting to be fully reassembled, which may be a very long time.

Yep, the only reasonable way to use this is to set the PD-API point to  
1. This
way you will not be stuck waiting for data without being aware of it :-)

I am sure we need to add a bit of text here :-)

R

-----
Randall Stewart
[email-masked]

Date: Tue, 24 Feb 2009 08:24:12 -0500
From: Vlad Yasevich <[email-masked]>
To: Randy Stewart <[email-masked]>
Cc: Michael Tuexen <[email-masked]>, Kacheong Poon <[email-masked]>, tsvwg <[email-masked]>
Subject: Re: [Tsvwg] EXPLICIT_EOR api

Randy Stewart wrote:
> 
> On Feb 23, 2009, at 4:05 PM, Vlad Yasevich wrote:
> 
>> Hi All
>>
>> I've recently been asked about SCTP_EXPLICIT_EOF support on linux.
>> After re-rereading the spec, I realized that the text is rather sparse.
>>
>> The first question that came to mind was whether this should be limited
>> to 1-1 sockets (as it appears to be), or should it also be available
>> for 1-many sockets?  If the later, the API needs to change to include
>> the association id.
> 
> Hmm if you get that impression it is INCORRECT. the explicit EOR mode
> should work no matter if you are one-2-one or one-2-many.

I get this "impression" because the is no way to turn on explicit EOR on
an association.  The interface doesn't allow one to pass the association
id to the kernel.  Thus, it's really a per-socket value, meaning that every
association on a 1-many socket would use explicit EOR mode.  If we want
to offer full support for 1-many api, we need change the option api to
be able to take association id, just like most other API already specified.

> 
> If you are on a 1-2-m socket then once you do a EOR mode on
> that assoc whenever you write to that one association, until
> you explicitly say "EOR" you are sending to that same stream. In
> fact the BSD implementation will give you an error if you try
> to change the stream number. So for example I could do
> 
> socketopt(12msd, set EOR mode, assoc1);

But you can't with the api.  Generic setsockopt doesn't take assoc id.

Thanks
-vlad

> send("msgpart1", assoc1, stream-1);
> send("mspart2", assoc1, stream-1)
> send("entire msg", assoc2, stream-8);
> send("mspart3", assoc1, stream-1);
> 
> If I tried
> send ("msgforanotherstream", assoc1, stream-5); // ERRROR return
> 
> Until I finally do
> 
> send ("msgfinalpart", assoc1, stream-1, "EEOR");
> 
> Now once this last one is done I can send again to some
> other stream
> 
> send ("newmsg", assoc1, stream-N);
> 
> For that matter I could send just like EEOR mode was off if I did:
> 
> send ("newmsg", assoc1, stream-N, "EEOR");
> 
> I should have lots of time after March 4th to look at the i-d I will
> see if I can't tighten up the wording a bit :-)
> 
>>
>>
>> The other thing is that we need to explain the limitation of this
>> option wrt. to multi-streaming.  I've had to explain to a few users
>> already this limitation and it considerable changed their plans.
> 
> Yes, it needs to stated explicitly if you start sending to stream-x
> until you do EOR you must send to stream-x... at least thats
> the way I envisioned it. If you will until you indicate EEOR
> the connection becomes no different than a TCP connection... i.e.
> a stream of bytes. Hmm.. I wonder if we could lift this restriction..
> I will have to think about that...
> 
>>
>>
>> Additionally,  since there is no signaling mechanism that lets a peer
>> know that this API is in use, there needs to some guidance here as well.
>> As it stands right now,  when the sender uses this option, the receiver
>> needs to reset its partial deliver point so that data gets delivered
>> instead
>> of waiting to be fully reassembled, which may be a very long time.
> 
> Yep, the only reasonable way to use this is to set the PD-API point to
> 1. This
> way you will not be stuck waiting for data without being aware of it :-)
> 
> I am sure we need to add a bit of text here :-)
> 
> R
> 
>>
>>
>> -vlad
>>
>>
>>
> 
> -----
> Randall Stewart
> [email-masked]
> 
> 
> 
> 

Date: Tue, 24 Feb 2009 13:29:45 -0500
From: Vlad Yasevich <[email-masked]>
To: =?ISO-8859-1?Q?Michael_T=FCxen?= <[email-masked]>
Cc: Kacheong Poon <[email-masked]>, tsvwg <[email-masked]>, Randy Stewart <[email-masked]>
Subject: Re: [Tsvwg] EXPLICIT_EOR api

Michael Tüxen wrote:
> Hi Vlad,
> 
> comments in-line.
> 
> Best regards
> Michael
> 
> On Feb 24, 2009, at 2:24 PM, Vlad Yasevich wrote:
> 
>> Randy Stewart wrote:
>>>
>>> On Feb 23, 2009, at 4:05 PM, Vlad Yasevich wrote:
>>>
>>>> Hi All
>>>>
>>>> I've recently been asked about SCTP_EXPLICIT_EOF support on linux.
>>>> After re-rereading the spec, I realized that the text is rather sparse.
>>>>
>>>> The first question that came to mind was whether this should be limited
>>>> to 1-1 sockets (as it appears to be), or should it also be available
>>>> for 1-many sockets?  If the later, the API needs to change to include
>>>> the association id.
>>>
>>> Hmm if you get that impression it is INCORRECT. the explicit EOR mode
>>> should work no matter if you are one-2-one or one-2-many.
>>
>> I get this "impression" because the is no way to turn on explicit EOR on
>> an association.  The interface doesn't allow one to pass the association
>> id to the kernel.  Thus, it's really a per-socket value, meaning that
>> every
>> association on a 1-many socket would use explicit EOR mode.  If we want
>> to offer full support for 1-many api, we need change the option api to
>> be able to take association id, just like most other API already
>> specified.
> We could use
> 
>      uint32_t assoc_value;
> instead of an int and use assoc_value to enable/disable if we want
> to be able to control this on a per association base, which makes sense
> for me.
> Kacheong, what do you think?

Hi Michael

That would work.  If assoc_id is set to 0, option applies to socket
and future associations.

>>
>>>
>>> If you are on a 1-2-m socket then once you do a EOR mode on
>>> that assoc whenever you write to that one association, until
>>> you explicitly say "EOR" you are sending to that same stream. In
>>> fact the BSD implementation will give you an error if you try
>>> to change the stream number. So for example I could do
>>>
>>> socketopt(12msd, set EOR mode, assoc1);
>>
>> But you can't with the api.  Generic setsockopt doesn't take assoc id.
> Correct. We can't do this for socket options. And we can't enable
> notifications on a per association base. Should we change that too?

Hmm..  That's an interesting question.  Is it a possible scenario where
an application decides to change event subscription of an association after
it's established?  I can't see a reason right now, but that doesn't mean it
doesn't exist.

On the other hand, I see an application wanting to temporarily enable EEOR,
to transfer a very large message, and then turn EEOR off again.  It's simple
on the 1-1 socket, but on a 1-many you can change the setting for a single
association without peeling it off.

Thanks
-vlad

>>
>>
>> Thanks
>> -vlad
>>
>>> send("msgpart1", assoc1, stream-1);
>>> send("mspart2", assoc1, stream-1)
>>> send("entire msg", assoc2, stream-8);
>>> send("mspart3", assoc1, stream-1);
>>>
>>> If I tried
>>> send ("msgforanotherstream", assoc1, stream-5); // ERRROR return
>>>
>>> Until I finally do
>>>
>>> send ("msgfinalpart", assoc1, stream-1, "EEOR");
>>>
>>> Now once this last one is done I can send again to some
>>> other stream
>>>
>>> send ("newmsg", assoc1, stream-N);
>>>
>>> For that matter I could send just like EEOR mode was off if I did:
>>>
>>> send ("newmsg", assoc1, stream-N, "EEOR");
>>>
>>> I should have lots of time after March 4th to look at the i-d I will
>>> see if I can't tighten up the wording a bit :-)
>>>
>>>>
>>>>
>>>> The other thing is that we need to explain the limitation of this
>>>> option wrt. to multi-streaming.  I've had to explain to a few users
>>>> already this limitation and it considerable changed their plans.
>>>
>>> Yes, it needs to stated explicitly if you start sending to stream-x
>>> until you do EOR you must send to stream-x... at least thats
>>> the way I envisioned it. If you will until you indicate EEOR
>>> the connection becomes no different than a TCP connection... i.e.
>>> a stream of bytes. Hmm.. I wonder if we could lift this restriction..
>>> I will have to think about that...
>>>
>>>>
>>>>
>>>> Additionally,  since there is no signaling mechanism that lets a peer
>>>> know that this API is in use, there needs to some guidance here as
>>>> well.
>>>> As it stands right now,  when the sender uses this option, the receiver
>>>> needs to reset its partial deliver point so that data gets delivered
>>>> instead
>>>> of waiting to be fully reassembled, which may be a very long time.
>>>
>>> Yep, the only reasonable way to use this is to set the PD-API point to
>>> 1. This
>>> way you will not be stuck waiting for data without being aware of it :-)
>>>
>>> I am sure we need to add a bit of text here :-)
>>>
>>> R
>>>
>>>>
>>>>
>>>> -vlad
>>>>
>>>>
>>>>
>>>
>>> -----
>>> Randall Stewart
>>> [email-masked]
>>>
>>>
>>>
>>>
>>
>>
> 

Date: Wed, 25 Feb 2009 11:33:25 +0800
From: Kacheong Poon <[email-masked]>
Organization: Sun Microsystems, Inc.
To: Vlad Yasevich <[email-masked]>
Cc: =?ISO-8859-1?Q?Michael_T=FCxen?= <[email-masked]>, tsvwg <[email-masked]>, Randy Stewart <[email-masked]>
Subject: Re: [Tsvwg] EXPLICIT_EOR api

...
>> We could use
>>      uint32_t assoc_value;
>> instead of an int and use assoc_value to enable/disable if we want
>> to be able to control this on a per association base, which makes sense
>> for me.
>> Kacheong, what do you think?
> 
> Hi Michael
> 
> That would work.  If assoc_id is set to 0, option applies to socket
> and future associations.

This is fine.

>> Correct. We can't do this for socket options. And we can't enable
>> notifications on a per association base. Should we change that too?
> 
> Hmm..  That's an interesting question.  Is it a possible scenario where
> an application decides to change event subscription of an association after
> it's established?  I can't see a reason right now, but that doesn't mean it
> doesn't exist.

I am also not sure if it is worthwhile to do that.

-- 

						K. Poon.
						[email-masked]

Date: Wed, 25 Feb 2009 11:46:50 +0800
From: Kacheong Poon <[email-masked]>
Organization: Sun Microsystems, Inc.
To: =?ISO-8859-1?Q?Michael_T=FCxen?= <[email-masked]>
Cc: Vlad Yasevich <[email-masked]>, tsvwg <[email-masked]>, Randy Stewart <[email-masked]>
Subject: Re: [Tsvwg] EXPLICIT_EOR api

Michael Tüxen wrote:
> On Feb 24, 2009, at 7:29 PM, Vlad Yasevich wrote:
...
>> Hmm..  That's an interesting question.  Is it a possible scenario where
>> an application decides to change event subscription of an association 
>> after
>> it's established?  I can't see a reason right now, but that doesn't 
>> mean it
>> doesn't exist.
> We do this for the DRY event since we are only interested in it
> during some specific states in DTLS (during renegotiations).

If we want to explore this, I'd suggest we retire (just keep
it there for backward compatibility) the sctp_event_subscribe.
It is not extensible.  Just use sctp_assoc_value.  An app can
subscribe/unsubscribe each event one by one.

BTW, I guess it should not cause a problem if the DRY event is
enabled for all associations controlled by one socket all the
time.

-- 

						K. Poon.
						[email-masked]

From: Randy Stewart <[email-masked]>
To: Kacheong Poon <[email-masked]>
Date: Wed, 25 Feb 2009 03:23:10 -0500
Cc: Vlad Yasevich <[email-masked]>, =?ISO-8859-1?Q?Michael_T=FCxen?= <[email-masked]>, tsvwg <[email-masked]>
Subject: Re: [Tsvwg] EXPLICIT_EOR api

On Feb 24, 2009, at 10:33 PM, Kacheong Poon wrote:

>> Michael T=FCxen wrote:
>>> We could use
>>>     uint32_t assoc_value;
>>> instead of an int and use assoc_value to enable/disable if we want
>>> to be able to control this on a per association base, which makes =20=

>>> sense
>>> for me.
>>> Kacheong, what do you think?
>> Hi Michael
>> That would work.  If assoc_id is set to 0, option applies to socket
>> and future associations.
>
>
> This is fine.

Yeah, I agree here.. and I had missed the fact that
I forgot to add on/off EOR mode for per assoc... good catch
lets add this (and I will fix my code too :-D)

>
>
>
>>> Correct. We can't do this for socket options. And we can't enable
>>> notifications on a per association base. Should we change that too?
>> Hmm..  That's an interesting question.  Is it a possible scenario =20
>> where
>> an application decides to change event subscription of an =20
>> association after
>> it's established?  I can't see a reason right now, but that doesn't =20=

>> mean it
>> doesn't exist.
>
>
> I am also not sure if it is worthwhile to do that.

I agree here too.. I don't see the value in notifications on a per
assoc basis...

R
> --=20

-----
Randall Stewart
[email-masked]

From: Randy Stewart <[email-masked]>
To: Kacheong Poon <[email-masked]>
Date: Wed, 25 Feb 2009 03:32:44 -0500
Cc: Vlad Yasevich <[email-masked]>, =?ISO-8859-1?Q?Michael_T=FCxen?= <[email-masked]>, tsvwg <[email-masked]>
Subject: Re: [Tsvwg] EXPLICIT_EOR api

On Feb 24, 2009, at 10:46 PM, Kacheong Poon wrote:

> Michael T=FCxen wrote:
>> On Feb 24, 2009, at 7:29 PM, Vlad Yasevich wrote:
> ...
>>> Hmm..  That's an interesting question.  Is it a possible scenario =20=

>>> where
>>> an application decides to change event subscription of an =20
>>> association after
>>> it's established?  I can't see a reason right now, but that =20
>>> doesn't mean it
>>> doesn't exist.
>> We do this for the DRY event since we are only interested in it
>> during some specific states in DTLS (during renegotiations).
>
>
> If we want to explore this, I'd suggest we retire (just keep
> it there for backward compatibility) the sctp_event_subscribe.
> It is not extensible.  Just use sctp_assoc_value.  An app can
> subscribe/unsubscribe each event one by one.
>
> BTW, I guess it should not cause a problem if the DRY event is
> enabled for all associations controlled by one socket all the
> time.
>

Hmm so let me summarize what I think we have agreed to so far

1) We will add support for using the sctp_assoc_value structure
    to turn on/off EEOR mode on a per assoc basis.
2) If the value of the assoc is 0, then the entire socket (1-2many or =20=

1-1) is
    set to EEOR mode this includes future and all existing sockets.

On the events... I am not convinced a per-assoc subscription is
needed. Going to Michael's sender-dry for DTLS.. even on a 1-to-many
socket .. you know if you are sending and can turn it off as soon
as the dry-event occurs. If you get a dry event on another
association, you can pretty easily ignore it. It might be nice
to have per-association on/off of some events. But I am mixed
on how useful that is.

I do agree with Kacheong here though, if we have to go this route we
need a new structure.. i.e. one that includes an assoc id.. and then
do the thing that says if the assoc-id=3D=3D0 its to future associations
or the entire socket... vs just changing a single association. I would
also think we want to make it more extensible and as Kacheong said
just retire the old SCTP_EVENTS... i.e. support for backward =20
compatibility
but move to the new structure for future things..

But again, is this really worth it? I am not convinced it is yet..

R

> --=20

-----
Randall Stewart
[email-masked]

From: =?ISO-8859-1?Q?Michael_T=FCxen?= <[email-masked]>
To: Randy Stewart <[email-masked]>
Date: Wed, 25 Feb 2009 10:35:40 +0100
Cc: Vlad Yasevich <[email-masked]>, Kacheong Poon <[email-masked]>, tsvwg <[email-masked]>
Subject: Re: [Tsvwg] EXPLICIT_EOR api

On Feb 25, 2009, at 9:32 AM, Randy Stewart wrote:

>
> On Feb 24, 2009, at 10:46 PM, Kacheong Poon wrote:
>
>> Michael T=FCxen wrote:
>>> On Feb 24, 2009, at 7:29 PM, Vlad Yasevich wrote:
>> ...
>>>> Hmm..  That's an interesting question.  Is it a possible scenario =20=

>>>> where
>>>> an application decides to change event subscription of an =20
>>>> association after
>>>> it's established?  I can't see a reason right now, but that =20
>>>> doesn't mean it
>>>> doesn't exist.
>>> We do this for the DRY event since we are only interested in it
>>> during some specific states in DTLS (during renegotiations).
>>
>>
>> If we want to explore this, I'd suggest we retire (just keep
>> it there for backward compatibility) the sctp_event_subscribe.
>> It is not extensible.  Just use sctp_assoc_value.  An app can
>> subscribe/unsubscribe each event one by one.
>>
>> BTW, I guess it should not cause a problem if the DRY event is
>> enabled for all associations controlled by one socket all the
>> time.
>>
>
> Hmm so let me summarize what I think we have agreed to so far
>
> 1) We will add support for using the sctp_assoc_value structure
>   to turn on/off EEOR mode on a per assoc basis.
> 2) If the value of the assoc is 0, then the entire socket (1-2many =20
> or 1-1) is
>   set to EEOR mode this includes future and all existing sockets.
>
>
> On the events... I am not convinced a per-assoc subscription is
> needed. Going to Michael's sender-dry for DTLS.. even on a 1-to-many
> socket .. you know if you are sending and can turn it off as soon
> as the dry-event occurs. If you get a dry event on another
> association, you can pretty easily ignore it. It might be nice
> to have per-association on/off of some events. But I am mixed
> on how useful that is.
>
> I do agree with Kacheong here though, if we have to go this route we
> need a new structure.. i.e. one that includes an assoc id.. and then
> do the thing that says if the assoc-id=3D=3D0 its to future =
associations
> or the entire socket... vs just changing a single association. I would
> also think we want to make it more extensible and as Kacheong said
> just retire the old SCTP_EVENTS... i.e. support for backward =20
> compatibility
> but move to the new structure for future things..
>
> But again, is this really worth it? I am not convinced it is yet..
There are two points here specific to the DRY event:

1. Performance: I might be interested only in the events for one
    particular association, but I get them for all. Of course I
    can ignore them for all associations I'm not interested in,
    but this means the kernel is going to generate a lot of =20
notifications
    I'm not interested in. This is just waisted cycles and mbufs.

2. The DRY event is generated when it is enabled and the the association
    is dry.  So assume I have N associations (being dry), I'm interested
    in one. Now I enable it. The kernel has to generate N notifications
    instantly. This might be a resource problem (on Mac OS X I ran into
    it), because you need N mbufs at about the same time. There is also
    no "flow control" for notifications.
    That is why I implemented this currently only for 1-to-1 style =20
sockets.

But I think we should be more future proof here.
I like Kacheongs idea to use the assoc_value structs:
1. This allows it to control it on an association base. No limitation
    here.
2. It can be used with any future notification. It is just adding a
    new constant, not changing a structure which might break ABI =20
compatibility.
3. It is simple.

I think we should add this.
>> --=20

From: Randy Stewart <[email-masked]>
To: Randy Stewart <[email-masked]>
Date: Wed, 25 Feb 2009 06:27:06 -0500
Cc: Vlad Yasevich <[email-masked]>, =?ISO-8859-1?Q?Michael_T=FCxen?= <[email-masked]>, Kacheong Poon <[email-masked]>, tsvwg <[email-masked]>
Subject: Re: [Tsvwg] EXPLICIT_EOR api

Let me reply to myself :-)

Since I had no coffee when I wrote this (never
answer email at 3am when you first wakeup without coffee :-D):

>
>
> Hmm so let me summarize what I think we have agreed to so far
>
> 1) We will add support for using the sctp_assoc_value structure
>   to turn on/off EEOR mode on a per assoc basis.
> 2) If the value of the assoc is 0, then the entire socket (1-2many  
> or 1-1) is
>   set to EEOR mode this includes future and all existing sockets.
>
>

I think the above needs to be reworded.. to be consistent with what
we do in the rest of the api:

1) We will add support for using the sctp_assoc_value structure
    to turn on/off EEOR mode on a per assoc basis.

This is fine ;-)

but 2 should be:

2) if the value of the assoc is 0, then all FUTURE sockets only
    are setup to be EEOR mode. Not existing assoc's..

I realized this AM that we are pretty consistent that when we
do an assoc-id ==0  on some setting then the change only
effects "future" assoc's.

I will reply separately on the sender-dry event since this is a separate
thread I think. Lets keep the two things separate please :-)

R
-----
Randall Stewart
[email-masked]

From: Randy Stewart <[email-masked]>
To: =?ISO-8859-1?Q?Michael_T=FCxen?= <[email-masked]>
Date: Wed, 25 Feb 2009 06:34:47 -0500
Cc: Vlad Yasevich <[email-masked]>, Kacheong Poon <[email-masked]>, tsvwg <[email-masked]>
Subject: Re: [Tsvwg] Event Notifications

On Feb 25, 2009, at 4:35 AM, Michael T=FCxen wrote:

> On Feb 25, 2009, at 9:32 AM, Randy Stewart wrote:
>
>>
>> On Feb 24, 2009, at 10:46 PM, Kacheong Poon wrote:
>>
>>> Michael T=FCxen wrote:
>>>> On Feb 24, 2009, at 7:29 PM, Vlad Yasevich wrote:
>>> ...
>>>>> Hmm..  That's an interesting question.  Is it a possible =20
>>>>> scenario where
>>>>> an application decides to change event subscription of an =20
>>>>> association after
>>>>> it's established?  I can't see a reason right now, but that =20
>>>>> doesn't mean it
>>>>> doesn't exist.
>>>> We do this for the DRY event since we are only interested in it
>>>> during some specific states in DTLS (during renegotiations).
>>>
>>>
>>> If we want to explore this, I'd suggest we retire (just keep
>>> it there for backward compatibility) the sctp_event_subscribe.
>>> It is not extensible.  Just use sctp_assoc_value.  An app can
>>> subscribe/unsubscribe each event one by one.
>>>
>>> BTW, I guess it should not cause a problem if the DRY event is
>>> enabled for all associations controlled by one socket all the
>>> time.
>>>
>>
>> Hmm so let me summarize what I think we have agreed to so far
>>
>> 1) We will add support for using the sctp_assoc_value structure
>>  to turn on/off EEOR mode on a per assoc basis.
>> 2) If the value of the assoc is 0, then the entire socket (1-2many =20=

>> or 1-1) is
>>  set to EEOR mode this includes future and all existing sockets.
>>
>>
>> On the events... I am not convinced a per-assoc subscription is
>> needed. Going to Michael's sender-dry for DTLS.. even on a 1-to-many
>> socket .. you know if you are sending and can turn it off as soon
>> as the dry-event occurs. If you get a dry event on another
>> association, you can pretty easily ignore it. It might be nice
>> to have per-association on/off of some events. But I am mixed
>> on how useful that is.
>>
>> I do agree with Kacheong here though, if we have to go this route we
>> need a new structure.. i.e. one that includes an assoc id.. and then
>> do the thing that says if the assoc-id=3D=3D0 its to future =
associations
>> or the entire socket... vs just changing a single association. I =20
>> would
>> also think we want to make it more extensible and as Kacheong said
>> just retire the old SCTP_EVENTS... i.e. support for backward =20
>> compatibility
>> but move to the new structure for future things..
>>
>> But again, is this really worth it? I am not convinced it is yet..
> There are two points here specific to the DRY event:
>
> 1. Performance: I might be interested only in the events for one
>   particular association, but I get them for all. Of course I
>   can ignore them for all associations I'm not interested in,
>   but this means the kernel is going to generate a lot of =20
> notifications
>   I'm not interested in. This is just waisted cycles and mbufs.
>
> 2. The DRY event is generated when it is enabled and the the =20
> association
>   is dry.  So assume I have N associations (being dry), I'm interested
>   in one. Now I enable it. The kernel has to generate N notifications
>   instantly. This might be a resource problem (on Mac OS X I ran into
>   it), because you need N mbufs at about the same time. There is also
>   no "flow control" for notifications.
>   That is why I implemented this currently only for 1-to-1 style =20
> sockets.
>
> But I think we should be more future proof here.
> I like Kacheongs idea to use the assoc_value structs:
> 1. This allows it to control it on an association base. No limitation
>   here.
> 2. It can be used with any future notification. It is just adding a
>   new constant, not changing a structure which might break ABI =20
> compatibility.
> 3. It is simple.
>
> I think we should add this.

This is a subtle difference but one we should document well. I think
its ok, since most folks using the SCTP_EVENT's do not change
things in the middle. They basically open a socket, set the events
they may want... and then never touch it again.

I do agree this would then add a nice extensible mechanism to add
future events as well.

As long as Kacheong and Vlad are ok with this I am too... I can see
it will at least be useful for the sender-dry-event. Not sure about
other ones but you never know.

Kacheong, Vlad, -- thoughts.. if you agree I will start making
changes in BSD and the ID..

R

-----
Randall Stewart
[email-masked]

From: =?ISO-8859-1?Q?Michael_T=FCxen?= <[email-masked]>
To: Randy Stewart <[email-masked]>
Date: Wed, 25 Feb 2009 12:54:39 +0100
Cc: Vlad Yasevich <[email-masked]>, Kacheong Poon <[email-masked]>, tsvwg <[email-masked]>
Subject: Re: [Tsvwg] Event Notifications

On Feb 25, 2009, at 12:34 PM, Randy Stewart wrote:

>
> On Feb 25, 2009, at 4:35 AM, Michael T=FCxen wrote:
>
>> On Feb 25, 2009, at 9:32 AM, Randy Stewart wrote:
>>
>>>
>>> On Feb 24, 2009, at 10:46 PM, Kacheong Poon wrote:
>>>
>>>> Michael T=FCxen wrote:
>>>>> On Feb 24, 2009, at 7:29 PM, Vlad Yasevich wrote:
>>>> ...
>>>>>> Hmm..  That's an interesting question.  Is it a possible =20
>>>>>> scenario where
>>>>>> an application decides to change event subscription of an =20
>>>>>> association after
>>>>>> it's established?  I can't see a reason right now, but that =20
>>>>>> doesn't mean it
>>>>>> doesn't exist.
>>>>> We do this for the DRY event since we are only interested in it
>>>>> during some specific states in DTLS (during renegotiations).
>>>>
>>>>
>>>> If we want to explore this, I'd suggest we retire (just keep
>>>> it there for backward compatibility) the sctp_event_subscribe.
>>>> It is not extensible.  Just use sctp_assoc_value.  An app can
>>>> subscribe/unsubscribe each event one by one.
>>>>
>>>> BTW, I guess it should not cause a problem if the DRY event is
>>>> enabled for all associations controlled by one socket all the
>>>> time.
>>>>
>>>
>>> Hmm so let me summarize what I think we have agreed to so far
>>>
>>> 1) We will add support for using the sctp_assoc_value structure
>>> to turn on/off EEOR mode on a per assoc basis.
>>> 2) If the value of the assoc is 0, then the entire socket (1-2many =20=

>>> or 1-1) is
>>> set to EEOR mode this includes future and all existing sockets.
>>>
>>>
>>> On the events... I am not convinced a per-assoc subscription is
>>> needed. Going to Michael's sender-dry for DTLS.. even on a 1-to-many
>>> socket .. you know if you are sending and can turn it off as soon
>>> as the dry-event occurs. If you get a dry event on another
>>> association, you can pretty easily ignore it. It might be nice
>>> to have per-association on/off of some events. But I am mixed
>>> on how useful that is.
>>>
>>> I do agree with Kacheong here though, if we have to go this route we
>>> need a new structure.. i.e. one that includes an assoc id.. and then
>>> do the thing that says if the assoc-id=3D=3D0 its to future =
associations
>>> or the entire socket... vs just changing a single association. I =20
>>> would
>>> also think we want to make it more extensible and as Kacheong said
>>> just retire the old SCTP_EVENTS... i.e. support for backward =20
>>> compatibility
>>> but move to the new structure for future things..
>>>
>>> But again, is this really worth it? I am not convinced it is yet..
>> There are two points here specific to the DRY event:
>>
>> 1. Performance: I might be interested only in the events for one
>>  particular association, but I get them for all. Of course I
>>  can ignore them for all associations I'm not interested in,
>>  but this means the kernel is going to generate a lot of =20
>> notifications
>>  I'm not interested in. This is just waisted cycles and mbufs.
>>
>> 2. The DRY event is generated when it is enabled and the the =20
>> association
>>  is dry.  So assume I have N associations (being dry), I'm interested
>>  in one. Now I enable it. The kernel has to generate N notifications
>>  instantly. This might be a resource problem (on Mac OS X I ran into
>>  it), because you need N mbufs at about the same time. There is also
>>  no "flow control" for notifications.
>>  That is why I implemented this currently only for 1-to-1 style =20
>> sockets.
>>
>> But I think we should be more future proof here.
>> I like Kacheongs idea to use the assoc_value structs:
>> 1. This allows it to control it on an association base. No limitation
>>  here.
>> 2. It can be used with any future notification. It is just adding a
>>  new constant, not changing a structure which might break ABI =20
>> compatibility.
>> 3. It is simple.
>>
>> I think we should add this.
>
>
The socket option is called SCTP_EVENTS. I suggest to keep it.
>   with constants e.g. SCTP_DRY_NOTIFICATION
What about SCTP_EVENT (no S, so singular)? This would use
struct sctp_assoc_value.
>   and non-zero to be specific associations.
Correct. And ignore for 1-to-1 style sockets.
> a slight change, which I think is ok. It would now be a short cut
Why do you want to change that? I would suggest to keep it at it is.
> This is a subtle difference but one we should document well. I think
> its ok, since most folks using the SCTP_EVENT's do not change
> things in the middle. They basically open a socket, set the events
> they may want... and then never touch it again.
>
> I do agree this would then add a nice extensible mechanism to add
> future events as well.
>
> As long as Kacheong and Vlad are ok with this I am too... I can see
> it will at least be useful for the sender-dry-event. Not sure about
> other ones but you never know.
>
> Kacheong, Vlad, -- thoughts.. if you agree I will start making
> changes in BSD and the ID..
>
> R
>
> -----
> Randall Stewart
> [email-masked]
>
>
>
>
>

From: Randy Stewart <[email-masked]>
To: =?ISO-8859-1?Q?Michael_T=FCxen?= <[email-masked]>
Date: Wed, 25 Feb 2009 07:02:24 -0500
Cc: Vlad Yasevich <[email-masked]>, Kacheong Poon <[email-masked]>, tsvwg <[email-masked]>
Subject: Re: [Tsvwg] Event Notifications

On Feb 25, 2009, at 6:54 AM, Michael T=FCxen wrote:

> On Feb 25, 2009, at 12:34 PM, Randy Stewart wrote:
>
>>
>> On Feb 25, 2009, at 4:35 AM, Michael T=FCxen wrote:
>>
>>> On Feb 25, 2009, at 9:32 AM, Randy Stewart wrote:
>>>
>>>>
>>>> On Feb 24, 2009, at 10:46 PM, Kacheong Poon wrote:
>>>>
>>>>> Michael T=FCxen wrote:
>>>>>> On Feb 24, 2009, at 7:29 PM, Vlad Yasevich wrote:
>>>>> ...
>>>>>>> Hmm..  That's an interesting question.  Is it a possible =20
>>>>>>> scenario where
>>>>>>> an application decides to change event subscription of an =20
>>>>>>> association after
>>>>>>> it's established?  I can't see a reason right now, but that =20
>>>>>>> doesn't mean it
>>>>>>> doesn't exist.
>>>>>> We do this for the DRY event since we are only interested in it
>>>>>> during some specific states in DTLS (during renegotiations).
>>>>>
>>>>>
>>>>> If we want to explore this, I'd suggest we retire (just keep
>>>>> it there for backward compatibility) the sctp_event_subscribe.
>>>>> It is not extensible.  Just use sctp_assoc_value.  An app can
>>>>> subscribe/unsubscribe each event one by one.
>>>>>
>>>>> BTW, I guess it should not cause a problem if the DRY event is
>>>>> enabled for all associations controlled by one socket all the
>>>>> time.
>>>>>
>>>>
>>>> Hmm so let me summarize what I think we have agreed to so far
>>>>
>>>> 1) We will add support for using the sctp_assoc_value structure
>>>> to turn on/off EEOR mode on a per assoc basis.
>>>> 2) If the value of the assoc is 0, then the entire socket =20
>>>> (1-2many or 1-1) is
>>>> set to EEOR mode this includes future and all existing sockets.
>>>>
>>>>
>>>> On the events... I am not convinced a per-assoc subscription is
>>>> needed. Going to Michael's sender-dry for DTLS.. even on a 1-to-=20
>>>> many
>>>> socket .. you know if you are sending and can turn it off as soon
>>>> as the dry-event occurs. If you get a dry event on another
>>>> association, you can pretty easily ignore it. It might be nice
>>>> to have per-association on/off of some events. But I am mixed
>>>> on how useful that is.
>>>>
>>>> I do agree with Kacheong here though, if we have to go this route =20=

>>>> we
>>>> need a new structure.. i.e. one that includes an assoc id.. and =20
>>>> then
>>>> do the thing that says if the assoc-id=3D=3D0 its to future =20
>>>> associations
>>>> or the entire socket... vs just changing a single association. I =20=

>>>> would
>>>> also think we want to make it more extensible and as Kacheong said
>>>> just retire the old SCTP_EVENTS... i.e. support for backward =20
>>>> compatibility
>>>> but move to the new structure for future things..
>>>>
>>>> But again, is this really worth it? I am not convinced it is yet..
>>> There are two points here specific to the DRY event:
>>>
>>> 1. Performance: I might be interested only in the events for one
>>> particular association, but I get them for all. Of course I
>>> can ignore them for all associations I'm not interested in,
>>> but this means the kernel is going to generate a lot of =20
>>> notifications
>>> I'm not interested in. This is just waisted cycles and mbufs.
>>>
>>> 2. The DRY event is generated when it is enabled and the the =20
>>> association
>>> is dry.  So assume I have N associations (being dry), I'm interested
>>> in one. Now I enable it. The kernel has to generate N notifications
>>> instantly. This might be a resource problem (on Mac OS X I ran into
>>> it), because you need N mbufs at about the same time. There is also
>>> no "flow control" for notifications.
>>> That is why I implemented this currently only for 1-to-1 style =20
>>> sockets.
>>>
>>> But I think we should be more future proof here.
>>> I like Kacheongs idea to use the assoc_value structs:
>>> 1. This allows it to control it on an association base. No =20
>>> limitation
>>> here.
>>> 2. It can be used with any future notification. It is just adding a
>>> new constant, not changing a structure which might break ABI =20
>>> compatibility.
>>> 3. It is simple.
>>>
>>> I think we should add this.
>>
>>
> The socket option is called SCTP_EVENTS. I suggest to keep it.

Opps.. you are right so I did not go look at the header file :-)

> What about SCTP_EVENT (no S, so singular)? This would use
> struct sctp_assoc_value.

Thats fine with me..

> Correct. And ignore for 1-to-1 style sockets.

Not if you are a listener.. A listening 1-on-1 socket would
be setting up for its future "accepted" associations.

> Why do you want to change that? I would suggest to keep it at it is.

I guess we could.. but it will really be the first socket
option that digs through a 1-M socket and grabs each
assoc and applies some settings. Which in my mind kinda makes
it inconsistent.

The current events are set socket wide.. so at an implementation
level we are discussing moving the events onto the actual
"assoc structure" not the "socket level structure". Which in my
mind changes the semantics of the way the thing is manipulated.

Inside the API we have been pretty consistent. If its a over-reaching
socket level thing it of course effects everything when you change
it. However if its something ON an association changes at
the socket level effect future associations vs changes on a specific
assoc...

This concerns me somewhat.. but I guess for compatibility reasons it
would be ok...

But honestly other than this new sender-dry event of yours most everyone
I have ever taught the API too or worked with on it sets up the
SCTP_EVENTS once and only once.. and then never touches it again.

R

>> This is a subtle difference but one we should document well. I think
>> its ok, since most folks using the SCTP_EVENT's do not change
>> things in the middle. They basically open a socket, set the events
>> they may want... and then never touch it again.
>>
>> I do agree this would then add a nice extensible mechanism to add
>> future events as well.
>>
>> As long as Kacheong and Vlad are ok with this I am too... I can see
>> it will at least be useful for the sender-dry-event. Not sure about
>> other ones but you never know.
>>
>> Kacheong, Vlad, -- thoughts.. if you agree I will start making
>> changes in BSD and the ID..
>>
>> R
>>
>> -----
>> Randall Stewart
>> [email-masked]
>>
>>
>>
>>
>>
>

-----
Randall Stewart
[email-masked]

From: =?ISO-8859-1?Q?Michael_T=FCxen?= <[email-masked]>
To: Randy Stewart <[email-masked]>
Date: Wed, 25 Feb 2009 14:32:01 +0100
Cc: Vlad Yasevich <[email-masked]>, Kacheong Poon <[email-masked]>, tsvwg <[email-masked]>
Subject: Re: [Tsvwg] Event Notifications

On Feb 25, 2009, at 1:02 PM, Randy Stewart wrote:

>
> On Feb 25, 2009, at 6:54 AM, Michael T=FCxen wrote:
>
>> On Feb 25, 2009, at 12:34 PM, Randy Stewart wrote:
>>
>>>
>>> On Feb 25, 2009, at 4:35 AM, Michael T=FCxen wrote:
>>>
>>>> On Feb 25, 2009, at 9:32 AM, Randy Stewart wrote:
>>>>
>>>>>
>>>>> On Feb 24, 2009, at 10:46 PM, Kacheong Poon wrote:
>>>>>
>>>>>> Michael T=FCxen wrote:
>>>>>>> On Feb 24, 2009, at 7:29 PM, Vlad Yasevich wrote:
>>>>>> ...
>>>>>>>> Hmm..  That's an interesting question.  Is it a possible =20
>>>>>>>> scenario where
>>>>>>>> an application decides to change event subscription of an =20
>>>>>>>> association after
>>>>>>>> it's established?  I can't see a reason right now, but that =20
>>>>>>>> doesn't mean it
>>>>>>>> doesn't exist.
>>>>>>> We do this for the DRY event since we are only interested in it
>>>>>>> during some specific states in DTLS (during renegotiations).
>>>>>>
>>>>>>
>>>>>> If we want to explore this, I'd suggest we retire (just keep
>>>>>> it there for backward compatibility) the sctp_event_subscribe.
>>>>>> It is not extensible.  Just use sctp_assoc_value.  An app can
>>>>>> subscribe/unsubscribe each event one by one.
>>>>>>
>>>>>> BTW, I guess it should not cause a problem if the DRY event is
>>>>>> enabled for all associations controlled by one socket all the
>>>>>> time.
>>>>>>
>>>>>
>>>>> Hmm so let me summarize what I think we have agreed to so far
>>>>>
>>>>> 1) We will add support for using the sctp_assoc_value structure
>>>>> to turn on/off EEOR mode on a per assoc basis.
>>>>> 2) If the value of the assoc is 0, then the entire socket =20
>>>>> (1-2many or 1-1) is
>>>>> set to EEOR mode this includes future and all existing sockets.
>>>>>
>>>>>
>>>>> On the events... I am not convinced a per-assoc subscription is
>>>>> needed. Going to Michael's sender-dry for DTLS.. even on a 1-to-=20=

>>>>> many
>>>>> socket .. you know if you are sending and can turn it off as soon
>>>>> as the dry-event occurs. If you get a dry event on another
>>>>> association, you can pretty easily ignore it. It might be nice
>>>>> to have per-association on/off of some events. But I am mixed
>>>>> on how useful that is.
>>>>>
>>>>> I do agree with Kacheong here though, if we have to go this =20
>>>>> route we
>>>>> need a new structure.. i.e. one that includes an assoc id.. and =20=

>>>>> then
>>>>> do the thing that says if the assoc-id=3D=3D0 its to future =20
>>>>> associations
>>>>> or the entire socket... vs just changing a single association. I =20=

>>>>> would
>>>>> also think we want to make it more extensible and as Kacheong said
>>>>> just retire the old SCTP_EVENTS... i.e. support for backward =20
>>>>> compatibility
>>>>> but move to the new structure for future things..
>>>>>
>>>>> But again, is this really worth it? I am not convinced it is yet..
>>>> There are two points here specific to the DRY event:
>>>>
>>>> 1. Performance: I might be interested only in the events for one
>>>> particular association, but I get them for all. Of course I
>>>> can ignore them for all associations I'm not interested in,
>>>> but this means the kernel is going to generate a lot of =20
>>>> notifications
>>>> I'm not interested in. This is just waisted cycles and mbufs.
>>>>
>>>> 2. The DRY event is generated when it is enabled and the the =20
>>>> association
>>>> is dry.  So assume I have N associations (being dry), I'm =20
>>>> interested
>>>> in one. Now I enable it. The kernel has to generate N notifications
>>>> instantly. This might be a resource problem (on Mac OS X I ran into
>>>> it), because you need N mbufs at about the same time. There is also
>>>> no "flow control" for notifications.
>>>> That is why I implemented this currently only for 1-to-1 style =20
>>>> sockets.
>>>>
>>>> But I think we should be more future proof here.
>>>> I like Kacheongs idea to use the assoc_value structs:
>>>> 1. This allows it to control it on an association base. No =20
>>>> limitation
>>>> here.
>>>> 2. It can be used with any future notification. It is just adding a
>>>> new constant, not changing a structure which might break ABI =20
>>>> compatibility.
>>>> 3. It is simple.
>>>>
>>>> I think we should add this.
>>>
>>>
>> The socket option is called SCTP_EVENTS. I suggest to keep it.
>
> Opps.. you are right so I did not go look at the header file :-)
>
>>
>>>
>>>
>>>
>> What about SCTP_EVENT (no S, so singular)? This would use
>> struct sctp_assoc_value.
>
> Thats fine with me..
>
>>
>>>
>>>
>> Correct. And ignore for 1-to-1 style sockets.
>
> Not if you are a listener.. A listening 1-on-1 socket would
> be setting up for its future "accepted" associations.
I meant: Ignore the association ID on the 1-to-1 style sockets.
On a listener, it is for future association, on a non listener,
it is for the specific one belonging to the socket.
>> Why do you want to change that? I would suggest to keep it at it is.
>
> I guess we could.. but it will really be the first socket
> option that digs through a 1-M socket and grabs each
> assoc and applies some settings. Which in my mind kinda makes
> it inconsistent.
>
> The current events are set socket wide.. so at an implementation
> level we are discussing moving the events onto the actual
> "assoc structure" not the "socket level structure". Which in my
> mind changes the semantics of the way the thing is manipulated.
I see what you mean... However, this means that some applications
might break since we are changing the semantics. But I think
it is worth the price.

Anyway: I think the best would be anyway to put a note in the
text that people should use the new API (SCTP_EVENT) instead
of the old one (SCTP_EVENTS). This way they can better use
additional features (Stream Reset comes to my mind...)
>
>
> Inside the API we have been pretty consistent. If its a over-reaching
> socket level thing it of course effects everything when you change
> it. However if its something ON an association changes at
> the socket level effect future associations vs changes on a specific
> assoc...
>
> This concerns me somewhat.. but I guess for compatibility reasons it
> would be ok...
>
> But honestly other than this new sender-dry event of yours most =20
> everyone
> I have ever taught the API too or worked with on it sets up the
> SCTP_EVENTS once and only once.. and then never touches it again.
I vote for changing the semantic!
>>> This is a subtle difference but one we should document well. I think
>>> its ok, since most folks using the SCTP_EVENT's do not change
>>> things in the middle. They basically open a socket, set the events
>>> they may want... and then never touch it again.
>>>
>>> I do agree this would then add a nice extensible mechanism to add
>>> future events as well.
>>>
>>> As long as Kacheong and Vlad are ok with this I am too... I can see
>>> it will at least be useful for the sender-dry-event. Not sure about
>>> other ones but you never know.
>>>
>>> Kacheong, Vlad, -- thoughts.. if you agree I will start making
>>> changes in BSD and the ID..
>>>
>>> R
>>>
>>> -----
>>> Randall Stewart
>>> [email-masked]
>>>
>>>
>>>
>>>
>>>
>>
>
> -----
> Randall Stewart
> [email-masked]
>
>
>
>
>

From: Randy Stewart <[email-masked]>
To: =?ISO-8859-1?Q?Michael_T=FCxen?= <[email-masked]>
Date: Wed, 25 Feb 2009 09:42:57 -0500
Cc: Vlad Yasevich <[email-masked]>, Kacheong Poon <[email-masked]>, tsvwg <[email-masked]>
Subject: Re: [Tsvwg] Event Notifications

I will go with whatever one else wants... I really
don't have much of an opinion.. the SCTP_EVENT is fine
and to the semantic changes... I will listen to
whatever Kacheong says on this.. since of all the
co-authors I think he is closest to being the
semantic police :-)

R
On Feb 25, 2009, at 8:32 AM, Michael T=FCxen wrote:

>
> On Feb 25, 2009, at 1:02 PM, Randy Stewart wrote:
>
>>
>> On Feb 25, 2009, at 6:54 AM, Michael T=FCxen wrote:
>>
>>> On Feb 25, 2009, at 12:34 PM, Randy Stewart wrote:
>>>
>>>>
>>>> On Feb 25, 2009, at 4:35 AM, Michael T=FCxen wrote:
>>>>
>>>>> On Feb 25, 2009, at 9:32 AM, Randy Stewart wrote:
>>>>>
>>>>>>
>>>>>> On Feb 24, 2009, at 10:46 PM, Kacheong Poon wrote:
>>>>>>
>>>>>>> Michael T=FCxen wrote:
>>>>>>>> On Feb 24, 2009, at 7:29 PM, Vlad Yasevich wrote:
>>>>>>> ...
>>>>>>>>> Hmm..  That's an interesting question.  Is it a possible =20
>>>>>>>>> scenario where
>>>>>>>>> an application decides to change event subscription of an =20
>>>>>>>>> association after
>>>>>>>>> it's established?  I can't see a reason right now, but that =20=

>>>>>>>>> doesn't mean it
>>>>>>>>> doesn't exist.
>>>>>>>> We do this for the DRY event since we are only interested in it
>>>>>>>> during some specific states in DTLS (during renegotiations).
>>>>>>>
>>>>>>>
>>>>>>> If we want to explore this, I'd suggest we retire (just keep
>>>>>>> it there for backward compatibility) the sctp_event_subscribe.
>>>>>>> It is not extensible.  Just use sctp_assoc_value.  An app can
>>>>>>> subscribe/unsubscribe each event one by one.
>>>>>>>
>>>>>>> BTW, I guess it should not cause a problem if the DRY event is
>>>>>>> enabled for all associations controlled by one socket all the
>>>>>>> time.
>>>>>>>
>>>>>>
>>>>>> Hmm so let me summarize what I think we have agreed to so far
>>>>>>
>>>>>> 1) We will add support for using the sctp_assoc_value structure
>>>>>> to turn on/off EEOR mode on a per assoc basis.
>>>>>> 2) If the value of the assoc is 0, then the entire socket =20
>>>>>> (1-2many or 1-1) is
>>>>>> set to EEOR mode this includes future and all existing sockets.
>>>>>>
>>>>>>
>>>>>> On the events... I am not convinced a per-assoc subscription is
>>>>>> needed. Going to Michael's sender-dry for DTLS.. even on a 1-to-=20=

>>>>>> many
>>>>>> socket .. you know if you are sending and can turn it off as soon
>>>>>> as the dry-event occurs. If you get a dry event on another
>>>>>> association, you can pretty easily ignore it. It might be nice
>>>>>> to have per-association on/off of some events. But I am mixed
>>>>>> on how useful that is.
>>>>>>
>>>>>> I do agree with Kacheong here though, if we have to go this =20
>>>>>> route we
>>>>>> need a new structure.. i.e. one that includes an assoc id.. and =20=

>>>>>> then
>>>>>> do the thing that says if the assoc-id=3D=3D0 its to future =20
>>>>>> associations
>>>>>> or the entire socket... vs just changing a single association. =20=

>>>>>> I would
>>>>>> also think we want to make it more extensible and as Kacheong =20
>>>>>> said
>>>>>> just retire the old SCTP_EVENTS... i.e. support for backward =20
>>>>>> compatibility
>>>>>> but move to the new structure for future things..
>>>>>>
>>>>>> But again, is this really worth it? I am not convinced it is =20
>>>>>> yet..
>>>>> There are two points here specific to the DRY event:
>>>>>
>>>>> 1. Performance: I might be interested only in the events for one
>>>>> particular association, but I get them for all. Of course I
>>>>> can ignore them for all associations I'm not interested in,
>>>>> but this means the kernel is going to generate a lot of =20
>>>>> notifications
>>>>> I'm not interested in. This is just waisted cycles and mbufs.
>>>>>
>>>>> 2. The DRY event is generated when it is enabled and the the =20
>>>>> association
>>>>> is dry.  So assume I have N associations (being dry), I'm =20
>>>>> interested
>>>>> in one. Now I enable it. The kernel has to generate N =20
>>>>> notifications
>>>>> instantly. This might be a resource problem (on Mac OS X I ran =20
>>>>> into
>>>>> it), because you need N mbufs at about the same time. There is =20
>>>>> also
>>>>> no "flow control" for notifications.
>>>>> That is why I implemented this currently only for 1-to-1 style =20
>>>>> sockets.
>>>>>
>>>>> But I think we should be more future proof here.
>>>>> I like Kacheongs idea to use the assoc_value structs:
>>>>> 1. This allows it to control it on an association base. No =20
>>>>> limitation
>>>>> here.
>>>>> 2. It can be used with any future notification. It is just =20
>>>>> adding a
>>>>> new constant, not changing a structure which might break ABI =20
>>>>> compatibility.
>>>>> 3. It is simple.
>>>>>
>>>>> I think we should add this.
>>>>
>>>>
>>> The socket option is called SCTP_EVENTS. I suggest to keep it.
>>
>> Opps.. you are right so I did not go look at the header file :-)
>>
>>>
>>>>
>>>>
>>>>
>>> What about SCTP_EVENT (no S, so singular)? This would use
>>> struct sctp_assoc_value.
>>
>> Thats fine with me..
>>
>>>
>>>>
>>>>
>>> Correct. And ignore for 1-to-1 style sockets.
>>
>> Not if you are a listener.. A listening 1-on-1 socket would
>> be setting up for its future "accepted" associations.
> I meant: Ignore the association ID on the 1-to-1 style sockets.
> On a listener, it is for future association, on a non listener,
> it is for the specific one belonging to the socket.
>>
>>
>>>
>>>>
>>>>
>>>>
>>> Why do you want to change that? I would suggest to keep it at it is.
>>
>> I guess we could.. but it will really be the first socket
>> option that digs through a 1-M socket and grabs each
>> assoc and applies some settings. Which in my mind kinda makes
>> it inconsistent.
>>
>> The current events are set socket wide.. so at an implementation
>> level we are discussing moving the events onto the actual
>> "assoc structure" not the "socket level structure". Which in my
>> mind changes the semantics of the way the thing is manipulated.
> I see what you mean... However, this means that some applications
> might break since we are changing the semantics. But I think
> it is worth the price.
>
> Anyway: I think the best would be anyway to put a note in the
> text that people should use the new API (SCTP_EVENT) instead
> of the old one (SCTP_EVENTS). This way they can better use
> additional features (Stream Reset comes to my mind...)
>>
>>
>> Inside the API we have been pretty consistent. If its a over-reaching
>> socket level thing it of course effects everything when you change
>> it. However if its something ON an association changes at
>> the socket level effect future associations vs changes on a specific
>> assoc...
>>
>> This concerns me somewhat.. but I guess for compatibility reasons it
>> would be ok...
>>
>> But honestly other than this new sender-dry event of yours most =20
>> everyone
>> I have ever taught the API too or worked with on it sets up the
>> SCTP_EVENTS once and only once.. and then never touches it again.
> I vote for changing the semantic!
>>
>>
>> R
>>
>>>
>>>>
>>>> This is a subtle difference but one we should document well. I =20
>>>> think
>>>> its ok, since most folks using the SCTP_EVENT's do not change
>>>> things in the middle. They basically open a socket, set the events
>>>> they may want... and then never touch it again.
>>>>
>>>> I do agree this would then add a nice extensible mechanism to add
>>>> future events as well.
>>>>
>>>> As long as Kacheong and Vlad are ok with this I am too... I can see
>>>> it will at least be useful for the sender-dry-event. Not sure about
>>>> other ones but you never know.
>>>>
>>>> Kacheong, Vlad, -- thoughts.. if you agree I will start making
>>>> changes in BSD and the ID..
>>>>
>>>> R
>>>>
>>>> -----
>>>> Randall Stewart
>>>> [email-masked]
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>
>> -----
>> Randall Stewart
>> [email-masked]
>>
>>
>>
>>
>>
>

-----
Randall Stewart
[email-masked]

Date: Wed, 25 Feb 2009 09:43:05 -0500
From: Vlad Yasevich <[email-masked]>
To: Randy Stewart <[email-masked]>
Cc: =?ISO-8859-1?Q?Michael_T=FCxen?= <[email-masked]>, Kacheong Poon <[email-masked]>, tsvwg <[email-masked]>
Subject: Re: [Tsvwg] Event Notifications

Randy Stewart wrote:
> 
> On Feb 25, 2009, at 4:35 AM, Michael Tüxen wrote:
> 
>> On Feb 25, 2009, at 9:32 AM, Randy Stewart wrote:
>>
>>>
>>> On Feb 24, 2009, at 10:46 PM, Kacheong Poon wrote:
>>>
>>>> Michael Tüxen wrote:
>>>>> On Feb 24, 2009, at 7:29 PM, Vlad Yasevich wrote:
>>>> ...
>>>>>> Hmm..  That's an interesting question.  Is it a possible scenario
>>>>>> where
>>>>>> an application decides to change event subscription of an
>>>>>> association after
>>>>>> it's established?  I can't see a reason right now, but that
>>>>>> doesn't mean it
>>>>>> doesn't exist.
>>>>> We do this for the DRY event since we are only interested in it
>>>>> during some specific states in DTLS (during renegotiations).
>>>>
>>>>
>>>> If we want to explore this, I'd suggest we retire (just keep
>>>> it there for backward compatibility) the sctp_event_subscribe.
>>>> It is not extensible.  Just use sctp_assoc_value.  An app can
>>>> subscribe/unsubscribe each event one by one.
>>>>
>>>> BTW, I guess it should not cause a problem if the DRY event is
>>>> enabled for all associations controlled by one socket all the
>>>> time.
>>>>
>>>
>>> Hmm so let me summarize what I think we have agreed to so far
>>>
>>> 1) We will add support for using the sctp_assoc_value structure
>>>  to turn on/off EEOR mode on a per assoc basis.
>>> 2) If the value of the assoc is 0, then the entire socket (1-2many or
>>> 1-1) is
>>>  set to EEOR mode this includes future and all existing sockets.
>>>
>>>
>>> On the events... I am not convinced a per-assoc subscription is
>>> needed. Going to Michael's sender-dry for DTLS.. even on a 1-to-many
>>> socket .. you know if you are sending and can turn it off as soon
>>> as the dry-event occurs. If you get a dry event on another
>>> association, you can pretty easily ignore it. It might be nice
>>> to have per-association on/off of some events. But I am mixed
>>> on how useful that is.
>>>
>>> I do agree with Kacheong here though, if we have to go this route we
>>> need a new structure.. i.e. one that includes an assoc id.. and then
>>> do the thing that says if the assoc-id==0 its to future associations
>>> or the entire socket... vs just changing a single association. I would
>>> also think we want to make it more extensible and as Kacheong said
>>> just retire the old SCTP_EVENTS... i.e. support for backward
>>> compatibility
>>> but move to the new structure for future things..
>>>
>>> But again, is this really worth it? I am not convinced it is yet..
>> There are two points here specific to the DRY event:
>>
>> 1. Performance: I might be interested only in the events for one
>>   particular association, but I get them for all. Of course I
>>   can ignore them for all associations I'm not interested in,
>>   but this means the kernel is going to generate a lot of notifications
>>   I'm not interested in. This is just waisted cycles and mbufs.
>>
>> 2. The DRY event is generated when it is enabled and the the association
>>   is dry.  So assume I have N associations (being dry), I'm interested
>>   in one. Now I enable it. The kernel has to generate N notifications
>>   instantly. This might be a resource problem (on Mac OS X I ran into
>>   it), because you need N mbufs at about the same time. There is also
>>   no "flow control" for notifications.
>>   That is why I implemented this currently only for 1-to-1 style sockets.
>>
>> But I think we should be more future proof here.
>> I like Kacheongs idea to use the assoc_value structs:
>> 1. This allows it to control it on an association base. No limitation
>>   here.
>> 2. It can be used with any future notification. It is just adding a
>>   new constant, not changing a structure which might break ABI
>> compatibility.
>> 3. It is simple.
>>
>> I think we should add this.
> 
> 

So, this option could only be used to turn something on, not turn
it off?  Seems one-sided. :)

> This is a subtle difference but one we should document well. I think
> its ok, since most folks using the SCTP_EVENT's do not change
> things in the middle. They basically open a socket, set the events
> they may want... and then never touch it again.
> 
> I do agree this would then add a nice extensible mechanism to add
> future events as well.
> 

Yes, this is something that would be good to have.  It also gives
applications a very fine control over what they can request and that's
generally a good thing.

-vlad

> As long as Kacheong and Vlad are ok with this I am too... I can see
> it will at least be useful for the sender-dry-event. Not sure about
> other ones but you never know.
> 
> Kacheong, Vlad, -- thoughts.. if you agree I will start making
> changes in BSD and the ID..
> 
> R
> 
> -----
> Randall Stewart
> [email-masked]
> 
> 
> 
> 

From: Randy Stewart <[email-masked]>
To: Vlad Yasevich <[email-masked]>
Date: Wed, 25 Feb 2009 10:09:38 -0500
Cc: =?ISO-8859-1?Q?Michael_T=FCxen?= <[email-masked]>, Kacheong Poon <[email-masked]>, tsvwg <[email-masked]>
Subject: Re: [Tsvwg] Event Notifications

On Feb 25, 2009, at 9:43 AM, Vlad Yasevich wrote:

> Randy Stewart wrote:
>>
>> On Feb 25, 2009, at 4:35 AM, Michael T=FCxen wrote:
>>
>>> On Feb 25, 2009, at 9:32 AM, Randy Stewart wrote:
>>>
>>>>
>>>> On Feb 24, 2009, at 10:46 PM, Kacheong Poon wrote:
>>>>
>>>>> Michael T=FCxen wrote:
>>>>>> On Feb 24, 2009, at 7:29 PM, Vlad Yasevich wrote:
>>>>> ...
>>>>>>> Hmm..  That's an interesting question.  Is it a possible =20
>>>>>>> scenario
>>>>>>> where
>>>>>>> an application decides to change event subscription of an
>>>>>>> association after
>>>>>>> it's established?  I can't see a reason right now, but that
>>>>>>> doesn't mean it
>>>>>>> doesn't exist.
>>>>>> We do this for the DRY event since we are only interested in it
>>>>>> during some specific states in DTLS (during renegotiations).
>>>>>
>>>>>
>>>>> If we want to explore this, I'd suggest we retire (just keep
>>>>> it there for backward compatibility) the sctp_event_subscribe.
>>>>> It is not extensible.  Just use sctp_assoc_value.  An app can
>>>>> subscribe/unsubscribe each event one by one.
>>>>>
>>>>> BTW, I guess it should not cause a problem if the DRY event is
>>>>> enabled for all associations controlled by one socket all the
>>>>> time.
>>>>>
>>>>
>>>> Hmm so let me summarize what I think we have agreed to so far
>>>>
>>>> 1) We will add support for using the sctp_assoc_value structure
>>>> to turn on/off EEOR mode on a per assoc basis.
>>>> 2) If the value of the assoc is 0, then the entire socket =20
>>>> (1-2many or
>>>> 1-1) is
>>>> set to EEOR mode this includes future and all existing sockets.
>>>>
>>>>
>>>> On the events... I am not convinced a per-assoc subscription is
>>>> needed. Going to Michael's sender-dry for DTLS.. even on a 1-to-=20
>>>> many
>>>> socket .. you know if you are sending and can turn it off as soon
>>>> as the dry-event occurs. If you get a dry event on another
>>>> association, you can pretty easily ignore it. It might be nice
>>>> to have per-association on/off of some events. But I am mixed
>>>> on how useful that is.
>>>>
>>>> I do agree with Kacheong here though, if we have to go this route =20=

>>>> we
>>>> need a new structure.. i.e. one that includes an assoc id.. and =20
>>>> then
>>>> do the thing that says if the assoc-id=3D=3D0 its to future =20
>>>> associations
>>>> or the entire socket... vs just changing a single association. I =20=

>>>> would
>>>> also think we want to make it more extensible and as Kacheong said
>>>> just retire the old SCTP_EVENTS... i.e. support for backward
>>>> compatibility
>>>> but move to the new structure for future things..
>>>>
>>>> But again, is this really worth it? I am not convinced it is yet..
>>> There are two points here specific to the DRY event:
>>>
>>> 1. Performance: I might be interested only in the events for one
>>>  particular association, but I get them for all. Of course I
>>>  can ignore them for all associations I'm not interested in,
>>>  but this means the kernel is going to generate a lot of =20
>>> notifications
>>>  I'm not interested in. This is just waisted cycles and mbufs.
>>>
>>> 2. The DRY event is generated when it is enabled and the the =20
>>> association
>>>  is dry.  So assume I have N associations (being dry), I'm =20
>>> interested
>>>  in one. Now I enable it. The kernel has to generate N notifications
>>>  instantly. This might be a resource problem (on Mac OS X I ran into
>>>  it), because you need N mbufs at about the same time. There is also
>>>  no "flow control" for notifications.
>>>  That is why I implemented this currently only for 1-to-1 style =20
>>> sockets.
>>>
>>> But I think we should be more future proof here.
>>> I like Kacheongs idea to use the assoc_value structs:
>>> 1. This allows it to control it on an association base. No =20
>>> limitation
>>>  here.
>>> 2. It can be used with any future notification. It is just adding a
>>>  new constant, not changing a structure which might break ABI
>>> compatibility.
>>> 3. It is simple.
>>>
>>> I think we should add this.
>>
>>
> So, this option could only be used to turn something on, not turn
> it off?  Seems one-sided. :)

Hmm.. yeah you are right here. You would have to define two contants
I guess..

SCTP_DRY_NOTIFICATION_ON
SCTP_DRY_NOTIFICATION_OFF

Since its a 32 bit number space in the value it would probably be =20
extensible
enough (2 billion possibilities) :-)

>> This is a subtle difference but one we should document well. I think
>> its ok, since most folks using the SCTP_EVENT's do not change
>> things in the middle. They basically open a socket, set the events
>> they may want... and then never touch it again.
>>
>> I do agree this would then add a nice extensible mechanism to add
>> future events as well.
>>
>
> Yes, this is something that would be good to have.  It also gives
> applications a very fine control over what they can request and that's
> generally a good thing.

True

R
>
>
> -vlad
>
>> As long as Kacheong and Vlad are ok with this I am too... I can see
>> it will at least be useful for the sender-dry-event. Not sure about
>> other ones but you never know.
>>
>> Kacheong, Vlad, -- thoughts.. if you agree I will start making
>> changes in BSD and the ID..
>>
>> R
>>
>> -----
>> Randall Stewart
>> [email-masked]
>>
>>
>>
>>
>

-----
Randall Stewart
[email-masked]

From: =?ISO-8859-1?Q?Michael_T=FCxen?= <[email-masked]>
To: Vlad Yasevich <[email-masked]>
Date: Wed, 25 Feb 2009 16:19:01 +0100
Cc: Kacheong Poon <[email-masked]>, tsvwg <[email-masked]>, Randy Stewart <[email-masked]>
Subject: Re: [Tsvwg] Event Notifications

On Feb 25, 2009, at 3:43 PM, Vlad Yasevich wrote:

> Randy Stewart wrote:
>>
>> On Feb 25, 2009, at 4:35 AM, Michael T=FCxen wrote:
>>
>>> On Feb 25, 2009, at 9:32 AM, Randy Stewart wrote:
>>>
>>>>
>>>> On Feb 24, 2009, at 10:46 PM, Kacheong Poon wrote:
>>>>
>>>>> Michael T=FCxen wrote:
>>>>>> On Feb 24, 2009, at 7:29 PM, Vlad Yasevich wrote:
>>>>> ...
>>>>>>> Hmm..  That's an interesting question.  Is it a possible =20
>>>>>>> scenario
>>>>>>> where
>>>>>>> an application decides to change event subscription of an
>>>>>>> association after
>>>>>>> it's established?  I can't see a reason right now, but that
>>>>>>> doesn't mean it
>>>>>>> doesn't exist.
>>>>>> We do this for the DRY event since we are only interested in it
>>>>>> during some specific states in DTLS (during renegotiations).
>>>>>
>>>>>
>>>>> If we want to explore this, I'd suggest we retire (just keep
>>>>> it there for backward compatibility) the sctp_event_subscribe.
>>>>> It is not extensible.  Just use sctp_assoc_value.  An app can
>>>>> subscribe/unsubscribe each event one by one.
>>>>>
>>>>> BTW, I guess it should not cause a problem if the DRY event is
>>>>> enabled for all associations controlled by one socket all the
>>>>> time.
>>>>>
>>>>
>>>> Hmm so let me summarize what I think we have agreed to so far
>>>>
>>>> 1) We will add support for using the sctp_assoc_value structure
>>>> to turn on/off EEOR mode on a per assoc basis.
>>>> 2) If the value of the assoc is 0, then the entire socket =20
>>>> (1-2many or
>>>> 1-1) is
>>>> set to EEOR mode this includes future and all existing sockets.
>>>>
>>>>
>>>> On the events... I am not convinced a per-assoc subscription is
>>>> needed. Going to Michael's sender-dry for DTLS.. even on a 1-to-=20
>>>> many
>>>> socket .. you know if you are sending and can turn it off as soon
>>>> as the dry-event occurs. If you get a dry event on another
>>>> association, you can pretty easily ignore it. It might be nice
>>>> to have per-association on/off of some events. But I am mixed
>>>> on how useful that is.
>>>>
>>>> I do agree with Kacheong here though, if we have to go this route =20=

>>>> we
>>>> need a new structure.. i.e. one that includes an assoc id.. and =20
>>>> then
>>>> do the thing that says if the assoc-id=3D=3D0 its to future =20
>>>> associations
>>>> or the entire socket... vs just changing a single association. I =20=

>>>> would
>>>> also think we want to make it more extensible and as Kacheong said
>>>> just retire the old SCTP_EVENTS... i.e. support for backward
>>>> compatibility
>>>> but move to the new structure for future things..
>>>>
>>>> But again, is this really worth it? I am not convinced it is yet..
>>> There are two points here specific to the DRY event:
>>>
>>> 1. Performance: I might be interested only in the events for one
>>>  particular association, but I get them for all. Of course I
>>>  can ignore them for all associations I'm not interested in,
>>>  but this means the kernel is going to generate a lot of =20
>>> notifications
>>>  I'm not interested in. This is just waisted cycles and mbufs.
>>>
>>> 2. The DRY event is generated when it is enabled and the the =20
>>> association
>>>  is dry.  So assume I have N associations (being dry), I'm =20
>>> interested
>>>  in one. Now I enable it. The kernel has to generate N notifications
>>>  instantly. This might be a resource problem (on Mac OS X I ran into
>>>  it), because you need N mbufs at about the same time. There is also
>>>  no "flow control" for notifications.
>>>  That is why I implemented this currently only for 1-to-1 style =20
>>> sockets.
>>>
>>> But I think we should be more future proof here.
>>> I like Kacheongs idea to use the assoc_value structs:
>>> 1. This allows it to control it on an association base. No =20
>>> limitation
>>>  here.
>>> 2. It can be used with any future notification. It is just adding a
>>>  new constant, not changing a structure which might break ABI
>>> compatibility.
>>> 3. It is simple.
>>>
>>> I think we should add this.
>>
>>
> So, this option could only be used to turn something on, not turn
> it off?  Seems one-sided. :)
Good point.
So I think we need something like
struct sctp_event {
	sctp_assoc_t assoc_id;
	uint32_t event;
	uint8_t enable;
}
Using enable!=3D0, you can enable it, using enable=3D0, you can disable =
it =20
when
you use setsockopt().

For getsockopt(), you provie the assoc_id and the event and get back =20
whether it
is enabled or not.
>> This is a subtle difference but one we should document well. I think
>> its ok, since most folks using the SCTP_EVENT's do not change
>> things in the middle. They basically open a socket, set the events
>> they may want... and then never touch it again.
>>
>> I do agree this would then add a nice extensible mechanism to add
>> future events as well.
>>
>
> Yes, this is something that would be good to have.  It also gives
> applications a very fine control over what they can request and that's
> generally a good thing.
>
> -vlad
>
>> As long as Kacheong and Vlad are ok with this I am too... I can see
>> it will at least be useful for the sender-dry-event. Not sure about
>> other ones but you never know.
>>
>> Kacheong, Vlad, -- thoughts.. if you agree I will start making
>> changes in BSD and the ID..
>>
>> R
>>
>> -----
>> Randall Stewart
>> [email-masked]
>>
>>
>>
>>
>
>

From: =?ISO-8859-1?Q?Michael_T=FCxen?= <[email-masked]>
To: Randy Stewart <[email-masked]>
Date: Wed, 25 Feb 2009 16:19:56 +0100
Cc: Vlad Yasevich <[email-masked]>, Kacheong Poon <[email-masked]>, tsvwg <[email-masked]>
Subject: Re: [Tsvwg] Event Notifications

On Feb 25, 2009, at 4:09 PM, Randy Stewart wrote:

>
> On Feb 25, 2009, at 9:43 AM, Vlad Yasevich wrote:
>
>> Randy Stewart wrote:
>>>
>>> On Feb 25, 2009, at 4:35 AM, Michael T=FCxen wrote:
>>>
>>>> On Feb 25, 2009, at 9:32 AM, Randy Stewart wrote:
>>>>
>>>>>
>>>>> On Feb 24, 2009, at 10:46 PM, Kacheong Poon wrote:
>>>>>
>>>>>> Michael T=FCxen wrote:
>>>>>>> On Feb 24, 2009, at 7:29 PM, Vlad Yasevich wrote:
>>>>>> ...
>>>>>>>> Hmm..  That's an interesting question.  Is it a possible =20
>>>>>>>> scenario
>>>>>>>> where
>>>>>>>> an application decides to change event subscription of an
>>>>>>>> association after
>>>>>>>> it's established?  I can't see a reason right now, but that
>>>>>>>> doesn't mean it
>>>>>>>> doesn't exist.
>>>>>>> We do this for the DRY event since we are only interested in it
>>>>>>> during some specific states in DTLS (during renegotiations).
>>>>>>
>>>>>>
>>>>>> If we want to explore this, I'd suggest we retire (just keep
>>>>>> it there for backward compatibility) the sctp_event_subscribe.
>>>>>> It is not extensible.  Just use sctp_assoc_value.  An app can
>>>>>> subscribe/unsubscribe each event one by one.
>>>>>>
>>>>>> BTW, I guess it should not cause a problem if the DRY event is
>>>>>> enabled for all associations controlled by one socket all the
>>>>>> time.
>>>>>>
>>>>>
>>>>> Hmm so let me summarize what I think we have agreed to so far
>>>>>
>>>>> 1) We will add support for using the sctp_assoc_value structure
>>>>> to turn on/off EEOR mode on a per assoc basis.
>>>>> 2) If the value of the assoc is 0, then the entire socket =20
>>>>> (1-2many or
>>>>> 1-1) is
>>>>> set to EEOR mode this includes future and all existing sockets.
>>>>>
>>>>>
>>>>> On the events... I am not convinced a per-assoc subscription is
>>>>> needed. Going to Michael's sender-dry for DTLS.. even on a 1-to-=20=

>>>>> many
>>>>> socket .. you know if you are sending and can turn it off as soon
>>>>> as the dry-event occurs. If you get a dry event on another
>>>>> association, you can pretty easily ignore it. It might be nice
>>>>> to have per-association on/off of some events. But I am mixed
>>>>> on how useful that is.
>>>>>
>>>>> I do agree with Kacheong here though, if we have to go this =20
>>>>> route we
>>>>> need a new structure.. i.e. one that includes an assoc id.. and =20=

>>>>> then
>>>>> do the thing that says if the assoc-id=3D=3D0 its to future =20
>>>>> associations
>>>>> or the entire socket... vs just changing a single association. I =20=

>>>>> would
>>>>> also think we want to make it more extensible and as Kacheong said
>>>>> just retire the old SCTP_EVENTS... i.e. support for backward
>>>>> compatibility
>>>>> but move to the new structure for future things..
>>>>>
>>>>> But again, is this really worth it? I am not convinced it is yet..
>>>> There are two points here specific to the DRY event:
>>>>
>>>> 1. Performance: I might be interested only in the events for one
>>>> particular association, but I get them for all. Of course I
>>>> can ignore them for all associations I'm not interested in,
>>>> but this means the kernel is going to generate a lot of =20
>>>> notifications
>>>> I'm not interested in. This is just waisted cycles and mbufs.
>>>>
>>>> 2. The DRY event is generated when it is enabled and the the =20
>>>> association
>>>> is dry.  So assume I have N associations (being dry), I'm =20
>>>> interested
>>>> in one. Now I enable it. The kernel has to generate N notifications
>>>> instantly. This might be a resource problem (on Mac OS X I ran into
>>>> it), because you need N mbufs at about the same time. There is also
>>>> no "flow control" for notifications.
>>>> That is why I implemented this currently only for 1-to-1 style =20
>>>> sockets.
>>>>
>>>> But I think we should be more future proof here.
>>>> I like Kacheongs idea to use the assoc_value structs:
>>>> 1. This allows it to control it on an association base. No =20
>>>> limitation
>>>> here.
>>>> 2. It can be used with any future notification. It is just adding a
>>>> new constant, not changing a structure which might break ABI
>>>> compatibility.
>>>> 3. It is simple.
>>>>
>>>> I think we should add this.
>>>
>>>
>> So, this option could only be used to turn something on, not turn
>> it off?  Seems one-sided. :)
>
>
> Hmm.. yeah you are right here. You would have to define two contants
> I guess..
>
> SCTP_DRY_NOTIFICATION_ON
> SCTP_DRY_NOTIFICATION_OFF
This does not help for getsockopt()... Se my suggestion in my previous =20=

mail.
>
>
> Since its a 32 bit number space in the value it would probably be =20
> extensible
> enough (2 billion possibilities) :-)
>
>>
>>
>>>
>>> This is a subtle difference but one we should document well. I think
>>> its ok, since most folks using the SCTP_EVENT's do not change
>>> things in the middle. They basically open a socket, set the events
>>> they may want... and then never touch it again.
>>>
>>> I do agree this would then add a nice extensible mechanism to add
>>> future events as well.
>>>
>>
>> Yes, this is something that would be good to have.  It also gives
>> applications a very fine control over what they can request and =20
>> that's
>> generally a good thing.
>
> True
>
> R
>>
>>
>> -vlad
>>
>>> As long as Kacheong and Vlad are ok with this I am too... I can see
>>> it will at least be useful for the sender-dry-event. Not sure about
>>> other ones but you never know.
>>>
>>> Kacheong, Vlad, -- thoughts.. if you agree I will start making
>>> changes in BSD and the ID..
>>>
>>> R
>>>
>>> -----
>>> Randall Stewart
>>> [email-masked]
>>>
>>>
>>>
>>>
>>
>
> -----
> Randall Stewart
> [email-masked]
>
>
>
>
>