gwhitecl / nqbdraft Goto Github PK
View Code? Open in Web Editor NEWIETF draft on Non-Queue-Building Per-Hop-Behavior
IETF draft on Non-Queue-Building Per-Hop-Behavior
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?
"Wi-Fi" is the correct spelling. Please update all occurrences of "WiFi" to be "Wi-Fi".
https://mailarchive.ietf.org/arch/msg/tsvwg/W7NNUE-sEb3hOJC5k0V41Nvzj1c/
- 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.
- 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.
https://mailarchive.ietf.org/arch/msg/tsvwg/TEExPUudk8X5fw9F9vtGD--OwoU/
- 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?
"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?
Concerning this line, it should be: updates="8325"
Regarding the sentence in: https://www.ietf.org/archive/id/draft-ietf-tsvwg-nqb-23.html#section-3.2-6
The PHB is also designed to minimize any incentives for a sender to mismark its traffic, since neither higher priority nor reserved bandwidth are being offered.
DB & GF identified two issues with the wording "higher-priority":
Ref: https://mailarchive.ietf.org/arch/msg/tsvwg/-rOK_naHqiJtNV4TrcQlGyZhCNY/
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).
These comments are generally editorial. If you wish, I can submit a PR for the text substitutions.
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/
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?
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.
If so, we'll need to specify exactly the wording changes that are being made to RFC9330 & 9331.
From https://mailarchive.ietf.org/arch/msg/tsvwg/XNNyrMOLvqxqPVPuZsWPwwlCCVk/
[GW2] The only update to L4S requirements is the statement:
"L4S network functions SHOULD treat packets marked with the NQB DSCP and ECT(1) or CE the same as packets marked with the Default DSCP and the same ECN value. Here, L4S network functions means the L4S Network Node functions (Section 5 of [RFC9331]), and any mechanisms designed to protect the L4S queue (such as those discussed in Section 8.2 of [RFC9330])."[GW2] In other words, L4S nodes shouldn't handle "L4S+NQB" packets (DSCP45 && (ECT1 || CE)) any differently from "L4S+Default" packets (DSCP0 && (ECT1 || CE)). This recommendation only applies to nodes that support both NQB and L4S.
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?
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.
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).
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.
Regarding the sentence in: https://www.ietf.org/archive/id/draft-ietf-tsvwg-nqb-23.html#section-3.2-6
The PHB is also designed to minimize any incentives for a sender to mismark its traffic, since neither higher priority nor reserved bandwidth are being offered.
DB raised a concern (in https://mailarchive.ietf.org/arch/msg/tsvwg/OMOc-jHjik2_p3GWZBt4cPZbkHc/):
[A] The incentives are not minimized because lower latency is clearly
being offered to NQB traffic, which provides an incentive for traffic
mismarking. Section 4.1 identifies traffic protection as the primary
disincentive for mismarking queue-building traffic as NQB: "The
consideration as to whether an application chooses to mark its traffic
as NQB involves the risk of being subjected to a traffic protection
algorithm (see Section 5.2) if it contributes to the formation of a
queue in a node that supports the PHB."
https://mailarchive.ietf.org/arch/msg/tsvwg/TEExPUudk8X5fw9F9vtGD--OwoU/
- 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.
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.
Please cite at least one 802.11 reference in the first paragraph.
https://mailarchive.ietf.org/arch/msg/tsvwg/W7NNUE-sEb3hOJC5k0V41Nvzj1c/
- “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/
- 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.
DB raised an issue (in https://mailarchive.ietf.org/arch/msg/tsvwg/OMOc-jHjik2_p3GWZBt4cPZbkHc/):
Section 5 states: "Malicious behavior is not necessarily based on rational self-interest, so incentive alignment is not a sufficient defense, but the large majority of users do not act out of malice. Protection against malicious attacks (and accidents) is addressed in Section 5.2 and summarized in Section 10."
An important implication is that traffic protection is the countermeasure to malicious use, which is confirmed by section 10: "To preserve low latency performance for NQB traffic, networks that support the NQB PHB will need to ensure that mechanisms are in place to prevent malicious traffic marked with the NQB DSCP from causing excessive queue delays. Section 5.2 recommends the implementation of a traffic protection mechanism to achieve this goal but recognizes that other options might be more desirable in certain situations."
[...] the usually IETF requirement for crucial security countermeasures such as this (traffic protection) is that they be mandatory to implement so that they are available for use if/as needed.
and
Both the incentive framework and security of NQB have a fundamental dependency on traffic protection - absent "certain situations", neither works without traffic protections. Nonetheless, the requirement for traffic protection in the second paragraph of Section 5.2 is a SHOULD: "... network elements that support the NQB PHB SHOULD support a "traffic protection" function ...". That's completely inadequate - based on incentives framework and security considerations, the appropriate requirement is "... network elements that support the NQB PHB MUST support and SHOULD use a "traffic protection" function ..." .
Turning to "certain situations" - these would initially be exceptions to "SHOULD use" and perhaps equipment that is only used in such exceptional situations could be an exception to "MUST support". Unfortunately, the paragraph in Section 5.2 on these exceptional situations is a serious hand-wave: "There are some situations where traffic protection is potentially not necessary. One example could be a network element designed for use in controlled environments (e.g., enterprise LAN) where a network administrator is expected to manage the usage of DSCPs. Another example could be highly aggregated links (links designed to carry a large number of simultaneous microflows), where individual microflow burstiness is averaged out and thus is unlikely to cause much actual delay." That's nowhere near good enough.
For "SHOULD use", quoting from RFC 2119's definition of "SHOULD": "... there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course." The "full implications" that "must be understood and carefully weighed" in this case are the presence of incentives to mismark and the absence of protection against malicious use. Omission of these concerns is a major flaw in the Section 5.2 paragraph on exceptional situations. OTOH, there will be certainly be some situations in which network operators have effective controls outside of the NQB forwarding implementation that prevent mismarking and malicious use, and it would be good to describe at least one such situation - an extreme example would be an air-gapped network with complete controls on application deployment and network traffic origination, including traffic marking..
Exceptions to "MUST support" are a taller order, although one possibility could be implementations that are only usable in networks that have "valid reasons to ignore" the "SHOULD use" could be one possibility - in essence the implementer has to be certain that mismarking and malicious use are impossible in networks that use her implementation. In order to agree to any text describing exceptions to "MUST support", I want to first understand the specific network examples that motivate the exception(s), including their mechanisms for prevention of mismarking and malicious use, since traffic protection will not be available for those purposes.
GF provided a further comment (in https://mailarchive.ietf.org/arch/msg/tsvwg/-rOK_naHqiJtNV4TrcQlGyZhCNY/):
GF: I wonder if there are several options here, only one of which we
might like: (a) A WG could require implementation - some implementations
of course might still choose to ignore, as they will, the IETF can’t
control that. (b) A WG can make this optional, in which case I would
expect to explain how this will be managed, and clearly indicate to
indicate the implications, and that needs work. (c) A WG can constrain
this use to a limited domain and defined the scoping - or we can leave
that for others to work out, as they will. More precision here would
seem very helpful at this stage. I'm thinking that the last is not the
way to proceed.
https://mailarchive.ietf.org/arch/msg/tsvwg/TEExPUudk8X5fw9F9vtGD--OwoU/
- 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.
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/W7NNUE-sEb3hOJC5k0V41Nvzj1c/
- 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....
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/
- “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.
(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) ?
https://mailarchive.ietf.org/arch/msg/tsvwg/W7NNUE-sEb3hOJC5k0V41Nvzj1c/
- 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.
https://mailarchive.ietf.org/arch/msg/tsvwg/W7NNUE-sEb3hOJC5k0V41Nvzj1c/
- 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.
First paragraph – I suggest removing interactive video, as it's not always low data rate. Interactive voice is a great example to keep.
[**] should say something about WiFi, as elevated priority is used there.
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?
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?
to denote Non-Queue-Building behavior.
s/to denote/as the RECOMMENDED codepoints for/ - to align with Section 5 of RFC 2474.
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.
[**] 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.
[**] 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.
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.
BC commented (in https://mailarchive.ietf.org/arch/msg/tsvwg/ej3Rk8FVIuopmM0xMwZqndECTGs/)
In 4.4 "Cross-domain usage and DSCP Re-marking":
I think there needs to be an explanation of how this section relates to RFC 8100
RG responded (https://mailarchive.ietf.org/arch/msg/tsvwg/Qi-nsXhDwbVAgGThPWtMfdEOxgs/):
Section 4.4: If NQB support is extended across a DiffServ domain boundary, the interconnected networks agreeing to support NQB SHOULD use the DSCP value 45 (decimal) for NQB at network interconnection, unless a different DSCP is explicitly documented in the TCA (Traffic Conditioning Agreement, see [RFC2475]) for that interconnection.
[RG] If RFC 8100 is agreed and operational and the provider interconnection link is no bottleneck, my suggestion would be to explicitly document usage of DSCP 5 (dec.) The sending party should re-mark NQB traffic to DSCP dec. 5 and the receiving party should classify NQB traffic by that DSCP.
BC concluded (https://mailarchive.ietf.org/arch/msg/tsvwg/CcytdksJWAxZ20xm1U7qYALwLD0/):
I think your first suggestion is useful, and sufficient.
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/
- 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.
- 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?
Several sentences in the sender requirements section use the term "application" where "microflow" would be more clear.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.