Re: [tcpinc] Review of draft-bittau-tcpinc-tcpeno-01

John Leslie <> Tue, 25 August 2015 16:46 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 38DF31A700E for <>; Tue, 25 Aug 2015 09:46:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id sY34uY-NgHKf for <>; Tue, 25 Aug 2015 09:46:23 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 417B11A871E for <>; Tue, 25 Aug 2015 09:44:53 -0700 (PDT)
Received: by (Postfix, from userid 104) id 9DCB5C94BD; Tue, 25 Aug 2015 12:44:50 -0400 (EDT)
Date: Tue, 25 Aug 2015 12:44:50 -0400
From: John Leslie <>
To: "Scharf, Michael (Michael)" <>
Message-ID: <20150825164450.GA30018@verdi>
References: <> <> <> <> <> <> <> <> <> <>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.4.1i
Archived-At: <>
Cc: Stephen Kent <>, David Mazieres <>, "" <>, Stephen Farrell <>
Subject: Re: [tcpinc] Review of draft-bittau-tcpinc-tcpeno-01
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Discussion list for adding encryption to TCP." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 25 Aug 2015 16:46:26 -0000

Scharf, Michael (Michael) <> wrote:
> To: David Mazieres <>...
>> In fact, it's possible to fit a 32-byte ECDH parameter into a SYN-ACK
>> segment today.

   It's always possible to fit _one_ thing in -- what's hard is fitting
all the things folks consider "necessary".

   We've come late to this dance. :^( We should expect a lot of pushback
putting that much in SYN-ACK until there is a Proposed Standard for
expanding the SYN-ACK option space.

>> That means even without large SYN options, we can imagine making TCPINC
>> zero latency.

   "Zero latency" isn't the right target, IMHO. We should be advocating
for low latency by alieviating buffer-bloat latency overall; and designing
a default-case where we're not negotiating in the originating SYN: merely
allowing for negotiation later.

   Until TCPM gets a "round tuit" and increases option space at least for
the SYN-ACK, we're facing an almost insurmountable obstacle to deployment.

>> Realistically, doing so will require a gross hack in which TCP-ENO
>> compactly encodes timestamp and SACK availability, window scaling,
>> etc., in lieu of larger options.

   I strongly advise against going there. Deployment would take forever!

>> I don't expect people would be very happy with something like that from
>> day one. But we don't want to shut the door to such an optimization
>> either, in case TCPINC becomes a runaway success.

   Ah! Youthful optimism! It's refreshing to see it!

>> (We've been careful to leave a bunch of reserved suboptions in the
>> TCP-> ENO spec just in case we need extra bits for such optimizations.)
> I've not followed this thread. But this discussion about long options in
> SYN, modifying existing TCP options, etc. really scares me. I've always
> thought TCPINC's objective is to provide *payload* encryption, and
> negotiating this should IMHO not require any complex option.

   I wonder if we _have_ a shared goal there...

> I am also confused about the actual technical details in this
> discussion. In my understanding, the SYN-ACK for any modern high-speed
> TCP stack has to carry MSS (4 bytes), windows scale (3 bytes), and
> SACK permitted (2 bytes).

   (In _many_ cases, timestamp is automatically included, in order to
disambiguate over-large bandwidth-delay-product and error-correction
algorithms trying to avoid packet loss. This _is_ of course a terrible
design; but we seem to be stuck with it for at least five more years.)

> This means that at most 31 bytes are left (in theory, we have plenty of
> other TCP extensions consuming parts of it).


> Also, I believe some middleboxes/firewalls may act upon those options
> in the SYN-ACK, i.e., they cannot easily be replaced or encoded in a
> more compact way. As a result, I somehow don't understand how to get a
> 32 byte value into SYN-ACK without EDO (draft-ietf-tcpm-tcp-edo).

   That really _is_ a non-starter. If we want negotiation in the SYN-ACK,
we need to push the TCPM group to publish _some_ Proposed Standard.

   (Myself, I'd rather avoid the need for negotiatting in our first
Proposed Standard: deployment of draft-ietf-tcpm-tcp-edo is going to be
too slow for what I thought our target deployment to be. :^(

> And for EDO there are deployment challenges with using it in the SYN-ACK, see the discussion in TCPM.

   Seriously, we SHOULD follow (and participate in) the TCPM discussion.

> In any case, this sort of discussion on SYN option space IMHO should be
> taken to the TCPM list.

   I suspect we need to continue the discussion here; but recognize that
multi-byte TCP options simply won't be available without TCPM action.


John Leslie <>