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

[Brian E Carpenter <[e-mail]>]

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.

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

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