ALTO protocol |
ALTO server discovery protocol |
Deployment considerations |
Incremental updates |
Caching and subscription |
Cost schedule |
Multi-cost ALTO |
i2aex BoF considerations]
Meeting notes from ALTO WG meeting, IETF 83, Paris, France
Thursday, March 29, 9:00-11:30
About 100 attendees
This report has been distilled from the detailed meeting notes taken
by Dave McDysan and Sreekanth Madhavan
Chairs: Enrico Marocco and Vijay Gurbani.
Meeting materials: slides, MP3 (5m:04s, 2.32 MBytes)
Enrico presents the agenda for the meeting.
No questions nor comments.
Martin Stiemerling will be the new responsible area director. Welcome,
and thanks to Dave Harrington for his help in the past two years.
Martin: will be responsible for the WG and for all docs, except for
those I am co-author.
Meeting materials: slides, MP3 (14m:32s, 6.65 MBytes)
Rich Alimi presents the latest version of the protocol document that
should address all outstanding issues. Most changes are to add
Enrico: would like to hear from extension proposers if extension
capabilities are sufficient for their cases.
Sabine Randriamasy: change from Number to JSON Value is
good. Multicost is not covered, but is OK for the base
protocol. Will be challenging to extend base protocol without
changing media types. Rich: could be addressed by adding another
capability for an array in the extension, or define another MIME
type. Martin: are these extensions to ALTO or clarifications of data
type? Sabine: would like more generality in the encoding. Enrico:
are options Rich mentioned appropriate for multi-cost? Wish to avoid
complexity. Sabine: I need to write down how to do this. If defining
arrays is too complex and want to avoid adding MIME types. Enrico:
conditionally call this issue closed unless Sabine can make a
concrete compelling case on the mailing list by next week.
Martin: can an extension be added easily? Rich: other methods
exist. A JSON Value means that an array can be encoded. Issue with
server not supporting all cost types in a multi-cost scenario.
Martin: Propose leaving this out for this version. Discuss other
means of how to achieve desired function.
Enrico: issue WG last call at end of next week. Call for review
volunteers. Vijay: base/benchmark document for alto wg. Emphasizes
the call for review volunteers.
ALTO server discovery protocol
Meeting materials: slides, MP3 (17m:57s, 8.22 MBytes)
Martin presents the updated version of the server discovery draft.
Rich: "Cannot redirect" means forbidden or should not? Stefano
Previdi: some ALTO servers redirect clients to other alto
servers. For example, in a CDN context. Statement is too extreme.
Martin: the document needs to be general. Will reword statement.
Haibin Song: need to make "closest" term clearer.
Open issue for obtaining host name from IP address. Reverse DNS lookup
has too many problems to be used.
Rich: do current alto implementers use DNS? Is there a solution
approach without DNS? Martin: ALTO client sits on end system,
tracker is not directly on the client and need to find server for a
specific client. Jari Arrko: reconsider his draft from last meeting?
Jon Peterson: surprised if ALTO client in CDN request router needs
to discover ALTO server. P2P is different, but what we are seeing is
that there is not a lot of market drive for P2P. Infrastucutural use
cases do need server discovery. Martin: extensions for DHCP and PPP
appear promising. Stefano: don't need discovery for controlled
environments. Only needed at bootstrap, not critical, does not
require standardization. Vijay: agree with prior points. Do DNS Ops
objections stop this approach. Martin: woud be good to document the
DNS Ops objections. Rich: revisit earlier approach ALTO client
discover server and pass this information to the tracker. Jon:
emergency services analogy for a similar problem. Would need an
inter-area BoF. Works only sometimes.
Meeting materials: slides, MP3 (2m:12s, 1.00 MBytes)
Martin presents the updated version of the deployment considerations
draft. No comments even though much new text. If no interest, then
possibly remove as wg item. Please review and comment on the list!
Stefano: deployment only beginning and this could be reason there is
little discussion. Closing this draft now would be premature.
Meeting materials: slides, MP3 (15m:37s, 7.14 MBytes)
Vijay presents the draft dealing with possible mechanisms for
incremental updates on behalf of the authors that couldn't make it to
the meeting. More discussion on the list is needed.
Proposal for new MIME type is not mentioned in the draft. (It
should be added).
Rich: JSON Patch. Would like to see how large a JSON patch needs to
be and how much compression this provides.
Stefano: an option is missing - implementing BGP LS draft to
advertise an alto topology. May be worth investigating. Could be
used client-server, server-server. Often clients do not need
topology information. Vijay: Requested that Stefano post this draft
and initiate discussion on list. Stefano: ALTO server uses BGP, IGP,
other data to create network and cost maps. Vijay: using BGP between
alto servers makes sense. Concern with client-server use of
BGP. Stefano: base protocol works well for ECS -- does not work well
for maps. Jon: not giving up on idea that something (easier) than
BGP could be used as being discussed in cdni as well. Jan Medved:
tried ALTO and BGP-LS and ended up using BGP-LS. BGP-LS best for
partial updates. Vijay: encourages list discussion.
Caching and subscription
Meeting materials: slides, MP3 (11m:14s, 5.43 MBytes)
Sreekanth presents a new draft dealing with caching of ALTO
Rich: agree with Martin's suggestion to determine addresses for each
PID via an additional identifier. Works with existing
infrastructure. Sreekanth: becomes more complex on server since each
additional identifier has additional URI.
Meeting materials: slides, MP3 (9m:57s, 4.55 MBytes)
Sabine presents a new draft (previously incorporated in the multi-cost
draft) about and ALTO protocol extension for cost schedule.
Rich: why is timezone needed? Why doesn't UTC work? Sabine: UTC
could be used. Agree. Martin: UTC better to use in event of Daylight
Savings Time. Rich: suggested review with DTN application
developers, e.g., Dirk Kutscher.
Meeting materials: slides, MP3 (18m:20s, 8.39 MBytes)
Sabine presents the new version of the multi-cost draft, from which
the cost schedule part was extracted.
Rich: how do constraints work with multi-cost? Sabine: have not
thought about in great detail. Will need to play with arrays of
constraints. May constrain how many cost types a client may request.
Rich: If non-trivial changes to constraints are needed, then this
possibly should be a separate MIME type since this is quite
Lars Eggert: will all of this information be needed by
operators? Enrico: discussed during i2aex BoF. At least in
controlled environments of CDN and DC very accurate info could be
used. In P2P or between operators concerns about trust and privacy.
Martin: note there is an IPR declaration on this draft. Can you
clarify? Sabine: there is IPR -- not competent to answer - see alto
status page. IPR on ALTO status page applies to both multi-cost
and/or cost-schedule mechanisms.
Martin (as AD): good that people looking at extensions, but not
enough people are reviewing and getting the base version completed.
Enrico: 80/20 problem, much interest earlier and people are bored
with the base and looking to extensions and the future. Jan Seedorf:
have a draft proposing use of ALTO in cdni and decision was made to
advance tat work in that WG. Some of the proposed extensions are
quite useful. Enrico: Jan sounds like he's candidating himself as a
WGLC reviewer, to speed up the publication process. Jan: couldn't
hear the last comment from the chairs, room is noisy.
Rich: what about scheduling another interop event as a way of
finalizing the base ALTO protocol spec?
i2aex BoF considerations
Meeting materials: slides, MP3 (38m:46s, 17.70 MBytes)
Vijay presented a recap of the i2aex BoF.
Enrico (as individual): significant interest. ALTO to be more real
time. Other proposals (BGP, XMPP) and will be handled by ADs, out
of scope for alto. Write down concrete proposals. altoex mailing
Lars: not at i2aex. Originally, ALTO intended to expose
meta-stable information over longer time scales. Information
returned would be the same for each client. Starting to look like
ADA or a kitchen sink of capabilities.
Jon: positive response at BoF doing this in alto. Communicating
information of protocols outside of ALTO and using ALTO to deliver
Jan: Trust is a key component as mentioned in the BoF.
Ying Ge: Chinese DC enterprise has a system to do much of this, she
is requesting they participate in ia2ex.
Dave: i2aex DC preso in Bof involves a non-IP name space, PID
concept of alto may be useful. Often some administrator modifies
infrastructure (not the application) and there is a need for
application to be informed of this change (not requiring the app to
poll). The problem is a distributed database with incremental
updates with a range of possible keys. Need to rename BGP NLRI, it
is now a Normative List of Related Info -- not Network Layer
Reachability Info. Stefano: suggest doing requirements analysis for
a range of applications instead of starting with a narrow focus of
p2p. Approach in more systematic way.
Lars: another WG doing this PAWS. Suggest folks looking at extending
alto to solve PAWS problems.
Jan M.: topology and ease of access (HTTP) and data model should be
separated. Similar to netconf model - base protocol and detailed
data model in netmod.
Stefano Picconi: what is overlap with i2aex and a cloud (eg. DC
resources, P2P, etc) broker application? Want to find most suitable
cloud meeting these characteristics. Enrico: Yes, beside the term
"cloud" not many here like, there seem to be some overlap.
Rich: incremental updates and notifications are technical changes
needed to alto. Alternative PID definitions may be needed for DCs,
and this work could be separated.
Martin (as AD): discussion expands from network-related information
but now includes computing-resources as well.
Dave: mentioned NetStitcher/ Sabine's summary as a good example of
joint usage of network and copmpute/storage current and predicted
future state. Agreed with Stefano to approach in systemic way.
Rich: not all use cases need not be done in alto. Suggested that
problem statement, use cases, requirements could be done.
Martin (as AD): good to see interest, and operators standing up at
the mike. Could see some CDN related things being done in alto. On
the DC side there may be something in alto, he will need to think
about it. Encourage folks to contribute to i2aex mailing list.