Dear Satish,
Thank you for your interest in our paper. I will try to answer your
questions, please do not hesitate to tell me if something is still
unclear afterward.
Going by the discussion in Section 3.3.2 and Section 4.1, I get the
following impression. In the experiments, increased locality has the
effect of increased number of peers in the same ISP. That is, the
population of peers is somehow unaffiliated to ISPs and locality seems
to determine the number of ISPs per peer. Locality seems to be defined
in terms of the number of inter-ISP links and the number of peers per
ISP seem to change with that. Excerpt from 3.3.2:
In all the experiments that evaluate the robustness of high
locality values, for 8 inter-ISP connections the locality values
range from 99% (for 100 peers and 10 ISPs) to 99.998% (for
10 000 peers and 5 000 peers per ISP), and for 80 inter-ISP
connections, the locality values range from 90% (for 100
peers and 10 ISPs) to 99.98% (for 10 000 peers and 5 000
peers per ISP).
Is my understanding right? Or did I misinterpret the text?
Let me rephrase this to make sure we understand each other.
As we define locality as the percentage of cross-ISP connections (see
Section 3.1) and the number of connections per peer is fixed (i.e., 80),
if we increase the number of peers in an ISP, the number of inter-ISP
connections in that ISP increases as well. To keep the number of
inter-ISP connections constant while we vary the torrent size and the
number of peers per ISP, we vary the locality value. For this reason, we
consider 2 fixed numbers of inter-ISP connections (i.e., 8 and 80) in
Section 5.
I feel judging impact on download performance should ideally consider
the impact of lack of peers that participate in a swarm within the local
ISP. If I am an end-user, my concern would be more that I may not find
enough peers if a high degree of locality is enforced. I feel it is
important to add experiments that capture the problem of lack of peers
due to locality policy.
As you have noticed, there is a trade off here: If I am an end-user my
concern is to get good performances but if I am an ISP, my concern is to
reduce my bill. At one extreme, if there is only one user active for a
file in one ISP, there is no locality to be exploited. What to do in
that case, e.g., delay the transfer or not, is outside of the scope of
our paper. Our paper relies on findings from previous works that showed
that there is locality to be exploited.
However, note that we have experimented with as few as 10 peers per ISP
in Section 5.1 and showed that even in that case, we can save up to 54%
of inter-ISP traffic with absolutely no performance penalty as compared
to BitTorrent.
There were a few other minor questions that the paper may want to
clarify. There seem to be up to 100 bittorrent clients per node. Could a
'local download' result in two clients on the same node talking to each
other and could that lead to artificially low download times?
Yes, two peers on the same node can talk to each.
I'm not sure why that may lead to slower download times as all peers
read and write on some disk with a limited speed. The pieces must be
read by a first peer, and then written by a second peer. That those two
peers be located on the same node or not, the load is the same globally.
That said, you are right that we have to be careful with the load on the
nodes for the experiments to be relevant. However, we discuss this issue
in Section 3.2.1 (last paragraph), and are actually quite conservative
in the number of clients that we run on each node.
The other question is about the bottleneck simulation (page 5, col 2).
This is somewhat different from a real n/w having throttling some place
in the network. The paper describes a per-node throttling mechanism. In
your experiment, if an ISP spans across nodes (lets say has 200 peers),
does the Linux 'tc' traffic controller policy make sure there is no
throttling between nodes that belong to the same ISP? This might again
complicate the read on download times for local downloads.
In those experiments we run 1,000 clients on 10 physical nodes with a
topology of 10 ISPs (one node per ISP). Hence, no ISP spans across
nodes. You can read Section 5.3, Fig. 7, and Fig. 8 for more details. We
could have made this point clearer, thank you for pointing that out.
Thank you very much for your comments.
Best regards,
Stevens Le Blond
_______________________________________________
alto mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/alto
