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

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

> From: Bob Briscoe [mailto:[email-masked]]

> > > 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.

> > 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.

Well, transparent timestamps will have to live in a potentially hostile
environment; For example, Linux 2.6.13 .. 2.6.22 used TSecr directly in
CUBIC congestion control, and malicious receivers could exploit that to
get a unfair large share of bandwidth; The linux community then appears
to have decided to throw out the baby with the bath water - and
currently they don't use TSecr directly, but perform a per-segment RTT
tracking based on other clues...

If b) is not necessary, the sender (receiver) is free to set MASK=0.
However, algorithms critical for TCP (such as congestion control) would
still need to check the plausibility of returned timestamps (see my
comment about CUBIC).

With a MASK that could cover almost the entire TSval field, the PAWS
test at the receiver is very simple to implement in a future-proof
version (simply shift right the TSval before performing PAWS). This may
become in handy if different kinds of entropy are added the the TSval by
a future version (that the receiver doesn't understand, but where the
sender still wants immediate reflection of TSval, and the receiver still
can perform PAWS with the last remaining unmasked bit...

Having one bit set aside for "TS will be strict monotinic increasing"
will not fully solve this, as you still would have to have a mask field
to demark where potentially added entropy begins; the sender timestamp
clock value should still be recognizable by the receiver...

I agree that having 5 bits (0..31) appears to be overkill, but with 64
or 128 bit timestamps, the fraction of reserved bits would be smaller.

Perhaps I need to explicitly state, that the non-masked bits have be
non-decreasing (monotonic increasing with sequence numbers, strictly
monotonic increasing between windows). With that property, having a
single unmasked bit is pointless (because +1 and -1 have the same
result). Thus a MASK=31 could be interpreted as all bits are opaque to a
version0 receiver, and the highest meaningful value would be 30 (leaving
the topmost 2 bits for PAWS).

Actually, I was just made aware of the fact, that making TSval truly
opaque without any constraints such as for PAWS could allow a data
payload CRC, as discussed in
http://tools.ietf.org/html/draft-ietf-tcpm-anumita-tcp-stronger-checksum
-00; provided that both ends agree on the scheme (tbd in a IANA
sanctioned future version :) ).

Does that sound reasonable?

> > 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.

I understand that many OS (and SOCs) can not do floating point in the
Kernel, and if, then binary16 is often not implemented in hardware.

Thus, some bit-banging will be required to find the correction factor
between local and remote timestamp clocks for OWD calculation.

Actually, your argument works in my favor :) 

If the representation is suspiciously close to IEEE-754, an implementer
may simply put that into a regular float16 library; however, EXP=31
would mean infinitiy/NaN in such an regular IEEE library, which would
probably lead to even more intricate bugs...

Having a spec that is off by 1 from something very similar may help
implementers to read the spec more closely (to discover that one can not
simply put this into a float16, multiply with 2^-13 and be done with
parsing it).

Anyway, I'm not feeling very strong about how this bit finally ends up
either way :)

> > 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.

One point here - setting the indicated clock rate to 0 would not be the
same as masking everything out (in my thinking), as even not wall-clock
related TSval would have the property to monotonic increase with
advancing segments... (allowing PAWS by the receiver, even when enhanced
timing uses as to be disabled).

> > > 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.
> >
> > 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?

Will do!

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

You need to start somewhere :) 8 bits out of 32 (as in the draft already
recommended) is also 1/4 - we have consistency there.

> > 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.

I'll be happy to take advice in that space. Based on this discussion, I
did expand the possible use cases where a mandatory "mask" would make
sense for backwards compatibility; as discussed, the unmasked portion
would hold to the constraints imposed by rfc1323 (monotonic increase in
value between segments), while the masked (opaque) part is excluded from
this limitation.

> > > 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.
> >
> >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 :) ).
> >
> > > (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.)
> >
> >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.

> 
> 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'?

Well, a receiver that understands the EXO bit, has to reply with at
least version 0 (regardless of the version sent to it).

For a received version 0, it can do additional checks (to verify if the
sender wasn't just misbehaving), while for any other version, the
receiver couldn't to local time-based calculations, only the traditional
PAWS check...

I think the EXO bit is what you had as TYPE, with my VERsion field being
specifics about the semantics...

If it aligns better with standing naming practices, perhaps "VER" should
really be a message type as a whole, and the semantics describe, how a
receiver has to deal with unknown types (respond with type 0, or
(discouraged) traditional RFC1323). 

Basically:

(receiver version 0)
EXO=0 -> RFC1323
EXO=1, VER=0 -> VER=0
EXO=1, VER=1..3 -> VER=0 (or RFC1323)

A future spec may stipulate

EXO=1, VER1 -> VER1 in return, or (as in Appendix A) VER1 -> VER0 etc...

> > > 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.
> >
> >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.
> >
> >
> >
> > > This would leave more space reserved for future stuff, when range
> >negotiation was also needed.
> >
> >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.

>From my point of view, 3 enumeration points are still unused; I would
like to keep the 5-bit mask though, but one bit could indicate if MASK
is valid (and if MASK is not valid, a version 0 receiver would need to
treat the TSval as completely opaque entity (no PAWS allowed):

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|E|V|V|         #               |         |                     |
|X|L|E|  MASK   #      RES      |   EXP   |        FRAC         |
|O|D|R|         #               |         |                     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

VLD (valid) ... must be set (MASK valid); if unset, treat TSval opaque
VER (or TYPE) ... 0 (or 1 - compatible with v0 receivers)
MASK # of LSB bits to exclude from PAWS (timestamp) calculations

If VLD=0, MASK gives 5 bits to burn otherwise; some possible features
that would require MASK=31 can simply set VLD=0 for the same purpose...

> > > However, I'm not convinced range negotiation is important. Can you
> >motivate it?
> >
> >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.

I believe it was Anantha Ramaiah, who also suggested to have an
enumerated "typical" rate/frequency... With 24 bits available, 24
"common" rates could be defined in a range-negotiation type (sender
sends timestamp capability with the locally supported rates (appropriate
bits set), and the receiver picks the one it can also support (or none)
in the 2nd packet...

Anyway, this is all possible, once it becomes clear that the basic
functionality is worthwhile to have (and exactly the reason, why I try
to allow a multibit version/type field.

Best regards,
   Richard

---

From: Bob Briscoe <[email-masked]>
Date: Tue, 31 May 2011 16:39:17 +0100

Richard,

> >    timestamps to protect against malicious tweaking of

You haven't answered this question really - it really needs answering 
in the draft as part of describing the problem.

>If b) is not necessary, the sender (receiver) is free to set MASK=0.

True.

HOWEVER, that still means implementers have to support MASK!=0. That 
adds quite a bit of complexity to their TCP code to support some 
tricky crypto-heuristics.  Given it seems some implementers cannot 
even get basic things like 2-bit ECN or SACK right, this seems to be 
setting the bar very high.

I am not saying security isn't important. I am saying that mandating 
security features is often worse than no security at all, because it 
forces people to have to implement complex security techniques when 
they aren't capable of doing so properly.

>still need to check the plausibility of returned timestamps (see my

Whether to make security mandatory is a question for the w-g if this 
draft becomes a wg item - no need for us to argue further on this.

>can perform PAWS with the last remaining unmasked bit...

I agree it's clever. I was just thinking that a future version might 
prefer to have more space for something instead of the MASK.

My comments were in the context of this text added in the -02 PDF 
draft: "MASK: ... This field MUST be present in all future version of 
timestamp capability fields."

I'm not saying don't include MASK, just don't make it mandatory for 
all future versions. I would try to say as little as possible is a 
MUST for future versions as yet uninvented.

>the topmost 2 bits for PAWS).

That reminds me, I suggest you avoid using the term opaque, but 
instead say exactly what you mean (the field need not have any 
semantics that the echoing node can check or understand).

Opaque is nearly as ambiguous as the word transparent, which some 
people use to mean you can see something and others mean you cannot 
see it (you see through it).

>Does that sound reasonable?

Well, it wouldn't make sense to give implementers a dilemma that they 
could only use a bigger checksum or timestamps, but not both.

And anyway, I don't think a CRC needs the semantics of echoing.

>probably lead to even more intricate bugs...

It would be best to specifically say that EXP=31 MUST signal 
something exceptional, so implementers have to catch it before a library does.

>Anyway, I'm not feeling very strong about how this bit finally ends up

I see your point. I would lean towards simplicity wherever possible, 
rather than making implementers have to do complex coding.

>timing uses as to be disabled).

Understood.

> > > > Perhaps instead it would be better to use the following format:

No, I wasn't thinking that. Your EXO field is like a "Not vRFC1323" 
flag, so it's a part of a version field. Whereas your VER field 
doesn't seem to have the semantics of Version, because a v1 receiver 
replies to a v1 request with a v0 reply. This is purely a terminology 
problem, nothing serious.

>EXO=1, VER1 -> VER1 in return, or (as in Appendix A) VER1 -> VER0 etc...

I agree with all this about specifying what the receiver must do. My 
only concern was to choose a word that doesn't confuse people, rather 
than redefining the meaning of a word like 'version' that actually 
has different semantics in normal usage.

The term 'version' normally has the semantics than a lower version 
implementation cannot understand a higher version protocol. If you 
want to stray from that, I suggest you find a different word.

>treat the TSval as completely opaque entity (no PAWS allowed):

I didn't mean you to have to waste a bit now saying whether MASK is valid.

My comments were in the context of objecting to the text added in the 
-02 PDF draft: "MASK: ... This field MUST be present in all future 
version of timestamp capability fields."

All you need to do now is *not* say this sentence.

Then, if someone doesn't want MASK to be valid in a future version, 
they just need to say in the spec of v3 (say) that the bits where 
MASK was in v0 have a different usage.

Yes, but we need to work out a way to future-proof a look-up table of 
"common" rates. It is hard to imagine picosecond or femtosecond 
resolution now, but it will happen. We need something like an 
exponent (scaling factor), where we can define a list of common 
numbers, but put a scaling factor in the capability negotiation, so 
that each "common" value can be multiplied by the same scaling factor.

[Also, 24 bits seems an excessively large range of choice.]

>to allow a multibit version/type field.

Indeed

Cheers

Bob

>    Richard

________________________________________________________________
Bob Briscoe,                                BT Innovate & Design

---

From: "Scheffenegger, Richard" <[email-masked]>
Date: Tue, 31 May 2011 19:32:14 +0100

Hi Bob,

Just to focus on the MASK discussion (I'll address the other comments
later).

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

After thinking about this question some more, I believe it really boils
down to the question, should the protocol provision for senders to add
some entropy to TSval or not. That entropy could be used in various
ways, as described in the Use Cases of the draft. MASK cannot be
removed, if the sender maintains monotonicity, but adds entropy
nevertheless...

I have argued that it makes sense to allow a sender to add entropy. Even
if that entropy could ensure that the full 32-bit values remain
monotonic increasing, a receiver would still have to know where the
clock-based timestamp value ends, and entropy starts. In fact, these two
(monotonicity and time value) may not necessarily coincide - but keeping
this identical saves another field.

The receiver may want to do a couple things:

PAWS processing (simple monotonic increase of TSval is sufficient)
Time processing (needs to know where the last significant bit of that
timestamp is in TSVal); time values, by definition, are monotonic
increasing at the sender side.
Entropy processing [short of introducing another word] - perhaps
interesting in a future variant (to replace "version" in the field
definition).

There are alternative ways, how the TSval may be set by the sender. Each
of these MUST be processed correctly by a variant 0 receiver, IMHO.

a) entire TSval is monotonic increasing, but has no direct relation to
wall-clock time 

This is what a receiver currently has to assume; PAWS processing using
the full TSval is possible. Here, MASK is set to 0, and DUR also set 0
(draft-02 defined DURation as the value of EXP/FRAC together).

b) entire TSval is monotonic increasing, and has a direct relation to
wall-clock time

This is how TSval should be used, but currently a receiver has no way of
knowing exactly what clock tick interval is used by the sender. Here
MASK would be 0, while DUR the duration of a timestamp clock tick
(probably static at compile time).

c) a part of TSVal is monotonic increasing (with or without relationship
to wall-clock time, the timestamp value boundary coinciding with the
monotonic part or not)

A receiver should at least be capable of using the monotonic increasing
part in PAWS processing, even if it does not know how to process the
TSval for other purposes. This was the reason of stipulating that MASK
is always present. A future variant may use a monotonic increasing TSval
for not-time related purposes, but a receiver could still make use of
the monotonic part. MASK would be set to some non-zero value smaller
than 31. 

d) the sender does not want the receiver to do any processing of TSval
for any heuristics (PAWS or otherwise), because no part of TSval
satisfies the monotonicity restriction imposed by PAWS.

This would be the case with MASK set to 31 meaning a complete masking of
TSval. With MASK=31, a variant 0 receiver would disable even PAWS
processing. Obviously, this setting wouldn't really make sense between
two variant0 hosts, because it would remove standard RFC1323 features
entirely. However, this would allow (experimental) deployment of future
variants, where two hosts understanding that variant could make sense of
the TSval again. A variant 1..3 sender may also have to have the
capability to dynamically switch to a legacy mode (with only traditional
use of TSval) if it receives a variant0 answer. Nevertheless, such a
sender may still want to add entropy in that legacy mode (case c above).

If a sender adds some entropy (hash etc), the implementation for the
receiver doesn't change. Receiver side implementation with a fixed MASK
field, which has to be maintained with any future variant, would be easy
(no hash/crypto processing is necessary). Only a fixed number has to be
kept (0-32) at the receiver by which a TSval is right-shifted, before
PAWS processing is done (right shifting by 32 is the same as disabling
PAWS, of course). 

A future variant may have the sender indicate, what is contained in that
masked-out bits, if it becomes interesting to the receiver to process
this (such as a payload CRC). Also, if such processing is done at the
receiver end, the semantics of the data stream TSval may change (e.g.
TCecr may not be a 1:1 reflection of TSval at all...). But this is of no
concern for a variant0 implementation, really...

Using less than 5 bits would be possible though, but require the
agreement on common numbers of masked bits, and some kind of lookup in
the tcp stacks (possibly wasting a few bits during the session, or not
having enough for some purposes, when only certain mask values are
supported (i.e. a 3-bit field, encoding 0, 2, 4, 8, 12, 16, 24, 32 was
discussed early on between Mirja and me, before we decided to go for
single-bit resolution). As mentioned above, full masking would probably
not make sense, so the mask distribution could be adjusted...

The reason for having MASK in the common part is that a variant0
receiver which sees a variant != 0 negotiated, would have to fall back
to RFC1323 processing, even though it may be preferable for a variant1,
2 or 3 sender, to have at least the semantics of variant0 (e.g. direct
reflection instead of RFC1323 receiver side reflection). Alternatively,
a variant 1..3 sender would have to use a unsecured TSval, that is
monotonic increasing, if a variant0 is at the other end; nearly the same
as a complete fall-back to RFC1323 on the receiver side, though.

Thus if MASK is removed from the common fields, the specs must be very
clear about the expected receiver behavior, and TSval semantics when a
var1..3 talks to a var0 receiver.

Best regards,

Richard Scheffenegger

> -----Original Message-----
> Sent: Dienstag, 31. Mai 2011 17:39
> To: Scheffenegger, Richard
> Cc: [email-masked]; draft-scheffenegger-tcpm-timestamp-
> [email-masked]
> Subject: Re: [tcpm] Tech points: draft-scheffenegger-tcpm-timestamp-
> negotiation-01
> 
> Richard,
> 
> >result). Thus a MASK=31 could be interpreted as all bits are opaque
to
> a
> > > > >    0                   1                   2
> 3
> > > >sender (SYN, no ACK) only, and responded to with certain
semantics
> -
> > > >simplifying one-way delay variance calculations (so that
wirespeed
> @
> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm

---

From: "Scheffenegger, Richard" <[email-masked]>
Date: Tue, 31 May 2011 19:32:46 +0100

Hi Bob,

> see it (you see through it).

Understood :) I'll adjust the wording to avoid these two terms.

> And anyway, I don't think a CRC needs the semantics of echoing.

The TSval handling semantics could be adjusted with such a future
variant as well... Timestamps are well known, and not messed up by
middleboxes as much as a new TCP option possibly - at least not by those
middleboxes that allow TS negotiation that is. All I wanted to express
is, that a future variant may want to completely overrule current TSval
processing by disabling even PAWS processing. But it's probably just as
easy to make sure that such a sender is compatible with a variant0
receiver.

> something exceptional, so implementers have to catch it before a

Already in the draft (signaling, EXP field). However, if the fields
align too straight with a regular IEEE, an implementer may stop reading
short of these details :)

> rather than making implementers have to do complex coding.

Is this an support towards the "implicit precision" suggestion I posted
to the list the other day?

Making a integer from a IEEE-754 requires special processing:

If (exp > 0) 
  Frac = frac | 0x800;
Integer64 = frac << exp;

The implicit precision scheme can be implemented as

Integer64 = frac << exp;

Directly. Integer would then represent the tick duration at in units of
maximum resolution (3 ps). 
Processing would only become more complex, when the host does care about
the confidence the partner host has in its clock source.

> want to stray from that, I suggest you find a different word.

As a native speaker, would you recommend "TYPE" (as in message type), or
identifier, or variant? Or some other term not yet mentioned?

> >sends timestamp capability with the locally supported rates
> >(appropriate bits set), and the receiver picks the one it can 
> >also support (or none) in the 2nd packet...
> 

I believe the DURation as defined in the draft gives the best
granularity over a reasonable large range (10s-10ps). Femtoseconds will
definitely require a roll in the variant number :), or the use of some
reserved variant0 bits.

The negotiation sketch in Appendix A would appear to be more flexible
than any bit-mapped lookup table negotiation (ie. Sender supports the
rates 10001b, while the receiver only 00100b; what rate will the sender
then choose?). The "implicit precision" stuff could be applied to a
range negotiation as well, btw.

Best regards,
   Richard