[Olsr-users] Fwd: Question about hidden node behavior

[Markus Kittenberger]

first thanks for your long (and informative) mail,.. *G

it`s somehow a bit my fault, as probably there was no "urgent" reason for it

On Thu, Jan 13, 2011 at 7:26 PM, Nick Kossifidis <(spam-protected)>wrote:

> 2011/1/13 Markus Kittenberger <(spam-protected)>:
> >
>
> Haven't looked ath9k much, on ath5k


hmm this QoS thread was never really related to a "specific" driver,..

it was just a discussion about does QoS work on wireless interfaces without
defining/using qdisc that need static bandwidth

infact our starting QoS usecase was just if it works to priorize olsrd
packets with some tc rules,.. (without having to shape the interface to an
static (or periodically adjusted) bandwidth,..) (as imho if not doing so
this can reduce the stability of an olsrd mesh,..)

and while saverio "nearly" insisted that it`s not possible (or useless), i
insisted that it works fine,.. *g

cause e.g. old freifunkfriemware uses simple prio qdiscs to do so (together
with some tc filters) with legacy broadcom drivers,
and i defintely verified some years ago that this setup is definetely
effective (= it e.g. allows the top priorized traffic to get all available
bandwidth if it "needs" it)

as i already some knew that same methods don`t do well on atheros,.. (but
never found the time to dig deeper,..)
i did some tests on a atheros based device i had lying around (infact a
ubiquiti nanostation), and started to understand why saverio came to his
opinion *G
(as it`s really absolutely useless to do any layer 3 packet reordering (with
iprouet/tc) on this devices,..)

this was the point when I somehow started to "blame" internal queuing of (at
this point) unfortunately "undefined" wireless drivers of atheros
hardware,..
and i didn't mention that i was infact blaming madwifi, which is afaik still
the only real choice for atheros WISOC devices,..

and i think mitar asked you about your input regarding QoS and atheros
drivers,..
and so we came somehow to ath9k,... (and started to comment it`s source
code, (infact probably without a real reason to do so *G))

i hope this clearified how we got here *G


> we do ACK reporting + we stop
> queues on mac80211 until hw finishes + free the skbs (as ath9k does in
> your quote). As I told you I've rarely seen driver running out of tx
> buffers on some reports on highly congested environments with
> multi-bss setups etc, never on any of my tests, I believe we handle
> this correctly.


if i find time next week, i will definetly run my QoS test-scripts against
ath5k and ath9k aswell

and i`m quite optimistic that it will work,.. (and if not i`ll let u know
*G)

The only way for tx to fail on ath5k/ath9k is a) hw
> reports we didn't get an ACK -through the tx status descriptor- and
> the frame transmition failed, b) We didn't have enough buffers and ran
> out of memory so driver has to stop the queues until hw is done with
> current queued frames/buffers c) If frame was a beacon and we couldn't
> transmit it on time we reset the card.
>

i guess this means dropping all currently queued packets?

>
> Anyway dropping is normal, both layer 2 and layer 3 are by design
> best-effort, packet loss is part of the game, upper layers such as TCP
> etc will handle lost packets so there is no problem with dropping
> them. QoS in 802.11 and general has to do with the
> probability/priority of a frame/packet to go out compared to normal
> traffic. On 802.11e this is related to channel access and frame sizes
> etc (contention window), that means that a frame that goes eg. on the
> "voip" queue will be processed faster by the hardware (will "override"
> frames with lower priority on chip's scheduler) so any frame with
> lower priority will have more chances of being dropped (because it'll
> belong in a queue that is "emptied" more slowly and has more chances
> of getting filled up). We don't violate QoS by dropping frames since
> our drop probability goes together with transmition probability. Also
> we have tested layer 2 QoS with multiple hw queues and it works as
> expected, on city-wide setups + on testbeds with high
> traffic/bandwidth utilization scenarios.
>
> Iproute2/tc etc are higher layer tools, they operate at the IP layer
> and have nothing to do with how we handle frames on layer 2, there are
> some schedulers that "know" about hw queues but even if they don't
> mac80211 puts packets on the needed queues automatically

hmm this depends on what layer3 was doing,..
if he tried to priorize packets (e.g. with reordering) of lower DSCP classes
aginst higher ones (,without mangling their ip header), he stands alone *G

ofcourse this is nothing to be surprised of, but ethernet or wifi drivers
having only one (small) fifo queue, would work fine with this,.. *G

, eg. based on
> DSCP, it doesn't matter anyway, even if we only had one queue layer 3
> QoS would still work. L3 QoS does reordering, fragmentation stuff,
> packet dropping/queuing and various other techniques.
>

hmm as i put before layer 3 reordering might get useless fast, if layer 2 is
reordering aswell,..
or (differently) classifying traffic into queues with different drop
probability,..

regards Markus

>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.olsr.org/pipermail/olsr-users/attachments/20110113/47b78100/attachment.html>