Reinaldo,
On 10 May 2011, at 19:04, Reinaldo Penno wrote:
> The document in my opinion is close to complete. When I look at the
> protocol, we are meeting most of the reqs.
>
> But personally I think these 3 Requirements should be modified, or maybe
> removed. But as editor I would like to hear the WG opinions.
I would agree that as written the requirements you highlight are not very clear
and could do with being modified.
It is not clear to me what is meant by "MUST be able to" i.e does this mean the
server MUST do it or it MUST be capable of doing it but is allowed to choose
not to.
As you mention below "impending overload" is a difficult state to associate
clear semantics with.
They also raise the question of what is meant by "close to its capacity limit"
i.e. what aspect of its capacity (concurrent TCP connections, CPU cycles to
process ALTO request etc.) needs to be covered.
I assume the original intent of the requirements was to provide a capability
for ALTO servers to gracefully inform clients that the server is overloaded and
inform the client of possible recovery actions?
> My suggestion: Keep it simple. ALTO Server returns the equivalent to 50X (if
> not already by HTTP Server).
I would agree. RFC2616 is not prescriptive on the response code to return when
a server is overloaded and for 503 response for example states:
Note: The existence of the 503 status code does not imply that a
server must use it when becoming overloaded. Some servers may wish
to simply refuse the connection.
The question in my mind is therefore do we drop the requirements and leave it
to implementers to "be nice" or do we try to keep the original intent I assume
above and reword the requirements to reflect the intent more precisely, e.g.
something like (it probably needs more wordsmithing)
"An ALTO server which is unable to handle a request due to temporary
overloading SHOULD inform the client of its overloaded state. Alternatively it
MAY redirect them to an alternative ALTO server."
Ben
>
> Let's take them one by one given current HTTP best practices. Just to make
> sure we do not require something that can not be operationalized.
>
>
> " REQ. ARv09-34: An ALTO server, which is operating close to its
> capacity limit, MUST be able to inform clients about its impending
> overload situation, and require them to throttle their query rate.
>
> [reinaldo] HTTP Servers (ALTO might likely reuse such infra) do not perform
> this function today. They are busy or not (503, 509, etc). They do not
> inform clients of 'impending' overload probably due to very fact that this
> is a loosely defined term and difficult to predict.
>
> Also, in reality, LBs are used in front of virtually every 'commercial' (for
> the lack of a better word) HTTP Server. LBs will send a TCP RST, perform
> geo-redirection and whatnot. HTTP Server would not even have the opportunity
> to tell about 'impending overload'.
>
>
> REQ. ARv09-35: An ALTO server, which is operating close to its
> capacity limit, MUST be able to inform clients about its impending
> overload situation, and redirect them to another ALTO server.
>
> [reinaldo] Same as above. Moreover we are asking for something that current
> HTTP infra is not required to perform. HTTP Servers are not required to
> perform redirection if they are busy.
>
>
> REQ. ARv09-36: An ALTO server, which is operating close to its
> capacity limit, MUST be able to inform clients about its impending
> overload situation, and terminate the conversation with the ALTO
> client."
>
> [reinaldo] Okay, this one I interpret as the following. If my ALTO Server is
> 'impeding' to overload I will go look at all my current ALTO connections and
> choose a few to send TCP RST? Again, how to operationalize these
> requirements?
>
>
>
> Thanks,
>
> Reinaldo
>
> On 5/10/11 10:30 AM, "[email protected]" <[email protected]>
> wrote:
>
>> A new Internet-Draft is available from the on-line Internet-Drafts
>> directories.
>> This draft is a work item of the Application-Layer Traffic Optimization
>> Working Group of the IETF.
>>
>> Title : Application-Layer Traffic Optimization (ALTO) Requirements
>> Author(s) : S. Previdi, et al
>> Filename : draft-ietf-alto-reqs-09.txt
>> Pages : 21
>> Date : 2011-05-10
>>
>> Many Internet applications are used to access resources, such as
>> pieces of information or server processes, which are available in
>> several equivalent replicas on different hosts. This includes, but
>> is not limited to, peer-to-peer file sharing applications. The goal
>> of Application-Layer Traffic Optimization (ALTO) is to provide
>> guidance to applications, which have to select one or several hosts
>> from a set of candidates, that are able to provide a desired
>> resource. This guidance shall be based on parameters that affect
>> performance and efficiency of the data transmission between the
>> hosts, e.g., the topological distance. The ultimate goal is to
>> improve performance (or Quality of Experience) in the application
>> while reducing resource consumption in the underlying network
>> infrastructure.
>>
>> This document enumerates requirements for ALTO, which should be
>> considered when specifying, assessing, or comparing protocols and
>> implementations.
>>
>>
>> A URL for this Internet-Draft is:
>> http://www.ietf.org/internet-drafts/draft-ietf-alto-reqs-09.txt
>>
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>
>> Below is the data which will enable a MIME compliant mail reader
>> implementation to automatically retrieve the ASCII version of the
>> Internet-Draft.
>
> _______________________________________________
> alto mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/alto
_______________________________________________
alto mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/alto
