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

From: Zongning <[email-masked]>
Date: Thu, 14 Jun 2012 02:12:08 +0000

Hi, Haibin,

Thanks for your comments. Please see reply below.

> > -----Original Message-----
> > From: Songhaibin
> > Sent: Wednesday, June 13, 2012 5:30 PM
> > To: 'Richard Alimi'; [email-masked]
> > Subject: RE: [decade] WG Review of draft-ietf-decade-integration-example-03
> >
> > 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.

[Ning]: Agree.

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

[Ning]: Agree.

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

[Ning]: Agree.

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

[Ning]: Larger is compared to the typical existing P2P live streaming application.

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

[Ning]: OK, I will give better reference.

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

[Ning]: Agree.

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

[Ning]: OK.

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

[Ning]: OK, I will clarify this. One reason is that INS server can always server content to peers while in traditional P2P applications, peer have to finish downloading content before sharing with others.

> >
> > BR,
> > -Haibin
> >
> > > -----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.
> > >
> > > 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?
> > >   - if not at this time, is that planned for a future iteration of
> > > this draft (if not I'd suggest removing "at this time")
> > >
> > > ** Terminlogy
> > >
> > > add definition for "native application client"
> > >
> > > INS Service Provider
> > >   - does it deploy the entire INS system, or just some servers?
> > >
> > > INS Portal
> > >   - why simulated? what's a simulated portal?
> > >   - don't use 'portal' in order to define the term
> > >
> > > ** INS Client API
> > >
> > > define what a 'token' is (or provide a reference)
> > >
> > > 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?
> > >
> > > ** 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.
> > >
> > > 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?
> > >
> > > "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)."
> > >
> > > 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)
> > >
> > > "On the other hand, INS-enabled .." - remove "on the other hand"
> > >
> > > 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.
> > >
> > > 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.
> > >
> > > "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
> > >
> > > 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.)
> > >
> > > ** 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).
> > >
> > > Either explain why it is an "Azureous handshake" or replace it with
> > > just "handshake reply" or similar
> > >
> > > There seems to be a transition sentence missing before the details of
> > > Figure 4 are discussed.
> > >
> > > 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.
> > >
> > > ** 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 :)
> > >
> > > 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
> > >
> > > s/Architecture Design/Architecture/
> > >
> > > how does alto help CPs to upload files ot INS servers?
> > >
> > > 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.
> > >
> > > 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.
> > >
> > > 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.
> > >
> > > 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?
> > >
> > > How is "optimal" decided?
> > >
> > > ** Test Environment and Settings
> > >
> > > Avoid using the word "cloud". They are large sets of servers available for
> use.
> > >
> > > wild-spread area -> global?
> > >
> > > how is geolocation distance computed?
> > >
> > > Figure 9 - also include where the servers were in the figure?  (like Figure 8)
> > >
> > > s/leeches/leechers/
> > >
> > > would it be simpler to just assume PlanetLab Manager was part of the
> > > text controller and not mention it explicitly?
> > >
> > > "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 :)
> > >
> > > For filesharing, why is there 480MB of download traffic in the INS
> > > case but 430MB in the native case?
> > >
> > > 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?
> > >
> > > it would be interesting to note what scaling issues you found passed
> > > 400 concurrent users at an INS server.

---

From: Songhaibin <[email-masked]>
Date: Thu, 14 Jun 2012 05:59:45 +0000

Hi Ning,

> From: Zongning
> Sent: Thursday, June 14, 2012 10:12 AM
> To: Songhaibin
> Cc: [email-masked]; Richard Alimi

> [Ning]: OK, I will clarify this. One reason is that INS server can always server
> content to peers while in traditional P2P applications, peer have to finish
> downloading content before sharing with others.
 
A further explanation can be, by using INS server, a peer an immediately share the object to others before it download the object to the end host, unlike the native P2P, a peer has to download the object, and then it can begin to share with others.

BR,
-Haibin

---

From: Zongning <[email-masked]>
Date: Thu, 14 Jun 2012 06:04:39 +0000

Thanks, Haibin,

I want to call for more comments from the list and produce a new revision soon.

-Ning

> Sent: Thursday, June 14, 2012 2:00 PM
> To: Zongning
> A further explanation can be, by using INS server, a peer an immediately share
> the object to others before it download the object to the end host, unlike the
> native P2P, a peer has to download the object, and then it can begin to share
> with others.
> 
> BR,
> -Haibin
> 
> 
> 
> 
>  >