Hi Dave, Please see inline. On 2019-05-10 11:17, Dave Taht wrote: > On Mon, Apr 29, 2019 at 5:32 PM Magnus Westerlund > <magnus.westerlund@xxxxxxxxxxxx> wrote: >> Hi Dave, >> >> Thanks for bring this work to the IETF. Yes, I would also like to encourage you to discuss your proposal in TSVWG using the mailing list and eventually present this work at the next TSVWG meeting. However, there is not required to participate in-person. We frequently have remote presentations and from my experience that works well. I’m sure the TSVWG chairs can further advise you on this. > This is one of those replies that I had to sit on for a while because > it was so mind-boggling. > > If you haven't noticed a few hundred messages about reforming the ietf > on the IETF mailing list to allow remote participants to have *a vote* > in how the ietf operates, you might want to review those. I have noticed that discussion. Process changes are hard, and the one thing I am certain over is that we need to have an open discussion about what changes should happen to facilitate remote only participants to have nomcom eligibility, right to sign recall petitions etc. Remote participants are most definitely not on equal footing on that part. If you think the IESG is obstructionist in this discussion, then it comes from the position that if we would simply jump on something without ensuring consensus on things we equally would be called bad things. We can facilitate the discussion and ensure that it is given room. For example a virtual BOF for these topics do make sense. > > A remote presentation is not enough to get a vote in how the ietf operates. However, when it comes to be able to influence the technical work in a WG a remote participant do have a fair chance. The one to one discussions that happens in the hallways are hard to cover. That requires spending a lot of time trying to reach out to people between the meeting for those conversations. > > Remote participation on the mailing lists, in this case, was certainly > not enough. Externally it looked like the l4s/dualpi/tcpprague effort > was spiraling down the drain with a pesky FRAND patent, no integrated, > running code, and 4 as-yet unresolved theoretical problems weighing it > down. I don't know what your expectations where here from what I would consider a rather limited engagement you have had so far on the TSVWG mailing list. I don't share the same view of L4S, although I would have hoped for more rapid progress and more available running code. > > But... it really did feel like matters were being settled in smoky > back rooms when this set of drafts, pitched to the IETF as a (rather > dubious) experiment, when it came out (hours after we submitted our > SCE draft) that cablelabs had announced their new standard (no doubt > expecting a rubber stamp from the ietf) a few weeks prior, and had, > indeed, been working in secret for 16 months to take over the "last > half bit" of the ECN header for their own use. I have no insight into what has happened in CableLabs. However, it fairly obvious from mailing list traffic and presentations that Cablelabs had an interest in L4S. What I know is that we have discussed L4S for a significant time in IETF. There was a BOF at IETF 96 which resulted in the inclusion of the work in TSVWG. The framework for the experiment was discussed, documented and approved in RFC 8311. Yes, the specification of L4S as being developed have made slow progress, but it has been making progress. > > Radically enough, I do tend to think that the open source community > does need MUCH better *representation* within the ietf, and to > leverage Thomas Paine's writings, there should be "no standardization > without representation", particularly in cases where the code has to > be universally deployed. This requires actual IETF attendance, by the > coders or their representatives, at least presently. I definitely like more participation from people implementing the protocols in the IETF and Open Source contributors are important part of that. Certain things can most definitely be done on the mailing list and interacting with authors and being an author of proposals, even if not present. There are challenges of not being present at meetings when topics becomes controversial. Building a contact network is also more challenging when not present at the meetings. > > Unlike all the other conferences we attend, speakers are not > recompensed for their costs in the IETF, either. IETF is not a conference. We don't have speakers, we have participants that drives proposals. I do not know of any standardization forum where participants get reimbursed for contributing to the specifications. > > I still doubt that our new competing, backwards compatible alternate > proposal, will get any pull in various smoky backrooms, but being > there in person, giving a preso, and wandering the hallways still > seems to help. Especially... when the ideas and their implications are > so difficult to express to people outside the narrow field of > congestion control in the first place, and don't fit easily into an > RFC format without useful code, repeatable benchmarks, public > experiments and graphs as guides. Yes, it is an alternative proposal. Where both SCE and L4S desires to use the same half-bit of the ECN codepoint space. That is what makes this topic really hard as it appears difficult to run the solutions in parallel, at least outside of specific DSCPs, and thus especially for the Best Effort class. Your proposal has its challenges in respect to providing a clear specification of what SCE are and provide that supportive material that would sway people that your proposal are a better one. To my understanding the TSVWG chairs have been encouraging a constructive discussion on the matter. It might be that to reach maximum efficiency from your perspective on this matter you need to have representatives attend the upcoming meeting in person. Remote participant is an option as the previous email pointed out and will have some impact. However, I hope you see that there are a significant fairness issue for IETF as organization to provide monetary support to some participants and implicitly their proposals. I wish you luck in finding financial support, however I would kindly request that you don't use IETF's mailing lists for such requests. Cheers Magnus Westerlund (as TSV AD responsible for TSVWG) ---------------------------------------------------------------------- Network Architecture & Protocols, Ericsson Research ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Torshamnsgatan 23 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@xxxxxxxxxxxx ----------------------------------------------------------------------
