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

From: [email-masked]
Date: Fri, 18 May 2012 09:14:23 -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-02.txt
	Pages           : 45
	Date            : 2012-05-18

   This memo presents a set of TCP extensions to improve performance
   over large bandwidth*delay product paths and to provide reliable
   operation over very high-speed paths.  It defines TCP options for
   scaled windows and timestamps, which are designed to provide
   compatible interworking with TCP's that do not implement the
   extensions.  The timestamps are used for two distinct mechanisms:
   RTTM (Round Trip Time Measurement) and PAWS (Protection Against
   Wrapped Sequences).  Selective acknowledgments are not included in
   this memo.

   This memo updates and obsoletes RFC 1323.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-tcpm-1323bis-02.txt

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

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-tcpm-1323bis-02.txt

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

---

From: "Scheffenegger, Richard" <[email-masked]>
Date: Fri, 18 May 2012 16:56:59 +0000

Hi,

I have been asked by the chairs to act as editor on this draft, to shepard it and help finalize it.

The main differences between the last version published in March 2009 are summarized here:

Moved from nroff to xml2rfc. 
  This changed the layout (indentation, TOC, pagination) somewhat.

The content changed in these three aspects, after hallway discussions at the last IETF and email discussions:

   RTTM update processing explicitly excludes packets containing
        SACK options.  This addresses inflation of the RTT during
        episodes of packet loss in both directions.

(This really addresses an omission in all known implementations on the spirit of RTTM).

    In Section 3.2 the if-clause allowing sending of timestamps only
        when received in a <SYN> or <SYN,ACK> was removed, to allow for
        late timestamp negotiation.

(to continue the ongoing WG discussion on TCP Option space exhaustion and possible (if temporary) mitigations)

 Section 2.4 was added describing the unavoidable window
        retraction issue, and explicitly describing the mitigation steps
        necessary. 

(-01 already had a pointer to RFC1122 in here, but it may be helpful to implementers to have the proper action described once more explicitly in this document too).

Note: I submitted a version without the Nits-fix from Alexander (http://www.ietf.org/mail-archive/web/tcpm/current/msg04477.html) for some reason; this is fixed. Also, the issue brought up here may need more discussion, especially if Timestamps should become useful for more than just PAWS and coarse RTTM:

http://www.ietf.org/mail-archive/web/tcpm/current/msg04706.html

Best regards,
   Richard

-----Original Message-----
From: Scharf, Michael (Michael)
Sent: Mittwoch, 09. Mai 2012 14:10
To: [email-masked]

Dear all,

there have been suggestions to add an additional author to draft-ietf-tcpm-1323bis-01 in past TCPM meetings.

As a consequence, the chairs suggest to add Richard as an additional author in order the help with the completion of this WG item. Please let us know if this should result in any issue.

The understanding of the chairs is that the 1323bis document should really focus on fixing corner cases in RFC 1323, and we think that this document should be finished as soon as possible.

The recent discussion has shown that TCP timestamps could be further improved, e. g., by late activiation of options. However, this is a new concept that seems to require further studies and experiments. Our recommendation is therefore to address such new, interesting use of timestamps in a separate document.

Thanks

Michael (TCPM co-chair)

---

From: David Borman <[email-masked]>
Date: Fri, 18 May 2012 12:38:12 -0500

Hi Richard,
Thanks for doing the legwork on bringing this document into the modern age, the original nroff code was getting a bit old. :-)

The pseudo code needs to be updated to match the main body of the document.  Specifically, it has:

            Check whether the segment contains a Timestamps option and
            bit Snd.TS.OK is on.  If so:

               If SEG.TSval < TS.Recent and the RST bit is off, then
               test whether connection has been idle less than 24 days;
               if all are true, then the segment is not acceptable;
               follow steps below for an unacceptable segment.

               If SEG.SEQ is equal to Last.ACK.sent, then save SEG.TSval
               in variable TS.Recent.

            There are four cases for the acceptability test for an
            incoming segment:

The second case needs to be changed to:

               If SEG.SEQ is less than or equal to Last.ACK.sent, then save SEG.TSval
               in variable TS.Recent.

			-David Borman

On May 18, 2012, at 11:14 AM, [email-masked] wrote:

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

---

From: "Scheffenegger, Richard" <[email-masked]>
Date: Sat, 19 May 2012 10:22:40 +0000

Thanks David,

I believe that change was in the Nits provided by Alex already (and I forgot to apply before re-posting the draft);

The other issue mentioned by Alex, the failing PAWS test when ACKs get reordered (and the timestamp clock granularity is fine enough to have almost "individual" timestamps per data packet), is still something that I would like to work out. 

But I need to dig into this some more (if this can be addressed in a efficient way), before I can post some meaningful updates to that aspect.

IMHO, making timestamps resilient in the face of fast timestamp clocks and/or high ACK reordering would be good properties to allow future extensions. But I would like to learn if this is just a minority opinion in this WG...

To quote you:

> Also, for this issue that Alexander brings up, the 
> timestamp has to be changing between ACKs. If the 
> timestamp hasn't changed between the re- ordered 
> ACKs, then the "SEG.TSval >= TS.recent" check will 
> succeed. Generally, the TS clock shouldn't be 
> ticking that often, if it is changing with every 
> ACK then it might be going faster than it needs to.
>
> So, this issue only occurs when ACKs are re-ordered, 
> *and* the Timestamp clock has ticked between the 
> reordered ACKs. I'm thinking that 1323bis should 
> just note that this situation does exist.
>
> What does everyone else think? Shall we leave the 
> text as is and just document this edge case, or do 
> people disagree with me and feel that this is a
> real problem that needs to be addressed, and is
> more important than the problems that the original
> change fixes?
>
>			-David

Richard Scheffenegger

NetApp
[email-masked]
+43 1 3676811 3146 Office (2143 3146 - internal)
+43 676 654 3146 Mobile
www.netapp.com  

EURO PLAZA
Gebäude G, Stiege 7, 3.OG
Am Euro Platz 2
A-1120 Wien

> From: David Borman [mailto:[email-masked]]
> Sent: Freitag, 18. Mai 2012 19:38
> To: Scheffenegger, Richard
> Cc: [email-masked] Extensions WG
> Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-1323bis-02.txt
> 
> Hi Richard,
> Thanks for doing the legwork on bringing this document into the modern
> age, the original nroff code was getting a bit old. :-)
> 
> > 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.
> >

---

From: "Scheffenegger, Richard" <[email-masked]>
Date: Sat, 19 May 2012 16:10:47 +0000

Sorry. 

I'm trying to wrap my head around the implications of a reordered, and then discarded, pure ACK  as mentioned by Alex (http://www.ietf.org/mail-archive/web/tcpm/current/msg04478.html)

In the example given, the main issues appear to be that 
 a) TCP A would not process RTTM updates
 b) TCP A would send out an updated TS.ecr
 c) TCP A would not be able to detect reordering
 d) TCP A would not process any TCP information (options) in the discarded delayed ACK
provided that the PAWS check is performed prior to discarding the delayed ACK, correct?

>From a TCP flow and CC perspective, the later ACK (X+2 in the example) would however give the proper indication to update pipe; only pure NewReno without ABC would potentially misbehave during SS - slower than otherwise - but not during CA).

Point a) above wouldn't be done with RFC1323 either (as the reordered ACK doesn't ACK any new data anymore) - so ACK reordering would not increase the RTTM. This may lead to spurious RTOs because of that - but this is status quo.

Point b) may be an issue, but is effectively also covered by a) - as no data flows from B to A, B doesn't update its RTTM anyway, using TS.ecr...

Which leaves c) (detection of ACK reordering) and d) (processing of out-band TCP information). But that too is not defined, if I'm not mistaken.

c) and d) are basically sub-themes of the unreliable side-channels in TCP signaling...

If RTTM processing is seen important, it could be done prior to PAWS, with a time-based acceptance test (ie. TS.val >= TS.recent - 2 * RTO ) when TS.val < TS.recent...

What am I missing?

Best regards,
   Richard