Re: [tsvwg] SCTP Socket API modification proposal

[Vlad Yasevich <vladislav.yasevich at hp.com>]

Florian Niederbacher wrote:
> Michael Tüxen schrieb:
>> On Oct 20, 2009, at 10:12 PM, Vlad Yasevich wrote:
>>
>>> Florian
>>>
>>> Adding anything to this option would break the ABI at this point
>>> especially considering multiple uses of sctp_paddrinfo.
>>>
> Ok, I thought that it wouldn't such a big effort to add an additional
> value to the structure therefore also the question.
> 
>>> -vlad
>> I second that. I do not want to change structures anymore...
>> ... and I do not think that adding ssthresh helps much. When
>> I'm interested in these values, I'm also interested in any change
>> of them. So you need some kind of logging infrastructure.
>> FreeBSD, for example, has such a infrastructure, but it is
>> system specific. Other OSes might have similar things.
> 
> I agree to build a logging infrastructure for getting changes in
> userspace only polling is possible and is never such useful as a kernel
> hook.
> Thanks for your comments.

If you want asynchronous notifications, that might be more useful.  Something
that notifies the user when congestion window changes or congestion events
occur.

It seem that there is a subset of applications that want to know congestion
state.  I am not sure why (may be logging purposes).  Right now, these
applications periodically poll with either SCTP_STATUS or PEER_ADDR_INFO.

-vlad

> 
> Best regards
> Florian
> 
>>
>> Best regards
>> Michael
>>>
>>> Florian Niederbacher wrote:
>>>> Hi,
>>>> what thinks the community and the SCTP developers about an additional
>>>> value in SCTP_GET_PEER_ADDR_INFO ?
>>>>
>>>> TCP allows to retrieve values about the congestion control with
>>>> TCP_INFO. The cwnd value can be retrieved from both(SCTP and TCP),
>>>> but the
>>>> ssthresh value in SCTP is missing. I guess it would make sense to add
>>>> these value and return it with the SCTP_GET_PEER_ADDR_INFO socket
>>>> option.
>>>>
>>>> Regards
>>>> Florian Niederbacher
>>>>
>>>
>>
>