Subject: RE: [Tsvwg] SCTP query

From: [email-masked]
Date: Fri, 28 Sep 2001 15:11:14 +0300

Hi Vakul!

> Hi
> 
> I am having some doubt regarding the RTO calculation in SCTP.
> 
> Suppose two SCTP instances SCTP1 and SCTP2 have established
> an association. SCTP1 is transferring DATA chunks to SCTP2.
> 
> Let DATA chunk with TSN = 49 is sent by SCTP1.
> SACK is sent by SCTP2 with cummulative TSN = 49 and arwnd = 0.
> Assume RTO at SCTP1 is RTO.min at this point of time.
> 
> When arwnd of SCTP2 is 0, SCTP1 is allowed to send one data chunk
> to probe any change in the window at SCTP2.

	In the example, there isn't any TSN in flight, so you are allowed,
yes...

> So another chunk is sent by SCTP1 which has TSN = 50.
> An SACK again is sent by SCTP2  with Cummulative TSN = 49 arwnd = 0.
> 
> When SCTP1 receives this chunk, it discards it as TSN = 49 has already
> been acknowledged.

	Well, it actually processes it, for example to check arwnd... But in
this case the overall process can be summarized: the received SACK doesn't
change anything...

> After timeout, TSN = 50 would be retransmitted by SCTP1. As this
> happens, exponential backoff algoritm is applied to recalculate the
> value of RTO. Let again SACK with Cummulative TSN = 49 and arwnd = 0
> arrive. Thus more timeout happen and we end up increasing the RTO
> to some value RTO.max.

	Yes...

> My understanding about RTO is that it is increased 
> exponentially in the
> anticipation that the network has got congested. In this 
> situation, the network
> has not got congested, but due to temporary problem at 
> receiving SCTP2,
> RTO is being increased incorrectly at sending SCTP1.

	Well, there is congestion... Not at the network but at the receiver
side... Its buffer is full... There are two kinds of congestion, the one
that cwnd and ssthresh tries to avoid (congestion in the network) and the
one rwnd tries to avoid (congestion at the receiver). In any of these two
cases your transmission is not progressing and the datagrams are being
dropped somewhere, so it makes sense reducing your sending rate as you are
wasting bandwidth...

> Please correct me where I am wrong.

	I don't think you are wrong at all... Maybe somebody else can
correct us... :-)

> Regards
> Vakul
> Hughes Software Systems

	BR Iván Arias Rodríguez

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

---

From: "Armando L. Caro Jr." <[email-masked]>
Date: Fri, 28 Sep 2001 08:54:40 -0400 (EDT)

> > arrive. Thus more timeout happen and we end up increasing the RTO

Hmm... I couldn't find any text in the rfc which addressed this scenario,
but I think modifying the RTO due to dropped probes is the wrong thing to
do.

> dropped somewhere, so it makes sense reducing your sending rate as you are

Yes... When the receiver's buffer is full, it makes sense to reduce the
sending rate, but NOT increase the RTO.  There is no relationship between
the status of the receiver's buffer and the RTT.

> 	I don't think you are wrong at all... Maybe somebody else can

I don't think it is wrong to say that this is what would happened if the
rfc is followed. HOWEVER, I do think it is the wrong thing to do.

~armando

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