Subject: [alto] Proposal for ALTO re-charter

From: "wangaijun" <[email-masked]>
Date: Wed, 23 Jun 2010 15:56:29 +0800

Hi,Vijay,Enrico,Jon and Alimi

>From previous discussion, we can know the Server Notification Mechanism(SNM)
is important for the communication efficiency between ALTO Server and ALTO
Client. It is very similar to the "Traffic Guidance System",in which the
traffic control department will broadcast the real traffic information
actively to guide the car to avoid the congested road, or notify the driver
that some area are in "traffic control", in order to assure the performance
of some high priority traffic.

Considering this, we propose to modify the current ALTO charter to reflect
this requirement and add it into the final ALTO output. For example:

A.  In ALTO charter, we can add the new section as below:

The WG will focus on the following items:

1.  A "problem statement"..(omitted)

2.  A requirement document..(omitted)

3.  A request/response protocol..(omitted)

4.  (New part)A document to define the server notification mechanism(SNM) in
order to make the communication between ALTO Server and ALTO Client more
efficient, let the traffic keep up with the change of network topology and
more optimized. It should include the detailed description of SNM, its main
aim, the notification mode, message format/processing procedure and
implementation guidance. The relationship with query/response protocol
should also be considered.

5.  ..(omitted)

B.  In draft-ietf-alto-reqs-04.txt, add the subsection:

3.1 ALTO Client Protocol(Original part)

..

3.2 ALTO Server discovery(Original part)

..

3.3 ALTO Server Notification(Added part, detailed content will be added
later)
    REQ. ARV04-46 .

REQ. ARV04-47 .

    ..

3.4  Security and privacy(Original part)

..

Is it feasible for above thoughts? If OK, we will provide the detailed
proposal and the updated draft about "server notification mechanism ".

Best Regards.

Wang Aijun

Network Infrastructure Research Division

Network and Service Research Department

China Telecom Coporation Beijing Research Institute

---

From: "Martin Stiemerling" <[email-masked]>
Date: Wed, 23 Jun 2010 10:09:43 +0200

Hi,

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> wangaijun
> Sent: Wednesday, June 23, 2010 9:56 AM
> To: [email-masked]; 'Enrico Marocco'; [email-masked];
> 'Richard Alimi'
> Cc: [email-masked]; [email-masked]; 'Likai'
> Subject: [alto] Proposal for ALTO re-charter
> 
> From previous discussion, we can know the Server Notification
> Mechanism(SNM) is important for the communication efficiency between
> ALTO Server and ALTO Client. It is very similar to the "Traffic

I particular cannot recognize the importance of this mechanism, this is still not clear even after the last discussions and slides I've seen in the past.

One technical question: 
The SSM would required to keep the TCP connection between the ALTO client and ALTO server up and running at all times, even if there is no request from the  ALTO client and no to be delivered responsed from the server. This open TCP is required to let the server send this SSM to the client at any time. 

Have you considered if this system scales well compared to the HTTP approach of the ALTO protocol were you have open TCP connections only for the time of performing the request/response. 

> Guidance System",in which the traffic control department will broadcast
> the real traffic information actively to guide the car to avoid the
> congested road, or notify the driver that some area are in "traffic
> control", in order to assure the performance of some high priority
> traffic.

This comparison isn't doing right:
car traffic guidance systems typically work on a broadcast basis, as you have described, but the SSM would be unicast mechanism. So what's the comparison here?

> 
> 
> 
> Considering this, we propose to modify the current ALTO charter to
> reflect this requirement and add it into the final ALTO output. For
> example:

I'm opposing this change, as there is in my opinion no real use case behind this. Second this is overloading the ALTO protocol with a functionality beyond the originally envisioned functionality. 

With best regards

  Martin

> 1.  A "problem statement"......(omitted)
> 
> 2.  A requirement document......(omitted)
> 
> 3.  A request/response protocol......(omitted)
> 
> 4.  (New part)A document to define the server notification
> mechanism(SNM) in order to make the communication between ALTO Server
> and ALTO Client more efficient, let the traffic keep up with the change
> of network topology and more optimized. It should include the detailed
> description of SNM, its main aim, the notification mode, message
> format/processing procedure and implementation guidance. The
> relationship with query/response protocol should also be considered.
> 
> 5.  ......(omitted)
> 
> 
> 
> ......
> ......
>     REQ. ARV04-46 ...
> REQ. ARV04-47 ...
>     ......
> ......
[email-masked]

NEC Laboratories Europe - Network Research Division
NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014

---

From: "Martin Stiemerling" <[email-masked]>
Date: Wed, 23 Jun 2010 11:15:04 +0200

Hi,

> 
> Hi，Martin
> 
> 1. The SNM does not require the TCP connection between ALTO Server and
> ALTO
> Client to be kept at all time. Once there is any updated ALTO
> information,
> the ALTO Sever will make one new TCP connection to ALTO Client, it will
> be
> terminated after the transfer of the updated ALTO information. This is
> the
> reason that we keep the "candidate table" in ALTO Server.

This "letting the server open the TCP connection to the client" requires:
- having the ALTO client running a TCP server (easy)
- having the ALTO client using a defined/allocated TCP port number (still easy)on that host
-register this port (plus IP address) with the ALTO server (not that easy anymore, as the server needs to keep track of all ALTO clients he is in charge of)
- letting the server open n TCP connections to n clients, where n is the number of registered ALTO clients, probably all at the same time. This causes a bit of load on the server network interface and the links beyond this (it scales with the number of clients)

There may be some points missing in the list above but they are sufficient to explain what the issues:
- there are firewalls on the hosts:
the user of a host that is running the ALTO client has to properly configure its local host-based firewall -- enjoy fun.
- there are firewalls all over the network:
This does not allow any host in the Internet (e.g., the ALTO server) to open a TCP connection to the ALTO clients, unless the firewalls are configured to do so. Try to ask this questions to your favorite firewall operator ;)
- there are NATs all over the network:
A NAT usually (*) does not allow an ALTO client to register incoming TCP connections and thus it does not allow to get a public reachable IP address and port that is being registered at the ALTO server.

(*) usually I would say is at least 60% of all NATs you encounter.

You can now argue whether this is an issue or not, but I won't follow those arguments, as these issues have been experienced too many times by too many protocols. Ask the SIP guys...

> 
> 2. The comparison between "SNM" and "Traffic Guidance System" is mainly
> refer to the similarity for sending the updated information actively,
> not
> the sending methods(broadcast or unicast). In theory, not only unicast,
> the
> multicast method can also be used to transfer this information
> actively, in
> both scenarios.

Multicast and ALTO (TCP)? 
This does not work, see RFC 793, Section 1.5:
    The reliability and flow control mechanisms described above require
    that TCPs initialize and maintain certain status information for
    each data stream.  The combination of this information, including
    sockets, sequence numbers, and window sizes, is called a connection.
    Each connection is uniquely specified by a pair of sockets
    identifying its two sides.

I guess your SSM is referring to something beyond ALTO.

> 
> 3. We are now underlying the real on-site test in ChinaNet for ALTO
> deployment and find it is very useful for ALTO Server to have this
> capability, this is not the imagination in lab.

Unfortunately, I cannot tell how ChinaNet is configured and what is deployed where. 

Your SSM may be suitable for walled garden deployments, but this does not fit an Internet standard for the above mentioned points in the general case. 

  Martin

---

From: Sebastian Kiesel <[email-masked]>
Date: Wed, 23 Jun 2010 13:03:23 +0200

Hi,

On Wed, Jun 23, 2010 at 06:00:07PM +0800, wangaijun wrote:
> Hi, Martin
> 
> We have considered the existence of NAT/Firewall in real internet, so we
> divided the scope of SNM in two scenarios: 
> Tracker-based and Tracker-less type, and currently we mainly focus on the
> tracker-based situation

in a deployment scenario where the ALTO server gives guidance to only a
very small number of trackers, it seems feasible to configure the ALTO
clients in the trackers in a way that they ask the ALTO server rather
frequently whether the situation has changed (and the ALTO client
protocol should allow the ALTO server to reply "nothing changed since
<timestamp>" or so, in order to avoid frequent downloads of the same
information).

If, however, the number of ALTO clients in the deployment scenario is
high enough that their frequent polling for updates causes a significant
burden on the ALTO server, a notification mechanism based on callbacks
will most likely run into the problems Martin mentioned earlier.

  -- Sebastian

---

From: "Martin Stiemerling" <[email-masked]>
Date: Wed, 23 Jun 2010 14:25:01 +0200

[stream-lined the "to" lines, as most of the people are anyhow on [email-masked]]

Hi, 

> From: wangaijun [mailto:[email-masked]]
> Sent: Wednesday, June 23, 2010 12:00 PM
> To: Martin Stiemerling; [email-masked]; 'Enrico Marocco';
> [email-masked]; 'Richard Alimi'
> Subject: 答复: [alto] Proposal for ALTO re-charter
> 
> Hi, Martin
> 
> tracker-based situation(I have explained the reason in the presentation
> of
> interim meeting on June 16,2010).
> 
> For tracker-based situation, the ALTO Client is embedded in tracker,
> and it
> will have public address/port, or else the p2p client can't connect to
> p2p
> tracker for obtaining the URL of downloaded content either.

I totally agree that you will have fewer TCP connections compared to where the ALTO client is embedded in the P2P client. 

However, if you already need to distinguish between tracker and no tracker, how does the ALTO-server determine in which setting it is running? Knowing that there will be a time where a single ALTO-server is serving trackers and also peers directly. 

The nice property of the current ALTO-protocol is that there is no need to distinguish in the protocol whether a ALTO client at the peer or at the tracker is asking for guidance. This would be lost, if the SSM is implemented.

Second, the SSM is useful for map-based approaches but less of use for non-map-based approaches. But this is a minor issue.

Third, why not just use the current ALTO protocol, which is HTTP-based with the HTTP semantics of checking when the content was last modified? This is a lean request to the server (including the involvement of the HTTP cache infrastructure in between, probably also lower the load on the server) and a lean response from the server?
An ALTO response can also carry a "best before" time stamp, saying that you need to check again after this time is expired.

Another question: What update frequency for the server-side information do you have in mind? 

> 
> The argument always fall into the tracker-less situation. For this
> situation, we have discussed thoroughly in previous maillist. There
> sure no
> perfect methods to deal with it before we find some efficient
> information
> redistribution among p2p swarm(This has also presented in the meeting
> slides). On the other hand, the percentage of tracker-less p2p is very
> low,
> when compared to the traffic from tracker-based and CDN-based
> application.
> Currently, we can leave it as one open issue and tackle the problem
> from the
> most part of internet traffic.

Leaving this open is actually not good, as people will start building their own incompatible solution, plus some folks may believe they can just re-use SSM for tracker-less as is. 

  Martin

---

From: "Martin Stiemerling" <[email-masked]>
Date: Wed, 23 Jun 2010 14:46:18 +0200

Hi again,

I've just browsed through draft-sun-alto-notification-02.txt:

It says it the Abstract:
"such as when part of the network is congested, when a
new policy is to be deployed urgently, or when unexpected network
maintenance is required."

Congestion control and avoidance is out of scope of ALTO when I remember right, as congestion status is just too volatile for ALTO, plus congestion is handled at a different level. 

Deployment of new urgent policy: Why is there the believe that ALTO is the place for applying urgent policies and what are urgent policies. Will P2P systems (or even CDN) react to urgent policies or will this perish in the overall operations?

How does ALTO help in the case of an unexpected network maintenance? In my understanding " unexpected network maintenance " means some fault and the need to fix it soon, but there will not be the time to tell this to ALTO. Furthermore, why should a "unexpected network maintenance" be taken care of a tracker? This will be anyhow be detected by the clients, as they can probably at best judge if the network is still performing as expected. If " unexpected network maintenance" relates to route changes, this is also out of scope of ALTO.

My feeling is that the SSM is only useful for short-lived information that should not impact the ALTO server.

  Martin

> Martin Stiemerling
> Sent: Wednesday, June 23, 2010 2:25 PM
> To: wangaijun
> Cc: [email-masked]; [email-masked]; Likai
> Subject: Re: [alto] Proposal for ALTO re-charter
> 
> I totally agree that you will have fewer TCP connections compared to
> where the ALTO client is embedded in the P2P client.
> 
> However, if you already need to distinguish between tracker and no
> tracker, how does the ALTO-server determine in which setting it is
> running? Knowing that there will be a time where a single ALTO-server
> is serving trackers and also peers directly.
> 
> The nice property of the current ALTO-protocol is that there is no need
> to distinguish in the protocol whether a ALTO client at the peer or at
> the tracker is asking for guidance. This would be lost, if the SSM is
> implemented.
> 
> Second, the SSM is useful for map-based approaches but less of use for
> non-map-based approaches. But this is a minor issue.
> 
> Third, why not just use the current ALTO protocol, which is HTTP-based
> with the HTTP semantics of checking when the content was last modified?
> This is a lean request to the server (including the involvement of the
> HTTP cache infrastructure in between, probably also lower the load on
> the server) and a lean response from the server?
> An ALTO response can also carry a "best before" time stamp, saying that
> you need to check again after this time is expired.
> 
> Leaving this open is actually not good, as people will start building
> their own incompatible solution, plus some folks may believe they can
> just re-use SSM for tracker-less as is.
> 
>   Martin
> 
> NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road,
> London W3 6BL | Registered in England 2832014
> _______________________________________________
> alto mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/alto

---

From: Lars Eggert <[email-masked]>
Date: Thu, 24 Jun 2010 11:14:49 +0300

Hi,

On 2010-6-23, at 10:56, wangaijun wrote:
> From previous discussion, we can know the Server Notification Mechanism(SNM) is important for the communication efficiency between ALTO Server and ALTO Client. It is very similar to the “Traffic Guidance System”,in which the traffic control department will broadcast the real traffic information actively to guide the car to avoid the congested road, or notify the driver that some area are in “traffic control”, in order to assure the performance of some high priority traffic.

I won't comment on whether your SNM is similar to traffic management systems or not.

However, I will note that the charter says:

  The Working Group will design and specify an Application-Layer Traffic
  Optimization (ALTO) service that will provide applications with
  information to perform better-than-random initial peer selection.

And that's it.

End systems are already being informed about network congestion. The notifications come via packet losses or ECN marks. Due to being transmitted in-band, they are as timely as possible, and provide direct feedback about the resource load along the data path. This already gives application all the information they need to decide whether they want to prefer one peer over another.

In other words, ALTO is providing hints to a P2P app about which peers it may want to try first. Because ALTO is a control-plane mechanism and not coupled to the data plane, the information that is useful to exchange via ALTO needs to be stable and accurate over timescales that are orders of magnitude longer than RTTs.

Using again different words: You won't know what the actual path capacity or congestion to a peer is unless you start transmitting along the path.

Lars

---

From: Lars Eggert <[email-masked]>
Date: Thu, 24 Jun 2010 12:43:18 +0300

Hi,

On 2010-6-24, at 12:28, wangaijun wrote:
> The ip address allocation map can be coarser or finer, and get the different
> p2p localization effect. The ISP may adjust this allocation map, to give the
> p2p clients more or less hint according to the network condition. In this
> situation, it is useful for ISP to have SNM to notify the ALTO information
> customer.
> 
> This is just one example, there are other examples for ISP want to notify
> the changed network condition timely, via SNM. With SNM, the cooperation
> between ISP and p2p/CDN based application developer can be more active, more
> reciprocal.   

why? ALTO focuses on the *initial* peer selection. When a client joins a swarm, it fetches the current ALTO information, and incorporates that into its peer decision algorithm. Done.

Nothing in the design assumes that a client will need to continuously remain connected to the ALTO server (or even that the client queries the ALTO server at all.) If a client for whatever reason needs the most recent ALTO information, it can simply reconnect to the server. No notification mechanism is needed. An ALTO server is a purely passive information storage.

(That said, we can certainly discuss extending the ALTO architecture in the future, but I at least would like to see actual *deployment* of the simple current mechanism, so that we fix limitations of the current design that have been demonstrated through *actual deployment experience*. Which we don't have yet.)

Lars

---

From: "Martin Stiemerling" <[email-masked]>
Date: Thu, 24 Jun 2010 11:57:44 +0200

Hi, 

> Sent: Thursday, June 24, 2010 6:00 AM
> To: Martin Stiemerling
> Cc: [email-masked]; [email-masked]; 'Likai'; [email-masked]
> Hi,Martin
> 1. Let's me explain first the background of SNM(Server Notification
> Mechanism): The deployment of ALTO can certainly benefit both the
> network
> provider and p2p/CDN application user. It is obvious that the network
> provider has the most detail and real time topology information, and is
> the
> best candidate for providing the ALTO Service. If we consider only the
> query/response mechanism, as in current ALTO protocol, the ISP can only
> participate in the cooperation process in most passive manner, and this
> can't exert the ISP's advantage. For example, if there is any network
> outage
> in some area, the ISP has no methods to tell the p2p clients timely to
> select other peers for steering away from such area.  "...such as when
> part
> of the network is congested, when a new policy is to be deployed
> urgently,
> or when unexpected network maintenance is required..." are all examples
> of
> such situations.

I read this paragraph as not being ALTO at all, but as a different way of operator controlled P2P system influence system. You try to steer P2P systems (or any other app type that is using your service) to do exactly what your service is providing, including real-time traffic engineering.

This is not the goal of ALTO.

ALTO aims at letting cooperate P2P and ISPs to get "better-than-random initial peer selection". ALTO is providing guidance and does not enforce system behaviour and it even cannot enforce system behaviour. What if you provide information to the system and the apps do not care at all, or they react on much longer time-scales compared to the short time-scale guidance change? There is a misunderstanding on what ALTO can and will achieve IMHO.

For instance, in the case, your SSM is telling apps to avoid areas as you say they are congested, the apps will have found already, if they are having ongoing transmissions with peers, or they will very easily find this out while probing other peers, or you tell them the area is congested, but the congestion just is not there anymore?

I stop here, as I do not see the fundamental needs for this right now and I also do not see that this fits ALTO. 

  Martin

> 
> 2. (in current ALTO charter)"...In any case, this WG will not propose
> standards on how congestion is signaled, remediated, or avoided, and
> will
> not deal with information representing instantaneous network state.
> Such
> issues belong to other IETF areas and will be treated accordingly by
> the
> specific area....". The SNM is also not for these standards, it just
> provide
> one mechanism for ALTO clients knowing the important change(new
> deployment
> or re-allocated of ip address, merge or divide of network topology,
> network
> construction, area list that always in bad performance etc.) in network
> timely and let the ISP be more active along the ISP&p2p/CDN cooperation
> .
> How these information be told to ALTO Server is the work of ISP, not
> the
> task of ALTO Server.
> 
> 3. Within SNM, the ALTO Server need not distinguish between the p2p
> tracker
> ALTO Client or tracker-less p2p ALTO Client. Once there is any updated
> information, it just send notification to the clients in "candidate
> table".
> These clients may be p2p trackers, may be normal p2p clients which can
> receive the updated ALTO information(for example, has the contactable
> public
> IP address).
> 
> 4. SNM is one enhancement method for communication efficiency of ALTO
> information. It is obvious that the frequent polling packets will give
> burden to the ALTO Server, even when you ask only "is there any updated
> information" to ALTO Server. The frequency of TCP
> connections/disconnections
> in query/response mode between ALTO Sever and ALTO Clients is far
> higher
> than that in the SNM mode.
> 
> 5. The update frequency of ALTO information is undetermined and
> non-periodical. This is the main reason that we introduce the SNM into
> ALTO
> protocol.
> 
> Wang Aijun
> -----邮件原件-----
> 发件人: Martin Stiemerling [mailto:[email-masked]]
> 发送时间: 2010年6月23日 20:46
> 收件人: wangaijun
> 抄送: [email-masked]; [email-masked]; Likai
> 主题: RE: [alto] Proposal for ALTO re-charter
> 
> Hi again,
> 
> Congestion control and avoidance is out of scope of ALTO when I
> remember
> right, as congestion status is just too volatile for ALTO, plus
> congestion
> is handled at a different level.
> 
> Deployment of new urgent policy: Why is there the believe that ALTO is
> the
> place for applying urgent policies and what are urgent policies. Will
> P2P
> systems (or even CDN) react to urgent policies or will this perish in
> the
> overall operations?
> 
> How does ALTO help in the case of an unexpected network maintenance? In
> my
> understanding " unexpected network maintenance " means some fault and
> the
> need to fix it soon, but there will not be the time to tell this to
> ALTO.
> Furthermore, why should a "unexpected network maintenance" be taken
> care of
> a tracker? This will be anyhow be detected by the clients, as they can
> probably at best judge if the network is still performing as expected.
> If "
> unexpected network maintenance" relates to route changes, this is also
> out
> of scope of ALTO.
> 
> My feeling is that the SSM is only useful for short-lived information
> that
> should not impact the ALTO server.
> 
>   Martin
> 
> 
> > > We have considered the existence of NAT/Firewall in real internet,
> so
> > > we
> > > Tracker-based and Tracker-less type, and currently we mainly focus
> on
> > > the
> > Another question: What update frequency for the server-side
> information
> > do you have in mind?
> >
> > >

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 24 Jun 2010 13:51:30 -0600

On 6/24/10 3:43 AM, Lars Eggert wrote:

> (That said, we can certainly discuss extending the ALTO architecture
> in the future, but I at least would like to see actual *deployment*
> of the simple current mechanism, so that we fix limitations of the
> current design that have been demonstrated through *actual deployment
> experience*. Which we don't have yet.)

Yes, iterative seems like the right approach.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Sebastian Kiesel <[email-masked]>
Date: Sun, 27 Jun 2010 17:48:30 +0200

Hi,

my opinion is that at this point in time the ALTO WG should focus
the resources (i.e., session time during meetings, time of volunteers
working on or reviewing documents, etc.) on making progress with
the current deliverables. Further extensions should be considered
when the core protocol is (almost) complete.

That being said, I'd be very interested to read an individual document
that describes a sound technical solution for the notification
mechanism, which is applicable (technically and with respect to
user/operator acceptance) in a wide variety of scenarios.

Thanks,
    Sebastian

---

From: Lars Eggert <[email-masked]>
Date: Tue, 29 Jun 2010 04:07:46 -0400

Hi,

On 2010-6-26, at 20:13, wangaijun wrote:
> It is not the case that the clients will fetch the ALTO information when it
> joins a swarm. The client will first use the stored ALTO information.

sure, a client can use locally cached information first, but that is again an optimization.

> Theoretically, one can design the interaction between p2p application and
> ALTO server as you image, but it can give more burden to the ALTO server.
> The ALTO server will receive more redundant query packet and response the
> same information repeatedly. It is obvious not efficient as the proposed
> SNM(Server Notification Mechanism).

It's not clear at all that the mechanism you propose will lead to better scaling of the ALTO server - the ALTO server now needs to continuously monitor network traffic and push information the clients. Compare that with what I wrote, where the ALTO server basically responds with slowly changing (almost static) information only when requested.

That aside, without deployment we don't even know if scaling of the ALTO servers is something we should be worried about. ISPs are not exactly resource constrained.

> The SNM is just stemmed from the *actual deployment experience*, and is
> "which we don't have yet", it doesn't introduce complexity to the current
> ALTO mechanism and can reduce the burden of ALT Server, can be helpful to
> the performance of p2p/CDN application, can let the ISP participate into the
> cooperation actively and be helpful to the deployment of ALTO service. Why
> we are so reluctant to accept it, and hesitate to re-charter the ALTO to
> reflect this requirement?

Because at the moment I at least personally remain unconvinced there is a need for it. If you have actual deployment experience with an ALTO service, I'd love to see the data that shows that a mechanism like SNM is needed.

Lars

> 发件人: Lars Eggert [mailto:[email-masked]] 
> 发送时间: 2010年6月24日 17:43
> 收件人: wangaijun
> 抄送: [email-masked]
> 主题: Re: [alto] Proposal for ALTO re-charter
> 
> Hi,
> 
> why? ALTO focuses on the *initial* peer selection. When a client joins a
> swarm, it fetches the current ALTO information, and incorporates that into
> its peer decision algorithm. Done.
> 
> Nothing in the design assumes that a client will need to continuously remain
> connected to the ALTO server (or even that the client queries the ALTO
> server at all.) If a client for whatever reason needs the most recent ALTO
> information, it can simply reconnect to the server. No notification
> mechanism is needed. An ALTO server is a purely passive information storage.
> 
> (That said, we can certainly discuss extending the ALTO architecture in the
> future, but I at least would like to see actual *deployment* of the simple
> current mechanism, so that we fix limitations of the current design that
> have been demonstrated through *actual deployment experience*. Which we
> don't have yet.)
> 
> Lars
> 
>