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

From: [email-masked]
Date: Wed, 29 May 2002 21:13:02 +0300

Hi again!

	See my response below...

> -----Original Message-----
> From: ext Sridhar Samudrala [mailto:[email-masked]]
> Sent: 29. May 2002 20:31
> To: Arias-Rodriguez Ivan (NRC/Helsinki)
> Cc: [email-masked]; [email-masked]
> Subject: RE: [Tsvwg] queries on draft-ietf-tsvwg-sctpimpguide-05.txt
> 
> 
> On Wed, 29 May 2002 [email-masked] wrote:
> 
> > 	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.
> 
> Thanks for the clarification.
> 
> > 
> > >    ---------
> > >    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...
> 
> 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

	Well... this scenario is quite unrealistic... :-/

	If you have two destination transport addresses, as you can tell the SCTP implementation to which specific destination you want an user message to be sent, you could in theory be sending data to the two transport addresses at the same time... However, this is not the purpose of multihoming. You are supposed to send all the data to the primary address, and only use the rest (let's call them secondary addresses) if you must retransmit something...

	So, your case is theoretically correct, but I guess that it shouldn't be normal... But let's say that you reach to the situation in which both cwnd are set to 1 MTU because the timer expired, you retransmitted to the secondary address and the timer of that address also expired...

> are retransmitted. A delayed SACK is received for both of 
> them. The cwnd remains 
> 1 MTU.

	Why?... The cwnd should be already 1 MTU, the same as the flightsize, then upon receipt of the acknowledgement the cwnd should be increased by 1 MTU... :-/

> Now T1 tries to send 3 full sized data chunks immediately, 

	Why 3?... at most you could send cwnd...

> 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 

	I might be missing something... but I don't think so... After a retransmission and the receipt of a SACK, cwnd may be at most 2*MTU... :-/

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

	But in any case, one RTO is quite a long time... the RTT should be few hundredths of milliseconds, while RTO is at least one second... In that time, you are likely to receive the acknowledgement of the data sent...

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

	:-/

	I was happy with the Max(cwnd/2, 2*MTU)... :-)

	I think that the case you want to point out should be very rare (the "cwnd = 2*MTU" algo growing the cwnd)... Imagine that you have two addresses. The timer of the primary expires, and thus its RTO is set to 2 seconds (at least) and its cwnd will be set to 1*MTU. The secondary address will have its cwnd set to 2*MTU (it was unused) and its RTO set to 1 second...

	The RFC says that you are able to send only one MTU, so you do that to the secondary address (this brings an interesting issue... why limiting if the secondary address is not experiencing congestion?).

	To make a quick calculation let's consider that RTT is 125 ms, thus the "cwnd = 2*MTU" algo will grow cwnd if you need at least 16 RTTs to retransmit your DATA chunks... That means (taking into account the Max.Burst limitation):

	1*MTU + 2*MTU + (4*MTU)*13

	Which means that you need at least 55*MTUs + 1 byte of data... This seems to be quite a reasonable time, but you must think that most probably only one DATA chunk might be lost, and you will receive the acknowledgements of the first transmission of the chunks that must be retransmitted, and this will make things much faster...

	Summarizing, I think that after at least 2 seconds, having cwnd set to 2*MTU instead of 1*MTU should not hurt you... most likely because you will send something before those 2 seconds...

	BR Iván Arias Rodríguez

> Thanks
> Sridhar
> 
> > 
> > 	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 12:00:09 -0700 (PDT)

> 	If you have two destination transport addresses, as you can tell the SCTP implementation to which specific destination you want an user message to be sent, you could in theory be sending data to t…

I should have said that T1 and T2 are transport addresses on 2 different 
associations and hence they are independent. 

> 	Why?... The cwnd should be already 1 MTU, the same as the flightsize, then upon receipt of the acknowledgement the cwnd should be increased by 1 MTU... :-/

I am assuming that the data chunk size of an MTU sized SCTP packet will be little 
less than MTU (considering the headers).  Suppose MTU is 1500 and the data chunk
size is 1400. A SACK will increase the cwnd only when we are using the full cwnd
which is 1500, but the flight size is only 1400. So this should not increase the
cwnd if my understanding is correct. 

> 	Why 3?... at most you could send cwnd...

Again as i am assuming that a full sized data chunk will be little less that
MTU, we will be able to 3 data chunks when cwnd is 2*MTU.

> 	But in any case, one RTO is quite a long time... the RTT should be few hundredths of milliseconds, while RTO is at least one second... In that time, you are likely to receive the acknowledgement o…

If we are no longer experiencing congestion, we should get an acknowledgement.
But it is possible that we may not have recovered even after an RTO duration. 

> 	Summarizing, I think that after at least 2 seconds, having cwnd set to 2*MTU instead of 1*MTU should not hurt you... most likely because you will send something before those 2 seconds...

I agree that it doesn't make much of a difference.

---

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

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

> 	The RFC says that you are able to send only one MTU, so you do
> that to the secondary address (this brings an interesting issue... why
> limiting if the secondary address is not experiencing congestion?).

Yeah, I also wondered the same thing. I asked Randall about it, and his
response was that they (Randall & Vern) wanted to be conservative. Using
multihoming on the Internet means that there is no guarantee that the
different paths are completely disjoint. Therefore, it may be possible
that the bottleneck link is shared by both paths. So until more research
is done with multipath congestion control, this 'feature' will have to
remain.

~armando

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