Hi Vijay,

Very interesting results!  It does look like it converges to a good
result, but I'm wondering if it would be possible to reduce the
convergence time further (smaller than 10m). Can you give some more
details on how ALTO was integrated with the BitTorrent clients here?
Was it used for ranking peers returned from a tracker, or also
peer-exchange (if enabled)?  How often were new peers discovered from
a tracker or peer-exchange? Was it a greedy strategy in which only
closest peers were chosen, or were a few sub-optimal peers chosen for
robustness?

Thanks!
Rich

On Fri, Apr 15, 2011 at 9:43 AM, Vijay K. Gurbani <[email protected]> wrote:
> Folks: In the Prague p2prg, I had presented an ns-3 simulation
> of ALTO [1].
>
> The topology was simple (see slide 4 of [1]): an
> ISP (Chicago-ISP, PID 1), a peering link (ISP-Peering, PID 2),
> a transit link (ISP-Transit, PID 5), and a couple of links
> representing the rest of the Internet (Internet-1 and Internet-2,
> PIDs 3 and 4, respectively).  A cost map was provided in
> slide 5 of [1].
>
> A couple of simulations were shown, the first showed results
> of traffic transferred from the Chicago-ISP to rest of the
> network without ALTO, and the second simulation showed the
> resulting decrease in transit traffic and increase in peering
> and intra-ISP traffic when ALTO is used.
>
> I was running a third simulation, which is probably the most
> interesting one.  It did not complete by the time p2prg was held
> in Prague.  This simulation sheds some light on whether ALTO
> can influence the choice of suboptimal peer selection.
>
> One issue that has been talked about in ALTO is whether it can
> influence the choice of sub-optimal peers; in other words,
> can ALTO be used to purposely provide sub-optimal peers simply
> because a peering relationship exists and the peers in the
> peering network are sub-optimal (i.e., they may have less upload
> bandwidth when compared to other peers).
>
> The third simulation shows that this is not the case, and other
> publications [2] have experimentally demonstrated that this
> is not the case for BitTorrent at least.  BitTorrent exhibits
> strong clustering behaviour, where similar-bandwidth peers
> cluster together to ensure effective sharing incentives by
> rewarding peers who contribute proportionally more to the
> system.
>
> To run the third simulation, I kept the cost map invariant.
> However, I downgraded the data rate of the ISP-Peering
> peers.  So, compared to the rest of the peers, the ISP-Peering
> peers offer upload at a much reduced rate.  The expectation is
> that over time, the peers in ISP-Chicago will stop preferring
> peers in ISP-Peering, even though the cost to reach those peers
> is minimal.  And, the peers in ISP-Chicago would start
> preferring intra-ISP peers (i.e., other peers from ISP-Chicago),
> and even peers from ISP-Transit.
>
> This appears to indeed be the case, and the result is shown in
> the attached PDF.  Here is a summary table; in the table below,
> "Simulation 2" is the third simulation:
>
>            |      Simulation 1         |      Simulation 2
> Traffic     | (all peers have similar   | (peers in ISP-Peering
> destined to |       data rates)         |  have lower data rates)
> ------------+---------------------------+-----------------------------
> ISP-Chicago | 1.78 GB                   |   1.97 GB  (+ ~11%)
> ISP-Transit | 1.84 GB                   |   2.14 GB  (+ ~16%)
> ISP-Peering | 2.26 GB                   | 606.97 MB  (- ~3.7x)
> Internet-1  | 2.03 GB                   |   2.38 GB  (+ ~15%)
> Internet-2  | 2.12 GB                   |   2.35 GB  (+ ~12%)
>
> [1] http://www.ietf.org/proceedings/80/slides/P2PRG-5.pdf
> [2] "Clustering and sharing incentives in BitTorrent systems",
>  Arnaud Legout, Nikitas Liogkas, Eddie Kohler and Lixia Zhang,
>  ACM Sigmetrics, June 2007.
>
> I thought some of you may find this interesting.
>
> Thanks,
>
> - vijay
> --
> Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
> 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA)
> Email: vkg@{bell-labs.com,acm.org} / [email protected]
> Web:   http://ect.bell-labs.com/who/vkg/
>
> _______________________________________________
> alto mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/alto
>
>
_______________________________________________
alto mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/alto

Reply via email to