From: Sebastian Moeller <moeller0@gmx.de>
To: Mikael Abrahamsson <swmike@swm.pp.se>
Cc: Jonathan Morton <chromatix99@gmail.com>,
bloat <bloat@lists.bufferbloat.net>
Subject: Re: [Bloat] benefits of ack filtering
Date: Wed, 13 Dec 2017 13:36:09 +0100 [thread overview]
Message-ID: <9E518E4F-0DCA-4B28-B01D-612201FEE493@gmx.de> (raw)
In-Reply-To: <alpine.DEB.2.20.1712131033530.8884@uplift.swm.pp.se>
Hi Mikael,
> On Dec 13, 2017, at 10:46, Mikael Abrahamsson <swmike@swm.pp.se> wrote:
>
> On Wed, 13 Dec 2017, Jonathan Morton wrote:
>
>> the uplink shaper is set to about a fiftieth of that. I seriously doubt that DOCSIS is ever inherently that asymmetric.
>
> Well, the products are, because that's what the operators seems to want, probably also because that's what the customers demand.
Not 100% about the demand; I believe this also has a component of market segmentation:
a) everybody that actually wants to offer content is going to be not to well-served with the asymmetric links and hence might need to upgrade to the typical business-grade contracts that AFAIKT often have smaller download/upload ratios.
b) I seem to recall (but can find no evidence, so I might fantasizing) that having assymmetric traffic can have advantages for an ISP with peering/transit costs.
>
> So my modem has 16x4 (16 downstream channels and 4 upstream channels), meaning built into the hardware, I have 1/4 split.
In addition to the differences in available modulations for down- and upstream channels.
>
> Then providers typically (this is my understanding, I haven't worked professionally with DOCSIS networks) do is they have 24 downstream channels and 4 upstream channels. Older modems can have 8 downstream and 4 upstream for instance, so they'll "tune" to the amount of channels they can, and then there is an on-demand scheduler that handles upstream and downstream traffic.
>
> So I guess theoretically the operator could (if large enough) make a hw vendor create a 16x16 modem and have 32 channels total.
> But nobody does that, because that doesn't sell as well as having more downstream (because people don't seem to care about upstream).
Or because more symmetric offers can be sold for more money to businesses (sure the "business" contract class probably offers more than that, but I think this is one thing it does offer).
> It just makes more market sense to sell these asymmetric services, because typically people are eyeballs and they don't need a lot of upstream bw (or think they need it).
Let's put it that way, people simply do not know as in the advertisements one typically only sees the downstream numbers with the upstream relegated to the footnotes (or hidden behind a link). If customers truly would not care ISPs could afford to be more open with the upstream numbers (something regulators would certainly prefer to hiding the information in the fine print).
>
> On the ADSL side, I have seen 28/3 (28 down, 3 up) for annex-M with proprietary extensions. The fastest symmetric I have seen is 4.6/4.6. So if you as an operator can choose between selling a 28/3 or 4.6/4.6 service, what will you do? To consumers, it's 28/3 all day.
I agree that most users would see it that way (especially since 4.6 to 3 is not that much loss); also I b;eive it will be hard to offer simultaneous 23/3 and 4.6/4.6 over the same trunk line (not sure whether that is the correct word, I mean the thick copper cable "tree" that starts from the CO/gf-attached DSLAM).
For ADSL the challenge is that the up-/downstrewam bands need to be equal for all users on a trunk cable other wise interference/cross talk will be bad; and the most remote customer will still need some downstream effectively limiting the high end for the single upstream band in ADSL. VDSL2 sidesteps this issue somewhat by using multiple upstream bands and more remote lines will simply miss out on the higher frequency upstream bands but will still get a better symmetry...
>
> So people can blame the ISPs all day long, but there is still (as you stated) physical limitations on capacity on RF spectrum in air/copper,
These limitations might or might not be close: https://www.assia-inc.com/wp-content/uploads/2017/05/TDSL-presentation.pdf
> and you need to handle this reality somehow. If a lot of power is used upstream then you'll get worse SNR for the downstream, meaning less capacity overall. Symmetric access capacity costs real money and results in less overall capacity unless it's on point to point fiber.
Best Regards
Sebastian
>
> --
> Mikael Abrahamsson email: swmike@swm.pp.se
> _______________________________________________
> Bloat mailing list
> Bloat@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat
next prev parent reply other threads:[~2017-12-13 12:36 UTC|newest]
Thread overview: 76+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-11-28 21:48 Dave Taht
2017-11-29 6:09 ` Mikael Abrahamsson
2017-11-29 9:34 ` Sebastian Moeller
2017-11-29 12:49 ` Mikael Abrahamsson
2017-11-29 13:13 ` Luca Muscariello
2017-11-29 14:31 ` Mikael Abrahamsson
2017-11-29 14:36 ` Jonathan Morton
2017-11-29 15:24 ` Andrés Arcia-Moret
2017-11-29 15:53 ` Luca Muscariello
[not found] ` <CAJq5cE3qsmy8EFYZmQsLL_frm8Tty9Gkm92MQPZ649+kpM1oMw@mail.gmail.com>
2017-11-29 16:13 ` Jonathan Morton
2017-11-30 7:03 ` Michael Welzl
2017-11-30 7:24 ` Dave Taht
2017-11-30 7:45 ` Dave Taht
2017-11-30 7:48 ` Jonathan Morton
2017-11-30 8:00 ` Luca Muscariello
2017-11-30 10:24 ` Eric Dumazet
2017-11-30 13:04 ` Mikael Abrahamsson
2017-11-30 15:51 ` Eric Dumazet
2017-12-01 0:28 ` David Lang
2017-12-01 7:09 ` Jan Ceuleers
2017-12-01 12:53 ` Toke Høiland-Jørgensen
2017-12-01 13:13 ` [Bloat] [Make-wifi-fast] " Кирилл Луконин
2017-12-01 13:22 ` Luca Muscariello
2017-12-11 17:42 ` Simon Barber
2017-12-01 13:17 ` [Bloat] " Luca Muscariello
2017-12-01 13:40 ` Toke Høiland-Jørgensen
2017-12-01 17:42 ` Dave Taht
2017-12-01 20:39 ` Juliusz Chroboczek
2017-12-03 5:20 ` [Bloat] [Make-wifi-fast] " Bob McMahon
2017-12-03 10:35 ` Juliusz Chroboczek
2017-12-03 11:40 ` Jan Ceuleers
2017-12-03 13:57 ` Juliusz Chroboczek
2017-12-03 14:07 ` Mikael Abrahamsson
2017-12-03 19:53 ` Juliusz Chroboczek
2017-12-03 14:09 ` Ryan Mounce
2017-12-03 19:54 ` Juliusz Chroboczek
2017-12-03 20:14 ` Sebastian Moeller
2017-12-03 22:27 ` Dave Taht
2017-12-03 15:25 ` Robert Bradley
2017-12-04 3:44 ` Dave Taht
2017-12-04 14:38 ` David Collier-Brown
2017-12-04 15:44 ` Juliusz Chroboczek
2017-12-04 17:17 ` David Collier-Brown
2017-12-03 19:04 ` Bob McMahon
2017-12-01 21:17 ` Bob McMahon
2017-12-01 8:45 ` [Bloat] " Sebastian Moeller
2017-12-01 10:45 ` Luca Muscariello
2017-12-01 18:43 ` Dave Taht
2017-12-01 18:57 ` Luca Muscariello
2017-12-01 19:36 ` Dave Taht
2017-11-30 14:51 ` Neal Cardwell
2017-11-30 15:55 ` Eric Dumazet
2017-11-30 15:57 ` Neal Cardwell
2017-11-29 16:50 ` Sebastian Moeller
2017-12-12 19:27 ` Benjamin Cronce
2017-12-12 20:04 ` Dave Taht
2017-12-12 21:03 ` David Lang
2017-12-12 21:29 ` Jonathan Morton
2017-12-12 22:03 ` Jonathan Morton
2017-12-12 22:21 ` David Lang
[not found] ` <CAJq5cE3nfSQP0GCLjp=X0T-iHHgAs=YUCcr34e3ARgkrGZe-wg@mail.gmail.com>
2017-12-12 22:41 ` Jonathan Morton
2017-12-13 9:46 ` Mikael Abrahamsson
2017-12-13 10:03 ` Jonathan Morton
2017-12-13 12:11 ` Sebastian Moeller
2017-12-13 12:18 ` Jonathan Morton
2017-12-13 12:36 ` Sebastian Moeller [this message]
2017-12-13 12:39 ` Luca Muscariello
2017-11-29 18:21 ` Juliusz Chroboczek
2017-11-29 18:41 ` Dave Taht
2017-11-29 23:29 ` Steinar H. Gunderson
2017-11-29 23:59 ` Stephen Hemminger
2017-11-30 0:21 ` Eric Dumazet
2017-12-11 20:15 ` Benjamin Cronce
2017-11-29 18:28 ` Juliusz Chroboczek
2017-11-29 18:48 ` Dave Taht
2017-12-11 18:30 ` Jonathan Morton
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/bloat.lists.bufferbloat.net/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=9E518E4F-0DCA-4B28-B01D-612201FEE493@gmx.de \
--to=moeller0@gmx.de \
--cc=bloat@lists.bufferbloat.net \
--cc=chromatix99@gmail.com \
--cc=swmike@swm.pp.se \
/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