» ISP News » 
Sponsored Links

DOCSIS 3.1 Tweak Bringing Ultra Low Latency to Cable Broadband

Tuesday, Jun 25th, 2019 (12:01 am) - Score 9,939

Cable broadband and TV operators, such as Virgin Media in the UK, that have adopted or are in the process of adopting the new DOCSIS 3.1 standard could also benefit from a new software update. This could enable them to deliver ultra low latency times of around 1ms (millisecond) or less.

Latency is simply a measure of the time (i.e. the delay in milliseconds – 1000ms = 1 second) that it takes for a packet of data to travel from your router to a remote server and then back again (ping). The shorter the delay, the better. All of this is particularly important for fans of fast paced online multiplayer games, where a low ping (lower figures are better) can result in smoother gameplay.

Generally most modern connections already deliver good latency performance and the best tend to be “full fibre” (FTTP) links, as well as future 5G mobile services, where latency times on the network can be down in the low single figures (1-10ms). Admittedly you can get this on FTTC connections too, at least provided the remote server, ISP side network and your local network are all optimally setup (varies from server to server – ISPs can only do such much to improve this).

The new DOCSIS 3.1 standard for cable broadband networks has already been designed to improve upon the older methods via Active Queue Management (AQM). As a result it experiences typical latency performance of around 10ms on the Access Network link, although spikes of 100ms+ are still possible when under heavy load (consumers will rarely see it this bad).

Earlier this year a new specification was added to the D3.1 standard by CableLabs called Low Latency DOCSIS (LLD), which aims to reduce typical latency performance to around 1ms even when under heavy load and the best thing is that the operator can deploy this via a cost-effective software update to existing kit. One step closer to ensuring that hybrid fibre coax networks are able to remain reasonably competitive with full fibre ones.

docsis 3.1 lld improvement

So how is this possible? Internet traffic consists of various types of data and latency isn’t as important to all of those (e.g. file downloads) as it to others (e.g. online video games). Conversely the types of data where latency tends to be less important are often also the same types that tend to benefit from more bandwidth (broadband speed).

In simple terms, LLD recognises this difference and somewhat pre-emptively optimizes the flow of internet traffic through the network in order to reduce latency. It does this by, among other things, targeting two of the biggest delay areas for latency within the DOCSIS 3.1 network – “Media Acquisition” and “Queuing“.


The “Queuing” delay is mainly caused by the current TCP protocol and its variants, which uses a “congestion control” algorithm to adjust to the available bandwidth at the bottleneck link through the network. Typically, this will be the last mile link – the DOCSIS link for cable customers – where the bandwidth available for each application often varies rapidly as the activity of all the devices in the household varies.

With today’s congestion control algorithms, the sender ramps up the sending rate until it’s sending data faster than the bottleneck link can support. Packets then start queuing in a buffer at the entrance to the link, i.e. the CM or CMTS. This queue of packets grows quickly until the device decides to discard some newly arriving packets, which triggers the sender to pause for a bit in order to allow the buffer to drain somewhat before resuming sending.

This process is an inherent feature of the TCP family of Internet transport protocols, and it repeats over and over again until the file transfer completes. In doing so, it causes latency and packet loss for all of the traffic that shares the broadband link.

LLD addresses Queueing Delay by allowing non-queue-building applications to avoid waiting behind the delays caused by the current TCP or its variants. At a high level, the low-latency architecture consists of a dual-queue approach that treats both queues as a single pool of bandwidth.

Media Acquisition

This delay is a result of the shared-medium scheduling currently provided by DOCSIS technology, in which the CMTS arbitrates access to the upstream channel via a request-grant mechanism. LLD cuts Media Acquisition Delay by using a faster request-grant loop and by adding support for a new proactive scheduler that can provide extremely low latency service.

The White Paper (PDF) goes into a lot more detail, although at present we’re not sure if it will be included when Virgin Media unveil their first DOCSIS 3.1 based “gigabit cities” later this year (here). The specification is fairly recent and we imagine that an operator like Virgin might wish to test it a lot before introducing into a live environment.

We have asked their press team about this but as D3.1 hasn’t yet launched (commercially) in the UK then they may be unable to answer. In any case the move to regular DOCSIS 3.1 will still bring plenty of latency improvements and it’s worth noting that, in terms of online video games, the fastest rate at which humans appear to be able to process incoming visual stimuli is about 13ms.

By Mark Jackson
Mark is a professional technology writer, IT consultant and computer engineer from Dorset (England), he also founded ISPreview in 1999 and enjoys analysing the latest telecoms and broadband developments. Find me on X (Twitter), Mastodon, Facebook and .
Search ISP News
Search ISP Listings
Search ISP Reviews
23 Responses
  1. Avatar photo James says:

    So does this just mean they are prioritising UDP and similar protocols, to mask the fact that TCP protocols are generally the bandwidth hogs (ie streaming and file downloading)?

    1. Avatar photo spurple says:

      No. A simplistic view is to think of it as buckets. Most modern implementations do the classification int buckets by “flow” which can logically be thought of as a connection. For example, there could be a bucket that is explicitly marked as “high priority” by the sender. Call it Bucket H. Then there is a bucket for unclassified or Bulk traffic, call it bucket B. Then there will be a bucket for interactive (low latency desired) traffic, call it bucket I.

      Bucket H is guaranteed 50% of available bandwidth. Things that explicitly mark themselves as high priority include VOiP and Wifi Calling traffic. We all know that they generally aren’t bandwidth heavy, they’re just sensitive. They will do fine in 50% of almost any link especially one faster than 2mbps.

      Bucket B is the default class. It is allowed up to 99% of the available bandwidth, provided there is nobody else using that bandwidth. It generally gets a low minimum guarantee, something like 10%.

      Bucket I would be for traffic like SSH (Secure Shell) and perhaps Gaming traffic, and would be guaranteed something like 40% of the bandwidth.

      Whenever traffic arrives, there’s a classifier which will put the traffic into those 3 buckets, and the transmitter will pick from each bucket in turn according to how much of the bandwidth it is permitted to use. If the higher priority buckets are empty, then it always picks from the bulk bucket.

      Experience and years of practical implementation of this kind of scheme on the wider internet shows that it results in great average latency for every user and doesn’t unnecessarily constrain the peak usable capacity.

      Notice that all of this is kind of voluntary. Anyone could just irresponsibly mark their traffic as high priority. Yes, but since high priority traffic doesn’t get the full speed of the link, you’d be capping yourself if you tried to run downloads by marking your packets as high priority.

      In practice, almost nobody bothers to correctly mark their traffic so this provides little benefit. I have looked at a few games on PS4 and XBox One and none of them properly mark their traffic as “I” (interactive), and so they only benefit slightly from the fact that improvements in latency benefit everyone equally.

    2. Avatar photo Ferrocene Cloud says:

      spurple, in my experience of working at ISPs and MSPs from small to global, we ignore DSCP markings and remark the packets according to our own policies, and any additional services that have been sold to the customer. Or if we do listen to them, it’s because we’ve expressly permitted it.

      We’re not just going to blindly allow a customer to send a gig of traffic all marked EF, which could have a negative impact on network performance and other customers.

    3. Avatar photo spurple says:

      @Ferrocene, Interesting. I’ve not done this at carrier-scale, so I don’t know what kind of challenges you face.

      How could you know which traffic is EF ? Would you just do it by port and protocol information? I can’t see how you could DPI this intelligently without adding undue latency, or do the right thing for encrypted traffic.

      At my home router for example, since apps don’t bother with DSCP flags, I configured my router to mark UDP datagrams of less than 600 bytes as CS4 because this covers most online gaming traffic and some DNS traffic. It doesn’t improve the latency I encounter, and now I get confirmation as to why 🙂

      I can think of ways ISPs could make this so that even a reckless customer couldn’t harm the network by marking all of their traffic as EF. For example, if QOS was applied at ingress into the edge of the ISP network (wherever you do the bandwidth limiting for the service the customer paid for), and since the bucket for EF is usually relatively small, they’d hit the bottleneck right at the beginning.

    4. Avatar photo Ferrocene Cloud says:


      Obviously I can’t speak for every ISP/MSP in existence, though I would imagine many run their networks similarly because it makes good business sense, even if the exact specifics differ. There’s no real sense in allowing others to control your network, not just because of the loss of control but because it’s a potential attack vector as well.

      Because of this, you apply QoS as close to ingress as possible. No point letting someone swamp half my network with EF traffic only controlling it well past ingress where it could have caused queuing and delays upstream. You also don’t want to be having to apply QoS policies on the core. Get that traffic under control as soon as possible!

      Incidentally, bandwidth policing is done on the CPE and/or PE. This even applies to residential kit, such as my Virgin Media router setting the max download rate at something like 575Mbps. For DSL of course, Openreach control what gets negotiated with the DSLAM. If it’s customer kit and they do it wrong, then too bad it’s probably going to be suboptimal for them.

      The config I saw the other day was a relatively small bucket for EF (say 5-10% of bandwidth), with an additional overflows which you mark at something like 41, 42, 43, and then finally dump the rest in the default best effort class up to the bandwidth limit. After the burst limit, it’s hard dropped.

      As for which traffic is EF, depends on the exact service being provided. I’ve seen cases where the customer can mark the traffic themselves and we stop it from going out of control. If they mark it badly and end up with problems on premium traffic, too bad they’ve got to pay.

      For managed services it’ll usually be a policy that’s been agreed with customers at point of sale, where they send the traffic and we classify it accordingly. Typically this is most often used for VoIP/video where we get given their source subnet and ports.

      Not particularly sure how it gets handled on the residential side, as I’ve always dealt with the business world. Others can answer that far better than me.

    5. Avatar photo spurple says:

      @Ferrocene , I think you pretty much confirmed that there is no way that a customer could abuse this if you accepted the DSCP flags from the customer, at least in your networks.

      If you’re policing the traffic at the earliest point of ingress into your network, then there is no way that a customer could send 1Gb/s of Expedited forwarding traffic unless they have a 10Gbit link, since as you have said, you cap the EF bucket to about 10% of the allowed speed. If a customer blindly marked all their traffic as EF, they’d only really be able to use about 10% of their capacity if the ISP’s system is doing it’s job properly.

      Please keep in mind, it goes without saying that you can only speak as to your experience/knowledge or extrapolate from it :), and also, well, It may seem like I’m arguing with you, but I hope that with any luck, my arguments could reach someone at an ISP who may be able to perhaps suggest a rethink of how they treat DSCP flags, if what you describe is the norm industry-wide.

    6. Avatar photo Ferrocene Cloud says:


      Sorry to clarify it is possible for customers to try to abuse it. The abuse is stopped because we don’t trust them (completely). If they try sending excess EF traffic it will get remarked to a lower value, or dropped.

      If I was in charge of the residential network, away from business contracts and SLAs, I might well implement a policy that completely ignores any dscp markings inbound and classify it according to my own policies.

      Of course, if a customer wants to mark all their traffic the same, it completely fails at the differentiated part and it would ultimately just harm themselves.

      You could of course try pinging with the ToS set to mimic EF and see if it decreases latency. If it does, you find out if your provider actually respects your marking… to an extent!

  2. Avatar photo Sean says:

    Both Birmingham and Sheffield live when Virgin Media work job make learning more fixing old medon need new medon Inside working cable signal weak problem time V6 box.

    1. Avatar photo Dave says:


  3. Avatar photo Toby Adams says:

    Still life in those copper cables yet! Imagine a symmetric 1Gbps link with 1-2ms ping offered by Virgin Media. A real game changer and the technology is all already there for it. So exciting to see this come to fruition.

    1. Avatar photo SimonR says:

      Might be too little too late, the rate that some fibre is being laid.

      If they could do it, I’d stay with them. But fibre is being laid within a mile of me, and VM have no (published) plans to upgrade around here.

    2. Avatar photo CarlT says:

      They aren’t upgrading anyone from HFC to FTTP, SimonR. No need. Coaxial with fibre to the tap can handle 3GHz+: more than enough to sell symmetrical 10G to end users.

    3. Avatar photo SimonR says:

      Sorry CarlT, didn’t mean I wanted FTTP from VM. More about the upload/symmetry for me, and VM don’t seem to be addressing it where I am. Ultimately, I couldn’t give a monkeys about the tech used so long as the result’s there, and if it could be done without a reinstall all the better.

    4. Avatar photo CarlT says:

      As they have for years VM have been able to get away with lower upstream than the competition for a while. It’s still not a big thing for people. Zero benefit to VM in undertaking the upgrades required to provide symmetrical services: gigabit downstream is the priority for now.

    5. Avatar photo SimonR says:

      Yep, completely understand and appreciate that. I’m in a minority, but it’s why I’m waiting to move.

  4. Avatar photo Archie says:

    This would be awesome. I have Virgin’s FTTP and the lowest latency I’ve had on an online game is 4ms, typically I’ll get between 10-20ms if it’s based in the UK. It would be great to have what is essentially a LAN ping to a remote server!

    1. Avatar photo CarlT says:

      You aren’t going to get 1ms to remote servers. This latency is just between cable modem and the kit at Virgin Media. You were unlikely to have been getting 4ms to remote servers unfortunately.

    2. Avatar photo Archie says:

      You do make me laugh.

    3. Avatar photo CarlT says:

      You are very easily amused. Sadly not as well informed as you are entertained, though. Do read the links Mark provided if interested in learning more.

    4. Avatar photo Dan says:

      Hi mate I have superhub3 380d 38up im just wondering have I got FTTP

  5. Avatar photo Matt says:

    As I’ve said for years if Liberty Global we’re willing to put the money in like Comcast or even Vodafone Germany they could of had been ahead of the FTTP Surge and possibly looking at DCOIS 3.1 Full Duplex trials now

    1. Avatar photo mike says:

      Why would the bother when the competition is so shit?

    2. Avatar photo Matt says:

      Because they really need to at this point Openreach are deploying FTTP on mass now and Cityfibre/Vodafone are going be a strong competitor in many cities across the UK as well. It’s been obvious for a while that Liberty Global want out of the Cable business in Europe if all their current sales go through they will only have Poland and Slovakia East of Belgium left. If Liberty Global put in the money in the UK and Ireland they could be competitive with FTTP players for a long time to come framework is already in place to do 10G Symmetric via Cable. Many Cable companies in Europe are either nearing completion of basic DOCSIS 3.1 Conversion or at least well underway in UK they aren’t even at a launch yet.

Comments are closed

Cheap BIG ISPs for 100Mbps+
Community Fibre UK ISP Logo
Gift: None
Virgin Media UK ISP Logo
Virgin Media £25.00
Gift: None
Vodafone UK ISP Logo
Vodafone £26.50 - 27.00
Gift: None
Plusnet UK ISP Logo
Plusnet £27.99
Gift: None
Zen Internet UK ISP Logo
Zen Internet £28.00 - 35.00
Gift: None
Large Availability | View All
New Forum Topics
Cheapest ISPs for 100Mbps+
Gigaclear UK ISP Logo
Gigaclear £17.00
Gift: None
Community Fibre UK ISP Logo
Gift: None
BeFibre UK ISP Logo
BeFibre £19.00
Gift: None
YouFibre UK ISP Logo
YouFibre £21.99
Gift: None
Hey! Broadband UK ISP Logo
Gift: None
Large Availability | View All
The Top 15 Category Tags
  1. FTTP (5649)
  2. BT (3547)
  3. Politics (2578)
  4. Openreach (2327)
  5. Business (2304)
  6. Building Digital UK (2263)
  7. FTTC (2054)
  8. Mobile Broadband (2014)
  9. Statistics (1815)
  10. 4G (1702)
  11. Virgin Media (1654)
  12. Ofcom Regulation (1485)
  13. Fibre Optic (1414)
  14. Wireless Internet (1410)
  15. FTTH (1382)

Copyright © 1999 to Present - ISPreview.co.uk - All Rights Reserved - Terms , Privacy and Cookie Policy , Links , Website Rules , Contact