Meeting notes from ALTO WG meeting, IETF76, Hiroshima, Japan November 11, 2009, 9:00-11:30. About 100 attendees This report has been distilled from the detailed meeting notes taken by Roni Even and Jan Seedorf. Chairs: Vijay Gurbani, Enrico Marocco and Jon Peterson Agenda ------ Vijay presents agenda and status of the WG, since IETF75 the problem statement has been published as RFC 5693. No questions nor comments. Requirements ------------ Rich Woundy presents requirements draft, small update since IETF75, authors are looking for input. No questions nor comments. Problems with Fuzzy IP Provisioning, Link Capacity, etc ------------------------------------------------------- Enrico presents on "Fixing (?) the Shortcomings of Map-based Approaches", explains problems with using provisioned bandwidth for ALTO-guidance, trying to address mailing list discussion. To provide guideline based on topology and bandwidth need at worst case one entry per user. Note that user IP address is dynamically assigned so the map may become stale often. It is desirable to provide information based on provisioned bandwidth. Approach 1: ask the ISP to provision based on bandwidth if they really want to provide guidance based on that. Martin Stiemerling: IETF cannot tell ISP how to provision their network. Rich W.: will add complexity with IPv4 addresses management. Approach 2: fine-grain in second step, maps may point to second-step servers. Martin: privacy, was presented in previous IETF. Lars Eggert: charter talks about better to random, so maybe discuss what the ISP will not want to do. Reinaldo Penno: is it on server or client, the two step approach is in the current protocol. Enrico: right, but it does not explain how clients get to know when the second step is availeble. Reinaldo: stale of map depends on ISP. The current bittorents clients deal with it. Rich W.: end-user who spends money on uplink bandwidth may not want to share this info (privacy issue), this may also indicate something about the income of the user. Enrico: it is often only a temporary identifier. Wolfgang Beck: need to consider other parameters, not only bandwidth. Martin: how static is a network map in reality? Richard Alimi: third approach could be to only give info about provisioned bandwidth to the user and leave it up to the user to disclose this info further. Reinaldo: the specification does not say when coarse grain is used and when to move to fine-grain. Thinks it is up to the client if and when. There is a draft suggesting what Richard A. proposes. Jon: network maps are huge if they contain fine-grained information, it is not only a privacy issue. Reinaldo: yes, such maps can become very large. ALTO Protocol Merged Proposal ----------------------------- Richard A. presents the merged ALTO protocol, comments were that the overall architecture was unclear in the previous -03 version, new -04 version has required and optional services, focus of -04 version is on overall structure and not on syntax details. Martin: please announce such intention in advance next time when you leave out details. Richard A. explains basic ALTO information. Martin: why not just say numerical to make it easier to client? Richard A.: difference is numerical give relative importance. Ordinal allows ISP to not disclose relative importance. Richard A. explains server capabilities and the ALTO services. Martin: how can I filter for PIDs without knowing them? Richard A.: endpoint properties allows finding specific points' PID. Richard A. asks if this shall become a WG item. Jan Seedorf: is it one document - may be too big. Richard A.: protocol will be simple, the functions can be divided later. Jon: there is enough contents but details can be later. Martin: protocol proposal is much clearer after seeing the slides but not from reading the draft, suggests to write the draft in a more readable way. Also need to discuss the point that Enricco presented and was mentioned on the list. Rich W.: the draft and slides are reasonable direction and can be adopted, it is not going to IESG now. Martin: decision on WG adoption should be based on draft status and not on slides presented. Richard A.: please give advice how make the draft clearer. Rich W.: agree that it is about writing the document but still think that this is good enough staring point. Reinaldo: wants to know if this is the right direction, even a WG item can be changed, WG adoption is just a step into the right direction. Hum: do people believe we have enough information about where this document is going to make a decision on WG item? Good consensus, but no unanimity. Hum: do people want to adopt version -04 of draft-penno as WG item? Consensus, no hums against. Aggregate Network Map and Cost Map into CPID -------------------------------------------- Haibin Song presents "Aggregate Network Map and Cost Map into CPID". CPID (cost PID) is a new type of PID that reflects costs between peers implicitly. Haibin explains CPID and use cases. Martin: what is the problem you are trying to solve? Haibin: slide 1 gave the objective. Martin: how is this different from draft penno-04 with respect to privacy? Reinaldo: difference is that clients can decide themselves what to disclose. Ning Zong: CPID enables the ALTO server to not reveal the network map to the client. Martin: so this is like the oracle solution. Need more clarification in the draft. Ning: here the CPID is stored on the client who can decide. Third-party ALTO Server Discovery --------------------------------- Martin: presents "third-party ALTO server discovery", explains why third-party ALTO queries are useful and options for solving this problem. Jon: will there be one authorative ALTO-server per IP-address? DNS solution assumes that there will be one authorative ALTO-server per IP-address? Roni: same as Jon, depends on the solution for service discovery, it is optimization and always can leave it to the client peer. It should be stidied with the service discovery work. Martin: also less work on the peer since will get the order from the tracker. Roni: peer may anyhow need to access ALTO server after gossip stage. Information Redistribution -------------------------- Richard A. presents on ALTO information redistribution, ALTO servers may be a bottleneck if millions of peers, discusses possibility of using P2P for distributing ALTO information, explains difference between reusable vs. non-reusable ALTO information. Martin: what is a subset of an ALTO response? Why not simply sign the complete network/cost map? Lucy Yong: this assumes trust on other peers. Richard A.: you can always ask the ALTO server as a backup. Martin: that is why the information needs to be signed by the server. Reinaldo: good idea but do you need to sign, the peers already trust the other peer. Can be extra security stuff. Martin: ALTO information is different from P2P since it is third party information. Jon: ALTO is not limited to P2P systems. Lars: what is the threat model? The information is not crucial, what are potential attacks? Jon: can be used to denial of service attack. Lars: need to have a good enough security, what are we preventing maybe will need something simpler than signing by the ALTO server. Ning Zong: ALTO servers can use a DHT as a backup for distributing information when they are getting overloaded. Richard A.: overload may be short and setting the DHT may be longer. The draft says that there is time life for the information. Relay Usage in Realtime Communications -------------------------------------- Yu Meng presents on "Relay Usage in Realtime Communications", explains use cases when a UE needs a relay (connectivity, QoS). Martin: what is the problem for ALTO? Yu: relay usage is in ALTO charter. Yu explains how ALTO can help with finding relay nodes. Rich W.: triangular inequality violations may be bad but there maybe there is some reason for it, redirection may make it worse. Lars: this does not scale, for QoS you would have to relay a lot. Martin: this looks like a mix of different requirements, is this not layer-violation? Stefano Previdi: routing protocols adapt based on state of the link, not sure if this is about cooperation between layers as in scope for ALTO. Lars: there was such a proposal years ago and it failed due to scalability. The application will move to a different media relay will not provide better QoS. Look at Dave Anderson papers. Jun Wang: want to standardize on the application layer since you can not solve all on the IP layer. They want to provide a capability for analyzing not to mandate. Lars: the proposed solution does not fit in the ALTO server, what information would you need from an ALTO server for your solution? If it's alrady provided by ALTO, just use it and build your framework. Otherwise modifying ALTO to meet such requirements is out of scope. Jon: finding a TURN server has been discussed within ALTO. Lars: but QoS framework presented is probably not in the charter. Martin: this is mostly about fixing problems ALTO is not chartered to do. Jon: I agree. Simple ALTO (SALTO) Protocol (Not on the agenda) ---------------------------- Martin Stiemerling presents SALTO (Simple ALTO protocol), explains some issues with draft penno-04. Stefano: network map does not assume static network, the network map is not static but stable (not a lot of variation but can change). Martin: this is the assumption in current draft. Martin explains ALTO hemisphere conflict and H12 model. Enrico: how do the penno-04 authors see this model and how does it relate to their draft? Richard A.: how do ISPs configure their system for such a system? There are options of how to respond, may have different cost. Martin: you can configure to answer static or dynamic. Out of time, discussion referred to the list.