[Babel-users] [PATCH 2/3] Add ECN support to babel messages

Thu Sep 27 18:11:17 BST 2018

On Thu, Sep 27, 2018 at 9:51 AM David Schinazi <dschinazi at apple.com> wrote:
>
> Hi Dave,
>
> If I'm understanding you correctly, you want Babel to say it's an
> ECN-capable transport to have it land in a shorter fq_codel queue.

No. It lands in a queue (potentially with other flows), where, if it
is overloaded, marks the packet on a tcp--friendly schedule, rather
than drops it. That queue tends to get longer, not shorter.

(this is sort of why I'd like more people to get actual experience
with fq_codel/pie and ecn'd behaviors in general so we all have a
better starting point - fiddle with unresponsive senders with irtt,
load up links with tons of ecn-enabled tcps with flent, futz with
routing protocols, observe what changes in typical voip or webrtc
traffic, etc)

Lot of apple traffic with ecn on now...

> I'm not familiar with what configuration knobs fq_codel offers, but
> couldn't you instead configure fq_codel to filter based on DiffServ
> when deciding which queue a packet goes in?

There are 4 fq_codeled instances now in linux wifi. And mcast. There's
a lot of work landing to make it better on ath10k and ath9k, and soon
iwl...

Since 802.11n aggregation and airtime fairness tend to work so much
better than 802.11e, on APs I typically don't use those. Clients can.

Apple unleashed ecn globally last year... I see 4 fq_codel instances
enabled on my OSX box[1] (is it on ios now?) - how does that direct
stuff to each?

> Barring that you
> could also imagine filtering on the UDP port number, but that
> sounds even less likely to be supported.

you can send stuff into another queue - if you have one - with an
iptables or tc rule.

>
> I think I agree with Juliusz here, I'd prefer Babel stay truthful and

I think I'm going to long-term object to the memes of "lying and
truth" when it comes to this discussion. How about: "enabling" and
"respecting"?

> instead change how fq_codel reacts to it.

So we mod fq_codel for every application? Not gonna happen. sch_cake
has some ideas here.

[1] daves-Air-3:babel d$ netstat -I en0 -qq

en0:

     [ sched:  FQ_CODEL  qlength:    0/128 ]

     [ pkts:          0  bytes:          0  dropped pkts:    383 bytes:  79517 ]

=====================================================

     [ pri: VO (1) srv_cl: 0x400180 quantum: 600 drr_max: 8 ]

     [ queued pkts: 0 bytes: 0 ]

     [ dequeued pkts: 18705 bytes: 2208248 ]

     [ budget: 0 target qdelay: 10.00 msec update interval:100.00 msec ]

     [ flow control: 0 feedback: 0 stalls: 0 failed: 0 ]

     [ drop overflow: 0 early: 0 memfail: 0 duprexmt:0 ]

     [ flows total: 0 new: 0 old: 0 ]

     [ throttle on: 0 off: 0 drop: 0 ]

=====================================================

     [ pri: VI (2) srv_cl: 0x380100 quantum: 3000 drr_max: 6 ]

     [ queued pkts: 0 bytes: 0 ]

     [ dequeued pkts: 0 bytes: 0 ]

     [ budget: 0 target qdelay: 10.00 msec update interval:100.00 msec ]

     [ flow control: 0 feedback: 0 stalls: 0 failed: 0 ]

     [ drop overflow: 0 early: 0 memfail: 0 duprexmt:0 ]

     [ flows total: 0 new: 0 old: 0 ]

     [ throttle on: 0 off: 0 drop: 0 ]

=====================================================

     [ pri: BE (7) srv_cl: 0x0 quantum: 1500 drr_max: 4 ]

     [ queued pkts: 0 bytes: 0 ]

     [ dequeued pkts: 3120521 bytes: 674001960 ]

     [ budget: 0 target qdelay: 10.00 msec update interval:100.00 msec ]

     [ flow control: 0 feedback: 0 stalls: 0 failed: 0 ]

     [ drop overflow: 0 early: 0 memfail: 0 duprexmt:0 ]

     [ flows total: 0 new: 0 old: 0 ]

     [ throttle on: 0 off: 0 drop: 0 ]

=====================================================

     [ pri: BK (8) srv_cl: 0x100080 quantum: 1500 drr_max: 2 ]

     [ queued pkts: 0 bytes: 0 ]

     [ dequeued pkts: 706005 bytes: 50973110 ]

     [ budget: 0 target qdelay: 10.00 msec update interval:100.00 msec ]

     [ flow control: 0 feedback: 0 stalls: 0 failed: 0 ]

     [ drop overflow: 0 early: 0 memfail: 0 duprexmt:0 ]

     [ flows total: 0 new: 0 old: 0 ]

     [ throttle on: 0 off: 0 drop: 0 ]

> David
>
>
> > On Sep 27, 2018, at 09:30, Dave Taht <dave.taht at gmail.com> wrote:
> >
> > On Wed, Sep 26, 2018 at 3:36 PM Juliusz Chroboczek <jch at irif.fr> wrote:
> >>
> >>> -    const int ds = 0xc0;        /* CS6 - Network Control */
> >>> +    const int ds = 0xc2;        /* CS6 - Network Control + ECN */
> >>
> >> Nope.  If we start lying about ECN, people will start disabling ECN in
> >> routers, which would not be a good thing.
> >
> > I appreciate the moral stance, and to a huge extent I share it (
> > https://www.bufferbloat.net/projects/ecn-sane/wiki/dtaht_ecn_editorial/
> > )
> >
> > On the other hand the characteristics of ECN'd babel traffic (single
> > low volume flows) interact with fq_codel
> > well, only imparting delay on overload to those flows and affecting
> > other traffic minimally. It makes l3 based routing info behave more
> > like a control plane, and more similarly to 802.11s which does stuff
> > at the management frame layer underneath layer 2 with no congestion
> > control applied at all.
> >
> > I had at one point a patch that attempted to do more of the right
> > thing ( increasing the metric as per loss but not ever going infinite
> > ) but it was invasive. At some point in the coming year or two maybe
> > we'll be able to sit down and do more science on the ecn front but
> > it's quite a long list (
> > https://www.bufferbloat.net/projects/ecn-sane/wiki/  ) with the usual
> > lack of bodies and funding.
> >
> > In the interim, I'd welcome more data from more deployments. Including mine.
> >
> >
> >
> > I
> >
> > --
> >
> > Dave Täht
> > CEO, TekLibre, LLC
> > http://www.teklibre.com
> > Tel: 1-669-226-2619
> >
> > _______________________________________________
> > Babel-users mailing list
> > Babel-users at alioth-lists.debian.net
> > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users
>

-- 

Dave Täht
CEO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-669-226-2619