Re: [tsvwg] draft-ietf-tsvwg-dscp-considerations-07.txt

[Gorry Fairhurst <[e-mail]>]

On 08/12/2022 20:08, Brian E Carpenter wrote:
> Ruediger,
>
> I disagree with a few of your comments, as noted below.

Brian, I hope the current editors copy for 08 will address this (see 
proposed text below).

> On 08-Dec-22 02:16, [e-mail] wrote:
>> Hi Ana, hi Gorry,
>>
>> it took me some time after meeting Gorry and a heads up by David to 
>> read and comment, I'm sorry. I've carefully read the entire doc and 
>> still found issues or would like to add text, marked [RG]:
>>
>> Regards,
>>
>> Ruediger
>>
>>
>>
>> 4.3.  Remarking to a Particular DSCP
>>
>> ....Both [RFC2474] and [RFC8100] recommend that DiffServ boundary nodes
>>     use remarking, if necessary, to avoid theft/denial of service or
>>     ensure that appropriate DSCPs are used within a DiffServ domain.
>>
>> [RG]: Please delete the sentence below. RFC2474 is not scoped
>> to specify DiffServ interconnection policies.
>
> I disagree. RFC2474 covers the issue of what happens at the boundary
> several times, e.g,:
>
> "  ... Operators may choose to use
>    different codepoints for a PHB, either in addition to or in place of
>    the recommended default.  Note that if operators do so choose, re-
>    marking of DS fields may be necessary at administrative boundaries
>    even if the same PHBs are implemented on both sides of the boundary.
>
>    See [ARCH] for further discussion of re-marking.
>    ...
>    ...  The
>    presumption is that DS domains protect themselves by deploying re-
>    marking boundary nodes, as should networks using the RFC 791
>    Precedence designations.
>    ...
>    A packet initially marked for the Default behavior MAY be re-marked
>    with another codepoint as it passes a boundary into a DS domain"
>
> And it does indeed say:
>
>    "Packets received with an unrecognized codepoint SHOULD be forwarded
>    as if they were marked for the Default behavior (see Sec. 4), and
>    their codepoints should not be changed.  Such packets MUST NOT cause
>    the network node to malfunction."
>
> So I think that the sentence you propose to delete is 100% accurate.
>
>
The text thge editors currently propose for 08 is:

Section 3 of <xref target="RFC2474"></xref> recommends:

     "Packets received with an unrecognized codepoint SHOULD be 
forwarded as if
     they were marked for the Default behavior, and their codepoints
     should not be changed."  Some networks might not follow this 
recommendation

     and instead remark packets with these codepoints to the default 
class, CS0 (0x00).

Should that be improved?

>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>     Some networks therefore may not follow the earlier recommendation in
>>     [RFC2474] to carry unknown or unexpected DSCPs without modification,
>>     and instead remark packets with these codepoints to the default
>>     class, CS0 (0x00).
>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>
>> #####################
>>
>>     Remarking is sometimes performed using a Multi-Field (MF) classifier
>>     [RFC2475] [RFC3290] [RFC4594].  For example, a common remarking 
>> is to
>>     remark all traffic to a single DSCP, thus removing any traffic
>>     differentiation (see Section 4.1).
>>
>> [RG] That depends on the DSCP the traffic is remarked to. To keep 
>> text in line with 4.2.2 I'd suggest:
>>
>>    "If remarking to a single DSCP occurs, packets are forwarded using 
>> the
>>     PHB specified for the resulting DSCP in that domain.  As an example,
>>     remarking traffic AF31, AF32 and AF33 all to a single DSCP AF11 
>> stops
>>     any drop probability differentiation, which may have been expressed
>>     by these three DSCPs. If such a remarked packet further traverses
>>     other domains, it would receive treatment as specified by the 
>> domain's operator corresponding
>>     to the remarked codepoint.
>>
>> #####################
>>
>> 5.  Interpretation of the IP DSCP at Lower Layers
>>
>> .....  In many cases, this use is constrained by designs that
>>     utilise fewer than 6 bits to express the service class, and 
>> therefore
>>     infer mapping to a smaller L2 QoS field, for example,
>>
>>    ([RG] please add ) Ethernet,
>>
>>     WiFi or Multi-
>>     Protocol Label Switching (MPLS).  A Treatment Aggregate (TA)
>>     [RFC5127] is an optional intermediary mapping groups of BAs to PHBs.
>>     #####################
>>
>> 5.1.2.  Mapping Specified for IEEE 802.11
>>
>>     Section 6 of [RFC8325] provides a brief overview of IEEE 802.11 QoS.
>>     The IEEE 802.11 standards [IEEE-802-11] provide MAC functions to
>>     support QoS in WLANs using Access Classes (AC).  The upstream User
>>     Priority (UP) in the 802.11 header has a 3-bit QoS value.  A DSCP 
>> can
>>     be mapped to the UP.
>>
>>     Most current WiFi implementations [RFC8325] use a default mapping
>>     that maps the first three bits of the DSCP to the 802.11 UP value.
>>
>> [RG] Please add:
>> This is an example of equipment still classifying on ToS Precedence 
>> (which may
>> be seen as a simple method to map IP layer DiffServ to layers 
>> offering 3-bit QoS
>> codepoints only.
>>     #####################
>>
>> 5.2.  DiffServ and MPLS
>>
>>     Multi-Protocol Label Switching (MPLS) specified eight MPLS Traffic
>>     Classes (TCs), which restrict the number of different treatments
>>     [RFC5129].  RFC 5127 describes aggregation of DiffServ TCs 
>> [RFC5127],
>>     and introduces four DiffServ Treatment Aggregates.  Traffic marked
>>     with multiple DSCPs can be forwarded in a single MPLS TC.
>>
>>     There are three Label-Switched Router (LSR) models: the Pipe, the
>>     Short Pipe and the Uniform Model [RFC3270].
>>       [RG] Please delete: These only differ when a
>>     LSP performs a push or a pop.
>>     [RG] Please add:
>>     With the Uniform and Pipe model, the egress MPLS router forwards
>>     traffic based on the received MPLS TC. The Uniform model includes
>>     an egress DSCP rewrite. With the Short Pipe model, the
>>     egress MPLS router forwards traffic based on the DiffServ DSCP
>>     as present at the egress router. If the domain supports IP and
>>     MPLS QoS differentiation, controlled behaviour requires the DSCP 
>> of an (outer)
>>     IP header to be assigned or re-written by all domain ingress routers
>>     to conform with the domain internal DiffServ deployment.
>>     Note that the short pipe model is prevalent in MPLS domains.
>>     #####################
>>
>> 6.  Considerations for DSCP Selection
>>
>>     This section provides advice for the assignment of a new DSCP value.
>>     It is intended to aid the IETF and IESG in considering a request for
>>     a new DSCP.  The section identifies known issues that might 
>> influence
>>     the finally assigned DSCP, and provides a summary of considerations
>>     for assignment of a new DSCP.
>>
>>   [RG]  Please add:
>>     Recall, that the treatment of packets marked by an unknown or an
>>     unexpected DSCP at DiffServ domain boundaries is a matter of
>>     administrative policy and outside the scope of [RFC2474]. Without 
>> a traffic
>>     conditioning agreement (TCA) specifying the treatment
>>     of marked packets between interconnecting parties at domain 
>> boundaries, a sender may not expect
>>     any specific treatment of marked packets within downstream 
>> domains. Marked packets may be forwarded unchanged,
>>     dropped or arbitrarily remarked according to the policies of the 
>> receiving domain.
>
> That contradicts RFC2474, which (see above extract) defines the 
> default remarking action as leaving an unrecognized DSCP untouched and 
> treating it as BE. So the user may *expect* that (and possibly be 
> disappointed). We can comment on this, but we can't change it without 
> an Updates: 2474.
>
We did not follow this particular text proposal, we think this topic was 
discussed in an earlier section (see above).
>>        #########################
>>
>> 6.1.  Effect of Bleaching and Remarking to a single DSCP
>>
>>     New DSCP assignments should consider the impact of bleaching
>>     (/Bleach/) or remarking (/Remark/) to a single DSCP, which can limit
>>     the ability to provide the expected treatment end-to-end. This is
>>     particularly important for cases where the codepoint is intended to
>>     result in lower than best effort treatment, as was the case when
>>     defining the LE PHB [RFC8622].  In this case, bleaching, or 
>> remarking
>>     to "CS0" would result in elevating the lower effort traffic (LE) to
>>     the default class (BE/CS0).
>>         [RG] Forwarding LE by default PHB is in line with RFC8622. 
>> Please
>>     replace the final 'inversion' statements of this section to:
>>
>>    [RG] Forwarding LE by default PHB is in line with RFC8622, but
>>     it is recommended to maintain the distinct LE DSCP codepoint
>>     end-to-end to allow for differentiated treatment by
>>     domains supporting LE. Rewriting the LE DSCP to default DSCP
>>     results in an undesired priority promotion for LE traffic in such 
>> a domain.
>>     Bleaching the lower three bits of the DSCP (/Bleach-low/
>>     and /Bleach-some-low/), as well well as  remarking to a particular
>>     DSCP can result in a similar priority promotion.
>>         ########################
>>       6.4.  Impact on deployed infrastructure
>>        Networks that condition the DSCP:  A network that implements more
>>        than one PHB and enforces SLAs with its peers.  Operators in this
>>        category use conditioning to ensure that only traffic that 
>> matches
>>        a policy is permitted to use a specific DSCP (see [RFC8100]).
>>        This requires operators to choose to support or remark a new DSCP
>>        assignment.
>>
>> [RG] I don't understand what is meant by "choose to support or remark 
>> a new DSCP assignment."
>>
>> [RG] Do you mean "to remark this traffic with codepoint
>>     values appropriate for the domain's deployed DiffServ 
>> infrastructure." ? If yes, please replace the sentence.
>>         #######################
>>         Same section
>>            The DSCP re-marking corresponding to the ToS Precedence 
>> Bleaching
>>     (/Bleach-ToS-Precedence/) observed behaviour described in section 4
>>     can arise for various reasons, one of which is old equipment which
>>     precedes DiffServ.  It can also arise when traffic conditioning is
>>     provided by DiffServ routers at operator boundaries, or as a result
>>     of misconfiguration.
>>        [RG] Please delete, as in all cases both, classification on 
>> and remarking
>>     to several (or single) DSCPs is conforming to the DiffServ 
>> architecture.
>
> I don't understand why that is a reason to delete a factual observation.
>
Agree - it was simply an observation that you can't externally tell why 
any pattern of remarking happens, it could be for many reasons. I think 
the editors were responsible for some ambiguity here, we propose 
slightly rewritten text for 08:

"The same remarking can also arise in some cases when traffic 
conditioning is
provided by DiffServ routers at operator boundaries, or as a result
of misconfiguration."

> Regards
>     Brian
>
best wishes,

Gorry & Ana.

>>         ############################
>>         6.5.  Considerations to guide the discussion of a proposed 
>> new DSCP
>>           *  Section 5.2 describes examples of treatment 
>> aggregation.  What are
>>        the effects of treatment aggregation on the proposed DSCP?
>>
>>     *  Section 5 describes some observed treatments by layers below IP.
>>        What are the implications of the treatments and mapping described
>>        in Section 5 on the proposed DSCP?
>>
>> [RG] Please add:
>>      * Treatment aggregation by classification on ranges of DSCPs is 
>> a common
>>     deployment method simplifying configuration and increasing
>>     comprehensibilty of forwarding differentiaton.
>>
>> *  Provider service paths may consist of sections where multiple and
>>     changing layers determine forwarding by own code points determining
>>     differentiated forwarding (e.g., IP - MPLS - IP - Ethernet - WiFi).
>>     * With the DiffServ architecture as specified and operated as is,
>>    packets may not be expected to reach a destination by the same 
>> DSCP as
>>    has been set by the sender, if one or more service provider
>>    interconnections have to be passed by the traffic.
>>
>> [RG] Could you kindly add some info on the representativeness of your
>> data by an own bullet point, to help indicating some likeliness for a 
>> remark?
>> How many commercial backbone operator networks have been tested
>> and which percentage operated one of the above mentioned re-marking 
>> schemes?