On Wed, Aug 28, 2019 at 7:00 AM Bob Briscoe <research@xxxxxxxxxxxxxx> wrote:Yes, I got a student to add hooks for the Linux classification architecture (either adding more, or overriding the defaults) a couple of years ago, along with creating a classful structure. But his unfinished branch got left dangling once he graduated and is now way out of date. it's still our intention to take that direction tho.
Olivier, Dave,At the time of my code review of dualpi I had not gone back to review
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.
the NQB draft fully.
We can add support for NQB in the future, by expanding theYes, you'll find find folk are fans of being able to put tc (and ebpf)
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.
filters in front of various qdiscs for classification, logging, and/or
A fairly typical stanza is here:
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-02Hmmm... no. I think oliver's statement was correct.
NQB was put into the "call for adoption into tsvwg" state (
) 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:
While using up ECT1 in the L4S code as an identifier and not as aThat ship has sailed. You can consider it controversial if you want, but the tsvwg decided to use ECT(1) as an identifier for L4S after long discussions back in 2016. Years of a large number of people's work was predicated on that decision. So the dualpi2 code reflects the way the IETF is approaching this.
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)...
We're working on that - top priority now.
... 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.
It is, but Olivier recently found the elusive cause of the problem that made later versions bursty. So we're getting close.
Is the known to work reference codebase for "tcp prague" still 3.19 based?
Bob Briscoe http://bobbriscoe.net/
CTO, TekLibre, LLC