Subject: [Tsvwg] RFC4960 chapter 6.2.1

From: Andrey Konstantinov <[email-masked]>
Date: Fri, 27 Feb 2009 14:44:58 +0300

Hi,

Could you help me to interpret the rule from RFC4960 correctly?

There is a rule:
   A) At any given time, the data sender MUST NOT transmit new data to
      any destination transport address if its peer's rwnd indicates
      that the peer has no buffer space (i.e., rwnd is 0; see Section
      6.2.1).  However, regardless of the value of rwnd (including if it
      is 0), the data sender can always have one DATA chunk in flight to
      the receiver if allowed by cwnd (see rule B, below).  This rule
      allows the sender to probe for a change in rwnd that the sender
      missed due to the SACK's having been lost in transit from the data
      receiver to the data sender.

Let me consider the example:

Initial ARWND = 400;
Local SCTP --> DATA(100 bytes, TSN1) --> Remote SCTP
Local SCTP --> DATA(100 bytes, TSN2) --> Remote SCTP
Local SCTP --> DATA(100 bytes, TSN3) --> Remote SCTP
Local SCTP --> DATA(100 bytes, TSN4) --> Remote SCTP
Local SCTP <-- SACK(Acknowledges TSN3, RWND is 200) <-- Remote SCTP
Local SCTP has inflight 100 bytes after SACK processing: 200 (RWND) -
100 (inflight) = 100 bytes can be sent
Local SCTP --> DATA(90 bytes, TSN5) --> Remote SCTP ------ valid
transmission, 100 - 90 = 10 bytes left
Local SCTP --> DATA(90 bytes, TSN5) --> Remote SCTP ------ ?, 0 bytes
left, not send more

Is the last transmission valid? Can local SCTP transmit it? OR it is
not alllowed?

Thanks in advance,
Andrey Konstantinov

---

From: Randy Stewart <[email-masked]>
Date: Fri, 27 Feb 2009 07:20:27 -0500

> Is the last transmission valid? Can local SCTP transmit it? OR it is

Hmm.. interesting point. In the case of TCP, TCP would just
send 10 bytes. In the case of SCTP this is not possible (although
TCP would most likely NOT send it anyway due to SWS avoidance).

I think one should take the more conservative approach here
and NOT send it. That send would put you over the receivers
rwnd so its likely the receiver will discard it. You have
data in flight, so why send it.

As long as there is a TSN in flight then you WILL get an
update eventually... i.e.

<-----SACK(TSN5, rwnd=XXX)

Should be coming shortly.

You must also remember, most implementations also implement a silly  
window
syndrome avoidance.. in the case of BSD we do this .. and if you do that
this situation would not arise.. i.e. you would not even think about
sending 10 bytes. Can't remember the RFC that talks about SWS but it
is something you should look at too. Basically you subtract a bit
extra off of the rwnd (its a bit more than that and I would suggest
you look through the RFC's and find the details they escape me
at the moment :D )...

R

> Andrey Konstantinov

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

---

From: Andrey Konstantinov <[email-masked]>
Date: Fri, 27 Feb 2009 16:37:35 +0300

Hi,

Thanks for your answer.

Our SCTP implementation supports SWS.
   It adjusts RWND when reports it in SACK: it reports zero OR nonzero
value which is much more than PMTU.
   Also, it adjusts RWND received from remote side in SACK: it zeros
received ARWND if it is too small OR it keeps unchanged if it is much
more than PMTU

The question is about sending DATA chunk when ARWND is almost consumed
and there is small bytes left.
  Of course, 10 bytes will not be sent if the next outgoing chunk is
90 bytes (as it is in my example), i.e. new chunk (10 bytes) will not
be fragmented from already created chunk (90 bytes)...
The question is how to consider RWND threshold: is it allowed to
transmit more bytes than RWND value which is declared by remote side
in last received SACK?

For example (cwnd and SWS are not considered here):
1. Reported RWND is 200 bytes
2. There is 100 bytes inflight after SACK procesing
3. SCTP can send 90 bytes because RWND threshold has not been reached
OR exceeded: [90 (new data) < 200 (RWND) - 100 (inflight)]. But can
SCTP send TWO data chunks (both with 90 bytes of ULP data) in these
conditions?
90 < 100  - the first chunk is sent
180 > 100 - the second chunk is sent, stop sending due to RWND exceeded

Thanks in advance,
Andrey Konstantinov

2009/2/27 Randy Stewart <[email-masked]>:
> You must also remember, most implementations also implement a silly window

---

From: Randy Stewart <[email-masked]>
Date: Fri, 27 Feb 2009 08:43:30 -0500

I think the strict answer is NO you cannot
transmit in that situation.

Again, because MOST LIKELY the peer will discard your packet.

R

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

---

From: Andrey Konstantinov <[email-masked]>
Date: Fri, 27 Feb 2009 16:43:34 +0300

Just a comment.
According to your answer it is RECOMMENDED not to send the second chunk.
BUT is it prohibited (MUST NOT) or recommended (SHOULD NOT) by RFC4960?

---

From: Randy Stewart <[email-masked]>
Date: Fri, 27 Feb 2009 09:09:29 -0500

Hmm.. well if you want to be legalistic.

It does say:

A) At any given time, the data sender MUST NOT transmit new data to
    any destination transport address if its peer's rwnd indicate
    that the peer has no buffer space (i.e., rwnd is 0; see Section  
6.2.1).

Now the qualification in the second part (one chunk in flight) is  
true.. i.e
in your example TSN 4 is still in flight. If you send the next 90 bytes
TSN 5, then you WILL have MORE than the peers rwnd in flight. This
violates the MUST NOT.

So I would say its a violation of the spec..

R

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