Re: [tcpm] More TCP option space in a SYN: draft-briscoe-tcpm-syn-op-sis-02

[Joe Touch <[e-mail]>]

Hi, Bob (et al.),

It's good to have a more detailed description of the proposal.

I still find a dual-SYN solution untenable, though, as it has been for
other upgrade paths in the past (e.g., IPv6).

Also, I don't particularly think that putting the options at the end of
the segment serves any useful purpose other than to make this option
handle the option space in a different way than the default DO header field.

I'm glad to hear what others think and agree that an unbiased comparison
of the approaches would be a useful place to for the discussion to start...

Joe

On 9/22/2014 7:55 AM, Bob Briscoe wrote:
> Joe,
> 
> I've just posted a revision here:
> <http://tools.ietf.org/html/draft-briscoe-tcpm-syn-op-sis-02>
> 
> * I've taken more care to explain it. It was a bit terse before. So it's
> ready for the list to review properly now.
> 
> It would be useful if someone wrote a comparison with the other ideas on
> how to do this, including the ones we wrote jointly and SLO, LOIC and
> DBormam's 4-way HS. Better someone independent of all the authors does
> this. But I want to get syn-op-sis right first, a comparison won't be
> much use until its stable.
> 
> 
> The underlying idea is still the same. The reasons I've updated it are
> many (the change log taken from the appendix is pasted at the end of
> this email for convenience).
> 
> * Mainly I've articulated that all these approaches that add TCP options
> after the Data Offset are not just hacks to get more space; they add a
> new architectural capability to TCP - a distinction between TCP options
> that might be relevant to middleboxes, and ones that are only for the
> destination (a bit like destopt in IPv6 - needing to specify which TCP
> options are for the destination only is ironic but necessary).
> 
> * I've also realised that this approach will ultimately return to a
> single SYN solution, whereas both the ideas in
> draft-touch-tcpm-tcp-syn-ext-opt will always require two SYNs.
> 
> 
> 
> Bob
> 
> Pasted from the change log:
> 
>    From briscoe...-01 to briscoe...-02:
> 
>       Technical changes:
> 
>       *  Defined the client behaviour dependent on which response
>          arrives first.
> 
>       *  Allowed retransmission of either SYN or SYN-U if no response
>          from either.
> 
>       *  Redefined EOO as an offset from the end of the packet, not from
>          the beginning of the payload.
> 
>       *  Added section on Migration to a Single Handshake.  Reworded
>          dual handshake so that it is not mandatory for the client to
>          send dual SYNs simultaneously; only the relation between the
>          SYNs and the response to either is mandatory, while parallel
>          SYNs is purely for latency reduction.
> 
>       *  Added rules for writing TCP options, i.e. i) options like TFO
>          MUST NOT be located in the TCP header and ii) add no-ops to
>          align on 4-octet boundary.
> 
>       *  Added rules for forwarding TCP options, i.e. only the
>          destination looks for TCP options after the Data Offset, not
>          middleboxes.
> 
>       *  Moved the Explicit Handshake variant (SYN-L) into the body from
>          the appendix, and recommended the choice could be down to
>          implementers or apps.  Included section on corner cases.
> 
>       *  Introduced more normative language throughout the Protocol
>          Spec.
> 
>       Editorial changes:
> 
>       *  Added temporary motivation section
> 
>       *  Added confusible terminology to Terminology section.
> 
>       *  Divided protocol spec into sub-sections.
> 
>       *  Handshake table: Clarified that the two columns under each
>          server represent separate threads, that may run on separate
>          servers, without co-ordination.  Represented message
>          dependencies in the alignment of the rows.
> 
>       *  Explained the table.
> 
>       *  Explained why a legacy server won't ever pass SYN-U to the app.
> 
>       *  More precisely described loss as 'not arrived before a
>          timeout', and explained the tradeoff between latency and extra
>          TCP options.
> 
>       *  Gave reasoning for locating TCP options in three groups.
> 
>       *  Acknowledged Rob Hancock for the architectural idea of hiding
>          an extension to a protocol in the layer above.
> 
>       *  Appendix about protocol alternatives now only presents the SYN-
>          UD alternative, given the implicit/explicit handshake choice
>          has been moved to the body.
> 
>       *  Rewrote appendix about comparing the choices to treat the two
>          pairs of choices separately, rather than discussing all four
>          combinations of pairs of choices.
> 
> ________________________________________________________________
> Bob Briscoe,                                                  BT