From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.taht.net (mail.taht.net [176.58.107.8]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id EE4403B2A4; Sat, 25 Jan 2020 11:04:32 -0500 (EST) Received: from dancer.taht.net (unknown [IPv6:2601:646:8301:676f:eea8:6bff:fefe:9a2]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.taht.net (Postfix) with ESMTPSA id 32A552296C; Sat, 25 Jan 2020 16:04:31 +0000 (UTC) From: Dave Taht To: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= Cc: Dave Taht , Sebastian Moeller , ECN-Sane , bloat References: <95CC814B-9F95-4C79-BF47-ABB551B50429@gmail.com> <3D7A8E2C-5A8F-4FBB-89B0-9711E46CD560@gmx.de> <87zhedgp2g.fsf@toke.dk> Date: Sat, 25 Jan 2020 08:04:29 -0800 In-Reply-To: <87zhedgp2g.fsf@toke.dk> ("Toke \=\?utf-8\?Q\?H\=C3\=B8iland-J\?\= \=\?utf-8\?Q\?\=C3\=B8rgensen\=22's\?\= message of "Fri, 24 Jan 2020 10:51:19 +0100") Message-ID: <87tv4jzfn6.fsf@taht.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Ecn-sane] [Bloat] 2019-12-31 docsis strict priority dual queue patent granted 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: Sat, 25 Jan 2020 16:04:33 -0000 Toke H=C3=B8iland-J=C3=B8rgensen writes: > Dave Taht writes: > >> 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. > > I have heard about 5G vendors implementing CoDel on their > modems. That's the best news I've heard all year. > Maybe > what will end up happening is that all the promises of "low-latency > networking" on 5G will end up being true simply because the vendors > finally fix their bloat? ;) One can hope. I must admit that I still think fiber to the home is a way better idea than fiber to the pole, and I'd really like delegated /60 at the very least, regularly available, over (X)G. I tether a lot these days and don't have ipv6 on my tether at all... > > -Toke > _______________________________________________ > Bloat mailing list > Bloat@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/bloat