[Bloat] Large buffers: deliberate optimisation for HTTP?

[Bloat] Large buffers: deliberate optimisation for HTTP?

[Steve Davies]

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

Hi,

I'm a new subscriber and hardly a hardcore network programmer.  But I have
been working with IP for years and even have Douglas Comer's books...

I was thinking about this issue of excess buffers.  It occurred to me that
the large buffers could be a deliberate strategy to optimise HTTP-style
traffic.  Having 1/2 MB or so of buffering towards the edge does mean that a
typical web page and images etc can likely be "dumped" into those buffers
"en-bloc".

Or maybe its not so deliberate but just that testing has become fixated on
"throughput" and impact latency and jitter has been ignored.  If you have a
spanking new Gb NIC the first thing you do is try some scps and see how
close to line-speed you can get.  And lots of buffering helps that test in
the absence of real packet loss in the actual link.

Perhaps the reality is that our traffic patterns are not typical of
broadband link usage and that these large buffers that mess up our usage
patterns (interactive traffic mixed with bulk data), actually benefit the
majority usage pattern which is "chunky bursts".

Would you agree with my logic?

Steve

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

Re: [Bloat] Large buffers: deliberate optimisation for HTTP?

[Richard Scheffenegger]

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


No.
  ----- Original Message ----- 
  From: Steve Davies 
  To: bloat@lists.bufferbloat.net 
  Sent: Friday, February 04, 2011 8:08 PM
  Subject: [Bloat] Large buffers: deliberate optimisation for HTTP?


  Hi,


  I'm a new subscriber and hardly a hardcore network programmer.  But I have been working with IP for years and even have Douglas Comer's books...  


  I was thinking about this issue of excess buffers.  It occurred to me that the large buffers could be a deliberate strategy to optimise HTTP-style traffic.  Having 1/2 MB or so of buffering towards the edge does mean that a typical web page and images etc can likely be "dumped" into those buffers "en-bloc".


  Or maybe its not so deliberate but just that testing has become fixated on "throughput" and impact latency and jitter has been ignored.  If you have a spanking new Gb NIC the first thing you do is try some scps and see how close to line-speed you can get.  And lots of buffering helps that test in the absence of real packet loss in the actual link.


  Perhaps the reality is that our traffic patterns are not typical of broadband link usage and that these large buffers that mess up our usage patterns (interactive traffic mixed with bulk data), actually benefit the majority usage pattern which is "chunky bursts".


  Would you agree with my logic?


  Steve




------------------------------------------------------------------------------


  _______________________________________________
  Bloat mailing list
  Bloat@lists.bufferbloat.net
  https://lists.bufferbloat.net/listinfo/bloat

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

Re: [Bloat] Large buffers: deliberate optimisation for HTTP?

[Richard Scheffenegger]

[-- Attachment #1.1: Type: text/plain, Size: 1297 bytes --]



Shouldn't a ns2 animation suffice - like the one on the DCTCP site:

http://research.microsoft.com/en-us/projects/cloudfaster/


I'll try to revive my ns2 installation, and do some simulation, one with 1000 buffers per hop (and slightly less bandwidth at each hops forward direction), and one with 10 buffers FIFO. However, I'm no ns2 expert - one could add color-marked frames, and also track the RTT latency (making a graph next to the packet simulation). No promises, though.

Richard



        Animation to show bufferbloat badly needed... 
      gettys | February 4, 2011 at 6:01 pm | Categories: Bufferbloat, Networking | URL: http://wp.me/pfzIQ-8O  


If you are facile at putting together animations, a great public service would be to build an animation (preferably web based) that demonstrates the consequences of bufferbloat. Ideally, there would be two such animations: one demonstrating simple single path bufferbloat (something vaguely like this) and the other showing a more complex network of machines, demonstrating aggregate forms of bufferbloat. This would help engineers, their managers, and the general public understand the problem much more easily.

Let us know at bufferbloat.net if you are interested in helping here.

Add a comment to this post 

[-- Attachment #1.2: Type: text/html, Size: 5532 bytes --]

[-- Attachment #2: f8d189bcbc1174d1e7ae15621d5b674f?s=48&d=&r=G --]
[-- Type: application/octet-stream, Size: 1745 bytes --]

[-- Attachment #3: jigsawfish2.png?w=90&h=82#038;h=82 --]
[-- Type: application/octet-stream, Size: 14864 bytes --]