Re: [p2pi] After-BoF charter

[Stanislav Shalunov <[e-mail]>]

This is quite obvious, but I thought it might be worth stating in the  
context of this discussion:

As an ISP, you can't put up a server that answers short questions with  
short answers or publish some information for the public or your  
customers and expect the amount of upload P2P capacity used by your  
customers to drop much below the amount of download P2P capacity.   
Every downloaded bit is someone's uploaded bit.  For the swarm, the  
upload/download ratio is always 1.  You can try to encourage your  
customers to be leeches, but that doesn't work too well, because then  
their download rates go down as they are chocked or snubbed by more  
and more people.

The only way to break the 1:1 ratio is by introducing caches.

While this consideration is important to keep in mind to be realistic  
about possible outcomes of ALTO, I agree with all the posters that  
that goal of ALTO should not be unconditional localization but a more  
general mechanism for expressing network routing preferences to the  
application.

-- Stas


On Aug 11, 2008, at 6:51 AM, Bruce Davie wrote:

> Good points Bob, most of which I agree with. A little clarification  
> below:
>
> On Aug 8, 2008, at 8:40 PM, Bob Briscoe wrote:
>
>> Enrico,
>>
>> Charter generally looks good.
>> Generally agree with Lars, Dave's & Laird's responses so far.
>> My additional 3 penny's worth:
>>
> [snip]
>
>>
>> 3/ What does optimal mean, and what does better mean?
>>
>> The charter has hidden assumptions about what optimal is, and what  
>> better is. From whose perspective? It needs to either say what  
>> these assumptions are, or say that the w-g will define what optimal  
>> means in a w-g document.
>
> I would suggest that there will be different views of optimal for  
> different providers, and the WG should work on capturing that fact  
> and developing solutions that can deal with it.
>
>>
>> As I have to keep saying, and as Richard Woundy from ComCast has  
>> agreed, excessive cross domain traffic is much less bad than  
>> excessive local traffic.
>
> I believe you have just stated what is optimal for two providers,  
> but I'm not convinced that the entire universe of providers agrees  
> with you. I think the WG needs to deal with the fact that some  
> providers will care about reducing backhaul traffic and others will  
> care about reducing inter-domain traffic.
>
> Rather than trying to get this all nailed down in the charter, I  
> think it would be good if the charter mentioned the problem of  
> defining optimality from a variety of perspectives as one of its  
> work items.
>
> I also note that the charter is ultimately intended only to specify  
> the interface between clients and "peer selection services"  - so we  
> need to make sure that the information carried across that interface  
> is sufficiently rich to allow for a range of different definitions  
> of optimality. We don't need to get everyone to buy into a single  
> definition of optimality.
>
> The rest of your email below finds me in complete agreement.
>
> Bruce
>
>>
>> I agree that the /current/ traffic arrangement resulting from p2p  
>> has excessive cross-domain traffic. But this is the not-seeing- 
>> beyond-the-first-step problem I tried to explain at the mic in the  
>> ALTO BoF.
>>
>> Once traffic is sitting in an optimum arrangement (possibly  
>> bootstrapped by ALTO then optimised by e2e congestion control), the  
>> best place to add the /next/ connection will likely be cross-domain  
>> not local. Because the optimium is a /balance/ of light congestion  
>> across both. This is why the goal MUST NOT be unconditional  
>> localisation. That could eventually drive the network /beyond/ the  
>> balance, persistently trying to drive up congestion in the access  
>> and backhaul. That will be much worse than excessive cross-domain  
>> traffic.
>>
>> You might say it would be nice to have that problem.
>>
>> But if this service only does localisation, it will only be safe / 
>> if/ it is used by a minority. If the popularity of an ALTO service  
>> goes beyond a certain point, it will start to kill the ISP's local  
>> network. Of course, then less people will use it and an equilibrium  
>> might be reached. But that's what I said. Optimisation is a  
>> process, not just a first step. ALTO has to be able to move traffic  
>> out, not just in.
>>
>> \
>> \
>>  \      /\
>>   \    /  \ ^----- <<<---goal
>>    \  /    V
>>     \/
>>
>> NOT
>> \
>> \
>>  \
>>   \          <<<---goal
>>    \
>>     \
>>      \
>>       \
>>        \
>>         \
>>
>>
>> Bob
>>
>> At 20:06 07/08/2008, Enrico Marocco wrote:
>>> We have tried to collect all comments received during the meeting,  
>>> in
>>> mailing list and hallway discussions. The new version of the  
>>> charter,
>>> available as always at http://alto.tilab.com/docs/charter.txt,  
>>> should
>>> reflect at least some of them. Please take a look and comment.  
>>> Feel free
>>> to say if you don't like it -- entirely or partially -- and why;  
>>> or if
>>> you like it. And why.
>>>
>>> Major changes include:
>>> + terminology: dropped terms like "the oracle" and "best peer";
>>> + scope: removed cache/TURN/whatever service discovery;
>>> + path selection: stressed the importance of routing preferences and
>>>  peering policies;
>>> + forbidden third-party queries;
>>> + mentioned IRTF for analysis on more sophisticated metrics.
>>>
>>> The current version of the charter is also more explicit about what
>>> pieces of information will be provided by an ALTO service; I'll  
>>> start a
>>> separate thread specifically for this discussion.
>>>
>>> --
>>> Ciao,
>>> Enrico
>>>
>>>
>>> _______________________________________________
>>> p2pi mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/p2pi
>>
>> ____________________________________________________________________________
>> Bob Briscoe, <[e-mail]>      Networks Research Centre, BT  
>> Research
>> B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK.    +44  
>> 1473 645196
>> _______________________________________________
>> p2pi mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/p2pi
>
> _______________________________________________
> p2pi mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/p2pi

--
Stanislav Shalunov



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