Subject: RE: [Tsvwg] queries on draft-ietf-tsvwg-sctpimpguide-05.txt

From: [email-masked]
Date: Wed, 29 May 2002 15:57:48 +0300

Hi Sridhar!

	See my comments inline...

> -----Original Message-----
> From: ext Sridhar Samudrala [mailto:[email-masked]]
> Sent: 28. May 2002 22:04
> To: [email-masked]
> Subject: [Tsvwg] queries on draft-ietf-tsvwg-sctpimpguide-05.txt
> 
> 
> I have a couple of queries on the latest sctp implementation 
> guide draft,
> draft-ietf-tsvwg-sctpimpguide-05.txt.
> 
> In section 2.14.2, 
> 
>    ---------
>    New text: (Section 6.1)
>    ---------
> 
>    D) When the time comes for the sender to transmit new DATA 
> chunks, the
>       protocol parameter Max.Burst MUST first be applied to 
> limit how many
>       new DATA chunks may be sent.  The limit is applied by 
> adjusting cwnd
>       as follows:
> 
>       if((flightsize + Max.Burst*MTU) < cwnd)
>          cwnd = flightsize + Max.Burst*MTU
> 
> I think this limit should be applied only when a SACK that 
> acks a fast retransmit 
> is received. The text indicates that the limit must be 
> applied whenever the
> sender wants to transmit new data.

	Originally, Max.Burst was applied only in the case of a SACK acknowledging fast retransmitted DATA Chunks. However, Max.Burst is now used always. Note that this is a modification to the general congestion control algorithm.

>    ---------
>    New text: (Section 7.2.1)
>    ---------
> 
>    o  When the association does not transmit data on a given 
> transport address
>       within an RTO, the cwnd of the transport address MUST 
> be adjusted to
>       2*MTU.
> 
> The above statement doesn't take the current cwnd of a 
> transport address into 
> consideration.  Even if the current cwnd is less than 2*MTU, 
> should it be 
> adjusted to 2*MTU?

	This has been changed in the last version. Previously it was Max(2*MTU, cwnd/2)...

	2*MTU is the value of an unused path. Cwnd could be as small as a single MTU, but this only happens when we are retransmitting, i.e., facing congestion. When we don't use that path, we consider that the congestion has been alleviated within an RTO.

	I think that this change is quite drastic... Maybe Randall or Armando can say more about this...

	BR Iván Arias Rodríguez

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

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

---

From: Sridhar Samudrala <[email-masked]>
Date: Wed, 29 May 2002 10:30:30 -0700 (PDT)

> 	Originally, Max.Burst was applied only in the case of a SACK acknowledging fast retransmitted DATA Chunks. However, Max.Burst is now used always. Note that this is a modification to the general co…

Thanks for the clarification.

> 	I think that this change is quite drastic... Maybe Randall or Armando can say more about this...

Suppose we have an association with 2 transport addresses(T1, T2) trying to send 
a data chunk and both of them experienced congestion causing retransmission 
timeout to go off. This will cause the cwnd to be reduced to 1 MTU and the chunks
are retransmitted. A delayed SACK is received for both of them. The cwnd remains 
1 MTU.

Now T1 tries to send 3 full sized data chunks immediately, while T2 waits for an 
RTO duration and then sends 3 full sized data chunks. 
If we follow the above algorithm, the transport address that waits for an RTO
time will be able to send all the 3 chunks, but the one which tries to send 
immediately can send only 2 chunks. As you said we can consider that the 
congestion is alleviated within an RTO. But it cannot be guaranteed.

May be a more reasonable and conservative way to adjust the cwnd of a transport 
address that is inactive is
	cwnd = min(cwnd, 2*MTU) 

Thanks
Sridhar

---

From: "Armando L. Caro Jr." <[email-masked]>
Date: Fri, 31 May 2002 16:12:03 -0400 (EDT)

Sorry for the late reponse to this thread...

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

> 	Originally, Max.Burst was applied only in the case of a SACK
> acknowledging fast retransmitted DATA Chunks. However, Max.Burst is
> now used always. Note that this is a modification to the general
> congestion control algorithm.

Yes, this change was made to avoid bursts at any time. Max.Burst was left
as a parameter, because we don't really know what an acceptable burst
is... 4 was a reasonable number chosen earlier, so we stuck with it.

> 	2*MTU is the value of an unused path. Cwnd could be as small as
> a single MTU, but this only happens when we are retransmitting, i.e.,
> facing congestion. When we don't use that path, we consider that the
> congestion has been alleviated within an RTO.
>

It does seem drastic, but it is actually the correct thing to do. The idea
is "use it or lose it". The ack clock provides feedback to the sender
that the current cwnd is acceptable. If the sender becomes idle for a
significant amount of time (ie, an RTO), the sender can no longer assume
that the same cwnd is acceptable. Since ssthresh isn't touched, the sender
can slow start back up to the previous cwnd when the sending
application has more to send again.

The mechanism is no different than a timeout. The reason the sender begins
from slow start is because the ack clock is lost. Otherwise, the cwnd
would just be cut in half as is done with fast retransmit.

Now, whether it should be 2*MTU or 1*MTU... That may be debatable, but I
figured that 2*MTU was more consistent... 1*MTU is used only after a
timeout.

For more info, you may want to refer to emails in the archive... Mark
Allman and I advocated the changes with Max.Burst in early March (I
think).

~armando

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