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

Stefanos Harhalakis <v13@v13.gr> Sun, 21 September 2008 09:44 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 73F553A6966; Sun, 21 Sep 2008 02:44:26 -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 41E473A68B6 for <tcpm@core3.amsl.com>; Sun, 21 Sep 2008 02:44:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.305
X-Spam-Level:
X-Spam-Status: No, score=-0.305 tagged_above=-999 required=5 tests=[AWL=1.694, BAYES_00=-2.599, J_CHICKENPOX_34=0.6]
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 6xlEA4Wrwmsb for <tcpm@core3.amsl.com>; Sun, 21 Sep 2008 02:44:19 -0700 (PDT)
Received: from mx-out.forthnet.gr (mx-out.forthnet.gr [193.92.150.104]) by core3.amsl.com (Postfix) with ESMTP id F3C253A687C for <tcpm@ietf.org>; Sun, 21 Sep 2008 02:44:18 -0700 (PDT)
Received: from mx-av-05.forthnet.gr (mx-av.forthnet.gr [193.92.150.27]) by mx-out-05.forthnet.gr (8.14.3/8.14.3) with ESMTP id m8L9iYRw018039; Sun, 21 Sep 2008 12:44:34 +0300
Received: from MX-IN-05.forthnet.gr (mx-in-05.forthnet.gr [193.92.150.32]) by mx-av-05.forthnet.gr (8.14.3/8.14.3) with ESMTP id m8L9iYce021293; Sun, 21 Sep 2008 12:44:34 +0300
Received: from hell.hell.gr (adsl70-48.lsf.forthnet.gr [79.103.197.48]) by MX-IN-05.forthnet.gr (8.14.3/8.14.3) with ESMTP id m8L9iUex023988; Sun, 21 Sep 2008 12:44:31 +0300
Authentication-Results: MX-IN-05.forthnet.gr smtp.mail=v13@v13.gr; spf=neutral
Authentication-Results: MX-IN-05.forthnet.gr header.from=v13@v13.gr; sender-id=neutral
From: Stefanos Harhalakis <v13@v13.gr>
To: Joe Touch <touch@isi.edu>
Date: Sun, 21 Sep 2008 12:44:30 +0300
User-Agent: KMail/1.9.9
References: <396556a20807311252j67b1ab26mf6511dbdae780fdd@mail.gmail.com> <48D5E708.4000006@isi.edu> <48D5EBCF.7060401@isi.edu>
In-Reply-To: <48D5EBCF.7060401@isi.edu>
MIME-Version: 1.0
Content-Disposition: inline
Message-Id: <200809211244.30186.v13@v13.gr>
Cc: Adam Langley <agl@imperialviolet.org>, 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-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: tcpm-bounces@ietf.org
Errors-To: tcpm-bounces@ietf.org

On Sunday 21 September 2008, Joe Touch wrote:
> > Stefanos Harhalakis wrote:
> >> Add a generic 'user data' option for SYN fields that would carry user
> >> data.
>
> There are two reasons for doing this:
>
> 	1- to send an out-of-band signal
>
> 	2- to send a signal that the server acts on before the
> 	handshake completes
>
> #2 violates TCP semantics, so the SYN-ACK cannot have application data
> that depends on the SYN's user data option (which is the desired result
> here). The signal can't be acted on at the application layer until the
> handshake completes.
>
> #1 changes TCP semantics as well, since TCP does not have an out-of-band
> signal path, and this would add that. However, because it cannot be
> acted on until after the handshake completes, it cannot modify
> application behavior that isn't required to wait until the handshake
> finishes - i.e., apps that can write to the socket before the handshake
> completes (e.g., to write data available to a SYN-ACK) would never
> change because of this signal. The utility of this feature depends on
> application behavior, which cannot be known, and thus cannot be relied
> upon.

What I proposed is what you describe in #1. It is different from the 
SA-with-data proposal and thus it hasn't to do anything with #2. As I said in 
the original mail, it has to do with what Adam said:

"If HTTP sent a banner, like SMTP servers, then my life would be a lot
easier! The banner could advertise all the extensions supported.
However, without SYNACK payloads, this banner would cost another round
trip."

and more specifically with the first sentence. Supposing that (a hypothetical) 
HTTP/1.3 would support an optional banner, such an option would allow the 
server side to send it without braking backwards compatibility:

Client --> SYN+DATA --> Server
Client <-- SYNACK+? <-- Server
Client -->   ACK    --> Server
Client <--  BANNER  <-- Server

Without changing current behavior (It is not required that data be sent with 
the SYNACK option).

Also, this is not exactly "data" as there is space for a very small amount of 
information (some bits). Considering the possibilities of this, it can be 
used in many situations such as:
* HTTP or other protocols that use a well-known-port, to negotiate different
  behavior without introducing a new port number (SSL over port 80?).
* Cryptographic applications
* Anything that someone out there can think of. 8 bits (or a little more) of 
  information can be used for many things.

Wrong?

p.s: I can write a draft if this would clarify things.
_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm