[Babel-users] QoS for system critical packets on wireless
Juliusz Chroboczek
jch at pps.jussieu.fr
Wed Jun 22 18:12:13 EDT 2011
Dave,
My points below are tainted by the fact that I deeply dislike
classification -- I'm hoping for solutions in which there's no higher
layer knowledge in the routers.
> 1) System control and 'MICE' are < less than 1% of all packets. Mice
> includes a bunch of messages like ARP, NTP, UDP, and most of the icmp6
> portion of the stack, in what I'm doing currently.
Once you've fought the bloat, there's hopefully no further need to
classify these packets. On a working network, you should be able to
achieve less than 5% packet loss, even without ECN, and all protocols
should be able to support that level of loss.
> A) wireless devices are currently making heroic efforts (deep
> buffering, exorbitant retries) to get packets through. Seeing a big
> delay between transmit time and reception is more an indicator of
> congestion than actual packet loss is right now. By the time you see
> actual packet loss, the network has often already collapsed
> completely.
Not for multicast -- there's no link-layer ARQ for multicast in 802.11.
That's why RFC 6126 says that you MUST send hello TLVs over multicast
only.
> C) QoS, Packet marking and prioritization of any sort makes babel
> control packets jump closer to the head of the internal queues of the
> transmitting clients, thus speeding up routing change propagation.
Yes. However, Babel is designed to support loss rates up to 80% or so,
and therefore should normally only collapse when your network has
already collapsed.
(The reason for that? Julien used to have a couch in his office, where
the pre-ARQ loss rate to the closest Babel router was well above 50%.
We put a lot of effort into ensuring that Julien could read mail on his
couch.)
> I've also written elsewhere about the effect of multicast traffic on
> wireless and am trying hard to stop bridging gigE (1000Mbit) and
> Wireless (a,b,g,n) together wherever possible,
Hear, hear.
(Somebody please bring that up with the OpenWRT folks.)
-- Juliusz
More information about the Bloat-devel
mailing list