[ipv6-wg] Latest draft for RIPE554-bis

On Fri, Nov 26, 2021 at 12:16 AM Eric Vyncke (evyncke)
<evyncke at cisco.com> wrote:
>
> Dave
>
> Out of curiosity, is it linked to the (controversial) L4S work at the IETF in the TSVWG ?

If I have any one regret it is turning on RFC3168-style ECN by default
in linux (at the 2012 behest of the
now L4S side). I would much rather we all move forward on recommending
deployments of now-proven
technologies using good ole drop, with now well-demonstrated
reductions in latency under load of 10-100x across many edge
technologies. My position on that debate is very very very nuanced but
rooted in (my perceived!) need for backward compatibility with the
field deployment (e.g. SCE). I would love operator input here... but
on another thread, please!

It's very "life of brian"-esq, in that I'd really like all to focus on
shipping the tech that demonstrably works, at least pointing out in
various RFP oriented standards documents that RFC7567 is
ietf-recommended as best current practice (
https://datatracker.ietf.org/group/aqm/documents/  ) and let the
market sort it out.

My second biggest regret in watching the deployments grow, is not
choosing a unique, google-able, identifier for PIE or Cake! My request
below is related to the difficulty in finding out what products have
shipped a modern AQM or FQ ("SQM") system, and getting data back as to
how well they are working.

For example, finding riverbed's cake implementation for their branch
office routers took some doing.

https://support.riverbed.com/bin/support/static/hgc5k5odj0e955sd2uk2qr4ir5/html/7h0cpt4lqflt1k1pfdpth18at9/sc_ug_html/index.html#page/sc_ug%2Fqos.html%23

DOCSIS-pie is also very very much "out there", but not enabled by
anyone except comcast at this point, to my knowledge.

On the rfc8290 front...

While some are using the name the bufferbloat project chose for the
core concepts ("Smart Queue Management") instead of or addition to
"QoS", I've documented three of the other trade names in the wikipedia
page, but not got around to documenting that the most common name for
it in the field being "optimize network for conferencing and gaming"
which is what eero and google wifi are using, at least.

My assumption, is that in this community believes, overprovisioning
was, is, and will remain the principal means for eliminating queuing
delay across your networks, and that all the fancy schmancy queueing
algos are needed only along the edge and on variable bandwidth
wireless technologies. Please feel free to educate me. On another
thread?

 I've got a bit of time off this week to edit wikipedia. And before
forking this convo to discuss "the battle of the bit",
please put this famous thanksgiving song on in the background:
https://www.youtube.com/watch?v=W5_8U4j51lI

thx

> Regards
>
> -éric
>
> On 25/11/2021, 16:16, "Dave Taht" <dave.taht at gmail.com> wrote:
>
>     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 at gmail.com> wrote:
>     >
>     > On Thu, Nov 25, 2021 at 6:46 AM Tim Chown <Tim.Chown at 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 at gmail.com> wrote:
>     > > >
>     > > > yes please.
>     > > >
>     > > > On Thu, Nov 25, 2021 at 3:36 AM Tim Chown <Tim.Chown at jisc.ac.uk> wrote:
>     > > >>
>     > > >>> On 23 Nov 2021, at 16:41, Dave Taht <dave.taht at gmail.com> wrote:
>     > > >>>
>     > > >>> On Tue, Nov 23, 2021 at 8:31 AM Tim Chown <Tim.Chown at jisc.ac.uk> wrote:
>     > > >>>>
>     > > >>>> Hi Dave,
>     > > >>>>
>     > > >>>>> On 23 Nov 2021, at 16:09, Dave Taht <dave.taht at 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 at ripe.net> 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) <evyncke at 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://mailman.ripe.net/
>     > > >>>>>
>     > > >>>>>
>     > > >>>>>
>     > > >>>>> --
>     > > >>>>> 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
>


-- 
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