[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
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.
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.
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!
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.
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
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.
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.
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.
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. |