From nobody Fri Nov 20 01:27:24 2020 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31E193A1B00 for ; Fri, 20 Nov 2020 01:27:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.649 X-Spam-Level: X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M4v4WnJhac_0 for ; Fri, 20 Nov 2020 01:27:20 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 447383A1AFE for ; Fri, 20 Nov 2020 01:27:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1605864419; bh=1i9NVBV0wTN9cj7OYg9xHGgvSXhUuzoGWcsbzNHN/zE=; h=X-UI-Sender-Class:Subject:From:In-Reply-To:Date:Cc:References:To; b=UvOa5E7q2JPu1C49QitsJTDyiwJX7KnpSLqXXszNOhu6aFq3DJ8zzMrL2XVSVKUly XKEirNqm5Pu4JtvYJQMO4LCIMJt1vUarbnNRRWsyPxjtfdF869ASAQyEgCcfW1mDZt swGARXhmZIBQrS8/gmXRSYfrLcgdTCUTPO+fJ38I= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.250.102] ([134.76.241.253]) by mail.gmx.com (mrgmx105 [212.227.17.168]) with ESMTPSA (Nemesis) id 1Ml6qC-1jz2Mh2Vsi-00lUYA; Fri, 20 Nov 2020 10:26:59 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.17\)) From: Sebastian Moeller In-Reply-To: Date: Fri, 20 Nov 2020 10:26:57 +0100 Cc: Lars Eggert , tsvwg IETF list Content-Transfer-Encoding: quoted-printable Message-Id: References: <5dff4f73463c2a7e7cc8dc8255ae9825e78f4c11.camel@petri-meat.com> <4FF8800F-B618-4818-AF5E-1E997EA9FBF3@eggert.org> <3EAC47AC-5937-4DB2-8B3C-D8C8A4459FBA@eggert.org> To: Ingemar Johansson S X-Mailer: Apple Mail (2.3445.104.17) X-Provags-ID: V03:K1:vJHScxfrgQq6oco2ulrpn+rwobfAo+clFHVmWmoERKbNO3CV2hI k+8DAgfj+cWDoyuRDnbTd5MDECBmfDW6qDB5adZU82zcizt84UGvxeM4IAy/Ac8Vmu3B7PA KY4lpPMsOA/GpIu9hNa/kiHG08yDAX7zkVaAeYtOg1G3YCB/KUBnxcAXjfZqKsXohrBxekN /wHVf9WpYLvwHjzz9oA6A== X-UI-Out-Filterresults: notjunk:1;V03:K0:2W1qpTElXBE=:T4xe3fiMUprUJGPzN2JZhd OneoqvftQyrlbnfL1lZ3LIOlYpnTI4xR4GFM0uypN9SfGcw3X9wjLNTLLPCv1jGPcU6MZr/8d bCSUrzBVMkYOiTUYRSTAu4J5df2bl2rx+DfxyAqxH1UUkwzROzibkCDT8N+xf5Q5mwgnWnlgZ xxJ5XNVNVjvx4V8iWrAeOxsxQGBk5bERFiA+Wk6dpMw70C/7rUKK61GOxJKD3WHgzCuOOETJa 2kEFg223tDG6TGlk9JwQ2ihmXypYMDIORoXnVcvYrWPzNaz6xxbMh/zt5vpyddnAfyshgcxJw QD5aAa/5PAuTj9XIS5cO0zMtHQmN1+vJ52Jon1jzpxNR0ey1RNuXbJoJyk23yhkYlL3aBpk5V GxckevZ8IQhy0REeAddfJ4baeqGP3y4MQT71yH31FyeOudHnzjSmveF6qE06zssOOJM1sN1oy +WC8Dt5hjVXK/heqnCCpqyizXP2vX/TrgGLoc/291bwxAxzfkJrgWYDWCUhAwW8v/HculUfUF 4dgXeXoOvARrsY7Hz2iG4qcYlh7L35vFfvz36Ekw3P+tnAYx14ok5IocCs+faoyUuPENQ9pTD Z6BkWAML6LTn5KcJY7Vs3T39vZZ1fQQ8abeDB2kriCrTW8HXAJIMdWaWCLMHa/6ORvvatJe3i WoLaLkBh/8eqb6v0GkYCgiNPyqnH4FFv98AiKzdJwTdXv7gujqKvnGTZBlvy+BWUrbi1KvkR5 9VSg19qahJLzQR46dA6hSWdVHSqZdznOBUO2/4Yq5o+F4wB2UWVKT//Z7h14CpO2k02uZQnB6 g6WYPHIKWcwRBrHZRqfytEyyn+d7VbnEkK1YXU2QMo51U70vKxA4wTtn+Z3iYK6WvF19PNXyc +6XLL4ozdwD5fdqu3cMqct9j9lLW9+6B8O1QiBqXfX5eSZP5ArTuzn3Atp+BXAFh34h1c0AI3 SwxjEZN6ClP0J7Ke3vtR+ovo/85ZiWlo= Archived-At: Subject: Re: [tsvwg] Reasons for WGLC/RFC asap X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2020 09:27:23 -0000 Hi Ingemar, more below in-line, prefixed [SM]. Tl;dr: We are discussing whether L4S operational safety can be achieved = by requiring/expecting that all existing network nodes will be updated = in time to fix up the safety gaps the current L4S design and = implementation introduced.=20 > On Nov 20, 2020, at 10:10, Ingemar Johansson S = wrote: >=20 > Hi Sebastian.=20 >=20 > I appears to me that we have had this discussion for 6 months of more = and it > is quite obvious that we can agree to disagree.=20 [SM] Ingemar, we are talking about hard facts here, that will = not change whether you accept them or not. There are no "alternative" = facts in reality. Either you are right, and all relevant network nodes = (including all CPE/home-routers) can be updated to accommodate L4S' new = demands on the network layers in sufficient time, or they can not. The = conservative prediction is that they can and will not (unless we are = talking about a time frame for starting the L4S roll-out of another = decade). You say, that is wromg and it can be done mich quicker, and = hence L4S can skip safety steps. Fine, now proof that your prediction is = likely and we can talk. But continuously claiming other peoples updates = will safeL4S' posterior without giving data that supports that = prediction is simply the same old engineerng by wishful thinking that I = have complained about in the past. > I don't see that the potential audience in this WG will become much = wiser if > we continue the discussion for yet another 6 months or more.=20 [SM] This is why you need not to simply repeat your assertions = and conviction, but present data that convince others that your view = holds merit and is not sinply taken because it is convenient to push L4S = through this WG's process. > My standpoint remains that these issues are to be addressed during the = L4S > experiment.=20 [SM] Tat is a tall order to add to the L4S experiment, solving = the existing critical update and security issue that afflicts = home-routers (and similarly IoT)...=20 >=20 > And.. to help this experiment gain traction also outside IETF it is > necessary that the L4S draft have RFC status. [SM] That is conjecture, sorry. You are trying to make the WG = "ratify" the current L4S drafts by implying that 3GPP is currentky = up-help by lack of RFC status, which seems not exactly true. IIUC 3GPP = has in no way committed to L4S, it is just you (and maybe others) that = want to make it that way. No doubt, that for this endeavor RFC status = could be helpful, but please do not paint that as an already sorted and = settled 3GPP requirement. Best Regards Sebastian >=20 > /Ingemar >=20 >=20 >> -----Original Message----- >> From: Sebastian Moeller >> Sent: den 20 november 2020 09:34 >> To: Ingemar Johansson S >> Cc: Lars Eggert ; tsvwg IETF list >> Subject: Re: [tsvwg] Reasons for WGLC/RFC asap >>=20 >> Hi Ingemar, >>=20 >>=20 >>> On Nov 20, 2020, at 09:22, Ingemar Johansson S >> wrote: >>>=20 >>> Hi >>>=20 >>> My take is that network equipment need to be upgraded for other >>> reasons than AQM functionality. >>=20 >> [SM] In the home router space that time point often only comes = when >> either: >> 1) the old device ceases to work/operate at all (block smoke) >> 2) the old device is not compatible with the access tech anymore = (ADSL >> router on VDSL2 plant) >>=20 >> These have time frames on the order of 5-15 years, if you are in for = the > long >> haul, you might be fine, but banking on that for operational safety = is a > gamble >> you undertake with somebody else's quality of internet access... >>=20 >>=20 >>> And then we have the case that network gear becomes old or breaks = down >>> (my home WiFi routers have been fragged by lightning twice). >>=20 >> [SM] Exactly, but that does not have reliable time constants to > predict >> when the fleet currently in service is going to be replaced, no? >>=20 >>=20 >>> No I don't have hard numbers >>=20 >> [SM] Which all of us knew... >>=20 >>> but I don't see that lack of knowledge about how for instance edge >>> routers are equipped and how upgradeable they are, should to be used >>> as an argument against WGLC for the L4S drafts (that target >>> experimental status). >>=20 >> [SM] But universal deployment. Sorry, as long as L4S has > side-effects >> in the real internet these need to be taken into consideration, > independent >> whether standards or experimental track RFCs are sought. The critical > issue >> here is not word in an RFC or whether there exists an RFC at al, but = what >> happens in the real world with non-ETC(1) data flows. >>=20 >>=20 >>> This applies also to the VPN tunnels discussion in a separate = thread. >>> These potential issues can be a part on the L4S experiment and >>> solutions can be documented as a result of this, but it is not >>> necessarily so that L4S need to adapt to all possible issues. >>=20 >> [SM] Again, L4S wants something special, the exclusive right to = one >> rate IP header code point, and the permit to run rough-shed over = existing > CE >> users, which exist in the real world. The least to be expected from = L4S is > to >> demonstrate that its un-doubted negative side-effects are = sufficiently >> controlled to "do no harm" to the existing internet. The way to do = that is > not >> to argue ad infinitum in a mailing list why you BELIEVE that these > concerns >> don't matter, but to run experiments and show empirical data = demonstrating >> these concerns can be safely put to rest. >> As S. Blake explained (again) to ru these experiments over the > existing >> internet, no RFC is required and using carefully selected DSCPs and = SLA's > the >> participating partners can make sure to not affect unsuspecting = parties > during >> those experiments. >>=20 >> Best Regards >> Sebastian >>=20 >>=20 >>>=20 >>> /Ingemar >>>=20 >>>> -----Original Message----- >>>> From: Sebastian Moeller >>>> Sent: den 20 november 2020 08:52 >>>> To: Ingemar Johansson S >>>> Cc: Lars Eggert ; tsvwg IETF list >>>> Subject: Re: [tsvwg] Reasons for WGLC/RFC asap >>>>=20 >>>> Hi Ingemar, >>>>=20 >>>> a correction below. >>>>=20 >>>>=20 >>>>> On Nov 19, 2020, at 15:24, Ingemar Johansson S >>>> wrote: >>>>>=20 >>>>> Hi >>>>>=20 >>>>> Please see inline [IJ] >>>>>=20 >>>>> /Ingemar >>>>>=20 >>>>>> -----Original Message----- >>>>>> From: Lars Eggert >>>>>> Sent: den 19 november 2020 14:10 >>>>>> To: Ingemar Johansson S >>>>>> Cc: Steven Blake ; tsvwg IETF list >>>>> >>>>>> Subject: Re: [tsvwg] Reasons for WGLC/RFC asap >>>>>>=20 >>>>>> Hi, >>>>>>=20 >>>>>> On 2020-11-19, at 14:36, Ingemar Johansson S >>>>>> wrote: >>>>>>> The only way is see is that the L4S drafts are moved to WGLC, = then >>>>>>> people will hopefully read the drafts and come with requests for >>>>>>> clarifications where needed. Until then you can only expect more >>>>>>> of the same long incomprehensible discussion threads until = March, >>>>>>> when we will repeat the same process >>>> again. >>>>>>=20 >>>>>> to clarify: I don't have opinions about the L4S drafts. I haven't >>>>>> read >>>>> them in a >>>>>> while, I agree that I should. >>>>>>=20 >>>>>> One point I am trying to make is that since the set of documents = we >>>>>> are discussing seems incomplete, in that it doesn't seem to = contain >>>>>> a TCP >>>>> variant >>>>>> that intends to delivers benefits over L4S paths w/o regressions. >>>>>>=20 >>>>>> My main point though is that there seem to be questions raised >>>>>> about the performance and behavior of L4S with various TCP >>>>>> variants. This is not an issue with the content of the L4S = drafts. >>>>>> It's a remaining uncertainty >>>>> related to >>>>>> the experimental evaluation and analysis that the L4S mechanisms >>>>>> have seen so far. Going forward with a LC is not going to bring >>>>>> further clarity >>>>> here. >>>>>>=20 >>>>>>> [IJ] The only pain point I see now is the RTT bias in cases = where >>>>>>> long RTT Prague flows compete with short RTT ditto. This is = being >>>>>>> addressed by the developers and it is not only an L4S problem. >>>>>>> Besides this, Prague will be presented at ICCRG tomorrow as I >>> understand >>>> it. >>>>>>=20 >>>>>> That is one point. I think interactions with tunnels was another. >>>>> [IJ] My take is that this is something for L4S ops that I see as a >>>>> product of the L4S experiment. It is not something that needs to = be >>>>> answered on its own as it is mainly the RFC3168 AQM issue in = another >>>>> shape, we don't know how widely spread this problem is or to how >>>>> large extent this equipment can be updated, earlier discussions on >>>>> fq-codel implementations in home gateways was not conclusive I = guess >>>>> but it appears that many of these have automatic upgrade features, >>>>=20 >>>> [SM] This is simply untrue, most home router will only see an = update >>> if >>>> the user actively monitor's the provider's or manufacturer's = website >>>> and >>> most >>>> manufacturer's will only create and distribute updates around the >>>> time a device is still marketed/sold. There is pretty little home >>>> gear out these >>> which >>>> gets automatic updates or only notifications of possible updates. I >>>> agree >>> that >>>> that would be a great situation to be in, but realistically the = home >>> router >>>> update and security situation is only mildly above the update and >>>> security situation of IoT devices. Remember it is the "s" in IoT = that >>>> stands for security/safety... >>>> So, if your stance is, automatic updates are robust, reliable = and >>> wide- >>>> spread, please post some references supporting that hypothesis. >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>> I guess the reason here is to be able to upgrade to combat = security >>>>> threats but this is admittedly speculation. >>>>=20 >>>> [SM] For someone putting their operational safety in that basket = I >>>> would have expected more robust and reliable numbers for how many >>>> devices might be amenable to automated updates. Like hard numbers >>>> supporting the hypothesis that automatic updates are wide spread >>>> enough to allow distribution of such functionality updates. Also >>>> think about who is supposed to make back-ports of the required = Linux >>>> kernel changes to the often ancient kernel versions SoC-SDKs are >>>> based on? To be honest that >>> level >>>> of engineering by wishful thinking frightens me a bit. >>>>=20 >>>>=20 >>>>>=20 >>>>>>=20 >>>>>> I'm actually looking forward to the presentation on TCP Prague - = is >>>>>> there >>>>> a >>>>>> draft? >>>>> [IJ] Not that I know of, code is found at >>>>> https://protect2.fireeye.com/v1/url?k=3D3f509ea0-60cba7e3-3f50de3b- >>>> 861fc >>>>> b972bfc-3fb038567b51ac5d&q=3D1&e=3D0ad66ee5-96b6-405d-84d7- >>>> e83c5a03bcba&u=3D >>>>> https%3A%2F%2Fgithub.com%2FL4STeam%2F >>>>=20 >>>> [SM] Is it just me that sees a problem in that the reference >>> protocol >>>> implementation just exists in a repository, without even an attempt >>>> of >>> writing >>>> an internet dratf describing that protocol? There are zero = guarantees >>>> the tomorrows TCP Prague still is L4S compliant (today's is not, = the >>>> rfc3168 detection and fall back are disabled by default, see >>>> https://protect2.fireeye.com/v1/url?k=3Dc7557841-98ce4102-c75538da- >>>> 861fcb972bfc-22e4ec3d607132d2&q=3D1&e=3D0ad66ee5-96b6-405d-84d7- >>>>=20 >> e83c5a03bcba&u=3Dhttps%3A%2F%2Fgithub.com%2FL4STeam%2Flinux%2Fcom >>>> mit%2Fb256daedc7672b2188f19e8b6f71ef5db7afc720). >>>>=20 >>>>=20 >>>>>>=20 >>>>>>> Besides this there is discussion around all sorts of cases with >>>>>>> RFC3168 style AQMs, additional discussion before a WGLC will >>>>>>> definitely not make us more wise. >>>>>>=20 >>>>>> Discussion won't, but experimentation would. >>>>> [IJ] Yes, but we need to get past the discussion on all possible >>>>> things that can happen. Recall from the discussion yesterday that >>>>> Stuart Cheshire and his team has not need evidence of ECN marking >>>>> AQMs. So I fear that we spend a lot of time discussing problems = that >>>>> are >>>> very rare. >>>>=20 >>>> [SM] Ingemar, I and other OpenWrt users have an rfc3168 AQM on >> my >>>> internet access link, that by default uses ECN for the downlink. I = do >>> not >>>> have the view of the world as apple has, but I can guarantee the >>>> number is grater than zero. And as stated before people doing this >>>> today are exactly >>> the >>>> latency conscious users L4S should aim at winning over... >>>>=20 >>>>>=20 >>>>>>=20 >>>>>>> As regards to investment, already today there is investment in >>>>>>> this, examples that are disclosed in the open are Broadcom and >>>>>>> Nokia. I can imagine that there is some expectation that L4S = will >>>>>>> materialize in RFCs >>>>>>=20 >>>>>> Sorry I was unclear. You are right that there is investment by > vendors. >>>>> But I >>>>>> think the key question if there will be an investment by = operators, >>>>>> since >>>>> they >>>>>> need to eventually buy L4S kit and deploy it. And that investment >>>>>> will >>>>> only pay >>>>>> off if end systems actually have deployed a CC scheme that takes >>>>>> advantage >>>>> of >>>>>> L4S. So the ready availability of such a scheme is IMO a key >>> requirement. >>>>> [IJ] I would say that we already have CC algos that can be used. >>>>> Surely they do not meet all the requirements today but I don't see >>>>> why it will not be possible. >>>>=20 >>>> [SM] This tells more about your confidence in your vision than = in >>> what >>>> might be achiebale in those CCs. IMHO ithe onus is on team L4S to >>>> demonstrate that possibility by demonstrating a CC that ticks all = the >>> check >>>> marks (does not need to be perfect, but should show significantly >>>> better performance in some dimension, while doing at least no harm = in >>>> others, currently TCP Prague fails on both accounts). >>>>=20 >>>>=20 >>>>> It is definitely the case that we will be discussing what typical >>>>> RTTs are like forever but that is not something that should delay >>>>> the L4S drafts I think. >>>>=20 >>>> [SM] Sorry, this is getting absurd, I point out both Bob = completely >>>> missing how PIE works (and what it's target variable actually >>>> describes ) >>> and an >>>> inconsistency between two of the L4S drafts only to be ridiculed = here. >>>> Ingemar, publishing RFC with inconsistent terms and definition is = not >>>> a >>> sign of >>>> a professional authoring process. Reviews are supposed to help >>>> finding >>> such >>>> issues, and the response of the authors should not be something = like >>>> your offense above, but a simple "thanks for pointing out the >>>> inconsistency, we >>> are >>>> going to fix it, here is our proposed change". The ambiguity = between >>>> the DualQ and the id drafts I pointed out are real, and "typical = RTT" >>>> is not a >>> well >>>> known term of art that every IETF member or operator is going to >>> understand >>>> intuitively. >>>> Also, if my worst fear is correct, protocol and AQM "typical = RTT" >>>> values need to be selected in lock-step to be effective, and such a >>>> requirement needs to be made explicit in an RFC. And if I am wrong >>>> that >>> the >>>> two uses of the term have different definitions that needs to be >>>> disambiguated in the internet drafts, no? >>>>=20 >>>>=20 >>>>>=20 >>>>>>=20 >>>>>>> [IJ] If this would only be a IETF matter, then you are right. We >>>>>>> however try to address this also in 3GPP standards to make the >>>>>>> whole thing work in products, and that is of course hard to do = if >>>>>>> L4S is not >>>>> even an >>>>>> RFC. >>>>>>=20 >>>>>> Is L4S currently a requirement for a future 3GPP release? >>>>> [IJ] L4S is not currently pushed for in 3GPP, there is however = work >>>>> on the support for extended reality that requires low latency. L4S >>>>> will definitely fit there. I would expect that L4S support can be >>>>> proposed ~ >>> mid >>>> next year. >>>>=20 >>>> [SM] So you are willing to push an under-tested solution into = 3GPP, >>>> but you insist upon that un-tested solution having IETF blessing? >>>> That >>> seems >>>> rather odd, I would have expected that the primary requirement = should >>>> be "works robustly and reliably without (unacceptable) = side-effects" >>>> and not >>> only >>>> "has RFC status". I have a hard time believing 3GPP works like = that... >>>>=20 >>>> Best Regards >>>> Sebastian >>>>=20 >>>>=20 >>>>>=20 >>>>>>=20 >>>>>> Thanks, >>>>>> Lars >>>=20 >=20