[alto] Review of draft-livingood-woundy-p4p-experiences-04

[Enrico Marocco <[e-mail]>]

I think the draft is in a good shape and, even if not a product of the
WG, would make for an informational document useful for ALTO too.
However, there are still a few things that should be taken care of.


GENERAL COMMENTS

Terminology: text in Abstract and Introduction sections (S. 2.) seems to
use the term "P4P" to refer to the DCIA initiative and the term
"iTracker" for the technology. However, in the reminder of the document
both terms are used to refer to the technology; this could generate
confusion, especially now that "P4P" is also the name of a solution
proposed in this working group, a solution derived by the one evaluated
in the trial the document describes, but not the same one. I would
suggest to revise the terminology in the draft and replace the term
"P4P" with "iTracker" whenever it is used to indicate the technology. I
would also suggest (see comments about S. 2.) to add an informative
reference to the SIGCOMM paper describing the solution tested in the trial.

Different iTrackers: in S. 3. the four types of iTracker evaluated in
the trial are introduced, but not described. Accurate descriptions are
quite strangely proposed later in the text (S. 5.), after their actual
evaluation; I think that moving such descriptions before the results (S.
4.) would improve the readability. Also, I recall from Minneapolis (and
the minutes from the meeting seem to reflect that) that the "random"
approach does not really consist of a random selection, rather it is the
native approach Pando clients would follow without P4P support. If that
is the case, it may make sense using a different name ("native"?) for
that approach.


Section 2. Introduction

   P4P's so-called "iTracker" technology was conceptually discussed with
   the IETF at the Peer to Peer Infrastructure (P2Pi) Workshop held on
   May 22, 2008, at the Massachusetts Institute of Technology (MIT).

I would add two informative references here, to some document describing
the technology actually evaluated in the trial (10.1145/1402946.1402999,
e.g.) and to the workshop report (draft-p2pi-cooper-workshop-report-01,
in IESG evaluation).

   video file as in order to measure the effectiveness of P4P iTrackers.

s/as in order to/in order to/


Section 4.2. Impact on Downloads, or Downstream Traffic

   However, we did notice that download activity in our access network
   increased somewhat, from 56,030 MB for Random, to 59,765 MB for P4P
   Generic Weight, and 60,781 MB for P4P Coarse Grained.  Note that for
   each swarm, the number of downloaded bytes our logs report is very
   close to the number of downloaders multiplied by file size.  But they
   do not exactly match due to log report errors and duplicated chunks.
   One factor contributing to the differences in access network download
   activity is that different swarms have different numbers of
   downloaders due to random variations during uniform random assignment
   of downloaders to swarms (see Table 1).  One interesting observation
   is that Random has higher cancellation rate (3.17%) than that of the
   guided swarms (1.77% to 2.22%).  Whether guided swarms achieve lower
   cancellation rate is an interesting issue for future investigation.

This text is repeated word-by-word in the following section (S. 4.3.);
I'd suggest to remove it. If you agree to do this change, I'd also
suggest to change the title of the section to "Impacts on Downloads" and
to add a paragraph to describe the data show in Table 2, just as the
remove paragraph did for Table 1.


Section 4.3. Other Impacts and Interesting Data

The section is actually about the impacts on the traffic (i.e. what the
ISP cares about), as opposed to the previous section that was about the
impacts on the downloads (i.e. what users care about); I'd suggest to
make the dichotomy explicit changing the title to something like
"Impacts on upstream and downstream traffic."

-- 
Ciao,
Enrico