Re: revision RFC 2001 (draft-ietf-tcpimpl-cong-control-00.txt)

Andi Kleen <ak@muc.de> Wed, 12 August 1998 18:51 UTC

Return-Path: <owner-tcp-impl@relay.engr.sgi.com>
To: Matt Mathis <mathis@psc.edu>
Cc: Vern Paxson <vern@ee.lbl.gov>, tcp-impl@cthulhu.engr.sgi.com
Subject: Re: revision RFC 2001 (draft-ietf-tcpimpl-cong-control-00.txt)
References: <199808121612.MAA04021@zippy.psc.edu>
From: Andi Kleen <ak@muc.de>
Date: Wed, 12 Aug 1998 20:51:17 +0200
In-Reply-To: "Matt Mathis"'s message of "Wed, 12 Aug 1998 12:12:00 -0400"
Message-ID: <k2n29a2fve.fsf@zero.aec.at>
X-Mailer: Gnus v5.6.30/Emacs 20.2
Sender: owner-tcp-impl@relay.engr.sgi.com
Precedence: bulk
Status: RO
Content-Length: 599
Lines: 14

In article <199808121612.MAA04021@zippy.psc.edu>,
"Matt Mathis" <mathis@psc.edu> writes:

> Yes, all(?) existing implementation are non-conformant, and yes all(?)
> can be made to misbehave on real paths.  (In the above FDDI/ethernet
> examples most receivers send one ACK per six segments.  We have one
> trace where the receiver was ACKing every 2*4096 Bytes, but the sender
> was using 512 Byte segments, causing 17 packet bursts during
> slow-start).

Exactly this problem got fixed in Linux 2.1 a few days ago. Funny 
that you bring it up now :) See my other mail on the algorithm used.

-Andi