Message ID | 20220202142554.9691-1-justin.iurman@uliege.be (mailing list archive) |
---|---|
Headers | show |
Series | Support for the IOAM insertion frequency | expand |
On 2/2/22 7:25 AM, Justin Iurman 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.
On Feb 3, 2022, at 4:47 AM, David Ahern dsahern@gmail.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.
Hello: This series was applied to netdev/net-next.git (master) by Jakub Kicinski <kuba@kernel.org>: On Wed, 2 Feb 2022 15:25:52 +0100 you 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)]. > > [...] Here is the summary with links: - [net-next,v2,1/2] uapi: ioam: Insertion frequency https://git.kernel.org/netdev/net-next/c/be847673cfff - [net-next,v2,2/2] ipv6: ioam: Insertion frequency in lwtunnel output https://git.kernel.org/netdev/net-next/c/08731d30e78e You are awesome, thank you!