Re: [tcpm] TCP Long Options

"Adam Langley" <> Tue, 01 July 2008 18:27 UTC

Return-Path: <>
Received: from [] (localhost []) by (Postfix) with ESMTP id 15BE93A6876; Tue, 1 Jul 2008 11:27:56 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 932A13A686C for <>; Tue, 1 Jul 2008 11:27:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.827
X-Spam-Status: No, score=-1.827 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ntoHHUl5QmAN for <>; Tue, 1 Jul 2008 11:27:53 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 989E63A6876 for <>; Tue, 1 Jul 2008 11:27:53 -0700 (PDT)
Received: by with SMTP id b25so6849rvf.49 for <>; Tue, 01 Jul 2008 11:28:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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=w5Qjn2r4+WA33GiM2KNJkcW5c1I1zObK0Vr5YVde8bM=; b=nFLCCXy51jUXBgnT6LCe4UY4ssyi+uNuWQkp0V52rML1PEoHhpU+71/exNQchqqyF9 bS3RTWEbfg/F0tRybys4stPPFm/zC1MSdkPGNXBHbV6AVY9pAZk4oQpkz7o86WLQhRx8 njgwt/6513csi6hH3dJ5WMRSno/88gfxjmI8o=
DomainKey-Signature: a=rsa-sha1; c=nofws;; 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=lPX7J/feMT3FAn4alpAr0fD6LT/4jFvyn68L7uMu86WaKHpQczI8L8YQ28N2bIVOHq /l5MV0NWVzZURhnxZqurDkyBvHc2SZKO+QTOsYOMUBmCEO8pftiJE8auKy8PtGizHMZS LgxuZZ3f8QjgZiUQUBVB10Lh27Aohx3OYife4=
Received: by with SMTP id c17mr3801224rvl.212.1214936884322; Tue, 01 Jul 2008 11:28:04 -0700 (PDT)
Received: by with HTTP; Tue, 1 Jul 2008 11:28:04 -0700 (PDT)
Message-ID: <>
Date: Tue, 01 Jul 2008 11:28:04 -0700
From: Adam Langley <>
To: Joe Touch <>
In-Reply-To: <>
MIME-Version: 1.0
Content-Disposition: inline
References: <> <>
X-Google-Sender-Auth: 3729f51fcf5730fa
Subject: Re: [tcpm] TCP Long Options
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

On Tue, Jul 1, 2008 at 10:20 AM, Joe Touch <> wrote:
> It might be worth reviewing the discussion on the TCP-LO when it was
> previously presented, and provide a summary to the group as to whether
> anything has changed.

Good point, although I am probably omitting salient points which I
missed when reviewing the archives:

1. It's a "non-optional option" / it's another 4 bytes of bloat

Referring to the requirement that the LO option be included in every
packet. This requirement has been removed for implementation reasons
(it's very good to have a single fast path), but that also addresses
this. (However, the LO option is still required to be the first
option, if present and DO is required to be set to 6 in this case. I
reasoned that it was still best to remove extra degrees of freedom
about where to put it / how to set DO)

2. Some options can't be included in SLO

This is still correct. There's no good way to negotiate some options,
like MSS, if not included in the SYN packet so they cannot be moved to
the SLO option. The draft doesn't discuss this, and possibly it
should. Thinking about it, I might suggest that only options
explicitly defined to be SLO compatible should be included in the SLO
space. At the moment, that list might include just timestamps.

(Consider a SYN with MD5: LO (4 bytes) + WScale (4 bytes) + MSS (4
bytes) + SACK perm + TS (12 bytes) + MD5 (20 bytes) > 40 bytes - so we
can't even advertise LO in this case if we include TS in the SYN)

3. Three SACK blocks is sufficient

This is probably true for the vast majority of the time. However, auth
options esp reduce the number of possible SACK blocks when timestamps
are included as well. So, although extra SACK space is probably a
waste in packets with just a timestamp option, it can have it's uses

4. We could squeeze the options better

Several suggestions concerning making better use of the options space
were suggested like a binary flags option where timestamp permitted
and SACK permitted could live, or making the timestamp option smaller
in SYN packets. This would have been a great idea before these options
were deployed, but there's really no good way to transition now that
they have wide acceptance in their current form.

However, possibly we should change that by defining that binary flags
option right now and make LO the first user. If there's general
acceptance of this, I'll happily write the drafts.

5. Other methods of extending the option space

For example, making DO 5-bits wide or defining a scaling options for
DO. None seemed to gather widespread acceptance.

6. There's no need / we're not running out of space

Fundamentally, this objection is unaddressable by a long options draft
:) I suggest that there is a need in the case of TCP-AO/MD5 to include
SACK blocks. Additionally, the lack on long options hampers
experimentation. Personally, I'm pushing this because I want to
include an ECDH key exchange and need the extra options space. Others
have certainly needed the same thing and by specifying it we can aid
experimentation and encourage future TCP work which might not have
happened otherwise.

Adam Langley
tcpm mailing list