Re: [Bloat] sigcomm wifi

[Jonathan Morton <chromatix99@gmail.com>]

On 24 Aug, 2014, at 11:24 am, David Lang wrote:

> but it is a lot larger than simple packet size would indicate, because the encapsulation per transmission is a fixed size (and no, I don't know how large it is)

I found a reference to the preamble/header format of 802.11a/g.  Under ideal conditions with default settings, the preamble+header of the PPDU is transmitted at 6Mbps and takes about 50µs; the PSDU adds a further 18µs overhead; a 4500-byte payload would then take 667µs to transmit at 54Mbps.  (Except that 'g' doesn't support a payload that big.)

So even with a fairly large aggregated payload, and ignoring RTS/CTS, the overhead is several percent.  A 64-byte packet takes only 10µs to send at that speed, so that 68µs overhead looks really nasty even at lower speeds.  And even that assumes that there aren't any 'b' devices associated, which would cause the whole network to fall back to 96µs 'b' preambles.

That document doesn't even mention RTS/CTS/ACK.  I found another diagram which points out that each of these takes 30µs to send, including 10µs periods of silence.  So that's 90+68+10 = 168µs to send a 64-byte packet, and 90+68+222 = 380µs to send a 1500-byte packet - only twice as long.

http://ict.siit.tu.ac.th/~sgordon/its413y12s2/unprotected/ITS413Y12S2H22-DCF-RTS-Three-Stations-Hidden.png

The practical upshot - for 802.11a/g, a TCP ack costs roughly half as much channel time as a full data packet.  An ack every three packets, with no aggregation on the data packets, would consume one-seventh (14%) of the channel time.  It's not as high as my previous estimate, but it's still significant - and it backs up my hunch that simply negotiating for the channel is a big enough overhead to talk about separately.

 - Jonathan Morton