Leaving stuff in a buffer in hopes that more will arrive is a terrible idea, 
proven over and over.
 
However, if you already have a packet waiting to go out, combining packets 
after that with each other does create some benefit at no cost (reducing 
negotiation time).  Coupled with something like FQ_Codel so that the combined 
packets are managed properly, and the queue doesn't bloat, there's a likely 
benefit for small packets in reducing overhead.
 
Of course you want the "turn taking" for packets coming in to the access point 
from different stations to be "unlumpy" so the maximum *airtime* of a packet 
(transmission unit size / transmission rate) to be limited, so slow 
transmitters can't fill up the airtime with low rate, long packets.
 
So you don't want big MTU's on the air link, and you want the air link to 
discourage occupancy by low-data-rate transmitters.
 


On Thursday, February 12, 2015 5:23pm, "Dave Taht" <[email protected]> said:



> The max mtu for wifi is somewhere around 2300 bytes. So there is not a
> lot of benefit, and all kinds of headaches for other devices. I don't
> remember the max mtu for the ag71xx but I think it was 1514+vlan
> header only...
> 
> No point. The only case where I can think it is useful is when you are
> tunnelling some protocol over another protocol on a wifi p2p link and
> don't want to mess with the underlying mtu. That was the use case for
> it when I tried to deploy ipv4 over ipv6 with the nat work being done
> on the edgepoints a few years back.
> 
> On Thu, Feb 12, 2015 at 1:46 PM, David Lang <[email protected]> wrote:
> > It occured to me as I was driving home last night that if the APs are
> > working to combine packets into a single transmission due to the high
> > overhead of independent transmissions, would it possibly improve wifi
> > performance to just configure a larger MTU?
> >
> > Has anyone done any experimentation in this area?
> >
> > David Lang
> > _______________________________________________
> > Cerowrt-devel mailing list
> > [email protected]
> > https://lists.bufferbloat.net/listinfo/cerowrt-devel
> 
> 
> 
> --
> Dave Täht
> 
> thttp://www.bufferbloat.net/projects/bloat/wiki/Upcoming_Talks
> _______________________________________________
> Cerowrt-devel mailing list
> [email protected]
> https://lists.bufferbloat.net/listinfo/cerowrt-devel
> 
_______________________________________________
Cerowrt-devel mailing list
[email protected]
https://lists.bufferbloat.net/listinfo/cerowrt-devel

Reply via email to