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