Re: [tcpm] timestamp options (was Re: New Version Notification for draft-touch-tcpm-tcp-edo-01.txt)

[Joe Touch <[e-mail]>]

On 5/28/2014 1:17 AM, Scheffenegger, Richard wrote:
> Hi Joe,
>
>> Late negotiation has too many problems, as have been repeatedly raised on
>> this list:
>>
>> 	- prevents use of the timestamp to help address PAWS for
>> 	the initial SYN
>
> This one is genuine. However, given the prevalence of non-TS TCP
> sessions and no wide-spread havoc caused by NOT having PAWS on the SYN,
> it appears to me that the impact is manageable. (Of course it would be
> nicer to have PAWS on SYN, but as long as SYN option space is limited...)

I don't know the stats, but I'd prefer if initial connections were 
PAWS-protected.

>> 	- a new connection that either avoids TS in SYN or
>> 	uses just "use TS" (two-byte) flag can't know when
>> 	to engage the timestamp and what initial value to use
>
> Well, as this would be a new mechanism, there should be some broad
> guidance given; I would assume that the latest onset - if late TS is
> negotiated for - would be when either direction has sent at most 2^31 -
> (2^16 << Window.scale) bytes; and a receiver that sees the full TS must
> then start to reflect TS as usual, independent of its own relative
> offset into the session. And never relinquish from sending TS even when
> some packets - ie. retransmissions, or due to middleboxes on a changed
> path - not contain a TS from the other side.

I had thought of a similar mechanism, e.g., where there would be an 
extended sequence number (ESN), and the upper bits would be assumed zero 
until actually needed.

The advantage to that would be:
	ESN flag would occur in all segments
		length = 2 until needed
		length can increase as additional bytes/words are needed

i.e., the meaning and use of the flag would never change; it would be 
synchronized at the start in both directions. It would just be 
compressed until actually needed. If you have a recent connection that 
already wrapped, you might start with ESN of length = 4 rather than 
length = 2 (0 in both directions), so you can sync non-zero ESNs.

The only benefit would be that this is a lot shorter than timestamps - 
i.e., it'd be 4 rather than 10 bytes.

(is this "Extended Sequence Number" option worth explaining in detail, 
e.g., in a separate draft?)

---

Doing real TS's later in the connection requires a new sort of 
synchronization in the middle of the connection - which, as I noted in 
my other post, seems to require a TWHS mechanism, and I think that's too 
cumbersome.

> As for the semantic change, I propose that when the session has SACK
> enabled as well as late TS, then the TS should reflect the TS of the
> segment triggering the ACK (we can discuss what should happen during
> in-sequence delayed ACK processing though; the relevant aspect for me is
> during loss - SACK recovery - to not mask the timestamps of
> retransmitted packets as per 1323bis; For legacy RTTM processing, the
> presence of a SACK option is indicative enough to NOT do normal RTTM
> processing - although a sender could choose to do so particularly for
> the loss recovery episodes. Having the (unique) Timestamp/SACK block
> combinations during loss recovery would allow more efficient, faster and
> also packet conserving recovery of lost retransmissions - unlike the
> current method of last resort, RTO.

Perhaps, but I don't see this paragraph as being related to late TS.

Joe