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

[Pablo Neira Ayuso <pablo@netfilter.org>]

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.