Re: [p2pi] Information in an ALTO protocol

[Stanislav Shalunov <[e-mail]>]

Live P2P video streaming is an interesting research problem, so far  
not solved.  The business case has also not been proven, with  
different companies targeting very different uses, from UGC to TV  
distribution to screencasting.

Improving the efficiency of an application that does not yet exist  
should probably not be in scope for ALTO.

As a side note, I don't think the metric of lag is particularly  
interesting to optimize, and, therefore, I'll be happy to have our  
competitors use it.  The two right metrics are in different units.   
But let's not go too far down the path of discussing an interesting  
research topic.

-- Stas


On Aug 14, 2008, at 7:59 AM, Sebastian Kiesel wrote:

> Hi,
>
> "total transfer rate divided by total upload capacity" is a good  
> measure
> of swarm efficiency if the application is file sharing.
>
> p2p live video streaming (an application which might gain much  
> relevance
> till the time when a potential ALTO workgroup would deliver their  
> first
> specifications) has differenent metrics: the system can only be stable
> if the video stream's bitrate is lower than the average upload  
> capacity,
> i.e., not all uplinks will be saturated by this application.
>
> The interesting metric is the lag, i.e., the delay of the video stream
> between injection into the swarm and playout (measured individually  
> per
> node or as average in the swarm). It can be reduced if nodes with  
> higher
> upload capacity or shorter transport delay from the source are placed
> closer to the source in the logical topology. The incentive for a user
> to offer more upload capacity to the swarm is to get a smaller
> individual lag.
>
> While p2p algorithms can converge to a "good" state, ALTO guidance  
> would
> be very beneficial if it could speed up that process. This is very
> relevant here as many users switch TV channels (streams) frequently.
>
> Any thoughts?
>
> Thanks,
> Sebastian
>
>
> On Mon, Aug 11, 2008 at 06:16:44PM -0700, Stanislav Shalunov wrote:
>> This might be workable and interesting, but here are a few concerns:
>>
>> 1. For this to be useful, an ISP would need to provide an  
>> unobfuscated
>> third-party service that will tell the world what service plan I  
>> bought.
>> As a user, I'd have a bit of discomfort with it, but the ISP would  
>> probably
>> be a lot more concerned about telling its competitors the fraction  
>> of its
>> customers whom they upsold on a premium plan.  I suspect this might  
>> be a
>> real show-stopper.
>>
>> 2. Nominal provisioned bandwidth on DSL is only an upper bound for  
>> the
>> actual negotiated bandwidth.  The negotiation takes a few seconds  
>> after the
>> modem starts and routinely results in lower-than-nominal rates for  
>> longer
>> distances to CO.
>>
>> 3. While it's obvious that an individual peer will, in the current  
>> world,
>> do better trading with fat-uplink partners, I'm skeptical of  
>> possibility of
>> substantial increases in swarm throughput, which determines the  
>> average
>> outcome.  Consider the measure of swarm efficiency: total transfer  
>> rate
>> divided by total upload capacity.  I posit that swarm efficiency is  
>> usually
>> quite high, and the only real slack is on super-fast peers in colos  
>> and
>> such.  Home connection uplinks are so narrow that it does not take  
>> much to
>> saturate them.
>>
>> -- Stas
>
>
>
>
>
> -- 
> Sebastian Kiesel            mailto:[e-mail]
> Network Research Division   tel:[phone]   fax: 
> [phone]
> NEC Laboratories Europe     Kurfuerstenanlage 36, 69115 Heidelberg,  
> Germany
> --
> NEC Europe Limited          Registered in England 2832014
> Registered Office           NEC House, 1 Victoria Road, London W3 6BL

--
Stanislav Shalunov



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