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. My suggestion: Keep it simple. ALTO Server returns the equivalent to 50X (if not already by HTTP Server). 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
