Subject: Re: [tcpm] draft-ietf-tcpm-1323bis-14.txt

From: "Scheffenegger, Richard" <[email-masked]>
Date: Fri, 2 Aug 2013 13:55:00 +0000

Hi Yuchung,

thanks for the review.

> Some minor suggestions on wordings.
> 1.    RTTM Rule: A TSecr value received in a segment MAY be used to update
>               the averaged RTT measurement only if the segment advances
>               the left edge of the send window, i.e.  SND.UNA is
>               increased.
> s/segment/ACK

I have not incorporated that change, as this could be interpreted to be true only for pure ACKs. Segments here could be any valid segments, with or without data (bidirectional data flow).

> 2. "An <ACK> for an out-of-order segment
>         SHOULD therefore contain the timestamp from the most recent
>         segment that advanced the window."
> s/advanced the window/advanced RCV.NXT

Modified.

The contended section describing the semantics of the Timestamps option now (in 1323bis-15 to-be) reads:

   Once TSopt has been successfully negotiated (sent and received)
   during the <SYN>, <SYN,ACK> exchange, TSopt MUST be sent in every
   non- <RST> segment for the duration of the connection, and SHOULD be
   sent in an <RST> segment (see Section 4.2 for details).  If a non-
   <RST> segment is received without a TSopt, a TCP SHOULD silently drop
   the segment.  A TCP MUST NOT abort a TCP connection because any
   segment lacks an expected TSopt.

So, the SHOULD / SHOULD NOT are condensed in a simpler to read sentence. 

As there have been multiple comments to describe the effects of this SHOULD, the following paragraph was added right after. This is new text, and the first throw. Text donations are highly appreciated if this text does not capture the purpose to the required extent:

   Implementations are strongly encouraged to follow the above rules for
   handling a missing Timestamps option, and the order of precedence
   mentioned in Section 4.3 when deciding on the acceptance of a
   segment.  This is to maintain the integrity of the payload data at
   the receiver in particular on high speed networks.  However, it has
   been mentioned that under some circumstances, the above guidelines
   are too strict, and some paths sporadically suppress the Timestamps
   option, while maintaining payload integrity.  A path behaving in this
   manner should be deemed inacceptable, but it has been noted that
   relaxing the acceptance rules can serve as a workaround, and allows
   TCP to run across such paths.

Richard Scheffenegger

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Yuchung Cheng
> Sent: Montag, 29. Juli 2013 13:12
> To: Pasi Sarolahti
> Cc: tcpm ([email-masked])
> Subject: Re: [tcpm] draft-ietf-tcpm-1323bis-14.txt
> 
> I only reviewed section 3 and it looks good to me.
> 
> Some minor suggestions on wordings.
> 1.    RTTM Rule: A TSecr value received in a segment MAY be used to update
>               the averaged RTT measurement only if the segment advances
>               the left edge of the send window, i.e.  SND.UNA is
>               increased.
> s/segment/ACK
> 
> 2. "An <ACK> for an out-of-order segment
>         SHOULD therefore contain the timestamp from the most recent
>         segment that advanced the window."
> s/advanced the window/advanced RCV.NXT
> 
> 
> FWIW Linux recently changed to only use TS for RTTM if normal timings
> aren't available. It now also measure RTT on new SACK for better RTO
> during loss recovery http://patchwork.ozlabs.org/patch/260836/
> http://patchwork.ozlabs.org/patch/260838/
> http://patchwork.ozlabs.org/patch/260837/
> 
> 
> On Sun, Jul 21, 2013 at 10:39 PM, Pasi Sarolahti <[email-masked]>
> wrote:
> > Lots of mails have been exchanged on this since the WGLC, but here is an
> attempt to shortly summarize the main points:
> >
> > * Mark Allman made a thorough set of comments during the WGLC. My
> understanding is that these comments are now addressed. Some paragraphs
> have changed quite a bit as a result, so it would be good if people can
> check if the current text looks good.
> >
> > * After the WGLC there was an update on the text regarding handling of
> segments without timestamp option after they have been successfully
> negotiated (MUST drop in ver-14), and a follow-up discussion about
> possible interactions with middleboxes. In a recent mail Richard proposes
> changing this to SHOULD. This change is not yet visible in the I-D
> repository.
> >
> > If I'm forgetting something important, please remind me (and the list).
> >
> > I think in the meeting we should go through the main recent changes, and
> check if people are ok with the current wordings. Additional comments on
> the list are much appreciated.
> >
> > - Pasi
> >
> >
> > On Jul 16, 2013, at 2:03 PM, "Scheffenegger, Richard" <[email-masked]>
> wrote:
> >
> >> Hi,
> >>
> >> I would like to take this opportunity to stir up the recent discussions
> (from April/May timeframe) again.
> >>
> >> There have been some comments past the posting of this version on the
> list, which I wasn't able to fully qualify how they would impact this
> latest text.
> >>
> >> I would like to encourage the participants in these discussions to
> review the latest version, and point out if they cannot agree with any of
> the wording.
> >>
> >>
> >>
> >> There will probably be a slot at the upcoming IETF to try to find out
> what the consensus is on this document, too...
> >>
> >> Best regards,
> >>
> >> Richard Scheffenegger
> >>
> >>
> >>> -----Original Message-----
> >>> From: [email-masked] [mailto:[email-masked]]
> >>> Sent: Donnerstag, 23. Mai 2013 16:10
> >>> To: Bob Braden; Scheffenegger, Richard; Robert T. Braden; David
> >>> Borman; Van Jacobson
> >>> Subject: New Version Notification for draft-ietf-tcpm-1323bis-14.txt
> >>>
> >>>
> >>> A new version of I-D, draft-ietf-tcpm-1323bis-14.txt has been
> >>> successfully submitted by David Borman and posted to the IETF
> repository.
> >>>
> >>> Filename:     draft-ietf-tcpm-1323bis
> >>> Revision:     14
> >>> Title:                TCP Extensions for High Performance
> >>> Creation date:        2013-05-23
> >>> Group:                tcpm
> >>> Number of pages: 46
> >>> URL:             http://www.ietf.org/internet-drafts/draft-ietf-tcpm-
> >>> 1323bis-14.txt
> >>> Status:          http://datatracker.ietf.org/doc/draft-ietf-tcpm-
> 1323bis
> >>> Htmlized:        http://tools.ietf.org/html/draft-ietf-tcpm-1323bis-14
> >>> Diff:            http://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-
> 1323bis-
> >>> 14
> >>>
> >>> 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 Secretariat
> >>
> >> _______________________________________________
> >> tcpm mailing list
> >> [email-masked]
> >> https://www.ietf.org/mailman/listinfo/tcpm
> >
> > _______________________________________________
> > tcpm mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/tcpm
> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm

---

From: Joe Touch <[email-masked]>
Date: Fri, 02 Aug 2013 09:35:42 -0700

On 8/2/2013 6:55 AM, Scheffenegger, Richard wrote:
...
> As there have been multiple comments to describe the effects of this
> SHOULD, the following paragraph was added right after. This is new text,
> and the first throw. Text donations are highly appreciated if this text
> does not capture the purpose to the required extent:
>
>

This misses the key issue, and it should not be glossed-over.

A TCP that SHOULD drop segment missing an expected TSOpt (as when TS is 
negotiated during the SYN) MAY experience ***undetectable*** 
wrapped-sequence effects.

A TCP that MUST drop such segments WILL NOT experience such effects.

So relaxing this constraint turns PAWS protection from a guarantee to a 
maybe - and it does so in ways that the source cannot determine. The 
source presumably asked for PAWS, and the receiver agreed to it, but 
that guarantee is being turned into a maybe.

The big problem with allowing this SHOULD is it thus turns all TS 
requests into "no PAWS provided".

So you've just killed PAWS.

Another victory for "rough consensus".

Joe

---

From: "Scheffenegger, Richard" <[email-masked]>
Date: Mon, 5 Aug 2013 09:32:36 +0000

Hi Joe,

Thank you for your input!

I reworded the paragraph slightly. With my background in data storage, the one thing to avoid is silent data corruption (storage companies are generally very paranoid about that), thus the use of "data corruption" twice in the text below. That wording may nudge market forces to weed out the "best effort" PAWS implementations over time. That would agreeably be an improvement above the current state.

      <t>Implementations are strongly encouraged to follow the above rules for 
      handling a missing Timestamps option, and the order of precedence 
      mentioned in <xref target="sec421"/> when deciding on the acceptance of a 
      segment. A TCP receiver not dropping segments without an expected 
      Timestamps option may expirience *undetectable* wrapped-sequence effects, 
      such as data (payload) corruption or session stalls. In order to maintain 
      the integrity of the payload data, in particular on high speed networks, 
      it is paramount to follow the described processing rules.
      </t>
      
      <t>However, it has been mentioned that under some circumstances, the above 
      guidelines are too strict, and some paths sporadically suppress the 
      Timestamps option, while maintaining payload integrity. A path behaving in 
      this manner should be deemed inacceptable, but it has been noted that some 
      implementations relax the acceptance rules as a workaround, and allow TCP 
      to run across such paths. Again, if a receiver chooses to accept a segment 
      without an expected Timestamps option, it must be clear that undetectable 
      data corruption may occur. 
      </t>

Richard Scheffenegger

> From: Joe Touch [mailto:[email-masked]]
> Sent: Freitag, 02. August 2013 18:36
> To: Scheffenegger, Richard
> Cc: Yuchung Cheng; Pasi Sarolahti; tcpm ([email-masked])
> > SHOULD, the following paragraph was added right after. This is new
> > text, and the first throw. Text donations are highly appreciated if
> > this text does not capture the purpose to the required extent:
> >
> >
> negotiated during the SYN) MAY experience ***undetectable*** wrapped-
> sequence effects.
> 
> source presumably asked for PAWS, and the receiver agreed to it, but that
> guarantee is being turned into a maybe.
> 
> The big problem with allowing this SHOULD is it thus turns all TS requests
> into "no PAWS provided".
>

---

From: Joe Touch <[email-masked]>
Date: Mon, 05 Aug 2013 11:40:00 -0700

Hi, Richard,

This is good. I do think that the lead is buried - the last sentence is 
the most important, and needs to be highlighted somehow - either 
repeating it earlier, setting it as a stand-alone sentence for emphasis, 
etc.

Joe

---

From: "Scheffenegger, Richard" <[email-masked]>
Date: Tue, 6 Aug 2013 13:40:12 +0000

Hi Joe, Kevin, Pasi,

I have shuffled the sentences slightly, to reflect the suggested emphasis and make the point early and easier to spot.
The typo is also fixed.

Unless anyone objects, I'll submit -15 in the next few hours with these changed paragraphs.

      Implementations are strongly encouraged to follow the above 
      rules for handling a missing Timestamps option, and the order of 
      precedence mentioned in Section 4.3 when deciding on the 
      acceptance of a segment.
      
      If a receiver chooses to accept a segment without an expected 
      Timestamps option, it must be clear that undetectable data 
      corruption may occur. 
      
      Such a TCP receiver may experience undetectable wrapped-
      sequence effects, such as data (payload) corruption or session 
      stalls. In order to maintain the integrity of the payload data, 
      in particular on high speed networks, it is paramount to follow 
      the described processing rules.
      
      However, it has been mentioned that under some circumstances, 
      the above guidelines are too strict, and some paths sporadically 
      suppress the Timestamps option, while maintaining payload 
      integrity. A path behaving in this manner should be deemed 
      unacceptable, but it has been noted that some implementations 
      relax the acceptance rules as a workaround, and allow TCP to run 
      across such paths.  

Richard Scheffenegger

> Joe Touch
> Sent: Montag, 05. August 2013 20:40
> the most important, and needs to be highlighted somehow - either repeating
> it earlier, setting it as a stand-alone sentence for emphasis, etc.
> 
> Joe
> 
> > I reworded the paragraph slightly. With my background in data storage,
> the one thing to avoid is silent data corruption (storage companies are
> generally very paranoid about that), thus the use of "data corruption"
> twice in the text below. That wording may nudge market forces to weed out
> the "best effort" PAWS implementations over time. That would agreeably be
> an improvement above the current state.
> >
> >
> >>>      Implementations are strongly encouraged to follow the above
> >>> rules
> >> for
> >>>      option, while maintaining payload integrity.  A path behaving
> >>> in
> >> this
> >> A TCP that SHOULD drop segment missing an expected TSOpt (as when TS
> >> is negotiated during the SYN) MAY experience ***undetectable***
> >> wrapped- sequence effects.
> >>
> >> So relaxing this constraint turns PAWS protection from a guarantee to
> >> a maybe - and it does so in ways that the source cannot determine.
> >> The source presumably asked for PAWS, and the receiver agreed to it,
> >> but that guarantee is being turned into a maybe.
> >>

---

From: Joe Touch <[email-masked]>
Date: Tue, 6 Aug 2013 09:35:28 -0700

> I have shuffled the sentences slightly, to reflect the suggested emphasis and make the point early and easier to spot.

Thanks. I still prefer MUST with an explanation of how some endpoints violate that, FWIW. I don't think that having a TCP that compromises integrity "to allow TCP to run" makes ANY sense at all.

Joe

---

From: Kevin Mason <[email-masked]>
Date: Tue, 6 Aug 2013 18:51:13 -0400

Joe,
I understand your point, but could there be legacy stack implementations that prevent declaring MUST?

Kevin

---

From: Joe Touch <[email-masked]>
Date: Tue, 06 Aug 2013 16:01:09 -0700

MUST is what the world ought to be. There are always legacy violations. 
The point of MUST is that this means they should be fixed, rather than 
left alone.

Joe