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


@Andrew-G wrote:

...not to mention that I'd see the proposed activity as clearly in breach of clause G10 of the Terms & Conditions, probably in the same class as introducing noise to the network.  VM's customary response is disconnection of services.


You (and one or two others) think changing the settings on your own router and/or desktop devices is grounds for disconnection? LOL... If VM implemented proper AQM (eg DOCSIS-pie) it wouldn't be necessary, and nobody would see bufferbloat. I'm failing to see how managing the queue on your own router to send packets from the LAN with fairer queuing leads to being 'probably in the same class as introducing noise to the network'. Depending on your OS, you're already running some form of AQM - especially if you're running anything macOS, iOS or Linux (and that includes your third party router and WiFi AP). All I did was change its settings to mix and queue my LAN traffic more appropriately for the line speed.

You (and jem101) seem to fundamentally misunderstand what AQM is, or how network queues work. Managing your LAN to fairly queue traffic is nothing to do with 'what happened at the beginning of the year' to the wider network. That was more people using their (oversubscribed) lines at the same time. Contrary to the earlier assertion, if 'everyone' implemented AQM then the lines would all work better and there'd be less bloat throughout, including upstream. As I said, if VM implemented this properly at their end none of this would be an issue, and everyone's lines would work better transparently. It seems some people have seen some scary graphs and thought 'hacking'. 😂


@Anonymous wrote:

You guys are aware that OP is talking about contention on his own service, as in someone else in the household using all his allowed upstream bandwidth on a bulk transfer and drowning out real-time or interactive traffic, right?

What he's implemented will do nothing to impact VM's network.

The load testing is no different from those who obsessively run automated speed tests.

If a segment is congested AQM isn't going to help, you need LLD and then more capacity per modem, whether by reducing the modems on the segment or increasing the capacity. 


Someone gets it. 👍

@Anonymous you know, one of the main things I have learnt in my career, is that no matter how much you think you know about a subject, there is always someone who knows more than you do! Which is good otherwise how do you learn anything?

My bad, valuable lesson learnt, should not post without actually researching first what is being talked about. The way is was worded made me think that the OP had found a way to game the request/grant mechanism for the upstream and my answer was along the lines of website SEO - if everyone is doing it then effectively no-one is doing it!

It sounded like the OP was wondering why this wasn't implemented globally by VM as if it was a WAN-level issue rather than something done on the local LAN side.

John


@jem101 wrote:

@Anonymous you know, one of the main things I have learnt in my career, is that no matter how much you think you know about a subject, there is always someone who knows more than you do! Which is good otherwise how do you learn anything?

My bad, valuable lesson learnt, should not post without actually researching first what is being talked about. The way is was worded made me think that the OP had found a way to game the request/grant mechanism for the upstream and my answer was along the lines of website SEO - if everyone is doing it then effectively no-one is doing it!

It sounded like the OP was wondering why this wasn't implemented globally by VM as if it was a WAN-level issue rather than something done on the local LAN side.

John


Thank you for admitting you'd grabbed the wrong end of the stick. 🙂 As you said, that's how we learn - admit we missed something, and start reading up! Actually, SQM and AQM are something that runs on every device - from your desktop (cubic, reno, fq_codel, bbr) through your WiFi (codel, cake) and router (cake, hopefully). It's how the OS running on that device deals with packets filling the buffers on the network cards, prioritises and queues them (or not) and send them onward. This type of active congestion control / active queue management is part of the official Cable Labs DOCSIS 3.1 standard, but VM don't implement it. It's free, as in both speech and beer, and would solve this issue for all subscribers, not just the ones who know how to set it up on their own CPE. My question is 'why'?

Just to add, as I said earlier, I was helped in this endeavour by Dave Taht. He's one of the world's foremost experts on this stuff. He literally wrote the book (and the journal articles, and some of the underlying protocols), and works with organisations like IETF to get this stuff working. He's fixing bufferbloat for Elon Musk at Starlink atm. Clever guy. I was really very lucky to catch his attention and have him help me through this. He's a stand up guy and cares a *lot* about fixing the Internet. Nothing contained in this thread could, or would, ever impact VM's network (except possibly in a good way). It stands to really help improve your own connection, though...

Edit: Some more reading by Dave Taht. This one's about making better use of your connection while working from home during the pandemic. Also don't forget the more formal paper on that topic (complete with AQM testing on Comcast's DOCSIS network), that I posted earlier in the tread. Fascinating stuff.

Anonymous
Not applicable

Good question. Hub 4 will be capable, subject to software of course.

I'm sure there is a reasonable explanation. QoS at 40 Mb/s shouldn't be too taxing. 

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


@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. 😄


@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!

legacy1
Alessandro Volta
VM and other names before that have known about the upstream problem for years for every area is a ticking time bomb!

That problem with no QoS at the hardware level in the modems upstream means that say you QoS at 48Mb and the available is not their you buffer in the modem with no QoS because your router does not know it sees 30Mb yes keep it coming! Yet the modem can't send it because the upstream is loaded and so you buffer.
---------------------------------------------------------------