[Cerowrt-devel] Baby jumbo frames support?

[Dave Taht]

I'd kind of hoped someone other than me would answer this because the
details are long and intricate.

Another way to put it is that after hearing simon barber, myself,
andrew mcgregor spend 5 hours trying to explain the issues of
wireless-n to kathie nichols and jg and multiple other devs one day, a
prominent networking developer in the room shook his head, and said
"I'm glad I work on 10GigE. It's so much simpler".

Bigger packet sizes are not necessary or useful in the current wifi
standards because of packet aggregation which bundles up to 42 packets
in one burst. There's this HUGE header, followed by X packets in an
aggregated "A-MPDU".

A-MPDU bursts = TSO/GSO on steroids, with similar (but worse)
attendant side effects (big checksum and ack on portions or the whole
bundle!), and dwarf classic (9k) jumbo packets in size - and don't
require reframing when put on the internet.

A-MSDU is a similar concept but proven thus far hard to implement.

On my bad days I think the ratio between ack (68) and max packet
(1500) MTU is too large, already.

As for other wireless standards, say something high bandwidth for tvs,
I could see short haul stuff taking advantage of larger frame sizes,
but as for wifi, gprs, 3g,4g, no.

Felix and I did a pair of podcasts on this stuff, one when we first
met back in the early days of bufferbloat, and the second in august
after we'd been working together for a while. The first half of the
second is largely historical; it got detailed about 40+ minutes in.

I think these are only useful now as historical documents but if enjoy
this sort of background noise, certainly they were stepping stones
towards mutual understanding for felix and I.

http://mirrors.bufferbloat.net/podcasts/BPR-The_Wireless_Stack.mp3
http://huchra.bufferbloat.net/~d/talks/felix/ (includes a transcript)

I ran out of budget for transcripts soon afterward. :(

Anyway...

As the wifi standards are backward compatible, the surrounding frame
is broadcast at a rate that made sense in 1998 in many cases, so the
time spent establishing a frame can far outweigh the actual data
transfered.

This is not a bad description of what happens in wireless-n, but dated.

http://thenetworkguy.typepad.com/nau/2007/12/caveats-of-larg.html

Kind of missed the infinite retry bugs endemic today... among others...

Lastly Andrew McGregor has a wonderful and apparently unpublishable
(far beyond the MPU) paper on how the minstrel rate selection
algorithm works, rate selection and retry being the big thing that
throws the fixed size/time/width calculation you use below overboard,
documenting 1/3 a page of related variables in wireless.

Perhaps he can send that over? I wish I'd recorded the 3 hours he
spent with me explaining in detail how minstrel worked, it was these
three indepth conversations and that paper that were the seed crystals
of converting my obsolete-as-of-2006 understanding of wifi to where I
stand now.

I almost forgot to mention that 802.11e has 4 queues already, each
with different algos for grabbing airtime - and an effectively
invisible set of queues for managing frames and crypto...



On Sat, Jun 16, 2012 at 8:54 AM,  <dpreed at reed.com> wrote:
> Digging deeper, there is also a good reason for bigger frames when one is
> using 600 Mbit 802.11 signalling ( that's 75 bytes per microsecond).  A 1500
> byte frame occupies only 50 microseconds of airtime. Not much return for the
> investment in contention time (5-10 microseconds) by the transmitting
> station.  9000 byte frames would be good, just as they are for GigE.
>
>
>
> -----Original Message-----
> From: "Alexander Hulse" <ah at amch.net>
> Sent: Saturday, June 16, 2012 5:53am
> To: cerowrt-devel at lists.bufferbloat.net
> Subject: [Cerowrt-devel] Baby jumbo frames support?
>
> I've done some basic research and some (unsuccessful) hacking the on the
> driver source for the ag71xx driver and was wondering about baby jumbo frame
> support?
>
> I know that the WNDR37/800's built in switch supports passing jumbo frames,
> but the underlying router interfaces do not support large MTU frames.
>
> However, this:
>
> http://wiki.mikrotik.com/wiki/Manual:Maximum_Transmission_Unit_on_RouterBoards
>
> seems to imply that the built-in interfaces ought to support baby jumbo
> frames, unless I'm misunderstanding what they are saying.
>
> As to the "Why?", in the UK, the fibre offering by BT using FTTC uses a
> PPPoE modem that can understand PPPoE packets with an MTU 1508, as described
> in RFC 4638.
>
> It was possible using a Netgear WNR834T with the application of some patches
> from the pppd git:
>
> http://git.ozlabs.org/?p=ppp.git;a=commit;h=fd1dcdf758418f040da3ed801ab001b5e46854e7
> http://wiki.aa.net.uk/index.php/FTTC_Modem
>
> Would this be a useful feature to add (if possible) to CeroWrt so that full
> sized frames can be used if the ISP / connection supports it?
>
> Alex
> _______________________________________________
> Cerowrt-devel mailing list
> Cerowrt-devel at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>
>
> _______________________________________________
> Cerowrt-devel mailing list
> Cerowrt-devel at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>



-- 
Dave Täht
http://www.bufferbloat.net/projects/cerowrt/wiki - "3.3.8-6 is out
with fq_codel!"