[Babel-users] QoS for system critical packets on wireless

[Dave Taht]

On Wed, Jun 22, 2011 at 4:12 PM, Juliusz Chroboczek <jch at pps.jussieu.fr> wrote:
> 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.

It was seeing even the minm

>
>> 1) 'ANTS' are < less than 1% of all packets. ANTS includes system control and
>> 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.

I have always needed some minimal level of QoS on all networks I
shared with other people, even prior to bufferbloat.

As for classification, with asymmetric networks, the canonical example
of some level needed is moving interactive packets up in priority over
uploads.

Once you admit there is some need for classication, you rapidly head
down an Aristotelian rathole. Believe me, I'm feeling that - a couple
hundred protocols, two mutually sort-of-similar classification schemes
in linux (tc, iptables)... the chain of functions a linux box has to
call to get a packet from point a to point b is 3 pages long,
even before you start trying to classify things.

Minimal, ad-hoc classification methods as they exist today are
insufficient to handle enough 'normal' cases to accomplish their
intent. Wedging everything into Ants, Mice, and Elephants seems a more
reasonable approach by the day, although I admit some fondness for
diffserv...

An example, also taken from the above - no common shaper script out
there accounts properly for ipv6 packets, and you can clobber upload
bandwidth easily without prioritization for interactive ipv6 packets,
too.

I struggle with the need for any level of classification, but I
reluctantly have given up, and begun to assume that it needs to be
done way better and more consistently in the general case.

As it is, here's a tidbit from last night... after poking into how
802.11e is supposed to work (mac80211 basically treats values in the
skb->priority field in the range 256 0..7 as a map from 802.1d) I went
looking into how 802.1p (vlan prioritization, based on d) worked in
Linux...

from linux-2.6/net/8021q/vlan.h

/**
 *      struct vlan_priority_tci_mapping - vlan egress priority mappings
 *      @priority: skb priority
 *      @vlan_qos: vlan priority: (skb->priority << 13) & 0xE000
 *      @next: pointer to next struct
 */


At which point I decided to go drinking.

(guess what else skb-priority is used for?)

I can't believe anybody is actually using this stuff, the details are
too deeply buried.

>> 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.

The problem is that all the packets in the queues ahead of babel can
be delayed with deep buffering and exorbitant retries.

(I am intensely curious as to the effect of 802.11e on n - if it was
modified to support transmitting in the short windows assigned to VI
and VO....)

>
>> 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.)

Heh. Pre-n, I imagine.

>
>> 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.)

I have. But I don't want to talk about this now, because then I'd want
to go drinking again. I do think in the long run that better tools and
unifying concepts need to show up that would make routing and
firewalling easier and more effective and performant than bridging and
ebtables...

but if I could toss the bridge code out of the cerowort effort right
now, I would. I  have got 3x the performance out of the wired side of
it by doing pure routing, without DoSing the wireless side, and I get
working multicast throughout, too...

All I need is a way of generating a unique local mac for the second
ethernet interface on first boot. I'm tempted to buy my own mac
address range - I'm that frustrated.

>
> -- Juliusz
>



-- 
Dave Täht
SKYPE: davetaht
US Tel: 1-239-829-5608
http://the-edge.blogspot.com