Discussion of explicit congestion notification's impact on the Internet
 help / color / mirror / Atom feed
From: "Toke Høiland-Jørgensen" <toke@toke.dk>
To: Dave Taht <dave.taht@gmail.com>, Sebastian Moeller <moeller0@gmx.de>
Cc: ECN-Sane <ecn-sane@lists.bufferbloat.net>,
	bloat <bloat@lists.bufferbloat.net>
Subject: Re: [Ecn-sane] 2019-12-31 docsis strict priority dual queue patent granted
Date: Fri, 24 Jan 2020 10:51:19 +0100	[thread overview]
Message-ID: <87zhedgp2g.fsf@toke.dk> (raw)
In-Reply-To: <CAA93jw5pnfM_TBgQFZyfk14+3UXUVLzR_umhwbFyt4a5ShzsSQ@mail.gmail.com>

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. 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? ;)

-Toke

  reply	other threads:[~2020-01-24  9:51 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-23  2:29 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 [this message]
2020-01-25 16:04               ` [Ecn-sane] [Bloat] " Dave Taht
2020-01-24 12:08             ` [Ecn-sane] " 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=87zhedgp2g.fsf@toke.dk \
    --to=toke@toke.dk \
    --cc=bloat@lists.bufferbloat.net \
    --cc=dave.taht@gmail.com \
    --cc=ecn-sane@lists.bufferbloat.net \
    --cc=moeller0@gmx.de \
    /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