[tcpm] delayed ACKs (was Re: Review: draft-ietf-tcpm-early-rexmt-01)

[Mark Allman <[e-mail]>]

> >> The example on page three considers a window of three segments (FWIW,
> >> it should probably read "a window of three segments' worth of data",
> >> since windows are in bytes not segments). I'm wondering if ACK
> >> compression (as required) affects the example. It's worth either
> >> fixing the example, or addressing the effect of ACK compression (even
> >> if to clarify that there is none) somewhere in the doc.
> >
> > I think you're talking about duplicate ACKs and not ACK compression
> > (ACKs getting squished together in the time domain), right?  The
> > assumption here is that stacks are following 5681 which says they should
> > not use duplicate ACKs if there is a hole in the sequence space.  I.e.,
> > that they should immediately ACK each incoming segment.  I'll add a
> > quick note.
> 
> I had been thinking of compression (sending an ACK every other
> segment), i.e., you have a window of three segments, but you will
> receive one ACK quickly, and the second ACK will just stall for some
> time (200 ms?).  It's like Nagle on the ACK side - would it wait for
> some time before sending an ACK for a single segment (i.e., in
> anticipation of squishing the next ACK with the pending one). At least
> that's what I'm wondering about.

Damn... "Joe, let me correct your terminology with some bogus
terminology of my own!"

Where I wrote "duplicate ACK" I meant "delayed ACK".  I.e., what you're
describing is not ACK compression, but delayed ACKs.  And, it is
certainly not duplicate ACKs as I tried to make it out to be.

allman