[Cake] arp flow dissector

[Cake] arp flow dissector

[Dave Taht]

Didn't know we had this now.

https://www.spinics.net/lists/netdev/msg413986.html
-- 

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

Re: [Cake] arp flow dissector

[Jonathan Morton]

> On 2 Sep, 2018, at 10:37 pm, Dave Taht <dave.taht@gmail.com> wrote:
> 
> Didn't know we had this now.
> 
> https://www.spinics.net/lists/netdev/msg413986.html

Does that automagically give Cake an idea of the IP addresses associated with the packet, for host-fairness purposes?  If not, we should fix that.

 - Jonathan Morton

Re: [Cake] arp flow dissector

[Toke Høiland-Jørgensen]

Jonathan Morton <chromatix99@gmail.com> writes:

>> On 2 Sep, 2018, at 10:37 pm, Dave Taht <dave.taht@gmail.com> wrote:
>> 
>> Didn't know we had this now.
>> 
>> https://www.spinics.net/lists/netdev/msg413986.html
>
> Does that automagically give Cake an idea of the IP addresses
> associated with the packet, for host-fairness purposes?  If not, we
> should fix that.

Don't think so. There's a follow-up patch to enable the matching for
cls_flower: https://www.spinics.net/lists/netdev/msg413985.html

However, in normal operation ARPs should be fairly rare, so adding this
support to CAKE would mostly be to protect against flooding, wouldn't
it?

-Toke

Re: [Cake] arp flow dissector

[Jonathan Morton]

> On 3 Sep, 2018, at 2:14 pm, Toke Høiland-Jørgensen <toke@toke.dk> wrote:
> 
> However, in normal operation ARPs should be fairly rare, so adding this
> support to CAKE would mostly be to protect against flooding, wouldn't
> it?

Mostly it's just for consistency's sake.  Currently all ARPs end up in a single queue together, because they have no IP header and no transport header to extract any of the components of the usual 5-tuple from.  With IP addresses extracted, they would be correctly associated with their originating and/or destination hosts for fairness purposes, while still being in distinct queues from normal traffic.

I suspect anyone generating an ARP flood would also be doing a lot of spoofing, so it's not actually very helpful from that perspective.  In fact, arguably the current behaviour of putting all ARP traffic in a single queue would be better.

Conversely, it's straightforward to imagine a scenario where ARP is a tiny fraction of the traffic generated by one host, but ARP traffic from many idle hosts contributes more significantly to the total.  Most of these ARP requests might just be part of a DHCP transaction.

 - Jonathan Morton

Re: [Cake] arp flow dissector

[Jonathan Morton]

> On 3 Sep, 2018, at 3:29 pm, David Lang <david@lang.hm> wrote:
> 
> how much ARP traffic would there have to be before the benefits of this outweigh the overhead of tracking it?

If there's very little ARP traffic (as normal), then the overhead of recognising it is basically nil.

The benefits become apparent as soon as the volume of ARP traffic, in aggregate, becomes great enough for its queue to be marked "saturating" instead of "sparse".  This could reasonably occur if the other traffic consists of a lot of distinct flows.

 - Jonathan Morton