[Agenda |
Requirements |
ALTO protocol |
3rd party ALTO server discovery |
Deployment considerations |
ALTO and content delivery networks |
Inter-ALTO communication protocol |
China Telecommunications trial |
ALTO information redistribution |
ALTO and IPv4/6 transition]
Meeting notes from ALTO WG meeting, IETF78, Maastricht, Netherlands
July 26, 2010, 13:00-15:30.
About 100 attendees
This report has been distilled from the detailed meeting notes taken
by David Bryan, Roni Even and Jan Seedorf.
Chairs: Vijay Gurbani, Enrico Marocco and Jon Peterson
Vijay presents the agenda.
No questions nor comments.
Martin Stiemerling presents the updates to the requirements
document. Editorial changes: Martin has replaced Laird Popkin. Changed
requirements since -04: Added Target audience to ALTO reply.
Question: How many people have read it? About 10 shows of hands.
Richard Alimi: Adding that information can be explicit or implicit.
Next steps: No open issues as far as editors know. Need to add much
normative text, but perhaps belongs in the deployment scenario
document if such a document is adopted.
Richard presents the updated protocol document. Default Cost: No
default cost - may cause problems with clients. Proposal: define a
0.0.0.0/0 PID.
Vijay (as contributor): Didn't we have this already? Richard: yes,
but no mechanism to specify. David Bryan : If we MUST define for all,
but RECOMMENDED to use this mechanism, how do we reconcile in draft?
Richard: may need to change to should? Will make consistent in
draft.
ALTO service ID: New mechanism to have a service ID for
servers. What do people think?
Martin: Can this be incorporated into the version information for
cost maps? Same number = same? Richard: Could do this, but would
overload the version field.
Dave McDysan: Use shared key and not private key for this purpose.
Richard: Adding the ability to let clients know data is
shared. Dave: Need to be careful sharing public key in distribution,
perhaps use a shared public key. Richard: Goal isn't encryption, but
validation. Will try to extend draft to consider this scenario.
What if updates are applied at different times? Protecting clients
against this needs to be looked at.
Simple integration path for apps looking to use ALTO presented
experimental evidence that even simple approaches based on
location-only peer selection improve performance Extension needed:
attribute indicating which PID are in an ISP. May be useful in this
context.
Martin: Why should you want this? Richard: If there is concern that
evaluating relative costs is hard, and requires contacting too much,
ISP data can be used to determine it. Martin: we can take offline.
Jon (as individual): How do we do this? What constitutes an ISP?
Support Martin's point that essentially we want to rank PIDs and use
that. Hard to define and makes me nervous.
Remaining issues: IPv4/v6 preferences? Schema for request/response?
May want a draft that sketches a fully REST-ful ALTO.
Martin: Did we talk with ipv4/ipv6 folks? Please do.
Martin presents the new version of the third-party service discovery
draft, that now is not "third-party" only any more. New version uses
DNS based and documents it.
Hannes Tschofenig: This is a repeat of thought in GEOPRIV.
Martin Thomson: Have a draft in RFC editors queue that uses this
approach. Difficult approach with no good answers. Will get riped to
shresds at calls. Martin: Glad this is out there, take to list.
Jon (as individual): Reverse resolution is sketchy. Need the other
functionality. We need to know the security problem, what's
different from GEOPRIV. We need a way to know what is the domain
name. Martin: will take this offline to discuss further.
Haibin: We define a DNS based approach in our draft to discover the
domain name.
Martin presents the updated version of the deployment considerations
draft. New structure based on the application: Using ALTO for P2P, for
CDN, Cascading servers, Known limitations, security considerations.
WG item waiting for input - authors continue to update. Shall this be
a WG item?
Richard: Support to have it WG item but currently looks like a dump
for everything which is not in ALTO protocol. Propose to divide, for
example client API is not related. Martin: Agree on API but
scenarios are better in the same document.
Richard presents the updated draft about the CDN use case. Current
scope: Looking strictly at ho you pick an appropriate server. DNS and
HTTP mechanisms. Architectures presented: HTTP redirect, DNS
resolution. Maybe ALTO server in the CDN device.
Jon (as individual): Can calculate costs from border routers to
cache, but where do you put this? Richard: ALTO server is used,
stored in CDN.
Yunfei Zhang: How do you get the information from ALTO and how used?
Richard: Current draft discusses both in some detail.
Piotr Wydrych presents a new draft proposing a server-to-server
communication protocol. Why do we need this protocol? Two ASes are
connected by transit ASes. Different costs potentially for up and
down, so how do we take this into account. Coordination of ISP
policies. Parameters and communities: Use of a community. Presented
sample dependency tree.
Jan Seedorf: Do we think that ISPs will really use this? Question to
service providers?
Richard: How do you solve the A prefers B but B not A case? What is
the solution and how do you do it? Piotr: Must peer some of the
traffic. Richard: Seems like if they already have had the business
discussion? So why does a protocol have to be used here rather than
the ISPs simply negotiate this?
Martin T.: Once the providers understand what they need to agree on,
they don't need the protocol mechanisms. Can't you simply use two
ALTO servers and consult the other server to make these decisions. I
don't see that it is needed in many cases.
Enrico (as individual): I trust you have done simulations, and have
known that the problem exists. My boss and Rich Woundy's boss may
not believe it. There may be better use to go to P2PRG and share
this evidence to let us convince our bosses there is a
problem. Maybe more important than defining a protocol. Put this on
the mailing list.
Rich Woundy: Seems like this may be the case where one network is
dead and the other has been extending the network. Odd case. Seems
that if there is cooperation between ISPs, it may be the network
map, not the cost map that is exchanged. Not certain we need a new
protocol - maybe can just use ALTO and do this as a private
agreement.
Kai Lee presents the results of an ALTO/P4P trial conducted on the
China Telecom network. Trial conducted last year for four
months. Cooperated with Xunlei (Thunder). Xunlei contributes 20% of
inter-province network in trial. Trial conducted in one province with
7M subscribers. Presented graphics defining the trial: the Network
Components, including ALTO/P4P server Simple PID and cost map
presented. Xunlei is hybrid, using tracker and DHT. About 85% of
traffic used/controlled by tracker. Trial modified only the
tracker. Presented the details of the modified selection algorithm.
Contrasting the differences between this trial and the Comcast trial.
Results without caching service was significant reduction in traffic
but user download speed slowed down.
Vijay: Why did this slow down? Expect clustering of high with high
and low with low? Kai: The number of peers returned is lower than
normal, 120 vs. 500. Vijay: well, many things only return 80. Kai:
Less than normal. Jan: If you guide too many to the near (interal)
peer, it may be overloaded and reduce speed, but reduces
cost. Richard: what is normal download speed? Kai: 270kbps Rich:
what is typical link in this province? Kai: in that province it is
about 300kps. Richard: Sorry, what I am asking is to try to figure
out if in some cases the peers are in high power/speed areas, but by
preferring the local (slower) peers, which could slow down the
traffic. Be interesting to know what the provisioned speed
was.
Yunfei: Does Xunlei have interdomain supernodes that could improve
performance, but isn't local and thus maybe not used? Kai: Don't
know.
David: Inbound was reduced by 28 Gbps, but what is this as a
percentage? Kai: That was removed as it was sensitive. David: Hard
to know how much of an improvement that really is then.
Yingjie Gu: Do you plan to trial with a finer grained cost map? Kai:
If needed, and it seems it will provide an impact, we will provide
it.
Yingjie presents the updated draft about ALTO information
redistribution. Basic requirements: Client should be able to
identify the desired redistribution data, and should be able to
check the authenticity of the data. Redistributable information is
the server capabilities, network map and full cost map among the
PIDs. Presentation of the questions to design the scheme for
redistribution. Changes since 77 discussed. Redistribution
Architecture presented: Redistribution Proxy (RProxy) can be ISP
deployed, or a tracker or supernode. Presented new architecuture
with RProxy, two options to communicate between ALTO server and
RProxy - Push and Pull mechanisms.
Vijay (as individual): This is mostly related to ALTO server being
overloaded - did this happen in the China mobile case? Kai: We only
had trackers talk to the ALTO server.
Martin T.: Can we reuse the HTTP redistribution system? Buy instead
of build? Roni: ALTO doesn't change, it actually doesn't make
significant changes.
--------------
Not presented due to time constraints.