From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ob0-x236.google.com (mail-ob0-x236.google.com [IPv6:2607:f8b0:4003:c01::236]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 6D89021F424 for ; Fri, 13 Feb 2015 13:03:25 -0800 (PST) Received: by mail-ob0-f182.google.com with SMTP id nt9so23967760obb.13 for ; Fri, 13 Feb 2015 13:03:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=y8r1m99YL7rQzMJivLam4esiisa2nTmD4++PIgavtxU=; b=c9r4cfDRxYCDoaTMQ+bX2FlYRQONsn+JsoXLYWNQi9sXM23z3DBlqW1Y9a0SVer2EI BybZZb+MOF+Y9a/eMxUYiBmowo/jcS06Z+m3fLzSjfOFioiBa6Vb1oE8LlnNzldvL/tl CFU3MZXdbJsXWgRUvfcRzvGUjTeVzN8+UYYZXbA/5f6MQNoF8iLvnoRNTm6gSOGPjLzi tGTdLvcN01hqJY5NitH0hf0diFPVfVKZ9QSRI6qHKMVaBT/6LitYStDBoKtl2vivlhu7 R6wsT6Xk401dOB6AT6Vg2cnNXhCO+7iv14lZNb5IA02Gesvj+NEylXLfoQiYW65jyf7w lsAA== MIME-Version: 1.0 X-Received: by 10.202.204.88 with SMTP id c85mr7269878oig.81.1423861404930; Fri, 13 Feb 2015 13:03:24 -0800 (PST) Received: by 10.202.51.66 with HTTP; Fri, 13 Feb 2015 13:03:24 -0800 (PST) In-Reply-To: <1423860068.294931127@apps.rackspace.com> References: <1423860068.294931127@apps.rackspace.com> Date: Fri, 13 Feb 2015 13:03:24 -0800 Message-ID: From: Dave Taht To: David Reed Content-Type: multipart/alternative; boundary=001a1134fd4c40190a050efe914c Cc: linux-wireless , Derrick Pallas , "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 21:03:54 -0000 --001a1134fd4c40190a050efe914c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Feb 13, 2015 at 12:41 PM, 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 packet= s > 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 slo= w > transmitters can't fill up the airtime with low rate, long packets. yes. Also, I proposed here that when retransmits and media acquisition star= t 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" > 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 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=C3=A4ht >> >> 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 >> --=20 Dave T=C3=A4ht thttp://www.bufferbloat.net/projects/bloat/wiki/Upcoming_Talks --001a1134fd4c40190a050efe914c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Feb 13, 2015 at 12:41 PM, =C2=A0<dpreed@reed.com> wrote:
> Leaving= stuff in a buffer in hopes that more will arrive is a terrible idea,
&g= t; proven over and over.
>
> =C2=A0
>
> However, if= you already have a packet waiting to go out, combining packets
> aft= er that with each other does create some benefit at no cost (reducing
&g= t; negotiation time).

+1

> Coupled with something like FQ= _Codel so that the
> combined packets are managed properly, and the q= ueue doesn't bloat, there's
> a likely benefit for small pack= ets in reducing overhead.

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

given a choice between sc= heduling a transmission to station

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

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 c= oncept could be made stable, or to what extent it would, indeed, better pac= k aggregates with tons of stations in use or not.

>
> Of co= urse you want the "turn taking" for packets coming in to the acce= ss
> point from different stations to be "unlumpy" so the m= aximum *airtime* of a

There a math term for "unlumpy"? :)<= br>
> packet (transmission unit size / transmission rate) to be limit= ed, so slow
> transmitters can't fill up the airtime with low rat= e, long packets.

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

http://www.spinics.net/lists/linux-wireles= s/msg133340.html

> =C2=A0
>
> So you don't wa= nt big MTU's on the air link, and you want the air link to
> disc= ourage occupancy by low-data-rate transmitters.
>
> =C2=A0
&= gt;
>
>
> On Thursday, February 12, 2015 5:23pm, "Da= ve Taht" <dave.taht@gmail.co= m>
> said:
>
>> The max mtu for wifi is somewhe= re 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 onl= y...
>>
>> No point. The only case where I can think it i= s 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 d= eploy ipv4 over ipv6 with the nat work being done
>> on the edgepo= ints 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 t= hat if the APs are
>> > working to combine packets into a singl= e transmission due to the high
>> > overhead of independent tra= nsmissions, would it possibly improve wifi
>> > performance to = just configure a larger MTU?
>> >
>> > Has anyone d= one any experimentation in this area?
>> >
>> > Dav= id Lang
>> > _______________________________________________>> > Cerowrt-devel mailing list
>> > Cerowrt-devel@lists.bufferbloat.net<= /a>
>> > https://lists.bufferbloat.net/listinfo/cerowrt-devel
>= >
>>
>>
>> --
>> Dave T=C3=A4ht
&= gt;>
>> thttp://www.bufferbloat.net/projects/bloat/wiki/Upcoming= _Talks
>> _______________________________________________
&= gt;> Cerowrt-devel mailing list
>> Cerowrt-devel@lists.bufferbloat.net
>&= gt; https:= //lists.bufferbloat.net/listinfo/cerowrt-devel
>>


<= br>--
Dave T=C3=A4ht

thttp://www.bufferbloat.net/projects/bloat/w= iki/Upcoming_Talks
--001a1134fd4c40190a050efe914c--