Re: delay as a metric, aggregation

[Jari Arkko <jari.arkko@piuha.net>]

Delay is a pretty good metric. I have a feeling that packet
loss is also an important metric when we are talking about
wireless interfaces and host multihoming, but I have no
data to back that up.

I liked your idea of comparing the nominal delay to
actual delay.

The synthetic coordinates idea from Cedric was a very interesting
one as well. I'd like to play with that if it became available. But I fear
that DNS storage etc. is a deployment barrier.

Anyway, I see two bigger issue here. The first one is the division
of work between IP and transports. If we are sure that we
can develop a simple scheme that works well, it would make sense
adding to that to the IP layer. But if we find out later that
we need to take into account variations in congestion level,
packet loss, etc., we may find ourselves adding a lot of
functionality to try to mimic what transports are already
doing. An approach that does not have this drawback would
be providing feedback from transports and ULPs to the
shim6 so that when they say "unacceptable", Shim6 would
attempt to find another path. This would still leave the
problem of the exploration process finding the right
alternative with a high probability of success. I'm not sure
we know how to do that. For instance, if the transports say
that while the current path works its too small bandwidth,
we test another one, switch to that, and then find out that
also is too small. Perhaps delay can act as a metric here,
but I'd prefer to see some experimental results to understand
how well it works.

The second issue is our ambition level with load balancing
functionality in Shim6. If the ambition level is so high that
we try to get the same session over two paths, then this
impacts transports. But even if the ambition level is
running different sessions in different paths, we
would still have to deal with congestion in some manner.
Ideally, we'd be adding sessions to a path so that
the existing sessions do not have to slow down.

If the ambition level is choosing the best path,
then we are in an area where delay could work
as a metric, I think. Finally, if the ambition level
is just choosing a path that gets some packets
through, we have no problems with the measurements.
However, because many configurations have a
high-bandwidth preferred path and a low-bandwidth
backup (e.g. wireless), and returning to the better
path is a requirement, I think.

--Jari