From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10089.outbound.protection.outlook.com [40.107.1.89]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id B10603B29E for ; Fri, 10 May 2019 07:35:31 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=LORavvyKQxRhvVvkAGl5I6buTnwO0e41B8vQzav3GQE=; b=gaw4f49t67EntlmE/Z/zkEcOCr5ptQ2cJj2RNdzKdQ3Fur9g8q6BkwZCkI/EFNlY8MgWmPUwQR/3Kop3AtURcGRvncUzyA7EYp7vVUGwJf7Te0Va81ldb0b6E6k7tKlfx8oYCzwm29eaQPSUZ/a4/e53dCEH5sl0vaFU86yNTlA= Received: from HE1PR0701MB2522.eurprd07.prod.outlook.com (10.168.128.149) by HE1PR0701MB2460.eurprd07.prod.outlook.com (10.168.128.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1900.7; Fri, 10 May 2019 11:35:29 +0000 Received: from HE1PR0701MB2522.eurprd07.prod.outlook.com ([fe80::b161:fb77:e4ea:4723]) by HE1PR0701MB2522.eurprd07.prod.outlook.com ([fe80::b161:fb77:e4ea:4723%3]) with mapi id 15.20.1878.022; Fri, 10 May 2019 11:35:29 +0000 From: Magnus Westerlund To: Dave Taht CC: The IESG , ECN-Sane , IETF Discussion Mailing List , tsvwg IETF list Thread-Topic: travel funds for ietf for the next SCE talk? Thread-Index: AQHU/cneO/MepbMfKEimxUTyWE/Y/Q== Date: Fri, 10 May 2019 11:35:29 +0000 Message-ID: References: Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=magnus.westerlund@ericsson.com; x-originating-ip: [192.176.1.87] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 2ba6ba0a-52f4-4aad-2a3d-08d6d53b9aa1 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(2017052603328)(7193020); SRVR:HE1PR0701MB2460; x-ms-traffictypediagnostic: HE1PR0701MB2460: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0033AAD26D x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(346002)(366004)(136003)(39860400002)(376002)(189003)(199004)(25786009)(4326008)(6116002)(3846002)(256004)(478600001)(14454004)(86362001)(14444005)(486006)(44832011)(446003)(476003)(53936002)(5660300002)(6246003)(9686003)(6506007)(316002)(66446008)(71190400001)(55016002)(81156014)(71200400001)(6436002)(99286004)(66946007)(73956011)(66556008)(76116006)(6916009)(64756008)(53546011)(66476007)(7696005)(54906003)(66066001)(229853002)(76176011)(561944003)(2906002)(68736007)(102836004)(26005)(8936002)(8676002)(186003)(81166006)(305945005)(7736002)(52536014)(33656002)(74316002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR0701MB2460; H:HE1PR0701MB2522.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: GRPPobMBRNvI4AguWNtzygG0kkwI7urQ57XmdiQFdoVTb68txsuLy7Cs4hxWXMmQSUgs435PbFIMy/DNJhpLUs/O5+Ajx6Xicc4qf0YCw0hjzYQ001Wvg+bRspx9Ieu5KlU9fLjN93RTxkgMaVbk3rYLc7nGQ3JkMJOmdyNM4ZLUj6Ri3QsgrCRsR+VNOZDQhO4/jQV9KtgBc52Z7hVDlaRgISFdMVlm9VDKW8MaVooSZ27iVAlsHfzi7AkfsJwWCx/IEVb/t14opcnsMfc3Bh9q1TEPs0SvtR8ntcr9y/r9bpvMlqohBbXb12+EqsR9wAChEBJEvAu48IyXdQcromhSndmvXCW9cW/1cSwmkSnY5Ixd33lqxyIG96lYy/vlFYdfXqzWmpsM6APRcAI3y3VZQOctdbA/zO/IzqyqRxQ= Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 2ba6ba0a-52f4-4aad-2a3d-08d6d53b9aa1 X-MS-Exchange-CrossTenant-originalarrivaltime: 10 May 2019 11:35:29.2122 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2460 Subject: Re: [Ecn-sane] travel funds for ietf for the next SCE talk? X-BeenThere: ecn-sane@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussion of explicit congestion notification's impact on the Internet List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 May 2019 11:35:32 -0000 Hi Dave,=0A= =0A= Please see inline.=0A= =0A= On 2019-05-10 11:17, Dave Taht wrote:=0A= > On Mon, Apr 29, 2019 at 5:32 PM Magnus Westerlund=0A= > wrote:=0A= >> Hi Dave,=0A= >>=0A= >> Thanks for bring this work to the IETF. Yes, I would also like to encour= age you to discuss your proposal in TSVWG using the mailing list and eventu= ally present this work at the next TSVWG meeting. However, there is not req= uired to participate in-person. We frequently have remote presentations and= from my experience that works well. I=92m sure the TSVWG chairs can furthe= r advise you on this.=0A= > This is one of those replies that I had to sit on for a while because=0A= > it was so mind-boggling.=0A= >=0A= > If you haven't noticed a few hundred messages about reforming the ietf=0A= > on the IETF mailing list to allow remote participants to have *a vote*=0A= > in how the ietf operates, you might want to review those.=0A= =0A= I have noticed that discussion. Process changes are hard, and the one=0A= thing I am certain over is that we need to have an open discussion about=0A= what changes should happen to facilitate remote only participants to=0A= have nomcom eligibility, right to sign recall petitions etc. Remote=0A= participants are most definitely not on equal footing on that part. If=0A= you think the IESG is obstructionist in this discussion, then it comes=0A= from the position that if we would simply jump on something without=0A= ensuring consensus on things we equally would be called bad things. We=0A= can facilitate the discussion and ensure that it is given room. For=0A= example a virtual BOF for these topics do make sense.=0A= =0A= >=0A= > A remote presentation is not enough to get a vote in how the ietf operate= s.=0A= =0A= However, when it comes to be able to influence the technical work in a=0A= WG a remote participant do have a fair chance. The one to one=0A= discussions that happens in the hallways are hard to cover. That=0A= requires spending a lot of time trying to reach out to people between=0A= the meeting for those conversations. =0A= =0A= =0A= >=0A= > Remote participation on the mailing lists, in this case, was certainly=0A= > not enough. Externally it looked like the l4s/dualpi/tcpprague effort=0A= > was spiraling down the drain with a pesky FRAND patent, no integrated,=0A= > running code, and 4 as-yet unresolved theoretical problems weighing it=0A= > down.=0A= =0A= I don't know what your expectations where here from what I would=0A= consider a rather limited engagement you have had so far on the TSVWG=0A= mailing list. I don't share the same view of L4S, although I would have=0A= hoped for more rapid progress and more available running code.=0A= =0A= =0A= >=0A= > But... it really did feel like matters were being settled in smoky=0A= > back rooms when this set of drafts, pitched to the IETF as a (rather=0A= > dubious) experiment, when it came out (hours after we submitted our=0A= > SCE draft) that cablelabs had announced their new standard (no doubt=0A= > expecting a rubber stamp from the ietf) a few weeks prior, and had,=0A= > indeed, been working in secret for 16 months to take over the "last=0A= > half bit" of the ECN header for their own use.=0A= =0A= I have no insight into what has happened in CableLabs. However, it=0A= fairly obvious from mailing list traffic and presentations that=0A= Cablelabs had an interest in L4S. What I know is that we have discussed=0A= L4S for a significant time in IETF. There was a BOF at IETF 96 which=0A= resulted in the inclusion of the work in TSVWG. The framework for the=0A= experiment was discussed, documented and approved in RFC 8311. Yes, the=0A= specification of L4S as being developed have made slow progress, but it=0A= has been making progress.=0A= =0A= =0A= >=0A= > Radically enough, I do tend to think that the open source community=0A= > does need MUCH better *representation* within the ietf, and to=0A= > leverage Thomas Paine's writings, there should be "no standardization=0A= > without representation", particularly in cases where the code has to=0A= > be universally deployed. This requires actual IETF attendance, by the=0A= > coders or their representatives, at least presently.=0A= =0A= I definitely like more participation from people implementing the=0A= protocols in the IETF and Open Source contributors are important part of=0A= that. Certain things can most definitely be done on the mailing list and=0A= interacting with authors and being an author of proposals, even if not=0A= present. There are challenges of not being present at meetings when=0A= topics becomes controversial. Building a contact network is also more=0A= challenging when not present at the meetings.=0A= =0A= =0A= >=0A= > Unlike all the other conferences we attend, speakers are not=0A= > recompensed for their costs in the IETF, either.=0A= =0A= IETF is not a conference. We don't have speakers, we have participants=0A= that drives proposals. I do not know of any standardization forum where=0A= participants get reimbursed for contributing to the specifications.=0A= =0A= >=0A= > I still doubt that our new competing, backwards compatible alternate=0A= > proposal, will get any pull in various smoky backrooms, but being=0A= > there in person, giving a preso, and wandering the hallways still=0A= > seems to help. Especially... when the ideas and their implications are=0A= > so difficult to express to people outside the narrow field of=0A= > congestion control in the first place, and don't fit easily into an=0A= > RFC format without useful code, repeatable benchmarks, public=0A= > experiments and graphs as guides.=0A= =0A= =0A= Yes, it is an alternative proposal. Where both SCE and L4S desires to=0A= use the same half-bit of the ECN codepoint space. That is what makes=0A= this topic really hard as it appears difficult to run the solutions in=0A= parallel, at least outside of specific DSCPs, and thus especially for=0A= the Best Effort class.=0A= =0A= Your proposal has its challenges in respect to providing a clear=0A= specification of what SCE are and provide that supportive material that=0A= would sway people that your proposal are a better one. To my=0A= understanding the TSVWG chairs have been encouraging a constructive=0A= discussion on the matter.=0A= =0A= It might be that to reach maximum efficiency from your perspective on=0A= this matter you need to have representatives attend the upcoming meeting=0A= in person. Remote participant is an option as the previous email pointed=0A= out and will have some impact. However, I hope you see that there are a=0A= significant fairness issue for IETF as organization to provide monetary=0A= support to some participants and implicitly their proposals. I wish you=0A= luck in finding financial support, however I would kindly request that=0A= you don't use IETF's mailing lists for such requests.=0A= =0A= =0A= Cheers=0A= =0A= Magnus Westerlund =0A= (as TSV AD responsible for TSVWG)=0A= =0A= ----------------------------------------------------------------------=0A= Network Architecture & Protocols, Ericsson Research=0A= ----------------------------------------------------------------------=0A= Ericsson AB | Phone +46 10 7148287=0A= Torshamnsgatan 23 | Mobile +46 73 0949079=0A= SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com=0A= ----------------------------------------------------------------------=0A= =0A=