Re: revision RFC 2001 (draft-ietf-tcpimpl-cong-control-00.txt)
Andi Kleen <ak@muc.de> Wed, 12 August 1998 21:34 UTC
Return-Path: <owner-tcp-impl@relay.engr.sgi.com>
To: Kacheong Poon <Kacheong.Poon@Eng.Sun.COM>
Cc: David Borman <dab@bsdi.com>, tcp-impl@cthulhu.engr.sgi.com, mathis@psc.edu
Subject: Re: revision RFC 2001 (draft-ietf-tcpimpl-cong-control-00.txt)
References: <Roam.SIMCSD.2.0.4.902950136.15924.kcpoon@jurassic>
From: Andi Kleen <ak@muc.de>
Date: Wed, 12 Aug 1998 23:34:14 +0200
In-Reply-To: Kacheong Poon's message of "Wed, 12 Aug 1998 12:28:56 -0700 (PDT)"
Message-ID: <k2iujx3mw9.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: 1170
Lines: 26
In article <Roam.SIMCSD.2.0.4.902950136.15924.kcpoon@jurassic>, Kacheong Poon <Kacheong.Poon@Eng.Sun.COM> writes: >> Yes you can. In the receiver, you implement a local state variable that >> keeps track of the largest packet ever received from the peer, and use >> that in determining how many full size packets you have received, instead >> of the sending MSS. I implemented this in UNICOS years ago, and it worked >> fine for most cases. > This issue was discussed about a week ago in the Linux networking list. I > think they implement something similar, which they called "adaptive receive > MSS." So I guess Linux, beside UNICOS, is also conformant to the RFC. > Anyone from the Linux networking community can confirm this? All released versions (Linux 2.0, official 2.1) do not conform. The implementation of adaptive receive MSS will appear shortly in 2.1 snapshots, and will be included in the upcoming 2.2 release. Most BSD implementation (at least Free/NetBSD) don't have the problem, because they simply send an ACK every second packet, no matter how big the packets were (this means BSD will send more acks than linux in some situations) -Andi
- revision RFC 2001 (draft-ietf-tcpimpl-cong-contro… Vern Paxson
- Re: revision RFC 2001 (draft-ietf-tcpimpl-cong-co… Kacheong Poon
- Re: revision RFC 2001 (draft-ietf-tcpimpl-cong-co… Mark Allman
- Re: revision RFC 2001 (draft-ietf-tcpimpl-cong-co… Matt Mathis
- Re: revision RFC 2001 (draft-ietf-tcpimpl-cong-co… David Borman
- Re: revision RFC 2001 (draft-ietf-tcpimpl-cong-co… Kacheong Poon
- Re: revision RFC 2001 (draft-ietf-tcpimpl-cong-co… Andi Kleen
- Re: revision RFC 2001 (draft-ietf-tcpimpl-cong-co… Andi Kleen
- Re: revision RFC 2001 (draft-ietf-tcpimpl-cong-co… Andi Kleen
- Re: revision RFC 2001 (draft-ietf-tcpimpl-cong-co… Kacheong.Poon
- Re: revision RFC 2001 (draft-ietf-tcpimpl-cong-co… Kevin M. Lahey
- Re: revision RFC 2001 (draft-ietf-tcpimpl-cong-co… Andi Kleen
- Re: revision RFC 2001 (draft-ietf-tcpimpl-cong-co… Vern Paxson
- Re: revision RFC 2001 (draft-ietf-tcpimpl-cong-co… Vern Paxson
- Re: revision RFC 2001 (draft-ietf-tcpimpl-cong-co… Vern Paxson