Mikael Abrahamsson wrote:
On Tue, 3 Mar 2015, Michael Sweet wrote:
True, but most video conferencing software and live video feeds
handle disconnects gracefully (enough) already, and most streaming
video is not done using a single file/URL but with a series of
files/URLs, with each file/URL representing a "chapter" or other
divisible unit within the program/movie being watched - there you
will either seamlessly transition to the new address when the next
chapter is fetched, or the application will detect the lost
connection/stalled data and then attempt a reconnect which gets the
new address.
So don't assume there will be problems when a network is renumbered -
a lot of the work that's been done to deal with unreliable networks
is equally useful for network changes, so long as the client
application does not assume the network address of a named service
won't change.
So where is the sweet spot? 10 minutes? 30 minutes? 1 hour? 3 hour? 6
hour? 12 hour?
I just tried this. I was on the same subnet on wired ethernet and on
wifi (etablished the call on wired with disabled wifi, enabled wifi,
waited 30 seconds, then unplugged wired) using my OSX macbook, using
Skype voice session with another skype user, and it took around 10
seconds to detect the outage, and another 20 seconds to re-establish
the call.
I tried the same procedure with Facetime audio, and it disconnected
the call after 10 seconds and didn't try to establish it again until I
manually did something.
Mosh fixes this with a 1-2 second outage.
I have no reason to believe the above behavior would be different if
the call was over IPv6 (which I presume it wasn't) and the address
went away because of a renumbering event.
So I'd say that at least two of the top VoIP clients on the market
have no functionality to gracefully (30 second customer outage isn't
gracefully) handling moving between two addresses. So applications
need to get a *lot* better at being endpoint address independent.
I read your requirements.
I think there are two completely separate mechanisms being discussed
here: the need for rapid failover to a previously known alternative
address for your partner device, and discovering the alternative
addresses of your partner.
The one thing I think that is still missing in the discussion is caching
in the name space. Whether name resolution of the remote partner address
be done via mDNS, DNS, or monitoring the currently established channel
between partner nodes like in shim6, whatever.
I / we know from experience with Appletalk II NBP and ZIP that 100%
dynamic a la minute server/name - address resolution doesn't scale well,
and certainly not beyond enterprise level.
So we know we have to have some sort of caching in the name space. Or
the list of partner addresses at the other end of the channel. Whatever.
You cannot poll your partner on MOSH every 1mSec to see if it has
changed its addresses.
I think caching in the name/address space sets a much more relevant
lower limit on the speed of renumbering/ roaming via L3 on wifi/
whatever other event that causes your host's address(es) to change.
Otherwise you're forced into either taking your L3 prefix with you and
using routing to the end host, or NATting the old address, or using
rendezvous points, or being able to deprecate cache contents. None of
which have proven particularly practicable.
So your 1 hour flash renumbering event seems way too small IMHO. 36
hours would seem more reasonable.
I think that time limit is completely independent of a node's ability to
fallback/fall forward to previously known alternative addresses (mSec
range).
And for the wifi roaming example: if a node already knew all of the wifi
prefixes in use in a Homenet, it could publish AAAA records well in
advance of any move for all possible interfaces it could attach to.
--
Regards,
RayH
_______________________________________________
homenet mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/homenet
