Wednesday, June 16, 2010 -- 14:00-16:00 UTC
| 14:00 | Administrivia | Chairs, 10' |
| 14:10 | Requirements | Sebastian Kiesel, 5' |
| 14:15 | ALTO Protocol | Richard Alimi, 20' |
| 14:35 | Deployment considerations | Sebastian Kiesel, 5' |
| 14:40 | v4/v6 issues | Reinaldo Penno, 10' |
| 14:50 | ALTO Discovery | Nico Schwan, 15' |
| 15:05 | Notification mechanism | Wang Aijun, 20' |
| 15:25 | ALTO and CDNs | Reinaldo Penno, 10' |
| 15:35 | Open Discussion / Wrap up | WG / Chairs, 5' to 25' |
This report has been distilled from the detailed meeting notes taken by Jan Seedorf (attachment:alto-notes-js.txt) and Eric Burger (attachment:alto-notes-eb.txt).
Advisor Area Director: Peter Saint-Andre
Chairs: Vijay Gurbani, Enrico Marocco and Jon Peterson
Participants: Adrianus van Ewijk, Aijun Wang, Diana Kramer, Damien Saucez, Enrico Marocco, Martin Stiemerling, Eric Burger, Jan Medved, Jan Seedorf, John Leslie, Jong Min, Kai Lee, Michael Scharf, Nico Schwan, Jean-Francois Peltier, Reinaldo Penno, Rich Alimi, Roni Even, Sebastian Kiesel, Stefano Previdi, Sun Xianghui, Tsuyoshi Momose, Volker Hilt, Xuan Zhang, Richard Yang
Slides: http://www.standardstrack.com/ietf/alto/alto-interim/alto-agenda.pdf
Vijay presents agenda.
No questions nor comments.
ALTO server discovery is a chartered item, only one survey draft out yet, hopefully being updated before IETF-78. Add deployment considerations to the charter as agreed in Anaheim. Also need to adjust protocol work items according to current document structure.
Richard Alimi: ALTO protocol document is getting large, maybe it should be split up. Extension for notifications is controversial at this point in time, decision on chartering other ALTO extensions postponed for now.
Chairs and AD will negotiate re-charter milestones.
Draft: draft-ietf-alto-reqs-05
Slides: http://www.standardstrack.com/ietf/alto/alto-interim/alto-requirements.pdf
Sebastian Kiesel presents the updated requirements document. Since IETF-77 only one new requirement: "target audience" in ALTO reply. Does ALTO follow DNS theory, where all servers deployed in an ISP give same answer to same question, or if ALTO will follow DNS practice, where a regional ALTO server may give a regional response that can differ from an ALTO server in another region? Depending on this, discovery becomes an important consideration in the development of the protocol.
Richard: does this put discovery information into the ALTO protocol? Proposal to move some text from requirements draft to deployments draft if the latter becomes a WG item; Peter: the requirements document is looking more like two documents, a requirements document and a rationale / FAQ document. Should we publish the requirements, since they seem stable? Counter-arguments, to keep the requirements document a live document, were that we expect to refine requirements as we get implementation experience. In addition, the CDN exercise may introduce new requirements. Moreover, it is more important to have correct requirements than to have a bone-headed requirement memorialized in an RFC that people than say, "well, we have to implement that because that is what the RFC says."
Vijay: there was a decision in the past to keep the requirements draft an open document for some time. Sebastian: not many changes recently in the requirements draft. Richard: suggests to keep the requirements draft living for some more time. Eric: agrees not to publish it quickly, it is easier to keep it alive for some time.
Draft: draft-ietf-alto-protocol-04
Slides: http://www.standardstrack.com/ietf/alto/alto-interim/alto-protocol.pdf
Richard presents the updated version of the protocol draft. Lots of discussion as to whether we need to take the current proposed protocol, which is REST-like, to be a full, RESTful protocol. Arguments for making the protocol fully RESTful include the fact the protocol will be much easier to extend and there are a lot of tools available, such as WADL. However, no one really could articulate near-term benefits. Editor's proposal is to remove the term REST from the protocol. Action item is to solicit someone to write an I-D describing what a full RESTful API would look like, so the work group could better make the cost / benefit tradeoff.
Discussion among several participants lead to the proposal from the authors to keep the protocol structure the way it is (REST-like), but to also have a separate draft that more concretely describes what the protocol might look like if it were more of a REST-ful protocol. With such a draft, we can more easily judge what the benefits of a REST-ful approach in our context are and whether it makes sense to go that direction.
Issue: should the protocol split a server query response into a simple server list and a separate server capabilities list? Jon: suggests to keep a single response, in the ALTO document (as opposed to mixing in some HTTP headers).
Note: Jon's suggestion was probably in response to the issue of keeping the version number in ALTO Client-Server protocol vs. putting the version number "below" the ALTO Client-Server protocol such as in HTTP headers or the discovery protocol. Jon was (probably) supporting the former option -- should check the audio.
Issue: status codes (numeric) or names (text) - everyone uses text for debugging. Do we need numeric codes at all? Benefit is a future binary version of ALTO would benefit from having the numeric codes defined already. Taking to the list.
Issue: Inter-ISP PID: Timed out - take discussion to list.
Draft: draft-stiemerling-alto-deployments-03
Slides: http://www.standardstrack.com/ietf/alto/alto-interim/alto-deployment.pdf
Martin Stiemerling presents the updated individual draft. Goal of the draft is to have a document for any kind of deployment issues, e.g. overloading, also to have a document to answer questions for people new to ALTO.
Richard: it is an important draft, but wonders if there is a need for splitting the draft into considerations for a) ISPs/network operators and b) application point of view.
No further comments, chairs and ADs will decide on how to proceed with chartering a work item for this (hum at IETF-77 for charting an item for this), then the draft can be adopted as a WG item.
Draft: draft-penno-alto-ipv4v6-00
Slides: http://www.standardstrack.com/ietf/alto/alto-interim/alto-ipv4ipv6.pdf
Reinaldo Penno presents the updated individual draft. The issue is where to place an ALTO server (private or public network side)?
No feedback nor discussion, further discussion postponed to IETF-78 meeting.
Drafts: draft-song-alto-server-discovery-01, draft-kiesel-alto-3pdisc-02
Slides: http://www.standardstrack.com/ietf/alto/alto-interim/alto-server-discovery.pdf
Nico Schwan presents the updated individual draft. Discussion on user configuration requirement (user needs to be able to manually choose a specific ALTO server).
Sebastion: this is an important and necessary requirement. Richard: agree.
Further discussion postponed to the list.
Draft: draft-sun-alto-notification-02
Slides: http://www.standardstrack.com/ietf/alto/alto-interim/alto-server-notification.pdf
Aijun Wang presents the individual draft. Basically the draft proposes a notification mechanism for servers to actively push ALTO information to clients.
Enrico: ALTO is chartered such that the protocol does not care about real-time congestion, this draft seems to propose frequent ALTO information updates (also for congestion control), authors should explain how the draft fits the charter.
Draft: draft-penno-alto-cdn-00
Slides: http://www.standardstrack.com/ietf/alto/alto-interim/alto-cdns.pdf
Reinaldo presents an individual draft outlining how ALTO can be used for CDN optimization. Discusses CDN HTTP redirect with ALTO and CDN DNS resolution with ALTO.
Richard: does the CDN use case require protocol changes or is it more about deployment considerations? Reinaldo: draft will be revised for IETF-78 based on the many comments received.