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.
Congestion is one of them - there is a fundamental issue with congestion that
it happens because of collective actions among independent actors.
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.
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).
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).
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.
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.
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.
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.
Note that this all is an argument about architectural principles and the
essence of the congestion problem.
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.
On Wednesday, May 21, 2014 12:30pm, "Dave Taht" <[email protected]> said:
> On Wed, May 21, 2014 at 9:03 AM, <[email protected]> wrote:
> > In reality we don't disagree on this:
> >
> >
> >
> > On Wednesday, May 21, 2014 11:19am, "Dave Taht" <[email protected]>
> said:
> >
> >>
> >
> >> Well, I disagree somewhat. The downstream shaper we use works quite
> >> well, until we run out of cpu at 50mbits. Testing on the ubnt edgerouter
> >> has had the inbound shaper work up a little past 100mbits. So there is
> >> no need (theoretically) to upgrade the big fat head ends if your cpe is
> >> powerful enough to do the job. It would be better if the head ends did
> it,
> >> of course....
> >>
> >
> >
> >
> > There is an advantage for the head-ends doing it, to the extent that each
> > edge device has no clarity about what is happening with all the other cpe
> > that are sharing that head-end. When there is bloat in the head-end even if
> > all cpe's sharing an upward path are shaping themselves to the "up to" speed
> > the provider sells, they can go into serious congestion if the head-end
> > queues can grow to 1 second or more of sustained queueing delay. My
> > understanding is that head-end queues have more than that. They certainly
> > do in LTE access networks.
>
> Compelling argument! I agree it would be best for the devices that have the
> most information about the network to manage themselves better.
>
> It is deeply ironic to me that I'm arguing for an e2e approach on fixing
> the problem in the field, with you!
>
> http://en.wikipedia.org/wiki/End-to-end_principle
>
> >
> >
>
>
>
> --
> Dave Täht
>
> NSFW:
> https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_indecent.article
>
_______________________________________________
Cerowrt-devel mailing list
[email protected]
https://lists.bufferbloat.net/listinfo/cerowrt-devel
