netdev - Re: [PATCH net-next v2 0/2] Support for the IOAM insertion frequency

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1603413387.15401325.1643882515850.JavaMail.zimbra@uliege.be>
Date:   Thu, 3 Feb 2022 11:01:55 +0100 (CET)
From:   Justin Iurman <justin.iurman@...ege.be>
To:     David Ahern <dsahern@...il.com>
Cc:     netdev@...r.kernel.org, davem@...emloft.net, kuba@...nel.org,
        yoshfuji@...ux-ipv6.org, dsahern@...nel.org
Subject: Re: [PATCH net-next v2 0/2] Support for the IOAM insertion
 frequency

On Feb 3, 2022, at 4:47 AM, David Ahern dsahern@...il.com wrote:
>> v2:
>>  - signed -> unsigned (for "k" and "n")
>>  - keep binary compatibility by moving "k" and "n" at the end of uapi
>> 
>> The insertion frequency is represented as "k/n", meaning IOAM will be
>> added to {k} packets over {n} packets, with 0 < k <= n and 1 <= {k,n} <=
>> 1000000. Therefore, it provides the following percentages of insertion
>> frequency: [0.0001% (min) ... 100% (max)].
>> 
>> Not only this solution allows an operator to apply dynamic frequencies
>> based on the current traffic load, but it also provides some
>> flexibility, i.e., by distinguishing similar cases (e.g., "1/2" and
>> "2/4").
>> 
>> "1/2" = Y N Y N Y N Y N ...
>> "2/4" = Y Y N N Y Y N N ...
>> 
> 
> what's the thought process behind this kind of sampling? K consecutive
> packets in a row with the trace; N-K consecutive packets without it.

Flexibility. Long story short, it was initially designed with a fixed
"k" (i.e., k=1) so that operators could set the IOAM insertion frequency
to "1/n" (i.e., inject IOAM every n packets). Available frequencies were
100% ("1/1"), 50% ("1/2"), 33% ("1/3"), 25% ("1/4"), etc. By introducing
a non-fixed "k", we wanted to provide flexibility and accuracy to
operators, because you never know... They could require to inject IOAM
in 75% of their traffic, or want to differentiate "1/2" and "2/4", or
whatever). So you can see it as an improved feature of the "1/n" base
frequency. Whether it'll be useful or not, well, I don't know. Again, it
all depends on operators' needs.