[CRIU] criu - Restoring TCP connections and timestamps

Pavel Emelyanov xemul at parallels.com
Tue Nov 20 11:55:23 EST 2012


On 11/20/2012 08:21 PM, Dilip Daya wrote:
> 
> Re: tcp_time_stamp when restoring TCP connections
> 
> tcp_time_stamp:
> This is the low-order 32 bits of the jiffies counter and is used to
> generate the timestamp in the TCP timestamp option.  The timestamp
> option is included in almost every outgoing TCP packet and is used for
> two purposes.
> 
> For PAWS, it acts something like a high-order extension of the packet
> sequence number.  If the receiver sees a timestamp value less than what
> it previously got on the connection (modulo 2^31), it assumes the
> sequence number is from a previous wrap and discards the packet.  The
> timestamp generator must therefore never decrease.
> 
> The jiffies counters on separate systems can be any value when restore
> occurs, so the restore system has a good chance of generating timestamps
> less than that of the original system and the this will start dropping
> packets.  This problem was discussed in the paper "TCP Connection
> Passing" by Werner Almesberger, which is the basis of previous
> connection migration code for Linux.  The solution given in that paper
> is to save an offset for each connection that is applied to
> tcp_time_stamp when generating the TCP timestamp option.  The offset is
> calculated to ensure the timestamps never decrease.
> 
> Connection Repair does not appear to do anything special for timestamp
> generation and I'm wondering how it gets away with that.
> 
> => So looking at Linux kernel code snippets, does the following take
>    care of the this issue?

You're right, the tcp repair feature is not complete yet. Currently we're
concentrated on making it work when doing c/r without changing the kernel.
If you can participate in this things will get fixed faster :)

I think I should have a page on wiki that lists all the issues we haven't
yet fixed with tcp repair.

Thanks,
Pavel


More information about the CRIU mailing list