Development issues regarding the cerowrt test router project
 help / color / mirror / Atom feed
From: dpreed@reed.com
To: "Dave Taht" <dave.taht@gmail.com>
Cc: "cerowrt-devel@lists.bufferbloat.net"
	<cerowrt-devel@lists.bufferbloat.net>
Subject: Re: [Cerowrt-devel] MTU question
Date: Fri, 13 Feb 2015 15:41:08 -0500 (EST)	[thread overview]
Message-ID: <1423860068.294931127@apps.rackspace.com> (raw)
In-Reply-To: <CAA93jw4KNf-=9RLBN8ZaK7_aDNa8PcDVjJj+r0Wq757gtFQsEQ@mail.gmail.com>

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

  reply	other threads:[~2015-02-13 20:41 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-02-12 21:46 David Lang
2015-02-12 22:23 ` Dave Taht
2015-02-13 20:41   ` dpreed [this message]
2015-02-13 21:03     ` Dave Taht
2015-02-12 22:30 ` Valdis.Kletnieks

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://lists.bufferbloat.net/postorius/lists/cerowrt-devel.lists.bufferbloat.net/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1423860068.294931127@apps.rackspace.com \
    --to=dpreed@reed.com \
    --cc=cerowrt-devel@lists.bufferbloat.net \
    --cc=dave.taht@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox