Hi Vijay, Thank you for your response. Please see comments inline below. > -----Original Message----- > From: Vijay K. Gurbani [mailto:[EMAIL PROTECTED] > Sent: Friday, October 10, 2008 11:41 AM > To: Narayanan, Vidya > Cc: IESG IESG; ietf@ietf.org; [EMAIL PROTECTED] > Subject: Re: [p2pi] WG Review: Application-Layer Traffic > Optimization (alto) > > Narayanan, Vidya wrote: > > I am surprised to see that ALTO is being proposed for a WG > after the > > last BoF concluded with no consensus whatsoever. I think a > second BoF > > is more appropriate than a WG on the topic at this time. > That said, I > > do see the need for this work, although I have some comments on the > > current direction. > > Vidya: Thank you for the feedback. After analyzing your > points, it seems that the charter as written is already > conducive to the important points raised in your review of it > (i.e., we may already be in agreement.) > > More inline. > > > Overall, I think we should work with the notion of an ALTO "service" > > rather than specifically an ALTO "server". > > Great. I believe that is exactly what the charter does; the > charter talks in terms of an "ALTO service" at many places > (pedantically speaking, the term "ALTO service" occurs eight > times and the term "ALTO server" occurs six.) The ALTO "server" > mentioned in the charter refers to the *host* the client > finally queries (calling it a "peer" is ambiguous; if you > have a specific term to use here instead of "server", please > do let us know.) >
When we consider ALTO as a distributed service, there may not necessarily be "a" host that specifically resolves the ALTO queries. For instance, consider the case where ALTO is a service offered in an overlay. There may be peers publishing information about themselves on the overlay and other peers looking up such information. These are not necessarily client-server style communications. In fact, all that is important in this context is that the overlay acts as a rendezvous for sharing such information. Now, of course, that is one possible model. But, in order to allow for that and other models, I do want the charter to keep the focus on the service and not on a server. > > The ALTO service may be provided by a server, a cluster of > distributed > > servers or as a service in an overlay. Although some of > the charter > > wording talks about a "service" rather than a "server", there is > > enough mention of a "server" entity to imply a strict client-server > > protocol. > > The charter is not meant to imply a centralized architecture, > nor to rule out peer-to-peer implementations of it. The > charter simply mentions a "request/reply" protocol is needed. > Whether or not there is a cluster of ALTO servers or one > needs to be decided by the requirement analysis and > subsequent discussions in the WG. > > > As part of that, I think there are a couple of key things > that need to > > be addressed here: > > > > - A protocol that allows peers (or ALTO clients) to publish > > information about themselves as part of the ALTO service. > An example > > of such information may be the uplink/downlink bandwidth of > the peer. > > We have had discussions on the mailing list about this already. > Some people felt that providing uplink bandwidth would not be > a good idea for various reasons running from privacy concerns > to peers skewing traffic in favor of a high uplink bandwidth. > Others felt that even if a peers uplink bandwidth was not > provided, it could calculated nonetheless by other peers. > That is, there are degrees of disagreement here and > consequently, including a contentious point in the charter > would be counter- productive. > I'm afraid that would be a mistake. It actually doesn't matter if we don't agree today on the exact types of information that can be shared. It is important that we have a protocol that allows peers to publish ALTO related information. Having this protocol be extensible would allow for any type of information to be carried in it. So, I strongly believe we don't need a recharter to consider any information types - in fact, I'd be okay if this effort only took on the protocol and if all information types were to be registered through other means. That said, I'm not against taking on some subset of those types - I don't believe that should be the core focus of this work though. > > - The ability to register information types with IANA and extend > > these. > > Having a IANA registry for the information type carried in > the protocol is certainly a possibility the charter does not > rule out, no? > Well, it is a bit hard to say what the charter does not rule out - typically we try and do what the charter says we should do. However, before we get to the registry, we need to agree on the protocol components. In my view, there are two such components - the publish protocol mentioned above and the request/response protocol (actually, more generically, a lookup protocol) mentioned below. > > The request/response protocol should be a generic enough > container for > > any information that peers can provide and look for, plus > what may be > > available from service providers, etc. There may be some > guidelines > > on how such information types can be registered and we may > start with > > default ones. > > Exactly; this is what the charter is saying in the paragraph: > > - A document defining core request and response formats and > semantics to communicate network preferences to applications. > Since ALTO services may be run by entities with different level > of knowledge about the underlying network, such preferences > may have different representations. Initially the WG will > consider: IP ranges to prefer and to avoid, ranked lists of > the peers requested by the client, information about > topological proximity and approximate geographic locations. > Other usages will be considered as extensions to the charter > once the work for the initial services has been completed. > > We *are* starting with the default information; as other > information is required, we can extend the charter, right? Actually, I am saying that is exactly what is not needed. I don't see the information types as something this effort will necessarily nail down. We need to define interoperable semantics for the protocol - what gets carried in it may actually be registered as a type in the registry outside of this effort. The registry comes into picture for enabling this part. > Extending the charter is cheap -- it is a bureaucratic > process that will auto- matically happen if there are enough > interested parties willing to do the work and the work is > considered to be important enough. > I believe that the higher bar is ensuring that the initial > charter contains the right amount of work so that the WG can > finish it in an appropriate amount of time. > > >> The Working Group will design and specify an Application-Layer > >> Traffic Optimization (ALTO) service that will provide > applications > >> with information to perform better-than-random initial peer > >> selection. ALTO services may take different approaches at > balancing > >> factors including maximum bandwidth, minimum cross-domain > traffic, > >> lowest cost to the user, etc. The WG will consider the needs of > >> BitTorrent, tracker-less P2P, and other applications, such > as content > >> delivery networks (CDN) and mirror selection. > > > > What does the above sentence mean? If we are putting such a list > > together, we must also take into account needs from structured P2P > > overlays such as those being specified in P2PSIP. > > In P2PSIP, the amount of information being stored in the > overlay is small (a R-URI, on the order of tens of bytes.) > ALTO will not much help there. OTOH, ALTO will help > tremendously if in a P2PSIP network, there is a need to find > a peer that hosts the recording of a 2-hour conference call. > Nothing in the ALTO charter prevents this from happening as > it is specified today. > I would like us to think beyond applications we see today. Had TCP not been designed that way, we probably would have needed a redesign of it for HTTP :) I can envision video applications using the P2PSIP framework, for instance. In any event, I still don't have a good understanding of what it means to consider the needs of these various things - what does it mean to say that we'll consider the needs of BitTorrent/CDN, etc.? Could you maybe give me an example of what it means? > > Is this meant to allow for entities such as proxies to be > in the path? > > There's been quite a lot of discussion on this topic on the list. > Current consensus is to keep the architecture as simple as > possible and exclude at least initially support for > non-transparent intermediaries; if at some point we have > evidence of the need for it, the group will go through rechartering. > Okay. > > Earlier, it is mentioned that the requirements document > will determine > > the types of information that are useful for P2P > applications. Given > > that, it seems premature to conclude that the WG should > consider the > > above mentioned parameters. Also, as I mentioned earlier, > I think it > > is essential to keep the protocol and message formats > extensible and > > allow for exchange of any registered information type. > > The limit on what data to consider initially was suggested to > avoid the group to wander for years discussing any kind of > possible information; however, extensibility will be the key > principle in designing a protocol (for good design practices > rather than because it is written in the charter). > Again, as I wrote above, I think the information types are less important than the container for any such type in the protocol. > > Another question I have is about the assumptions around > expected peer > > addressing models. Some of the above seems to hint at IP addresses > > - is this an assumption already? > > No, the text says "ranked lists of the peers requested by the > client" exactly because we still don't know how they could be > identified. > Hmmm... Okay. Perhaps it would be good to say that some analysis is needed to determine how to identify the peers? Maybe this is something that needs to happen in the requirements phase. <snip> > >> > >> - Can the ALTO service technically provide that information? > >> - Is the ALTO service willing to obtain and divulge that > information? > >> - Is it information that a client will find useful? > > > > I'm not sure how useful it is for us to answer this question. The > > protocol we develop simply needs to be a container for any > information > > that has a registered type and fits a certain format. > > Sure, no disagreements here. However, the list of questions > that appears in the charter was suggested as a set of minimum > vetting points to ensure that the WG spent some thought > process on making an adequate determination on the importance > and use of an ALTO service. The list of questions does not > inhibit the protocol we develop in any way. > What I am saying is that it is not for us to determine the usefulness of a particular piece of information. As long as the peers or service providers are willing to share a piece of information, that can be consumed by other peers as they deem fit. So, I don't think we should consider ourselves the gatekeeper for the types of information shared. Best regards, Vidya _______________________________________________ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
