IETF Logo Mail Archive

Re: [tcpinc] TCP's treatment of data in SYN packets

Kyle Rose <krose@krose.org> Sun, 31 July 2016 04:09 UTC

Return-Path: <krose@krose.org>
X-Original-To: tcpinc@ietfa.amsl.com
Delivered-To: tcpinc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE4DF12D5A9 for <tcpinc@ietfa.amsl.com>; Sat, 30 Jul 2016 21:09:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=krose.org
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b35GUPiWLf06 for <tcpinc@ietfa.amsl.com>; Sat, 30 Jul 2016 21:09:34 -0700 (PDT)
Received: from mail-qk0-x22d.google.com (mail-qk0-x22d.google.com [IPv6:2607:f8b0:400d:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A1E612B034 for <tcpinc@ietf.org>; Sat, 30 Jul 2016 21:09:33 -0700 (PDT)
Received: by mail-qk0-x22d.google.com with SMTP id x1so121054405qkb.3 for <tcpinc@ietf.org>; Sat, 30 Jul 2016 21:09:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=krose.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=oKUPDOXu/i0RSwsk9APBl4Z0xDk++bk4DAx5fkQr1Go=; b=l8FSajWUtaSiY3XVSNnFAvLeZOMyjhINO99ucX1i7mneNtSAPgI2y6TvAxdmkxH8Sg VqpAlHumboUe0wQ2LtqqvVQYsJatfP3gdedPdMVD+GxGm4FK2QLXdW0zSdHBc0/pD29d ipuC3EouCfQg7xw1YRcoJr2DkE/B0XY/JlR4o=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=oKUPDOXu/i0RSwsk9APBl4Z0xDk++bk4DAx5fkQr1Go=; b=O7FXSkhZ7Tg405cRS9CRcnztHeC89v8ozGe4AgkkSAwrItkSaroOT4EKHu/+xIHbwZ aeBHqqHAqnUFFIAsT221TCHpWybFgm+Zj/mkWxpZaw5hFlJytvZpqzvtldhSwLOlVLS6 l+BRm4LlZNyhrClKFbw972XhAHruKE1s2i6CLsPm/SUGWLyZCbmUMJc4mhWzCQ5uo5fQ YuIErxVRpBQN9YyfWaI/TwGNmmZ+UkG8Ei/FaHQr12ky1mOwwEBkNGx6Si20tjd9WO0W aIAtxa4rDS6FPsDKdcs3mxbCajhOEpNykP6U+sISL1Fup+/bxuq7H4QG5mAzc5PtVlmw A/4Q==
X-Gm-Message-State: AEkoousd7zAft8fsLNdn2nmes7L65I3vQTVPYI7BnScKwU9+lW4ZcyWq9aS6ObMXsRY5g9QS0wRh+vaOceHFvA==
X-Received: by 10.55.158.203 with SMTP id h194mr7975363qke.51.1469938172764; Sat, 30 Jul 2016 21:09:32 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.55.94.70 with HTTP; Sat, 30 Jul 2016 21:09:31 -0700 (PDT)
X-Originating-IP: [2001:470:1f07:121:cd3:1756:1f5:ea51]
Received: by 10.55.94.70 with HTTP; Sat, 30 Jul 2016 21:09:31 -0700 (PDT)
In-Reply-To: <9ff12fb6-44f9-b1d0-2e9d-a67683679037@wizmail.org>
References: <CAJU8_nU1WzQNFFUn_2o1cACutB01iyQ_hC29PHoutr8TRDKGnA@mail.gmail.com> <579A4669.7030600@isi.edu> <87lh0lselg.fsf@ta.scs.stanford.edu> <CAJU8_nUPrm9JJMrrMbL5+FpP-9CKC6EkidCry9UuZA5ZfyJtoA@mail.gmail.com> <579A8223.8050308@isi.edu> <CAJU8_nXSxr7ykC1TwptBmyP8pNccz52ozq=hF7-EYiaMdDeLBQ@mail.gmail.com> <579BA470.3000405@isi.edu> <CAJU8_nXjhHH1eEXPA3hvhJ3YXsP_v2djGX=X2p9+wyn767Hm5A@mail.gmail.com> <adcaa33a-3bf5-e63a-bd19-fd165b16aa7d@wizmail.org> <87oa5fniu0.fsf@ta.scs.stanford.edu> <9ff12fb6-44f9-b1d0-2e9d-a67683679037@wizmail.org>
From: Kyle Rose <krose@krose.org>
Date: Sun, 31 Jul 2016 00:09:31 -0400
Message-ID: <CAJU8_nVBem40i5Rqke37UBtOquF_mVBJHkjrtAmNN2qPdHqY=A@mail.gmail.com>
To: Jeremy Harris <jgh@wizmail.org>
Content-Type: multipart/alternative; boundary="94eb2c05d3c8a136570538e6a664"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpinc/g58LoUpZqAV1Secj_ajRiQNvndw>
Cc: tcpinc <tcpinc@ietf.org>
Subject: Re: [tcpinc] TCP's treatment of data in SYN packets
X-BeenThere: tcpinc@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Discussion list for adding encryption to TCP." <tcpinc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpinc>, <mailto:tcpinc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tcpinc/>
List-Post: <mailto:tcpinc@ietf.org>
List-Help: <mailto:tcpinc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpinc>, <mailto:tcpinc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 31 Jul 2016 04:09:37 -0000

I'm not the author, so nothing to see here. :-) I was not considering
David's line of thinking about future mandatory application aware uses:
rather, I was speculating about how ENO could make use of SYN data in
general, which immediately led to the question in my OP about TCP's actual
(normative and observed) semantics regarding SYN data in the absence of TFO.

The thread has split, and I'm happy to let David represent his intentions.

Kyle

On Jul 30, 2016 7:33 PM, "Jeremy Harris" <jgh@wizmail.org> wrote:

> On 30/07/16 18:20, David Mazieres wrote:
> > No one is suggesting sending data in a SYN segment to a server that does
> > not support ENO.  In fact, no one is even suggesting sending data in a
> > SYN segment.
>
> I'm confused.  Kyle was talking about it:
>
> On 29/07/16 20:41, Kyle Rose wrote:
> > Right, I get that for interoperability with ENO-unaware stacks there is
> no
> > way to change data presented in the SYN.
> [...]
> > (1) If it is negotiating ENO, it will hand the data off to the chosen
> TEP,
> > which will then indicate back to ENO whether to ACK the data or not.
>
> --
> Jeremy
>
> _______________________________________________
> Tcpinc mailing list
> Tcpinc@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpinc
>

v2.37.1 | Report a Bug | By Email | System Status