Re: Ephemeral addressing [was Re: 64share v2]

[Lorenzo Colitti <[e-mail]>]

QUIC supports connection migration. See for example this draft:

https://tools.ietf.org/html/draft-tan-quic-connection-migration-00

In hindsight, the real reason mobility is hard is that TCP does not provide
its own session identifier and instead relies on the lower-level
identifiers (i.e., IP addresses) to identify its connections. So I think
part of the answer is that QUIC will solve this problem.

The other part of the answer, I think, is that it isn't actually a big
problem. I think we should remember that flash renumbering - as long as
it's clearly communicated to the application - isn't actually a difficult
problem for many of today's apps, at least on mobile. Modern mobile apps
primarily use HTTP, with either idempotent GETs or using POST with replay
protection tokens. Once you have that, why bother with IP or TCP session
continuity? For streaming use cases you can just use chunked requests at
the application layer, or, at worst, range requests at the HTTP layer. Good
networking libraries can, I think, be told which requests are idempotent so
they can seamlessly retry them. Real-time apps like video conferencing use
things like webrtc which can already deal with multiple concurrent IP
addresses (and thus mobility) via STUN.

So actually, the main problem with mobility is not dealing with the change
- that's easy - but noticing the change. This is why Android added a
feature to the Linux kernel where userspace can force given sockets to
return errors to the apps that opened them. The OS does this when a network
goes down, so the app can immediately retry on whatever other network is
available, ideally without ever showing the user an error. The default
Linux behaviour was that read() or write() on that socket would block
"forever" (i.e., at least for minutes). That was solved a decade ago.

The remaining hard problem is what do you do when wifi is still connected
but is not actually getting any packets through right now. For that you do
need an actual L5 protocol that can do multipath or at least connection
migration. One of the first apps to do this was Siri, using MPTCP. But
other apps are starting to use QUIC connection migration for that, since
it's a lot easier to build and deploy than MPTCP.

On Wed, Nov 11, 2020 at 10:36 PM <[e-mail]> wrote:

> Philip,
>
> >> Let me rename this thread as this opens a much larger issue.  While
> >> being able to rapidly reconfigure an end-user network using the
> >> layer3 primitives in 6man, I don't think it's worth solving unless
> >> also the upper layer problems are solved.
> >> - How do TCP connections
> >> survive a renumbering event?
> >> - How do applications get notified to
> >> reconnect?
> >> - Do all applications have to change as a result? Or
> >> use a different transport layer?
> >> - What happens with DNS configuration?
> >> Are you assuming everyone has DNS-SD deployed and working?
> >> - What
> >> about other configuration? Static addresses for example?
> >>
> >> Good luck I say...  Until then I suggest that we continue (to
> >> pretend) that addresses must be long-lived.
> >
> > My reality is that many addresses are short lived. Not because addresses
> > on a single link change often, but because mobile devices regularly
> connect
> > to new links.
> >
> > Static addresses are similar to old unix systems where you have recompile
> > the kernel and reboot for each new piece of hardware that gets added to a
> > system. Modern systems were forced to evolve because users expect to
> > plug in USB devices, connect bluetooth devices, etc.
> >
> > Does the world wait until the IETF solves renumbering? No. Just like the
> > world switched to NAT long before the IETF recognized there was such a
> > thing, most modern application deployments are essentially an overlay
> > network.
> >
> > Applications use https to connect to the cloud, session identifiers are
> > stored in cookies. Short sessions and short timeouts make renumber event
> > transparent to the application.
> >
> > Can TCP survive a renumber event? Yes, MPTCP should be able to that.
> >
> > How do applications get notified. The IETF and the Open Group failed to
> > create APIs for that. So every OS creates its own ad-hoc mechanisms.
> >
> > DNS support dynamic updates.
> >
> > But what we do at the transport layer may not be relevant. So we can
> focus
> > on making the network layer work.
> >
> > Or just stick to static prefixes.
>
> Seems to me the world waited. At least the one I'm leaving in did. :-)
> None of the systems I use handle renumbering. Barring a single application
> (mosh).
> Most of the building blocks are there, but in 20 years of waiting few if
> any have put them together.
> I doubt this is deployable in time to avoid users being forced to NAT on
> the edge, to protect themselves from instability in global addressing.
>
> Are we going to restrict all future IPv6 end-user networks that are forced
> to depend on PA addressing to be client only?
>
> Cheers,
> Ole
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>