Hi Reinaldo, On Tue, Jul 05, 2011 at 10:53:18AM -0400, Reinaldo Penno wrote: > > > > On 7/5/11 7:22 AM, "Sebastian Kiesel" <ietf-a...@skiesel.de> wrote: > > > Reinaldo, > > > > On Tue, Jul 05, 2011 at 06:10:38AM -0400, Reinaldo Penno wrote: > >> Is is possible to provide clear use cases for requiring throttling in the > >> protocol? This requirement came from > >> http://tools.ietf.org/html/draft-kiesel-alto-reqs-02 and was carried over > >> to > >> the WG document. > > Thanks for chiming in. > > > > > Having a P2P swarm of an unknown swarm size sending queries at an > > unspecified rate to one focal point (i.e., the more or less centralized > > ALTO server) sounded dangerous at that time. > > I appreciate where you are coming from but Why would somebody have an ALTO > Server answering queries for a swarm on unknown size in the firs place? It > seems bad dimensioning of the service.
At that time, and even today, I am not 100% sure what will eventually be the most relevant use cases for ALTO. There was consensus that ALTO should be designed in a way that ALTO servers can be operated by parties other than the network operators. Maybe some time in the future some people that operate a large "independent" P2P tracker (independent from ISPs and content owners...) decide to operate an "independent" ALTO server because they feel that ISP's "official" ALTO servers are optimizing ISP's transit costs while penalizing overall swarm throughput. In that case you would have peers from swarms of unknown size accessing the ALTO server. You might want to say "free access is fine but please not too often". > > I think the word "overload (situation|control|handling|relief|...)" is > > so important that must be mentioned as one requirement and not just > > considered to be one special case of error handling. On the other hand, > > I am not sure whether we should mandate (MUST) mechanisms that are more > > sophisticated than what http provides. > > Exactly my point. The issue is that the current wording precludes us from > reusing the HTTP mechanism because it talks about throttling and there is no > such thing in HTTP. > > In general all these requirements say "or detail how to how to leverage > appropriate mechanisms provided by underlying protocol layers" but we can > not leverage since the requirements are wider than what HTTP provides. ACK. Thanks Sebastian _______________________________________________ alto mailing list alto@ietf.org https://www.ietf.org/mailman/listinfo/alto
