From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from oproxy3-pub.bluehost.com (oproxy3-pub.bluehost.com [69.89.21.8]) by huchra.bufferbloat.net (Postfix) with SMTP id AF225201745 for ; Fri, 13 May 2011 12:55:33 -0700 (PDT) Received: (qmail 29425 invoked by uid 0); 13 May 2011 20:03:54 -0000 Received: from unknown (HELO host291.hostmonster.com) (74.220.215.91) by oproxy3.bluehost.com with SMTP; 13 May 2011 20:03:54 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=avanw.com; h=Received:From:To:References:In-Reply-To:Subject:Date:Organization:Message-ID:MIME-Version:Content-Type:X-Mailer:Thread-index:Content-Language:X-Identified-User; b=dxFSwvU+8j6RqZpQb8I5+UK3T4o/0tCEb5ps2R92TtNEt7Bdg/M/FNznffCDP4jNOYVqBy8R1sURmO0+j73p5xFnsvQQA5hhqTC0+fUjHwtxO+xlXO7Ul0HixoXO3mgm; Received: from c-76-120-76-232.hsd1.co.comcast.net ([76.120.76.232] helo=AVADesk2) by host291.hostmonster.com with esmtpa (Exim 4.69) (envelope-from ) id 1QKyaX-0005Ai-Lc for bloat@lists.bufferbloat.net; Fri, 13 May 2011 14:03:54 -0600 From: "Kevin Gross" To: References: <4DB70FDA.6000507@mti-systems.com> <4DC2C9D2.8040703@freedesktop.org> <20110505091046.3c73e067@nehalam> <6E25D2CF-D0F0-4C41-BABC-4AB0C00862A6@pnsol.com> <35D8AC71C7BF46E29CC3118AACD97FA6@srichardlxp2> <1304964368.8149.202.camel@tardy> <4DD9A464-8845-49AA-ADC4-A0D36D91AAEC@cisco.com> <1305297321.8149.549.camel@tardy> In-Reply-To: Date: Fri, 13 May 2011 14:03:46 -0600 Organization: AVA Networks Message-ID: <014c01cc11a8$de78ac10$9b6a0430$@gross@avanw.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_014D_01CC1176.93DE3C10" X-Mailer: Microsoft Office Outlook 12.0 Thread-index: AcwRfahavqkV0MW5RMCi1C05koPH0wAJuSTw Content-Language: en-us X-Identified-User: {1416:host291.hostmonster.com:avanwcom:avanw.com} {sentby:smtp auth 76.120.76.232 authed with kevin.gross@avanw.com} Subject: [Bloat] Jumbo frames and LAN buffers (was: RE: Burst Loss) X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 May 2011 19:55:34 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_014D_01CC1176.93DE3C10 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Do we think that bufferbloat is just a WAN problem? I work on live media applications for LANs and campus networks. I'm seeing what I think could be characterized as bufferbloat in LAN equipment. The timescales on 1 Gb Ethernet are orders of magnitude shorter and the performance problems caused are in many cases a bit different but root cause and potential solutions are, I'm hoping, very similar. Keeping the frame byte size small while the frame time has shrunk maintains the overhead at the same level. Again, this has been a conscious decision not a stubborn relic. Ethernet improvements have increased bandwidth by orders of magnitude. Do we really need to increase it by a couple percentage points more by reducing overhead for large payloads? The cost of that improved marginal bandwidth efficiency is a 6x increase in latency. Many applications would not notice an increase from 12 us to 72 us for a Gigabit switch hop. But on a large network it adds up, some applications are absolutely that sensitive (transaction processing, cluster computing, SANs) and (I thought I'd be preaching to the choir here) there's no way to ever recover the lost performance. Kevin Gross From: Dave Taht [mailto:dave.taht@gmail.com] Sent: Friday, May 13, 2011 8:54 AM To: rick.jones2@hp.com Cc: Kevin Gross; bloat@lists.bufferbloat.net Subject: Re: [Bloat] Burst Loss On Fri, May 13, 2011 at 8:35 AM, Rick Jones wrote: On Thu, 2011-05-12 at 23:00 -0600, Kevin Gross wrote: > One of the principal reasons jumbo frames have not been standardized > is due to latency concerns. I assume this group can appreciate the > IEEE holding ground on this. Thusfar at least, bloaters are fighting to eliminate 10s of milliseconds of queuing delay. I don't think this list is worrying about the tens of microseconds difference between the transmission time of a 9000 byte frame at 1 GbE vs a 1500 byte frame, or the single digit microseconds difference at 10 GbE. Heh. With the first iteration of the bismark project I'm trying to get to where I have less than 30ms latency under load and have far larger problems to worry about than jumbo frames. I'll be lucky to manage 1/10th that (300ms) at this point. Not, incidentally that I mind the idea of jumbo frames. It seems silly to be saddled with default frame sizes that made sense in the 70s, and in an age where we will be seeing ever more packet encapsulation, reducing the header size as a ratio to data size strikes me as a very worthy goal. ------=_NextPart_000_014D_01CC1176.93DE3C10 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Do we think that bufferbloat is just a WAN problem? I work on live = media applications for LANs and campus networks. I'm seeing what I think = could be characterized as bufferbloat in LAN equipment. The timescales = on 1 Gb Ethernet are orders of magnitude shorter and the performance = problems caused are in many cases a bit different but root cause and = potential solutions are, I'm hoping, very = similar.

 

Keeping the frame byte size small while the frame time has shrunk = maintains the overhead at the same level. Again, this has been a = conscious decision not a stubborn relic. Ethernet improvements have = increased bandwidth by orders of magnitude. Do we really need to = increase it by a couple percentage points more by reducing overhead for = large payloads?

 

The cost of that improved marginal bandwidth efficiency is a 6x = increase in latency. Many applications would not notice an increase from = 12 us to 72 us for a Gigabit switch hop. But on a large network it adds = up, some applications are absolutely that sensitive (transaction = processing, cluster computing, SANs) and (I thought I'd be preaching to = the choir here) there's no way to ever recover the lost = performance.

 

Kevin Gross

 

From:= = Dave Taht [mailto:dave.taht@gmail.com]
Sent: Friday, May 13, = 2011 8:54 AM
To: rick.jones2@hp.com
Cc: Kevin Gross; = bloat@lists.bufferbloat.net
Subject: Re: [Bloat] Burst = Loss

 

 

On Fri, May 13, 2011 at 8:35 AM, Rick Jones <rick.jones2@hp.com> = wrote:

On Thu, 2011-05-12 at 23:00 -0600, Kevin = Gross wrote:
> One of the principal reasons jumbo frames have not = been standardized
> is due to latency concerns. I assume this = group can appreciate the
> IEEE holding ground on = this.

Thusfar at least, = bloaters are fighting to eliminate 10s of milliseconds
of queuing = delay.  I don't think this list is worrying about the tens = of
microseconds difference between the transmission time of a 9000 = byte
frame at 1 GbE vs a 1500 byte frame, or the single digit = microseconds
difference at 10 GbE.


Heh.  With the = first iteration of the bismark project I'm trying to get to where I have = less than 30ms latency under load and have far larger problems to worry = about than jumbo frames. I'll be lucky to manage 1/10th that (300ms) at = this point.

Not, incidentally that I mind the idea of jumbo = frames. It seems silly to be saddled with default frame sizes that made = sense in the 70s, and in an age where we will be seeing ever more packet = encapsulation, reducing the header size as a ratio to data size strikes = me as a very worthy goal.

------=_NextPart_000_014D_01CC1176.93DE3C10--