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

"Adam Langley" <agl@imperialviolet.org> Tue, 05 August 2008 18:27 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 9ABDA3A6856; Tue, 5 Aug 2008 11:27:27 -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 4607D28C30C for <tcpm@core3.amsl.com>; Tue, 5 Aug 2008 11:27:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.609
X-Spam-Level:
X-Spam-Status: No, score=-1.609 tagged_above=-999 required=5 tests=[AWL=0.368, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622]
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 BsYKl9UcyADo for <tcpm@core3.amsl.com>; Tue, 5 Aug 2008 11:27:25 -0700 (PDT)
Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.238]) by core3.amsl.com (Postfix) with ESMTP id 50C5E3A6774 for <tcpm@ietf.org>; Tue, 5 Aug 2008 11:27:25 -0700 (PDT)
Received: by rv-out-0506.google.com with SMTP id b25so2290397rvf.49 for <tcpm@ietf.org>; Tue, 05 Aug 2008 11:27:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=0l8tCgTNp1ysr6qLhIoqsm4mOjBOILixHpVrFNe+rNM=; b=K5DegxsYl6/V4UvKXnnssumJptEiBzToAsuCbVLEVC6TToJeGnMIT3JZnjJ80BToIj ol+UO87UT35lg1s+5vCg0NmPqHu9P0VbQ/04Y8nmKmN0QQLPLa7Y0+fmCsL0GwAJr0NO QOOpcVamUGlc06nA1gLgkCJ5YM4YGxHWFAfb8=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=EBfm9Jk7dJdodC/m5PxqBtFGT2XmHEkRyDUcswMvixeuMFdpkPoC5a13ieQhiqG+XZ TTYPxM1/C9lJ4MMtZprCEEcXSS/8yWGBH2DrU+jUJFW4pWGAgYeBl/eSuIlfhytJc11J dDqB32xzc7C3CpnRxeK4jgemsCi+wkoC4nJgw=
Received: by 10.140.191.14 with SMTP id o14mr8382693rvf.130.1217960875972; Tue, 05 Aug 2008 11:27:55 -0700 (PDT)
Received: by 10.141.37.3 with HTTP; Tue, 5 Aug 2008 11:27:55 -0700 (PDT)
Message-ID: <396556a20808051127m4c03dd9cr4bfa0209fdb059b2@mail.gmail.com>
Date: Tue, 05 Aug 2008 11:27:55 -0700
From: Adam Langley <agl@imperialviolet.org>
To: Joe Touch <touch@isi.edu>
In-Reply-To: <48974877.6050202@isi.edu>
MIME-Version: 1.0
Content-Disposition: inline
References: <396556a20807311252j67b1ab26mf6511dbdae780fdd@mail.gmail.com> <48924496.9060907@isi.edu> <396556a20807311640w2b17d447ud0c51241dc84f682@mail.gmail.com> <48935337.5060205@isi.edu> <396556a20808021200u75c3bdd5h77c328a9b61f8d78@mail.gmail.com> <4895B1F0.3070102@isi.edu> <396556a20808031106q18f6145cu7f6911ad8277d60c@mail.gmail.com> <48961F94.2040507@isi.edu> <396556a20808041025r42e640famf8ae9e07e5d3bca@mail.gmail.com> <48974877.6050202@isi.edu>
X-Google-Sender-Auth: d8032bae403148d3
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-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: tcpm-bounces@ietf.org
Errors-To: tcpm-bounces@ietf.org

On Mon, Aug 4, 2008 at 11:20 AM, Joe Touch <touch@isi.edu> wrote:
> | Imaging that we change the sockets interface such that applications
> | get a callback when a SYN frame is received on a listening socket.
> | Applications could inspect the SYN frame and choose to enqueue data to
> | be written. Hopefully the kernel would send some of that data in the
> | SYNACK, but that's unimportant here.
>
> Why wouldn't the application just enqueue the data? Why does it need to
> know that the other end supports this?

It doesn't always. SMTP, IRC and SSH protocols, for example, all
include a banner from the server to the client. In this case, the data
can be unconditionally enqueued for transmission. It's for protocols
which don't already start with a server->client transmission, and for
which we wish to add one, that the client must signal that we're
changing the application level protocol for this connection.

> 150ms is large when considered in the context of a small number of RTTs,
> but in the context of a connection that lasts 10 RTTs, it's 10%; the
> impact drops as you keep the connection going.
>
> I.e., a reduction of a single RTT is important only when the total
> exchange lasts 2-3 RTTs. That's 8KB-16KB of data - and it matters only
> for the first chunk of data in a persistent connection. For web pages
> with dozens of embedded components (in specific, more than 4, which is
> the typical limit for simultaneous connections), again this seems very
> much in the noise...

Many Google users are now using search bars to submit queries. Thus
they type into a text field in the browser, hit enter and the browser
makes a connection, sends the query encoded in a GET and displays the
result. This is one example of a situation where the connection
latency isn't amortised. There are many others, but obviously, this is
the example that usually dominates my thinking. And, in this
situation, it turns out that every 10ms makes a difference.

I might be wrong here. This might be an overcomplex solution. But I
think only time will tell, which is why I wish to have it published as
an experimental spec. If, in a couple of years, it doesn't work the
option number can be released, ready for the next guy.


Cheers,

AGL

-- 
Adam Langley agl@imperialviolet.org http://www.imperialviolet.org
_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm