Message-ID: <aSe/IfNSZBTTAfTA@pop-os.localdomain>
Date: Wed, 26 Nov 2025 19:01:53 -0800
From: Cong Wang <xiyou.wangcong@...il.com>
To: William Liu <will@...lsroot.io>
Cc: netdev@...r.kernel.org, stephen@...workplumber.org, kuba@...nel.org,
	Savino Dicanosa <savy@...t3mfailure.io>,
	Jamal Hadi Salim <jhs@...atatu.com>
Subject: Re: [Patch net v5 3/9] net_sched: Implement the right netem
 duplication behavior

On Thu, Nov 27, 2025 at 02:09:58AM +0000, William Liu wrote:
> On Wednesday, November 26th, 2025 at 11:13 PM, Cong Wang <xiyou.wangcong@...il.com> wrote:
> 
> > Again, it does not violate the man page. What standard are you referring
> > to when you say "expected user behavior"? Please kindly point me to the
> > standard you refer here, I am happy to look into it.
> 
> I meant long-time existing user-observable behavior (since 2005).

If you believe this does not violate man page, then it is safe.

Otherwise, please be specific on how it violates man page. There is only
one sentence in the man page: "creates a copy of the packet before queuing."
Let's reduce it down to two words: "before queuing", please kindly point out
which word my patch violates. I am happy to consider your opinion, but
only when you are willing to help.

Keep saying long-time or user-expected does not help anything here, man
page is the only "contract" we have with the users.

> 
> If you were just trying to fix the bug, then a fix that prevents DOS and changes no existing observable behavior is better imo.

The problematic behavior of duplication is the root cause. So, we can't
fix the bug without fixing the root cause.

Let's put security aside, it is still problematic logically. There is no
way to define a logiclly correct behavior with queuing back to root.

Since you ignored my 3-page long changelog, let me copy-n-paste it for
your convenience:

   Single netem hierarchy (prio + netem):
      tc qdisc add dev lo root handle 1: prio bands 3 priomap 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
      tc filter add dev lo parent 1:0 protocol ip matchall classid 1:1
      tc qdisc add dev lo parent 1:1 handle 10: netem limit 4 duplicate 100%

    Result: 2x packet multiplication (1→2 packets)
      2 echo requests + 4 echo replies = 6 total packets

    Expected behavior: Only one netem stage exists in this hierarchy, so
    1 ping becomes 2 packets (100% duplication). The 2 echo requests generate
    2 echo replies, which also get duplicated to 4 replies, yielding the
    predictable total of 6 packets (2 requests + 4 replies).

    Nest netem hierarchy (netem + netem):
      tc qdisc add dev lo root handle 1: netem limit 1000 duplicate 100%
      tc qdisc add dev lo parent 1: handle 2: netem limit 1000 duplicate 100%

    Result: 4x packet multiplication (1→2→4 packets)
      4 echo requests + 16 echo replies = 20 total packets
 
If a netem clone is reinjected at the root, then each duplicate enters the
entire qdisc hierarchy again, so the clone becomes
an input to netem again, producing: 1 → 2 → 4 → 8 → …

This is no longer a single probability distribution; it becomes a cascade
of netem stages, even if you only configured one.

The behavior becomes structural, not probabilistic. Which is not what users
expect when they set duplicate 100%.

They intuitively expect:
- One duplication,
- One netem pass,
- No recursion.

This matches same-qdisc enqueueing.

This is why the right behavior matters for users, regardless of security
concern. Hence it must be corrected.

If any part of it is not clear, please let me know. I am very happy to
explain to you. If you need, we can have a video meeting too, happy to
walk you through this step-by-step.

Thanks,
Cong

Powered by blists - more mailing lists