From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp105.iad3a.emailsrvr.com (smtp105.iad3a.emailsrvr.com [173.203.187.105]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by huchra.bufferbloat.net (Postfix) with ESMTPS id 5903D21F425 for ; Fri, 13 Feb 2015 12:41:09 -0800 (PST) Received: from smtp6.relay.iad3a.emailsrvr.com (localhost.localdomain [127.0.0.1]) by smtp6.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 73098180295; Fri, 13 Feb 2015 15:41:08 -0500 (EST) Received: from app15.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by smtp6.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 5834718024B; Fri, 13 Feb 2015 15:41:08 -0500 (EST) X-Sender-Id: dpreed@reed.com Received: from app15.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by 0.0.0.0:25 (trex/5.4.2); Fri, 13 Feb 2015 20:41:08 GMT Received: from reed.com (localhost.localdomain [127.0.0.1]) by app15.wa-webapps.iad3a (Postfix) with ESMTP id 487B780041; Fri, 13 Feb 2015 15:41:08 -0500 (EST) Received: by apps.rackspace.com (Authenticated sender: dpreed@reed.com, from: dpreed@reed.com) with HTTP; Fri, 13 Feb 2015 15:41:08 -0500 (EST) Date: Fri, 13 Feb 2015 15:41:08 -0500 (EST) From: dpreed@reed.com To: "Dave Taht" MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_20150213154108000000_65064" Importance: Normal X-Priority: 3 (Normal) X-Type: html In-Reply-To: References: X-Auth-ID: dpreed@reed.com Message-ID: <1423860068.294931127@apps.rackspace.com> X-Mailer: webmail/11.3.12-RC Cc: "cerowrt-devel@lists.bufferbloat.net" Subject: Re: [Cerowrt-devel] MTU question X-BeenThere: cerowrt-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: Development issues regarding the cerowrt test router project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Feb 2015 20:41:38 -0000 ------=_20150213154108000000_65064 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =0ALeaving stuff in a buffer in hopes that more will arrive is a terrible i= dea, proven over and over.=0A =0AHowever, if you already have a packet wait= ing to go out, combining packets after that with each other does create som= e benefit at no cost (reducing negotiation time). Coupled with something l= ike FQ_Codel so that the combined packets are managed properly, and the que= ue doesn't bloat, there's a likely benefit for small packets in reducing ov= erhead.=0A =0AOf course you want the "turn taking" for packets coming in to= the access point from different stations to be "unlumpy" so the maximum *a= irtime* of a packet (transmission unit size / transmission rate) to be limi= ted, so slow transmitters can't fill up the airtime with low rate, long pac= kets.=0A =0ASo you don't want big MTU's on the air link, and you want the a= ir link to discourage occupancy by low-data-rate transmitters.=0A =0A=0A=0A= On Thursday, February 12, 2015 5:23pm, "Dave Taht" sa= id:=0A=0A=0A=0A> The max mtu for wifi is somewhere around 2300 bytes. So th= ere is not a=0A> lot of benefit, and all kinds of headaches for other devic= es. I don't=0A> remember the max mtu for the ag71xx but I think it was 1514= +vlan=0A> header only...=0A> =0A> No point. The only case where I can think= it is useful is when you are=0A> tunnelling some protocol over another pro= tocol on a wifi p2p link and=0A> don't want to mess with the underlying mtu= . That was the use case for=0A> it when I tried to deploy ipv4 over ipv6 wi= th the nat work being done=0A> on the edgepoints a few years back.=0A> =0A>= On Thu, Feb 12, 2015 at 1:46 PM, David Lang wrote:=0A> > I= t occured to me as I was driving home last night that if the APs are=0A> > = working to combine packets into a single transmission due to the high=0A> >= overhead of independent transmissions, would it possibly improve wifi=0A> = > performance to just configure a larger MTU?=0A> >=0A> > Has anyone done a= ny experimentation in this area?=0A> >=0A> > David Lang=0A> > _____________= __________________________________=0A> > Cerowrt-devel mailing list=0A> > C= erowrt-devel@lists.bufferbloat.net=0A> > https://lists.bufferbloat.net/list= info/cerowrt-devel=0A> =0A> =0A> =0A> --=0A> Dave T=C3=A4ht=0A> =0A> thttp:= //www.bufferbloat.net/projects/bloat/wiki/Upcoming_Talks=0A> ______________= _________________________________=0A> Cerowrt-devel mailing list=0A> Cerowr= t-devel@lists.bufferbloat.net=0A> https://lists.bufferbloat.net/listinfo/ce= rowrt-devel=0A> ------=_20150213154108000000_65064 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Leaving stuff in a buffe= r in hopes that more will arrive is a terrible idea, proven over and over.<= /p>=0A

 

=0A

However, if you alre= ady have a packet waiting to go out, combining packets after that with each= other does create some benefit at no cost (reducing negotiation time). &nb= sp;Coupled with something like FQ_Codel so that the combined packets are ma= naged properly, and the queue doesn't bloat, there's a likely benefit for s= mall packets in reducing overhead.

=0A

 

=0A

Of course you want the "turn taking" for packets coming in t= o the access point from different stations to be "unlumpy" so the maximum *= airtime* of a packet (transmission unit size / transmission rate) to be lim= ited, so slow transmitters can't fill up the airtime with low rate, long pa= ckets.

=0A

 

=0A

So you don't = want big MTU's on the air link, and you want the air link to discourage occ= upancy by low-data-rate transmitters.

=0A

 

=0A= =0A



On Thursday, February 12, 2015 5:23pm, "Dave Taht" &l= t;dave.taht@gmail.com> said:

=0A
=0A

> The max mtu for wifi is somewhere around = 2300 bytes. So there is not a
> lot of benefit, and all kinds of he= adaches for other devices. I don't
> remember the max mtu for the a= g71xx but I think it was 1514+vlan
> header only...
>
> No point. The only case where I can think it is useful is when you ar= e
> tunnelling some protocol over another protocol on a wifi p2p li= nk and
> don't want to mess with the underlying mtu. That was the u= se 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 tha= t if the APs are
> > working to combine packets into a single tr= ansmission due to the high
> > overhead of independent transmiss= ions, would it possibly improve wifi
> > performance to just con= figure a larger MTU?
> >
> > Has anyone done any expe= rimentation in this area?
> >
> > David Lang
>= ; > _______________________________________________
> > Cerow= rt-devel mailing list
> > Cerowrt-devel@lists.bufferbloat.net> > https://lists.bufferbloat.net/listinfo/cerowrt-devel
>=
>
>
> --
> Dave T=C3=A4ht
> > thttp://www.bufferbloat.net/projects/bloat/wiki/Upcoming_Talks
> _______________________________________________
> Cerowrt-dev= el mailing list
> Cerowrt-devel@lists.bufferbloat.net
> htt= ps://lists.bufferbloat.net/listinfo/cerowrt-devel
>

=0A
------=_20150213154108000000_65064--