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

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

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, but doesn't police NQB at ingress, will be policed at egress by that peer. But that's not new, it really applies to every PHB except Default. So I think the text is OK as is.

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