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

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 <gorry@erg.abdn.ac.uk> 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
> > tsv-art@ietf.org 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@ietf.org
> > 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.
>