On 3/1/2015 10:01 AM, Michael Thomas wrote:


They didn't want to give channels for internet bandwidth either. Life would have been *far* more simple had the MSO's not *forced* the hardware designer to use their crappy noisy back channel, such as it was. The move from analog -- which was happening around the same time -- pretty much negated that reason, but by then they had a bunch more
reasons why they thought slow upstream was great for business.


To be fair, because of the size of their loops when they went data, they needed as much download as they could put on the wire and even then we listened to complaints of the "too many customers on a cable loop" for years.

Of course, some cable companies shorted their loops and didn't have saturation problems on the loop side. You'd have to ask them how much excess they have during peak that would allow for higher upstreams without sacrificing producing downstream.

DSL standards were all over the place, and most models make sense if you take into account what they need for a downstream. This is true for ADSL2+ even, given that it is also used for video and the extra downstream takes that into account more than anything. There are annexes that have higher upstreams, but the vendor support on them is limited.

This is why I always argue that standards should cease to look at static allocations and support variable with both default "starting rates" and "cap rates" depending on what the provider needs. Even if we went with a longer term adjustment scheme, it would still be better; so your 1.5mb/s upstream eventually shifts to a 10mb/s upstream because you are actively using it. Simple user controls would be nice (if both are being saturated, allow for balance at symmetric, or downstream is greedy; only give upstream if downstream isn't saturated).

I don't design these things, don't have the time for it, so I won't overtax my brain actually trying to design it. However, given the work on GMPLS, I suspect it's very probable that we could have something highly variable based on demand. Wasting timeslots/frequencies in technology is still waste. KISS is only better then the solution meets needs. Over the years, I've found that we have made things a lot more complex to deal with needs. This is just another area that could use some of that complexity. It also removes a lot of the need for annexes which generally weren't all supported in a vendor product anyways.

Jack

Reply via email to