Subject: [tcpm] FW: Structure/clarity: draft-scheffenegger-tcpm-timestamp-negotiation-01

From: "Scheffenegger, Richard" <[email-masked]>
Date: Fri, 27 May 2011 21:17:31 +0100

-----Original Message-----
From: Bob Briscoe [mailto:[email-masked]] 
Sent: Donnerstag, 26. Mai 2011 14:23
To: Scheffenegger, Richard
Cc: Mirja KUEHLEWIND;
[email-masked];
[email-masked]
Subject: Structure/clarity:
draft-scheffenegger-tcpm-timestamp-negotiation-01

Richard,

I've split the thread into three:
- technical
- structural / clarity  <<<--- this posting
- editorial details

We need to explain to people on the list that I had criticised 
draft-01 for not explaining the problem, so you sent me an offlist 
preview of draft-02, and I replied (also offlist) with proposed text 
as an introduction to the problem.

>Hi Bob,
>
>thank you very much for your extensive list of improvements the draft
>must have!
>
>May I add you as additional author, I really like the introduction
>section / layout you provided!

You're free to use it - I wanted to help this draft to be understood, 
as I think it will be useful for many purposes (including one of my
own).

I'm OK just to be acknowledged. I'd rather not take on another 
co-authorship at the moment, as I would then feel committed to 
continued invovlement, which I cannot promise given my current
commitments.

>I have written a problem statement earlier, but commented it out of the
>draft; I think that is more appropriate when starting the discussion
>about the normative wire protocol - see below.

This would have been very useful if it had not been commented out! It 
gives exactly the sort of introductory information, the ommission of 
which made me struggle to understand the doc without reading it more 
than once through.

Feel free to merge it with my suggested text.

I've added one or two thoughts inline...

><!--
>     <section title="Problem statement">
><t>
>Timestamp values are carried in each segment if negotiated for. 
>However, the content of this values is to be treated as an opaque 
>entity by the receiver. This document describes an enhancement to 
>the timestamp negotiation, and must meet the following criteria:
>     <list>
>         <t>Indicate the (rough) timestamp clock rate used by the 
> sender in a wide range. The slowest rate should be slower than 1 
> sec, while the highest rate should allow unique timestamps per 
> segment, even at extremely high link speeds. At the time of 
> writing, this highest clock rate was assumed to be 64 byte packets 
> (i.e. ACK segments) sent at a rate of 100 Gbit/s. This would set 
> the highest rate at about 5 ns.</t>

I know you wrote the terminology section to give yourself a license 
to say rate but mean duration. However, I would strongly advise 
against redefining a word to mean something it doesn't actually mean 
in normal usage. A manual on good writing style would say this is a 
sign that the author hasn't spent enought care and time to find the
right word.

>         <t>Allow for timestamps that are not directly related to 
> real time (i.e. segment counting, or use of the timestamp value as 
> a true extension of sequence numbers).</t>
>         <t>Provide means to prevent or at least detect tampering 
> with the echoed timestamp value.</t>
>         <t>Allow for future extensions that may use some of the 
> timestamp value bits for other signaling purposes.</t>

Do you mean some of the timestamp bits in data packets, or in the
SYN/SYN-ACK?

Mission creep?

>         <t>Signaling must be backwards compatible with existing TCP 
> stacks implementing basic <xref target="RFC1323"/> timestamps.</t>
>         <t>In-session signaling must not add sender or receiver 
> complexity.</t>

I think I would just list required features. Things like backward 
compatibility and simplicity are different (I would avoid listing 
requirements where the converse would clearly never be a requirement 
- 'motherhood' requirements).

>         <t>Support current schemes for timestamp value generation.</t>

Need to explain why this is different from backward compatible, or 
merge into that bullet.

>         <t>Allow for timing information to be gathered during the 
> initial handshake.</t>

I think you mean state timings explicitly to avoid a training phase 
that would have to extend beyond the initial handshake.

>         <t>Possibly provide a means to disambiguate resent SYN
segments.</t>
>     </list>
></t>
><t>
>To support these design goals, only the TSecr field in the initial 
>SYN can be used directly. The response from the receiver has to be 
>encoded, since no unused field is available. The most straighforward 
>encoding is a XOR with a value, known to the sender. Therefore, the 
>receiver also uses TSecr to indicate it's capabilities, but 
>calculates the XOR sum with the received TSval. This allows the 
>receiver to remain stateless and functionalities like syncache can 
>be maintained with no change.</t>

This is solution, not problem.

However, a para like this at the start of the signalling section 
would have helped me understand much better.

><t>
>Furthermore, some legacy implementations exist that violate <xref 
>target="RFC1323"/> in that the TSecr field in a SYN is not cleared. 
>This is mitigated by verifying that one specific bit (EXO), plus any 
>reserved bits (currently 9, RES and SGN) are set accordingly. This 
>reduces the chance of a receiver mistakenly negotiating the 
>timestamp capabilities to less than 0.1% when passively receiving a 
>TCP handshake from a misbehaving TCP sender.</t>
>         <t>

This starts to stray from problem to solution.

BTW, the risk of false positives is only 0.1% if the non-compliant 
TCPs are random. We ought to know what they do, because if they set 
TSecr in a SYN to a particular value, all we have to do is avoid it. 
And if we don't avoid it, the risk of false positive would be 100%, not
0.1%.

>As there exist some benefit to change the receiver side treatement 
>of which timestamp value to echo, the negotiation protocol itself 
>must also provide some backwards compatibility. Therefore, even when 
>a sender tries to negotiate for a higher version then is supported 
>by the receiver, the receiver MUST respond with at least version 0. 
>Furthermore, if selective acknowledgements are also negotiated for, 
>the immediate echoing of the last received timestamp value has to be 
>enabled regardless of the senders version of the timestamp 
>capabilities. Also, the receiver must ignore an indicated number of 
>opaque bits, before applying heuristics defined in <xref 
>target="RFC1323"/>, because the monotonic increase for each newly 
>sent segment may not be applicable. This lead to the presented 
>distribution of the fields, with three fields (EXO, VER and MASK) 
>that MUST be present regardless of version in the uppermost octet, 
>while the lower three octets MAY be redefined freely with subsequent 
>versions of this negotiation protocol.</t>

This is straying into solution, not problem.

><t>
>The wide range of indicated timestamp clock rates (spanning at least 
>9 orders of (decimal) magnitude, or 28 binary digits, and the 
>limitation to no more than 24 bits requires the use of a logarithmic 
>encoding. For simplicity, a format was choosen that conforms with 
>the format of a IEEE-754 representation. Most stacks will at first 
>not be able to dynamically adjust their timestamp clock rate, so 
>that this pattern can be a static, compile time value. To use the 
>indicated clock rate, for example to perform one way delay variance 
>calculations, simple integer operations can be used.</t>

Again, straying into solution, not problem.

></section>
>     -->

Cheers

Bob

________________________________________________________________
Bob Briscoe,                                BT Innovate & Design

---

From: "Scheffenegger, Richard" <[email-masked]>
Date: Sat, 28 May 2011 13:08:29 +0100

Hello Bob, group,

please see inline.

[text donation]

Out of curiosity, is this purpose already contained in the list of
possible use cases? 

If not, would you mind to mention it in a rough sketch so that I can add
it?

> > I have written a problem statement earlier, but commented it out of
> > the draft; 
:
> Feel free to merge it with my suggested text.

I included the problem statement as a separate section after your text
contribution, because it already goes into a lot of detail. I think for
someone trying to get the overall picture fast, your text really is the
best approach.

Also, I disentangled the problem / solution comments, as you mentioned
in this email.

> sign that the author hasn't spent enought care and time to find the

Well, rate (frequency) and duration can easily be converted. 

The reason for having duration in the wire protocol instead of frequency
is to have high precision floating point values available for long
durations (low frequencies). I agree that the dynamic range of an
almost-binary16 would be enough for the relevant problem, but using the
duration of a clock tick allows even higher clock rates to be indicated
(by 3 decimal magnitudes), so that CPU cycle counters running at GHz
rates could be used directly  as timestamp value clock source (provided
the CPU doesn't shift frequency gears :). 

>From the remainder of the text, I feel that text talking about a "clock
rate" (frequency) flows better than a text talking about tick durations
- technically, I don't see much difference for the discussion of the
feature.

I do agree this is overkill right now, but may be an interesting aspect
for experimental hardware implementations.

Also, I added some section, because to my understanding, everyone is
using the TCP clock as timestamp clock source*. This comes naturally,
when the timestamp is only useful for RTTM; but when indicating "real"
time with higher precision, any other clock source could be used. In a
discussion with William Simpson, he indicated that the TCPCT extended
timestamps are intended for direct NTP timestamps, even though the
document is never explicit about that aspect...

[* glad to hear about counter-examples]

> And if we don't avoid it, the risk of false positive would be 100%,
not

Actually, there are two issues: 
The chances that the receiver is using TSval from a misbehaving sender -
this is quite low assuming random scrambling of bits <0.1%, as 11 bits
have to match (EXO, VER, RES). This is the more problematic one as the
receiver (passive sender) may perform decisions based on invalid TSval
data...

The second issue is the fact, the semantics of TS get changed by the
receiver with a much higher likelihood (37.5%), but no enhanced
heuristics are allowed to be enabled on the receiver side. This change
in semantics may cause a sender to arrive at too small RTOs, increasing
spurious retransmissions, and self-inflicting lower bandwidth. 

Both issues can only happen with host not compliant to RFC1323, and
since such a host is not mischievously feeding fabricated information to
the receiver, it's almost certain that such a session would perform
worse than normal. That should be motivation to upgrade the misbehaving
sender...

Talking about mission creep: 

I would like to get feedback from the community, if indicating the
stability/precision of the senders timestamp clock source is seen as a
viable feature.

With a IEEE754 type floating point representation, and the implicit lead
bit in the fraction field, this is not possible (and decoding has a
conditional on the exponent). However, as SGN is really not useful, the
exponent field and fraction field could be expressed completely
explicit.

Thus, up to 11 different representations could be chosen for the same
value:

EXP=10, FRAC= 1.0000 0000 00
EXP=11, FRAC= 0.1000 0000 00
:
:
EXP=20, FRAC= 0.0000 0000 01

Obviously, the first representation carries a lot of significant bits,
indicating that the sender has high confidence in the TSval signal it
sends; the last representation has only a single bit significance, thus
the TSval duration may not be known by a wide margin (+- 50%) to the
sender, and a receiver may want to take this difference in precision
into consideration when enabling different heuristics...

Also, a conversion of the float representation to an integer becomes an
unconditional bit shift by a known value...

Best regards,
   Richard