[tcpm] SYN/ACK Payloads, draft 01

"Adam Langley" <agl@imperialviolet.org> Mon, 11 August 2008 17:35 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 [] (localhost []) by core3.amsl.com (Postfix) with ESMTP id B72FC3A6C62; Mon, 11 Aug 2008 10:35:42 -0700 (PDT)
X-Original-To: tcpm@core3.amsl.com
Delivered-To: tcpm@core3.amsl.com
Received: from localhost (localhost []) by core3.amsl.com (Postfix) with ESMTP id 8F5AA3A6C62 for <tcpm@core3.amsl.com>; Mon, 11 Aug 2008 10:35:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.623
X-Spam-Status: No, score=0.623 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_50=0.001, FM_FORGED_GMAIL=0.622]
Received: from mail.ietf.org ([]) by localhost (core3.amsl.com []) (amavisd-new, port 10024) with ESMTP id oXmrdXRBpQlJ for <tcpm@core3.amsl.com>; Mon, 11 Aug 2008 10:35:40 -0700 (PDT)
Received: from rv-out-0506.google.com (rv-out-0506.google.com []) by core3.amsl.com (Postfix) with ESMTP id 85ED13A6D0B for <tcpm@ietf.org>; Mon, 11 Aug 2008 10:35:40 -0700 (PDT)
Received: by rv-out-0506.google.com with SMTP id b25so1945306rvf.49 for <tcpm@ietf.org>; Mon, 11 Aug 2008 10:35:20 -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:mime-version:content-type:content-transfer-encoding :content-disposition:x-google-sender-auth; bh=eacL9mf8bf3jfLZtWvybowp2cn98Q4XTmEndmSLcsnQ=; b=pT/1eljFHQHgai619tJNm69+u5mOy9fHPNn1eqAuRo8QK2Fp3+NG+lTtWv6Pim4yyu fYNpld4lbccmKLV35bRqMQC0VzaVqqgIHycEIOwdtGLdqZqNm+kdjk5a7427JPocZqBx gOoJ2JE2WsYAi+qpuRRzGSuMbrgZ12hf2nLrM=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:mime-version:content-type :content-transfer-encoding:content-disposition:x-google-sender-auth; b=t4QjpTnKm2rliIVZZU29SANK+DCg6MFYTtiaqzH2lJnoUVSQ0IOsZiMoM9qtfEjYIB 9w2veTs7DhTYAub3HreLpkSlqXhQT0K2+GIK5S6GDQFRtYQDfYA7tKThKxImid/Ddu/V yO92isf0y2C77Gq+NmOuCWeBJKpqFT4v9yrbo=
Received: by with SMTP id a7mr3676975rvj.58.1218476120878; Mon, 11 Aug 2008 10:35:20 -0700 (PDT)
Received: by with HTTP; Mon, 11 Aug 2008 10:35:20 -0700 (PDT)
Message-ID: <396556a20808111035s2b974233o1e9d3671e82e3350@mail.gmail.com>
Date: Mon, 11 Aug 2008 10:35:20 -0700
From: Adam Langley <agl@imperialviolet.org>
To: tcpm@ietf.org
MIME-Version: 1.0
Content-Disposition: inline
X-Google-Sender-Auth: 170cee7f43e382f8
Subject: [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-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: tcpm-bounces@ietf.org
Errors-To: tcpm-bounces@ietf.org

The comments on SYNACK Payloads[1] seem to have died down, so I'd like
to see how people are feeling about it.

Just to be clear; I'm seeking to publish this as experimental in order
to get an option number assigned to conduct more widespread tests.

I thought that I would dig out a couple of the points that I believe
Joe Touch was still unsure about after the last thread. I don't wish
to misrepresent anyone, but it is a long thread to dig through: thanks
to Joe for being so generous with his time in giving feedback.

> I appreciate the
> idea of optimizing TCP, but there are so many other places where RTTs
> are not under your control, and so many RTTs in a connection, that
> removing (or adding) a single one anywhere seems 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.

> Using a transport signal to change the application protocol seems
> very strange to me. Other's can comment on that.

It is strange, I agree. My usual test about such things is if I get an
"ick" reaction and, in this case, I don't. Although, that might just
be me.

Two reasonable questions arise:

"Where will this stop?"  - obviously, the TCP option space shouldn't
be a repository for application data. In this case, at least, the
option is advertising a certain minimum capability of the TCP stack,
as defined in the draft. Also, I'll claim that this is the last such
need in this area:

The SYNACK payload sizes is a decision for the server (within the
advertised window). No more client options could be needed to
advertise support for larger ones.

Since the SYNACK payload is (nearly) constant, and TCP stacks are not
going to differ sufficiently to change this in the next 20 years,
applications don't gain anything else by stuffing anything more in the
SYN option space.

So I don't think this sets an unreasonable precedent.

Thanks all,

[1] http://www.ietf.org/internet-drafts/draft-agl-tcpm-sadata-01.txt


Adam Langley agl@imperialviolet.org http://www.imperialviolet.org
tcpm mailing list