I was going to do the lightning talks separately, but
they all went so quickly (like lightning!) the notes
rather ran together--apologies, but at least I put some
===== separators in to make it somewhat clearer.
(again apologies for typos, and now off to lunch!)
2008.02.18 Lightning talk #1
Laird Popkin, Pando networks
Doug Pasko, Verizon networks
P4P: ISPs and P2P
DCIA, distributed computing industry
P2P and ISPs
P2P market is maturing
digital content delivery is where things are heading;
content people are excited about p2p as disruptive
way to distribute content.
BBC doing production quality P2P traffic;
rapidly we're seeing huge changes, production
people are seeing good HD rollout.
Nascent P2P market pre 2007
Now, P2P is become a key part of the portfolio
for content delivery
P2P bandwidth usage
cachelogic slide, a bit dated, with explosion of
youtube, the ratio is sliding again the other way,
but it's still high.
ISPs address P2P
deploy p2p caching
rate limit p2p traffic
use random ports
Fundamental problem; our usual models for managing
traffic don't apply anymore. It's very dynamic, moves
all over the place.
DCIA has P4P working group, goal is to get ISPs working
with the p2p community, to allow shared control of
Make tracking infrastructure smarter.
Pando, Verizon, has a unch of other members.
There's companies in the core working group,
and many more observing.
Goal is it design framework to allow ISPs and P2P
networks to guide connectivity to optimize traffic
flows, provide better performance and reduce network
P2P alone doesn't understand topology, and has no
idea of cost models and peering relationships.
So, goal is to blend business requirements together
with network topology.
Reduce hop count, for example.
Want an industry solution to arrive before a
regulatory pressure comes into play.
Drive the solution to be carrier grade, rather
than ad-hoc solutions.
P2P applications with P4P benefits
better performance, faster downloads
less impact on ISPs results in fewer restrictions
P4P enables more efficient delivery.
CDN model (central pushes, managed locations)
P2P, more chaotic, no central locations,
P2P+P4P, knowledge of ISP infrastructure, can
form adjacencies among local clients as much
Traditional looking network management, but pushed
to network layer.
share topology in a flexible, controlled way;
sanitized, generalized, summarized set of information,
with privacy protections in place; no customer or user
information out, without security concerns.
Need to be flexibile to be usable across many P2P
applications and architectures (trackers, trackerless)
Needs to be easy to implement, want it to be an open
standard; any ISP/P2P can implement it.
P4P architecture slide
P2P clients talk to Ptracker to figure out who to
talk to; Ptracker talks to Itracker to get guidance
on which peers to connect to which; so peers get told
to connect to nearby peers.
It's a joint optimization problem; minimize utilization
by P2P, while maximizing download performance.
At the end of this, goal is customer to have a better
experience; customer gets to be happier.
Data exchanged in P4P; network maps go into Itracker,
provides a weight matrix between locations without
giving topology away.
Each PID has IP 'prefix' associated with it in the
matrix, has percentage weighting of how heavily
people in one POP should connect to others.
Ran simulations on Verizon and Telefonica networks.
Zero dollars for the ISPs, using Yale modelling,
shows huge reduction in hop counts, cutting down
long haul drastically. Maps to direct dollar
Results also good for P2P, shorter download times,
with 50% to 80% increases in download speeds
and reductions in download time.
This isn't even using caching yet.
Q: interface, mathematical model; why not have a
model where you ask the ISP for a given prefix, and
get back weighting. But the communication volume
between Ptracker and Itracker was too large for that
to work well; needed chatter for every client that
connected. The map was moved down into the Ptracker
so it can do the mapping faster as in-memory
operation, even in the face of thousands of mappings
The architecture here is one proof of concept test;
if there's better designs, please step forward and
talk to the group; goal is to validate the basic idea
that localizing traffic reduces traffic and improves
They're proving out, and then will start out the
Danny Mcphereson, when you do optimization, you will
end up with higher peak rates within the LAN or within
the POP; p2p isn't a big part of intradomain traffic,
as opposed with localized traffic, where it's 80-90%
of the traffic.
What verizon has seen is that huge amounts of P2P
traffic is crossing peering links.
What about Net Neutrality side, and what they might
be contributing in terms of clue factor to that
It's definitely getting attention; but if they can
stem the vertical line, and make it more reasonable,
should help carriers manage their growth pressures
Are they providing technical contributions to the
FCC, etc.? DCIA is sending papers to the FCC, and
is trying to make sure that voices are being heard
on related issues as well.
Q: Bill Norton, do the p2p protocols try to infer any
topological data via ping tests, hop counts, etc.?
Some do try; others use random peer connections;
others try to reverse engineer network via traceroutes.
One attempts to use cross-ISP links as much as
possible, avoids internal ISP connections as much
P4P is addition to existing P2P networks; so this
information can be used by the network for whatever
information the P2P network determines its goal is.
Is there any motivation from the last-mile ISP to
make them look much less attractive? It seems to
actually just shift the balance, without altering
the actual traffic volume; it makes it more localized,
without reducing or increasing the overall level.
How are they figuring on distributing this information
from the Itracker to the Ptracker? Will it be via a
BGP feed? If there's a central tracker, the central
tracker will get the map information; for distributed
P2P networks, there's no good answer yet; each peer
asks Itracker for guidance, but would put heavy load
on the Itracker.
If everyone participates, it'll be like a global,
offline IGP with anonymized data; it's definitely
a challenge, but it's information sharing with a
Jeff--what stops someone from getting onto a tracker
box, and maybe changing the mapping to shift all traffic
against one client, to DoS them?
This is aimed as guidance; isn't aimed to be the
absolute override. application will still have some
intelligence built in.
Goal will be to try to secure the data exchange and
updates to some degree.