I do not envision DDoS as being in scope, no. I'm not 100% sure what you are looking for, but RFC 8085 has general guidance for bespoke congestion controls. If people feel that document is outdated (I do not), that would certainly be in scope for the proposed WG.
As for designing a whole new transport/security layer, that is certainly not in scope. On Fri, Jul 1, 2022 at 6:10 AM Phillip Hallam-Baker <[email protected]> wrote: > 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 >> >
