Meeting notes from ALTO Working Group meeting, IETF73, Minneapolis November 18, 2008, 13:00-15:00. About 180 attendees This report is a distillation of the detailed meeting notes taken by Jan Seedorf and Volker Hilt. Chairs: Jon Peterson, Vijay Gurbani and Enrico Marocco Agenda Bashing -------------- Vijay Gurbani presented the agenda, asking if there are any objections to the agenda. No questions nor comments. Status of the WG ---------------- Lisa Dusseault presented the history of the WG (P2Pi workshop). Since IETF-72 scope has been narrowed down (now basically focused on making better than random selection decisions), chartered as WG before IETF-73. Current work is problem statement, requirements, and solution space. ALTO service can come from any different places, not only ISP. P2PRG being rechartered to cover also alto-related topics (P2P pricing, getting information from routers, etc); if WG is not certain about something, go to RG. Vijay, Enrico, Jon will be WG chairs. Aaron Falk talked about IRTF P2PRG. Volker Hilt and Stefano Previdi have put together a new charter (still draft) to cover a wide range of topics. A wiki page is being maintained. Model will be: IRTF partner with WGs in IETF - things that are not baked for standardization sent to IRTF to come back to IETF. Questions/comments: Vijay Gurbani: feel free to talk to the chairs or to Aaron if you have interest in topics fitting in the IRTF RG. Problem Statement ----------------- Enrico Marocco presented version 03 of the problem statement draft, which reflects all comments from Dublin. Problem is to provide applications with information to perform better-than-random peer selection. Main changes include: do better than random (vs. optimal), optimization may be localization but can also be something else, replaced term "oracle". Added a Terminology section. Added solutions considerations section discussing potential ALTO service providers, user privacy, topology hiding, coexistence with caching solutions, and protocol extensibility. Questions/comments: Jon Peterson: is this going into the right direction? Vidya Narayanan: solutions considerations should not be part of the problem statement, what are the privacy consideration exactly? ALTO is voluntary, no one can force users to disclose information if they do not want to. Enrico: if we define an interface that requires disclosure of sensible information, clients won't use it. Roni Even: like the document, but would move solution considerations into requirements. Yushun Wang: document includes not only problem statement but also applicability issues, suggests to rename the document accordingly. Eric Rescorla: requirements should be in the requirements document, not in the problem statement. Jon: problem statement should set the scope, while requirements will have like REQ1, REQ2, REQ3. Requirements ------------ Sebastian Kiesel presented the changes from previous version: terminology has been aligned with problem statement draft, more precise wording, removed implicit assumption of a "sorting oracle" solution. Still to be done: section on overload control. Clients may not send queries very often - possibly overengineerd. Requirements are very general, should be confined more in the future; definition of an extensible "core set" of attributes for expressing preferences. Questions/comments: Leslie Daigle: are there specific requirements for transport protocol. Is XML over HTTP ok? Sebastian: no requirements for transport protocol at this time. Vidya: concerns about the process of requirements being presented a week after the WG has been accepted. This is an individual draft, what's the point of this discussion? Jon: not uncommon to propose an individual draft to see if it could meet a charter milestone. Vidya: there's been no time to read the document, and the presentation talks about deltas. Jon: asks how many people have read the document. Shows of hand are "more than expected" (in Jon's words). There is sort of an obligation to read the drafts being presented. Vidya: is there an assumption that everything but the deltas is agreed? Jon: no, it's not as WG item. Hannes Tschofenig: time on requirements documents is wasted time. Important are solution discussions. Can't treat requirements separate from solution. Group should build solution. Ted Hardie: document needs some work. Lots of things are implicit. One area is overload mechanisms. E.g. dropping messages places implicit requirements on transport protocol which is not good. Consider real requirements of transport protocols. Make all requirements explicit. Sebastian: due to history - draft assumed a specific solution. Let's postpone discussion until we know more. Dave Crocker: interesting topic. Good that there is attempt to make progress. But there needs to be effort people are in sync. Concerns about having 1st meeting talking about deltas. Culture everyone to basic requiremts. Requirements get our heads in wrong place. Too little experience. Actually only few people read and understood it and discussed it. Rethink how approach. Jon: need to come to common understanding. ??: requirements documents are ok to structure problem but it's too early to give it authority. Hannes: requirements don't provide any additional help to reader - basic requirements. What are the really challenging aspectis - usually 3-5. Consider architecture. ??: difficult is to define problem to be solved. What is the problem. Requirements fall out once you understand the problem. Jon: we have requirements in the charter. I agree that requirements are sometimes not entirely useful, but this seems a chartering issue. Vijay: hands - who has been in MIT workshop (couple). Most important question: how can you be more specific. Give requirements more teeth. Now we have depoloyments - author should talk to these people - what are their requirements. Daryl Malas: like requirements docs - helps to frame the immediate needs of WG. People will want add ons and solution will be delayed. Vendors will do own solutions. Agree on set of immediate requirments. Avoids creep. Stanislav Shalunov: sequencing of work. Requirements before solution or with solution. We should iterate between requirements and solutions. Jon: more discussion needed of this document. Maybe need to do a tutorial. P4P Design and Implementation ----------------------------- Richard Yang presented P4P portal mainly consisting of two services: location portal service and pDistance portal service. Location portal service allows an ISP to aggregate the internet address space; uses PID to denote a set of network locations. PDistance portal service allows an ISP to define the pDistance for any given pair of network locations; there can be different types of pDistance (e.g., ordinal, numerical). Questions/comments: ??: does each ISP have to define own PIDs? Richard Y.: each ISP defines own view on PID. ??: one AS is assigned to particalr 16 but for traffic engineering purposes the part is turned over to someone else. AS would have to disaggregate announcement. Some of the announcemed routes are only true if you know the hole punching routes of someone else. Richard Y.: You can do traffic engineering. Anja Feldmann: who would use such a service? Richard Y.: so far envisioned to be used by application trackers and clients. Ted: suggests to use existing mechanisms for a "looking glass" on the Internet. Comcast's Experiences In a P4P Technical Trial ---------------------------------------------- Rich Woundy presented results from last summer's P4P tial. Results: P4P improved download speeds, was effective in reducing inter-domain traffic and no increase in upstream congestion. Comcast believes P4P has merit and will continue working on this. Pando clients were made to download a 20 Mb file and four swarms have been analyzed, each with different principles: unbiased, proprietary optimization, fine grained P4P model (1180 PIDs) and course grained P4P (22 PIDs). Best results with course grained model - can't explain why. Reduction on ingress traffic 80% and usually more traffic coming in than going out -- interesting savings. Does not solve last mile problem. Questions/comments: ??: does Pando schema use P4P technology? Rich: no, but acts in similar way. ??: did you compare to other peer selection strategies (other than random)? Rich: Pando does not do random selection, it does its best to make optimal choices. ALTO Information Export Service ------------------------------- Satish Raghunath presented infoexport service: ISP prepares ALTO information, application díscovers the service URL and uses http to fetch ALTO information from service (discovery mechanism out of scope). Data format is: type designator (ASN or CIDR) and priority value. Key concept is that P2P application should not choose peers solely from the preferred set from the ALTO service (e.g. 50% from preferred and the rest from default set). There are different approaches for mapping IP addresses to ASNs and there are different BGP looking glasses available in the internet which may return different results. Questions/comments: Richard Barnes: check out work done in SIDR WG which work on verifyable mapping. Anja Feldmann: do you want to download the routing tables? How much info does client send? Satish: client does not send any information. Anja: how much info would the client have to download? Satish: up to the ISP. Stanislav: an important thing is the capability for incremental updates, the amount will depend on the ISP, expects a quantity of about 1000 records, 50 bytes each. Leslie: what kind of information is needed to share is important rather than the format. Rich: had examples in slides. E.g. 210000 for find grained. Routing Proximity ----------------- Stefano Previdi presented a proximity service based on the idea of leveraging information in the routing layer. Routing databases are well-known and have good properties for computing localization. Questions/comments: Jon: is there a draft? Stefano: no, maybe in the future. Ruediger Volk: from the operators point of view probably some additional information is relevant. Rich: the routing topology changes over time, the information should be smoothed over time. Stefano: don't pass network info to clients, instead just use it to compute proximity. Algorithms that leverage real info of infratstructure for computation are powerful. Igor Faynberg: what is meant by routing layer? Do you assume interation of application servers with routers? Stefano: plenty of possibility. Here is important to agree what is the signaling needed. Could try to come to agreement on how service is implemented but may not need to go down that path. Igor: recommend group to look at FORCES WG. Useful information can get there. Anja: two different approaches to the whole problem, a) is to give the client information without considering network dynamics, b) is to consider network dynamics. Info missing: congestionn information This would me made available to the server. Stefano: routing is only one source of information, others can be used. Jon: remember charter text on congestion. A Multi Dimensional Peer Selection Problem ------------------------------------------ Saumitra Das presented slides about various aspects of peer selection optimization. Need to define a common framework to allow information provided by both ISPs and peers. Peer input only is not enough to optimize transfer performance. ISP input only is not enough as some info needed is not available to ISPs (only interested in minimizing congestion and interdomain traffic). ALTO query and response should be extensible to enable a variety of peer selection services. Questions/comments: Stanislav: the ability to publish information into an ALTO service is not necessarily an incentive for deployment. ??: You argue we should be build an interface but not describe info at all. You have deferred the hard part. Saumitra: also solve the hard part, but there may be pieces of info we don't know about yet. ??: You are suggesting to build a protocol that is extensible and not talk about info? Saumitra: no. Jon: must be at least one interesting piece of information.