Re: [tsvwg] I-D Action: draft-ietf-tsvwg-nqb-02.txt

[Greg White <[e-mail]>]

Hi Rüdiger,

When we discussed this concern before, it seemed to me that an SLA might be a good approach (at least in the near term).  So, perhaps we aren’t communicating well.  It is possible that a peering network is already using the value 42 (0b101010) - or for that matter any DSCP that IANA might assign for NQB - in a manner that is inconsistent with NQB, so default bleaching is probably the best near term situation.  For an ISP that wishes to support the NQB PHB, they can validate (and set up SLAs) that identify the NQB traffic from a peer, and treat it per the PHB, whichever DSCP is chosen.  Alternatively, if the ISP does not wish to support the NQB PHB at all, then they can choose to bleach it to Default, or pass it though with Default treatment, whichever they choose.

But, for end-systems, it is important that a single DSCP is assigned, and for that value to be one that provides benefit from the beginning.  In this case, aligning with the default QoS mapping in WiFi to allow traffic that already wishes to be treated separately from bulk TCP traffic to use a standardized DSCP that additionally enables it to get NQB treatment in other parts of the network.  I think it is unlikely that such applications would wish to give up WiFi QoS for the potential of NQB treatment elsewhere in the network.

Perhaps I'm still misunderstanding your concern, so if the above doesn't seem to address it, can you please try once again?  In particular, your final sentence is a bit confusing to me.  The design of the PHB is that an application should be free to choose between NQB and BE, and that there should be a downside to selecting NQB if the traffic is non-conformant.  The PHB recommends a policing mechanism at the PHB node as a means of enforcing that downside, but allows that there may be other mechanisms as well (e.g. policing at the edge).  Also, cloud gaming to me seems to be a better example for L4S than NQB, since it is a high data-rate, rate-adaptive application, but if it can comply with the description in the NQB PHB without using L4S, then it should be ok for that traffic to be marked with the NQB DSCP.

I've discussed your concern with other large network operators (in some cases, sharing your email directly), and have yet to hear the same concern being raised.

-Greg



On 9/24/20, 1:16 AM, "[e-mail]" <[e-mail]> wrote:

    Hi Greg,

    See

    https://mailarchive.ietf.org/arch/browse/tsvwg/?q=nqb&so=frm  and  https://mailarchive.ietf.org/arch/msg/tsvwg/Pk4nBgUP-9B1I4s0biOIIsv-Alc/

    The draft as is may work within a single domain, if a DSCP 101xxx is to be preserved, I think. 

    If you are interested in traffic marked 101xxx to enter a domain and experience differentiated PHBs, I'd expect it to be policed or remarked. If you prefer marked traffic not to be policed and not to experience a rewrite at inerconnection, try 000xxx. I'm unwilling to worry about the meaning of this and that DSCP which is received at a peering router by one or another peer. The market here is regulated and operational deployments can't discriminate peers (so no peer or all peers will be able to send NQB traffic without an SLA and expect it not be remarked, practically meaning "no", if its marked 101xxx).  Tell cloud gaming providers that traffic marked NQB has a fair change to see no queue without incurring extra charges and no negative consequences, if that traffic isn't confirming to the PHB description and I think I know what they will do.

    Regards,

    Rüdiger



    -----Ursprüngliche Nachricht-----
    Von: tsvwg <[e-mail]> Im Auftrag von Greg White
    Gesendet: Donnerstag, 24. September 2020 01:30
    An: [e-mail]
    Betreff: Re: [tsvwg] I-D Action: draft-ietf-tsvwg-nqb-02.txt

    .... Also in this update, I've listed the DSCP 42 as *the* chosen value.  This value has been discussed at several IETFs now and early on was debated a bit.  I've not heard any opposition to the selection of that value since.  I'd like to see if there is WG consensus for us to finalize that codepoint decision.

    -Greg

    On 9/22/20, 11:24 AM, "tsvwg on behalf of Greg White" <[e-mail] on behalf of [e-mail]> wrote:

        All,

        My co-author and I have just posted an updated NQB draft that addresses many of the issues that had been identified previously.

        Specifically:
        - adds a discussion of interaction with DSCP remarking pathologies
        - adds more text to describe what happens if the SHOULDs are not followed
        - adds a requirement related to configuration of classifiers
        - adds a section on impact to higher layer protocols
        - adds a section on configuration and management
        - adds a paragraph in the security considerations section about maliciously mismarked traffic
        - other minor editorial changes.

        One of the guidelines from RFC2475 that has not been complied with (yet) is "G.7:  A PHB group specification should include a section defining the implications of tunneling on the utility of the PHB group."  I would appreciate comments from the WG on useful items to discuss in such a section if it were to be included, the utility of including such a section, and even proposed text if anyone is willing to offer it.

        Best Regards,
        Greg



        On 9/22/20, 11:07 AM, "tsvwg on behalf of [e-mail]" <[e-mail] on behalf of [e-mail]> wrote:


            A New Internet-Draft is available from the on-line Internet-Drafts directories.
            This draft is a work item of the Transport Area Working Group WG of the IETF.

                    Title           : A Non-Queue-Building Per-Hop Behavior (NQB PHB) for Differentiated Services
                    Authors         : Greg White
                                      Thomas Fossati
            	Filename        : draft-ietf-tsvwg-nqb-02.txt
            	Pages           : 13
            	Date            : 2020-09-22

            Abstract:
               This document specifies properties and characteristics of a Non-
               Queue-Building Per-Hop Behavior (NQB PHB).  The purpose of this NQB
               PHB is to provide a separate queue that enables low latency and, when
               possible, low loss for application-limited traffic flows that would
               ordinarily share a queue with capacity-seeking traffic.  This PHB is
               implemented without prioritization and without rate policing, making
               it suitable for environments where the use of either these features
               may be restricted.  The NQB PHB has been developed primarily for use
               by access network segments, where queuing delays and queuing loss
               caused by Queue-Building protocols are manifested, but its use is not
               limited to such segments.  In particular, applications to cable
               broadband links and mobile network radio and core segments are
               discussed.  This document defines a standard Differentiated Services
               Code Point (DSCP) to identify Non-Queue-Building flows.


            The IETF datatracker status page for this draft is:
            https://datatracker.ietf.org/doc/draft-ietf-tsvwg-nqb/

            There are also htmlized versions available at:
            https://tools.ietf.org/html/draft-ietf-tsvwg-nqb-02
            https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-nqb-02

            A diff from the previous version is available at:
            https://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-nqb-02


            Please note that it may take a couple of minutes from the time of submission
            until the htmlized version and diff are available at tools.ietf.org.

            Internet-Drafts are also available by anonymous FTP at:
            ftp://ftp.ietf.org/internet-drafts/