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

"Adam Langley" <agl@imperialviolet.org> Thu, 31 July 2008 23:39 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 502683A6D56; Thu, 31 Jul 2008 16:39:55 -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 2B2D03A6D31 for <tcpm@core3.amsl.com>; Thu, 31 Jul 2008 16:39:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level:
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[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 emWCHeP1WuyW for <tcpm@core3.amsl.com>; Thu, 31 Jul 2008 16:39:53 -0700 (PDT)
Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.232]) by core3.amsl.com (Postfix) with ESMTP id 44A673A6B45 for <tcpm@ietf.org>; Thu, 31 Jul 2008 16:39:53 -0700 (PDT)
Received: by rv-out-0506.google.com with SMTP id b25so702071rvf.49 for <tcpm@ietf.org>; Thu, 31 Jul 2008 16:40:08 -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=XF6Z4c9SZjLpvVrsvvZcQQVoRHLoL13d+ZGJtIOIErQ=; b=wrDzT64AGueZYppJNp2u2rRegWQ3kKv600MCQygLVFLKFTTpmDNEhO5bQDksc8jNIB tdwKFaINQZYkt09KkOrWlbpguq+MjP//ZEhZsT3IOL8ZVrgm8Zg7cmkrBsthls0/dnmh SfIKVTzEV+dT3WaEpXzcEXcs1TzHn+i38Dv8M=
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=XM3KEkNTJfPa5CF7HJ0x3tAN5mNhCfu+h68Wl6J1tV3uiXOpWHo5uW2ndCHe87D+pp 1sZlduCs2gIME386QFgTgLqxXTieKASEnnAMt6rOCm0cUnp8QYrtCR+1Z1v8KgGrY5gh yWAWRQ0w3McyDKdiKwzHgAW3SyL0YL9hGZnno=
Received: by 10.141.1.2 with SMTP id d2mr5602884rvi.129.1217547608673; Thu, 31 Jul 2008 16:40:08 -0700 (PDT)
Received: by 10.141.186.3 with HTTP; Thu, 31 Jul 2008 16:40:08 -0700 (PDT)
Message-ID: <396556a20807311640w2b17d447ud0c51241dc84f682@mail.gmail.com>
Date: Thu, 31 Jul 2008 16:40:08 -0700
From: "Adam Langley" <agl@imperialviolet.org>
To: "Joe Touch" <touch@isi.edu>
In-Reply-To: <48924496.9060907@isi.edu>
MIME-Version: 1.0
Content-Disposition: inline
References: <396556a20807311252j67b1ab26mf6511dbdae780fdd@mail.gmail.com> <48924496.9060907@isi.edu>
X-Google-Sender-Auth: 0021b91a58543ee7
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 Thu, Jul 31, 2008 at 4:02 PM, Joe Touch <touch@isi.edu> wrote:
> - - TCP is already permitted to send data in the SYN-ACK
>        prohibiting it when the SA-PP option is missing violates
>        RFC1122 sec 4.2.2.5 -- unknown options are silently ignored
>
>        options that change TCP need to be explicitly acknowledged,
>        and current (legacy) behavior should be assumed if not
>        acknowledged

Ah, I didn't know this. Thank you!

I don't believe changing TCP to disallow this is a good idea. However,
it's important that userland knows weather this experiment is in
effect. Thus, I believe that I should echo the SA-PP option in the
SYNACK. Also, it should probably change names: SYN/ACK Payloads
Processed or some similar.

> - - The rule "For a given SYN, if any resulting SYNACK frame has a payload
> then all resulting frames MUST have a payload" appears to disable
> persists and ACKs as would be needed for proper operation when data is
> not available in one or more direction

That's badly worded on my part. It should read:
"For a given SYN, if any resulting SYNACK frame has a payload then all
resulting SYNACK frames MUST have a payload"

(i.e. the restriction only apply to SYNACK frames. It's just so a host
cannot decide the retransmit a different SYNACK)

> - - AFAICT, it isn't sensible to retransmit a SYN with the same ISN, port,
> etc. and different options. Since you do not explicitly acknowledge the
> option, how do you know which SYN is being ACKd - the presence of SA
> data isn't sufficient (e.g., legacy TCPs could do this)

As you note, as another consequence of my misunderstanding, the
presence of SA data isn't sufficient to tell which SYN is getting
acked. Echoing the option should also solve this issue.

> - - the diagrams need to include some corner cases:
>        - when KX is larger than the PMTU in fig 3 (or NList is
>        larger than the PMTU in fig 2)
>        (i.e., it seems like there is a missing MUST NOT on the length)

It's suggested that the payload be limited to 64-bytes to prevent
amplification backscatter from a SYN flood. Thus these bytestrings
have to fit within the MTU. If an implementation doesn't enforce this,
then it has to drop support when replying on a link where the MTU is
insufficient.

>        - how do you handle simultaneous opens?

I believe that simultaneous opens work just fine, although both sides
will believe that the other doesn't support this experiment since the
option won't be echoed in the SYN.

> - - can you explain why you use a bit-field for the TCP option flag,
> rather than just using a 2-byte option? (i.e., KIND, length)

My hope was that by defining a flags option like this, future options
that require only to signal their presence in a SYN could save space.
If SACK permitted has been defined this way, for example, then this
draft wouldn't need to take any more space.

However, this is very subjective. If people would prefer not to do
this, or would prefer to break it out into its own draft, I'm
perfectly happy with that.


Thanks!

AGL

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