Subject: Re: [p2pi] ALTO BoF - generalize the problem

From: Laird Popkin <[email-masked]>
Date: Mon, 14 Jul 2008 16:58:05 -0400 (EDT)

Good idea.

Here's a quick explanation of P4P. There's more info at http://www.openp4p.net/.

The components in P4P are:
- p2p client
- p2p server (coordinates p2p network, optional).
- P4P optimizer engine (iTracker that creates unified view from multiple ISP iTrackers)
- iTracker server (run by ISP or third party)
- ISP

The data flow is:
- ISP generates network map and policies, loads them into their iTracker. This map is expressed as locations (called PIDs), each with lists of IP prefixes of addresses, and ASNs, with 'costs' provided for interconnections between each PID-PID or PID-ASN pair.
- The ISP iTracker exposes an 'abstract weight matrix' of all PID-PID and PID-ASN pairs for the ISP.
- The P2P server gets the PID definitions (lists of IP prefixes for each location) from each ISP iTracker. This is a one-time retrieval (or daily, etc.).
- The "optimization engine" iTracker retrieves the weight matrixes from each ISP iTracker, and generates a unified weight matrix.
- P2P server sends a list of peer locations to the optimizer engine, and gets a weight matrix for all PID-PID and PID-ASN connections for all ISPs. This is done for each swarm, and updates periodically, as the weights vary over time depending on the peer distribution and changing network conditions (e.g. a link outage, time of day, etc.). This is an expensive communication, as it has to be handled for each (popular) swarm, every few minutes.
- Alternatively the guidance ignores peer distribution, so the P2P server retrieves a full weight matrix. This is a much cheaper implementation (e.g. one message, or daily, etc.).

OK, so how does this map into ALTO?

Where I think that ALTO could apply:
- The protocol between the p2p server and the iTrackers could be ALTO. The contents of the message would be lists of network locations (e.g. IP prefixes, PIDs) and weights (e.g. floating point numbers between 0 and 1).
- The protocol between the iTrackers (e.g. the "optimization engine" and the ISP iTrackers) could be ALTO. This is pretty much the same kind of communication as above, though a different path.

- Laird Popkin, CTO, Pando Networks
  mobile: 646/465-0570

----- Original Message -----
From: "Jason Livingood" <[email-masked]>
To: "Laird Popkin" <[email-masked]>, "Reinaldo Penno" <[email-masked]>
Cc: "PAPADIMITRIOU Dimitri" <[email-masked]>, [email-masked], "Saverio Niccolini" <[email-masked]>
Sent: Monday, July 14, 2008 3:49:43 PM (GMT-0500) America/New_York
Subject: RE: [p2pi] ALTO BoF - generalize the problem

Laird - It may be helpful to post what you think the precise mapping of
P4P concepts into the ALTO terms will be.  That should help guide some
of the P4Pers and folks doing P4P tests right now. 

Jason 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Laird Popkin
> Sent: Friday, July 11, 2008 11:21 AM
> To: Reinaldo Penno
> Cc: PAPADIMITRIOU Dimitri; [email-masked]; Saverio Niccolini
> Subject: Re: [p2pi] ALTO BoF - generalize the problem
> 
> Whether ALTO covers one or both depends on the contents of 
> the ALTO messages, which is intentionally quite abstract at 
> the moment. This is intentional, so that ALTO can be used to 
> express a wide range of possible p2p optimization strategies.
> 
> To express what P4P does in ALTO, for example, I could 
> imagine that the P4P iTracker is an ALTO client to the ISP's 
> ALTO server, and is an ALTO server to the P2P network's ALTO 
> client, with different levels of information flowing through 
> each ALTO client/server communication. That is, I believe, 
> within the scope of what we expressed in the ALTO requirments.
> 
> - Laird Popkin, CTO, Pando Networks
>   mobile: 646/465-0570
> 
> ----- Original Message -----
> From: "Reinaldo Penno" <[email-masked]>
> To: "Laird Popkin" <[email-masked]>
> Cc: [email-masked], "Saverio Niccolini" 
> <[email-masked]>, "Enrico Marocco" 
> <[email-masked]>, "PAPADIMITRIOU Dimitri" 
> <[email-masked]>
> Sent: Friday, July 11, 2008 11:05:12 AM (GMT-0500) America/New_York
> Subject: Re: [p2pi] ALTO BoF - generalize the problem
> 
> Hello,
> 
> The latter does not seem to be part of the charter at this 
> point. It certainly needs to be part of any working solution 
> but I'm not sure if it can be easily standardized.
> 
> Thanks,
> 
> Reinaldo
> 
> On 7/10/08 8:29 AM, "Laird Popkin" <[email-masked]> wrote:
> 
> > LP: I would say that there are two layers of communication 
> that ALTO 
> > needs to address. One layer is between the ALTO client 
> (e.g. p2p app, 
> > p2p server) and the ALTO server, and the second is between the ALTO 
> > server and the source of network topology information (e.g. 
> ISP, third-party).
> 
> 
> _______________________________________________
> p2pi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/p2pi
> 
_______________________________________________
p2pi mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/p2pi

---

From: Stanislav Shalunov <[email-masked]>
Date: Tue, 15 Jul 2008 16:36:11 -0700

Transport issues belong in the transport area with TANA.  Congestion control and everything that deals with depending on network utilization is a transport issue.  Static information, costs, caches, and such do not belong in TANA and go to ALTO.

-- Stas

-----Original Message-----
From: "Laird Popkin" <[email-masked]>
To: "Salman Abdul Baset" <[email-masked]>
Cc: [email-masked]
Sent: 7/15/08 6:41 AM
Subject: Re: [p2pi] ALTO BoF - generalize the problem

In terms of whether this issue is more appropriate in TANA or ALTO, I gather that we'll need to work that out at the BOFs. But I hope that it fits within one of them.

---

From: Stanislav Shalunov <[email-masked]>
Date: Tue, 15 Jul 2008 16:36:17 -0700

Precisely.  Thank you.

-----Original Message-----
From: "Enrico Marocco" <[email-masked]>
To: "Salman Abdul Baset" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Sent: 7/15/08 5:25 AM
Subject: Re: [p2pi] ALTO BoF - generalize the problem

Salman Abdul Baset wrote:
>>> Yes, there are scenarios where it's not clear whether there is a relevant
>>> link capacity, etc., but I'm fine getting no guidance in those situations.
>>> Even an 80% accurate knowledge of what the user's network capacity is would
>>> be a big improvement over the current situation.
>> Not without additional information. If I run five P2P apps on different
>> machines in my home and they all know my access link capacity through some
>> mechanism, they'll still self-interfere before they have ramped up to that
>> capacity.
> 
> It seems that this is a scenario where cable/DSL modem should pass
> information of self-interference to other machines behind the same modem.
> For example, if mom/dad is using the Internet connection for work and are
> not getting the expected speed, they will like to know which child/device is
> hogging the connection.

This discussion is certainly interesting, but it is not about ALTO any
more, is it? I mean, in this context we are trying to charter a working
group for developing some mechanism for optimizing peer selection. At
best, "network" information will be used for selecting between a peer
with FTTH access and a DSL ones, when no additional information is
available.

The TANA BoF discussed on the [email-masked] mailing list explicitly
covers transport issues like congestion notification and sharing of
network resources; its problem statement is available at:
http://tools.ietf.org/id/draft-shalunov-tana-problem-statement

-- 
Ciao,
Enrico