Re: [Last-Call] [Tsv-art] Tsvart last call review of draft-ietf-rtgwg-qos-model-11

[Gorry Fairhurst <[e-mail]>]

On 06/12/2023 19:05, Colin Perkins via Datatracker wrote:
> Reviewer: Colin Perkins
> Review result: Ready with Nits
>
> This document has been reviewed as part of the transport area review team's
> ongoing effort to review key IETF documents. These comments were written
> primarily for the transport area directors, but are copied to the document's
> authors and WG to allow them to address any issues raised and also to the IETF
> discussion list for information.
>
> When done at the time of IETF Last Call, the authors should consider this
> review as part of the last-call comments they receive. Please always CC
> [e-mail] if you reply to or forward this review.
>
> I am not an expert on YANG or DiffServ, and I have not followed the development
> and discussion related to this draft. This review is hence necessarily written
> from a generalist transport perspective. Please accept my apologies if I touch
> on topics that have been considered before in the working group.
>
> The draft looks to be defining mechanisms to configure the use of existing QoS
> mechanisms and to report on their effects. As such, any new transport protocol
> impact would seem limited. The mechanisms described may make it easier to
> deploy QoS, but the QoS techniques exist and can be used irrespective of
> whether this draft is published.
>
> For AQM, this draft specifies configuration parameters for RED and WRED. These
> AQM algorithms have certainly been widely implemented and used, but there are
> more modern alternatives that have been defined in IETF and that are also
> starting to see use (e.g., PIE – RFC 8033, and several variants on CoDel – RFC
> 8289/8290). Has consideration been given to whether any other AQM algorithms
> should be included? Is the mechanism extensible to support these and other
> future AQM approaches? From a transport perspective I would not recommend use
> of RED or WRED today, since the alternatives perform better and are harder to
> misconfigure. Some discussion about extensibility and alternatives would be
> helpful.
>
> Similarly there are only two traffic classifiers specified, which may warrant
> an extension point.
>
> Otherwise, this seems broadly ready.
>
> Colin
>
>
> _______________________________________________
> Tsv-art mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tsv-art

I would like to add a few comments on definitions in this ID, following 
the TSV-ART review above, as a TSVWG Co-Chair (since TSVWG maintains the 
DiffServ Specs).

1. Remove duplicate deifinion?
DS behavior aggregate and BA are both defined, but I think they are the 
same? Maybe you could choose BA?

2. Cite RFC for BA:
Behavior Aggregates (BAs) are defined in [RFC4594].

3. Cite RFC for Diffserv and the associated IANA Registry
The Differentiated Services (Diffserv) architecture provides 
differentiated traffic forwarding based on the DSCP carried in the 
Diffserv field of the IP packet header [RFC2474]. A common set of DSCPs 
are defined for both IPv4 and IPv6, and both network protocols use a 
common IANA registry [DSCP-registry].

4. For avoidance of doubt, please could you also add:

The IETF first defined QoS using ToS precedence for IP packets in 
[RFC0791] and updated it to be part of the ToS field in [RFC1349]. Since 
1998, this practice has been deprecated by [RFC2474].

5. Cite RFC for ECN:

ECN is defined in [RFC3168].

6.
“or will be classified  based on source IPv4 address prefix.”
- Please update to include IPv6.
.
7. Section 3:please update to cite the definition in RFC 2474.
The architecture is defined in RFC 2475, while the definitions are 
provided in RFC 2474.

8. I confirm that RFC 2475 seems the correct reference for the colored 
marking.


Since there are many ways to describe Diffserv, it could be useful for 
the editors to take a quick look at the more recent definitions included 
in RFC9435 to see if any of these are appropriate. (This RFC was however 
published for other reasons and likely is not the best reference for 
generic DiffServ methods.)

Finally, I am sure there are people in TSVWG with a broad experience of 
implementing and configuring DiffServ, you may find it worthwhile to 
remind them of this LC (since some will not read RTGWG drafts).

Best wishes,
Gorry Fairhurst
(TSVWG Co-Chair)