Hi Vijay, On Fri, 27 Mar 2009, 11:49am -0500, Vijay Gurbani wrote:
> Y. R. Yang wrote: > > First I should say that I still do not understand the diagram. I can infer > > the intention of 1 and 3, but not the other two: > > http://www.ietf.org/proceedings/09mar/slides/alto-10.pdf > > > > Which one represents P4P/Info Export? Any elaboration? > > Ellipse 2 was the P4P/Infoexport (at least that was the intent, if > not the delivery.) I have to say that this is not the case. > > To be honest, I should say that the image did create an image of conflicting > > possibilities in my mind and may not represent real protocols, which can > > support multiple possibilities. > > But regardless, the diagram of the chairs was not normative ;-) It was > mainly a vehicle to get involved actors in direct talks towards > consensus on a path to a protocol. In that, I think it may have > succeeded. I was thinking about the second meeting on my long trip back to east coast. Below is a friendly, but critical comment on the second meeting that I wrote on the way. I have to say that the meeting might have slowed down the convergence process. Like I said during my presentation and shown in my comparison slide, I think much convergence has already happened. Thinking more about it, I think it is fair to say that the second meeting started with a presentation with such a set up: Facts: ----- Fact 1. Both Eclipse 1 and Eclipse 2 are technically sound and workable. Fact 2. ISPs can accept only Eclipse 1 because it can protect ISP privacy; and P2P can accept only Eclipse 2 because it can protect P2P privacy. Implication: ----------- Now the only issue is to select whose privacy. Assignment: ---------- You guys figure out a way to pick one or design a negotiation protocol to do the run-time selection. During the meeting, I said multiple times that I was confused about the setup. I disagree with both stated "facts". For Fact 1, I think Sorting (Eclipse 1) of course can be useful---this is why we included it in P4P/Info Export. But I have doubt about it working in large-scale settings, not only for privacy issues. Think about PPLive which can run to 2 million clients in a single channel. Do you send 2 million IP addresses to an ALTO Server to sort? Trim down to 200,000, or 20,000, or 2,000, or 200. How? It is a pity that technical issues did not play a major role in the discussions. In my slides, scalability is before privacy, with the understanding that privacy of course is important. I also have to disagree with the second stated "fact". Like I said multiple times, sorting protects ISP privacy is an assumption, not a fact. It is a complicated issue. Suppose an ALTO Server does not directly reveal the classification in Eclipse 2, but only uses the Eclipse 1 as an interface. Then a probing experiment is the following. Take any two destinations a and b, and ask the sorting interface. If a and b have same preference value to the ALTO Server, we are likely see either order [a b] or [b a]. If one has a higher preference value, say a is more preferred than b, the sorting will return a before b. Build a graph with nodes being IP addresses. If we see a ahead of b, add a directed link from a to b. Then the problem of identifying the preference ladders is a standard strongly connected components problem. Of course, we can modify the sorting machine to be more complicated (trying to obfuscate the information while at the same time making the ALTO info less effective), then we can design more learning/mining algorithms to filter the added noise. To summarize, I greatly appreciate your effort for chairing the working group. It is a lot of work! It may be much helpful if the agenda has been sent out earlier for feedback and comments. Again, let me emphasize that this is a *friendly*, but criticial comment. Cheers, Richard > Thanks, > > - vijay > -- > Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent > 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA) > Email: v...@{alcatel-lucent.com,bell-labs.com,acm.org} > WWW: http://www.alcatel-lucent.com/bell-labs > _______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
