Subject: [rtcweb] Rehydration

From: Martin Thomson <[email-masked]>
Date: Tue, 13 Nov 2012 16:46:36 -0800

Preconditions:
  Two peers, each have the following state:
  * open candidates
  * remote candidates with consent state
  * nominated candidate pairs
  * (optionally) DTLS session negotiated
  * outbound media streams for which consent has been given
  * inbound and outbound media streams, some of which have media flowing
Trigger:
  One peer refreshes the page, or navigates to a page on the same origin.
Desired Outcome:
  An analogue of the above state is created with minimal latency and
no user interaction from the peer that did not refresh.
  The recreated session cannot re-use an SRTP key stream that may have
already been used.  Session continuation is OK, but restarting with
the same keys would expose the session.  In other words, don't re-use
your security descriptions.

The proposal made in the meeting (slide 11 of
http://tools.ietf.org/agenda/85/slides/slides-85-rtcweb-11.pdf)
proposes the following process:
 * Store old local description
 * Refresh page and create new PeerConnection
 * [Load old local description]
 * Apply old local description as offer
 * createOffer("RestartSession") to get new local description with new
ICE and crypto
 * Apply new local description as offer and send it
 * Apply received answer as remote description

It wasn't clear what properties are imparted as a result of setting a
previously built description.   It's also unclear if this is even
feasible.  We decided that setLocalDescription can only be called from
a createOffer/createAnswer callback at the W3C meeting.  Any new SDP
will be completely incompatible with the old SDP.

This proposal adds nothing if you are willing to pay the price of a
round trip.  Several, if you consider the need to re-run the DTLS
handshake.  It is possible to re-use some state at the non-refreshed
peer: consented streams, open candidates.  That is already necessary.

Everything else must be rebuilt.  The peer that refreshes must gather
candidates and obtain consent for user media.  Both peers still need
consent for new candidate pairs and the DTLS handshake must be re-run.
 Media would need to be re-attached to the connection in a consistent
fashion, for which it is non-obvious how.  Other related state must
also be recreated, such as whether particular streams are currently
paused.

Optimizations on ICE startup time are the only real possibility in
this proposal.  Prioritize the candidates that were previously in use.
 Avoid allocating relays if you weren't using them.  These are of such
marginal utility that I'd argue for SDP editing if applications cared
to do this.  Assuming that we can agree on an API for discovering
which candidate pairs were nominated.

If you are serious about rehydration, then we already have a far
superior solution:
 * Request a handle to the RTCPeerConnection instance
 * Store the handle
 * Refresh or navigate
 * Load the handle
 * Recover the RTCPeerConnection instance using the handle

No signaling would be necessary.  The handle would have a very short
lifetime after navigation to avoid resource exhaustion.  The handle
would also have to be origin-bound.  It would be necessary to sever
the ties to the old page when navigation occurs to avoid leakage
(event handlers and output tags).  It might not even be necessary to
reacquire consent either.

I tend to think that this alternative is probably more useful for
navigation than it would be for refresh.  Being able to navigate while
continuing a communication session would be nice.  On the other hand,
refresh is often used to "fix" "broken" pages.  Having the page
restore a "broken" RTCPeerConnection instance would be annoying.
Breaking handles on a "hard" refresh would be advisable if we pursued
this solution.

--Martin

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 14 Nov 2012 08:49:04 +0100

I'm somewhat leery of the rehydration concept - to me it seems like a 
lot of coding to get into a state that is unlikely to work reliably 
anyway. But anyway, since we're discussing it....

One problem with a "handles" based proposal is the question of where the 
context has to live - at the moment, Chrome is a multiprocess browser, 
and most of the context lives in the rendering process. Chrome's model 
says that if Bad Things (tm) happen, it's OK to let the rendering 
process die.

Refreshing the page after a crash will (of course) mean that there's a 
new rendering process.
Implementing a system of "recoverable handles" will then mean either 
that all the recoverable state has to live outside the rendering process 
or that rehydration will sometimes work and sometimes not.

The last outcome is one I would like to avoid.

On 11/14/2012 01:46 AM, Martin Thomson wrote:
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Martin Thomson <[email-masked]>
Date: Wed, 14 Nov 2012 09:06:37 -0800

In 13 November 2012 23:49, Harald Alvestrand <[email-masked]> wrote:
> I'm somewhat leery of the rehydration concept - to me it seems like a lot of
> coding to get into a state that is unlikely to work reliably anyway. But
> anyway, since we're discussing it....

I actually agree with you.  I wrote this as a follow up to the action
I took in the meeting.  I can understand the usability advantages, but
I'd rather focus effort on making startup faster under all conditions.

> Implementing a system of "recoverable handles" will then mean either that
> all the recoverable state has to live outside the rendering process or that
> rehydration will sometimes work and sometimes not.

That's OK.  If we were to pursue something like this, an application
would have to be prepared for the handle to be invalid.  For more
reasons than that.  Reload might take too long; the application might
be loaded after a long time away; the computer or browser might have
just started up; etc...

In the end, sometimes work, sometimes not is one price you would have
to pay for this.