Subject: [alto] ALTO client

From: Song Haibin <[email-masked]>
Date: Fri, 21 May 2010 08:48:42 +0800

For tracker based p2p applications, some guys proposed to embed the ALTO
client within the tracker, so that the p2p clients do not have to be
changed. But one additional thought comes into mind, peers usually exchange
peer list among themselves, does a peer also have to implement ALTO client
to select peers from these candidates got from other peers? 

Xie Xie,
Haibin

---

From: Reinaldo Penno <[email-masked]>
Date: Thu, 20 May 2010 22:50:24 -0400

Hi,

> to select peers from these candidates got from other peers?

I would say no. ALTO was optional from the beginning since the idea is that
clients can always fall back to original behavior in case of disruption.

Interesting question what would happen if you control the tracker (as  in
your example) but peers can exchange info that ultimately is based on the
original selection done at the tracker. You will loose some localization but
without DHT there is no other place to get peers from, therefore inter-AS
traffic might still be curbed.

> 
> Xie Xie,
> Haibin
> 
> 
> 
> _______________________________________________
> alto mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/alto

---

From: Song Haibin <[email-masked]>
Date: Fri, 21 May 2010 12:07:09 +0800

Hi Reinaldo,

Thanks for your reply. See comments in line.

> -----Original Message-----
> From: Reinaldo Penno [mailto:[email-masked]]
> Sent: Friday, May 21, 2010 10:50 AM
> To: Song Haibin; [email-masked]
> Subject: Re: [alto] ALTO client
> 
> Hi,
> 

A peer can get peers in the same swarm from the connected neighbors in the
existing p2p applications, even without DHT. I don't know how much
difference there will be if the peer also implements the ALTO client.

Haibin

---

From: Sebastian Kiesel <[email-masked]>
Date: Sun, 23 May 2010 00:03:23 +0200

On Fri, May 21, 2010 at 08:48:42AM +0800, Song Haibin wrote:
> changed. 

It is a good question wheter it is more practical to change only the
tracker or all the peers in order to deploy ALTO.
However, I think this is not the most important question when we
ask ourselves where to place the ALTO client!

I believe it is more important that we ask: Which configuration will
yield better results for the peer selection? Please read section
2.1 of draft-kiesel-alto-3pdisc-02, there we explain why we believe the
ALTO client in the tracker will give better results as opposed to
putting the ALTO client in the peers. If you have questions or another
point of view pleas let us know, we'd be happy to discuss!

> But one additional thought comes into mind, peers usually exchange

I am not sure about this. Probably it would be the best if there
was an ALTO client in the tracker and in each peer. But maybe in some
scenarios it would be sufficient to have an ALTO client in the tracker,
in order to get a "good" list of initial neighbors. For the peers you
learn from your neigbors it might be sufficient to assess them by doing
measurements. If you are interested not only in performance improvements
but also in reducing ISP's costs you probably need to always ask ALTO.

Thanks,
Sebastian

---

From: Enrico Marocco <[email-masked]>
Date: Mon, 24 May 2010 11:14:13 +0200

> point of view pleas let us know, we'd be happy to discuss!

I don't have a strong opinion whether it will be better to have the
client embedded in the peers or in the tracker, but I see good points on
both sides.

To add some information to the discussion, I've uploaded at the
following link some charts showing the observed number of peers a
BitTorrent client got to know while downloading a particular file in
swarms of different size: http://ubiq.tilab.com/~enrico/graphs/

While the peers returned by the tracker -- the initial rise in the
graphs -- are important in the first phase of the download, the number
of peers discovered during the entire download period gets often very
close to the size of the swarm.

-- 
Ciao,
Enrico

---

From: Song Haibin <[email-masked]>
Date: Tue, 25 May 2010 16:32:40 +0800

> From: Enrico Marocco [mailto:[email-masked]]
> Sent: Monday, May 24, 2010 5:14 PM
> To: Sebastian Kiesel
> Cc: Song Haibin; [email-masked]

> client embedded in the peers or in the tracker, but I see good points on

I agree. My concern is the tradeoff between the complexity and the
performance. 

> close to the size of the swarm.
These graphs are very interesting. Do you have some data about the total
number of peers returned by tracker VS the total number got from other peers
during the entire download period?

BR,
Haibin

---

From: Enrico Marocco <[email-masked]>
Date: Tue, 25 May 2010 10:47:27 +0200

> during the entire download period?

50, only once, at the beginning of the download.

-- 
Ciao,
Enrico

---

From: Dirk Haage <[email-masked]>
Date: Tue, 25 May 2010 11:00:52 +0200

Hi,

comments below

> difference there will be if the peer also implements the ALTO client.
One thing I would expect in this scenario is, that each client gets peers from the tracker which in this case are selected by the ALTO client within the tracker.
This means most of the clients will know mostly good peers in the sense of ALTO. The direct peer exchange will then also provide the better peers to other clients.

But this argument might only be valid if all trackers use ALTO.

best regards
Dirk

-- 
Dipl.-Ing. Dirk Haage          | Informatics VIII:
+49 89 289 18019               | Network Architectures & Services
[email-masked]            |Technical University of Munich
MI 03.05.057, Bolzmannstr. 3, 85748 Garching bei München, Germany

---

From: Sebastian Kiesel <[email-masked]>
Date: Tue, 25 May 2010 14:49:49 +0200

> close to the size of the swarm.

Isn't this initial phase when joining a swarm the one where ALTO
can be most beneficial? IIRC this insight was captured in our
charter: "The Working Group will design ... service ... to perform
better-than-random *** INITIAL *** peer selection."

If we are talking about the application's performance or QoE only:
It is no suprise that, if we wait long enough, we can find enough fast
neighbors just by gossipping and throughput probing (if fast neighbors
actually exist in the swarm). But not trying to optimize the tracker
response would mean that we assume, that the tracker is an irrelvant
bootstrap helper only, while the "real" neighbor discovery is done
by other means, right?

If we think of the general case with arbitrary rating criteria that
cannot be measured(e.g., monetary cost for data transmission to the
candidate peer), all candidate peers should be evaluated by ALTO, no
matter whether they were learnt from the tracker or discovered by some
other means. Therefore we need an ALTO client in the peer. Nevertheless,
the quality (i.e., long-term impact) of the tracker response can be
improved by performing an ALTO-guided selection of peers in the tracker.

Thanks,
Sebastian

---

From: Enrico Marocco <[email-masked]>
Date: Tue, 25 May 2010 15:43:32 +0200

> better-than-random *** INITIAL *** peer selection."

Well, I'd say that ALTO information may be useful in any selection
process that would be random otherwise, regardless of whether it happens
when joining the swarm or, e.g., in the BitTorrent optimistic unchoke
recurring phase. In the spirit of the charter, at least as I read it,
"initial" peer selection is intended as opposed to application-specific
peer selection (e.g. tit-for-tat in BitTorrent).

> improved by performing an ALTO-guided selection of peers in the tracker.

I agree. Again, I really don't have an opinion whether an ALTO client
would be best embedded in the tracker or in the peers, but I don't even
see a reason why it could not be embedded in both.

-- 
Ciao,
Enrico