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

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

You raised this issue before, and it has already been addressed in the current draft.

-Greg

On 11/2/20, 1:06 AM, "Sebastian Moeller" <[email-masked]> wrote:

    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]>
    > Betreff: Re: [tsvwg] I-D Action: draft-ietf-tsvwg-nqb-02.txt
    >
    > 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: Sebastian Moeller <[email-masked]>
Date: Tue, 03 Nov 2020 05:50:03 +0100

Hi Greg,

The draft still offers no solution at all for the most common case at the start of using NQB, the situation where there is no NQB aware wifi AP AND also no benevolent ISP that can remap NQB to DSCP 0. As written NQB still requires an active opt-out, and that requires at least one agent on the path that remaps dscp 42 which simply is not guaranteed. If I might be blunt, safety through accidental chance is not a convincing concept. Especially in the light that this draft also encourages networks to pass this DSCP end to end. I realize that we talked about that, but in my understanding "addressing" an issue means finding an agreeable solution to it, and under that definition this issue has not been addressed. The issue is not even explicitly mentioned in draft as being a potential problem.

Best Regards
        Sebastian

On 2 November 2020 23:29:34 CET, Greg White <[email-masked]> wrote:
>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.
>
>> 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
>    > 
>    > 
>    > 
>>     [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.
>    > 
>>     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
>    > 
>    > 
>    > 
>>     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
>    > 
>    > 
>    > 
>>         https://mailarchive.ietf.org/arch/browse/tsvwg/?q=nqb&so=frm 
>and 
>https://mailarchive.ietf.org/arch/msg/tsvwg/Pk4nBgUP-9B1I4s0biOIIsv-Alc/
>    > 
>>         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
>    > 
>    > 
>    > 
>>         .... 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:
>>             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:
>    > 
>    > 
>>                         Title           : A Non-Queue-Building
>Per-Hop Behavior (NQB PHB) for Differentiated Services
>    >                         Authors         : Greg White
>    >                                           Thomas Fossati

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.