[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.
- [tcpm] TCP ackcc and application limited Ilpo Järvinen