[sctp-dev] Setting "Traffic Class" to a SctpChannel

Chris Hegarty chris.hegarty at oracle.com
Fri Aug 12 07:26:24 PDT 2011


Hi Petro,

These variables are defined by the SCTP RFC itself, but the SCTP 
implementation in the JDK does not directly implement this RFC. It 
builds on top of the native OS implementation, and this exposes itself 
through the Socket Extension API (internet draft) [1]. So we can only 
alter whatever is exposed by this API.

Retransmission Timeout Parameters are controlled by the SCTP_RTOINFO 
socket option. I haven't looked into others. It should be possible to 
add support for this, but I haven't yet tested to see if it is 
implemented on the major platforms, Solaris & LKSCTP.

What I found when initially working on the Java SCTP implementation was 
that the native OS support in different platforms conforms to different 
levels of this internet draft. And most OS implementers are reluctant to 
rev their implementation now until the internet draft is finalized and 
an RFC published. This is long overdue, but I don't full understand what 
there process is, or what the complications are. I need to follow up 
with my contacts there.

So your requirements so far is for the ability to set:
   SCTP_RTOINFO
   Traffic Class

-Chris.

[1] http://tools.ietf.org/html/draft-ietf-tsvwg-sctpsocket-31

On 03/08/2011 11:40, Petro Flomin wrote:
> Hi Chris,
> Thanks for your email, I have few comments:
>
> The sysctl parameters are actually exposing some of the Parameters
> described in RFC, could be syntax and names are different but they are
> listed in RFC (chapter 14):
>     RTO.Initial              - 3  seconds
>     RTO.Min                  - 1  second
>     RTO.Max                 -  60 seconds
>     RTO.Alpha                - 1/8
>     RTO.Beta                 - 1/4
>     Valid.Cookie.Life        - 60  seconds
>     Association.Max.Retrans  - 10 attempts
>     Path.Max.Retrans         - 5  attempts (per destination address)
>     Max.Init.Retransmits     - 8  attempts
>     HB.interval              - 30 seconds
>
>
> The question is it possible to have possibility to manage these
> parameters per socket and not globally? Please note we want to set these
> parameters upon creating socket and they shouldn't be changed during
> live process.
>
> Thanks,
> Petro
> -----Original Message-----
> From: Chris Hegarty [mailto:chris.hegarty at oracle.com]
> Sent: Tuesday, August 02, 2011 2:24 PM
> To: Michal Lefler
> Cc: sctp-dev at openjdk.java.net; Gil Shafran; Lenny Ridel; Petro Flomin
> Subject: Re: [sctp-dev] Setting "Traffic Class" to a SctpChannel
>
> On 8/1/2011 9:29 AM, Michal Lefler wrote:
>> Chris.
>> Thanks for your response.
>> We are indeed interested in configuring the different SCTP parameters
>> since it makes a significant difference in how the associations
>> function in different scenarios (channel failover etc.).
>> SCTP is very sensitive to the network condition and we interconnect
>> different associations with different network condition, so we should
>> be able to configure profile per each remote association.
>> We would like to configure each server accepted channel differently.
>> Is this possible?
>
> Socket-level options can be configured per accepted channel, but I'm not
> sure if this is what you are really looking for.
>
>> We would like to be able to configure the traffic class.
>
> Currently this is not supported, but I don't see any problem with
> supporting it. I'll file a bug in our bug database for this.
>
>>
>> In addition, we are very interested to be able to configure the
>> following parameters:
>> * net.sctp.sack_timeout
>> * net.sctp.prsctp_enable
>> * net.sctp.addip_enable
>> * net.sctp.rto_beta_exp_divisor
>> * net.sctp.rto_alpha_exp_divisor
>> * net.sctp.cookie_preserve_enable
>> * net.sctp.hb_interval
>> * net.sctp.max_init_retransmits
>> * net.sctp.path_max_retrans
>> * net.sctp.rcvbuf_policy
>> * net.sctp.sndbuf_policy
>> * net.sctp.association_max_retrans
>> * net.sctp.max_burst
>> * net.sctp.valid_cookie_life
>> * net.sctp.rto_max
>> * net.sctp.rto_min
>> * net.sctp.rto_initial
>>
>> and in a lower priority:
>> * net.sctp.sctp_wmem
>> * net.sctp.sctp_rmem
>> * net.sctp.sctp_mem
>
> These sysctl variables are not part of any RFC and I guess are
> implementation specific to LKSCTP. Most are not appropriate to a higher
> level API like Java, we could not provide consistent cross platform
> support. Also it is not clear to me the implication of setting some of
> these variables on a live process, e.g. can you enable/disable Dynamic
> Address Reconfiguration support per association?
>
> -Chris.
>
>>
>> Thanks,
>> Michal.
>>
>>
>> -----Original Message-----
>> From: Chris Hegarty [mailto:chris.hegarty at oracle.com]
>> Sent: Tuesday, July 12, 2011 12:35 PM
>> To: Michal Lefler
>> Cc: sctp-dev at openjdk.java.net
>> Subject: Re: [sctp-dev] Setting "Traffic Class" to a SctpChannel
>>
>> On 07/ 7/11 03:09 PM, Michal Lefler wrote:
>>> Hi.
>>> Is there a way in which I can set the traffic class to a
>>> com.sun.nio.sctp.SctpChannel instance?
>> Currently there is no way of setting the traffic class on an
>> SctpChannel. In our experience traffic class was not widely used and
>> there were no requests for supping it in SCTP.
>>
>> Since socket options are supported through the SctpSocketOption
>> interface and the channel can report its supported options,
>> supportedOptions(), then it may be possible to support implementation
>> specific options in the future.
>>
>> Is this something that is really important to you?
>>
>> -Chris.
>>
>>> I mean something similar to the TCP option:
>>> java.net.Socket.setTrafficClass(int tc);
>>>
>>> Thanks,
>>> Michal.
>>>
>
>


More information about the sctp-dev mailing list