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

[[e-mail]]

Hi Brian,

thanks for your comments.

Section 4.4: If NQB support is extended across a DiffServ domain boundary, the interconnected networks agreeing to support NQB SHOULD use the DSCP value 45 (decimal) for NQB at network interconnection, unless a different DSCP is explicitly documented in the TCA (Traffic Conditioning Agreement, see [RFC2475]) for that interconnection.

[RG] If RFC 8100 is agreed and operational and the provider interconnection link is no bottleneck, my suggestion would be to explicitly document usage of DSCP 5 (dec.) The sending party should re-mark NQB traffic to DSCP dec. 5 and the receiving party should classify NQB traffic by that DSCP.

[RG] This complies to Section 4.2. ... and "result in traffic marked with the NQB DSCP being aggregated into ... the Default / Elastic Treatment Aggregate (for [RFC8100] networks)." I assume the provider interconnection not to be a permanent bottleneck, if two network providers agree upon a TCA. So I don't think, that any text related to scheduling needs to be added, if RFC8100 is applied.
[RG] Section 4.4 is explicit on the desired behaviour, how the receiving domain should behave, when forwarding traffic to a third party domain: "To ensure reliable NQB PHB treatment on the entire path, the appropriate NQB DSCP [RG: 45] would need to be restored when forwarding to another network." I assume, this third party domain isn't interconnected by RFC 8100, to be explicit. I hope, this text is explicit enough too, not to require an additional statement.

If my first statement marked [RG] is useful, should text be added? Would you prefer text related to the other two statements as well?

Sorry for the delayed response (we've had a prolonged weekend) and regards,

Ruediger


-----Ursprüngliche Nachricht-----
Von: Brian E Carpenter <[e-mail]> 
Gesendet: Donnerstag, 30. Mai 2024 22:04
An: Greg White <[e-mail]>; [e-mail]
Cc: Gorry Fairhurst <[e-mail]>; Black, David <[e-mail]>
Betreff: [tsvwg] Re: Request to review diffserv spec: draft-ietf-tsvwg-nqb

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