<font face="times new roman" size="2"><p style="margin:0;padding:0;font-family: 'times new roman'; font-size: 10pt; word-wrap: break-word;">Even better, it would be fun to get access to an Arista switch and some high performance TCP sources and sinks, and demonstrate extreme bufferbloat compared to a small-buffer switch. Just a demo, not a simulation full of assumptions and guesses.</p>
<p style="margin:0;padding:0;font-family: 'times new roman'; font-size: 10pt; word-wrap: break-word;"> </p>
<p style="margin:0;padding:0;font-family: 'times new roman'; font-size: 10pt; word-wrap: break-word;">RRUL, basically.</p>
<p style="margin:0;padding:0;font-family: 'times new roman'; font-size: 10pt; word-wrap: break-word;"> </p>
<!--WM_COMPOSE_SIGNATURE_START--><!--WM_COMPOSE_SIGNATURE_END-->
<p style="margin:0;padding:0;font-family: 'times new roman'; font-size: 10pt; word-wrap: break-word;"><br /><br />On Monday, June 6, 2016 10:52pm, dpreed@reed.com said:<br /><br /></p>
<div id="SafeStyles1465268171">
<p style="margin:0;padding:0;margin: 0; padding: 0; font-family: 'times new roman'; font-size: 10pt; word-wrap: break-word;">So did anyone write a response debunking their paper? Their NS-2 simulation is most likely the erroneous part of their analysis - the white paper would not pass a review by qualified referees because there is no way to check their results and some of what they say beggars belief.</p>
<p style="margin:0;padding:0;margin: 0; padding: 0; font-family: 'times new roman'; font-size: 10pt; word-wrap: break-word;"> </p>
<p style="margin:0;padding:0;margin: 0; padding: 0; font-family: 'times new roman'; font-size: 10pt; word-wrap: break-word;">Bechtolsheim is one of those guys who can write any damn thing and it becomes "truth" - mostly because he co-founded Sun. But that doesn't mean that he can't make huge errors - any of us can.</p>
<p style="margin:0;padding:0;margin: 0; padding: 0; font-family: 'times new roman'; font-size: 10pt; word-wrap: break-word;"> </p>
<p style="margin:0;padding:0;margin: 0; padding: 0; font-family: 'times new roman'; font-size: 10pt; word-wrap: break-word;">The so-called TCP/IP Bandwidth Capture effect that he refers to doesn't sound like any capture effect I've ever heard of. There is an "Ethernet Capture Effect" (which is cited), which is due to properties of CSMA/CD binary exponential backoff, not anything to do with TCP's flow/congestion control. So it has that "truthiness" that makes glib people sound like they know what they are talking about, but I'd like to see a reference that says this is a property of TCP!</p>
<p style="margin:0;padding:0;margin: 0; padding: 0; font-family: 'times new roman'; font-size: 10pt; word-wrap: break-word;"> </p>
<p style="margin:0;padding:0;margin: 0; padding: 0; font-family: 'times new roman'; font-size: 10pt; word-wrap: break-word;">What's interesting is that the reference to the Ethernet Capture Effect in that white paper proposes a solution that involves changing the backoff algorithm slightly at the Ethernet level - NOT increasing buffer size!</p>
<p style="margin:0;padding:0;margin: 0; padding: 0; font-family: 'times new roman'; font-size: 10pt; word-wrap: break-word;"> </p>
<p style="margin:0;padding:0;margin: 0; padding: 0; font-family: 'times new roman'; font-size: 10pt; word-wrap: break-word;">Another thing that would probably improve matters a great deal would be to drop/ECN-mark packets when a contended output port on an Arista switch develops a backlog. This will throttle TCP sources sharing the path.</p>
<p style="margin:0;padding:0;margin: 0; padding: 0; font-family: 'times new roman'; font-size: 10pt; word-wrap: break-word;"> </p>
<p style="margin:0;padding:0;margin: 0; padding: 0; font-family: 'times new roman'; font-size: 10pt; word-wrap: break-word;">The comments in the white paper that say that ACK contention in TCP in the reverse direction are the problem that causes the "so-called TCP/IP Bandwidth Capture effect" that is invented by the authors appears to be hogwash of the first order.</p>
<p style="margin:0;padding:0;margin: 0; padding: 0; font-family: 'times new roman'; font-size: 10pt; word-wrap: break-word;"> </p>
<p style="margin:0;padding:0;margin: 0; padding: 0; font-family: 'times new roman'; font-size: 10pt; word-wrap: break-word;">Debunking Bechtolsheim credibly would get a lot of attention to the bufferbloat cause, I suspect.</p>
<p style="margin:0;padding:0;margin: 0; padding: 0; font-family: 'times new roman'; font-size: 10pt; word-wrap: break-word;"> </p>
<p style="margin:0;padding:0;margin: 0; padding: 0; font-family: 'times new roman'; font-size: 10pt; word-wrap: break-word;"><br /><br />On Monday, June 6, 2016 5:16pm, "Ketan Kulkarni" <ketkulka@gmail.com> said:<br /><br /></p>
<div id="SafeStyles1465266791">
<div dir="ltr">some time back they had this whitepaper -
<div>"Why Big Data Needs Big Buffer Switches"<br />
<div><a href="http://www.arista.com/assets/data/pdf/Whitepapers/BigDataBigBuffers-WP.pdf">http://www.arista.com/assets/data/pdf/Whitepapers/BigDataBigBuffers-WP.pdf</a></div>
</div>
<div>the type of apps they talk about is big data, hadoop etc</div>
</div>
<div class="gmail_extra"><br />
<div class="gmail_quote">On Mon, Jun 6, 2016 at 11:37 AM, Mikael Abrahamsson <span dir="ltr"><<a href="mailto:swmike@swm.pp.se" target="_blank">swmike@swm.pp.se</a>></span> wrote:<br />
<blockquote class="gmail_quote" style="margin: 0 0 0 .8ex; border-left: 1px #ccc solid; padding-left: 1ex;"><span class=""><span class="">On Mon, 6 Jun 2016, Jonathan Morton wrote:<br /><br /></span></span>
<blockquote class="gmail_quote" style="margin: 0 0 0 .8ex; border-left: 1px #ccc solid; padding-left: 1ex;">At 100ms buffering, their 10Gbps switch is effectively turning any DC it’s installed in into a transcontinental Internet path, as far as peak latency is concerned. Just because RAM is cheap these days…</blockquote>
Nono, nononononono. I can tell you they're spending serious money on inserting this kind of buffering memory into these kinds of devices. Buying these devices without deep buffers is a lot lower cost.<br /><br /> These types of switch chips either have on-die memory (usually 16MB or less), or they have very expensive (a direct cost of lowered port density) off-chip buffering memory.<br /><br /> Typically you do this:<br /><br /> ports ---|-------<br /> ports ---| |<br /> ports ---| chip |<br /> ports ---|-------<br /><br /> Or you do this<br /><br /> ports ---|------|---buffer<br /> ports ---| chip |---TCAM<br /> --------<br /><br /> or if you do a multi-linecard-device<br /><br /> ports ---|------|---buffer<br /> | chip |---TCAM<br /> --------<br /> |<br /> switch fabric<br /><br /> (or any variant of them)<br /><br /> So basically if you want to buffer and if you want large L2-L4 lookup tables, you have to sacrifice ports. Sacrifice lots of ports.<br /><br /> So never say these kinds of devices add buffering because RAM is cheap. This is most definitely not why they're doing it. Buffer memory for them is EXTREMELY EXPENSIVE.<span class="HOEnZb"><span style="color: #888888;"><br /><br /> -- <br /> Mikael Abrahamsson email: <a href="mailto:swmike@swm.pp.se" target="_blank">swmike@swm.pp.se</a></span></span><br />_______________________________________________<br /> Cerowrt-devel mailing list<br /><a href="mailto:Cerowrt-devel@lists.bufferbloat.net">Cerowrt-devel@lists.bufferbloat.net</a><br /><a rel="noreferrer" href="https://lists.bufferbloat.net/listinfo/cerowrt-devel" target="_blank">https://lists.bufferbloat.net/listinfo/cerowrt-devel</a><br /><br /></blockquote>
</div>
</div>
</div>
</div></font>