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
tsv-art@xxxxxxxx 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
Tsv-art@xxxxxxxx
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)
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
