Subject: [Tsvwg] Increase of cwnd in SCTP.

From: [email-masked]
Date: Wed, 15 May 2002 20:59:20 +0300

Hi all!

	This is something that most probably you know, but let's see what do you think about it... I don't think it is a big problem in any case...

	The point is that the congestion avoidance algorithms of SCTP have been taken directly from those of TCP, and sometimes the adaptation cannot be perfect...

	In TCP, when the cwnd must be increased, it is increased either by the total amount of acknowledged bytes in the acknowledgement or by one SMSS (the MTU minus the IP and TCP headers) whichever is smaller. In SCTP, instead of using the SMSS we use the MTU... And this is the problem...

	The length of the headers of the DATA chunks are not included in that quantity. Thus, if we are sending small DATA chunks (i.e., more than one per packet), the difference between the "acknowledgeable data" inside the packet, and the actual length of the packet, can lead us to send datagrams with really few bytes of data... I'll explain this with an example...

	Imagine the MTU is 1500. Imagine the user messages are 512 bytes long, and we use IPv4. Initially the cwnd is set to 2*MTU, i.e. 3000... So we start bundling DATA chunks. In the first chunk we include: 20 (IP header) + 12 (SCTP header) + 16+512 (DATA Chunk) + 16+512 (DATA Chunk) + 16+396 (DATA Chunk) = 1500 bytes. In the second datagram we include: 20 + 12 + 16+116 + 16+512 + 16+512 + 16+264 = 1500 bytes. So far we have sent 512*5 + 264 = 2824 of user data... We can still send at least 176 bytes, so we send a third datagram with the rest of the last user message, i.e.: 20 + 12 + 16+248 = 296 bytes, and we surpass the value of cwnd so we don't send anything else... And this is just at the very beginning. This behavior is kept during the data transmission, making that the last of the SCTP datagrams originated upon the receipt of a SACK datagram is smaller (sometimes much smaller) than the MTU...

	This is just a quick and simple example that I have observed while making some tests, and I'm sure you all already noticed it... The problem is that, as the DATA chunk headers (and IP/SCTP headers) are not included in the cwnd. Thus when a packet is acknowledged, the user data inside this packet is always smaller than the MTU... This causes, for example, that if the user messages are big enough, at the beginning we will always send 3 packets (of one MTU each, i.e.: 3*(MTU - IP/SCTP/DATA headers) bytes of data), instead of 2 packets, which is, as far as I know, the idea... In any case we are always allowed to send three packets (the two first being "full" ones)...

	The only way I can think about now to overcome this problem is to define an SMSS for SCTP as the MTU - IP/SCTP headers, and include the DATA chunk headers in the calculation of the flight size and the cwnd... :-/ In any case, most of the information contained in the DATA chunk header must be kept as well until the data is delivered to the upper user (this does not happen in TCP)... In this way we could send SCTP datagrams that perfectly fit in the MTU, which is what we are looking for...

	However, I don't know if this is a big problem at all... Maybe the experts could send their comments regarding this issue...

	Thanks!!

	BR Iván Arias Rodríguez

_______________________________________________
tsvwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tsvwg

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 15 May 2002 13:47:06 -0500

Ivan.Arias-Rodriguez,

What did you think was a problem?  The algorithm still exhibits
additive increase and exponential decrease.

--brian

-- 
Brian F. G. Bidulock    ¦ The reasonable man adapts himself to the ¦
[email-masked]    ¦ world; the unreasonable one persists in  ¦
http://www.openss7.org/ ¦ trying  to adapt the  world  to himself. ¦
                        ¦ Therefore  all  progress  depends on the ¦
                        ¦ unreasonable man. -- George Bernard Shaw ¦

---

From: "Armando L. Caro Jr." <[email-masked]>
Date: Wed, 15 May 2002 16:11:21 -0400 (EDT)

On Wed, 15 May 2002 [email-masked] wrote:

> The problem is that, as the DATA chunk headers (and IP/SCTP headers)
> are not included in the cwnd. Thus when a packet is acknowledged, the
> user data inside this packet is always smaller than the MTU... This
> causes, for example, that if the user messages are big enough, at the
> beginning we will always send 3 packets (of one MTU each, i.e.: 3*(MTU
> - IP/SCTP/DATA headers) bytes of data), instead of 2 packets, which
> is, as far as I know, the idea... In any case we are always allowed to
> send three packets (the two first being "full" ones)...

Yes, I agree with you... the idea is that only 2 packets should be sent.

> 	The only way I can think about now to overcome this problem is
> to define an SMSS for SCTP as the MTU - IP/SCTP headers, and include
> the DATA chunk headers in the calculation of the flight size and the
> cwnd... :-/ In any case, most of the information contained in the DATA
> chunk header must be kept as well until the data is delivered to the
> upper user (this does not happen in TCP)... In this way we could send
> SCTP datagrams that perfectly fit in the MTU, which is what we are
> looking for...

Yes, your solution is correct as far as I am concerned. In fact, I always
made the assumption that this was what the RFC implied. Hence, that is how
our ns-2 implementation works. The cwnd, flight size, etc are all based on
the entire data chunks including their headers.

> 	However, I don't know if this is a big problem at all... Maybe
> the experts could send their comments regarding this issue...

I think it is a big deal, because otherwise the cwnd has little control.
The cwnd is meant to give an estimate of what is allowed in flight.
However, if the sender can put more bytes on the wire simply because it is
sending smaller data chunks, then cwnd has no function. In terms of
congestion, the network cares about absolute bytes on the wire...
congestion doesn't distinguish application bytes from headers.

Suppose the sender's cwnd is 2 MTUs. This means that the sender can send
a total of 2MTUs on the wire. Let's suppose that the MTU is 1500 bytes and
we are using IPv4. Hence, subtracting the IPv4 header/SCTP headers, the
sender can fill the packet with 1468 bytes worth of chunks. It doesn't
matter if there is 1 big data chunk or many small data chunks.... it is
1468 bytes that are allowed. Obviously, many small data chunks will have
higher overhead and not get as much application data through, but that is
too bad.

However, suppose an SCTP implementation _incorrectly_ uses 1468 to gate
how much application data can be sent without regard to chunk header info.
Also suppose the application sends 128 byte messages. The bad
implementation will say it can send 11 data chunks of 128 application
bytes each. But each data chunk is actually 144 bytes when you include the
chunk headers.  Hence, the sender will send 1584 bytes for every 1468
bytes allowed to be sent. This is clearly wrong!

Maybe 116 bytes of difference doesn't seem significant, but consider when
the cwnd is say 10 MTUs. These are all examples, but the issue is that
cwnd's purpose fades. For any given cwnd, the sender will be able to send
a variety of different amounts depending on the size of the data chunks.

You may be thinking as Brian is thinking...

On Wed, 15 May 2002, Brian F. G. Bidulock wrote:

> The algorithm still exhibits additive increase and exponential
> decrease.

Yes, it does... but what does cwnd mean if you don't count data chunk
headers? The AIMD algorithm accounts for IP headers and for SCTP's common
header. You may not realize it since these headers are fixed for the
lifetime of the association. Just because the number of bytes made up
by data chunk headers is not fixed, doesn't mean they shouldn't be
accounted for.

~armando

0--                                                --0
| Armando L. Caro Jr.     |       [email-masked] |
| University of Delaware  |  www.cis.udel.edu/~acaro |
0--                                                --0

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 15 May 2002 15:41:13 -0500

Armando,

> congestion doesn't distinguish application bytes from headers.

So why is the IP header and TCP/SCTP header subtracted?

--brian

---

From: Randall Stewart <[email-masked]>
Date: Wed, 15 May 2002 19:33:02 -0500

Armando:

I think you and Ivan forget one key thing here...

SCTP will NOT increase its cwnd unless flightsize >= cwnd.

TCP increases 1 MTU (in slow start) per ack ... this is
discounting other proposal's by Mark.. 

I don't see slopping over up to 1 MTU is going to
hurt you... 

The key here is as Brian put it.. we are using additive
increase and multiplicative backoff..

There are enough other differences where TCP puts more
bytes on the wire (such as the one above) to more
than compensate...

It all comes out in the wash I think..

R

-- 
Randall R. Stewart
[email-masked] 815-342-5222 (cell phone)