On 07/14/2014, 08:02, "Sebastian Kiesel" <[email protected]> wrote:
>On Fri, Jul 11, 2014 at 02:27:40PM -0400, Wendy Roome wrote:
>>...
>> Eg, when a New York peer asks for peers, the tracker uses the cost map
>> from the ALTO server nearest New York. For a Tokyo peer, the tracker
>>uses
>> the cost map from the ALTO server nearest Tokyo. Then the individual
>>maps
>> wouldn??t be as large. But there would be a lot of them. And the tracker
>> would have to decide which map to use. Perhaps it could use the network
>> map which has the finest detail around the requesting peer??s address?
>> Whatever that means?
>
>Basically yes, but I am a bit sceptical that your example thinks too
>much in terms of geographical location instead of network topology and
>administrative domains.
>Who would be the operator of the "New York City Area ALTO Server"?
I agree. I just used geographic distance as a simple metaphor for
topological or administrative distance.
But the question then becomes given a set of N Network Maps, how would you
decide which one is best for costs relative to (say) 1.0.0.0? One
possibility is pick the map with the longest CIDR that matches 1.0.0.0.
However that favors sloppy maps that haven¹t aggregated adjacent CIDRs.
And of course that map might not be unique.
One way to filter out sloppy maps is to start with the set of all map(s)
with the longest CIDR that covers 1.0.0.0. Then add any maps with CIDRs
that cover 1.0.0.0 but are only slightly shorter than the longest one. Eg,
if the longest CIDR is 1.0.0.0/24, include maps with 1.0.0.0/22 and
1.0.0.0/23, but not 1.0.0.0/16. Then for each of those network maps,
estimate the size of the PID containing 1.0.0.0 -- that is, estimate the
maximum number of endpoints in the PID. Then pick the map with the
smallest PID containing 1.0.0.0. If that¹s not unique ... I dunno.
Randomize??
Estimating PID size might work for ipv4, because by this time, I think
assigned ipv4 addresses are uniformly dense. But I don¹t think it would
work as well for ipv6.
- Wendy Roome
_______________________________________________
alto mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/alto
