Will the scope of this work include DDoS? There are really three separate congestion type concerns:
1) Lawful good: Will comply with reasonable constraints to preserve the commons 2) Chaotic good: Is interested in preserving the commons but has limited interest in researching constraints themselves. 3) Chaotic evil: Will create congestion deliberately out of malice. A WG could potentially persuade some actors (e.g. myself) in (2) to move into (1) which is a win. But my bigger security concern is (3). The QUIC working group has surely done most of the work necessary to work out some reasonable rules of the road for new transport proposals. But QUIC is certainly not the last word in transport proposals, nor is most of that work written up in the published RFCs. While QUIC is an improvement on TLS for most applications, including Web Services, it is optimized for HTTP Web browsing, not Web service transactions. While HTTP can be used to do that, it is really not a good choice. HTTP is now a very large and complex protocol and it is optimized for one particular purpose. When writing a binding for a Web Service, I have to turn all that complexity off because it is irrelevant to my needs, then add a bunch more complexity. One of the constraints that is particularly frustrating is that HTTP is based on a request/response interaction while Web Services frequently require request/response*. Yes I know that I can try to squeeze all my needs into a protocol I helped to design three decades ago but I decided not to. Rather than trying to use HTTP for everything, it is time to write a transport/security layer that meets the needs of Web Services directly. Having some advice on how to avoid congestion would be helpful. On Fri, Jul 1, 2022 at 1:28 PM 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 <https://www.rfc-editor.org/rfc/rfc5033.html>, 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://github.com/martinduke/congestion-control-charter/ > 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 >
