From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-il1-x141.google.com (mail-il1-x141.google.com [IPv6:2607:f8b0:4864:20::141]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 7B62A3B29E; Fri, 24 Jan 2020 03:59:54 -0500 (EST) Received: by mail-il1-x141.google.com with SMTP id u14so1026968ilj.4; Fri, 24 Jan 2020 00:59:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=aVuTibALzLMdKApUiWxNWRhGGbe/yX7Y6wAWyDs4AEU=; b=aIWJ7oDfkA1Ko+W7Yx/8jd2U7nM/TQQ/5cGVos8my5gtMZXM4qa1nKVbMbygB3ql2k f3kMgFhZ9rhLaHgxAJSeZE/IEy/e6FB6oR8rif2TOdb8XSsTmbnGj633I44h6jTdrOUa UvUwZZ+x9SZXvaXA2pCVxGOU4GtnN64FzumAubIc/1F2Ol5a4w/SP5faQi7X6R2YE2sy DU4MQDkesPPnJBluRiBBwxr/4owp6qUKHv3V5QHCWbpBi6HAE0nbJZcBzIE9TCbEadIJ aOJrTTIkZclQpMkVhpDDsMQkAtfN4lTqWAG9XJ94uVukowDiJKFL5LrtIMf602b2JH5d 0Npg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=aVuTibALzLMdKApUiWxNWRhGGbe/yX7Y6wAWyDs4AEU=; b=nMQItRjfe8uVaDnMK8xGLcgPwZH5xRc6Z8hfAl6asWE2Cr1n5JR2gXdtBSNXTcSYok hefRHJyKJWzQd2luqu4Tyw4bRRv45Zb+9PLyEDjbhNkSHKu9wEol7F9cvf1PE2eAupvY BYuaKlL2AgfgOW15Selfi4CsylLVDZXotOW4bjRHE1sl/HohdQ6CY/JkLEiYZSJXbgNf r4vyrik6kPNxgKadDgvck56oTlewIjKVGt5iENGl5q0XLaPBdmUxkEzd2PZZC3lho4RW S12wG2hm0Cr7SBQgXq2WuwORXFnjH6GRCxjnfOOoxWPhpSYvcSimWK1ObnXAEmrFkSVU 7oZA== X-Gm-Message-State: APjAAAU2z6N+50YcEEXa+KbwCXh3ce4r1UrJbw256q5PfBIUYjPYxq+o YyyZaOoaWHpeOuSwmvGA8UoLwdm88ubizGXCA1A= X-Google-Smtp-Source: APXvYqwLl4FjRLNgP7nlxB8C2854xGec0orkAL2tP2pPTQERCAEdAp/3HXMm/K6Goz/3F3t+5feB+uzqofVs8fW0MRg= X-Received: by 2002:a92:3a95:: with SMTP id i21mr2126867ilf.249.1579856393879; Fri, 24 Jan 2020 00:59:53 -0800 (PST) MIME-Version: 1.0 References: <95CC814B-9F95-4C79-BF47-ABB551B50429@gmail.com> <3D7A8E2C-5A8F-4FBB-89B0-9711E46CD560@gmx.de> In-Reply-To: From: Dave Taht Date: Fri, 24 Jan 2020 00:59:42 -0800 Message-ID: To: Sebastian Moeller Cc: Jonathan Morton , ECN-Sane , bloat Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [Bloat] [Ecn-sane] 2019-12-31 docsis strict priority dual queue patent granted X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2020 08:59:54 -0000 To be deliberately contrarian - (I do try to only pay attention to this a few days a month) - after also re-reading https://www.cablelabs.com/technologies/low-latency-docsis and the associated white papers (yes, 24 hours on a plane can do this to you) 1) I've never been able to figure out where the 99 percentile latency figure so often cited came from. on the upstream which typically runs well below 20Mbit, a single IW10 burst at 10Mbit is 1.3ms, so I've generally figured it was either a long term figure, or calculated from a much higher (100mbit? 1gbit?) downstream rate against some load that's never been documented. (that I know of, please note that I don't read much of the traffic about this stuff) 2) There is a lot of valuable looking stuff in the lower level aspects of the docsis LL standard. I'd noted it when I first read it, but achieving .9ms baseline a/g latency finally does make it competitive with fiber with whatever the heck "pgm" is. So far as I knew, the overlapping grant request and estimator functions documented in the patent are already present in most cablemodems already, and not really tied to the ll spec... but that data would be interesting to get out of the modem itself, somehow. The histogram is made available via a MIB to the operator. It would be nice if those MIBs were also visible to the user somehow. 3) In the docsis-ll white paper and spec it lays out cmts requirements also. With the cmtses currently exhibiting 500+ms of latency at 100Mbit loaded, from a mere "solving bufferbloat" perspective - getting just pie there to work would be *marvelous* - it would be superior to any of the fiber deployments I know of. dualpi, even if not configured for l4s ecn support, would be a godsend. The ECO for cablemodems at least, went out over a year ago. some aqm tech becoming common on these head ends would also spur deployment of aqm (or fq + aqm) tech on fiber also. But I've seen no info as to what's going into cmtses today. Haven't seen any announcements... I still have no idea what is going to happen on 5G. My initial experiments with the intel ax200 wifi card have been dismal. On Fri, Jan 24, 2020 at 12:24 AM Dave Taht wrote: > > Jeeze, you guys are up early. I read this stuff on the plane home from > australia, and am still a bit under the weather. > > On Fri, Jan 24, 2020 at 12:01 AM Sebastian Moeller wrot= e: > > > > Hi Jonathan, > > > > > > > On Jan 24, 2020, at 08:44, Jonathan Morton wr= ote: > > > > > >> On 24 Jan, 2020, at 7:37 am, Dave Taht wrote: > > >> > > >> "Otherwise, this exemplary embodiment enables system configuration t= o > > >> discard the low-priority packet tail, and transmit the high-priority > > >> packet instead, without waiting." > > > > > > So this really *is* a "fast lane" enabling technology. Just as we su= spected. > > Well, there are weasel words elsewhere in the patent, and the dualq > code for linux merely cleared a lane for L4S traffic and hardcoded the > ect(1) as an identifier. It would be good to have more data on > rtt-fairness, and on CE reordering of rfc3168 ecn packets. > > I spent time dreaming up also all the ways "queue protection" could be > used against the user. Given the rigor of the l4s spec required, and > how one misbehaving application can screw it all up, I could see > queue protection of unknown sources that can be squelched on demand > being a desirable "feature". This can be used to stop "unauthorized" > mac addresses from participating in this design as one example. > > I like the idea of queue protection - there is a lot of malicious > traffic worth throttling - but without a reporting scheme to the user, > nor a means for the user to set it up, and the mechanism under the > sole control of the ISP - not so much. > > My other in-flight entertainment was cory doctorow's latest piece, > which was so good I submitted it to slashdot. ( > https://arstechnica.com/gaming/2020/01/unauthorized-bread-a-near-future-t= ale-of-refugees-and-sinister-iot-appliances/ > ) > > > > They seem to be setting their customers up for a head-on collis= ion with the European Union's net neutrality rules, according to which "spe= cial services/fast lanes" are permissible under the condition thay they are= realized with completely dedicated addition bandwidth. Just looking at the= ir patent diagram there is one common input path to the classifier. So eith= er that fast lane is not going to be a paid for fast lane, or the ISPs roll= ing this out will be in hot water with the respective national regulators (= at least in the EU). The one chance would be to give the end-user control o= ver the classification engine, or if the strict priority path is only used = for ISP originated VoIP traffic (I seem to recall there are weasel words in= the EU rules that would allow that and ISPs are doing something like that = already, and I agree that it is nice to be able to field an emergency call = independent of access link load). > > Well, one country at a time. NN is currently quite dead in the USA, > and only a change in regime might change that, and it's unclear if any > of the candiates understand the issues. Certainly with twin subsidies > being aimed at 5G and broadband deployment in pending legislation, I > have no idea what will happen here next. I view 5G with fear, watching > frontier file for bankruptcy, also... I really wish all the fiber > being run for 5G was being run into the home instead. > > > > > > Best Regards > > Sebastian > > > > > > > > > > - Jonathan Morton > > > _______________________________________________ > > > Ecn-sane mailing list > > > Ecn-sane@lists.bufferbloat.net > > > https://lists.bufferbloat.net/listinfo/ecn-sane > > > -- > Make Music, Not War > > Dave T=C3=A4ht > CTO, TekLibre, LLC > http://www.teklibre.com > Tel: 1-831-435-0729 --=20 Make Music, Not War Dave T=C3=A4ht CTO, TekLibre, LLC http://www.teklibre.com Tel: 1-831-435-0729