Re: [tsvwg] SCTP Socket API modification proposal

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

Florian Niederbacher wrote:
> Vlad Yasevich schrieb:
>>
>> 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
>>
> Yes that's exactly what I am also doing to log the congestion state.
> (but the ssthresh in SCTP is missing)
> In this way I have also noticed following:
> 
> After a data transmission is stopped because of the end of file, but the
> connection is already up (no close or shutdown)
> the cwnd value is immediately set back to 4*MTU (4*1500 = 6000) also if
> the cwnd was during the transmission at the maximum of
> the receiver window.(e.g. 130000 - no loss). TCP holds the cwnd value
> over a defined time always at the old value (max. cwnd = 130000).
> 
> Is this value setting in SCTP intended?

No, the intended behavior is at the end of section 7.2.1.

-vlad


> Maybee I interpret the chapter
> 7.2.3 of RFC 4960 wrong. But I guess the value should be set at least to
> cwnd/2
> (130000/2 = 65000 and this is higher as the 4*MTU) after a transmission
> stops. The benefit is if you continue after some seconds with another
> data transmission maybe on another stream but on the same connection you
> have a higher cwnd value and therefore a higher throughput rate.
> 
> cite from RFC 4960:
> 
> 
>        7.2.3. Congestion Control
> 
> 
> 
>   Upon detection of packet losses from SACK (see Section 7.2.4
> <http://tools.ietf.org/html/rfc4960#section-7.2.4>), an
>   endpoint should do the following:
> 
>      ssthresh = max(cwnd/2, 4*MTU)
>      cwnd = ssthresh
>      partial_bytes_acked = 0
> 
>   Basically, a packet loss causes cwnd to be cut in half.
> 
>   When the T3-rtx timer expires on an address, SCTP should perform slow
>   start by:
> 
>      ssthresh = max(cwnd/2, 4*MTU)
>      cwnd = 1*MTU
> 
>   and ensure that no more than one SCTP packet will be in flight for
>   that address until the endpoint receives acknowledgement for
>   successful delivery of data to that address.
> 
> 
> 
> Best regards
> Florian
> 
>>> 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
>>>>>>
>