Subject: [p2pi] New version of the problem statement

From: Enrico Marocco <[email-masked]>
Date: Mon, 30 Jun 2008 18:27:49 +0200

An updated version of the problem statement is available at the 
following link:
http://www.ietf.org/internet-drafts/draft-marocco-alto-problem-statement-01.txt

Diffs from the previous version may be viewed at:
http://tools.ietf.org//rfcdiff?url1=http://tools.ietf.org/id/draft-marocco-alto-problem-statement-00&url2=http://www.ietf.org/internet-drafts/draft-marocco-alto-problem-statement-01.txt

So far, it seems there is agreement on the fact that ALTO will focus on 
an application-layer interface for exposing some kind of topology 
information to be used for optimizing traffic generated by a wide range 
of applications (including file-sharing, VoIP, real-time streaming.)

What is probably less agreed at this time is what kind of information 
the protocols specified in ALTO are going to provide, whether it should 
be static information (e.g. from AS1, AS2 is always preferred to AS3,) 
dynamic information (e.g. right now the link between AS1 and AS2 is 
congested, peers in AS1 should prefer peers in AS3) or both.  Even if 
such a decision is likely to be discussed after a working group is 
created, we would like to encourage people who have a strong opinion 
which they think would impact a potential charter, to express it now.

Any other comments -- both substantial and editorial -- are of course 
welcome too.

-- 
Ciao,
Enrico
_______________________________________________
p2pi mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/p2pi

---

From: Stanislav Shalunov <[email-masked]>
Date: Mon, 30 Jun 2008 09:51:13 -0700

Enrico,

The problem statement generally looks good.

Some comments:

1. The popular metrics used by P2P applications are based on obtained  
goodput, not RTT.  This doesn't ignore bitrate and reliability -- if  
it did, P2P would work much worse than it does today.  It ignores cost  
and desires of the ISP, which is the problem ALTO needs to solve.

2. Cache location is clearly the low-hanging fruit that requires no  
research.  It's a matter of engineering, and any decent choice of  
mechanism will work.  We just need to agree on the mechanism.  I'd  
like to see this stressed and moved up.

3. Would it not help to have an actual formulation of the problem  
somewhere?  Like a sentence or a paragraph?  I've trouble finding this  
spot.  All the text says the right things, but it'd help to start with  
something like

	ALTO will solve two problems: (1) finding application caches and (2)  
conveying some of the information about the network already available  
to the routing layer up to application layer so that applications can  
choose better and lower-cost paths for their data.

    Is this the problem that your document describes?  If so, it  
should say it.  If not, it should say what the problem is.

4. Multiple solutions have indeed been proposed, and it's too early to  
talk about them, but given how different the approaches are, it makes  
sense to explore agreement on the general principles -- do we expect  
that it is possible to solve the problem of conveying information  
about routing layer in a way that leaves ISPs happy and is practical?   
How complicated can a solution be before it becomes flaky and  
fragile?  What is the smallest, most general-purpose standard that we  
can come up with that conveys this information.

Good job with getting it out,

-- Stas

On Jun 30, 2008, at 9:27 AM, Enrico Marocco wrote:

> <smime.p7s><ATT00001.c>

-- 
Stanislav Shalunov
http://shlang.com

---

From: John Leslie <[email-masked]>
Date: Mon, 30 Jun 2008 13:42:14 -0400

> http://www.ietf.org/internet-drafts/draft-marocco-alto-problem-statement-01.txt

   Looks pretty good! :^)

> of applications (including file-sharing, VoIP, real-time streaming.)

   Agreed.

> the protocols specified in ALTO are going to provide,

   My strongest desire is that it be easily extensible.

> whether it should be static information (e.g. from AS1, AS2 is always
> preferred to AS3,) 

   I believe an ISP should be able to choose static vs. dynamic.

> congested, peers in AS1 should prefer peers in AS3) or both.

   Obviously, benefits _could_ accrue from dynamic information.

> Even if such a decision is likely to be discussed after a working group
> is created, we would like to encourage people who have a strong opinion 

   I would like the charter to allow designing a protocol which _could_
provide dynamic information; but I don't think we should _require_ any
oracle operator to provide it.

> Any other comments -- both substantial and editorial -- are of course 

   One thing which caught my eye was the third paragraph of the Introduction
where it says:
" 
" ... file sharing applications... tend to ignore bandwidth and reliability
" of underlying links..."

   I don't think that's quite right, but the issue is correctly raised.
Certainly in the case of wireless links there will be non-congestion
packet loss; and there are other issues which _might_ be thought of as
"reliability" issues.

   I guess I wonder whether there's a better way to raise this concern.
(I don't mean to require reporting any of these: this might better be
left for an extension.)

--
John Leslie <[email-masked]>
_______________________________________________
p2pi mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/p2pi

---

From: Enrico Marocco <[email-masked]>
Date: Mon, 30 Jun 2008 20:04:53 +0200

> The problem statement generally looks good.

Thank you very much for the comments and for a quick response.

> and desires of the ISP, which is the problem ALTO needs to solve.

Well, I guess you are right.  Here we probably messed up with 
coordinate-based systems described in literature, which are sometimes
used before actually starting transmissions.  We will fix this in the 
next version.

> like to see this stressed and moved up.

Are you suggesting to mention earlier in the draft (in the 
Introduction?) the benefit that would come from an ALTO solution when 
used in conjunction with (or even just aware of) application caches, or 
are you just asking to move S3.5 to S3.1 or S3.2?  Both of the two make 
sense to me, but the latter seems to assume some kind of rational order 
in section 3, which so far has not been the case.

> should say it.  If not, it should say what the problem is.

Finding application caches is something very application-specific, while 
we try to keep the problem statement a bit more general.  So, instead of 
saying something like "(a) finding application caches, and (b) finding 
best VoIP relays, and (c) finding closest DHT nodes", we prefer to say 
"finding the best peer, for some reasonable value of best".  Then, if an 
ALTO service is aware of BitTorrent caches, it will do a good job in 
redirecting querying peers to them.

> about routing layer in a way that leaves ISPs happy and is practical?

In this version we tried to stress that an ALTO solution should be 
deployable also by third-parties other than ISPs.  However, it seems 
quite a shared feeling that deployment of ALTO would bring ISPs and P2P 
systems to a win-win situation, so I'd tend to say yes, it should leave 
ISPs happy.  Do you have any issue in mind why this may not be the case?

> can come up with that conveys this information.

Those are probably questions a working group should try to answer, but 
we still don't have one.

---

From: Enrico Marocco <[email-masked]>
Date: Mon, 30 Jun 2008 20:18:17 +0200

>    I don't think that's quite right, but the issue is correctly raised.

Right, we'll fix it in the next version.

> (I don't mean to require reporting any of these: this might better be

Yes, extensibility will probably be the key.

---

From: Stanislav Shalunov <[email-masked]>
Date: Mon, 30 Jun 2008 13:02:22 -0700

On Jun 30, 2008, at 11:04 AM, Enrico Marocco wrote:
> Introduction?) the benefit that would come from an ALTO solution  
> when used in conjunction with (or even just aware of) application  
> caches, or are you just asking to move S3.5 to S3.1 or S3.2?  Both  
> of the two make sense to me, but the latter seems to assume some  
> kind of rational order in section 3, which so far has not been the  
> case.

I'd say both.  Right now, it's treated as an afterthought.  Given how  
easy it is to engineer and the immense payoffs that it promises to  
both the ISP and the P2P app user, it should be given more prominent  
display.  This is the easy stuff that we probably very easily all  
agree on.

> Finding application caches is something very application-specific,  
> while we try to keep the problem statement a bit more general.  So,  
> instead of saying something like "(a) finding application caches,  
> and (b) finding best VoIP relays, and (c) finding closest DHT  
> nodes", we prefer to say "finding the best peer, for some reasonable  
> value of best".  Then, if an ALTO service is aware of BitTorrent  
> caches, it will do a good job in redirecting querying peers to them.

I agree with the need to keep the mechanisms general-purpose.

When I say "application caches" I mean more generally than  
BitTorrent.  I'm not aware of a general mechanism other than hard-to- 
modify DSCP for discovery of local application-specific resources.  We  
could do that.

So it might be even more general than "best peer".

Whatever the goal is and however it's phrased, it would help focus to  
add it in the most concise form in the very beginning of the document.

> deployable also by third-parties other than ISPs.

It's good if it can be made deployable by entities other than ISPs.   
Who might be such third parties?

>  However, it seems quite a shared feeling that deployment of ALTO  
> would bring ISPs and P2P systems to a win-win situation, so I'd tend  
> to say yes, it should leave ISPs happy.  Do you have any issue in  
> mind why this may not be the case?

I stress ISP happiness because to me that's one of the key drivers for  
ALTO.  P2P systems already work and ALTO information might improve  
their performance somewhat, but not radically.  The ISPs' costs, on  
the other hand, might be substantially reduced.

(This is a bit different from caching, which would also radically  
improve P2P app performance potentially.)

> Those are probably questions a working group should try to answer,  
> but we still don't have one.

OK, agreed.

-- 
Stanislav Shalunov
http://shlang.com

---

From: Laird Popkin <[email-masked]>
Date: Mon, 30 Jun 2008 16:23:59 -0400 (EDT)

I view cache discovery as a particularly valuable case of ALTO's general goal, which (IMO) is to allow network providers to provide guidance so that applications that can choose from multiple potential data sources to make better informed selections.

I suggest that both ISPs and the P2P platforms have a strong incentive to optimize p2p traffic. The ISPs save network resources (and eventually money), which is a strong direct driver. It's true that p2p performance improvements may not be as dramatic an incentive for a pure p2p network, the hybrid P2P networks (e.g. Pando, BitTorrent DNA, Kontiki) do save money when the p2p performance is improved, because it allows them to pull less data from the CDN servers. But more importantly (IMO) I think that it's fairly safe to say that the p2p networks don't want ISPs to throttle or block their applications, and if working together to optimize traffic reduced the incentive for ISPs to shape traffic, etc., that's good for the entire p2p industry.

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

----- Original Message -----
From: "Stanislav Shalunov" <[email-masked]>
To: "Enrico Marocco" <[email-masked]>
Cc: [email-masked]
Sent: Monday, June 30, 2008 4:02:22 PM (GMT-0500) America/New_York
Subject: Re: [p2pi] New version of the problem statement

OK, agreed.

-- 
Stanislav Shalunov
http://shlang.com

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Mon, 30 Jun 2008 15:46:12 -0500

Stanislav Shalunov wrote:
> easy it is to engineer and the immense payoffs that it promises to both 
> the ISP and the P2P app user, it should be given more prominent 
> display.  This is the easy stuff that we probably very easily all agree on.

Stanislav: OK.

> add it in the most concise form in the very beginning of the document.

Agreed; hence getting this document out for early review for
maybe one more iteration before the submission deadline.

> It's good if it can be made deployable by entities other than ISPs.  Who 
> might be such third parties?

One model is espoused by Ono, from Northwestern University.  Ono, as
I am sure you may be aware of, is an Azureus plug-in that uses
Akamai's CDN to derive hints on how clients are redirected to
replica servers and thus bias a peer selection algorithm (their
paper is in Sigcomm 2008 conference and can be accessed from
http://www.aqualab.cs.northwestern.edu/publications/DChoffnes08Sigcomm.pdf).

We posit that a neutral third party may be someone that uses
techniques like this that are not ISP-dependent.

Thanks,

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA)
Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org}
WWW:   http://www.alcatel-lucent.com/bell-labs
_______________________________________________
p2pi mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/p2pi

---

From: Laird Popkin <[email-masked]>
Date: Mon, 30 Jun 2008 17:04:08 -0400 (EDT)

Other possible third party providers would be a trusted third party such as ARIN, or a service provider that's used by ISP's to outsource the service (e.g. the way some smaller ISPs outsource email, etc.).

----- Original Message -----
From: "Vijay K. Gurbani" <[email-masked]>
To: "Stanislav Shalunov" <[email-masked]>
Cc: [email-masked]
Sent: Monday, June 30, 2008 4:46:12 PM (GMT-0500) America/New_York
Subject: Re: [p2pi] New version of the problem statement

Stanislav: OK.

Thanks,

- vijay

---

From: Reinaldo Penno <[email-masked]>
Date: Mon, 30 Jun 2008 14:16:46 -0700

Hi,

although P2P peer selection geared towards keeping the traffic local (as in
the same AS) is a major driver there are other cases as well that we should
keep in mind so the solution is general. And sometimes the interest of the
client is not necessarily the same as the ISP.

* There are ISPs that want traffic within its AS because of cross-ISP
transit costs. Here traffic locality and caching would be good solutions.

* There are ISPs where transit cost is not the major problem. The most
pressing problem is upload/download between subscribers within its AS. Peer
locality might not to help much here (actually could be make the problem
worse). Caching or downloading from peers outside your own AS might be a
better fit. 

* Then there are ISPs that actually want peers outside its AS to download
from them. This allows them to argue for settlement free peering since now
then send as much traffic as they receive from their upstream provider.

* The other dimension is that with the exception of caches, the closest peer
from a pure coordinate perspective is not necessarily the best peer. At
least not from the client perspective due to bw limitations.

But I'm guessing the results from P2P CDNs like DNA vs. open would be quite
different in this aspect.

* Then of course as it was mentioned the needs of streaming P2P vs. file
transfer vs. replication  are quite different.

Thanks,

---

From: Stanislav Shalunov <[email-masked]>
Date: Mon, 30 Jun 2008 15:20:12 -0700

> techniques like this that are not ISP-dependent.

Yeah, makes sense.  Also Laird's RIR example, and perhaps roting  
registries.  I was thinking about it as primarily an ISP-provided  
service to reduce costs, but indeed this could be used more broadly  
and should be designed to accommodate such uses.

Then the ISP's instance of the ALTO information service could be found  
using the same technique as the ISP's instance of the ALTO cache.

-- 
Stanislav Shalunov
http://shlang.com

---

From: Stanislav Shalunov <[email-masked]>
Date: Mon, 30 Jun 2008 15:33:15 -0700

> then send as much traffic as they receive from their upstream  

Agreed on the diverse needs.

And note how caching is an answer to the first two and can easily be  
an answer for the third with a very simple config switch.

-- 
Stanislav Shalunov
http://shlang.com

---

From: Enrico Marocco <[email-masked]>
Date: Tue, 1 Jul 2008 00:49:14 +0200

> Who might be such third parties?

I'd say communities in general.  Nodes running distributed algorithms 
like Vivaldi or Meridian may easily implement the interface defined in 
ALTO, and such nodes are likely to be run on a volunteer basis just as 
mirrors for open-source software distributions (or eDonkey or Jabber 
servers) today are.

Having third-parties in the game from the beginning would basically 
avoid ALTO to suffer from the same diffidence P2P users have in regard 
to ISPs.  Then, at the end of the day, if the service provided by ISPs 
will result better than the others, I see no problem in it being adopted.

---

From: Stanislav Shalunov <[email-masked]>
Date: Mon, 30 Jun 2008 16:35:08 -0700

On Jun 30, 2008, at 3:49 PM, Enrico Marocco wrote:

> I'd say communities in general.  Nodes running distributed  
> algorithms like Vivaldi or Meridian may easily implement the  
> interface defined in ALTO, and such nodes are likely to be run on a  
> volunteer basis just as mirrors for open-source software  
> distributions (or eDonkey or Jabber servers) today are.
>
> avoid ALTO to suffer from the same diffidence P2P users have in  
> regard to ISPs.  Then, at the end of the day, if the service  
> provided by ISPs will result better than the others, I see no  
> problem in it being adopted.

Makes sense.

-- 
Stanislav Shalunov
http://shlang.com

---

From: Arvind Krishnamurthy <[email-masked]>
Date: Mon, 30 Jun 2008 16:49:20 -0700

> will result better than the others, I see no problem in it being adopted.

Hi Enrico,

Just wanted to clarify as to whether the primary focus
of ALTO is on improving application performance (as opposed
to lowering ISP costs/loads)?

Also wanted to point out that the different proposals
floating around are trying to solve slightly different
problems, and consequently provide different sets of
incentives to the various parties involved (such as
the iTracker/apptracker/clients).

For instance, in p4p, the focus is more on alleviating
the adversarial relationship between ISPs and P2P.  The
question then is: can P2P applications reduce ISP costs/loads
*without* sacrificing on application-level performance - as
opposed to proposals that are more focussed on just improving
application-level performance *irrespective* of what happens
to ISPs (and I would put network coordinates/Ono in that
category).  As an example, if applications establish peering
connections based on just end-to-end latency considerations,
the peerings might be sub-optimal from an ISP perspective, as
latency and AS-path length are only weakly correlated (and we
have a bunch of data to demonstrate that).

Hence the question as to what is the primary objective,
especially when the incentives are not perfectly aligned.
Thanks,

          Arvind

---

From: Stanislav Shalunov <[email-masked]>
Date: Mon, 30 Jun 2008 20:00:52 -0700

On Jun 30, 2008, at 1:02 PM, Stanislav Shalunov wrote:

> DSCP for discovery of local application-specific resources

DHCP, of course.  Drain bramage on my part.

-- 
Stanislav Shalunov
http://shlang.com

---

From: Enrico Marocco <[email-masked]>
Date: Tue, 1 Jul 2008 10:33:10 +0200

> to lowering ISP costs/loads)?

Both. For the most part of the industry (not all, of course), the
primary focus is probably on lowering costs, but it seems quite
straightforward that if a deployed solution is not beneficial to
applications, it will just not get adopted.

> have a bunch of data to demonstrate that).

The goal is to design an interface which could be exposed by both types
of systems. Some proposals seem to already have such a propriety (e.g.
the "sorting oracle"), others will probably need some tweaking.

I believe that, since it is unlikely that the use of ALTO services may
be imposed, eventually competition will depend on the benefit they bring
to applications. However, I am quite optimistic about ISP based
solutions, as they show impressive improvements in applications
performance: for example, the SIGCOMM P4P paper (you are a co-author of,
btw) reports a 23% improvement in download completion time, which seems
a very important achievement, especially if the main goal of the work
was just to lower ISP costs.