RE: [tcpm] New I-D posted : draft-moncaster-tcpm-rcv-cheat-00

Michael Welzl <michael.welzl@uibk.ac.at> Thu, 22 February 2007 07:27 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HK8MJ-0000CZ-Eg; Thu, 22 Feb 2007 02:27:19 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HK8MH-0000Ba-EV for tcpm@ietf.org; Thu, 22 Feb 2007 02:27:17 -0500
Received: from lmr1.uibk.ac.at ([138.232.1.142] helo=smtp.uibk.ac.at) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HK8MF-0003CH-VR for tcpm@ietf.org; Thu, 22 Feb 2007 02:27:17 -0500
Received: from [138.232.65.105] (pc105-c703.uibk.ac.at [138.232.65.105] michael.welzl@uibk.ac.at) (authenticated bits=0) by smtp.uibk.ac.at (8.13.8/8.13.1/F1) with ESMTP id l1M7R66T032106 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Thu, 22 Feb 2007 08:27:06 +0100
Subject: RE: [tcpm] New I-D posted : draft-moncaster-tcpm-rcv-cheat-00
From: Michael Welzl <michael.welzl@uibk.ac.at>
To: "Anantha Ramaiah (ananth)" <ananth@cisco.com>
In-Reply-To: <0C53DCFB700D144284A584F54711EC5802E88AD8@xmb-sjc-21c.amer.cisco.com>
References: <0C53DCFB700D144284A584F54711EC5802E88AD8@xmb-sjc-21c.amer.cisco.com>
Content-Type: text/plain
Organization: University of Innsbruck
Date: Thu, 22 Feb 2007 08:27:06 +0100
Message-Id: <1172129226.3233.4.camel@pc105-c703.uibk.ac.at>
Mime-Version: 1.0
X-Mailer: Evolution 2.8.0 (2.8.0-7.fc6)
Content-Transfer-Encoding: 7bit
X-Spam-Score: () -9.4 ALL_TRUSTED,RCV_SMTP_AUTH,RCV_SMTP_UIBK
X-Scanned-By: MIMEDefang 2.58 at uibk.ac.at on 138.232.1.140
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581
Cc: tcpm@ietf.org
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
Errors-To: tcpm-bounces@ietf.org

> > There's been some talk lately about reverse path congestion control. 
> > (This would be much harder with TCP than DCCP, but maybe someone can 
> > figure it out?)
> 
> By reverse path, you mean ACK congestion control? Data transfer can be
> bi-directional.

Funny enough, I stumbled over this SHOULD when thinking about ACK
congestion control, where it could be useful for the sender to be
able to count the number of ACKs that the receiver would normally
have to send during a loss period.

In any case, it's the concern of a new mechanism, yet to be specified,
how to do ACK congestion control, and not the concern of RFC 2581 -
using a SHOULD instead of a MUST for sending ACKs to out-of-order
segments doesn't implement or even help ACK congestion control,
but it actually seems to be a hindrance.

Cheers,
Michael


_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www1.ietf.org/mailman/listinfo/tcpm