RE: connection migration

[Mike Bishop <[e-mail]>]

No; in the TCP case your transport doesn’t have any migration provision, so it’s up to the application whether it wants to wind down the existing connection and start a new one.  If migration fails with QUIC, the situation is exactly the same, and the application decides whether it wants to wind down the existing connection and start a new one.

If there’s more than one application, then the answer to “which application” is “each application” because each application owns its own connections.

From: Roni Even [mailto:[e-mail]]
Sent: Wednesday, November 15, 2017 3:44 PM
To: Mike Bishop <[e-mail]>; QUIC WG <[e-mail]>
Subject: RE: connection migration

inline

From: Mike Bishop [mailto:[e-mail]]
Sent: יום ד 15 נובמבר 2017 08:23
To: Roni Even; QUIC WG
Subject: RE: connection migration

Exactly the same way that TCP-to-TCP handoff between these interfaces works today, because (non-MP) TCP isn’t capable of changing to a different interface.  We’re trying to build a better answer, but you’re positing from the start that connection migration fails, so we’re now in “no worse” land.

The QUIC stack in the client device will see a new interface is available.  It attempts to switch to it, because of some local policy.  The transition fails for whatever reason, but the cellular connection is still active.  It is the application’s choice
[Roni Even] which application if there is more than one? In the TCP case you stay in the cell. Here there are two options, stay on the cell with QUIC or move to wifi on TCP
whether it wants to wind down and close that connection and start a new one using TCP, or keep using the old one if the interface remains available.  If there are multiple applications, each application makes that choice independently.

And if the first interface becomes unavailable for whatever reason, the choice is made for it, and the application will have to recover.

From: Roni Even [mailto:[e-mail]]
Sent: Wednesday, November 15, 2017 1:25 PM
To: Mike Bishop <[e-mail]<mailto:[e-mail]>>; QUIC WG <[e-mail]<mailto:[e-mail]>>
Subject: RE: connection migration

So what is the connection migration flow here. The quic stack in the cell network will try to migrate to wifi without application request and fail but will not fall back to TCP.
There may be multiple application running over quic? HTTP and peer to peer at the same time, so who will handle this case?

Roni

From: Mike Bishop [mailto:[e-mail]]
Sent: יום ד 15 נובמבר 2017 05:35
To: Roni Even; QUIC WG
Subject: RE: connection migration

That may well be the case, but it’s not the QUIC stack’s choice to make.  The application could choose to open a new connection, but that remains outside the scope of the transport and the mapping to it which we’re defining.

For HTTP, this is fairly straightforward – it could stop issuing new flow control credit, let currently-in-transit data arrive and any losses recovered, and open a TCP connection to issue a range request starting at whatever data offset it hasn’t seen.  But that’s still a property of an HTTP management above the HTTP/QUIC mapping.

From: QUIC [mailto:[e-mail]] On Behalf Of Roni Even
Sent: Wednesday, November 15, 2017 11:25 AM
To: QUIC WG <[e-mail]<mailto:[e-mail]>>
Subject: connection migration

Hi,
When moving from cell to wifi the reason may be due to cost (money or quota). In this case the  user (client) may want to move to wifi even if it will mean dropping to TCP.

Roni