Subject: [Tsvwg] Association is PR-SCTP enabled?

From: Christopher Hegarty - Sun Microsystems Ireland <[email-masked]>
Date: Mon, 22 Sep 2008 11:17:57 +0100

Hi,

I posted a query to the lksctp-developers mailing list asking if it is 
possible using the socket API extensions to determine if an association 
supports the partial reliability extension? I was redirected to this 
mailing list.

I wanted to include a link here to my question, but the lksctp mailing 
list archive does not seem to be updated yet so I here is the message:

   "Is there a way of determining if an association supports the partial
    reliability extension? Solaris provides 'SCTP_PRSCTP_CAPABLE' if
    the association is PR-SCTP enabled. Or is the value formally known
    as sctp_timetolive (now sinfo_pr_policy and info_pr_value) just a
    best effort with respect to PR-SCTP?

    I noticed that HAVE_SCTP_PRSCTP and many other definitions have
    been removed from the draft API. Are these just moving to
    implementation details?"

Obviously the SCTP stack has knowledge of whether or not an association 
supported this extension, but there doesn't appear to be support in the 
API to allow upper layers to determine this.

Thanks,
-Chris.

---

From: Randy Stewart <[email-masked]>
Date: Mon, 22 Sep 2008 04:20:21 -0700

Chris:

This is a good point... I can't remember why we decided
to take out the HAVE_XXX defines ... but it was for this
very reason they were put in.

Hmm.. maybe it would be nice to have a method that one could query for  
the
various extensions aka a socket option that you could call like

x.associd = associd
x.value = SUPPORTS_PRSCTP;

getsocketoption(..., SCTP_GETSUPPORTED, &x, ..)

but of course it is a bit late to add supprot for new things since
we are trying to close the draft :->

R
On Sep 22, 2008, at 3:17 AM, Christopher Hegarty - Sun Microsystems  
Ireland wrote:

> Hi,
>
> I posted a query to the lksctp-developers mailing list asking if it  
> is possible using the socket API extensions to determine if an  
> association supports the partial reliability extension? I was  
> redirected to this mailing list.
>
> I wanted to include a link here to my question, but the lksctp  
> mailing list archive does not seem to be updated yet so I here is  
> the message:
>
> Obviously the SCTP stack has knowledge of whether or not an  
> association supported this extension, but there doesn't appear to be  
> support in the API to allow upper layers to determine this.
>
> Thanks,
> -Chris.
>

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 22 Sep 2008 05:53:50 -0600

Randy,

Does not the application merely need to examine ALI to determine
whether PR-SCTP is supported?

--brian

Randy Stewart wrote:                       (Mon, 22 Sep 2008 04:20:21)

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/

---

From: Michael Tüxen <[email-masked]>
Date: Mon, 22 Sep 2008 14:19:11 +0200

Hi Brian,

comments inline.

Best regards
Michael

> Does not the application merely need to examine ALI to determine
Not sure what ALI means...
> whether PR-SCTP is supported?
I think it can be important for an application to figure out
if an extension is supported by both ends... DTLS/SCTP, for example,
requires the use of SCTP-AUTH... I can think about applications that
want to make sure that the peer supports PR-SCTP...

---

From: Michael Tüxen <[email-masked]>
Date: Mon, 22 Sep 2008 14:15:13 +0200

Randy,

I think a compile time options (like HAVE_something) does not help
here...

We are providing the socket API for plain SCTP, PR-SCTP, SCTP-AUTH
and ADD_IP in the ID. I think we need to provide such an interface
and do it in a way that it is clear how other extensions in the
future can do it (like Stream Reset).

I know it is late, but I think we should add such a thing since
it is important to have a way to see what the peer support and
what not.

One way is another socket options and new constants, one for
each feature. Another possibility would be to make the
intersection of the sent supported chunks type and received
supported chunks type available. This would be future proof...

I prefer a socket option compared to notifications...

What do you think?

Best regards
Michael

On Sep 22, 2008, at 1:20 PM, Randy Stewart wrote:

> Hmm.. maybe it would be nice to have a method that one could query  
> for the
>> association supported this extension, but there doesn't appear to  
>> be support in the API to allow upper layers to determine this.
>>
>> Thanks,
>> -Chris.
>>
>
> -----
> Randall Stewart
> [email-masked]
>
>
>
>
>

---

From: Michio HONDA <[email-masked]>
Date: Mon, 22 Sep 2008 16:30:43 +0300

Hi,

BSD implementation also has no way to determine if the association 
supports PRSCTP by socket API or sysctl. 

I think that there is possibility of applications changing the action 
depending on the PRSCTP capability. 
So I agree suggesting the option like PRSCTP_CAPABLE in Solaris to the 
API draft. 

Thanks

Christopher Hegarty - Sun Microsystems Ireland wrote:
> possible using the socket API extensions to determine if an 

-- 
Michio Honda
E-mail: [email-masked], [email-masked]
Website: http://www.micchie.net/

---

From: Vlad Yasevich <[email-masked]>
Date: Mon, 22 Sep 2008 10:10:23 -0400

> very reason they were put in.

The reasons to take out the features were that they didn't
state what is currently turned on.  Only what is available.
Another reason was that the semantics for testing of "defined"
were never fully documented and people were getting confused.

> 
> Hmm.. maybe it would be nice to have a method that one could query for the

That, we could define feature flags and fill in the flags in the
sctp_assoc_change structure.  That way when the association comes
up, the notification provides data for the features a given association
supports.  It only gives us 16 features (since the flags is a short),
but I think that might be enough for now.

-vlad

---

From: Michael Tüxen <[email-masked]>
Date: Mon, 22 Sep 2008 17:47:08 +0200

Vlad,

what about a getsockopt() where you can get the
list of chunks supported by the local and remote end?
This would be in tune with the supported chunks why
of negotiating extensions...

Best regards
Michael

On Sep 22, 2008, at 4:10 PM, Vlad Yasevich wrote:

>>> mailing

---

From: Vlad Yasevich <[email-masked]>
Date: Mon, 22 Sep 2008 12:11:03 -0400

> of negotiating extensions...

Yes, but there is no requirement to include FWD-TSN chunk
in the supported extensions list.  In fact, there is
specific Forward-TSN-Supported parameter that is separate
from the supported extensions parameter.

-vlad

---

From: Vlad Yasevich <[email-masked]>
Date: Mon, 22 Sep 2008 12:16:33 -0400

> of negotiating extensions...

I am also thinking of a way of not introducing any
new socket options just to we can close the down
the spec.

If 16 extensions is not enough, we can define and extension
structure and attach to sctp_assoc_change as sac_info
for the SCTP_COMM_UP and SCTP_RESTART states.  That can
handle future extensions easier.

It's not just the supported chunks arguments.  That's fine
for well behaving implementations.  However, for some things
we have multiple ways of signaling support and it's possible
had conflicting information.

I am trying to separate the API from the protocol behavior.

-vlad

---

From: Michael Tüxen <[email-masked]>
Date: Mon, 22 Sep 2008 19:25:21 +0200

Hi Vlad,

can you propose text?

Best regards
Michael

---

From: Michael Tüxen <[email-masked]>
Date: Mon, 22 Sep 2008 19:21:35 +0200

> from the supported extensions parameter.
OK. We can require the getsockopt to include the FWD-TSN
parameter if the local and remote endpoint support PR-SCTP...

---

From: Vlad Yasevich <[email-masked]>
Date: Tue, 23 Sep 2008 14:11:55 -0400

> can you propose text?

Ok  how about:

   sac_info: variable

   If the sac_state is SCTP_COMM_LOST and an ABORT chunk was received
   for this association, sac_info[] contains the complete ABORT chunk as
   defined in the SCTP specification [RFC4960] section 3.3.7.

   If the sac_state is SCTP_COMM_UP or SCTP_RESTART, sac_info may contain
   an array of features that the current association supports.  See Section
   X.Y.Z for information about features defined in this document.
   Additional features may be defined in separate specifications detailing
   specific extensions.

This allows us to simply look at the length of the notification returned to see
if sac_info contains any information.  The information is encoded as a simple
array of bytes.  It doesn't matter what the values.  We just need to document
the names.

The names reference in the document are:
	HAVE_SCTP_MULTIBUF
	HAVE_SCTP_NOCONNECT

I think we can drop the HAVE_ prefix.

Additionally, we can define the following:

SCTP_PR
SCTP_AUTH
SCTP_ASCONF

may be SCTP_PAD.

Anything else, would include a symbol in he draft specifying the feature.

Applications simply test for the existence of the feature they are interested in.

-vlad