Re: [alto] Second round of comments on Re: WGLC on ALTO reqs 10, not 08

[Sebastian Kiesel <[e-mail]>]

Hi Reinaldo,

On Tue, Jul 05, 2011 at 10:53:18AM -0400, Reinaldo Penno wrote:
> 
> 
> 
> On 7/5/11 7:22 AM, "Sebastian Kiesel" <[e-mail]> 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