[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: addition of TLV to locator ID or locator ID set



Jason Schiller (schiller@uu.net) wrote:

However, if one of the links to destination B is getting over loaded, then
destination B will want to migrate some traffic away from what most people
are seeing as the lowest latency link.

But this could be done by B adjusting some preference (e.g. a weight) instead of trying to pad something like a latency. For instance, if it turns out that the applications care more about throughput than latency, then inflating the latency number might not have the desired effect.


Of course, for host B to be able to send anything, it needs to somehow discover that the border routers sees overload on one link but not the other; I think this is another desirable feature of a signaling mechanism from the border routers (we talked earlier on the mailing list about the border routers being able to influence the source address selection). I view these as potentially useful optimizations; I'm not sure we should have shim6 depend on the existence of some such new communication mechanism from the border routers to the hosts.


I'm not married to the concept of using a TLV if there is a better
approach that is equally flexible. I proposed TLV as it seems very
flexible, can be used to carry multiple sets of values that can allows for
a complex nested sorting, and doesn't seem like a re-invention of the
wheel.

Multiple sets of values assume something about how the peer will interpret the values. If what A cares about is to tell B to prefer some other locators when sending to A, I think we can handle that by just allowing A to send updated preferences for its locators to B.
Once we agree on such a capability, then we can discuss what the actions should be on B's side (immediately switch vs. something else).



The question here is what are the solution spaces for path failure
detection, and do any of them fit nicely with trying to determin some sort
of forwarding plane measured "best" path.

Presumably a notion of "best" path is dynamic. If it can't be detected dynamically by A or B, then we have another case where the border routers need to tell the hosts in their site. But it isn't clear to me how a signal about the paths can avoid having to effectively tell all the hosts about all the paths. I think the hosts should only need information about the destinations/paths they are using, which seems a bit challenging in this context.


   Erik