[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <20130122.162410.201366520574331812.davem@davemloft.net>
Date: Tue, 22 Jan 2013 16:24:10 -0500 (EST)
From: David Miller <davem@...emloft.net>
To: ncardwell@...gle.com
Cc: avagin@...nvz.org, netdev@...r.kernel.org, criu@...nvz.org,
linux-kernel@...r.kernel.org, kuznet@....inr.ac.ru,
jmorris@...ei.org, yoshfuji@...ux-ipv6.org, kaber@...sh.net,
edumazet@...gle.com, ycheng@...gle.com, xemul@...allels.com,
davej@...hat.com, mtk.manpages@...il.com
Subject: Re: [PATCH net-next] tcp: add ability to set a timestamp offset
From: Neal Cardwell <ncardwell@...gle.com>
Date: Tue, 22 Jan 2013 16:18:04 -0500
> On Tue, Jan 22, 2013 at 3:52 PM, Andrey Vagin <avagin@...nvz.org> wrote:
>> If a TCP socket will get live-migrated from one box to another the
>> timestamps (which are typically ON) will get screwed up -- the new
>> kernel will generate TS values that has nothing to do with what they
>> were on dump. The solution is to yet again fix the kernel and put a
>> "timestamp offset" on a socket.
>
> One serious issue with this patch is that outgoing timestamp values
> will no longer correspond to tcp_time_stamp, so echoed timestamp
> values will also no longer have a meaningful relationship to
> tcp_time_stamp. That violates assumptions made in several places in
> the code, which assumes that we can compare echoed timestamp values to
> tcp_time_stamp; for example, there are several places where we do
> things like subtracting:
> tcp_time_stamp - tp->rx_opt.rcv_tsecr
> to find the estimated RTT for a segment.
Right, this change seems pretty bogus as-is.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists