A Non-Queue-Building Per-Hop Behavior (NQB PHB) for Differentiated Services
draft-ietf-tsvwg-nqb-33

Hi Greg, Thomas, and Ruediger,

Thank you for the effort put into this interesting piece of work. I strongly support the direction of this work.

Thanks to Giuseppe Fioccola for the OPSDIR review and to Greg for engaging and structuring “Operational Considerations” content.

Please find below some comments, fwiw:

# Other SDOs

The document cites many SDOs and includes a discussion about how the mapping is supposed to be undertaken for technologies not owned by the IETF. I wonder whether LSes were sent to these SDOs to seek for their review of these parts? 

If not done, I suggest we do so.

# (abstract) NQ or NQB?

OLD:
   In particular, the
   application of NQ PHB to cable broadband links, Wi-Fi links, and
                  ^^^^^^
   mobile network radio and core segments are discussed.  

NEW:
   In particular, the
   application of NQB PHB to cable broadband links, Wi-Fi links, and
   mobile network radio and core segments are discussed.  

# Terminology

We do say the following in the introduction:

   This document defines a Differentiated Services per-hop behavior
   (PHB) called the "Non-Queue-Building Per-Hop Behavior" (NQB PHB),
   which isolates traffic microflows (application-to-application flows,
   see [RFC2475]) that are relatively low data rate and that do not

I think that it is better to cite rfc2475#section-1.2.

As a general note, consider pointing readers to that terminology list.

# Applicable to access network, but not only

I suggest to make the following change to not exclude other segments where bottleneck may be experienced as well (interco, for example).

OLD:
   In contrast to applications that frequently cause queuing delay,
   there are a variety of relatively low data rate applications that do
   not materially contribute to queuing delay and loss but are
   nonetheless subjected to it by sharing the same bottleneck link in
   the access network.

NEW:
   In contrast to applications that frequently cause queuing delay,
   there are a variety of relatively low data rate applications that do
   not materially contribute to queuing delay and loss but are
   nonetheless subjected to it by sharing the same bottleneck link in
   the access network, in particular.  
  
# Applicability

CURRENT:
   This PHB is designed
   for broadband access network links, where there is minimal
   aggregation of traffic, and especially when buffers are deep.  

Please point to Section 3.4 where applicability is discussed with more details.

# NQB DSCP

CURRENT:
   To be clear, a network implementing the NQB PHB solely provides
   isolation for traffic classified as behaving in conformance with the
   NQB DSCP.  

Not introduced yet. Maybe add a pointer to the section that defines that DSCP?
	
# Regulation

CURRENT:
   Finally, some jurisdictions impose regulations that limit the ability
   of networks to provide differentiation of services, in large part
   this seems to be based on the belief that doing so necessarily
   involves prioritization or privileged access to network capacity, and
   thus a benefit to one class of traffic always comes at the expense of
   another.

Why is this mentioned here? How does this impact this spec?

Also, when that point is linked to 

   In contrast, the NQB PHB has been designed with the goal that it
   avoids many of these issues, and thus could conceivably be deployed
   across the Internet.   

I don’t see how this is different from any other PHB (for example, the regulation point).

# Jitter & Cie

CURRENT:
   Instead, the sole
   goal of the NQB PHB is to isolate NQB traffic from other traffic that
   degrades loss, latency, and jitter performance, given that the NQB
   traffic is itself only an insignificant contributor to those
   degradations.  

Many words for the same thing (e.g., Latency variation, jitter). Unless there are subtle differences assumed by the author, please use a consistent term here. I have a preference of IPPM terms (delay variation) to be aligned with the IETF terminology.

# Access control & trust

CURRENT:
   In this context, the NQB
   PHB provides a better network environment for applications that send
   data at relatively low and non-bursty data rates.

Still the network decides which flows to bind to a PHB, right?

How the new PHB changes the trust practices out there? How classification will be done? 

# Not L4S specific (Section 3.3)

CURRENT:
   NQB network functions MUST treat packets marked with the NQB DSCP
   uniformly, regardless of the value of the ECN field.  Here, NQB
   network functions refers to the traffic protection function (defined
   in Section 5.2) and any re-marking/traffic policing function designed
   to protect unmanaged networks (as described in Section 6.4.1).

## What is meant by “NQB network function”?

## I think this behavior is independent of the use of L4S. If so, is this the right place to have this recommendation? I would move this till the PHB is defined first.

# Eligible flows

Section 4 says:
   Microflows that are eligible to be marked with the NQB DSCP are ones
   that send non-bursty traffic at a low data rate relative to typical
   network path capacities.   

How these are identified and who decides these meet the conditions? Is this a local application choice? A provisioning action?

# Marking bidirectionality

Section 4 states:
   Microflows marked with the NQB DSCP are expected to comply with
   existing guidance for safe deployment on the Internet, 

As this reasons about “microflow”, is there a bidirectionality need/assumptions? That is, do packets in both directions need to have the same marking?

I’m asking this question because some deployments uses a model where the marking from the host-to-the network is inherited from the marking set in network-to-host direction.

# Primary Requirements 

I would rename Section 5.1 to “Provisioning Requirements”

# Per user or per subscriber?

Section 5.1 says: 

   To prevent propagation of degradation of service for NQB traffic
   caused by potential mis-marking of QB traffic, network equipment that
   supports this PHB and handles traffic for multiple users (e.g.,
   subscribers) SHOULD support provisioning of capacity and related
   forwarding resources on a per-user (e.g., subscriber) basis and
   SHOULD support enforcement of the resulting per-user limits on the
   aggregate of NQB and QB traffic for each user.   

I guess this is per subscriber. Multiple users may share the same subscription.

At least, you should define “user”.

# Policy

Section 5.2 says:
   In the case of a traffic protection algorithm
   that reclassifies offending traffic, the implementation MAY
   additionally re-mark such traffic to Default (or possibly to another
   local use code point) so that the result of the traffic protection
   decision can be used by further hops.  This sort of re-marking could
   provide a limited layer of protection in situations where downstream
   network nodes support separate queuing for NQB marked packets but
   lack support for traffic protection.

This behavior should be policy-based.

# Application-layer constructs might be useful in some cases, however relying on them exclusively should not be recommended

I suggest to make this change in Section 5.2

OLD:
   The traffic protection function SHOULD NOT base its decisions upon
   application-layer constructs (such as the port number used by the
   application or the source/destination IP address).  Instead, it ought
   to base its decisions on the actual behavior of each microflow (i.e.
   the pattern of packet arrivals).

NEW:
   The traffic protection function SHOULD NOT base its decisions solely upon
                                                                 ^^^^^^ 
   application-layer constructs (such as the port number used by the
   application or the source/destination IP address).  Instead, it ought
   to base its decisions on the actual behavior of each microflow (i.e.,
   the pattern of packet arrivals).

# Resource exhaustion

Section 5.2 says:

CURRENT:
   The traffic protection function described here might require that the
   network element maintains microflow state.  The traffic protection
   function MUST be designed such that the node implementing the NQB PHB
   does not fail (e.g. crash) in the case that the microflow state is
   exhausted.

Which is great… but can we be more explicit how to do that? For example, can we say “control/limit the resources dedicated to tracking misbehaving flows”?

Cheers,
Med