Subject: Re: [Tsvwg] Increase of cwnd in SCTP.

From: Randall Stewart <[email-masked]>
Date: Thu, 16 May 2002 07:59:03 -0500

[email-masked] wrote:
> 
>         Hi all!
> 
>         Some comments inline...
> 
> > -----Original Message-----
> > From: ext Randall Stewart [mailto:[email-masked]]
> > Sent: 16. May 2002 3:33
> > To: Armando L. Caro Jr.
> > Cc: Arias-Rodriguez Ivan (NRC/Helsinki); [email-masked]
> > Subject: Re: [Tsvwg] Increase of cwnd in SCTP.
> >
> >
> > Armando:
> >
> > I think you and Ivan forget one key thing here...
> >
> > SCTP will NOT increase its cwnd unless flightsize >= cwnd.
> 
>         Yes, I know that due to DATA chunk sizes, most probably your flightsize will be > than cwnd...
> 
> > TCP increases 1 MTU (in slow start) per ack ... this is
> > discounting other proposal's by Mark..
> 
>         Kind of... TCP uses SMSS instead of MTU...
> 
Yeah.. but that almost always boils down to PMTU == SMSS... with
few exceptions I think...

> > I don't see slopping over up to 1 MTU is going to
> > hurt you...
> 
>         No, that's not the only problem... As shown, initially, if the data sender has enough data to send, it will always send at least three packets... And in general, you send one more packet than expected (this situation changes during the data transfer), being that last one a small packet, with a lot of overhead... which could trigger a SACK back as well... I think it would be better to count those header bytes as Armando said (as it is actually done in TCP).
> 

My implementation actually does it this way :> it was simpler...
yet I don't see how it helps you.. If the MTU is say 1500
and I send 1480 (assume IPv4) and 1480... we still are
smaller than 3000 and will have 40 bytes of room left...

Unless you are suggesting to count the IP header overhead too.. and
I don't think TCP does this... I could not agree with this...

Note to Aramando: mail sent to you directly rejects.. not sure why...

>         I would even suggest to count them not only for cwnd but also for the rwnd. The point is that unless you are receiving DATA Chunks belonging to a fragmented user message, apart from the user data, you must also keep the values of the Stream Identifier, Stream Sequence Number, Payload Protocol Identifier and the flags, until you deliver that data to the upper user... So, that information is using some memory space as well at the receiver...
> 

Now I don't see counting them in the rwnd. rwnd is the amount of DATA
space
that the peer is giving you to send. It does not include the overhead
and
I don't see that it does in TCP either. One does not keep the mbuf sizes
added in to the overhead of the rwnd calculation. There IS a collapsing
that does occur if you get a lot of mbufs allocated... the mbuf totals
can override the space used by the data.. but for TCP this generally
does not occur...

> > The key here is as Brian put it.. we are using additive
> > increase and multiplicative backoff..
> 
>         Yes.
> 
> > There are enough other differences where TCP puts more
> > bytes on the wire (such as the one above) to more
> > than compensate...
> 
>         Yes, I don't think that the only problem is that you are allowing to send more or less data. The point is that you don't send them in full packets... :-/ I think that the cost for the network of a packet 10 times smaller than the MTU is not precisely 10 times lower... So we should try to send MTU-sized datagrams...
> 
>         In any case, I could live with the present mechanism... :-)
> 
>         Thanks for your comments!
> 
>         BR Iván Arias Rodríguez

But a smaller packet I think does cost less.. maybe not 10 times less..
but
it does cost less..

Now even more so look at what we are talking about... on average
it must be an elephant.. .not a mouse. Elephants typcially
have LOTS of data to send ... so say it  is a file transfer.. I am
reading 

1400 byte blocks.. and writing them ....--

The send queue will be FULL of 1400 byte blocks.. (more likely 1k but
lets say we optimized for SCTP)... in this case guess what
the third packet will be full sized..

I just don't see the majority being:
writing...
1400/1400/200

This I think is a rarity.. it is more
likely you are doing

1400/1400/1400/.../1400

R

> 
> > It all comes out in the wash I think..
> >
> > R
> >
> >
> > "Armando L. Caro Jr." wrote:
> > >
> > > 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
> > >
> > > _______________________________________________
> > > tsvwg mailing list
> > > [email-masked]
> > > https://www1.ietf.org/mailman/listinfo/tsvwg
> >
> > --
> > Randall R. Stewart
> > [email-masked] 815-342-5222 (cell phone)
> >

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

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

---

From: [email-masked]
Date: Thu, 16 May 2002 14:55:43 +0300

Hi all!

	Some comments inline...

	Yes.

	BR Iván Arias Rodríguez

---

From: "Armando L. Caro Jr." <[email-masked]>
Date: Thu, 16 May 2002 10:32:05 -0400 (EDT)

> I don't think TCP does this... I could not agree with this...

I was not suggesting that.

Anyway, after thinking about it some more... I realize that it really
isn't a big deal as you and Brian have suggested. It will only be a
*slight* problem in some corner cases, which I don't think are even worth
worrying about.

However, I still do believe that counting the chunk headers is the right
thing to do. But maybe it isn't a big enough deal to make it a
requirement?

> Note to Aramando: mail sent to you directly rejects.. not sure why...

hmmm... You had this problem a while back with Jana too, right? Did you 2
ever figure this one out? Maybe it is related somehow?? (ie, I have no
clue what the prob could be!) Can you try a couple of my aliases:
[email-masked], [email-masked]

~armando

0--                                                --0