Subject: Re: [alto] Comments on provisioned bandwidth and ALTO

From: "Woundy, Richard" <[email-masked]>
Date: Thu, 18 Mar 2010 18:54:13 -0400

How about:

(Probability of picking peer X) := (Prov.BW of peer X) / (Sum prov.BW) 

Or here's a totally different idea. The client states a bandwidth floor and the server/service eliminates peers without at least that much provisioned bandwidth??? And no response from server/service if too few peers?

-- Rich

----- Original Message -----
From: Sebastian Kiesel <[email-masked]>
To: Woundy, Richard
Cc: Sebastian Kiesel <[email-masked]>; [email-masked] <[email-masked]>
Sent: Thu Mar 18 18:20:44 2010
Subject: Re: [alto] Comments on provisioned bandwidth and ALTO

Rich,

On Thu, Mar 18, 2010 at 05:48:04PM -0400, Woundy, Richard wrote:
> I agree.
> 
> Here's a slightly different example. The common tier for ISP A may have
> provisioned bandwidth of 12 Mbps, and 10 Mbps for ISP B. Assuming that
> an application doesn't need 11 Mbps, it may make more sense for the app
> to pick an ISP A client 12 times out of 22 (55%), and an ISP B client 10
> times out of 22 (45%), 

what you describe here sounds very reasonable. But how would you
implement it as an algorithm that works for arbitrary BW distributions
in the swarm?

My first thought,

(Probability of picking peer X) := (Prov.BW of peer X) / (Average prov.BW) 

would exactly cause the problem I described, if there were very many
peers with a BW slightly below the average and very few ones with a BW
far above the average.

I'm not saying that the provisioned bandwidth attribute is useles,
but I think we must be very careful in designing algorithms that make
use of it.

-- Sebastian

---

From: Sebastian Kiesel <[email-masked]>
Date: Fri, 19 Mar 2010 00:19:52 +0100

> (Probability of picking peer X) := (Prov.BW of peer X) / (Sum prov.BW) 

better. :) though getting BW info for all peers might be unrealistic

> Or here's a totally different idea. The client states a bandwidth
> floor and the server/service eliminates peers without at least that
> much provisioned bandwidth??? 

The ALTO reqs draft already says:

5.3.  Performance-related rating criteria

   o  The minimum achievable throughput between the resource consumer
      and the candidate resource provider, which is considered useful by
      the application (only in ALTO queries), or

   o  An arbitrary upper bound for the throughput from/to the candidate
      resource provider (only in ALTO replies).  This may be, but is not
      necessarily the provisioned access bandwidth of the candidate
      resource provider.
...

   The ALTO client MUST be aware, that with high probability, the actual
   performance values differ significantly from these upper and lower
   bounds.  In particular, an ALTO client MUST NOT consider the "upper
   bound for throughput" parameter as a permission to send data at the
   indicated rate without using congestion control mechanisms.

...

   Nevertheless, these rating
   criteria may provide a useful shortcut for quickly excluding
   candidate resource providers from such probing, if it is known in
   advance that connectivity is in any case worse than what is
   considered the minimum useful value by the respective application.

-- Sebastian

---

From: Richard Alimi <[email-masked]>
Date: Thu, 18 Mar 2010 20:10:33 -0400

Another method for doing peer selection utilizing some measure of provisioned 
bandwidth is the optimization that we used in the P4P trials. In particular, 
we used peer selection guided by a technique called bandwidth matching.  For 
details, see the section titled "Application with Upload/Download Matching" on 
Page 4 (labeled page 354) of the Sigcomm 2008 paper:
  http://ccr.sigcomm.org/online/?q=node/402

Related to Reinaldo's comment about the interaction with localization, we took 
the approach that the application would first try to maximize its objective 
(e.g., maximize the total matched bandwidth).  Then, we recompute peering 
guidance to optimize for network efficiency (i.e., minimize ALTO costs) under 
the constraint that the total matched bandwidth is at least a certain 
percentage (e.g., 80%) of the optimal value. Put another way, the application 
sacrifices up to a certain (application-configured) percentage in favor of 
network efficiency. Nevertheless, in the trials, we did see increased 
application performance (in addition to increased network efficiency).

There are a couple of things to note about the the technique applied here:
1) This optimization was done by the tracker when doing peer selection for
   newly-joined peers (and peers getting new peer lists from the tracker),
   and not locally by the peers themselves.
2) Aggregation was applied at the PID level for scalability purposes.

The formulation described here can face scalability problems when done swarm-
wide without such aggregation, but I mention it here as another possibility 
for computing peering weights that utilizes bandwidth jointly with 
localization.

-- 
Richard Alimi
Department of Computer Science
Yale University

On Thursday 18 March 2010 7:19:52 pm Sebastian Kiesel wrote:
> _______________________________________________
> alto mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/alto

---

From: Richard Alimi <[email-masked]>
Date: Thu, 18 Mar 2010 20:17:58 -0400

On Thursday 18 March 2010 8:10:33 pm Richard Alimi wrote:

[ .. snip .. ]

> 2) Aggregation was applied at the PID level for scalability purposes.

I should also note one other thing: the bandwidth matching technique was 
formulated for, and applied to filesharing.