Verizon Policy Statement on Net Neutrality

Sun Mar 1 16:27:13 UTC 2015

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