Overflow meeting Intro - Vijay Information disclosure - P2P vs ISP related - converge to something in the middle? - Jon: let the room decide Jon: IETF has long history - something is going on in industry, research. What do we do? Do we need a protocol. Traditional case for this: XMPP 9 different proposals for applications. Consolidated to 3, 2 WGs. Is this the right/best outcome? Maybe not but better than we started. Only tool to common protocol is consenus. H12 stuff is similar to proposal trying to reach consensus. It is up to us to agree on a set of common elements in these protocols. Stefano: understand the scope. Agree on protocol and not solution? Hope protocol will accomodate all solutions we currently have. May not need to find something in the middle. Is this against the charter of the working group. Should we have a protocol that is flexible enough to accomodate different approaches. Vijay: charter is a protocol. From an implementation point of view Stefano: protocol or solution Vijay: issue is negotiation Stefano: we have this in all protocols XXcisco: H12 presentation was right on target. Can identify large oval or small point in middle. Like H12. If you don't reconcile this you end up in a deadlock. Be careful that we do not often end in cases where there is no overlap. Look at proposals at end of spectrum. H12 allows server to transform information. Anja: all of it is not limited to P2P. Applies to anything where content/anything available at multiple locations. Even if a protcol offers full info disclosure. Jon: Stanislav: everyone should speak for their own solutions. Are you speaking for service providers. Richard: WE have a problem of sorting - that will preserve privacy. This is not true. XX: if you use P2P client you can't keep your pres secret. Stanislav: P2P does not Anja: cannot be true. Stanislav: ISP tyipcal to know who you connected to but does not know about all peers you know about. That's the interesting part. XX: valid point Richard: look into what we can find out if we do ranking. Telling information piecewise does not lead to privacy. Anja: ranking is the minimal amount you can return. We do not claim it is accurate. There are counter measures to make breaking security difficult. Question is here: benefit is only happen if both do share a little bit of information. Stanislav: statement if you answer orancle ranking questions often enough cyou cna find out the underying mechanism. M.: you can always use network tomography. XX: User may large number of queries to lear topologies. That is a theoretical concern. Stanislav: not my concern Anja: may ways to reverse engineer topology. Stanislav: yes. the ISP knows what exactly is disclosed. The file contains that. E.g. stay in local AS. If you answer arbitrary question you don't know whayt you disclose. Anja: dealing with large quatities of traffic. May want to do load balancing, adjust dynamically. Is impossible wit ha file. S: don't have to give everyone the same fiel. Jon: What is the reconcilabel middleground. Is the application is any good if none is giving info. M.: like myinternet view. Client can ask for everything but server only returns fraction. Jon: there is a protocol that does some good. To what degree does the protocol have to capture the policy asusmption. Does the protocol need a given sharing model? XX: Concern there is a deadlock issue. You can implement a protocol on both ends and there is a benefit. If no P2P client / ISP participat in each other there is no beneift. Protocol should be able to express things in both proposals. Converge if possible XX: allow protocol that goes across spectrum. Stanislav: ISP may have contractual obligation not to disclose. Can be less than foo info about everything that can be useful to disclose. E.g. I like you to stay in ISP. Jon: do you object to standardize a protocol that is on other end. Stanislav: question for users. What will users perceive. In perspection of users protocol snoops on their activites. If there is a protocol capable of that - is this an issue? XX: You can't speak of all BT users. I can't speak of all ISPs. Argument in favor for an expansive protocol. Anja: differnet kinds of applications. Solution may depend on application. We shouldn't expclude on or the other. Jon: who objects to doing one or the other end? Nobody. Jon: do you think ISP end is defeating the protocol. Stanislav: don't know. Jon: protocol had capability but implementer can set threshold on what is disclosed. Would this be a problem in community. Just the fact that protocol has capability? stanislav: jsut question of perception. M.: purpose of H12 protocol. Jon: tons of protocols with various capabilities misunderstood in the press. Always a risk. YY: Draw a line where the privacy bar should be? The more info yyou are willing to disclose the better the service by ALTO. We don't know how much info each user is willing to disclose. People make these choices. Have to allow users to make these decision. Stanislav: users are fine with performance today. ISPs are unhappy. YY: You may get lower cost for your performance. Anja: your app use network resources inefficiently. You can get better performance from local transfer. M.: a service provider offers flat rate as long as stays within network but 10G to other ISPs. Flat at night. Stanislav: how do you know as a user. Anja: by querying an alto server Stanislav: but a ranking isn't goingto help with this. Richard W.: Three stakeholders: network, app, user. User paranoid about his info. App about getting infos. App can choose Anja: question is which service will ISP offer Richard W.: offer separate service. XX: Mechanism that helps application and net to converge. Maybe that is differential pricing. Many different incentives at play. Protocol designers enable mechanism to converge. Richard W.: conversion is good. Will there be users that this the app is giving away to much info. Anja: chart is messed up! :) Anja: bubble 1 - if no user can be forced to user alto server. Privacy concerned users can be turend off. Stanislav: will be off by default. YY: there is performance improvement. Learning process is individual. Share information so that each peer can learn from experience of others. I.e. sharing information. Richard: 1 is good for ISP. Ranking look at all perspective. Network privacy. We do an analysis. Anja: can be countered. Richard: privacy bad for app and ISP Analyze performance. 1 has scalability issues for servers. Each request send to servers all the time. Very frequent hits. Bad for performance. App performance analysis. Ranking does not provide app performance. Optimizing logic that Anja: BT is just one possible app. Show that ranking can imporve perf. Jon: need to know what protocol wants to do. How use protocol. Can find virtues and flaws in boths ends. Acceptable - have a protocol that covers both ends Richard: Ranking supported by our proposal. But seems the last protocol to use. Jon: client might decide what to use. Can we allow for the superset of this. Richard: not buying performance impr. Jon: need to go. XX: do consenus call. - Hum: Try to define a protocol that supports the full range of picture. good consnsus. Critical for mechanism to reach conclusion of what to do. Do people support convergence. Jon: trying multiple time XX: does not lead to deadlock Jon: - hum: who supports some kind of negotiation mechansm leaning toward negative Vijay: one more presentation: DNS based IP netlocation service Question: are you using static DNS record Have to figure out ... ?? Q2: how many users does chinatelecom have. Vijay: discussion on the list