Subject: RE: [Tsvwg] SCTP Implementor's Guide

From: [email-masked]
Date: Wed, 27 Jun 2001 20:55:40 +0300

Hi all!

	See some comments below...

> Janardhan:
> 
> I don't beleive this is strictly how things work in TCP and I
> don't see why things are not eligible for fast retransmit
> after a timeout.
> 
> If you consider:
> 
> ----FR(TSNx)---->
> ..
> ..
> ..
> ---Time-Out---
> ---All outstanding marked for retran---
> so we end up
> 
> ---Re-Tran(TSNx)---->
> <plus possibly others>
> 
> At this point we have now reach the same state as before. All

	Well, not exactly... You have to take into account that there are
several SACK coming back from the peer by the time you make the
retransmission... Also, you must note that some of the DATA chunks you are
going to mark for retransmissions are in "early flight" to the destination
and is likely that they will arrive to the destination... So, you are not
exactly as before, I would say things are quite different...

	The point is that both those SACK coming back, and the SACK that
will be originated by the DATA chunks that are going to the peer, sent
before the timeout but not yet arrived to the receiver, will originate the
same gap as the one that previously originated the fast retransmission...

	I happen to be sitting next to Janardhan and he explained me exactly
what the problem is, showing me the NS2 graphs that made him reach to that
conclusion... The point is that once you loose a packet and you start
receiving SACKs with gaps, if you fast retransmit a chunk and then you have
a timeout, it is really likely that the addition of SACK in the way back to
the sender, and those DATA chunks sent before the timeout that could
originate the same "whole" in the receiver's buffer, will be bigger than 4,
and so, it is quite probable that you will fast retransmit the chunk again
upon the arrival of the fourth SACK chunk after the time out...

	As we see it, one TSN acknowledged in a Gap ACK Block should trigger
the fast retransmission counter of one TSN not acknowledged by that SACK
chunk *only* if we can be sure that the partial acknowledgement received was
originated by a TSN that was undoubtedly sent after that TSN... Uf... this
seems hard to say, but the idea is not that hard... An example might help...

	Imagine that the cumulative TSN ACK point is 14, and by the time we
have the time out, TSNs from 16 to 21 has been acknowledged, and imagine as
well that TSNs from 22 to 26 are in flight (we haven't received any
acknowledgement about them)... In this situation, if we have a timeout and
then we resend TSNs 14 and 22-26 and maybe we also send some new one, we
will receive the SACKs originated by the original transmission of chunks
22-26, containing a gap that excludes TSN 14, so once we receive the first 4
SACKs (originated by the first transmission of chunks 22-25) we will fast
retransmit again TSN 14...

	The idea is having some memory about that the last TSN sent before
the timeout was 26, and so, when SACK chunks come not acknowledging anything
newer than TSN 26, we shouldn't increment the FR counter... Once we have
sent new chunks again whose TSN is newer than 26, if we receive a SACK that
includes any gap that is acknowledging TSN 26 or newer in any of its Gap ACK
Blocks, we should start incrementing the gap counters of the TSNs not
acknowledged so far...

	Thanks for your time!

	BR Iván Arias Rodríguez

> of our scores are now 0. We have obviously lost our ack-clock
> and we allow very little out. Probably our TSNx and no more
> than a few others depending on how big TSNx is. Since we did
> FR TSNx it is probably the smallest TSN... it may be capable
> of being bundled... 
> 
> Now once I send these again and start to get an Ack-Clock, all
> the scores are reset to 0. So I am now waiting for a 4 missing
> reports to occur.
> 
> I see nothing wrong with this... Maybe a further clearification
> 
> such as..
> 
> "   5) Mark the DATA chunk(s) as being fast retransmitted and thus
>        ineligible for a subsequent fast retransmit until after the
>        T3-rxt timer expires. Note all missing reports for any 
>        chunks that were outstanding at the time of retransmission
>        MUST be reset to 0 so that four additional missing reports
>        will be necessary before a fast retransmit will occur.
> "
> 
> Also I believe you will find in Mark Allman and Ethan Blanton draft:
> draft-allman-tcp-sack-04.txt
> 
> A section under transmission time-out that illustrates that the
> scoreboard is purged but new SACK's arriving do continue to use
> information gained during the slow-start period following a RTO 
> event (At least if I have read it correctly :>)
> 
> What do you think Mark/Sally? Should new SACK's coming in after
> a RTO be used to count a segment towards a subsequent FR?
> 
> R
> 
> 
> 
> Janardhan Iyengar wrote:
> > 
> > Hi all,
> > 
> > Section 2.8 (Fast Retransmit issues), new text for section 7.2.4 of
> > RFC2960:
> > "   5) Mark the DATA chunk(s) as being fast retransmitted and thus
> >        ineligible for a subsequent fast retransmit until after the
> >        T3-rxt timer expires.
> > "
> > 
> > Should a sender have *any* fast retranmits after a timeout? 
> If so, there
> > needs to be a mechanism for determining which TSNs being 
> SACK'd were sent
> > prior to the timeout rtx and which ones were sent 
> afterwards. Only those
> > which were sent aftewards, should be counted towards the 
> fast rtx trigger.
> > 
> > We feel that the text should read as follows:
> > "   5) Mark the DATA chunk(s) as being fast retransmitted and thus
> >        ineligible for a subsequent fast retransmit.
> > "
> > 
> > Regards,
> > Jana and Armando
> > 
> > 
> --------------------------------------------------------------
> ---------
> > "The future belongs to those who believe in the beauty of 
> their dreams"
> >                                                     - 
> Eleanor Roosevelt
> > 
> --------------------------------------------------------------
> ---------
> > Janardhan R. Iyengar                               
> [email-masked]
> > University of Delaware                 
http://www.cis.udel.edu/~iyengar
> -----------------------------------------------------------------------
> 
> _______________________________________________
> tsvwg mailing list
> [email-masked]
> http://www1.ietf.org/mailman/listinfo/tsvwg

-- 
Randall R. Stewart
[email-masked] 815-342-5222 (cell phone)

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

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

---

From: Randall Stewart at work <[email-masked]>
Date: Wed, 27 Jun 2001 14:57:22 -0500

Ivan:

Just a couple of quick statements:

A) I just finished downloading ghostview... I did not
   have it on my laptop :< so I was unable to read
   the .ps Janardhan sent... I should be able to real
   soon now :>

B) The current guide just follows what was stated on
   the lists earlier AND what was in Mark's draft. If this
   is wrong I have no problems in forever not FR'ing the chunk
   (which is what Janardhan proposed).

C) I think your proposal is a bit different then Janardhan's i.e.
   saving a state variable 'Sack.At.Tx3' and then not stroking
   FR counters if no GapAck Block shows greater than this
   value. This sorta runs parrallel to our FR draft we are working
   on :) We may want to put Janardhan's proposal in the implementors
   guide and then add this to the FR document...

Now that my download is done I go to look with ghostview at
Janardhan's graphs :->

R

---

From: Randall Stewart at work <[email-masked]>
Date: Wed, 27 Jun 2001 15:11:22 -0500

Ivan:

After having a chance to look at the graphs...  I think
I agree.. lets only allow 1 FR... as Janardhan proposes.
Then we can address the other proposal of yours in
the document we are working on...

R

---

From: "Armando L. Caro Jr." <[email-masked]>
Date: Thu, 28 Jun 2001 02:49:21 -0400 (EDT)

> Blocks, we should start incrementing the gap counters of the TSNs not

Yes, I like this idea. I am just wondering if such a case would ever be
needed/possible...

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