[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