<font face="arial" size="2"><p style="margin:0;padding:0;">The end-to-end argument against putting functionality in the network is a modularity principle, as you know. The exception is when there is a function that you want to provide that is not strictly end-to-end.</p>
<p style="margin:0;padding:0;"> </p>
<p style="margin:0;padding:0;">Congestion is one of them - there is a fundamental issue with congestion that it happens because of collective actions among independent actors.</p>
<p style="margin:0;padding:0;"> </p>
<p style="margin:0;padding:0;">So if you want to achieve the goals of the modularity principle, you need to find either a) the minimal sensing and response you can put in the network that allows the independent actors to "cooperate", or b) require the independent actors to discover and communicate amongst each other individually.</p>
<p style="margin:0;padding:0;"> </p>
<p style="margin:0;padding:0;">Any solution that tries to satisfy the modularity principle has the property that it provides sufficient information, in a sufficiently timely manner, for the independent actors to respond "cooperatively" to resolve the issue (by reducing their transmission volume in some - presumably approximately fair - way).</p>
<p style="margin:0;padding:0;"> </p>
<p style="margin:0;padding:0;">Sufficiently timely is bounded by the "draining time" of a switch's outbound link's queue.  For practical applications of the Internet today, the "draining time" should never exceed about 30-50 msec., at the outbound link's rate.  However, the optimal normal depth of the queue should be no larger than the size needed to keep the outbound link continuously busy at its peak rate whatever that is (for a shared WiFi access point the peak rate is highly variable as you know).</p>
<p style="margin:0;padding:0;"> </p>
<p style="margin:0;padding:0;">This suggests that the minimal function the network must provide to the endpoints is the packet's "instantaneous" contribution to the draining time of the most degraded link on the path.</p>
<p style="margin:0;padding:0;"> </p>
<p style="margin:0;padding:0;">Given this information, a pair of endpoints know what to do.  If it is a receiver-managed windowed protocol like TCP, the window needs to be adjusted to minimize the contribution to the "draining time" of the currently bottlenecked node, to stop pipelined flows from its sender as quickly as possible.</p>
<p style="margin:0;padding:0;"> </p>
<p style="margin:0;padding:0;">In that case, cooperative behavior is implicit.  The bottleneck switch needs only to inform all independent flows of their contribution, and with an appropriate control loop on each node, approximate fairness can result.</p>
<p style="margin:0;padding:0;"> </p>
<p style="margin:0;padding:0;">And this is the most general approach.  Switches have no idea of the "meaning" of the flows, so beyond timely and accurate reporting, they can't make useful decisions about fixing congestion.</p>
<p style="margin:0;padding:0;"> </p>
<p style="margin:0;padding:0;">Note that this all is an argument about architectural principles and the essence of the congestion problem.</p>
<p style="margin:0;padding:0;"> </p>
<p style="margin:0;padding:0;">I could quibble about whether fq_codel is the simplest or best choice for the minimal functionality an "internetwork" could provide.  But it's pretty nice and simple.  Not clear it works for a decentralized protocol like WiFi as a link - but something like it would seem to be the right thing.</p>
<p style="margin:0;padding:0;"> </p>
<p style="margin:0;padding:0;"> </p>
<p style="margin:0;padding:0;"><br class="WM_COMPOSE_SIGNATURE_START" /><br class="WM_COMPOSE_SIGNATURE_END" /><br /><br />On Wednesday, May 21, 2014 12:30pm, "Dave Taht" <dave.taht@gmail.com> said:<br /><br /></p>
<div id="SafeStyles1400693480">
<p style="margin:0;padding:0;">> On Wed, May 21, 2014 at 9:03 AM,  <dpreed@reed.com> wrote:<br />> > In reality we don't disagree on this:<br />> ><br />> ><br />> ><br />> > On Wednesday, May 21, 2014 11:19am, "Dave Taht" <dave.taht@gmail.com><br />> said:<br />> ><br />> >><br />> ><br />> >> Well, I disagree somewhat. The downstream shaper we use works quite<br />> >> well, until we run out of cpu at 50mbits. Testing on the ubnt edgerouter<br />> >> has had the inbound shaper work up a little past 100mbits. So there is<br />> >> no need (theoretically) to upgrade the big fat head ends if your cpe is<br />> >> powerful enough to do the job. It would be better if the head ends did<br />> it,<br />> >> of course....<br />> >><br />> ><br />> ><br />> ><br />> > There is an advantage for the head-ends doing it, to the extent that each<br />> > edge device has no clarity about what is happening with all the other cpe<br />> > that are sharing that head-end. When there is bloat in the head-end even if<br />> > all cpe's sharing an upward path are shaping themselves to the "up to" speed<br />> > the provider sells, they can go into serious congestion if the head-end<br />> > queues can grow to 1 second or more of sustained queueing delay.  My<br />> > understanding is that head-end queues have more than that.  They certainly<br />> > do in LTE access networks.<br />> <br />> Compelling argument! I agree it would be best for the devices that have the<br />> most information about the network to manage themselves better.<br />> <br />> It is deeply ironic to me that I'm arguing for an e2e approach on fixing<br />> the problem in the field, with you!<br />> <br />> http://en.wikipedia.org/wiki/End-to-end_principle<br />> <br />> ><br />> ><br />> <br />> <br />> <br />> --<br />> Dave Täht<br />> <br />> NSFW:<br />> https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_indecent.article<br />></p>
</div></font>