From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp131.iad.emailsrvr.com (smtp131.iad.emailsrvr.com [207.97.245.131]) (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 6811B21F1AA for ; Wed, 9 Jan 2013 06:58:27 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp53.relay.iad1a.emailsrvr.com (SMTP Server) with ESMTP id 2FB1E58621; Wed, 9 Jan 2013 09:58:26 -0500 (EST) X-Virus-Scanned: OK Received: from legacy5.wa-web.iad1a (legacy5.wa-web.iad1a.rsapps.net [192.168.2.221]) by smtp53.relay.iad1a.emailsrvr.com (SMTP Server) with ESMTP id 0190658876; Wed, 9 Jan 2013 09:58:25 -0500 (EST) Received: from reed.com (localhost [127.0.0.1]) by legacy5.wa-web.iad1a (Postfix) with ESMTP id DAAFF2E9802E; Wed, 9 Jan 2013 09:58:25 -0500 (EST) Received: by apps.rackspace.com (Authenticated sender: dpreed@reed.com, from: dpreed@reed.com) with HTTP; Wed, 9 Jan 2013 09:58:25 -0500 (EST) Date: Wed, 9 Jan 2013 09:58:25 -0500 (EST) From: dpreed@reed.com To: "Maciej Soltysiak" MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_20130109095825000000_97077" Importance: Normal X-Priority: 3 (Normal) X-Type: html In-Reply-To: References: Message-ID: <1357743505.8941746@apps.rackspace.com> X-Mailer: webmail7.0 Cc: cerowrt-devel@lists.bufferbloat.net Subject: Re: [Cerowrt-devel] slightly OT: WMM 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: Wed, 09 Jan 2013 14:58:28 -0000 ------=_20130109095825000000_97077 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =0A"Delays incurred by signal quality" needs some serious measurement work.= =0A =0AWhile it's clear that 802.11 is degraded in both throughput and late= ncy under signal quality variation, it's not at all clear what the effect l= ooks like, and what it looks like actually matters.=0A =0AThis depends a gr= eat deal on parameters that may be inaccessible or poorly set in the MAC la= yer of one or more nodes. The following factors related to propagation env= ironment are common in indoor environments:=0A =0A1) What is the algorithm = used to manage transmit power - in particular, how quickly does the automat= ic transmit power selectcut power or raise it? And when it does, does it c= hoose a different waveform or not?=0A =0A2) what else radiates energy on th= e channel (since the protocol listens before talking for a good approximati= on of "radio silence" for 4 microseconds or so before any packet can be sen= t)? This has a different but significant effect from, say, hidden terminal = problems. Hidden 802.11 terminals only transmit occasionally, thus they do= n't degrade in the same way as a background "hum".=0A =0A3) what kind of de= lays are caused by legacy 802.11g devices on 802.11n networks in 2.4 GHz? = They transmit slower, so occupy channel longer.=0A =0A4) What kind of delay= s are induced by accumulating frames into a single transmission, and where = in the OS are frames merged - device firmware, device driver, or common lay= er 2 code in the OS?=0A =0AEtc.=0A =0AThe first order question should be: = how significant are such delays, in comparison to those involving overbuffe= ring?=0A =0AThe second order question should be: can channel degradation af= fecting one pair of terminals cause starvation of another pair?=0A =0AIf th= ese are small effects, focusing on them before implementing bufferbloat fix= es and anti-starvation within one queue (fq in general does this), then I w= ould suggest that we not proceed by *changing everything at once* without d= ata that characterizes the problem vs. non-problem areas.=0A =0AThere's lot= s of research already out there to draw on that started "imagine that wirel= ess networks look like *this* (assumption X inserted here), what would be a= great solution?" and then say "my cool XYZ algorithm optimizes [all? reall= y, all of them?] wireless channels." So it's not as if there are not a z= illion PhD dissertations with approaches to pick from.=0A =0ABut what we ne= ed to know is what the heck is going on - not in an imaginary ns2 simulatio= n, but really in real, badly behaved but well-understood and otherwise prob= lem-free networks. (bufferbloat would hide such concerns really well, give= n multiple second queueing delays that arise under load.)=0A =0ASo, it does= n't matter what I *think* - it matters what the data tells us. And we have= very, very little data on propagation effects in 802.11. Almost none. Th= at's not what the market focuses on. The market measures highest speed in = *perfect* propagation conditions.=0A =0A =0A =0A =0A =0A =0A =0A-----Origin= al Message-----=0AFrom: "Maciej Soltysiak" =0ASent: W= ednesday, January 9, 2013 8:52am=0ATo: cerowrt-devel@lists.bufferbloat.net= =0ASubject: [Cerowrt-devel] slightly OT: WMM=0A=0A=0A=0AHi,=0A=0AAside from= reducing buffers and changing the queue management tactics, we're still in= terested in QoS and that's why we have tc filters, iptables MARKing, etc.= =0A=0AWith regard to WLAN, what do you think about enabling or disabling WM= M on WLAN NICs and ap/routers?=0A=0ASupposing that applications or other me= chanisms to proper DSCP or layer 2 tagging this should allow WMM to further= do the prioritization on layer 1, however I've read a WMM-enabled station = is like 4 stations competing for medium time. Is that analogy justified? Is= that good or bad in terms of delays incurred by signal quality?=0A=0ARegar= ds,=0AMaciej=0A ------=_20130109095825000000_97077 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

= "Delays incurred by signal quality" needs some serious measurement work.=0A

 

=0A

While it's clear that 802.11 is degraded in both throughput and lat= ency under signal quality variation, it's not at all clear what the effect = looks like, and what it looks like actually matters.

=0A

 

=0A

This depends= a great deal on parameters that may be inaccessible or poorly set in the M= AC layer of one or more nodes.  The following factors related to propa= gation environment are common in indoor environments:

=0A

 

=0A

1) What is = the algorithm used to manage transmit power - in particular, how quickly do= es the automatic transmit power selectcut power or raise it?  And when= it does, does it choose a different waveform or not?

=0A

 

=0A

2) what els= e radiates energy on the channel (since the protocol listens before talking= for a good approximation of "radio silence" for 4 microseconds or so befor= e any packet can be sent)? This has a different but significant effect from= , say, hidden terminal problems.  Hidden 802.11 terminals only transmi= t occasionally, thus they don't degrade in the same way as a background "hu= m".

=0A

 

=0A

3) what kind of delays are caused by legacy 802.11g devices o= n 802.11n networks in 2.4 GHz?  They transmit slower, so occupy channe= l longer.

=0A

 

=0A

4) What kind of delays are induced by accumulating fram= es into a single transmission, and where in the OS are frames merged - devi= ce firmware, device driver, or common layer 2 code in the OS?

=0A

 

=0A

Etc= .

=0A

 

=0A

The first order question should be:  how significant are s= uch delays, in comparison to those involving overbuffering?

=0A

 

=0A

The = second order question should be: can channel degradation affecting one pair= of terminals cause starvation of another pair?

=0A

 

=0A

If these are smal= l effects, focusing on them before implementing bufferbloat fixes and anti-= starvation within one queue (fq in general does this), then I would suggest= that we not proceed by *changing everything at once* without data that cha= racterizes the problem vs. non-problem areas.

=0A

 

=0A

There's lots of res= earch already out there to draw on that started "imagine that wireless netw= orks look like *this* (assumption X inserted here), what would be a great s= olution?" and then say "my cool XYZ algorithm optimizes [all? really, all o= f them?] wireless channels."    So it's not as if there are = not a zillion PhD dissertations with approaches to pick from.

=0A

 

=0A

But= what we need to know is what the heck is going on - not in an imaginary ns= 2 simulation, but really in real, badly behaved but well-understood and oth= erwise problem-free networks.  (bufferbloat would hide such concerns r= eally well, given multiple second queueing delays that arise under load.)=0A

 

=0A

So, it doesn't matter what I *think* - it matters what the data te= lls us.  And we have very, very little data on propagation effects in = 802.11.  Almost none.  That's not what the market focuses on.&nbs= p; The market measures highest speed in *perfect* propagation conditions.=0A

 

=0A

 

=0A

 

=0A

 

=0A

&nb= sp;

=0A

 

=0A

 

=0A

-----Original M= essage-----
From: "Maciej Soltysiak" <maciej@soltysiak.com>
Sent: Wednesday, January 9, 2013 8:52am
To: cerowrt-devel@lists.buffe= rbloat.net
Subject: [Cerowrt-devel] slightly OT: WMM

= =0A
=0A
Hi,
=0A
=0A
= Aside from reducing buffers and changing the queue management tactics, we'r= e still interested in QoS and that's why we have tc filters, iptables MARKi= ng, etc.
=0A
=0A
With regard to WLAN, what do you think = about enabling or disabling WMM on WLAN NICs and ap/routers?
=0A
<= /div>=0A
Supposing that applications or other mechanisms to proper DSCP= or layer 2 tagging this should allow WMM to further do the prioritization = on layer 1, however I've read a WMM-enabled station is like 4 stations comp= eting for medium time. Is that analogy justified? Is that good or bad in te= rms of delays incurred by signal quality?
=0A
=0A
Regard= s,
=0A
Maciej
=0A
=0A
 ------=_20130109095825000000_97077--