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 <dave.taht@gmail.com> wrote:
On Thu, Nov 25, 2021 at 6:46 AM Tim Chown <Tim.Chown@jisc.ac.uk> 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 <dave.taht@gmail.com> wrote:
yes please.
On Thu, Nov 25, 2021 at 3:36 AM Tim Chown <Tim.Chown@jisc.ac.uk> wrote:
On 23 Nov 2021, at 16:41, Dave Taht <dave.taht@gmail.com> wrote:
On Tue, Nov 23, 2021 at 8:31 AM Tim Chown <Tim.Chown@jisc.ac.uk> wrote:
Hi Dave,
> On 23 Nov 2021, at 16:09, Dave Taht <dave.taht@gmail.com> 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 <ipv6-wg@ripe.net> wrote: >> >> Hi Eric, >> >> >> Many thanks for your comments, we’ve updated the ‘living draft’ at >> https://docs.google.com/document/d/10HsfHDOIhUPIvGk9WP0azJiIsMVzQ49RsqWfnbNt... >> And attached as PDF. >> >> In-line... >> >>> On 5 Nov 2021, at 07:52, Eric Vyncke (evyncke) <evyncke@cisco.com> 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