Re: [tcpm] Fwd: I-D Action:draft-cheng-tcpm-fastopen-00.txt

[William Allen Simpson <[e-mail]>]

On 3/16/11 2:00 AM, Jerry Chu wrote:
> TFO and TCPCT have distinctly different goals so I don't see how one could call
> it a follow-on to RFC6013.
> Yes we've had some discussion a year ago because after reading your then still
> unpublished and very sketchy draft I thought we could use TCPCT to get what we
> want. But after the meeting we concluded TCPCT is not suitable for us.
>
Thank you for clarifying.  I misunderstood our prior communications, and
your actions on joining the private TCPCT developers list.  I was unaware
that Google had decided to go its own way, and had been waiting for various
other parties to complete their work.  TCPCT as a specification has been
stable and fully specified for over a year!

Rather than continuing to wait, I'll post my own competing variant of this
proposal as a follow-on to TCPCT for comparison and discussion, as soon as
I've some spare hours.

However, I do not view flooding data on the second connection as important
as reducing all latency by including data on the first connection (and all
subsequent connections).  Much more bang for the buck!

The fact that your proposal does not test whether SYN data works *before*
flooding the data is a serious flaw, as it will in many cases actually
increase the number of RTT.  First do no harm....

I do not consider sacrificing reliability and security for performance a
good trade.

Moreover, this impedes ever adding any other TCP option ever again.  This
actively prevents inclusion of options approved by the IETF and this group
over the past few years.