From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp110.iad3a.emailsrvr.com (smtp110.iad3a.emailsrvr.com [173.203.187.110]) (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 6384021F78E for ; Fri, 31 Jul 2015 09:47:35 -0700 (PDT) Received: from smtp22.relay.iad3a.emailsrvr.com (localhost.localdomain [127.0.0.1]) by smtp22.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id A1E5338072D; Fri, 31 Jul 2015 12:47:34 -0400 (EDT) Received: from app16.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by smtp22.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 81BBC380495; Fri, 31 Jul 2015 12:47:34 -0400 (EDT) X-Sender-Id: dpreed@reed.com Received: from app16.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by 0.0.0.0:25 (trex/5.4.2); Fri, 31 Jul 2015 16:47:34 GMT Received: from reed.com (localhost.localdomain [127.0.0.1]) by app16.wa-webapps.iad3a (Postfix) with ESMTP id 70D46380044; Fri, 31 Jul 2015 12:47:34 -0400 (EDT) Received: by apps.rackspace.com (Authenticated sender: dpreed@reed.com, from: dpreed@reed.com) with HTTP; Fri, 31 Jul 2015 12:47:34 -0400 (EDT) Date: Fri, 31 Jul 2015 12:47:34 -0400 (EDT) From: dpreed@reed.com To: "Sebastian Moeller" MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_20150731124734000000_81646" Importance: Normal X-Priority: 3 (Normal) X-Type: html In-Reply-To: <4D24A497-5784-493D-B409-F704804326A7@gmx.de> References: <356F5FEE-9FBD-4FF9-AC17-86A642D918A4@gmail.com> <5CC1DC90-DFAF-4A4D-8204-16CD4E20D6E3@gmx.de> <4D24A497-5784-493D-B409-F704804326A7@gmx.de> X-Auth-ID: dpreed@reed.com Message-ID: <1438361254.45977158@apps.rackspace.com> X-Mailer: webmail/11.5.5-RC X-Mailman-Approved-At: Sat, 08 Aug 2015 08:27:43 -0700 Cc: cerowrt-devel@lists.bufferbloat.net, make-wifi-fast@lists.bufferbloat.net Subject: Re: [Make-wifi-fast] [Cerowrt-devel] [tsvwg] Comments on draft-szigeti-tsvwg-ieee-802-11e X-BeenThere: make-wifi-fast@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2015 16:48:04 -0000 ------=_20150731124734000000_81646 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =0AHardware people tend to think about queues way too much in general. Que= ues should be almost never occupied. That causes the highest throughput po= ssible. And getting there is simple: push queueing back to the source.=0A = =0AThe average queue length into a shared medium should be as close to zero= as possible, and the variance should be as close to zero as possible. Thi= s is why smaller packets are generally better (modulo switching overhead).= =0A =0AThe ideal network is a network that maintains what I call a "ballist= ic" phase. (like a perfect metallic phase in a conductive material).=0A = =0AIt's easy to prove (as Kleinrock recently did with a student) that a net= work working optimally will have an average queue length everywhere that is= less than 1 packet.=0A =0AI think that is achievable, *even if there is a = WiFi network in the middle*, by thinking about the fact that the shared air= waves in a WiFi network behaves like a single link, so all the queues on in= dividual stations are really *one queue*, and that the optimal behavior of = that link will be achieved if there is at most one packet queued at a time.= =0A =0AThe problem with hardware folks and link folks is that they conflate= the link with the network - two very different things. The priority (if t= here is any) should be resolved by pushing back at the source, NOT by queue= ing low priority traffic inside the network!=0A=0AIf you think deeply about= this, it amounts to a distributed priority-managed source-endpoint-located= queuing strategy. That is not actually hard to think about - when packets= are dropped/ECN'd, the node that does the dropping knows a lot about the o= ther competing traffic - in particular, it implicitly reflects some informa= tion about the existence of competing traffic to the source/dest pair (and = in ECN, that can be rich information, like "the stated urgency of the compe= ting traffic"). Then the decision about retransmitting can be pushed to th= e sources, with a lot of information about what's competing in the congeste= d situation.=0A =0AThis is *far* better than leaving a lot of low priority = stuff clogging the intermediate nodes.=0A=0ASo ignore the hardware folks wh= o can't think about the fact that their link is embedded in a context that = the link doesn't understand at all! Don't let them convince you to queue = things, especially lower priority things.... instead push congestion back = to the source!!!=0A =0AI know it is really, really productive of *research = papers* to try to make a DSCP-based switching decision inside the network. = But it is totally ass-backwards in the big picture of an Internet.=0A=0A= =0AOn Thursday, July 30, 2015 11:27pm, "Sebastian Moeller" said:=0A=0A=0A=0A> Hi Jonathan,=0A> =0A> =0A> On July 30, 2015 11:56:23 P= M GMT+02:00, Jonathan Morton=0A> wrote:=0A> >Hardwa= re people tend to think in terms of simple priority queues, much=0A> >like= =0A> >old fashioned military communications (see the original IP precedence= =0A> >spec). Higher priority thus gets higher throughput as well as lower= =0A> >latency.=0A> >=0A> >I note also that in 802.11e, leftover space in a = TXOP can't be (or at=0A> >least=0A> >generally isn't) used opportunisticall= y for traffic from another class,=0A> >because the four queues are so rigid= ly separated.=0A> >=0A> >I think the hardware people are shortsighted in th= is respect. It's so=0A> >easy=0A> >to game simple priority queues when ther= e's no filter on the field=0A> >controlling it. That's why cake's Diffserv = layer works the way it does.=0A> >And=0A> >if I ever get the chance to do a= Wi-Fi specific version, I'll avoid=0A> >both of=0A> >the above problems.= =0A> >=0A> >- Jonathan Morton=0A> =0A> Thanks for the insight. Now I Start = to realize why my jome network behaves AS it=0A> does. When I run RRUL loca= lly from my macbook over WiFi with cerowrt as AP (which=0A> if I recall cor= rectly only uses AC_BE) the macbook's send starves the AP and hence=0A> the= macbook's receive tanks. Since macos seems to exercise the AC_v[I|o] queue= s,=0A> it hogs airtime and and all systems using lower AC classes see less = airtime, less=0A> bandwidth and higher latency. I guess my gut feeling woul= d be to run the AP always=0A> at AC_VO so it does not get starved. But real= ly calling such a system where any=0A> station can inflict that much pain/b= adness on others 'quality of service' makes me=0A> wonder. Then again it ce= rtainly affects quality of service just not deterministic=0A> or overall po= sitive ;)=0A> =0A> Best Regards=0A> Sebastian=0A> --=0A> Sent from my Andro= id device with K-9 Mail. Please excuse my brevity.=0A> ____________________= ___________________________=0A> Cerowrt-devel mailing list=0A> Cerowrt-deve= l@lists.bufferbloat.net=0A> https://lists.bufferbloat.net/listinfo/cerowrt-= devel=0A> ------=_20150731124734000000_81646 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hard= ware people tend to think about queues way too much in general.  Queue= s should be almost never occupied.  That causes the highest throughput= possible.  And getting there is simple: push queueing back to the sou= rce.

=0A

 

=0A

The average queue length into a shared medium should be as close to = zero as possible, and the variance should be as close to zero as possible. =  This is why smaller packets are generally better (modulo switching ov= erhead).

=0A

The ideal network is a network that maintains what I call a "bal= listic" phase.  (like a perfect metallic phase in a conductive materia= l).

=0A

 

=0A

It's easy to prove (as Kleinrock recently did with a student) that a = network working optimally will have an average queue length everywhere that= is less than 1 packet.

=0A

 

=0A

I think that is achievable, *even if there is a W= iFi network in the middle*, by thinking about the fact that the shared airw= aves in a WiFi network behaves like a single link, so all the queues on ind= ividual stations are really *one queue*, and that the optimal behavior of t= hat link will be achieved if there is at most one packet queued at a time.<= /p>=0A

 

=0A

=0A

 

= =0A

This is *far* better than leaving a lot of = low priority stuff clogging the intermediate nodes.

So ignore th= e hardware folks who can't think about the fact that their link is embedded= in a context that the link doesn't understand at all!   Don't let the= m convince you to queue things, especially lower priority things....  = instead push congestion back to the source!!!

=0A

 

=0A

I know it is really, really= productive of *research papers* to try to make a DSCP-based switching= decision inside the network.  But it is totally ass-backwards in the = big picture of an Internet.

=0A=0A



On Thurs= day, July 30, 2015 11:27pm, "Sebastian Moeller" <moeller0@gmx.de> sai= d:

=0A
=0A

> Hi Jonathan,
>
>
> On July 30, 20= 15 11:56:23 PM GMT+02:00, Jonathan Morton
> <chromatix99@gmail.c= om> wrote:
> >Hardware people tend to think in terms of simpl= e priority queues, much
> >like
> >old fashioned mili= tary communications (see the original IP precedence
> >spec). Hi= gher priority thus gets higher throughput as well as lower
> >la= tency.
> >
> >I note also that in 802.11e, leftover s= pace in a TXOP can't be (or at
> >least
> >generally = isn't) used opportunistically for traffic from another class,
> >= ;because the four queues are so rigidly separated.
> >
>= >I think the hardware people are shortsighted in this respect. It's so<= br />> >easy
> >to game simple priority queues when there'= s no filter on the field
> >controlling it. That's why cake's Di= ffserv layer works the way it does.
> >And
> >if I ev= er get the chance to do a Wi-Fi specific version, I'll avoid
> >= both of
> >the above problems.
> >
> >- Jo= nathan Morton
>
> Thanks for the insight. Now I Start to r= ealize why my jome network behaves AS it
> does. When I run RRUL lo= cally from my macbook over WiFi with cerowrt as AP (which
> if I re= call correctly only uses AC_BE) the macbook's send starves the AP and hence=
> the macbook's receive tanks. Since macos seems to exercise the A= C_v[I|o] queues,
> it hogs airtime and and all systems using lower = AC classes see less airtime, less
> bandwidth and higher latency. I= guess my gut feeling would be to run the AP always
> at AC_VO so i= t does not get starved. But really calling such a system where any
>= ; station can inflict that much pain/badness on others 'quality of service'= makes me
> wonder. Then again it certainly affects quality of serv= ice just not deterministic
> or overall positive ;)
>
> Best Regards
> Sebastian
> --
> Sent from my = Android device with K-9 Mail. Please excuse my brevity.
> _________= ______________________________________
> Cerowrt-devel mailing list=
> Cerowrt-devel@lists.bufferbloat.net
> https://lists.buff= erbloat.net/listinfo/cerowrt-devel
>

=0A
 ------=_20150731124734000000_81646--