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

From: Sridhar Samudrala <[email-masked]>
Date: Tue, 28 May 2002 12:04:26 -0700 (PDT)

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.

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

Thanks
Sridhar

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

---

From: [email-masked]
Date: Fri, 31 May 2002 01:23:39 +0300

> -----Original Message-----
> From: ext Sridhar Samudrala [mailto:[email-masked]]
> Sent: 29. May 2002 22:00
> 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 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
> > > 
> > > 
> > > > >    ---------
> > > > 	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...
> 
> I should have said that T1 and T2 are transport addresses on 
> 2 different 
> associations and hence they are independent. 

	Ok...

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

	Very interesting...

	Actually I made a comment about this couple of weeks ago or so... However, my point was that when starting the association, for this same reason, you would always send three packets instead of two... Now I have realized about this... You are limited to send just one packet when you start retransmitting (if possible to a secondary address)... so you are very likely not to increase the cwnd upon receipt of the acknowledgement for that packet (the only case I can think about is if the flightsize of a secondary address is not zero, which shouldn't be the normal case).

	I suggested to change the way the bytes sent are counted, to include the headers... Somehow similar as in TCP and its MSS...

	In any case, if you are thinking about two single-homed associations, you are right...

> > > Now T1 tries to send 3 full sized data chunks immediately, 
> > 
> > 	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, if the cwnd is set to 1*MTU (for the reason stated above), then you will only be able to send up to 2*MTU...

	But your idea is right: if the cwnd is set to X*MTU, you are always able to send at least X+1 full packets...

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

	But you must always set a limit... :-/

> > > 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...
> 
> I agree that it doesn't make much of a difference. 

	The algo could be changed to min(max(cwnd/2, 2*MTU), cwnd), to solve this situation but at the end the difference should be really small... :-/

	BR Iván Arias Rodríguez

> > 	BR Iván Arias Rodríguez
> > > > 	BR Iván Arias Rodríguez