On Wed, Aug 28, 2019 at 7:00 AM Bob Briscoe <resea...@bobbriscoe.net> wrote: > > Olivier, Dave, > > On 23/08/2019 13:59, Tilmans, Olivier (Nokia - BE/Antwerp) wrote: > > as best as I can > tell (but could be wrong) the NQB idea wants to put something into the > l4s fast queue? Or is NQB supposed to > be a third queue? > > NQB is not supported in this release of the code. But FYI, it's not for a > third queue.
At the time of my code review of dualpi I had not gone back to review the NQB draft fully. > We can add support for NQB in the future, by expanding the > dualpi2_skb_classify() function. This is however out of scope at the > moment as NQB is not yet adopted by the TSV WG. I'd guess we may want more > than just the NQB DSCP codepoint in the L queue, which then warrant > another way to classify traffic, e.g., using tc filter hints. Yes, you'll find find folk are fans of being able to put tc (and ebpf) filters in front of various qdiscs for classification, logging, and/or dropping behavior. A fairly typical stanza is here: https://github.com/torvalds/linux/blob/master/net/sched/sch_sfq.c#L171 to line 193. > The IETF adopted the NQB draft at the meeting just passed in July, but the > draft has not yet been updated to reflect that: > https://tools.ietf.org/html/draft-white-tsvwg-nqb-02 Hmmm... no. I think oliver's statement was correct. NQB was put into the "call for adoption into tsvwg" state ( https://mailarchive.ietf.org/arch/msg/tsvwg/fjyYQgU9xQCNalwPO7v9-al6mGk ) in the tsvwg aug 21st, which doesn't mean "adopted by the ietf", either. In response to that call several folk did put in (rather pithy), comments on the current state of the NQB idea and internet draft, starting here: https://mailarchive.ietf.org/arch/msg/tsvwg/hZGjm899t87YZl9JJUOWQq4KBsk For those here that are not familiar with IETF processes (and there are many!) there are "internet drafts" that may or may not become working group items, that if they become accepted by the working group may or may not evolve to become actual RFCs. Unlike lkml usage where we use RFC in its original meaning as a mere request for comments, there are several classes of IETF RFC - standards track, experimental, and informational - whenever they are adopted and published by the ietf. There are RFCs for how they do RFCs, and BCPs and other TLAs, and if you really want to know more about how the ietf processes actually work, please contact me off list. Anyway... Much of the experimental L4S architecture itself (of which NQB MAY become part, and dualpi/tcpprague/etc are) is presently an accepted tsvwg wg item with a list of 11 problems on the bug database here ( https://trac.ietf.org/trac/tsvwg/report/1?sort=ticket&asc=1&page=1 ). IMHO it's not currently near last call for standardization as a set of experimental RFCs. L4S takes advantage of several RFCs that have indeed been published as experimental, notably, RFC8311, which too few have read as yet. While using up ECT1 in the L4S code as an identifier and not as a congestion indicator is very controversial for me ( https://lwn.net/Articles/783673/ ), AND I'd rather it not be baked into the linux api for dualpi should this identifier not be chosen by the wg (thus my suggestion of a mask or lookup table)... ... I also dearly would like both sides of this code - dualpi and tcp prague - in a simultaneously testable and high quality state. Without that, many core ideas in dualpi cannot be tested, nor objectively evaluated against other tcps and qdiscs using rfc3168 behavior along the path. Multiple experimental ideas in RFC8311 (such as those in section 4.3) have also not been re-evaluated in any context. Is the known to work reference codebase for "tcp prague" still 3.19 based? > The draft requests 0x2A (decimal 42) as the DSCP but, until the IETF > converges on a specific DSCP for NQB, I believe we should not code in a > default classifier anyway. > > > > Bob > > -- > ________________________________________________________________ > Bob Briscoe http://bobbriscoe.net/ -- Dave Täht CTO, TekLibre, LLC http://www.teklibre.com Tel: 1-831-205-9740
