Subject: Re: [decade] WG Review of draft-ietf-decade-integration-example-03

From: Zongning <[email-masked]>
Date: Wed, 13 Jun 2012 07:54:13 +0000

Hi, Rich,

Sorry for the late reply. Please see below my response.
I think most of your comments are valuable and I will incorporate these in the new revision soon.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Richard Alimi
Sent: Sunday, May 13, 2012 2:10 AM
To: [email-masked]
Subject: [decade] WG Review of draft-ietf-decade-integration-example-03

The following is my review of
draft-ietf-decade-integration-example-03.  Overall, the document is
much improved.  It could still use some general revision for grammar
and to make the wording more concise.

>>[Ning]: Thanks.

Detailed review:

** Introduction

s/firstly/first

"we only show the feasibility of ALTO and INS without comparing to
other content distribution systems at this time"
  - what other "content distribution systems" would be compared against?

>>[Ning]: IMO, it could be CDN, but we don't have real plan for comparison .

  - if not at this time, is that planned for a future iteration of
this draft (if not I'd suggest removing "at this time")

>>[Ning]: No, we don't have such plan. I will rephrase this sentence.

** Terminlogy

add definition for "native application client"

>>[Ning]: Agree.

INS Service Provider
  - does it deploy the entire INS system, or just some servers?

>>[Ning]: It mostly needs to deploy INS servers, portal for application access, and probably dispatch INS plug-in for application.

INS Portal
  - why simulated? what's a simulated portal?

>>[Ning]: I will change the wording. How about just "point for application access"?

  - don't use 'portal' in order to define the term

>>[Ning]: Agree.

** INS Client API

define what a 'token' is (or provide a reference)

>>[Ning]: Agree.

s/authorized token/authorization token/

why does the particular example (ALTO + INS) determine who generates
the token?  Is this detail necessary in the API description?

>>[Ning]: I will remove this from API description.

** Integration of P2P Live Streaming and INS System

Introductory sentence can be simplified to just "We integrate an INS
client into a P2P live streaming client." The rest is repetative.

>>[Ning]: Agree.

what does it mean to be "compatible with original P2P live streaming
signalling"?  Is it more accurate to just say that existing
signallling is still used?

>>[Ning]: I would delete this sentence as all the detail is in control message section.

"whose size can be application-customized according to the variable
requirements of of performance or sensitive factors" - wording seems
awkward. How about something like "the API supports variable-sized
blocks to cater to different application requirements (e.g., latency
and throughput)."

>>[Ning]: Agree.

For live streaming, in what sense are they "bittorrent-like"?  Piece
exchanges?  (the concept of the torrent file and piece map doesn't
directly apply without modifications)

>>[Ning]: I think BitTorrent-like is misleading and I would reword this. We were using a Lab-based P2P live streaming system only for research purpose.

"On the other hand, INS-enabled .." - remove "on the other hand"

>>[Ning]: Agree.

is the token exchange message the reason for the INS Client <-> INS
Client line in Figure 1?  If so, explain in the "Control Messages"
section tha tthis does not use (or extend) the native application
protocol.

>>[Ning]: Yes, and I will explain this in control message section.

To what extent are the recommendations based on the fact that M=1 in
the implementation?  The stronger argument to make might be that the
INS server may need to concurrently serve many thousands (or more)
clients.

>>[Ning]: Each server has M=1 connect to EACH client, NOT all clients.

"can use this range token to access all available data objects in the
INS server"  - make it clear that it isn't all objects in the server,
but only those to which it was permitted access

>>[Ning]: Agree.

The design considerations would be a lot more convincing and easier to
follow if the message flow were discussed before making the
recommendations.  Otherwise, the reader is less clear on the
particular problem being solved.  (Presenting filesharing before live
streaming may solve the problem.)

>>[Ning]: Good point, I will see how to improve this. Changing section order could be one approach.

** Integration of P2P file sharing and INS system

Is Figure 1 basically the same as Figure 2 with the exception of
Figure 2 saying Vuze?  If they are the same, perhaps just present the
general architecture at the beginning of the document and say it works
with both filesharing and live streaming (reuse is a good thing).

>>[Ning]: Yes, and it is good point to have one common picture.

Either explain why it is an "Azureous handshake" or replace it with
just "handshake reply" or similar

>>[Ning]: "handshake reply" is fine here.

There seems to be a transition sentence missing before the details of
Figure 4 are discussed.

>>[Ning]: I will add some sentence here.

Are ther eany additional lessons/recommendatons based on the
filesharing integration?  Even if there aren't, it seems like there
should be some sort of concluding remarks in that section.

>>[Ning]: I will add some short conclusion remark.

** Integration of ALTO and INS System for File Distribution

Alto doesn't (typically) give information to end users. It gives
information to applications run by those end users :)

>>[Ning]: OK, I will change the wording.

s/content servers/content providers/

alto won't help reduce bandwidth consumption for the end host (the
current text seems to imply that). make it clear that it can reduce
network usage within ISP

>>[Ning]: OK, I will change the wording.

s/Architecture Design/Architecture/

how does alto help CPs to upload files ot INS servers?

>>[Ning]: No. ALTO doesn't do this. I will modify.

In Figure 5, why don't End Users talk to INS Servers?  It makes it
look like the CP Portal and INS Portal are on the data path for
downloads.  Similar comment for End Users and ALTO Server.

>>[Ning]: Figure 5 is not data patch, but logical connection between the components. Some redirections can also happen between them. I will try to make this more clear.

In Figure 6, why not have the Portal redirect the uploder to an INS
server instead of acting as a proxy? Acting as a proxy means the
portal (a server or set of servers presumably) must have an aggregate
network capacity equal to the sum of the total upload rate that it
wishes to provide to all the INS servers.  By not using the proxy
design, it also means the INS Portal no longer needs to define
protocol messaging for communicating things like placement policies.

>>[Ning]: In many cases that one CP distribute many copies of many INS servers, a proxy in INS provider could reduce the load of CP. Also note that INS provider may not want to disclose its INS servers to CP.

s/HTTP_POST/HTTP POST/

In the downloading procedure, is the user using a standard web
browser?  From the description, it seems like there must be some sort
of INS extension installed in the web browser (in order to understand
tokens, know how to communicate with INS servers, etc).  That should
be stated.

>>[Ning]: User uses web-browser with INS plug-in.

What is the relationship between the ISP and the INS Service Provider?
 Does the INS Service Provider have servers in multiple ISPs (in which
case it would make sense to consult ALTO servers from each ISP).  Or
is the INS Service Provider the same as the ISP?

>>[Ning]: We tried to decouple the ISP and INS provider when doing experiment. As you see we actually used PlanetLab and EC2 for deploying INS server. The options you mentioned are all possible and open question when deploying INS system.

How is "optimal" decided?

>>[Ning]: How about change to "INS server suggested by ALTO"?

** Test Environment and Settings

Avoid using the word "cloud". They are large sets of servers available for use.

>>[Ning]: Agree.

wild-spread area -> global?

>>[Ning]: Not global yet. We deployed servers mainly on US and Europe.

how is geolocation distance computed?

>>[Ning]: We just decide which clients connect to which server based on client IP address. So, it is basically region-based and very coarse.

Figure 9 - also include where the servers were in the figure?  (like Figure 8)

>>[Ning]: Agree.

s/leeches/leechers/

would it be simpler to just assume PlanetLab Manager was part of the
text controller and not mention it explicitly?

>>[Ning]: PlanetLab Manager is not part of test controller. See different sections for their definitions.

"4G CPU" -> 4 CPU? (or, did you find 4-Ghz CPUs?)  If you found a VM
with 4 billion CPUs that were halfway-decent, we should chat :)

>>[Ning]: Good question:). It is actually assigned with 4 core from 16 core 1Ghz CPU.

For filesharing, why is there 480MB of download traffic in the INS
case but 430MB in the native case?

>>[Ning]: Because PlanetLab clients are not controlled by us, not all clients will finish downloading process. So for independent tests, there are different total download traffic.

Can an INS server always supply 94%, or only when there was a 1Gbps
NIC?  More specifically, does it supply 9.4Gbps with a 10Gbps NIC?

>>[Ning]: We did test on 100Mbps and 1Gbps NIC, and got same result of 94%.

it would be interesting to note what scaling issues you found passed
400 concurrent users at an INS server.

>>[Ning]: When we tried 450 concur users, 50 users didn't start downloading at the same time with other 400 users.

-Ning

---

From: Songhaibin <[email-masked]>
Date: Wed, 13 Jun 2012 09:29:38 +0000

Thanks to Rich Alimi for a very good review. Besides that, here are some detailed comments from myself.

In the abstract section, please do NOT refer to the working group. This is also applied to the first paragraph of Introduction.

In section 3, last paragraph, it mentioned "In our P2P live streaming example, the token is generated by INS client", I think it should be clear that the token is generated by the INS client that is sharing its data.

Section 4.2.1, for the batch request, we may change the wording "an application client may combine multiple requests in a single request" to "an application client may request a batch of data objects in a single request".

Change "Larger Data Object" to "Large Data Object", otherwise, what is it compared to?

Section 5.2, can you give the reference to Vuze messages to a more specific webpage instead of "www.vuze.com"?

Figure 5, it is better to make it upside down, with "end user" in the bottom, so as to be consistent with other figures.

Section 7.4, delete more spaces before "ALTO", "End" and "CP".  2G/2GB   10G/10GB

Section 8.2.2, could the authors clarify the reason behind the high network resource efficiency when compared to native P2P applications?

BR,
-Haibin