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

"Adam Langley" <agl@imperialviolet.org> Thu, 14 August 2008 17:14 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 928513A6E07; Thu, 14 Aug 2008 10:14:49 -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 E2FC73A6E01 for <tcpm@core3.amsl.com>; Thu, 14 Aug 2008 10:14:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.47
X-Spam-Level:
X-Spam-Status: No, score=-1.47 tagged_above=-999 required=5 tests=[AWL=0.507, 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 pDwI+qbWGyBt for <tcpm@core3.amsl.com>; Thu, 14 Aug 2008 10:14:48 -0700 (PDT)
Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.228]) by core3.amsl.com (Postfix) with ESMTP id EE2643A6E07 for <tcpm@ietf.org>; Thu, 14 Aug 2008 10:14:47 -0700 (PDT)
Received: by rv-out-0506.google.com with SMTP id b25so450692rvf.49 for <tcpm@ietf.org>; Thu, 14 Aug 2008 10:14:51 -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=cTkg8t1SlS472lha+BV1/7BVZp63O6cQxuhlulMGWz0=; b=ga9I6gSF/ovG2NJT69Z/AAyqEj5964Lva/sLfrnhimqqE4On2FSYmnOHyw/QAAz5Qy hF8qW/L0h+eauKegjaSaAHDllydVrabA42Xl++Qt0RE+yF5t4puAFkpfX1DcSNMHorAO xn1uRpah3PtQXq+LtJQaymPNHnTDvkU82ZhNc=
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=wzVd18UiHbhR/nb2I6b/f3Ltmc7MMnaWflO3lPfjpohqKf2+ewN+y22QfOZacZi5yq az9Qgd7HYVIp/ibekQaMns023ZfBjr6zMxXoqWQJEdiFBSQW0+PCJRD5HIAPA8H3ozvn Ke81L0IarAPjKUWZRMeS2JxIIWO2GqdVTSwdc=
Received: by 10.141.5.3 with SMTP id h3mr850835rvi.138.1218734091329; Thu, 14 Aug 2008 10:14:51 -0700 (PDT)
Received: by 10.141.37.3 with HTTP; Thu, 14 Aug 2008 10:14:51 -0700 (PDT)
Message-ID: <396556a20808141014m459e07ebh667aaee60e355ac9@mail.gmail.com>
Date: Thu, 14 Aug 2008 10:14:51 -0700
From: "Adam Langley" <agl@imperialviolet.org>
To: "Caitlin Bestler" <Caitlin.Bestler@neterion.com>
In-Reply-To: <78C9135A3D2ECE4B8162EBDCE82CAD77040E3E2E@nekter>
MIME-Version: 1.0
Content-Disposition: inline
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>
X-Google-Sender-Auth: 5b165c73be2bd24a
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

If I might address your concern first:

On Thu, Aug 14, 2008 at 8:27 AM, Caitlin Bestler
<Caitlin.Bestler@neterion.com> wrote:
> 4) The size of the optional payload is what fits in the SYN ACK
>   response.
>
> I have a major problem with this. Having an option to indicate
> that the TCP payload stream will start with a special header
> that documents its own length would make a lot more sense to me.
>
> The key problem here is that if the active side is not capable of
> delivering SYN-ACK payload it will just not ACK that portion.
> There is no guarantee that the resulting retransmit will be
> segmented the same way.

I've not included any details of the application level data in the
draft because I didn't think it to be in scope for TCPM. However, the
payload is self deliminating. It has to be because, if you are a
client application using the sockets API you might not run for an
arbitary amount of time. In that time, the server can have sent any
amount of data and there's no deliminators in the bytestream from the
socket.

If you are interested, I've included by current notes on the format at
the end of this email. (It's certainly not set in stone). However, the
draft does require a minimal level of support in conforming stacks to
allow applications to decide not to use the ability unless they know
that it has certain charactoristics. That minimal level is: the active
open side must be able to enqueue 64 bytes of payload from a SYN/ACK
and that the server be able to include 64-byte of data in a SYN/ACK.

I'll skip the points with which I agree with entirely.

> 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.



Cheers


--- Current notes on the possible format of the start of the
application data streams ---

This is nothing to do with TCP. It describes an extensible, self
deliminating format which is expected to prefix the usual application
data (say HTTP) in both directions:

// The format is like a TCP options structure. We wish to have an extensible
// set of options.
//
// The payload is in two sections. First, a bit-packed list of option numbers
// and payload lengths. Second, byte aligned, the payloads of all those
// options, concatenated.
//
// Numbers in the first part are encoded thus:
//
// The number of bits needed is encoded in uniary form, terminated by a zero
// bit, followed by that many bits.
//
// Thus, 0 is encoded with a single 0 bit.
// One is encoded by specify that one bit is needed with bits 10, followed by
// one bit of content. This bit is actually a zero. Since we already know that
// the number isn't 0, we bias the payload by one.
//
// Likewise, four is encoded with 110 to specify two bits, followed by 01.
// Since the 110 means that the smallest number that it could be is three, we
// only need to add one to make four.
//
// The first part of the payload is then a list of (kind number delta, payload
// length) tuples, where both elements are numbers, encoded as above. The kind
// numbers MUST appear in order, smallest first. The delta of the tuple
// specifies the difference between the current kind number and the next one.
// The current kind number is initially 0. A delta of 0 terminates the list.
// Such a delta doesn't have a payload length following it.
//
// Kinds which are a power of two (1, 2, 4, 8, ...) are defined to be protocol
// agnostic. Other kind numbers are availible for per-protocol options.
//
// Kinds 1 and 2 are special in that they have no payload length encoded. The
// payload length of kind 1 is defined to be 40 bytes and the payload length of
// kind 2 is defined to be 0 bytes.
//
// After all the tuples have been encoded, 0 bits are added to align to the
// next 8-bit boundary. Then the payloads are added, in order.
//
// If the end of the first section and the end of the whole bytestring
lie within the same 4-byte word, 0 bytes are appened to pad to the
next 4 byte word.


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