Hi Gorry, Thanks for the feedback, I really appreciate it. we'll make sure that TSVWG is copied when RTGWG is to LC this draft.
Thanks, Yingzhen On Thu, Dec 7, 2023 at 5:03 AM Gorry Fairhurst <[email protected]> wrote: > 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 > > [email protected] 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 > > [email protected] > > 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. >
_______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
