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

From: [email-masked]
Date: Tue, 22 Sep 2020 10:07:11 -0700

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: Greg White <[email-masked]>
Date: Tue, 22 Sep 2020 17:23:51 +0000

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:

    
    Abstract:

---

From: Greg White <[email-masked]>
Date: Wed, 23 Sep 2020 23:29:31 +0000

.... 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,

    Specifically:

    Best Regards,
    Greg

        
        
        Abstract:

---

From: <[email-masked]>
Date: Thu, 24 Sep 2020 07:16:17 +0000

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

-Greg

    All,

    Specifically:

    Best Regards,
    Greg

        
        
        Abstract: