Subject: [tsvwg] SCTP Socket API modification proposal

From: Florian Niederbacher <[email-masked]>
Date: Tue, 20 Oct 2009 21:52:28 +0200

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

---

From: Vlad Yasevich <[email-masked]>
Date: Tue, 20 Oct 2009 16:12:00 -0400

Florian

Adding anything to this option would break the ABI at this point
especially considering multiple uses of sctp_paddrinfo.

-vlad

---

From: Michael Tüxen <[email-masked]>
Date: Tue, 20 Oct 2009 22:50:26 +0200

> especially considering multiple uses of sctp_paddrinfo.
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.

Best regards
Michael

---

From: Yoshifumi Nishida <[email-masked]>
Date: Wed, 21 Oct 2009 14:11:59 +0900 (JST)

Hi, 
It's not very precise, but I think getting peer's rwnd by using SCTP_ASSOCINFO 
might be an alternative.

Thanks,
--
Yoshifumi Nishida
[email-masked]

From: Florian Niederbacher <[email-masked]>
Subject: [tsvwg] SCTP Socket API modification proposal
Date: Tue, 20 Oct 2009 21:52:28 +0200
Message-ID: <[email-masked]>

---

From: Florian Niederbacher <[email-masked]>
Date: Wed, 21 Oct 2009 12:33:39 +0200

>> 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.

> 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.

Best regards
Florian

---

From: Vlad Yasevich <[email-masked]>
Date: Wed, 21 Oct 2009 10:34:09 -0400

> 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

---

From: Florian Niederbacher <[email-masked]>
Date: Wed, 21 Oct 2009 21:00:47 +0200

> applications periodically poll with either SCTP_STATUS or PEER_ADDR_INFO.
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? 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

---

From: Vlad Yasevich <[email-masked]>
Date: Wed, 21 Oct 2009 15:17:49 -0400

Florian Niederbacher wrote:
> 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:
> 
> 
>   Upon detection of packet losses from SACK (see Section 7.2.4
> <http://tools.ietf.org/html/rfc4960#section-7.2.4>), an

---

From: Randy Stewart <[email-masked]>
Date: Sat, 24 Oct 2009 08:13:54 -0400

I too agree, we can't be changing these structures anymore.. there is
just too many issues with ABI ;-)

I also agree that what these apps actually want is a logging framework  
(as
discussed in the rest of this thread).. and you are right Michael we  
have
such a thing in FreeBSD... which is specific to the O/S.

Its unfortunate we cannot come up with something that would be more
"standard"... It might also be a bit difficult to add things that would
"wake up" and give you event changes. Often times such an interface  
could
slow the system or overload the buffering....

Hmm I wonder if there would be some way to create a "standard trace  
buffer", that
could be pulled with a unified socket API proposal..

And then also add some "tracing" structures. Of course I would think
this would really need to be a separate API document..

Just a thought

R

>>> these value and return it with the SCTP_GET_PEER_ADDR_INFO socket  

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