The only mandatory form of aggregation in 'n' is of the one-checksum type,
even though other types are permitted. The overhead at the data layer is
slightly less, and checksum failure handling on receive is simpler (just
throw the whole thing out and nak it), as is handling the nak at the
On Sun, 9 Aug 2015, Jonathan Morton wrote:
This is the difference between the typical 802.11n situation (one checksum
per aggregate) and the mandatory 802.11ac capability of a checksum per
packet. As long as you also employ RTS/CTS when appropriate, the
possibility of collisions is no longer a
There's a capability handshake during association, so there's no
compatibility problem. Clients supporting only the single checksum won't
understand multiple-checksum aggregates at all, but the transmitter will
know not to send that type to them.
- Jonathan Morton
On Fri, 14 Aug 2015, Jonathan Morton wrote:
The only mandatory form of aggregation in 'n' is of the one-checksum type,
even though other types are permitted. The overhead at the data layer is
slightly less, and checksum failure handling on receive is simpler (just
throw the whole thing out and
On 8/7/2015 3:31 PM, David Lang wrote:
On Fri, 7 Aug 2015, dpr...@reed.com wrote:
On Friday, August 7, 2015 4:03pm, David Lang da...@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
The question of whether to aggregate under congested conditions is
controversial, probably because it depends on complex conditions. There
are arguments both for and against.
It may be worth considering it as a risk/reward tradeoff. Given N packets
(which for brevity I'll assume are equal MTU
On Sat, 8 Aug 2015, dpr...@reed.com wrote:
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
On Sun, 9 Aug 2015, David Lang wrote:
Just like wired networks benefit greatly from time-based queues rather
than packet count based queues, I think that wifi aggregation should not
be based on packet count (or even aggregate size) but rather the amont
of airtime that's going to be used
Some level of hardware queueing is necessary to meet the response time.
It's further complicated by the need to include retries at the start of the
next aggregate, but you only learn which ones from the block-ACK received
after the last one. Given the hardware's need to have frame length well
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
] 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
On 7 Aug, 2015, at 15:22, Rich Brown richb.hano...@gmail.com wrote:
- At that time, the wifi driver requests packets from fq_codel until a) the
the fq_codel queues are empty, or b) the wifi frame is full. In either case,
the wifi driver sends what it has.
There’s one big flaw with this:
On Fri, 7 Aug 2015, Jonathan Morton wrote:
On 7 Aug, 2015, at 15:22, Rich Brown richb.hano...@gmail.com wrote:
- At that time, the wifi driver requests packets from fq_codel until a) the
the fq_codel queues are empty, or b) the wifi frame is full. In either case,
the wifi driver sends what
On Fri, 7 Aug 2015, dpr...@reed.com wrote:
On Friday, August 7, 2015 4:03pm, David Lang da...@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
On Fri, 31 Jul 2015, dpr...@reed.com wrote:
So ignore the 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 them convince you to queue things, especially lower priority
things instead push congestion
On Monday, August 3, 2015 8:13pm, David Lang da...@lang.hm said:
That requires central coordination of the stations. Something we don't have in
wifi. Wifi lives and dies with 'listen for a gap, try transmitting, and if you
collide, backoff a random period'
Central coordination is not the
Because at today's link rates, a full 1500 byte MTU packet is small.
- Jonathan Morton
___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel
On Mon, 3 Aug 2015, dpr...@reed.com wrote:
I design and build physical layer radio hardware (using SDR reception and
transmission in the 5 GHz and 10 GHz Amateur radio bands).
Fairness is easy in a MAC. 1 usec. is 1,000 linear feet. If the next station
knows when its turn is, it can start
Hardware people tend to think about queues way too much in general. Queues
should be almost never occupied. That causes the highest throughput possible.
And getting there is simple: push queueing back to the source.
The average queue length into a shared medium should be as close to zero
Jonathan Morton chromati...@gmail.com wrote:
I think that is achievable, *even if there is a WiFi network in the
middle*, by thinking about the fact that the shared airwaves in a WiFi
network behaves like a single link, so all the queues on individual
stations are really *one
Hi Jonathan,
On July 30, 2015 11:56:23 PM GMT+02:00, Jonathan Morton chromati...@gmail.com
wrote:
Hardware people tend to think in terms of simple priority queues, much
like
old fashioned military communications (see the original IP precedence
spec). Higher priority thus gets higher throughput
21 matches
Mail list logo
