I'm aware of this issue but IMO this is not a specific ALTO issue and therefore I do not think we should try to solve it. This is an ISP Policy/Provisioning issue.
The fast reuse of IP addresses have other impacts such as security, accounting, subscriber limits, etc. The ISPs today are aware of this issue since they are using or (trying to move) to a 'sticky' IP address approach where the same device gets always the same address and/or make sure it takes a 'safe' long time to recycle the same IP address to another customer. One could also argue that if the ISP is running the ALTO Service (or in partnership with a Content Provider) it is in its best interest to invalidate any IP/customer associated info whenever an IP address is dished out by the DHCP/Radius Server. But again, I think this is a generic provisioning problem ISPs face day to day. Thanks, Reinaldo On 10/13/09 6:52 AM, "Enrico Marocco" <[email protected]> wrote: > Hi all, > > as I happened to discover recently, in at least two cases of fairly big > ISPs IP addresses dynamically assigned to residential users are taken > from pools regardless of the subscriber contracts. As a consequence, in > such scenarios the same address could be quickly reassigned to users > that, despite being topologically close, have very different provisioned > bandwidth. So, while such reassignments are unlikely to happen to the > peers participating in a swarm -- or at least are not going to have a > significant statistical impact -- I can't figure any easy way to keep > such information updated in relatively static maps some of the proposed > solutions use (I can see how static maps AND dynamic queries can be used > together though). > > Now, we had several discussions about the usefulness of information > regarding provisioned bandwidth in peer selection without reaching > consensus, and honestly don't know how common such an address assignment > policy is. Thus I would be very interested in hearing what people think > about that, whether it should be something reflected in the requirements > and addressed by the solution, or simply just ignored. _______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
