<<alto_notes_Jan_Seedorf.txt>> Dear all, Attached are my notes from the ALTO session last week at IETF-73.
Kind regards, Jan
ALTO Session at IETF-73 Tuesday, 13:00-15:00 Notes, Notetaker: Jan Seedorf 13:00 -- Chairs present Agenda, no objections -- Lisa presents WG status: history of the WG (P2Pi workshop), since IETF-72: narrowing down of the scope of the WG, chartered as WG before IETF-73, current work is problem statement, requirements, and solution space; no questions from the audience 13:09: Aaron Falk talk about IRTF p2prg -- p2prg has a new charter (draft form) -- wiki is being maintained for this working group 13:12: Enrico Marocco presents the ALTO problem statement draft -- version 3 with all comments from Dublin included -- problem is to provide applications iwth information to perform better-than-random peer selection -- presents changes from the previous version, e.g., replaced the term "oracle" -- new terminology section -- solution considerations include potential ALTO service providers, user privacy, topology hiding, coexistence with caching solutions, and protocol extensibility -- no questions from the audience -- Jon Peterson asks for comments from the audience -- ??: potential solutions should not be part of the problem statement, what are the privacy consideration exactly? -- ??: likes the document -- ??: document includes not only problem statement but also applicability issues, suggests to rename the document accordingly 13:25: Sebastian Kiesel presents the requirements draft -- terminology has been aligned with problem statement draft -- changes since 00-version: more precise wording, removed implicit assumption of a "sorting oracle" solution -- still do be done: section on overload control -- next steps: requirements are very general, should be confined more in the future; definition of a "core set" of attributes for expressing preferences -- ??: are there assumptions regarding the protocol for querying the ALTO service -- Sebastian: currently not -- ??: concerns about the process of requirements being presented a week after the WG has been accepted, no time to read the draft -- Jon Peterson:`how many people have read the document? Answer: many people in the room -- Hannes Tschofenig: requirements docs are a waste of time, delays everything but does not produce anything -- Ted Hardie: the document needs some work, many things are implicit but not explicitly mentioned, suggests to state requirements more explicit -- Dave Crocker: seems to be a tough topic, people need to be in sync, suggestion: step back, the problem needs to be understood better before continuing with requirements -- ??: too early for a requirements to be authorative -- Hannes Tschofenig: requirements docs are not of much help, what are the really challenging questions?, this should be in the doc -- ??: dislikes requirements docs, understant what the problem really is first -- Jon Peterson: requirements are in the charter -- Vijay Gurbani: problem statement needs to be understood more and discussed on the list to establish a common ground -- Vijay Gurbani: authors of the requirements draft should talk to the people actually deploying solutions -- Daryl Malas: likes requirements docs, they help to frame the path of the WG -- Stanislav Shalunov: it is ok to dive into solutions and then to revisit the requirements 13:47: Richard Yang presents "P4P Design and Implementation" -- two kinds of P4P portal 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 -- question from audience (by ??): does each ISP run its own location portal service? Answer: Yes -- Anja Feldmann: who would use such a service? Answer: so far envisioned to be used by client -- 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) -- Ted Hardie: suggests to use existing mechanisms for a "looking glass" on the Internet 14:00: Richard Woundy presents Comcast's Experiences In a P4P Technical Trial (draft-livingood-woundy-p4p-experiences-02) -- first P4P trial over cable infrastructure -- results: P4P improved download speeds, was effective in reducing inter-domain traffic, Comcast believes P4P has merit and will continue working on this -- next steps are more trials -- ??: does the PNA schema use P4P technology? Answer: No, but it is comparable 14:15: ?? presents on "ALTO Information Export Service" (draft-shalunov-alto-infoexport-00) -- protocol overview: ISP prepares ALTO information, application dÃscovers the service URL and uses http to fetch ALTO information from service (discovery mechanism out of scope) -- format is: type designator (asn or cidr), AS number or IP prefix, priority value -- key concept is that P2P application should not choose peers solely from the preferred set from the ALTO service -- there are different approaches for mapping IP addresses to ASNs -- there are different BGP looking glasses available in the internet which may return different results -- there are some other related issues -- Richard Barnes: check out work done in SIDR WG which work on verifyable mapping -- Anja Feldmann: which amount of data will a client download each time it contacts the alto service? -- answer: no limit as a matter of principle -- Anja Feldmann: you said you want to download the full routing table ... how much data is that? -- answer: dont know. depends on isp how coarse -- Stanislav Shalunov: 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 -- ??: what kind of information is needed to share is important rather than the format 14:29: Stefano Prevedi presents on "Routing Proximity" -- idea is leveraging routing databases (ISIS, OSPF, BGP) for computing proximity services -- such routing databases are well-known, have very good proximity information -- there is a need for a protocol supporting routing-based proximity -- Jon Peterson: is there a draft? answer: no, but maybe in the future -- Ruediger Volk: from the operators point of view probably some additional information is relevant -- Richard Woundy: the routing topology changes over time, the information should be smoothed over time -- answer: leveraging the routing layer means just using this information for aggregating it for the ALTO service -- Anja Feldmann: two different approaches to the whole problem, a) is to give the client information without considering network dynamics, b) is to consider network dynamics 14:44: Saumitra Das presents "A Multi Dimensional Peer Selection Problem" (draft-saumitra-alto-multi-ps-00) -- ALTO should define a common framework for peer selection in P2P systems -- inputs for peer selection come from the peers and from the network: peer input is not enough -- also, ISP input is not enough: ISP input may lead to ISP cost reduction without improving application performance -- applications should make decisions on both inputs (peer and network) -- multidimensional ALTO: several ALTO services are available to the application and can be considered in peer selection (each of these ALTO services may have a different goal/background) -- ALTO query and response should be extensible to enable a variety of peer selection services -- Stanislav Shalunov: the ability to publish information into an ALTO service is not necessarily an incentive for deployment -- ??: does the WG want a generic protocol without saying what the information exchanged is or rather a more specific protocol which exchanges specific, useful information; this seems like a key choice for the WG -- answer: generic does not mean that the meaning of data exchange should not be discussed
_______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
