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

[Joe Touch <[e-mail]>]

On 9/26/2014 12:53 PM, John Leslie wrote:
> Bob Briscoe <[e-mail]> wrote:
>> " If an upgraded TCP client includes the TCP Fast Open option
>> " [I-D.ietf-tcpm-fastopen] in the SYN, it MUST be placed with the extra
>> " TCP options after the end of the payload.
> 
>    Indeed, that is a good way to ensure that the SYN receiver is aware
> of the sender's intent to place something _after_ the data intended to
> be passed to the application.

I'd like to understand the logic behind this claim.

Regardless of where signalling information is placed:

	- legacy servers will (irrevocably) accept it as
	application data; the only way to undo it is to
	terminate the connection*

	- upgraded servers will know where to find it

Except to make parsing more complex, what is the perceived benefit of
using trailer-based signalling?

Joe

*- TCP-FO is particularly dangerous when coupled with dual-SYN (DS)
variants when the connection uses a cookie from a previous connection;
non-DS FO servers can't prevent passing invalid data to the application
by terminating the connection when the SYN-ACK is received by the client.