The Telco 2.0 research team is undertaking some detailed business modelling around ‘Rich Media Distribution’ over the summer. We’ll also be debating this with industry leaders on 4-5 November at our next event in London. More on both of these anon. In the meantime, here’s some analysis of Verizon’s P4P next generation file swapping initiative:
We’re not sure how it happened, but Verizon appears to be turning
into one of the most interesting telcos around. For a start, there’s
the fibre - but then again, even AT&T has an FTTH roll-out of sorts going on. Then there’s ODI,
their developer platform initiative. The whizzy portal-like Dashboard
application Verizon Wireless is putting on its LG Chocolates has a
publicly available API so people can do evil things to it. But perhaps the most significant change at Verizon is P4P, an attempt to reconcile the huge RBOC with the world of peer-to-peer applications, using a technology developed at Yale University as Haiyong Xie’s PhD research project.
We’ll start by noting that a lot of people read “P2P” and think
copyright. Of course, the means by which you distribute something don’t
determine its content, and certainly not its intellectual property
status, so this is a red herring. Anyway, we’ll recognise this and move
on - we’re interested in the telecoms aspects, not the record industry.
Why don’t telcos/ISPs like P2P?
Theoretically it should be one of the most efficient ways of
delivering heavyweight content like video, music and big datasets; as
more people want a specific file, so more sources of it are available.
The scaling process is that of a mesh network. But of course, it
doesn’t work like that; the Internet isn’t actually a random mesh
network, but it does look like one to its participants. Instead, the
underlying topology is very much scale-free, with more mesh-like areas
interconnected by unusually critical and heavily-used links.
OpenP4P chart showing traffic by type
Thinking of it in economic, rather than technical, terms, this comes
out even more strongly; the cost of delivering bits varies sharply as
they make their way across the Net, depending on the markets for
various kinds of lower-layer connectivity, the distinction between
peering and transit, regulatory issues, time, and geography. The
problem with P2P clients is that they tend
to hammer away exactly as if they were part of a dense mesh network,
where it doesn’t really matter where traffic comes from or goes to -
but in fact, their behaviour can cause serious economic problems for ISPs if it means a high-cost sector of the network is heavily used.
This could be literally anywhere - for an Australian or New Zealand
operator, it could be a congested transpacific cable, for an
emerging-market one it could be an expensive international satellite
link, for a British operator it could be the BT-owned local loop under IPStream
or their BT Wholesale backhaul links, for an operator in a small but
highly connected country like the Netherlands it could be metro
connectivity, and for an FTTH operator it might be their peering relationships at their friendly local IX. But what’s certain is that there’s always somewhere, but it’s never the same place.
It’s Not That Simple
Some P2P clients now attempt to prefer
local peers; but this is where the second clause comes in. What is
excellent optimisation for one network will be poison for another;
trying to maximise local traffic is exactly what the British or Dutch
examples don’t want. The British ISP will
have to fork out much more to Openreach and/or BT Wholesale; the Dutch
one would much rather push traffic out to the abundant and cheap
international connectivity of AMS-IX.
The problem is really that the business models of both parties to the game don’t work. Both ISPs and P2P users
are constrained by their assumptions to behave as if they were
adversaries; one desperately trying to stop the flood of traffic or
sting it for more money, one desperately trying to evade them. What
they really need to do is to co…well, whatever the verb from
“co-opetition” is. If there was a way for ISPs to announce details of the network’s cost structure, so the P2P client
can programmatically adapt its behaviour, this problem could be
overcome. Rather than imposing crude preferences on the users through QOS and deep packet inspection, the ISP would play a tune for the clients to dance to.
OpenP4P Results
This, in a nutshell, is the aim of OpenP4P. Here are the results
of Verizon,Telefonica, Pando Networks, and Yale’s field trial of the
system. They are impressive, on the surface at least; but we’d note
that so far, they’ve only tested it in the context of Verizon and
Telefonica’s network topology. Obviously enough.
The data showed a dramatic cut in the traffic hitting VZ’s
external peering links and also a big cut in traffic on their long
lines between metro areas; unsurprisingly, given that the project’s aim
was to localise traffic, the utilisation of local loops and metro
backhaul was dramatically increased (this went from 6% of the total P2P to 57%). We don’t know how well it would work if the optimisation target was different - for example, to maximise traffic on LLU lines and lay off the backhaul, or to minimise internal traffic and maximise external.
OpenP4P results on Verizon: a metric of hop count over time for P2P and P4P traffic
However, Telefonica’s half of the trial does suggest that it works; they saw a 57% cut in the number of hops a P2P packet
traversed, compared to a fivefold reduction for Verizon, but saw a much
greater increase in the amount of traffic served within their local
networks (it increased by a factor of 36, compared to a factor of 10 at
VZ).
More Unanswered Questions
There are also some issues of security and trust that still need to
be cleared up; the “trackers” that provide the network data to clients
are in a very responsible position, which hackers would give their eye
teeth for. A malicious tracker would be able to steer all the P2P traffic on the network down the most critical link, for example.
And how is this going to make money? By definition, if we’re
publishing this information to the Internet at large, we can’t really
restrict who reads it. More fundamentally, we don’twant to do
that - because this doesn’t serve our interests at all. Refusing some
group of applications the information would just add them to the heap
of undifferentiated P2P traffic that’s clogging the lines.
Conclusions: Fundamentally Two-Sided
But there is an implicit two-sided market
here. Users’ cooperation is rewarded with improved throughput and
latency; content providers’ cooperation is rewarded by better quality
delivery; the telco is rewarded with lower costs. Trade, in a sense,
has been facilitated by the creation of a new network API. P4P is precisely what telcos and ISPs
ought to be doing, faced with this coordination problem. However, we
would recommend considerable caution in deploying technologies like
this until the engineering and operations aspects of security have been
clarified. The best way to clarify them would, of course, be to
participate in the Working Group.
This Blog is republished from
www.Telco2.net/blog.
The Telco 2.0 Initiative is a new industry program focused on helping
with this thorny question: "How do we (telcos, handset manufacturers,
Media companies, IT players, NEPs, etc) make money in an IP-based
world?"
Posted
Jul 16 2008, 09:16 AM
by
Telco 2.0