[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 [127.0.0.1] (localhost [127.0.0.1]) 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 [127.0.0.1]) 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-Level:
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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (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 [209.85.198.228]) 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 10.141.23.7 with SMTP id a7mr3676975rvj.58.1218476120878; Mon, 11 Aug 2008 10:35:20 -0700 (PDT)
Received: by 10.141.37.3 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 AGL -- Adam Langley agl@imperialviolet.org http://www.imperialviolet.org _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm
- Re: [tcpm] SYN/ACK Payloads, draft 01 Sergio Freire
- [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 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