<font face="tahoma" size="2"><p style="margin:0;padding:0;font-family: tahoma; font-size: 10pt; word-wrap: break-word;">Leaving stuff in a buffer in hopes that more will arrive is a terrible idea, proven over and over.</p>
<p style="margin:0;padding:0;font-family: tahoma; font-size: 10pt; word-wrap: break-word;"> </p>
<p style="margin:0;padding:0;font-family: tahoma; font-size: 10pt; word-wrap: break-word;">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.</p>
<p style="margin:0;padding:0;font-family: tahoma; font-size: 10pt; word-wrap: break-word;"> </p>
<p style="margin:0;padding:0;font-family: tahoma; font-size: 10pt; word-wrap: break-word;">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.</p>
<p style="margin:0;padding:0;font-family: tahoma; font-size: 10pt; word-wrap: break-word;"> </p>
<p style="margin:0;padding:0;font-family: tahoma; font-size: 10pt; word-wrap: break-word;">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.</p>
<p style="margin:0;padding:0;font-family: tahoma; font-size: 10pt; word-wrap: break-word;"> </p>
<!--WM_COMPOSE_SIGNATURE_START--><!--WM_COMPOSE_SIGNATURE_END-->
<p style="margin:0;padding:0;font-family: tahoma; font-size: 10pt; word-wrap: break-word;"><br /><br />On Thursday, February 12, 2015 5:23pm, "Dave Taht" <dave.taht@gmail.com> said:<br /><br /></p>
<div id="SafeStyles1423859701">
<p style="margin:0;padding:0;font-family: tahoma; font-size: 10pt; word-wrap: break-word;">> The max mtu for wifi is somewhere around 2300 bytes. So there is not a<br />> lot of benefit, and all kinds of headaches for other devices. I don't<br />> remember the max mtu for the ag71xx but I think it was 1514+vlan<br />> header only...<br />> <br />> No point. The only case where I can think it is useful is when you are<br />> tunnelling some protocol over another protocol on a wifi p2p link and<br />> don't want to mess with the underlying mtu. That was the use case for<br />> it when I tried to deploy ipv4 over ipv6 with the nat work being done<br />> on the edgepoints a few years back.<br />> <br />> On Thu, Feb 12, 2015 at 1:46 PM, David Lang <david@lang.hm> wrote:<br />> > It occured to me as I was driving home last night that if the APs are<br />> > working to combine packets into a single transmission due to the high<br />> > overhead of independent transmissions, would it possibly improve wifi<br />> > performance to just configure a larger MTU?<br />> ><br />> > Has anyone done any experimentation in this area?<br />> ><br />> > David Lang<br />> > _______________________________________________<br />> > Cerowrt-devel mailing list<br />> > Cerowrt-devel@lists.bufferbloat.net<br />> > https://lists.bufferbloat.net/listinfo/cerowrt-devel<br />> <br />> <br />> <br />> --<br />> Dave Täht<br />> <br />> thttp://www.bufferbloat.net/projects/bloat/wiki/Upcoming_Talks<br />> _______________________________________________<br />> Cerowrt-devel mailing list<br />> Cerowrt-devel@lists.bufferbloat.net<br />> https://lists.bufferbloat.net/listinfo/cerowrt-devel<br />> </p>
</div></font>