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

[Bob Briscoe <[e-mail]>]

Joe,

At 23:25 24/09/2014, Joe Touch wrote:
>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).

That's why I prefer syn-op-sis because it only uses 2 SYNs for transition.

I've included a new section on ways to use only 1 SYN during 
transition (building a white-list) and ultimately moving to 1 SYN in 
the future, only falling back to the legacy SYN in series rather than 
parallel if you hit a legacy listener.

The other two in tcp-syn-ext-opt have to be 2-SYN for ever.

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

That's the architectural point.
There's also a tactical point. It should get through every middlebox.

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

Yes, I'm already repeating myself - you're right we need wider opinions.



Bob


>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

________________________________________________________________
Bob Briscoe,                                                  BT