Cake - FQ_codel the next generation
 help / color / mirror / Atom feed
From: Kevin Darbyshire-Bryant <kevin@darbyshire-bryant.me.uk>
To: John Sager <john@sager.me.uk>
Cc: "cake@lists.bufferbloat.net" <cake@lists.bufferbloat.net>
Subject: Re: [Cake] Ingress classification
Date: Wed, 6 Feb 2019 12:52:22 +0000	[thread overview]
Message-ID: <65D66C9D-6C65-4307-87AE-35DC93EC5AE1@darbyshire-bryant.me.uk> (raw)
In-Reply-To: <2ffe2d11-ed65-6dde-881f-997afa3d8485@sager.me.uk>



> On 5 Feb 2019, at 13:38, John Sager <john@sager.me.uk> wrote:
> 
> As you say, an unsolicited incoming packet doesn't get marked. However it
> creates a conntrack record with zero mark. What you then do is to mark the
> conntrack record later so that all subsequent packets on that connection get
> marked by 'action connmark'. So the first packet gets classified on ifb to
> some low priority queue, but subsequent ones go where they should.
> 
> I do this for incoming ssh and VPN connections, though I'm using
> htb/fq_codel rather than cake at the moment.
> 

Thank you John, that has confirmed my understanding that in essence it’s not possible in linux to mangle/mark the first packet on ingress and you ideally need the DSCP to be correct.

My router threw me another curve ball in that it was classifying incoming packets correctly but outgoing acks weren’t.  Since (ingress) connmarks were based on DSCP values I really couldn’t understand how the connection had been marked correctly for ingress but the egress was wrong.

This turned out to be fallout from openwrt’s software flow offload feature which bypasses some more of the stack.  So ingress classification was based on connmarks whilst the egress was based on DSCP and because of the flow offloading the DSCP values weren’t being mangled after the first few packets.

At this stage I’m wondering if its possible to get tc/cake to classify egress based on connmarks instead of relying on DSCP but my tc filter syntax is failing me at the moment :-)



Kevin D-B

012C ACB2 28C6 C53E 9775  9123 B3A2 389B 9DE2 334A


  reply	other threads:[~2019-02-06 12:52 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-02-05 12:08 Kevin Darbyshire-Bryant
2019-02-05 13:38 ` John Sager
2019-02-06 12:52   ` Kevin Darbyshire-Bryant [this message]
2019-02-06 13:54     ` Toke Høiland-Jørgensen
2019-02-10 21:54       ` Kevin Darbyshire-Bryant
2019-02-10 22:18         ` Toke Høiland-Jørgensen
2019-02-06 16:19     ` Stephen Hemminger
2019-02-07 16:28       ` Kevin Darbyshire-Bryant

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://lists.bufferbloat.net/postorius/lists/cake.lists.bufferbloat.net/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=65D66C9D-6C65-4307-87AE-35DC93EC5AE1@darbyshire-bryant.me.uk \
    --to=kevin@darbyshire-bryant.me.uk \
    --cc=cake@lists.bufferbloat.net \
    --cc=john@sager.me.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox