[Ecn-sane] travel funds for ietf for the next SCE talk?

[Dave Taht]

On Fri, May 10, 2019 at 1:35 PM Magnus Westerlund
<magnus.westerlund at ericsson.com> wrote:
>
> 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 at ericsson.com> 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

I don't consider the IESG to be an entity with one mind.

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

Reform from within moves slowly.

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

Most of my interactions pre-date that work, on the aqm mailing list,
that we closed in part, because it seemed the aqm work had moved to
maintenence mode. We were off creating and shipping code, in qty (10s)
of millions, based on the accepted standards. Things had got stable
enough after releasing sch_cake to start considering an rfc8290bis
with what we'd learned from shipping all that code, in real products,
particularly on wifi, and to take a harder look at ecn, in general.

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

It was the total lack of any integrated useful code from the L4S
people, the dodgy benchmarks, lack of third party verification of the
benchmarks, and the long-nagging issues never resolved on the IETF AQM
mailing list that kicked off the ecn-sane design group (
https://www.bufferbloat.net/projects/ecn-sane/wiki/ ) and its charter
last august. SCE is just the first of several outputs of that project.
There are several other projects going on in various states of
completion which we'll bring to the ietf once the code is in a usuable
state, or the papers gone through peer review.

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

And I would like more representation. I've largely stayed out of those
threads, because, really, I vastly prefer to just do the technical
stuff. I hope that progress is made.

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

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

To clarify, I should not have said recompense. Elsewhere, speakers are
usually not charged conference fees when speaking. Their other costs
they eat.

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

Yes, but 'round here, it's running code first, specs later. Usually.

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

My request here was informational. We got offers of airmiles from two
ietfers, and that's a help. We're pursuing other sources of travel
funds.

There will be no further financial requests by us here, and this ends
this thread, as far as I'm concerned.

>
>
> 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 at ericsson.com
> ----------------------------------------------------------------------
>


-- 

Dave Täht
CTO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-831-205-9740