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

Reinaldo, 

Here is a text suggestion (to appear in draft-11). Let us know your comments.

3.1.6.  Error Handling and Overload Protection

   REQ.  ARv11-31: An ALTO client protocol MUST use TCP based transport.

   REQ.  ARv11-32: An ALTO client protocol specification MUST specify
   mechanisms, or detail how to leverage appropriate mechanisms provided
   by underlying protocol layers, which can be used by an ALTO server to
   inform clients about an impending or occurring overload situation,
   and require them to throttle their query rate.

   REQ.  ARv11-33: An ALTO client protocol specification MUST specify
   mechanisms, or detail how to leverage appropriate mechanisms provided
   by underlying protocol layers, which can be used by an ALTO server to
   inform clients about an impending or occurring overload situation,
   and redirect them to another ALTO server.

   REQ.  ARv11-34: An ALTO client protocol specification MUST specify
   mechanisms, or detail how to leverage appropriate mechanisms provided
   by underlying protocol layers, which can be used by an ALTO server to
   inform clients about an impending or occurring overload situation,
   and terminate the conversation with the ALTO client.

   REQ.  ARv11-35: An ALTO client protocol specification MUST specify
   mechanisms, or detail how to leverage appropriate mechanisms provided
   by underlying protocol layers, which can be used by an ALTO server to
   inform clients about its inability to answer queries due to technical
   problems or system maintenance, and require them not to send any
   further queries before an indicated point in time.

   REQ.  ARv11-36: An ALTO client protocol specification MUST specify
   mechanisms, or detail how to leverage appropriate mechanisms provided
   by underlying protocol layers, which can be used by an ALTO server to
   inform clients about its inability to answer queries due to technical
   problems or system maintenance, and redirect them to another ALTO
   server.

   REQ.  ARv11-37: An ALTO client protocol specification MUST specify
   mechanisms, or detail how to leverage appropriate mechanisms provided
   by underlying protocol layers, which can be used by an ALTO server to
   inform clients about its inability to answer queries due to technical
   problems or system maintenance, and terminate the conversation with
   the ALTO client.

   Note: The existence of the above-mentioned protocol mechanisms does
   not imply that an ALTO server must use them when facing an overload,
   technical problem, or maintenance situation, respectively.  Some
   servers may be unable to use them in that situation, or they may
   prefer to simply refuse the connection or not to send any answer at
   all.

> -----Original Message-----
> From: alto-bounces@ietf.org [mailto:alto-bounces@ietf.org] On Behalf Of
> Reinaldo Penno
> Sent: Wednesday, June 29, 2011 3:40 PM
> To: Martin Stiemerling; Sebastian Kiesel; Enrico Marocco
> Cc: alto@ietf.org
> Subject: Re: [alto] Second round of comments on Re: WGLC on ALTO reqs 10,
> not 08
> 
> 
> 
> 
> On 6/29/11 6:26 AM, "Martin Stiemerling" <Martin.Stiemerling@neclab.eu>
> wrote:
> 
> > Reinaldo,
> >
> >
> >> -----Original Message-----
> >> From: alto-bounces@ietf.org [mailto:alto-bounces@ietf.org] On Behalf
> >> Of Reinaldo Penno
> >> Sent: Wednesday, June 22, 2011 9:25 AM
> >> To: Sebastian Kiesel; Enrico Marocco
> >> Cc: alto@ietf.org
> >> Subject: [alto] Second round of comments on Re: WGLC on ALTO reqs 10,
> >> not
> >> 08
> >>
> >> I've sent some emails in the past regarding ARV-31-34 that were
> >> echoed by other people. I still think WGLC can be completed without
> >> changing their text
> >>
> >> For example...
> >>
> >> "   REQ.  ARv10-32: An ALTO client protocol specification MUST specify
> >>    mechanisms, or detail how to leverage appropriate mechanisms
> provided
> >>    by underlying protocol layers, which can be used by an ALTO server
> >>    operating close to its capacity limit, to inform clients about its
> >>    impending overload situation, and require them to throttle their
> >>    query rate.
> >> "
> >>
> >> - Why is 'impending overload'?
> >> - Why clients need to throttle their requests? Throttle how?
> >> Exponetial backoff, etc...
> >
> > I guess the text is fine as it is: this draft is not a protocol
> > specification which needs to specify what the back-off algorithm is.
> 
> If you are requiring clients to throttle then the protocol needs to specify how
> to throttle, the algorithm and others. This makes the client more complex
> without any tangible benefit.
> 
> >
> >>
> >> Others
> >>
> >> - " operating close to its capacity limit". How close?
> >
> > This is neither a matter of the ALTO requirements nor of the ALTO
> > protocol specification but a local configuration of the ALTO server.
> 
> If it is not a matter of requirements can we drop this requirement? The IETF
> does not standardize local policy issues, right?
> 
> >
> >>
> >> This all leads to multiple interpretations and interoperability
> >> issues
> >>
> >> As I mention before we should just use wording similar to HTTP.
> >>
> >> Suggested simpler text
> >>
> >> "...inform the client that the server is currently unable to handle
> >> the request due to a temporary overloading or maintenance of the
> >> server."
> >
> > HTTP is a protocol specification, this draft is a requirements draft.
> 
> It is still making a requirement that is open to interpretation. Why not
> simplify the requirement wording?
> 
> 
> >
> >   Martin
> >
> >>
> >>
> >>
> >> On 6/21/11 8:43 AM, "Sebastian Kiesel" <ietf-alto@skiesel.de> wrote:
> >>
> >>> draft-ietf-alto-reqs-10
> >>
> >> _______________________________________________
> >> alto mailing list
> >> alto@ietf.org
> >> https://www.ietf.org/mailman/listinfo/alto
> 
> _______________________________________________
> alto mailing list
> alto@ietf.org
> https://www.ietf.org/mailman/listinfo/alto