Subject: RE: [Tsvwg] about HighData

From: "Henderson, Thomas R" <[email-masked]>
Date: Wed, 17 Jul 2002 08:48:34 -0700

> -----Original Message-----
> From: Lili Wang [mailto:[email-masked]]
> Sent: Wednesday, July 17, 2002 7:11 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [Tsvwg] about HighData
> 
> 
> 
> Henderson, Thomas R wrote:
> >The pipe variable SHOULD NOT be used to limit transmissions after a
> >retransmission timeout, even though Update() and NextSeg() 
> can be used to
> >intelligently select segments for transmission.  Furthermore,
> >RecoveryPoint
> >SHOULD NOT be changed upon a retransmission timeout, and 
> additional fast
> >recovery phases SHOULD NOT be initiated until a cumulative ACK is
> >received
> >for RecoveryPoint."
> 
>    It seems from the draft that fast recovery can be invoked before
> finishing retransmiting past HighData after timeout. 
> Even if it is not allowed to invoke fast recovery in that case,
> using NextSeg() may cause some packets not allowed to
> retransmit after timeout() when HighData is not reset.
> Some packets that are below HighData and do not meet the 
> criteria(a)-(c)in LeftNetwork() will not be returned by  
> NextSeg(), even if they are not retransmitted and need to 
> retransmit after a timeout. 
> 
> 
This is a potential problem.  This is why a timeout should cause a byte sent
before the timeout to be considered as having "left the network," otherwise
NextSeg() may not work correctly.

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

---

From: Ethan Blanton <[email-masked]>
Date: Wed, 17 Jul 2002 13:56:54 -0400

> NextSeg() may not work correctly.

I disagree.  (And after a short conversation with Mark, I think we are
in the same camp -- standard disclaimer applies)  This algorithm
should *not* be used after an RTO.  This includes NextSeg () -- my
thinking being that it would needlessly complicate the draft to say
"oh, and if you use NextSeg during slow start you ..."  Update is
completely untied from the actual loss recovery algorithm
side-effects, and as such can (and should, in my opinion) be used on
every ACK containing SACK information.  NextSeg, however, is riddled
with dependencies on the exact algorithm.

The algorithm for packet selection during the slow start following a
timeout is not specified by this draft.

Since NextSeg is as such not used after a timeout, LeftNetwork also
does not need special-cased.
Ethan

-- 
Now if I wasn't such a weenie do ya think you'd still love me,
Pretendin' I'm an airplane on the living room floor?
                -- The Offspring, "I Choose"