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

From: Laird Popkin <[email-masked]>
Date: Mon, 15 Sep 2008 10:22:01 -0400 (EDT)

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. 

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

----- 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 static and more accurate. 

Can someone fill me in on how a P2P app would use provisioned uplink numbers? 

Thanks, -- Stas 

-----Original Message----- 
From: "Laird Popkin" < [email-masked] > 

To: "Salman Abdul Baset" < [email-masked] > 
Cc: [email-masked] ; "Richard Woundy" < [email-masked] > 
Sent: 9/11/08 1:28 PM 
Subject: Re: [p2pi] Information in an ALTO protocol 

(1) If an ISP configures their ALTO server to tell applications that the users' uplink is less than it really is, I think that could have two effects. For users inside the ISP, it would tend to suppress internal traffic and cause peers to download from external peers, which is probably bad for the ISP. And it might tend to cause peers from outside the ISP to shift traffic elsewhere to some degree, which would reduce uplink utilization, which would be an incentive to 'aim low'. How these two factors would balance out would depend on the ISP's infrastructure. 

(2) I don't believe that the p2p network would have to decide that the ISP's ALTO server was 'lying'. P2P networks all currently measure observed throughput between peers and use that to make decisions. If they add ALTO provisioning information, I would expect that they would treat observed throughput as being more true than the ALTO guidance. So without having to make a decision about 'ALTO lying' the p2p network would tend to take advantage of good ALTO guidance (because ALTO guidance and p2p performance optimization reinforce each other) and would tend to cancel out bad ALTO guidance (because the p2p performance optimization would end up overruling the ALTO guidance). 

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

----- Original Message ----- 
From: "Salman Abdul Baset" < [email-masked] > 
To: "Laird Popkin" < [email-masked] > 
Cc: "Richard Woundy" < [email-masked] >, [email-masked] 
Sent: Thursday, September 11, 2008 3:46:10 PM (GMT-0500) America/New_York 
Subject: Re: [p2pi] Information in an ALTO protocol 

This raises at least two issues: 

> Playing devil's advocate, while ALTO doesn't provide a mechanism for ISP A 
> to tell non-customers anything, but it is possible for the p2p network 
> as a whole to make decisions based on information provided by ALTO. For 
> example, if ISP A says that its users have bad uplink, and ISP B says 
> that its customers have great uplink, then the rest of the internet will 
> tend to download more from ISP B than A. 

(1) Do ISPs have an incentive to lie to their customers that their uplink 
is bad? 

This will be counter-balanced 
> in that if, in practice, ISP A has fine uplink, the p2p network will 
> figure that out and use those peers anyway, ignoring the misleading ALTO 
> guidance, because observed behavior has (IMO) more 'weight' than ALTO 
> guidance. 

(2) Do P2P applications must determine if an ISP ALTO server is lying? 

Note, that misconfiguration can also be a cause of ALTO server providing 
misleading information. 

-s 

> 
> ----- Original Message ----- 
> From: "Richard Woundy" < [email-masked] > 
> To: "Reinaldo Penno" < [email-masked] >, "Laird Popkin" < [email-masked] > 
> Cc: [email-masked] 
> Sent: Thursday, September 11, 2008 2:52:06 PM (GMT-0500) America/New_York 
> Subject: RE: [p2pi] Information in an ALTO protocol 
> 
>> I was wondering if he was assuming some kind inter-ALTO communication. 
> 
> I guess I was. And perha 

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

_______________________________________________ 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: Nicholas Weaver <[email-masked]>
Date: Mon, 15 Sep 2008 07:38:41 -0700

On Sep 15, 2008, at 7:22 AM, Laird Popkin wrote:

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

If you control a well-connected server, you can probably do this  
pretty easily (at least into the right ballpark) with just a few sets  
of back-to-back UDP packets to estimate uncongested-link bandwidth: at  
least to get

If you do this on startup and IP address change, use 8, 1000B packets  
(4 pairs), and have 10M clients a day doing a test, this would  
require, roughly, 80 GB of upload bandwidth a day.

Given the cost of EC2 as a host for such a test server, this would  
cost a company <$20/day in bandwidth to support 10M clients a day.

---

From: Laird Popkin <[email-masked]>
Date: Mon, 15 Sep 2008 10:54:58 -0400 (EDT)

The cost of bandwidth testing isn't terrible, but the accuracy of measurements taken on 1K transfers is very low - you're really measuring latency and buffering, not sustained data transfer rate. Of course, there might be some relationship between them, but (at least in our measurements) it took much larger data transfers to get even remotely stable results. In addition, measuring actual throughput at a point in time can be affected by other traffic on the PC (e.g. PC's do many things when they're starting up), other nearby PC's (e.g. someone else in your neighborhood is busy right now), transient interference on the internet, etc. So while it's not unreasonable to do such testing, and we certainly do so, an ISP provided provisioned capacity would be much more accurate (when it's available).

---

From: Nicholas Weaver <[email-masked]>
Date: Mon, 15 Sep 2008 08:06:40 -0700

On Sep 15, 2008, at 7:54 AM, Laird Popkin wrote:

> The cost of bandwidth testing isn't terrible, but the accuracy of  
> measurements taken on 1K transfers is very low - you're really  
> measuring latency and buffering, not sustained data transfer rate.  
> Of course, there might be some relationship between them, but (at  
> least in our measurements) it took much larger data transfers to get  
> even remotely stable results. In addition, measuring actual  
> throughput at a point in time can be affected by other traffic on  
> the PC (e.g. PC's do many things when they're starting up), other  
> nearby PC's (e.g. someone else in your neighborhood is busy right  
> now), transient interference on the internet, etc. So while it's not  
> unreasonable to do such testing, and we certainly do so, an ISP  
> provided provisioned capacity would be much more accurate (when it's  
> available).

The point of the 1K back-to-back packets is NOT that you are testing  
the transfer time for the 1K packets, but that interarrival time of  
the packets can be used as an uncongested-link bandwidth estimate, as  
long as the queue at the point of congestion uses FIFO delivery of  
packets.

Since the question you are asking the user is "whats the UNCONGESTED"  
behavior as a starting point (to set an initial threshold/ceiling  
somewhere below this point), the behavior of back-to-back packets  
should get you in the right ballpark without having to ask the user.

---

From: Laird Popkin <[email-masked]>
Date: Mon, 15 Sep 2008 12:52:04 -0400

The main problem is not only that the measurement accuracy is low, but  
that fairly often even an accurate measurement of the instantaneous  
measurement is not representative of typical throughput that the app  
should be configured for.

This is a complex area, so there's lots of interesting research. For  
example:

- http://www.rfc-editor.org/rfc/rfc5136.txt defines terminology
- http://mice.cs.columbia.edu/getTechreport.php?techreportID=500&format=pdf& 
  proposes a method (and has lots of links to other tools and research).

So while there are plenty of clever methods for trying to figure out  
end user link capacity, they're all complex methods of estimation. If  
I can get the ISP to tell me, that's simpler and more reliable. Of  
course, I can't count on the ISP to always do so, so the various  
methods of estimating link capacity remain useful. :-)

- LP

On Sep 15, 2008, at 11:06 AM, Nicholas Weaver wrote:

>> least in our measurements) it took much larger data transfers to  
>> get even remotely stable results. In addition, measuring actual  
>> now), transient interference on the internet, etc. So while it's  
>> not unreasonable to do such testing, and we certainly do so, an ISP  
>> provided provisioned capacity would be much more accurate (when  
>> it's available).
>
> the packets can be used as an uncongested-link bandwidth estimate,  
> as long as the queue at the point of congestion uses FIFO delivery  
> of packets.
>
> Since the question you are asking the user is "whats the  
> UNCONGESTED" behavior as a starting point (to set an initial  
> threshold/ceiling somewhere below this point), the behavior of back- 
> to-back packets should get you in the right ballpark without having  
> to ask the user.
>
>

---

From: Philip Levis <[email-masked]>
Date: Mon, 15 Sep 2008 10:18:46 -0700

> should get you in the right ballpark without having to ask the user.

Nick,

I think you're talking about a theoretical "should" and Laird is  
talking about what he's observed in practice.

Phil