Re: [tcpm] SYN/ACK Payloads, draft 01
Joe Touch <touch@ISI.EDU> Thu, 14 August 2008 17:06 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 B7E9E3A6C89; Thu, 14 Aug 2008 10:06:34 -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 DE4273A6C60 for <tcpm@core3.amsl.com>; Thu, 14 Aug 2008 10:06:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.392
X-Spam-Level:
X-Spam-Status: No, score=0.392 tagged_above=-999 required=5 tests=[AWL=-0.997, 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 f2Y5b2-MAzyZ for <tcpm@core3.amsl.com>; Thu, 14 Aug 2008 10:06:32 -0700 (PDT)
Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 190DB3A6B7F for <tcpm@ietf.org>; Thu, 14 Aug 2008 10:06:32 -0700 (PDT)
Received: from [75.214.2.40] (40.sub-75-214-2.myvzw.com [75.214.2.40]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id m7EH60kh006995 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 14 Aug 2008 10:06:02 -0700 (PDT)
Message-ID: <48A465CC.8000402@isi.edu>
Date: Thu, 14 Aug 2008 10:05:16 -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: <396556a20808111035s2b974233o1e9d3671e82e3350@mail.gmail.com> <20080813195027.C4C5B50848@romeo.rtfm.com> <396556a20808131307r65a9f6a0oe4365be029620b2c@mail.gmail.com> <48A35CFA.4060709@isi.edu> <396556a20808131525i20dabf06w7a7a11e3468e541a@mail.gmail.com> <48A36104.6000000@isi.edu> <396556a20808131605w2ccac3ceo21160401e4545c15@mail.gmail.com> <48A383F0.9030601@isi.edu> <396556a20808131827x1ab32b13yaa9358ac1a70c6ed@mail.gmail.com> <48A3C0B3.8050003@isi.edu> <396556a20808140940p63dec2d2ib3332b27da8260ae@mail.gmail.com>
In-Reply-To: <396556a20808140940p63dec2d2ib3332b27da8260ae@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] SYN/ACK Payloads, draft 01
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 Adam Langley wrote: | On Wed, Aug 13, 2008 at 10:20 PM, Joe Touch <touch@isi.edu> wrote: |> I'm confused now; your code - and your note. Let's go back to the key issue: |> |> - is the data received by the client dependent on the option? | | I do apologise, the confusion is my fault: | | There are two extensions interacting here. Firstly, there's an | extension to include data in the SYNACK. Then there's the application | layer signaling with the option. I was outlining the code for the | latter. The former is an extension that could be deployed today, it's | managed with a setsockopt on the server socket: | | struct tcpsa tcpsa; | memcpy(tcpsa.tcpsa_payload, mysynackdata, length); | setsockopt(socket, SOL_TCP, TCP_SADATA, &tcpsa, sizeof(tcpsa)); | | listen(socket); | | for (;;) { accept(); ... } | | Obviously, this is just an implementation detail. It's a lot more than that; it hints that the socket interface is insufficient for using the available TCP capability for sending data with either SYNs or SYN-ACKs. I'm wondering how/if this has been explored before, and whether there would be a solution that maps to TCP's model of a stream better. The socket option above is incorrect, IMO. It implies that the user should have control over data that ends up in the SYN-ACK directly; IMO, TCP's stream model should allow only that data be written to the stream early - which may require a socket option - BUT should *not* imply that the data maps to the SYN-ACK directly. E.g., what happens if the data is larger than the MSS? Or if the SYN-ACK comes back with an ICMP 'too-big'? I.e., this should be called just TCP_DATA, not TCP_SADATA. | It's nice for | sockets based APIs to do it like this. Since such stacks are dominant, | the idea of a constant payload appears in the draft. I make a couple | of exceptions to this. The ability to include a 64-bit nonce is very | useful and easy for the stack to manage. That's done with: | | struct tcpsa tcpsa; | memcpy(tcpsa.tcpsa_payload, mysynackdata, length); | tcpsa.tcpsa_flags = TCP_SADATA_INC_NONCE; | tcpsa.tcpsa_nonce_offset = 0; | setsockopt(socket, SOL_TCP, TCP_SADATA, &tcpsa, sizeof(tcpsa)); | | Also, the ability to only send this data when the SYN includes the | SAPP option. At the moment, this is the default, although there is | space in the flags set aside for when I get round to it. I do not understand the semantics of a TCP option that changes the TCP stream. TCP is a stream-oriented protocol, and each connection provides one stream. If you want a separate channel, you ought to be using a different protocol, e.g., SCTP. | Example client side code and stack patches are referenced below. | | Again, this is just to appease the sockets API. Stacks like [1] allow | the application to process the SYN directly and construct any SYNACK | payload they like on a per-packet basis. That's fine as an implementation decision, as Caitlin notes, but has no business affecting the TCP protocol spec. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkikZcsACgkQE5f5cImnZrso6ACgoHYVA1x+SiEZE+I/WIKPeBlL nekAoKTmhId3CpGqVk4cwaRjQ/7/AHjf =XmHR -----END PGP SIGNATURE----- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm
- [tcpm] SYN/ACK Payloads, draft 01 Adam Langley
- Re: [tcpm] SYN/ACK Payloads, draft 01 Sergio Freire
- Re: [tcpm] SYN/ACK Payloads, draft 01 Adam Langley
- Re: [tcpm] SYN/ACK Payloads, draft 01 Sergio Freire
- Re: [tcpm] SYN/ACK Payloads, draft 01 Lars Eggert
- Re: [tcpm] SYN/ACK Payloads, draft 01 Sergio Freire
- Re: [tcpm] SYN/ACK Payloads, draft 01 Adam Langley
- Re: [tcpm] SYN/ACK Payloads, draft 01 Sergio Freire
- Re: [tcpm] SYN/ACK Payloads, draft 01 Adam Langley
- Re: [tcpm] SYN/ACK Payloads, draft 01 Sergio Freire
- Re: [tcpm] SYN/ACK Payloads, draft 01 Eric Rescorla
- Re: [tcpm] SYN/ACK Payloads, draft 01 Adam Langley
- Re: [tcpm] SYN/ACK Payloads, draft 01 Eric Rescorla
- Re: [tcpm] SYN/ACK Payloads, draft 01 Adam Langley
- Re: [tcpm] SYN/ACK Payloads, draft 01 Eric Rescorla
- Re: [tcpm] SYN/ACK Payloads, draft 01 Adam Langley
- Re: [tcpm] SYN/ACK Payloads, draft 01 Eric Rescorla
- Re: [tcpm] SYN/ACK Payloads, draft 01 Adam Langley
- Re: [tcpm] SYN/ACK Payloads, draft 01 Joe Touch
- Re: [tcpm] SYN/ACK Payloads, draft 01 Adam Langley
- Re: [tcpm] SYN/ACK Payloads, draft 01 Joe Touch
- Re: [tcpm] SYN/ACK Payloads, draft 01 Adam Langley
- Re: [tcpm] SYN/ACK Payloads, draft 01 Joe Touch
- Re: [tcpm] SYN/ACK Payloads, draft 01 Joe Touch
- Re: [tcpm] SYN/ACK Payloads, draft 01 Adam Langley
- Re: [tcpm] SYN/ACK Payloads, draft 01 Adam Langley
- Re: [tcpm] SYN/ACK Payloads, draft 01 Joe Touch
- Re: [tcpm] SYN/ACK Payloads, draft 01 Joe Touch
- Re: [tcpm] SYN/ACK Payloads, draft 01 Caitlin Bestler
- Re: [tcpm] SYN/ACK Payloads, draft 01 Adam Langley
- Re: [tcpm] SYN/ACK Payloads, draft 01 Joe Touch
- Re: [tcpm] SYN/ACK Payloads, draft 01 Adam Langley
- Re: [tcpm] SYN/ACK Payloads, draft 01 Joe Touch
- Re: [tcpm] SYN/ACK Payloads, draft 01 Adam Langley
- Re: [tcpm] SYN/ACK Payloads, draft 01 Adam Langley
- Re: [tcpm] SYN/ACK Payloads, draft 01 Joe Touch
- Re: [tcpm] SYN/ACK Payloads, draft 01 Caitlin Bestler
- Re: [tcpm] SYN/ACK Payloads, draft 01 Adam Langley
- Re: [tcpm] SYN/ACK Payloads, draft 01 Joe Touch
- Re: [tcpm] SYN/ACK Payloads, draft 01 Adam Langley
- Re: [tcpm] SYN/ACK Payloads, draft 01 Joe Touch
- Re: [tcpm] SYN/ACK Payloads, draft 01 Adam Langley
- Re: [tcpm] SYN/ACK Payloads, draft 01 Adam Langley
- Re: [tcpm] SYN/ACK Payloads, draft 01 Joe Touch
- Re: [tcpm] SYN/ACK Payloads, draft 01 Adam Langley
- Re: [tcpm] SYN/ACK Payloads, draft 01 Michael Tüxen
- Re: [tcpm] SYN/ACK Payloads, draft 01 Caitlin Bestler
- Re: [tcpm] SYN/ACK Payloads, draft 01 Adam Langley
- Re: [tcpm] SYN/ACK Payloads, draft 01 Eric Rescorla
- Re: [tcpm] SYN/ACK Payloads, draft 01 Michael Tüxen
- Re: [tcpm] SYN/ACK Payloads, draft 01 Adam Langley
- Re: [tcpm] SYN/ACK Payloads, draft 01 Joe Touch
- Re: [tcpm] SYN/ACK Payloads, draft 01 Joe Touch
- Re: [tcpm] SYN/ACK Payloads, draft 01 Caitlin Bestler
- Re: [tcpm] SYN/ACK Payloads, draft 01 Adam Langley
- Re: [tcpm] SYN/ACK Payloads, draft 01 Anantha Ramaiah (ananth)
- Re: [tcpm] SYN/ACK Payloads, draft 01 Joe Touch
- Re: [tcpm] SYN/ACK Payloads, draft 01 Joe Touch