Re: [Bloat] Random idea in reaction to all the discussion of TCP flavours - timestamps?

[Jim Gettys <jg@freedesktop.org>]

On Tue, Mar 15, 2011 at 8:47 PM, John W. Linville
<linville@tuxdriver.com> wrote:
>
> If you count mac80211 as part of the "driver", what is between the
> qdisc and the "driver"?  I wouldn't consider the bottom of the qdisc
> as the core of the stack.
>
> I would really like to see eBDP (or ALT or A* or something similar)
> implemented in a single place if possible, rather than reimplemented
> (perhaps poorly) in a series of drivers.  I know Felix and others think
> that 802.11n aggregation makes that impossible, but I'm inclined to
> think that is still at least partly from a bias towards throughput
> at the expense of latency -- I could be wrong! :-)

I'm told by our cell phone wireless people there are similar concerns
for the wireless cellular technologies; in their case  I encouraged
them strongly today to join the mailing list. Let's also distinguish
between "can't do it with today's broken hardware" (of which there is
almost certainly an ample supply), and having a solution that can work
when the hardware is cooperative.

"(2) Less well known to non-cellular folks is the fact that the *full
buffer* packet data cell throughput of EVDO or HSPA is noticeably
higher than that with *bursty* traffic at decent load. Part of it is
due to (1)  above but a second part is due to the fact that each
cellular link is  made more efficient through multi-user diversity
gain that exploits
fading channel peaks of independent users while still utilizing the
link fully provided there are enough users - my point is, such gains
dilute when a user enjoying a channel peak doesn't have data waiting
in his
buffer at that time... It helps to keep users' buffers non-empty from
this perspective..."

As I pointed out to them, it may (or may not) be that things just work
out well; if the channel is busy, you'll have more time for
aggregation of packets to naturally occur.  We don't need to run the
channel efficiently when the channel isn't saturated.  Whenever the
air isn't busy, it doesn't matter if we don't bother to aggregate.

Who knows what those driver interfaces look like at this point?  Has
anyone tried to grok what's in Android for those drivers (if enough of
the source is available to them to be useful...)
                            - Jim