Re: [tcpm] Ordering of SACK blocks, flushing of reassembly queue after inactivity
David Malone <David.Malone@nuim.ie> Thu, 24 January 2008 15:24 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 1JI3wZ-0000LN-Km; Thu, 24 Jan 2008 10:24:43 -0500
Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1JI3wY-0000K2-92 for tcpm-confirm+ok@megatron.ietf.org; Thu, 24 Jan 2008 10:24:42 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JI3wX-0000JB-UY for tcpm@ietf.org; Thu, 24 Jan 2008 10:24:41 -0500
Received: from kac.cnri.dit.ie ([147.252.67.9]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JI3wX-0007wK-Ak for tcpm@ietf.org; Thu, 24 Jan 2008 10:24:41 -0500
Received: from kac.cnri.dit.ie (localhost.cnri.dit.ie [127.0.0.1]) by kac.cnri.dit.ie (8.13.4/8.13.4) with ESMTP id m0OFOTB1024134; Thu, 24 Jan 2008 15:24:30 GMT (envelope-from dwmalone@kac.cnri.dit.ie)
Message-Id: <200801241524.m0OFOTB1024134@kac.cnri.dit.ie>
To: Lars Eggert <lars.eggert@nokia.com>
Subject: Re: [tcpm] Ordering of SACK blocks, flushing of reassembly queue after inactivity
In-Reply-To: Your message of "Thu, 24 Jan 2008 17:04:25 +0200." <1648983D-9F94-4C59-88AD-78496CBFA119@nokia.com>
From: David Malone <David.Malone@nuim.ie>
Date: Thu, 24 Jan 2008 15:24:29 +0000
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c
Cc: TCP Maintenance and Minor Extensions WG <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
> The highspeed TCP folks have reported cases where SACK processing can > eat CPU cycles up to a degree where it significantly affects > performance. (I think this was under Linux.) I'm not sure if this is > an issue with the code or an issue with the spec; if it's the latter, > we may have some work to do. (But you probably know more about this > than I do anyway.) I think it was mainly implementation issues, see Chapter 3 of: http://www.hamilton.ie/publications/baruch_even_thesis.pdf it describes how to fix some of the problems. With that, there were no problems running up to about 1Gbps with sizeable RTTs. David. _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm
- [tcpm] Ordering of SACK blocks, flushing of reass… Andre Oppermann
- Re: [tcpm] Ordering of SACK blocks, flushing of r… Joshua Blanton
- Re: [tcpm] Ordering of SACK blocks, flushing of r… Matt Mathis
- RE: [tcpm] Ordering of SACK blocks, flushing of r… Mahdavi, Jamshid
- Re: [tcpm] Ordering of SACK blocks, flushing of r… Andre Oppermann
- Re: [tcpm] Ordering of SACK blocks, flushing of r… Andre Oppermann
- Re: [tcpm] Ordering of SACK blocks, flushing of r… Matt Mathis
- Re: [tcpm] Ordering of SACK blocks, flushing of r… Lars Eggert
- Re: [tcpm] Ordering of SACK blocks, flushing of r… David Malone
- Re: [tcpm] Ordering of SACK blocks, flushing of r… Matt Mathis
- Re: [tcpm] Ordering of SACK blocks, flushing of r… Andre Oppermann