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

"Adam Langley" <agl@imperialviolet.org> Thu, 14 August 2008 21:01 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 C9B8B3A68BD; Thu, 14 Aug 2008 14:01:03 -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 759133A68EB for <tcpm@core3.amsl.com>; Thu, 14 Aug 2008 14:01:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.429
X-Spam-Level:
X-Spam-Status: No, score=0.429 tagged_above=-999 required=5 tests=[AWL=-1.582, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, FRT_STOCK2=3.988]
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 XizEQSWUqm6C for <tcpm@core3.amsl.com>; Thu, 14 Aug 2008 14:01:01 -0700 (PDT)
Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.238]) by core3.amsl.com (Postfix) with ESMTP id 627253A68A0 for <tcpm@ietf.org>; Thu, 14 Aug 2008 14:01:01 -0700 (PDT)
Received: by rv-out-0506.google.com with SMTP id b25so528067rvf.49 for <tcpm@ietf.org>; Thu, 14 Aug 2008 14:01:05 -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=m01m94hv5WB1YuwPcHS/tY90xvPiN35kiBQW4KM/sPA=; b=VEciHx0SCNwaHmHLoRpEK84Yv9j52Wvv6B/yXjO7obl9KCvt6eyGb0pU4AIB9zWb/m uAeUICkmCAtunRovl6eRlqP+CQnSFl2lWThFYzoYpEyEUH2UgFh7Y6pUHKc2gwaRSMVE /9pDYXrAHdF7r+xKZLfT29Cig6L+2HHNBcD44=
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=KpiVNieNVPgpnzDAC6B/XKTSR9NqWQhqeR6xXZ13XmjhL3oy/Py81hYfm3fR08MmbB 88WUVqxC0lavf86gTuvN0Ux6vTQ2Dg5DDml41qnv+RNgdSOhfVNIl8XIu9ka8nL3m/uj U+WUDLGG4Pz+XSbbmSyfUOlNw5zmxEID1o5y8=
Received: by 10.141.137.6 with SMTP id p6mr1018582rvn.279.1218747665287; Thu, 14 Aug 2008 14:01:05 -0700 (PDT)
Received: by 10.141.37.3 with HTTP; Thu, 14 Aug 2008 14:01:05 -0700 (PDT)
Message-ID: <396556a20808141401of8ad149w5850e8dc552a9948@mail.gmail.com>
Date: Thu, 14 Aug 2008 14:01:05 -0700
From: "Adam Langley" <agl@imperialviolet.org>
To: "Joe Touch" <touch@isi.edu>
In-Reply-To: <48A4975D.3070303@isi.edu>
MIME-Version: 1.0
Content-Disposition: inline
References: <396556a20808111035s2b974233o1e9d3671e82e3350@mail.gmail.com> <48A3C0B3.8050003@isi.edu> <396556a20808140940p63dec2d2ib3332b27da8260ae@mail.gmail.com> <48A465CC.8000402@isi.edu> <396556a20808141023s3abddc96u43b9e6e7898033ed@mail.gmail.com> <48A46BD3.4030408@isi.edu> <396556a20808141303k341599wfeef32d0841e9f76@mail.gmail.com> <48A491B9.3000209@isi.edu> <396556a20808141325u1e67c93co595eadeb3341539@mail.gmail.com> <48A4975D.3070303@isi.edu>
X-Google-Sender-Auth: 390a47e1123c65c7
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 1:36 PM, Joe Touch <touch@isi.edu> wrote:
> Isn't it a *lot* simpler to avoid an option and just send the data anyway?

Yep! And I intend to patch Linux to support exactly this (no options
involved anywhere) at some point. To reuse an example, I could have an
SMTP server which writes "200 example.com ESMTP\r\n" this way and save
a round trip. (Although SMTP isn't too latency sensitive some busy
servers might be glad of it.)

But many application level protocols have been designed as
client-speaks-first, like HTTP. So, let's define HTTP-ssf (server
speaks first). HTTP-ssf is exactly the same as HTTP, except that the
client waits for a banner from the HTTP server before sending a banner
of it's own. We can use the same trick as the SMTP server to maybe fit
this banner in the SYNACK. If it doesn't fit, no loss, it can go in
later packets. If the client doesn't ACK all the data from the SYNACK,
no loss, again it goes in the next packets.

Now, I can run an HTTP-ssf server, but no web browser on the planet
can talk to me! And the browsers that I modify to speak HTTP-ssf can't
take to any non-ssf HTTP servers. It's a very lonely website.

I could define a whole new URL scheme (httpssf://...) and a new port.
But then there's no gradual deployment path because users with old
browsers don't understand httpssf:// and it confuses the users anyway.
Most type http:// by habit.

My HTTP-ssf server happens to be an embedded device and it handles the
TCP processing directly. So, I have browsers that understand HTTP-ssf
set an option in the SYN packet. If I see this option, I start talking
HTTP-ssf, otherwise I stick with HTTP. When I start talking HTTP-ssf,
I echo the option to let the client know which protocol is in effect.
Now HTTP-ssf can be deployed gradually.

In order to run HTTP-ssf servers on non-embedded machines I define a
couple of (get|set)sockopt's to set and query the option so I know
what protocol to speak. I also want to include the banner in the
SYNACK for latency reasons, so I include another setsockopt to set a
constant banner that's prepended to the beginning of the server's
outgoing data stream. However, the kernel needs to know only to
prepend this banner if the client include the option, so I add that
ability too.

Now my server gets SYN flooded and, to mitigate the problem, it
doesn't want to send large SYNACKs out, even when the client has
requested them. It can send minimal SYNACKs and put the banner in
later packets. However, user's hate it when their websites slow down
so, rather than do that, the kernel can also ignore the requests and
fall back to HTTP.

(Sorry, I don't mean to be condescending in the slightest! I just got
carried away with the personification there. However, I don't think
the clarity suffered for it, so I'm going to stick with it. I hope you
don't mind)


AGL

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