Vlad Yasevich schrieb:
Yes that's exactly what I am also doing to log the congestion state. (but the ssthresh in SCTP is missing)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.-vladI 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
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? 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 FlorianBest regards MichaelFlorian 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