IETF Logo Mail Archive

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

Joe Touch <touch@ISI.EDU> Wed, 23 September 2009 14:42 UTC

Return-Path: <touch@ISI.EDU>
X-Original-To: tcpm@core3.amsl.com
Delivered-To: tcpm@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E29CF3A6803 for <tcpm@core3.amsl.com>; Wed, 23 Sep 2009 07:42:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lLYktmJpd9CX for <tcpm@core3.amsl.com>; Wed, 23 Sep 2009 07:42:33 -0700 (PDT)
Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) by core3.amsl.com (Postfix) with ESMTP id 301ED3A659A for <tcpm@ietf.org>; Wed, 23 Sep 2009 07:42:33 -0700 (PDT)
Received: from [70.208.68.126] (126.sub-70-208-68.myvzw.com [70.208.68.126]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id n8NEaBZL005128 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 23 Sep 2009 07:36:16 -0700 (PDT)
Message-ID: <4ABA325B.2000607@isi.edu>
Date: Wed, 23 Sep 2009 07:36:11 -0700
From: Joe Touch <touch@ISI.EDU>
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: mallman@icir.org
References: <20090923143349.A77E94AF45B@lawyers.icir.org>
In-Reply-To: <20090923143349.A77E94AF45B@lawyers.icir.org>
X-Enigmail-Version: 0.96.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-MailScanner-ID: n8NEaBZL005128
X-ISI-4-69-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Cc: tcpm@ietf.org
Subject: Re: [tcpm] delayed ACKs (was Re: Review: draft-ietf-tcpm-early-rexmt-01)
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 23 Sep 2009 14:42:34 -0000

-----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-----

v2.23.0 | Report a Bug | By Email