OT somewhat and on my beta noir, sorry! I am curious as to what if any, higher end products rfc8290 has appeared in already? It's got to be quite a lot over the past year, particularly on qualcomm and mediatek's wifi chips. I know of preseem and libreQos in middleboxes... a couple I can't talk about unless I find public info on it...
https://en.wikipedia.org/wiki/FQ-CoDel Comcast rolled out DOCSIS-pie this year also. Really compelling real-world study across a million boxes here: https://arxiv.org/abs/2107.13968 Very pretty graphs starting pp14. Anyway it's looking like pie and fq_codel are winners (unlike RED). but I'd totally settle for that BCP recommending some form of aqm be available in your document at the two points so far. A deeply philosophical discussion of what constitutes a host could however ensue. On Thu, Nov 25, 2021 at 6:57 AM Dave Taht <[email protected]> wrote: > > On Thu, Nov 25, 2021 at 6:46 AM Tim Chown <[email protected]> wrote: > > > > It’s in 4.4 (routers and L3 switches). Does it need to be in 4.1, Hosts? > > I'd like it to be available everywhere. :) > > fq_codel is already pretty universal in linux hosts. sch_fq is better > for a solely tcp-serving workloads where it can apply pacing more > directly, but what a "host" is, post kubernetes, post network > namespaces, with vms, with tunnels, vpns, with quic, etc, looks a lot > more like a router. > > There's a debate here - with 27 8x10 glossy pictures with circles and > arrows and a paragraph on the back of each one - making that point, > for a "host" - over here: > > https://github.com/systemd/systemd/issues/9725#issuecomment-413369212 > > > > > Tim > > > > > On 25 Nov 2021, at 14:43, Dave Taht <[email protected]> wrote: > > > > > > yes please. > > > > > > On Thu, Nov 25, 2021 at 3:36 AM Tim Chown <[email protected]> wrote: > > >> > > >>> On 23 Nov 2021, at 16:41, Dave Taht <[email protected]> wrote: > > >>> > > >>> On Tue, Nov 23, 2021 at 8:31 AM Tim Chown <[email protected]> wrote: > > >>>> > > >>>> Hi Dave, > > >>>> > > >>>>> On 23 Nov 2021, at 16:09, Dave Taht <[email protected]> wrote: > > >>>>> > > >>>>> It is perhaps selfish of me to really want active queue management, of > > >>>>> some form, as part of specifications for new equipment. > > >>>>> > > >>>>> https://datatracker.ietf.org/doc/rfc7567/ > > >>>> > > >>>> I would agree, but this doc is IPv6 requirements, while the RFC is > > >>>> generally applicable to v4 or v6? > > >>> > > >>> It's an and, not an or. > > >>> > > >>> Additionally useful treatments of the ipv6 flow header, and the > > >>> diffserv & ecn bits, the ability to shape or police traffic, would be > > >>> nice to have in a document that talks to the properties of switches > > >>> and routers. > > >> > > >> So we could for example in Section 4 in Optional at least add > > >> > > >> • Active Queue Management support [RFC7567] > > >> > > >> ? > > >> > > >> (Where AF and EF are listed for QoS) > > >> > > >> Tim > > >> > > >>> > > >>>> Tim > > >>>>> > > >>>>> On Tue, Nov 23, 2021 at 7:38 AM Tim Chown via ipv6-wg > > >>>>> <[email protected]> wrote: > > >>>>>> > > >>>>>> Hi Eric, > > >>>>>> > > >>>>>> > > >>>>>> Many thanks for your comments, we’ve updated the ‘living draft’ at > > >>>>>> https://docs.google.com/document/d/10HsfHDOIhUPIvGk9WP0azJiIsMVzQ49RsqWfnbNtceI/edit# > > >>>>>> And attached as PDF. > > >>>>>> > > >>>>>> In-line... > > >>>>>> > > >>>>>>> On 5 Nov 2021, at 07:52, Eric Vyncke (evyncke) <[email protected]> > > >>>>>>> wrote: > > >>>>>>> > > >>>>>>> Tim*2, Sander, Jan, and Merike, > > >>>>>>> > > >>>>>>> First of all, thank you for taking the pen to update this document. > > >>>>>>> As you kindly asked for comments, here are some > > >>>>>>> - page 2: 'fairly recent' won't age well ;-) > > >>>>>> > > >>>>>> Removed. > > >>>>>> > > >>>>>>> - page 4: all requirements are limited to performance, but should > > >>>>>>> it also include telemetry/monitoring ? Or is it implicit in the > > >>>>>>> list of RFC ? > > >>>>>> > > >>>>>> Agreed - we added mention of capabilities in a couple of places. > > >>>>>> > > >>>>>>> - page 4: what about systems to handle VMs and containers ? > > >>>>>> > > >>>>>> Out of scope. > > >>>>>> > > >>>>>>> - page 4: mobile devices have a *big difference* with normal host > > >>>>>>> though as they often have multiple interfaces active at the same > > >>>>>>> time. > > >>>>>> > > >>>>>> True, but out of scope. The document is about their connectivity to > > >>>>>> the enterprise infrastructure. We could note this, but currently do > > >>>>>> not. > > >>>>>> > > >>>>>>> - page 4: should we assume that Wi-Fi access points are 'normal > > >>>>>>> layer-2 switches' ? > > >>>>>> > > >>>>>> Added text to say consider as L2 consumer switch, see Section 3.1. > > >>>>>> > > >>>>>>> - page 6: I am surprised to see RFC 8415 DHCPv6 client as mandatory… > > >>>>>> > > >>>>>> Fair comment, as this could be something contentious. The only way > > >>>>>> we can think to avoid that is to include the DHCPv6 requirements > > >>>>>> conditionally, ie. “IF you need DHCPv6 then…” those requirements are > > >>>>>> required. So networks deploying with just RA for address > > >>>>>> configuration can avoid that. > > >>>>>> > > >>>>>>> - page 6: if not mistaken RFC 8200 now includes RFC 5722 and RFC > > >>>>>>> 8021 (so no need to add the latter in the requirements) > > >>>>>> > > >>>>>> Deleted 5722 and 8021. > > >>>>>> > > >>>>>>> - page 7: same surprise to see all DHCP-related requirements > > >>>>>> > > >>>>>> Also made into an “If DHCPv6 is needed then” > > >>>>>> > > >>>>>>> - page 7 and other: nice to list some MIB but I would expect some > > >>>>>>> YANG modules as well for enterprise/ISP devices > > >>>>>> > > >>>>>> RFC8504 covers this in16.2, should we say the same words here, as > > >>>>>> optional in each section? > > >>>>>> https://datatracker.ietf.org/doc/html/rfc8504#section-16.2 > > >>>>>> Thoughts? > > >>>>>> > > >>>>>>> - page 9: should Jen's RFC 9131 be added as optional ? > > >>>>>> > > >>>>>> Can do, in which sections? Presumably 4.1 and 4.4? > > >>>>>> > > >>>>>> Best wishes, > > >>>>>> Tim > > >>>>>> > > >>>>>> > > >>>>>> To unsubscribe from this mailing list, get a password reminder, or > > >>>>>> change your subscription options, please visit: > > >>>>>> https://lists.ripe.net/mailman/listinfo/ipv6-wg > > >>>>> > > >>>>> > > >>>>> > > >>>>> -- > > >>>>> I tried to build a better future, a few times: > > >>>>> https://wayforward.archive.org/?site=https%3A%2F%2Fwww.icei.org > > >>>>> > > >>>>> Dave Täht CEO, TekLibre, LLC > > >>>> > > >>> > > >>> > > >>> -- > > >>> I tried to build a better future, a few times: > > >>> https://wayforward.archive.org/?site=https%3A%2F%2Fwww.icei.org > > >>> > > >>> Dave Täht CEO, TekLibre, LLC > > >> > > > > > > > > > -- > > > I tried to build a better future, a few times: > > > https://wayforward.archive.org/?site=https%3A%2F%2Fwww.icei.org > > > > > > Dave Täht CEO, TekLibre, LLC > > > > > -- > I tried to build a better future, a few times: > https://wayforward.archive.org/?site=https%3A%2F%2Fwww.icei.org > > Dave Täht CEO, TekLibre, LLC -- I tried to build a better future, a few times: https://wayforward.archive.org/?site=https%3A%2F%2Fwww.icei.org Dave Täht CEO, TekLibre, LLC To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/ipv6-wg
