Subject: Re: [alto] Re： Proposal for ALTO re-charter

From: Lars Eggert <[email-masked]>
Date: Fri, 2 Jul 2010 08:04:14 +0100

Hi,

On 2010-7-2, at 3:31, wangaijun wrote:
> [Wang Aijun]: The ALTO Server does not need continuously monitor network traffic. There will be other device located within the ISP network to accomplish this work and this is the routine work of ISPs.

sure.

> The ALTO server just push such information to the client, once it receive them from the NMS(Network Management System) of ISP. 

Yes, I understood that. I still question the need for continuous communication between the ALTO server and all its clients. You claim efficiency gains, but so far I haven't seen a convincing argument of where they would come from, how large they would be, and under which conditions they will occur.

> [Wang Aijun] Scalability is one of the benefit of SNM

You said this before. Again, so far I haven't seen a convincing argument of exactly what resource would scale better, how large these claimed benefits are, and under which conditions they would occur.

> , others are the active participation of ISP, to reflect the updated policy/network condition timely.

Why will this improve initial peer selection, which is the stated charter goal?

I think you have a very different view of how a P2P app will interact with an ALTO server, which I don't share and which is also at odds with the understanding that underlies the current charter text.

> These are two contrary solutions under current query/response mechanism. If you emphasize the latter(real-time/shorter query interval), you will hurt the former(scalability/server load & bandwidth occupy). If we use SNM, we can satisfy them at the same time.

Request/response load will be somewhat higher without server push, because clients will need to send requests. On the other hand, requests are small, clients only send them when they really need them, and the server needs to manage a large number of parallel open connections to do server push, which isn't exactly easy on its resources. (Their is likely no difference in the size of the actual responses.)

In other words, as I said before, it's not clear at all that scaling will be better.

> We have encounter many similar events from the crash of DNS Server, why we do not try to avoid the happen of such thing for ALTO Service from the initial design phase?

The information an ALTO server provides is optional and not needed for the operation of the P2P app. Therefore, a crash or overload of an ALTO server has much milder consequences than a crash or overload of a DNS server (which, by the way, we've been able to handle with various failover techniques for a long time.)

To wrap this up: I think I've stated my case, and a continued discussion that is not backed by operational experience is unlikely to be very productive, so I'll refrain from sending additional emails on this topic.

Lars