Hi Martin, Given that Lisa is looking for solutions, I almost wish I have a solution thought out :) But, I don't. At the moment, I'm just saying that ALTO should be beyond *only* dealing with information from service providers. Peer selection is absolutely beyond just catering to ISP interests; peers have a vested interest in it - that said, information that peers are willing to share towards this is very valuable. We need to have interoperable ways of making that available and I do think this fits nicely with the ALTO objectives - going back to the root of the objectives, it is about peer selection and not just about ISP network utilization interests.
Just to be clear, I am not downplaying the importance of ISP network utilization aspects - it is one component of the puzzle and there are others we need to consider along with it for a more complete picture. Thanks, Vidya > -----Original Message----- > From: Martin Stiemerling [mailto:[EMAIL PROTECTED] > Sent: Monday, October 13, 2008 8:03 AM > To: Narayanan, Vidya; Vijay K. Gurbani > Cc: [EMAIL PROTECTED]; IESG IESG; ietf@ietf.org > Subject: RE: [p2pi] WG Review: Application-Layer Traffic > Optimization (alto) > > Hi Vidja, all, > > I believe that the charter is narrow and broad enough to > cover the topic of ALTO, i.e., the charter is not limiting > the solution space. > > However, when reading your comments, it sounds that you have > a very specific solution in mind which is probably not > covered by the current charter. > > [...] > > > > > > > > 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. > > You probably have a publish/subscribe system in mind for p2p overlays. > I assume this is not in scope of ALTO. > > > 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. > > Is the IETF anyhow standardizing services? I don't see this. > > [...] > > > > > > > > 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 > > I'm afraid that carrying up/downlink capacity of the peer's > local link is a complete waste of resource, as this is not > indicating something. For instance, a peer may have a > relatively huge uplink but on a shared medium, i.e., a medium > which might be shared by hundreds of other hosts/traffic. > So what does this information express? > > > 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 > > The question is, whether the roots of ALTO are actually > intended to carry any type of information? The main idea is > to carry information to optimize traffic, e.g., decreasing > cross ISP traffic. > > > 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. > > It is good to see your ideas but doesn't this go beyond a > charter discussion, as your are discussing a solution? > > This comes back to my initial comment about discussing a > specific solution, and we haven't yet reached the times to > discuss a solution - at least not here. > > Martin > > > [EMAIL PROTECTED] > > NEC Laboratories Europe - Network Research Division NEC > Europe Limited | Registered Office: NEC House, 1 Victoria > Road, London W3 6BL | Registered in England 2832014 > _______________________________________________ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
