From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp65.iad3a.emailsrvr.com (smtp65.iad3a.emailsrvr.com [173.203.187.65]) (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 69F1E21FC12 for ; Sat, 8 Aug 2015 13:46:07 -0700 (PDT) Received: from smtp17.relay.iad3a.emailsrvr.com (localhost.localdomain [127.0.0.1]) by smtp17.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id EB57A18017F; Sat, 8 Aug 2015 16:46:05 -0400 (EDT) Received: from app35.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by smtp17.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id C941A18017C; Sat, 8 Aug 2015 16:46:05 -0400 (EDT) X-Sender-Id: dpreed@reed.com Received: from app35.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by 0.0.0.0:25 (trex/5.4.2); Sat, 08 Aug 2015 20:46:05 GMT Received: from reed.com (localhost.localdomain [127.0.0.1]) by app35.wa-webapps.iad3a (Postfix) with ESMTP id B3DCB18224B; Sat, 8 Aug 2015 16:46:05 -0400 (EDT) Received: by apps.rackspace.com (Authenticated sender: dpreed@reed.com, from: dpreed@reed.com) with HTTP; Sat, 8 Aug 2015 16:46:05 -0400 (EDT) Date: Sat, 8 Aug 2015 16:46:05 -0400 (EDT) From: dpreed@reed.com To: "David Lang" MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_20150808164605000000_41966" Importance: Normal X-Priority: 3 (Normal) X-Type: html In-Reply-To: References: <356F5FEE-9FBD-4FF9-AC17-86A642D918A4@gmail.com> <5CC1DC90-DFAF-4A4D-8204-16CD4E20D6E3@gmx.de> <4D24A497-5784-493D-B409-F704804326A7@gmx.de> <1438361254.45977158@apps.rackspace.com> <6E08E48D-5D53-48E5-B088-2D1DB5E566AD@gmail.com> <1438983998.16576420@apps.rackspace.com> X-Auth-ID: dpreed@reed.com Message-ID: <1439066765.7348311@apps.rackspace.com> X-Mailer: webmail/11.5.5-RC Cc: Jonathan Morton , cerowrt-devel@lists.bufferbloat.net, make-wifi-fast@lists.bufferbloat.net Subject: Re: [Cerowrt-devel] [Make-wifi-fast] [tsvwg] Comments on draft-szigeti-tsvwg-ieee-802-11e 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: Sat, 08 Aug 2015 20:46:36 -0000 ------=_20150808164605000000_41966 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =0ADavid - I find it interesting that you think I am an idiot. I design wa= veforms for radios, and am, among other things, a fully trained electrical = engineer with deep understanding of information theory, EM waves, propagati= on, etc. as well as an Amateur Radio builder focused on building experiment= al radio network systems in the 5 GHz and 10 GHz Amateur Radio bands.=0A = =0AI know a heck of a lot about 802.11 PHY layer and modulation, propagatio= n, etc., and have been measuring the signals in my personal lab, as well as= having done so when I was teaching at MIT, working on cooperative network = diversity protocols (physical layers for mesh cooperation in digital networ= ks).=0A =0AAnd I was there with Metcalfe and Boggs when they designed Ether= net's PHY and MAC, and personally worked on the protocol layers in what bec= ame the Token Ring standard as well - so I understand the backoff and other= issues associated with LANs. (I wrote an invited paper in IEEE Proceeding= s "An Introduction to Local Area Networks" that appeared in the same specia= l issue as the Cerf and Kahn paper entitled "A Transmission Control Protoco= l" that described the first Internet protocol concept..)=0A =0AI guess what= I'm saying is not that I'm always correct - no one is, but I would suggest= that it's worth considering that I might know a little more than most peop= le about some things - especially the physical and MAC layers of 802.11, bu= t also about the internal electronic design of radio transceivers and digit= al interfaces to them. From some of your comments below, I think you either= misunderstood my point (my fault for not explaining it better) or are misi= nformed.=0A=0AThere's a lot of "folklore" out there about radio systems and= WiFi that is quite wrong, and you seem to be quoting some of it - e.g. the= idea that the 1 Mb/s waveform of 802.11b DSSS is somehow more reliable tha= n the lowest-rate OFDM modulations, which is often false. The 20 MHz-wide = M0 modulation with 800ns GI gives 6.2 Mb/s and typically much more reliable= than than the 802.11b standard 1 Mb/sec DSSS signals in normal environment= s, with typical receiver designs. It's not the case that beacon frames are = transmitted at 1 Mb/sec. - that is only true when there are 802.11b station= s *associated* with the access point (which cannot happen at 5 GHz). Nor is= it true that the preamble for ERP frames is wastefully long. The preamble = for an ERP (OFDM operation) frame is about 6 microseconds long, except in t= he odd case on 2.4GHz of compatibility-mode (OFDM-DSSS) operation, where th= e DSSS preamble is used. The DSSS preamble is 72 usec. long, because 72 b= its at 1 Mb/sec takes that long, but the ERP frame's preamble is much short= er.=0A =0AIn any case, my main points were about the fact that "channel est= imation" is the key issue in deciding on a modulation to use (and MIMO sett= ings to use), and the problem with that is that channels change characteris= tics quite quickly indoors! A spinning fan blade can create significant var= iation in the impulse response over a period of a couple milliseconds. To = do well on channel estimation to pick a high data rate, you need to avoid a= backlog in the collection of outbound packets on all stations - which mean= s minimizing queue buildup (even if that means sending shorter packets, get= ting a higher data rate will minimize channel occupancy).=0A =0ALong frames= make congested networks work badly - ideally there would only be one frame= ready to go when the current frame is transmitted, but the longer the fram= e, the more likely more than one station will be ready, and the longer the = frames will be (if they are being combined). That means that the penalty d= ue to, and frequency of, collisions where more than one frame are being sen= t at the same time grows, wasting airtime with collisions. That's why CTS/= RTS is often a good approach (the CTS/RTS frames are short, so a collision = will be less wasteful of airtime). But due to preamble size, etc., CTS/RTS= can't be very short, so an alternative hybrid approach is useful (assume t= hat all stations transmit CTS frames at the same time, you can use the sync= hronization acquired during the CTS to mitigate the need for a preamble on = the packet sent after the RTS). (One of the papers I did with my student = Aggelos Bletsas on Cooperative Diversity uses CTS/RTS in this clever way - = to measure the channel while acquiring it).=0A =0A =0A =0A=0AOn Friday, Aug= ust 7, 2015 6:31pm, "David Lang" said:=0A=0A=0A=0A> On Fri,= 7 Aug 2015, dpreed@reed.com wrote:=0A> =0A> > On Friday, August 7, 2015 4:= 03pm, "David Lang" said:=0A> >>=0A> >=0A> >> Wifi is the on= ly place I know of where the transmit bit rate is going to=0A> vary=0A> >> = depending on the next hop address.=0A> >=0A> >=0A> > This is an interesting= core issue. The question is whether additional=0A> > queueing helps or hur= ts this, and whether the MAC protocol of WiFi deals well=0A> > or poorly wi= th this issue. It is clear that this is a peculiarly WiFi'ish=0A> > issue.= =0A> >=0A> > It's not clear that the best transmit rate remains stable for = very long, or=0A> > even how to predict the "best rate" for the next statio= n since the next=0A> > station is one you may not have transmitted to for a= long time, so your "best=0A> > rate" information is old.=0A> =0A> I wasn't= even talking about the stability of the data rate to one destination. I=0A= > was talking about the fact that you may have a 1.3Gb connection to system= A (a=0A> desktop with a -ac 3x3 radio) and a 1Mb connection to machine B (= an IoT 802.11b=0A> thermostat)=0A> =0A> trying to do BQL across 3+ orders o= f magnatude in speed isn't going to work=0A> wihtout taking the speed into = account.=0A> =0A> Even if all you do is estimate with the last known speed,= you will do better=0A> than ignorming the speed entirely.=0A> =0A> If the = wifi can 'return' data to the queue when the transmission fails, it can=0A>= then fetch less data when it 're-transmits' the data at a lower speed.=0A>= =0A> > Queueing makes information about the channel older,=0A> > by bindin= g it too early. Sending longer frames means retransmitting longer=0A> > fra= mes when they don't get through, rather than agilely picking a better rate= =0A> > after a few bits.=0A> =0A> As I understand wifi, once a transmission= starts, it must continue at that same=0A> data rate, it can't change mid-t= ransmission (and tehre would be no way of=0A> getting feedback in the middl= e of a transmission to know that it would need to=0A> change)=0A> =0A> > Th= e MAC protocol really should give the receiver some opportunity to control= =0A> > the rate of the next packet it gets (which it can do because it can = measure=0A> > the channel from the transmitter to itself, by listening to p= rior=0A> > transmissions). Or at least to signal channel changes that might= require a=0A> > new signalling rate.=0A> >=0A> > This suggests that a tran= smitter might want to "warn" a receiver that some=0A> > packets will be com= ing its way, so the receiver can preemptively change the=0A> > desired rate= . Thus, perhaps an RTS-CTS like mechanism can be embedded in the=0A> > MAC = protocol, which requires that the device "look ahead" at the packets it=0A>= > might be sending.=0A> =0A> the recipient will receive a signal at any da= ta rate, you don't have to tell it=0A> ahead of time what rate is going to = be sent. If it's being sent with a known=0A> encoding, it will be decoded.= =0A> =0A> The sender picks the rate based on a number of things=0A> =0A> 1.= what the other end said they could do based on the mode that they are=0A> = connected with (b vs g vs n vs bonded n vs ac vs 2x2 ac etc)=0A> =0A> 2. wh= at has worked in the past. (with failed transmissions resulting in dropping= =0A> the rate)=0A> =0A> there may be other data like last known signal stre= ngth in the mix as well.=0A> =0A> =0A> > On the other hand, that only works= if the transmitter deliberately congests=0A> > itself so that it has a que= ue built up to look at.=0A> =0A> no, the table of associated devices keeps = track of things like the last known=0A> signal strength, connection mode, e= tc. no congestion needed.=0A> =0A> > The tradeoffs are not obvious here at = all. On the other hand, one could do=0A> > something much simpler - just ha= ve the transmitter slow down to the=0A> worst-case=0A> > rate required by a= ny receiving system.=0A> =0A> that's 1Mb/sec. This is the rate used for thi= ngs like SSID broadcasts.=0A> =0A> Once a system connects, you know from th= e connection handshake what speeds could=0A> work. no need to limit yoursel= f the the minimum that they all can know at that=0A> point.=0A> =0A> > As t= he number of stations in range gets larger, though, it seems unlikely=0A> t= hat=0A> > "batching" multiple packets to the same destination is a good ide= a at all -=0A> > because to achieve that, one must have n_destinations * ba= tch_size chunks of=0A> > data queued in the system as a whole, and that get= s quite large. I suspect=0A> it=0A> > would be better to find a lower level= way to just keep the packets going out=0A> > as fast as they arrive, so no= clog occurs, and to slow down the stuff at the=0A> > source as quickly as = possible.=0A> =0A> no, no, no=0A> =0A> you are falling into the hardware de= signer trap that we just talked about :-)=0A> =0A> you don't wait for the b= uffers to fill and always send full buffers, you=0A> oppertunisticaly send = data up to the max size.=0A> =0A> you do want to send multiple packets if y= ou have them waiting. Because if you=0A> can send 10 packets to machine A a= nd 10 packets to machine B in the time that it=0A> would take to send one p= acket to A, one packet to B, a second packet to A and a=0A> second packet t= o B, you have a substantial win for both A and B at the cost of=0A> very li= ttle latency for either.=0A> =0A> If there is so little traffic that sendin= g the packets out one at a time doesn't=0A> generate any congeston, then go= od, do that [1]. but when you max out the=0A> airtime, getting more data th= rough in the same amount of airtime by sending=0A> larger batches is a win= =0A> =0A> [1] if you are trying to share the same channel with others, this= may be a=0A> problem as it uses more airtime to send the same amount of da= ta than always=0A> batching. But this is a case of less than optimal networ= k design ;-)=0A> =0A> > [one should also dive into the reason for maintaini= ng variable rates -=0A> > multipath to a particular destination may require= longer symbols for decoding=0A> > without ISI. And when multipath is invol= ved, you may have to retransmit at a=0A> > slower rate. There's usually not= much "noise" at the receiver compared to the=0A> > multipath environment. = (one of the reasons why mesh can be a lot better is=0A> > that shorter dist= ances have much less multipath effect, so you can get higher=0A> > symbol r= ates by going multi-hop, and of course higher symbol rates compensate=0A> >= for more airtime occupied by a packet due to repeating).]=0A> =0A> distanc= e, interference, noise, etc are all variable in wifi. As a result, you=0A> = need to adapt.=0A> =0A> The problem is that the adaptation is sometimes doi= ng the wrong thing.=0A> =0A> simlifying things a bit:=0A> =0A> If your data= doesn't get through at rate A, is the right thing to drop to rate=0A> A/2 = and re-transmit?=0A> =0A> If the reason it didn't go through is that the si= gnal is too weak for the rateA=0A> encoding, then yes.=0A> =0A> If the reas= on it didn't go through is that your transmission was stepped on by=0A> som= ething you can't hear (and can't hear you), but the recipient can here, the= n=0A> slowing down means that you take twice the airtime to get the message= through,=0A> and you now have twice the chance of being stepped on again. = Repeat and you=0A> quickly get to everyone broadcasting at low rates and no= thing getting through.=0A> =0A> =0A> This is the key reason that dense wifi= networks 'fall off the cliff' when they=0A> hit saturation, the backoff th= at is entirely correct for a weak-signal, low=0A> usage situations is entir= ely wrong in dense environments.=0A> =0A> David Lang=0A> ------=_20150808164605000000_41966 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Davi= d - I find it interesting that you think I am an idiot.  I design wave= forms for radios, and am, among other things, a fully trained electrical en= gineer with deep understanding of information theory, EM waves, propagation= , etc. as well as an Amateur Radio builder focused on building experimental= radio network systems in the 5 GHz and 10 GHz Amateur Radio bands.

=0A<= p style=3D"margin:0;padding:0;font-family: 'times new roman'; font-size: 10= pt; word-wrap: break-word;"> 

=0A

I kno= w a heck of a lot about 802.11 PHY layer and modulation, propagation, etc.,= and have been measuring the signals in my personal lab, as well as having = done so when I was teaching at MIT, working on cooperative network diversit= y protocols (physical layers for mesh cooperation in digital networks).

= =0A

 

=0A

A= nd I was there with Metcalfe and Boggs when they designed Ethernet's PHY an= d MAC, and personally worked on the protocol layers in what became the Toke= n Ring standard as well - so I understand the backoff and other issues= associated with LANs.  (I wrote an invited paper in IEEE Proceed= ings "An Introduction to Local Area Networks" that appeared in the same spe= cial issue as the Cerf and Kahn paper entitled "A Transmission Control Prot= ocol" that described the first Internet protocol concept..)

=0A

 

=0A

I guess what= I'm saying is not that I'm always correct - no one is, but I would suggest= that it's worth considering that I might know a little more than most peop= le about some things - especially the physical and MAC layers of 802.1= 1, but also about the internal electronic design of radio transceivers and = digital interfaces to them. From some of your comments below, I think you e= ither misunderstood my point (my fault for not explaining it better) or are= misinformed.

=0A=0A


There's a lot of "folklore" = out there about radio systems and WiFi that is quite wrong, and you seem to= be quoting some of it - e.g. the idea that the 1 Mb/s waveform of 802.11b = DSSS is somehow more reliable than the lowest-rate OFDM modulations, w= hich is often false.  The 20 MHz-wide M0 modulation with 800ns GI give= s 6.2 Mb/s and typically much more reliable than than the 802.11b standard&= nbsp;1 Mb/sec DSSS signals in normal environments, with typical receiv= er designs. It's not the case that beacon frames are transmitted at 1 Mb/se= c. - that is only true when there are 802.11b stations *associated* with th= e access point (which cannot happen at 5 GHz). Nor is it true that the prea= mble for ERP frames is wastefully long. The preamble for an ERP (OFDM opera= tion) frame is about 6 microseconds long, except in the odd case on 2.4GHz = of compatibility-mode (OFDM-DSSS) operation, where the DSSS preamble is use= d.   The DSSS preamble is 72 usec. long, because 72 bits at 1 Mb/sec t= akes that long, but the ERP frame's preamble is much shorter.

=0A

 

=0A

In any case= , my main points were about the fact that "channel estimation" is the key i= ssue in deciding on a modulation to use (and MIMO settings to use), an= d the problem with that is that channels change characteristics quite quick= ly indoors! A spinning fan blade can create significant variation in the im= pulse response over a period of a couple milliseconds.  To do well on = channel estimation to pick a high data rate, you need to avoid a backlog in= the collection of outbound packets on all stations - which means minimizin= g queue buildup (even if that means sending shorter packets, getting a high= er data rate will minimize channel occupancy).

=0A

 

=0A

Long frames make congested= networks work badly - ideally there would only be one frame ready to go wh= en the current frame is transmitted, but the longer the frame, the more lik= ely more than one station will be ready, and the longer the frames will be = (if they are being combined).  That means that the penalty due to, and= frequency of, collisions where more than one frame are being sent at the s= ame time grows, wasting airtime with collisions.  That's why CTS/RTS i= s often a good approach (the CTS/RTS frames are short, so a collision will = be less wasteful of airtime).  But due to preamble size, etc., CTS/RTS= can't be very short, so an alternative hybrid approach is useful (assume t= hat all stations transmit CTS frames at the same time, you can use the sync= hronization acquired during the CTS to mitigate the need for a preamble on = the packet sent after the RTS).   (One of the papers I did with my stu= dent Aggelos Bletsas on Cooperative Diversity uses CTS/RTS in this clever w= ay - to measure the channel while acquiring it).

=0A

 

=0A

 

=0A

 

=0A


On Friday= , August 7, 2015 6:31pm, "David Lang" <david@lang.hm> said:

=0A
=0A

&= gt; On Fri, 7 Aug 2015, dpreed@reed.com wrote:
>
> > On= Friday, August 7, 2015 4:03pm, "David Lang" <david@lang.hm> said:> >>
> >
> >> Wifi is the only place I= know of where the transmit bit rate is going to
> vary
> &= gt;> depending on the next hop address.
> >
> >> > This is an interesting core issue. The question is whether add= itional
> > queueing helps or hurts this, and whether the MAC pr= otocol of WiFi deals well
> > or poorly with this issue. It is c= lear that this is a peculiarly WiFi'ish
> > issue.
> >= ;
> > It's not clear that the best transmit rate remains stable = for very long, or
> > even how to predict the "best rate" for th= e next station since the next
> > station is one you may not hav= e transmitted to for a long time, so your "best
> > rate" inform= ation is old.
>
> I wasn't even talking about the stabilit= y of the data rate to one destination. I
> was talking about the fa= ct that you may have a 1.3Gb connection to system A (a
> desktop wi= th a -ac 3x3 radio) and a 1Mb connection to machine B (an IoT 802.11b
= > thermostat)
>
> trying to do BQL across 3+ orders of = magnatude in speed isn't going to work
> wihtout taking the speed i= nto account.
>
> Even if all you do is estimate with the l= ast known speed, you will do better
> than ignorming the speed enti= rely.
>
> If the wifi can 'return' data to the queue when = the transmission fails, it can
> then fetch less data when it 're-t= ransmits' the data at a lower speed.
>
> > Queueing mak= es information about the channel older,
> > by binding it too ea= rly. Sending longer frames means retransmitting longer
> > frame= s when they don't get through, rather than agilely picking a better rate> > after a few bits.
>
> As I understand wifi, o= nce a transmission starts, it must continue at that same
> data rat= e, it can't change mid-transmission (and tehre would be no way of
>= getting feedback in the middle of a transmission to know that it would nee= d to
> change)
>
> > The MAC protocol really sh= ould give the receiver some opportunity to control
> > the rate = of the next packet it gets (which it can do because it can measure
>= ; > the channel from the transmitter to itself, by listening to prior> > transmissions). Or at least to signal channel changes that mig= ht require a
> > new signalling rate.
> >
> &= gt; This suggests that a transmitter might want to "warn" a receiver that s= ome
> > packets will be coming its way, so the receiver can pree= mptively change the
> > desired rate. Thus, perhaps an RTS-CTS l= ike mechanism can be embedded in the
> > MAC protocol, which req= uires that the device "look ahead" at the packets it
> > might b= e sending.
>
> the recipient will receive a signal at any = data rate, you don't have to tell it
> ahead of time what rate is g= oing to be sent. If it's being sent with a known
> encoding, it wil= l be decoded.
>
> The sender picks the rate based on a num= ber of things
>
> 1. what the other end said they could do= based on the mode that they are
> connected with (b vs g vs n vs b= onded n vs ac vs 2x2 ac etc)
>
> 2. what has worked in the= past. (with failed transmissions resulting in dropping
> the rate)=
>
> there may be other data like last known signal streng= th in the mix as well.
>
>
> > On the other ha= nd, that only works if the transmitter deliberately congests
> >= itself so that it has a queue built up to look at.
>
> no= , the table of associated devices keeps track of things like the last known=
> signal strength, connection mode, etc. no congestion needed.
>
> > The tradeoffs are not obvious here at all. On the ot= her hand, one could do
> > something much simpler - just have th= e transmitter slow down to the
> worst-case
> > rate req= uired by any receiving system.
>
> that's 1Mb/sec. This is= the rate used for things like SSID broadcasts.
>
> Once a= system connects, you know from the connection handshake what speeds could<= br />> work. no need to limit yourself the the minimum that they all can= know at that
> point.
>
> > As the number of s= tations in range gets larger, though, it seems unlikely
> that
> > "batching" multiple packets to the same destination is a good id= ea at all -
> > because to achieve that, one must have n_destina= tions * batch_size chunks of
> > data queued in the system as a = whole, and that gets quite large. I suspect
> it
> > wou= ld be better to find a lower level way to just keep the packets going out> > as fast as they arrive, so no clog occurs, and to slow down t= he stuff at the
> > source as quickly as possible.
> > no, no, no
>
> you are falling into the hardware d= esigner trap that we just talked about :-)
>
> you don't w= ait for the buffers to fill and always send full buffers, you
> opp= ertunisticaly send data up to the max size.
>
> you do wan= t to send multiple packets if you have them waiting. Because if you
&g= t; can send 10 packets to machine A and 10 packets to machine B in the time= that it
> would take to send one packet to A, one packet to B, a s= econd packet to A and a
> second packet to B, you have a substantia= l win for both A and B at the cost of
> very little latency for eit= her.
>
> If there is so little traffic that sending the pa= ckets out one at a time doesn't
> generate any congeston, then good= , do that [1]. but when you max out the
> airtime, getting more dat= a through in the same amount of airtime by sending
> larger batches= is a win
>
> [1] if you are trying to share the same chan= nel with others, this may be a
> problem as it uses more airtime to= send the same amount of data than always
> batching. But this is a= case of less than optimal network design ;-)
>
> > [on= e should also dive into the reason for maintaining variable rates -
&g= t; > multipath to a particular destination may require longer symbols fo= r decoding
> > without ISI. And when multipath is involved, you = may have to retransmit at a
> > slower rate. There's usually not= much "noise" at the receiver compared to the
> > multipath envi= ronment. (one of the reasons why mesh can be a lot better is
> >= that shorter distances have much less multipath effect, so you can get hig= her
> > symbol rates by going multi-hop, and of course higher sy= mbol rates compensate
> > for more airtime occupied by a packet = due to repeating).]
>
> distance, interference, noise, etc= are all variable in wifi. As a result, you
> need to adapt.
&= gt;
> The problem is that the adaptation is sometimes doing the wr= ong thing.
>
> simlifying things a bit:
>
&g= t; If your data doesn't get through at rate A, is the right thing to drop t= o rate
> A/2 and re-transmit?
>
> If the reason it= didn't go through is that the signal is too weak for the rateA
> e= ncoding, then yes.
>
> If the reason it didn't go through = is that your transmission was stepped on by
> something you can't h= ear (and can't hear you), but the recipient can here, then
> slowin= g down means that you take twice the airtime to get the message through,> and you now have twice the chance of being stepped on again. Repeat= and you
> quickly get to everyone broadcasting at low rates and no= thing getting through.
>
>
> This is the key reas= on that dense wifi networks 'fall off the cliff' when they
> hit sa= turation, the backoff that is entirely correct for a weak-signal, low
= > usage situations is entirely wrong in dense environments.
> > David Lang
>

=0A
 ------=_20150808164605000000_41966--