Re: [tcpm] Faster application handshakes with SYN/ACK payloads
Joe Touch <touch@ISI.EDU> Sun, 03 August 2008 13:26 UTC
Return-Path: <tcpm-bounces@ietf.org>
X-Original-To: tcpm-archive@megatron.ietf.org
Delivered-To: ietfarch-tcpm-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 623AF3A6A71; Sun, 3 Aug 2008 06:26:35 -0700 (PDT)
X-Original-To: tcpm@core3.amsl.com
Delivered-To: tcpm@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B2E533A6A71 for <tcpm@core3.amsl.com>; Sun, 3 Aug 2008 06:26:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.389
X-Spam-Level: *
X-Spam-Status: No, score=1.389 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FRT_STOCK2=3.988]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nRFYjW-1dxG7 for <tcpm@core3.amsl.com>; Sun, 3 Aug 2008 06:26:32 -0700 (PDT)
Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id BDCE03A63D3 for <tcpm@ietf.org>; Sun, 3 Aug 2008 06:26:32 -0700 (PDT)
Received: from [192.168.2.121] (bolongo.jbtelenet.com [204.11.152.116]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id m73DQk0L006469 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 3 Aug 2008 06:26:49 -0700 (PDT)
Message-ID: <4895B1F0.3070102@isi.edu>
Date: Sun, 03 Aug 2008 06:26:08 -0700
From: Joe Touch <touch@ISI.EDU>
User-Agent: Thunderbird 2.0.0.16 (Windows/20080708)
MIME-Version: 1.0
To: Adam Langley <agl@imperialviolet.org>
References: <396556a20807311252j67b1ab26mf6511dbdae780fdd@mail.gmail.com> <48924496.9060907@isi.edu> <396556a20807311640w2b17d447ud0c51241dc84f682@mail.gmail.com> <48935337.5060205@isi.edu> <396556a20808021200u75c3bdd5h77c328a9b61f8d78@mail.gmail.com>
In-Reply-To: <396556a20808021200u75c3bdd5h77c328a9b61f8d78@mail.gmail.com>
X-Enigmail-Version: 0.95.6
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Cc: tcpm@ietf.org
Subject: Re: [tcpm] Faster application handshakes with SYN/ACK payloads
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/tcpm>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: tcpm-bounces@ietf.org
Errors-To: tcpm-bounces@ietf.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Adam, Again, popping up a level, you've made a good case for a socket option that lets the server app signal its TCP to try to send data in the SYNACK. TCPs that do this will; TCPs that don't will fail on the socket option, and the server will know. I am unclear why the client TCP is involved in this; if the data is sent, it will either be acknowledged or retransmitted. There is no change to the semantics, and only a change to timing (which NOTHING in TCP ensures anyway). As a minor note, it doesn't seem useful to extend that socket option to say how much data to put in the SYNACK; nothing else in TCP knows about application data boundaries, and I think it would be a mistake to assume that. You might add something like: setsockopt(SEND_SA_DATA, bytecount) where: bytecount = number of data bytes the app is *suggesting* the SA include; this is NOT guaranteed to be enforced by TCP if the sockopt succeeds, the app should reasonably assume that bytecount bytes are sent in the SYNACK if available when the SYNACK is sent As a final question (I'm not a sockets expert), it might be that there are other socket modifications to allow users to write to connections that are not yet open (or can they just be queued up? in which case, it seems like the socket must be completely bound, i.e., this might not work for unbound LISTENs). Specific notes below... Joe Adam Langley wrote: ... | Thanks for your detailed response, I fear that there's a | misunderstanding somewhere and that's almost certainly the fault of my | inadequate writeups. Please let me try again: | | At the moment, almost no stacks will send payloads in the SYNACK even | though they could as an optimisation. This springs from a few reasons: | R1) Processing time for a SYN must be minimal to mitigate the | effects of SYN floods. Even waking up an application to process a SYN | would greatly increase the costs. | R2) Replies to SYNs must be small, otherwise it provides a way to | amplify a DDoS attacks using false source IP addresses. | R3) The ubiquitous sockets API doesn't make it easy to do so. This sounds like a really good reason to extend the API to have a flag that allows the server app to ask its TCP to send data in the SYN-ACK if possible. That sounds consistent with the overall TCP model, AFAICT. I see no good way to have the application tell TCP how many bytes to send, or to have TCP tell the app this. That is an API change that lets the app know about segment boundaries, and that's inconsistent with TCP's API semantics. | I'm proposing that a constant payload (optionally with 8 random bytes) | overcomes R1 and R3. And limiting the size of that payload to 64 bytes | overcomes R2. I don't understand the "8 random bytes" issue; the data path should be sending data from the app only, and that's not random. | There are protocols that could immediately benefit from a gradual | deployment of hosts which supported a setsockopt to set a constant | payload and hosts that would ACK and enqueue such a payload. The sockopt sounds OK - but I'm not too sure about knowing the payload boundaries at the app layer. Again, that is inconsistent with TCP presenting a stream model. ~ > Additionally, this would also be easy to deploy. For clients that | don't support it, they will ACK only the SYN flag and then the server | knows to include the payload again in the next frame. Sure. | However, the sockets API has guided the design of many application | level protocols. Because of this, these protocols are often designed | such that | * The client starts the exchange: see HTTP | * The exchange is large, since there's little space pressure: SSH | algorithm agreement uses strings like "diffie-hellman-group14-sha1" | (28 bytes) because of this. Sure. | Modifications to take advantage of SYNACK payloads would then require | changes to the application level protocol. This could be managed by | assigning new ports, trying connections on the new ports first, | backing off etc. However, given that this is a partly a latency | optimisation, that's an anathema. I don't see this at all. Apps don't need any modification, other than to set the "send data early in the SYNACK" flag. That can be set by default on a per-port basis, or set within the app directly. | So I additionally define an option that the application layer can set | and query that advertises support for this trick and allows many more | application level protocols to take advantage of it. ***this is the big question*** Why do you need an option that does this? Seems like the app can always TRY to do it, and the data just gets retransmitted if dropped (i.e., not supported at the receiver). |> (side note) Such an option might be useful, but might also be an issue. |> It tests the fact that TCPs ignore unknown options, a test that might |> fail. It also tests the fact that middleboxes should pass options |> unmodified, which also might fail. | | Because of this, I wanted to make sure that clients were free to retry | a connection without the option in the case that something was | reacting badly to it. Wouldn't it be simpler to do this without an option at all, then? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkiVsfAACgkQE5f5cImnZrvA8gCcD2lJafEkZH4Ue5prXgQAWySv FtsAoPIfNXaZzYqLZCNFlOml85FTi52+ =5dMt -----END PGP SIGNATURE----- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm
- [tcpm] Faster application handshakes with SYN/ACK… Adam Langley
- Re: [tcpm] Faster application handshakes with SYN… Lloyd Wood
- Re: [tcpm] Faster application handshakes with SYN… Adam Langley
- Re: [tcpm] Faster application handshakes with SYN… Joe Touch
- Re: [tcpm] Faster application handshakes with SYN… Adam Langley
- Re: [tcpm] Faster application handshakes with SYN… Adam Langley
- Re: [tcpm] Faster application handshakes with SYN… Michael Scharf
- Re: [tcpm] Faster application handshakes with SYN… Adam Langley
- [tcpm] Faster application handshakes with SYN/ACK… Adam Langley
- Re: [tcpm] Faster application handshakes with SYN… Murali Bashyam
- Re: [tcpm] Faster application handshakes with SYN… Adam Langley
- Re: [tcpm] Faster application handshakes with SYN… Joe Touch
- Re: [tcpm] Faster application handshakes with SYN… Joe Touch
- Re: [tcpm] Faster application handshakes with SYN… Joe Touch
- Re: [tcpm] Faster application handshakes with SYN… Adam Langley
- Re: [tcpm] Faster application handshakes with SYN… Adam Langley
- Re: [tcpm] Faster application handshakes with SYN… Matt Mathis
- Re: [tcpm] Faster application handshakes with SYN… Adam Langley
- Re: [tcpm] Faster application handshakes with SYN… Joe Touch
- Re: [tcpm] Faster application handshakes with SYN… Adam Langley
- Re: [tcpm] Faster application handshakes with SYN… Joe Touch
- Re: [tcpm] Faster application handshakes with SYN… Adam Langley
- Re: [tcpm] Faster application handshakes with SYN… Joe Touch
- Re: [tcpm] Faster application handshakes with SYN… Anantha Ramaiah (ananth)
- Re: [tcpm] Faster application handshakes with SYN… Adam Langley
- Re: [tcpm] Faster application handshakes with SYN… Adam Langley
- Re: [tcpm] Faster application handshakes with SYN… Joe Touch
- Re: [tcpm] Faster application handshakes with SYN… Adam Langley
- Re: [tcpm] Faster application handshakes with SYN… Joe Touch
- Re: [tcpm] Faster application handshakes with SYN… Adam Langley
- Re: [tcpm] Faster application handshakes with SYN… Adam Langley
- Re: [tcpm] Faster application handshakes with SYN… Joe Touch
- Re: [tcpm] Faster application handshakes with SYN… Stefanos Harhalakis
- Re: [tcpm] Faster application handshakes with SYN… Joe Touch
- Re: [tcpm] Faster application handshakes with SYN… Stefanos Harhalakis
- Re: [tcpm] Faster application handshakes with SYN… Adam Langley
- Re: [tcpm] Faster application handshakes with SYN… Joe Touch
- Re: [tcpm] Faster application handshakes with SYN… Stefanos Harhalakis
- Re: [tcpm] Faster application handshakes with SYN… Stefanos Harhalakis
- Re: [tcpm] Faster application handshakes with SYN… Joe Touch