Subject: [tcpm] I-D Action: draft-ietf-tcpm-1323bis-16.txt

From: [email-masked]
Date: Tue, 12 Nov 2013 11:07:28 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the TCP Maintenance and Minor Extensions Working Group of the IETF.

	Title           : TCP Extensions for High Performance
	Author(s)       : David Borman
                          Bob Braden
                          Van Jacobson
                          Richard Scheffenegger
	Filename        : draft-ietf-tcpm-1323bis-16.txt
	Pages           : 49
	Date            : 2013-11-12

Abstract:
   This document specifies a set of TCP extensions to improve
   performance over paths with a large bandwidth * delay product and to
   provide reliable operation over very high-speed paths.  It defines
   TCP options for scaled windows and timestamps.  The timestamps can be
   used for two distinct mechanisms, PAWS (Protection Against Wrapped
   Sequences) and RTTM (Round Trip Time Measurement).

   This document obsoletes RFC 1323 and describes changes from it.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-tcpm-1323bis

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-tcpm-1323bis-16

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-1323bis-16

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: "Scheffenegger, Richard" <[email-masked]>
Date: Tue, 12 Nov 2013 19:43:58 +0000

Hi group,

As mentioned, I have incorporated all the changes from the latest review of this draft, except where noted (in the earlier email).

In addition, I fixed all occurances of "monotonically increasing" to "monotonically non-decreasing" (never decreases, but may stay the same) in case someone mistakenly reads the first reference identical to "strictly monotonically increasing" (ie. always has to increase).

And I added a privacy section as a subsection of security. Fernando, could you please check if the paragraphs there align with your understanding of these issues?

As some paragraphs have shuffled to new places, you may want to review the full document rather than the diffs, to learn how the text reads in full context.

But even reviews of just the diff are fine.

As a remainder, with the following feedback I was not sure how to address the, and WG discussion might be helpful:

------------

>   - Sec 1: In the last paragraph before 1.1:
> 
>     - should "recommended" be "RECOMMENDED"?  (I am not sure)

This text is before the definition of RFC2119 style wording; I tend to keep this lower case...

>   - Sec 1.2, point (1): This is not entirely correct.  You need both a
>     high transfer rate *and a whole bunch of data* to have a sequence
>     wrapping issue.  This point could be a lot better by noting that it
>     takes 4GB of data to wrap.

Sentence now reads: At a high enough transfer rate of large volume of data (at least 4 GiB in the same session), the 32-bit sequence space may be wrapped within the time that a sement is delayed in queues.

Do you think this is good enough?

>   - Sec 2.3: The list at the beginning of the section should be
>     converted to standards language (MUST, SHOULD, etc.).

Added mostly MUSTs (only one SHOULD on the receiver, which may choose to limit the window for memory constrains etc).

>     Sec 3.2: This whole discussion of valid and invalid TSecr is
>     confusing.  You note that when the value is invalid it should be set
>     to zero.  But, a TSecr of zero does not mean the TS is invalid.  So,
>     how should we tell?

This was my attempt at "liberal at what you accept, and conservative in what you send". There are implementations that assume TSecr=0 == invalid, with not strictly defined behavior in that case (e.g. drop that segment and stall until the sender timestamp increases to 1, or end up with strange RTO values...). When TSval is more or less the uptime of the sender, this roll-over hardly matters [which is probably the reason this was not fixed a long time ago in the affected stack], but when TSval is randomized, this corner case is more likely to occur and the implementer should properly treat this case. 

If anyone can think of better wording to express this, please donate text.

------------

Richard Scheffenegger

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> [email-masked]
> Sent: Dienstag, 12. November 2013 20:07
> To: [email-masked]
> Cc: [email-masked]
> Subject: [tcpm] I-D Action: draft-ietf-tcpm-1323bis-16.txt
> 
> 
> Please note that it may take a couple of minutes from the time of
> submission until the htmlized version and diff are available at
> tools.ietf.org.
> 
> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm

---

From: Pasi Sarolahti <[email-masked]>
Date: Thu, 14 Nov 2013 17:14:22 +0200

> As mentioned, I have incorporated all the changes from the latest review of this draft, except where noted (in the earlier email).

Thanks! Let's wait for a couple of days if there are any additional remarks, and then start a WGLC unless something major shows up.

> This text is before the definition of RFC2119 style wording; I tend to keep this lower case...

The important thing is not whether it comes before or after the definition, but that "RECOMMENDED" has a specific meaning (synonym of SHOULD). I agree with you to keep it lower case here (and might even prefer less strong language about recommending an optional mechanism). Generally, I feel that introduction is a bit too early place start rolling out normative protocol requirements, and the typical location of RFC 2119 reference boilerplate speaks for that, too.

> Do you think this is good enough?

Works for me.

> Added mostly MUSTs (only one SHOULD on the receiver, which may choose to limit the window for memory constrains etc).

Ok, but I would leave the first bullet about augmenting connection state in its previous state. It is a local implementation detail, and doesn't need MUST.

> This was my attempt at "liberal at what you accept, and conservative in what you send". There are implementations that assume TSecr=0 == invalid, with not strictly defined behavior in that case (e.…

Hmm... I can see the point of Mark's comment.

How about:

The Timestamp Echo Reply field (TSecr) is valid if the ACK bit is set in the TCP header; if ACK bit is set in the TCP header, the sender of TSecr field MUST echo a recently received timestamp sent by the remote TCP in the TSval field of a Timestamps option (the exact rules on which timestamp to echo will be given in Sec. 4.3). If ACK bit is not set in the outgoing TCP header, the sender MUST (or SHOULD?) set TSecr field to 0. When ACK bit is set, the receiver should process the incoming TSecr value as valid (including value 0). When ACK bit is not set, the receiver MUST ignore the value of TSecr field.

Is this correct?

(I don't see the need for MUST set TSecr to 0 above, because the field should be ignored anyway in the absence of ACK. Generally I'm not fond of excess use of MUST when not necessary)

- Pasi

---

From: "Scheffenegger, Richard" <[email-masked]>
Date: Thu, 14 Nov 2013 15:36:17 +0000

Hi Pasi,

> > Added mostly MUSTs (only one SHOULD on the receiver, which may choose to
> limit the window for memory constrains etc).
> 
> Ok, but I would leave the first bullet about augmenting connection state
> in its previous state. It is a local implementation detail, and doesn't
> need MUST.

Will check this...

> > This was my attempt at "liberal at what you accept, and conservative in
> what you send". There are implementations that assume TSecr=0 == invalid,
> with not strictly defined behavior in that case (e.g. drop that segment
> and stall until the sender timestamp increases to 1, or end up with
> strange RTO values...). When TSval is more or less the uptime of the
> sender, this roll-over hardly matters [which is probably the reason this
> was not fixed a long time ago in the affected stack], but when TSval is
> randomized, this corner case is more likely to occur and the implementer
> should properly treat this case.
> 
> The Timestamp Echo Reply field (TSecr) is valid if the ACK bit is set in
> the TCP header; if ACK bit is set in the TCP header, the sender of TSecr
> field MUST echo a recently received timestamp sent by the remote TCP in
> the TSval field of a Timestamps option (the exact rules on which timestamp
> to echo will be given in Sec. 4.3). If ACK bit is not set in the outgoing
> TCP header, the sender MUST (or SHOULD?) set TSecr field to 0. When ACK
> bit is set, the receiver should process the incoming TSecr value as valid
> (including value 0). When ACK bit is not set, the receiver MUST ignore the
> value of TSecr field.
> 
> Is this correct?

The reference here was that certain implementations also set TSecr to 0 in the SYN,ACK  or the first ACK, when they internally do something akin to SYNCaching and don't keep the original TS in that state... I believe Windows 95 / 98 behaved that way.

I think your last sentence should read "the sender should process" :)

Still a value of 0 has ambiguity currently (1323), as it may be a valid value, or indicating that the receiver could not reflect a valid value for some reason...

Your text suggestion will tie this up a bit, and is more strict to the receiver to not evict valid TS data :)

Best regards,

Richard Scheffenegger

> From: Pasi Sarolahti [mailto:[email-masked]]
> Sent: Donnerstag, 14. November 2013 16:14
> To: Scheffenegger, Richard
> Cc: [email-masked]; [email-masked]; Fernando Gont
> Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-1323bis-16.txt
> 
> > As mentioned, I have incorporated all the changes from the latest review
> of this draft, except where noted (in the earlier email).
> 
> Thanks! Let's wait for a couple of days if there are any additional
> remarks, and then start a WGLC unless something major shows up.
> 
> The important thing is not whether it comes before or after the
> definition, but that "RECOMMENDED" has a specific meaning (synonym of
> SHOULD). I agree with you to keep it lower case here (and might even
> prefer less strong language about recommending an optional mechanism).
> Generally, I feel that introduction is a bit too early place start rolling
> out normative protocol requirements, and the typical location of RFC 2119
> reference boilerplate speaks for that, too.
> 
> > Sentence now reads: At a high enough transfer rate of large volume of
> data (at least 4 GiB in the same session), the 32-bit sequence space may
> be wrapped within the time that a sement is delayed in queues.
> >
> > Added mostly MUSTs (only one SHOULD on the receiver, which may choose to
> limit the window for memory constrains etc).
> 
> Ok, but I would leave the first bullet about augmenting connection state
> in its previous state. It is a local implementation detail, and doesn't
> need MUST.
> 
> > This was my attempt at "liberal at what you accept, and conservative in
> what you send". There are implementations that assume TSecr=0 == invalid,
> with not strictly defined behavior in that case (e.g. drop that segment
> and stall until the sender timestamp increases to 1, or end up with
> strange RTO values...). When TSval is more or less the uptime of the
> sender, this roll-over hardly matters [which is probably the reason this
> was not fixed a long time ago in the affected stack], but when TSval is
> randomized, this corner case is more likely to occur and the implementer
> should properly treat this case.
> 
> The Timestamp Echo Reply field (TSecr) is valid if the ACK bit is set in
> the TCP header; if ACK bit is set in the TCP header, the sender of TSecr
> field MUST echo a recently received timestamp sent by the remote TCP in
> the TSval field of a Timestamps option (the exact rules on which timestamp
> to echo will be given in Sec. 4.3). If ACK bit is not set in the outgoing
> TCP header, the sender MUST (or SHOULD?) set TSecr field to 0. When ACK
> bit is set, the receiver should process the incoming TSecr value as valid
> (including value 0). When ACK bit is not set, the receiver MUST ignore the
> value of TSecr field.
> 
> Is this correct?
> 
> (I don't see the need for MUST set TSecr to 0 above, because the field
> should be ignored anyway in the absence of ACK. Generally I'm not fond of
> excess use of MUST when not necessary)
> 
> - Pasi

---

From: "Scheffenegger, Richard" <[email-masked]>
Date: Thu, 14 Nov 2013 23:54:22 +0000

Hi Pasi,

> (including value 0). When ACK bit is not set, the receiver MUST ignore the

I rephrased this now to 

      The Timestamps Echo Reply (TSecr) field is valid if the ACK bit 
      is set in the TCP header. If the ACK bit is not set in the 
      outgoing TCP header, the sender of that segment SHOULD set the 
      TSecr field to zero.  When the ACK bit is set in an outgoing 
      segment, the sender MUST echo a recently received timestamp sent 
      by the remote TCP in the TSval field of a Timestamps option. The 
      exact rules on which TSval MUST be echoed are given in  <xref 
      target="sec34"/>. When the ACK bit is not set, the receiver MUST 
      ignore the value of the TSecr field.

(Which renders stacks that don't keep TS state during SYN-Caching not compliant... ).

Comments?

Richard Scheffenegger