RE: [p2pi] WG Review: Application-Layer Traffic Optimization (alto)
Hi Vidya, Other usages will be considered as extensions to the charter once the work for the initial services has been completed. I think we should delete the sentence above. While it may seem redundant, I don't see anything wrong with that. It just means we may have a narrow scope now, but we will think about new extensions once we are done. I actually believe that if we designed the protocols right, we don't need a recharter to carry other types of information - we can allow registration of new information types for ALTO beyond the life of the WG. Agreed in principle, and I don't think anyone on the list would disagree we should design an extensible protocol/solution. The need for such wording is, imo, for the practical purpose of scoping a working group. Any new type of info the wg considers must be carefully evaluated for the impacts and such. The current charter just says we will focus on the protocol and certain types of info. Note that it doesn't say the protocol must NOT be extensible. (If it does, then we should change that.) ... I read the list below somewhat differently. These are not for relative importance of the information, but kind of a min bar for what we want to do. While some may need re-wording, the intent is fine, IMO. I'm not so sure. Basically, it is a question of what usage these are evaluated based on. Let's take a couple of examples. Whether the ALTO service can provide a piece of information is dependent on various factors - some things are dependent on whether such information is available from other places today (e.g., topology or ASNs, etc.); I think this set of questions has been written with that mindset. But, there are others (e.g., quality, reputation, semantic expertise, etc.) that are totally based on the type of the p2p overlay and whether clients can provide that information. Similarly, whether some information is useful to a client is totally contextual to the application as well. Once again, I don't think we are that far apart, and in a sense, what is missing is really a note that the answers to these questions largely depend on the type of info they apply to. Although I still think these are fair questions to ask on the info under consideration. I would totally agree that these need re-wording for clarity. Let's wait for the next round of charter update. :-) Thanks, yushun - 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? - Can a client get that information without excessive privacy concerns(e.g. by sending large lists of peers)? - Is it information that a client cannot find easily some other way? After these criteria are met, the generality of the data will be considered for prioritizing standardization work, for example the number of operators and clients that are likely to be able to provide or use that particular data. The above again gets into our evaluation of what is important based on what we know today and is limiting. This point does need some clarification and rewording. Thanks, yushun ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: [p2pi] WG Review: Application-Layer Traffic Optimization (alto)
Hi Vidya, Comments inline. (I've only preserved the points I have comments on. Others are fine with me.) Thanks, yushun -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Narayanan, Vidya Sent: Wednesday, October 22, 2008 5:51 PM -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of IESG Secretary Sent: Monday, October 06, 2008 1:36 PM ... A significant part of the Internet traffic today is generated by peer-to-peer (P2P) applications used for file sharing, real-time communications, and live media streaming. P2P applications exchange large amounts of data, often uploading as much as downloading. In contrast to client/server architectures, P2P applications often have a selection of peers and must choose. Add: Peer selection is also a problem that has many different applications in p2p systems - e.g., identifying the best peer to download content from, identifying the best super peer to contact in a system, using the best relay for NAT traversal, identifying the best next hop for a query based on several criteria (e.g., quality, reputation, semantic expertise, etc.), etc. I actually think the proposed addition is somewhat redundant, and could easily lead into ratholes on what are the metrics for best and whether it is even possible to get the best. The current charter tries to avoid that by saying better-than- random selection gating mostly on getting better performance and lowering the costs (as two examples). Also, what's the best depends heavily on whom you ask. ISP's notions of best may not align with those of the end users. I am fine with the examples (targets for selections), but let's try to avoid the debates on best again. ... yet applications have at best incomplete information about the topology of the network. s/incomplete information about the topology of the network/incomplete information to help the selection, e.g., topology of the network. I'm neutral to this. I think the intention is to narrow the initial scope to avoid confusion w/ TANA. The charter does leave the door open to future re-chartering/work. ... Other usages will be considered as extensions to the charter once the work for the initial services has been completed. I think we should delete the sentence above. While it may seem redundant, I don't see anything wrong with that. It just means we may have a narrow scope now, but we will think about new extensions once we are done. ... When the WG considers standardizing information that the ALTO server could provide, the following criteria are important to ensure real feasibility. In the context of standardization, I don't think we should be trying to evaluate the importance of any information. The idea for us should be to standardize mechanisms to exchange peer selection related information. The value of the actual information exchanged is very contextual and not for general evaluation. I read the list below somewhat differently. These are not for relative importance of the information, but kind of a min bar for what we want to do. While some may need re-wording, the intent is fine, IMO. - 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? - Can a client get that information without excessive privacy concerns(e.g. by sending large lists of peers)? - Is it information that a client cannot find easily some other way? After these criteria are met, the generality of the data will be considered for prioritizing standardization work, for example the number of operators and clients that are likely to be able to provide or use that particular data. The above again gets into our evaluation of what is important based on what we know today and is limiting. This point does need some clarification and rewording. Thanks, yushun ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: [p2pi] WG Review: Application-Layer Traffic Optimization (alto)
Hi Yushun, snip Add: Peer selection is also a problem that has many different applications in p2p systems - e.g., identifying the best peer to download content from, identifying the best super peer to contact in a system, using the best relay for NAT traversal, identifying the best next hop for a query based on several criteria (e.g., quality, reputation, semantic expertise, etc.), etc. I actually think the proposed addition is somewhat redundant, and could easily lead into ratholes on what are the metrics for best and whether it is even possible to get the best. The current charter tries to avoid that by saying better-than- random selection gating mostly on getting better performance and lowering the costs (as two examples). Also, what's the best depends heavily on whom you ask. ISP's notions of best may not align with those of the end users. I am fine with the examples (targets for selections), but let's try to avoid the debates on best again. I'm fine with that. I agree that best is a relative word and causes confusion at best :) snip Other usages will be considered as extensions to the charter once the work for the initial services has been completed. I think we should delete the sentence above. While it may seem redundant, I don't see anything wrong with that. It just means we may have a narrow scope now, but we will think about new extensions once we are done. I actually believe that if we designed the protocols right, we don't need a recharter to carry other types of information - we can allow registration of new information types for ALTO beyond the life of the WG. snip I read the list below somewhat differently. These are not for relative importance of the information, but kind of a min bar for what we want to do. While some may need re-wording, the intent is fine, IMO. I'm not so sure. Basically, it is a question of what usage these are evaluated based on. Let's take a couple of examples. Whether the ALTO service can provide a piece of information is dependent on various factors - some things are dependent on whether such information is available from other places today (e.g., topology or ASNs, etc.); I think this set of questions has been written with that mindset. But, there are others (e.g., quality, reputation, semantic expertise, etc.) that are totally based on the type of the p2p overlay and whether clients can provide that information. Similarly, whether some information is useful to a client is totally contextual to the application as well. - 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? - Can a client get that information without excessive privacy concerns(e.g. by sending large lists of peers)? - Is it information that a client cannot find easily some other way? After these criteria are met, the generality of the data will be considered for prioritizing standardization work, for example the number of operators and clients that are likely to be able to provide or use that particular data. The above again gets into our evaluation of what is important based on what we know today and is limiting. This point does need some clarification and rewording. Thanks, yushun ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [p2pi] WG Review: Application-Layer Traffic Optimization (alto)
Hey, stupid thought... Could you do proximity based on who's your DNS resolver? Do a few name lookups: one to register YOU as using YOUR DNS resolver to the remote coordinator, and one to get who are other peers using the same resolver? An ugly, UGLY hack, but it might be interesting to think about. Has anyone done this already? ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [p2pi] WG Review: Application-Layer Traffic Optimization (alto)
On Oct 13, 2008, at 5:23 AM, Pekka Savola wrote: I believe this work could be useful and would provide an improvement over existing p2p usage and traffic management. I also believe that an ALTO WG should be formed and would like to contribute to a solutions draft. The current requirements and problem statement are scoped rather narrowly around a solution in mind. This is recognized by the BoF chairs and the authors, and I would be interested in contributing to these documents so that they more generally applicable. A solutions draft should be a start to help think about the solutions space. The starting point for the solutions idea is described at http://www.ietf.org/mail-archive/web/p2pi/current/msg00508.html This is intended to answer Lisa's call for example candidate solutions to better understand the space. The solution will emphasize simplicity, privacy, and, correspondingly, clear understanding of what information is given to whom. The question at hand is not consensus on the requirements or even problem statement, but just the charter. I believe the charter has by now been crafted with the intention of covering the known cases. One small concern that I didn't previously raise because I just noticed it is that the charter still says A request/response protocol for querying the ALTO service to obtain information useful for peer selection, and a format for requests and responses. This starts to specify an architecture. While the known candidate solutions seem to fit, I would prefer clarifying that it's not request/ response protocol or data format that's the point, but the information. One way of doing so would to to rephrase as follows: A complete mechanisms that enables clients to learn from the ALTO service information useful for peer selection. Again, this should go forward. Thanks, -- Stas -- Stanislav Shalunov ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [p2pi] WG Review: Application-Layer Traffic Optimization (alto)
Narayanan, Vidya wrote: With respect to process, I think this one takes the cake among abominations. Having been at the IETF long enough and having participated in several BoFs, I'm quite familiar with RFC2418 and the process. Here we have an effort that started with a closed/gated workshop outside the IETF, Actually, this is not so. The workshop *was* sponsored by IETF; the RAI area, to be more precise (please see http://www.ietf.org/mail-archive/web/ietf-announce/current/msg04758.html). The initial notes from the workshop are also archived at http://www.ietf.org/mail-archive/web/p2pi/current/msg00025.html. Thanks, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA) Email: [EMAIL PROTECTED],bell-labs.com,acm.org} WWW: http://www.alcatel-lucent.com/bell-labs ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: [p2pi] WG Review: Application-Layer Traffic Optimization (alto)
Just catching up on some of the traffic in this list. I think the openness of the ALTO effort is highlighted by the fact that currently this is the busiest out of the 8 IETF lists I subscribe to... In the IETF vigorous mailing activity is a better signal than any other of the level of interest in a topic and thus the level of involvement in the wider community. Regarding the workshop, it was pretty open. It was widely advertised, albeit at short notice. Seemingly the majority of submissions were accepted (impressive given the short time available in the workshop). Copies of all the documents and presentations are available and the output was to convince several ADs of the need for new work at the IETF (hence two BoFs and probably eventually 2 WGs). As to including your point b). Lisa correctly pointed out that the main reason the BoF in Dublin failed was a lack of focus in ALTO. What you are proposing sounds like an interesting work item for a different WG or more likely an IRTF RG given you admit you don't know of any proposals out there currently. However adding it to ALTO would just scupper the next BoF and thus kill the work completely. I think Lars summed up the ideal aims of ALTO best: The intent here isn't that ALTO would pick the globally optimal peers for you, the intent is that it'll help an application reach a good set of peers a bit more quickly. In other words ALTO will be great so long as it is lightweight and has sensible ambitions! Toby Toby Moncaster, [EMAIL PROTECTED] Networks Research Centre, BT B54/70 Adastral Park, Ipswich, IP53RE, UK. +44 1473 648734 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Enrico Marocco Sent: 19 October 2008 18:23 To: Narayanan, Vidya Cc: [EMAIL PROTECTED]; ietf@ietf.org Subject: Re: [p2pi] WG Review: Application-Layer Traffic Optimization (alto) Narayanan, Vidya wrote: With respect to process, I think this one takes the cake among abominations. Having been at the IETF long enough and having participated in several BoFs, I'm quite familiar with RFC2418 and the process. Here we have an effort that started with a closed/gated workshop outside the IETF, Actually, this is not so. The workshop *was* sponsored by IETF; the RAI area, to be more precise (please see http://www.ietf.org/mail-archive/web/ietf-announce/current/msg 04758.html). My point is that this was a closed effort - it was not a meeting that was open to all for attendence. The fact that the RAI ADs decided to do this doesn't automatically make it IETF sponsored. Not to mention that the topics covered by this workshop or the scope of it was not really open to discussion at the IETF. All of this makes it sqauarely an effort outside the IETF and let's not try to pretend it was somehow as open as other IETF efforts. This is simply not true. The P2PI workshop was open to all (including via jabber) and its main goal, as I read it, was to put together people interested in addressing the issues P2P traffic poses for Internet infrastructures. After that, two BOFs had been organized, in the very same way BOFs are usually organized: some people get together, draft a problem statement, set a mailing list up, add an entry in the BOF page, involve the community, discuss, ask a meeting slot during an official meeting, discuss, draft a charter, discuss, discuss... In a word, as described in draft-narten-successful-bof. Unfortunately it isn't possible to measure how much open an effort is, but if you accept the number of contributions and contributors (as per 3978) as a somewhat meaningful indicator, for ALTO you can count 561 messages posted on the list by 67 different authors (from 6/9, when the first BOF was announced, to 9/30, when LC began) and 6 I-Ds co-signed by 19 people (Authors and Contributors). Now, if you consider that no one of such contributors have complained about feeling excluded and instead all have agreed to move forward with the proposed charter (in fact they have contributed to the proposed charter), I wouldn't say that it has been a closed effort. -- Ciao, Enrico ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [p2pi] WG Review: Application-Layer Traffic Optimization (alto)
I'd like to second this - the P2Pi workshop was open and well publicized. While I've not been involved in the IETF for a long time, I heard about it through several channels, submitted a paper, presented, etc. Of course, I can't prove that someone else didn't feel excluded, but from my perspective the process has certainly appeared open. Does anyone else feel like this process hasn't been open to all interested parties? - Laird Popkin, CTO, Pando Networks mobile: 646/465-0570 - Original Message - From: Enrico Marocco [EMAIL PROTECTED] To: Vidya Narayanan [EMAIL PROTECTED] Cc: [EMAIL PROTECTED], ietf@ietf.org Sent: Sunday, October 19, 2008 1:23:09 PM (GMT-0500) America/New_York Subject: Re: [p2pi] WG Review: Application-Layer Traffic Optimization (alto) Narayanan, Vidya wrote: With respect to process, I think this one takes the cake among abominations. Having been at the IETF long enough and having participated in several BoFs, I'm quite familiar with RFC2418 and the process. Here we have an effort that started with a closed/gated workshop outside the IETF, Actually, this is not so. The workshop *was* sponsored by IETF; the RAI area, to be more precise (please see http://www.ietf.org/mail-archive/web/ietf-announce/current/msg 04758.html). My point is that this was a closed effort - it was not a meeting that was open to all for attendence. The fact that the RAI ADs decided to do this doesn't automatically make it IETF sponsored. Not to mention that the topics covered by this workshop or the scope of it was not really open to discussion at the IETF. All of this makes it sqauarely an effort outside the IETF and let's not try to pretend it was somehow as open as other IETF efforts. This is simply not true. The P2PI workshop was open to all (including via jabber) and its main goal, as I read it, was to put together people interested in addressing the issues P2P traffic poses for Internet infrastructures. After that, two BOFs had been organized, in the very same way BOFs are usually organized: some people get together, draft a problem statement, set a mailing list up, add an entry in the BOF page, involve the community, discuss, ask a meeting slot during an official meeting, discuss, draft a charter, discuss, discuss... In a word, as described in draft-narten-successful-bof. Unfortunately it isn't possible to measure how much open an effort is, but if you accept the number of contributions and contributors (as per 3978) as a somewhat meaningful indicator, for ALTO you can count 561 messages posted on the list by 67 different authors (from 6/9, when the first BOF was announced, to 9/30, when LC began) and 6 I-Ds co-signed by 19 people (Authors and Contributors). Now, if you consider that no one of such contributors have complained about feeling excluded and instead all have agreed to move forward with the proposed charter (in fact they have contributed to the proposed charter), I wouldn't say that it has been a closed effort. -- Ciao, Enrico ___ p2pi mailing list [EMAIL PROTECTED] https://www.ietf.org/mailman/listinfo/p2pi ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [p2pi] WG Review: Application-Layer Traffic Optimization (alto)
Narayanan, Vidya wrote: With respect to process, I think this one takes the cake among abominations. Having been at the IETF long enough and having participated in several BoFs, I'm quite familiar with RFC2418 and the process. Here we have an effort that started with a closed/gated workshop outside the IETF, Actually, this is not so. The workshop *was* sponsored by IETF; the RAI area, to be more precise (please see http://www.ietf.org/mail-archive/web/ietf-announce/current/msg 04758.html). My point is that this was a closed effort - it was not a meeting that was open to all for attendence. The fact that the RAI ADs decided to do this doesn't automatically make it IETF sponsored. Not to mention that the topics covered by this workshop or the scope of it was not really open to discussion at the IETF. All of this makes it sqauarely an effort outside the IETF and let's not try to pretend it was somehow as open as other IETF efforts. This is simply not true. The P2PI workshop was open to all (including via jabber) and its main goal, as I read it, was to put together people interested in addressing the issues P2P traffic poses for Internet infrastructures. After that, two BOFs had been organized, in the very same way BOFs are usually organized: some people get together, draft a problem statement, set a mailing list up, add an entry in the BOF page, involve the community, discuss, ask a meeting slot during an official meeting, discuss, draft a charter, discuss, discuss... In a word, as described in draft-narten-successful-bof. Unfortunately it isn't possible to measure how much open an effort is, but if you accept the number of contributions and contributors (as per 3978) as a somewhat meaningful indicator, for ALTO you can count 561 messages posted on the list by 67 different authors (from 6/9, when the first BOF was announced, to 9/30, when LC began) and 6 I-Ds co-signed by 19 people (Authors and Contributors). Now, if you consider that no one of such contributors have complained about feeling excluded and instead all have agreed to move forward with the proposed charter (in fact they have contributed to the proposed charter), I wouldn't say that it has been a closed effort. -- Ciao, Enrico smime.p7s Description: S/MIME Cryptographic Signature ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: [p2pi] WG Review: Application-Layer Traffic Optimization (alto)
Vidya, This would be a big mistake on our part. b) is not a research problem and it is very much related to the same problem being solved in ALTO. Personally, I can see that there is value in b): information that peers decide to make available about themselves to other peers for this purpose. Your example below was information about whether a client is on a wireless network. In an earlier thread, I had suggested that clients may want to reveal their available access bandwidth in a similar fashion; see http://www.ietf.org/mail-archive/web/p2pi/current/msg00658.html. So even as an ISP person, I can see where you are coming from. But if I am interpreting RFC 2418 correctly http://tools.ietf.org/html/rfc2418, it is not sufficient to decide if b) is a worthy IETF activity, but that there are enough participants working on b) for an IETF effort to be successful. Quoting from parts of RFC 2418 section 2.1: Is there sufficient interest within the IETF in the working group's topic with enough people willing to expend the effort to produce the desired result (e.g., a protocol specification)? Is there enough expertise within the IETF in the working group's topic, and are those people interested in contributing in the working group? Does a base of interested consumers (end-users) appear to exist for the planned work? Consumer interest can be measured by participation of end-users within the IETF process, as well as by less direct means. You said: Given that Lisa is looking for solutions, I almost wish I have a solution thought out :) But, I don't. Are you volunteering to work on requirements and/or solutions for b)? Would others? (I may be interested and supportive in the future, although right now I am predictably focused on activities related to a).) If there isn't a quorum to work on b) right now, this could be revisited in the future with a re-charter of ALTO, when such a quorum does exist. If there is a quorum, it would be helpful to hear about it. -- Rich -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Narayanan, Vidya Sent: Wednesday, October 15, 2008 7:48 PM To: Lisa Dusseault; Vijay K. Gurbani Cc: [EMAIL PROTECTED]; ietf@ietf.org Subject: Re: [p2pi] WG Review: Application-Layer Traffic Optimization (alto) Lisa, There's plenty of work to do in a). My recommendation based on estimation of appropriate scope as well as an estimation of the consensus here, would be to do that first -- to have a charter that is scoped to (a). Then the possibilities for (b) include working in the P2P research group, individual submissions, and /or a new BoF/WG. Another option would be a future charter update for ALTO if it's successful and there's consensus for it to be the basis for (b). This would be a big mistake on our part. b) is not a research problem and it is very much related to the same problem being solved in ALTO. Letting each p2p application come up with its own mechanism of doing b) only kills the interoperability and extensibility. We keep talking about scope creep here, but, we seem to miss something critical. By not keeping the related problems together in producing solutions, we are only increasing the number of different mechanisms that are going to be needed in future to provide this one service - I cannot understand why that is a good thing. Without allowing for b), I think information that a) gives you can be more or less useless in some circumstances. Let me provide some additional context here. One of the pieces of information that is important to allow wireless devices to participate in p2p networks is the basic fact that a given node is wireless. This may place some fundamentally different criteria on path selection decisions that cannot be deduced simply with topology information. For any forward looking work we do at the IETF, we must stop designing just for wired (and stationary) devices. These are the designs that tend to look horrible when adapted to the wireless (and mobile) world and I seriously hope that that is not where we are headed with this work. Best regards, Vidya Lisa ___ p2pi mailing list [EMAIL PROTECTED] https://www.ietf.org/mailman/listinfo/p2pi ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: [p2pi] WG Review: Application-Layer Traffic Optimization (alto)
To answer your question about participation, I can definitely volunteer to work on the requirements and solution for this effort. We will try to produce a draft explaining the problem and need for peer participation in ALTO by the deadline for Minneapolis. With respect to process, I think this one takes the cake among abominations. Having been at the IETF long enough and having participated in several BoFs, I'm quite familiar with RFC2418 and the process. Here we have an effort that started with a closed/gated workshop outside the IETF, was brought into the IETF as a BoF in RAI that ended in an inconclusive manner and transitioned now into a WG proposal for APP with little to no explanation to the wider audience on the rationale. So, it may be best if we didn't really get into the process discussion with this effort. I'm just hoping that at this stage, the ADs are going to hear all opinions and also use technical judgment on the relative points that are being made. Best regards, Vidya -Original Message- From: Woundy, Richard [mailto:[EMAIL PROTECTED] Sent: Thursday, October 16, 2008 12:34 PM To: Narayanan, Vidya; Lisa Dusseault; Vijay K. Gurbani Cc: [EMAIL PROTECTED]; ietf@ietf.org Subject: RE: [p2pi] WG Review: Application-Layer Traffic Optimization (alto) Vidya, This would be a big mistake on our part. b) is not a research problem and it is very much related to the same problem being solved in ALTO. Personally, I can see that there is value in b): information that peers decide to make available about themselves to other peers for this purpose. Your example below was information about whether a client is on a wireless network. In an earlier thread, I had suggested that clients may want to reveal their available access bandwidth in a similar fashion; see http://www.ietf.org/mail-archive/web/p2pi/current/msg00658.ht ml. So even as an ISP person, I can see where you are coming from. But if I am interpreting RFC 2418 correctly http://tools.ietf.org/html/rfc2418, it is not sufficient to decide if b) is a worthy IETF activity, but that there are enough participants working on b) for an IETF effort to be successful. Quoting from parts of RFC 2418 section 2.1: Is there sufficient interest within the IETF in the working group's topic with enough people willing to expend the effort to produce the desired result (e.g., a protocol specification)? Is there enough expertise within the IETF in the working group's topic, and are those people interested in contributing in the working group? Does a base of interested consumers (end-users) appear to exist for the planned work? Consumer interest can be measured by participation of end-users within the IETF process, as well as by less direct means. You said: Given that Lisa is looking for solutions, I almost wish I have a solution thought out :) But, I don't. Are you volunteering to work on requirements and/or solutions for b)? Would others? (I may be interested and supportive in the future, although right now I am predictably focused on activities related to a).) If there isn't a quorum to work on b) right now, this could be revisited in the future with a re-charter of ALTO, when such a quorum does exist. If there is a quorum, it would be helpful to hear about it. -- Rich -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Narayanan, Vidya Sent: Wednesday, October 15, 2008 7:48 PM To: Lisa Dusseault; Vijay K. Gurbani Cc: [EMAIL PROTECTED]; ietf@ietf.org Subject: Re: [p2pi] WG Review: Application-Layer Traffic Optimization (alto) Lisa, There's plenty of work to do in a). My recommendation based on estimation of appropriate scope as well as an estimation of the consensus here, would be to do that first -- to have a charter that is scoped to (a). Then the possibilities for (b) include working in the P2P research group, individual submissions, and /or a new BoF/WG. Another option would be a future charter update for ALTO if it's successful and there's consensus for it to be the basis for (b). This would be a big mistake on our part. b) is not a research problem and it is very much related to the same problem being solved in ALTO. Letting each p2p application come up with its own mechanism of doing b) only kills the interoperability and extensibility. We keep talking about scope creep here, but, we seem to miss something critical. By not keeping the related problems together in producing solutions, we are only increasing the number of different mechanisms that are going to be needed in future to provide this one service - I cannot understand why that is a good thing. Without allowing for b), I think information that a) gives you can be more or less useless in some circumstances. Let me provide some additional context here. One of the pieces of information that is important to allow wireless
RE: [p2pi] WG Review: Application-Layer Traffic Optimization (alto)
-Original Message- From: Vijay K. Gurbani [mailto:[EMAIL PROTECTED] Sent: Friday, October 17, 2008 2:32 PM To: Narayanan, Vidya Cc: [EMAIL PROTECTED]; ietf@ietf.org Subject: Re: [p2pi] WG Review: Application-Layer Traffic Optimization (alto) Narayanan, Vidya wrote: With respect to process, I think this one takes the cake among abominations. Having been at the IETF long enough and having participated in several BoFs, I'm quite familiar with RFC2418 and the process. Here we have an effort that started with a closed/gated workshop outside the IETF, Actually, this is not so. The workshop *was* sponsored by IETF; the RAI area, to be more precise (please see http://www.ietf.org/mail-archive/web/ietf-announce/current/msg 04758.html). My point is that this was a closed effort - it was not a meeting that was open to all for attendence. The fact that the RAI ADs decided to do this doesn't automatically make it IETF sponsored. Not to mention that the topics covered by this workshop or the scope of it was not really open to discussion at the IETF. All of this makes it sqauarely an effort outside the IETF and let's not try to pretend it was somehow as open as other IETF efforts. But, let's get past that itself and focus on how to make the best of the effort going forward. Regards, Vidya The initial notes from the workshop are also archived at http://www.ietf.org/mail-archive/web/p2pi/current/msg00025.html. Thanks, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA) Email: [EMAIL PROTECTED],bell-labs.com,acm.org} WWW: http://www.alcatel-lucent.com/bell-labs ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [p2pi] WG Review: Application-Layer Traffic Optimization (alto)
I agree that (a) is where ALTO should focus. To elaborate a bit, (a) can only be provided by the ISP by definition (nobody else really knows the ISP's network and business policies), while (b) and (c) are, if I understand you correctly, both currently being done using internal communications within the p2p applications using their existing protocols. IMO, standardizing (a) is very important because it allows ISPs to provide information to applications that that they can't otherwise get (e.g. ISP policies) or can only derive in complex, inaccurate ways (e.g. using hop counts to approximate network locality). - Laird Popkin, CTO, Pando Networks mobile: 646/465-0570 - Original Message - From: Lisa Dusseault [EMAIL PROTECTED] To: Vijay K. Gurbani [EMAIL PROTECTED] Cc: [EMAIL PROTECTED], ietf@ietf.org Sent: Wednesday, October 15, 2008 2:39:57 PM (GMT-0500) America/New_York Subject: Re: [p2pi] WG Review: Application-Layer Traffic Optimization (alto) On Wed, Oct 15, 2008 at 8:20 AM, Vijay K. Gurbani [EMAIL PROTECTED] wrote: Narayanan, Vidya wrote: Peer selection is important to ISPs from a network utilization perspective and to peers themselves from a performance perspective. That automatically makes peer selection a function of multiple aspects - a) information that some service providers may decide to share with the peers, b) information that peers decide to make available about themselves to other peers for this purpose, and, c) any measurements peers may do on their own. The current charter definition (and from what I can tell based on your response below) only seems to allow for a). I would agree that c) is out of scope of ALTO and something that peers can additionally do. I strongly believe that b) should be part of the ALTO work. I believe that incorporating (b) expands the charter quite a bit, whereas the consensus since the first BoF was for narrowing it down. I will also note that the feedback expressed on the list does not appear to view ALTO as a peer description protocol. To be sure, I am not unsympathetic to (b), it seems like a great problem to solve, it's just that ALTO may not be the best place to solve this problem. In the end, maybe the ADs can decide a way forward. There's plenty of work to do in a). My recommendation based on estimation of appropriate scope as well as an estimation of the consensus here, would be to do that first -- to have a charter that is scoped to (a). Then the possibilities for (b) include working in the P2P research group, individual submissions, and /or a new BoF/WG. Another option would be a future charter update for ALTO if it's successful and there's consensus for it to be the basis for (b). Lisa ___ p2pi mailing list [EMAIL PROTECTED] https://www.ietf.org/mailman/listinfo/p2pi___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [p2pi] WG Review: Application-Layer Traffic Optimization (alto)
Citing one of the responses from Vijay on Oct 13 For instance, it is not ALTO that gets to decide which peer is hosting which content and what the contributions of that peer to the overlay are. However, it is ALTO's job to provide information to a querying peer allowing it to determine wisely where it will download the content from. I agree ALTO does not determine content location but given a set of content locations by an application would provide a ranked order of good peers to download this from. However, a fundamental issue to consider is that simply using ISP information is not enough for a querying peer to determine wisely what to do. Unless there is a performance perspective to the goodness of peers, is there a real incentive for applications to adopt looking up ALTO since they anyway need to do a bunch of performance measurements. Applications typically may be happy simply saturating download bandwidth and not much else. Providing more information in ALTO could be a path to incentivising the users of the service. What this more information is should be up for debate. We should also consider the more general question of when we are designing something for peer selection we are only designing a small piece of an information plane for the Internet. In this context, it may be useful to have information that can be aggregated across various applications and simply because specific BitTorrent clients may implement some such mechanisms does not mean that is a good design choice to leave it out of ALTO. An information plane (see the U Wash IPlane paper) of some kind may be something to consider given that we seem to solving only one part of the puzzle. Instead of each application building their own proprietary and application-specific information plane which is redundant and wasteful, such an information plane could potentially be something ALTO provides and can be reused across a wide range of services. Thanks, Saumitra Das ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [p2pi] WG Review: Application-Layer Traffic Optimization (alto)
On Tue, Oct 14, 2008 at 10:55 AM, Nicholas Weaver [EMAIL PROTECTED] wrote: On Oct 14, 2008, at 7:40 AM, Lars Eggert wrote: FYI, there's at least one more proposal in this space: the Ono stuff from Northwestern (http://www.aqualab.cs.northwestern.edu/projects/Ono.html). There was a paper at SIGCOMM this year, and their system has the interesting feature that it simply freeloads of Akamai's DNS entries in order to determine who's close to whom. No ALTO boxes needed. Basically, this is freeloading on the akamai DNS infrastructure to create a topology oracle: which nodes are close in terms of network topology as a common proxy for bandwidth. It doesn't need ALTO boxes only because someone else has colleced that information, and that there is a separation between the query replying infrastructure (through DNS) and the measurement infrastructure. However, it does bring up a good point: DNS games allow the ability to divorce the measurement infrastructure from the reporting infrastructure, and to create a reporting infrastructure that can always work both with and without ISP cooperation. This is a very good comment on the architecture on ALTO box. Just to clarify on a risk of building an Internet infrastructure based on a hack of using the Akamai DNS infrastructure to create a topology oracle. You may already know it, but some others may not. So I would like to point it out. Akamai DNS redirection considers not only topology, but also Akamai's own server state, and Akamai's own redirection policy. To illustrate this, consider a simple example where Akamai temporarily (e.g., during maintenance, or misconfiguration, or under attack, or whatever reason) redirects users from distant geographic locations to the same set of servers. This may result in these users being deemed close together when in fact they are not. This is not limited to Akamai. DNS redirection typically considers not only topology, but also the state and policy of whoever controls it. ___ p2pi mailing list [EMAIL PROTECTED] https://www.ietf.org/mailman/listinfo/p2pi ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [p2pi] WG Review: Application-Layer Traffic Optimization (alto)
On Oct 14, 2008, at 1:07 PM, Ye WANG wrote: On Tue, Oct 14, 2008 at 10:55 AM, Nicholas Weaver [EMAIL PROTECTED] wrote: On Oct 14, 2008, at 7:40 AM, Lars Eggert wrote: FYI, there's at least one more proposal in this space: the Ono stuff from Northwestern (http://www.aqualab.cs.northwestern.edu/projects/Ono.html ). There was a paper at SIGCOMM this year, and their system has the interesting feature that it simply freeloads of Akamai's DNS entries in order to determine who's close to whom. No ALTO boxes needed. Basically, this is freeloading on the akamai DNS infrastructure to create a topology oracle: which nodes are close in terms of network topology as a common proxy for bandwidth. It doesn't need ALTO boxes only because someone else has colleced that information, and that there is a separation between the query replying infrastructure (through DNS) and the measurement infrastructure. However, it does bring up a good point: DNS games allow the ability to divorce the measurement infrastructure from the reporting infrastructure, and to create a reporting infrastructure that can always work both with and without ISP cooperation. This is a very good comment on the architecture on ALTO box. Just to clarify on a risk of building an Internet infrastructure based on a hack of using the Akamai DNS infrastructure to create a topology oracle. You may already know it, but some others may not. So I would like to point it out. Akamai DNS redirection considers not only topology, but also Akamai's own server state, and Akamai's own redirection policy. To illustrate this, consider a simple example where Akamai temporarily (e.g., during maintenance, or misconfiguration, or under attack, or whatever reason) redirects users from distant geographic locations to the same set of servers. This may result in these users being deemed close together when in fact they are not. This is not limited to Akamai. DNS redirection typically considers not only topology, but also the state and policy of whoever controls it. To be fair, I don't think anyone was recommending Ono, merely noting it was one that has been proposed and so should be included in the list. While a cute systems hack that might make something work better today, it's pretty clearly not a good interoperable and long-term solution. Phil ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: [p2pi] WG Review: Application-Layer Traffic Optimization (alto)
-Original Message- From: Laird Popkin [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 14, 2008 10:48 PM To: Song Haibin Subject: Re: [p2pi] WG Review: Application-Layer Traffic Optimization (alto) I'd like to second this, and also make sure that the relationship between ALTO and the application is clear. From the application perspective, ALTO is a source of useful guidance (i.e. network topology and cost model) that can help the p2p network find good peers to connect. But once peers are exchanging data, the p2p network/protocol (and TCP) pretty much takes over, because those protocols address the actual throughput between peers, real-time congestion, etc., that are not addressed by ALTO. I should also make clear that ALTO does not (and cannot) control the p2p network. Generally ALTO guidance should provide better than average peer connections (which is certainly what we saw in the P4P field tests), so the p2p networks will be motivated to use ALTO guidance when they can because it's in their interests to do so. But there will always be cases that are exceptions. For example, if a p2p network is getting fantastic data delivery between two peers, it is highly likely to keep using that connection no matter what ALTO says. And, on the flip side, if the ALTO-recommended peer connections aren't providing the data needed, the p2p network will use other peers as data sources. And, of course, p2p networks must continue to operate where ALTO guidance is unavailable. :-) Yes, actually I have the same thought with you. BR Song Haibin - Laird Popkin, CTO, Pando Networks mobile: 646/465-0570 - Original Message - From: Song Haibin [EMAIL PROTECTED] To: Vijay K. Gurbani [EMAIL PROTECTED], [EMAIL PROTECTED] Cc: [EMAIL PROTECTED], IESG IESG [EMAIL PROTECTED], ietf@ietf.org Sent: Tuesday, October 14, 2008 4:29:30 AM (GMT-0500) America/New_York Subject: Re: [p2pi] WG Review: Application-Layer Traffic Optimization (alto) Hi Vijay, Narayanan, Vidya wrote: communications. In fact, all that is important in this context is that the overlay acts as a rendezvous for sharing such information. I think the disconnect we may be having is that you view ALTO as a peer description protocol; it is not. Other protocols like BitTorrent, for example, are more suited to this, and they do exactly what you want. In a BitTorrent overlay (swarm), the overlay knows exactly which peer is contributing which content, which peer has which chunks, the download/upload ratio, the time the peer joined the swarm, whether the peer is choked or unchoked, whether the peer has a public port, etc. ALTO is not out to replace BitTorrent. What ALTO is providing are better strategies for peer selection. For instance, it is not ALTO that gets to decide which peer is hosting which content and what the contributions of that peer to the overlay are. However, it is ALTO's job to provide information to a querying peer allowing it to determine wisely where it will download the content from. Totally agree. 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 far, no one on the list has proposed that ALTO be a peer description and publication protocol. So based on the discussion we have had since (essentially the workshop in) May 2008 on the p2pi list, I would hesitate to add in the charter something that participants have not expressed any preference for (i.e., a deliverable on peers publishing their information.) IMHO, not every type of information can be carried in the ALTO protocol, but only network policy and topology related (e.g. peer preference) information is allowed. I don't think we are designing BitTorrent here. Regards! Song Haibin ___ p2pi mailing list [EMAIL PROTECTED] https://www.ietf.org/mailman/listinfo/p2pi ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [p2pi] WG Review: Application-Layer Traffic Optimization (alto)
Narayanan, Vidya wrote: Hi Vijay, I am not at all talking about reinventing what BitTorrent can do or even remotely about any actual p2p application itself. I am only talking about peer selection. However, I think there is a critical difference between what I view as contributing to peer selection and what the current proposed charter does. Vidya: Thank you for your response. I think we are converging to the crucial difference in this thread. This is a good thing. More inline. Peer selection is important to ISPs from a network utilization perspective and to peers themselves from a performance perspective. That automatically makes peer selection a function of multiple aspects - a) information that some service providers may decide to share with the peers, b) information that peers decide to make available about themselves to other peers for this purpose, and, c) any measurements peers may do on their own. The current charter definition (and from what I can tell based on your response below) only seems to allow for a). I would agree that c) is out of scope of ALTO and something that peers can additionally do. I strongly believe that b) should be part of the ALTO work. I believe that incorporating (b) expands the charter quite a bit, whereas the consensus since the first BoF was for narrowing it down. I will also note that the feedback expressed on the list does not appear to view ALTO as a peer description protocol. To be sure, I am not unsympathetic to (b), it seems like a great problem to solve, it's just that ALTO may not be the best place to solve this problem. In the end, maybe the ADs can decide a way forward. This functionality itself is application agnostic and requires an interoperable solution for it to be beneficial. This has nothing to do with content itself; it is purely about sharing information that helps with peer selection. Protocols like BitTorrent already contain elements such that the peers know enough about other peers that the overlay is functioning. The information that BitTorrent (and other P2P overlays) do not have is topology and policies. This is where ALTO is urged to fill a crucial gap, at least initially. Since the IETF/MIT workshop, the problem outlined for what has become ALTO has been how to choose the peers wisely. We (i.e., the BoF/list participants) have been diligent to note that ALTO is not completely dependent on service providers; third parties can run ALTO servers as well; and these servers can use ad-hoc techniques like Ono (which was discussed yesterday on the list) or some form of Internet Coordinate Systems to derive a topology. We have also been diligent to note that ALTO is an additional service provided to an overlay; the overlay will continue to function without it (albeit in a bit of a sub-optimal manner.) We have also noted given a choice between a service provider run ALTO server and a third party ALTO server, that peers will naturally gravitate towards the ALTO server that provides them the best information over a long period of time. In other words, we have covered substantial grounds since the IETF/MIT workshop and the Dublin BoF based on the premise of the problem as the group has understood it. Thanks, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA) Email: [EMAIL PROTECTED],bell-labs.com,acm.org} WWW: http://www.alcatel-lucent.com/bell-labs ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [p2pi] WG Review: Application-Layer Traffic Optimization (alto)
On Wed, Oct 15, 2008 at 8:20 AM, Vijay K. Gurbani [EMAIL PROTECTED]wrote: Narayanan, Vidya wrote: Peer selection is important to ISPs from a network utilization perspective and to peers themselves from a performance perspective. That automatically makes peer selection a function of multiple aspects - a) information that some service providers may decide to share with the peers, b) information that peers decide to make available about themselves to other peers for this purpose, and, c) any measurements peers may do on their own. The current charter definition (and from what I can tell based on your response below) only seems to allow for a). I would agree that c) is out of scope of ALTO and something that peers can additionally do. I strongly believe that b) should be part of the ALTO work. I believe that incorporating (b) expands the charter quite a bit, whereas the consensus since the first BoF was for narrowing it down. I will also note that the feedback expressed on the list does not appear to view ALTO as a peer description protocol. To be sure, I am not unsympathetic to (b), it seems like a great problem to solve, it's just that ALTO may not be the best place to solve this problem. In the end, maybe the ADs can decide a way forward. There's plenty of work to do in a). My recommendation based on estimation of appropriate scope as well as an estimation of the consensus here, would be to do that first -- to have a charter that is scoped to (a). Then the possibilities for (b) include working in the P2P research group, individual submissions, and /or a new BoF/WG. Another option would be a future charter update for ALTO if it's successful and there's consensus for it to be the basis for (b). Lisa ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: [p2pi] WG Review: Application-Layer Traffic Optimization (alto)
Lisa, There's plenty of work to do in a). My recommendation based on estimation of appropriate scope as well as an estimation of the consensus here, would be to do that first -- to have a charter that is scoped to (a). Then the possibilities for (b) include working in the P2P research group, individual submissions, and /or a new BoF/WG. Another option would be a future charter update for ALTO if it's successful and there's consensus for it to be the basis for (b). This would be a big mistake on our part. b) is not a research problem and it is very much related to the same problem being solved in ALTO. Letting each p2p application come up with its own mechanism of doing b) only kills the interoperability and extensibility. We keep talking about scope creep here, but, we seem to miss something critical. By not keeping the related problems together in producing solutions, we are only increasing the number of different mechanisms that are going to be needed in future to provide this one service - I cannot understand why that is a good thing. Without allowing for b), I think information that a) gives you can be more or less useless in some circumstances. Let me provide some additional context here. One of the pieces of information that is important to allow wireless devices to participate in p2p networks is the basic fact that a given node is wireless. This may place some fundamentally different criteria on path selection decisions that cannot be deduced simply with topology information. For any forward looking work we do at the IETF, we must stop designing just for wired (and stationary) devices. These are the designs that tend to look horrible when adapted to the wireless (and mobile) world and I seriously hope that that is not where we are headed with this work. Best regards, Vidya Lisa ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [p2pi] WG Review: Application-Layer Traffic Optimization (alto)
On 2008-10-11, at 4:27, ext Enrico Marocco wrote: Lakshminath Dondeti wrote: It's difficult to write a charter without actually designing the solution. This is an interesting opinion. May I translate that to mean that there is already a solution in the minds of the people who wrote the charter? Nope. Who has been following the p2pi list for the last five months probably knows that there are three different approaches (solutions?) floating around: the sorting oracle (described in a SIGCOMM paper authored by folks from TU-Berlin, a variant of which is IDIPS), P4P (soon to be published as I-D and, IIRC, described in another SIGCOMM paper), and Stanislav's proposal (discussed in Dublin and on the list: http://www.ietf.org/mail-archive/web/p2pi/current/msg00508.html). Who wrote the charter had all those approaches clear in mind and took special care that none of them got ruled out. FYI, there's at least one more proposal in this space: the Ono stuff from Northwestern (http://www.aqualab.cs.northwestern.edu/projects/Ono.html ). There was a paper at SIGCOMM this year, and their system has the interesting feature that it simply freeloads of Akamai's DNS entries in order to determine who's close to whom. No ALTO boxes needed. Lars ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [p2pi] WG Review: Application-Layer Traffic Optimization (alto)
I'd like to second this, and also make sure that the relationship between ALTO and the application is clear. From the application perspective, ALTO is a source of useful guidance (i.e. network topology and cost model) that can help the p2p network find good peers to connect. But once peers are exchanging data, the p2p network/protocol (and TCP) pretty much takes over, because those protocols address the actual throughput between peers, real-time congestion, etc., that are not addressed by ALTO. I should also make clear that ALTO does not (and cannot) control the p2p network. Generally ALTO guidance should provide better than average peer connections (which is certainly what we saw in the P4P field tests), so the p2p networks will be motivated to use ALTO guidance when they can because it's in their interests to do so. But there will always be cases that are exceptions. For example, if a p2p network is getting fantastic data delivery between two peers, it is highly likely to keep using that connection no matter what ALTO says. And, on the flip side, if the ALTO-recommended peer connections aren't providing the data needed, the p2p network will use other peers as data sources. And, of course, p2p networks must continue to operate where ALTO guidance is unavailable. :-) - Laird Popkin, CTO, Pando Networks mobile: 646/465-0570 - Original Message - From: Song Haibin [EMAIL PROTECTED] To: Vijay K. Gurbani [EMAIL PROTECTED], [EMAIL PROTECTED] Cc: [EMAIL PROTECTED], IESG IESG [EMAIL PROTECTED], ietf@ietf.org Sent: Tuesday, October 14, 2008 4:29:30 AM (GMT-0500) America/New_York Subject: Re: [p2pi] WG Review: Application-Layer Traffic Optimization (alto) Hi Vijay, Narayanan, Vidya wrote: communications. In fact, all that is important in this context is that the overlay acts as a rendezvous for sharing such information. I think the disconnect we may be having is that you view ALTO as a peer description protocol; it is not. Other protocols like BitTorrent, for example, are more suited to this, and they do exactly what you want. In a BitTorrent overlay (swarm), the overlay knows exactly which peer is contributing which content, which peer has which chunks, the download/upload ratio, the time the peer joined the swarm, whether the peer is choked or unchoked, whether the peer has a public port, etc. ALTO is not out to replace BitTorrent. What ALTO is providing are better strategies for peer selection. For instance, it is not ALTO that gets to decide which peer is hosting which content and what the contributions of that peer to the overlay are. However, it is ALTO's job to provide information to a querying peer allowing it to determine wisely where it will download the content from. Totally agree. 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 far, no one on the list has proposed that ALTO be a peer description and publication protocol. So based on the discussion we have had since (essentially the workshop in) May 2008 on the p2pi list, I would hesitate to add in the charter something that participants have not expressed any preference for (i.e., a deliverable on peers publishing their information.) IMHO, not every type of information can be carried in the ALTO protocol, but only network policy and topology related (e.g. peer preference) information is allowed. I don't think we are designing BitTorrent here. Regards! Song Haibin ___ p2pi mailing list [EMAIL PROTECTED] https://www.ietf.org/mailman/listinfo/p2pi ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [p2pi] WG Review: Application-Layer Traffic Optimization (alto)
Lars Eggert wrote: FYI, there's at least one more proposal in this space: the Ono stuff from Northwestern (http://www.aqualab.cs.northwestern.edu/projects/Ono.html). There was a paper at SIGCOMM this year, and their system has the interesting feature that it simply freeloads of Akamai's DNS entries in order to determine who's close to whom. No ALTO boxes needed. Since you mentioned DNS as a proximity tool, I thought I'd go slightly awry and point out a bit of work I did a while back that, while not at itself at the application level, did try to address some application layer optimizations concerns that we had when I was working on binding video clients to video services. The main idea was that neither hop count, asn-path length, ICMP-Echo time, DNS answer time, nor TCP-connect-time are very good indicators of internet proximity for the purposes of applications that are going to make different kinds of demands and need different levels of service. And because such proximity questions are likely to be asked frequently, the cost of asking the question, and the delay incurred in asking that question, ought to be low. So what I did was to try to blend the notions of potential bandwidth and packet size dynamics (from the old integrated services work) with some ideas from the old multicast mtrace protocol. What I came up, and it was far, far from complete, was something that needed to live inside the router infrastructure, although not on any fast-path part of any router. I called the thing the Fast Path Characterization Protocol. (The name may be misleading, the implementation was intended to find a path quickly, *not* that it would sit in any router fast-path switching logic.) So, here it is, 8+ years old: http://www.cavebear.com/archive/fpcp/fpcp-sept-19-2000.html --karl-- ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [p2pi] WG Review: Application-Layer Traffic Optimization (alto)
On Oct 14, 2008, at 7:40 AM, Lars Eggert wrote: FYI, there's at least one more proposal in this space: the Ono stuff from Northwestern (http://www.aqualab.cs.northwestern.edu/projects/Ono.html ). There was a paper at SIGCOMM this year, and their system has the interesting feature that it simply freeloads of Akamai's DNS entries in order to determine who's close to whom. No ALTO boxes needed. Basically, this is freeloading on the akamai DNS infrastructure to create a topology oracle: which nodes are close in terms of network topology as a common proxy for bandwidth. It doesn't need ALTO boxes only because someone else has colleced that information, and that there is a separation between the query replying infrastructure (through DNS) and the measurement infrastructure. However, it does bring up a good point: DNS games allow the ability to divorce the measurement infrastructure from the reporting infrastructure, and to create a reporting infrastructure that can always work both with and without ISP cooperation. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: [p2pi] WG Review: Application-Layer Traffic Optimization (alto)
Hi Vijay, Narayanan, Vidya wrote: communications. In fact, all that is important in this context is that the overlay acts as a rendezvous for sharing such information. I think the disconnect we may be having is that you view ALTO as a peer description protocol; it is not. Other protocols like BitTorrent, for example, are more suited to this, and they do exactly what you want. In a BitTorrent overlay (swarm), the overlay knows exactly which peer is contributing which content, which peer has which chunks, the download/upload ratio, the time the peer joined the swarm, whether the peer is choked or unchoked, whether the peer has a public port, etc. ALTO is not out to replace BitTorrent. What ALTO is providing are better strategies for peer selection. For instance, it is not ALTO that gets to decide which peer is hosting which content and what the contributions of that peer to the overlay are. However, it is ALTO's job to provide information to a querying peer allowing it to determine wisely where it will download the content from. Totally agree. 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 far, no one on the list has proposed that ALTO be a peer description and publication protocol. So based on the discussion we have had since (essentially the workshop in) May 2008 on the p2pi list, I would hesitate to add in the charter something that participants have not expressed any preference for (i.e., a deliverable on peers publishing their information.) IMHO, not every type of information can be carried in the ALTO protocol, but only network policy and topology related (e.g. peer preference) information is allowed. I don't think we are designing BitTorrent here. Regards! Song Haibin ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: [p2pi] WG Review: Application-Layer Traffic Optimization (alto)
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
RE: [p2pi] WG Review: Application-Layer Traffic Optimization (alto)
Hi Vijay, I am not at all talking about reinventing what BitTorrent can do or even remotely about any actual p2p application itself. I am only talking about peer selection. However, I think there is a critical difference between what I view as contributing to peer selection and what the current proposed charter does. Peer selection is important to ISPs from a network utilization perspective and to peers themselves from a performance perspective. That automatically makes peer selection a function of multiple aspects - a) information that some service providers may decide to share with the peers, b) information that peers decide to make available about themselves to other peers for this purpose, and, c) any measurements peers may do on their own. The current charter definition (and from what I can tell based on your response below) only seems to allow for a). I would agree that c) is out of scope of ALTO and something that peers can additionally do. I strongly believe that b) should be part of the ALTO work. This functionality itself is application agnostic and requires an interoperable solution for it to be beneficial. This has nothing to do with content itself; it is purely about sharing information that helps with peer selection. Lastly, as long as this framework is made available, information can be shared among peers on an overlay in a distributed fashion and/or provided by a service provider host. Best regards, Vidya -Original Message- From: Vijay K. Gurbani [mailto:[EMAIL PROTECTED] Sent: Monday, October 13, 2008 8:50 AM To: Narayanan, Vidya Cc: IESG IESG; ietf@ietf.org; [EMAIL PROTECTED] Subject: Re: [p2pi] WG Review: Application-Layer Traffic Optimization (alto) Vidya: Thank you for your response and your time in helping define the work. More inline. Narayanan, Vidya wrote: 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. I think the disconnect we may be having is that you view ALTO as a peer description protocol; it is not. Other protocols like BitTorrent, for example, are more suited to this, and they do exactly what you want. In a BitTorrent overlay (swarm), the overlay knows exactly which peer is contributing which content, which peer has which chunks, the download/upload ratio, the time the peer joined the swarm, whether the peer is choked or unchoked, whether the peer has a public port, etc. ALTO is not out to replace BitTorrent. What ALTO is providing are better strategies for peer selection. For instance, it is not ALTO that gets to decide which peer is hosting which content and what the contributions of that peer to the overlay are. However, it is ALTO's job to provide information to a querying peer allowing it to determine wisely where it will download the content from. 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 far, no one on the list has proposed that ALTO be a peer description and publication protocol. So based on the discussion we have had since (essentially the workshop in) May 2008 on the p2pi list, I would hesitate to add in the charter something that participants have not expressed any preference for (i.e., a deliverable on peers publishing their information.) 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. I am confused; I thought earlier you were trying to make the case that ALTO should provide even more specific information that needs to be published? In the end, we do agree on that any protocol be extensible. Whether that is extensible through a registry-like mechanism or other means remains to be discussed in the WG, right? 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 :) Protocols evolve, networks evolve. I am sure we were prescient when we designed TCP such that HTTP could simply use it. However, other realities of evolution did force us to design SCTP, for instance. But regardless, the point is that we should be general, and we are; but we have to do this while drawing a fine line
Re: [p2pi] WG Review: Application-Layer Traffic Optimization (alto)
Lakshminath Dondeti wrote: Hi Enrico, Vijay, Thank you for the summary of what transpired after the Dublin meeting. I appreciate you taking the time. Lakshminath: No problem. Thank you for your time and effort on this. My reading at the BoF was that there were some concerns about this work being done in haste without clearly understanding what it is that we want to do and what it is that we need to do to address this particular problem space (there were even suggestions to move some of the work to the IRTF). And since the BoF, much has changed to narrow the scope of the charter down to more manageable pieces as well as establish a channel with IRTF to move certain aspects of the work there (as the timeline in my previous email indicated.) My perception and my understanding of some of the dissenting opinions was that some of those need to be worked out before creating a working group. But I believe that we have done exactly that: the list has been busy since Dublin on attempts to move the work forward in a manner that is conducive to all participants. Some of the disagreements here in this thread now, and the intent of some of the folks to whitewash the issues raised do seem troublesome. I sincerely do not believe that we are trying to whitewash any issues here. It would seem an awful waste of time of the ADs, IRTF chair and list participants to engage in detailed discussions since the Dublin BoF if that were indeed the case. Thanks, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA) Email: [EMAIL PROTECTED],bell-labs.com,acm.org} WWW: http://www.alcatel-lucent.com/bell-labs ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
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.) 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. - 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? 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? 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
Re: [p2pi] WG Review: Application-Layer Traffic Optimization (alto)
On a related note, I'd like to make sure that you guys know that, as we discussed in Dublin, the P4P Working Group is in the process of documenting the P4P protocol as used in our field tests, which we would like to offer to the ALTO group as input into the ALTO process. Our hope is to have this ready for the next IETF meeting. - Laird Popkin, CTO, Pando Networks mobile: 646/465-0570 - Original Message - From: Lisa Dusseault [EMAIL PROTECTED] To: Lakshminath Dondeti [EMAIL PROTECTED] Cc: [EMAIL PROTECTED], IESG IESG [EMAIL PROTECTED], ietf@ietf.org Sent: Friday, October 10, 2008 3:21:02 PM (GMT-0500) America/New_York Subject: Re: [p2pi] WG Review: Application-Layer Traffic Optimization (alto) Lakshminath and Vidya, Vijay, Enrico and Stefano have said what I was going to say (e.g. below) -- as sponsoring AD for this charter I've been following the WG discussion, working with the rest of the IESG, and talking to people to confirm that there's better consensus on the list, even if there was confusion at the BOF. This IETF Last Call is also part of confirming whether there's now consensus. It's difficult to write a charter without actually designing the solution. What would help with the charter, even now, is for people to write up proposals for the solution -- ideally in the form of Internet-Drafts. I haven't yet selected chairs for the WG, so as you can imagine editors and authors aren't yet selected. It would be most excellent to see some individual proposals before a committee gets their hands on them :) Lisa On Fri, Oct 10, 2008 at 11:36 AM, Vijay K. Gurbani [EMAIL PROTECTED] wrote: ... And since the BoF, much has changed to narrow the scope of the charter down to more manageable pieces as well as establish a channel with IRTF to move certain aspects of the work there (as the timeline in my previous email indicated.) Lakshminath Dondeti wrote: My perception and my understanding of some of the dissenting opinions was that some of those need to be worked out before creating a working group. But I believe that we have done exactly that: the list has been busy since Dublin on attempts to move the work forward in a manner that is conducive to all participants. ___ p2pi mailing list [EMAIL PROTECTED] https://www.ietf.org/mailman/listinfo/p2pi___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [p2pi] WG Review: Application-Layer Traffic Optimization (alto)
Marshall Eubanks wrote: I support this moving forward. My reading of the room in Dublin was that there was serious support for this and certainly a critical mass to move forward. Marshall: Thank you for your review. More inline. Some comments in the charter below. This document clearly needs some more work. As a overall comment, I think it is premature to discuss ALTO servers and would keep the charter focused on describing the ALTO service. In an earlier reply to Vidya I note that the charter does indeed predominantly refer to ALTO services over ALTO server. Having said that, if I did not convince you through that argument, then we can leave the s/ALTO server/ALTO service discussion on the table. I do not see consensus at this moment as to a central service solution versus a distributed solution. Agreed. s/choose/choose the best peer or peers to exchange data with/ Unfortunately, in the Dublin BoF charter, we did state best peer (we had termed it optimal peer). This was one reason for the negative hums in the BoF because people have differing notion of what an optimal (or best) peer is. Thus, we reverted to the non-confrontational use of the phrase that you now see in the charter. - A request/response protocol for querying the ALTO service to obtain information useful for peer selection, and a format for requests and responses. The WG does not require intermediaries between the ALTO This is strange wording, as WG themselves are not protocols. More fundamentally, is this a requirement? No. We had some list discussion on whether or not to include intermediaries, but the resolution of that discussion appeared to be no (please see the few emails around the following link: http://www.ietf.org/mail-archive/web/p2pi/current/msg00635.html). - Can the ALTO service technically provide that information? I think that what is meant here is Can the ALTO service realistically discover that information? OK. - Is the ALTO service willing to obtain and divulge that information? Do computers have free will? AI notwithstanding ;-) But point taken; we can attempt a reword (if you have any suggestions, please throw them our way.) After these criteria are met, the generality of the data will be What is meant by the generality of the data ? considered for prioritizing standardization work, for example the Hmmm ... since we are talking about prioritizing, maybe what is meant is importance -- as in importance of the service -- may be a better fit. Comments? number of operators and clients that are likely to be able to provide or use that particular data. In any case, this WG will not propose standards on how congestion is signaled, remediated, or avoided, and Does this mean that congestion is not an issue to consider ? It is, but not in ALTO. That will be part of TANA. If the closest peer to me was totally congested and had no available bandwidth, isn't that something that I would want to know ? will not deal with information representing instantaneous network state. What is meant by information representing instantaneous network state ? Isn't this a protocol to share information about the state of the network ? Or is this an attempt to separate network topology from network performance ? But should network performance also be an issue ? By and large, it has been the case that that instantaneous network characteristics -- like current link usage, congestion, etc. -- are not be part of ALTO; they will be part of TANA. Hence, congestion control was deemed out of scope. What is an Internet coordinate system? Things like IDMaps, GNP, Vivaldi, etc. Should we define this term in the charter? Thanks, Marshall. - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA) Email: [EMAIL PROTECTED],bell-labs.com,acm.org} WWW: http://www.alcatel-lucent.com/bell-labs ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
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
RE: [p2pi] WG Review: Application-Layer Traffic Optimization (alto)
Dear Lakshminath, I left Dublin thinking, out of the p2pi efforts, TANA will be a WG (there was strong consensus and agreement on the problem space and what needs to be done) and ALTO may have another BoF. As of today, there is a WG proposal on the table for ALTO and in a different area from where we started; TANA is on the BoF wiki. Next, my experiences in the past on BoFs that did not have consensus have been dramatically different from what is happening on ALTO. The IESG has really even refused to allow another BoF much less directly started creating a working group. So, it makes me wonder whether the rules have recently been changed or whether they are selectively applied. I am not an IETF veteran, but from my experience it is perfectly ok for post-BoF discussions to happen on the mailing list and for these discussions to resolve some of the controversial issues at the BoF. I think this is was happened with ALTO. I also think that the IESG has been following the discussions on the mailing list and the WG Review is in fact a reaction to the agreement which has been found on the mailing list regarding the disagreements from the BoF. Just my two cents ... - Jan -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Lakshminath Dondeti Sent: Saturday, October 11, 2008 12:10 AM To: Lisa Dusseault Cc: [EMAIL PROTECTED]; IESG IESG; ietf@ietf.org Subject: Re: [p2pi] WG Review: Application-Layer Traffic Optimization (alto) On 10/10/2008 12:21 PM, Lisa Dusseault wrote: Lakshminath and Vidya, Vijay, Enrico and Stefano have said what I was going to say (e.g. below) -- as sponsoring AD for this charter I've been following the WG discussion, working with the rest of the IESG, and talking to people to confirm that there's better consensus on the list, even if there was confusion at the BOF. This IETF Last Call is also part of confirming whether there's now consensus. Hi Lisa, My concern can be put in really simple terms. We have some really very confusing processes and we seem to add to the confusion and not make things simpler. I left Dublin thinking, out of the p2pi efforts, TANA will be a WG (there was strong consensus and agreement on the problem space and what needs to be done) and ALTO may have another BoF. As of today, there is a WG proposal on the table for ALTO and in a different area from where we started; TANA is on the BoF wiki. Next, my experiences in the past on BoFs that did not have consensus have been dramatically different from what is happening on ALTO. The IESG has really even refused to allow another BoF much less directly started creating a working group. So, it makes me wonder whether the rules have recently been changed or whether they are selectively applied. I am also confused by your use of the word consensus; you say that you've talked to people to confirm that there's better consensus on the list, but also say that the charter review is also part of the consensus process. Shouldn't there be a call for consensus? It's difficult to write a charter without actually designing the solution. This is an interesting opinion. May I translate that to mean that there is already a solution in the minds of the people who wrote the charter? Why then would we bother with the proposed requirements effort, writing down a problem statement and all the rest? Why not put an RFC number on the solution? It also makes me wonder what your opinion on the following from 2418. - Is the proposed work plan an open IETF effort or is it an attempt to bless non-IETF technology where the effect of input from IETF participants may be limited? What would help with the charter, even now, is for people to write up proposals for the solution -- ideally in the form of Internet-Drafts. This seems to be starkly different from the process I know of. Are you really suggesting that people come up with solutions to help with the charter? What problem are we solving? What are the requirements? Based on the proposal that was sent out, we won't have consensus on all of those until Oct 2009 or later. Apr 2009: Working Group Last Call for problem statement Jun 2009: Submit problem statement to IESG as Informational Aug 2009: Working Group Last Call for requirements document Oct 2009: Submit requirements document to IESG as Informational I haven't yet selected chairs for the WG, so as you can imagine editors and authors aren't yet selected. It would be most excellent to see some individual proposals before a committee gets their hands on them :) I am sorry Lisa, but I am really confused by your request for proposals before we even agree on the problem. I am hoping for a clarification. thanks, Lakshminath Lisa On Fri, Oct 10, 2008
Re: [p2pi] WG Review: Application-Layer Traffic Optimization (alto)
Vidya: Thank you for your response and your time in helping define the work. More inline. Narayanan, Vidya wrote: 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. I think the disconnect we may be having is that you view ALTO as a peer description protocol; it is not. Other protocols like BitTorrent, for example, are more suited to this, and they do exactly what you want. In a BitTorrent overlay (swarm), the overlay knows exactly which peer is contributing which content, which peer has which chunks, the download/upload ratio, the time the peer joined the swarm, whether the peer is choked or unchoked, whether the peer has a public port, etc. ALTO is not out to replace BitTorrent. What ALTO is providing are better strategies for peer selection. For instance, it is not ALTO that gets to decide which peer is hosting which content and what the contributions of that peer to the overlay are. However, it is ALTO's job to provide information to a querying peer allowing it to determine wisely where it will download the content from. 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 far, no one on the list has proposed that ALTO be a peer description and publication protocol. So based on the discussion we have had since (essentially the workshop in) May 2008 on the p2pi list, I would hesitate to add in the charter something that participants have not expressed any preference for (i.e., a deliverable on peers publishing their information.) 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. I am confused; I thought earlier you were trying to make the case that ALTO should provide even more specific information that needs to be published? In the end, we do agree on that any protocol be extensible. Whether that is extensible through a registry-like mechanism or other means remains to be discussed in the WG, right? 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 :) Protocols evolve, networks evolve. I am sure we were prescient when we designed TCP such that HTTP could simply use it. However, other realities of evolution did force us to design SCTP, for instance. But regardless, the point is that we should be general, and we are; but we have to do this while drawing a fine line between research and engineering. Some applications that are appearing on the horizon are streaming media and P2PTV; for these we have opened up channels with IRTF. So I don't see where we are constraining ourselves in ALTO. I can envision video applications using the P2PSIP framework, for instance. Yes, and as I wrote earlier, they can use ALTO to discover the the peer they find optimal within their constraints and use it. 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? Look at the Ono work, which is a plug-in to BitTorrent. It uses Akamai redirections to find the closest peer to download content from. In a sense, ALTO is replacing that ad-hoc lookup and providing a much more deterministic answer. That is what we mean by the needs of BitTorrent/CDN etc. 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. But we are not. As I made the point earlier, ALTO is not out to replace BitTorrent. So replicating in ALTO the details about peers that BitTorrent already has is counter-productive. Instead, ALTO can focus on providing the pieces that BitTorrent does not: topology, policy, etc. That is where we will make a difference. Thanks, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA) Email: [EMAIL
RE: [p2pi] WG Review: Application-Layer Traffic Optimization (alto)
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
RE: [p2pi] WG Review: Application-Layer Traffic Optimization (alto)
Contrary to what some people seem to have interpreted my email to mean, I did actually say that the work is needed. I was noting the lack of consensus from the last BoF and I definitely feel a second BoF is more appropriate at this time to iron out the disagreements. However, I am still not trying to block the work - I am saying that there are some critical things to alter in the charter proposal. As Lakshminath notes, the notion of service vs. server is more than a terminology issue. It is important that we consider the possibility of ALTO being provided as a distributed service, potentially in an overlay context. I also see the charter being restrictive in terms of assuming a subset of information types to be provided by the ALTO server. We need to shoot for a much more generic and extensible mechanism. Another important missing piece is the ability for peers to publish information about themselves - without that, the request/response protocol alone carries much less value. Regards, Vidya -Original Message- From: Lakshminath Dondeti [mailto:[EMAIL PROTECTED] Sent: Thursday, October 09, 2008 10:17 PM To: Richard Barnes Cc: Narayanan, Vidya; [EMAIL PROTECTED]; '[EMAIL PROTECTED]' Subject: Re: [p2pi] WG Review: Application-Layer Traffic Optimization (alto) On 10/9/2008 6:36 PM, Richard Barnes wrote: On the contrary, I perceived pretty strong agreement at the BoF that the ALTO problem, as expressed in the documents and presentations, as an important one to solve. There was some disagreement about solutions, but there seemed to be agreement about the general idea that it would be useful to create an ALTO service that could help peers optimize their peer selection. Richard, The minutes (http://www.ietf.org/proceedings/08jul/minutes/alto.txt) say this: +++ Many people agreed that this is important work for the IETF, also some (less) people hummed against. Hum was inconclusive - some of the no hums were (in Jon's words) vehement. +++ Given that there was no consensus, it would have been nice if the sponsoring AD(s) or the IESG explained what's going on, but then transparency, it appears, is not really a goal in this case. If the idea was to just go forward anyway, we really wasted 3, may be 6 months. The half measures are a waste of everyone's time. The question of service versus server in the text is a complete non-issue, purely a matter of wording. No it is not; please see below. In all of the ALTO service scenarios Vidya describes, there is ultimately a single host that provides ALTO information, which you might as well call an ALTO server. A distributed service is not necessarily provided by a single host. Since it addresses an important problem, and a problem that many people agree is important, I support moving forward with this work. I for one think that there needs to be much more clarity on the goals and the terminology before just moving forward and producing useless RFCs. regards, Lakshminath --Richard 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. Overall, I think we should work with the notion of an ALTO service rather than specifically an ALTO 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. 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. - The ability to register information types with IANA and extend these. 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. Some further comments/questions inline. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of IESG Secretary Sent: Monday, October 06, 2008 1:36 PM To: IETF Announcement list Cc: [EMAIL PROTECTED] Subject: WG Review: Application-Layer Traffic Optimization (alto) A new IETF working group has been proposed in the Applications Area. The IESG has not made any determination as yet. The following draft
Re: [p2pi] WG Review: Application-Layer Traffic Optimization (alto)
Hi Enrico, Vijay, Thank you for the summary of what transpired after the Dublin meeting. I appreciate you taking the time. My reading at the BoF was that there were some concerns about this work being done in haste without clearly understanding what it is that we want to do and what it is that we need to do to address this particular problem space (there were even suggestions to move some of the work to the IRTF). My perception and my understanding of some of the dissenting opinions was that some of those need to be worked out before creating a working group. We have been in situations where working groups have been created in haste to address important and urgent problems, but then people disagree so much in working groups that some such working groups never made any real progress or had to be shut down (folks, please don't try to guess which WG(s) and try to explain the individual situations; thanks). Surely, we don't want that to happen here. Some of the disagreements here in this thread now, and the intent of some of the folks to whitewash the issues raised do seem troublesome. It would be great if we could rather focus on trying to understand all aspects of the problem, have the charter reflect the correct level of scope (too wide or too narrow are problematic as we know), and move forward. thanks, Lakshminath On 10/10/2008 5:15 AM, Enrico Marocco wrote: Lakshminath Dondeti wrote: The minutes (http://www.ietf.org/proceedings/08jul/minutes/alto.txt) say this: +++ Many people agreed that this is important work for the IETF, also some (less) people hummed against. Hum was inconclusive - some of the no hums were (in Jon's words) vehement. +++ Given that there was no consensus, it would have been nice if the sponsoring AD(s) or the IESG explained what's going on, but then transparency, it appears, is not really a goal in this case. If the idea was to just go forward anyway, we really wasted 3, may be 6 months. The half measures are a waste of everyone's time. Lakshminath, the objections raised during the BoF in Dublin were on very specific issues, namely the general service discovery problem supposedly addressed by the charter, a too broad scope in terms of information exchanged between ALTO clients and ALTO servers, and the connection between traffic localization and optimization someone seemed to see implied in the problem statement. During the weeks following the meeting, people who had expressed concerns at the mic and on the list constructively contributed to the discussion and the group converged on a charter the current version is a slight variant of. For this reason, and for the amount of interest shown in Dublin -- we called inconclusive the hum on the charter, but interest in the problem was made pretty clear by what we heard at the mic, by the number of contributors, and by the number of people in the room -- we managed to convince our sponsoring AD (and transitively the IESG) to send it out for IETF-wide review. If the community identifies new serious issues or considers the old ones not completely addressed, probably a new BoF will be the best way to sort them out. Of course I'm only speaking for myself, not certainly on behalf of Lisa nor the IESG. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [p2pi] WG Review: Application-Layer Traffic Optimization (alto)
Lakshminath Dondeti wrote: The minutes (http://www.ietf.org/proceedings/08jul/minutes/alto.txt) say this: +++ Many people agreed that this is important work for the IETF, also some (less) people hummed against. Hum was inconclusive - some of the no hums were (in Jon's words) vehement. +++ Given that there was no consensus, it would have been nice if the sponsoring AD(s) or the IESG explained what's going on, but then transparency, it appears, is not really a goal in this case. If the idea was to just go forward anyway, we really wasted 3, may be 6 months. The half measures are a waste of everyone's time. Lakshminath, the objections raised during the BoF in Dublin were on very specific issues, namely the general service discovery problem supposedly addressed by the charter, a too broad scope in terms of information exchanged between ALTO clients and ALTO servers, and the connection between traffic localization and optimization someone seemed to see implied in the problem statement. During the weeks following the meeting, people who had expressed concerns at the mic and on the list constructively contributed to the discussion and the group converged on a charter the current version is a slight variant of. For this reason, and for the amount of interest shown in Dublin -- we called inconclusive the hum on the charter, but interest in the problem was made pretty clear by what we heard at the mic, by the number of contributors, and by the number of people in the room -- we managed to convince our sponsoring AD (and transitively the IESG) to send it out for IETF-wide review. If the community identifies new serious issues or considers the old ones not completely addressed, probably a new BoF will be the best way to sort them out. Of course I'm only speaking for myself, not certainly on behalf of Lisa nor the IESG. -- Ciao, Enrico smime.p7s Description: S/MIME Cryptographic Signature ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [p2pi] WG Review: Application-Layer Traffic Optimization (alto)
It was evident that the Dublin BoF went well but also evident that it ended without consensus on the work that a ALTO WG should do/not do. However, it looks to me that the 200 and more emails that followed the BoF, allowed us to find some form of agreement on the direction ALTO community should look at. A few weeks later we had a new (revised) charter document. It has been sent to the mailing list and slightly amended (nothing really substantial as I recall). This also enforces the idea that we reached substantial consensus. We may argue that consensus reached is not enough for a WG creation but sincerely this is not my perception. Naively, I tend to believe that a WG can be created once agreement exists on problem statement and charter. Once WG is created, consensus is anyway required for any standardization process so, we'll have a lot of other opportunities for disagreement... thanks. s. From: Narayanan, Vidya [EMAIL PROTECTED] Date: Thu, 9 Oct 2008 23:07:21 -0700 To: Dondeti, Lakshminath [EMAIL PROTECTED], Richard Barnes [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] [EMAIL PROTECTED], '[EMAIL PROTECTED]' [EMAIL PROTECTED], ietf@ietf.org ietf@ietf.org Conversation: [p2pi] WG Review: Application-Layer Traffic Optimization (alto) Subject: Re: [p2pi] WG Review: Application-Layer Traffic Optimization (alto) Contrary to what some people seem to have interpreted my email to mean, I did actually say that the work is needed. I was noting the lack of consensus from the last BoF and I definitely feel a second BoF is more appropriate at this time to iron out the disagreements. However, I am still not trying to block the work - I am saying that there are some critical things to alter in the charter proposal. As Lakshminath notes, the notion of service vs. server is more than a terminology issue. It is important that we consider the possibility of ALTO being provided as a distributed service, potentially in an overlay context. I also see the charter being restrictive in terms of assuming a subset of information types to be provided by the ALTO server. We need to shoot for a much more generic and extensible mechanism. Another important missing piece is the ability for peers to publish information about themselves - without that, the request/response protocol alone carries much less value. Regards, Vidya -Original Message- From: Lakshminath Dondeti [mailto:[EMAIL PROTECTED] Sent: Thursday, October 09, 2008 10:17 PM To: Richard Barnes Cc: Narayanan, Vidya; [EMAIL PROTECTED]; '[EMAIL PROTECTED]' Subject: Re: [p2pi] WG Review: Application-Layer Traffic Optimization (alto) On 10/9/2008 6:36 PM, Richard Barnes wrote: On the contrary, I perceived pretty strong agreement at the BoF that the ALTO problem, as expressed in the documents and presentations, as an important one to solve. There was some disagreement about solutions, but there seemed to be agreement about the general idea that it would be useful to create an ALTO service that could help peers optimize their peer selection. Richard, The minutes (http://www.ietf.org/proceedings/08jul/minutes/alto.txt) say this: +++ Many people agreed that this is important work for the IETF, also some (less) people hummed against. Hum was inconclusive - some of the no hums were (in Jon's words) vehement. +++ Given that there was no consensus, it would have been nice if the sponsoring AD(s) or the IESG explained what's going on, but then transparency, it appears, is not really a goal in this case. If the idea was to just go forward anyway, we really wasted 3, may be 6 months. The half measures are a waste of everyone's time. The question of service versus server in the text is a complete non-issue, purely a matter of wording. No it is not; please see below. In all of the ALTO service scenarios Vidya describes, there is ultimately a single host that provides ALTO information, which you might as well call an ALTO server. A distributed service is not necessarily provided by a single host. Since it addresses an important problem, and a problem that many people agree is important, I support moving forward with this work. I for one think that there needs to be much more clarity on the goals and the terminology before just moving forward and producing useless RFCs. regards, Lakshminath --Richard 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. Overall, I think we should work with the notion of an ALTO service rather than specifically an ALTO server. The ALTO service may be provided by a server, a cluster of distributed servers or as a service
Re: [p2pi] WG Review: Application-Layer Traffic Optimization (alto)
On Oct 9, 2008, at 6:36 PM, Richard Barnes wrote: On the contrary, I perceived pretty strong agreement at the BoF that the ALTO problem, as expressed in the documents and presentations, as an important one to solve. There was some disagreement about solutions, but there seemed to be agreement about the general idea that it would be useful to create an ALTO service that could help peers optimize their peer selection. The question of service versus server in the text is a complete non-issue, purely a matter of wording. In all of the ALTO service scenarios Vidya describes, there is ultimately a single host that provides ALTO information, which you might as well call an ALTO server. Since it addresses an important problem, and a problem that many people agree is important, I support moving forward with this work. I agree. This is such a pressing problem that blocking on terminology disputes which can be easily reconciled seems ill-advised. There was an excellent technical discussion on the list after the last IETF, and I think we reached at least rough consensus on the important points. I support moving forward. Phil ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [p2pi] WG Review: Application-Layer Traffic Optimization (alto)
Lakshminath and Vidya, Vijay, Enrico and Stefano have said what I was going to say (e.g. below) -- as sponsoring AD for this charter I've been following the WG discussion, working with the rest of the IESG, and talking to people to confirm that there's better consensus on the list, even if there was confusion at the BOF. This IETF Last Call is also part of confirming whether there's now consensus. It's difficult to write a charter without actually designing the solution. What would help with the charter, even now, is for people to write up proposals for the solution -- ideally in the form of Internet-Drafts. I haven't yet selected chairs for the WG, so as you can imagine editors and authors aren't yet selected. It would be most excellent to see some individual proposals before a committee gets their hands on them :) Lisa On Fri, Oct 10, 2008 at 11:36 AM, Vijay K. Gurbani [EMAIL PROTECTED]wrote: ... And since the BoF, much has changed to narrow the scope of the charter down to more manageable pieces as well as establish a channel with IRTF to move certain aspects of the work there (as the timeline in my previous email indicated.) Lakshminath Dondeti wrote: My perception and my understanding of some of the dissenting opinions was that some of those need to be worked out before creating a working group. But I believe that we have done exactly that: the list has been busy since Dublin on attempts to move the work forward in a manner that is conducive to all participants. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [p2pi] WG Review: Application-Layer Traffic Optimization (alto)
I agree with the sentiment that this work is too important to not move forward. While feelings at the BoF were mixed, the work done since the BoF has been substantial, particularly in the area of narrowing the charter's scope. The ALTO work as it has been put forth in the current charter has potential value not only for diverse applications (as the IPTV example below suggests), but also for a diversity of network operators facing difficult technical and policy trade-offs arising from ever-changing network usage. All sides will benefit from moving forward. Alissa Cooper Center for Democracy Technology On Oct 10, 2008, at 12:29 AM, Daniel Park wrote: I also agree to move it forward. One example: ALTO issue is quickly coming up in the IPTV business. P2P for IPTV service already takes place in some of standard bodies (e.g., DVB, EBU, etc...). So, it's a good timing not to missing over the important business changes... -- Daniel Park [at] Samsung Electronics Standard Architect, blog.naver.com/natpt On Fri, Oct 10, 2008 at 10:36 AM, Richard Barnes [EMAIL PROTECTED] wrote: On the contrary, I perceived pretty strong agreement at the BoF that the ALTO problem, as expressed in the documents and presentations, as an important one to solve. There was some disagreement about solutions, but there seemed to be agreement about the general idea that it would be useful to create an ALTO service that could help peers optimize their peer selection. The question of service versus server in the text is a complete non-issue, purely a matter of wording. In all of the ALTO service scenarios Vidya describes, there is ultimately a single host that provides ALTO information, which you might as well call an ALTO server. Since it addresses an important problem, and a problem that many people agree is important, I support moving forward with this work. --Richard 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. Overall, I think we should work with the notion of an ALTO service rather than specifically an ALTO 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. 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. - The ability to register information types with IANA and extend these. 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. Some further comments/questions inline. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of IESG Secretary Sent: Monday, October 06, 2008 1:36 PM To: IETF Announcement list Cc: [EMAIL PROTECTED] Subject: WG Review: Application-Layer Traffic Optimization (alto) A new IETF working group has been proposed in the Applications Area. The IESG has not made any determination as yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list ([EMAIL PROTECTED]) by Monday, October 13, 2008. Application-Layer Traffic Optimization (alto) = Last Modified: 2008-09-29 Current Status: Proposed Working Group Chair(s): TBD Applications Area Director(s): Lisa Dusseault (lisa at osafoundation.org) Chris Newman (Chris.Newman at sun.com) Applications Area Advisor: Lisa Dusseault (lisa at osafoundation.org) Mailing List: General Discussion: p2pi at ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/p2pi Archive: http://www.ietf.org/pipermail/p2pi/ Description of Working Group: A significant part of the Internet traffic today is generated by peer-to-peer (P2P) applications used for file sharing, real-time communications, and live media streaming. P2P applications exchange large amounts of data, often uploading as much as downloading. In contrast to client/server architectures, P2P applications often have a selection of peers and must choose. One of the advantages of P2P systems comes from redundancy in resource availability. This requires choosing among
RE: [p2pi] WG Review: Application-Layer Traffic Optimization (alto)
Marshall makes some excellent points. Some additional thoughts on a few of his observations. snip Some comments in the charter below. This document clearly needs some more work. As a overall comment, I think it is premature to discuss ALTO servers and would keep the charter focused on describing the ALTO service. I do not see consensus at this moment as to a central service solution versus a distributed solution. I fully agree. And, I see some discussions almost collapsing the two saying that eventually, there is a server that an ALTO client is talking to. That is incorrect in a distributed system and pre-supposing that will get us on the wrong solution path with a narrow view. snip - Is the ALTO service willing to obtain and divulge that information? Do computers have free will ? More seriously, it seems very odd to assume that a P2P service will not do something that the owners of the peers want it to do. In my opinion that drives P2P adoption much more than the efficiencies of bandwidth sharing. Absolutely! This also goes back to some of the responses on sharing uplink/downlink bandwidth information having privacy issues. If a peer is willing to share a piece of information, that makes that information viable to be shared. Building distributed systems within the confines of what may administratively be the best types of information to share doesn't automatically produce the best systems. snip Does this mean that congestion is not an issue to consider ? If the closest peer to me was totally congested and had no available bandwidth, isn't that something that I would want to know ? I do think this type of information is needed, but, I suspect ALTO is not the place for this. Peers may do measurement-based selection that eventually decides the best ranking of peers and the input from the ALTO service may just be one data point. Regards, Vidya ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: [p2pi] WG Review: Application-Layer Traffic Optimization (alto)
Lisa, Enrico, Vijay, Thanks for the clarifications. I went through the P2PI mailing list and found some interesting discussions. There are some topics where I don't yet see consensus and some of the discussions still seem open. As Marshall, Sam, Lakshminath and I have pointed out, I don't yet see a consensus on whether the ALTO service is a centralized or distributed one. I also noted some unresolved discussions on the list on the types of information that can be shared as part of this service. As I've already noted, I do support the work and believe it needs to be done. But, I don't believe we have sorted out all the charter issues yet and focusing on that discussion would help move this forward. Instead, I see a lot of emails reinstating the importance of the work and that it needs to move forward. Well, that's clearly not the point of debate at all here, since I haven't seen anyone say the work is not important. A couple of notes inline. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Lisa Dusseault Sent: Friday, October 10, 2008 12:21 PM To: Dondeti, Lakshminath Cc: [EMAIL PROTECTED]; IESG IESG; ietf@ietf.org Subject: Re: [p2pi] WG Review: Application-Layer Traffic Optimization (alto) Lakshminath and Vidya, Vijay, Enrico and Stefano have said what I was going to say (e.g. below) -- as sponsoring AD for this charter I've been following the WG discussion, working with the rest of the IESG, and talking to people to confirm that there's better consensus on the list, even if there was confusion at the BOF. This IETF Last Call is also part of confirming whether there's now consensus. It's difficult to write a charter without actually designing the solution. What would help with the charter, even now, is for people to write up proposals for the solution -- ideally in the form of Internet-Drafts. I haven't yet selected chairs for the WG, so as you can imagine editors and authors aren't yet selected. It would be most excellent to see some individual proposals before a committee gets their hands on them :) The above made me wonder if we are still operating at the IETF :) We repeatedly chastize people for writing charters with a solution in mind. I think it is extremely premature to talk about specific solutions, editors and authors - we have more fundamental discussions to be had on scoping the problem and agreeing to what is going to be solved. I hope we can do that first. Regards, Vidya Lisa On Fri, Oct 10, 2008 at 11:36 AM, Vijay K. Gurbani [EMAIL PROTECTED] wrote: ... And since the BoF, much has changed to narrow the scope of the charter down to more manageable pieces as well as establish a channel with IRTF to move certain aspects of the work there (as the timeline in my previous email indicated.) Lakshminath Dondeti wrote: My perception and my understanding of some of the dissenting opinions was that some of those need to be worked out before creating a working group. But I believe that we have done exactly that: the list has been busy since Dublin on attempts to move the work forward in a manner that is conducive to all participants. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [p2pi] WG Review: Application-Layer Traffic Optimization (alto)
Dear Vijay; On Oct 10, 2008, at 5:31 PM, Vijay K. Gurbani wrote: Marshall Eubanks wrote: I support this moving forward. My reading of the room in Dublin was that there was serious support for this and certainly a critical mass to move forward. Marshall: Thank you for your review. More inline. Some comments in the charter below. This document clearly needs some more work. As a overall comment, I think it is premature to discuss ALTO servers and would keep the charter focused on describing the ALTO service. In an earlier reply to Vidya I note that the charter does indeed predominantly refer to ALTO services over ALTO server. Having said that, if I did not convince you through that argument, then we can leave the s/ALTO server/ALTO service discussion on the table. I do not see consensus at this moment as to a central service solution versus a distributed solution. Agreed. To me, this agreement answers the previous point. (Servers presupposes the answer, service does not IMO.) s/choose/choose the best peer or peers to exchange data with/ Unfortunately, in the Dublin BoF charter, we did state best peer (we had termed it optimal peer). This was one reason for the negative hums in the BoF because people have differing notion of what an optimal (or best) peer is. Thus, we reverted to the non-confrontational use of the phrase that you now see in the charter. OK, but is doesn't read well : In contrast to client/server architectures, P2P applications often have a selection of peers and must choose. There is a missing object. How about must choose one or more peers from this selection. ? - A request/response protocol for querying the ALTO service to obtain information useful for peer selection, and a format for requests and responses. The WG does not require intermediaries between the ALTO This is strange wording, as WG themselves are not protocols. More fundamentally, is this a requirement? No. We had some list discussion on whether or not to include intermediaries, but the resolution of that discussion appeared to be no (please see the few emails around the following link: http://www.ietf.org/mail-archive/web/p2pi/current/ msg00635.html). How about s/The WG does not/In scope solutions do not/ - Can the ALTO service technically provide that information? I think that what is meant here is Can the ALTO service realistically discover that information? OK. - Is the ALTO service willing to obtain and divulge that information? Do computers have free will? AI notwithstanding ;-) But point taken; we can attempt a reword (if you have any suggestions, please throw them our way.) Whose will ? This gets to a crucial difference between a central server and a distributed system. If it is a central server, then the owner of that server gets a vote here, and maybe a veto. It it is distributed service, then the owners of the peers will ultimately decide this. How about - Is the ALTO service technically able to obtain that information, and is the distribution of that information allowed by the operators of that service ? After these criteria are met, the generality of the data will be What is meant by the generality of the data ? considered for prioritizing standardization work, for example the Hmmm ... since we are talking about prioritizing, maybe what is meant is importance -- as in importance of the service -- may be a better fit. Comments? WFM number of operators and clients that are likely to be able to provide or use that particular data. In any case, this WG will not propose standards on how congestion is signaled, remediated, or avoided, and Does this mean that congestion is not an issue to consider ? It is, but not in ALTO. That will be part of TANA. ACK If the closest peer to me was totally congested and had no available bandwidth, isn't that something that I would want to know ? will not deal with information representing instantaneous network state. What is meant by information representing instantaneous network state ? Isn't this a protocol to share information about the state of the network ? Or is this an attempt to separate network topology from network performance ? But should network performance also be an issue ? By and large, it has been the case that that instantaneous network characteristics -- like current link usage, congestion, etc. -- are not be part of ALTO; they will be part of TANA. Hence, congestion control was deemed out of scope. OK. This WFM now. What is an Internet coordinate system? Things like IDMaps, GNP, Vivaldi, etc. Should we define this term in the charter? I was not aware of this work. Thanks for alerting me to it. Regards Marshall Thanks, Marshall. - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA) Email: [EMAIL PROTECTED],bell-labs.com,acm.org} WWW: http://www.alcatel-lucent.com/bell-labs
Re: [p2pi] WG Review: Application-Layer Traffic Optimization (alto)
On 10/10/2008 12:21 PM, Lisa Dusseault wrote: Lakshminath and Vidya, Vijay, Enrico and Stefano have said what I was going to say (e.g. below) -- as sponsoring AD for this charter I've been following the WG discussion, working with the rest of the IESG, and talking to people to confirm that there's better consensus on the list, even if there was confusion at the BOF. This IETF Last Call is also part of confirming whether there's now consensus. Hi Lisa, My concern can be put in really simple terms. We have some really very confusing processes and we seem to add to the confusion and not make things simpler. I left Dublin thinking, out of the p2pi efforts, TANA will be a WG (there was strong consensus and agreement on the problem space and what needs to be done) and ALTO may have another BoF. As of today, there is a WG proposal on the table for ALTO and in a different area from where we started; TANA is on the BoF wiki. Next, my experiences in the past on BoFs that did not have consensus have been dramatically different from what is happening on ALTO. The IESG has really even refused to allow another BoF much less directly started creating a working group. So, it makes me wonder whether the rules have recently been changed or whether they are selectively applied. I am also confused by your use of the word consensus; you say that you've talked to people to confirm that there's better consensus on the list, but also say that the charter review is also part of the consensus process. Shouldn't there be a call for consensus? It's difficult to write a charter without actually designing the solution. This is an interesting opinion. May I translate that to mean that there is already a solution in the minds of the people who wrote the charter? Why then would we bother with the proposed requirements effort, writing down a problem statement and all the rest? Why not put an RFC number on the solution? It also makes me wonder what your opinion on the following from 2418. - Is the proposed work plan an open IETF effort or is it an attempt to bless non-IETF technology where the effect of input from IETF participants may be limited? What would help with the charter, even now, is for people to write up proposals for the solution -- ideally in the form of Internet-Drafts. This seems to be starkly different from the process I know of. Are you really suggesting that people come up with solutions to help with the charter? What problem are we solving? What are the requirements? Based on the proposal that was sent out, we won't have consensus on all of those until Oct 2009 or later. Apr 2009: Working Group Last Call for problem statement Jun 2009: Submit problem statement to IESG as Informational Aug 2009: Working Group Last Call for requirements document Oct 2009: Submit requirements document to IESG as Informational I haven't yet selected chairs for the WG, so as you can imagine editors and authors aren't yet selected. It would be most excellent to see some individual proposals before a committee gets their hands on them :) I am sorry Lisa, but I am really confused by your request for proposals before we even agree on the problem. I am hoping for a clarification. thanks, Lakshminath Lisa On Fri, Oct 10, 2008 at 11:36 AM, Vijay K. Gurbani [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: ... And since the BoF, much has changed to narrow the scope of the charter down to more manageable pieces as well as establish a channel with IRTF to move certain aspects of the work there (as the timeline in my previous email indicated.) Lakshminath Dondeti wrote: My perception and my understanding of some of the dissenting opinions was that some of those need to be worked out before creating a working group. But I believe that we have done exactly that: the list has been busy since Dublin on attempts to move the work forward in a manner that is conducive to all participants. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [p2pi] WG Review: Application-Layer Traffic Optimization (alto)
Lakshminath Dondeti wrote: It's difficult to write a charter without actually designing the solution. This is an interesting opinion. May I translate that to mean that there is already a solution in the minds of the people who wrote the charter? Nope. Who has been following the p2pi list for the last five months probably knows that there are three different approaches (solutions?) floating around: the sorting oracle (described in a SIGCOMM paper authored by folks from TU-Berlin, a variant of which is IDIPS), P4P (soon to be published as I-D and, IIRC, described in another SIGCOMM paper), and Stanislav's proposal (discussed in Dublin and on the list: http://www.ietf.org/mail-archive/web/p2pi/current/msg00508.html). Who wrote the charter had all those approaches clear in mind and took special care that none of them got ruled out. Why then would we bother with the proposed requirements effort, writing down a problem statement and all the rest? Why not put an RFC number on the solution? It also makes me wonder what your opinion on the following from 2418. - Is the proposed work plan an open IETF effort or is it an attempt to bless non-IETF technology where the effect of input from IETF participants may be limited? I don't know Lisa's opinion, but am sure that this is not the case here. -- Ciao, Enrico smime.p7s Description: S/MIME Cryptographic Signature ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [p2pi] WG Review: Application-Layer Traffic Optimization (alto)
Thanks for the clarification Enrico :). best, Lakshminath On 10/10/2008 6:27 PM, Enrico Marocco wrote: Lakshminath Dondeti wrote: It's difficult to write a charter without actually designing the solution. This is an interesting opinion. May I translate that to mean that there is already a solution in the minds of the people who wrote the charter? Nope. Who has been following the p2pi list for the last five months probably knows that there are three different approaches (solutions?) floating around: the sorting oracle (described in a SIGCOMM paper authored by folks from TU-Berlin, a variant of which is IDIPS), P4P (soon to be published as I-D and, IIRC, described in another SIGCOMM paper), and Stanislav's proposal (discussed in Dublin and on the list: http://www.ietf.org/mail-archive/web/p2pi/current/msg00508.html). Who wrote the charter had all those approaches clear in mind and took special care that none of them got ruled out. Why then would we bother with the proposed requirements effort, writing down a problem statement and all the rest? Why not put an RFC number on the solution? It also makes me wonder what your opinion on the following from 2418. - Is the proposed work plan an open IETF effort or is it an attempt to bless non-IETF technology where the effect of input from IETF participants may be limited? I don't know Lisa's opinion, but am sure that this is not the case here. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
