To the two things being considered on this thread: (1) Should the map service be required or optional?
I believe we should have a base set of functionality that is required. My concern with making everything optional is that ALTO Clients wishing to operate on the public Internet are left needing to implement code paths for both the full maps and endpoint cost services. I understand that there are going to be deployments that may not need the map service. It is within their power to return "I don't know". In short, my preference is to reduce the complexity needed in the case where there is little or no coordination between the ALTO Client and ALTO Server providers (e.g., when the ALTO client is part of an application on a subscriber's device, and the ALTO Server is hosted by an ISP). Along those lines, I could probably be convinced that SHOULD instead of MUST is suitable for the Map Service. (2) Should there be a maximum response size and should the ALTO Client be made aware of it? I think its certainly within the server's ability to guard against requests that it can't satisfy due to resource constraints. I would imagine that it an HTTP 503 would be reasonable here (which is already doable by the current spec). However, I don't believe its necessary to give ALTO clients guidance on the size of the query. A few reasons why: - In an environment where the ALTO Server is behind some load-balancing mechanism, the available resources to service a request are going to be dependent on the particular machine handling the request. If you tell the client "sorry, I can support up to 1000 source/destination pairs" and the client closes the TCP connection and retries with a different source port, the next request may arrive at a different physical machine which may have a different limit on what it can safely support. - Let's say someone really wanted to DoS the server and you told them that you can only reply to queries with up to 1000 source/destination pairs. In a DDoS scenario, they are just going to send more queries each with the maximum query size that you'll allow. - If the ALTO Server is overloaded and still wants to actually answer queries (instead of returning errors), it is within its power to aggregate the information (say, aggregate to 100 PIDs instead of 1000) and then forget about serving the large maps that were causing it problems. Thanks, Rich On Wed, Mar 20, 2013 at 5:41 PM, Diego R. Lopez <[email protected]> wrote: > Hi, > > Since I am in the same situation as Wendy (in terms of being old enough to > remember when the Internet was small and even when it barely existed) I > like the idea of the "Request Too Large" error code, that reminds me what a > LDAP server returns when a search would include more entries than what the > server configuration allows to be returned. > > And I must say I support the idea of making full cost maps optional. > Replacing MUST for a SHOULD (and making clear that only the "Request Too > Large" error is acceptable to not satisfy it) should be enough to avoid the > overload risk while staying as close as possible to the minimum that makes > Sebastian feel uneasy... > > Be goode, > > -- > "Esta vez no fallaremos, Doctor Infierno" > > Dr Diego R. Lopez > Telefonica I+D > http://people.tid.es/diego.lopez/ > > e-mail: [email protected] > Tel: +34 913 129 041 > Mobile: +34 682 051 091 > ----------------------------------------- > > > ________________________________ > > Este mensaje se dirige exclusivamente a su destinatario. Puede consultar > nuestra política de envío y recepción de correo electrónico en el enlace > situado más abajo. > This message is intended exclusively for its addressee. We only send and > receive email on the basis of the terms set out at: > http://www.tid.es/ES/PAGINAS/disclaimer.aspx > _______________________________________________ > alto mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/alto >
_______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
