Juliusz Chroboczek wrote:
So even though link-local multicast may be part of the IPv6 base spec,
it may be desirable to avoid use of multicast traffic where
possible. e.g. a routing protocol could perform initial neighbor
discovery using multicast, but then switch to unicast when maintaining
individual neighbor associations on the longer term, or for exchanging
information with specific neighbors.

Ah, I see.  Yes, that makes sense.

Then I think I don't understand what is meant by "multi-path support".  Is
that merely the ability to switch to a better route if one becomes
available?  Or is there something more to it?  Could you please clarify?

"The inclusion of physical layer characteristics including bandwidth,
loss, and latency in path computation should be considered for
optimising communication in the homenet."

I interpret the above text as requesting an ability to perform load
balancing over equal cost paths, potentially taking into account packet
loss and link quality when selecting which stream to send over which link.

I don't.  I interpret that as meaning that the routing protocol should be
able to pick a path using more refined criteria than just hop count.
E.g. to prefer a 1Gb/s link to a 100Mb/s one, or to prefer two wired hops
to a single wireless one.  Doing that is not too difficult, and yields
dramatic performance improvements in some fairly simple, realistic
topologies.

Load sharing is a completely different headache.  Done carelessly, load
sharing causes issues with increased latency and jitter, and causes
intermittent connectivity problems that are very difficult to troubleshoot
if one of the links is unreliable.  It also has ghastly performance if you
balance across wireless links without taking radio interference into account.

While it's certainly an area worth experimenting with, I'd be cautious
about requiring load sharing in Homenet unless somebody knows how to do it
right in the general unadministered case.

-- Juliusz


Your interpretation of the current architecture text also seems perfectly valid, and is indeed much simpler to implement.

Should the text then rather say "Path selection in Homenet needs to be more sophisticated than measuring pure hop count due to the use of heterogeneous link technologies, and therefore the routing protocol should be capable of utilising multiple link-dependent metrics, such as bandwidth, delay, and link reliability", rather than mentioning "optimised"?

IMHO That revised text would provide a very clear selection criteria for preferring certain routing protocols over others.

Or do you think the text is OK as is?

--
Regards,
RayH

_______________________________________________
homenet mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/homenet

Reply via email to