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

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

Hi Greg,

Thanks for this, your responses are fine for me, except for the points that others have raised already. I'll be glad to hear from Ruediger about the interaction with RFC 8100.

Regards
    Brian Carpenter

On 30-May-24 10:54, Greg White wrote:
> Hi Brian,
> 
> Thanks very much for your review.
> 
> See responses below [GW].
> 
> @Ruediger, one question for you below as well (Sec. 4.4 regarding RFC 8100).
> 
> -Greg
> 
> 
> 
> On 5/26/24, 8:53 PM, "Brian E Carpenter" <[e-mail] <mailto:[e-mail]>> 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.
> 
> [GW] I agree with your point.  The rest of the sentence was aiming to further clarify by stating "with Cubic, Reno or other ... congestion control algorithms that probe for the link capacity and induce latency and loss  ...." But, the key characteristic (inducing latency and loss) gets sort of buried behind the "TCP or QUIC" lead-in.   Maybe this would be better as:
> "In contrast, Queue-Building (QB) microflows include those that probe for the link capacity and induce latency and loss as a result, for example microflows that use Cubic, Reno or other TCP/QUIC congestion control algorithms in a capacity-seeking manner."
> 
> 
> 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..."
> 
> [GW] How about: "NQB is expected to be given the same forwarding preference as Default"?  This mimics the language used earlier in the section which you seemed to be ok with.
> 
> 
> 
> 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.
> 
> [GW] How about:  "Microflows that are eligible to be marked with the NQB DSCP are ones that send traffic at a low data rate relative to typical network path capacities."
> 
> 
> 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.
> 
> [GW] Fine.
> 
> 
> 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.
> 
> [GW] I'd also like to seek an opinion from Ruediger, who was the editor of RFC 8100, and a co-author of this draft.
>   
> 
> 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.
> 
> [GW] Ok
> 
> 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.)
> 
> [GW] The recommendations around traffic protection can be found in Section 5.2.  It discusses re-marking as an option and situations where it could be useful.
> 
> 
> Regards
> Brian Carpenter
> 
> 
> 
> 
>