Re: Summary of responses so far and proposal moving forward [Was Re: [tcpm] Is this a problem?]

Ted Faber <faber@ISI.EDU> Wed, 21 November 2007 19:30 UTC

Return-path: <tcpm-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuvHW-0006Da-E1; Wed, 21 Nov 2007 14:30:42 -0500
Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1IuvHU-0006AV-MQ for tcpm-confirm+ok@megatron.ietf.org; Wed, 21 Nov 2007 14:30:40 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuvHU-00068f-Ar for tcpm@ietf.org; Wed, 21 Nov 2007 14:30:40 -0500
Received: from boreas.isi.edu ([128.9.160.161]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IuvHT-0004yU-Sa for tcpm@ietf.org; Wed, 21 Nov 2007 14:30:40 -0500
Received: from hut.isi.edu (hut.isi.edu [128.9.168.160]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id lALJT1Uw007513 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 21 Nov 2007 11:29:02 -0800 (PST)
Received: (from faber@localhost) by hut.isi.edu (8.14.2/8.14.2/Submit) id lALJT1FV016962; Wed, 21 Nov 2007 11:29:01 -0800 (PST) (envelope-from faber)
Date: Wed, 21 Nov 2007 11:29:01 -0800
From: Ted Faber <faber@ISI.EDU>
To: "Anantha Ramaiah (ananth)" <ananth@cisco.com>
Subject: Re: Summary of responses so far and proposal moving forward [Was Re: [tcpm] Is this a problem?]
Message-ID: <20071121192901.GF13024@hut.isi.edu>
References: <200711210546.FAA00566@cisco.com> <0C53DCFB700D144284A584F54711EC58044CDF71@xmb-sjc-21c.amer.cisco.com>
Mime-Version: 1.0
In-Reply-To: <0C53DCFB700D144284A584F54711EC58044CDF71@xmb-sjc-21c.amer.cisco.com>
User-Agent: Mutt/1.4.2.3i
X-url: http://www.isi.edu/~faber
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: faber@hut.isi.edu
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793
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>
Content-Type: multipart/mixed; boundary="===============1721624877=="
Errors-To: tcpm-bounces@ietf.org

I haven't spoken to Mark about this, so this is me speaking for myself.

On Wed, Nov 21, 2007 at 10:12:44AM -0800, Anantha Ramaiah (ananth) wrote:
> B) Do we think this is an issue to be dealt at the transport layer?
> 
>    Here there seems to be mixed reaction. Granted that there may be many
> people feeling that this is an application issue and not a transport
> issue.

That's not my assessment.

It looks to me that there is considerable resistance to standardizing 
the proposed solution, both on the grounds of placement in the stack and
on the limitations of the solution.  

[ For example, connections that advertise a large initial window and then
read a byte every (proposed timer size -1) seconds will replicate the
problem in the limit. Using timers alone penalizes stopped connections
when there is no resource shortage. ]

Despite the fairly lively discussion, I have seen little support for
standardizing this mechanism in TCP, outside the authors and their
collaborators, and strong resistance from the members of the WG.  

Again, I'm not assessing consensus officially here, but that's how I see
it.

-- 
Ted Faber
http://www.isi.edu/~faber           PGP: http://www.isi.edu/~faber/pubkeys.asc
Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#SIG
_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www1.ietf.org/mailman/listinfo/tcpm