[p2prg] RGLC review for draft-kamei-p2p-experiments-japan-06

["Vijay K. Gurbani" <[e-mail]>]

Volker, Stefano: In response to your email on the list for reviewing
draft-kamei-p2p-experiments-japan-06 [1], I am submitting the following
review of the draft.

In summary, I think that the draft has the potential to document, for
archival purposes, the early work on ALTO-like systems and trace the
evolution of ALTO.  But it needs a lot of editorial and grammatical
work.  Ideas and explorations in the draft need to be described more
clearly and the results explained in more detail.

Below is an in-depth summary of the changes that will be required on the
draft.

MAJOR:

- S1: "Several proposals have been made to build an overlay network
  that takes account of the information about the lower layer network."

  May be a good idea to list some references, or a survey of this
  work.

- S2.1, second paragraph: I am not sure I understand the impact of
  this paragraph.  I *think* what you are trying to say is something
  like the following:

  Each P2P file sharing application has a unique protocol and none of
  them have a large market share therfore making it hard to effectively
  control.

- S2.2, first paragraph: perhaps you meant "delay-sensitive" instead
  of "traffic-sensitive"?

- S2.2, second paragraph: "From the viewpoint of network providers, the
  traffic that content servers generate has shifted to the edge
  network..." --- Is this still true?  I was under the impression that
  the CSP's were moving ever so deeper into the network to position the
  content servers closer to the users, no?

- S2.2, third paragraph: Not sure where you are headed with this text.
  Server improvement results in increased traffic, and so does using P2P
  applications.  So, network bandwidth is not the problem that we are
  trying to solve here ...

- S3.1: I believe what you are calling a "Dummy node" is actually a
  "Control node"; i.e., a node under your control so you can observe
  in detail what is transpiring on the P2P network and maybe even
  influence what happens on the network.

  By contrast, a real "dummy node" would be one that is passive and
  does not participate in the P2P network.

  Your description seems to lead credence to the belief that your
  dummy nodes essentially infiltrated the P2P network and somehow
  captured traffic on the network; but you do not describe how did they
  do this?  By joining the P2P network and acting as peers?  Or by
  DPI?  It seems that you joined the P2P network as a sybil peer, but
  what confuses me is that you go on to say that "With this
  configuration, all packets can be captured without any impacts to the
  network ..." Clearly, a sybil peer will get all packets that traverse
  through it, but it will NOT get all packets generated in the P2P
  swarm.

- S4, second paragraph: You write --- "When a peer joins the network,
  it registers its location information (IP address) and supplementary
  information (line speed, etc.) with the hint server."  Here, I think
  you imply that a "peer" is one of your dummy servers, hence it is
  happy to provide supplementary information like line speed, etc.
  Since you did not modify the real peers, they will not provide the
  same supplementary information to the hint server that your dummy peer
  will.  Please clarify.

-S4, second paragraph: "The hint server makes a mapping of the new peer
  (P2P client) [...and...] generates a routing table in which peers
  are listed in the order of priority for selection, and returns the
  table to the peer." --- To be sure, this is not a routing table as much
  as it is an "ordered list of peers to contact" (your Figure 2 lends
  more credence to such a view).  This should be clarified since the
  term "routing table" has a specific meaning to DHTs.

- S4, below Figure 2 you write, "The network information used by the
  hint server is not information solicited from individual ISPs but the
  AS number and district information, which are more or less already
  public."  Earlier, you made a point that supplementary information such
  as line speed is also sent to the hint server.  How does the hint
  server use such information to rank the peers?

- S4, 3rd paragraph below Figure 2: "Although the priority node ..."
  I think here you mean "target node" instead of "priority node".

- S5: What is the difference between Experiment 1 and Experiment 2?
  It seems that Experiment 2 had a richer swarm, so you are getting
  better localization from this swarm.  You may want to put some more
  information about the number of peers in Experiments 1 and 2, the
  duration during which these results were generated, etc.

- S5.2 seems rather odd since you earlier made a point that traffic
  reduction was an important metric (c.f. S2.3, last sentence of the
  second paragraph, and last sentence of third paragraph).  After priming
  the user that traffic reduction is important, S5.2 says that it is
  not.  So, I am at a loss on how to interpret the results ...

NITS:

- S1, second paragraph: s/have been/has been/
- S2.1: s/application Bittorrent isn't/application, Bittorrent, isn't/
- S2.1: Any reference for PerfectDark?
- S2.2: Please expand "IX".
- S2.2: s/fees[3]./fees [3]./
  This is a global comment to check for similar typos (see for instance,
  S3 that has the same problem).
- S2.3: s/applications ./applications./
- S2.3: Not sure that the use of "conjunction" is the right word here...
  (c.f., "Besides this activity, the council also looked for new ways to
  avoid traffic conjunction by commercial P2P applications with
  ISPs,...")
- S3: s/goals of our experiment are/goals of our experiment is/
- S4, below Table 1: s/gotten at/received from/

[1] http://www.ietf.org/mail-archive/web/p2prg/current/msg01719.html

Thanks,

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
Email: vkg@{bell-labs.com,acm.org} / [e-mail]
Web:   http://ect.bell-labs.com/who/vkg/