cancel
Showing results for 
Search instead for 
Did you mean: 

Is DOCSIS-PIE enabled per specification on VM?

RainmakerRaw
Up to speed

Having suffered with poor upstream latency under load (aka 'bufferbloat') for years, as have VM's other customers, I was interested to read a paper[1] today by Flickinger et al.

The paper refers to a newer upstream active queue management, Proportional Integral Controller Enhanced - known colloquially as DOCSIS-PIE. More specifically, the paper discusses the impact of implementing DOCSIS-PIE on a (Comcast) DOCSIS network during the COVID-19 pandemic, when everyone started working and schooling from home, thus adding unprecedented latency and load to networks.

A rollout by Comcast with two modems, one with AQM/PIE enabled and one without, showed a difference in upstream latency under load to the order of 15ms (with PIE) vs 250ms (without PIE). A rather staggering difference! I certainly don't see behaviour as good as that on VM, hence the thread/question.

More importantly, the paper goes on to cite that:

 

In 2014, CableLabs included PIE as the official AQM in the DOCSIS 3.1 specifications as a mandatory feature for the CMTS and cable modems (PIE was also added as an optional feature for earlier generation DOCSIS 3.0 cable modems). At the same time, CableLabs required that DOCSIS 3.1 CMTS equipment support AQM as well but left the algorithm choice to the vendor.

 

Given it's mandatory in the standard/specification, I'm assuming this is something that VM has enabled for the downstream DOCSIS 3.1 channel on Gig1? What of the other DOCSIS 3 channels, which are optional?

(Edit: I'm asking about the CMTS and the CPE here.)

There's scant information out there on the VM network core, and this is the only place I know of to ask such a question despite the fact the forum is clearly not geared to this type of discussion (regrettably).

I'd be interested to hear a definitive reply back from someone at VM, and I do understand that the forum team will likely need to bounce this over to someone at networks for comment.

It'd be nice to finally have a connection that doesn't collapse into a crippled mess of high latency because someone's phone is backing up to iCloud, when I'm trying to (for example) make a video call or waiting for elements to render on a website. As it is, currently I'm just implementing fq_codel on my OpenBSD router (and running cake+bbr on my *nix boxes). But what of VM's end?

[1] Improving Latency with Active Queue Management (AQM) During COVID-19
By Allen Flickinger, Carl Klatsky, Atahualpa Ledesma, Jason Livingood, Sebnem Ozer
https://arxiv.org/ftp/arxiv/papers/2107/2107.13968.pdf

35 REPLIES 35


@jem101 wrote:

@RainmakerRaw wrote:

@Andrew-G wrote:

I'd also like to put my hand up for getting the wrong end of the stick here.


Fair play mate. Now get reading, and start asking VM questions. 😄


Economy of scale (sort of), yes VM or any ISP could do 'X' but doing this would cost 'Y' and only 'Z' percent of users would notice anything anyway, and probably doing so would result in about 0 increase in subscribers, it's not worth it!

Annoying, but to be fair VM is a business which exists to make money (as indeed do all businesses), so why spend X if you are going to make less back?

Let's be honest here, what percentage do you think of VM users, use the connection to download mostly cute cat videos? Do they care if it's using D 3.0 or 3.1 or 4.0? can I see my cat videos? If yes, then all is OK! Upstream issues, what's that then?

We all know that DOCSIS has issues with upstream, simply because of historical issue of how it works, but do you really think that the majority of customers care less? - it works (mostly); so fine*

* OK I don't personally subscribe to this viewpoint, but I do know how businesses work!


Actually, you're looking at this all wrong too. It costs nothing, so the business angle is a red herring. In fact it would reduce costs, especially in relation to reduced support overhead. It would also better balance available bandwidth and aggregate it properly, resulting in less urgent need to re-segment and upgrade networks (though not entirely, as over-subscription is its own thing too).

Actually, regular uses do care. They just don't know why (yet). Video conferencing stuttering and dropping off during the pandemic? Bufferbloat. Social media jumping around, stuttering, freezing and dropping video playback to potato quality? Bufferbloat. Stuttering and missing words on your phone's WiFi calling? Bufferbloat. One person using the net in the house, and the rest having their browsing and whatnot turning to treacle? Bufferbloat... You'd cut a huge proportion of complaints and support calls (both on the forum and the phone) by properly implementing active queue management. Most of the issues caused on VM's network are due to bufferbloat. The fact that DOCSIS has traditionally been so heavily asymmetric only compounds this, but again can be fixed (eg with ack-filtering).

@RainmakerRaw No I'm not actually arguing with you, although I think you are wrong in a couple of cases. DOCSIS being asymmetric, well yes of course it is, think about the origins of the technology and what it is built on - even now, what do you think the split is between upstream and downstream requirements?

I promise you, I know all about upstream latency and the issues it can cause - but again I'm trying to see this from a business perspective, from VM's view it's not a problem - yes x% of users complain about zoom cals etc. (although not understanding what the issue really is), but x% is tiny and it would cost too much to fix.

OK let's be honest here, I'm the CEO of VM, I'm told that x% of customers are complaining about some random zoom issues, my IT people tell me that the issue is well know but it would cost more than what they pay in subscriptions to fix - what do you do? I know what I'd do, which is to say f*** 'em, safe in the knowledge that most won't leave anyway - (customer inertia).

Any change, honestly any change, does absolutely have a cost in terms of support - someone in VM has done the maths and concluded that it isn't worth it.


@jem101 wrote:

@RainmakerRaw No I'm not actually arguing with you, although I think you are wrong in a couple of cases. DOCSIS being asymmetric, well yes of course it is, think about the origins of the technology and what it is built on - even now, what do you think the split is between upstream and downstream requirements?

I promise you, I know all about upstream latency and the issues it can cause - but again I'm trying to see this from a business perspective, from VM's view it's not a problem - yes x% of users complain about zoom cals etc. (although not understanding what the issue really is), but x% is tiny and it would cost too much to fix.

OK let's be honest here, I'm the CEO of VM, I'm told that x% of customers are complaining about some random zoom issues, my IT people tell me that the issue is well know but it would cost more than what they pay in subscriptions to fix - what do you do? I know what I'd do, which is to say f*** 'em, safe in the knowledge that most won't leave anyway - (customer inertia).

Any change, honestly any change, does absolutely have a cost in terms of support - someone in VM has done the maths and concluded that it isn't worth it.


Again, what cost? The (free) software is already part of the official specification for DOCSIS, it's included in the software already installed on the hardware VM install, and it's possible to enable with a simple flick of a configuration switch. How are you reaching the conclusion that it would 'cost more than what they pay in subscriptions'?

@RainmakerRaw for a business, I promise you 'nothing is free'

OK assume that you want to include this into the next revision of the hubs firmware; test it! And then test it again - are you absolutely sure that this won't cause an issue with any of the 5.5 - 6 million hubs already in service? Oh; and if you say you are 100% there will be no issues, you're fired, because there is no such thing as 100% certainty.

One last thing, I'm a multi-billion pound company, if you personally are sure that there are no issues, then fine, but if there are then I will use my really expensive lawyers to sue you into oblivion and will happily see you and your entire family living rough on the streets!

Like I say, I know how big businesses work!

legacy1
Alessandro Volta

Well VM can trial it...I mean their are issues not doing it so why not...

---------------------------------------------------------------


@legacy1 wrote:

Well VM can trial it...I mean their are issues not doing it so why not...


NO there are no issues not doing it, other than a few users on a forum getting annoyed - but who cares about them?

legacy1
Alessandro Volta

@jem101 wrote:
other than a few users on a forum getting annoyed 

or not and make it better.

---------------------------------------------------------------


@jem101 wrote:

None of VM’s internet tiers utilise DOCSIS 3.1 on the upstream, they are still on 3.0, and as you say it’s not obligatory to support AQM.

That is not a deal breaker. The modem (and the CMTS) is 3.1, so 3.1 is what governs.

Anonymous
Not applicable

Spot on. It's software running before the modem pushes data to the link / DoCSIS layer so whether the network is 3.1 or 1.0 the modem can do this.

This is the modem deciding what to ask the DoCSIS network for bandwidth for and when. When I mentioned I was dubious about the Hub 3 and below it was more about the CPU, etc in the device being able to do the job. It's purely whether the router has the hardware resources to run the software, it's nothing to do with the CMTS or VM network on the upstream at all. 

Hi RainmakerRaw 

It looks as though our community have this in hand.  Is there anything that you wish us to look into?

Regards


Lee_R