[Bloat] Jumbo frames and LAN buffers (was: RE: Burst Loss)

["Kevin Gross" <kevin.gross@avanw.com>]

[-- Attachment #1: Type: text/plain, Size: 2529 bytes --]

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.


[-- Attachment #2: Type: text/html, Size: 8491 bytes --]