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

[Greg White <[e-mail]>]

Gorry, 

See my responses to a couple of your points below [GW].

-Greg
 

On 4/29/22, 9:48 PM, "Gorry Fairhurst" <[e-mail]> wrote:

    CableLabs WARNING: The sender of this email could not be validated and may not match the person in the "From" field.

    On 29/04/2022 20:34, Greg White wrote:
    > Thanks Ruediger.
    >
    > Glad to hear that we are converging, though it wasn't clear to me which version of the new text you preferred.  For now, I'll stick with the version that I'd sent on April 4, but let me know if I've misunderstood you.
    > Hopefully others find this text change acceptable.
    >
    > N.B. I don't have any issue with your bigger picture idea, but it is beyond the scope of the NQB draft.   So, if you want to pursue documenting it in an RFC, it probably should be proposed separately.
    >
    > So, for the NQB draft, are folks ok with replacing:
    >
    > To support NQB, networks MUST preserve a DSCP marking distinction between NQB traffic and Default traffic when forwarding via an interconnect from or to another network.
    > To facilitate the default treatment of NQB traffic in backbones and core networks discussed in the previous section (where IP Precedence may be deployed), networks that support NQB SHOULD NOT use the value 45 for NQB at network interconnects unless that usage is explicitly documented in the TCA (Traffic Conditioning Agreement, see [RFC2475]) for that interconnection.
    > Rather, networks SHOULD remap NQB traffic to DSCP 5 prior to interconnection, unless agreed otherwise between the interconnecting partners.
    > To be clear, interconnecting networks are not precluded from negotiating (via an SLA, TCA, or some other agreement) a different DSCP to use to signal NQB across an interconnect.
    > Additionally, the fact that this PHB is intended for end-to-end usage does not preclude networks from mapping the NQB DSCP to a value other than 45 or 5 for internal usage, as long as the appropriate NQB DSCP is restored when forwarding to another network.
    >
    >
    > With [notes in square brackets added to help those trying to compare against the above]:
    >
    > To support NQB, networks MUST preserve a DSCP marking distinction between NQB traffic and Default traffic when forwarding via an interconnect from or to another network.    [no change]
    > Networks that support NQB SHOULD support the ability to re-mark NQB traffic prior to such an interconnection.    [new recommendation]

    GF: I think "networks that support" is slightly awkard for me. Does this actually mean "support the PHB"?
    (if not, can we understand if we can differentiate "carry traffic marked with an NQB DSCP"... To me, ""support the PHB" is something I would configure with respect to an SLA, whereas "carry traffic marked with an NQB DSCP" is something which I could do without configuring, e.g. forward the DSCP using the "default PHB").

[GW]: Hmm.  I think that recommendation is conditional on more than just carrying traffic marked with an NQB DSCP (since a network could do that inadvertently), but it isn't necessarily contingent on implementing the PHB.   I was trying to make it conditional on the intention of the network to enable NQB to work end-to-end. In other words, if a network operator is reading this document and thinking "NQB sounds useful, I'd like to do my part to making it work, what do I need to do?", these statements would apply.   So, the first requirement is that you've got to ensure that you maintain a DSCP marking distinction within your network.  Then the subsequent recommendations and requirements follow.  I suppose it could just be implicit that all requirement statements in the document only apply to those interested in implementing them.  In that case the second sentence could be: "Networks SHOULD support the ability ...."  Thoughts?


    > It is RECOMMENDED that interconnecting networks negotiate the use of the DSCP value 45 to indicate NQB traffic across their interconnections (thus avoiding the need to re-mark traffic), however, local DSCP usage by either network could require the use of a different value.   [new recommendation]
    > To be clear, interconnecting networks are not precluded from negotiating (via an SLA, TCA, or some other agreement) a different DSCP than 45 to use to mark NQB traffic across an interconnect.  [only editorial change]
    > In situations where negotiation of a DSCP between interconnection partners is infeasible, networks that support NQB SHOULD NOT use the value 45 for NQB at network interconnects, but rather SHOULD re-mark NQB traffic to DSCP 5 prior to interconnection.  [limited the applicability of this recommendation]

    GF: For me, I don't read the above sentence as being quite what I had
    hoped ... As above, I think there may be a distinction between an
    interconnection that *negotiates* a DSCP usage (and likely deploys a PHB
    mapping), and one that does not. I suspect many current networks/routers
    *do not* negotiate the usage of DSCPs for traffic. So I wonder whether
    we will need to split the advice two-ways:

    - I see the case as mentioned that likely applies to ISPs who think
    decide to enforce a SLA:  "negotiation to use DSCP 45 between
    interconnection partners is infeasible" -> which I would see as a good
    to recommend  "SHOULD NOT use the value 45 for NQB at network
    interconnects, but rather SHOULD re-mark NQB traffic to DSCP 5 prior to
    interconnection"

    - However, I also would like clarity for the case where there is no
    specific negoiation SLA, then I think the traffic SHOULD use DSCP 45,
    and ought to then pass this codepoint unmodified through this diffserv
    domain. My rationale is that we ought to avoid adding a remarking
    behaviour for routers that could transparently forward the traffic.


[GW]  For a transit network, the value 5 could be used to transparently forward traffic without re-marking.  I guess the concern is around an edge network (where NQB-45 marked traffic originates and/or where traffic will cross a Wi-Fi link) that wishes to "support" (in the sense I described above) NQB.  In that case is it onerous to require that the operator have the ability to do re-marking, and that they actually do it if their interconnection partner can't (for one reason or another) accept 45 as NQB?  The re-marking could be performed at the edge of the network (e.g. in the Wi-Fi gear itself or in Access Network gear) if it is important for core network routers to be able to transparently forward DSCPs.





    > This is intended to facilitate the default treatment of NQB traffic in backbones and core networks discussed in the previous section (where it is possible that IP Precedence may still be deployed).  [only editorial change]
    GF: "may still be deployed" seems to miss an opportunity to also add "is
    deprecated" - which I think we should.

[GW] I don't personally have a real problem with that, but based on Ruediger's comments, it sounds like it could be difficult to get consensus on adding it. So, if it isn't important for understanding NQB (and I think it isn't) perhaps it isn't needed here?





    > Additionally, the fact that this PHB is intended for end-to-end usage does not preclude networks from mapping the NQB DSCP to a value other than 45 or 5 for internal usage, as long as the appropriate NQB DSCP is restored when forwarding to another network.  [no change]
    >
    > In addition to Ruediger, I'd like to specifically hear from David Black and Gorry, since two of the original sentences came from David, and Gorry was the OP raising a concern about those sentences.
    >
    >
    > -Greg
    >
    The discussion looks really close on this point, I hope this helps,

    Gorry
   
 
   > {snip}