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

"Caitlin Bestler" <Caitlin.Bestler@neterion.com> Thu, 14 August 2008 17:44 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 F23783A68FE; Thu, 14 Aug 2008 10:44:59 -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 10D9E3A6A2C for <tcpm@core3.amsl.com>; Thu, 14 Aug 2008 10:44:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 M-ul8Mlcmfrd for <tcpm@core3.amsl.com>; Thu, 14 Aug 2008 10:44:57 -0700 (PDT)
Received: from owa.neterion.com (mx.neterion.com [72.1.205.142]) by core3.amsl.com (Postfix) with ESMTP id 325E13A68FE for <tcpm@ietf.org>; Thu, 14 Aug 2008 10:44:57 -0700 (PDT)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Thu, 14 Aug 2008 13:44:36 -0400
Message-ID: <78C9135A3D2ECE4B8162EBDCE82CAD77040E3F07@nekter>
In-Reply-To: <396556a20808141014m459e07ebh667aaee60e355ac9@mail.gmail.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [tcpm] SYN/ACK Payloads, draft 01
Thread-Index: Acj+MUZEqj8ua0UVRWqdDx0Uy70oPwAA0x9w
References: <396556a20808111035s2b974233o1e9d3671e82e3350@mail.gmail.com> <000001c8fbfe$0dba0960$292e1c20$@pt> <396556a20808111617n622aceabn62db0d55b25ae712@mail.gmail.com> <000301c8fc81$8e02d470$aa087d50$@pt> <396556a20808120914k6d087534o5c34dfd51dd7d1c5@mail.gmail.com> <000b01c8fc9f$4d9f3c20$e8ddb460$@pt> <396556a20808121155h4e3c551aqcf5260d551bcdd4a@mail.gmail.com> <78C9135A3D2ECE4B8162EBDCE82CAD77040E3E2E@nekter> <396556a20808141014m459e07ebh667aaee60e355ac9@mail.gmail.com>
From: Caitlin Bestler <Caitlin.Bestler@neterion.com>
To: Adam Langley <agl@imperialviolet.org>
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

Adam Langley wrote:

> 
> > and 2) Designing a feature that deliberately throws away some
> > of the TCP payload stream seems contrary to the whole concept
> > of a reliable transport.
> 
> Here you are thinking about including SYN/ACK payloads when many
> clients will ignore them? It does have some inefficiency problems,
> I'll agree. However, I mostly expect that SYN/ACK payloads will only
> be returned to clients which have explicitly requested it with an
> option. There are certainly some server-speaks-first protocols (like
> SMTP) which could oppitunistically use SYN/ACK payloads. Then the
> inefficiency decision has to be made on a per application basis,
> probably a config option somewhere.
> 

My reservation is entirely theoretical.

The "overhead" of 64 data bytes on a SYN/ACK frame that is being
sent anyway is very slight or even zero, depending on exactly
what forms of intermediate queuing are in use.

The real concern would be if applications that did not use the
special sockopts were to have this special payload automatically
discarded by the stack.

Automatic discarding of payload, no matter how efficient, just
strikes me as contrary to the definition of what it means to
be a "reliable transport" service.

And experience has taught me that when something looks really
bad from a "purely theoretical" viewpoint it merely means that
I have not yet identified the specific case where it *will*
cause problems. So at the minimum I like to come up with
a strong reason why something is intrinsically safe, not
just "So far, I haven't thought of how it goes wrong."

_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm