Discussion of explicit congestion notification's impact on the Internet
 help / color / mirror / Atom feed
From: Dave Taht <dave@taht.net>
To: "Toke Høiland-Jørgensen" <toke@toke.dk>
Cc: Dave Taht <dave.taht@gmail.com>,
	Sebastian Moeller <moeller0@gmx.de>,
	ECN-Sane <ecn-sane@lists.bufferbloat.net>,
	bloat <bloat@lists.bufferbloat.net>
Subject: Re: [Ecn-sane] [Bloat] 2019-12-31 docsis strict priority dual queue patent granted
Date: Sat, 25 Jan 2020 08:04:29 -0800	[thread overview]
Message-ID: <87tv4jzfn6.fsf@taht.net> (raw)
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")

Toke Høiland-Jørgensen <toke@toke.dk> writes:

> Dave Taht <dave.taht@gmail.com> 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

  reply	other threads:[~2020-01-25 16:04 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-23  2:29 [Ecn-sane] " Dave Taht
2020-01-23  8:21 ` Luca Muscariello
2020-01-24  5:37   ` Dave Taht
2020-01-24  7:44     ` Jonathan Morton
2020-01-24  8:01       ` Sebastian Moeller
2020-01-24  8:24         ` Dave Taht
2020-01-24  8:59           ` Dave Taht
2020-01-24  9:51             ` Toke Høiland-Jørgensen
2020-01-25 16:04               ` Dave Taht [this message]
2020-01-24 12:08             ` Sebastian Moeller
2020-01-25 16:21               ` [Ecn-sane] [Bloat] " Dave Taht

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://lists.bufferbloat.net/postorius/lists/ecn-sane.lists.bufferbloat.net/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87tv4jzfn6.fsf@taht.net \
    --to=dave@taht.net \
    --cc=bloat@lists.bufferbloat.net \
    --cc=dave.taht@gmail.com \
    --cc=ecn-sane@lists.bufferbloat.net \
    --cc=moeller0@gmx.de \
    --cc=toke@toke.dk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox