Hi Wendy, Great consideration! Some Web sites provide file sizes, say on some images, and I check them before deciding if I want to download at given connectivity.
A few quick comments: - In the context of the ALTO information resources, in particular, when there are multiple versions (e.g., different granularities such as different numbers of PIDs) of the same information resource, such information can be quite helpful. - Beyond network maps and cost maps, as you already mentioned, the Endpoint Property Service can indicate the range of endpoints that the service can give information. - I see multiple ways to indicate the coarse info. You mentioned range. I can image current size (e.g., number of PIDS right now) as a possibility. Assuming continuity, the ALTO client may guess the size. To summarize, my answer to your Q1 is yes. For Q2: service discovery appears to be a good category. Richard On Thu, Aug 28, 2014 at 1:27 PM, Wendy Roome <[email protected]> wrote: > This list has been quiet for a while, so I thought I'd shake it up. > > While an IRD does define an ALTO server's resources, it leaves a lot of > questions unanswered. For example, before retrieving a cost map, a client > might like to know whether the map has 200 costs or 2,000,000 costs. Or > whether a network map has 50 PIDs and 200 CIDRs, or 2,000 PIDs and 200,000 > CIDRs. > > So what do you think of adding an "advice" field to IRD entries? Like > "capabilities", it would be a JSON object with attributes specific to the > resource type. The values would be approximate guidelines, not exact > values. For example, sizes should be ranges, with the implication that no > matter how much the map changes, it SHOULD stay within that range. E.g., > rather than saying that a network map has exactly 78 PIDs and 363 PIDs, > the advice might be that the map has between 50 and 100 PIDs, and 250 to > 500 CIDRs. > > For network maps, another advisory would be the set of endpoint addresses > for which this map is authoritative (for want of a better word). While it > would be wonderful if an ALTO server had detailed PIDs for every endpoint > in the network, and had costs to and from every PID, it is very unlikely > that will happen. Instead, most ALTO servers will be run by ISPs. The > server will have detailed PIDs for the ISP's customers, and will have > source and destination costs between its customer's PIDs and the rest of > the network. But as you get farther from the ISP's coverage area, the PIDs > get less detailed, and the cost maps will be unlikely to have costs > between those PIDs. > > If a P2P tracker knows about (say) a dozen different different ALTO > servers, the tracker can use their "authoritative sets" to select the > appropriate ALTO server. E.g., if a peer at address X asks for a set of > peers, the tracker would use the ALTO server whose set covers X to > evaluate the costs from the other peers to X. Similarly, if an ALTO server > offers several network maps, a client could use this to distinguish > between those maps. > > Before I develop this as a formal proposal, I have two questions for y'all: > > 1. Do you think this extension is useful? > > 2. How would this fit into the update charter? My take is that it could > come under the heading of "server discovery." True, it doesn't allow a > client discover a server from scratch. But it does allow a client to > select the appropriate server from a set of twisty little ALTO servers, > all alike. > > - Wendy Roome > > > > _______________________________________________ > alto mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/alto > -- -- ===================================== | Y. Richard Yang <[email protected]> | | Professor of Computer Science | | http://www.cs.yale.edu/~yry/ | =====================================
_______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
