Hi Ruediger, Thanks for your comments.
We are looking into adding support for buffer/burst in ms and percentages for rate. Also, I have forwarded the draft to TSVWG and will follow up for any comment/suggestion. Regards, Aseem From: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Date: Tuesday, March 20, 2018 at 4:12 AM To: asechoud <[email protected]<mailto:[email protected]>> Cc: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Subject: Comment on draft-asechoud-rtgwg-qos-model-03 Aseem, the current draft provides limited support for standard parameters supporting scheduling and WRED. The solution suggested by the authors is to allow for flexible vendor specific extensions. Vendor advice for many QoS configuration tasks often results in application of following generic formula: Assign_buffer_in_[ms]@bitrate to configure some buffer in [byte]. Percentages related to a rate my replace an absolute rate. This holds for the following configurations: * Policer / Burst * Shaper / Burst * Guaranteed Scheduler Rate / Queue depth (and WRED threholds) Further, an option might be useful to allow to configure a bitrate deviating from the guaranteed scheduler rate for dimensioning scheduler queue depth.. This makes sense if overbooking of a class is allowed. My proposal is to support the following input commands per shaper/policer/class.... in a generic way: * a buffer/burst in [ms] * a rate (either as a rate or as a percentage referring to a rate) And from there to calculate buffers in Byte. Providers preferring to configure in byte should of course be able to continue doing so, I don't suggest to prevent that. The advantage is as I mentioned above that this is a generic way of configuring a scheduler (queue depth and WRED)/policer/shaper. That may allow providers to specify a standard input determining at least major parts of the vendor specific parameters. I'd also like to suggest to present this work at TSVWG, as this may result in additional QoS configuration related feedback. Regards, Ruediger
_______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
