[PATCH] src: proto: support DF, LE, VA for DSCP

[PATCH] src: proto: support DF, LE, VA for DSCP

[Oleksandr Natalenko]

Add a couple of aliases for well-known DSCP values.

As per RFC 4594, add "df" as an alias of "cs0" with 0x00 value.

As per RFC 5865, add "va" for VOICE-ADMIT with 0x2c value.

As per RFC 8622, add "le" for Lower-Effort with 0x01 value.

tc-cake(8) in diffserv8 mode would benefit from having "le" alias since
it corresponds to "Tin 0".

Signed-off-by: Oleksandr Natalenko <oleksandr@natalenko.name>
---
 src/proto.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/src/proto.c b/src/proto.c
index a013a00d..84555b9e 100644
--- a/src/proto.c
+++ b/src/proto.c
@@ -684,7 +684,9 @@ static const struct symbol_table dscp_type_tbl = {
 		SYMBOL("cs5",	0x28),
 		SYMBOL("cs6",	0x30),
 		SYMBOL("cs7",	0x38),
+		SYMBOL("df",	0x00),
 		SYMBOL("be",	0x00),
+		SYMBOL("le",	0x01),
 		SYMBOL("af11",	0x0a),
 		SYMBOL("af12",	0x0c),
 		SYMBOL("af13",	0x0e),
@@ -697,6 +699,7 @@ static const struct symbol_table dscp_type_tbl = {
 		SYMBOL("af41",	0x22),
 		SYMBOL("af42",	0x24),
 		SYMBOL("af43",	0x26),
+		SYMBOL("va",	0x2c),
 		SYMBOL("ef",	0x2e),
 		SYMBOL_LIST_END
 	},
-- 
2.36.1

Re: [PATCH] src: proto: support DF, LE, VA for DSCP

[Pablo Neira Ayuso]

Hi,

On Mon, Jun 20, 2022 at 08:58:07PM +0200, Oleksandr Natalenko wrote:
> Add a couple of aliases for well-known DSCP values.
> 
> As per RFC 4594, add "df" as an alias of "cs0" with 0x00 value.
> 
> As per RFC 5865, add "va" for VOICE-ADMIT with 0x2c value.

Quickly browsing, I don't find "va" nor 0x2c in this RFC above? Could
you refer to page?

> As per RFC 8622, add "le" for Lower-Effort with 0x01 value.

This RFC refers to replacing CS1 by LE

   o  This update to RFC 4594 removes the following entry from its
      Figure 4:

   |---------------+------+-------------------+---------+--------+----|
   | Low-Priority  | CS1  | Not applicable    | RFC3662 |  Rate  | Yes|
   |     Data      |      |                   |         |        |    |
    ------------------------------------------------------------------

      and replaces it with the following entry:

   |---------------+------+-------------------+----------+--------+----|
   | Low-Priority  | LE   | Not applicable    | RFC 8622 |  Rate  | Yes|
   |     Data      |      |                   |          |        |    |
    -------------------------------------------------------------------


static const struct symbol_table dscp_type_tbl = {
        .base           = BASE_HEXADECIMAL,
        .symbols        = {
                [...]
                SYMBOL("cs1",   0x08),
                [...]
                SYMBOL("le",    0x01),

> tc-cake(8) in diffserv8 mode would benefit from having "le" alias since
> it corresponds to "Tin 0".

Aliasing is fine, let's just clarify this first.

Thanks.

Re: [PATCH] src: proto: support DF, LE, VA for DSCP

[Oleksandr Natalenko]

Hello.

Thank you for your response. Please find my comments inline.

On pondělí 27. června 2022 19:31:27 CEST Pablo Neira Ayuso wrote:
> On Mon, Jun 20, 2022 at 08:58:07PM +0200, Oleksandr Natalenko wrote:
> > Add a couple of aliases for well-known DSCP values.
> > 
> > As per RFC 4594, add "df" as an alias of "cs0" with 0x00 value.
> > 
> > As per RFC 5865, add "va" for VOICE-ADMIT with 0x2c value.
> 
> Quickly browsing, I don't find "va" nor 0x2c in this RFC above? Could
> you refer to page?

As per my understanding it's page 11 ("2.3.  Recommendations on implementation of an Admitted Telephony Service Class") here:

      Name         Space    Reference
      ---------    -------  ---------
      VOICE-ADMIT  101100   [RFC5865]

Am I wrong?

> > As per RFC 8622, add "le" for Lower-Effort with 0x01 value.
> 
> This RFC refers to replacing CS1 by LE
> 
>    o  This update to RFC 4594 removes the following entry from its
>       Figure 4:
> 
>    |---------------+------+-------------------+---------+--------+----|
>    | Low-Priority  | CS1  | Not applicable    | RFC3662 |  Rate  | Yes|
>    |     Data      |      |                   |         |        |    |
>     ------------------------------------------------------------------
> 
>       and replaces it with the following entry:
> 
>    |---------------+------+-------------------+----------+--------+----|
>    | Low-Priority  | LE   | Not applicable    | RFC 8622 |  Rate  | Yes|
>    |     Data      |      |                   |          |        |    |
>     -------------------------------------------------------------------
> 
> 
> static const struct symbol_table dscp_type_tbl = {
>         .base           = BASE_HEXADECIMAL,
>         .symbols        = {
>                 [...]
>                 SYMBOL("cs1",   0x08),
>                 [...]
>                 SYMBOL("le",    0x01),

I think we shouldn't remove existing symbol, should we? Please let me know if I missed any suggested action item for myself here.

> > tc-cake(8) in diffserv8 mode would benefit from having "le" alias since
> > it corresponds to "Tin 0".
> 
> Aliasing is fine, let's just clarify this first.

I mean, "le" would be an alias to "0x01", not to "cs1".

BTW, the reason I included Loganaden Velvindron in Cc is that "le" was already added in the past, but got quickly reverted as it broke some tests. Shall "le" interfere with "less-equal", or what could be the issue with it? If the name is not acceptable, "lephb" or similar can be used instead.

Thanks.

Thanks.

-- 
Oleksandr Natalenko (post-factum)

Re: [PATCH] src: proto: support DF, LE, VA for DSCP

[Pablo Neira Ayuso]

On Tue, Jun 28, 2022 at 08:29:42PM +0200, Oleksandr Natalenko wrote:
> Hello.
> 
> Thank you for your response. Please find my comments inline.
> 
> On pondělí 27. června 2022 19:31:27 CEST Pablo Neira Ayuso wrote:
> > On Mon, Jun 20, 2022 at 08:58:07PM +0200, Oleksandr Natalenko wrote:
> > > Add a couple of aliases for well-known DSCP values.
> > > 
> > > As per RFC 4594, add "df" as an alias of "cs0" with 0x00 value.
> > > 
> > > As per RFC 5865, add "va" for VOICE-ADMIT with 0x2c value.
> > 
> > Quickly browsing, I don't find "va" nor 0x2c in this RFC above? Could
> > you refer to page?
> 
> As per my understanding it's page 11 ("2.3.  Recommendations on implementation of an Admitted Telephony Service Class") here:
> 
>       Name         Space    Reference
>       ---------    -------  ---------
>       VOICE-ADMIT  101100   [RFC5865]
> 
> Am I wrong?

Ok, hence the 'va'.

> > > As per RFC 8622, add "le" for Lower-Effort with 0x01 value.
> > 
> > This RFC refers to replacing CS1 by LE
> > 
> >    o  This update to RFC 4594 removes the following entry from its
> >       Figure 4:
> > 
> >    |---------------+------+-------------------+---------+--------+----|
> >    | Low-Priority  | CS1  | Not applicable    | RFC3662 |  Rate  | Yes|
> >    |     Data      |      |                   |         |        |    |
> >     ------------------------------------------------------------------
> > 
> >       and replaces it with the following entry:
> > 
> >    |---------------+------+-------------------+----------+--------+----|
> >    | Low-Priority  | LE   | Not applicable    | RFC 8622 |  Rate  | Yes|
> >    |     Data      |      |                   |          |        |    |
> >     -------------------------------------------------------------------
> > 
> > 
> > static const struct symbol_table dscp_type_tbl = {
> >         .base           = BASE_HEXADECIMAL,
> >         .symbols        = {
> >                 [...]
> >                 SYMBOL("cs1",   0x08),
> >                 [...]
> >                 SYMBOL("le",    0x01),
> 
> I think we shouldn't remove existing symbol, should we? Please let
> me know if I missed any suggested action item for myself here.

Not removing. I mean, if I understood correctly, the RFC says LE == cs1 ?
But the values are different.

> > > tc-cake(8) in diffserv8 mode would benefit from having "le" alias since
> > > it corresponds to "Tin 0".
> > 
> > Aliasing is fine, let's just clarify this first.
> 
> I mean, "le" would be an alias to "0x01", not to "cs1".
> 
> BTW, the reason I included Loganaden Velvindron in Cc is that "le"
> was already added in the past, but got quickly reverted as it broke
> some tests. Shall "le" interfere with "less-equal", or what could be
> the issue with it? If the name is not acceptable, "lephb" or similar
> can be used instead.

Oh right, this is an issue for the parser, the 'le' keyword is an
alias of '<='.

What does 'lephb' stands for BTW?

Note that these aliases will be lost when listing back the ruleset
from the kernel, so it is only working as an input.

Re: [PATCH] src: proto: support DF, LE, VA for DSCP

[Oleksandr Natalenko]

Hello.

On středa 29. června 2022 19:24:28 CEST Pablo Neira Ayuso wrote:
> On Tue, Jun 28, 2022 at 08:29:42PM +0200, Oleksandr Natalenko wrote:
> > On pondělí 27. června 2022 19:31:27 CEST Pablo Neira Ayuso wrote:
> > > On Mon, Jun 20, 2022 at 08:58:07PM +0200, Oleksandr Natalenko wrote:
> > > > Add a couple of aliases for well-known DSCP values.
> > > > 
> > > > As per RFC 4594, add "df" as an alias of "cs0" with 0x00 value.
> > > > 
> > > > As per RFC 5865, add "va" for VOICE-ADMIT with 0x2c value.
> > > 
> > > Quickly browsing, I don't find "va" nor 0x2c in this RFC above? Could
> > > you refer to page?
> > 
> > As per my understanding it's page 11 ("2.3.  Recommendations on implementation of an Admitted Telephony Service Class") here:
> > 
> >       Name         Space    Reference
> >       ---------    -------  ---------
> >       VOICE-ADMIT  101100   [RFC5865]
> > 
> > Am I wrong?
> 
> Ok, hence the 'va'.

Yes.

> > > > As per RFC 8622, add "le" for Lower-Effort with 0x01 value.
> > > 
> > > This RFC refers to replacing CS1 by LE
> > > 
> > >    o  This update to RFC 4594 removes the following entry from its
> > >       Figure 4:
> > > 
> > >    |---------------+------+-------------------+---------+--------+----|
> > >    | Low-Priority  | CS1  | Not applicable    | RFC3662 |  Rate  | Yes|
> > >    |     Data      |      |                   |         |        |    |
> > >     ------------------------------------------------------------------
> > > 
> > >       and replaces it with the following entry:
> > > 
> > >    |---------------+------+-------------------+----------+--------+----|
> > >    | Low-Priority  | LE   | Not applicable    | RFC 8622 |  Rate  | Yes|
> > >    |     Data      |      |                   |          |        |    |
> > >     -------------------------------------------------------------------
> > > 
> > > 
> > > static const struct symbol_table dscp_type_tbl = {
> > >         .base           = BASE_HEXADECIMAL,
> > >         .symbols        = {
> > >                 [...]
> > >                 SYMBOL("cs1",   0x08),
> > >                 [...]
> > >                 SYMBOL("le",    0x01),
> > 
> > I think we shouldn't remove existing symbol, should we? Please let
> > me know if I missed any suggested action item for myself here.
> 
> Not removing. I mean, if I understood correctly, the RFC says LE == cs1 ?

To my understanding, no. The RFC talks about obsoleting:

"This specification obsoletes RFC 3662 and updates the DSCP recommended in RFCs 4594 and 8325 to use the DSCP assigned in this specification."

> But the values are different.

Yes, as a consequence of obsoleting, not replacing.

> > > > tc-cake(8) in diffserv8 mode would benefit from having "le" alias since
> > > > it corresponds to "Tin 0".
> > > 
> > > Aliasing is fine, let's just clarify this first.
> > 
> > I mean, "le" would be an alias to "0x01", not to "cs1".
> > 
> > BTW, the reason I included Loganaden Velvindron in Cc is that "le"
> > was already added in the past, but got quickly reverted as it broke
> > some tests. Shall "le" interfere with "less-equal", or what could be
> > the issue with it? If the name is not acceptable, "lephb" or similar
> > can be used instead.
> 
> Oh right, this is an issue for the parser, the 'le' keyword is an
> alias of '<='.

OK, then another name should be found.

> What does 'lephb' stands for BTW?

"LE PHB" originally, as described in the RFC, it's Lower-Effort Per-Hop Behavior.

> Note that these aliases will be lost when listing back the ruleset
> from the kernel, so it is only working as an input.

Sure thing.

Thanks.

-- 
Oleksandr Natalenko (post-factum)

Re: [PATCH] src: proto: support DF, LE, VA for DSCP

[Pablo Neira Ayuso]

On Wed, Jun 29, 2022 at 07:34:40PM +0200, Oleksandr Natalenko wrote:
> Hello.
> 
> On středa 29. června 2022 19:24:28 CEST Pablo Neira Ayuso wrote:
> > On Tue, Jun 28, 2022 at 08:29:42PM +0200, Oleksandr Natalenko wrote:
> > > On pondělí 27. června 2022 19:31:27 CEST Pablo Neira Ayuso wrote:
> > > > On Mon, Jun 20, 2022 at 08:58:07PM +0200, Oleksandr Natalenko wrote:
> > > > > Add a couple of aliases for well-known DSCP values.
> > > > > 
> > > > > As per RFC 4594, add "df" as an alias of "cs0" with 0x00 value.
> > > > > 
> > > > > As per RFC 5865, add "va" for VOICE-ADMIT with 0x2c value.
> > > > 
> > > > Quickly browsing, I don't find "va" nor 0x2c in this RFC above? Could
> > > > you refer to page?
> > > 
> > > As per my understanding it's page 11 ("2.3.  Recommendations on implementation of an Admitted Telephony Service Class") here:
> > > 
> > >       Name         Space    Reference
> > >       ---------    -------  ---------
> > >       VOICE-ADMIT  101100   [RFC5865]
> > > 
> > > Am I wrong?
> > 
> > Ok, hence the 'va'.
> 
> Yes.

OK.

> > > > > As per RFC 8622, add "le" for Lower-Effort with 0x01 value.
> > > > 
> > > > This RFC refers to replacing CS1 by LE
> > > > 
> > > >    o  This update to RFC 4594 removes the following entry from its
> > > >       Figure 4:
> > > > 
> > > >    |---------------+------+-------------------+---------+--------+----|
> > > >    | Low-Priority  | CS1  | Not applicable    | RFC3662 |  Rate  | Yes|
> > > >    |     Data      |      |                   |         |        |    |
> > > >     ------------------------------------------------------------------
> > > > 
> > > >       and replaces it with the following entry:
> > > > 
> > > >    |---------------+------+-------------------+----------+--------+----|
> > > >    | Low-Priority  | LE   | Not applicable    | RFC 8622 |  Rate  | Yes|
> > > >    |     Data      |      |                   |          |        |    |
> > > >     -------------------------------------------------------------------
> > > > 
> > > > 
> > > > static const struct symbol_table dscp_type_tbl = {
> > > >         .base           = BASE_HEXADECIMAL,
> > > >         .symbols        = {
> > > >                 [...]
> > > >                 SYMBOL("cs1",   0x08),
> > > >                 [...]
> > > >                 SYMBOL("le",    0x01),
> > > 
> > > I think we shouldn't remove existing symbol, should we? Please let
> > > me know if I missed any suggested action item for myself here.
> > 
> > Not removing. I mean, if I understood correctly, the RFC says LE == cs1 ?
> 
> To my understanding, no. The RFC talks about obsoleting:
> 
> "This specification obsoletes RFC 3662 and updates the DSCP recommended in RFCs 4594 and 8325 to use the DSCP assigned in this specification."
> 
> > But the values are different.
> 
> Yes, as a consequence of obsoleting, not replacing.

OK.

> > > > > tc-cake(8) in diffserv8 mode would benefit from having "le" alias since
> > > > > it corresponds to "Tin 0".
> > > > 
> > > > Aliasing is fine, let's just clarify this first.
> > > 
> > > I mean, "le" would be an alias to "0x01", not to "cs1".
> > > 
> > > BTW, the reason I included Loganaden Velvindron in Cc is that "le"
> > > was already added in the past, but got quickly reverted as it broke
> > > some tests. Shall "le" interfere with "less-equal", or what could be
> > > the issue with it? If the name is not acceptable, "lephb" or similar
> > > can be used instead.
> > 
> > Oh right, this is an issue for the parser, the 'le' keyword is an
> > alias of '<='.
> 
> OK, then another name should be found.
>
> > What does 'lephb' stands for BTW?
> 
> "LE PHB" originally, as described in the RFC, it's Lower-Effort Per-Hop Behavior.

Fine with me.