[Cake] best way at getting at tcp ack data?

[Cake] best way at getting at tcp ack data?

[Dave Taht]

I was thinking about how I'd go about adding saner ack filtering [1]
to cake (or maybe to a tc filter), and perhaps it is way simple, now.

Merely using the skb_flow_dissect stuff gives me all the flow related
fields, from potentially deeply encapsulated packets - and seems to
have grown FLOW_DISSECTOR_KEY_TCP at some point since I last looked.

Seems promising. Not sure how to get at it in the context of cake?

....

The infamous wondershaper filter looks like this:

tc filter add dev $DEV parent 1: protocol ip prio 12 u32 \
   match ip protocol 6 0xff \
   match u8 0x05 0x0f at 0 \
   match u16 0x0000 0xffc0 at 2 \
   match u8 0x10 0xff at 33 \
   flowid 1:10

And that filter is wrong for encapsulated traffic, and ipv6.

[1] https://tools.ietf.org/html/rfc3449

-- 

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

Re: [Cake] best way at getting at tcp ack data?

[Jonathan Morton]

On 01/10/17 06:10, Dave Taht wrote:
> I was thinking about how I'd go about adding saner ack filtering [1]
> to cake

I didn't see any obvious improvement in that reference over what Cake 
does already.  What are you thinking of?

-- 
  - Jonathan Morton

Re: [Cake] best way at getting at tcp ack data?

[Dave Taht]

https://tools.ietf.org/html/rfc3449#section-5.2.1

On Sat, Sep 30, 2017 at 10:22 PM, Jonathan Morton <chromatix99@gmail.com> wrote:
> On 01/10/17 06:10, Dave Taht wrote:
>>
>> I was thinking about how I'd go about adding saner ack filtering [1]
>> to cake
>
>
> I didn't see any obvious improvement in that reference over what Cake does
> already.  What are you thinking of?
>
> --
>  - Jonathan Morton
> _______________________________________________
> Cake mailing list
> Cake@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cake



-- 

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

Re: [Cake] best way at getting at tcp ack data?

[Jonathan Morton]

[-- Attachment #1: Type: text/plain, Size: 453 bytes --]

Ah, so effectively you want to drop acks more aggressively than data
packets when they become a saturating flow in themselves, but without
disturbing the cues that TCP relies on.  There is some logic behind that,
since COBALT ramps up quite slowly with very small packets like acks.

I think it's worth opening an issue to remind me to look into that.  I
still don't have a replacement for my MBP, which is complicating matters
here.

- Jonathan Morton

[-- Attachment #2: Type: text/html, Size: 522 bytes --]

Re: [Cake] best way at getting at tcp ack data?

[Dave Taht]

The crux of my question was what would be the best way to incorporate
the FLOW_DISSECTOR_KEY_TCP into cake whilst retaining all the other
DPI. I would add a "ack_filter" parameter to the rate_flags?

On Sun, Oct 1, 2017 at 6:08 PM, Jonathan Morton <chromatix99@gmail.com> wrote:
> Ah, so effectively you want to drop acks more aggressively than data packets
> when they become a saturating flow in themselves,

Well, no, what I envisioned would try to comprehensively "do the right
thing" when it came to dropping acks, and not actually wait til they
were saturating.

you have a good point though.

Where I see the most use for it is on very slow DSL, and on wifi
(where you have a small packet limit and reliable transfers).

I also don't know what will happen with extensive filtering in place
to the reverse path, reason tells me that the sparse packet priority
scheme when applied to filtered out acks will result in really bursty
throughput on the other side, and it would be better to defer a full
round between deliveries than leave the sparse packet priority scheme
in place, when doing ack filtering. But that's "reason", and that
fails me a lot whilst thinking about queues.

As I believe at least some level of ack filtering is widely
deployed... til now, I've largely been satisfied that the DRR would
deliver a ton of acks that would be filtered out by the device doing
it.

>but without disturbing the
> cues that TCP relies on.  There is some logic behind that, since COBALT
> ramps up quite slowly with very small packets like acks.
>
> I think it's worth opening an issue to remind me to look into that.

Well, I might gather enough gumption to go after it, as well as try
and produce a cleaned up cake branch suitable for inclusion in 4.15.

At the moment I'm starting to prototype a bit with a bfifo, and
perhaps netem, 'cause grokking cake makes my head hurt.

> I still
> don't have a replacement for my MBP, which is complicating matters here.

MBP?

> - Jonathan Morton



-- 

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

Re: [Cake] best way at getting at tcp ack data?

[Noah Causin]

After reading about ACK filtering, I have an idea and wonder if it is 
possible.  I only have basic knowledge about the TCP protocol.

Instead of dropping TCP data packets, would it be possible to drop 
normal ACK packets to signal congestion?

The sender would see that ACK packets are missing and slow down its 
transmission rate and re-transmit the data packets it thought were 
lost.  Since the client has already received the packets beforehand, the 
application would not experience packet loss, and TCP would simply 
re-acknowledge the packets and discard the copies.

Could this be used to create a pseudo-lossless congestion notification 
scheme, since the client would not see any packet loss, which could be 
beneficial for certain applications?

Noah

Re: [Cake] best way at getting at tcp ack data?

[Jonathan Morton]

[-- Attachment #1: Type: text/plain, Size: 175 bytes --]

No, because acks are cumulative.  Dropping an ack doesn't normally trigger
any retransmissions, and is actually difficult to detect reliably at the
sender.

- Jonathan Morton

[-- Attachment #2: Type: text/html, Size: 222 bytes --]

Re: [Cake] best way at getting at tcp ack data?

[Jonathan Morton]

[-- Attachment #1: Type: text/plain, Size: 84 bytes --]

There's a much better way to achieve what you want anyway - ECN.

- Jonathan Morton

[-- Attachment #2: Type: text/html, Size: 127 bytes --]