Meeting notes from ALTO WG meeting, IETF75, Stockholm, Sweeden July 28, 2009, 13:00-15:00. About 100 attendees This report has been distilled from the detailed meeting notes taken by Marco Tomsu and Jan Seedorf. Chairs: Jon Peterson, Vijay Gurbani and Enrico Marocco Agenda ------ Jon Peterson presented the agenda and reminded of the two related bar BoF, DECADE on Wednesday night and PPSP on Thursday night. The problem statement doc is in last call, requirements draft was agreed to stay alive for a while, protocol proposals and survey proposals have merged since IETF74. No questions nor comments. Requirements ------------ Sebastian Kiesel presented the new version of the draft, adopted as WG item at IETF74. There are three new terms replacing the "host location attribute", several requirements can be expressed better with the new terms (examples on the slides). There are different options regarding alto server discovery requirements (ALTO client finding "right" ALTO server, or ALTO client finding a near ALTO server and then redirection). Hannes Tschofenig (from Jabber): finding the access provider based on the IP address of the end host is complicated and error prone. Haibin Song: cross ISP redirection is difficult, prefers first option. Rich Woundy: combination of the two might be helpful. Roni Even: we should not document a preference in the requirements. Albert Tian: also thinks not necessary to have such requirements, second option seems more doable. Reinaldo Penno: what does "right" mean? David McDysan: some parts of the requirements doc are confusing, including this issue. Hannes: nobody is going to read that document anyway after it is finished. Richard Alimi: worried about the trust issue in the second option when there is redirection between ALTO servers. Lars Eggert: do not take solution decisions into the requirements, probably the discovery requirement should be more general and not so detailed. There are new security requirements regarding authentication of servers and clients. Lars: authentication between client and servers is probably not so important but data authentication (authenticating the information exchanged) is important. Ruediger ?: what types of NATs must be support. Should be well defined. General discussion. David: are the new terms target of the query? John ?: have you considered and anonymity server for privacy purposes? Sebastian: currently undefined, please bring the comments to the mailing list. ALTO Protocol ------------- Reinaldo presented the merged ALTO protocol (individual) draft. The current draft is a merger of plenty initial protocol proposals (P4P, infoexport, ATTP, PROXIDOR, ...). Martin Stiemerling (from Jabber): what happened to the PROXIDOR approach of sorting IP addresses in the server, abandoned? How did the merger happen exactly? Reinaldo explains the "my internet view" concept and other key concepts of the draft, there may be multiple costs between a pair of network locations. Lars: is the "my internet view" service specific? do several clients have to ask twice? Reinaldo: peers within the same group should have the same "my internet view." Lars: can you query information only related to yourself or also query information between two other peers? Reinaldo: both are possible. ?: make cost metrics more specific. Iljitsch van Beijnum: infering technical but more financial on cost. Wolfgang Beck (from Jabber): does A really need to know the cost between B and C, and would any service provider actually reveal such information? Reinaldo: there are different types of cost, not only monetary costs. Richard Alimi presented the protcol framework with clients and/or trackers querying the server and four query types. Lars: we should think what information exchange actually makes sense, not everything is necessarily to be done via an ALTO-service. Richard presented the network map, consisting of grouping of endpoints with PIDs as identifiers, for scalability and privacy reasons. ?: defining and introducing ranges is useful also for several other requirements such as bandwidth. Richard explained path rating and protocol message encoding (proposed is HTTP + REST-ful API + XML encoding in bodies). Volker Hilt: there is lots of felxibility in the protocol, this means that clients and servers need to implement many options and maybe this should be simplified. Richard: this should be discussed. Richard presented use-cases of ALTO client located in the P2P tracker and in the P2P client. Question if this should be adopted as WG item. Stefano Previdi: merge corresponds to some implementations, that's the reason for having so many options in the protocol. It should be kept flexible to allow different services. Support adoption as WG item. Lisa Dusseault: this is probably the best REST-ful design she has seen in the IETF. Fixed URLs for simplicity. Bertrand Mathieu: does not think it is a good merged document, has concerns that the information retrieved from ALTO is quite extensive. Jan Seedorf: has concerns with the workload for ALTO servers caused by queries with multiple source network locations, risk of easy DoS attacks. Richard: the resulting answer matrices can be pre-computed and should not change that frequently. No hum on WG adoption, further discussion referred to the mailing list. Feedback-based Client Protocol ------------------------------ Zoran Despotovic presented a proposal complementing existing protocols with feedback mechanisms from a client to server. No questions nor comments. ALTO Server Discovery --------------------- Marco Tomsu presented the draft that is mainly a merger without much new technical content. Next steps are adopting the draft as a WG document. David: what is really the information needed? what does really need to be standardized? ?: are different versions considered for DHCP and in general? Marco: yes. No hum on WG adoption. BGP-based ALTO Service ---------------------- Zoran presented a draft that proposes BGP as the source for locaility information used by an ALTO-server, identifying the relevant BGP attributes which could be used. David: thinks this is an interesting direction. Stefano: understand usefulness of BGP but finds the approach dangerous because it uses different semantics, may have impact on actual BGP use.