ALTO WG Meeting Notes IETF 74 Agenda - Vijay: - 4-5 discrete solutions for a protocol * Discuss the mechanics here * Discuss merits in overflow session Problem Statement - Eric - out for 3/4 year, stable - no discussion on the list Vijay: this chartered item -> hum: adopt draft? result: good consensus ??: none of the drafts appear of the WG list * put all alto documents on the Web page? Jon: intentionally so Cullen: only WG drafts appear on list/web page Requirements - Sebastian - changes: * terminology updated * reqiremnets about alto client protcol * removed too specific itesm - sec 4 + 5 new - section 2: framework architecture - subscrion of requirements "compliance" * should there only be one client protocol or should wording say any client protocol should comply? Jon: should/can there be multiple protocols Lisa: Jon: assume to converge on one protocol but who knows ??: Maybe be another protocol in future - requirements for error handling/overload protection - Lars: client protocol must use TCP - server should be able to tell clients they are overloaded Anja: must use TCP in error case or always TCP Sebastian: always TCP requested by transport area Anja: there are usecases for UDP Martin: UDP should not be regarded as transport protcol. Have very good reasons for not useing TCP. Does not see the reasons. Anja: TCP 3-way handshake is overhead Sebastian: take this offlien - discovery - missing: how does a third party server find alto server on behalf of a distant resource consumer - security - host location attributes - client needs to have a way to express client - how to move forward: wg should define initial set of attributes. - define registry: register future attributes - existing drafts contain 3 types: CIDR, AS, Group ID - question: how likely is it to come up with additional ids Ted: will need more. AS has many things in a routing system. If someone wants exhaustive list should be able to do so. Ted: 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 Seb: inside protocol specification define groups Ted: requirements for mapping protocol should belong in protocols specification ??: AS number is not suefule without knowing what it means to you. Need to add attributes. Stanislav: protocol should extensible. Should be obvious how to add infos. No need to define exhaustive list. Just list to get started with. Richard: Important to have flexible IDs. Need flexibility here. - rating crieteria - server expresses recommendation. - List of rating criteria that have been proposed. Initial list. - Cleaned up document - Next steps? Lisa: do not publish it soon. Things that seem reasonable may turn out to be difficult. Keep it editable. Sebastian: is this right level of abstraction ??: multiple protocols will not help WG. Having new versions seems ok but not having multple protocols. Dave: requirements statement has challenge to distinguish between what and how. This is the case here. TCP is how. What are the decisions for TCP? What are the desires - then make decision on what meets desires. Similarly criteria list is not is not requirement. Instead say there needs to be an extensible critaria list. Stanislav: reqiurements should be wg document but should remain editable. Enables us to change requirements if needed. Jon: would this be a good baseline to start with? Is there another req document? -> hum: take this doc a wg item? good consensus. Vijay: has more slides to present - Activity on alto drafts: - lots of drafts before the deadline. - submit throughout the cycle! ALTO P4P Protocol: Richard - merged P4P/Info export - objective: basic concept - provide info to p2p apps to provide better service - info to client and tracker - my internt view - network location plus cost - alto query response defined in simple way - query: set of source, set of destination, cost type - response: numerical values/ranking Martin: why mumerical and ordinal Richard: need this: 2nd can be almost as good as first or very bad - architectural issues - how to specify sets of source and estination - privacy, - source/detination grouping - source group: locations with similar alto costs from other locations - destination: - view: support aggregation - gropuing benefits - improves scalability - helps privacy (masquerading) - key design features - instantion of proposed architecture - transport based on http - availability, - decouple from htto: evolve independently - ALTO Network Information: the interfaces - get network map, cost map - Inerface Descriptior - alto response may spicyf a rule - Example - clients gets information and can cache it - Example 2: - alto client in p2p client - iterface description returns info for pid1 - client gets info for pid1 Comparison - 6 attributes - lots of similarities - there are differences - come back to this slide at the end Proxidor - Stefano - Intro - Merger of 3 proposals plus 3 implementations - Protocol is similar even though there were differences in algorithms - Model: client/server - client in p2p app or other component, server: alto server based on ranking, servers can act as client to communicate btw. servers) - Messaging - All protocols based on TLV enconding - flexible, simple, extensible - Query/response based protocol - Messaging - content - PSL: proxidor source list - PTL: proxidor target list - Ranking System - Ranking system based on: topo info, policies, resource util - Sources: routing databases, extensible to resource-state, app network state, ... - P2P neighbor selection: - client sends list of notential neighbors - server ranks list of IP addresses based on ranking criteria - Summary - Next step: - we already have multiple implementations - difficult do include all requirements into one protocol - need to come to agreement on basic et of protocols - then work on extensions as needed for apps Stanislav: p2p clients are not going to send ip lists to a server. Vijay: will be discussed in overflow session. Stefano: reality - there are apps that do this. Proxidor Use Case - Anja - Legal p2p apps deployed will send lists to server - server features: - scaleable architecture (multithreaded - two levels: internal vs. external topology - Implementation - Performance study: - external routes: 67000, ... - Minimal memory requirements, 4 threads: 27000 requests for seconds, - Packet loss: less than 0.4% Richard: pplive: 2-8 million requests per second. Lots of systems to support this. Anja: these numbers are across ISPs not for a single ISP H1/H2 - Martin - Purpose of H1H2/H12 drafts - no real protocol yet - describe information models - Where we are - Players in space: users, trackers, p2p software vendors, network operators - not all are present here: may limit view - H is for Hemispheres - H1: p2p apps - H2: netowrk operators - How to bring them together - Communication Model - Client Server - H1 Model - Request: no info, Response: generic guidance - H2 Model - Request: some info (e.g. client list), response: ranked list - H1/H2 server client model - client cna staty his way of operating - server replies with accepted set - does not solve problem - H12 model - client sends some info (IP address, prefix, ...) that it likes to disclose - server replies with specific guidance: answer can be 1:1 for request, can be broad or can be narrow - Conclusion - each side can tune level of detail Ted: H12 model: allocated IP address space e.g. v6 Presume: can you use record route to use .. Info hiding seems to be broken Martin: Q2: yes you can always use traceroute to find out Q1: IP addresses are one example - we're just trying to get this going Service Protocol for ALTO - Saumitra - Goals: look at ISP and peer performance - provide apps with info to perform better - info needed to assist peer selection - common framework for info exchange - Entities in ALTO system - ALTO service providers, ALTO Clients, ALTO Aggregators - Assumption - protocols opverats over single interface - Discovery - get config document from an ALTO server - Use out of band mechanism: eg. DNS SRV, - Config Document - xml doc - e.g. what metric is supported: latency, distance, bandwidth - Config Doc - which metricts should be standardized - should be extensible - Message Format - Message Context - LocationQuery, LocationResponse - Host Location Attribute IPv4, IPv6 address, ... - Guidance Query - source hla, precision needed, metrics, list of destinations - Guidance Qury - object id - Response - List of metrics - Example use - Lots of synergies with Richards proposal Server Discovery - Yu-Shun Wang - ALTO Discofery - Survey field and evaluate requirements against available solutions - Discovery Metrics - We stay at high level - Once we progress we get to more details - Who is doing disovery: peers, trackers,.. - Service Deployments - ISP centric, application level, trusted third parties - not all clients are in local network - Single server or distributed service. Does not matter - user rendezvous point - DHCP - happens during attachment - does not work for tracker based discovery - NAT box needs to relay info - DNS - well know name/port or SRV record - need to know name (pre-discover domain anme) - Multicast - NAT box speaker change -> Habing Song - Disvoery by Peer (DHCP & DNS) - DHCP to retrieve service name of ALTO service - Use DNS SRV query for address information - Discovery by Tracker - get ISP/AS info of its clients (e.g. IANA database) - tracker sends DNS SRV query to retrieve address info of alto server for client - Manual configuration - Serve info - Concerns - Load balancing - Wll known port - IP cange of ALTO servers - Next steps - merged Id - ??: pros and cons slide of DHCP slide: - ??: look at work in geopriv - need to look into this in more depth - Jon: lots of work has been done - Lisa: discovery is a big problem, resource and service discovery are different, app area presentations, all easy - ?? look into composite approaches, evaluate methods - Jon: is this a promising direction - ??: architectural question: query response protocol. But topology changes and link goes down. Nothing in the reqs about notifications. What are the implications about this. Is this a discussion for now. - Jon: not a discovery question. Nothing an avalance restart in requ. Take question offline - Eric Hammer?: Separate between ow you find a location and how you describe service P2P Localization by Alias Tracker ATTP - Yunfei Zhang - P2P apps > 50% traffic in China - Problems - low performance ,... - ISP Cooperation betwen ISP and P2P poivder - how to use topology - prefer P2P apps sending ip addresses and return a response - Advantage of 2nd option - operator independece and privacy - full use of operatofs knowledge - no burden for p2p apps - Vijay: context - no protocol but in solution space - ATTP - Alias tracker controlled by ISP cooperates with org tracker - resource website publishes popular resource info - ATTP Process - peer list - Strategies of Alias Tracker choosing seed nodes - select according to network conditions. - according to seed node cpapbilities - according to peering and economic relationship - Conclusion - specify tracker cooperative mechanism between ISP and service providers - Next Steps - Interface between local and org tracker - application agnostic solutions - Problems in current scope of ALTO - local tracker and org traker interface, caches - Stanislav: are you replicating an external website with torrents and are reording torrents? - Yunfei: org tracker replaced by inner tracker