Re: [tcpm] Faster application handshakes with SYN/ACK payloads

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

Hi, Adam (et al.),

I looked this over, and had a clarification:

Data could *always* come in the SYN/ACK (i.e., in a SYN), but often it's
just ignored. So this option is just a hint to the server that the
client won't ignore that data. It doesn't change any rules about data
delivery; once the SYN/ACK arrives, the client can send that data up to
the user as per conventional rules, AFAICT.

Adam Langley wrote:
| On Tue, Jul 15, 2008 at 11:22 AM, Lloyd Wood <L.Wood@surrey.ac.uk> wrote:
|> This looks awfully like reinventing transactional TCP to me - and
IIRC the
|> reason that never got widely adopted was the increased potential for DOS
|> attacks by tying up memory early on with a loaded SYN.

Transaction TCP allows a server to push data to the user that arrives in
the SYN without waiting for the client's final ACK; that doesn't appear
to be related to this.

I think the only catch is that this works only when there's a
unidirectional-initiated connection from client to server, and only
helps hint the server that the client will accept data in the SYN/ACK.
It doesn't help with simultaneous opens, e.g., since neither side can
send the data up until their SYN is ACK'd -- *that* is what T/TCP
changes, but this doesn't, again AFAICT.

I'm really not sure what buying a single RTT will do for TCP, though.
Very few exchanges that need reliable transfer of a single packet need
TCP, IMO.

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

iD8DBQFIfQ4NE5f5cImnZrsRAhXdAKC54DBHXzDHYMLhyoIebf1WuF5puACfcEnj
rl+lp9HBV6XIGjhfaBnu7YA=
=MHdC
-----END PGP SIGNATURE-----
_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm