I filed an issue for rolling RMCAT into this charter:
https://github.com/martinduke/congestion-control-charter/issues/2

On Mon, Jul 4, 2022 at 12:37 AM Zaheduzzaman Sarker <
[email protected]> wrote:

>
>
> > On 1 Jul 2022, at 17:30, Dave Taht <[email protected]> wrote:
> >
> > I  wish rmcat was not considered out of scope in this charter. The
> > internet is a communications network, not just a file transfer
> > network.
>
> The  RMCAT WG still exits and can take work on standardising congestion
> control algorithms for interactive real-time communications, if needed.
> However, the working group activities have declined over the last couple of
> years and I am not sure how much interest/energy is there for new work (in
> genera)l for the real-time interactive traffic. The working group has
> published materials that can useful if discussions pops  up in relevant
> forums/working groups.
>
> I wish the congestion control algorithms RMCAT produced were used widely
> in WebRTC and other RTP based real-time communication systems. That is not
> the case yet. This also shows the fact that there should be honest interest
> not only in developing good congestion control algorithms but also
> deploying it.
>
>
> >
> > Also I find measurement tools that depend on obsolete 00's thinking -
> > like owamp - and rtp - very out of date when we should be thinking
> > about latency
> > and jitter in the sub 8ms range - if we're really serious about
> > building a metaverse. These days I am working with very fine grained
> > (3ms - preferably 1ms but no cloudy machine I have access to can
> > actually reliably generate packets from userspace on a 1ms interval)
> > active measurement data.
> >
> > As an example of what we learn from inspecting a network at 3ms
> > detail, see:
> https://forum.openwrt.org/t/cake-w-adaptive-bandwidth/108848/3142
> > for some current plots and a plotting script - of starlink's behaviors
> > using the irtt tool.
> >
> > I was thinking about doing a talk (in iccrg? here?) on how we think
> > about network traffic at too large a granularity (mbits/sec) in favor
> > of "steady kbit/ms" or "steady packets over ms" (SPOM).
>
> I would be interest in this kind of talks. If you have proposals we can
> pick venues.
>
>
> //Zahed
>
> >
> > On Fri, Jul 1, 2022 at 5:28 AM Martin Duke <[email protected]>
> wrote:
> >>
> >> Hello Transport Enthusiasts,
> >> (bcc: TCPM, QUIC, and ICCRG)
> >>
> >> Zahed and I would like to invite you to the TSVAREA meeting at IETF 114
> (Monday 13:30 local time), where we will be having a more action-oriented
> discussion than usual.
> >>
> >> TL;DR the way we do congestion control standards is written down in RFC
> 5033, and is no longer aligned with how congestion control innovation
> happens or the family of transport protocols that use standard congestion
> control. The IETF is largely irrelevant to new congestion control
> deployments. So we'll discuss a proposal to fix it. This meeting will have
> some BoF-like elements but it is not formally a BoF.
> >>
> >> In consultation with several stakeholders, we've devised a strategy to
> address this:
> >>
> >> * Colin Perkins, IRTF chair, has agreed to add at least one chair to
> ICCRG (I'm sure Colin would welcome volunteer candidates!). While retaining
> its hosting presentations role, there will be renewed emphasis on serving
> as a forum to produce experimental RFCs, with a charter update if necessary.
> >>
> >> * The Transport ADs are going to consider chartering a new IETF working
> group to update the administrative framework for congestion control
> standardization, and potentially adopt any proposals that are sufficiently
> mature for the standards track. We've formulated a proposed charter. Please
> consider it a starting point for discussion.
> >>
> https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-89f2a2da742ddce8&q=1&e=e6a9d612-3bda-4815-aac4-b5fd39764cb5&u=https%3A%2F%2Fgithub.com%2Fmartinduke%2Fcongestion-control-charter%2F
> >> I ask you to review this document before attending. It answers many of
> the questions you may already have.
> >>
> >> In Philadelphia, we hope to answer as many of the following questions
> as possible, in order:
> >> * Is there rough consensus on the problem to solve?
> >> * Are the deliverables right?
> >> * Are there people willing to take responsibility for those
> deliverables? (The meeting is over if the answer is "no")
> >> * Does the proposed charter need changes?
> >> * Is anyone especially excited to chair this WG?
> >>
> >> Please come to Philadelphia having thought about these questions and
> prepared to answer them. You are also welcome to share thoughts on the
> tsv-area list; all other recipients have been Bcced: so that the rest of
> the thread will go to only that list. Subscribe if you want to track the
> discussion.
> >>
> >> Although charter wordsmithing is somewhat premature, you are also
> welcome to file issues and PRs on the github linked above.
> >>
> >> See you there,
> >> Martin and Zahed
> >> Your friendly Transport ADs
> >
> >
> >
> > --
> > FQ World Domination pending:
> https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-52d7a4659d6bb6c6&q=1&e=e6a9d612-3bda-4815-aac4-b5fd39764cb5&u=https%3A%2F%2Fblog.cerowrt.org%2Fpost%2Fstate_of_fq_codel%2F
> > Dave Täht CEO, TekLibre, LLC
>
>

Reply via email to