gwhitecl / nqbdraft Goto Github PK

https://mailarchive.ietf.org/arch/msg/tsvwg/2jzEaHmGg-qSqLGTX_YbEyL4F5c/
From RG:

I'm referring to the app programmer pursuing the biggest advantage for his app by being standards compliant where that is advantageous, i.e. an app-programmer cherry-picking features from L4S and NQB (including TCP prague requs) to optimize app throughput without obviously ignoring both standards simultaneously. To me, a standards track document must offer text how an access provider reliably fends off traffic of this kind (working detection and working mitigation). That latter part is at least incomplete and I don't think it addresses traffic marked DSCP NQB and ECT (1).

Several sentences in the sender requirements section use the term "application" where "microflow" would be more clear.

https://mailarchive.ietf.org/arch/msg/tsvwg/TEExPUudk8X5fw9F9vtGD--OwoU/

31. I just do not understand this clause:

/support for at least 5 simultaneous NQB streams,/

• why 5?

[GW] The logic that led to the suggested 5% rule-of-thumb was actually a combination of A) 5% of the interconnect rate would be less than 50% of the internal link rate for internal links as low as 10% of the interconnect rate, B) in a residential context, 5 maximum-rate NQB compliant flows seemed like an ok starting point, as long as it came with the caveat provided in that sentence.

[GF2] I didn't yet manage to think more about "5" this likely needs some thought.

From RG: https://mailarchive.ietf.org/arch/msg/tsvwg/LHlfusaxLLDPQLCVCWMfmYtrnRo/

• I agree with you, that the requirements I ask for should not include the exact mechanism and algorithm as specified for DOCSIS
• however I expect the requirements provided by a standard to be sufficient to allow for compatible implementations and operation; to be more clear, algo's and mechanisms may be different, but externally observable behaviour is identical (or compatible, as IETF puts it, but in the case of scheduling that is better described by statistically equivalent behaviour).
• and to me, a specification for this behaviour is missing in major parts for NQB (I don't object to having it as an RFC as is, but it's not ready for standards track, I think).

From GF: https://mailarchive.ietf.org/arch/msg/tsvwg/TEExPUudk8X5fw9F9vtGD--OwoU/

32. There is a sentence that says:
    /Such a function SHOULD be implemented in an objective and verifiable manner, basing its decisions upon the
    behavior of the flow rather than on application-layer constructs./

• to me this sentence is hard to understand. Please ensure the sentence with RFC2119 language is self-contained and clearly verifiable.

33. The following clasue doesn’t seem verifiable, please say what “fail gracefully” means…
    /The traffic protection function MUST be designed to fail gracefully in the case
    that the flow state is exhausted./

[GW] Ok, maybe the best we can mandate is (like the 5th paragraph of section 6.1 in RFC2475) that the node doesn't fail (e.g. crash). Is it acceptable to use the same type of requirement as RFC2475? Or, can you think of other examples that would codify that the implementer needs to be aware of this potential error/attack case and do their best to make sure nothing catastrophic happens?

[GF2] I personally like the idea of talking about the potential error/attack case. A MUST is very strong for design guidance, but it is important to say what needs to be done, refering to RFC 2475 is some help.

From RG: https://mailarchive.ietf.org/arch/msg/tsvwg/qkO2s7TbQciXrfcjYEMp9m5QH9M/

The following situations may occur:

• QB/NQB traffic present, no congestion - cool, should just continue to operate
• QB/NQB traffic present, congestion and NQB below NQB rate - NQB should just continue to operate
• QB/NQB traffic present, congestion and NQB above NQB rate - ? The draft doesn't specify how an NQB conformant scheduler works under this operational condition. Traffic protection now doesn't reclassify traffic, does it? If it still does, how does it pick NQB packets to be reclassified, remarked and re-scheduled?

https://mailarchive.ietf.org/arch/msg/tsvwg/W7NNUE-sEb3hOJC5k0V41Nvzj1c/

17. controlled environments

I would also like to see a para break between the IETF-specified domains
and any local-use description of controlled environments:

/An alternative, in controlled environments/

• perhaps advice on controlled environments would be better placed in a
  separate subsection?

[GW] How big a concern is this for you? It does seem like it would make things difficult to explain. I'd probably prefer deleting any mention of controlled environments rather than trying to create a new subsection.

[GF2] Removal might also be good. Or if needed, putting in an annexe for
now until we all agree.

In discussing the upper bound on data rate for applications to mark traffic as NQB (see #21), at least two WG participants raised the concern that a rate like 1 Mbps would be too high for a non-congestion-controlled application to send.

https://youtu.be/u8Y3_d4oZP0?t=1839
https://youtu.be/u8Y3_d4oZP0?t=2103

While true, that statement doesn't relate to the intent of the NQB draft, which is seeking to only set an upper bound on application data rate that is eligible for marking itself with the NQB DSCP. The draft is clear on this point.

What more could or should the draft say to dispel this misconception?

Would it help to swap the order of the concepts discussed in the first two paragraphs of the sender requirements section (https://www.ietf.org/archive/id/draft-ietf-tsvwg-nqb-17.html#section-4.1)? Currently, the first paragraph talks about data rates and application limited-ness. The second paragraph talks about the need for congestion response. Maybe this order makes congestion response seem like an afterthought?

https://mailarchive.ietf.org/arch/msg/tsvwg/W7NNUE-sEb3hOJC5k0V41Nvzj1c/

19. The following text is still to me is problematic for a PS.
    /Similarly, networks and nodes that aggregate service classes as discussed in
    [RFC5127] and [RFC8100] might not be able to provide a PDB/PHB that
    meets the requirements of this document./

• We can define in this PS, what is to be done to comply with the PS, we
  should not provide text that seems to hint that complying with the spec
  allows non-compliance.
• This text needs to be in a separate section to clearly differentiate
  it from the other treatment

[GW] I see your point. How separate does it need to be? An appendix?

[GF2] Moving some discussion of considerations there might work, it would be a good start.

[**] Should there be some sort of recommendation for hysteresis in flow (re-)classification between QB and NQB?  That could help limit the out-of-order delivery impact on each individual flow.

https://mailarchive.ietf.org/arch/msg/tsvwg/TEExPUudk8X5fw9F9vtGD--OwoU/

37. Section 5.3 says:
    /To limit the consequences of this scenario, operators of such
    networks SHOULD utilize a traffic protection function that is more
    tolerant of burstiness (i.e., a temporary queue). Alternatively,
    operators of such networks MAY choose to disable NQB support (and
    thus aggregate NQB-marked traffic with Default traffic) on these low-
    speed links. For links that are less than ten percent of "typical"
    path rates, it is RECOMMENDED that NQB support be disabled and for
    NQB-marked traffic to thus be carried using the default PHB./

Is there a standards-track specification for this function?
[GW] No. But the example algorithm has a configuration parameter specifically for this purpose. Implementers of other algorithms could learn from this, or design an alternative.

Is there a clear indication of why this is important?

 
       In these cases it is
   recommended that NQB-marked traffic be aggregated with standard,
   elastic, best-effort traffic, although in some cases a network
   operator may instead choose to aggregate NQB traffic with Real-Time
   traffic.
Need more clarity on exactly what the NQB traffic is being aggregated with.  I suggest using terminology from RFC 4594, 5127 and/or 8100 and referencing the relevant RFC(s) for precision.
 
      In either case, [RFC5127]
   requires that such aggregations preserve the notion of each end-to-
   end service class that is aggregated, and recommends preservation of
   the DSCP as a way of accomplishing this.  Compliance with this
   recommendation would serve to limit the negative impact that such
   networks would have on end-to-end performance for NQB traffic.
Phrasing is a bit peculiar.  It might be better to rewrite the sentence to say that the identity of the NQB traffic should be preserved when that traffic is aggregated and use RFC 5127 as an example.  Something to keep in mind is that RFC 5127 and RFC 8100 were both motivated by MPLS limitations, and have limited applicability to non-MPLS networks.

1. Section 4: This section provides a couple of reasons why it has been difficult with existing DiffServ architecture to meet end-to-end performance requirements, especially issues related to all networks in the path not agreeing to performance requirements of an application. With NQB PHB, separate DiffServ codes are defined so that packets from NQB flows can essentially avoid getting backlogged with QB flows in the same queues. But what about performance requirements associated with NQB flows? Is having separate NQB queues sufficient to meet end-to-end performance requirements? While having separate queues for NQB flows will definitely help, is that enough to overcome the issue of all networks in the path not agreeing to performance requirements? In other words, would some sort of end-to-end agreement still be required across all networks in the path, albeit in a simpler form?

2. Section 6: This section indicates, that the node should provide a scheduler, which allows QB and NQB traffic of equivalent importance to share the link in a fair manner, e.g. a deficit round-robin scheduler with equal weights. Is it fair to assume that the scheduler would allow NQB traffic of higher importance to get more prioritized scheduling treatment. For example, two NQB flows may have different latency requirements wrt each other as well as wrt to other QB traffic. In such a case, would the NQB flow with tighter latency requirement be able to get prioritized scheduling treatment? The answer to this may simply fall back to how current DiffServ architecture treats flows with different priorities. But that is exactly where the end-to-end issue from previous question comes in.

3. Section 11.2: Again, there could be some discussion here related to per-flow QoS for 5G. For example, even though an NQB flow is assigned to the same ‘default’ non-GBR bearer as a QB flow, it could be assigned a different flow ID so that it could be provided more QoS-specific treatment (although still non-GBR, but potentially with higher priority weighting, e.g. QCI7).

https://mailarchive.ietf.org/arch/msg/tsvwg/W7NNUE-sEb3hOJC5k0V41Nvzj1c/

1. The definition of “low-rate data-rate, application-limited traffic
   flows” is still problematic for me. The text later describes this (in
   more than one place) as /relatively low data rate applications/ … which
   I am less sure about what that means? how relative is this? Can we be
   more concrete?

[GW] Section 4.1 describes an upper bound using a rate equation, where the rate R is described as 'about 1 percent of "typical" network path capacity' and further provides that today that works out to 1 Mbps. Would it help if we provided that definition earlier on in the document? Or, it your concern that even this definition is not concrete enough?

[GF2] Hmmmm.... This needs to be handled well in the spec. At this
moment, it linked to 4 and 13 below.

4. I agree with the desire that they are “such that they are highly
   unlikely to exceed the available capacity of the network path between
   source and sink.”, but reading this left me feel really uncomfortable
   with respect to operators and networks offering less than 100 Mbps - I
   am not sure I like the idea of the IETF projecting a minimal service
   rate, so I'd encourage much more care in how this is all framed.

[GW] The intent wasn't to project a minimal service rate in general for the Internet. But, the ability to deliver on the promise of the NQB PHB does depend on the relative rates between the applications sending NQB-marked traffic (in aggregate on a link) and the link rate where the PHB is supported. We could enable the benefits of the NQB PHB to extend to more networks by setting this application rate guidance lower, but that would then limit the applications that could take advantage of it. This is a judgement call, but 1% of "typical" capacity (1 Mbps today) to me seems like a reasonable place to draw the line and provides some headroom in cases where the capacity is less than typical. I think setting it to 500 kbps would be ok, but I don't think we would want to go a lot lower than that.

[GF2] It is judgment call, and a lower rate would ease the pain with
respect to objections (including mine). I'd expect we'll find more
comfort with more experience, but I'm going to continue to query if a 1
Mbps rate is low enough.

/At the time
of writing, it is believed that 1 Mbps is a reasonable upper bound on
instantaneous traffic rate for an NQB-marked application, but this
value is of course subject to the context in which the application is
expected to be deployed./

• This is an IETF PS, and needs to have IETF consensus: I’ve argued this
  is high in the past for a PS designed for the Internet as a whole, and I
  will argue again the same. Although I can see that in some regions this
  value would be legitimate, I fear in other places it would not. I think
  this is something I where I would like to see a strong consensus.

[GW] Per my comment above I think if we reduce it too much it won't provide a benefit for very many applications. Do you have a number in mind?

[GF2] Aha - I wonder can we find a rate low enough to be happy? I'm
guessing an agregate of 1 Mbps might be nearer, which might really be a
small share of many paths? I think we will need to return to point 13
after we finish others.

"and partly in Net Neutrality considerations. Of late, said consideration seems to have lost momentum"

It sounds like you're saying Net Neutrality is less important that it once was. Is this true?

last para of S.4 contains a bunch of good questions:

   Some questions that arise when considering endpoint marking are: How
   can an application determine whether it is queue building or not,
   given that the sending application is generally not aware of the
   available capacity of the path to the receiving endpoint?  Even in
   cases where an application is aware of the capacity of the path, how
   can it be sure that the available capacity (considering other flows
   that may be sharing the path) would be sufficient to result in the
   application's traffic not causing a queue to form?
   In an unmanaged environment, how can networks trust endpoint marking,
   and why wouldn't all applications mark their packets as NQB?

I suggest we make this a separate subsection called "open points" where all the different contentious questions are clearly identified (e.g., each one is an entry in a bullet list, or it's framed in a nested subsection, or something along these lines).

This way we can show the readers how each point is addressed in a clear and ordered fashion as we iterate the document.

https://mailarchive.ietf.org/arch/msg/tsvwg/W7NNUE-sEb3hOJC5k0V41Nvzj1c/

8. “In addition, these applications send their traffic in a smooth (i.e.
   paced) manner,”

• I know smooth pacing can be true in some cases, but is it necessarily
  true. If I take a Zone transfer or download a large DNS record is this
  paced? What are the implications here?

[GW] Well, I think we need to draw the line somewhere. Based on the current text, a burst greater than 1500 bytes above "R" would not be compliant with the sender requirements. Do you think 1500 bytes isn't the right number?
[GF2] I was more asking if these apps really are paced?

https://mailarchive.ietf.org/arch/msg/tsvwg/W7NNUE-sEb3hOJC5k0V41Nvzj1c/

2. I understand the goal of “This PHB is implemented without
   prioritization” and that is not in dispute, but the side effects of the
   currently discussed DSCP value is that it could be assigned by accident
   to a lower layer that treats traffic with this DSCP as having this
   priority. I expect that somehow needs extra diligence with the way we
   define the traffic profile.

[GW] That topic is the subject of section 4.3.1, which provides recommendations on how to prevent or mitigate problems that could otherwise result. Do you have any thoughts on what changes there would help eliminate this concern?
[GF2] We should check this again in the next reading....

   Active Queue Management (AQM) mechanisms (such as PIE [RFC8033],
   DOCSIS-PIE [RFC8034], or CoDel [RFC8289]) can improve the quality of
   experience for latency sensitive applications, but there are
   practical limits to the amount of improvement that can be achieved
   without impacting the throughput of capacity-seeking applications.

Is there an established reference that we could add here to substantiate the claim?

      Compliance with the DualQ
   coupled AQM requirements is considered sufficient to enable fair
   allocation of bandwidth between the QB and NQB queues.
s/DualQ/dual-queue/ for consistency or explain how the two terms differ.

      (e.g. they
   are NQB on higher-speed links, but QB on lower-speed links)
s/are NQB on/exhibit NQB behavior on/ and s/QB on/exhibit QB behavior on/
 
       If
   there is uncertainty as to whether an application's traffic aligns
   with the description of NQB behavior in the preceding section, the
   application SHOULD NOT mark its traffic with the NQB DSCP.
Well, the previous section (4) is somewhat conversational and informal, whereas this "SHOULD NOT" is a very important requirement.  It would be better to spell that requirement out crisply, e.g., in the form of:  If , or then the application SHOULD NOT mark its traffic with the NQB DSCP.  That reduces the opportunity for different readers to reach different interpretations about what is required.
 
      In such a
   case, the application SHOULD instead implement a congestion control
   mechanism, for example as described in [RFC8085] or
   [I-D.ietf-tsvwg-ecn-l4s-id].
Add a specific section number or numbers to the citation of RFC 8085, as there's a lot of other material in that RFC.
 
   It is worthwhile to note again that the NQB designation and marking
   is intended to convey verifiable traffic behavior, not needs or
   wants.
Hmm – perhaps s/not needs/in addition to needs/ ??
 
      Thus, a useful property of nodes that
   support separate queues for NQB and QB flows would be that ...
I suggest providing a forward reference at the end of this sentence to a section or sections later in this draft that explain more about how that property can be achieved, perhaps to Section 14 (Security considerations) ?

Please cite at least one 802.11 reference in the first paragraph.

First paragraph – I suggest removing interactive video, as it's not always low data rate.  Interactive voice is a great example to keep.

https://mailarchive.ietf.org/arch/msg/tsvwg/W7NNUE-sEb3hOJC5k0V41Nvzj1c/

18. Please explain:

/would be to aggregate NQB-marked traffic with real-time, latency sensitive traffic./

• How would aggregation be performed … would this traffic with this set
  of DSCP values be forwarded as the same treatment aggregate?

[GW] That is what I had in mind, but this sentence has pretty low overall value in the draft. If it is problematic, I'd probably delete it rather than spending a lot of time wordsmithing it.

[GF2] Please suggest something, removal might be fine.

Concerning this line, it should be: updates="8325"

   A node supporting the NQB PHB MUST provide a queue for non-queue-
   building traffic separate from the queue used for queue-building
   traffic.
s/separate from the queue/separate from any queue/ as there may be more than one such queue.
 
      The NQB queue SHOULD be given equal priority compared to queue-
   building traffic of equivalent importance.
I understand the intent, but I don't think that "equal priority" is the right choice of words because more than priority is involved.  Something like "equivalent forwarding preference" seems closer to the mark.
 
   A node supporting the NQB PHB SHOULD treat traffic marked as Default
   (DSCP=0) as QB traffic having equivalent importance to the NQB marked
   traffic.
[**] That may not work out well for the 42 DSCP.  Needs some rethinking.
 
   A node supporting the NQB PHB SHOULD treat traffic marked as Default
   (DSCP=0) as QB traffic having equivalent importance to the NQB marked
   traffic.  A node supporting the NQB DSCP MUST support the ability to
   configure the classification criteria that are used to identify QB
   and NQB traffic having equivalent importance.
Second sentence doesn't parse for me.  Do the criteria have equivalent importance or do the two types of traffic?
 
   The NQB queue SHOULD have a buffer size that is significantly smaller
   than the buffer provided for QB traffic.  It is expected that most QB
   traffic is optimized to make use of a relatively deep buffer (e.g. on
   the order of tens or hundreds of ms) in nodes where support for the
   NQB PHB is advantageous (i.e. bottleneck nodes).  Providing a
   similarly deep buffer for the NQB queue would be at cross purposes to
   providing very low queueing delay, and would erode the incentives for
   QB traffic to be marked correctly.
Add an example of time-duration size of NQB queue – e.g., single-digit ms, sub-ms?

   These applications do not cause queues
   to form in network buffers, but nonetheless can be subjected to
 
That's not strictly correct, but it's close.  A word such as "standing" or "persistent" ought to be inserted between "cause" and "queues to form" as NQB traffic can form short-lived queues that quickly drain.  A similar word insertion change is also wanted here (before "queues"):
 
   ... as a result of sharing a network
   buffer with applications that do cause queues to form

https://mailarchive.ietf.org/arch/msg/tsvwg/i4sz-cMb5MOLBCzDv47RFB0cn7g/

In some earlier emails on this topic, I had thought that this would be a non-typical case, but I am reconsidering that. I think the IETF should encourage low-data-rate NQB-compliant applications to also implement an L4S-compliant congestion response, rather than a circuit-breaker or other (non-L4S) congestion response. There are a couple of benefits to this. One is that the application can't know a priori whether the network bottlenecks support the NQB PHB, or an L4S dual-queue, or both. Complying with the superset of requirements, and marking traffic with both DSCP NQB & ECT(1) could provide it the best chance of achieving low latency. Secondly, an NQB-compliant application that implements an L4S congestion response could achieve better latency performance than one that implements a circuit-breaker or some other (non-L4S) congestion response (e.g. delay or loss based) when it finds itself in a low data rate (e.g. well below "typical path capacity") L4S-aware bottleneck.

https://mailarchive.ietf.org/arch/msg/tsvwg/qjVx4gABUWMsw0aq05x0zgHVJSA/

9. “Note that, while such flows ordinarily don't implement a traditional congestion control mechanism, they”

[GW] .... Actually, I'm still a bit uneasy with how that is presented. As I mentioned in
https://mailarchive.ietf.org/arch/msg/tsvwg/i4sz-cMb5MOLBCzDv47RFB0cn7g/
I don't see why we wouldn't want to encourage ALL NQB-marked applications to also implement an L4S-compliant congestion controller. Later in this section we recommend that NQB non-compliant applications consider implementing L4S, but why not low-data rate ones too?

[GF2] I think some classes of very low rate apps will find it hard to respond to ECN - because they send too infrequently and might not be able to understand marks properly. To me, these are a good match to NQB. Anything that has many packets in flight or sends many packets/sec could be encouraged to use L4S. This should be thought through.

"Wi-Fi" is the correct spelling. Please update all occurrences of "WiFi" to be "Wi-Fi".

[**] Please check the first paragraph with some 3GPP folks to make sure that it won't cause problems.]
 
   A packet carrying the NQB DSCP SHOULD be routed through the dedicated
   low-latency EPS bearer.  A packet that has no associated NQB marking
   SHOULD be routed through the default EPS bearer.
For robustness wrt additional bearers, it may be better to rephrase the second sentence as a "SHOULD NOT" – e.g., A packet that has no associated NQB marking SHOULD NOT be routed through the low-latency EPS bearer.

      to denote Non-Queue-Building behavior.
s/to denote/as the RECOMMENDED codepoints for/  - to align with Section 5 of RFC 2474.
 

https://mailarchive.ietf.org/arch/msg/tsvwg/TEExPUudk8X5fw9F9vtGD--OwoU/

36. Section 5.3 says it provides
    /Guidance for Very Low-Rate Links/

• I am doubtful that people providing 10 Mbps service would regard their service as
• I'll reiterate that I really felt uncomfortable with labeling this as /very low rate/. The title here is clearly not likely to attract the reader who needs to pay a lot of attenetion to this section. In some places in the world 10 Mbps would still be regarded as high speed!!

[GW] One thought would be to call this section something like "Applicability of the NQB PHB" and then this could be a home for the current 4.3.1 and the "controlled environments" material. Would that be a logical structure in your view?

[GF2] I think the section title should be chosen to encourage the correct people to read - just as security considerations makes security people take notice, so we need something that makes people deploying/configuring diffserv take notice.

Material on observed DSCP remappings (last 3 paragraphs in Section 5.1) is important, but seems to detract from the flow of draft at this point.  Perhaps move that to a later section or Appendix?

https://mailarchive.ietf.org/arch/msg/tsvwg/UTR74bpFzaUULGD0bhZzxq0CT1c/
https://mailarchive.ietf.org/arch/msg/tsvwg/IxvY0N8faDxqyaYuYc_zz6gedog/

[**] should say something about WiFi, as elevated priority is used there.

These comments are generally editorial. If you wish, I can submit a PR for the text substitutions.

• Use a consistent spelling for the following words and phrases: prioritize, queuing, judgment, out-of-order
• In line 134, assuming 'LE' stands for 'lower-effort', indicate as such, and cite RFC 8622

Also, provide these text substitutions at the given lines:

154: s/NQP/NQB/
156: s/applications generation/applications generating/
158: s/DSCP value/DSCP values/
190: s/An operator would need to use their own judgement based on the actual traffic characteristics in their network/Operators would need to use their own judgement based on the actual traffic characteristics in their networks/
235: s/that are used classify packets/that are used to classify packets/
376: s/If a Non-Queue-Building microflow were to fail/If a Non-Queue-Building microflow was to fail/
511: s/non capacity-seeking/non-capacity-seeking/

NQB intends to update the DSCP-to-UP guidance provided in RFC8325, yet it doesn't directly provide that guidance for the NQB DSCP. Instead it provides a DSCP-to-AC recommendation. This should be fixed to be consistent.

s/DiffServ/Diffserv/
 
Top of p.5:
   performance "requirements" are not hard ones (e.g. applications will
s/hard/strict/ or s/hard/absolute/ to avoid "hard" being misread as "difficult".  Not every reader will understand that the meaning of "hard" in "hard real time" is intended here.
 
A few paragraphs further down:
      The intent of the NQB DSCP is that
   it signals verifiable behavior as opposed to wants and needs.
Hmm – perhaps s/as opposed to/in addition to/ ??
The NQB PHB definitely signals desired traffic treatment/conditioning, but it also signals verifiable behavior that justifies applying that treatment/conditioning.  FWIW, EF and VOICE-ADMIT go part of the way there, but explaining that in this draft is probably a diversion.
 
       As a result, the NQB
   PHB does not aim to meet specific application performance
   requirements, nor does it aim to provide a differentiated service
   class as defined in [RFC4594].  Instead the goal of the NQB PHB is
Suggest changing that text to:
       As a result, the goal of the NQB PHB is
The statement about RFC 4594 is probably wrong, and it may be simpler just remove that statement rather than debate it.
 
   These attributes eliminate the inherent value judgments that underlie
   the handling of differentiated service classes in the DiffServ
   architecture as it has traditionally been defined, they also
   significantly simplify access control and admission control
   functions, reducing them to simple verification of behavior.
s/the inherent value judgements/many of the tradeoffs/
Otherwise, the draft will likely have to explain what an "inherent value judgement" is – better to not go there.