Re: last mile prioritization (was Re: Enterprise VoIP Peering Point? )

[Paul Vixie <paul@vix.com>]

> On the topic of congestion and the questioned need for prioritization --
> Jasleen Kaur's group at UNC-CH is studying the presence of congestion in
> the Internet. It turns out to be non-trivial to find it.

indeed.  endusers who can't run their MMORPG's have already taught their
dsl and cablemodem providers to maintain enough headroom to their peers;
enterprise and datacenter customers are now receiving competitive SLA's
from their transit providers.  bankrupt fiber/wavelength assets are being
sold/leased at a fraction of their construction costs.  datacenters are
almost invariably carrier-neutral now, just to stay in business.  we are
just not living in a congestion-in-the-middle world any more, and the trend
looks pretty good.

> If we isolate the congestion to places that our RTP doesn't transit, then
> we're done . . . as long as our offered loads grow similarly to the growth
> of available bandwidth. Just because we have enough bandwidth and
> consistently-low delay on today's Internet doesn't mean we'll have it next
> year. If, over time, we do have congestion problems at significant points
> in the Internet, then we probably can't ignore it.

but if you have it, then the MMORPG people will have it too.  the only way
to stay in business while offering congested transit or using congested
peering is if your competitors are all doing the same -- but it's too easy
for your competitors to NOT do it as a way to steal your business, so unless
we go back to some kind of monopoly game where the "congestor" doesn't have
to worry about the customer alternatives, i do not expect congestion-in-the-
middle to ever again be a way of life.

> A related question, though -- if our bandwidth grows much faster than our
> 'need' for it grows, then are we okay? I.e., can we ever have enough
> bandwidth? Somehow I'm skeptical -- since TCP always attempts to use all
> available bandwidth. A single TCP flow attempts to create moderate
> congestion.

there will always be congestion of the kind you describe on the last mile,
since it'll be paid for by someone who (a) wants to use everything they
bought and (b) is only hurting themselves when they run it "too hot".  for
links that aren't at the edge, there's no way to know who's getting hurt
when it runs too hot, and the danger of either increasing customer service
costs or losing renewal business is much higher than the cost of just
putting in more routers and more wavelengths and more peering points.

therefore we'll all need to prioritize our voip traffic at the last mile,
but that's an easily solved problem.  google for "voip priority queuing
cisco ios" if you don't believe this yet.

the solution to congestion-in-the-middle, if it were to occur without easy
economics solutions like "buy more routers, more wavelengths, and more
peering points", is ugly, Ugly, U-G-L-Y.  global end to end MPLS or Frame
would look simple compared to what qos/rsvp over IP must end up looking like.

--
To unsubscribe send a message to voip-peering-request@psg.com with
the word 'unsubscribe' in a single line as the message text body.
An archive is at <http://psg.com/lists/voip-peering/>.