Subject: Re: [p2pi] New version of the problem statement

From: Song Haibin <[email-masked]>
Date: Wed, 09 Jul 2008 14:55:45 +0800

Hi Reinaldo,

>From: [email-masked] [mailto:[email-masked]] On Behalf Of
>Reinaldo Penno
>Sent: Tuesday, July 01, 2008 5:17 AM
>
>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.

I agree. The problem is that there is much traffic in the ISP back-bone or
inter-ISP link. In my mind, there are ways to optimize this kind of traffic,
one is through the peer selection (provided by the implicit ISP topology),
and the second one is caching, the third one is through the traffic
aggregation and distribution in the ISP's network (something like multicast
in the ISP's network, especially for hot files).

>* 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.

Yes. I think here is another problem for the P2P application. The
subscriber's upload/download bandwidths are asymmetric. Then the total
upload/download bandwidths are also unbalanced. Peer selection from other
ISP network can lessen this problem, if that ISP network has plenty of
upload capability and resources. Caching, traffic aggregation and
distribution in the ISP's network are also choices to solve this problem.

>* 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.

This is the ISP's policy. ISPs of course want their policies about traffic
to be carried out by all applications.

>* 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.

Yes, I agree.

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

Could you please give me some materials on that for information?

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

So here ISP just provides the information that P2P or other applications can
use to optimize their traffic directly or indirectly, but not itself makes
decisions for these applications.

Best Regards
Song Haibin
Skype: alexsonghw

>Thanks,
>
>
>
>
>On 6/30/08 1:46 PM, "Vijay K. Gurbani" <[email-masked]> wrote:
>
>> Stanislav Shalunov wrote:
>>> 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.
>>
>> Stanislav: OK.
>>
>>> 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.
>>
>> Agreed; hence getting this document out for early review for
>> maybe one more iteration before the submission deadline.
>>
>>>> In this version we tried to stress that an ALTO solution should be
>>>> 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?
>>
>> 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
>
>_______________________________________________
>p2pi mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/p2pi

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