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

[Brian E Carpenter <[e-mail]>]

On 12-Dec-22 21:35, [e-mail] wrote:
> Hi Brian,
> 
> thanks for clarification...I'd like to make sure, I understand you correctly
> 
> My take on your response is:
> - (intent of RFC2474: a domain with no DiffServ or ToS support) should comply to the default set by RFC2474, which accept all set DSCPs, don't remark and forward by default PHB.
> - the traffic conditioning configured for boundary nodes (of a DiffServ compliant domain) is out of scope of RFC2474.

I would prefer to say that it's undefined in RFC2474, but yes. I believe that when defining it for a particular secanrio, it's useful to state that this replaces the default setting.

    Brian

> 
> Please confirm or correct my above interpretation.
> 
> In addition, I think that RFC2575 confirms my interpretation.
> 
> https://datatracker.ietf.org/doc/html/rfc2475#section-2-3 (repeating the "DiffServ boundary conditioning out of scope" statement of RFC 2474)
> 
> https://datatracker.ietf.org/doc/html/rfc2475#section-2-3-4-2 (which is rather functional, but re-marking is mentioned as a minimum boundary node function, even if a TCA applies)
> 
> https://datatracker.ietf.org/doc/html/rfc2475#section-6-1
> 
> To add, the Deutsche Telekom IP and MPLS network section which is engineered and operated from Germany is and has been deploying DiffServ for almost 20 years by now. We also operate a set of DiffServ interconnections.
> 
> Regards,
> 
> Ruediger
> 
> 
> -----Ursprüngliche Nachricht-----
> Von: Brian E Carpenter <[e-mail]>
> Gesendet: Freitag, 9. Dezember 2022 21:04
> An: Geib, Rüdiger <[e-mail]>
> Cc: [e-mail]; [e-mail]
> Betreff: Re: AW: [tsvwg] draft-ietf-tsvwg-dscp-considerations-07.txt
> 
> Ruediger,
> On 09-Dec-22 23:14, [e-mail] wrote:
>> Hi Brian,
>>
>> as I've responded to David's email regarding the "factual observation", I think that's settled.
>>
>> Your comment addresses RFC2474. You and I disagree on the scope of RFC 2474.
>>
>> https://datatracker.ietf.org/doc/html/rfc2474#section-1
>>
>> [RG] Final section:
>>
>>     The classifiers and traffic conditioners at DS
>>      boundaries are configured in accordance with some service
>>      specification, a matter of administrative policy outside the scope of
>>      this document.
>>
>> [RG] I take that as a clear statement, saying "classifiers and traffic conditioners at DS
>>      boundaries are .... a matter of administrative policy outside the scope of  [RFC2474]."
> 
> Yes, the issue is that RFC2474 does imply a *default* policy of not remarking an unrecognized DSCP and treating it as BE. I think the authors' proposed change clarifies that point.
> 
> I also think that this text was intended to describe the behaviour of a domain with no diffserv or ToS support whatever, which was most of the Internet in 1998.
> 
>>
>> [RG] If my trouble is caused by not being a native speaker, please
>> excuse. I'm aware that the RFC2474 statement you quote caused discussions like ours in the past.
>> It resulted in a separate clarification section in (informative)
>>    https://datatracker.ietf.org/doc/html/rfc3260#section-6 . The
>> community still waits for the clarification announced there.
> 
> Ah, yes, RFC 3260. I think that it was perhaps a misjudgment by the diffserv WG chairs to declare rough consensus on that draft. No disrespect to its author, but it was written at a late stage in the WG when energy was low and the chairs and Area Director wanted nothing more than closing the WG.
> 
> (For those who don't know it, the chairs with Kathy Nichols and myself.)
> 
> You are correct, the language in RFC 2474 is imprecise. But RFC 3260 claims to update RFC 2474, which as an Informational document it has no right to do, so that is another bug.
> 
>       Brian
> 
>>
>> Regards,
>>
>> Ruediger
>>
>>
>> -----Ursprüngliche Nachricht-----
>> Von: Brian E Carpenter <[e-mail]>
>> Gesendet: Donnerstag, 8. Dezember 2022 21:08
>> An: Geib, Rüdiger <[e-mail]>; [e-mail];
>> [e-mail]
>> Cc: [e-mail]; [e-mail]
>> Betreff: Re: [tsvwg] draft-ietf-tsvwg-dscp-considerations-07.txt
>>
>> Ruediger,
>>
>> I disagree with a few of your comments, as noted 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.
>>
>>
>>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>>       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.
>>
>>>       
>>>      #########################
>>>
>>> 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.
>>
>> Regards
>>        Brian
>>
>>>       
>>>       ############################
>>>       
>>>       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?