[Discuss] Geoff Huston's talk at NANOG53

[cra at WPI.EDU (Chuck Anderson)]

On Sat, May 11, 2013 at 02:48:26AM -0400, Tom Metro wrote:
> He lost me, though, we he started to describe how they would use the
> IPv4 to IPv6 transition points like a toll bridge and extract money from
> content providers. Doesn't tunneling provide a bypass to reach
> competitors who can provide that transition point?

Tunneling isn't really a viable solution, since it will always perform
worse than native connectivity.  You need "rendez-vous" points outside
of the NATs in order to work around the fact than NATs break the
end-to-end model of the Internet.  If those rendez-vous points and
tunnel endpoints aren't co-located along the native traffic route, you
are introducing latency and possible bottlenecks in the path.  You are
also lowering the MTU when tunneling which can cause blackholes when
combined with PMTUd failure.

If the last-mile providers implement Carrier Grade NATs and other such
technologies instead of IPv6, then there will be serious impediments
to the open Internet.  Those last-mile-providers will be able to
extract fees from content providers and end-users for "better"
connectivity--a larger allocation of port numbers, the ability to
request that applications be handled by their NATs and ALGs (perhaps
for a fee), port-forwarding configuration, or when all else fails,
co-location in the last-mile provider's space for content delivery
nodes to be "behind" their NATs.  You know all those things you have
to configure on your own router to allow full (inbound)
connectivity?--you would have to ask the last-mile-provider to do that
for you on their NAT.  In effect, Geoff is saying we'd be reinventing
the 1970s world of telecommunications.

> On the last-mile issue he said that the big difference between the old
> telecom companies and the ones today is that the old ones were
> vertically integrated, such that the sales of profitable services
> subsidized the lower layer infrastructure, while today all the profit is
> in selling content services, with no money to pay for the infrastructure.
> 
> I'm not sure I buy that, if you look at the stats for an ISP like
> Comcast, who supposedly makes more profit on net connections than they
> do selling video. Maybe in the big picture content (aggregated across
> everything available on the Internet) is were the majority of the money
> is, but that doesn't mean that the infrastructure part of the business
> can't itself be quite profitable, and easily afford v6 equipment.

Comcast is vertically-integrated.  They own 100% of NBC Universal as
of March 2013 (and 51% before that).  As a result, they can afford to
cross-subsidize the infrastructure.  And look what has
happened--Comcast is a leader in residential IPv6 deployment.

It's not just about "v6 equipment".  It's about the support cost
because as soon as the customer picks up that phone and calls the
helpdesk, the last mile provider has lost their profit on that
customer for 2 years.  The providers would rather not have to touch
that CPE at all so they can avoid those extra support costs.
 
> >Seth Gordon wrote:
> >> The Right Way to run the telecom system, IMHO, would be to "delaminate"
> >> it (h/t David Weinberger). Have the ILECs be responsible for maintaining
> >> the network infrastructure that shuttles bits from place to place, and 
> >> let them rent out that bandwidth to service providers, but forbid them 
> >> from actually providing any of those services themselves.
> > 
> > I think Geoff Huston's talk at NANOG53 captures pretty well why this
> > doesn't work, and can even be dangerous
> 
> You're referring to Huston's point that the lack of vertical integration
> is to blame?

I'm saying it could be dangerous to force the only way for the
last-mile providers to make money be by them becoming "toll-booths" of
the Internet, and that they would be forced into that role in order to
survive if they are not allowed to also provide services (and become
vertically integrated).

> But we're stuck in a middle ground. We may not have the vertical
> integration of the older companies, but we also don't have the
> separation of concern that Seth describes.
> 
> The problem seem to come about when you have a company that is
> responsible for both, but they see the content side as more profitable,
> and there are no regulations or competitive pressure to make them care
> about the infrastructure side.
> 
> A company that is limited to infrastructure by its legal charter will be
> focused on improving and making that infrastructure profitable. It'll

Here "profitable" means "no investment in improvement".

> require less regulation, as government won't care how it implements the
> infrastructure, as long as it sticks to that as its only business.
> Though this still leaves plenty of opportunity for an ILEC to provide
> minimum required services at the least cost and milk the monopoly. It

"minimum required services".  This is why we don't have gigabit to the
home in the US.

> may be that in the absence of competition, the only answer is to have
> the ILEC managed (i.e. roadmap of speed improvements) by the community,
> even if the physical plant is maintained by a telco under contract.
> 
> At some point Huston mentions that community ran infrastructure might be
> the solution. That's identical to what Seth suggests, except the ILEC is
> government ran instead of private.

Perhaps.

Or alternatively, open up all those rights of way to allow other
providers to build their own last-mile access infrastructure alongside
the ILECs and cable providers'.  Google may be the game-changer here
since they have a huge purse to cross-subsidize the infrastructure
development (Google Fiber).

Today's On The Media (NPR, http://www.onthemedia.org/) brought up
strikingly similar issues with ad-supported news websites (and the
arms race with ad blockers) and the unprofitibility of streaming radio
(Spotify et al).  The only way to support the news and music going
forward may be to have the Internet giants run them at a loss,
cross-subsidized by the giants' other business (Google, Amazon, etc.)