[tcpm] TCP ackcc and application limited

" Ilpo Järvinen " <ilpo.jarvinen@helsinki.fi> Thu, 05 March 2009 12:15 UTC

Return-Path: <ilpo.jarvinen@helsinki.fi>
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 69D2C28C2A2 for <tcpm@core3.amsl.com>; Thu, 5 Mar 2009 04:15:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.061
X-Spam-Level:
X-Spam-Status: No, score=-5.061 tagged_above=-999 required=5 tests=[AWL=1.239, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4]
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 BYbWsMqlzuzn for <tcpm@core3.amsl.com>; Thu, 5 Mar 2009 04:15:04 -0800 (PST)
Received: from mail.cs.helsinki.fi (courier.cs.helsinki.fi [128.214.9.1]) by core3.amsl.com (Postfix) with ESMTP id 036AD3A6980 for <tcpm@ietf.org>; Thu, 5 Mar 2009 04:15:02 -0800 (PST)
Received: from wrl-59.cs.helsinki.fi (wrl-59.cs.helsinki.fi [128.214.166.179]) (AUTH: PLAIN cs-relay, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by mail.cs.helsinki.fi with esmtp; Thu, 05 Mar 2009 14:15:30 +0200 id 001480F0.49AFC262.000012D6
Received: by wrl-59.cs.helsinki.fi (Postfix, from userid 50795) id 9191AA0096; Thu, 5 Mar 2009 14:15:30 +0200 (EET)
Received: from localhost (localhost [127.0.0.1]) by wrl-59.cs.helsinki.fi (Postfix) with ESMTP id 8EDEBA0091; Thu, 5 Mar 2009 14:15:30 +0200 (EET)
Date: Thu, 05 Mar 2009 14:15:30 +0200
From: Ilpo Järvinen <ilpo.jarvinen@helsinki.fi>
X-X-Sender: ijjarvin@wrl-59.cs.helsinki.fi
To: "tcpm@ietf.org" <tcpm@ietf.org>, Sally Floyd <sallyfloyd@mac.com>
Message-ID: <Pine.LNX.4.64.0901191459060.1889@wrl-59.cs.helsinki.fi>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Subject: [tcpm] TCP ackcc and application limited
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: Thu, 05 Mar 2009 12:15:10 -0000

Hi,

I read a while ago the ackcc draft (04)... I've one question about 
"Adjusting the ACK ratio" section's constraint 2... What is supposed to 
happen if a TCP flow becomes application limited with a large ACK ratio as 
only R=2R and R=R-1 are the allowed changes (and even that is limited 
additionally by the "should not attempt to change ACK ratio more than once 
per rtt" rule)? TCP receiver wouldn't be sending at least two ACKs for 
a window of data with the given constraint 2.

It's somewhat similar to the case added in -05 with cwnd reductions which 
seem to suggest about possiblity of halving R. In that case as well with 
application limited such dramatic changes might be necessary to actually 
force two acks per window. Depending on scenario ack ratio would also need 
to be changed more often than once per rtt. In case of application limit 
even more than halving with application limited actually might be 
necessary and there's yet another problem that we really cannot know
how much data we will finally have because the sender might generate more 
data at any point of time.

In addition, the receiver should ACK FIN immediately which I think was not 
mentioned anywhere.

I think that rfc4341 might miss application limited vs ack cc issues 
too and possibly the at-end-of-flow stuff too but I didn't read that too 
deeply (it discusses application limited but in different context)...


-- 
 i.