Subject: RE: [Tsvwg] Retransmission Query

From: [email-masked]
Date: Mon, 8 Apr 2002 16:23:16 +0300

Hi Arun, Kashif and the rest of the people of the list!

	Let's see if I can make things clearer...

	By the way, there is a 04 version since the end of January...

> hi kashif,
>     Comments inline...
> 
> "Khan, Mohammad" wrote:
> 
> > Hi All,
> > Following is the querry regarding retransmission 
> improvement described in
> > section 2.8 of
> > 
> http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-sctpimpgu
> ide-03.txt .
> > What is the difference between normal retransmission and fast
> > retransmission?

	Well, there are two reasons why you should retransmit a TSN. One of them is due to the Fast Retransmit algorithm, and the other is due to T3 expiration... This second reason is the "normal" retransmission.

> > In section 2.8.2 of the same draft where new section has 
> been added for RFC
> > 2960 section 7.2.4
> >         In step 3 it says that Ignore the value of cwnd 
> while performing the
> > fast retransmission.

	The point is that when you apply the Fast Retransmission algorithm, you have to shrink your cwnd, so, normally, you won't have any space to send any TSN since your flight size will normally be bigger than your cwnd. But what you are trying to do is avoiding a T3 timer expiration, so in this case you don't care about the value of cwnd and you fast retransmit the TSN. BUT, in any case, you only send one MTU worth of data...

> >         In step 5 it says that Mark the data chunks as being fast
> > retransmitted and thus ineligible for a subsequentfast  
> retransmit but only
> > those allowed by cwnd would be retransmitted.
> >         Do the above two statements contradict?

	No...

	One TSN that has been marked for Fast retransmission once, cannot be set for fast retransmission any more. This is because in a normal flow of data, there are both DATA chunks and SACK chunks in flight. So, it is likely that right after fast retransmitting a TSN, you will still receive many SACKs triggered by TSNs sent before the one you fast retransmitted. These SACKs will still include the gap, and thus you would most probably fast retransmit a TSN several times before you receive the SACK acknowledging the receipt of the first fast retransmission (acknowledging the gap). So, this is why one TSN can only be mark for retransmission once due to the Fast Retransmit algorithm.

	And about the second statement. A SACK chunk can cause several TSNs to be fast retransmitted. However, you should only send one MTU worth of data. This causes that you might have marked several TSNs for retransmission due to the fast retransmit algorithm, but you only send, let's say, one of them. The rest are marked for retransmission, but cannot be sent in that very moment. So, they will be retransmitted later, when cwnd allows to do so...

>         I think the answer for the above question  could be 
> understood once we
> know the difference between "Packets marked for Fast 
> Retransmission" and
> "First Packet which is fast Retransmitted"......
>     In step 3,  draft says about the "First Fast 
> Retransmitted packet" and in
>         step 5,  draft says about the " Waiting Marked Fast 
> Retransmit packets"....
> 
> ie., Only the first packet sent  during Fast Retransmition 
> should have the privilage
>       to override the Congestion rules...... The rest of the 
> data chunks which are
> marked for Fast Retransmition , but couldnot be sent due to 
> PMTU restriction,
> will be waiting till the CWND allows it to send data....
> 
> I think there is no contradiction.....   Hope I didnt miss 
> any point...

	You are right. The point is that a TSN that has been marked for retransmission due to the fast retransmit algorithm is still a TSN that is marked for retransmission. It is like when the T3 expires: you might not be able to send all the TSNs marked for retransmission in the very moment when the T3 expires, however, they are kept marked for retransmission and will be resent later, when the cwnd allows to do so...

	I hope now things are a little bit clearer...

	BR Iván Arias Rodríguez

> Thanks
> -arun
> 
> 
> 
> 
> >
> >
> > Regards
> > kashif khan
> >
> > _______________________________________________
> > tsvwg mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/tsvwg
> 
> --
> ****************************************************************
> V.Arun Prasad
> HCL Technologies Ltd.
> 51, Jawaharlal Nehru Road,
> Ekkattuthangal,
> Guindy Industrial Estate,
> Chennai - 600097.
> 
> Contact # : 9144 - 2334174
>             9144 - 2334181
>             extn : 233
> ****************************************************************
> 
> 
> 
> _______________________________________________
> tsvwg mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/tsvwg
> 

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