[tsvwg] Re: Request to review diffserv spec: draft-ietf-tsvwg-nqb

[Sebastian Moeller <[e-mail]>]

Hi Brian,


> On 1. Jun 2024, at 22:35, Brian E Carpenter <[e-mail]> wrote:
> 
> On 02-Jun-24 01:06, Sebastian Moeller wrote:
>> Hi Brian,
>>> On 31. May 2024, at 22:22, Brian E Carpenter <[e-mail]> wrote:
>>> 
>>> On 31-May-24 17:28, Sebastian Moeller wrote:
>>>> Hi Brian,
>>>> On 31 May 2024 01:47:35 CEST, Brian E Carpenter <[e-mail]> wrote:
>>>>> On 31-May-24 10:47, Greg White wrote:
>>>>>> Thanks Christian.
>>>>>> 
>>>>>> On the topic of the need to verify behavior, that discussion (and further work in that space) should continue.  There seems to be a wide range of opinions on the topic, from those who firmly believe that no verification is needed, to those who believe it needs to be mandatory and bulletproof.  The draft provides guidance and recommendations, but leaves this open for implementers.  To me that is the right stance.
>>>>> 
>>>>> I think that a network that claims to send NQB traffic to a NQB-supporting peer network,
>>>> [SM] NQB being intended end to end there is no guarantee that along a path there exists a NQB supporting peer network to begin with. And the IETF in the past recommended to leave uncontentious DSCPs in place (that is dscp aware networks are encouraged to only modify ingress dscps they use themselves).
>>> 
>>> True, but that was not what I was discussing.
>>> 
>>>> but doesn't police NQB at ingress, will be policed at egress by that peer.
>>>> [SM] A peer that might not exist... putting safety into the hands of 'to whom it may concern' seems neither robust, nir reliable to me.
>>> 
>>> I'm simply saying that an NQB-supporting domain will most likely defend itself against incoming traffic that claims to be NQB but doesn't behave as NQB.
>> [SM] How? The harm is not done at the AS level, but will only realise at the bottleneck... unless you know about the the bottleneck capacities of the individual leaf sites you can not defend against NQB appropriately at the interconnection points... And with variable rate links like LTE/5G and especially WiFi in the mix I claim policing NQB at the interconnection side is a fools errand, it might help in curtailing mass abuse, 
> 
> Exactly. That is all a provider can do.

[SM2] Which is an indirect consequence of:
"To prevent this situation from harming the performance of the microflows that comply with the requirements in Section 4.1, network elements that support the NQB PHB SHOULD support a "traffic protection" function that can identify microflows or packets that are inconsistent with the sender requirements in Section 4.1, and either reclassify those microflows/packets to the QB queue or discard the offending traffic. 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."

For this to help, the "traffic protection" essentially needs to operate at the bottleneck node, as only there it will be really possible to assess whether a microflow is problematic or not.
The draft partially admits that:

"Traffic protection as it is defined here differs from Traffic Conditioning implemented in other Diffserv contexts. Traffic Conditioning is commonly performed at the edge of a Diffserv domain (either ingress or egress, depending on Traffic Conditioning Agreements in place). In contrast, traffic protection is intended to be implemented in the nodes that implement the PHB. By placing the traffic protection at the PHB node, an implementation can monitor the actual NQB queue and take action only if a queue begins to form. Implementation of traffic protection at PHB nodes that are most likely to be a bottleneck is particularly important because these are the nodes that would be expected to show the most queue build-up in the presence of QB traffic mismarked as NQB."

But fails to go the full distance: Arguing that "traffic protection at PHB nodes that are most likely to be a bottleneck" is IMHO incompatible with allowing NQB with side effects on APs that do not implement the NQB PHB, as these in many residential contexts are "most likely to be a bottleneck". And the way WiFi typically works essentially all WiFi stations also need to implement such traffic protection for their own NQB transmissions. (If we assume a CBR flow without rate control that takes too much airtime on a WiFi link, shaping that rate down in a CPE or BNG node will do nothing to help capacity sharing over the WiFi link).
And yet the draft opts for requiring explicit opt out to avoid the side-effects on non-participating nodes. Parties that are likely complete unaware of NQB and its side effects are supposed to take actions to defend against those side-effects. And this design is 'justified' with convenience of deployment.


> 
>> but will do squat for individual subscribers. But it is the subscribers that are supposed to benefit from NQB not the providers.
>>> 
>>>> But that's not new, it really applies to every PHB except Default. So I think the text is OK as is.
>>>> [SM] Almost all new RFC introduce change from the status quo... if we would like business as usual, why do we keep adding new RFCs?
>>> 
>>> We add new PHBs occasionally because we think they're useful, but none of them change the basics of what happens at a diffserv domain boundary.
>> [SM] Yes, but most PHBs do not claim to be useful for end to end traffic without first negotiating TCAs/SLAs NQB however aims to be end to end with or without participating networks in between...
>> "A Lower-Effort Per-Hop Behavior (LE PHB) for Differentiated Services" https://www.rfc-editor.org/rfc/rfc8622.html solves this issue simply by being beneficial to all parties (packets marked LE are intended to be dropped when bottlenecks arise something helpful for any bottleneck, whether in an ISP's backbone or at the edge) and by having no side effects (so no trade-off and aligned benefits). To be clear LE is safe by design, so unless some ISP mismarks LE packets >= BE no harm is done, NQB is decidedly not safe by design, but has side effects that shold be controlled, but in the current draft are not.
> 
> Isn't that the whole point of section 5.2 "Traffic Protection"?
> 
> 'network elements that support the NQB PHB SHOULD support a "traffic protection" function that can identify microflows or packets that are inconsistent with the sender requirements in Section 4.1, and either reclassify those microflows/packets to the QB queue or discard the offending traffic.'
> 
> So my CE router, for example, should do that.

[SM2] But does your CE router and do that, and what about your AP(s)? What about the bulk of routers and APs in current deployment, will these offer NQB aware "traffic protection"? And how likely do you think it is for the expected millions of WiFi4 and WiFi5 APs and WiFi-routers in the field to actually get updates that implement such a traffic protection function?
The draft clearly assumes that the likelihood is extremely slim, other wise the whole section "7.3.1. Interoperability with Existing Wi-Fi Networks" would hardly be needed...


Now, personally I am well prepared, I use flow queueing in both my router and my APs and I used the appropriate IEEE method* to make sure DSCP decimal 45 maps to AC_BE in my network. The result of which is, that even without the NQB code points, flows with the appropriate behaviour (like the one described in the draft) will experience little queueing delay and there will be no side effect on WiFi even for misbehaving flows. (I accept that using AC_BE on the WiFi link will introduce a bit more jitter than using AC_VI would**).
But I am well aware that this is outside of the reach for the vast majority of deployed routers and APs.


Regards
	Sebastian

*) IEEE Std 802.11-2012, 8.4.2.97, there already exists a standardised way of mapping DSCPs to UPs/ACs for WiFi that would lend itself well to an opt-in approach. Propose a DSCP that by default maps to the default AC_BE and only change that if an AP is NQB aware by simply employing the appropriate mechanism to doing so. That approach would also have the added benefit of allowing to propose a DSCP that has a higher probability to passage the existing internet unchanged (according to Exploring DSCP modification pathologies in the Internet, by Ana Custura, Raffaello Secchi , Gorry Fairhurst, the likelihood of traversal is ~25%age points higher for DSCP1-7 conpared to DSCPs 8-47, and ~17%age points for DSCPs 48-63; so selecting a DSCP out of the range 2-7 would increase the end-to-endness of NQB massively).

**) Sidenote: the way I understand the airtime acquisition process in WiFi if AC_BE acquires a transmit-opportunity and has aggregate data for say 3ms worth of airtime, it will sends these, so even with NQB in a higher AC, like AC_VI or AC_VO NQB packets will not preempt on going transmissions and hence over WiFi the jitter will still be noticeably higher than over a medium without aggregation. What using AC_VI or AC_VO will give is a higher probability to gain airtime access sooner outside of ongoing transmissions.


> 
> Regards,
>    Brian
> 
>> Regards
>> Sebastian
>>> 
>>> Regards
>>>   Brian
>>> 
>>>>> 
>>>>>   Brian
>>>>> 
>>>>> 
>>>>>> 
>>>>>> -Greg
>>>>>>    On 5/30/24, 11:42 AM, "Christian Huitema" <[e-mail] <mailto:[e-mail]>> wrote:
>>>>>> 
>>>>>> 
>>>>>> Greg,
>>>>>> 
>>>>>> 
>>>>>> Your proposal removes the mention of UDP, and that does address my
>>>>>> comment that the behavior should not be linked to a specific transport.
>>>>>> 
>>>>>> 
>>>>>> As for the need to verify behavior, that's another discussion, still
>>>>>> ongoing.
>>>>>> 
>>>>>> 
>>>>>> -- Christian Huitema
>>>>>> 
>>>>>> 
>>>>>> On 5/30/2024 8:43 AM, Greg White wrote:
>>>>>>> Christian,
>>>>>>> 
>>>>>>> Agreed. Please have a look at my response to Brian to see if the proposed modifications address your point.
>>>>>>> https://mailarchive.ietf.org/arch/msg/tsvwg/SOfCGp2DcqUJT9TCjP8kJDdWyyU/ <https://mailarchive.ietf.org/arch/msg/tsvwg/SOfCGp2DcqUJT9TCjP8kJDdWyyU/>
>>>>>>> Specifically, items relating to 3.1 and 4.1
>>>>>>> 
>>>>>>> -Greg
>>>>>>> 
>>>>>>> 
>>>>>>> On 5/27/24, 1:29 AM, "Christian Huitema" <[e-mail] <mailto:[e-mail]> <mailto:[e-mail] <mailto:[e-mail]>>> wrote:
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> On 5/27/2024 12:16 AM, Sebastian Moeller wrote:
>>>>>>>> Hi Christian,
>>>>>>>> 
>>>>>>>> 
>>>>>>>>> On 27. May 2024, at 08:48, Christian Huitema<[e-mail] <mailto:[e-mail]> <mailto:[e-mail] <mailto:[e-mail]>>> wrote:
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> On 5/26/2024 7:52 PM, Brian E Carpenter wrote:
>>>>>>>>>> Hi,
>>>>>>>>>> This is a brief review of draft-ietf-tsvwg-nqb-23. This is the first time I've read the draft for a very long time. It looks pretty good to me, but of course I have a few comments below. (I no longer subscribe to tsvwg, so please Cc me if appropriate.)
>>>>>>>>>> In 3.1 "Non-Queue-Building Behavior" we find:
>>>>>>>>>> "In contrast, Queue-Building (QB) microflows include those that use TCP or QUIC..."
>>>>>>>>>> I can easily imagine an NQB application that chooses to use a reliable transport layer even for a small, intermittent flow. So the implication of this phrase that only QB flows use a reliable transport seems wrong to me.
>>>>>>>>> We have a working group dedicated to "media over QUIC", and the resulting protocol will indeed be capable of managing NQB flows. As Brian notes, please revise that part!
>>>>>>>>> 
>>>>>>>>>> In 3.2 "Relationship to the Diffserv Architecture":
>>>>>>>>>> "in many cases the implementation of Diffserv PHBs has historically involved prioritization of service classes with respect to one another, which sets up the zero-sum game"
>>>>>>>>>> This is a very important remark (and of course is exactly what RFC2474 wanted to avoid), but a bit later we find:
>>>>>>>>>> "NQB is expected to be treated with the same priority as Default..."
>>>>>>>>>> Oh dear. Perhaps "NQB is expected to be treated similarly to Default..."
>>>>>>>>>> In 4.1 "Non-Queue-Building Sender Requirements"
>>>>>>>>>> "Microflows that are eligible to be marked with the NQB DSCP are typically UDP microflows that send traffic at a low data rate relative to typical network path capacities."
>>>>>>>>>> Or, as noted above, intermittent and low data rate TCP (or even QUIC) flows.
>>>>>>>>> +1. What matters is the media being carried, not the transport protocol.
>>>>>>>> [SM] Puzzled... IMHO all that matters is whether a flow is above its abstract capacity share or not. With abstract capacity share I mean not related to any kind of 'fairness', but whether that flow pushes the aggregate over the bottlenecks egress capacity or not.
>>>>>>>> If incoming rate > outgoing rate a queue builds up (assuming there is space for it) or packets need to be dropped.
>>>>>>>> A flow with a low share of the queued packets will contribute less than a flow with a high contribution to the queue, but contribute it will.
>>>>>>>> 
>>>>>>>> The draft actually proposes an elegant way past this dilemma:
>>>>>>>> 
>>>>>>>> The intent of the NQB DSCP is that it signals verifiable behavior that permits the sender to request differentiated treatment.
>>>>>>>> 
>>>>>>>> Where it IMHO falls short is in not actually defining this behavior in a way that is actually robustly and reliably enforceable.
>>>>>>>> 
>>>>>>>> However, that IMHO is not a show stopper, the fact that the draft recommends to completely give up on its principles for ease of deployment over existing WiFi is where I draw the line.
>>>>>>> 
>>>>>>> 
>>>>>>> Basically, the application that starts a flow with the proposed NQB mark
>>>>>>> is asserting that it will keep its traffic within some known envelope. I
>>>>>>> agree with you, Sebastian, that this only makes sense if this envelope
>>>>>>> is well defined, can be verified, and that if bugs or misbehavior cause
>>>>>>> the traffic to exceed the limits, such bugs or misbehavior are
>>>>>>> corrected. We may debate whether the behavior has to be enforced by an
>>>>>>> AQM, or whether it is OK to just combine real-time detection and post
>>>>>>> facto correction. But then, I don't think that the behavior is linked to
>>>>>>> the specific transport being used, whether UDP, QUIC, TCP or others.
>>>>>>> 
>>>>>>> 
>>>>>>> -- Christian Huitema