IETF Logo Mail Archive

Re: [tcpm] Ordering of SACK blocks, flushing of reassembly queue after inactivity

Lars Eggert <lars.eggert@nokia.com> Thu, 24 January 2008 15:05 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 1JI3dY-00032v-N6; Thu, 24 Jan 2008 10:05:04 -0500
Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1JI3dX-00032q-PM for tcpm-confirm+ok@megatron.ietf.org; Thu, 24 Jan 2008 10:05:03 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JI3dX-00032i-Du for tcpm@ietf.org; Thu, 24 Jan 2008 10:05:03 -0500
Received: from smtp.nokia.com ([192.100.122.230] helo=mgw-mx03.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JI3dW-0006qA-JK for tcpm@ietf.org; Thu, 24 Jan 2008 10:05:03 -0500
Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m0OF3sVR003211; Thu, 24 Jan 2008 17:04:34 +0200
Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 24 Jan 2008 17:04:29 +0200
Received: from esdhcp035182.research.nokia.com ([172.21.35.182]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Thu, 24 Jan 2008 17:04:29 +0200
Message-Id: <1648983D-9F94-4C59-88AD-78496CBFA119@nokia.com>
From: Lars Eggert <lars.eggert@nokia.com>
To: ext Matt Mathis <mathis@psc.edu>
In-Reply-To: <Pine.LNX.4.64.0801240911250.27196@tesla.psc.edu>
Mime-Version: 1.0 (Apple Message framework v915)
Subject: Re: [tcpm] Ordering of SACK blocks, flushing of reassembly queue after inactivity
Date: Thu, 24 Jan 2008 17:04:25 +0200
References: <47952032.3030809@freebsd.org> <Pine.LNX.4.64.0801221619190.27196@tesla.psc.edu> <4797D53C.10908@freebsd.org> <Pine.LNX.4.64.0801240911250.27196@tesla.psc.edu>
X-Mailer: Apple Mail (2.915)
X-OriginalArrivalTime: 24 Jan 2008 15:04:29.0239 (UTC) FILETIME=[6AF3B470:01C85E9A]
X-Nokia-AV: Clean
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a
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>
Content-Type: multipart/mixed; boundary="===============1524669133=="
Errors-To: tcpm-bounces@ietf.org

On 2008-1-24, at 16:29, ext Matt Mathis wrote:
> BTW 1000 packet windows are not all that big: 1500 Byte MTU, 70 ms  
> RTT and only 90 Mb/s - well within reach for any university user in  
> the US or Europe
> and FIOS users in Korea or Japan.   The real challenge is getting  
> the scoreboard to work well with 10k or 100k packet windows....

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.)

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

v2.23.0 | Report a Bug | By Email