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

["Adam Langley" <agl at imperialviolet.org>]

If I might address your concern first:

On Thu, Aug 14, 2008 at 8:27 AM, Caitlin Bestler
<Caitlin.Bestler at 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 at imperialviolet.org http://www.imperialviolet.org
_______________________________________________
tcpm mailing list
tcpm at ietf.org
https://www.ietf.org/mailman/listinfo/tcpm