[Cerowrt-devel] MTU question

[Cerowrt-devel] MTU question

[David Lang]

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

Re: [Cerowrt-devel] MTU question

[Dave Taht]

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 <david@lang.hm> 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
> Cerowrt-devel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel



-- 
Dave Täht

thttp://www.bufferbloat.net/projects/bloat/wiki/Upcoming_Talks

Re: [Cerowrt-devel] MTU question

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 601 bytes --]

On Thu, 12 Feb 2015 13:46:47 -0800, David Lang said:
> 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?

It tends to totally ruin latency.  Go read up on why things like ssh turn off
Nagle.  I have no reason to expect the same "leaving stuff in a buffer while we
wait for more data to make a full packet" will work any better on Wifi.


[-- Attachment #2: Type: application/pgp-signature, Size: 848 bytes --]

Re: [Cerowrt-devel] MTU question

[dpreed]

[-- Attachment #1: Type: text/plain, Size: 2437 bytes --]


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" <dave.taht@gmail.com> 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 <david@lang.hm> 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
> > Cerowrt-devel@lists.bufferbloat.net
> > https://lists.bufferbloat.net/listinfo/cerowrt-devel
> 
> 
> 
> --
> Dave Täht
> 
> thttp://www.bufferbloat.net/projects/bloat/wiki/Upcoming_Talks
> _______________________________________________
> Cerowrt-devel mailing list
> Cerowrt-devel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel
> 

[-- Attachment #2: Type: text/html, Size: 3863 bytes --]

Re: [Cerowrt-devel] MTU question

[Dave Taht]

[-- Attachment #1: Type: text/plain, Size: 3843 bytes --]

On Fri, Feb 13, 2015 at 12:41 PM,  <dpreed@reed.com> wrote:
> 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).

+1

> 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.

One of the more speculative ideas for aggregation I've had was to be mildly
more aware of packet pairing in the AP, where we could generally expect at
least half the formerly outgoing packets to be matched by new incoming
packets.

given a choice between scheduling a transmission to station

A: 3 packets outstanding (8 last seen in the other direction)
B: 2 packets outstanding (1 last seen in the other direction)
C: 5 packets outstanding (6 last seen in the other direction)

I would schedule transmissions in the order B, C, A, in the hope that more
packets would arrive for A by the time it was scheduled.

I'm not sure how to describe this mathematically, or whether the concept
could be made stable, or to what extent it would, indeed, better pack
aggregates with tons of stations in use or not.

>
> 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

There a math term for "unlumpy"? :)

> packet (transmission unit size / transmission rate) to be limited, so slow
> transmitters can't fill up the airtime with low rate, long packets.

yes. Also, I proposed here that when retransmits and media acquisition start
to get out of hand that the maximum ampdu be reduced to 1ms, and we just
eat the frame overhead in favor of providing more service to more devices.

http://www.spinics.net/lists/linux-wireless/msg133340.html

>
>
> 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" <dave.taht@gmail.com>
> 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 <david@lang.hm> 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
>> > Cerowrt-devel@lists.bufferbloat.net
>> > https://lists.bufferbloat.net/listinfo/cerowrt-devel
>>
>>
>>
>> --
>> Dave Täht
>>
>> thttp://www.bufferbloat.net/projects/bloat/wiki/Upcoming_Talks
>> _______________________________________________
>> Cerowrt-devel mailing list
>> Cerowrt-devel@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>>



-- 
Dave Täht

thttp://www.bufferbloat.net/projects/bloat/wiki/Upcoming_Talks

[-- Attachment #2: Type: text/html, Size: 5084 bytes --]