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

"Tsuyoshi Momose (tmomose)" <tmomose@cisco.com> Mon, 09 July 2012 06:54 UTC

Return-Path: <tmomose@cisco.com>
X-Original-To: p2prg@ietfa.amsl.com
Delivered-To: p2prg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFF3311E8079 for <p2prg@ietfa.amsl.com>; Sun, 8 Jul 2012 23:54:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.97
X-Spam-Level:
X-Spam-Status: No, score=-6.97 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FB_INCREASE_VOL=3.629, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VAvWtU5TtM4F for <p2prg@ietfa.amsl.com>; Sun, 8 Jul 2012 23:54:58 -0700 (PDT)
Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 9148511E8073 for <p2prg@irtf.org>; Sun, 8 Jul 2012 23:54:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=tmomose@cisco.com; l=8718; q=dns/txt; s=iport; t=1341816923; x=1343026523; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=GAiuDvNimWwUi1wGtcz1DuNN5TDjMl6jaXK1t3UFgKE=; b=kbKroT+Vs8AAHx2BwRoGDtBWa1P9EcIlylSFmZ4VkY5XZiNysgc8yU4/ +xbPLXwoY0Xk8rkVLk48fAsBowfV4JZJ491EfAOetuWdPk6nWkZeFuhJN KPjD3XOqTmAe97CVZ/tiaJf71pCCA3H3dZNwKLSM+1yHfPjcrSDiMc8J7 M=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av8EACiA+k+tJV2Y/2dsb2JhbABFt2OBB4IgAQEBAwEBAQEPAQUiNAsFCwIBCC0JECcLJQIEDgUJGYdlBguaZJ8Ji1QGgkqCSGADlTaOH4Fmgl+BVgk
X-IronPort-AV: E=Sophos;i="4.77,551,1336348800"; d="scan'208";a="99891529"
Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-7.cisco.com with ESMTP; 09 Jul 2012 06:55:22 +0000
Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q696tMte000569 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 9 Jul 2012 06:55:22 GMT
Received: from xmb-aln-x10.cisco.com ([169.254.5.146]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.02.0298.004; Mon, 9 Jul 2012 01:55:21 -0500
From: "Tsuyoshi Momose (tmomose)" <tmomose@cisco.com>
To: "Vijay K. Gurbani" <vkg@bell-labs.com>
Thread-Topic: [p2prg] RGLC review for draft-kamei-p2p-experiments-japan-06
Thread-Index: AQHNTZzNMAqtncdh/06lMAg2z1pvu5cg+DMA
Date: Mon, 09 Jul 2012 06:55:21 +0000
Message-ID: <6781AC7A-D3B1-466F-9B3F-4AF876A027A0@cisco.com>
References: <4FDFA4A7.3090807@bell-labs.com>
In-Reply-To: <4FDFA4A7.3090807@bell-labs.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.141.32.241]
x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19028.004
x-tm-as-result: No--68.846700-8.000000-31
x-tm-as-user-approved-sender: No
x-tm-as-user-blocked-sender: No
Content-Type: text/plain; charset="us-ascii"
Content-ID: <EEB069429FD0CC42BA59B0CE270E78B8@cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "p2prg@irtf.org" <p2prg@irtf.org>, "Hilt, Volker (Volker)" <volker.hilt@bell-labs.com>
Subject: Re: [p2prg] RGLC review for draft-kamei-p2p-experiments-japan-06
X-BeenThere: p2prg@irtf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Peer-to-Peer Research Group <p2prg.irtf.org>
List-Unsubscribe: <http://www.irtf.org/mailman/options/p2prg>, <mailto:p2prg-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/p2prg>
List-Post: <mailto:p2prg@irtf.org>
List-Help: <mailto:p2prg-request@irtf.org?subject=help>
List-Subscribe: <http://www.irtf.org/mailman/listinfo/p2prg>, <mailto:p2prg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Mon, 09 Jul 2012 06:54:59 -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} / vijay.gurbani@alcatel-lucent.com
> Web:   http://ect.bell-labs.com/who/vkg/
> _______________________________________________
> p2prg mailing list
> p2prg@irtf.org
> http://www.irtf.org/mailman/listinfo/p2prg


Thanks,

--
Tsuyoshi Momose