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

From: Greg White <[email-masked]>
Date: Mon, 2 Nov 2020 04:28:40 +0000

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, "[email-masked]" <[email-masked]> 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 <[email-masked]> 
    Gesendet: Montag, 19. Oktober 2020 22:34
    An: Geib, Rüdiger <[email-masked]>
    Cc: [email-masked]
    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, "[email-masked]" <[email-masked]> 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 <[email-masked]> Im Auftrag von Greg White
        Gesendet: Donnerstag, 24. September 2020 01:30
        An: [email-masked]
        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" <[email-masked] on behalf of [email-masked]> 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 [email-masked]" <[email-masked] on behalf of [email-masked]> 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/

---

From: <[email-masked]>
Date: Mon, 2 Nov 2020 07:07:29 +0000

Hi Greg,

RFC8100 suggests to map DSCPs on an interconnection interface to values which can be treated as an aggregate. If NQB is not supposed to be policed, a DSCP 101xxx is a bad choice at interconnection from my point of view. Options to me are
- either accept policing and rather low an aggregated bandwidth at interconnection, if DSCP 101xxx is to be kept at interconnection and an SLA is present
- or map to a DSCP with guaranteed QoS but some more bandwidth (and policing...you don't get around it I think) at interconnection and an SLA is present
- or map to a non-ambiguous DSCP 000xyz at interconnection without an SLA and without policing (will not reach access with that value in all cases, but raises chances)
- or accept re-marking to the value described in the draft if no SLA is in place and RFC8100 is not applied.

I'm not aware of a backbone network supporting more than 4 PHBs (but I don't know all concepts). As described by RFC 8100, a network provider operating an MPLS backbone likely isn't liberal in the set and values of forwarded DSCPs. 

Regards,

Rüdiger

-----Ursprüngliche Nachricht-----
Von: Greg White <[email-masked]> 
Gesendet: Montag, 2. November 2020 05:29
An: Geib, Rüdiger <[email-masked]>
Cc: [email-masked]
Betreff: Re: [tsvwg] I-D Action: draft-ietf-tsvwg-nqb-02.txt

-Greg

    Hi Greg,

    Regards,

    Rüdiger

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

    Hi Rüdiger,

    -Greg

        Hi Greg,

        See

        Regards,

        Rüdiger

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

        -Greg

            All,

            Specifically:

            Best Regards,
            Greg

                Abstract:

---

From: Sebastian Moeller <[email-masked]>
Date: Mon, 2 Nov 2020 09:05:56 +0100

Hi Greg,

especially with your drive of making NQB survive internet passage end-to-end the choice of aDSCP that maps to anything but AC_BE is something I consider a critical design flaw of the NQB draft. IMHO anthing higher than the default AC_BE MUST be active opt-in by the end-user, as it is the end-users (and the neihgors) resource, preferential access to air-time that is affected.
All the arguments about a benevolent ISP being in control and taking care that nothing bad happens become irrelevant once you set-up NQB to have potentially severe side-effects unless reigned-in. IMHO you absolutely need to make sure that ACs > AC_BE are only assigned with the users/wifi network operators consent. For your major use-case, I assume DOCSIS ISPs, this will be possible independent on the DSCP value of NQB. I have voiced that objection before, but I am not convinced that there are sufficient measures described to avoid unintended side-effects in likely scenarios without a controlling entity that avoids NQB taking too much air-time. I do not see how this can be fixed other than selecting a DSCP belonging to the CS0 group, but I am open to alternatives, doing nothing and just hoping that nothing bad is going to happen does not strike me as the optimal path forward.

Best Regards
        Sebastian

P.S.: Top posted, because only marginally connected to Ruediger's point, in that for different reaons we recommend a DSCP in the 000xxx range.

> Gesendet: Montag, 02. November 2020 um 05:28 Uhr
> Von: "Greg White" <[email-masked]>
> An: "[email-masked]" <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>

---

From: Greg White <[email-masked]>
Date: Mon, 2 Nov 2020 18:06:29 +0000

Hi Rüdiger,

What you are describing below doesn't match my read of RFC8100. Are you describing local policy decisions beyond what is documented in the RFC?  If that is the case, then this is best sorted out via an SLA between the interconnecting partners, where local interconnection policies can be taken into account. In fact, RFC8100 itself leaves this up to negotiation between the two partners already.  If you agree, I'll leave the discussion and recommendations around interaction with RFC8100 and interconnections fairly light.  

Here is what I plan to include:
"Note: Unless agreed otherwise between the interconnecting partners, interconnects that implement [RFC8100] for DiffServ interconnection would consider the NQB DSCP as an unrecognized or unsupported DSCP, and would thus re-mark it to CS0."
  
Would you like to see something different there?  While it may make sense in some cases, I don't think we can recommend mapping to 000xyz on these interconnections, since RFC8100 makes no mention of special treatment for those values (aside from CS0).

In the future, it would always be possible to update RFC8100 if there is more specific guidance that the IETF could/should make in order to facilitate interconnection of NQB traffic.  

Does this sound good?

-Greg

On 11/2/20, 12:07 AM, "[email-masked]" <[email-masked]> wrote:

    Hi Greg,

    Regards,

    Rüdiger

    -----Ursprüngliche Nachricht-----
    Von: Greg White <[email-masked]> 
    Gesendet: Montag, 2. November 2020 05:29
    An: Geib, Rüdiger <[email-masked]>
    Cc: [email-masked]
    Betreff: Re: [tsvwg] I-D Action: draft-ietf-tsvwg-nqb-02.txt

    -Greg

        Hi Greg,

        Regards,

        Rüdiger

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

        Hi Rüdiger,

        -Greg

            Hi Greg,

            See

            Regards,

            Rüdiger

            -----Ursprüngliche Nachricht-----

            -Greg

                All,

                Specifically:

                Best Regards,
                Greg

                    Abstract:

---

From: <[email-masked]>
Date: Tue, 3 Nov 2020 11:13:05 +0000

Hi Greg,

to me it's alright to state that you do not recommend anything in the draft if an SLA is present in the case of RFC8100 interconnection. You've added text describing behavior following RFC8100 in the absence of an SLA and that’s alright. RFC8100 is supposed to be extended especially by commodity PHBs (and DSCPs) which are forwarded by a set of usually 2-4 Treatment Aggregates at interconnections. 

To be honest, I also can't understand why network control and the other real-time traffic would be assigned to NQB or transported by the same Treatment Aggregate. Most of this traffic is priority queued in some or all parts of a provider network and faces policies limiting access to the PHB. If NQB allows simple validation qualifying  the traffic marked for the PHB, please specify that in the draft. The method should scale well also for interconnections (up to n*100 Gbit/s by today). This must be clarified.

Regards, 

Rüdiger

-----Ursprüngliche Nachricht-----
Von: Greg White <[email-masked]> 
Gesendet: Montag, 2. November 2020 19:06
An: Geib, Rüdiger <[email-masked]>
Cc: [email-masked]
Betreff: Re: [tsvwg] I-D Action: draft-ietf-tsvwg-nqb-02.txt

Hi Rüdiger,

  

Does this sound good?

-Greg

    Hi Greg,

    Regards,

    Rüdiger

    -----Ursprüngliche Nachricht-----
    Von: Greg White <[email-masked]> 
    Gesendet: Montag, 2. November 2020 05:29
    An: Geib, Rüdiger <[email-masked]>
    Cc: [email-masked]
    Betreff: Re: [tsvwg] I-D Action: draft-ietf-tsvwg-nqb-02.txt

    -Greg

        Hi Greg,

        Regards,

        Rüdiger

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

        Hi Rüdiger,

        -Greg

            Hi Greg,

            See

            Regards,

            Rüdiger

            -----Ursprüngliche Nachricht-----

            -Greg

                All,

                Specifically:

                Best Regards,
                Greg

                    Abstract: