Re: [alto] WGLC: draft-ietf-alto-problem-statement-01

["Jan Seedorf" <[e-mail]>]

Dear Richard, ALTO folks,

we have discussed the comments received from Richard for the WGLC of "draft-ietf-alto-problem-statement-01" among the editors and addressed them accordingly. I have just submitted the new -02 version of the draft. For seeing how we addressed the comments please produce a diff from the -01 version and compare with the comments from Richard below.

Please check (by the end of next week, July 10th) that we addressed all comments and provide feedback on this list otherwise.

 - Jan

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of
> Y. Richard Yang
> Sent: Sonntag, 7. Juni 2009 06:18
> To: [e-mail]
> Subject: Re: [alto] WGLC: draft-ietf-alto-problem-statement-01
> 
> Hi Jan, Eric, Enrico, and Vijay,
> 
> Thanks for the work on the problem statement document!
> 
> Below are some comments for the version at
> (http://www.ietf.org/internet-drafts/draft-ietf-alto-problem-statement-
> 01.txt):
> 
> Richard
> 
> ==============
> There are a couple places where I marked with **. These are more
> important.
> 
> - Both abstract and Introduction have this sentence: "Peer-to-peer
>   applications, such as file sharing, real-time communication, and live
>   media streaming ..." It is clear that VoD P2P streaming is becoming
> much
>   more popular than live. For example, if you check PPLive/UUSee, you
> will
>   see a few hundres live streaming channels, but a lot more VoD
> channels.
>   How about changing the sentence to " such as file sharing, real-time
>   communications, live and on-demand media streaming ..."
> 
>   Another nit is the word "real-time communication". Is voice/video
>   conferencing more explicit?
> 
> - Abstract: "direct peer-to-peer connections". Is the word "direct"
> necessary?
> 
> - Abstract: "This document describes problems related to optimizing
>   traffic generated by peer-to-peer applications and associated issues
>   such optimizations raise in the use of network-layer information."
> 
>     This sentence is a bit long and may parse in different ways. For
>     example, for the first "problems", it is not clear the "problems"
> are
>     caused by not optimizing or optimizing in the wrong way. It may be
>     helpful to revise the sentence a bit.
> 
> ** Abstract: "may lead to suboptimal choices" and "to optimizing
> traffic";
>   in the text, it uses the word "best" in many places. I know this is
>   consistent with the working group name (this is a reason I do not
> like
>   the working group name :-( But on the other hand, the charter is
> trying
>   to achieve better than random, which may not be "optimizing", may be
>   suboptimal, and may not be the best. I feel that it is necessary to
> go
>   over the document to address this issue. What do you think?
> 
> - Page 1: "resources[WWW.wired.fuel]" need a space before [
> 
> - Section 1.1 first paragraph: "Different from the client/server
>   architecture, P2P applications ..." architecture and applications do
> not
>   match.  A suggestion is to either change architecture to applications
>   or applications to architecture.
> 
> - Section 1.1 second paragraph: "One advantage of P2P systems ..." This
>   time it uses the word systems. So we have P2P systems, P2P
> architecture,
>   and P2P applications. It may be necessary to make sure they are used
> in
>   a consistent way. I will not point out this later. I feel that the
> word
>   systems should be architecture here. What do you think?
> 
> - Section 1.1 second paragraph: "select among available instances": the
>   preceding sentence uses replicas not instances.
> 
> - Section 1.1 second paragraph: "deduce from empirical measurements".
> How
>   about "deduce from partial observations"?
> 
> - Section 1.1 second paragraph: "For example, one popular metric is an
>   estimation of round-trip time." to be consistent with the following
>   sentence, how about
> 
>     "For example, one peer selection algorithm is based
>     only on the measurements during initial connection establishment
> between
>     two peers. Since actual data transmission does not begin, the
> algorithm
>     measures only the round-trip time and cannot reliably deduce actual
>     throughput between the peers. A peer selection algorithm that
> simply
>     uses round-trip time may result in a sub-optimal choice of peers."
> 
> 
> - Section 1.1: "network operators or third parties can collect reliable
>   network information": reliable -> "more reliable"
> 
> - Section 1.1: "topology or instantaneous bandwidth available": do you
>   want to emphasize "instantaneous"? How about ->
> 
>   "topology and bandwidth"
> 
> - Section 1.1: "Normally, such information is rather "static", i.e.,
>   information which can change over time but on a much longer time
> scale
>   than information used for congestion control on the transport layer":
> 
>  ->
> 
>    "Normally, such information changes on a much longer time scale
>    than information used for congestion control on the transport layer"
> 
> - Section 1.1: "it would be possible to greatly increase application
>   performance, reduce congestion and optimize the overall traffic
> across
>   different networks"
> 
>   Do you want to use "would be"? I would remove "greatly".
> 
> 
> - Section 1.1: "presumably, both the application": before this, you
> always
>   say "applications", not a particular application.
> 
> - Section 1.1: "Thus, network operators have an incentive to provide,
>   either directly themselves or indirectly through a third party, such
>   information and applications have an incentive to use such
> information."
> 
>   ->
> 
>   "Thus, network operators have an incentive to provide, either
> directly
>   themselves or indirectly through a third party, such information;
>   applications have an incentive to use such information."
> 
> 
> - Section 1.1: "Section 3 introduces the problem.  Section 4 describes
>   some use cases where both P2P applications and network operators
> benefit
>   from a solution to such a problem." Missing Section 2.
> 
> - Section 1.1: "The papers [I-D.bonaventure-informed-path-selection]
> and
> 
>   [ACM.ispp2p] [WWW.p4p.overview] are ..."
> 
>   Change to "The papers [I-D.bonaventure-informed-path-selection],
>   [ACM.ispp2p], and [WWW.p4p.overview] present". How about move
>   [ACM.ispp2p] to be the first to make them alphabetical order?
> 
> * Section 1.2: "better-than-random": this keyword appeared here for the
>   first time. It may make sense to make it appear earlier, as it is a
> key
>   working group design decision.
> 
> - Section 1.2: "It is not easy to foresee how such solutions will
> perform
>   in the Internet.  A more accurate evaluation requires representative
>   data collected from real systems by a critical mass of users."
> 
>   -> P4P field trials are (relatively) large, real systems. How about
> 
>   change to:
> 
>   "It is not clear how such solutions will perform if deployed globally
> on
>    the Internet."
> 
> 
> - Section 2: The definitions of the terms depend on hybrid, but hybrid
> is not
>   defined. So some definitions read somehow strange.
> 
> - Section 2: it defines "Overlay Network", but it is used only at
> defining
>   Application Protocol. Do you really need it?
> 
> 
> - Section 2: "Resource Directory:  An entity that is logically separate
> from the
>       resource consumer that assists a resource consumer to identify a
>       set of resource providers.  Some P2P applications refer to the
>       resource directory as a P2P tracker."
> 
>   Only separated from consumer, not provider? How about DHT?
> 
> 
> ** Section 3: definition of Host Location Attribute: "or any
>   other localization attribute. I am not sure if it is necessary to
>   specify that it is a localization attribute, because it is not clear
>   what is localization. To some readers, localization may mean (e.g.,
>   in windows) language used in UI, etc. How about "or any other host
>   connectivity attribute"?
> 
> 
>   One issue I am considering is if the term Host Location Attribute
>   reflects our intention well, because it may include both location
>   (point on the topology) and other info such as bandwidth, customer
>   type etc. Unfortunately, we were not able to come up with a good
>   term. In P4P, we named it PID (provider ID, or partition ID) due to
>   lacking of a good term.
> 
> - Section 2: "The ALTO service gives guidance to a resource consumer
>   or resource directory about which resource provider(s) to select
>   in order to optimize the client's performance" change
>   "a resource consumer or resource directory" to "a resource consumer
>   and/or resource directory".
> 
> - Section 2: "ALTO Server:  A logical entity that provides interfaces
>   to query the ALTO service."
> 
>   ->
> 
>   "ALTO Server:  A logical entity that provides interfaces to the
>   queries to the ALTO service."
> 
> 
> - Section 2: "ALTO Client:  The logical entity that sends ALTO
>   queries.  Depending on the architecture of the application one may
>   embed it in the resource consumer or in the resource directory."
> 
>   Change "or" to "and/or".
> 
> 
> 
> * Section 2: "ALTO Response:  A message sent from an ALTO server
>   to an ALTO client, which contains guiding information from the
>   ALTO service."
> 
> 
>   The Response may not need to directly from an ALTO Server.
>   We are using cache and P2P redistribution. How about:
> 
>    "ALTO Response:  A message contains replies for an ALTO query."
> 
> - Section 2: the definitions of Local Traffic, Peering Traffic,
>   and Transit Traffic. I am not sure we need to define these terms.
>   I noticed that Transit Traffic is used once in this doc. But these
>   may not be stable terms. For example, there also can be the concepts
>   of last-mile traffic. I recommend removal.
> 
> - Section 2: "Provisioning Protocol:  A protocol used for populating
>   the ALTO server with topology-related information." There does not
>   appear to be a need to be so specific that it is only
>   topology-related information. How about just ALTO information?
> 
> - Section 2: Why introduce the term of "Inter-ALTO Server Protocol"?
>   It is not used in the document.
> 
> - Figure 1: How about not labeling the first entity only "topological
> information." It may also include policy information.
> 
> - Figure 1: Since you have introduced the terms already, why label
> Peers and Resource Directory, instead of the terms that you have
> already introduced, e.g., ALTO Clients?
> 
> - Section 3: "... do not benefit much from the above route-based
>   techniques" May not need to label "route-based techniques". Also,
>   it may cause discussions to say that applications cannot benefit.
>   How about change to "cannot directly use the aforementioned
> techniques"?
> 
> - Section 3: "Cooperating with external services aware of the network
>   topology could greatly optimize the traffic the P2P application
> generates."
>   Who cooperating?
> 
> - Section 3: "the logical target is not a host, but rather a resource
>   (e.g., a file or a media relay) that is often available ..." I am not
>   sure about the word "is often". How about just say "can be
> available"?
> 
> 
> 
> - Section 3: This sentence "Selection of the closest one -- or,
>   in general, the best from an overlay topological proximity -- has
> much
>   more impact on the overall traffic than the route followed". This
> sentence
>   hard to parse.
> 
> - Section 3: "Optimization of peer selection is particularly
>   important in the initial phase of the process." I am not sure if
> necessary
>   to emphasize "particularly important in the initial phase". A weaker
> statement
>   can be better.
> 
> - Section 3: "Consider a P2P protocol such as BitTorrent, where a
>   querying peer receives a list of candidate destinations where a
> resource
>   resides." This is not a correct description of BitTorrent.
> 
> - Section 4.1: "   File sharing applications allow users to search
>   for content shared by other users and download it." The word "it"
>   is not clear?
> 
> - Section 4.1: "Typically, search results consist of many instances of
>   the same file (or chunk of a file) available from multiple sources."
>   This is more an EDonkey model. BitTorrent is not this model.
> 
> - Section 4.2: "network location systems or often delegated to the
>   user himself": himself -> herself
> 
> - Section 4.3: "The goal of an ALTO solution is to help peers to find
>   the best sources and the best destinations for media flows they
>   receive and relay." Source has particular meaning in P2P streaming.
>   How about "The goal of an ALTO solution is to help a peer to find
>   effective communicating peers that exchange the media content"?
> 
> - Section 4.4: "In such systems, peers maintain addresses of other
> peers participating in the same DHT in a routing table, sorted
> according to specific criteria." A reader may get the impression
> of maintaining ALL other peers. How about "a peer maintains the
> addresses of a set of other peers participating in the same DHT
> in a routing table"?
> 
> - Section 4.4: "An ALTO solution will provide valuable information
> for DHT algorithms." I will not say "will". It is still a tricky
> question. How about replace "will" with "can"?
> 
> - Section 5.1: "Network operators.  Network operators usually have
>   full knowledge of the network they administer and are aware of
>   their network topology and transit and peering traffic policies."
> 
>   How about remove "transit and peering traffic policies"? There is
>   no need to limit to them.
> 
> - Section 5.1: "Likewise, there are other user communities that
>   expect a service that services P2P applications be itself a
>   distributed, possibly even a P2P, service." The wording needs change.
> 
>   How about "Likewise, there are other user communities to expect
>   that the ALTO service be a distributed service, possibly even based
>   on or integrating with a P2P service."?
> 
> - Section 5.4: "However, operators often consider such network
>   information to be confidential."
> 
> ->
> 
>   "However, operators often consider such network information to
>   be confidential to be revealed in details."
> 
> 
> - Section 5.5: "Caching is a common approach to optimizing
>   traffic generated by applications that require large data
>   transfers." How about remove "common"?
> 
>   Also, instead of say "large data transfers", which may be
>   interpreted as large files, how about "large amounts of data
> transfers"?
> 
> - Section 5.5: "Thus, the cache must use the same protocol
>   as the querying peer. Any cache solution for a given protocol
>   needs to present that same protocol to the client. Said differently,
>   each caching solution for a different protocol needs to implement
>   that specific protocol.  For this reason, one can only reasonably
>   expect caching solutions for the most popular protocols,
>   such as HTTP and BitTorrent."
> 
>   I presented the Data Locker concepts at last IRTF. It shows that
>   this may not need to be the case. It will be a long discussion.
>   How about shorten the preceding sentences to avoid debates?
> 
> 
> On Fri, 29 May 2009, 12:59pm -0700, Jon Peterson wrote:
> 
> 
> 
> >
> 
> > The chairs would like to declare a Working Group Last Call for
> > draft-ietf-alto-problem-statement-01, beginning Monday June 1st and
> ending
> > Monday June 15th.
> >
> > Please do review the latest version of the draft, and send any
> comments to
> > the list before the expiry of WGLC so we can get this document ready
> for the
> > IESG.
> >
> > Jon Peterson
> > NeuStar, Inc.
> >
> 
> 
> _______________________________________________
> alto mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/alto