Subject: Re: [p2pi] Information in an ALTO protocol

From: Laird Popkin <[email-masked]>
Date: Thu, 4 Sep 2008 18:44:25 -0400 (EDT)

P2P live streaming is smaller data volume right now than p2p downloads, but I wouldn't write it off entirely - Abacast, PPLive, etc., do have large number of users, and don't appear to be going away any time soon.

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

----- Original Message -----
From: "Stanislav Shalunov" <[email-masked]>
To: "Sebastian Kiesel" <[email-masked]>
Cc: [email-masked]
Sent: Sunday, August 17, 2008 9:31:32 PM (GMT-0800) America/Los_Angeles
Subject: Re: [p2pi] Information in an ALTO protocol

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:[email-masked]
> Network Research Division   tel:+49-6221-4342-232   fax: 
> +49-6221-4342-155
> 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
[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: Fri, 12 Sep 2008 12:55:40 -0700

If the ALTO service provides ISP preferences, the whole issue of lying goes away.

If you say it's what you want, and it's really not, you'll be the only one unhappy.

Right incentives are the key.

-- Stas

-----Original Message-----
From: "stefano previdi" <[email-masked]>
To: "Woundy, Richard" <[email-masked]>; "Laird Popkin" <[email-masked]>; "Salman Abdul Baset" <[email-masked]>
Cc: [email-masked]
Sent: 9/12/08 9:14 AM
Subject: Re: [p2pi] Information in an ALTO protocol

Rich,

> From: "Woundy, Richard" <[email-masked]>
> 
>> well, I don't think there's anything there that needs do be
> standardized
> 
> Sorry, I disagree. The protocol spec needs to make the semantics clear
> for a "user bandwidth" value.

sorry, I misunderstood. I wasn't referring to the "user bandwidth" here.

The point I was trying to make is that I'm not sure we need to standardize
the way rankings are computed since each provider may have own policies that
would make results to vary.

The choice of an ALTO client to follow ALTO "suggestion" (or not) will be
solely based on the effective performance.

> The spec could state that the value could
> be randomized / statistically balanced, so that such value manipulation
> could be anticipated by the ALTO client. Transparency is the key here.

if we have explicit BW values in the ALTO protocol, then I agree with you,
there's no point in hiding/cheating

> To be honest, I have my doubts whether randomization of the value will
> really help. 

"randomization" clearly not.

Sorry for the misunderstanding.

s.

> The more randomization is used, the less effective this
> information will help the ALTO client. The less randomization is used,
> the more concerns I have about user privacy.
> 
> I will step back from this debate and listen.
> 
> -- Rich
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> stefano previdi
> Sent: Friday, September 12, 2008 9:22 AM
> To: Woundy, Richard; Laird Popkin; Salman Abdul Baset
> Cc: [email-masked]
>> From: "Woundy, Richard" <[email-masked]>
>> 
>>> Nothing prevents an ISP to configure his ALTO server in order answer
>> to
>> identical requests using some form of statistical-balancing
> preference.
>> 
>> I would worry that the 'statistical balancing preference' could
>> alternatively viewed as 'ISP ALTO server is lying' or 'ISP ALTO server
>> prefers some applications over others'. I don't want to go there.
> 
> well, I don't think there's anything there that needs do be standardized
> (or
> worked out in the context).
> 
> Regarding the Alto-lies, it looks to me ALTO is a form of traffic
> engineering based on peer selection guidance. I don't see why a
> dynamic/variable algorithm (taking into consideration parameters such as
> time of day, current backbone load, ...) returning different results for
> the
> same query, would be considered as a "bad thing".
> 
> But it also looks to me it's going to be something implementation
> specific.
> Being adopted/used or no will be the ISP choice.
> 
> s.
> 
>> 
>> -- Rich
>> 
>> -----Original Message-----
>> From: stefano previdi [mailto:[email-masked]]
>> Sent: Friday, September 12, 2008 5:06 AM
>> To: Laird Popkin; Salman Abdul Baset
>> Cc: [email-masked]; Woundy, Richard
>>> From: Laird Popkin <la

---

From: Stanislav Shalunov <[email-masked]>
Date: Mon, 15 Sep 2008 13:53:03 -0700

That's your own uplink capacity only.

I suspect even that would be hard to provide on DSL, where there is dynamic negotiation.

I'd expect measuring it once would be, while  deeply flawed, still give better results than asking...

Even better, of course, is to use real transfers as ongoing measurements, right?

-----Original Message-----
From: "Laird Popkin" <[email-masked]>
To: "Ye WANG" <[email-masked]>
Cc: [email-masked]
Sent: 9/15/08 7:22 AM
Subject: Re: [p2pi] Information in an ALTO protocol

If a p2p application knows roughly what bandwidth the user is provisioned with, it can set reasonable defaults. 

For example, Azureus' configuration wizard asks users what kind of uplink speed they have (e.g. dial, 128K, 256K, ..., 1M) and uses different application level values (e.g. max upload speed, number of active transfers, number of active peer connections) appropriate for that kind of network connection. If they could automatically configure themselves rather than asking the user a rather intimidating (to a non-technical consumer) question, that would be better for the users and the network. 

----- Original Message ----- 
From: "Ye WANG" <[email-masked]> 
To: [email-masked] 
Sent: Monday, September 15, 2008 10:09:57 AM (GMT-0500) America/New_York 
Subject: Re: [p2pi] Information in an ALTO protocol 

On Fri, Sep 12, 2008 at 3:40 PM, Stanislav Shalunov < [email-masked] > wrote: 

Let us put the privacy considertaions aside for a minute. 

I'm actually not even sure how one would use uplink sizes if they were available, particularly only for some peers. 

The underlying assumption of many messages seems to be that P2P clients will prefer to connect to higher-uplink peers.  While this would help you if you're the only one doing it, it would hurt everyone if done universally.  [Ye (Yale)] 
We have seen many studies on video streaming applications that prefer higher-uplink-bandwidth peers.  I certainly agree with you that the system may somehow get 'blocked' if all clients naively select the highest-uplink peer to be parents.  How to efficiently use all upload capacity, especially those higher-uplink peers, is still an interesting problem. 

The only use I can think of right now that doesn't have obvious adverse consequences is to prefer peers with uplinks of about the same size as yours.  While this shouldn't reduce average download rate, I'm also not sure what purpose it would serve.  It would make the response to increases in uplink capacity more linear, but of course it's sublinear by design. 

[Ye (Yale)] 

Analysis based on a fluid model of P2P file sharing system indicates that bandwidth matching can help improve average file download rate.  The bandwidth matching can be roughly described like: a peer with download capacity R downloads from the peer whose upload capacity R (=downloader download rate).  Thus, for file sharing applications, like Pando, BitTorrent, etc., the uplink/downlink bandwidth information can be useful in system optimization.  
In the recent P4P field test, we estimated these numbers before using them to compute peering selection weights.  Estimation based on measurement is dynamic and less accurate, while direct numbers from ALTO servers may be generally stati
_______________________________________________
p2pi mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/p2pi