Subject: [tcpm] FW: Tech points: draft-scheffenegger-tcpm-timestamp-negotiation-01

From: "Scheffenegger, Richard" <[email-masked]>
Date: Wed, 25 May 2011 15:29:01 +0100

Bob's comments were intended to go to the list also... 

From: Bob Briscoe [mailto:[email-masked]] 
Sent: Montag, 23. Mai 2011 16:58
To: Scheffenegger, Richard; Mirja KUEHLEWIND
Cc: [email-masked];
[email-masked]
Subject: Tech points: draft-scheffenegger-tcpm-timestamp-negotiation-01

Richard, Mirja,

1/ Because you are introducing the idea of different types of 
capability negotiation (e.g. range negotiation in Appendix A), I 
think it would be useful to divide the signalling protocol into two
parts:
a) Stuff that has to be common to all types.
b) Stuff for the baseline type defined normatively in this doc

a) Common to all types:
* EXO (which distinguishes all versions from RFC1323)
* the two bits after EXO, which seem to be used like a type field 
(but see later)

b) Stuff for the baseline type:
* MASK
* SGN
* EXP16
* FRAC16

Alternatively, given (offlist) you've said that MASK must be present 
in all future types of capability negotiation, it could be placed 
under category (a). However, I'm not sure how you know it will always 
be needed before future types have all been invented.

3/ In the baseline capability negotiation, the sign (SGN) bit is 
wasted, because it must be zero. As you're not using a float format 
identical to IEEE 754-2008, you might as well admit you are not 
precisely using the IEEE format and not bother with the sign either. 
You could simple say that the sign bit is hidden outside the wire 
protocol, as an implicit hard-coded sign defined in the specification.

4/ Could the MASK use up only 4 bits? Is anyone ever likely to want 
to mask more than 2**4=16 bits, given you already say (Section 6.4) 
that MASK>8 is discouraged.

Perhaps instead it would be better to use the following format:
        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |E| R |T|       |               |R|         |                   |
       |X| E |Y| MASK  |      RES      |E|  EXP16  |      FRAC16       |
       |O| S |P|       |               |S|         |                   |
       | |   |E|       |               | |         |                   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The 2-bit reserved field before the type would be useful if the 
number of types needed is eventually >2. Leaving it reserved allows 
it to be used for some other purpose orthogonal to types, if nec.
Note I've called the third field 'TYPE', whereas in draft-01 you 
called it a reserved flag, then called it RNG in the appendix.

(An alternative might have been to call it a version field, but that 
wouldn't be quite right. For instance, in Appendix A, although the 
TCP server understands what I would call type 1, it replies with a 
type 0 option. This doesn't have the same semantics as versioning.)

Are you expecting all hosts that support type 0 to also support type 
1 (RNG negotiation)? If not, you need to say what a type-0-only host 
would reply to a RNG request.

5/ For range negotiation (RNG, Appendix A), why not use the same 
FRAC12 field for the hi and lo end of the range, and only communicate 
hi and lo EXP12 fields? Surely it's not so important to specify the 
ends of the ranges precisely.

This would leave more space reserved for future stuff, when range 
negotiation was also needed.

However, I'm not convinced range negotiation is important. Can you
motivate it?

Bob

________________________________________________________________
Bob Briscoe,                                BT Innovate & Design

---

From: "Scheffenegger, Richard" <[email-masked]>
Date: Wed, 25 May 2011 15:54:43 +0100

Hi Bob, group,

I will post an updated version (-02) of this draft shortly.

A few of these observations were addressed already, but the majority is
still pending (but should be addressed in version -02).

The comment by Bob,
 
> However, I'm not convinced range negotiation is important. Can you

I would also like to get feedback from the list on.

The only sensible reason I could come up with to have range negotiation
(appendix A, really intended as example of a future enhancement) would
be for hardware-accelerated TCP NICs:

For one-way delay measurement with two different timestamp clock rates,
the sender would have to do multiplication and divisions for every ACK
received. I believe this to be a costly operation for very high speed
(1-10 Gbps) and low delay (local/metro area) environments. With both
ends of a TCP session using an identical TCP timestamp clock rate
(frequency), one-way delay variance calculation can be done by simple
additions/subtractions. From my understanding, simple integer operations
are constant in time, and quite fast. That calculation would then not
add additional jitter into the one-way delay variance signal.

Overall, I don't see a high motivation to do range-negotiation today.
Shall I keep this Appendix at all, then?

Richard Scheffenegger

> -----Original Message-----
> From: Scheffenegger, Richard
> Sent: Mittwoch, 25. Mai 2011 16:29
> To: [email-masked] Extensions
> Subject: FW: Tech points: draft-scheffenegger-tcpm-timestamp-
> negotiation-01
> 
> Subject: Tech points:
draft-scheffenegger-tcpm-timestamp-negotiation-01
> Perhaps instead it would be better to use the following format:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
> +
>        |E| R |T|       |               |R|         |
> |
>        |O| S |P|       |               |S|         |
> |
>        | |   |E|       |               | |         |
> |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
> +

---

From: "Scheffenegger, Richard" <[email-masked]>
Date: Fri, 27 May 2011 18:11:45 +0100

Intended to include the list!

-----Original Message-----
From: Bob Briscoe [mailto:[email-masked]] 
Sent: Donnerstag, 26. Mai 2011 13:38
To: Scheffenegger, Richard
Cc: Mirja KUEHLEWIND;
[email-masked];
[email-masked]
Subject: RE: Tech points:
draft-scheffenegger-tcpm-timestamp-negotiation-01

Richard,

I should have said,... I intended to split discussion into three parts:
- technical
- structural / clarity
- editorial details.

This is the tech part. It reviews the published -01 draft. I've 
shifted other stuff to a different thread.

inline...

At 15:23 25/05/2011, Scheffenegger, Richard wrote:

>The reason for mask to be present would be to fence off parts of TS.val
>that must be excluded from PAWS processing on the receiver side. That
>was also in the context of allowing a version0 receiver to reply always
>with version0, even if it cann't process the timestamp value for
>anything but PAWS (excluding the masked bits, where the monotonic
>increase property can be broken by the sender). A future version may
>specify what is in that opaque part for a compatible receiver still...

My question was whether there could be a version where the sender 
ensures timestamps monotonically increase, so MASK would not be
necessary.

I suspect I have not fully understood what the underlying need for 
MASK is. The doc seems to hint at two:
a) when not echoing timestamps to the rules in RFC1323, they might 
not monotonically increase
b) some senders add entropy to the low order bits of timestamps to 
protect against malicious tweaking of TSecr values

Am I correct?

My thinking is that b) would not be necessary in trusted 
environments. I'm now not sure whether a) will always be a requirement.

>correct; After thinking about this a bit more (I departed from IEEE-754
>originally but modified it already as you noted), that bit would serve
>best when re-shuffled for 1 bit higher precision.

I would argue it's OK to depart from IEEE-754 in some ways but not
others:

- Making the sign bit always 0 and outside the wire protocol is OK, 
because implementers are unlikely to get it wrong

- Adding 1 bit more precision to binary16 float representation is NOT 
OK, because implementers will have to tweak low level arithmetic code 
rather than using common libraries. Given the level of bugs that have 
recently been found even in really simple things like ECN or SACK, it 
is important to keep all changes really really simple.

>The only special value
>would be all-zero (this is included in the PDF, I hope you reviewed
that
>text) to indicate the timestamp values are not related to wall-clock
>time.

Yes, I noticed that.

In case anyone listening on the list is confused, Richard sent me an 
offlist preview of the proposed next rev, in PDF format.

>The mask field would make up to 31 bits completely opaque to the
>receiver (thus exclude those bits also from PAWS receiver-side
>processing, lifting any constraints like the monotonic increasing
values
>- PAWS would need that).
>
>The unstated reason for the full 5 bits was to cover up to 1/4th of the
>TS value, even when TCPCT (RFC6013) with the 64 / 128 bit timestamps
are
>in use, or if the sender wants to have a true hash value (segment
>digest) with each segment, or when the future contents of TS.val would
>be at odds with PAWS processing...

Understood. Will you be explaining this reasoning in the next rev?

I assume 1/4 is a member of the set of made-up numbers, see 
<http://search.dilbert.com/comic/Made%20Up%20Numbers> ;)

>Also, a future version could define some use of these masked out bits,
>but remain compatible with a version 0 receiver. Such a receiver would
>treat the TS.val as opaque entity again, and only the immediate echoing
>would remain as compatibility with future instances...

Again, I think this discussion shows that it would be useful to talk 
in the draft about what will be needed for any version and what will 
be only in some.

The WG needs to be able to decide where to draw the line between 
features that might be nice (mission creep), and features that are
necessary.

>RNG is no longer in the draft (the PDF version I sent you via email),
>that was in version -01.

Yup, I had noticed that. But, because I cc'd my email to the list, I 
tried to relate the discussion to draft-01 that everyone has seen, 
not the offlist preview you sent me.

>Appendix A refers to version 1, which would be
>sender (SYN, no ACK) only, and responded to with certain semantics - so
>that an identical (or at least known) timestamp clock rate can be
>arrived with only one exchange in each direction. (it'll be some time
>before tcp stacks would allow dynamic adjustment of their timestamp
>clock rates, I guess :) ).
>
>Yes, the -02 PDF has a 2-bit version field with the difference in
>semantics you point out. I really want this to be an enumeration, and
>the exact semantics (like a version 0 receiver is free to either ignore
>higher versions, or respond simply with version 0 always) are in the
>specs.
>
>I'm unhappy with "type" because that sounds like request/response - but
>implicitly, the active sender (SYN, no ACK bit set) is the requester,
>and the passive sender (receiver, SYN+ACK) is the responder. Having two
>different definitions in a single version of the timestamp negotiation,
>depending on direction(i.e. if the ACK bit is set or not), with one
>being identical to version 0 sounds like overkill - version 0 would
>already have the appropriate signaling for the response...
>
>In the PDF, I settled on version as that deviates the least as I
>understand it in the effective semantics.
>
>
>
>Yes, that is in the preliminary -02 draft (PDF); hidden as it is, with
>the Wire protocol specs. Need to fix this in the high level
description.

To repeat back to you, you are saying all version 0 implementations 
must also support version 1? Then I don't think 'version' is the 
right word for this. If you don't like 'type' either, then we need 
another word. What about 'kind'?

>I really couldn't come up with a decent use case for range negotiation,
>where it would be important that both ends run at the same clock rate;
>That's why I put this whole range negotiation stuff into an appendix,
as
>just an example of a future enhancement.
>
>You are completely correct, depending on what one wants to achieve with
>something like a range negotiation, more bits could be saved or
shuffled
>to better uses.
>A roll of the version number, and reshuffling of the signaling bits
>appropriately (i.e. a certain use may only be possible with tcp
>timestamp clocks ticking between micro- and milliseconds, instead of
>nano- to tenth's of seconds) would achive the same. Of course, if this
>signaling takes off, and people figure out clever ways to further
>utilize a timing / sideband channel in TCP, having just 4 enumerated
>versions available may be too few :). I think this discussion can be
>postponed until version 3 of the negotiation signaling is to be defined
>:)

You'll notice I suggested 2 bits of reserved space before the 1-bit 
type/kind/version field. That would allow extension to 8 
types/kinds/versions. But it also allows some other future use to 
burn those bits if we decide it's more important than allowing space 
for more types in future.

HOWEVER, every new variant faces a new deployment problem.
I strongly believe we should try to settle on a core extension to 
timestamping that the WG believes includes enough features for 
important stuff like one-way delay, and we draw a line above "would 
be nice to have" mission creep.

>Not really (the reason why it was pushed to an appendix as an example);
>The only sensible idea I have would be a hardware-assisted TCP stack,
>which does the timing processing on the NIC; with range negotiation,
>both TCP timestamp clocks could run at the exact same frequency,
>simplifying one-way delay variance calculations (so that wirespeed @
10G
>Ethernet becomes a possibility). As long as one-way delay variance
>calculations are carried out in software (main CPU), doing a division
>(or at least one multiplication) instead of only addition/subtraction
>should have very little impact really...

But then range negotiation doesn't help anyway, if both ends have a 
set of discrete frequencies their hardware can use and they are 
trying to find one they have in common. This requires an enumeration, 
not a range. That's tough to fit into a confined space.

>Again, thanks a lot for your insightful comments!

Cheers

Bob