Subject: [tcpm] New Version Notification for draft-scheffenegger-tcpm-timestamp-negotiation-02.txt

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

http://www.ietf.org/id/draft-scheffenegger-tcpm-timestamp-negotiation-02.txt

A new version of I-D, draft-scheffenegger-tcpm-timestamp-negotiation-02.txt has been successfully submitted by Richard Scheffenegger and posted to the IETF repository.

Filename:	 draft-scheffenegger-tcpm-timestamp-negotiation
Revision:	 02
Title:		 Additional negotiation in the TCP Timestamp Option field during the TCP handshake
Creation date:	 2011-05-28
WG ID:		 Individual Submission
Number of pages: 31

Abstract:
   A number of TCP enhancements in so diverse fields as congestion
   control, loss recovery or side-band signaling could be improved by
   making the values carried in the Timestamp option transparent, and
   changing the receiver side processing of timestamps in the presence
   of selective acknowledgements.

   This documents specifies a backwards compatible way of negotiating
   for Timestamp capabilities, and lists a number of benefits and
   drawbacks of this approach.

The IETF Secretariat

---

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

Hi,

this is to summarize the open (technical content) issues, as mentioned
in earlier emails:

1)
naming of the "VER"sion field. As a receiver implementing this draft
should always respond with at least a capabilities field where this
field is set to zero (described in the draft), regardless of the version
used by the sender, the appropriate name for this field may semantically
more correct be "TYPE" or message-"ID".

It really describes the content of the lower 3 octets, and is intended
as an enumeration. The semantics how / when to use what value in this
field is explicit in the spec (and again, a value=0)

2) 
5-bits mask field: It may be interesting to prevent a (version 0, see
above) receiver from processing the TSval during the data stream at all,
while bit-granularity of the mask may not be needed for too many
applications. At the same time, concern was raised as all the common
bits are already assigned to fields (even though 3 enumerations of the
"VER" field are available as future expansions.

One suggestion is to have a separate bit to indicate if MASK is valid,
and that (smaller, 4-bit) field it not, the receiver stop any TSval
processing (including PAWS check). This could yield additional (sub-)
codepoints for future extensions of the negotiation.

There are still 8 unused (reserved) bits, specific to version 0;
however, some reserved bits are important as long as misbehaving RFC1323
senders may be operating, to prevent receivers from processing TSval
improperly.

3)
Explicit indication of the confidence / precision the sender has in the
timestamp clock source. One bit (SGN) was removed over draft -01, as
negative time durations make little sense. In -02, this bit is used to
increase the indicated precision (and to deviate more from IEEE754
binary16 format, to avoid wrong implementations simply mapping the wire
protocol fields into a binary16 float).
However, such a high precision is often not necessary, while indicating
a confidence with the clock source could enable additional heuristics to
be enabled/disabled based on the time source precision.

Also, without an implicit lead bit, conversion of the float
representation to integer is slightly streamlined (no special processing
for subnormal numbers).

4)
Two possible extensions of this protocol received a little thought so
far: 
 a) range negotiation (to simplify OWD calculations to pure
addition/subtraction operations)
 b) complete masking of the timestamp for timing purposes and using it
to carry a data payload CRC

These extensions are obviously incompatible, and would need new
version/type values (but they can signal a version 0 receiver how it
should behave on receipt of such a capabilities field).

Shall these options discussed in any more detail than they are already?
Or completely removed from the draft?

Best regards,

Richard Scheffenegger

> -----Original Message-----
> From: Scheffenegger, Richard
> Sent: Samstag, 28. Mai 2011 14:21
> To: [email-masked]
> Subject: [tcpm] New Version Notification fordraft-scheffenegger-tcpm-
> timestamp-negotiation-02.txt
> 
> 
> A new version of I-D, draft-scheffenegger-tcpm-timestamp-negotiation-
> 02.txt has been successfully submitted by Richard Scheffenegger and
> posted to the IETF repository.
> 
> Title:		 Additional negotiation in the TCP Timestamp
Option
> field during the TCP handshake
> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm

---

From: Joe Touch <[email-masked]>
Date: Tue, 31 May 2011 10:00:48 -0700

> field is explicit in the spec (and again, a value=0)

That's still basically a version field. It describes not just the 
interpretation of the rest of the field, but also the overall protocol 
used (as per the draft).

However, other than "version 0", there are no useful versions of this, 
AFAICT - see below.

> senders may be operating, to prevent receivers from processing TSval

For reserved fields, you need to specify:

	- whether a VERS=0 sender MUST set them
	- whether a VERS=0 receiver MUST check them
	on receipt or ignore them

"MUST be zero" is ambiguous - it could refer to the sender's actions or 
the receiver's.

I don't like the rest of the description, which may impact the overall 
utility of this option:

            If timestamp capabilities are received with version set
            to 0, but some of these bits set, the receiver MUST ignore
            the extended options field and react as if the TSecr was zero
            (compatibility mode).

There is no requirement that TCP use actual time in timestamps.
Other than "all zeroes" (as spec'd in RFC1323), there are no special 
values for timestamps.

So I'm a bit concerned about the idea of interpreting whether this 
option is in effect simply by the use of unexpected timestamp values.

Joe

---

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

Hello Joe,

thank you for your comment.

> interpretation of the rest of the field, but also the overall protocol

Exactly; if a sender initiates a session with VER=1, but receives a
VER=0 in the <SYN,ACK>, the sender should operate in a mode, that is
compatible with how a VER=0 receiver processes the TSval (and echoes it
in TSecr).

> However, other than "version 0", there are no useful versions of this,

Well, the range negotiation stuff would be one instance, where a
different VER would become necessary (because the field definition
changes). Again, from the current point of view, providing 3 additional
codepoints for future expansion seems enough to warrant the bit-granular
MASK field.

> "MUST be zero" is ambiguous - it could refer to the sender's actions
or

Thank you; in fact, these bits MUST be set by the sender.

> option is in effect simply by the use of unexpected timestamp values.

The wording is not clear, thanks for bringing this up. 

If a receiver observes some RES bits set to one (which can only happen
with misbehaving RFC1323 senders not clearing TSecr in <SYN>), it should
simply reflect the received TSval from the <SYN> in TSecr in <SYN,ACK>.
That is, behave like a standard RFC1323 host. During the session,
timestamp processing would follow regular RFC1323 rules.

If the receiver determines that a sender compliant to this draft is
negotiating, the <SYN,ACK> TSecr is set to (<SYN> TSval) XOR (receiver
TS capabilities).

The idea behind the XOR is, that a sender can discriminate between
different <SYN> retransmissions:

<SYN> TSval = 0x010000, TSecr=capability negotiation
 (lost)
<SYN> TSval = 0x020000, TSecr=capability negotiation
 (delayed)
<SYN> TSval = 0x030000, TSecr=capability negotiation
<SYN,ACK> TSval = <xxx>, TSecr=0x200000 XOR capability negotiation.

If the sender modifies the TS offset in that 3rd octet, but keeps only
state for the initial TSval, it can determine which <SYN> made it to the
receiver by checking only a few bits (instead of keeping track of all
the sent SYN TSvals). But sampling RTT on SYN is discouraged, so I
didn't mention this aspect in the draft.

Thanks,

  RIchard

---

From: Joe Touch <[email-masked]>
Date: Tue, 31 May 2011 16:48:34 -0700

Hi, Richard,

On 5/31/2011 11:56 AM, Scheffenegger, Richard wrote:
...
> with misbehaving RFC1323 senders not clearing TSecr in<SYN>),  it should
> simply reflect the received TSval from the<SYN>  in TSecr in<SYN,ACK>.

OK - that's more clear.

> negotiating, the<SYN,ACK>  TSecr is set to (<SYN>  TSval) XOR (receiver
> TS capabilities).

How do you know whether it's a sender compliant to the draft 
negotiating, vs. a noncompliant RFC1323 host?

> different<SYN>  retransmissions:
>
> <SYN,ACK>  TSval =<xxx>, TSecr=0x200000 XOR capability negotiation.
>
> state for the initial TSval, it can determine which<SYN>  made it to the

If the only example you have for using these bits is something you 
discourage, perhaps it's worth omitting it. ;-)

Joe