Re: [tcpm] SYN/ACK Payloads, draft 01

[Joe Touch <[e-mail]>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



Adam Langley wrote:
| On Thu, Aug 14, 2008 at 1:12 PM, Joe Touch <[e-mail]> wrote:
|> Client-speaks-first puts data in the SYN, not the SYN-ACK. Or have you
|> got the roles reversed, as with FTP data connections?
|
| Sorry, I was speaking of the application layer protocol. Commonly,
| client-speaks-first application protocols are putting data in the
| final ACK of the 3-way handshake.
|
|> If the option is ignored, and you don't intend to change TCP semantics,
|> then the data - i.e., the hash or whatever - needs to be sent in the
|> next data packet.
|
| Ok, I'm fine with that. But there will always be servers which ignore
| the option because they don't understand it. In that case, obviously,
| they can't send it in the next packet.

Please walk through this again. AFAIK, "client" refers to the initiator
of the first connection. Let's use that convention here:

client sets socket option before connect
		server sets socket option after listen, before accept?
		(again, this is a problem; the socket of the connection
		exists only after the accept returns; before that, the
		'socket' applies to *any* connection that would return
		a subsequent listen call)

1.	SYN->
2.		<- SYN/ACK
3.	ACK->
4.	data->
5.		<- data

The option you're talking is useful, AFAICT, only in #2 (the SYN/ACK).

I'm proposing that the data that the server sends in the socket option
be considered equivalent to a WRITE on the socket - which would
otherwise have been possible only after the ACCEPT call. I.e.:

	- if the SYN (#1) has the option, then the socket option
	data commences in the SYN/ACK (#2) [it could spill over into
	later data segments #5 (or even between steps 3 and 4)]

	- if the SYN (#1) lacks the option, then the socket option
	data commences in the data segments #5 (or between steps
	3 and 4)

At that point, there is no real need for an option. The server can
ALWAYS send the data in the SYN/ACK, and just resend it if the ACK (#3)
is just for the SYN (in the SYN/ACK #2).

Isn't it a *lot* simpler to avoid an option and just send the data anyway?

Joe
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkikl10ACgkQE5f5cImnZrtgKgCgkhBNp2K7PsklAYLRKhv2ljJN
t3EAn1Ehv8SJTJc4QN6AHGwRZJQEpvWN
=/GhB
-----END PGP SIGNATURE-----
_______________________________________________
tcpm mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/tcpm