Re: [httpstreaming] [conex] [dispatch] Q-HTTP

[Ben Niven-Jenkins <[e-mail]>]

On 10 Nov 2010, at 22:08, Mikael Abrahamsson wrote:

> On Wed, 10 Nov 2010, Mike Hammer (hmmr) wrote:
> 
>> 3) The people that build and operate the networks will double (quadruple?) their investments for no additional return out of the goodness of their hearts.
> 
> No, they're going to do it because if they don't give the customers what they promised, their customers are going to leave. This is if there is a functional market and customers actually have a choice of providers. I realise this is not the case in parts of the world, but that doesn't mean we should solve that by technical means, that's a political and regulatory problem, it doesn't have any technical solution.
> 
> Let's not forget that if you're congesting your core and distribution, you're not delivering what your customers have purchased. Period.
> 

It depends what the customer has purchased. Many times what the customer *thinks* they have purchased and what they have *actually* purchased are not the same.

> Everything else is just smoke and mirrors.
> 
> Congestion is acceptable on the customer access, it's not acceptable in the core. That means that any flows/pakets that should yield, are within a single customer domain, and thus in the customers own interest.

I used to work at a large PTT. Our design was to make the core non-blocking (i.e. does not drop packets except under multiple failures) and constrain the backhaul[1] (and to a lesser extent the access line itself).

Your sentence above seems to ignore the backhaul? Which is strange as the backhaul is a significant proportion of the overall cost and larger than the cost of the core itself.

Ben

[1] The bit that transports & aggregates many access connections into the core.