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

From: "Tsuyoshi Momose (tmomose)" <[email-masked]>
Date: Mon, 9 Jul 2012 06:55:21 +0000

Vijay, 

Thank you for the review. And I apologize too late reply.
Based on your comment, we submitted updated edition on last Friday.
Let me explain what we've updated.

On 2012/06/19, at 6:59, Vijay K. Gurbani wrote:

> 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.

Added some references.
See the latest draft for the detail.

> 
> - 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.

Changed as your proposal.

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

Changed as your proposal.

> - 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?

You pointed out for the case of CSP peers to the core networks. This paragraph tries to say what happens server cost reduction with using P2P. We added words after the sentence as follows:

"From the viewpoint of network providers, the traffic that content servers generate has shifted to the edge network and the amount of traffic has not necessarily been reduced with using P2P technology for reducing server cost."

> - 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 ...

It might mislead you with the document. we've updated it as follows:

In some cases, the total amount of traffic on the Internet used to be limited by the capacity of servers.  For those cases, P2P technology can improve the scalability of servers, however it may exhaust network resources. Moreover, using P2P applications increases the volume of traffic per user remarkably.

> - 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.

Our dummy node is also passive. But the description about dummy node might be insufficient. we added it at the tail of section 2.3.

> 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.

Dummy nodes are used just for measurement with using sampling not DPI. That should be already described in the document.

> - 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.

Dummy nodes are used only for measurement. They do not control the p2p network at all.
But to make it clear, we updated the document.

> 
> -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.

Indeed the term "routing table" is ambiguous. We've changed the description more simply not to use the term.

> - 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".

Changed as your proposal.

> - 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 ...

We've changed the description to make it clear as "From the viewpoint of network providers, the traffic that content servers generate has shifted to the edge network and the amount of traffic has not necessarily been reduced with using P2P technology for reducing server cost."

> 
> NITS:
> 
> - S1, second paragraph: s/have been/has been/
> - S2.1: s/application Bittorrent isn't/application, Bittorrent, isn't/

Changed as your proposal.

> - S2.1: Any reference for PerfectDark?

Deleted for PerfectDark because it isn't so known even in Japan.

> - S2.2: Please expand "IX".

Changed as 'Internet Exchange'

> - 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).

They should be fixed for all similar typos.

> - S2.3: s/applications ./applications./

fixed.

> - 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/

fixed.

> - S4, below Table 1: s/gotten at/received from/

fixed.

> 
> [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} / [email-masked]
> Web:   http://ect.bell-labs.com/who/vkg/
> _______________________________________________
> p2prg mailing list
> [email-masked]
> http://www.irtf.org/mailman/listinfo/p2prg

Thanks,

--
Tsuyoshi Momose

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Wed, 11 Jul 2012 11:19:41 -0500

On 07/09/2012 01:55 AM, Tsuyoshi Momose (tmomose) wrote:
> Vijay,
>
> Thank you for the review. And I apologize too late reply. Based on
> your comment, we submitted updated edition on last Friday. Let me
> explain what we've updated.

Thank you for attending to my comments.

I only have one further comment in -07, which is detailed below.

>> - 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.
>
> Dummy nodes are used only for measurement. They do not control the
> p2p network at all. But to make it clear, we updated the document.

I remain unsure on how a non-dummy peer sends information to a "hint
server".  My assumption is that a non-dummy peer was not modified, so
why would it contact the hint server. which appears to be a piece of
your data-gathering machinery and would not normally appear in the
swarm?

It may be that I am missing something minor here.

Apart from the above, I have no further comments on -07.

I suspect that edits for language etc. will help the draft, but maybe
these could be done by the RFC editor?

Thanks for attending to my review.

Regards,

- vijay

---

From: "Tsuyoshi Momose (tmomose)" <[email-masked]>
Date: Fri, 13 Jul 2012 10:16:10 +0000

Vijay, 

Thanks again.

> your data-gathering machinery and would not normally appear in the

I may not understand your question correctly, but let me summarize again the purpose and behavior of dummy nodes.
The experiment coordinator put a hint server which behaves like an ALTO server.
Every P2P nodes provided by vendors who join this experiment always use the hint server. The protocol for the hint server is open to the experiment attendee, thus, the vendors can implement the code for the hint server by themselves and they can choose best peers to reduce the traffic. But there are neither methods nor protocols to measure the effect of reduced traffic because it's hard to make standards for quite different p2p applications.
So, to measure the effect, we introduced nodes which dedicate p2p traffic measurement. The nodes build another p2p network system but do nothing except measuring traffic. So, they are called 'dummy nodes'. Dummy nodes just monitors the traffic and analyze their peers at their network interface. 

I hope this summary helps you to understand the situation.

> these could be done by the RFC editor?

we hope so, but I don't know the further plans.

> Thanks for attending to my review.

We appreciate your sincere review.

Regards,

--
Tsuyoshi Momose

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Fri, 13 Jul 2012 08:33:32 -0500

On 07/13/2012 05:16 AM, Tsuyoshi Momose (tmomose) wrote:
vkg> I remain unsure on how a non-dummy peer sends information to a "hint
vkg> server".
> I may not understand your question correctly, but let me summarize 
> again the purpose and behavior of dummy nodes. The experiment coordinator 
> put a hint server which behaves like an ALTO server.
> Every P2P nodes provided by vendors who join this experiment always use 
> the hint server. 

Aha ... that bit --- "every P2P node provided by vendors who join this
experiment always use the hint server." --- is what is missing
in the draft.

A quick sentence like:

  "Every P2P node provided by participating vendors in the
   experiment was configured so it always contacted the hint server."

is all that is needed.

That's it.

Thanks,

- vijay

---

From: "Tsuyoshi Momose (tmomose)" <[email-masked]>
Date: Fri, 13 Jul 2012 15:07:14 +0000

I'll update the I-D as you proposed.

Thank you.

--
Tsuyoshi Momose

---

From: stefano previdi <[email-masked]>
Date: Mon, 16 Jul 2012 12:42:42 +0200

On Jul 13, 2012, at 9:39 PM, Volker Hilt wrote:

> Tsuyoshi Momose,
> 
> great, thanks! Please note that the deadline for draft submissions is
> 2012-07-16 (Monday) cut-off by UTC 24:00

note that IRTF needs not to follow ietf deadline and we may be more flexible.

s.

> 
> Thanks,
> 
> Volker
> 
> 
> On 13.07.2012 11:07, Tsuyoshi Momose (tmomose) wrote:
>> On 2012/07/13, at 22:27, "Vijay K. Gurbani"<[email-masked]>  wrote:
>>

---

From: "Eggert, Lars" <[email-masked]>
Date: Mon, 16 Jul 2012 11:02:05 +0000

The submission deadline is for all IDs. (The RFC streams are different, but the IDs are not.)

Lars

---

From: "Tsuyoshi Momose (tmomose)" <[email-masked]>
Date: Mon, 16 Jul 2012 12:31:53 +0000

I've already submitted the final edition by 7/16 as attached.

Regards,

--
Tsuyoshi Momose

On 2012/07/14, at 4:39, "Volker Hilt" <[email-masked]<mailto:[email-masked]>> wrote:

Tsuyoshi Momose,

Thanks,

Volker

Thank you.

--
Tsuyoshi Momose

On 2012/07/13, at 22:27, "Vijay K. Gurbani"<[email-masked]<mailto:[email-masked]>>  wrote:

A quick sentence like:

is all that is needed.

That's it.

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<http://acm.org>} / [email-masked]<mailto:[email-masked]>
Web:   http://ect.bell-labs.com/who/vkg/

Begin forwarded message:

差出人: <[email-masked]<mailto:[email-masked]>>
日時: 2012年7月15日 23:46:58 JST
宛先: <[email-masked]<mailto:[email-masked]>>
Cc: <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>
件名: New Version Notification for draft-kamei-p2p-experiments-japan-08.txt

A new version of I-D, draft-kamei-p2p-experiments-japan-08.txt
has been successfully submitted by Tsuyoshi Momose and posted to the
IETF repository.

Filename:     draft-kamei-p2p-experiments-japan
Revision:     08
Title:         ALTO-Like Activities and Experiments in P2P Network Experiment Council
Creation date:     2012-07-15
WG ID:         Individual Submission
Number of pages: 16
URL:             http://www.ietf.org/internet-drafts/draft-kamei-p2p-experiments-japan-08.txt
Status:          http://datatracker.ietf.org/doc/draft-kamei-p2p-experiments-japan
Htmlized:        http://tools.ietf.org/html/draft-kamei-p2p-experiments-japan-08
Diff:            http://tools.ietf.org/rfcdiff?url2=draft-kamei-p2p-experiments-japan-08

Abstract:
  This document introduces experiments to clarify how ALTO-like
  approach was effective to reduce network traffic made by a Council in
  Japan to harmonize P2P technology with the infrastructure.  And this
  also provides some suggestions that might be useful for ALTO
  architecture learned through our experiments.

The IETF Secretariat