Subject: Re: [Tsvwg] delayed SACK when sender is retransmitting

From: Randall Stewart <[email-masked]>
Date: Tue, 02 Apr 2002 13:07:28 -0600

Mark Allman wrote:
> 
> > I think Arun has mad the correct observation here.
> >
> > It is really impossible to tell the difference between
> > a retransmission and a network delayed packet.
> 
> Yeah, I agree.
> 
> But, I think the packet should be immediatly SACKed.  In RFC 2581 we
> added some language that says you should immedaitly ACK packets that
> either create a hole in the sequence (or TSN, in this case) space or
> that fill in the hole (or part of a hole).  Doing so provides the
> quickest possible feedback to the sender as to the state of the
> world -- which is a good thing for loss recovery algorithms.
> 
Hmm...

So what you are proposing is to always send a SACK without
delay when there are other TSN's ahead of the one that 
advances the cum-ack point. This seems ok.. I don't see that
it is prohibited explicitly or on the other hand encouraged to
do so... in fact I doubt that I did it in our bsd implementation
I will have to add this :>

R

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

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

---

From: Mark Allman <[email-masked]>
Date: Tue, 02 Apr 2002 11:05:31 -0500

Yeah, I agree.

allman

--
Mark Allman -- BBN/NASA GRC -- http://roland.grc.nasa.gov/~mallman/