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

From: [email-masked]
Date: Thu, 21 Mar 2013 15:08:54 -0700

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-07.txt
	Pages           : 42
	Date            : 2013-03-21

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 are
   used for two distinct mechanisms, RTTM (Round Trip Time Measurement)
   and PAWS (Protection Against Wrapped Sequences).

   This document updates and obsoletes RFC 1323.

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

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

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

---

From: "Scheffenegger, Richard" <[email-masked]>
Date: Thu, 21 Mar 2013 22:15:02 +0000

Group,

After the valuable feedback today regarding the sections of text, and updating the document with a minor number of other editorial changes such as swapping Packets for segments, and adding < > brackts to signify specific types of segments in the text, and doing minor layout work - after a final update of the changes section - here is the promised -07 version of the draft.

Please review those sections you think are critical, and please also scan over the other parts of the documents for missed nits.

Probably not everyone will be happy, but I think this document reflects the concensus of the WG so far.

Feedback is still very welcome, but if no one objects, I call on the chairs to formally start a WGLC in a couple days time on this document!

Best regards,
  Richard

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Donnerstag, 21. März 2013 23:09
To: [email-masked]
Cc: [email-masked]
Subject: [tcpm] I-D Action: draft-ietf-tcpm-1323bis-07.txt

Abstract:

_______________________________________________
tcpm mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tcpm

---

From: Joe Touch <[email-masked]>
Date: Thu, 21 Mar 2013 16:47:10 -0700

Hi, Richard,

I'm a bit concerned about the text here; I know I raised the issue 
before, but I want to be specific about the concern:

    A TCP MAY send the Timestamps option (TSopt) in an initial <SYN>
    segment.  When used, the Timestamp option SHOULD be negotiated during
    the initial <SYN> and <SYN,ACK> unless another mechanism allows to
    enable it during an established session.  However, such a mechanism
    is outside the scope of this document.

First, I don't like SHOULD unless there is a specific example of an 
exception. The exception noted is vague and defined as out of scope of 
this doc, so IMO this should be "MUST" *until* overridden by some 
potential future document that has WG consensus. I don't think it's 
appropriate to have consensus on "some future but unspecified mechanism" 
in this way.

*** (note the stars, I'll refer to them later)

However, the rest of the paragraph is confusing:

                                            When TSopt has been sent or
    received in a non-<SYN> segment, it MUST be sent in all segments.

Does the above refer to:

a) mid-stream enabling when TS was not negotiated during the SYN?

b) the idea that TS is negotiated during a SYN and yet the endpoints can 
decide to hold-off using it, but at some point "turn it on"?

Either way, there's a lot of detail here that's missing. Do you mean:

	When TSopt has been sent or received in a non-<SYN> segment
	with a sequence number X, it must be sent on all subsequent
	segments from X forward including retransmissions that overlap
	with X or higher.

Is that what you mean? or does this refer to ANY segments once the first 
one with TSopt?

    Once a TSopt has been received in a non-<SYN> segment, then any
    successive segment that is received without the RST bit and without a
    TSopt MAY be dropped without further processing, and an <ACK> of the
    current SND.UNA generated.

The above paragraph appears to need the same treatment, referring to 
specific sequence numbers.

However, I would much prefer a cleaner:

    A TCP MAY send the Timestamps option (TSopt) in an initial <SYN>
    segment.  When used, the Timestamp option MUST be negotiated during
    the initial <SYN> and <SYN,ACK>. The potential for mid-stream
    enabling of this option was discussed, but no current mechanism
    is yet specified.   Once a TSopt has been received in a non-<SYN>
    segment of a connection that has TS enabled, all subsequent segments
    MUST include TSopt. Any
    successive segment that is received without the RST bit and without a
    TSopt MAY be dropped without further processing, and an <ACK> of the
    current SND.UNA generated. Any successive segment received with the
    RST bit can ignore the absence of TSopt; this allows an connection
    that does not support TSopt to cleanup TCP state associated with a
    previous TSopt-enabled connection.

Joe

---

From: Tim Shepard <[email-masked]>
Date: Thu, 21 Mar 2013 21:43:10 -0400

> Please review those sections you think are critical, and please also scan over the other parts of the documents for missed nits.

OK, I took a look at the paragraph mentioning mid-stream negotiation
of the timestamp option:

   is outside the scope of this document.  When TSopt has been sent or

You say it is outside scope of this document, but then the rest of the
paragraph talks about receipt of the TSopt on a non-SYN segment being
what determines whether you've got it on or off.   That is a change
from rfc1323 which says simply:

         A TCP may send the Timestamps option (TSopt) in an initial
         <SYN> segment (i.e., segment containing a SYN bit and no ACK
         bit), and may send a TSopt in other segments only if it re-
         ceived a TSopt in the initial <SYN> segment for the connection.

It seems to me that there may indeed something approaching WG
consensus that it sure would be nice if timestamps could be negotiated
on sometime later even if they weren't negotiated on in the initial
exchange of SYN bits.

But I think we are no where near having something written down that
explains how this might be accomplished safely and effectively.  Mark
Allman's recent e-mail exchanges with Joe makes me think that maybe it
would be possible.  But I'd like to see a draft that explains it in
full detail.

But even so, if you're going to potentially need time stamps on for
PAWS today, next year, or 5 years from now, or 10 years from now, you
are going to have to include the timestamp option in the SYN otherwise
the other end of the TCP connection will not allow the timestamp
option to be turned on mid stream.

Does that matter?  Seems to me it would, and there are a number of
things to think about.

Unless you can somehow know out-of-band before you send the SYN to
initiate the connection that the other end happens to be a host which
can turn on the timestamp option midstream, you have to include it
with the SYN to get it turned on reliably.  And with 1 Gbps symmetric
internet connections to the home becoming routine in some communities
(e.g. Chattanooga, Lafayette, Kansas City) enabling things like
routine overnight cross-town copying (of a 3 TB disk) it seems to me
that getting TCP timestamps turned on reliably for PAWS protection
sorta matters these days.

And it's not just protection from old packets from a TCP connection
that has itself wrapped the sequence space, but also protection from
packets from previous TCP connections that used the same port
numbers and sent bytes at a rate faster than the initial sequence
number clock ticked.  (There is no mechanism in the net that
provides any sort of MSL-like guarantee.  And with the proliferation
of dodgy cheap devices with network interfaces capable of 1 Gbps
that can have cables plugged into them that can be tripped over, the
range of crazy undead packet possibilities are only going to get
more and more interesting.)

I think mechanisms for turning on TCP timestamp option after it was
not turned on in the SYN packets belongs (for now) in a seperate
draft targeted at experimental status (at best).

			-Tim Shepard
			 [email-masked]

---

From: Joe Touch <[email-masked]>
Date: Thu, 21 Mar 2013 20:53:27 -0700

FWIW...

On 3/21/2013 6:43 PM, Tim Shepard wrote:
(the original 1323 text:)
>           ceived a TSopt in the initial <SYN> segment for the connection.

I like this one even better because it is more clear about:

	a) the use of TSopt is optional
	b) TSopt must be enabled in the SYN
	c) TSopt, once enabled, may (or may not) be in a given segment

There's no rule about how to respond if an endpoint simply decides not 
to use it on a given segment, which makes more sense to me.

Joe

---

From: "Scheffenegger, Richard" <[email-masked]>
Date: Sun, 24 Mar 2013 11:34:02 +0000

I restored the original text of draft -00:

   A TCP MAY send the Timestamp option (TSopt) in an initial <SYN>
   segment (i.e., segment containing a SYN bit and no ACK bit), and MAY
   send a TSopt in other segments only if it received a TSopt in the
   initial <SYN> or <SYN,ACK> segment for the connection.  When TSopt
   has been sent or received in a non-<SYN> segment, it MUST be sent in
   all segments.  Once a TSopt has been received in a non-<SYN> segment,
   then any successive segment that is received without the RST bit and
   without a TSopt MAY be dropped without further processing, and an
   <ACK> of the current SND.UNA generated.

Keeping the additional text to stipulate exactly, that TSopt MUST NOT be removed later in the session, and also the text specific to <RST>, as that is one area of major technical change to RFC1323. 

Richard Scheffenegger

> From: Joe Touch [mailto:[email-masked]]
> Sent: Freitag, 22. März 2013 04:53
> To: Tim Shepard
> Cc: Scheffenegger, Richard; tcpm ([email-masked])
> Subject: Re: [tcpm] FW: I-D Action: draft-ietf-tcpm-1323bis-07.txt
> 
> FWIW...
> 
> There's no rule about how to respond if an endpoint simply decides not to
> use it on a given segment, which makes more sense to me.
> 
> Joe

---

From: Joe Touch <[email-masked]>
Date: Mon, 25 Mar 2013 10:10:38 -0700

Hi, Richard,

On 3/24/2013 4:34 AM, Scheffenegger, Richard wrote:
> Keeping the additional text to stipulate exactly, that TSopt MUST
> NOTbe removed later in the session, and also the text specific to <RST>, as
> that is one area of major technical change to RFC1323.

I don't recall the rationale for either change; can you explain in the doc?

Joe

---

From: "Scheffenegger, Richard" <[email-masked]>
Date: Mon, 25 Mar 2013 17:31:15 +0000

Hi Joe,

at the end of 4.2, there is this paragraph; doesn't that contain the rationale? (Albeit, the "most recently" is ~2007 or so...)

   [RFC1323] recommended that <RST> segments NOT carry timestamps, and
   that they be acceptable regardless of their timestamp.  At that time,
   the thinking was that old duplicate <RST> segments should be
   exceedingly unlikely, and their cleanup function should take
   precedence over timestamps.  More recently, discussions about various
   blind attacks on TCP connections have raised the suggestion that if
   the timestamp option is present, SEG.TSecr could be used to provide
   stricter acceptance tests for <RST> segments.  While still under
   discussion, to enable research into this area it is now RECOMMENDED
   that when generating a <RST>, that if the segment causing the <RST>
   to be generated contained a timestamp option, that the <RST> also
   contain a timestamp option.  In the <RST> segment, SEG.TSecr SHOULD
   be set to SEG.TSval from the incoming segment and SEG.TSval SHOULD be
   set to zero.  If a <RST> is being generated because of a user abort,
   and Snd.TS.OK is set, then a timestamp option SHOULD be included in
   the <RST>.  When a <RST> segment is received, it MUST NOT be
   subjected to PAWS checks, and information from the timestamp option
   MUST NOT be used to update connection state information.  SEG.TSecr
   MAY be used to provide stricter <RST> acceptance checks.

This was added before my time as editor, though....

Disallowing the state machine from later opting out from sending TSopt (even when the other end stops sending it) sounds like a reasonable approach?

Richard Scheffenegger
> Sent: Montag, 25. März 2013 18:11
> To: Scheffenegger, Richard
> Cc: Tim Shepard; tcpm ([email-masked])
> > NOTbe removed later in the session, and also the text specific to
> > <RST>, as that is one area of major technical change to RFC1323.
>

---

From: Joe Touch <[email-masked]>
Date: Mon, 25 Mar 2013 11:35:14 -0700

Hi, Richard,

There are two separate issues:

1) whether non-RST segments should be required to include TSopt once it 
is negotiated for a connection

and

2) whether RSTs should be required to include TSopt once it is 
negotiated for a connection

I disagree with either one. TSopt is not a security mechanism, so I'm 
not buying arguments based on that at all.

I am more concerned with TCP's stability.

Joe

---

From: David Borman <[email-masked]>
Date: Mon, 25 Mar 2013 19:06:34 +0000

On Mar 25, 2013, at 1:35 PM, Joe Touch <[email-masked]> wrote:

> 1) whether non-RST segments should be required to include TSopt once it is negotiated for a connection

Whether or not you send TSopt on the first non-SYN packet, once you start sending TSopt, you need to keep sending TSopt for the duration of the connection or it messes up both PAWS and making RTT measurements based on TSopt.  If you can't use it for PAWS and you can't trust the RTT measurements, then TSopt is worthless.  Hence, once you start sending/receiving it, you send it for the rest of the connection.

That's the point of the original 1323bis wording that Richard has restored, that text goes back to at least 1996.

			-David Borman

> 
> and
> 
> 2) whether RSTs should be required to include TSopt once it is negotiated for a connection
> 
> I disagree with either one. TSopt is not a security mechanism, so I'm not buying arguments based on that at all.
> 

----------------------------------------------------------------------
The information contained in this transmission may be confidential. Any disclosure, copying, or further distribution of confidential information is not permitted unless such privilege is explicitly granted in writing by Quantum. Quantum reserves the right to have electronic communications, including email and attachments, sent across its networks filtered through anti virus and spam software programs and retain such messages in order to comply with applicable data security and retention requirements. Quantum is not responsible for the proper and complete transmission of the substance of this communication or for any delay in its receipt.

---

From: Joe Touch <[email-masked]>
Date: Mon, 25 Mar 2013 13:10:31 -0700

Hi, David,

I don't disagree, but none of this is in the doc.

IMO, the doc needs to be very clear about how it modifies RFC1323, and 
highlight not only how it differs but also why.

The reason you point out, FWIW, is valid for all segments except RST. 
For RST, there are valid robustness reasons that IMO trump security 
concerns exactly because this is NOT a security mechanism.

So my conclusion would be:

	- include the requirement for non-RST segments, but NOT for RSTs

	- add a paragraph explaining how things changed

	- include in that paragraph both why non-RST segments need TSopt
	and why RSTs should be allowed to omit them.

Joe

---

From: "Scheffenegger, Richard" <[email-masked]>
Date: Tue, 26 Mar 2013 11:39:44 +0000

Hi Joe,

>> Whether or not you send TSopt on the first non-SYN packet, once you
>> start sending TSopt, you need to keep sending TSopt for the duration of
>> the connection 

I believe, the (restored) wording covers that part...

>> or it messes up both PAWS and making RTT measurements based
>> on TSopt.  If you can't use it for PAWS and you can't trust the RTT
>> measurements, then TSopt is worthless.  Hence, once you start
>> sending/receiving it, you send it for the rest of the connection.

Only this more explicit explanation, why a TCP MUST NOT stop sending TSopt once started is missing. But the current text IMHO described that technically. I will try to reword the above statement and add it to 1323bis.

Again, this is NOT a deviation from 1323, just a clarification for implementers.

How about this paragraph following the TSopt text:

   As TSopt is required for the two mechanisms described in sections 3.3
   and 4.2, once established, every segment of a session - with the
   exception of <RST>  (for a detailed discussion see Section 4.2) - is
   REQUIRED to have TSopt sent.  If a TCP stopped sending TSopt at any
   later time, it would interfere with both PAWS and RTTM mechanism,
   that are both based on TSopt.  This update to [RFC1323] makes it
   explicit, that segments missing the TSopt MAY be dropped by either
   end of the session, to alert implementers of the serious
   repercussions of not adhering to the timestamp mechanism.

The detailed text explaining the <RST> is at the end of section 4.2, with the PAWS check.

Do you suggest to move that paragraph forward to the end of section 3.2, where TSopt is defined?

Richard Scheffenegger

> Sent: Montag, 25. März 2013 21:11
> To: David Borman
> > Whether or not you send TSopt on the first non-SYN packet, once you
> start sending TSopt, you need to keep sending TSopt for the duration of
> the connection or it messes up both PAWS and making RTT measurements based
> on TSopt.  If you can't use it for PAWS and you can't trust the RTT
> measurements, then TSopt is worthless.  Hence, once you start
> sending/receiving it, you send it for the rest of the connection.
> >
> > That's the point of the original 1323bis wording that Richard has
> restored, that text goes back to at least 1996.
> >
> > 			-David Borman
> >
> >>
> >> and
> >>
> >>> at the end of 4.2, there is this paragraph; doesn't that contain the
> >>> rationale? (Albeit, the "most recently" is ~2007 or so...)
> >>>
> >>>
> >>> Disallowing the state machine from later opting out from sending TSopt
> (even when the other end stops sending it) sounds like a reasonable
> approach?
> >>>
> >>>
> >>> Richard Scheffenegger
> > The information contained in this transmission may be confidential. Any
> disclosure, copying, or further distribution of confidential information
> is not permitted unless such privilege is explicitly granted in writing by
> Quantum. Quantum reserves the right to have electronic communications,
> including email and attachments, sent across its networks filtered through
> anti virus and spam software programs and retain such messages in order to
> comply with applicable data security and retention requirements. Quantum
> is not responsible for the proper and complete transmission of the
> substance of this communication or for any delay in its receipt.
> >

---

From: Joe Touch <[email-masked]>
Date: Tue, 26 Mar 2013 11:15:39 -0700

Hi, Richard,

On 3/26/2013 4:39 AM, Scheffenegger, Richard wrote:
...
>     repercussions of not adhering to the timestamp mechanism.

If you say that something is REQUIRED, you have to explain what happens 
when it's absent.

So far, you say a segment missing TSopt MAY be dropped "to alert". I 
don't consider a "drop" an "alert".

IMO, this should say:
	- if missing, MAY drop and MAY be logged
	- if missing and not dropped, what happens?

> The detailed text explaining the <RST> is at the end of section 4.2, with the PAWS check.

OK.

> Do you suggest to move that paragraph forward to the end of section 3.2, where TSopt is defined?

I think so; backward references make more sense than opaque forward ones.

I think you also need a paragraph to highlight how this changes what was 
in RFC1323, i.e., "what changed".

Joe

---

From: David Borman <[email-masked]>
Date: Tue, 26 Mar 2013 20:35:27 +0000

> 
> If you say that something is REQUIRED, you have to explain what happens when it's absent.

> 
> So far, you say a segment missing TSopt MAY be dropped "to alert". I don't consider a "drop" an "alert".
> 
> IMO, this should say:

How about something like:
  Once TSopt has been sent or received on a non-SYN packet, TSopt
  MUST be sent in every non-RST packet for the duration of the
  connection.  If a non-RST packet is received without a TSopt, a
  TCP MAY drop the packet and send an ACK.  A TCP MUST NOT abort a
  TCP connection if a non-RST packet is received without a TSopt.

  If a TSopt is received on a connection where TSopt was not
  negotiated in the initial SYN exchange, the TSopt SHOULD
  be ignored and the packet processed normally.

A bit of history: RFC 1072 had ECHO and ECHO-REPLY, and only talks
about sending the ECHO on data packets.  RFC 1185 introduced PAWS,
though not explicitly by that name, and the described algorithm
has the explicit assumption that the ECHO is in every packet.  RFC
1323 has that same explicit assumption in section 4.2, which is
carried forward to 1323.bis.  The coupling of ECHO and ECHO-REPLY
into a single TSopt option was done because both options were
being sent in every packet, and combining them made processing
easier and allowed both TS values to be 32 bit aligned without
inserting additional padding.

Despite the simplistic statement in the TSopt description in 1323:

the assumption was that once enabled, TSopt would be sent in every
packet,as stated in in section 4.2 for PAWS.

> I think you also need a paragraph to highlight how this changes what was in RFC1323, i.e., "what changed".

That's what appendix F is for, a detailed list of technical and
editorial changes from RFC 1323.  This a *replacement* for 1323,
not just an update to it.  It clutters up the document putting
in explanations throughout it on why things changed from 1323.
The main body should just have the current state of things, with
any necessary explanations for someone reading the document for
the first time, having never read 1323.  Just highlighting that
something is a change from 1323 belongs in Appendix F.

			-David Borman

---

From: "Scheffenegger, Richard" <[email-masked]>
Date: Wed, 27 Mar 2013 10:57:51 +0000

Hi David, Joe,

I added the text suggested by David, and updated the mentioned paragraphs to this text:

   A TCP MAY send the Timestamp option (TSopt) in an initial <SYN>
   segment (i.e., segment containing a SYN bit and no ACK bit), and MAY
   send a TSopt in other segments only if it received a TSopt in the
   initial <SYN> or <SYN,ACK> segment for the connection.

   Once TSopt has been sent or received on a non-<SYN> packet, TSopt
   MUST be sent in every non-<RST> packet for the duration of the
   connection.  If a non-<RST> packet is received without a TSopt, a TCP
   MAY drop the packet and send an <ACK>.  A TCP MUST NOT abort a TCP
   connection if a non-<RST> packet is received without a TSopt.

   If a TSopt is received on a connection where TSopt was not negotiated
   in the initial three-way handshake, the TSopt SHOULD be ignored and
   the packet processed normally.

   In the case of crossing <SYN> segments where one <SYN> contains a
   TSopt and the other doesn't, both sides SHOULD put a TSopt in the
   <SYN,ACK> segment.

   TSopt is required for the two mechanisms described in sections 3.3
   and 4.2.  If a TCP stopped sending TSopt at any time during an
   established session, it interferes with both the PAWS and RTTM
   mechanisms.  This update to [RFC1323] describes explicitly the
   previous implicit assumption.

Richard Scheffenegger

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> David Borman
> Sent: Dienstag, 26. März 2013 21:35
> To: Joe Touch
> Cc: tcpm ([email-masked])
> A bit of history: RFC 1072 had ECHO and ECHO-REPLY, and only talks about
> sending the ECHO on data packets.  RFC 1185 introduced PAWS, though not
> explicitly by that name, and the described algorithm has the explicit
> assumption that the ECHO is in every packet.  RFC
> 1323 has that same explicit assumption in section 4.2, which is carried
> forward to 1323.bis.  The coupling of ECHO and ECHO-REPLY into a single
> TSopt option was done because both options were being sent in every
> packet, and combining them made processing easier and allowed both TS
> values to be 32 bit aligned without inserting additional padding.
> 
> That's what appendix F is for, a detailed list of technical and editorial
> changes from RFC 1323.  This a *replacement* for 1323, not just an update
> to it.  It clutters up the document putting in explanations throughout it
> on why things changed from 1323.
> The main body should just have the current state of things, with any
> necessary explanations for someone reading the document for the first
> time, having never read 1323.  Just highlighting that something is a
> change from 1323 belongs in Appendix F.
> 
> 			-David Borman
> >
> > Joe
>

---

From: Tim Shepard <[email-masked]>
Date: Wed, 27 Mar 2013 08:46:41 -0400

>    connection.   [...]

I still find that confusing.  It sounds like it is suggesting to an
implementor that in addition to the normal sort of negotiation of the
TSopt on the SYN and SYN ACK exchange, they need to also watch for
whether a TSopt has been received on the first non-SYN packet.  It
makes it sound like it is OK to negotiate use of TSopt on the first
two packets, but then never send the option again on any of the normal
packets.

Is that really what we want here?

			-Tim Shepard
			 [email-masked]

---

From: "Scheffenegger, Richard" <[email-masked]>
Date: Wed, 27 Mar 2013 13:16:47 +0000

Hi Tim,

Well, I don't know how to improve this wording so that it is still optional for any TCP implementing 1323bis, to not use TS, but use WS...

The two MAYs in the first paragraph seem to accomplish that.

Perhaps the first sentence in the 2nd paragraph should be something like:

Once TSopt has been successfully negotiated in the initial three-way handshake (all of the <SYN>, <SYN,ACK> and first <ACK> contained a TSopt), TSopt MUST be send in every non-<RST> segment for the duration of the connection.

?

However, that wording might cause an implementer to use much more state that currently to track this.

Note that TSopt may be successfully delivered on the forward path, but some middlebox might be stripping it from the return path. So the receiver should really only start sending TSopt after the 3WHS <ACK> was received with TSopt. 

Richard Scheffenegger

> From: Tim Shepard [mailto:[email-masked]] On Behalf Of Tim Shepard
> Sent: Mittwoch, 27. März 2013 13:47
> Cc: David Borman; Joe Touch; tcpm ([email-masked])
> TSopt on the SYN and SYN ACK exchange, they need to also watch for whether
> a TSopt has been received on the first non-SYN packet.  It makes it sound
> like it is OK to negotiate use of TSopt on the first two packets, but then
> never send the option again on any of the normal packets.
>

---

From: David Borman <[email-masked]>
Date: Wed, 27 Mar 2013 14:43:33 +0000

> Is that really what we want here?

Yes, that is late enablement of TSopt, i.e., negotiate it on the SYNs,
and then not use TSopt until later in the connection.  But once a TSopt
has been sent in either direction, it must be enabled for the duration
of the connection.  What we don't want is TSopt being turned off later
in the connection.

The intention is that this is compatible with implementations that
don't support late enablement, i.e. either side can send TSopt in all
their packets, and then the other side must also send TSopt.

So, an implementor doesn't need to "watch for whether a TSopt has been
received on the first non-SYN packet," unless they are putting in support
for late enablement of TSopt.

---

From: Joe Touch <[email-masked]>
Date: Wed, 27 Mar 2013 08:47:03 -0700

>  Once TSopt has been sent or received on a non-SYN packet, TSopt

I don't understand this idea - that TSopt can be "activated" for a connection during the SYN exchange, but not used until sent in a non-SYN packet?  I thought we had converged that - for now - we would assume that TSopt needed to be in every non-SYN once it was negotiated.

So I would suggest:

  Once TSopt has been successfully negotiated during the SYN exchange,
  TSopt (continuing below)

>  TCP MAY drop the packet and send an ACK.

what's being ACK'd? i.e., ACK the last segment successfully received? could this then be used to 'trick' TCP into sending dup-acks? why send anything, if you consider this an error?

>  A TCP MUST NOT abort a

The SHOULD should be MUST AFAICT. Same as for any unrecognized option.

> something is a change from 1323 belongs in Appendix F.

OK. But you should mention that in the intro and perhaps reiterate it in each section. Right now, it is referenced first in the PAWS intro, but that's after TSopt.

Joe

---

From: Joe Touch <[email-masked]>
Date: Wed, 27 Mar 2013 08:49:42 -0700

On Mar 27, 2013, at 7:43 AM, David Borman <[email-masked]> wrote:

> and then not use TSopt until later in the connection.

Why would that make sense?

...
> their packets, and then the other side must also send TSopt.

Let's figure out what the protocol ought to do first, then decide whether it impacts existing implementations.

Joe

---

From: David Borman <[email-masked]>
Date: Wed, 27 Mar 2013 17:06:21 +0000

> Why would that make sense?

See the other discussion about the usefulness of TS.  If you are just
using TS for PAWS, don't use TS until you're in danger of wrapping
the sequence space.

			-David

---

From: David Borman <[email-masked]>
Date: Wed, 27 Mar 2013 17:29:17 +0000

> I don't understand this idea - that TSopt can be "activated" for a connection during the SYN exchange, but not used until sent in a non-SYN packet?  I thought we had converged that - for now - we w…

See the discussion about the usefulness of TSopt and using
it only for PAWS.

> what's being ACK'd? i.e., ACK the last segment successfully received? could this then be used to 'trick' TCP into sending dup-acks? why send anything, if you consider this an error?

You generate an ACK based on the TCP state, just like every place
else in 793 where it says you drop the packet and send an ACK.  So:
   "... MAY drop the packet and send an ACK of the form:

          <SEQ=SND.NXT><ACK=RCV.NXT><CTL=ACK>"

> The SHOULD should be MUST AFAICT. Same as for any unrecognized option.

Fine, it doesn't matter much, make it a MUST.  The only difference is
that if it is a MUST, then an implementation that does something
besides ignoring the TSopt does not conform to 1323bis.  If it's a SHOULD
then if they do something else they can still claim conformance to
1323bis, and future documents that specify how to use TSopt in this
case don't have to change 1323bis to do so.  Not that that matters
much since that future document will also have to say you can send
TSopt without having negotiated it in the SYNs.

> OK. But you should mention that in the intro and perhaps reiterate it in each section. Right now, it is referenced first in the PAWS intro, but that's after TSopt.

Put what in each section?  That there's an Appendix F that lists
the changes from 1323?  Ugh.  The table of contents already
lists "Appendix F.  Changes from RFC 1323".  At most, the
second paragraph of the Introduction section can have one
sentence added:

	"Changes between RFC 1323 and this document
	are detailed in Appendix F."

And that should be sufficient, no need to mention it again.

		-David

---

From: Joe Touch <[email-masked]>
Date: Wed, 27 Mar 2013 10:33:13 -0700

> using TS for PAWS, don't use TS until you're in danger of wrapping

I still find this confusing. The benefit is either worth using 10 bytes 
all the time or not at all. I can't see the justification for a complex 
mechanism to enable TS only when the seq wrap is imminent. I don't know 
of any other sort of "on demand" protection in TCP, and introducing this 
as such needs a bit of discussion on complexity vs. necessity.

IMO, this doc should stay closer to the minimum required to correct 
1323, not to introduce every corner case that implementers have considered.

Joe

---

From: Joe Touch <[email-masked]>
Date: Wed, 27 Mar 2013 10:35:41 -0700

On 3/27/2013 10:29 AM, David Borman wrote:
...
>            <SEQ=SND.NXT><ACK=RCV.NXT><CTL=ACK>"

Can you also address the issue of dup-acks?

> TSopt without having negotiated it in the SYNs.

My view is that future docs that want to extend this mechanism will need 
to UPDATE this doc anyway, so we shouldn't be leaving the door open to 
"future, unspecified" extensions in this one.

OK.

Joe

---

From: David Borman <[email-masked]>
Date: Wed, 27 Mar 2013 18:02:01 +0000

On Mar 27, 2013, at 12:33 PM, Joe Touch <[email-masked]>
 wrote:

> I still find this confusing. The benefit is either worth using 10 bytes all the time or not at all. I can't see the justification for a complex mechanism to enable TS only when the seq wrap is imminent. I don't know of any other sort of "on demand" protection in TCP, and introducing this as such needs a bit of discussion on complexity vs. necessity.

You can't have both: requiring TSopt in every packet and not using 10/12 bytes
of option space in every packet.  Delayed enablement of TSopt for PAWS is
how you avoid using TSopt until PAWS needs it.  And why do you think it is
a complex mechanism?  Just remember ISS in your TCP state, and when sending,
if SEG.SEQ < ISS, you're half way to wrapping the sequence space, so turn
on TSopt.

> 
> IMO, this doc should stay closer to the minimum required to correct 1323, not to introduce every corner case that implementers have considered.

It's pretty clear that the value of TSopt for calculating RTO is pretty
low. and the value of TSopt for PAWS only matters when you might wrap
the sequence space.  The minimum requirements are that once you start
sending TSopt on a connection, you need to continue sending it for the
duration of the connection, and you don't send TSopt on a connection
unless you negotiated it in the SYN exchange.  I don't see a good
argument for excluding the late usage of TSopt, especially in the
PAWS only case.

			-David

---

From: David Borman <[email-masked]>
Date: Wed, 27 Mar 2013 18:12:14 +0000

> Can you also address the issue of dup-acks?

Why?  I don't agree with the supposition.  It's not hard to get TCP
to generate a dup-ack today, e.g., that's what keep-alives do, so
what's special about this situation that would warrant it being called
out and discussed?
			-David

---

From: Joe Touch <[email-masked]>
Date: Wed, 27 Mar 2013 15:32:21 -0700

On 3/27/2013 11:02 AM, David Borman wrote:
...
> if SEG.SEQ < ISS, you're half way to wrapping the sequence space, so turn

Is that what's being proposed? Then *maybe*. But what I've seen so far 
is "you can turn it on when you want, and here's what happens" in a very 
vague way.

IMO, turning it on mid-stream requires the description of handling a 
bunch of corner cases - retransmission, SACK, etc. The doc either needs 
to go down that path - which requires a bunch more text *and* WG 
consensus, or should leave this out.

> argument for excluding the late usage of TSopt, especially in the

I described it - the complexity of the spec and the implementation vs. 
the extra overhead.

IMO, if you're willing to eat 10 bytes if PAWS might happen, and you ate 
it during the SYN, then I don't understand wanting or trying to save it 
the rest of the time.

Joe

---

From: Joe Touch <[email-masked]>
Date: Wed, 27 Mar 2013 15:35:18 -0700

> what's special about this situation that would warrant it being called

The first time you get a segment that you want to drop (because it lacks 
TSopt), this is fine.

The second or third time it's happening because a corner case isn't 
being handled, and it could prevent the TCP connection from progressing. 
E.g., what if the sender thinks that TSopt "starts at SEQNO=NNNN" (and 
thus retransmits segments<NNNN without TSopt) is trying to talk to a 
receiver that thinks that TSopt "starts once I get any segment with 
TSopt" (and thus drops every retransmission)?

We know what should happen, but it's not in the document. Yet.

Joe

---

From: Mark Allman <[email-masked]>
Date: Wed, 27 Mar 2013 23:25:40 -0400

> The benefit is either worth using 10 bytes all the time or not at
> all. 

I think this is just absurd.  This is about PAWS.  If the sequence space
never wraps then how could it be worth using 10 bytes?  As far as I can
tell the only reason one could even remotely come up with would be
simplicity of implementation.  But, even that seems dubious to me given
that turning on TS mid-way through is a simple conditional---hardly a
complex mechanism (and that is even more true if we negotiate in the
3WHS as you like).

Just to be clear, if this is all or nothing then ...

  - We could turn on timestamps for every TCP segment we send so we can
    ensure if we need PAWS that we can use PAWS.

    This is of course massively wasteful given that the vast, vast
    majority of connections will never wrap the sequence space (go look
    at a flow size distribution).

    (I do not like this approach.)

  - We could just decide PAWS isn't a big concern and we can just live
    with the slight probability that we'll end up with corrupted data on
    one of the slight number of connections that both sends enough
    volume and at a great enough speed to wrap too quickly.

    This is of course gaming things.

    But, hey, maybe you punt to the app and say there should be an app
    layer checksum anyway, so Oh Well.

    (I do not like this approach.)

  - We let the app indicate whether the TCP should use TS or not.  It
    may have an idea how much data will be sent and hence be able to
    make a good decision.

    - Now, what happens when the app says "don't use TS" and we end up
      in a situation where PAWS is necessary?  Well, that just sucks.
      Now we have to either just forget PAWS and hope for the best or we
      have to limit the speed of the connection so it can't wrap too
      fast.  Either of these may be OK since the app chose not to use TS
      and so I guess we could just use the Live With The Consequences
      notion. 

    - However, limiting the speed of the connection isn't getting us
      away from complexity TCP.

    - Also, now you're making the app designer grok TCP's sequence space
      and wrapping and window size and understanding how all this fits
      together.  That seems lousy.

    - And, its especially lousy when a little tweak (add a conditional)
      could fix this within TCP and leave the app out of it.

    (I do not like this approach.)

In other words, the first two add no complexity but either game
reliability or are grossly wasteful.  The third still adds complexity
and may also game reliability or be grossly wasteful.

To me it is simply common sense that you should turn the TS option on
when you need it.  And, for PAWS that isn't until you wrap (or get near
wrapping).

And, if you need an exemplar of an option we use only when necessary:
SACK. 

allman

---

From: Joe Touch <[email-masked]>
Date: Wed, 27 Mar 2013 23:11:11 -0700

On Mar 27, 2013, at 8:25 PM, Mark Allman <[email-masked]> wrote:

> I think this is just absurd.  This is about PAWS.

If you want absurd, see PAWS. That mechanism can be accomplished with a very short option that encodes the top byte(s) of an extended sequence number space - in much fewer than 10 bytes.

> If the sequence space
> never wraps then how could it be worth using 10 bytes?

If you don't "turn it on" during the connection, then you get no protection across connections or reboots as well, though. I'm OK with that, but that's another aspect that needs to be described, FWIW.

> As far as I can

I've listed a fairly large handful of corner cases for midway-commencement of TSopt even if negotiated during 3WHS that need to be clearly and completely documented before we should consider that reasonable.

>    (I do not like this approach.)

We could create a simple 3-4 byte version that can be defined as "implicitly encoding a 0 high-order value if absent", which then would take only 2 bytes during the SYN (vs 10 for TSopt), zero bytes during most connections, and 3-4 (depending on how far the wrap is expected) to protect against PAWS.

And it would be a lot simpler to spec than this, IMO.

Joe

---

From: Mark Allman <[email-masked]>
Date: Thu, 28 Mar 2013 09:11:55 -0400

> If you want absurd, see PAWS. That mechanism can be accomplished with
> a very short option that encodes the top byte(s) of an extended
> sequence number space - in much fewer than 10 bytes. 

Absolutely.  And, if could turn back the clock and know that RTTM wasn't
useful when 1323 was standardized that is no doubt exactly what we'd
do.

(As an aside, perhaps there is a lesson here in not entangling things up
too much.  If we had not piggybacked PAWS on the timestamps we presumed
we needed anyway then it'd be a bit easier to deprecate one without
impact on the other.  Well, OK.  That doesn't exactly help the current
situation, but perhaps a point to remember.)

However, while this sort of start-from-scratch approach might be
conceptually nice it ignores that the logic for the current PAWS is
all there in most TCP implementations and what we're talking about here
are a few modest tweaks.  The path to get to a PAWS 2.0 is easier
through tweaking the current scheme than through inventing a new
option. 

> > If the sequence space never wraps then how could it be worth using
> > 10 bytes?
> 
> If you don't "turn it on" during the connection, then you get no
> protection across connections or reboots as well, though. I'm OK with
> that, but that's another aspect that needs to be described, FWIW. 

PAWS doesn't necessarily give you protection across connections.  You
may get some protection.  Or, you may not.  But, you sure can't count on
it.  In fact, RFC 1323 explicitly says:

      We may still ask whether the PAWS mechanism can provide additional
      security against old duplicates from earlier connections, allowing
      us to relax the enforcement of MSL by the IP layer.  Appendix B
      explores this question, showing that further assumptions and/or
      mechanisms are required, beyond those of PAWS.  This is not part
      of the current extension.

So, unless you are proposing that 1323bis in fact should tackle this
issue further, I think that this is a red herring.

allman

---

From: David Borman <[email-masked]>
Date: Thu, 28 Mar 2013 14:26:01 +0000

I'm getting pretty frustrated of this whole discussion.  I'm to the
point where even though I personally think it's the wrong way to go,
make the text simply:

  A TCP MAY send the Timestamp option (TSopt) in an initial <SYN>
  segment (i.e., segment containing a SYN bit and no ACK bit), and MAY
  send a TSopt in a <SYN,ACK> only if it received a TSopt in an
  initial <SYN>.

  In the case of crossing <SYN> segments where one <SYN> contains a
  TSopt and the other doesn't, the side that sent the <SYN> without
  the TSopt MAY send a TSopt in the <SYN,ACK> segment.

  Once TSopt has been sent and received, TSopt MUST be sent in every
  non-<RST> packet for the duration of the connection.

This explicitly disallows late enablement of TSopt in 1323bis,
despite the fact that it's been desired for years.  Once you send and
receive TSopt, it's on for the whole connection.

Is this what *other* people on the list want?

>   previous implicit assumption.

we can just take it as is, which leaves the door open for late
enablement without spelling out in black and white every last detail
of how that would work.

Consensus doesn't mean we have 100% agreement, it means that everyone
has been able to express their opinion and that opinion has been heard
and understood, but the majority decision might still go a different way.

So it'd be really good to get some other comments from a larger pool
of people on where this should go so we can resolve this:

1) No late enablement of TSopt: once it's negotiated, it's on for
   the rest of the connection.

2) Allow for late enablement of TSopt, i.e., Richard's text.

3) Allow late enablement of TSopt, and we hash out all the explicit
   details of every corner case we can think of.

			-David

---

From: Pasi Sarolahti <[email-masked]>
Date: Thu, 28 Mar 2013 20:44:01 +0200

> and understood, but the majority decision might still go a different way.

Right. We need to decide about how to proceed with the TSopt negotiation issue, and I think the list you present below are a good and concrete set of options we have on the table. Thanks for moving us forward.

So, I'd like to second David's request: additional input would be much appreciated, based on the options below.

>   details of every corner case we can think of.

As Michael said in an earlier Email, option 3) could be a separate I-D, but in that case it would (in my opinion) imply 2) for rfc1323bis. In my opinion, it would be good to try to keep rfc1323bis reasonably close to the original, otherwise we might still need to keep on working on it for quite a while...

- Pasi

---

From: "Scharf, Michael (Michael)" <[email-masked]>
Date: Thu, 28 Mar 2013 20:19:46 +0100

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Pasi Sarolahti
> Sent: Thursday, March 28, 2013 7:44 PM
> To: David Borman
> Cc: Joe Touch; tcpm ([email-masked]); Tim Shepard; [email-masked]
> Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-1323bis-07.txt
> 
> Right. We need to decide about how to proceed with the TSopt 
> negotiation issue, and I think the list you present below are 
> a good and concrete set of options we have on the table. 
> Thanks for moving us forward.
> 
> So, I'd like to second David's request: additional input 
> would be much appreciated, based on the options below.
> 
> As Michael said in an earlier Email, option 3) could be a 
> separate I-D, but in that case it would (in my opinion) imply 
> 2) for rfc1323bis. In my opinion, it would be good to try to 
> keep rfc1323bis reasonably close to the original, otherwise 
> we might still need to keep on working on it for quite a while...

Indeed, I believe that 3) should be a separate document. For several reasons:

- 1323 is very widely deployed, while we talk here about a new feature that differs to how TCP works today

- 1323bis should really be finalized *now*

- It would be good to have a dedicated document for how to realize late enablement, in case that it could be applied to options other than TS in future - even if I am not sure if this will ever happen

- A new ID gives us the chance to discuss PS vs. EXP separately - I personally think it could be PS and thus update 1323bis, but I guess that some of you will disagree with that

Regarding 1) or 2), I think that a relevant criteria for 1323bis is what is indeed deployed today. According to what has been said (I don't have own data), this seems to be mostly 1) rather than 2). But, as already said, I'd also support a follow-up PS draft that would update 1323bis to fix a known bug therein ;)

Michael (random community member)

---

From: Mark Allman <[email-masked]>
Date: Thu, 28 Mar 2013 15:46:28 -0400

> - 1323bis should really be finalized *now*

Why?  This just seems bogus to me.  We've been waiting for a 1323bis for
10+ years.  Why the sudden rush?

Why are we pushing a 1323bis?  Because of ... what?  It seems to me that
if we're going to bis anything it isn't to just get an updated date
stamp on the same document, but we should incorporate what we have
learned about the technology into the new document.  It doesn't matter
if that is difficult.  It doesn't matter if that takes a little time.

Yes, at some point we need to decide that a change is big enough that
perhaps it isn't bis-worthy given the widespread use of this technology
and punt to another document.  But, I don't think we do that because we
all the sudden after a zillion years need to push something to the
IESG.

I.e., calm down! :-)

allman

---

From: David Borman <[email-masked]>
Date: Thu, 28 Mar 2013 20:12:09 +0000

> all the sudden after a zillion years need to push something to the

I hear you, Mark.  But as you know we've been down the 1323bis path
multiple times, and none of the previous attempts succeeded.  With
Richard doing a great job of editing the document, I think we are better
poised then ever to get this done.

My #1 reason for getting 1323bis published is to document and fix the
known bugs in 1323, i.e. things in Appendix F, specifically item (b):

   (b)  In RFC1323, section 3.4, step (2) of the algorithm to control
        which timestamp is echoed was incorrect in two regards:

        (1)  It failed to update TS.recent for a retransmitted segment
             that resulted from a lost <ACK>.

        (2)  It failed if SEG.LEN = 0.

        In the new algorithm, the case of SEG.TSval >= TS.recent is
        included for consistency with the PAWS test.

People only know things in Appendix F because of tribal knowledge, or
looking at draft copies of 1323bis.

That's why I'm willing to punt on late TS enablement in 1323bis in
favor of getting something published, just like when 1323 was published
we pulled out SACK so that 1323 could get published while the discussion
continued about SACK.

			-David

---

From: John Leslie <[email-masked]>
Date: Fri, 29 Mar 2013 09:32:24 -0400

Joe Touch <[email-masked]> wrote:
> If you want absurd, see PAWS. That mechanism can be accomplished
> with a very short option that encodes the top byte(s) of an extended

   I've got to agree with Joe here. PAWS is complicated, non-intutitive,
and drains entirely too much TCP option space. If the function is
important, we should design a better way to do it.

   If, OTOH, the funtion isn't worth designing a better way, I'd let
the sleeping dogs lie until we can deprecate it.

   RFC 1323 seems to deserve a path to Historic...

--
John Leslie <[email-masked]>

---

From: "Scheffenegger, Richard" <[email-masked]>
Date: Fri, 29 Mar 2013 13:53:29 +0000

>    RFC 1323 seems to deserve a path to Historic...

You sure?

That's make WindowScale historic too.... (and yes, the mingling of WS, TS and SACK in one RFC1072 two decades ago was not the wisest approach).

I think 1323bis should finally be published, simply to fix the omissions and bugs of the original text in 1323.

And for the time being, PLEASE let us not discuss the merits of using RTTM/PAWS/TSopt; 

Most stacks leave that as a global option, and from what I can tell, many disable this by default. And that is fine. But if one chooses to use TS, the mechanisms should be described properly, without any significant issues in the RFC for someone how is not into hunting down bug fixes to an RFC in running code. 

And WS, as described in 1323, does have its share of issues (implementers not considering window retractions properly). 

I'll post a -08 shortly, for a consolidated text. I would urge anyone who has a major bone to pick with the TSopt, to come up with improved text (thanks Joe for suggesting improvements). So far, the existing text describes the typical TSopt use case / state machine. 

Best regards,

Richard Scheffenegger

> John Leslie
> Sent: Freitag, 29. März 2013 14:32
> To: Joe Touch
> Cc: [email-masked]
>    If, OTOH, the funtion isn't worth designing a better way, I'd let the
> sleeping dogs lie until we can deprecate it.
>

---

From: "Scheffenegger, Richard" <[email-masked]>
Date: Fri, 29 Mar 2013 15:10:19 +0000

Hi,

> From: Pasi Sarolahti

Note, that text in 1323bis-08 now aligns with option 1) - explicitly disallow late TSopt enablement.

>>   details of every corner case we can think of.

As Joe pointed out, late enablement with a 10 (12) -byte option in the SYN is kind of pointless. Also, such a mechanism warrants a full draft in it's own right (and there are three authors working on that, see 
http://tools.ietf.org/html/draft-trammell-tcpm-timestamp-interval-00
and 
http://tools.ietf.org/html/draft-scheffenegger-tcpm-timestamp-negotiation-05 

which really is mostly a problem statement / requirements draft, but leaving out the late negotiation part in the published draft.

I hope that going with option 1 meets more the consensus of the WG.

Regards,
  Richard

---

From: Mark Allman <[email-masked]>
Date: Fri, 29 Mar 2013 12:22:06 -0400

> poised then ever to get this done.

Well, I guess we view this differently.  I'd say if we have energy then
lets do what needs to be done.

If you want to play small ball and fix only the small and minor things
then I think that'd be disappointing, but at least I think it'd be good
to catalog the bigger issues that have been raised.

allman

---

From: Joe Touch <[email-masked]>
Date: Fri, 29 Mar 2013 12:52:50 -0700

> important, we should design a better way to do it.

Stay tuned ;-)

I'm working on it. Not that it affects this discussion, though.

Joe