* [Cake] arp flow dissector
@ 2018-09-02 19:37 Dave Taht
2018-09-03 1:36 ` Jonathan Morton
0 siblings, 1 reply; 5+ messages in thread
From: Dave Taht @ 2018-09-02 19:37 UTC (permalink / raw)
To: Cake List
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [Cake] arp flow dissector
2018-09-02 19:37 [Cake] arp flow dissector Dave Taht
@ 2018-09-03 1:36 ` Jonathan Morton
2018-09-03 11:14 ` Toke Høiland-Jørgensen
0 siblings, 1 reply; 5+ messages in thread
From: Jonathan Morton @ 2018-09-03 1:36 UTC (permalink / raw)
To: Dave Taht; +Cc: Cake List
> 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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [Cake] arp flow dissector
2018-09-03 1:36 ` Jonathan Morton
@ 2018-09-03 11:14 ` Toke Høiland-Jørgensen
2018-09-03 12:26 ` Jonathan Morton
0 siblings, 1 reply; 5+ messages in thread
From: Toke Høiland-Jørgensen @ 2018-09-03 11:14 UTC (permalink / raw)
To: Jonathan Morton, Dave Taht; +Cc: Cake List
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [Cake] arp flow dissector
2018-09-03 11:14 ` Toke Høiland-Jørgensen
@ 2018-09-03 12:26 ` Jonathan Morton
[not found] ` <nycvar.QRO.7.76.6.1809030529130.4352@qynat-yncgbc>
0 siblings, 1 reply; 5+ messages in thread
From: Jonathan Morton @ 2018-09-03 12:26 UTC (permalink / raw)
To: Toke Høiland-Jørgensen; +Cc: Dave Taht, Cake List
> 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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [Cake] arp flow dissector
[not found] ` <nycvar.QRO.7.76.6.1809030529130.4352@qynat-yncgbc>
@ 2018-09-03 13:00 ` Jonathan Morton
0 siblings, 0 replies; 5+ messages in thread
From: Jonathan Morton @ 2018-09-03 13:00 UTC (permalink / raw)
To: David Lang; +Cc: Toke Høiland-Jørgensen, Cake List
> 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
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2018-09-03 13:00 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-09-02 19:37 [Cake] arp flow dissector Dave Taht
2018-09-03 1:36 ` Jonathan Morton
2018-09-03 11:14 ` Toke Høiland-Jørgensen
2018-09-03 12:26 ` Jonathan Morton
[not found] ` <nycvar.QRO.7.76.6.1809030529130.4352@qynat-yncgbc>
2018-09-03 13:00 ` Jonathan Morton
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox