[Agenda | Requirements | ALTO and IPv4/6 transition | ALTO protocol | ALTO H12 protocol | ALTO information redistribution | ALTO server discovery | ISP friendly live streaming | Deployment considerations]

Meeting notes from ALTO WG meeting, IETF77, Anaheim, CA
March 22, 2010, 17:40-19:40.

About 100 attendees

This report has been distilled from the detailed meeting notes taken
by David Bryan and Volker Hilt.

Chairs: Jon Peterson, Enrico Marocco and Vijay Gurbani


Presenter: Chairs
Slides: Agenda
Audio: MP3, 7min:30sec, 3.50 MBytes
Vijay presents agenda and status of the WG. No questions nor comments. Wine and a knit cap for Lisa, the advisor AD that made ALTO get chartered. The WG is infinitely grateful: thanks Lisa! Issue tracker experiment Vijay presents the issue tracker experiment. The tool is available on the wiki. It can be useful for organize issues that get raised to WG, mostly authors have posted issues so far. Group is encouraged to use it and leverage it to help advance the working group. This is an experiment -- chairs would like feedback on how it is working.


Presenter: Richard Woundy
Slides: Requirements
Audio: MP3, 14min:08sec, 6.50 MBytes
Rich Woundy presents requirements draft. New text about information disclosure: new section 7.2, new req ARv04-49, that clients can't be assumed not to redistribute. Not doing some sort of DRM. Open issues and planned changes: should we add an attribute for provisioned bandwidth? Are there special requirements around per-user requirements? Need input from the WG. Richard Alimi: per user attribte - is this tied to IP address? Asked by another peer? Can we differentiate between questions about the user's own information vs. asking another user on the provisioned bandwidth? Martin Stiemerling: so we need to write down the privacy issues, and is this the right place? Jon: since they may have implications these issues should be document in req document. Martin: since I am one of the folks who wants provisioned bandwidth, it allows this to be used for a rating mechanism. It may not be reported back, but may be used to allow clients to refine requests to the server "give me a client with bandwidth over X". Richard: still allow attack with binary search to obtain the exact bandwidth. Jon: this is a slippery slope. Lars will be unhappy if we start trying to guess how much is still available. Syed Ali: support use of JSON. Extensions - ISP can file localized policies. Rich: requirements does not discuss encoding. Syed: extensibility is a requirement. Rich: send requirement for extensibility to the list.

ALTO and IPv4/6 transition

Presenter: Reinaldo Penno
Slides: IPv4/6 transition
Audio: MP3, 4min:34sec, 2.09 MBytes
Reinaldo Penno presents the IPv4/6 problem. Most co-existance tools realize NAT, NAT move from EDGE to CORE. How can we distribute ALTO info across NAT? Do maps need to contain both addresses? Hairpinning is an issue. Plan to submit a draft - contributions welcome!

ALTO protocol

Presenter: Richard Alimi
Slides: ALTO protocol
Audio: MP3, 38min:02sec, 17.40 MBytes
Richard presents the ALTO protocol. Basic concepts: network locations, network map, cost map. Protocol structure with required services (server capability, map service) and other services built on top. Protocol encoding based on JSON. REST-ful design, input parameter approach. HTTP status codes, possibly a mapping to app layer status code. Protocol versioning. Lisa: this is one option, but can also do version based on document content types. Big protocol change means new content types. Giving servers maximum control over namespace including query strings -- path elements rather than orthoginal queries is good. Questions to be answered: separate query for discovery of alternate servers? How much config info in discovery? Registry for cost types? Martin: can have entry server redirecting to others. Richard: Not just availablitly, but also what are they really good at handling -- one may do static, etc. Martin: Could also use HTTP redirect. Martin: self signed certificates: per server? Richard: Maybe a single cert for a cluster. Vijay: there is a draft talking more about handling these multiple certificats. Jon: lots of smart people trying to do certs for IP blocks -- how to slice this? Begs broader security implications. Richard: in this context, used to sign info for redistribution, can fetch public key to verify. Martin: may be better to be zone certificate than server certificate. Haibin Song: do the servers have to communicate? Interalto protocol? Richard: if there is lots of info in the the records, and you change your capabilities, you need to redistribute. Syed: in terms of the strucutre -- I like the idea to use JSON, but for validating, how will the client validate? Richard: No equivalent of DTD. What do you mean? Syed: XML Schema, more mature, signing aspects. JSON is not far along, can we use XML and convert to JSON? Richard: is this defined? Syed: there are some tools to do this conversion, allow for richer XML vocabulary. Current approach requires you to compare against document to determine it is well formed. Techniques to do equivalent in JSON are being developed, but it isn't there yet. Richard: can you send pointers to list about conversions? Needs to be simple in the common case. Syed: will bring this and other comments about this issue to the list. Please provide feedback on IPv4/6. Reinaldo: use cases would be good. Instead of saying what to encode, what to convey? Dave Crocker: is this different from issue that needs to be resolved in other groups. Is this the right place to decide? Is it different from other factors you use to decide a route? Maybe there is a need for coordination between groups. Richard: how complex do we need to get? E.g. always use IPv6? Dave: is this a decision this group can make? Richard: in many cases, this will be going to the operator to decide. May decide on complexity. Dave: that means you are deciding. How do you decide what is needed? Richard: talk to operators. Jeff Batson: this is a very big can of worms -- transition and other concerns, may be a generic endpoint identifier. Seems you can't really avoid the complexity. Rich: problems with thinking you are v6 but not really (behind a NAT for example). May be good to provide info to the user about choosing between 4 and 6 in this context. Enrico: more comments to list.

ALTO H12 protocol

Presenter: Martin Stiemerling
Slides: ALTO H12 protocol
Audio: MP3, 11min:42sec, 5.40 MBytes
Martin presents an update on the H12 proposal. The goal is to propose it as a new service, or integrate it in the ranking service. Refresh: H is for Hemispheres. H1 is he users, H2 is the operators both have concerns about info -- how to bring together. Should this part of protocol? Jon: from the chair perspective, do people think there is a need to approach ranking from a prefix perspective. Do people think this is valuable, a requirement, helpful, too complex? Richard: two properties that can be separated: 1) Allow ALTO server to say this is a prefix, here it is. 2) Filtering -- if you aren't interested in the whole map, you can get costs to a particular prefix. Wolfgang Beck: consult with operators and P2P. Haibin: Not much different from P4P cost map. Similar map here but replace PID with explicit IP prefix. Martin: don't need to put full IP address into ranking, so fits well as ranking service

ALTO information redistribution

Presenter: Richard Alimi
Slides: ALTO information redistribution
Audio: MP3, 9min:00sec, 4.11 MBytes
Richard Alimi presents a proposal for information redistribution. Changed intended status to BCP, other modifications since -01 Discussion points: recommendations to providers about when? Updating before expiration? Additional techniques? Do we want this document? Martin: I feel it might be important, and lots of talking. Not sure here or deployment considerations. Yunfei Zhang: how do you keep thinkgs consistent if information about peers on the network change? How to ensure as redistributed properly? Richard: expiration time allows them to redistribute again or go back to the server. Yunfei: if done on a DHT, sync will be very difficult. Richard: Are you advocating change to let server notify client? Yunfei: Yes. Richard: Conceptually, easy, but difficult. Draft was submitted on this, but we need to keep in mind in that is that ALTO server now needs to keep track of which ALTO clients are out there. Can also do HTTP way: if changed, ask for it. Martin Thompson: REST and HTTP used this way, there is an ecosystem for this -- can we use this ecosystem, and make responses cachable, and just rely on that. Richard: Options, but may not work if people don't have the caches deployed. May need another mechanism. Certainly an option.

ALTO server discovery

Presenter: Michael Scharf
Slides: ALTO server discovery
Audio: MP3, 9min:26sec, 4.31 MBytes
Michael Scharf presents the server discovery problem. Possibility 1: alto client is resource cosumer. Possibility 2: alto client is resource tracker. Need 3rd party queries -- callenge is multi domain -- environment. Need for further discussion. Rich: question on comparison slide. On the column of changing the application - seems they may not want to, but rapidly innovate, but also there are other constraints like mem footprint, so leveraging OS capability is good. Michael: very initial comparison. Richard: keep in mind for tracker the additional load on the tracker, so if there are many peers, the per-peer work needs to be minimal -- even DNS could be big. Haibin: some of these mechanisms may not overload, in some cases the clients can obtain the infomation and send to tracker. Tracker may not have to do discovery. Michael: yep, this is incomplete, and maybe even technically incomplete. Please send comments to the list and I will incorporate into the next version of the draft.

ISP friendly live streaming

Presenter: Fabio Picconi
Slides: ISP friendly live streaming
Audio: MP3, 14min:27sec, 6.61 MBytes
Fabio Picconi presents the case of ALTO for P2P streaming. Live streaming is more fragile than bit torrent, ICDCS paper. Martin: bandwidth may be inportant here.

Deployment considerations

Presenter: Martin Stiemerling
Slides: Deployment considerations
Audio: MP3, 3min:48sec, 1.73 MBytes
Martin presents a new draft on deployment considerations. Goals of draft is document deployment scenarios that will answer the same questions would be otherwise getting forever. Richard: in the university campus case, ALTO server could get the info from the upstream alto server. Martin: that is the point -- how do you get this, are you allowed, etc. Do people think this is useful? Reinaldo: I think it's important and like the work. Rich: Some of us a year ago thought about this, lost the information because we didn't capture. Please make it WG item so we don't loose it again. Ning Zong: in PPSP, mailing list discussion that the tracker may need to rely on ALTO, so there is some interest. Richard: some stuff in the protocol doc might fit this as well, do adopt. Reinaldo: architecture document that covered the peices. Might be worth looking at this.
Hum: are we interested in having a milestone that this document might target, that would cover these deployment scenerios? Strong in favour, none opposed.