Skip to content

Support for migration

Jump to bottom
Christian Huitema edited this page Mar 7, 2018 · 4 revisions

I am implementing the support for the connection migration. The work in progress is in the path_context branch. I started with the easy part:

  1. Create a "path" structure that holds the per path parameters for RTT, MTU, Congestion control.
  2. Initially, instantiate just a default path.
  3. Change the send processing (sender.c) so all the packet preparation functions are per path, and of course also congestion algorithm, rtt measurements, and path MTU.
  4. Change the retransmission process to remember the path on which a packet was sent, and use that information when processing ack or retransmissions.

The next issue is the handling of addresses, making sure that source/dest pairs of IP addresses and ports define just one path, and having some logic for creating new paths. Should we use some stateless verification on the server? We need a protection against the attacker who captures a large number of legit packets and sends them from a fake address. So maybe something like:

  1. On receiving a packet from/to a different address, checks whether it passes the usual tests, sequence number, decryption, etc. If that's OK, allow the packet to proceed through the receive chain.

  2. If this is the first packet on that address pair, create a challenge frame. Maybe use some "cookie" approach, e.g. hash of the addresses and a secret key to produce a 16 byte cookie. Send it back to/from exactly the specified address. Maybe use the same code path as stateless reset, etc.

  3. If the packet contains a challenge response frame, and the cookie matches, create a path.

Of course, there will also need to be a way to delete a path. If we just support migration, the latest path created becomes the default path, no data is sent on the other path, and it is closed after a while. If we support multipath, we need to be smarter. Delete a path if its quality drops below a threshold, not enough activity, etc. And of course only close the connection if it all paths are closed, not just if one path behaves badly.

For true multipath, we need to change the transmission scheduling. Currently, each context contains a variable, "when will the host be ready to send the next packet". It should be updated to answer "when and on which path". I need to update a "next wake time per path" when a packet is sent or received on a path, or when data is posted on a stream. Short term, we are hoping to handle just a couple of paths, so there is no need to be too fancy, scanning all paths will work just fine.

There is a relation between path creation and connection ID. The server proposes a list of connection IDs, the client picks one of them for each new path that is deliberately created. If the server proposes a connection ID, it should be able to process it on reception, i.e. associate it to the connection context.

Already found several issues that will need some resolution:

  1. If the MTU really is "per path", we can be on a situation where path #1 has an MTU of 1500 bytes, and path #2 1280 bytes. It will not be possible to simply "repeat the stream frame". Maybe we really need to revisit issue #16.

  2. Not clear at all that the ack delay should be per path. It is probably fine if it is a function of the fastest link. In any case, packets received on link 1 can well be acked on link 2.

  3. If the data is sent on one link and the ack on another, what is the effect on the RTT measurements?

Clone this wiki locally