Cable Crafts 'Turbo' Option

A user signalled mechanism to change a carriers scheduler configuration has been around for years?  Interesting - I would guess you could count ATM SVCs - but I have not seen much consumer signaling to reconfigure routers.  Theoretically, it is pretty straightforward.  Until 1,000,000 users spam (say at 100 times per second) press the "button" in a virus DOS attack.

That is my point about ignoring things like the entire frame relay network (OP) as trivially small compared to the phone network and the Internet.  I will stand by my claim to date that there is no 1B (yes I mean 1 BILLION) connection network that uses this kind of technology.  Even at a single carrier level, you are still talking about networks that dwarf things like all the frame relay connections ever made.  The best part about these networks is that they charge the lowest price for this bandwidth.  So adding the complexity has to come with no added cost.

So, I am not saying none of this stuff can be thought of.  I am not saying none of this stuff is impossible.  What I am saying is that it all has to be heavily automated and work without bugs.  There is a term that I use called 100% design.  As most know, I have spent considerable time in the Wireline Access space.  All new access products have more problems with voice than they do with data.  Why is that?  Because the wireline voice network is supposed to work all the time.  That means no changes, no ECOs, no software downloads, no special cases.  This style of design and implementation is very different than what one sees on the data side (what I call 80% design) where things work most of the time.  Imagine a router that never required a protocol restart.  Not one that did so softly or had backup.  One that never failed.  Under any condition.  That is what is required in the residential scale world.  So, before you declare victory - probably ought to think about that.

seven

"Is this (Turbo) really a speed boost (more BW) or a priority change? (lowering normal subs BW) Traffic Management issue!"

It sounds from the article that they're allocating unused bandwidth on the link for turbo purposes.  Maybe that means holding some back to give out (which would be the same effect as to prioritize - reduced collective benefit).  Or maybe they'll only make turbo available when there is extra bandwidth.

I'm lost wrt what OldPots and seven are discussing/arguing. But in either ATM or Ethernet, the technology to implement this has been around for a while in the BSR space (at least since the early part of this decade), for either type of turbo implementation (prioritization or more bandwidth).  A turbo button could dynamically give the user a larger weight vs other subs in a hierarchical scheduler, giving a bigger portion of available bandwidth, or the shaping/policing rate of the user could be increased without changing the weight, or both, or the priority of the user could be raised in a true priority scheduling schema, or the user could be given access to a queue or set of queues that are not constrained by their bw limitation, but only have access to the bandwidth that's left on the link (good for an over-the-top or specialized service which can hit very high rates when it's available), or plenty of other mechanisms to skin this cat.  Maybe these are recycled ATM concepts, maybe not.  But they've all been available for a while and aren't dependent on the L2 access-type.  And they scale to many 10s of thousands (even 100K) of connections per system when the intelligence is distributed to each card.  BW per card is in the 10-20Gpbs range today, but will soon be in the 40-100G range.

Cheap?  Not so much.  

This is a side issue of traffic management but......

seven,
Traffic management techniques (QoS type, not CoS priorities) of more granular models than those simple examples referenced (constant and best effort) have been exercised at a reasonable scale.

Actually I have seen the traffic management techniques used in a very large packet network (better aggregation than ATM or FR and way before IP/Ethernet) to reduce those large old telco BW costs. There also was Frame Relay that used a two level model (guaranteed and shared parameters). Then in 'Fast Packet' (Stratacom) Fortune five enterprise multinode networks that had a proprietary model for a mixture of large quantities of voice, data and video. Even B-PON has a simple adaptive technique (tokens) for sharing uplink traffic mixtures.

I know of a Tier 1 that ran 10 nodes with thousands of users each (some real, others simulated). Evaluating the scaling of the network management of the 'user' link's QoS was a major goal. It ran POS internodal (simulated long distance) links at >90-95%. BVN. The trial was at considerable scale and used a full variety of QoS models and a wide range of values for each of the models parameters. With cheap plentiful BW available at the time the good results were put on the shelf.  So complex TM has been run successfully at reasonable scale for more than simple models.

But to your point of aggregation equipment, that equipment once was much more expensive to scale for traffic management and thus making it cheaper to add more node equipment and cheap internodal links/BW. But that equipment cost has been reduced by a significant levels, especially as more traffic management was added to that once cheaper equipment and implemented in complex line cards.
But how well does that scale today? This economic trade off was discussed several years ago in numerous threads. But now with new/different costs of equipment, BW and their speed tech limits, the push/goal is to do more sub's traffic volume with the same, or little more BW, especially in cable networks.

But my point (maybe not well expressed) was that as sub’s usage increases at quantum leaps with video, it will force better (more granular/complex and slightly more expensive) traffic management techniques for sharing the BW, even if it increases. This unless someone figures out how to deliver increases in bandwidth at quantum leaps and with much better costs. In the current economy quantum BW ain't quantum cheaper.

If service providers increase available BW to meet Turbo needs separately from 'normal' mode without increasing cost to normal subs that is OK. But can Turbo be done in a cable network at a Turbo price sub's are willing to pay for?

OP

"Is this (Turbo) really a speed boost (more BW) or a priority change? (lowering normal subs BW) Traffic Management issue!"

OP,

I beg to disagree about ATMs QoS.  There have been exactly 2 QoS models that have been produced at scale.  By that I mean residential scale of hundreds of millions of connections.  These are (using ATM parlance):

1 - UBR

2 - CBR

At the much lower scale of business connections, some other models have actually been deployed.  Business services cost more and therefore can cost more to create and manage.

Trying to come up with a multi-carrier model scaling to the billion connection number with something like nrt-VBR is a falacy.

seven

Is this really a speed boost or a priority change? Trafic Management issue!

Even if this is a speed boost that has not been allocated at the higher bandwidth, it is really a change in priority in a shared environment.

This turbo concept was proposed for packet networks way before IP/Ethernet!

OP

PS -ATM's QoS will rule again cause you can afford it. Cheaper than new BW?

Even in the cable context, you'd be right that even MSOs and their hardware/software guys have discussed the idea of a turbo button of some sort of bandwidth on demand app for some time.  Also, it would seem that the "invention" being proposed here would owe some something to Comcast's Powerboost technique even though it's supposed to give an automatic speed increase whenever there's latent capacity available on the network. But , in this version, the subscriber could set up that temporary boost, and probably pay something extra for that "privilege."

But whether it's really "new" or not, it looks like the cable industry (at least through its affiliation with CableLabs) is getting ready to defind the idea. Not sure why else they'd go to the length of disclosing the invention or (possibly) filing a patent claim sometime later.

Maybe I'm missing the special sauce here, but Turbo has been around forever.  Juniper E-series has offered this solution at the IP layer for ages  ("ages" in internet years - prior to the 2002 acquisition of Unisphere).  Granted, it doesn't work at the DOCSIS layer, so that may be the ground-breaking piece for cable, but the concept isn't new at all.

Also, telecom providers have already implemented it for their broadband networks.  Look at Telenor's website.  Even if you can't speak Norwegian, "Bredband Turbo, optil 16Mbps" is pretty obvious.  You get the premium speeds of 16mpbs at the at the medium 800K price. Not much of a turbo, but good for ADSL.  Maybe a slightly different concept than this cable version, but a few access-lists and some DPI P2P awareness and you have something pretty close.