Subject: [tcpm] Last Call: <draft-ietf-tcpm-fastopen-09.txt> (TCP Fast Open) to Experimental RFC

From: The IESG <[email-masked]>
Date: Wed, 09 Jul 2014 05:38:59 -0700

The IESG has received a request from the TCP Maintenance and Minor
Extensions WG (tcpm) to consider the following document:
- 'TCP Fast Open'
  <draft-ietf-tcpm-fastopen-09.txt> as Experimental RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
[email-masked] mailing lists by 2014-07-23. Exceptionally, comments may be
sent to [email-masked] instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract

   This document describes an experimental TCP mechanism TCP Fast Open
   (TFO). TFO allows data to be carried in the SYN and SYN-ACK packets
   and consumed by the receiving end during the initial connection
   handshake, thus saving up to one full round trip time (RTT) compared
   to the standard TCP, which requires a three-way handshake (3WHS) to
   complete before data can be exchanged. However TFO deviates from the
   standard TCP semantics since the data in the SYN could be replayed to
   an application in some rare circumstances. Applications should not
   use TFO unless they can tolerate this issue detailed in the
   Applicability section.

The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-tcpm-fastopen/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-tcpm-fastopen/ballot/

No IPR declarations have been submitted directly on this I-D.

---

From: John Leslie <[email-masked]>
Date: Wed, 9 Jul 2014 13:42:33 -0400

>   <draft-ietf-tcpm-fastopen-09.txt> as Experimental RFC

   Have we actually settled how this would interact with EDO?

   (Just asking...)

--
John Leslie <[email-masked]>

---

From: Joe Touch <[email-masked]>
Date: Wed, 09 Jul 2014 11:26:17 -0700

>     Have we actually settled how this would interact with EDO?

EDO currently does not change its behavior depending on other options.

The only options that might require interpreting EDO would be TCP-AO (to 
include or omit options in the HMAC calculation) or any alternate 
checksums (there was one, but it's been obsoleted).

Otherwise, I don't think there is - or should be - any interaction at all.

The only proposal I saw to link them involved SYN-EDO, not EDO (i.e., to 
deal with the initial SYN). I already responded as to why I don't think 
the proposed approach is useful, but the SYN-EDO doc hasn't even been 
posted yet.

Joe