Meeting notes from ALTO Working Group meeting, IETF74, San Francisco March 26, 2009, 13:00-15:00. About 100 attendees This report has been distilled from the detailed meeting notes taken by Marco Tomsu and Volker Hilt. Chairs: Jon Peterson, Vijay Gurbani and Enrico Marocco Agenda ------ Vijay Gurbani presented the agenda and announced an additional session at 16:10-17:00 to discuss merits of the solution proposals presented during the first session. If time permits, an additional presentation whose request came late will close the overflow session. No questions nor comments. Problem Statement ----------------- Eric Burger, no slides presented, checked the number of people who had read the draft (many shows of hands) asking for comments. The document has been out for 9 months, extensively discussed, no comments neigher in the room nor on the list. Call for hum for adopting draft -05 as deliverable and WG item: consensus (many for, no against). Pete Resnick: potential WG items should appear on the WG documents page. Jon: it is intentionally so. Cullen Jennings: do it as usual in the IETF, all drafts are on the mailing list and available on the tools page. Requirements ------------ Sebastian Kiesel presented the new version of the draft. Changes from previous version: terminology updated, distinguished requirements for ALTO client protocol, removed items that were too specific to solution proposals, added sections 4 and 5, added framework architecture in section 2. Question to the group: should there only be one client protocol or should wording say any client protocol should comply? Lisa Dusseault (as advisor AD): hard to answer. Jon: let's start focusing on one. ??: as long as architecture unclear, there might be other approaches. Error handling and overload protection: strong push from TSV ADs for using TCP. Anja Feldmann: (question for clarification) must use TCP in error case or always TCP? Sebastian: always TCP. Anja: potential bottleneck at the server and TCP requires extra delay. Martin Stiemerling: transport ADs advised that UDP should not be regarded as transport protcol. Need very good reasons for not useing TCP. Does not see the reasons. Sebastian: take this offline. Discovery: how does a third party server find alto server on behalf of a distant resource consumer? Input from the group needed. Host location attributes: need for a means to locate clients. Different options: define a set of attributes or define a registry for attributes. Right now three types of attributes: CIDR, AS, Group ID. How likely is it to come up with additional IDs? Ted Hardie: will need more. AS has many things in a routing system. If someone wants exhaustive list should be able to do so. Mapping group ID protocol is same as alto protocol? Sebastian: yes, mapping protocol can be a macro. Ted: without a mapping server values are useless. Sebastian: inside protocol specification define groups. Ted: requirements for mapping protocol should belong in protocols specification. ??: AS number is not useful without knowing what it means to you. Need to add attributes. Stanislav Shalunov: the protocol should extensible. Should be obvious how to add infos. No need to define exhaustive list, just set a list to get started with. Richard Yang: important to have flexible IDs. Need flexibility here. Rating criteria: initial list collected from the mailing list. Next steps? Lisa: do not finalize the document soon to avoid locking into something, keep it modifiable. Reinaldo: not a good idea to have multiple protocols. Dave Crocker: early reqirements document constrains the discussion, but discussion about requirement is helpful Stanislav: should remain editable as long as there's no consensus. Jon: making it a WG document doesn't makes it impossible to modify. Call for hum for adopting it as WG item: consensus (many for, no against). During the transition to solution proposal discussion Vijay presented an ALTO ID Activity Chart: good amount of input from the WG, but submissions are right before the deadline. Exhorts to submit throughout the cycle. Martin S.: this is fully in line with the standard IETF submission behaviour. P4P/Infoexport Merged Proposal ------------------------------ Richard Y. presented basic concept of the merged proposal: provide info to P2P applications (both clients and trackers) to provide a better service. Notion of of "my-Internet" view: network location plus cost. Alto query response defined in simple way: query consists of a set of source-destination pairs and cost type, response consists of numerical values/ranking. Martin S.: why numerical and ordinal? Richard Y.: second choice can be almost as good as first or very bad. Source/destination groups: proposal to abstract network details as you get to farther destinations. Benefits for scalability and privacy. Transport based on HTTP. Network mapping through two intefaces: getNetworkMap and getCostMap. Two examples with call flows shown. Comparison with other proposals based on six attributes: many similarities, some differences. Rich Woundy: should use this slide during the discussion of the proposals. PROXIDOR/Oracle --------------- Stefano Previdi presented the result of a merger of three proposals (with three implementations). Client/server model, providing a sorting functionality: request carries an unsorted PROXIDOR Source List (PSL), response carries a ranked PROXIDOR Target List (PTL). The ranking system may be based on several information, such as IP routing information, ISP policies, but those are not going to be standardized. No publishing of topology information needed. The draft proposes the architecture; a second draft with protocol details will follow. Three implementations exist: proposal to define a basic set of functions, headers, format, which allows specifying extensions later. Stanislav: P2P clients are not going to send their peer list. How is this handled in this approach? Vijay: this will be discussed in the follow up meeting today. Stefano: there are apps that do this. Anja presented the oracle use case for PROXIDOR. Legal P2P applications will send lists of IPs. Scalable architecture, with two level of topology (internal and external), implemented in C++ and soon to be available as open source. Very early performance results confirm scalability. Richard Y.: PPLive would require several million requests per second. Anja: these numbers are across ISPs not for a single ISP. H1H2/H12 -------- Martin S. presented two different information models, H1H2 and H12, not protocol proposals. Players in this space are users, trackers, P2P software vendors, network operators, but not all are present here and this may limit the view. H1 and H2 describe two hemispheres, P2P applications' and ISPs'. H1: nothing in the request, generic guidance in the response. H2: info in the request (e.g. lists of clients), ranked list in the response. In H1H2 client and server negotiate what model adopt before the transaction, but likely to cause deadlock. In H12 clients send some info (IP address, prefix, ...) that they likes to disclose, server replies with specific guidance that can be 1:1 for request, can be broad or can be narrow. Conclusion: H12 is the only model that won't cause deadlock, as each side can tune level of detail. Ted: issue with IPv6 in the depicted H12 request. Martin S.: using IP prefixes is just an example. Ted: info hiding seems to be broken, with record route enabled you could use first hop. Martin S.: running traceroute is probably too much, it should be usable by any kind of client. A Client to Service Protocol for ALTO ------------------------------------- Saumitra proposed a framework to exchange information among ALTO service providers, ALTO Clients and ALTO Aggregators. Discovery mechanisms based on DNS SRV query (open issue with distributed overlay based systems) to retrieve an XML configuration document from an ALTO server. The group should decide what metrics should be standardized (latency, distance, bandwidth). Described (very detailed) some message formats, Host Location Attributes, guidance request and response format and showed an example use case. No questions nor comments. ALTO Server Discovery --------------------- Yu-Shun Wang presented a survey of existing approaches, to avoid designing new protocols. High level overview on metrics and goals; the details will be worked out along with the progress of the ALTO protocol work. Different entities may do the discovery (clients or trackers) and there are different types of ALTO service providers (local ISPs or global third-parties). Most common mechanisms: DHCP (but does not work for tracker based discovery and NAT boxes need to relay), DNS (but need pre-discover for the name), multicast (issues with NATs). Haibin Song presented two strawman proposals: discovery by peers, based on DHCP and DNS SRV, and discovery by trackers in two steps, with retrivial of ISP/AS info (e.g. from a IANA database) and DNS SRV. Manual configuration has problems. Some concerns about load balancing (part of discovery or separated?), well known ports, servers' address changes. Next step planned is to create a single merged ID after this IETF. Martin Thomson: Conveying DHCP-type configuration parameters to RGWs via PPP is a problem. Refers to GEOPRIV work on discovey. Lisa: APPAREA meeting presented some discovery mechanisms on the application layer. It's useful to look into network oriented mechanisms, e.g. DHCP. ??: should look into composite approaches, evaluate methods. Jon: is this a promising direction? Pete: has someone thought about the implications of massive clients restart on the ALTO protocol and discovery? Jon: not a discovery question. Nothing about avalance restart in requirements. Take question offline. Eran Hammer-Lahav: Distinction between "finding the location of the ALTO service" and "how this is described" should be introduced. ALTO and P2P Edge-Caches ------------------------ Nick Weaver didn't make to the meeting, but slides are on the proceedings and can be discussed on the list. ATTP ---- Yunfei Zhang presented a tracker cooperation mechanism for tracker-based P2P systems. ISP Cooperation betwen ISP and P2P provider preferably with P2P applications sending IP addresses and getting a response back. Vijay: this is not a protocol proposal, but is being presented because falls in the solutions space. Alias tracker controlled by ISP cooperates with original tracker. Stanislav: Is this a redirect mechanism from original trackers to ISP trackers? Yunfei: original tracker replaced by inner tracker. ====================================================================== Meeting notes from ALTO overflow session March 26, 2009, 16:10-17:00. About 40 attendees Chairs: Jon Peterson, Vijay Gurbani and Enrico Marocco Open Discussion --------------- Vijay introduced the session, whose goal is to check how far we can get towards a common protocol today? Charts from the chairs: information Disclosure is either P2P Related or ISP related include some mapping of different approaches (4 ellipses). Jon encouraged people to solve this: in the IETF it's all about consensus. 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. It started with 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: IETF should work on a protocol, and not on a solution. Any protocol should support both extremes. Vijay: the issue is negotiation. Stefano: we have this in all protocols. Bruce Davie: 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: ALTO is not limited to P2P, but also useful for systems downloading content from different locations. There are more opportunities. Bruce: if you use P2P client you can't keep your presence secret. Stanislav: ISP tyipcal to know who you connected to but does not know about all peers you know about. That's the interesting part. Bruce: valid point. Richard Y.: information disclosure is not the problem; even piecewise disclosure offers no privacy. Anja: ISP can put randomized components in information. Stanislav: many ALTO queries may allow learning of the topology. Martin S.: there are many ways to re-engineer network topologies. You can always use network tomography. Stanislav: ISPs offering a simple file know what they are disclosing. Might be less the case for other approaches. Anja: ISP would like to give different information to different peers. Dealing with large quatities of traffic. May want to do load balancing, adjust dynamically. Is impossible with a file. Stanislav: don't have to give everyone the same file. Jon: what is the reconcilable middleground. It isn't of any good if none is giving info. Martin S.: like "my internet" 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? Bruce: 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. Stanislav: ISP may have contractual obligation not to disclose. Can be less than fool 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 allow ISP to record peer lists? Stanislav: might be already a problem for users if the protocol would allow that. But don't know yet. It's a matter of perception. Bruce: 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: if protocol had capability but implementer could set threshold on what is disclosed, would this be a problem in community? Just the fact that protocol has capability? Stanislav: just a question of perception. Martin S.: H12 allows setting the bar, what has to be disclosed. Jon: tons of protocols with various capabilities misunderstood in the press. Always a risk. ??: 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. Anja: your app use network resources inefficiently. You can get better performance from local transfer. Martin S.: 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 going to help with this. ??: 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. ??: mechanism that helps application and net to converge. Maybe that is differential pricing. Many different incentives at play. Protocol designers enable mechanism to converge. ??: conversion is good. Will there be users that this the app is giving away to much info. Anja: chart is messed up. No user can be forced to user alto server. Privacy concerned users can be turn it off. Stanislav: will be off by default. Richard Y.: have done some analysis, which shows that buble 1 in the slides does not allow any network privacy. Anja: disagree, could easily counter with other study. Richard Y.: analyze performance. Buble 1 has scalability issues for servers. Each request send to servers all the time. Very frequent hits. Bad for performance. Anja: BitTorrent is just one possible app. Show that ranking can imporve performance. Jon: need to know what protocol wants to do. How use protocol. Can find virtues and flaws in boths ends. Richard Y.: ranking supported by our proposal. But seems the last protocol to use. Bruce: Should have some consensus calls on some well defined questions. Call for hum for trying to define a protocol that supports the full range of picture: consnsus (many for, very few against). Call for hum for supporting some kind of negotiation mechansm: no consensus (some for, slighly more against). DNS-based IP Location Service ----------------------------- Syon Ding presented a mechanism for determining where a peer belongs to. GEOPRIV WG did some relevant work, main differences due to minor complexity. Using a new domain called nl.arpa. Richard W.: static DNS? Syon: special DNS servers are required.