Re: [tcpm] poll for adoption of draft-gont-tcpm-tcp-timestamps-03

[Fernando Gont <[e-mail]>]

Hi, Joe,

These are interesting points to be addressed/clarified. Thanks!

I will try to address these in the next rev of the document. --
Meanwhile, comments inline....

Joe Touch wrote:
> Presuming this is the path forward, one issue that needs to be
> addressed:
> 
> - what happens when one side assumes the timestamps are monotonically
> increasing, but they're not

Worst case scenario: the TIME_WAIT state cannot be recycled, and hence
the situation is no worse and no better than the current state of
affairs, namely:
a) The TIME_WAIT state is assasinated [RFC793], with the connection
request being rejected
b) The SYN segment is ignored, and thus the connection request times
out, or is accepted after future retransmissions of the SYN [RFC1337]


> As recent exchanges suggest, there are possible reasons why either
> side might want to implement timestamps differently. In that case,
> it's might not be realistic to assume monotonicity.

It's not really about assuming that timestamps are intentionally
monotonically-increasing. *If* they are, no matter whether that was by
choice or by chance, you can recycle the TCB.

*If* timestamps are monotonically-increasing, then you're sort of
assured that the aforementioned "heuristics" will work.

This parallels the processing of ISNs in the BSD hack (allowed by the
very RFC793). There are stacks that completely randomize the ISNs (e.g.,
OpenBSD). If the ISN of an incoming SYN is larger than the last SEQ seen
for a connection in the TIME_WAIT state, you recycle the TCB. If ISNs
are randomized, these heuristics may or may not kick in.


> It's not appropriate to consider client/server roles here; the issue
> is who shuts down the connection and thus holds the TIME_WAIT - that
> is often the server, but need not be.

What I meant is that the side more concerned with recycling TCBs in the
TIME_WAIT state is the server-side. And that the side that should
generate monotonically-increasing timestamps is the client-side.

You're right that which side remains in the TIME_WAIT state depends on
which side performs the "active close" (rather than on client vs.
server). But if it's the client TCB that remains in the TIME_WAIT state,
 the collision would not even occur, as it would be detected and avoided
by the client itself.


> Overall, if this suggestion requires the TIME_WAIT side assume 
> properties of the other end, it may *require* a flag to ensure.

I believe this is unnecessary. The beauty of this "TIME_WAIT tossing"
things is that this is a local policy, that can be applied even without
agreement with the other side.

Clearly, for the sake of this policy, it's better if clients generate
timestamps such that they are monotonically-increasing across
connections. If the chances of TIME_WAIT tossing are reduced.


> Given we're not talking about such a flag, the entire mechanism may
> be moot as a result.

THe "TIME_WAIT tossing" thing is a local policy, rather than a
mechanism. If clients generate timestamps such that they are
monotonically-increasing they clearly contribute to the success of this
policy. That's it.

Again, the heuristics performed by BSD-derived kernels with the ISN of
incoming SYNs when there's a previous incarnation of the same connection
in the TIME_WAIT state.

Thanks!

Kind regards,
-- 
Fernando Gont
e-mail: [e-mail] || [e-mail]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1