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

[Joe Touch <touch at ISI.EDU>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



Mark Allman wrote:
...
>> 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.

Thanks - yes, that's what I meant. Sorry for the confusion ;-)

Joe
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)

iEYEARECAAYFAkq6MlsACgkQE5f5cImnZrv0/wCgpSYNMtFELC3ha9Qcua27jHME
HdEAn1Vovig+nW5Aij1SGYyFo61m75Fp
=aMhz
-----END PGP SIGNATURE-----