Re: [tcpm] SYN/ACK Payloads, draft 01

"Adam Langley" <agl@imperialviolet.org> Thu, 14 August 2008 20:03 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 312E03A6878; Thu, 14 Aug 2008 13:03:58 -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 337503A686D for <tcpm@core3.amsl.com>; Thu, 14 Aug 2008 13:03:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.506
X-Spam-Level:
X-Spam-Status: No, score=-1.506 tagged_above=-999 required=5 tests=[AWL=0.471, 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 Krpg3wXqNxIf for <tcpm@core3.amsl.com>; Thu, 14 Aug 2008 13:03:55 -0700 (PDT)
Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.230]) by core3.amsl.com (Postfix) with ESMTP id 1EDEC3A6878 for <tcpm@ietf.org>; Thu, 14 Aug 2008 13:03:51 -0700 (PDT)
Received: by rv-out-0506.google.com with SMTP id b25so508230rvf.49 for <tcpm@ietf.org>; Thu, 14 Aug 2008 13:03:29 -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=coeOcVVxbL+1aGVZxjf33xkZGoi/28rptCZm+Xxaeac=; b=A2KB3/BDrCo6pBnjtaekdIO2mEVVrLZdKcHguJytKBpZmMayfroY1rpkn4ADbEXlGa hit4Xdy4HUYQlGICRsHtsjAUCwu1hK2ASQkW5GOYzkIGEJEhMr1hESKjOtBsfjKEwl12 OA/HS80WWcIT3zPvVPfZVBKzthEtBbkxXAjLc=
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=oHiJ1rvE84MZ3eMbO916srzkfoWYSsqnJx6ghmUbl0FPHmYjsjtPZi7P603EehqExm cx2eaq0zqb9RDOZT/vrrW3AsY/+K+gtV44JIBcfFdx912LV2dXYqMCCu/YgPFBMCxCcB 3uhnIKuSB1A+CtTy7QBm1YY+0KssJhe7YDhGQ=
Received: by 10.141.33.21 with SMTP id l21mr995215rvj.9.1218744208927; Thu, 14 Aug 2008 13:03:28 -0700 (PDT)
Received: by 10.141.37.3 with HTTP; Thu, 14 Aug 2008 13:03:28 -0700 (PDT)
Message-ID: <396556a20808141303k341599wfeef32d0841e9f76@mail.gmail.com>
Date: Thu, 14 Aug 2008 13:03:28 -0700
From: "Adam Langley" <agl@imperialviolet.org>
To: "Joe Touch" <touch@isi.edu>
In-Reply-To: <48A46BD3.4030408@isi.edu>
MIME-Version: 1.0
Content-Disposition: inline
References: <396556a20808111035s2b974233o1e9d3671e82e3350@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> <48A465CC.8000402@isi.edu> <396556a20808141023s3abddc96u43b9e6e7898033ed@mail.gmail.com> <48A46BD3.4030408@isi.edu>
X-Google-Sender-Auth: 8453fde795b91652
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-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: tcpm-bounces@ietf.org
Errors-To: tcpm-bounces@ietf.org

On Thu, Aug 14, 2008 at 10:30 AM, Joe Touch <touch@isi.edu> wrote:
> OK. So why bother with an option at that point? Why does the user data
> need to be different if the option is present?
>
> If the user data were not different, then this all boils down to a
> change in the implementation of the API. The trouble is that you're
> expecting a TCP option to change the *content* of the data stream, and
> that seems bizarre to me.

Because for server-speaks-first application protocols there's no
problem. This is just for client-speaks-first protocols. For these
protocols, had common stacks been able to send data in the SYN/ACK
when they were being designed, then they might have ended up as
server-speaks-first protocols. But they didn't for latency reasons.

In order for them to take advantage of this they need to be able to
signal their compliance somehow. There is, indeed, a cleanliness
argument against such a option, but I'm arguing that it's worthwhile
for backward compatibility reasons.

> This is a big change - you're saying that if the payload fits, it goes
> in the SYN-ACK. If not, *none* of it is sent in the SYN-ACK? Why?

I'm saying that implementations have latitude here. If the passive
open end wishes to ignore the client's option it may. Equally, it may
echo it, but not include the data in the SYNACK if the MTU makes it
troublesome. In that case, it needs to send it in the next packet as
normal. Since the implementation has the best knowledge of what's
best, I didn't see any reason to constrain it.


AGL

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