Re: [tcpm] Comments on draft-blanton-tcpm-3517bis-01

[" Ilpo Järvinen " <[e-mail]>]

On Wed, 13 Apr 2011, Mark Allman wrote:

> > 2)
> > If the incoming ACK is a duplicate acknowledgment and the TCP is
> > 
> >    not currently in loss recovery, the TCP MUST increase DupAcks by
> >    one and take the following steps:
> > 
> >    (1) If DupAcks >= DupThresh, go to step (4).
> > 
> >    (2) If DupAcks < DupThresh but IsLost (SND.UNA) returns
> >        true---indicating at least three segments have arrived above
> >        the current cumulative acknowledgment point, which is taken
> >        to indicate loss---go to step (4).
> > 
> > can we combine (1) and (2)? go to steps (4) if IsLost(SND.UNA) is
> > true. I guess it depends on your answer of my first question.
> 
> My first hit here is that this could indeed be tightened up by just
> getting rid of DupAcks and consulting IsLost (SND.UNA).  If that returns
> true we enter loss recovery, if not we don't.  Do I understand that to
> be what you're saying?

...I see, now we're back in discussing what this DupAcks counter is 
for, right? It was added in sack-recovery-entry ID and had proper 
explation of its purpose there in place. The DupAcks counter is to handle 
case where the sender is sending smaller than SMSS sized segments. 
...Perhaps it would be useful to explain it like the sack-recovery-entry 
did because otherwise this will just keep confusing people?

-- 
 i.