Re: [tsvwg] Some comments on NQB (part 2)

[Greg White <[e-mail]>]

Hi Ruediger,  

Thanks for responding.   See my responses [GW] below.

-Greg


On 4/26/22, 8:14 AM, "[e-mail]" <[e-mail]> wrote:

    Greg,

    Sorry for the late response.

    <snip>

    You wrote:
    What I offered for consideration below was that the [DSCP] value 45 be recommended across interconnections in cases where the two interconnecting partners are NQB-aware and they negotiate DSCP markings.

    RG: To me, that's an additional concept. My take was, NQB doesn't require more than default transport in the backbone and at interconnection. If the later holds, negotiation of NQB is no issue to me, but an appropriately picked DSCP is important (it should unambiguously indicate "default forwarding" at interconnection).
    If a QoS SLA is negotiated, in principle any negotiated DSCP does (it is well known that I prefer RFC 8100 at wholesale and interconnection interfaces, as this simplifies deployment and operation).

[GW] It seems to me that there isn't such a thing as a DSCP (other than possibly 0) that unambiguously indicates default forwarding at interconnection.  I quickly re-read RFC8100 and also don't see mention of it there (it refers to DSCP=0 as being default and seems to recommend that any traffic classified into the Default / Elastic Treatment Aggregate be re-marked to 0). As I understand it, the practice of aggregating traffic based on the IPP bits (top 3 bits) is not universal. If I'm right in that, then it seems that recommending NQB-aware networks re-mark NQB traffic to 5 and not use 45 at *all* interconnections might be unnecessary (and it was apparently concerning to some).  
In my post on April 4: https://mailarchive.ietf.org/arch/msg/tsvwg/PKTrfNdTCEXmwoovSkqec6cOJZc/ in response to Gorry's concerns, I had suggested softening this to (paraphrasing here):
- If negotiating a DSCP to use at interconnection, recommend 45, but the parties can negotiate whichever value they want.
- If negotiation isn't possible, the sending network SHOULD NOT use 45, and instead SHOULD use 5. 
What about this do you not like?  It seems to me that you're saying that you wouldn't negotiate a DSCP for NQB.  So, based on the proposed text, your interconnection partners SHOULD use 5. 
Would it make you happier if the first statement were replaced with:
- If negotiating a DSCP to use at interconnection, recommend the use of either 5 or 45, but the parties can negotiate whichever value they want.


 
    You wrote:
    The data from Ana Custura and Gorry indicates that, unless something changes in regards to bleaching of the upper 3 bits by some networks, any future assignments of the values 13, 21, 29, 37, 53, 61 would do well to keep in mind that any traffic so marked could end up being aggregated with NQB traffic.  That said, this sort of bleaching is non-compliant with the definition of the DSCP field, and is already problematic for EF, VA, and all of the CS codepoints (which aggregate in incompatible ways), so (as was commented in the last meeting) we may want to consider identifying the routers that continue to do this, and try to work with the associated network operators to change the behavior. 

    RG: I'd appreciate a concise reference for your claim "this sort of bleaching is non-compliant with the definition of the DSCP field".

[GW] I probably didn't choose my words as carefully as I could have, and I made that statement (without doing the appropriate research) based on comments others had made.  RFC2474 Section 3 seems to imply to me that selectively bleaching certain bits of the field is not what was intended, but it does allow that "Nodes MAY rewrite the DS field as needed to provide a desired local or end-to-end service."  So, I don’t see any requirement statement that is violated. 


    RG: If you are interested, I can sketch examples where single sided changes were made to well  negotiated EF deployments and the interesting consequences caused by that. That's not what mean by "problematic for EF", it rather shows what happens if a QoS design isn't well agreed with all parties responsible for QoS aware network sections and policy points in an operational end-to-end production chain.

    Regards,

    Ruediger