Bill St. Arnaud
- Bill St. Arnaud is a consultant and research engineer who works with clients around the world on a variety of subjects such as next generation Internet networks and developing practical solutions to reduce CO2 emissions such as free broadband and dynamic charging of eVehicles. He is an author of many papers and articles on these topics and is a frequent guest speaker. For more details on my research interests see https://www.researchgate.net/profile/Bill_Arnaud
Monday, February 25, 2008
As predicted, new tools to thwart traffic shaping by telcos and cablecos
[Will the telecos and cablecos ever learn? Implementing traffic shaping tools and trying to block BitTorrent and other applications will eventually backfire. Hackers are already working on tools to thwart such attempts. No one questions that carriers have the right to traffic manage their network. But using secretive techniques without informing users will guarantee the carriers will be saddled with some sort of network neutrality legislation. Instead they should be focusing on traffic engineering techniques that enhance the users P2P experience by establishing BitTorrent supernodes etc. Thankfully a consortium of ISPs and P2P companies had been created to come up with such solutions.--BSA]
[From a posting by Lauren Weinstein of NNSquad
As predicted, P2P extensions to thwart ISP "traffic shaping" and "RST
injections" are in development. We can assume that ISPs will attempt
to deploy countermeasures, then the P2P folks will ratchet up another
level, and ... well, we may well end up with the Internet version of
the Cold War's wasteful and dangerous Mutally Assured Destruction
(MAD). There's gotta be a better way, folks.
"The goal of this new type of encryption (or obfuscation) is to
prevent ISPs from blocking or disrupting BitTorrent traffic
connections that span between the receiver of a tracker response and any peer IP-port appearing in that tracker response,
according tothe proposal.
This extension directly addresses a known attack on the BitTorrent protocol performed by some deployed network hardware."
[Thanks to Matt Petach for these notes from NANOG]
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.
P4PWG is free to join
field test underway
mission is to improve
Marty Lafferty (email@example.com)
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 performance. 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 as possible. 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.
at 6:54 AM