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

[Sebastian Moeller <[e-mail]>]

Hi Christian,


> On 27. May 2024, at 08:48, Christian Huitema <[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.


Regards
	Sebastian


> 
> -- Christian Huitema
> 
>> In 4.3 "Aggregation of other DSCPs into the NQB PHB":
>> "[NOTE (to be removed by RFC-Editor): this section references the obsoleted RFC2598..."
>> I would leave that note in place; it's helpful to the reader.
>> 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, but David Black is probably the best person to comment on that.
>> In 7.3 "Wi-Fi Networks":
>> There are several references to what an implementation of RFC8325 should do, but there is no specific change to RFC8325. Either state exactly what is changed in the text of RFC8325, or remove the "Updates:" tag.
>> 9 "Implementation Status":
>> Thank you for including this.
>> In Appendix B "Comparison with Expedited Forwarding"
>> "NQB primarily recommends traffic protection located at each potential bottleneck, where actual queuing can be detected and where excess traffic can be reclassified into the Default PHB rather than dropping it."
>> It would be good to clarify that this does *not* mean re-marking the packet, just treating it as if it was marked as Default. (Assuming that's what you mean.)
>> Regards
>>    Brian Carpenter
>