[Cerowrt-devel] [Make-wifi-fast] [tsvwg] Comments on draft-szigeti-tsvwg-ieee-802-11e

[David Lang]

I'll reply more later. I don't think you are an idiot, I think you are too 
caught up in the no-olds-barred world of your ham tinkering to take into account 
the realities of the existing wifi reality.

for make-wifi-fast we don't get to start from scratch, there is a huge installed 
base that we can't change and have to interact with. Like the bufferbloat 
effort, we cn find better ways of doing things and try to get them ot there, but 
they have to work seamlessly with the existing equipment and protocols.

also, I tend to give a lot of background to justify my conclusions, not because 
I assume yuo dont know any of it, but for the two reasons that if I have a logic 
flaw or am basing my results on faulty info I can be corrected, and so that 
others in or watching the discussion who don't know these details can be brought 
up to speed and contribute.

David Lang


  On Sat, 8 Aug 2015, dpreed at reed.com wrote:

> Date: Sat, 8 Aug 2015 16:46:05 -0400 (EDT)
> From: dpreed at reed.com
> To: David Lang <david at lang.hm>
> Cc: Jonathan Morton <chromatix99 at gmail.com>,
>     cerowrt-devel at lists.bufferbloat.net, make-wifi-fast at lists.bufferbloat.net
> Subject: Re: [Cerowrt-devel] [Make-wifi-fast] [tsvwg] Comments on
>     draft-szigeti-tsvwg-ieee-802-11e
> 
>
> David - I find it interesting that you think I am an idiot.  I design waveforms for radios, and am, among other things, a fully trained electrical engineer 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.
> 
> I know 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 diversity protocols (physical layers for mesh cooperation in digital networks).
> 
> And I was there with Metcalfe and Boggs when they designed Ethernet's PHY and MAC, and personally worked on the protocol layers in what became the Token Ring standard as well - so I understand the backoff and other issues associated with LANs.  (I wrote an invited paper in IEEE Proceedings "An Introduction to Local Area Networks" that appeared in the same special issue as the Cerf and Kahn paper entitled "A Transmission Control Protocol" that described the first Internet protocol concept..)
> 
> 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 people about some things - especially the physical and MAC layers of 802.11, but also about the internal electronic design of radio transceivers and digital 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 misinformed.
>
> 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, 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 environments, 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 stations *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 the odd case on 2.4GHz of compatibility-mode (OFDM-DSSS) operation, where the DSSS preamble is used.   The DSSS preamble is 72 usec. long, because 72 bits at 1 Mb/sec takes that!
  long, but the ERP frame's preamble is much shorter.
> 
> In any case, my main points were about the fact that "channel estimation" is the key issue in deciding on a modulation to use (and MIMO settings to use), and the problem with that is that channels change characteristics quite quickly indoors! A spinning fan blade can create significant variation 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 means minimizing queue buildup (even if that means sending shorter packets, getting a higher data rate will minimize channel occupancy).
> 
> Long 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 frame, 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 due to, and frequency of, collisions where more than one frame are being sent 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 that all stations transmit CTS frames at the same time, you can use the synchronization 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 - t!
 o measure the channel while acquiring it).
> 
> 
> 
>
> On Friday, August 7, 2015 6:31pm, "David Lang" <david at lang.hm> said:
>
>
>
>> On Fri, 7 Aug 2015, dpreed at reed.com wrote:
>> 
>> > On Friday, August 7, 2015 4:03pm, "David Lang" <david at lang.hm> said:
>> >>
>> >
>> >> Wifi is the only place I know of where the transmit bit rate is going to
>> vary
>> >> depending on the next hop address.
>> >
>> >
>> > This is an interesting core issue. The question is whether additional
>> > queueing helps or hurts this, and whether the MAC protocol of WiFi deals well
>> > or poorly with this issue. It is clear 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 the next station since the next
>> > station is one you may not have transmitted to for a long time, so your "best
>> > rate" information is old.
>> 
>> I wasn't even talking about the stability of the data rate to one destination. I
>> was talking about the fact that you may have a 1.3Gb connection to system A (a
>> desktop with 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 into account.
>> 
>> Even if all you do is estimate with the last known speed, you will do better
>> than ignorming the speed entirely.
>> 
>> If the wifi can 'return' data to the queue when the transmission fails, it can
>> then fetch less data when it 're-transmits' the data at a lower speed.
>> 
>> > Queueing makes information about the channel older,
>> > by binding it too early. Sending longer frames means retransmitting longer
>> > frames when they don't get through, rather than agilely picking a better rate
>> > after a few bits.
>> 
>> As I understand wifi, once a transmission starts, it must continue at that same
>> data rate, 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 need to
>> change)
>> 
>> > The MAC protocol really should 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 might require a
>> > new signalling rate.
>> >
>> > This suggests that a transmitter might want to "warn" a receiver that some
>> > packets will be coming its way, so the receiver can preemptively change the
>> > desired rate. Thus, perhaps an RTS-CTS like mechanism can be embedded in the
>> > MAC protocol, which requires that the device "look ahead" at the packets it
>> > might be sending.
>> 
>> the recipient will receive a signal at any data rate, you don't have to tell it
>> ahead of time what rate is going to be sent. If it's being sent with a known
>> encoding, it will be decoded.
>> 
>> The sender picks the rate based on a number 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 bonded 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 strength in the mix as well.
>> 
>> 
>> > On the other hand, 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 other hand, one could do
>> > something much simpler - just have the transmitter slow down to the
>> worst-case
>> > rate required 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
>> work. no need to limit yourself the the minimum that they all can know at that
>> point.
>> 
>> > As the number of stations in range gets larger, though, it seems unlikely
>> that
>> > "batching" multiple packets to the same destination is a good idea at all -
>> > because to achieve that, one must have n_destinations * batch_size chunks of
>> > data queued in the system as a whole, and that gets quite large. I suspect
>> it
>> > would 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 the stuff at the
>> > source as quickly as possible.
>> 
>> no, no, no
>> 
>> you are falling into the hardware designer trap that we just talked about :-)
>> 
>> you don't wait for the buffers to fill and always send full buffers, you
>> oppertunisticaly send data up to the max size.
>> 
>> you do want to send multiple packets if you have them waiting. Because if you
>> 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 second packet to A and a
>> second packet to B, you have a substantial win for both A and B at the cost of
>> very little latency for either.
>> 
>> If there is so little traffic that sending the packets out one at a time doesn't
>> generate any congeston, then good, do that [1]. but when you max out the
>> airtime, getting more data through in the same amount of airtime by sending
>> larger batches is a win
>> 
>> [1] if you are trying to share the same channel 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 ;-)
>> 
>> > [one should also dive into the reason for maintaining variable rates -
>> > multipath to a particular destination may require longer symbols for 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 environment. (one of the reasons why mesh can be a lot better is
>> > that shorter distances have much less multipath effect, so you can get higher
>> > symbol rates by going multi-hop, and of course higher symbol 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.
>> 
>> The problem is that the adaptation is sometimes doing the wrong thing.
>> 
>> simlifying things a bit:
>> 
>> If your data doesn't get through at rate A, is the right thing to drop to rate
>> A/2 and re-transmit?
>> 
>> If the reason it didn't go through is that the signal is too weak for the rateA
>> encoding, then yes.
>> 
>> If the reason it didn't go through is that your transmission was stepped on by
>> something you can't hear (and can't hear you), but the recipient can here, then
>> slowing 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 nothing getting through.
>> 
>> 
>> This is the key reason that dense wifi networks 'fall off the cliff' when they
>> hit saturation, the backoff that is entirely correct for a weak-signal, low
>> usage situations is entirely wrong in dense environments.
>> 
>> David Lang
>>