Re: [NANOG] [Nanog] P2P traffic optimization Was: Lies, Damned Lies, and Statistics [Was: Re: ATT VP: Internet to hit capacity by 2010]

[Laird Popkin <laird () pando com>]

Interesting discussion. Comments below:

On Apr 24, 2008, at 11:59 AM, Eric Osterweil wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
> On Apr 24, 2008, at 6:48 AM, Keith O'Neill wrote:
>
> > The iTrackers just helps the nodes to talk to each other in a more
> > efficient way, all the iTracker does is talk to another p2p tracker
> > and
> > is used for network topology, has no caching or file information or
> > user
> > information..
>
> After reading the P4P paper, it seems like the iTrackers have some
> large implications.  Off the top of my head:
> - - The paper says, "An iTracker provides... network status/
> topology..." doesn't it seem like you wouldn't want to send this to
> P2P clients?  Is the "PID" supposed to preserve privacy here?  I have
> some doubts about how well the PID helps after exposing ASN and LOC.

The PID is an identifier of a POP, which is really just a grouping  
mechanism telling the P2P network that all of the nodes with IP  
addresses that match a list of prefixes are in "the same place" in  
network terms. The definition of "the same place" is up to the ISP -  
it can be metro area, region, or even local loop or cable head end,  
depending on the ISP's desire to localize traffic. The PID is an  
arbitrary string sent by the ISP, so it could be numbers, name of a  
city, etc., depending on how much the ISP wants to reveal. PID's are  
tied to ASN, but of course all IP's can be mapped to ASN easily, so  
that's not revealing new information.

The information that the iTracker sends to the p2p network is:
    - ASN (which is public)
    - PID (e.g. "1234" or "New York")
    - For each PID, a list of IP prefixes that identify users in the PID
    - A weight matrix of how much the ISP wants peers to connect  
between each pair of PID's. For example, if the PID's were cities, the  
weights might be something like "NYC to Philadephia 30%, NYC to  
Chicago 25%, NYC to LA 2%", and so on. Or if the PID's are  
'anonymized' then it could be something like "123 to 456 30%, 123 to  
876 25%, 123 to 1432 2%" and so on.

> - - As a P2P developer, wouldn't I be worried about giving the  
> iTracker
> the ability to tell my clients that their upload/download capacity is
> 0 (or just above)?  It seems like iTrackers are allowed to control
> P2P clients completely w/ this recommendation, right?  That would be
> very useful for an ISP, but a very dangerous DoS vector to clients.

It's important to keep in mind that P4P doesn't control the P2P  
network, it's just an additional source of data provided to the P2P  
Trackers (for example) in addition to whatever else the P2P network  
already does, helping the p2p network make smarter peer assignments.  
But P4P doesn't tell p2p clients what to do, or give the ISP any  
control over the P2P network. Specifically, if the P4P data from one  
ISP is bad, the P2P network can (and presumably will) choose to ignore  
it.

> These are just a couple of the thoughts that I had while reading.

I appreciate your taking the time. This is a good discussion.

> Eric
>
> > Keith O'Neill
> > Pando Networks
> >
> > Mike Gonnason wrote:
> > > On Thu, Apr 24, 2008 at 5:30 AM, Michael Holstein
> > > <michael.holstein () csuohio edu> wrote:
> > >
> > > > > ISP's have been very clear that they regard their network maps
> > > > > as being proprietary for many good reasons. The approach that
> > > > > P4P takes is to have an intermediate server (which we call an
> > > > > iTracker) that processes the network maps and provides
> > > > > abstracted guidance (lists of IP prefixes and percentages) to
> > > > > the p2p networks that allows them to figure out which peers are
> > > > > near each other. The iTracker can be run by the ISP or by a
> > > > > trusted third party, as the ISP prefers.
> > > >
> > > > Won't this approach (using a ISP-managed intermediate)
> > > > ultimately end up
> > > > being co-opted by the lawyers for the various industry "interest
> > > > groups"
> > > > and thus be ignored by the p2p users?
> > > >
> > > > Cheers,
> > > >
> > > > Michael Holstein
> > > > Cleveland State University
> > >
> > > This idea is what I am concerned about. Until the whole copyright
> > > mess
> > > gets sorted out, wouldn't these iTracker supernodes be a goldmine of
> > > logs for copyright lawyers? They would have a great deal of
> > > information about what exactly is being transferred, by whom and for
> > > how long.

The P2P network doesn't provide this kind of information to the  
iTracker.

We're comparing two models, "generic' and 'tuned per swarm'.

In the 'generic' model, the P2P network is given one weight matrix,  
based purely on the ISP's network. In this model, the P2P network  
doesn't provide any information to the iTracker at all - they just  
request an updated weight matrix periodically so that when the ISP  
changes network structure or policies it's updated in the P2P network  
automatically.

In the 'tuned per swarm' model, the P2P network provides information  
about peer distribution of each swarm's peers (e.g. there are seeds in  
NYC and downloaders in Chicago). With this information, the iTracker  
can provide a 'tuned' weight matrix for each swarm, which should in  
theory be better. This is something that we're going to test in the  
next field test, so we can put some numbers around it. This model  
requires more communications, and exposes more of the p2p network's  
information to the ISP, so it's important to be able to quantify the  
benefit to decide whether it's worth it.

BTW, if this discussion is getting off topic for the NANOG mailing  
list, we can continue the discussion offline. Does anyone think that  
we should do so?

> > > -Mike Gonnason
> > >
> > > _______________________________________________
> > > NANOG mailing list
> > > NANOG () nanog org
> > > http://mailman.nanog.org/mailman/listinfo/nanog
> >
> >
> > _______________________________________________
> > NANOG mailing list
> > NANOG () nanog org
> > http://mailman.nanog.org/mailman/listinfo/nanog
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.5 (Darwin)
>
> iD4DBQFIEK5hK/tq6CJjZQIRAgXqAJd8t3XkmYqo1WYaJP7qOF4W67tYAJ9C5hZ+
> iwVc8ZU8AJ3f98KCFCq8Eg==
> =LEPV
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> NANOG mailing list
> NANOG () nanog org
> http://mailman.nanog.org/mailman/listinfo/nanog

Laird Popkin
CTO, Pando Networks
520 Broadway, 10th floor
New York, NY 10012

laird () pando com
c) 646/465-0570


_______________________________________________
NANOG mailing list
NANOG () nanog org
http://mailman.nanog.org/mailman/listinfo/nanog