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

"Adam Langley" <agl@imperialviolet.org> Wed, 16 July 2008 16:36 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 DE0EE3A690F; Wed, 16 Jul 2008 09:36:16 -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 670A23A690F for <tcpm@core3.amsl.com>; Wed, 16 Jul 2008 09:36:15 -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 PdsOMzIEKFk6 for <tcpm@core3.amsl.com>; Wed, 16 Jul 2008 09:36:14 -0700 (PDT)
Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.28]) by core3.amsl.com (Postfix) with ESMTP id 6DBC13A6806 for <tcpm@ietf.org>; Wed, 16 Jul 2008 09:36:14 -0700 (PDT)
Received: by yx-out-2324.google.com with SMTP id 8so1581146yxg.49 for <tcpm@ietf.org>; Wed, 16 Jul 2008 09:36:41 -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=IE07fj3NrpZr3HiW7pDwNPCkd7Yt2exrA4ZP4KhWNb0=; b=HljEit45jGt5qN7Jp8qZ2K5Tts+qgZXB+PtlduQ7rJ0hA6I/PR2nMXvbN5Mm493V1U b2Wl6sDlAnGi7SpPb5zr/hlJX8YomS9ZQd5X9kLe3Z6hrOPyH77gm+o9qVjWL2rC4tWi jRYRx0Jk5ely5vjpkc6IMLmo/yI77t3Xs/LRA=
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=qjgG+a2d9BXZDYU2LVWh1AezlDX28kAFTuN5zh04vFawpncVMmv2jKZsL/d4C/oOh6 JhIQYgupAYXSCBuBzveCCtbeFrXHsLQCxC9tQsmQnD+EoCyrryZzPE8aYBKHcCNTDzsv 0uqFAcYt+WFP9Mi4kwZEbsqAL4kNIlIHBuk54=
Received: by 10.141.162.6 with SMTP id p6mr314413rvo.121.1216226201365; Wed, 16 Jul 2008 09:36:41 -0700 (PDT)
Received: by 10.141.186.3 with HTTP; Wed, 16 Jul 2008 09:36:41 -0700 (PDT)
Message-ID: <396556a20807160936u5839080eh26d904fa27e0c07b@mail.gmail.com>
Date: Wed, 16 Jul 2008 09:36:41 -0700
From: "Adam Langley" <agl@imperialviolet.org>
To: "Michael Scharf" <michael.scharf@ikr.uni-stuttgart.de>
In-Reply-To: <20080716065344.GA4443@ikr.uni-stuttgart.de>
MIME-Version: 1.0
Content-Disposition: inline
References: <396556a20807151111u778faed3wb5a533e90c00b8c1@mail.gmail.com> <7E78ADB4-804B-4C57-824E-04E11B484E94@surrey.ac.uk> <396556a20807151129m50cc0ad6u44cd9599b7e51ac1@mail.gmail.com> <487D0E0D.3030408@isi.edu> <396556a20807151415i7e6b0d4bu6984617a095b07db@mail.gmail.com> <20080716065344.GA4443@ikr.uni-stuttgart.de>
X-Google-Sender-Auth: 5c8dac161a7ef2f9
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 Tue, Jul 15, 2008 at 11:53 PM, Michael Scharf
<michael.scharf@ikr.uni-stuttgart.de> wrote:
> sorry for asking once again "stupid" questions: Wouldn't it be a
> simple solution if the server just sent the data in a normal packet
> immediately after the SYN/ACK?

That's a very interesting idea; I hadn't considered it.

The pros would be that one could imagine that the active open host
wouldn't need any changes to support it. Let's consider what could go
wrong:

Packet loss: shouldn't be an issue. If the SYNACK is lost, the packet
with a payload would, at worst, get ignored. Possibly some stacks
would enqueue it.
Reordering: again, should be fine. Since the data packet is affecting
the sequence numbers it would get retransmitted if it was dropped
because it arrived early.

However, application level protocols probably need to change in order
to take advantage of early passive-open data transmission. Either
because they weren't designed with that in mind or because they need
to be a lot more frugal with their bits to fit within the 64-byte
limit. So the option in the SYN would still be needed, and that means
there's an issue of consistency. Both sides need to know if early-data
is in play because it affects the application level. Consider

AO: active open host
PO: passive open host

1. AO: A SYN is sent with SYNPACK Payload Permitted
2. PO: A SYNACK reply is sent and a data packet is sent
3. AO: A timeout occurs and the SYN is retransmitted without the
permitted bit. Although I don't think middleware dropping the unknown
option is going to be too much of a problem (see citations in the
draft), it's good if hosts have the option of doing this
4. AO: The SYNACK packet (from step 2) arrives. ACK is sent
5. AO: The data packet (from step 2) arrives and is enqueued.
5. PO: The second SYN causes another SYNACK (which will be ignored by AO)
6: PO: The ACK arrives

Now, neither side believe that an extra data packet was in play (AO
because it timed out and transmitted without the permitted bit in 3
and PO because it got a SYN without the bit in 5). However, the data
reaches the application level.

This means that we have to mark the data packet in some way (probably
an option) so that AO can drop it at step 5. Alternatively we could
require that, if the AO host wishes to back off from sending the
permitted bit, it has to start a whole new connection.

Another con would be the, minor, additional SYN flood problems - a SYN
can now elicit two packets and an additional 30 (or so) bytes from a
host.

So I think the balance comes out against, but it was very much worth
the consideration.

Thanks

AGL


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