Hi Martin, sorry for the late reply to this e-mail. I hope the original thoughts are still present. > However, there is a shift in protocol heaviness, by introducing the oracle > approach to the protocol proposal. The oracle requires calculations during > the runtime, i.e., the server needs to serve the requests and do extra cycles > on calculating the guidance. If i understand the proposal correctly, the additional load the Oracle approach introduces is generated by the sorting of the candidates list. Having this in mind, the scheme is actually very similar to the other approaches, i.e. the cached lookup in the DB and socket Handling is the same. Since sorting is a well known problem and can be done fairly fast i don't see this as a huge overhead. But it introduces extra stress on the server. Furthermore, at least as far as i understand it, the sorting is not introduced by the Oracle scheme, but by the ordinal ranking defined in section 4.1.2 in the draft. My understanding of this section is to introduce a possibility to "replace" the actual weights from the cache by a numbered ordering in the reply. Since the lists of IP's/PID's change with every request, the ordering will have to be done every time a query comes in (there are special cases when this might not be neccessary, but in general i think it is). The Oracle use-case is, in my opinion, a special case of the ordinal ranking.
Cheers, Ingmar -- Ingmar Poese [email protected] TU Berlin / Deutsche Telekom Labs Sekr. TEL 4, FG INET www.net.t-labs.tu-berlin.de Ernst-Reuter-Platz 7 10587 Berlin, Germany _______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
