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

[Greg White <[e-mail]>]

Thanks Rüdiger, I appreciate the concrete feedback, and apologies that it has taken a few rounds to get this resolved.

I will add some text about interconnection and aggregation (SLAs/RFC4594/RFC5127/RFC8100) in the draft.  I don't have a strong opinion as to whether it is better to explicitly indicate that RFC 8100 is safe to ignore, or to describe the potential treatment.  My understanding is that an RFC8100 interconnection (absent a separate, non-RFC8100 arrangement/SLA) would bleach the NQB PHB.  I can certainly state that in the draft so it is clear.  Do you think there is another alternative that we could recommend?

I will also add some discussion of re-marking to a different DSCP in the non-pathological cases (e.g. a negotiated DSCP used in place of the IANA assigned one).   Currently I have this draft text in my local copy:

<t>The fact that this DSCP is intended for end-to-end usage does not preclude networks from mapping the NQB DSCP to some other value for internal usage, as long as the NQB DSCP is restored when forwarding to another network. Additionally, it is not precluded for interconnecting networks to negotiate (via an SLA or some other agreement) a different DSCP to use to signal NQB across the interconnect.</t>

Let me know if you have another suggestion for that.  (FYI the drafts deadline for IETF109 is less than 24 hrs away) 

-Greg



On 10/21/20, 4:17 AM, "[e-mail]" <[e-mail]> wrote:

    Hi Greg,

    [GW] 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.

    [RG] Draft nqb-02.txt ... [expects a proposed] DSCP.... to be used end-to-end across the Internet.
    The draft doesn't mention that an SLA should be in place at interconnection, nor that one should may have to be expected. It doesn't discuss the NQB PHB relation to other PHBs, specifically it does not clarify whether and how NQB relates to RFCs 4594, 5127 and 8100. Even if your view was "safe to ignore them", please express so explicitly. So far, only RFCs 4594 is mentioned by the draft (in a side note related to precedence compatibility), the other two are not referenced. Draft nqb doesn't discuss the relation of NQB PHB to existing PHBs, which are deployed as suggested by these documents (as mentioned, you may chose to ignore that, but then please do so explicitely). Please keep in mind, aggregating PHBs, as well as QoS at interconnection isn't greenfield. That should be reflected appropriately by any new PHB and the more so, if there's an expectation to maintain a DSCP end-to-end across domain boundaries. 

    I understand a desire to use a standardized DSCP for a PHB at the access. That doesn't require a standard cross domain end-to-end DSCP however, so I fail to look at this desire to justify end-to-end usage of a DSCP. 

    My interpretation of draft nqb is based on the text of that draft. That text, e.g, doesn't reflect that an SLA might be a good approach.

    Deutsche Telekom operates standard based interconnections as well as customized ones. Peering interfaces are mostly based on RFC 8100. VPNs obviously can be expected to offer customized QoS schemes, at least if it comes to codepoints. In addition, there's a public consumer-access-to-provider interface specification in Germany too, with to the extent that I recollect, Ethernet priority and DSCP determinations (the German Home Gateway market is liberalized, and if NQB sees widespread deployment, any available DSCP could be agreed for this interface). 

    Regards,

    Rüdiger



    -----Ursprüngliche Nachricht-----
    Von: Greg White <[e-mail]> 
    Gesendet: Montag, 19. Oktober 2020 22:34
    An: Geib, Rüdiger <[e-mail]>
    Cc: [e-mail]
    Betreff: Re: [tsvwg] I-D Action: draft-ietf-tsvwg-nqb-02.txt

    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/