[CRIU] criu - Restoring TCP connections and timestamps

[Pavel Emelyanov]

On 11/20/2012 09:45 PM, Dilip Daya wrote:
> Hi Pavel,
> 
> On Tue, 2012-11-20 at 20:55 +0400, Pavel Emelyanov wrote:
>> 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 :)
> 
> Sure I'm ready to participate, but will tread softly with the help of
> your guidance.
> 
> Let me very briefly explain the motivation that stemmed from your great
> work on c/r TCP connections: I'm investigating in a kernel-level
> framework for live TCP connection failover at sockets-layer and hope to
> make minimal kernel changes that are acceptable to c/r project as well
> as include any changes to crtool.

Can you elaborate a little bit more on this? Do you try to implement a
system that keeps a full mirror of a socket on some other host and switch
to it in case of the original node crash? By full mirror I mean a socket
which has the state (as seen by the connection peer) exactly the same as
of the original one. This is slightly different from what c/r does, but
it makes perfect sense to come up with the unified solution for both.

> Thanks.
> -DilipD.
> 
>>
>> I think I should have a page on wiki that lists all the issues we haven't
>> yet fixed with tcp repair.
> 
> That will be a great!

Already did: http://criu.org/TCP_repair_TODO
This lists all the issues I'm aware of with the tcp repair.

> Thanks.
> -DilipD.
> 
>>
>> Thanks,
>> Pavel
> 
> .
>