From nobody Mon Sep 1 03:51:49 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 871381A0363 for ; Mon, 1 Sep 2014 03:51:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.57 X-Spam-Level: X-Spam-Status: No, score=-7.57 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.668, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 am2tJSC5NI9r for ; Mon, 1 Sep 2014 03:51:46 -0700 (PDT) Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B6E4F1A0362 for ; Mon, 1 Sep 2014 03:51:46 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.04,441,1406617200"; d="asc'?scan'208";a="185496891" Received: from vmwexceht05-prd.hq.netapp.com ([10.106.77.35]) by mx12-out.netapp.com with ESMTP; 01 Sep 2014 03:51:46 -0700 Received: from HIOEXCMBX03-PRD.hq.netapp.com (10.122.105.36) by vmwexceht05-prd.hq.netapp.com (10.106.77.35) with Microsoft SMTP Server (TLS) id 14.3.123.3; Mon, 1 Sep 2014 03:51:05 -0700 Received: from HIOEXCMBX06-PRD.hq.netapp.com (10.122.105.39) by hioexcmbx03-prd.hq.netapp.com (10.122.105.36) with Microsoft SMTP Server (TLS) id 15.0.913.22; Mon, 1 Sep 2014 03:51:05 -0700 Received: from HIOEXCMBX06-PRD.hq.netapp.com ([::1]) by hioexcmbx06-prd.hq.netapp.com ([fe80::f511:c2df:a501:6356%21]) with mapi id 15.00.0913.011; Mon, 1 Sep 2014 03:51:04 -0700 From: "Zimmermann, Alexander" To: "tcpm@ietf.org Extensions" Thread-Topic: New Version Notification for draft-zimmermann-tcpm-cubic-00.txt Thread-Index: AQHPxdBcBL48prkNhEWOs8VteY4kXA== Date: Mon, 1 Sep 2014 10:51:04 +0000 Message-ID: References: <20140901103526.10291.7574.idtracker@ietfa.amsl.com> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.1878.6) x-originating-ip: [10.120.60.37] Content-Type: multipart/signed; boundary="Apple-Mail=_8227B0E1-75E3-4C04-8690-B446C78211E3"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/GAu-ZYpk1NJpYxapPGrWcAyI-pc Subject: [tcpm] Fwd: New Version Notification for draft-zimmermann-tcpm-cubic-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Sep 2014 10:51:48 -0000 --Apple-Mail=_8227B0E1-75E3-4C04-8690-B446C78211E3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi TCPM WG, after more or less 6 years after the last submission of CUBIC, we = resubmit the draft today. The current submission is exactly the same as old draft = from 2008. In upcoming versions we plan to document current version of CUBIC = implementation (may or may not including Hystart), so that it can be implemented by = others without needing to refer to the Linux code. Alex Anfang der weitergeleiteten Nachricht: > Von: > Betreff: New Version Notification for = draft-zimmermann-tcpm-cubic-00.txt > Datum: 1. September 2014 12:35:26 MESZ > An: Lars Eggert , Lars Eggert , = Lisong Xu , Injong Rhee , Alexander = Zimmermann , Alexander Zimmermann = , Sangtae Ha = , Lisong Xu , = "Injong Rhee" >=20 >=20 > A new version of I-D, draft-zimmermann-tcpm-cubic-00.txt > has been successfully submitted by Alexander Zimmermann and posted to = the > IETF repository. >=20 > Name: draft-zimmermann-tcpm-cubic > Revision: 00 > Title: CUBIC for Fast Long-Distance Networks > Document date: 2014-09-01 > Group: Individual Submission > Pages: 14 > URL: = http://www.ietf.org/internet-drafts/draft-zimmermann-tcpm-cubic-00.txt > Status: = https://datatracker.ietf.org/doc/draft-zimmermann-tcpm-cubic/ > Htmlized: = http://tools.ietf.org/html/draft-zimmermann-tcpm-cubic-00 >=20 >=20 > Abstract: > CUBIC is an extension to the current TCP standards. The protocol > differs from the current TCP standards only in the congestion window > adjustment function in the sender side. In particular, it uses a > cubic function instead of a linear window increase of the current = TCP > standards to improve scalability and stability under fast and long > distance networks. BIC-TCP, a predecessor of CUBIC, has been a > default TCP adopted by Linux since year 2005 and has already been > deployed globally and in use for several years by the Internet > community at large. CUBIC is using a similar window growth function > as BIC-TCP and is designed to be less aggressive and fairer to TCP = in > bandwidth usage than BIC-TCP while maintaining the strengths of BIC- > TCP such as stability, window scalability and RTT fairness. Through > extensive testing in various Internet scenarios, we believe that > CUBIC is safe for deployment and testing in the global Internet. = The > intent of this document is to provide the protocol specification of > CUBIC for a third party implementation and solicit the community > feedback through experimentation on the performance of CUBIC. We > expect this document to be eventually published as an experimental > RFC. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat >=20 --Apple-Mail=_8227B0E1-75E3-4C04-8690-B446C78211E3 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlQET7oACgkQdyiq39b9uS5oRwCgloEpQZAPJ5MZ3nNrK2Y8dJaj SvwAnRgvlq5zOn/9xZY9PwehQ+NolUNN =by/P -----END PGP SIGNATURE----- --Apple-Mail=_8227B0E1-75E3-4C04-8690-B446C78211E3-- From nobody Mon Sep 1 04:07:12 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E16191A0384 for ; Mon, 1 Sep 2014 04:07:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.567 X-Spam-Level: X-Spam-Status: No, score=-2.567 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.668] autolearn=ham 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 3hMVfWmljDvh for ; Mon, 1 Sep 2014 04:07:00 -0700 (PDT) Received: from mail-out5.uio.no (mail-out5.uio.no [IPv6:2001:700:100:10::17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC8231A038E for ; Mon, 1 Sep 2014 04:06:54 -0700 (PDT) Received: from mail-mx6.uio.no ([129.240.10.40]) by mail-out5.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1XOPRk-0001H0-Rp; Mon, 01 Sep 2014 13:06:52 +0200 Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx6.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80.1) (envelope-from ) id 1XOPRj-0008BL-Ua; Mon, 01 Sep 2014 13:06:52 +0200 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_3BDD277F-9129-45BD-B05C-5EE5583584E8" From: Michael Welzl In-Reply-To: Date: Mon, 1 Sep 2014 13:06:48 +0200 Message-Id: <342E46B0-B909-4B0E-9718-8C543A1EA3DE@ifi.uio.no> References: <20140901103526.10291.7574.idtracker@ietfa.amsl.com> To: "Zimmermann, Alexander" X-Mailer: Apple Mail (2.1283) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 2 msgs/h 1 sum rcpts/h 7 sum msgs/h 3 total rcpts 19752 max rcpts/h 44 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-6.1, required=5.0, autolearn=disabled, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.06, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 0DF31C430E936DE670955D4A987021D74A65F99B X-UiO-SPAM-Test: remote_host: 129.240.68.135 spam_score: -60 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 5929 max/h 17 blacklist 0 greylist 0 ratelimit 0 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/zp6rVtXkHHhSyj3RJYmnxRZLp_8 Cc: "tcpm@ietf.org Extensions" Subject: Re: [tcpm] New Version Notification for draft-zimmermann-tcpm-cubic-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Sep 2014 11:07:06 -0000 --Apple-Mail=_3BDD277F-9129-45BD-B05C-5EE5583584E8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Wow! As ICCRG co-chair I think that's great! The history of ICCRG evaluation is still there, at: http://trac.tools.ietf.org/group/irtf/trac/wiki/ICCRG_cubic It would be worthwhile going through the comments on this page and see = if they've been addressed. Cheers, Michael On 1. sep. 2014, at 12:51, Zimmermann, Alexander wrote: > Hi TCPM WG, >=20 > after more or less 6 years after the last submission of CUBIC, we = resubmit the > draft today. The current submission is exactly the same as old draft = from 2008. >=20 > In upcoming versions we plan to document current version of CUBIC = implementation > (may or may not including Hystart), so that it can be implemented by = others > without needing to refer to the Linux code. >=20 > Alex >=20 > Anfang der weitergeleiteten Nachricht: >=20 >> Von: >> Betreff: New Version Notification for = draft-zimmermann-tcpm-cubic-00.txt >> Datum: 1. September 2014 12:35:26 MESZ >> An: Lars Eggert , Lars Eggert , = Lisong Xu , Injong Rhee , Alexander = Zimmermann , Alexander Zimmermann = , Sangtae Ha = , Lisong Xu , = "Injong Rhee" >>=20 >>=20 >> A new version of I-D, draft-zimmermann-tcpm-cubic-00.txt >> has been successfully submitted by Alexander Zimmermann and posted to = the >> IETF repository. >>=20 >> Name: draft-zimmermann-tcpm-cubic >> Revision: 00 >> Title: CUBIC for Fast Long-Distance Networks >> Document date: 2014-09-01 >> Group: Individual Submission >> Pages: 14 >> URL: = http://www.ietf.org/internet-drafts/draft-zimmermann-tcpm-cubic-00.txt >> Status: = https://datatracker.ietf.org/doc/draft-zimmermann-tcpm-cubic/ >> Htmlized: = http://tools.ietf.org/html/draft-zimmermann-tcpm-cubic-00 >>=20 >>=20 >> Abstract: >> CUBIC is an extension to the current TCP standards. The protocol >> differs from the current TCP standards only in the congestion window >> adjustment function in the sender side. In particular, it uses a >> cubic function instead of a linear window increase of the current = TCP >> standards to improve scalability and stability under fast and long >> distance networks. BIC-TCP, a predecessor of CUBIC, has been a >> default TCP adopted by Linux since year 2005 and has already been >> deployed globally and in use for several years by the Internet >> community at large. CUBIC is using a similar window growth function >> as BIC-TCP and is designed to be less aggressive and fairer to TCP = in >> bandwidth usage than BIC-TCP while maintaining the strengths of BIC- >> TCP such as stability, window scalability and RTT fairness. Through >> extensive testing in various Internet scenarios, we believe that >> CUBIC is safe for deployment and testing in the global Internet. = The >> intent of this document is to provide the protocol specification of >> CUBIC for a third party implementation and solicit the community >> feedback through experimentation on the performance of CUBIC. We >> expect this document to be eventually published as an experimental >> RFC. >>=20 >>=20 >>=20 >>=20 >> Please note that it may take a couple of minutes from the time of = submission >> until the htmlized version and diff are available at tools.ietf.org. >>=20 >> The IETF Secretariat >>=20 >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm --Apple-Mail=_3BDD277F-9129-45BD-B05C-5EE5583584E8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Wow! = As ICCRG co-chair I think that's great!

The history = of ICCRG evaluation is still there, at:
It = would be worthwhile going through the comments on this page and see if = they've been = addressed.

Cheers,
Michael

On 1. sep. 2014, at 12:51, Zimmermann, = Alexander wrote:

Hi TCPM WG,

after more or less 6 years after = the last submission of CUBIC, we resubmit the
draft today. The = current submission is exactly the same as old draft from 2008.

In = upcoming versions we plan to document current version of CUBIC = implementation
(may or may not including Hystart), so that it can be = implemented by others
without needing to refer to the Linux = code.

Alex

Anfang der weitergeleiteten = Nachricht:

Von: <internet-drafts@ietf.org><= br>
Betreff: New Version = Notification for = draft-zimmermann-tcpm-cubic-00.txt
Datum: 1. September 2014 12:35:26 = MESZ
An: Lars Eggert <lars@netapp.com>, Lars Eggert = <lars@netapp.com>, Lisong = Xu <xu@unl.edu>, Injong Rhee = <rhee@ncsu.edu>, Alexander = Zimmermann <alexander.zimmermann@netap= p.com>, Alexander Zimmermann <alexander.zimmermann@netap= p.com>, Sangtae Ha <unknown-email-Sang= tae-Ha@ietfa.amsl.com>, Lisong Xu <xu@unl.edu>, "Injong Rhee" <rhee@ncsu.edu>


A new version = of I-D, draft-zimmermann-tcpm-cubic-00.txt
has been successfully submitted by Alexander Zimmermann = and posted to the
IETF = repository.

Name: = draft-zimmermann-tcpm-cubic
Revision: 00
Title: CUBIC for Fast Long-Distance = Networks
Document date: = 2014-09-01
Group: = Individual Submission
Pages: 14
URL: =            http://www.ietf.org/internet-drafts/draft-zimmermann-tcpm-cubic-00.t= xt
Status: =         htt= ps://datatracker.ietf.org/doc/draft-zimmermann-tcpm-cubic/
Htmlized: =       http://= tools.ietf.org/html/draft-zimmermann-tcpm-cubic-00


Abstract:
=  CUBIC is an extension to the current TCP standards.  The = protocol
 differs from = the current TCP standards only in the congestion = window
 adjustment = function in the sender side.  In particular, it uses = a
 cubic function = instead of a linear window increase of the current = TCP
 standards to = improve scalability and stability under fast and = long
 distance networks. =  BIC-TCP, a predecessor of CUBIC, has been = a
 default TCP adopted = by Linux since year 2005 and has already = been
 deployed globally = and in use for several years by the Internet
 community at large.  CUBIC is using a similar = window growth function
=  as BIC-TCP and is designed to be less aggressive and fairer to TCP = in
 bandwidth usage than = BIC-TCP while maintaining the strengths of = BIC-
 TCP such as = stability, window scalability and RTT fairness. =  Through
 extensive = testing in various Internet scenarios, we believe = that
 CUBIC is safe for = deployment and testing in the global Internet. =  The
 intent of = this document is to provide the protocol specification = of
 CUBIC for a third = party implementation and solicit the = community
 feedback = through experimentation on the performance of CUBIC. =  We
 expect this = document to be eventually published as an = experimental
=  RFC.




Please note = that it may take a couple of minutes from the time of = submission
until the htmlized = version and diff are available at tools.ietf.org.

The IETF = Secretariat


_______________________________________= ________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/ma= ilman/listinfo/tcpm

= --Apple-Mail=_3BDD277F-9129-45BD-B05C-5EE5583584E8-- From nobody Wed Sep 10 08:00:57 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B479F1A01F1 for ; Tue, 9 Sep 2014 12:47:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.1 X-Spam-Level: X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 rQS0X1DOKu3t for ; Tue, 9 Sep 2014 12:47:10 -0700 (PDT) Received: from mail-qa0-x22a.google.com (mail-qa0-x22a.google.com [IPv6:2607:f8b0:400d:c00::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 04EA31A01DD for ; Tue, 9 Sep 2014 12:47:09 -0700 (PDT) Received: by mail-qa0-f42.google.com with SMTP id dc16so12284071qab.15 for ; Tue, 09 Sep 2014 12:47:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=8PbdVxFIPD+3W2LmXwchah39++2CigM5krYs3kUyhQg=; b=wsAu+6JOEw8TjKiG4hOGiWzvacVIGWtIIIe6ugBfr9ha0SknnWAQgJeW0KhIsb9Lew oE27UFWq6UNtw/RgZv1hEkpmPQsQnkq9fr2YnJ3z/gBvhUkbDAKqH44dAnTkJ9rPoe+y rmu+QVYhQAA1DYZhbjyUSD6ql95m6bKIrbEE0BSoarydBfFomdZVv9p+EUkyrTlkaPgs fl+O16ZGLdFEGvsorN/Ou77aeMuZSFO7SV+GL5jTGbg9Weu2mASjdv181EPjT40gulXE NkuVel2k+9UTT7Eu23JZCA+CvrGEgQJSnH2g/0Pvl4GJWg4xlEwl7LIwPVO8oP1fu+Iy zksw== MIME-Version: 1.0 X-Received: by 10.224.168.207 with SMTP id v15mr21668360qay.96.1410292028764; Tue, 09 Sep 2014 12:47:08 -0700 (PDT) Received: by 10.140.216.136 with HTTP; Tue, 9 Sep 2014 12:47:08 -0700 (PDT) Date: Tue, 9 Sep 2014 21:47:08 +0200 Message-ID: From: renaud sallantin To: tcpm@ietf.org, cedric baudoin Content-Type: multipart/alternative; boundary=089e015375aa6799af0502a73336 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/8COhyJKWWc-Fv35CD-v7_K4yQ-w X-Mailman-Approved-At: Wed, 10 Sep 2014 08:00:55 -0700 Subject: [tcpm] Questions regarding our draft : draft-sallantin-iccrg-initial-spreading-01 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Sep 2014 19:47:11 -0000 --089e015375aa6799af0502a73336 Content-Type: text/plain; charset=UTF-8 Hi, We have presented our draft draft-sallantin-iccrg-initial-spreading-01 to ICCRG at IETF-89. We'd like to get more feedback, and are interested in taking this further in the IETF; since this is a direct change to TCP, the ICCRG chairs told me to send a note here. We'd appreciate your comments - it's a method that uses simple and easy-to-implement pacing *only over the initial window*, and we got good results with it (The ICCRG slides are at http://www.ietf.org/proceedings/89/slides/slides-89-iccrg-1.pdf). We also wrote 2 papers on the subject: - *Initial Spreading: a Fast Start-Up mechanism, LCN 2013* *- A TCP model for short-lived flows to validate Initial Spreading, LCN 2014* (I will present the second one tomorrow morning) May we present it at the next IETF? The draft is going to expire soon. Chairs, should we re-submit an updated version as draft-sallantin-tcpm-initial-spreading-00? Thanks in advance, Renaud Sallantin --089e015375aa6799af0502a73336 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

We have pres= ented our draft draft-sallantin-iccrg-initial-spreading-01 to ICCRG at IETF= -89. We'd like to get more feedback, and are interested in taking this = further in the IETF; since this is a direct change to TCP, the ICCRG chairs= told me to send a note here. We'd appreciate your comments - it's = a method that uses simple and easy-to-implement pacing *only over the initi= al window*, and we got good results with it (The ICCRG slides are at=C2=A0<= a href=3D"http://www.ietf.org/proceedings/89/slides/slides-89-iccrg-1.pdf" = target=3D"_blank">http://www.ietf.org/proceedings/89/slides/slides-89-iccrg= -1.pdf).

We a= lso wrote 2 papers on the subject:
-=C2=A0Initial Spreading: a Fast Start-Up mechan= ism, LCN 2013
- A TCP model for short-lived flows to validate Initial Spreading= , LCN 2014
(I will present the second one tomorrow morning)

May we present it at the next IETF?

The draft is going t= o expire soon. Chairs, should we re-submit an updated version as draft-sall= antin-tcpm-initial-spreading-00?=C2=A0

Thanks in advance,
Renaud Sallantin
--089e015375aa6799af0502a73336-- From nobody Wed Sep 10 08:26:39 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE8AF1A0277 for ; Wed, 10 Sep 2014 08:26:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.551 X-Spam-Level: X-Spam-Status: No, score=-3.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.652] autolearn=ham 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 YIDjH3_7Dyj9 for ; Wed, 10 Sep 2014 08:26:35 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 73A561A8730 for ; Wed, 10 Sep 2014 08:26:35 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (unknown [135.239.2.42]) by Websense Email Security Gateway with ESMTPS id 8D00FB4020783; Wed, 10 Sep 2014 15:26:28 +0000 (GMT) Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id s8AFQUgx006664 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 10 Sep 2014 17:26:31 +0200 Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.218]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.02.0247.003; Wed, 10 Sep 2014 17:26:31 +0200 From: "Scharf, Michael (Michael)" To: renaud sallantin , "tcpm@ietf.org" , cedric baudoin Thread-Topic: [tcpm] Questions regarding our draft : draft-sallantin-iccrg-initial-spreading-01 Thread-Index: AQHPzQgepToatAbbG0uw5eGDCJ7T4Zv6eEuQ Date: Wed, 10 Sep 2014 15:26:30 +0000 Message-ID: <655C07320163294895BBADA28372AF5D1661604A@FR712WXCHMBA15.zeu.alcatel-lucent.com> References: In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.39] Content-Type: multipart/alternative; boundary="_000_655C07320163294895BBADA28372AF5D1661604AFR712WXCHMBA15z_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/0XvWWWWpPOyPc35AHrwn_QSQihw Subject: Re: [tcpm] Questions regarding our draft : draft-sallantin-iccrg-initial-spreading-01 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Sep 2014 15:26:38 -0000 --_000_655C07320163294895BBADA28372AF5D1661604AFR712WXCHMBA15z_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgUmVuYXVkLA0KDQpTb3JyeSBpZiB0aGlzIHdhcyBhc2tlZCBhbHJlYWR5OiBJcyB0aGVyZSBy dW5uaW5nIGNvZGUsIGUuZy4sIGluIExpbnV4IG9yICpCU0Q/DQoNCklmIHlvdSBhcmUgaW50ZXJl c3RlZCBpbiBhIHByZXNlbnRhdGlvbiBpbiBUQ1BNLCBwbGVhc2UgcmVzdWJtaXQgYSByZXF1ZXN0 IGZvciBhIHRpbWUgc2xvdCB3aGVuIHdlIHN0YXJ0IGJ1aWxkaW5nIHRoZSBUQ1BNIGFnZW5kYS4g VGhlIGNoYWlycyB1c3VhbGx5IGdpdmUgcHJpb3JpdHkgdG8gcHJlc2VudGF0aW9ucyB3aXRoIHBy aW9yIG1haWxpbmcgbGlzdCBkaXNjdXNzaW9uIGFuZCBwb3NpdGl2ZSBmZWVkYmFjay4NCg0KQmVz dCByZWdhcmRzDQoNCk1pY2hhZWwNCg0KDQpGcm9tOiB0Y3BtIFttYWlsdG86dGNwbS1ib3VuY2Vz QGlldGYub3JnXSBPbiBCZWhhbGYgT2YgcmVuYXVkIHNhbGxhbnRpbg0KU2VudDogVHVlc2RheSwg U2VwdGVtYmVyIDA5LCAyMDE0IDk6NDcgUE0NClRvOiB0Y3BtQGlldGYub3JnOyBjZWRyaWMgYmF1 ZG9pbg0KU3ViamVjdDogW3RjcG1dIFF1ZXN0aW9ucyByZWdhcmRpbmcgb3VyIGRyYWZ0IDogZHJh ZnQtc2FsbGFudGluLWljY3JnLWluaXRpYWwtc3ByZWFkaW5nLTAxDQoNCkhpLA0KDQpXZSBoYXZl IHByZXNlbnRlZCBvdXIgZHJhZnQgZHJhZnQtc2FsbGFudGluLWljY3JnLWluaXRpYWwtc3ByZWFk aW5nLTAxIHRvIElDQ1JHIGF0IElFVEYtODkuIFdlJ2QgbGlrZSB0byBnZXQgbW9yZSBmZWVkYmFj aywgYW5kIGFyZSBpbnRlcmVzdGVkIGluIHRha2luZyB0aGlzIGZ1cnRoZXIgaW4gdGhlIElFVEY7 IHNpbmNlIHRoaXMgaXMgYSBkaXJlY3QgY2hhbmdlIHRvIFRDUCwgdGhlIElDQ1JHIGNoYWlycyB0 b2xkIG1lIHRvIHNlbmQgYSBub3RlIGhlcmUuIFdlJ2QgYXBwcmVjaWF0ZSB5b3VyIGNvbW1lbnRz IC0gaXQncyBhIG1ldGhvZCB0aGF0IHVzZXMgc2ltcGxlIGFuZCBlYXN5LXRvLWltcGxlbWVudCBw YWNpbmcgKm9ubHkgb3ZlciB0aGUgaW5pdGlhbCB3aW5kb3cqLCBhbmQgd2UgZ290IGdvb2QgcmVz dWx0cyB3aXRoIGl0IChUaGUgSUNDUkcgc2xpZGVzIGFyZSBhdCBodHRwOi8vd3d3LmlldGYub3Jn L3Byb2NlZWRpbmdzLzg5L3NsaWRlcy9zbGlkZXMtODktaWNjcmctMS5wZGYpLg0KDQpXZSBhbHNv IHdyb3RlIDIgcGFwZXJzIG9uIHRoZSBzdWJqZWN0Og0KLSBJbml0aWFsIFNwcmVhZGluZzogYSBG YXN0IFN0YXJ0LVVwIG1lY2hhbmlzbSwgTENOIDIwMTMNCi0gQSBUQ1AgbW9kZWwgZm9yIHNob3J0 LWxpdmVkIGZsb3dzIHRvIHZhbGlkYXRlIEluaXRpYWwgU3ByZWFkaW5nLCBMQ04gMjAxNA0KKEkg d2lsbCBwcmVzZW50IHRoZSBzZWNvbmQgb25lIHRvbW9ycm93IG1vcm5pbmcpDQoNCk1heSB3ZSBw cmVzZW50IGl0IGF0IHRoZSBuZXh0IElFVEY/DQoNClRoZSBkcmFmdCBpcyBnb2luZyB0byBleHBp cmUgc29vbi4gQ2hhaXJzLCBzaG91bGQgd2UgcmUtc3VibWl0IGFuIHVwZGF0ZWQgdmVyc2lvbiBh cyBkcmFmdC1zYWxsYW50aW4tdGNwbS1pbml0aWFsLXNwcmVhZGluZy0wMD8NCg0KVGhhbmtzIGlu IGFkdmFuY2UsDQpSZW5hdWQgU2FsbGFudGluDQo= --_000_655C07320163294895BBADA28372AF5D1661604AFR712WXCHMBA15z_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2 IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBs aS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9t Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJv bWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4u RS1NYWlsRm9ybWF0dm9ybGFnZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQou TXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTt9DQpAcGFnZSBXb3Jk U2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQg NzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30N Ci0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6 ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBn dGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2 OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0t LT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkRFIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4N CjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkhpIFJlbmF1 ZCw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+U29ycnkgaWYgdGhpcyB3YXMg YXNrZWQgYWxyZWFkeTogSXMgdGhlcmUgcnVubmluZyBjb2RlLCBlLmcuLCBpbiBMaW51eCBvciAq QlNEPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JZiB5b3UgYXJlIGludGVy ZXN0ZWQgaW4gYSBwcmVzZW50YXRpb24gaW4gVENQTSwgcGxlYXNlIHJlc3VibWl0IGEgcmVxdWVz dCBmb3IgYSB0aW1lIHNsb3Qgd2hlbiB3ZSBzdGFydCBidWlsZGluZyB0aGUgVENQTSBhZ2VuZGEu IFRoZSBjaGFpcnMgdXN1YWxseQ0KIGdpdmUgcHJpb3JpdHkgdG8gcHJlc2VudGF0aW9ucyB3aXRo IHByaW9yIG1haWxpbmcgbGlzdCBkaXNjdXNzaW9uIGFuZCBwb3NpdGl2ZSBmZWVkYmFjay48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+QmVzdCByZWdhcmRzPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPk1pY2hhZWw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9y ZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNt IDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlk ICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gdGNwbSBbbWFpbHRvOnRjcG0tYm91bmNlc0BpZXRm Lm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+cmVuYXVkIHNhbGxhbnRpbjxicj4NCjxiPlNlbnQ6 PC9iPiBUdWVzZGF5LCBTZXB0ZW1iZXIgMDksIDIwMTQgOTo0NyBQTTxicj4NCjxiPlRvOjwvYj4g dGNwbUBpZXRmLm9yZzsgY2VkcmljIGJhdWRvaW48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gW3RjcG1d IFF1ZXN0aW9ucyByZWdhcmRpbmcgb3VyIGRyYWZ0IDogZHJhZnQtc2FsbGFudGluLWljY3JnLWlu aXRpYWwtc3ByZWFkaW5nLTAxPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5IaSw8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij5XZSBoYXZlIHByZXNlbnRlZCBvdXIgZHJhZnQgZHJhZnQtc2FsbGFudGluLWljY3JnLWlu aXRpYWwtc3ByZWFkaW5nLTAxIHRvIElDQ1JHIGF0IElFVEYtODkuIFdlJ2QgbGlrZSB0byBnZXQg bW9yZSBmZWVkYmFjaywgYW5kIGFyZSBpbnRlcmVzdGVkIGluIHRha2luZyB0aGlzIGZ1cnRoZXIg aW4gdGhlDQogSUVURjsgc2luY2UgdGhpcyBpcyBhIGRpcmVjdCBjaGFuZ2UgdG8gVENQLCB0aGUg SUNDUkcgY2hhaXJzIHRvbGQgbWUgdG8gc2VuZCBhIG5vdGUgaGVyZS4gV2UnZCBhcHByZWNpYXRl IHlvdXIgY29tbWVudHMgLSBpdCdzIGEgbWV0aG9kIHRoYXQgdXNlcyBzaW1wbGUgYW5kIGVhc3kt dG8taW1wbGVtZW50IHBhY2luZyAqb25seSBvdmVyIHRoZSBpbml0aWFsIHdpbmRvdyosIGFuZCB3 ZSBnb3QgZ29vZCByZXN1bHRzIHdpdGggaXQgKFRoZSBJQ0NSRw0KIHNsaWRlcyBhcmUgYXQmbmJz cDs8YSBocmVmPSJodHRwOi8vd3d3LmlldGYub3JnL3Byb2NlZWRpbmdzLzg5L3NsaWRlcy9zbGlk ZXMtODktaWNjcmctMS5wZGYiIHRhcmdldD0iX2JsYW5rIj5odHRwOi8vd3d3LmlldGYub3JnL3By b2NlZWRpbmdzLzg5L3NsaWRlcy9zbGlkZXMtODktaWNjcmctMS5wZGY8L2E+KS48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5X ZSBhbHNvIHdyb3RlIDIgcGFwZXJzIG9uIHRoZSBzdWJqZWN0OjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPi0mbmJzcDs8aT5Jbml0aWFsIFNwcmVhZGluZzogYSBGYXN0IFN0YXJ0LVVwIG1l Y2hhbmlzbSwgTENOIDIwMTM8L2k+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+LSBB IFRDUCBtb2RlbCBmb3Igc2hvcnQtbGl2ZWQgZmxvd3MgdG8gdmFsaWRhdGUgSW5pdGlhbCBTcHJl YWRpbmcsIExDTiAyMDE0PC9zcGFuPjwvaT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4oSSB3aWxsIHByZXNlbnQgdGhlIHNlY29uZCBvbmUg dG9tb3Jyb3cgbW9ybmluZyk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5NYXkgd2UgcHJlc2VudCBpdCBhdCB0aGUgbmV4dCBJ RVRGPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Fy aWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPlRoZSBkcmFmdCBpcyBnb2luZyB0byBleHBpcmUgc29vbi4gQ2hhaXJzLCBz aG91bGQgd2UgcmUtc3VibWl0IGFuIHVwZGF0ZWQgdmVyc2lvbiBhcyBkcmFmdC1zYWxsYW50aW4t dGNwbS1pbml0aWFsLXNwcmVhZGluZy0wMD8mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5UaGFua3MgaW4gYWR2YW5j ZSw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlh bCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5SZW5hdWQgU2FsbGFudGluPG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8 L2h0bWw+DQo= --_000_655C07320163294895BBADA28372AF5D1661604AFR712WXCHMBA15z_-- From nobody Fri Sep 12 01:41:41 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B0101A0240 for ; Wed, 10 Sep 2014 14:56:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 RDSYW5SnSw8t for ; Wed, 10 Sep 2014 14:56:17 -0700 (PDT) Received: from mail-qg0-x235.google.com (mail-qg0-x235.google.com [IPv6:2607:f8b0:400d:c04::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 26F791A0218 for ; Wed, 10 Sep 2014 14:56:16 -0700 (PDT) Received: by mail-qg0-f53.google.com with SMTP id q108so2697706qgd.12 for ; Wed, 10 Sep 2014 14:56:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=5erEiZU17NSm+Tnk3s/GLArCROElQ7VYxQ/6ai1qWy0=; b=xJIG17Azm1Dmc1ZjmGgg2C6eZiP9MahtgOUycPsyjgtoONoAHUm/edcbkkDR8vIh3V xkShTyqRZvyIzXhYzbpkf+hcECZB2Lgi7bEiCtYnToF41rLft2pK4E1VDQuKtdXzopGM ijjmNIJ/d3tZFIUeFkgMrxkdFaneP0yqHSYkYvD6KkabSenp6xfQFX4Hz5WKaJY5l/nf yWAgHyBZT4x8H4+B27VXiI9Dj61S9RT0b12jtLGWUsARJ+tt0/OAKmZ+YkIPGffKWD+W mLwUkIbNxZlGlQbl69XJMiZY/y6vtjKrNMZhp8aZ4ZGLSyQ3FgVSZM4iWtM2PYvf979Y aQBg== MIME-Version: 1.0 X-Received: by 10.224.103.132 with SMTP id k4mr63691616qao.54.1410386176141; Wed, 10 Sep 2014 14:56:16 -0700 (PDT) Received: by 10.140.216.136 with HTTP; Wed, 10 Sep 2014 14:56:16 -0700 (PDT) In-Reply-To: <655C07320163294895BBADA28372AF5D1661604A@FR712WXCHMBA15.zeu.alcatel-lucent.com> References: <655C07320163294895BBADA28372AF5D1661604A@FR712WXCHMBA15.zeu.alcatel-lucent.com> Date: Wed, 10 Sep 2014 23:56:16 +0200 Message-ID: From: renaud sallantin To: "Scharf, Michael (Michael)" Content-Type: multipart/alternative; boundary=001a11c2cfc40672260502bd1f01 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/PHe70J6UjD-BDbwsoSfUpQ3xtOE X-Mailman-Approved-At: Fri, 12 Sep 2014 01:41:40 -0700 Cc: "tcpm@ietf.org" Subject: Re: [tcpm] Questions regarding our draft : draft-sallantin-iccrg-initial-spreading-01 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Sep 2014 21:56:19 -0000 --001a11c2cfc40672260502bd1f01 Content-Type: text/plain; charset=UTF-8 Hi Michael, I will post our last Linux patch next week. Thanks for your answer, regards, Renaud 2014-09-10 17:26 GMT+02:00 Scharf, Michael (Michael) < michael.scharf@alcatel-lucent.com>: > Hi Renaud, > > > > Sorry if this was asked already: Is there running code, e.g., in Linux or > *BSD? > > > > If you are interested in a presentation in TCPM, please resubmit a request > for a time slot when we start building the TCPM agenda. The chairs usually > give priority to presentations with prior mailing list discussion and > positive feedback. > > > > Best regards > > > > Michael > > > > > > *From:* tcpm [mailto:tcpm-bounces@ietf.org] *On Behalf Of *renaud > sallantin > *Sent:* Tuesday, September 09, 2014 9:47 PM > *To:* tcpm@ietf.org; cedric baudoin > *Subject:* [tcpm] Questions regarding our draft : > draft-sallantin-iccrg-initial-spreading-01 > > > > Hi, > > > > We have presented our draft draft-sallantin-iccrg-initial-spreading-01 to > ICCRG at IETF-89. We'd like to get more feedback, and are interested in > taking this further in the IETF; since this is a direct change to TCP, the > ICCRG chairs told me to send a note here. We'd appreciate your comments - > it's a method that uses simple and easy-to-implement pacing *only over the > initial window*, and we got good results with it (The ICCRG slides are at > http://www.ietf.org/proceedings/89/slides/slides-89-iccrg-1.pdf). > > > > We also wrote 2 papers on the subject: > > - *Initial Spreading: a Fast Start-Up mechanism, LCN 2013* > > *- A TCP model for short-lived flows to validate Initial Spreading, LCN > 2014* > > (I will present the second one tomorrow morning) > > > > May we present it at the next IETF? > > > > The draft is going to expire soon. Chairs, should we re-submit an updated > version as draft-sallantin-tcpm-initial-spreading-00? > > > > Thanks in advance, > > Renaud Sallantin > --001a11c2cfc40672260502bd1f01 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Michael,

I will post our last Linux = patch next week.=C2=A0
Thanks for your answer,

regards,
Renaud=C2=A0

2014-09-10 17:26 GMT+02:00 Scharf, Michael= (Michael) <michael.scharf@alcatel-lucent.com>:

Hi Renaud,=

=C2= =A0

Sorry if t= his was asked already: Is there running code, e.g., in Linux or *BSD?

=C2= =A0

If you are= interested in a presentation in TCPM, please resubmit a request for a time= slot when we start building the TCPM agenda. The chairs usually give priority to presentations with prior mailing list discussion and posi= tive feedback.

=C2= =A0

Best regar= ds

=C2= =A0

Michael=

=C2= =A0

=C2= =A0

From: tcpm [ma= ilto:tcpm-bounce= s@ietf.org] On Behalf Of renaud sallantin
Sent: Tuesday, September 09, 2014 9:47 PM
To: tcpm@ietf.org= ; cedric baudoin
Subject: [tcpm] Questions regarding our draft : draft-sallantin-iccr= g-initial-spreading-01

=C2=A0

Hi,

=C2=A0

We have presented our draft draft-sallant= in-iccrg-initial-spreading-01 to ICCRG at IETF-89. We'd like to get mor= e feedback, and are interested in taking this further in the IETF; since this is a direct change to TCP, the ICCRG chairs told me to se= nd a note here. We'd appreciate your comments - it's a method that = uses simple and easy-to-implement pacing *only over the initial window*, an= d we got good results with it (The ICCRG slides are at=C2=A0http://www.ietf.org/proceedings/89/s= lides/slides-89-iccrg-1.pdf).

=C2=A0

We also wrote 2 papers on the subject:=

-=C2=A0Initial Spreading: a Fast Start= -Up mechanism, LCN 2013

- A TCP model for short-lived flows to= validate Initial Spreading, LCN 2014

(I will present the second one tomorrow m= orning)

=C2=A0

May we present it at the next IETF?

=C2=A0

The draft is going to expire soon. Chairs= , should we re-submit an updated version as draft-sallantin-tcpm-initial-sp= reading-00?=C2=A0

=C2=A0

Thanks in advance,

Renaud Sallantin


--001a11c2cfc40672260502bd1f01-- From nobody Sat Sep 13 00:43:16 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A12F1A0663; Sat, 13 Sep 2014 00:43:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 WaTIIgm0ZjRa; Sat, 13 Sep 2014 00:43:11 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 099AF1A0535; Sat, 13 Sep 2014 00:43:11 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p6 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140913074311.28129.98151.idtracker@ietfa.amsl.com> Date: Sat, 13 Sep 2014 00:43:11 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/cwYyLOjJycwJr-BfTOAtalg8mwE Cc: tcpm@ietf.org Subject: [tcpm] I-D Action: draft-ietf-tcpm-newcwv-07.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Sep 2014 07:43:12 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the TCP Maintenance and Minor Extensions Working Group of the IETF. Title : Updating TCP to support Rate-Limited Traffic Authors : Godred Fairhurst Arjuna Sathiaseelan Raffaello Secchi Filename : draft-ietf-tcpm-newcwv-07.txt Pages : 24 Date : 2014-09-13 Abstract: This document proposes an update to RFC 5681 to address issues that arise when TCP is used to support traffic that exhibits periods where the sending rate is limited by the application rather than the congestion window. It provides an experimental update to TCP that allows a TCP sender to restart quickly following either a rate- limited interval. This method is expected to benefit applications that send rate-limited traffic using TCP, while also providing an appropriate response if congestion is experienced. It also evaluates the Experimental specification of TCP Congestion Window Validation, CWV, defined in RFC 2861, and concludes that RFC 2861 sought to address important issues, but failed to deliver a widely used solution. This document therefore recommends that the status of RFC 2861 is moved from Experimental to Historic, and that it is replaced by the current specification. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tcpm-newcwv/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-tcpm-newcwv-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-newcwv-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Sep 18 07:29:36 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 827C01A8820; Thu, 18 Sep 2014 07:29:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.853 X-Spam-Level: X-Spam-Status: No, score=-5.853 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.652, SPF_PASS=-0.001] autolearn=ham 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 vWZswK8zEXya; Thu, 18 Sep 2014 07:29:32 -0700 (PDT) Received: from spey.erg.abdn.ac.uk (spey.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id 9D7801A882C; Thu, 18 Sep 2014 07:29:23 -0700 (PDT) Received: from www.erg.abdn.ac.uk (blake.erg.abdn.ac.uk [139.133.210.30]) by spey.erg.abdn.ac.uk (Postfix) with ESMTPSA id EF1442B4484; Thu, 18 Sep 2014 15:29:22 +0100 (BST) Received: from 212.159.18.54 (SquirrelMail authenticated user gorry) by www.erg.abdn.ac.uk with HTTP; Thu, 18 Sep 2014 15:29:22 +0100 Message-ID: <0db9fb03774c3c5002530064864d496e.squirrel@www.erg.abdn.ac.uk> In-Reply-To: <20140913074311.28129.72796.idtracker@ietfa.amsl.com> References: <20140913074311.28129.72796.idtracker@ietfa.amsl.com> Date: Thu, 18 Sep 2014 15:29:22 +0100 From: gorry@erg.abdn.ac.uk To: internet-drafts@ietf.org User-Agent: SquirrelMail/1.4.22 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/t3CPlsX8JFEMyxVP58HqESiif7E Cc: "tcpm-chairs@tools.ietf.org" Subject: [tcpm] New Version - draft-ietf-tcpm-newcwv-07.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Sep 2014 14:29:34 -0000 The authors have submitted this update to CWV: - It updates text on ECN to clarify the process where R is a reduction based on ECN marks, and with the expectation this aligns better the current work on ECN within TCPM. -It notes that cwnd shouldn't be reduced below one MSS. - It also contains very minor changes to addresses all the current issues noted with the draft. We'd like to hear comments on this version. Gorry & Co-authors > > A new version (-07) has been submitted for draft-ietf-tcpm-newcwv: > http://www.ietf.org/internet-drafts/draft-ietf-tcpm-newcwv-07.txt > > > The IETF datatracker page for this Internet-Draft is: > https://datatracker.ietf.org/doc/draft-ietf-tcpm-newcwv/ > > Diff from previous version: > http://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-newcwv-07 > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > IETF Secretariat. > From nobody Fri Sep 19 05:29:41 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F007E1A00FA for ; Fri, 19 Sep 2014 05:29:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no 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 JFglY52k17_C for ; Fri, 19 Sep 2014 05:29:37 -0700 (PDT) Received: from kirsi1.inet.fi (mta-out1.inet.fi [62.71.2.234]) by ietfa.amsl.com (Postfix) with ESMTP id D47C21A0109 for ; Fri, 19 Sep 2014 05:29:36 -0700 (PDT) Received: from t40700-la020.org.aalto.fi (130.233.145.22) by kirsi1.inet.fi (8.5.142.08) (authenticated as saropa-1) id 5409BC7D015A2DC0 for tcpm@ietf.org; Fri, 19 Sep 2014 15:29:35 +0300 From: Pasi Sarolahti Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: Date: Fri, 19 Sep 2014 15:29:35 +0300 To: "tcpm@ietf.org (tcpm@ietf.org)" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/oGj54qhfAT4p2LaB1x2e1qUuzYQ Subject: [tcpm] WG adoption of draft-touch-tcpm-tcp-edo X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Sep 2014 12:29:39 -0000 Hi, The Extended Data Offset Option draft (draft-touch-tcpm-tcp-edo) was = discussed in the last IETF meeting, and there was a clear consensus in = favor of adopting the draft as a TCPM working group item. Therefore, = this mail confirms the adoption of the draft as a working group item. Among the co-chairs, and our AD Martin, we discussed the intended status = for the document. We thought that the draft should be targeted as = Proposed Standard, even though in the meeting there were also other = opinions. There does not seem to be any obvious experimentation that the = document would require, introducing a fairly straight-forward protocol = mechanism to extend the option space. Middlebox interactions were = discussed, and that certainly is an operational issue to be found out, = but not necessarily a reason to make the document experimental. On the = other hand, we hope that the intended PS status would encourage thorough = review and implementations. We are not in a hurry to push this document = for publication, so we should have enough maturation time for this. So authors: please submit the next version as draft-ietf-tcpm-tcp-edo. - Pasi, Michael, Yoshifumi From nobody Fri Sep 19 05:41:19 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1790F1A8759 for ; Thu, 18 Sep 2014 03:53:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 ciNWt2wyNtpP for ; Thu, 18 Sep 2014 03:53:05 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 01AEB1A875C for ; Thu, 18 Sep 2014 03:53:04 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: tcpm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p6 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140918105304.17892.96320.idtracker@ietfa.amsl.com> Date: Thu, 18 Sep 2014 03:53:04 -0700 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/WsmCTpXsd8feDFcVgRTz52uNYNw X-Mailman-Approved-At: Fri, 19 Sep 2014 05:41:17 -0700 Subject: [tcpm] Milestones changed for tcpm WG X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Sep 2014 10:53:07 -0000 Changed milestone "Submit document on a TCP Extended Data Offset Option to the IESG as a Proposed Standard RFC", set state to active from review, accepting new milestone. URL: http://datatracker.ietf.org/wg/tcpm/charter/ From nobody Fri Sep 19 12:18:03 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 138011A04B0; Fri, 19 Sep 2014 12:18:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.554 X-Spam-Level: X-Spam-Status: No, score=-108.554 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.652, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham 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 VTEJd2zJWVln; Fri, 19 Sep 2014 12:17:59 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) by ietfa.amsl.com (Postfix) with ESMTP id 55F941A0696; Fri, 19 Sep 2014 12:17:59 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id A3AE918253F; Fri, 19 Sep 2014 12:17:16 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 6000:ams_util_lib.php From: rfc-editor@rfc-editor.org Message-Id: <20140919191716.A3AE918253F@rfc-editor.org> Date: Fri, 19 Sep 2014 12:17:16 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/9RnmcisPN9Un94xSmg4-fjAnwIc Cc: drafts-update-ref@iana.org, tcpm@ietf.org, rfc-editor@rfc-editor.org Subject: [tcpm] RFC 7323 on TCP Extensions for High Performance X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Sep 2014 19:18:01 -0000 A new Request for Comments is now available in online RFC libraries. RFC 7323 Title: TCP Extensions for High Performance Author: D. Borman, B. Braden, V. Jacobson, R. Scheffenegger, Ed. Status: Standards Track Stream: IETF Date: September 2014 Mailbox: david.borman@quantum.com, braden@isi.edu, vanj@google.com, rs@netapp.com Pages: 49 Characters: 106013 Obsoletes: RFC 1323 I-D Tag: draft-ietf-tcpm-1323bis-21.txt URL: https://www.rfc-editor.org/rfc/rfc7323.txt This document specifies a set of TCP extensions to improve performance over paths with a large bandwidth * delay product and to provide reliable operation over very high-speed paths. It defines the TCP Window Scale (WS) option and the TCP Timestamps (TS) option and their semantics. The Window Scale option is used to support larger receive windows, while the Timestamps option can be used for at least two distinct mechanisms, Protection Against Wrapped Sequences (PAWS) and Round-Trip Time Measurement (RTTM), that are also described herein. This document obsoletes RFC 1323 and describes changes from it. This document is a product of the TCP Maintenance and Minor Extensions Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Fri Sep 19 15:30:12 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E472A1A88BD for ; Fri, 19 Sep 2014 15:30:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.552 X-Spam-Level: X-Spam-Status: No, score=-3.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.652] autolearn=ham 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 fYC6MPHe2MLV for ; Fri, 19 Sep 2014 15:30:10 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1EB8F1A6F34 for ; Fri, 19 Sep 2014 15:30:10 -0700 (PDT) Received: from [128.9.160.81] (nib.isi.edu [128.9.160.81]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id s8JMTjB0001732 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 19 Sep 2014 15:29:45 -0700 (PDT) Message-ID: <541CAE5B.7010103@isi.edu> Date: Fri, 19 Sep 2014 15:29:47 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Pasi Sarolahti , "tcpm@ietf.org (tcpm@ietf.org)" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/eXML5H_Faqyz12AtzmqXyPVQ_ac Subject: Re: [tcpm] WG adoption of draft-touch-tcpm-tcp-edo X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Sep 2014 22:30:12 -0000 Hi, Pasi, et al., AOK - will do. Joe On 9/19/2014 5:29 AM, Pasi Sarolahti wrote: > Hi, > > The Extended Data Offset Option draft (draft-touch-tcpm-tcp-edo) was > discussed in the last IETF meeting, and there was a clear consensus in > favor of adopting the draft as a TCPM working group item. Therefore, > this mail confirms the adoption of the draft as a working group item. > > Among the co-chairs, and our AD Martin, we discussed the intended > status for the document. We thought that the draft should be targeted as > Proposed Standard, even though in the meeting there were also other > opinions. There does not seem to be any obvious experimentation that the > document would require, introducing a fairly straight-forward protocol > mechanism to extend the option space. Middlebox interactions were > discussed, and that certainly is an operational issue to be found out, > but not necessarily a reason to make the document experimental. On the > other hand, we hope that the intended PS status would encourage thorough > review and implementations. We are not in a hurry to push this document > for publication, so we should have enough maturation time for this. > > So authors: please submit the next version as > draft-ietf-tcpm-tcp-edo. > > - Pasi, Michael, Yoshifumi > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > From nobody Mon Sep 22 10:00:18 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 991BC1A1B64 for ; Mon, 22 Sep 2014 09:59:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.688 X-Spam-Level: X-Spam-Status: No, score=-7.688 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.786, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 KbZNlkxy34vx for ; Mon, 22 Sep 2014 09:59:44 -0700 (PDT) Received: from mx11.netapp.com (mx11.netapp.com [216.240.18.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E9D21A1B4E for ; Mon, 22 Sep 2014 09:59:41 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.04,572,1406617200"; d="asc'?scan'208";a="153187708" Received: from hioexcmbx05-prd.hq.netapp.com ([10.122.105.38]) by mx11-out.netapp.com with ESMTP; 22 Sep 2014 09:59:40 -0700 Received: from HIOEXCMBX06-PRD.hq.netapp.com (10.122.105.39) by hioexcmbx05-prd.hq.netapp.com (10.122.105.38) with Microsoft SMTP Server (TLS) id 15.0.913.22; Mon, 22 Sep 2014 09:58:41 -0700 Received: from HIOEXCMBX06-PRD.hq.netapp.com ([::1]) by hioexcmbx06-prd.hq.netapp.com ([fe80::20d9:8f0e:9660:40ad%21]) with mapi id 15.00.0913.011; Mon, 22 Sep 2014 09:58:40 -0700 From: "Zimmermann, Alexander" To: "gorry@erg.abdn.ac.uk" Thread-Topic: [tcpm] New Version - draft-ietf-tcpm-newcwv-07.txt Thread-Index: AQHP00zq8EvvuvtTpEywMpP3IrDTc5wN2+AA Date: Mon, 22 Sep 2014 16:58:40 +0000 Message-ID: References: <20140913074311.28129.72796.idtracker@ietfa.amsl.com> <0db9fb03774c3c5002530064864d496e.squirrel@www.erg.abdn.ac.uk> In-Reply-To: <0db9fb03774c3c5002530064864d496e.squirrel@www.erg.abdn.ac.uk> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.1878.6) x-originating-ip: [10.122.56.79] Content-Type: multipart/signed; boundary="Apple-Mail=_EBB37531-4BE1-442E-96C8-C52A973F2834"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/6Nnh0AdngPPtYzGxF--cdv0Mryc Cc: "tcpm@ietf.org Extensions" Subject: Re: [tcpm] New Version - draft-ietf-tcpm-newcwv-07.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Sep 2014 16:59:51 -0000 --Apple-Mail=_EBB37531-4BE1-442E-96C8-C52A973F2834 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi Gorry, C&P from the TCPM 90 minutes: "Yuchung: Linux uses different algorithm to detect cwnd limited. We recently submitted a patch. What are your comments about the difference of the two? How does this interact with TSO? =20 Gorry: I don't know it. =20 Yuchung: Let's take it offline. =20 Gorry: Is it likely to change the spec? =20 Yuchung: We believe our idea is probably simpler. Yours is more difficult to implement. Linux uses TSO which creates a different way to see if cwnd is limited. These are interesting issues to consider which are not addressed in this draft.=93 Gorry can you comment on this? Is this already discussed w/ Yuchung? Can change the draft to reflect his ideas or is this completely incompatible w/ NewCVW? Greetings Alex Am 18.09.2014 um 10:29 schrieb gorry@erg.abdn.ac.uk: >=20 > The authors have submitted this update to CWV: >=20 > - It updates text on ECN to clarify the process where R is a reduction > based on ECN marks, and with the expectation this aligns better the > current work on ECN within TCPM. >=20 > -It notes that cwnd shouldn't be reduced below one MSS. >=20 > - It also contains very minor changes to addresses all the current = issues > noted with the draft. >=20 > We'd like to hear comments on this version. >=20 > Gorry & Co-authors >=20 >>=20 >> A new version (-07) has been submitted for draft-ietf-tcpm-newcwv: >> http://www.ietf.org/internet-drafts/draft-ietf-tcpm-newcwv-07.txt >>=20 >>=20 >> The IETF datatracker page for this Internet-Draft is: >> https://datatracker.ietf.org/doc/draft-ietf-tcpm-newcwv/ >>=20 >> Diff from previous version: >> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tcpm-newcwv-07 >>=20 >> Please note that it may take a couple of minutes from the time of >> submission >> until the htmlized version and diff are available at tools.ietf.org. >>=20 >> IETF Secretariat. >>=20 >=20 >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm --Apple-Mail=_EBB37531-4BE1-442E-96C8-C52A973F2834 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlQgVW4ACgkQdyiq39b9uS4BCQCcC0KvRfRufznWJvX0iy99MJ3C dXwAn0RAv0K6Nh/r3iCRprYVL9OlgISB =BsXM -----END PGP SIGNATURE----- --Apple-Mail=_EBB37531-4BE1-442E-96C8-C52A973F2834-- From nobody Mon Sep 22 12:41:02 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 776651A1BA2 for ; Mon, 22 Sep 2014 12:41:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.164 X-Spam-Level: X-Spam-Status: No, score=-2.164 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=ham 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 xK-F2Itw3mcq for ; Mon, 22 Sep 2014 12:40:58 -0700 (PDT) Received: from mail-ie0-x22d.google.com (mail-ie0-x22d.google.com [IPv6:2607:f8b0:4001:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 67F271A1B35 for ; Mon, 22 Sep 2014 12:40:58 -0700 (PDT) Received: by mail-ie0-f173.google.com with SMTP id tr6so8231110ieb.18 for ; Mon, 22 Sep 2014 12:40:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:references:from:date:message-id:subject:to:cc :content-type; bh=L4tDQFOCHcfRZ+Mv1hA1QXUrFEzlNuQVkiacRzryeKU=; b=DgkrsI63E/r9OeClrm+BHcn7JKMjWh8HXfrKW15AD1Rm/PW2BAdot6AF85D/6ad6dT tAxwDJHAETS2gFsQuOaNfWzzZ30SzHmjmM1Jl/5q1mCZ1yEedXNKaO4knsfjr9Z6Esx6 By/+//z+Y2z0Z/a0bdIl1VG9n5mkYuLbGxb9fMY0kRkWCpMhoRkq1O9oYAUj2qvZjPt2 4zr6xhtCdyUHXXq6JGzZ0q4z1j4oKSP8f1Z1dq4dKjDobEKPlrRfAx+b6TSfmcxryTDi z/Y1zM48U9zumcFKf8jFeGP0QlLYvNwsfoh2qKMgtuR+6FFCC4tD3OjMuMjYTG77e4S4 PNFA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:from:date:message-id :subject:to:cc:content-type; bh=L4tDQFOCHcfRZ+Mv1hA1QXUrFEzlNuQVkiacRzryeKU=; b=Y/dhMzri78aOqLKzoLu5cwAiH6Iynf5JHw4GKpuOQST5DQybSTdvMrBi3Dy5HwEaos l6eeZfVHz1/P11L/VH9y5tSs/JZ8rN39C/uXFBza/OUUcuugVoZHZz3b4UcdBB9SjpiD ZWme1mV3Eo9NPPYyl2GjXju7GHUi00k5tvmlVUDm1F/dCzHursqv6VybDDxaHeD/TiSd q1F0GFD/oElvin5atb3Fmq4lZvU0jvm17fdKmkOYHJyPiATDFRlfWxNAIAawS9wYTQ/k spxaigPyjutiM0GHcCxN5p6hs7IdBfLE9m4q72bAYhvF2fPsimNh7+zVruV9X9WrkZKq 80yQ== X-Gm-Message-State: ALoCoQk22l5wOH6aww0CHycxwNjA2DqjDZHEUnPJgLzES/5B2RCeAR0LMyQmmoVR+OiRJdufeofb X-Received: by 10.43.165.133 with SMTP id mw5mr18160084icc.35.1411414857618; Mon, 22 Sep 2014 12:40:57 -0700 (PDT) MIME-Version: 1.0 References: <20140913074311.28129.72796.idtracker@ietfa.amsl.com> <0db9fb03774c3c5002530064864d496e.squirrel@www.erg.abdn.ac.uk> From: Yuchung Cheng Date: Mon, 22 Sep 2014 19:40:57 +0000 Message-ID: To: "Zimmermann, Alexander" , "gorry@erg.abdn.ac.uk" Content-Type: multipart/alternative; boundary=001a11c254c83833ac0503aca1a2 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/BwXaDLBoi2jErnCjBSzY4giGHr4 Cc: "tcpm@ietf.org Extensions" Subject: Re: [tcpm] New Version - draft-ietf-tcpm-newcwv-07.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Sep 2014 19:41:00 -0000 --001a11c254c83833ac0503aca1a2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon Sep 22 2014 at 10:00:17 AM Zimmermann, Alexander < Alexander.Zimmermann@netapp.com> wrote: > Hi Gorry, > > C&P from the TCPM 90 minutes: > > "Yuchung: Linux uses different algorithm to detect cwnd limited. We > recently submitted a patch. What are your comments about the > difference of the two? How does this interact with TSO? > > Gorry: I don't know it. > > Yuchung: Let's take it offline. > > Gorry: Is it likely to change the spec? > > Yuchung: We believe our idea is probably simpler. Yours is more > difficult to implement. Linux uses TSO which creates a different way > to see if cwnd is limited. These are interesting issues to consider > which are not addressed in this draft.=E2=80=9C > > Gorry can you comment on this? Is this already discussed w/ Yuchung? > Can change the draft to reflect his ideas or is this completely > incompatible w/ NewCVW? > Gorry did reach to me and Neal but we couldn't quite parse the long email so we didn't make much progress. The latest Linux uses an algorithm by Neal Cardwell that incidentally is similar to the proposed newcwv draft sec 4.2. The key differences are 1) it uses FlightSize instead of the pipe variable 2) it takes care of the TSO deferral. The TSO deferral part is important because TCP may not always fill cwnd in order to build bigger packet. http://patchwork.ozlabs.org/patch/351512/ Note there is a preceeding bug-fix patch done by Eric Dumazet, where TSO and TCP small queue, could trick TCP not to slow start fast. This demonstrates the complexity to determine if TCP is cwnd limited or not, in modern networking stack. http://patchwork.ozlabs.org/patch/344293/ Linux does not implement newcwv. I guess it's not clear if the other parts are useful or not, other than not being so conservative in growing cwnd. Lastly, I would recommend newcwv draft to be more specific on the algorithm in Sec 4.2. HTH > > Greetings > Alex > > Am 18.09.2014 um 10:29 schrieb gorry@erg.abdn.ac.uk: > > > > > The authors have submitted this update to CWV: > > > > - It updates text on ECN to clarify the process where R is a reduction > > based on ECN marks, and with the expectation this aligns better the > > current work on ECN within TCPM. > > > > -It notes that cwnd shouldn't be reduced below one MSS. > > > > - It also contains very minor changes to addresses all the current issu= es > > noted with the draft. > > > > We'd like to hear comments on this version. > > > > Gorry & Co-authors > > > >> > >> A new version (-07) has been submitted for draft-ietf-tcpm-newcwv: > >> http://www.ietf.org/internet-drafts/draft-ietf-tcpm-newcwv-07.txt > >> > >> > >> The IETF datatracker page for this Internet-Draft is: > >> https://datatracker.ietf.org/doc/draft-ietf-tcpm-newcwv/ > >> > >> Diff from previous version: > >> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tcpm-newcwv-07 > >> > >> Please note that it may take a couple of minutes from the time of > >> submission > >> until the htmlized version and diff are available at tools.ietf.org. > >> > >> IETF Secretariat. > >> > > > > > > _______________________________________________ > > tcpm mailing list > > tcpm@ietf.org > > https://www.ietf.org/mailman/listinfo/tcpm > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > --001a11c254c83833ac0503aca1a2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Mon Sep 22 2014 at 10:00:17 AM Zimmer= mann, Alexander <Alex= ander.Zimmermann@netapp.com> wrote:
http://patchwork.ozlabs.org/patch= /351512/

Note there is a preceeding bug-fi= x patch done by Eric Dumazet, where TSO and TCP small queue, could trick TC= P not to slow start fast. This demonstrates the complexity to determine if = TCP is cwnd limited or not, in modern networking stack.


Linux does not = implement newcwv. I guess it's not clear if the other parts are useful = or not, other than not being so conservative in growing cwnd. Lastly, I wou= ld recommend newcwv draft to be more specific on the algorithm in Sec 4.2.= =C2=A0

HTH

=C2=A0

Greetings
Alex

Am 18.09.2014 um 10:29 schrieb gorry@erg.abdn.ac.uk:

>
> The authors have submitted this update to CWV:
>
> - It updates text on ECN to clarify the process where R is a reduction=
> based on ECN marks, and with the expectation this aligns better the > current work on ECN within TCPM.
>
> -It notes that cwnd shouldn't be reduced below one MSS.
>
> - It also contains very minor changes to addresses all the current iss= ues
> noted with the draft.
>
> We'd like to hear comments on this version.
>
> Gorry & Co-authors
>
>>
>> A new version (-07) has been submitted for draft-ietf-tcpm-newcwv:=
>> http://www.ietf.org/internet-drafts/dr= aft-ietf-tcpm-newcwv-07.txt
>>
>>
>> The IETF datatracker page for this Internet-Draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-tcp= m-newcwv/
>>
>> Diff from previous version:
>> http://www.ietf.org/rfcdiff?url2=3Ddraft-ie= tf-tcpm-newcwv-07
>>
>> Please note that it may take a couple of minutes from the time of<= br> >> submission
>> until the htmlized version and diff are available at tools.ietf.org.
>>
>> IETF Secretariat.
>>
>
>
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm

_______________________________________________
tcpm mailing list
tcpm@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/tcpm
--001a11c254c83833ac0503aca1a2-- From nobody Mon Sep 22 13:45:48 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADBAF1A1AC1 for ; Mon, 22 Sep 2014 13:45:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.905 X-Spam-Level: X-Spam-Status: No, score=0.905 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DATE_IN_PAST_03_06=1.592, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=ham 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 XWWZbYDDuvUj for ; Mon, 22 Sep 2014 13:45:44 -0700 (PDT) Received: from hubrelay-rd.bt.com (hubrelay-rd.bt.com [62.239.224.99]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A8841A1AC6 for ; Mon, 22 Sep 2014 13:45:43 -0700 (PDT) Received: from EVMHR71-UKRD.domain1.systemhost.net (10.36.3.109) by EVMHR68-UKRD.bt.com (10.187.101.23) with Microsoft SMTP Server (TLS) id 8.3.348.2; Mon, 22 Sep 2014 21:45:40 +0100 Received: from EPHR01-UKIP.domain1.systemhost.net (147.149.196.177) by EVMHR71-UKRD.domain1.systemhost.net (10.36.3.109) with Microsoft SMTP Server (TLS) id 8.3.348.2; Mon, 22 Sep 2014 21:45:40 +0100 Received: from bagheera.jungle.bt.co.uk (132.146.168.158) by EPHR01-UKIP.domain1.systemhost.net (147.149.196.177) with Microsoft SMTP Server id 14.3.181.6; Mon, 22 Sep 2014 21:45:37 +0100 Received: from BTP075694.jungle.bt.co.uk ([10.111.37.220]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id s8MKjZdD002071; Mon, 22 Sep 2014 21:45:36 +0100 Message-ID: <201409222045.s8MKjZdD002071@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 22 Sep 2014 15:55:42 +0100 To: Joe Touch From: Bob Briscoe MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/KF6s_6ma-3T9W_IWY16x3BZodxg Cc: tcpm IETF list Subject: [tcpm] More TCP option space in a SYN: draft-briscoe-tcpm-syn-op-sis-02 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Sep 2014 20:45:46 -0000 Joe, I've just posted a revision here: * I've taken more care to explain it. It was a bit terse before. So it's ready for the list to review properly now. It would be useful if someone wrote a comparison with the other ideas on how to do this, including the ones we wrote jointly and SLO, LOIC and DBormam's 4-way HS. Better someone independent of all the authors does this. But I want to get syn-op-sis right first, a comparison won't be much use until its stable. The underlying idea is still the same. The reasons I've updated it are many (the change log taken from the appendix is pasted at the end of this email for convenience). * Mainly I've articulated that all these approaches that add TCP options after the Data Offset are not just hacks to get more space; they add a new architectural capability to TCP - a distinction between TCP options that might be relevant to middleboxes, and ones that are only for the destination (a bit like destopt in IPv6 - needing to specify which TCP options are for the destination only is ironic but necessary). * I've also realised that this approach will ultimately return to a single SYN solution, whereas both the ideas in draft-touch-tcpm-tcp-syn-ext-opt will always require two SYNs. Bob Pasted from the change log: From briscoe...-01 to briscoe...-02: Technical changes: * Defined the client behaviour dependent on which response arrives first. * Allowed retransmission of either SYN or SYN-U if no response from either. * Redefined EOO as an offset from the end of the packet, not from the beginning of the payload. * Added section on Migration to a Single Handshake. Reworded dual handshake so that it is not mandatory for the client to send dual SYNs simultaneously; only the relation between the SYNs and the response to either is mandatory, while parallel SYNs is purely for latency reduction. * Added rules for writing TCP options, i.e. i) options like TFO MUST NOT be located in the TCP header and ii) add no-ops to align on 4-octet boundary. * Added rules for forwarding TCP options, i.e. only the destination looks for TCP options after the Data Offset, not middleboxes. * Moved the Explicit Handshake variant (SYN-L) into the body from the appendix, and recommended the choice could be down to implementers or apps. Included section on corner cases. * Introduced more normative language throughout the Protocol Spec. Editorial changes: * Added temporary motivation section * Added confusible terminology to Terminology section. * Divided protocol spec into sub-sections. * Handshake table: Clarified that the two columns under each server represent separate threads, that may run on separate servers, without co-ordination. Represented message dependencies in the alignment of the rows. * Explained the table. * Explained why a legacy server won't ever pass SYN-U to the app. * More precisely described loss as 'not arrived before a timeout', and explained the tradeoff between latency and extra TCP options. * Gave reasoning for locating TCP options in three groups. * Acknowledged Rob Hancock for the architectural idea of hiding an extension to a protocol in the layer above. * Appendix about protocol alternatives now only presents the SYN- UD alternative, given the implicit/explicit handshake choice has been moved to the body. * Rewrote appendix about comparing the choices to treat the two pairs of choices separately, rather than discussing all four combinations of pairs of choices. ________________________________________________________________ Bob Briscoe, BT From nobody Tue Sep 23 13:43:50 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67D321A88C4 for ; Tue, 23 Sep 2014 13:43:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.286 X-Spam-Level: X-Spam-Status: No, score=-2.286 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786] autolearn=ham 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 HXscWdKbowqg for ; Tue, 23 Sep 2014 13:43:42 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id A4F201A1B5D for ; Tue, 23 Sep 2014 13:43:42 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id A91B2C94BE; Tue, 23 Sep 2014 16:43:39 -0400 (EDT) Date: Tue, 23 Sep 2014 16:43:39 -0400 From: John Leslie To: Bob Briscoe Message-ID: <20140923204339.GE83009@verdi> References: <201409222045.s8MKjZdD002071@bagheera.jungle.bt.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201409222045.s8MKjZdD002071@bagheera.jungle.bt.co.uk> User-Agent: Mutt/1.4.1i Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/7RUDbvNnkU-fq80yiTAt_Cf8JJ4 Cc: tcpm IETF list , Joe Touch Subject: Re: [tcpm] draft-briscoe-tcpm-syn-op-sis-02 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Sep 2014 20:43:46 -0000 Bob Briscoe wrote: > > I've just posted a revision here: > > > * I've taken more care to explain it. It was a bit terse before. So > it's ready for the list to review properly now. I won't claim to have read the whole thing (24 pages); but I think I've read enough to justify a quick response (and I have a meeting startig soon). Bob, as usual, has a very good idea -- if a bit over-complicated. Placing the additional options at the end of the packet has real promise. I recommend that the response (acknowledging the SYN-U option) include a checksum or hash to verify what additional options have been received. I strongly recommend against trying to integrate this with the already adopted after-the-initial-SYN draft. Much of the complexity is inevitable, alas, but a rewrite to change the order of presentation and remove any differences in the data on-the-wire would really help both comprehension and adoption, IMHO. Also, in the interests of attracting adoption, I'd recommend first presenting the case we hope to finally achieve -- a single connection opened with the SYN-U -- immediately followed with a list of problems we may see. Then in sections following, we can introduce the overlapping-SYNs hack and other work-arounds. (IMHO there's nothing wrong with initial experiments which do NOT use the overlappingSYNs.) More tomorrow... -- John Leslie From nobody Wed Sep 24 15:26:43 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A21F81A1ADD for ; Wed, 24 Sep 2014 15:26:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.986 X-Spam-Level: X-Spam-Status: No, score=-4.986 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786] autolearn=ham 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 sjJlpIESbBPt for ; Wed, 24 Sep 2014 15:26:31 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 36A421A1AC8 for ; Wed, 24 Sep 2014 15:26:31 -0700 (PDT) Received: from [128.9.160.211] (mul.isi.edu [128.9.160.211]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id s8OMPU09003034 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 24 Sep 2014 15:25:31 -0700 (PDT) Message-ID: <542344DA.9020905@isi.edu> Date: Wed, 24 Sep 2014 15:25:30 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 MIME-Version: 1.0 To: Bob Briscoe References: <201409222045.s8MKjZdD002071@bagheera.jungle.bt.co.uk> In-Reply-To: <201409222045.s8MKjZdD002071@bagheera.jungle.bt.co.uk> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/i_toq9EpEdlsyWD01ZK_GbmTsDs Cc: tcpm IETF list Subject: Re: [tcpm] More TCP option space in a SYN: draft-briscoe-tcpm-syn-op-sis-02 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Sep 2014 22:26:34 -0000 Hi, Bob (et al.), It's good to have a more detailed description of the proposal. I still find a dual-SYN solution untenable, though, as it has been for other upgrade paths in the past (e.g., IPv6). Also, I don't particularly think that putting the options at the end of the segment serves any useful purpose other than to make this option handle the option space in a different way than the default DO header field. I'm glad to hear what others think and agree that an unbiased comparison of the approaches would be a useful place to for the discussion to start... Joe On 9/22/2014 7:55 AM, Bob Briscoe wrote: > Joe, > > I've just posted a revision here: > > > * I've taken more care to explain it. It was a bit terse before. So it's > ready for the list to review properly now. > > It would be useful if someone wrote a comparison with the other ideas on > how to do this, including the ones we wrote jointly and SLO, LOIC and > DBormam's 4-way HS. Better someone independent of all the authors does > this. But I want to get syn-op-sis right first, a comparison won't be > much use until its stable. > > > The underlying idea is still the same. The reasons I've updated it are > many (the change log taken from the appendix is pasted at the end of > this email for convenience). > > * Mainly I've articulated that all these approaches that add TCP options > after the Data Offset are not just hacks to get more space; they add a > new architectural capability to TCP - a distinction between TCP options > that might be relevant to middleboxes, and ones that are only for the > destination (a bit like destopt in IPv6 - needing to specify which TCP > options are for the destination only is ironic but necessary). > > * I've also realised that this approach will ultimately return to a > single SYN solution, whereas both the ideas in > draft-touch-tcpm-tcp-syn-ext-opt will always require two SYNs. > > > > Bob > > Pasted from the change log: > > From briscoe...-01 to briscoe...-02: > > Technical changes: > > * Defined the client behaviour dependent on which response > arrives first. > > * Allowed retransmission of either SYN or SYN-U if no response > from either. > > * Redefined EOO as an offset from the end of the packet, not from > the beginning of the payload. > > * Added section on Migration to a Single Handshake. Reworded > dual handshake so that it is not mandatory for the client to > send dual SYNs simultaneously; only the relation between the > SYNs and the response to either is mandatory, while parallel > SYNs is purely for latency reduction. > > * Added rules for writing TCP options, i.e. i) options like TFO > MUST NOT be located in the TCP header and ii) add no-ops to > align on 4-octet boundary. > > * Added rules for forwarding TCP options, i.e. only the > destination looks for TCP options after the Data Offset, not > middleboxes. > > * Moved the Explicit Handshake variant (SYN-L) into the body from > the appendix, and recommended the choice could be down to > implementers or apps. Included section on corner cases. > > * Introduced more normative language throughout the Protocol > Spec. > > Editorial changes: > > * Added temporary motivation section > > * Added confusible terminology to Terminology section. > > * Divided protocol spec into sub-sections. > > * Handshake table: Clarified that the two columns under each > server represent separate threads, that may run on separate > servers, without co-ordination. Represented message > dependencies in the alignment of the rows. > > * Explained the table. > > * Explained why a legacy server won't ever pass SYN-U to the app. > > * More precisely described loss as 'not arrived before a > timeout', and explained the tradeoff between latency and extra > TCP options. > > * Gave reasoning for locating TCP options in three groups. > > * Acknowledged Rob Hancock for the architectural idea of hiding > an extension to a protocol in the layer above. > > * Appendix about protocol alternatives now only presents the SYN- > UD alternative, given the implicit/explicit handshake choice > has been moved to the body. > > * Rewrote appendix about comparing the choices to treat the two > pairs of choices separately, rather than discussing all four > combinations of pairs of choices. > > ________________________________________________________________ > Bob Briscoe, BT From nobody Thu Sep 25 02:56:50 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EF2E1A6F27 for ; Thu, 25 Sep 2014 02:56:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.387 X-Spam-Level: X-Spam-Status: No, score=-3.387 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=ham 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 71VqdtR9Xt1C for ; Thu, 25 Sep 2014 02:56:44 -0700 (PDT) Received: from hubrelay-rd.bt.com (hubrelay-rd.bt.com [62.239.224.99]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C49D1A1BEE for ; Thu, 25 Sep 2014 02:56:44 -0700 (PDT) Received: from EVMHR02-UKBR.domain1.systemhost.net (193.113.108.41) by EVMHR68-UKRD.bt.com (10.187.101.23) with Microsoft SMTP Server (TLS) id 8.3.348.2; Thu, 25 Sep 2014 10:56:42 +0100 Received: from EPHR02-UKIP.domain1.systemhost.net (147.149.100.81) by EVMHR02-UKBR.domain1.systemhost.net (193.113.108.41) with Microsoft SMTP Server (TLS) id 8.3.348.2; Thu, 25 Sep 2014 10:56:41 +0100 Received: from bagheera.jungle.bt.co.uk (132.146.168.158) by EPHR02-UKIP.domain1.systemhost.net (147.149.100.81) with Microsoft SMTP Server id 14.3.181.6; Thu, 25 Sep 2014 10:56:37 +0100 Received: from BTP075694.jungle.bt.co.uk ([10.215.130.93]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id s8P9uae9013452; Thu, 25 Sep 2014 10:56:36 +0100 Message-ID: <201409250956.s8P9uae9013452@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 25 Sep 2014 10:56:35 +0100 To: Joe Touch From: Bob Briscoe In-Reply-To: <542344DA.9020905@isi.edu> References: <201409222045.s8MKjZdD002071@bagheera.jungle.bt.co.uk> <542344DA.9020905@isi.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/ggvmj6HdonQBYfqf621WsaOfkmQ Cc: tcpm IETF list Subject: Re: [tcpm] More TCP option space in a SYN: draft-briscoe-tcpm-syn-op-sis-02 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Sep 2014 09:56:47 -0000 Joe, At 23:25 24/09/2014, Joe Touch wrote: >Hi, Bob (et al.), > >It's good to have a more detailed description of the proposal. > >I still find a dual-SYN solution untenable, though, as it has been for >other upgrade paths in the past (e.g., IPv6). That's why I prefer syn-op-sis because it only uses 2 SYNs for transition. I've included a new section on ways to use only 1 SYN during transition (building a white-list) and ultimately moving to 1 SYN in the future, only falling back to the legacy SYN in series rather than parallel if you hit a legacy listener. The other two in tcp-syn-ext-opt have to be 2-SYN for ever. >Also, I don't particularly think that putting the options at the end of >the segment serves any useful purpose other than to make this option >handle the option space in a different way than the default DO header field. That's the architectural point. There's also a tactical point. It should get through every middlebox. >I'm glad to hear what others think and agree that an unbiased comparison >of the approaches would be a useful place to for the discussion to start... Yes, I'm already repeating myself - you're right we need wider opinions. Bob >Joe > >On 9/22/2014 7:55 AM, Bob Briscoe wrote: > > Joe, > > > > I've just posted a revision here: > > > > > > * I've taken more care to explain it. It was a bit terse before. So it's > > ready for the list to review properly now. > > > > It would be useful if someone wrote a comparison with the other ideas on > > how to do this, including the ones we wrote jointly and SLO, LOIC and > > DBormam's 4-way HS. Better someone independent of all the authors does > > this. But I want to get syn-op-sis right first, a comparison won't be > > much use until its stable. > > > > > > The underlying idea is still the same. The reasons I've updated it are > > many (the change log taken from the appendix is pasted at the end of > > this email for convenience). > > > > * Mainly I've articulated that all these approaches that add TCP options > > after the Data Offset are not just hacks to get more space; they add a > > new architectural capability to TCP - a distinction between TCP options > > that might be relevant to middleboxes, and ones that are only for the > > destination (a bit like destopt in IPv6 - needing to specify which TCP > > options are for the destination only is ironic but necessary). > > > > * I've also realised that this approach will ultimately return to a > > single SYN solution, whereas both the ideas in > > draft-touch-tcpm-tcp-syn-ext-opt will always require two SYNs. > > > > > > > > Bob > > > > Pasted from the change log: > > > > From briscoe...-01 to briscoe...-02: > > > > Technical changes: > > > > * Defined the client behaviour dependent on which response > > arrives first. > > > > * Allowed retransmission of either SYN or SYN-U if no response > > from either. > > > > * Redefined EOO as an offset from the end of the packet, not from > > the beginning of the payload. > > > > * Added section on Migration to a Single Handshake. Reworded > > dual handshake so that it is not mandatory for the client to > > send dual SYNs simultaneously; only the relation between the > > SYNs and the response to either is mandatory, while parallel > > SYNs is purely for latency reduction. > > > > * Added rules for writing TCP options, i.e. i) options like TFO > > MUST NOT be located in the TCP header and ii) add no-ops to > > align on 4-octet boundary. > > > > * Added rules for forwarding TCP options, i.e. only the > > destination looks for TCP options after the Data Offset, not > > middleboxes. > > > > * Moved the Explicit Handshake variant (SYN-L) into the body from > > the appendix, and recommended the choice could be down to > > implementers or apps. Included section on corner cases. > > > > * Introduced more normative language throughout the Protocol > > Spec. > > > > Editorial changes: > > > > * Added temporary motivation section > > > > * Added confusible terminology to Terminology section. > > > > * Divided protocol spec into sub-sections. > > > > * Handshake table: Clarified that the two columns under each > > server represent separate threads, that may run on separate > > servers, without co-ordination. Represented message > > dependencies in the alignment of the rows. > > > > * Explained the table. > > > > * Explained why a legacy server won't ever pass SYN-U to the app. > > > > * More precisely described loss as 'not arrived before a > > timeout', and explained the tradeoff between latency and extra > > TCP options. > > > > * Gave reasoning for locating TCP options in three groups. > > > > * Acknowledged Rob Hancock for the architectural idea of hiding > > an extension to a protocol in the layer above. > > > > * Appendix about protocol alternatives now only presents the SYN- > > UD alternative, given the implicit/explicit handshake choice > > has been moved to the body. > > > > * Rewrote appendix about comparing the choices to treat the two > > pairs of choices separately, rather than discussing all four > > combinations of pairs of choices. > > > > ________________________________________________________________ > > Bob Briscoe, BT ________________________________________________________________ Bob Briscoe, BT From nobody Thu Sep 25 07:53:30 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 438DA1A6F56 for ; Thu, 25 Sep 2014 07:53:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.986 X-Spam-Level: X-Spam-Status: No, score=-4.986 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786] autolearn=ham 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 p1lyw_AR2Xc0 for ; Thu, 25 Sep 2014 07:53:25 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E3A731A00F9 for ; Thu, 25 Sep 2014 07:53:25 -0700 (PDT) Received: from [128.9.176.34] (c1-vpn4.isi.edu [128.9.176.34]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id s8PEr0Co018241 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 25 Sep 2014 07:53:00 -0700 (PDT) Message-ID: <54242C4D.9000804@isi.edu> Date: Thu, 25 Sep 2014 07:53:01 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Bob Briscoe References: <201409222045.s8MKjZdD002071@bagheera.jungle.bt.co.uk> <542344DA.9020905@isi.edu> <201409250956.s8P9uae9013452@bagheera.jungle.bt.co.uk> In-Reply-To: <201409250956.s8P9uae9013452@bagheera.jungle.bt.co.uk> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/HR1g2XUmqkffsJNjNfG4Q2RmkHw Cc: tcpm IETF list Subject: Re: [tcpm] More TCP option space in a SYN: draft-briscoe-tcpm-syn-op-sis-02 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Sep 2014 14:53:27 -0000 On 9/25/2014 2:56 AM, Bob Briscoe wrote: > Joe, > > At 23:25 24/09/2014, Joe Touch wrote: >> Hi, Bob (et al.), >> >> It's good to have a more detailed description of the proposal. >> >> I still find a dual-SYN solution untenable, though, as it has been for >> other upgrade paths in the past (e.g., IPv6). > > That's why I prefer syn-op-sis because it only uses 2 SYNs for transition. > > I've included a new section on ways to use only 1 SYN during transition > (building a white-list) and ultimately moving to 1 SYN in the future, > only falling back to the legacy SYN in series rather than parallel if > you hit a legacy listener. > > The other two in tcp-syn-ext-opt have to be 2-SYN for ever. But they don't both use two SYNs. One (that I prefer) uses an additional out-of-band segment. IMO, using two SYNs is problematic - regardless of whether the upgraded system uses both or just one. IMO, we're going to be dealing with legacy TCPs for a *very* long time. Time for others to jump in ;-) Joe From nobody Thu Sep 25 08:14:58 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94FF71A6FFC for ; Thu, 25 Sep 2014 08:14:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.688 X-Spam-Level: X-Spam-Status: No, score=-7.688 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.786, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 DDpj5ucaBkaW for ; Thu, 25 Sep 2014 08:14:55 -0700 (PDT) Received: from mx11.netapp.com (mx11.netapp.com [216.240.18.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 29C651A6FFB for ; Thu, 25 Sep 2014 08:14:55 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.04,597,1406617200"; d="asc'?scan'208";a="155553449" Received: from hioexcmbx04-prd.hq.netapp.com ([10.122.105.37]) by mx11-out.netapp.com with ESMTP; 25 Sep 2014 08:14:55 -0700 Received: from HIOEXCMBX06-PRD.hq.netapp.com (10.122.105.39) by hioexcmbx04-prd.hq.netapp.com (10.122.105.37) with Microsoft SMTP Server (TLS) id 15.0.913.22; Thu, 25 Sep 2014 08:13:47 -0700 Received: from HIOEXCMBX06-PRD.hq.netapp.com ([::1]) by hioexcmbx06-prd.hq.netapp.com ([fe80::20d9:8f0e:9660:40ad%21]) with mapi id 15.00.0913.011; Thu, 25 Sep 2014 08:13:47 -0700 From: "Zimmermann, Alexander" To: Bob Briscoe Thread-Topic: [tcpm] More TCP option space in a SYN: draft-briscoe-tcpm-syn-op-sis-02 Thread-Index: AQHP2EaESdm1As8t2kS65+j3HwAI4JwSEseAgABY4oA= Date: Thu, 25 Sep 2014 15:13:46 +0000 Message-ID: References: <201409222045.s8MKjZdD002071@bagheera.jungle.bt.co.uk> <542344DA.9020905@isi.edu> <201409250956.s8P9uae9013452@bagheera.jungle.bt.co.uk> In-Reply-To: <201409250956.s8P9uae9013452@bagheera.jungle.bt.co.uk> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.1878.6) x-originating-ip: [10.122.56.79] Content-Type: multipart/signed; boundary="Apple-Mail=_2C23F7FB-4C50-4B9E-9B8B-FF46ECC1B462"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/4cxJMhApQ6tRkjqfb491XMcLeIU Cc: tcpm IETF list , Joe Touch Subject: Re: [tcpm] More TCP option space in a SYN: draft-briscoe-tcpm-syn-op-sis-02 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Sep 2014 15:14:57 -0000 --Apple-Mail=_2C23F7FB-4C50-4B9E-9B8B-FF46ECC1B462 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Bob, Am 25.09.2014 um 05:56 schrieb Bob Briscoe : > Joe, >=20 > At 23:25 24/09/2014, Joe Touch wrote: >> Hi, Bob (et al.), >>=20 >> It's good to have a more detailed description of the proposal. >>=20 >> I still find a dual-SYN solution untenable, though, as it has been = for >> other upgrade paths in the past (e.g., IPv6). >=20 > That's why I prefer syn-op-sis because it only uses 2 SYNs for = transition. >=20 > I've included a new section on ways to use only 1 SYN during = transition (building a white-list) and ultimately moving to 1 SYN in the = future, only falling back to the legacy SYN in series rather than = parallel if you hit a legacy listener. >=20 > The other two in tcp-syn-ext-opt have to be 2-SYN for ever. >=20 >> Also, I don't particularly think that putting the options at the end = of >> the segment serves any useful purpose other than to make this option >> handle the option space in a different way than the default DO header = field. >=20 > That's the architectural point. > There's also a tactical point. It should get through every middle box. but do we have not exactly the same problem w/ TCPinc. With TCPinc we = have the problem too that a middle box doesn=92t see any understandable after = the legacy TCP header (e.g. no HTTP header after TCP port 80). So, why it=92s acceptable for TCPinc but not for extending SYN option space? BTW any tcpdump user will love to have the options in front of a segment and not at the end ;-) Alex >=20 >> I'm glad to hear what others think and agree that an unbiased = comparison >> of the approaches would be a useful place to for the discussion to = start... >=20 > Yes, I'm already repeating myself - you're right we need wider = opinions. >=20 >=20 >=20 > Bob >=20 >=20 >> Joe >>=20 >> On 9/22/2014 7:55 AM, Bob Briscoe wrote: >> > Joe, >> > >> > I've just posted a revision here: >> > >> > >> > * I've taken more care to explain it. It was a bit terse before. So = it's >> > ready for the list to review properly now. >> > >> > It would be useful if someone wrote a comparison with the other = ideas on >> > how to do this, including the ones we wrote jointly and SLO, LOIC = and >> > DBormam's 4-way HS. Better someone independent of all the authors = does >> > this. But I want to get syn-op-sis right first, a comparison won't = be >> > much use until its stable. >> > >> > >> > The underlying idea is still the same. The reasons I've updated it = are >> > many (the change log taken from the appendix is pasted at the end = of >> > this email for convenience). >> > >> > * Mainly I've articulated that all these approaches that add TCP = options >> > after the Data Offset are not just hacks to get more space; they = add a >> > new architectural capability to TCP - a distinction between TCP = options >> > that might be relevant to middleboxes, and ones that are only for = the >> > destination (a bit like destopt in IPv6 - needing to specify which = TCP >> > options are for the destination only is ironic but necessary). >> > >> > * I've also realised that this approach will ultimately return to a >> > single SYN solution, whereas both the ideas in >> > draft-touch-tcpm-tcp-syn-ext-opt will always require two SYNs. >> > >> > >> > >> > Bob >> > >> > Pasted from the change log: >> > >> > =46rom briscoe...-01 to briscoe...-02: >> > >> > Technical changes: >> > >> > * Defined the client behaviour dependent on which response >> > arrives first. >> > >> > * Allowed retransmission of either SYN or SYN-U if no = response >> > from either. >> > >> > * Redefined EOO as an offset from the end of the packet, not = from >> > the beginning of the payload. >> > >> > * Added section on Migration to a Single Handshake. = Reworded >> > dual handshake so that it is not mandatory for the client = to >> > send dual SYNs simultaneously; only the relation between = the >> > SYNs and the response to either is mandatory, while = parallel >> > SYNs is purely for latency reduction. >> > >> > * Added rules for writing TCP options, i.e. i) options like = TFO >> > MUST NOT be located in the TCP header and ii) add no-ops = to >> > align on 4-octet boundary. >> > >> > * Added rules for forwarding TCP options, i.e. only the >> > destination looks for TCP options after the Data Offset, = not >> > middleboxes. >> > >> > * Moved the Explicit Handshake variant (SYN-L) into the body = from >> > the appendix, and recommended the choice could be down to >> > implementers or apps. Included section on corner cases. >> > >> > * Introduced more normative language throughout the Protocol >> > Spec. >> > >> > Editorial changes: >> > >> > * Added temporary motivation section >> > >> > * Added confusible terminology to Terminology section. >> > >> > * Divided protocol spec into sub-sections. >> > >> > * Handshake table: Clarified that the two columns under each >> > server represent separate threads, that may run on = separate >> > servers, without co-ordination. Represented message >> > dependencies in the alignment of the rows. >> > >> > * Explained the table. >> > >> > * Explained why a legacy server won't ever pass SYN-U to the = app. >> > >> > * More precisely described loss as 'not arrived before a >> > timeout', and explained the tradeoff between latency and = extra >> > TCP options. >> > >> > * Gave reasoning for locating TCP options in three groups. >> > >> > * Acknowledged Rob Hancock for the architectural idea of = hiding >> > an extension to a protocol in the layer above. >> > >> > * Appendix about protocol alternatives now only presents the = SYN- >> > UD alternative, given the implicit/explicit handshake = choice >> > has been moved to the body. >> > >> > * Rewrote appendix about comparing the choices to treat the = two >> > pairs of choices separately, rather than discussing all = four >> > combinations of pairs of choices. >> > >> > ________________________________________________________________ >> > Bob Briscoe, BT >=20 > ________________________________________________________________ > Bob Briscoe, BT=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm --Apple-Mail=_2C23F7FB-4C50-4B9E-9B8B-FF46ECC1B462 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlQkMWMACgkQdyiq39b9uS4A7QCfb7CH77ROOT5iw+1BK5ITLkO1 uB8An3XxzWO9PFOdniSVpkfoEeNxgtM5 =KsC5 -----END PGP SIGNATURE----- --Apple-Mail=_2C23F7FB-4C50-4B9E-9B8B-FF46ECC1B462-- From nobody Thu Sep 25 08:59:34 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 398871A0140 for ; Thu, 25 Sep 2014 08:59:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.387 X-Spam-Level: X-Spam-Status: No, score=-3.387 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=ham 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 xCWzXwUpH6Od for ; Thu, 25 Sep 2014 08:59:24 -0700 (PDT) Received: from hubrelay-by-03.bt.com (hubrelay-by-03.bt.com [62.7.242.139]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 123D61A0130 for ; Thu, 25 Sep 2014 08:59:22 -0700 (PDT) Received: from EVMHR02-UKBR.domain1.systemhost.net (193.113.108.41) by EVMHR03-UKBR.bt.com (10.216.161.35) with Microsoft SMTP Server (TLS) id 8.3.348.2; Thu, 25 Sep 2014 16:59:20 +0100 Received: from EPHR02-UKIP.domain1.systemhost.net (147.149.100.81) by EVMHR02-UKBR.domain1.systemhost.net (193.113.108.41) with Microsoft SMTP Server (TLS) id 8.3.348.2; Thu, 25 Sep 2014 16:59:20 +0100 Received: from bagheera.jungle.bt.co.uk (132.146.168.158) by EPHR02-UKIP.domain1.systemhost.net (147.149.100.81) with Microsoft SMTP Server id 14.3.181.6; Thu, 25 Sep 2014 16:59:19 +0100 Received: from BTP075694.jungle.bt.co.uk ([10.215.130.93]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id s8PFxHTH014819; Thu, 25 Sep 2014 16:59:18 +0100 Message-ID: <201409251559.s8PFxHTH014819@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 25 Sep 2014 16:59:15 +0100 To: "Zimmermann, Alexander" From: Bob Briscoe In-Reply-To: References: <201409222045.s8MKjZdD002071@bagheera.jungle.bt.co.uk> <542344DA.9020905@isi.edu> <201409250956.s8P9uae9013452@bagheera.jungle.bt.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/4OxoTSu_51kMJopuvrw15iPBZhY Cc: tcpm IETF list , Joe Touch Subject: Re: [tcpm] More TCP option space in a SYN: draft-briscoe-tcpm-syn-op-sis-02 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Sep 2014 15:59:31 -0000 Alex, At 16:13 25/09/2014, Zimmermann, Alexander wrote: >Bob, > >Am 25.09.2014 um 05:56 schrieb Bob Briscoe : > > > At 23:25 24/09/2014, Joe Touch wrote: > >> Hi, Bob (et al.), > >> > >> Also, I don't particularly think that putting the options at the end of > >> the segment serves any useful purpose other than to make this option > >> handle the option space in a different way than the default DO > header field. > > > > That's the architectural point. > > There's also a tactical point. It should get through every middle box. > >but do we have not exactly the same problem w/ TCPinc. With TCPinc we have >the problem too that a middle box doesn't see any understandable after the >legacy TCP header (e.g. no HTTP header after TCP port 80). So, why it's >acceptable for TCPinc but not for extending SYN option space? BTW any >tcpdump user will love to have the options in front of a segment and not >at the end ;-) tcpinc is about encrypting payload. I'm interested in extending opportunistic encryption to TCP options, which is why I want to separate options into 'middlebox' and 'destination' (note: zero middlebox options would be valid). Right now I'm working on a tcpcrypt-like approach, to see if I can get the cipher negotiation done in zero RTT (at least on a connection resume), so I can use it to encrypt TCP options after the payload (as well encrypting any payload, of course). This will then /enforce/ the middlebox-v-destination categorisation of options. I left any discussion of this out of syn-op-sis-02, because I'd rather not talk about possibilities until I know whether they are possible. (I guess that means I need to apologise for talking about possibilities on the list, but I couldn't help it, given your posting was so close to what I am thinking :| Bob >Alex ________________________________________________________________ Bob Briscoe, BT From nobody Thu Sep 25 09:41:48 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93A4F1A0149 for ; Thu, 25 Sep 2014 09:41:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.687 X-Spam-Level: X-Spam-Status: No, score=-14.687 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 xSXVFJ4HYVfk for ; Thu, 25 Sep 2014 09:41:45 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57EF51A00CF for ; Thu, 25 Sep 2014 09:41:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10407; q=dns/txt; s=iport; t=1411663305; x=1412872905; h=date:from:to:cc:subject:in-reply-to:message-id: references:mime-version; bh=w26N1bSUOQcV36aBcb+67RZ8SREHDcVmylWpTWj9kNU=; b=MZqVtyGQqzbZ15gzYg80mBV359RSADkTjJEEL/a7toslkaIF/RCMwavJ iAjZ6r6lRnnAY43/YC6OR5x5dr4hQ+958HiqLC8rRbMIJTeHrUo0nSW4N zrsJ2EI8UXTAl0UrxwyYoNTTDywa6SMrbxU/315HVzEVHIVOdWNDzBQ0f c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsILAHBFJFStJA2M/2dsb2JhbABXCYMOU1cEtigBAQEBAQEFAXIBkzkKh04CgQUWAXuEAwEBAQMBAQEBCxkRAisJBAcFCwsYLicwBg4FG4gbCA3BVwEXhhKEGIUSBwoBUAeESwWWGoI+hi2TdINlaoEGCRcEHoECAQEB X-IronPort-AV: E=Sophos;i="5.04,598,1406592000"; d="scan'208";a="81208469" Received: from alln-core-7.cisco.com ([173.36.13.140]) by alln-iport-1.cisco.com with ESMTP; 25 Sep 2014 16:41:44 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id s8PGfiet024585 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 25 Sep 2014 16:41:44 GMT Received: from ams-ayourtch-8813.cisco.com (10.55.47.212) by xhc-aln-x03.cisco.com (173.36.12.77) with Microsoft SMTP Server (TLS) id 14.3.195.1; Thu, 25 Sep 2014 11:41:42 -0500 Date: Thu, 25 Sep 2014 18:41:24 +0200 From: Andrew Yourtchenko X-X-Sender: ayourtch@ayourtch-mac To: Bob Briscoe In-Reply-To: <201409250956.s8P9uae9013452@bagheera.jungle.bt.co.uk> Message-ID: References: <201409222045.s8MKjZdD002071@bagheera.jungle.bt.co.uk> <542344DA.9020905@isi.edu> <201409250956.s8P9uae9013452@bagheera.jungle.bt.co.uk> User-Agent: Alpine 2.00 (OSX 1167 2008-08-23) MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="US-ASCII" X-Originating-IP: [10.55.47.212] Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/mehf67dVPpzmYkdeOnltodwxwjw Cc: tcpm IETF list , Joe Touch Subject: Re: [tcpm] More TCP option space in a SYN: draft-briscoe-tcpm-syn-op-sis-02 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Sep 2014 16:41:47 -0000 Bob, Joe, all, some comments below, maybe with some obvious questions as I did not follow the latest discussions very closely. On Thu, 25 Sep 2014, Bob Briscoe wrote: > Joe, > > At 23:25 24/09/2014, Joe Touch wrote: >> Hi, Bob (et al.), >> >> It's good to have a more detailed description of the proposal. >> >> I still find a dual-SYN solution untenable, though, as it has been for >> other upgrade paths in the past (e.g., IPv6). > > That's why I prefer syn-op-sis because it only uses 2 SYNs for transition. Both syn-op-sis and tcp-syn-ext-opt talk about using different port pairs - is this due to the explosion with the number of possibilities for the three-way handshake recovery ? (Of course the application will anyway see only 1 file descriptor, which will assume the identity of the connection that succeeds, right ?) > > I've included a new section on ways to use only 1 SYN during transition > (building a white-list) and ultimately moving to 1 SYN in the future, only > falling back to the legacy SYN in series rather than parallel if you hit a > legacy listener. The fundamental difference between the transition to the extended option space and IPv4->IPv6 transition is the absence of the DNS to signal the capabilities of the endpoint before the connection even starts - if the target host has A&AAAA you only have to deal with the failures on the path, while if the target host does not have AAAA record, it's worthless to try IPv6. OTOH, when attempt to negotiate the extended option space, you do not have any hints about the remote end - besides maybe past memory. In RFC6555 we tried to avoid dual-SYN as much as possible by providing a headstart that shrinks and inverses on failures - so the reference to RFC6555 being "parallel" is not correct, see section 5.5: The primary purpose of Happy Eyeballs is to reduce the wait time for a dual-stack connection to complete, especially when the IPv6 path is broken and IPv6 is preferred. Aggressive timeouts (on the order of tens of milliseconds) achieve this goal, but at the cost of network traffic. This network traffic may be billable on certain networks, will create state on some middleboxes (e.g., firewalls, intrusion detection systems, NATs), and will consume ports if IPv4 addresses are shared. For these reasons, it is RECOMMENDED that connection attempts be paced to give connections a chance to complete. It is RECOMMENDED that connection attempts be paced 150-250 ms apart to balance human factors against network load. In today's conditions, a simple 300ms headstart for IPv6 if AAAA is advertised might be sufficient, as the subpar IPv6 connectivity disappears, and more of the corner cases get into play for RTTs. So, depending on how much of a drop rate we'd expect for a "new" SYN across the variety of network scenarios, the simpler approach of just using 300ms delay could be reasonable due to its simplicity - an experiment could show. Doing this experiment on both address families at once could also reveal the drop rates to be different - I'd expect the IPv6 drop rates to be smaller - so maybe there is an opportunity to simplify things - if it "just works" in IPv6 using a single fancy-looking SYN in a sufficient %% of cases, that could be a great simplification *and* will give additional use case for IPv6 assuming there is enough demand for more space in the options. > > The other two in tcp-syn-ext-opt have to be 2-SYN for ever. > >> Also, I don't particularly think that putting the options at the end of >> the segment serves any useful purpose other than to make this option >> handle the option space in a different way than the default DO header >> field. > > That's the architectural point. > There's also a tactical point. It should get through every middlebox. Help me understand this argument. If we were sending the "old" and "new" SYNs on the same 5-tuple - sure, the data must be identical. But if source ports are different, then a typical middlebox is either happy about the "data in the SYN" or not ? Or, are you saying that placing them at the end of the packet makes it difficult for the current architectures to "grab" them and mess around with them ? Sure, it does. Especially higher-performing boxes might look at the start of the packet. But that's *today's* architectures - if someone pays one of my employer's BUs enough to create a box that fiddles with these options, that box will get created. Not an architecturally beautiful reality, but it is there. > >> I'm glad to hear what others think and agree that an unbiased comparison >> of the approaches would be a useful place to for the discussion to start... > > Yes, I'm already repeating myself - you're right we need wider opinions. Even though I am nominally "on the list of alternatives" due to LOIC, I've disliked the idea shortly after, after trying to implement it - the linux kernel's accelerated NIC path showed that the invalid CRC would be dropped very early, before the software can see it - so I would argue against that approach today from implementation standpoint as well. Hopefully arguing with my past self does buy me an "unbiased" ribbon, or at least a half of it :-) --a > > > > Bob > > >> Joe >> >> On 9/22/2014 7:55 AM, Bob Briscoe wrote: >> > Joe, >> > >> > I've just posted a revision here: >> > >> > >> > * I've taken more care to explain it. It was a bit terse before. So it's >> > ready for the list to review properly now. >> > >> > It would be useful if someone wrote a comparison with the other ideas on >> > how to do this, including the ones we wrote jointly and SLO, LOIC and >> > DBormam's 4-way HS. Better someone independent of all the authors does >> > this. But I want to get syn-op-sis right first, a comparison won't be >> > much use until its stable. >> > >> > >> > The underlying idea is still the same. The reasons I've updated it are >> > many (the change log taken from the appendix is pasted at the end of >> > this email for convenience). >> > >> > * Mainly I've articulated that all these approaches that add TCP options >> > after the Data Offset are not just hacks to get more space; they add a >> > new architectural capability to TCP - a distinction between TCP options >> > that might be relevant to middleboxes, and ones that are only for the >> > destination (a bit like destopt in IPv6 - needing to specify which TCP >> > options are for the destination only is ironic but necessary). >> > >> > * I've also realised that this approach will ultimately return to a >> > single SYN solution, whereas both the ideas in >> > draft-touch-tcpm-tcp-syn-ext-opt will always require two SYNs. >> > >> > >> > >> > Bob >> > >> > Pasted from the change log: >> > >> > From briscoe...-01 to briscoe...-02: >> > >> > Technical changes: >> > >> > * Defined the client behaviour dependent on which response >> > arrives first. >> > >> > * Allowed retransmission of either SYN or SYN-U if no response >> > from either. >> > >> > * Redefined EOO as an offset from the end of the packet, not from >> > the beginning of the payload. >> > >> > * Added section on Migration to a Single Handshake. Reworded >> > dual handshake so that it is not mandatory for the client to >> > send dual SYNs simultaneously; only the relation between the >> > SYNs and the response to either is mandatory, while parallel >> > SYNs is purely for latency reduction. >> > >> > * Added rules for writing TCP options, i.e. i) options like TFO >> > MUST NOT be located in the TCP header and ii) add no-ops to >> > align on 4-octet boundary. >> > >> > * Added rules for forwarding TCP options, i.e. only the >> > destination looks for TCP options after the Data Offset, not >> > middleboxes. >> > >> > * Moved the Explicit Handshake variant (SYN-L) into the body from >> > the appendix, and recommended the choice could be down to >> > implementers or apps. Included section on corner cases. >> > >> > * Introduced more normative language throughout the Protocol >> > Spec. >> > >> > Editorial changes: >> > >> > * Added temporary motivation section >> > >> > * Added confusible terminology to Terminology section. >> > >> > * Divided protocol spec into sub-sections. >> > >> > * Handshake table: Clarified that the two columns under each >> > server represent separate threads, that may run on separate >> > servers, without co-ordination. Represented message >> > dependencies in the alignment of the rows. >> > >> > * Explained the table. >> > >> > * Explained why a legacy server won't ever pass SYN-U to the app. >> > >> > * More precisely described loss as 'not arrived before a >> > timeout', and explained the tradeoff between latency and extra >> > TCP options. >> > >> > * Gave reasoning for locating TCP options in three groups. >> > >> > * Acknowledged Rob Hancock for the architectural idea of hiding >> > an extension to a protocol in the layer above. >> > >> > * Appendix about protocol alternatives now only presents the SYN- >> > UD alternative, given the implicit/explicit handshake choice >> > has been moved to the body. >> > >> > * Rewrote appendix about comparing the choices to treat the two >> > pairs of choices separately, rather than discussing all four >> > combinations of pairs of choices. >> > >> > ________________________________________________________________ >> > Bob Briscoe, BT > > ________________________________________________________________ > Bob Briscoe, BT > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > From nobody Thu Sep 25 10:17:56 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 747161A028B for ; Thu, 25 Sep 2014 10:17:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.386 X-Spam-Level: X-Spam-Status: No, score=-4.386 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786] autolearn=ham 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 ExnKUAZt9d7H for ; Thu, 25 Sep 2014 10:17:54 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18B3D1A8732 for ; Thu, 25 Sep 2014 10:17:45 -0700 (PDT) Received: from [128.9.160.211] (mul.isi.edu [128.9.160.211]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id s8PHGrJ5028104 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 25 Sep 2014 10:16:53 -0700 (PDT) Message-ID: <54244E05.9040009@isi.edu> Date: Thu, 25 Sep 2014 10:16:53 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 MIME-Version: 1.0 To: Andrew Yourtchenko , Bob Briscoe References: <201409222045.s8MKjZdD002071@bagheera.jungle.bt.co.uk> <542344DA.9020905@isi.edu> <201409250956.s8P9uae9013452@bagheera.jungle.bt.co.uk> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/KbCW0sErReXcIGgO_gsQoIdlOfw Cc: tcpm IETF list Subject: Re: [tcpm] More TCP option space in a SYN: draft-briscoe-tcpm-syn-op-sis-02 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Sep 2014 17:17:55 -0000 On 9/25/2014 9:41 AM, Andrew Yourtchenko wrote: > Bob, Joe, all, > > some comments below, maybe with some obvious questions as I did not > follow the latest discussions very closely. > > On Thu, 25 Sep 2014, Bob Briscoe wrote: > >> Joe, >> >> At 23:25 24/09/2014, Joe Touch wrote: >>> Hi, Bob (et al.), >>> >>> It's good to have a more detailed description of the proposal. >>> >>> I still find a dual-SYN solution untenable, though, as it has been for >>> other upgrade paths in the past (e.g., IPv6). >> >> That's why I prefer syn-op-sis because it only uses 2 SYNs for >> transition. > > Both syn-op-sis and tcp-syn-ext-opt talk about using > different port pairs tcp-syn-ext-opt describes two different approaches: SYN-EOS-OOB uses one port pair, sends only one SYN SYN-EOS-DS uses two port pairs the DS variant is very similar to the one in syn-op-sis; both are Bob's suggestion. Mine was SYN-EOS-OOB. Bob - let me know if its useful to retain SYN-EOS-DS or if you want to replace it with syn-op-sis. > - is this due to the explosion with the number of > possibilities for the three-way handshake recovery ? Two ports are used only when two SYNs are sent, largely to avoid the second SYN from affecting the progress of the first that arrives at a legacy endpoint. > (Of course the application will anyway see only 1 file descriptor, which > will assume the identity of the connection that succeeds, right ?) Yes. >> I've included a new section on ways to use only 1 SYN during >> transition (building a white-list) and ultimately moving to 1 SYN in >> the future, only falling back to the legacy SYN in series rather than >> parallel if you hit a legacy listener. > > The fundamental difference between the transition to the extended option > space and IPv4->IPv6 transition is the absence of the DNS to signal the > capabilities of the endpoint before the connection even starts - if the > target host has A&AAAA you only have to deal with the failures on the > path, while if the target host does not have AAAA record, it's worthless > to try IPv6. > > OTOH, when attempt to negotiate the extended option space, you do not > have any hints about the remote end - besides maybe past memory. You could have similar hints in SRV records, though those are used much less frequently. ... > In today's conditions, a simple 300ms headstart for IPv6 if AAAA is > advertised might be sufficient, as the subpar IPv6 connectivity > disappears, and more of the corner cases get into play for RTTs. > > So, depending on how much of a drop rate we'd expect for a "new" SYN > across the variety of network scenarios, the simpler approach of just > using 300ms delay could be reasonable due to its simplicity - an > experiment could show. Sure, but it also has creates delay on either the legacy or upgraded connection - depending on which SYN is stalled. That's the advantage of the OOB method - there's no need to insert a stall on the sending side (an upgraded receiver might cache OOBs that arrive briefly before SYNs to avoid the need for an additional exchange) >> The other two in tcp-syn-ext-opt have to be 2-SYN for ever. They're two segments forever. Only one is two SYNs. Joe From nobody Thu Sep 25 11:42:40 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0CBB1A87B0 for ; Thu, 25 Sep 2014 11:42:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.787 X-Spam-Level: X-Spam-Status: No, score=-2.787 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=ham 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 iccuV5uZpasc for ; Thu, 25 Sep 2014 11:42:35 -0700 (PDT) Received: from hubrelay-rd.bt.com (hubrelay-rd.bt.com [62.239.224.98]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0356F1A87BA for ; Thu, 25 Sep 2014 11:42:34 -0700 (PDT) Received: from EVMHR71-UKRD.domain1.systemhost.net (10.36.3.109) by EVMHR66-UKRD.bt.com (10.187.101.21) with Microsoft SMTP Server (TLS) id 14.3.195.1; Thu, 25 Sep 2014 19:42:31 +0100 Received: from EPHR02-UKIP.domain1.systemhost.net (147.149.100.81) by EVMHR71-UKRD.domain1.systemhost.net (10.36.3.109) with Microsoft SMTP Server (TLS) id 8.3.348.2; Thu, 25 Sep 2014 19:42:31 +0100 Received: from bagheera.jungle.bt.co.uk (132.146.168.158) by EPHR02-UKIP.domain1.systemhost.net (147.149.100.81) with Microsoft SMTP Server id 14.3.181.6; Thu, 25 Sep 2014 19:42:31 +0100 Received: from BTP075694.jungle.bt.co.uk ([10.215.130.93]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id s8PIgUdQ015414; Thu, 25 Sep 2014 19:42:30 +0100 Message-ID: <201409251842.s8PIgUdQ015414@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 25 Sep 2014 19:42:28 +0100 To: Andrew Yourtchenko From: Bob Briscoe In-Reply-To: References: <201409222045.s8MKjZdD002071@bagheera.jungle.bt.co.uk> <542344DA.9020905@isi.edu> <201409250956.s8P9uae9013452@bagheera.jungle.bt.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/lHE4suJd6OYn3aIMG7N0DPKnSQs Cc: tcpm IETF list , Joe Touch Subject: Re: [tcpm] More TCP option space in a SYN: draft-briscoe-tcpm-syn-op-sis-02 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Sep 2014 18:42:38 -0000 Andrew, At 17:41 25/09/2014, Andrew Yourtchenko wrote: >Bob, Joe, all, > >some comments below, maybe with some obvious questions as I did not >follow the latest discussions very closely. > >On Thu, 25 Sep 2014, Bob Briscoe wrote: > >>Joe, >> >>At 23:25 24/09/2014, Joe Touch wrote: >>>Hi, Bob (et al.), >>>It's good to have a more detailed description of the proposal. >>>I still find a dual-SYN solution untenable, though, as it has been for >>>other upgrade paths in the past (e.g., IPv6). >> >>That's why I prefer syn-op-sis because it only uses 2 SYNs for transition. > >Both syn-op-sis and tcp-syn-ext-opt talk about using >different port pairs - is this due to the explosion with the number >of possibilities for the three-way handshake recovery ? SYN-EOS OOB (within tcp-syn-ext-opt) uses the same src & dst ports. SYN-EOS DS (within tcp-syn-ext-opt) and syn-op-sis use same dst, but different src. Rationale for latter: too many middleboxes out there that would reject a SYN to/from the same ports, in their misguided attempts to be 'helpful' by removing SYNs that appear to be duplicate or same 4-tuple but different initial sequence no. Not only many firewalls, but all split connections would not forward the second SYN. >(Of course the application will anyway see only 1 file descriptor, >which will assume the identity of the connection that succeeds, right ?) Correct. >>I've included a new section on ways to use only 1 SYN during >>transition (building a white-list) and ultimately moving to 1 SYN >>in the future, only falling back to the legacy SYN in series rather >>than parallel if you hit a legacy listener. > >The fundamental difference between the transition to the extended >option space and IPv4->IPv6 transition is the absence of the DNS to >signal the capabilities of the endpoint before the connection even >starts - if the target host has A&AAAA you only have to deal with >the failures on the path, while if the target host does not have >AAAA record, it's worthless to try IPv6. > >OTOH, when attempt to negotiate the extended option space, you do >not have any hints about the remote end - besides maybe past memory. > >In RFC6555 we tried to avoid dual-SYN as much as possible by >providing a headstart that shrinks and inverses on failures - so the >reference to RFC6555 being "parallel" is not correct, see section 5.5: > > The primary purpose of Happy Eyeballs is to reduce the wait time for > a dual-stack connection to complete, especially when the IPv6 path is > broken and IPv6 is preferred. Aggressive timeouts (on the order of > tens of milliseconds) achieve this goal, but at the cost of network > traffic. This network traffic may be billable on certain networks, > will create state on some middleboxes (e.g., firewalls, intrusion > detection systems, NATs), and will consume ports if IPv4 addresses > are shared. For these reasons, it is RECOMMENDED that connection > attempts be paced to give connections a chance to complete. It is > RECOMMENDED that connection attempts be paced 150-250 ms apart to > balance human factors against network load. The dual SYN approaches could use a delay between the SYNs like 6655 does (not nec exactly the same numbers). However, in the short flow world, I would argue that 250ms is completely unacceptable unless you're fairly certain the first one will work, which is more-or-less the v4/v6 scenario that happy eyeballs addressed. Reasoning: multiply 250ms by a few connections with serial dependencies in a sequence and you have delays of seconds. I've made a note to change the description of 6555 in the next rev - clearly the word parallel is not strictly correct anyway - one serial (e.g. network) interface can't actually send two SYNs in parallel, the closest they can leave is back-to-back. Regarding billable total traffic: Damon Wischik once proposed to improve performance by duplicating the most sensitive packets at flow start: "three copies of the first packet of every message, two copies of the second and one copy of subsequent packets" He calculated these 6 extra full-sized packets per flow would (in 2005) increase total traffic by 2.7% (because elephants dominate total traffic). Duplicating just the legacy part of the SYN (60B max) would have a much smaller total effect (I could calculate it if you want - probably sub-0.1%). Certainly too small for people to care about the increment on bills or even packet load. >In today's conditions, a simple 300ms headstart for IPv6 if AAAA is >advertised might be sufficient, as the subpar IPv6 connectivity >disappears, and more of the corner cases get into play for RTTs. > >So, depending on how much of a drop rate we'd expect for a "new" SYN >across the variety of network scenarios, the simpler approach of >just using 300ms delay could be reasonable due to its simplicity - >an experiment could show. > >Doing this experiment on both address families at once could also >reveal the drop rates to be different - I'd expect the IPv6 drop >rates to be smaller - so maybe there is an opportunity to simplify >things - if it "just works" in IPv6 using a single fancy-looking SYN >in a sufficient %% of cases, that could be a great simplification >*and* will give additional use case for IPv6 assuming there is >enough demand for more space in the options. The delay between the pair should be implementation dependent anyway. No point arguing this to death in standards... but I will at least state the opposing view... The world is changing. Latency is everything and soon it will be even more than everything. If one values latency, the delay between the two will be as small as possible. My simple view of the world is that, dual SYN seems the /only/ way to extend TCP option space. I'm not proud of it. It's not nice. But it's necessary. If dual SYNs require more memory for connection state, it's OK as long as the need for more memory appears slowly enough to be able to deploy it. If this is the price of extra capabilities, and those capabilities are valued, then we invest in memory to provide the capabilities. Whether the number of connections that need >40B TCP options will suddenly jump, or gradually grow, I can't predict tho. >>The other two in tcp-syn-ext-opt have to be 2-SYN for ever. >> >>>Also, I don't particularly think that putting the options at the end of >>>the segment serves any useful purpose other than to make this option >>>handle the option space in a different way than the default DO header field. >> >>That's the architectural point. >>There's also a tactical point. It should get through every middlebox. > >Help me understand this argument. If we were sending the "old" and >"new" SYNs on the same 5-tuple - sure, the data must be identical. >But if source ports are different, then a typical middlebox is >either happy about the "data in the SYN" or not ? > >Or, are you saying that placing them at the end of the packet makes >it difficult for the current architectures to "grab" them and mess >around with them ? Sure, it does. Especially higher-performing boxes >might look at the start of the packet. > >But that's *today's* architectures - if someone pays one of my >employer's BUs enough to create a box that fiddles with these >options, that box will get created. Not an architecturally beautiful >reality, but it is there. Two clarifications: 1) By putting options after the payload, I'm including the (currently common) case of a SYN with no payload. Then the extra options will start immediately at the Data Offset. 2) A longer clarification... Let's separate middleboxes into two types (I'm trying to deal with both): - (meddleboxes) those that want to mess with headers for security - (muddleboxes) those that happen to mess with headers, because their developers never stopped to think that TCP might change. Muddleboxes tend to forward the payload unaltered. Some muddleboxes look at HTTP headers and try to be clever. By putting extra options after the Data Offset, they will pass the former. By putting them at the end of the payload they will mostly pass the latter. Meddleboxes might well evolve to find these new extra options at the end of the packet. But in the meantime, we've got over the transition of deploying a new protocol. Then the meddleboxes are on the back foot, and they have to justify removing these packets that are useful to someone. If they can - e.g. for security reasons - then fine. But they are not just removing packets because they are using a new rev of the protocol. As I said, the most important thing is we will have separated TCP options into two sets: - Those that middleboxes (past and future) can mess with - Those that middleboxes (future) should think much harder about before messing with them Then, this (maybe) enables the next step - for endpoints to encrypt those options they don't want middleboxes to interact with at all. (See my response to Alex Zimmerman's post in this thread.) >>>I'm glad to hear what others think and agree that an unbiased comparison >>>of the approaches would be a useful place to for the discussion to start... >> >>Yes, I'm already repeating myself - you're right we need wider opinions. > >Even though I am nominally "on the list of alternatives" due to >LOIC, I've disliked the idea shortly after, after trying to >implement it - the linux kernel's accelerated NIC path showed that >the invalid CRC would be dropped very early, before the software can >see it - so I would argue against that approach today from >implementation standpoint as well. > >Hopefully arguing with my past self does buy me an "unbiased" >ribbon, or at least a half of it :-) Certainly, this seems to give you the role of unbiased /and/ educated by experience. I'm also no longer like an idea that my past self proposed (SYN-EOS DS), for the same reasons Joe didn't like it - the two SYNs will often not end up in the same place to be re-united. But I still have a candidate I do prefer (syn-op-sis). That rules me out for the role of innocent bystander. Bob >--a > >> >> >> >>Bob >> >> >>>Joe >>>On 9/22/2014 7:55 AM, Bob Briscoe wrote: >>> > Joe, >>> > >>> > I've just posted a revision here: >>> > >>> > >>> > * I've taken more care to explain it. It was a bit terse before. So it's >>> > ready for the list to review properly now. >>> > >>> > It would be useful if someone wrote a comparison with the other ideas on >>> > how to do this, including the ones we wrote jointly and SLO, LOIC and >>> > DBormam's 4-way HS. Better someone independent of all the authors does >>> > this. But I want to get syn-op-sis right first, a comparison won't be >>> > much use until its stable. >>> > >>> > >>> > The underlying idea is still the same. The reasons I've updated it are >>> > many (the change log taken from the appendix is pasted at the end of >>> > this email for convenience). >>> > >>> > * Mainly I've articulated that all these approaches that add TCP options >>> > after the Data Offset are not just hacks to get more space; they add a >>> > new architectural capability to TCP - a distinction between TCP options >>> > that might be relevant to middleboxes, and ones that are only for the >>> > destination (a bit like destopt in IPv6 - needing to specify which TCP >>> > options are for the destination only is ironic but necessary). >>> > >>> > * I've also realised that this approach will ultimately return to a >>> > single SYN solution, whereas both the ideas in >>> > draft-touch-tcpm-tcp-syn-ext-opt will always require two SYNs. >>> > >>> > >>> > >>> > Bob >>> > >>> > Pasted from the change log: >>> > >>> > From briscoe...-01 to briscoe...-02: >>> > >>> > Technical changes: >>> > >>> > * Defined the client behaviour dependent on which response >>> > arrives first. >>> > >>> > * Allowed retransmission of either SYN or SYN-U if no response >>> > from either. >>> > >>> > * Redefined EOO as an offset from the end of the packet, not from >>> > the beginning of the payload. >>> > >>> > * Added section on Migration to a Single Handshake. Reworded >>> > dual handshake so that it is not mandatory for the client to >>> > send dual SYNs simultaneously; only the relation between the >>> > SYNs and the response to either is mandatory, while parallel >>> > SYNs is purely for latency reduction. >>> > >>> > * Added rules for writing TCP options, i.e. i) options like TFO >>> > MUST NOT be located in the TCP header and ii) add no-ops to >>> > align on 4-octet boundary. >>> > >>> > * Added rules for forwarding TCP options, i.e. only the >>> > destination looks for TCP options after the Data Offset, not >>> > middleboxes. >>> > >>> > * Moved the Explicit Handshake variant (SYN-L) into the body from >>> > the appendix, and recommended the choice could be down to >>> > implementers or apps. Included section on corner cases. >>> > >>> > * Introduced more normative language throughout the Protocol >>> > Spec. >>> > >>> > Editorial changes: >>> > >>> > * Added temporary motivation section >>> > >>> > * Added confusible terminology to Terminology section. >>> > >>> > * Divided protocol spec into sub-sections. >>> > >>> > * Handshake table: Clarified that the two columns under each >>> > server represent separate threads, that may run on separate >>> > servers, without co-ordination. Represented message >>> > dependencies in the alignment of the rows. >>> > >>> > * Explained the table. >>> > >>> > * Explained why a legacy server won't ever pass SYN-U to the app. >>> > >>> > * More precisely described loss as 'not arrived before a >>> > timeout', and explained the tradeoff between latency and extra >>> > TCP options. >>> > >>> > * Gave reasoning for locating TCP options in three groups. >>> > >>> > * Acknowledged Rob Hancock for the architectural idea of hiding >>> > an extension to a protocol in the layer above. >>> > >>> > * Appendix about protocol alternatives now only presents the SYN- >>> > UD alternative, given the implicit/explicit handshake choice >>> > has been moved to the body. >>> > >>> > * Rewrote appendix about comparing the choices to treat the two >>> > pairs of choices separately, rather than discussing all four >>> > combinations of pairs of choices. >>> > >>> > ________________________________________________________________ >>> > Bob Briscoe, BT >> >>________________________________________________________________ >>Bob Briscoe, BT >>_______________________________________________ >>tcpm mailing list >>tcpm@ietf.org >>https://www.ietf.org/mailman/listinfo/tcpm > >________________________________________________________________ >Bob Briscoe, BT From nobody Thu Sep 25 11:51:34 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 312DC1A87A1 for ; Thu, 25 Sep 2014 11:51:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.787 X-Spam-Level: X-Spam-Status: No, score=-2.787 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=ham 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 qixFk-1EXGHL for ; Thu, 25 Sep 2014 11:51:30 -0700 (PDT) Received: from hubrelay-rd.bt.com (hubrelay-rd.bt.com [62.239.224.98]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C5481A02D6 for ; Thu, 25 Sep 2014 11:51:30 -0700 (PDT) Received: from EVMHR71-UKRD.domain1.systemhost.net (10.36.3.109) by EVMHR65-UKRD.bt.com (10.187.101.20) with Microsoft SMTP Server (TLS) id 14.3.181.6; Thu, 25 Sep 2014 19:51:29 +0100 Received: from EPHR02-UKIP.domain1.systemhost.net (147.149.100.81) by EVMHR71-UKRD.domain1.systemhost.net (10.36.3.109) with Microsoft SMTP Server (TLS) id 8.3.348.2; Thu, 25 Sep 2014 19:51:28 +0100 Received: from bagheera.jungle.bt.co.uk (132.146.168.158) by EPHR02-UKIP.domain1.systemhost.net (147.149.100.81) with Microsoft SMTP Server id 14.3.181.6; Thu, 25 Sep 2014 19:51:27 +0100 Received: from BTP075694.jungle.bt.co.uk ([10.215.130.93]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id s8PIpQRO015438; Thu, 25 Sep 2014 19:51:26 +0100 Message-ID: <201409251851.s8PIpQRO015438@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 25 Sep 2014 19:51:26 +0100 To: Joe Touch From: Bob Briscoe In-Reply-To: <54244E05.9040009@isi.edu> References: <201409222045.s8MKjZdD002071@bagheera.jungle.bt.co.uk> <542344DA.9020905@isi.edu> <201409250956.s8P9uae9013452@bagheera.jungle.bt.co.uk> <54244E05.9040009@isi.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/YNiC1OW5JmmArIpzwqL_z7oORvE Cc: tcpm IETF list , Andrew Yourtchenko Subject: Re: [tcpm] More TCP option space in a SYN: draft-briscoe-tcpm-syn-op-sis-02 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Sep 2014 18:51:32 -0000 Joe, At 18:16 25/09/2014, Joe Touch wrote: >On 9/25/2014 9:41 AM, Andrew Yourtchenko wrote: > > Bob, Joe, all, > > > > some comments below, maybe with some obvious questions as I did not > > follow the latest discussions very closely. > > > > On Thu, 25 Sep 2014, Bob Briscoe wrote: > > > >> Joe, > >> > >> At 23:25 24/09/2014, Joe Touch wrote: > >>> Hi, Bob (et al.), > >>> > >>> It's good to have a more detailed description of the proposal. > >>> > >>> I still find a dual-SYN solution untenable, though, as it has been for > >>> other upgrade paths in the past (e.g., IPv6). > >> > >> That's why I prefer syn-op-sis because it only uses 2 SYNs for > >> transition. > > > > Both syn-op-sis and tcp-syn-ext-opt talk about using > > different port pairs > >tcp-syn-ext-opt describes two different approaches: > > SYN-EOS-OOB uses one port pair, sends only one SYN > > SYN-EOS-DS uses two port pairs > >the DS variant is very similar to the one in syn-op-sis; both are Bob's >suggestion. Mine was SYN-EOS-OOB. > >Bob - let me know if its useful to retain SYN-EOS-DS or if you want to >replace it with syn-op-sis. In my mind syn-op-sis solves problems with SYN-EOS-DS and doesn't introduce any new problems (AFAIK). So it's a pure upgrade. Let's have an author-huddle off-list about how we deal with these. Sorry for my last post crossing your response below. > > - is this due to the explosion with the number of > > possibilities for the three-way handshake recovery ? > >Two ports are used only when two SYNs are sent, largely to avoid the >second SYN from affecting the progress of the first that arrives at a >legacy endpoint. > > > (Of course the application will anyway see only 1 file descriptor, which > > will assume the identity of the connection that succeeds, right ?) > >Yes. > > >> I've included a new section on ways to use only 1 SYN during > >> transition (building a white-list) and ultimately moving to 1 SYN in > >> the future, only falling back to the legacy SYN in series rather than > >> parallel if you hit a legacy listener. > > > > The fundamental difference between the transition to the extended option > > space and IPv4->IPv6 transition is the absence of the DNS to signal the > > capabilities of the endpoint before the connection even starts - if the > > target host has A&AAAA you only have to deal with the failures on the > > path, while if the target host does not have AAAA record, it's worthless > > to try IPv6. > > > > OTOH, when attempt to negotiate the extended option space, you do not > > have any hints about the remote end - besides maybe past memory. > >You could have similar hints in SRV records, though those are used much >less frequently. > >... > > In today's conditions, a simple 300ms headstart for IPv6 if AAAA is > > advertised might be sufficient, as the subpar IPv6 connectivity > > disappears, and more of the corner cases get into play for RTTs. > > > > So, depending on how much of a drop rate we'd expect for a "new" SYN > > across the variety of network scenarios, the simpler approach of just > > using 300ms delay could be reasonable due to its simplicity - an > > experiment could show. > >Sure, but it also has creates delay on either the legacy or upgraded >connection - depending on which SYN is stalled. > >That's the advantage of the OOB method - there's no need to insert a >stall on the sending side (an upgraded receiver might cache OOBs that >arrive briefly before SYNs to avoid the need for an additional exchange) > > >> The other two in tcp-syn-ext-opt have to be 2-SYN for ever. > >They're two segments forever. Only one is two SYNs. > >Joe ________________________________________________________________ Bob Briscoe, BT From nobody Thu Sep 25 12:22:22 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79FE51A00DA for ; Thu, 25 Sep 2014 12:22:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.687 X-Spam-Level: X-Spam-Status: No, score=-14.687 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 L1iHWhUZUeAZ for ; Thu, 25 Sep 2014 12:22:17 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A907A1A8856 for ; Thu, 25 Sep 2014 12:22:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5693; q=dns/txt; s=iport; t=1411672934; x=1412882534; h=date:from:to:cc:subject:in-reply-to:message-id: references:mime-version; bh=BPOQrBdAre+b/PMmURuu4xYUkiGntkw5sF+NgKF7y/U=; b=NvdEo0+fuwyF8qrxknE+9h4QfG48bLSbTqDerCwd8gauyFar+cYjf5Zc ZdqZsrE76T+4VJphCXXNPpQ5XGpsnH2a1BZ/okmupH/PEJMz2L9xfyk0r LropRdO7K3vn6unGb67TF5+zVL5YUDqS7XqQYS3BTuPuvje9SfB1KIMVj A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AssLAOpqJFStJV2S/2dsb2JhbABXCQ6DAFNXBLYeDAEBAQEBAQUBcgGTRYdMAoEGFgF7hAMBAQEDAScRAj8QCxguVwYOIIgbCA3BawEXhhKJMRlCB4RLAQSPSIZSiGuTdIMjQmoBAYEGQIECAQEB X-IronPort-AV: E=Sophos;i="5.04,598,1406592000"; d="scan'208";a="81256312" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by alln-iport-1.cisco.com with ESMTP; 25 Sep 2014 19:22:13 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id s8PJMD35016750 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 25 Sep 2014 19:22:13 GMT Received: from ams-ayourtch-8813.cisco.com (10.55.47.212) by xhc-aln-x03.cisco.com (173.36.12.77) with Microsoft SMTP Server (TLS) id 14.3.195.1; Thu, 25 Sep 2014 14:22:13 -0500 Date: Thu, 25 Sep 2014 21:21:54 +0200 From: Andrew Yourtchenko X-X-Sender: ayourtch@ayourtch-mac To: Joe Touch In-Reply-To: <54244E05.9040009@isi.edu> Message-ID: References: <201409222045.s8MKjZdD002071@bagheera.jungle.bt.co.uk> <542344DA.9020905@isi.edu> <201409250956.s8P9uae9013452@bagheera.jungle.bt.co.uk> <54244E05.9040009@isi.edu> User-Agent: Alpine 2.00 (OSX 1167 2008-08-23) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII"; format=flowed X-Originating-IP: [10.55.47.212] Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/bZ-vwJidURqMwdszWAQwcNyhFUA Cc: tcpm IETF list Subject: Re: [tcpm] More TCP option space in a SYN: draft-briscoe-tcpm-syn-op-sis-02 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Sep 2014 19:22:20 -0000 On Thu, 25 Sep 2014, Joe Touch wrote: > > > On 9/25/2014 9:41 AM, Andrew Yourtchenko wrote: >> Bob, Joe, all, >> >> some comments below, maybe with some obvious questions as I did not >> follow the latest discussions very closely. >> >> On Thu, 25 Sep 2014, Bob Briscoe wrote: >> >>> Joe, >>> >>> At 23:25 24/09/2014, Joe Touch wrote: >>>> Hi, Bob (et al.), >>>> >>>> It's good to have a more detailed description of the proposal. >>>> >>>> I still find a dual-SYN solution untenable, though, as it has been for >>>> other upgrade paths in the past (e.g., IPv6). >>> >>> That's why I prefer syn-op-sis because it only uses 2 SYNs for >>> transition. >> >> Both syn-op-sis and tcp-syn-ext-opt talk about using >> different port pairs > > tcp-syn-ext-opt describes two different approaches: > > SYN-EOS-OOB uses one port pair, sends only one SYN > > SYN-EOS-DS uses two port pairs > > the DS variant is very similar to the one in syn-op-sis; both are Bob's > suggestion. Mine was SYN-EOS-OOB. Thanks for the clarification! > > Bob - let me know if its useful to retain SYN-EOS-DS or if you want to > replace it with syn-op-sis. > >> - is this due to the explosion with the number of >> possibilities for the three-way handshake recovery ? > > Two ports are used only when two SYNs are sent, largely to avoid the > second SYN from affecting the progress of the first that arrives at a > legacy endpoint. Makes sense, if both are valid SYNs for the legacy endpoint, indeed. > >> (Of course the application will anyway see only 1 file descriptor, which >> will assume the identity of the connection that succeeds, right ?) > > Yes. > >>> I've included a new section on ways to use only 1 SYN during >>> transition (building a white-list) and ultimately moving to 1 SYN in >>> the future, only falling back to the legacy SYN in series rather than >>> parallel if you hit a legacy listener. >> >> The fundamental difference between the transition to the extended option >> space and IPv4->IPv6 transition is the absence of the DNS to signal the >> capabilities of the endpoint before the connection even starts - if the >> target host has A&AAAA you only have to deal with the failures on the >> path, while if the target host does not have AAAA record, it's worthless >> to try IPv6. >> >> OTOH, when attempt to negotiate the extended option space, you do not >> have any hints about the remote end - besides maybe past memory. > > You could have similar hints in SRV records, though those are used much > less frequently. They're used quite frequently outside of HTTP (http://homepage.ntlworld.com/jonathan.deboynepollard/FGA/dns-srv-record-use-by-clients.html) though the "outside of HTTP" part makes it quite infrequent. OTOH, the SRV record has just priority,weight,port,target-name - there is no space for the hint as such. OTOH maybe a new record type that could be returned in "additional" field within the reply? Regardless, the DNS "hint"'s presence could change the game quite a lot - if you know that the remote end is supporting the new cool extension, you you might want to make a leap of faith and give it a chance first, with the quick enough fallback to make the impact minimal yet avoid two SYNs if possible. > > ... >> In today's conditions, a simple 300ms headstart for IPv6 if AAAA is >> advertised might be sufficient, as the subpar IPv6 connectivity >> disappears, and more of the corner cases get into play for RTTs. >> >> So, depending on how much of a drop rate we'd expect for a "new" SYN >> across the variety of network scenarios, the simpler approach of just >> using 300ms delay could be reasonable due to its simplicity - an >> experiment could show. > > Sure, but it also has creates delay on either the legacy or upgraded > connection - depending on which SYN is stalled. Exactly. The connecting side may decide it makes sense if it knows upfront from either the hint in DNS, or its own cache of previous connections to that host (which may not be valid, BTW - because the network inbetween might have changed) > > That's the advantage of the OOB method - there's no need to insert a > stall on the sending side (an upgraded receiver might cache OOBs that > arrive briefly before SYNs to avoid the need for an additional exchange) It's a tradeoff. two-SYN methods stall one of the connections during the transition period at initiator's discretion (with maybe using DNS hints or its local cache to decide which one to stall and the protocol type to decide for how long to stall), *or* cause two SYNs race which is not very nice. Assuming the stall delay is X, the session establishment time in the worst case is ~(1.5RTT+X) OOB method has a permanent decision to stall the connection if the upgraded server receives SYN-EOS OOB but no OOB segment (say, it's being blocked by the middleboxes?), "after a certain time". This time supposedly should be much shorter than the stall in the two-SYN case, ideally a function of jitter on the path, let's call it Y. If the client then proceeds as if the connection was legacy, the session establishment time is ~(1.5RTT+Y) - so, better than two-SYNs. But if the client decides to retransmit the OOB (the worse performing case of the, the overall connection establishment time will be ~(2.5*RTT+Y). And there'd need to be logic to still fallback to the legacy behavior if the (Second, third?) OOB packet gets dropped. If the above estimates make sense, then it's a tough call to make which one is better without trying in the wild, IMHO. --a From nobody Thu Sep 25 13:17:40 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 492931A0203 for ; Thu, 25 Sep 2014 13:17:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.986 X-Spam-Level: X-Spam-Status: No, score=-4.986 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786] autolearn=ham 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 VJd7xlFVmGJZ for ; Thu, 25 Sep 2014 13:17:37 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 158511A01D6 for ; Thu, 25 Sep 2014 13:17:37 -0700 (PDT) Received: from [128.9.160.211] (mul.isi.edu [128.9.160.211]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id s8PKH8rp025524 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 25 Sep 2014 13:17:08 -0700 (PDT) Message-ID: <54247844.1050202@isi.edu> Date: Thu, 25 Sep 2014 13:17:08 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 MIME-Version: 1.0 To: Andrew Yourtchenko References: <201409222045.s8MKjZdD002071@bagheera.jungle.bt.co.uk> <542344DA.9020905@isi.edu> <201409250956.s8P9uae9013452@bagheera.jungle.bt.co.uk> <54244E05.9040009@isi.edu> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/T26j0EwJyQDz-yWGHZZJ59YZp9Q Cc: tcpm IETF list Subject: Re: [tcpm] More TCP option space in a SYN: draft-briscoe-tcpm-syn-op-sis-02 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Sep 2014 20:17:39 -0000 On 9/25/2014 12:21 PM, Andrew Yourtchenko wrote: ... >>> OTOH, when attempt to negotiate the extended option space, you do not >>> have any hints about the remote end - besides maybe past memory. >> >> You could have similar hints in SRV records, though those are used much >> less frequently. ... > OTOH, the SRV record has just priority,weight,port,target-name - there > is no space for the hint as such. OTOH maybe a new record type that > could be returned in "additional" field within the reply? SRV records sometimes define additional parameters in the TXT records. See here: www.iana.org/assignments/service-names-port-numbers/ (search for TXT) ... >> That's the advantage of the OOB method - there's no need to insert a >> stall on the sending side (an upgraded receiver might cache OOBs that >> arrive briefly before SYNs to avoid the need for an additional exchange) > > It's a tradeoff. > > two-SYN methods stall one of the connections during the transition > period at initiator's discretion (with maybe using DNS hints or its > local cache to decide which one to stall and the protocol type to decide > for how long to stall), *or* cause two SYNs race which is not very nice. > Assuming the stall delay is X, the session establishment time in the > worst case is ~(1.5RTT+X) > > OOB method has a permanent decision to stall the connection if the > upgraded server receives SYN-EOS OOB but no OOB segment (say, it's being > blocked by the middleboxes?), "after a certain time". This time > supposedly should be much shorter than the stall in the two-SYN case, > ideally a function of jitter on the path, let's call it Y. That can be zero if the OOB arrives first or during the processing of the SYN. > If the client then proceeds as if the connection was legacy, the session > establishment time is ~(1.5RTT+Y) - so, better than two-SYNs. A legacy client wouldn't wait for the jitter - they would ignore the SYN-EOS flag in the SYN, and wouldn't know to wait. The OOB segment would get silently dropped if/when it arrives. > But if the client decides to retransmit the OOB (the worse performing > case of the, the overall connection establishment time will be > ~(2.5*RTT+Y). And there'd need to be logic to still fallback to the > legacy behavior if the (Second, third?) OOB packet gets dropped. The client need not wait for a RTT to retransmit the OOB; multiple OOBs have no impact on the server. Clients can send an OOB before and after the SYN, and if the OOB gets there and is cached it wins; if the OOB arrives after, the delay is just the arrival delay. Joe From nobody Thu Sep 25 15:48:58 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF4231A0066 for ; Thu, 25 Sep 2014 15:48:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.287 X-Spam-Level: X-Spam-Status: No, score=-15.287 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 WcGAAcAJN9-v for ; Thu, 25 Sep 2014 15:48:53 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C276B1A006D for ; Thu, 25 Sep 2014 15:48:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3866; q=dns/txt; s=iport; t=1411685333; x=1412894933; h=date:from:to:cc:subject:in-reply-to:message-id: references:mime-version; bh=8um97i822aHDewfs2JuKon1s8ZtSF3k8LiVWdwr1/p8=; b=VQ37Ptx5e2ri6FCoejWeDnIQjierm38aVRAzzN2gCtmvg2dw7WjdzpWa NJifYA/TGbzD0nBNGEP5KdxeeQZf6inDh37VrMIR68jBz6OqUuDwp8Q0a P28PbfNlEkxhxHW87uhzU/hDLYmFmG4bxLGmbMmh1SeGEByhDeZlAgMYx k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsQLALqaJFStJA2G/2dsb2JhbABgDoMAU1gDth0MAQEBAQEBBQFyAZMFh04CgQYWAXuEAwEBAQMBOAIPMBALGC5XBg4OiC0IDcFVAReGEoQYhTJCB4RLBbJ5gyNCgXJAgQIBAQE X-IronPort-AV: E=Sophos;i="5.04,600,1406592000"; d="scan'208";a="358288500" Received: from alln-core-12.cisco.com ([173.36.13.134]) by rcdn-iport-6.cisco.com with ESMTP; 25 Sep 2014 22:48:53 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id s8PMmq0K025414 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 25 Sep 2014 22:48:52 GMT Received: from ams-ayourtch-8813.cisco.com (10.55.47.212) by xhc-aln-x03.cisco.com (173.36.12.77) with Microsoft SMTP Server (TLS) id 14.3.195.1; Thu, 25 Sep 2014 17:48:52 -0500 Date: Fri, 26 Sep 2014 00:48:33 +0200 From: Andrew Yourtchenko X-X-Sender: ayourtch@ayourtch-mac To: Joe Touch In-Reply-To: <54247844.1050202@isi.edu> Message-ID: References: <201409222045.s8MKjZdD002071@bagheera.jungle.bt.co.uk> <542344DA.9020905@isi.edu> <201409250956.s8P9uae9013452@bagheera.jungle.bt.co.uk> <54244E05.9040009@isi.edu> <54247844.1050202@isi.edu> User-Agent: Alpine 2.00 (OSX 1167 2008-08-23) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII"; format=flowed X-Originating-IP: [10.55.47.212] Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/o3sEhulwfnGMdGpSHooaKjAG9Ow Cc: tcpm IETF list Subject: Re: [tcpm] More TCP option space in a SYN: draft-briscoe-tcpm-syn-op-sis-02 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Sep 2014 22:48:56 -0000 On Thu, 25 Sep 2014, Joe Touch wrote: > > > On 9/25/2014 12:21 PM, Andrew Yourtchenko wrote: > ... >>>> OTOH, when attempt to negotiate the extended option space, you do not >>>> have any hints about the remote end - besides maybe past memory. >>> >>> You could have similar hints in SRV records, though those are used much >>> less frequently. > ... >> OTOH, the SRV record has just priority,weight,port,target-name - there >> is no space for the hint as such. OTOH maybe a new record type that >> could be returned in "additional" field within the reply? > > SRV records sometimes define additional parameters in the TXT records. > See here: > www.iana.org/assignments/service-names-port-numbers/ > > (search for TXT) geez! Thanks for this link. I thought the uses of TXT beyond "descriptive text" were always very much frowned upon. > > ... >>> That's the advantage of the OOB method - there's no need to insert a >>> stall on the sending side (an upgraded receiver might cache OOBs that >>> arrive briefly before SYNs to avoid the need for an additional exchange) >> >> It's a tradeoff. >> >> two-SYN methods stall one of the connections during the transition >> period at initiator's discretion (with maybe using DNS hints or its >> local cache to decide which one to stall and the protocol type to decide >> for how long to stall), *or* cause two SYNs race which is not very nice. >> Assuming the stall delay is X, the session establishment time in the >> worst case is ~(1.5RTT+X) >> >> OOB method has a permanent decision to stall the connection if the >> upgraded server receives SYN-EOS OOB but no OOB segment (say, it's being >> blocked by the middleboxes?), "after a certain time". This time >> supposedly should be much shorter than the stall in the two-SYN case, >> ideally a function of jitter on the path, let's call it Y. > > That can be zero if the OOB arrives first or during the processing of > the SYN. Sure. It's not about reordering. It's about the worst case scenario. Best case scenarios "when everything works" both OOB and 2-SYNs are ~equivalent, the mild failure cases are nicer with OOB iff Y is smaller than X. OOB has the additional advantage of not consuming one more connection slot for a short period of time on the middleboxes (and the per-flow processing capacity). > >> If the client then proceeds as if the connection was legacy, the session >> establishment time is ~(1.5RTT+Y) - so, better than two-SYNs. > > A legacy client wouldn't wait for the jitter - they would ignore the > SYN-EOS flag in the SYN, and wouldn't know to wait. The OOB segment > would get silently dropped if/when it arrives. We seem to somehow miscommunicate the case description. Sorry, it's late here, maybe mea culpa. The case under discussion, which is the worst case scenario is: new client talking to new server with an evilbox in the middle dropping the OOB 100% of the time. > >> But if the client decides to retransmit the OOB (the worse performing >> case of the, the overall connection establishment time will be >> ~(2.5*RTT+Y). And there'd need to be logic to still fallback to the >> legacy behavior if the (Second, third?) OOB packet gets dropped. > > The client need not wait for a RTT to retransmit the OOB; multiple OOBs > have no impact on the server. Clients can send an OOB before and after > the SYN, and if the OOB gets there and is cached it wins; if the OOB > arrives after, the delay is just the arrival delay. See above on the definition of the worst case - the OOB spec does not appear to be clear. Maybe it's better to leave more ambiguity so this can be experimented with, but this this worst case was certainly at least to me one of the big differences between the 2-SYN and OOB approaches. --a > > Joe > From nobody Thu Sep 25 15:56:40 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B6671A00E9 for ; Thu, 25 Sep 2014 15:56:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.986 X-Spam-Level: X-Spam-Status: No, score=-4.986 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786] autolearn=ham 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 FaaS7CTemSWW for ; Thu, 25 Sep 2014 15:56:35 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C762C1A00D7 for ; Thu, 25 Sep 2014 15:56:35 -0700 (PDT) Received: from [128.9.160.211] (mul.isi.edu [128.9.160.211]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id s8PMteVh021263 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 25 Sep 2014 15:55:41 -0700 (PDT) Message-ID: <54249D6C.9010601@isi.edu> Date: Thu, 25 Sep 2014 15:55:40 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 MIME-Version: 1.0 To: Andrew Yourtchenko References: <201409222045.s8MKjZdD002071@bagheera.jungle.bt.co.uk> <542344DA.9020905@isi.edu> <201409250956.s8P9uae9013452@bagheera.jungle.bt.co.uk> <54244E05.9040009@isi.edu> <54247844.1050202@isi.edu> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/jk2tH72J86rm7SmWZTo7_bRf1MY Cc: tcpm IETF list Subject: Re: [tcpm] More TCP option space in a SYN: draft-briscoe-tcpm-syn-op-sis-02 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Sep 2014 22:56:37 -0000 On 9/25/2014 3:48 PM, Andrew Yourtchenko wrote: > On Thu, 25 Sep 2014, Joe Touch wrote: ... >>> OOB method has a permanent decision to stall the connection if the >>> upgraded server receives SYN-EOS OOB but no OOB segment (say, it's being >>> blocked by the middleboxes?), "after a certain time". This time >>> supposedly should be much shorter than the stall in the two-SYN case, >>> ideally a function of jitter on the path, let's call it Y. >> >> That can be zero if the OOB arrives first or during the processing of >> the SYN. > > Sure. It's not about reordering. It's about the worst case scenario. > > Best case scenarios "when everything works" both OOB and 2-SYNs are > ~equivalent, the mild failure cases are nicer with OOB iff Y is smaller > than X. OOB has the additional advantage of not consuming one more > connection slot for a short period of time on the middleboxes (and the > per-flow processing capacity). Also on legacy servers it opens only one connection. >>> If the client then proceeds as if the connection was legacy, the session >>> establishment time is ~(1.5RTT+Y) - so, better than two-SYNs. >> >> A legacy client wouldn't wait for the jitter - they would ignore the >> SYN-EOS flag in the SYN, and wouldn't know to wait. The OOB segment >> would get silently dropped if/when it arrives. > > We seem to somehow miscommunicate the case description. Sorry, it's late > here, maybe mea culpa. > > The case under discussion, which is the worst case scenario is: new > client talking to new server with an evilbox in the middle dropping the > OOB 100% of the time. That's one reason why we need to experiment with OOB packets; I don't know what will happen, except in the case when OOB comes too early before the SYN through a NAT. However, dual-SYN has the problem of potentially going to different servers or through different NATs and of opening multiple connections on legacy servers (thus impacting service rate). I wouldn't be surprised if the best path forward were to document each as a separate experiment and try them both. Joe From nobody Thu Sep 25 16:28:08 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A9AC1A00F4 for ; Thu, 25 Sep 2014 16:28:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.087 X-Spam-Level: X-Spam-Status: No, score=-14.087 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_14=0.6, J_CHICKENPOX_52=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 qvHMo5kNaZho for ; Thu, 25 Sep 2014 16:28:04 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 854F41A00F0 for ; Thu, 25 Sep 2014 16:28:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=18276; q=dns/txt; s=iport; t=1411687684; x=1412897284; h=date:from:to:cc:subject:in-reply-to:message-id: references:mime-version; bh=SQhaBp/3p2Jb+o27aGByXvXsximt8u84tyXGKU0ZdQc=; b=C3gFMQ294/y3EmSnnbq4EwBCcznzopbozCylRazBczMhjb+jns1iKCQn l+kdKzfTy2R+m7bS7H5sBYPPqlpY4JeYidTrgxruYjC4yXSYR+YL+NGgv zJjncsCEJBl4bWQCQvxG3sniMcvhmdsYH0K+9pW3N7EjcYxbYwrZMHter A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsgPABmkJFStJA2N/2dsb2JhbABXCYMOU1cEiEStaAEBAQEBAQUBcgGSewqHTgKBBhYBe4QDAQEBAwEBAQELGRECKwkEBwULCxguJzAGDgUbiBsIDcFgAReGEoQYhRIHCgFQB4RLAQSPSIZSgj6GLZN0g2VqAYEFBwIXBB6BAgEBAQ X-IronPort-AV: E=Sophos;i="5.04,600,1406592000"; d="scan'208";a="81372289" Received: from alln-core-8.cisco.com ([173.36.13.141]) by alln-iport-2.cisco.com with ESMTP; 25 Sep 2014 23:28:01 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id s8PNS1V7021418 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 25 Sep 2014 23:28:01 GMT Received: from ams-ayourtch-8813.cisco.com (10.55.47.212) by xhc-aln-x03.cisco.com (173.36.12.77) with Microsoft SMTP Server (TLS) id 14.3.195.1; Thu, 25 Sep 2014 18:28:00 -0500 Date: Fri, 26 Sep 2014 01:27:42 +0200 From: Andrew Yourtchenko X-X-Sender: ayourtch@ayourtch-mac To: Bob Briscoe In-Reply-To: <201409251842.s8PIgUdQ015414@bagheera.jungle.bt.co.uk> Message-ID: References: <201409222045.s8MKjZdD002071@bagheera.jungle.bt.co.uk> <542344DA.9020905@isi.edu> <201409250956.s8P9uae9013452@bagheera.jungle.bt.co.uk> <201409251842.s8PIgUdQ015414@bagheera.jungle.bt.co.uk> User-Agent: Alpine 2.00 (OSX 1167 2008-08-23) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII"; format=flowed X-Originating-IP: [10.55.47.212] Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/7fHP2E5_WVgTDywa7DtJjqD9S7g Cc: tcpm IETF list , Joe Touch Subject: Re: [tcpm] More TCP option space in a SYN: draft-briscoe-tcpm-syn-op-sis-02 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Sep 2014 23:28:07 -0000 Bob, On Thu, 25 Sep 2014, Bob Briscoe wrote: > Andrew, > > At 17:41 25/09/2014, Andrew Yourtchenko wrote: >> Bob, Joe, all, >> >> some comments below, maybe with some obvious questions as I did not follow >> the latest discussions very closely. >> >> On Thu, 25 Sep 2014, Bob Briscoe wrote: >> >>> Joe, >>> >>> At 23:25 24/09/2014, Joe Touch wrote: >>>> Hi, Bob (et al.), >>>> It's good to have a more detailed description of the proposal. >>>> I still find a dual-SYN solution untenable, though, as it has been for >>>> other upgrade paths in the past (e.g., IPv6). >>> >>> That's why I prefer syn-op-sis because it only uses 2 SYNs for transition. >> >> Both syn-op-sis and tcp-syn-ext-opt talk about using >> different port pairs - is this due to the explosion with the number of >> possibilities for the three-way handshake recovery ? > > SYN-EOS OOB (within tcp-syn-ext-opt) uses the same src & dst ports. > SYN-EOS DS (within tcp-syn-ext-opt) and syn-op-sis use same dst, but > different src. > > Rationale for latter: too many middleboxes out there that would reject a SYN > to/from the same ports, in their misguided attempts to be 'helpful' by > removing SYNs that appear to be duplicate or same 4-tuple but different > initial sequence no. Not only many firewalls, but all split connections would > not forward the second SYN. oh, *different* ISNs. Yes. I remember having to file a bug in at least one of the middleboxes that did not like such a scenario, it got fixed, but probably there're more. An experiment would be definitely interesting. > > >> (Of course the application will anyway see only 1 file descriptor, which >> will assume the identity of the connection that succeeds, right ?) > > Correct. > > > >>> I've included a new section on ways to use only 1 SYN during transition >>> (building a white-list) and ultimately moving to 1 SYN in the future, only >>> falling back to the legacy SYN in series rather than parallel if you hit a >>> legacy listener. >> >> The fundamental difference between the transition to the extended option >> space and IPv4->IPv6 transition is the absence of the DNS to signal the >> capabilities of the endpoint before the connection even starts - if the >> target host has A&AAAA you only have to deal with the failures on the path, >> while if the target host does not have AAAA record, it's worthless to try >> IPv6. >> >> OTOH, when attempt to negotiate the extended option space, you do not have >> any hints about the remote end - besides maybe past memory. >> >> In RFC6555 we tried to avoid dual-SYN as much as possible by providing a >> headstart that shrinks and inverses on failures - so the reference to >> RFC6555 being "parallel" is not correct, see section 5.5: >> >> The primary purpose of Happy Eyeballs is to reduce the wait time for >> a dual-stack connection to complete, especially when the IPv6 path is >> broken and IPv6 is preferred. Aggressive timeouts (on the order of >> tens of milliseconds) achieve this goal, but at the cost of network >> traffic. This network traffic may be billable on certain networks, >> will create state on some middleboxes (e.g., firewalls, intrusion >> detection systems, NATs), and will consume ports if IPv4 addresses >> are shared. For these reasons, it is RECOMMENDED that connection >> attempts be paced to give connections a chance to complete. It is >> RECOMMENDED that connection attempts be paced 150-250 ms apart to >> balance human factors against network load. > > The dual SYN approaches could use a delay between the SYNs like 6655 does > (not nec exactly the same numbers). However, in the short flow world, I would > argue that 250ms is completely unacceptable unless you're fairly certain the > first one will work, which is more-or-less the v4/v6 scenario that happy > eyeballs addressed. Reasoning: multiply 250ms by a few connections with > serial dependencies in a sequence and you have delays of seconds. > > I've made a note to change the description of 6555 in the next rev - clearly > the word parallel is not strictly correct anyway - one serial (e.g. network) > interface can't actually send two SYNs in parallel, the closest they can > leave is back-to-back. True... you might start with some conservative values, but then as you get RTT estimate for the connection, an implementation might opt to save that RTT estimate in a cache (http://www.tedunangst.com/flak/post/2Q-buffer-cache-algorithm seems maybe appropriate for this type of use?) And then we're somewhere in 6555 territory anyway. So much for simplicity! :-) > > Regarding billable total traffic: > Damon Wischik once proposed to improve performance by duplicating the most > sensitive packets at flow start: > "three copies of the first packet of every message, two copies of the > second and one copy of subsequent packets" > He calculated these 6 extra full-sized packets per flow would (in 2005) > increase total traffic by 2.7% (because elephants dominate total traffic). > > Duplicating just the legacy part of the SYN (60B max) would have a much > smaller total effect (I could calculate it if you want - probably sub-0.1%). > Certainly too small for people to care about the increment on bills or even > packet load. Thanks for the link! I will read it in detail tomorrow, for now just glanced, and there does not seem to be any discussion of what happens if the link is constrained ? Some time ago I had to work a nontrivial amount of time over a 3G throttled down to 64Kbps, and a number of tricks were required to change the experience from "unusable" to "slow but eventually loaded": switch from Chrome to Firefox (primarily because of my lack of knowledge of deep tuning for the former, maybe there was a better way!), and reducing the number of simultaneous connections down to 4, from 32. Maybe it's small enough and I am being paranoid, but the 64kbps environments are still real (unfortunately). > > >> In today's conditions, a simple 300ms headstart for IPv6 if AAAA is >> advertised might be sufficient, as the subpar IPv6 connectivity >> disappears, and more of the corner cases get into play for RTTs. >> >> So, depending on how much of a drop rate we'd expect for a "new" SYN across >> the variety of network scenarios, the simpler approach of just using 300ms >> delay could be reasonable due to its simplicity - an experiment could show. >> >> Doing this experiment on both address families at once could also reveal >> the drop rates to be different - I'd expect the IPv6 drop rates to be >> smaller - so maybe there is an opportunity to simplify things - if it "just >> works" in IPv6 using a single fancy-looking SYN in a sufficient %% of >> cases, that could be a great simplification *and* will give additional use >> case for IPv6 assuming there is enough demand for more space in the >> options. > > The delay between the pair should be implementation dependent anyway. No > point arguing this to death in standards... but I will at least state the > opposing view... > > The world is changing. Latency is everything and soon it will be even more > than everything. If one values latency, the delay between the two will be as > small as possible. Agreed. > > My simple view of the world is that, dual SYN seems the /only/ way to extend > TCP option space. I'm not proud of it. It's not nice. But it's necessary. If > dual SYNs require more memory for connection state, it's OK as long as the > need for more memory appears slowly enough to be able to deploy it. If this > is the price of extra capabilities, and those capabilities are valued, then > we invest in memory to provide the capabilities. > > Whether the number of connections that need >40B TCP options will suddenly > jump, or gradually grow, I can't predict tho. > Again, makes sense. > > >>> The other two in tcp-syn-ext-opt have to be 2-SYN for ever. >>> >>>> Also, I don't particularly think that putting the options at the end of >>>> the segment serves any useful purpose other than to make this option >>>> handle the option space in a different way than the default DO header >>>> field. >>> >>> That's the architectural point. >>> There's also a tactical point. It should get through every middlebox. >> >> Help me understand this argument. If we were sending the "old" and "new" >> SYNs on the same 5-tuple - sure, the data must be identical. >> But if source ports are different, then a typical middlebox is either happy >> about the "data in the SYN" or not ? >> >> Or, are you saying that placing them at the end of the packet makes it >> difficult for the current architectures to "grab" them and mess around with >> them ? Sure, it does. Especially higher-performing boxes might look at the >> start of the packet. >> >> But that's *today's* architectures - if someone pays one of my employer's >> BUs enough to create a box that fiddles with these options, that box will >> get created. Not an architecturally beautiful reality, but it is there. > > Two clarifications: > > 1) By putting options after the payload, I'm including the (currently common) > case of a SYN with no payload. Then the extra options will start immediately > at the Data Offset. > > 2) A longer clarification... > > Let's separate middleboxes into two types (I'm trying to deal with both): > - (meddleboxes) those that want to mess with headers for security > - (muddleboxes) those that happen to mess with headers, because their > developers never stopped to think that TCP might change. > > Muddleboxes tend to forward the payload unaltered. Some muddleboxes look at > HTTP headers and try to be clever. By putting extra options after the Data > Offset, they will pass the former. By putting them at the end of the payload > they will mostly pass the latter. > > Meddleboxes might well evolve to find these new extra options at the end of > the packet. But in the meantime, we've got over the transition of deploying a > new protocol. Then the meddleboxes are on the back foot, and they have to > justify removing these packets that are useful to someone. If they can - e.g. > for security reasons - then fine. But they are not just removing packets > because they are using a new rev of the protocol. > > As I said, the most important thing is we will have separated TCP options > into two sets: > - Those that middleboxes (past and future) can mess with > - Those that middleboxes (future) should think much harder about before > messing with them > > Then, this (maybe) enables the next step - for endpoints to encrypt those > options they don't want middleboxes to interact with at all. (See my response > to Alex Zimmerman's post in this thread.) > Thanks for the detailed explanation! This might be useful to just copypaste into the draft in the next rev, for the rationale. Now, a trick question. We all know IPv4 is entrenched with middleboxes necessarily meddling with L7 because they have to do NAT in the process. What about IPv6 ? I have a totally unfounded hope that there the situation might be better, at least for now ? > > >>>> I'm glad to hear what others think and agree that an unbiased comparison >>>> of the approaches would be a useful place to for the discussion to >>>> start... >>> >>> Yes, I'm already repeating myself - you're right we need wider opinions. >> >> Even though I am nominally "on the list of alternatives" due to LOIC, I've >> disliked the idea shortly after, after trying to implement it - the linux >> kernel's accelerated NIC path showed that the invalid CRC would be dropped >> very early, before the software can see it - so I would argue against that >> approach today from implementation standpoint as well. >> >> Hopefully arguing with my past self does buy me an "unbiased" ribbon, or at >> least a half of it :-) > > Certainly, this seems to give you the role of unbiased /and/ educated by > experience. > > I'm also no longer like an idea that my past self proposed (SYN-EOS DS), for > the same reasons Joe didn't like it - the two SYNs will often not end up in > the same place to be re-united. But I still have a candidate I do prefer > (syn-op-sis). That rules me out for the role of innocent bystander. Probably the best way to decide is to implement both, get them in parallel into the olde wilde internets and see what sticks better! --a > > > Bob > > >> --a >> >>> >>> >>> >>> Bob >>> >>> >>>> Joe >>>> On 9/22/2014 7:55 AM, Bob Briscoe wrote: >>>> > Joe, >>>> > >>>> > I've just posted a revision here: >>>> > >>>> > >>>> > * I've taken more care to explain it. It was a bit terse before. So >>>> it's >>>> > ready for the list to review properly now. >>>> > >>>> > It would be useful if someone wrote a comparison with the other ideas >>>> on >>>> > how to do this, including the ones we wrote jointly and SLO, LOIC and >>>> > DBormam's 4-way HS. Better someone independent of all the authors does >>>> > this. But I want to get syn-op-sis right first, a comparison won't be >>>> > much use until its stable. >>>> > >>>> > >>>> > The underlying idea is still the same. The reasons I've updated it are >>>> > many (the change log taken from the appendix is pasted at the end of >>>> > this email for convenience). >>>> > >>>> > * Mainly I've articulated that all these approaches that add TCP >>>> options >>>> > after the Data Offset are not just hacks to get more space; they add a >>>> > new architectural capability to TCP - a distinction between TCP options >>>> > that might be relevant to middleboxes, and ones that are only for the >>>> > destination (a bit like destopt in IPv6 - needing to specify which TCP >>>> > options are for the destination only is ironic but necessary). >>>> > >>>> > * I've also realised that this approach will ultimately return to a >>>> > single SYN solution, whereas both the ideas in >>>> > draft-touch-tcpm-tcp-syn-ext-opt will always require two SYNs. >>>> > >>>> > >>>> > >>>> > Bob >>>> > >>>> > Pasted from the change log: >>>> > >>>> > From briscoe...-01 to briscoe...-02: >>>> > >>>> > Technical changes: >>>> > >>>> > * Defined the client behaviour dependent on which response >>>> > arrives first. >>>> > >>>> > * Allowed retransmission of either SYN or SYN-U if no response >>>> > from either. >>>> > >>>> > * Redefined EOO as an offset from the end of the packet, not >>>> from >>>> > the beginning of the payload. >>>> > >>>> > * Added section on Migration to a Single Handshake. Reworded >>>> > dual handshake so that it is not mandatory for the client to >>>> > send dual SYNs simultaneously; only the relation between the >>>> > SYNs and the response to either is mandatory, while parallel >>>> > SYNs is purely for latency reduction. >>>> > >>>> > * Added rules for writing TCP options, i.e. i) options like TFO >>>> > MUST NOT be located in the TCP header and ii) add no-ops to >>>> > align on 4-octet boundary. >>>> > >>>> > * Added rules for forwarding TCP options, i.e. only the >>>> > destination looks for TCP options after the Data Offset, not >>>> > middleboxes. >>>> > >>>> > * Moved the Explicit Handshake variant (SYN-L) into the body >>>> from >>>> > the appendix, and recommended the choice could be down to >>>> > implementers or apps. Included section on corner cases. >>>> > >>>> > * Introduced more normative language throughout the Protocol >>>> > Spec. >>>> > >>>> > Editorial changes: >>>> > >>>> > * Added temporary motivation section >>>> > >>>> > * Added confusible terminology to Terminology section. >>>> > >>>> > * Divided protocol spec into sub-sections. >>>> > >>>> > * Handshake table: Clarified that the two columns under each >>>> > server represent separate threads, that may run on separate >>>> > servers, without co-ordination. Represented message >>>> > dependencies in the alignment of the rows. >>>> > >>>> > * Explained the table. >>>> > >>>> > * Explained why a legacy server won't ever pass SYN-U to the >>>> app. >>>> > >>>> > * More precisely described loss as 'not arrived before a >>>> > timeout', and explained the tradeoff between latency and extra >>>> > TCP options. >>>> > >>>> > * Gave reasoning for locating TCP options in three groups. >>>> > >>>> > * Acknowledged Rob Hancock for the architectural idea of hiding >>>> > an extension to a protocol in the layer above. >>>> > >>>> > * Appendix about protocol alternatives now only presents the >>>> SYN- >>>> > UD alternative, given the implicit/explicit handshake choice >>>> > has been moved to the body. >>>> > >>>> > * Rewrote appendix about comparing the choices to treat the two >>>> > pairs of choices separately, rather than discussing all four >>>> > combinations of pairs of choices. >>>> > >>>> > ________________________________________________________________ >>>> > Bob Briscoe, BT >>> >>> ________________________________________________________________ >>> Bob Briscoe, BT >>> _______________________________________________ >>> tcpm mailing list >>> tcpm@ietf.org >>> https://www.ietf.org/mailman/listinfo/tcpm >> >> ________________________________________________________________ >> Bob Briscoe, BT From nobody Fri Sep 26 02:58:03 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 694151A1ABC for ; Fri, 26 Sep 2014 02:58:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.187 X-Spam-Level: X-Spam-Status: No, score=-2.187 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_14=0.6, J_CHICKENPOX_52=0.6, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=ham 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 J1Eb0piSTUjP for ; Fri, 26 Sep 2014 02:57:58 -0700 (PDT) Received: from hubrelay-by-04.bt.com (hubrelay-by-04.bt.com [62.7.242.140]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3FCF31A1A6D for ; Fri, 26 Sep 2014 02:57:57 -0700 (PDT) Received: from EVMHR01-UKBR.domain1.systemhost.net (193.113.108.40) by EVMHR04-UKBR.bt.com (10.216.161.36) with Microsoft SMTP Server (TLS) id 8.3.348.2; Fri, 26 Sep 2014 10:58:42 +0100 Received: from EPHR01-UKIP.domain1.systemhost.net (147.149.196.177) by EVMHR01-UKBR.domain1.systemhost.net (193.113.108.40) with Microsoft SMTP Server (TLS) id 8.3.348.2; Fri, 26 Sep 2014 10:57:54 +0100 Received: from bagheera.jungle.bt.co.uk (132.146.168.158) by EPHR01-UKIP.domain1.systemhost.net (147.149.196.177) with Microsoft SMTP Server id 14.3.181.6; Fri, 26 Sep 2014 10:57:49 +0100 Received: from BTP075694.jungle.bt.co.uk ([10.215.130.93]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id s8Q9vmEd018560; Fri, 26 Sep 2014 10:57:48 +0100 Message-ID: <201409260957.s8Q9vmEd018560@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 26 Sep 2014 10:56:42 +0100 To: Andrew Yourtchenko From: Bob Briscoe In-Reply-To: References: <201409222045.s8MKjZdD002071@bagheera.jungle.bt.co.uk> <542344DA.9020905@isi.edu> <201409250956.s8P9uae9013452@bagheera.jungle.bt.co.uk> <201409251842.s8PIgUdQ015414@bagheera.jungle.bt.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/KpvvBgVrNQUGl6G6udhZASOD8QI Cc: tcpm IETF list , Joe Touch Subject: Re: [tcpm] More TCP option space in a SYN: draft-briscoe-tcpm-syn-op-sis-02 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Sep 2014 09:58:02 -0000 Andrew, At 00:27 26/09/2014, Andrew Yourtchenko wrote: >Bob, > >On Thu, 25 Sep 2014, Bob Briscoe wrote: > >>Andrew, >> >>At 17:41 25/09/2014, Andrew Yourtchenko wrote: >>>Bob, Joe, all, >>>some comments below, maybe with some obvious questions as I did >>>not follow the latest discussions very closely. >>>On Thu, 25 Sep 2014, Bob Briscoe wrote: >>> >>>>Joe, >>>>At 23:25 24/09/2014, Joe Touch wrote: >>>>>Hi, Bob (et al.), >>>>>It's good to have a more detailed description of the proposal. >>>>>I still find a dual-SYN solution untenable, though, as it has been for >>>>>other upgrade paths in the past (e.g., IPv6). >>>>That's why I prefer syn-op-sis because it only uses 2 SYNs for transition. >>>Both syn-op-sis and tcp-syn-ext-opt talk about using >>>different port pairs - is this due to the explosion with the >>>number of possibilities for the three-way handshake recovery ? >> >>SYN-EOS OOB (within tcp-syn-ext-opt) uses the same src & dst ports. >>SYN-EOS DS (within tcp-syn-ext-opt) and syn-op-sis use same dst, >>but different src. >> >>Rationale for latter: too many middleboxes out there that would >>reject a SYN to/from the same ports, in their misguided attempts to >>be 'helpful' by removing SYNs that appear to be duplicate or same >>4-tuple but different initial sequence no. Not only many firewalls, >>but all split connections would not forward the second SYN. > >oh, *different* ISNs. Yes. I remember having to file a bug in at >least one of the middleboxes that did not like such a scenario, it >got fixed, but probably there're more. An experiment would be >definitely interesting. To be absolutely clear: a) SYN-EOS OOB client sends a SYN and an OOB segment to complement it, using same src & dst ports. The OOB segment has SYN=0, ACK=0 and the seqno is the same as the ISN of the SYN. b) SYN-EOS DS client sends 2 complementary SYNs, using same dst port, but different src ports and different ISNs. c) syn-op-sis client sends 2 alternative SYNs, using same dst port, but different src ports and different ISNs. a & b use the word 'complement', which means an upgraded server needs to have received both segments to start an upgraded connection. c uses the word 'alternative', which means a server can start a connection when it receives either, and the upgraded handshake only completes if it's an upgraded server. >>>(Of course the application will anyway see only 1 file descriptor, >>>which will assume the identity of the connection that succeeds, right ?) >> >>Correct. >> >> >> >>>>I've included a new section on ways to use only 1 SYN during >>>>transition (building a white-list) and ultimately moving to 1 SYN >>>>in the future, only falling back to the legacy SYN in series >>>>rather than parallel if you hit a legacy listener. >>>The fundamental difference between the transition to the extended >>>option space and IPv4->IPv6 transition is the absence of the DNS >>>to signal the capabilities of the endpoint before the connection >>>even starts - if the target host has A&AAAA you only have to deal >>>with the failures on the path, while if the target host does not >>>have AAAA record, it's worthless to try IPv6. >>>OTOH, when attempt to negotiate the extended option space, you do >>>not have any hints about the remote end - besides maybe past memory. >>>In RFC6555 we tried to avoid dual-SYN as much as possible by >>>providing a headstart that shrinks and inverses on failures - so >>>the reference to RFC6555 being "parallel" is not correct, see section 5.5: >>> >>> The primary purpose of Happy Eyeballs is to reduce the wait time for >>> a dual-stack connection to complete, especially when the IPv6 path is >>> broken and IPv6 is preferred. Aggressive timeouts (on the order of >>> tens of milliseconds) achieve this goal, but at the cost of network >>> traffic. This network traffic may be billable on certain networks, >>> will create state on some middleboxes (e.g., firewalls, intrusion >>> detection systems, NATs), and will consume ports if IPv4 addresses >>> are shared. For these reasons, it is RECOMMENDED that connection >>> attempts be paced to give connections a chance to complete. It is >>> RECOMMENDED that connection attempts be paced 150-250 ms apart to >>> balance human factors against network load. >> >>The dual SYN approaches could use a delay between the SYNs like >>6655 does (not nec exactly the same numbers). However, in the short >>flow world, I would argue that 250ms is completely unacceptable >>unless you're fairly certain the first one will work, which is >>more-or-less the v4/v6 scenario that happy eyeballs addressed. >>Reasoning: multiply 250ms by a few connections with serial >>dependencies in a sequence and you have delays of seconds. >> >>I've made a note to change the description of 6555 in the next rev >>- clearly the word parallel is not strictly correct anyway - one >>serial (e.g. network) interface can't actually send two SYNs in >>parallel, the closest they can leave is back-to-back. > >True... you might start with some conservative values, but then as >you get RTT estimate for the connection, an implementation might opt >to save that RTT estimate in a cache >(http://www.tedunangst.com/flak/post/2Q-buffer-cache-algorithm seems >maybe appropriate for this type of use?) And then we're somewhere in >6555 territory anyway. So much for simplicity! :-) Cache algos don't have to be standardised. The standard can be simple, and implementers can tradeoff simplicity for latency. >>Regarding billable total traffic: >>Damon Wischik once proposed to improve performance by duplicating >>the most sensitive packets at flow start: >> "three copies of the first packet of every message, two >> copies of the second and one copy of subsequent packets" >>He calculated these 6 extra full-sized packets per flow would (in >>2005) increase total traffic by 2.7% (because elephants dominate >>total traffic). >> >>Duplicating just the legacy part of the SYN (60B max) would have a >>much smaller total effect (I could calculate it if you want - >>probably sub-0.1%). Certainly too small for people to care about >>the increment on bills or even packet load. > >Thanks for the link! I will read it in detail tomorrow, for now just >glanced, and there does not seem to be any discussion of what >happens if the link is constrained ? > >Some time ago I had to work a nontrivial amount of time over a 3G >throttled down to 64Kbps, and a number of tricks were required to >change the experience from "unusable" to "slow but eventually >loaded": switch from Chrome to Firefox (primarily because of my lack >of knowledge of deep tuning for the former, maybe there was a better >way!), and reducing the number of simultaneous connections down to 4, from 32. > >Maybe it's small enough and I am being paranoid, but the 64kbps >environments are still real (unfortunately). The number of simulataneous connections is certainly critical for a constrained environment. But the dual SYN approaches don't double the number of /connections/, they only double the number of SYNs (in the worst case when all connections need large TCP options at the start). I haven't done the proper calculation, but a rough estimate based on Wischik would be 0.05% more bytes. >>>In today's conditions, a simple 300ms headstart for IPv6 if AAAA >>>is advertised might be sufficient, as the subpar IPv6 connectivity >>>disappears, and more of the corner cases get into play for RTTs. >>>So, depending on how much of a drop rate we'd expect for a "new" >>>SYN across the variety of network scenarios, the simpler approach >>>of just using 300ms delay could be reasonable due to its >>>simplicity - an experiment could show. >>>Doing this experiment on both address families at once could also >>>reveal the drop rates to be different - I'd expect the IPv6 drop >>>rates to be smaller - so maybe there is an opportunity to simplify >>>things - if it "just works" in IPv6 using a single fancy-looking >>>SYN in a sufficient %% of cases, that could be a great >>>simplification *and* will give additional use case for IPv6 >>>assuming there is enough demand for more space in the options. >> >>The delay between the pair should be implementation dependent >>anyway. No point arguing this to death in standards... but I will >>at least state the opposing view... >> >>The world is changing. Latency is everything and soon it will be >>even more than everything. If one values latency, the delay between >>the two will be as small as possible. > >Agreed. > >> >>My simple view of the world is that, dual SYN seems the /only/ way >>to extend TCP option space. I'm not proud of it. It's not nice. But >>it's necessary. If dual SYNs require more memory for connection >>state, it's OK as long as the need for more memory appears slowly >>enough to be able to deploy it. If this is the price of extra >>capabilities, and those capabilities are valued, then we invest in >>memory to provide the capabilities. >> >>Whether the number of connections that need >40B TCP options will >>suddenly jump, or gradually grow, I can't predict tho. > >Again, makes sense. Especially to someone who sells memory ;) >>>>The other two in tcp-syn-ext-opt have to be 2-SYN for ever. >>>> >>>>>Also, I don't particularly think that putting the options at the end of >>>>>the segment serves any useful purpose other than to make this option >>>>>handle the option space in a different way than the default DO >>>>>header field. >>>>That's the architectural point. >>>>There's also a tactical point. It should get through every middlebox. >>>Help me understand this argument. If we were sending the "old" and >>>"new" SYNs on the same 5-tuple - sure, the data must be identical. >>>But if source ports are different, then a typical middlebox is >>>either happy about the "data in the SYN" or not ? >>>Or, are you saying that placing them at the end of the packet >>>makes it difficult for the current architectures to "grab" them >>>and mess around with them ? Sure, it does. Especially >>>higher-performing boxes might look at the start of the packet. >>>But that's *today's* architectures - if someone pays one of my >>>employer's BUs enough to create a box that fiddles with these >>>options, that box will get created. Not an architecturally >>>beautiful reality, but it is there. >> >>Two clarifications: >> >>1) By putting options after the payload, I'm including the >>(currently common) case of a SYN with no payload. Then the extra >>options will start immediately at the Data Offset. >> >>2) A longer clarification... >> >>Let's separate middleboxes into two types (I'm trying to deal with both): >>- (meddleboxes) those that want to mess with headers for security >>- (muddleboxes) those that happen to mess with headers, because >>their developers never stopped to think that TCP might change. >> >>Muddleboxes tend to forward the payload unaltered. Some muddleboxes >>look at HTTP headers and try to be clever. By putting extra options >>after the Data Offset, they will pass the former. By putting them >>at the end of the payload they will mostly pass the latter. >> >>Meddleboxes might well evolve to find these new extra options at >>the end of the packet. But in the meantime, we've got over the >>transition of deploying a new protocol. Then the meddleboxes are on >>the back foot, and they have to justify removing these packets that >>are useful to someone. If they can - e.g. for security reasons - >>then fine. But they are not just removing packets because they are >>using a new rev of the protocol. >> >>As I said, the most important thing is we will have separated TCP >>options into two sets: >>- Those that middleboxes (past and future) can mess with >>- Those that middleboxes (future) should think much harder about >>before messing with them >> >>Then, this (maybe) enables the next step - for endpoints to encrypt >>those options they don't want middleboxes to interact with at all. >>(See my response to Alex Zimmerman's post in this thread.) > >Thanks for the detailed explanation! This might be useful to just >copypaste into the draft in the next rev, for the rationale. I've added a 'Design Rationale' section for the next rev. >Now, a trick question. We all know IPv4 is entrenched with >middleboxes necessarily meddling with L7 because they have to do NAT >in the process. >What about IPv6 ? I have a totally unfounded hope that there the >situation might be better, at least for now ? Sorry to disappoint, but AFAIK the only middlebox function that is IPv4-specific is NAT. Firewalls, Web-filters, connection splitters, PEPs, WAN accelerators, DPI, app-layer load balancers, etc all serve functions that are nothing to do with address lengths. And even NATs serve an obfuscation function, not just address-space expansion. >>>>>I'm glad to hear what others think and agree that an unbiased comparison >>>>>of the approaches would be a useful place to for the discussion >>>>>to start... >>>>Yes, I'm already repeating myself - you're right we need wider opinions. >>>Even though I am nominally "on the list of alternatives" due to >>>LOIC, I've disliked the idea shortly after, after trying to >>>implement it - the linux kernel's accelerated NIC path showed that >>>the invalid CRC would be dropped very early, before the software >>>can see it - so I would argue against that approach today from >>>implementation standpoint as well. >>>Hopefully arguing with my past self does buy me an "unbiased" >>>ribbon, or at least a half of it :-) >> >>Certainly, this seems to give you the role of unbiased /and/ >>educated by experience. >> >>I'm also no longer like an idea that my past self proposed (SYN-EOS >>DS), for the same reasons Joe didn't like it - the two SYNs will >>often not end up in the same place to be re-united. But I still >>have a candidate I do prefer (syn-op-sis). That rules me out for >>the role of innocent bystander. > >Probably the best way to decide is to implement both, get them in >parallel into the olde wilde internets and see what sticks better! Before going to the trouble of implementation, some middlebox traversal testing of the proposed packet formats might weed out the field. I have a suspicion that the OOB segment won't get very far in many cases - it's unlikely that all firewalls and intrusion detection systems will allow the unusual ACK=0, SYN=0 and the same seqno as the SYN. Cheers Bob >--a > >> >> >>Bob >> >> >>>--a >>> >>>> >>>>Bob >>>> >>>>>Joe >>>>>On 9/22/2014 7:55 AM, Bob Briscoe wrote: >>>>> > Joe, >>>>> > >>>>> > I've just posted a revision here: >>>>> > >>>>> > >>>>> > * I've taken more care to explain it. It was a bit terse >>>>> before. So it's >>>>> > ready for the list to review properly now. >>>>> > >>>>> > It would be useful if someone wrote a comparison with the >>>>> other ideas on >>>>> > how to do this, including the ones we wrote jointly and SLO, LOIC and >>>>> > DBormam's 4-way HS. Better someone independent of all the authors does >>>>> > this. But I want to get syn-op-sis right first, a comparison won't be >>>>> > much use until its stable. >>>>> > >>>>> > >>>>> > The underlying idea is still the same. The reasons I've updated it are >>>>> > many (the change log taken from the appendix is pasted at the end of >>>>> > this email for convenience). >>>>> > >>>>> > * Mainly I've articulated that all these approaches that add >>>>> TCP options >>>>> > after the Data Offset are not just hacks to get more space; they add a >>>>> > new architectural capability to TCP - a distinction between TCP options >>>>> > that might be relevant to middleboxes, and ones that are only for the >>>>> > destination (a bit like destopt in IPv6 - needing to specify which TCP >>>>> > options are for the destination only is ironic but necessary). >>>>> > >>>>> > * I've also realised that this approach will ultimately return to a >>>>> > single SYN solution, whereas both the ideas in >>>>> > draft-touch-tcpm-tcp-syn-ext-opt will always require two SYNs. >>>>> > >>>>> > >>>>> > >>>>> > Bob >>>>> > >>>>> > Pasted from the change log: >>>>> > >>>>> > From briscoe...-01 to briscoe...-02: >>>>> > >>>>> > Technical changes: >>>>> > >>>>> > * Defined the client behaviour dependent on which response >>>>> > arrives first. >>>>> > >>>>> > * Allowed retransmission of either SYN or SYN-U if no response >>>>> > from either. >>>>> > >>>>> > * Redefined EOO as an offset from the end of the >>>>> packet, not from >>>>> > the beginning of the payload. >>>>> > >>>>> > * Added section on Migration to a Single Handshake. Reworded >>>>> > dual handshake so that it is not mandatory for the client to >>>>> > send dual SYNs simultaneously; only the relation between the >>>>> > SYNs and the response to either is mandatory, while parallel >>>>> > SYNs is purely for latency reduction. >>>>> > >>>>> > * Added rules for writing TCP options, i.e. i) options like TFO >>>>> > MUST NOT be located in the TCP header and ii) add no-ops to >>>>> > align on 4-octet boundary. >>>>> > >>>>> > * Added rules for forwarding TCP options, i.e. only the >>>>> > destination looks for TCP options after the Data Offset, not >>>>> > middleboxes. >>>>> > >>>>> > * Moved the Explicit Handshake variant (SYN-L) into >>>>> the body from >>>>> > the appendix, and recommended the choice could be down to >>>>> > implementers or apps. Included section on corner cases. >>>>> > >>>>> > * Introduced more normative language throughout the Protocol >>>>> > Spec. >>>>> > >>>>> > Editorial changes: >>>>> > >>>>> > * Added temporary motivation section >>>>> > >>>>> > * Added confusible terminology to Terminology section. >>>>> > >>>>> > * Divided protocol spec into sub-sections. >>>>> > >>>>> > * Handshake table: Clarified that the two columns under each >>>>> > server represent separate threads, that may run on separate >>>>> > servers, without co-ordination. Represented message >>>>> > dependencies in the alignment of the rows. >>>>> > >>>>> > * Explained the table. >>>>> > >>>>> > * Explained why a legacy server won't ever pass SYN-U >>>>> to the app. >>>>> > >>>>> > * More precisely described loss as 'not arrived before a >>>>> > timeout', and explained the tradeoff between latency and extra >>>>> > TCP options. >>>>> > >>>>> > * Gave reasoning for locating TCP options in three groups. >>>>> > >>>>> > * Acknowledged Rob Hancock for the architectural idea of hiding >>>>> > an extension to a protocol in the layer above. >>>>> > >>>>> > * Appendix about protocol alternatives now only >>>>> presents the SYN- >>>>> > UD alternative, given the implicit/explicit handshake choice >>>>> > has been moved to the body. >>>>> > >>>>> > * Rewrote appendix about comparing the choices to treat the two >>>>> > pairs of choices separately, rather than discussing all four >>>>> > combinations of pairs of choices. >>>>> > >>>>> > ________________________________________________________________ >>>>> > Bob Briscoe, BT >>>>________________________________________________________________ >>>>Bob Briscoe, BT >>>>_______________________________________________ >>>>tcpm mailing list >>>>tcpm@ietf.org >>>>https://www.ietf.org/mailman/listinfo/tcpm >>>________________________________________________________________ >>>Bob Briscoe, BT >> >>________________________________________________________________ >>Bob Briscoe, BT From nobody Fri Sep 26 04:15:44 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 935F51A1AC8 for ; Fri, 26 Sep 2014 04:15:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.087 X-Spam-Level: X-Spam-Status: No, score=-14.087 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_14=0.6, J_CHICKENPOX_52=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 a6jcSsBEZ8mC for ; Fri, 26 Sep 2014 04:15:37 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 42C731A1A8C for ; Fri, 26 Sep 2014 04:15:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=22770; q=dns/txt; s=iport; t=1411730137; x=1412939737; h=date:from:to:cc:subject:in-reply-to:message-id: references:mime-version; bh=ef5HrdRrw2KxXpouH/ajTMhN5mOwvHj4aIq6ghBnOeI=; b=f4gKzOd4pCz68L+xsDmDDqtHdSo5Cy5K4iXE5mIdK5BX3EvmMw+1itNx lWptuj/ES0L6FLzDClgoMgmS4ctb0ZPfj2ApWDhB3W7gM2BbzyiJVBMiB o4CVkHLBjvTG5NX1H1khpl/RCxpOx7cSNWMuy4yNrDRqtDYLa75GRIs9o 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjgOAM9JJVStJA2K/2dsb2JhbABXAwaDDlNXBIhErX4BAgUBcpJ+CodOAoEGFgF7hAMBAQECAQEBAQELDA0RAisJBAcFCwsYLicwBg4FG4gbCA3AVQEXhhKEGIUSBwoBDQFCB4RLBY9LhlKCPoYtk3iBaiAWgUVqAYEFAgUCFwQegQIBAQE X-IronPort-AV: E=Sophos;i="5.04,604,1406592000"; d="scan'208";a="358410467" Received: from alln-core-5.cisco.com ([173.36.13.138]) by rcdn-iport-5.cisco.com with ESMTP; 26 Sep 2014 11:15:35 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s8QBFZqa016781 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 26 Sep 2014 11:15:35 GMT Received: from ams-ayourtch-8813.cisco.com (10.55.47.212) by xhc-aln-x03.cisco.com (173.36.12.77) with Microsoft SMTP Server (TLS) id 14.3.195.1; Fri, 26 Sep 2014 06:15:33 -0500 Date: Fri, 26 Sep 2014 13:15:15 +0200 From: Andrew Yourtchenko X-X-Sender: ayourtch@ayourtch-mac To: Bob Briscoe In-Reply-To: <201409260957.s8Q9vmEd018560@bagheera.jungle.bt.co.uk> Message-ID: References: <201409222045.s8MKjZdD002071@bagheera.jungle.bt.co.uk> <542344DA.9020905@isi.edu> <201409250956.s8P9uae9013452@bagheera.jungle.bt.co.uk> <201409251842.s8PIgUdQ015414@bagheera.jungle.bt.co.uk> <201409260957.s8Q9vmEd018560@bagheera.jungle.bt.co.uk> User-Agent: Alpine 2.00 (OSX 1167 2008-08-23) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII"; format=flowed X-Originating-IP: [10.55.47.212] Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/9ArwUbzio0BP-pmG6SUbvRoeLDI Cc: tcpm IETF list , Joe Touch Subject: Re: [tcpm] More TCP option space in a SYN: draft-briscoe-tcpm-syn-op-sis-02 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Sep 2014 11:15:41 -0000 Bob, On Fri, 26 Sep 2014, Bob Briscoe wrote: > Andrew, > > At 00:27 26/09/2014, Andrew Yourtchenko wrote: >> Bob, >> >> On Thu, 25 Sep 2014, Bob Briscoe wrote: >> >>> Andrew, >>> >>> At 17:41 25/09/2014, Andrew Yourtchenko wrote: >>>> Bob, Joe, all, >>>> some comments below, maybe with some obvious questions as I did not >>>> follow the latest discussions very closely. >>>> On Thu, 25 Sep 2014, Bob Briscoe wrote: >>>> >>>>> Joe, >>>>> At 23:25 24/09/2014, Joe Touch wrote: >>>>>> Hi, Bob (et al.), >>>>>> It's good to have a more detailed description of the proposal. >>>>>> I still find a dual-SYN solution untenable, though, as it has been for >>>>>> other upgrade paths in the past (e.g., IPv6). >>>>> That's why I prefer syn-op-sis because it only uses 2 SYNs for >>>>> transition. >>>> Both syn-op-sis and tcp-syn-ext-opt talk about using >>>> different port pairs - is this due to the explosion with the number of >>>> possibilities for the three-way handshake recovery ? >>> >>> SYN-EOS OOB (within tcp-syn-ext-opt) uses the same src & dst ports. >>> SYN-EOS DS (within tcp-syn-ext-opt) and syn-op-sis use same dst, but >>> different src. >>> >>> Rationale for latter: too many middleboxes out there that would reject a >>> SYN to/from the same ports, in their misguided attempts to be 'helpful' by >>> removing SYNs that appear to be duplicate or same 4-tuple but different >>> initial sequence no. Not only many firewalls, but all split connections >>> would not forward the second SYN. >> >> oh, *different* ISNs. Yes. I remember having to file a bug in at least one >> of the middleboxes that did not like such a scenario, it got fixed, but >> probably there're more. An experiment would be definitely interesting. > > To be absolutely clear: > a) SYN-EOS OOB client sends a SYN and an OOB segment to complement it, using > same src & dst ports. The OOB segment has SYN=0, ACK=0 and the seqno is the > same as the ISN of the SYN. > > b) SYN-EOS DS client sends 2 complementary SYNs, using same dst port, but > different src ports and different ISNs. > > c) syn-op-sis client sends 2 alternative SYNs, using same dst port, but > different src ports and different ISNs. > > a & b use the word 'complement', which means an upgraded server needs to have > received both segments to start an upgraded connection. > > c uses the word 'alternative', which means a server can start a connection > when it receives either, and the upgraded handshake only completes if it's an > upgraded server. This is a very useful and succing comparison, thanks! > > >>>> (Of course the application will anyway see only 1 file descriptor, which >>>> will assume the identity of the connection that succeeds, right ?) >>> >>> Correct. >>> >>> >>> >>>>> I've included a new section on ways to use only 1 SYN during transition >>>>> (building a white-list) and ultimately moving to 1 SYN in the future, >>>>> only falling back to the legacy SYN in series rather than parallel if >>>>> you hit a legacy listener. >>>> The fundamental difference between the transition to the extended option >>>> space and IPv4->IPv6 transition is the absence of the DNS to signal the >>>> capabilities of the endpoint before the connection even starts - if the >>>> target host has A&AAAA you only have to deal with the failures on the >>>> path, while if the target host does not have AAAA record, it's worthless >>>> to try IPv6. >>>> OTOH, when attempt to negotiate the extended option space, you do not >>>> have any hints about the remote end - besides maybe past memory. >>>> In RFC6555 we tried to avoid dual-SYN as much as possible by providing a >>>> headstart that shrinks and inverses on failures - so the reference to >>>> RFC6555 being "parallel" is not correct, see section 5.5: >>>> >>>> The primary purpose of Happy Eyeballs is to reduce the wait time for >>>> a dual-stack connection to complete, especially when the IPv6 path is >>>> broken and IPv6 is preferred. Aggressive timeouts (on the order of >>>> tens of milliseconds) achieve this goal, but at the cost of network >>>> traffic. This network traffic may be billable on certain networks, >>>> will create state on some middleboxes (e.g., firewalls, intrusion >>>> detection systems, NATs), and will consume ports if IPv4 addresses >>>> are shared. For these reasons, it is RECOMMENDED that connection >>>> attempts be paced to give connections a chance to complete. It is >>>> RECOMMENDED that connection attempts be paced 150-250 ms apart to >>>> balance human factors against network load. >>> >>> The dual SYN approaches could use a delay between the SYNs like 6655 does >>> (not nec exactly the same numbers). However, in the short flow world, I >>> would argue that 250ms is completely unacceptable unless you're fairly >>> certain the first one will work, which is more-or-less the v4/v6 scenario >>> that happy eyeballs addressed. Reasoning: multiply 250ms by a few >>> connections with serial dependencies in a sequence and you have delays of >>> seconds. >>> >>> I've made a note to change the description of 6555 in the next rev - >>> clearly the word parallel is not strictly correct anyway - one serial >>> (e.g. network) interface can't actually send two SYNs in parallel, the >>> closest they can leave is back-to-back. >> >> True... you might start with some conservative values, but then as you get >> RTT estimate for the connection, an implementation might opt to save that >> RTT estimate in a cache >> (http://www.tedunangst.com/flak/post/2Q-buffer-cache-algorithm seems maybe >> appropriate for this type of use?) And then we're somewhere in 6555 >> territory anyway. So much for simplicity! :-) > > Cache algos don't have to be standardised. The standard can be simple, and > implementers can tradeoff simplicity for latency. > True. > > >>> Regarding billable total traffic: >>> Damon Wischik once proposed to improve performance by duplicating the most >>> sensitive packets at flow start: >>> "three copies of the first packet of every message, two copies of >>> the second and one copy of subsequent packets" >>> He calculated these 6 extra full-sized packets per flow would (in 2005) >>> increase total traffic by 2.7% (because elephants dominate total traffic). >>> >>> Duplicating just the legacy part of the SYN (60B max) would have a much >>> smaller total effect (I could calculate it if you want - probably >>> sub-0.1%). Certainly too small for people to care about the increment on >>> bills or even packet load. >> >> Thanks for the link! I will read it in detail tomorrow, for now just >> glanced, and there does not seem to be any discussion of what happens if >> the link is constrained ? >> >> Some time ago I had to work a nontrivial amount of time over a 3G throttled >> down to 64Kbps, and a number of tricks were required to change the >> experience from "unusable" to "slow but eventually loaded": switch from >> Chrome to Firefox (primarily because of my lack of knowledge of deep tuning >> for the former, maybe there was a better way!), and reducing the number of >> simultaneous connections down to 4, from 32. >> >> Maybe it's small enough and I am being paranoid, but the 64kbps >> environments are still real (unfortunately). > > The number of simulataneous connections is certainly critical for a > constrained environment. But the dual SYN approaches don't double the number > of /connections/, they only double the number of SYNs (in the worst case when > all connections need large TCP options at the start). > > I haven't done the proper calculation, but a rough estimate based on Wischik > would be 0.05% more bytes. The effect I had in mind was twofold - first, the number of connections, of course, but then also what are the loss patterns for the train of proactive retransmissions. Oh, let me argue against myself a bit again and tell me if this line of thinking has legs: IW10 should have a somewhat similar effect compared to sending multiple SYNs -> so we could use the results from https://www.ietf.org/proceedings/80/slides/iccrg-1.pdf to ballpark the effect - which would be the increase in probability of loss by 0.5%, which does not seem bad. > > > > >>>> In today's conditions, a simple 300ms headstart for IPv6 if AAAA is >>>> advertised might be sufficient, as the subpar IPv6 connectivity >>>> disappears, and more of the corner cases get into play for RTTs. >>>> So, depending on how much of a drop rate we'd expect for a "new" SYN >>>> across the variety of network scenarios, the simpler approach of just >>>> using 300ms delay could be reasonable due to its simplicity - an >>>> experiment could show. >>>> Doing this experiment on both address families at once could also reveal >>>> the drop rates to be different - I'd expect the IPv6 drop rates to be >>>> smaller - so maybe there is an opportunity to simplify things - if it >>>> "just works" in IPv6 using a single fancy-looking SYN in a sufficient %% >>>> of cases, that could be a great simplification *and* will give additional >>>> use case for IPv6 assuming there is enough demand for more space in the >>>> options. >>> >>> The delay between the pair should be implementation dependent anyway. No >>> point arguing this to death in standards... but I will at least state the >>> opposing view... >>> >>> The world is changing. Latency is everything and soon it will be even more >>> than everything. If one values latency, the delay between the two will be >>> as small as possible. >> >> Agreed. >> >>> >>> My simple view of the world is that, dual SYN seems the /only/ way to >>> extend TCP option space. I'm not proud of it. It's not nice. But it's >>> necessary. If dual SYNs require more memory for connection state, it's OK >>> as long as the need for more memory appears slowly enough to be able to >>> deploy it. If this is the price of extra capabilities, and those >>> capabilities are valued, then we invest in memory to provide the >>> capabilities. >>> >>> Whether the number of connections that need >40B TCP options will suddenly >>> jump, or gradually grow, I can't predict tho. >> >> Again, makes sense. > > Especially to someone who sells memory ;) *that* memory is used for RIB, hello deaggregation! :-) > > > >>>>> The other two in tcp-syn-ext-opt have to be 2-SYN for ever. >>>>> >>>>>> Also, I don't particularly think that putting the options at the end of >>>>>> the segment serves any useful purpose other than to make this option >>>>>> handle the option space in a different way than the default DO header >>>>>> field. >>>>> That's the architectural point. >>>>> There's also a tactical point. It should get through every middlebox. >>>> Help me understand this argument. If we were sending the "old" and "new" >>>> SYNs on the same 5-tuple - sure, the data must be identical. >>>> But if source ports are different, then a typical middlebox is either >>>> happy about the "data in the SYN" or not ? >>>> Or, are you saying that placing them at the end of the packet makes it >>>> difficult for the current architectures to "grab" them and mess around >>>> with them ? Sure, it does. Especially higher-performing boxes might look >>>> at the start of the packet. >>>> But that's *today's* architectures - if someone pays one of my employer's >>>> BUs enough to create a box that fiddles with these options, that box will >>>> get created. Not an architecturally beautiful reality, but it is there. >>> >>> Two clarifications: >>> >>> 1) By putting options after the payload, I'm including the (currently >>> common) case of a SYN with no payload. Then the extra options will start >>> immediately at the Data Offset. >>> >>> 2) A longer clarification... >>> >>> Let's separate middleboxes into two types (I'm trying to deal with both): >>> - (meddleboxes) those that want to mess with headers for security >>> - (muddleboxes) those that happen to mess with headers, because their >>> developers never stopped to think that TCP might change. >>> >>> Muddleboxes tend to forward the payload unaltered. Some muddleboxes look >>> at HTTP headers and try to be clever. By putting extra options after the >>> Data Offset, they will pass the former. By putting them at the end of the >>> payload they will mostly pass the latter. >>> >>> Meddleboxes might well evolve to find these new extra options at the end >>> of the packet. But in the meantime, we've got over the transition of >>> deploying a new protocol. Then the meddleboxes are on the back foot, and >>> they have to justify removing these packets that are useful to someone. If >>> they can - e.g. for security reasons - then fine. But they are not just >>> removing packets because they are using a new rev of the protocol. >>> >>> As I said, the most important thing is we will have separated TCP options >>> into two sets: >>> - Those that middleboxes (past and future) can mess with >>> - Those that middleboxes (future) should think much harder about before >>> messing with them >>> >>> Then, this (maybe) enables the next step - for endpoints to encrypt those >>> options they don't want middleboxes to interact with at all. (See my >>> response to Alex Zimmerman's post in this thread.) >> >> Thanks for the detailed explanation! This might be useful to just copypaste >> into the draft in the next rev, for the rationale. > > I've added a 'Design Rationale' section for the next rev. Thanks! > > >> Now, a trick question. We all know IPv4 is entrenched with middleboxes >> necessarily meddling with L7 because they have to do NAT in the process. >> What about IPv6 ? I have a totally unfounded hope that there the situation >> might be better, at least for now ? > > Sorry to disappoint, but AFAIK the only middlebox function that is > IPv4-specific is NAT. Firewalls, Web-filters, connection splitters, PEPs, WAN > accelerators, DPI, app-layer load balancers, etc all serve functions that are > nothing to do with address lengths. And even NATs serve an obfuscation > function, not just address-space expansion. > My speculation is based on the fact that IPv4 part of the middleboxes have a decades of sophistication in them, but IPv6 support is relatively young. So the "corner cases" that the approaches we are discussing essentially are, may likely get missed. But again I will argue with myself and say (1) the L4+ codepath could be common, (2) it could be argued the reverse way - that these corner cases might have bugs that make them worse than in IPv4. > > >>>>>> I'm glad to hear what others think and agree that an unbiased >>>>>> comparison >>>>>> of the approaches would be a useful place to for the discussion to >>>>>> start... >>>>> Yes, I'm already repeating myself - you're right we need wider opinions. >>>> Even though I am nominally "on the list of alternatives" due to LOIC, >>>> I've disliked the idea shortly after, after trying to implement it - the >>>> linux kernel's accelerated NIC path showed that the invalid CRC would be >>>> dropped very early, before the software can see it - so I would argue >>>> against that approach today from implementation standpoint as well. >>>> Hopefully arguing with my past self does buy me an "unbiased" ribbon, or >>>> at least a half of it :-) >>> >>> Certainly, this seems to give you the role of unbiased /and/ educated by >>> experience. >>> >>> I'm also no longer like an idea that my past self proposed (SYN-EOS DS), >>> for the same reasons Joe didn't like it - the two SYNs will often not end >>> up in the same place to be re-united. But I still have a candidate I do >>> prefer (syn-op-sis). That rules me out for the role of innocent bystander. >> >> Probably the best way to decide is to implement both, get them in parallel >> into the olde wilde internets and see what sticks better! > > Before going to the trouble of implementation, some middlebox traversal > testing of the proposed packet formats might weed out the field. I have a > suspicion that the OOB segment won't get very far in many cases - it's > unlikely that all firewalls and intrusion detection systems will allow the > unusual ACK=0, SYN=0 and the same seqno as the SYN. Yes, this is a prerequisite. --a > > Cheers > > > Bob > > >> --a >> >>> >>> >>> Bob >>> >>> >>>> --a >>>> >>>>> >>>>> Bob >>>>> >>>>>> Joe >>>>>> On 9/22/2014 7:55 AM, Bob Briscoe wrote: >>>>>> > Joe, >>>>>> > >>>>>> > I've just posted a revision here: >>>>>> > >>>>>> > >>>>>> > * I've taken more care to explain it. It was a bit terse before. So >>>>>> it's >>>>>> > ready for the list to review properly now. >>>>>> > >>>>>> > It would be useful if someone wrote a comparison with the other ideas >>>>>> on >>>>>> > how to do this, including the ones we wrote jointly and SLO, LOIC and >>>>>> > DBormam's 4-way HS. Better someone independent of all the authors >>>>>> does >>>>>> > this. But I want to get syn-op-sis right first, a comparison won't be >>>>>> > much use until its stable. >>>>>> > >>>>>> > >>>>>> > The underlying idea is still the same. The reasons I've updated it >>>>>> are >>>>>> > many (the change log taken from the appendix is pasted at the end of >>>>>> > this email for convenience). >>>>>> > >>>>>> > * Mainly I've articulated that all these approaches that add TCP >>>>>> options >>>>>> > after the Data Offset are not just hacks to get more space; they add >>>>>> a >>>>>> > new architectural capability to TCP - a distinction between TCP >>>>>> options >>>>>> > that might be relevant to middleboxes, and ones that are only for the >>>>>> > destination (a bit like destopt in IPv6 - needing to specify which >>>>>> TCP >>>>>> > options are for the destination only is ironic but necessary). >>>>>> > >>>>>> > * I've also realised that this approach will ultimately return to a >>>>>> > single SYN solution, whereas both the ideas in >>>>>> > draft-touch-tcpm-tcp-syn-ext-opt will always require two SYNs. >>>>>> > >>>>>> > >>>>>> > >>>>>> > Bob >>>>>> > >>>>>> > Pasted from the change log: >>>>>> > >>>>>> > From briscoe...-01 to briscoe...-02: >>>>>> > >>>>>> > Technical changes: >>>>>> > >>>>>> > * Defined the client behaviour dependent on which response >>>>>> > arrives first. >>>>>> > >>>>>> > * Allowed retransmission of either SYN or SYN-U if no response >>>>>> > from either. >>>>>> > >>>>>> > * Redefined EOO as an offset from the end of the packet, not >>>>>> from >>>>>> > the beginning of the payload. >>>>>> > >>>>>> > * Added section on Migration to a Single Handshake. Reworded >>>>>> > dual handshake so that it is not mandatory for the client to >>>>>> > send dual SYNs simultaneously; only the relation between the >>>>>> > SYNs and the response to either is mandatory, while parallel >>>>>> > SYNs is purely for latency reduction. >>>>>> > >>>>>> > * Added rules for writing TCP options, i.e. i) options like >>>>>> TFO >>>>>> > MUST NOT be located in the TCP header and ii) add no-ops to >>>>>> > align on 4-octet boundary. >>>>>> > >>>>>> > * Added rules for forwarding TCP options, i.e. only the >>>>>> > destination looks for TCP options after the Data Offset, not >>>>>> > middleboxes. >>>>>> > >>>>>> > * Moved the Explicit Handshake variant (SYN-L) into the body >>>>>> from >>>>>> > the appendix, and recommended the choice could be down to >>>>>> > implementers or apps. Included section on corner cases. >>>>>> > >>>>>> > * Introduced more normative language throughout the Protocol >>>>>> > Spec. >>>>>> > >>>>>> > Editorial changes: >>>>>> > >>>>>> > * Added temporary motivation section >>>>>> > >>>>>> > * Added confusible terminology to Terminology section. >>>>>> > >>>>>> > * Divided protocol spec into sub-sections. >>>>>> > >>>>>> > * Handshake table: Clarified that the two columns under each >>>>>> > server represent separate threads, that may run on separate >>>>>> > servers, without co-ordination. Represented message >>>>>> > dependencies in the alignment of the rows. >>>>>> > >>>>>> > * Explained the table. >>>>>> > >>>>>> > * Explained why a legacy server won't ever pass SYN-U to the >>>>>> app. >>>>>> > >>>>>> > * More precisely described loss as 'not arrived before a >>>>>> > timeout', and explained the tradeoff between latency and >>>>>> extra >>>>>> > TCP options. >>>>>> > >>>>>> > * Gave reasoning for locating TCP options in three groups. >>>>>> > >>>>>> > * Acknowledged Rob Hancock for the architectural idea of >>>>>> hiding >>>>>> > an extension to a protocol in the layer above. >>>>>> > >>>>>> > * Appendix about protocol alternatives now only presents the >>>>>> SYN- >>>>>> > UD alternative, given the implicit/explicit handshake choice >>>>>> > has been moved to the body. >>>>>> > >>>>>> > * Rewrote appendix about comparing the choices to treat the >>>>>> two >>>>>> > pairs of choices separately, rather than discussing all four >>>>>> > combinations of pairs of choices. >>>>>> > >>>>>> > ________________________________________________________________ >>>>>> > Bob Briscoe, BT >>>>> ________________________________________________________________ >>>>> Bob Briscoe, BT >>>>> _______________________________________________ >>>>> tcpm mailing list >>>>> tcpm@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/tcpm >>>> ________________________________________________________________ >>>> Bob Briscoe, BT >>> >>> ________________________________________________________________ >>> Bob Briscoe, BT From nobody Fri Sep 26 07:50:47 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92C7C1A8943 for ; Fri, 26 Sep 2014 07:50:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.986 X-Spam-Level: X-Spam-Status: No, score=-4.986 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786] autolearn=ham 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 FRC6O2wnHz7B for ; Fri, 26 Sep 2014 07:50:40 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 9F4F01A893C for ; Fri, 26 Sep 2014 07:50:39 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id 7110EC94C0; Fri, 26 Sep 2014 10:50:37 -0400 (EDT) Date: Fri, 26 Sep 2014 10:50:37 -0400 From: John Leslie To: Bob Briscoe Message-ID: <20140926145037.GA82183@verdi> References: <201409222045.s8MKjZdD002071@bagheera.jungle.bt.co.uk> <542344DA.9020905@isi.edu> <201409250956.s8P9uae9013452@bagheera.jungle.bt.co.uk> <201409251842.s8PIgUdQ015414@bagheera.jungle.bt.co.uk> <201409260957.s8Q9vmEd018560@bagheera.jungle.bt.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201409260957.s8Q9vmEd018560@bagheera.jungle.bt.co.uk> User-Agent: Mutt/1.4.1i Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/LT7zAasVOW_dhyKxf3OMvQMA3W8 Cc: tcpm IETF list , Joe Touch Subject: Re: [tcpm] More TCP option space in a SYN: draft-briscoe-tcpm-syn-op-sis-02 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Sep 2014 14:50:42 -0000 Alas, I haven't found time to completely read any of these drafts; but I think an overview would be valuable... Bob Briscoe wrote: >... > To be absolutely clear: > a) SYN-EOS OOB client sends a SYN and an OOB segment to complement > it, using same src & dst ports. The OOB segment has SYN=0, ACK=0 and > the seqno is the same as the ISN of the SYN. This is draft-touch-tcpm-tcp-syn-ext-opt. Two packets are sent: one is a SYN; the other isn't. > b) SYN-EOS DS client sends 2 complementary SYNs, using same dst port, > but different src ports and different ISNs. This is also draft-touch-tcpm-syn-ext-opt. Two packets are sent: both are SYNs. Joe asks us to work out which approach is better. > c) syn-op-sis client sends 2 alternative SYNs, using same dst port, > but different src ports and different ISNs. This is draft-briscoe-tcpm-syn-op-sis. One packet is sent, but Bob expects a totally separate packet to be sent proposing a separate connection, and only one of these connections will completely open. > a & b use the word 'complement', which means an upgraded server needs > to have received both segments to start an upgraded connection. I agree with Bob here. > c uses the word 'alternative', which means a server can start a > connection when it receives either, and the upgraded handshake only > completes if it's an upgraded server. Likewise... And I note that there's no _need_ to specify anything about the overlap between the two proposed connections. I like this a lot better, because I never trust that two packets will always reach the same endpoint. Meddleboxes and muddleboxes are too common and too varied in their world-views. I'd like to remind folks of two other drafts: - draft-ietf-tcpm-fastopen "allows data to be carried in the SYN" packet. Something like this is inevitable; and _will_ put application-layer data in the inital SYN (to reduce experienced latency). - draft-nishida-tcpm-apaws "can provide protection against old duplicates" without using timestamps. (Timestamps will eat up ten bytes in _every_ packet.) This should reduce the demand for option space in the SYN. ==== Hopefully I don't need to draw attention to draft-touch-tcpm-edo. This seems to be moving towards consensus on how to increase the option space on every packet _after_ the initial SYN. Thus, in most cases, for today's traffic there is little need to worry about extending the option space in the initial SYN. There seems to be plenty of time to experiment... >>Probably the best way to decide is to implement both, get them in >>parallel into the olde wilde internets and see what sticks better! > > Before going to the trouble of implementation, some middlebox > traversal testing of the proposed packet formats might weed out the > field. I have a suspicion that the OOB segment won't get very far in > many cases - it's unlikely that all firewalls and intrusion detection > systems will allow the unusual ACK=0, SYN=0 and the same seqno as the SYN. I agree with Bob that we don't need formal Experimental status to test how often an OOB packet will fail to pass a middlebox. For any Experimental-status document, I recommend: - that the various on-the-wire formats be kept as similar as possible; - that any acknowledgment of extra option space in an initial SYN include a checksum or hash of the extra options to ensure that both ends have the same view of what options have been signaled; - that any timing questions be specifically explored as part of the experiment. (This includes _whether_ there should be any overlap between the experimental SYN and the legacy SYN.) - that an explicit allocation of one (or more, possibly) dedicated option number be requested from IANA. ==== IMHO, Bob's SYN-U cases are best condensed into a single format where the SYN sender explicitly notes the position in the payload to be occupied by additional TCP options, and guarantees that no application- layer data will follow these. The receiving endpoint would search for the extra options whether or not it found the SYN-U option in the initial SYN, and reply including a checksum/hash of the options it found. (The receiving endpoint MUST find some confirmation that these options were intended, or _it_ bears the responsibility to reverse any action on the extended options and pass the payload where it otherwise would have gone.) I'm not sure this entire middlebox-transit idea is worth the trouble; but it probably deserves to be an optional part of the experiment. The SYN-U sender MUST deal with the danger of its additional options being passed to the application as data. For legacy receivers it can do this by aborting before the end of the three-way handshake. But there must be coordination with tcpm-fastopen to protect against such data being passed to the application before the SYN-U sender can abort. (This is not a trivial consideration!) I believe that much deserves to be settled _before_ tcpm-fastopen is published as an RFC. (NB that document currently has been approved for publication, but is waiting on a Point-Raised writeup.) The fastopen mechanism calls for the SYN sender to request a Fast Open Cookie, which the SYN receiver will generate and return in the SYN-ACK. In a _future_ connection, the SYN sender can send that cookie, and all payload data will go to the application _before_ the three-way handshake completes. Thus there is no way to use both fastopen and SYN-U in the same connection. This is unfortunate!!! (Note that fastopen will be Experimental; and deficiencies can be fixed before it reaches Proposed Standard: it's just best to consider overlaps like this before the RFC is published.) ==== The question of separating payload data to go to the application from extended TCP options clearly requires action by the SYN receiver. This is fairly simple if the SYN sender can ensure that _none_ of the payload data should go to the application (and thus not use fastopen at all): of course the connection must still be aborted if the SYN receiver doesn't acknowledge separating out the extended options. IMHO, the SYN sender should never use SYN-U unless extra option space in the SYN is needed; and it's probably better to never use SYN-U for connections where latency of setup is the over-riding factor. But YMMV. I wonder whether such overlap is worth the trouble to try to design into the protocol. -- John Leslie From nobody Fri Sep 26 09:48:12 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 451C01A870C for ; Fri, 26 Sep 2014 09:48:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.986 X-Spam-Level: X-Spam-Status: No, score=-4.986 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786] autolearn=ham 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 qDRIyI1nHP6G for ; Fri, 26 Sep 2014 09:48:09 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B823D1A8033 for ; Fri, 26 Sep 2014 09:48:09 -0700 (PDT) Received: from [10.123.102.67] (usc-secure-wireless-206-067.usc.edu [68.181.206.67]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id s8QGfBg8011856 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 26 Sep 2014 09:41:20 -0700 (PDT) Message-ID: <54259727.5090500@isi.edu> Date: Fri, 26 Sep 2014 09:41:11 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: John Leslie , Bob Briscoe References: <201409222045.s8MKjZdD002071@bagheera.jungle.bt.co.uk> <542344DA.9020905@isi.edu> <201409250956.s8P9uae9013452@bagheera.jungle.bt.co.uk> <201409251842.s8PIgUdQ015414@bagheera.jungle.bt.co.uk> <201409260957.s8Q9vmEd018560@bagheera.jungle.bt.co.uk> <20140926145037.GA82183@verdi> In-Reply-To: <20140926145037.GA82183@verdi> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/5dIt41NY-UkwpDvU0I0-OMlnqMU Cc: tcpm IETF list Subject: Re: [tcpm] More TCP option space in a SYN: draft-briscoe-tcpm-syn-op-sis-02 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Sep 2014 16:48:11 -0000 On 9/26/2014 7:50 AM, John Leslie wrote: ... > Hopefully I don't need to draw attention to draft-touch-tcpm-edo. > This seems to be moving towards consensus on how to increase the option > space on every packet _after_ the initial SYN. > > Thus, in most cases, for today's traffic there is little need to > worry about extending the option space in the initial SYN. There seems > to be plenty of time to experiment... I don't know if the need is as small, but I agree that experimentation is needed to proceed. ... > I agree with Bob that we don't need formal Experimental status to > test how often an OOB packet will fail to pass a middlebox. Agreed; that's on our to-do list. > For any Experimental-status document, I recommend: > > - that the various on-the-wire formats be kept as similar as possible; I disagree; there's no reason for that. > - that any acknowledgment of extra option space in an initial SYN > include a checksum or hash of the extra options to ensure that both > ends have the same view of what options have been signaled; Disagree. Options are ACKd by confirming the options - not by merely sending an ACK. > - that any timing questions be specifically explored as part of the > experiment. (This includes _whether_ there should be any overlap > between the experimental SYN and the legacy SYN.) Yes. > - that an explicit allocation of one (or more, possibly) dedicated > option number be requested from IANA. These can and IMO should use the experimental option IDs until we're ready to move forward. > The question of separating payload data to go to the application > from extended TCP options clearly requires action by the SYN receiver. > This is fairly simple if the SYN sender can ensure that _none_ of the > payload data should go to the application (and thus not use fastopen > at all): of course the connection must still be aborted if the SYN > receiver doesn't acknowledge separating out the extended options. I don't think that's tenable. SYNs have always been able to include data. Fastopen just helps that data get to the user faster. Joe From nobody Fri Sep 26 10:16:26 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B912A1A8030 for ; Fri, 26 Sep 2014 10:16:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.387 X-Spam-Level: X-Spam-Status: No, score=-3.387 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=ham 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 TtgOO4zB9pCD for ; Fri, 26 Sep 2014 10:16:21 -0700 (PDT) Received: from hubrelay-rd.bt.com (hubrelay-rd.bt.com [62.239.224.98]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2883C1A70E2 for ; Fri, 26 Sep 2014 10:16:19 -0700 (PDT) Received: from EVMHR71-UKRD.domain1.systemhost.net (10.36.3.109) by EVMHR65-UKRD.bt.com (10.187.101.20) with Microsoft SMTP Server (TLS) id 14.3.181.6; Fri, 26 Sep 2014 18:16:18 +0100 Received: from EPHR02-UKIP.domain1.systemhost.net (147.149.100.81) by EVMHR71-UKRD.domain1.systemhost.net (10.36.3.109) with Microsoft SMTP Server (TLS) id 8.3.348.2; Fri, 26 Sep 2014 18:16:17 +0100 Received: from bagheera.jungle.bt.co.uk (132.146.168.158) by EPHR02-UKIP.domain1.systemhost.net (147.149.100.81) with Microsoft SMTP Server id 14.3.181.6; Fri, 26 Sep 2014 18:16:14 +0100 Received: from BTP075694.jungle.bt.co.uk ([10.215.130.93]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id s8QHGC7I020142; Fri, 26 Sep 2014 18:16:12 +0100 Message-ID: <201409261716.s8QHGC7I020142@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 26 Sep 2014 18:16:11 +0100 To: John Leslie From: Bob Briscoe In-Reply-To: <20140926145037.GA82183@verdi> References: <201409222045.s8MKjZdD002071@bagheera.jungle.bt.co.uk> <542344DA.9020905@isi.edu> <201409250956.s8P9uae9013452@bagheera.jungle.bt.co.uk> <201409251842.s8PIgUdQ015414@bagheera.jungle.bt.co.uk> <201409260957.s8Q9vmEd018560@bagheera.jungle.bt.co.uk> <20140926145037.GA82183@verdi> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/S3PAF2PzXjQa83yc249wuqBxgSg Cc: tcpm IETF list , Joe Touch Subject: Re: [tcpm] More TCP option space in a SYN: draft-briscoe-tcpm-syn-op-sis-02 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Sep 2014 17:16:24 -0000 John, At 15:50 26/09/2014, John Leslie wrote: > Alas, I haven't found time to completely read any of these drafts; >but I think an overview would be valuable... > >Bob Briscoe wrote: > >... > > To be absolutely clear: > > a) SYN-EOS OOB client sends a SYN and an OOB segment to complement > > it, using same src & dst ports. The OOB segment has SYN=0, ACK=0 and > > the seqno is the same as the ISN of the SYN. > > This is draft-touch-tcpm-tcp-syn-ext-opt. Two packets are sent: one >is a SYN; the other isn't. > > > b) SYN-EOS DS client sends 2 complementary SYNs, using same dst port, > > but different src ports and different ISNs. > > This is also draft-touch-tcpm-syn-ext-opt. Two packets are sent: >both are SYNs. Joe asks us to work out which approach is better. > > > c) syn-op-sis client sends 2 alternative SYNs, using same dst port, > > but different src ports and different ISNs. > > This is draft-briscoe-tcpm-syn-op-sis. One packet is sent, but Bob >expects a totally separate packet to be sent proposing a separate >connection, and only one of these connections will completely open. > > > a & b use the word 'complement', which means an upgraded server needs > > to have received both segments to start an upgraded connection. > > I agree with Bob here. > > > c uses the word 'alternative', which means a server can start a > > connection when it receives either, and the upgraded handshake only > > completes if it's an upgraded server. > > Likewise... > > And I note that there's no _need_ to specify anything about the >overlap between the two proposed connections. > > I like this a lot better, because I never trust that two packets >will always reach the same endpoint. Meddleboxes and muddleboxes are >too common and too varied in their world-views. > > I'd like to remind folks of two other drafts: > >- draft-ietf-tcpm-fastopen "allows data to be carried in the SYN" packet. > Something like this is inevitable; and _will_ put application-layer > data in the inital SYN (to reduce experienced latency). This is referenced from both drafts. You have to be careful using fast open as well as putting TCP options in the payload. I've written the following into draft-briscoe-syn-op-sis, and a similar rule will be needed in draft-touch-tcpm-tcp-syn-ext-opt: " If an upgraded TCP client includes the TCP Fast Open option [I-D.ietf-tcpm-fastopen] in the SYN, it MUST be placed with the extra TCP options after the end of the payload. An upgraded TCP client MUST NOT place any TCP option in the TCP header of a SYN that might cause a TCP server to pass user-data directly to the application before the 3-way handshake completes. " See >- draft-nishida-tcpm-apaws "can provide protection against old duplicates" > without using timestamps. (Timestamps will eat up ten bytes in _every_ > packet.) This should reduce the demand for option space in the SYN. Most certainly agree. See quoted text under the next point... >==== > > Hopefully I don't need to draw attention to draft-touch-tcpm-edo. >This seems to be moving towards consensus on how to increase the option >space on every packet _after_ the initial SYN. > > Thus, in most cases, for today's traffic there is little need to >worry about extending the option space in the initial SYN. There seems >to be plenty of time to experiment... Not sure I'm so relaxed. Quoting "1.1. Motivation for Adoption (to be removed before publication) It is recognised that there could be potential for compressing together multiple options in order to mitigate the option space problem. However, it seems inevitable that ultimately more option space will be needed, particularly given that many of the TCP options introduced recently consume large numbers of bits in order to provide sufficient information entropy, which is not amenable to compression. Extension of TCP option space on a SYN requires support from both ends. This means it will take many years before the facility is functional for most pairs of end-points. Therefore, given the problem is already becoming pressing, a solution needs to start being deployed now. " > >>Probably the best way to decide is to implement both, get them in > >>parallel into the olde wilde internets and see what sticks better! > > > > Before going to the trouble of implementation, some middlebox > > traversal testing of the proposed packet formats might weed out the > > field. I have a suspicion that the OOB segment won't get very far in > > many cases - it's unlikely that all firewalls and intrusion detection > > systems will allow the unusual ACK=0, SYN=0 and the same seqno as the SYN. > > I agree with Bob that we don't need formal Experimental status to >test how often an OOB packet will fail to pass a middlebox. > > For any Experimental-status document, I recommend: > >- that the various on-the-wire formats be kept as similar as possible; > >- that any acknowledgment of extra option space in an initial SYN > include a checksum or hash of the extra options to ensure that both > ends have the same view of what options have been signaled; Not convinced on this one. Each TCP option has its own way for the 'server' to confirm whether it supports an option requested by the client. And support for the option to extend the option space is confirmed by the server. So it seems redundant for the server to feedback yet another confirmation via a checksum of all the extra options requested. >- that any timing questions be specifically explored as part of the > experiment. (This includes _whether_ there should be any overlap > between the experimental SYN and the legacy SYN.) Good point. >- that an explicit allocation of one (or more, possibly) dedicated > option number be requested from IANA. > >==== > > IMHO, Bob's SYN-U cases are best condensed into a single format >where the SYN sender explicitly notes the position in the payload to be >occupied by additional TCP options, and guarantees that no application- >layer data will follow these. Good point about the guarantee. >The receiving endpoint would search for >the extra options whether or not it found the SYN-U option in the >initial SYN, This won't work. This would require every server to hold a list of valid TCP options and their valid length fields. This list is large, and the list of future options yet to be defined is even larger (and obviously unknown). If the server has to check every sequence of bytes starting at every byte within the payload for a match with all possible TCP options, when searching through any arbitrary payload, it will continually return loads of false matches (and it will consume excessive cycles). This also doesn't provide any path to add new options. >and reply including a checksum/hash of the options it >found. (The receiving endpoint MUST find some confirmation that >these options were intended, or _it_ bears the responsibility to >reverse any action on the extended options and pass the payload where >it otherwise would have gone.) No need for all this - see above and see drafts. > I'm not sure this entire middlebox-transit idea is worth the trouble; >but it probably deserves to be an optional part of the experiment. The reason I came up with syn-op-sis is to be able to be near-certain that it will get through current middleboxes. I think the group will find such near-certainty to be liberating, compared to the minefield we currently have to tip-toe through. The only case I can think of where there could be a blockage is where a split TCP connection holds back any payload on the SYN until the 3WHS completes. > The SYN-U sender MUST deal with the danger of its additional options >being passed to the application as data. For legacy receivers it can do >this by aborting before the end of the three-way handshake. But there >must be coordination with tcpm-fastopen to protect against such data >being passed to the application before the SYN-U sender can abort. >(This is not a trivial consideration!) Altho certainly not a trivial consideration, it is trivial to be safe against this - see the rule already in the syn-op-sis draft, quoted above, which is careful to be specific about TFO, as well as generalising to anything in the future that might be like TFO (e.g. tcpcrypt uses the TCP payload for control messages). > I believe that much deserves to be settled _before_ tcpm-fastopen >is published as an RFC. (NB that document currently has been approved >for publication, but is waiting on a Point-Raised writeup.) > > The fastopen mechanism calls for the SYN sender to request a >Fast Open Cookie, which the SYN receiver will generate and return in >the SYN-ACK. In a _future_ connection, the SYN sender can send that >cookie, and all payload data will go to the application _before_ the >three-way handshake completes. Thus there is no way to use both >fastopen and SYN-U in the same connection. This is unfortunate!!! As above, syn-op-sis contains text solving this already. And the same approach can be used by the other drafts. > (Note that fastopen will be Experimental; and deficiencies can be >fixed before it reaches Proposed Standard: it's just best to consider >overlaps like this before the RFC is published.) > >==== > > The question of separating payload data to go to the application >from extended TCP options clearly requires action by the SYN receiver. >This is fairly simple if the SYN sender can ensure that _none_ of the >payload data should go to the application (and thus not use fastopen >at all): of course the connection must still be aborted if the SYN >receiver doesn't acknowledge separating out the extended options. > > IMHO, the SYN sender should never use SYN-U unless extra option >space in the SYN is needed; and it's probably better to never use >SYN-U for connections where latency of setup is the over-riding factor. >But YMMV. I wonder whether such overlap is worth the trouble to try >to design into the protocol. In the syn-op-sis spec there is a choice between two variants of the protocol (I recommend the choice can be made by implementers, not the IETF). The choice I've recommended removes any risk of extra latency on the upgraded connection. I've included a discussion of the tradeoff between them in Appendix B.1: BTW, I spend most of my time these days working on a project to remove latency from protocols. Cheers Bob >-- >John Leslie ________________________________________________________________ Bob Briscoe, BT From nobody Fri Sep 26 11:29:24 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14E211A00F3 for ; Fri, 26 Sep 2014 11:29:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.986 X-Spam-Level: X-Spam-Status: No, score=-4.986 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786] autolearn=ham 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 IQ8HyGtxBCUh for ; Fri, 26 Sep 2014 11:29:21 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 1DFAE1A00EF for ; Fri, 26 Sep 2014 11:29:21 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id 0B15CC94BF; Fri, 26 Sep 2014 14:29:15 -0400 (EDT) Date: Fri, 26 Sep 2014 14:29:15 -0400 From: John Leslie To: Joe Touch Message-ID: <20140926182914.GG83009@verdi> References: <201409222045.s8MKjZdD002071@bagheera.jungle.bt.co.uk> <542344DA.9020905@isi.edu> <201409250956.s8P9uae9013452@bagheera.jungle.bt.co.uk> <201409251842.s8PIgUdQ015414@bagheera.jungle.bt.co.uk> <201409260957.s8Q9vmEd018560@bagheera.jungle.bt.co.uk> <20140926145037.GA82183@verdi> <54259727.5090500@isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54259727.5090500@isi.edu> User-Agent: Mutt/1.4.1i Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/NVbzIilxYsUxFXD7SMZj4G0WOLo Cc: tcpm IETF list Subject: Re: [tcpm] More TCP option space in a SYN: draft-briscoe-tcpm-syn-op-sis-02 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Sep 2014 18:29:23 -0000 Joe Touch wrote: > On 9/26/2014 7:50 AM, John Leslie wrote: > >> For any Experimental-status document, I recommend: >> >> - that the various on-the-wire formats be kept as similar as possible; > > I disagree; there's no reason for that. "As possible" to be intepreted liberally... >> - that any acknowledgment of extra option space in an initial SYN >> include a checksum or hash of the extra options to ensure that both >> ends have the same view of what options have been signaled; > > Disagree. Options are ACKd by confirming the options - not by merely > sending an ACK. No thanks! _This_ option deserves its own confirmation. We're putting options in a funny place -- any number of things could go wrong with that. :^( (But, of course, the individual options in the extended option space should get their own confirmations.) >> - that any timing questions be specifically explored as part of the >> experiment. (This includes _whether_ there should be any overlap >> between the experimental SYN and the legacy SYN.) > > Yes. > > > - that an explicit allocation of one (or more, possibly) dedicated > > option number be requested from IANA. > > These can and IMO should use the experimental option IDs until we're > ready to move forward. Absolutely. I only meant when we issue a formal Experimental RFC. >> The question of separating payload data to go to the application >> from extended TCP options clearly requires action by the SYN receiver. >> This is fairly simple if the SYN sender can ensure that _none_ of the >> payload data should go to the application (and thus not use fastopen >> at all): of course the connection must still be aborted if the SYN >> receiver doesn't acknowledge separating out the extended options. > > I don't think that's tenable. What specifically isn't tenable? > SYNs have always been able to include data. Indeed! That by itself complicates things. > Fastopen just helps that data get to the user faster. Specifically, fastopen (when used) removes the opportunity to abort before the application sees the payload data. With 20/20 hindsight, it's obvious that fastopen would have been better if it included a byte-count of data to pass to the application before the three-way-handshake completes. -- John Leslie From nobody Fri Sep 26 11:41:14 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 987391A017F for ; Fri, 26 Sep 2014 11:41:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.986 X-Spam-Level: X-Spam-Status: No, score=-4.986 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786] autolearn=ham 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 UxBKtnIuDxxV for ; Fri, 26 Sep 2014 11:41:12 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0CDD01A007B for ; Fri, 26 Sep 2014 11:41:12 -0700 (PDT) Received: from [10.123.102.67] (usc-secure-wireless-206-067.usc.edu [68.181.206.67]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id s8QIdTWH013156 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 26 Sep 2014 11:39:38 -0700 (PDT) Message-ID: <5425B2E1.2090301@isi.edu> Date: Fri, 26 Sep 2014 11:39:29 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: John Leslie References: <201409222045.s8MKjZdD002071@bagheera.jungle.bt.co.uk> <542344DA.9020905@isi.edu> <201409250956.s8P9uae9013452@bagheera.jungle.bt.co.uk> <201409251842.s8PIgUdQ015414@bagheera.jungle.bt.co.uk> <201409260957.s8Q9vmEd018560@bagheera.jungle.bt.co.uk> <20140926145037.GA82183@verdi> <54259727.5090500@isi.edu> <20140926182914.GG83009@verdi> In-Reply-To: <20140926182914.GG83009@verdi> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/raZ0l6zOM4Gc7nDo2x_EVHR6FbY Cc: tcpm IETF list Subject: Re: [tcpm] More TCP option space in a SYN: draft-briscoe-tcpm-syn-op-sis-02 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Sep 2014 18:41:13 -0000 On 9/26/2014 11:29 AM, John Leslie wrote: > Joe Touch wrote: >> On 9/26/2014 7:50 AM, John Leslie wrote: >> >>> For any Experimental-status document, I recommend: >>> >>> - that the various on-the-wire formats be kept as similar as possible; >> >> I disagree; there's no reason for that. > > "As possible" to be intepreted liberally... That imposes a goal that will require cycles to resolve, one that serves no purpose unless the two options converge naturally. >>> - that any acknowledgment of extra option space in an initial SYN >>> include a checksum or hash of the extra options to ensure that both >>> ends have the same view of what options have been signaled; >> >> Disagree. Options are ACKd by confirming the options - not by merely >> sending an ACK. > > No thanks! _This_ option deserves its own confirmation. We're putting > options in a funny place -- any number of things could go wrong with > that. :^( If the extension works, then you have the extension place in which to send option confirmation. The extension itself clearly needs to be confirmed too - like any other options. I don't see the reason for a hash. ... >>> - that any timing questions be specifically explored as part of the >>> experiment. (This includes _whether_ there should be any overlap >>> between the experimental SYN and the legacy SYN.) >> >> Yes. >> >>> - that an explicit allocation of one (or more, possibly) dedicated >>> option number be requested from IANA. >> >> These can and IMO should use the experimental option IDs until we're >> ready to move forward. > > Absolutely. I only meant when we issue a formal Experimental RFC. It depends on the experiment. The ExID is intended for the potential to use an option in the public that we might not end up keeping. >>> The question of separating payload data to go to the application >>> from extended TCP options clearly requires action by the SYN receiver. >>> This is fairly simple if the SYN sender can ensure that _none_ of the >>> payload data should go to the application (and thus not use fastopen >>> at all): of course the connection must still be aborted if the SYN >>> receiver doesn't acknowledge separating out the extended options. >> >> I don't think that's tenable. > > What specifically isn't tenable? I don't think we should declare that SYNs don't have data. >> SYNs have always been able to include data. > > Indeed! That by itself complicates things. But we should allow it. >> Fastopen just helps that data get to the user faster. > > Specifically, fastopen (when used) removes the opportunity to abort > before the application sees the payload data. > > With 20/20 hindsight, it's obvious that fastopen would have been > better if it included a byte-count of data to pass to the application > before the three-way-handshake completes. TCP is a bytestream protocol. Even with the PSH bit, there's no guarantee of that boundary anyway. Joe From nobody Fri Sep 26 12:53:52 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7805D1A0242 for ; Fri, 26 Sep 2014 12:53:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.986 X-Spam-Level: X-Spam-Status: No, score=-4.986 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786] autolearn=ham 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 BjvkhmYRi2VD for ; Fri, 26 Sep 2014 12:53:47 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id B7C0F1A0092 for ; Fri, 26 Sep 2014 12:53:46 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id B44D2C94BE; Fri, 26 Sep 2014 15:53:38 -0400 (EDT) Date: Fri, 26 Sep 2014 15:53:38 -0400 From: John Leslie To: Bob Briscoe Message-ID: <20140926195338.GH83009@verdi> References: <201409222045.s8MKjZdD002071@bagheera.jungle.bt.co.uk> <542344DA.9020905@isi.edu> <201409250956.s8P9uae9013452@bagheera.jungle.bt.co.uk> <201409251842.s8PIgUdQ015414@bagheera.jungle.bt.co.uk> <201409260957.s8Q9vmEd018560@bagheera.jungle.bt.co.uk> <20140926145037.GA82183@verdi> <201409261716.s8QHGC7I020142@bagheera.jungle.bt.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201409261716.s8QHGC7I020142@bagheera.jungle.bt.co.uk> User-Agent: Mutt/1.4.1i Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/c1jhnEiPkUFL1G4PM3COHVVO-5U Cc: tcpm IETF list Subject: Re: [tcpm] More TCP option space in a SYN: draft-briscoe-tcpm-syn-op-sis-02 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Sep 2014 19:53:50 -0000 Bob Briscoe wrote: > At 15:50 26/09/2014, John Leslie wrote: >>Bob Briscoe wrote: >... >> I'd like to remind folks of two other drafts: >> >>- draft-ietf-tcpm-fastopen "allows data to be carried in the SYN" packet. >> Something like this is inevitable; and _will_ put application-layer >> data in the inital SYN (to reduce experienced latency). > > This is referenced from both drafts. Yes. I felt a need to emphasize it... > You have to be careful using fast open as well as putting TCP options > in the payload. I've written the following into > draft-briscoe-syn-op-sis, and a similar rule will be needed in > draft-touch-tcpm-tcp-syn-ext-opt: > >" If an upgraded TCP client includes the TCP Fast Open option >" [I-D.ietf-tcpm-fastopen] in the SYN, it MUST be placed with the extra >" TCP options after the end of the payload. Indeed, that is a good way to ensure that the SYN receiver is aware of the sender's intent to place something _after_ the data intended to be passed to the application. >" An upgraded TCP client MUST NOT place any TCP option in the TCP header >" of a SYN that might cause a TCP server to pass user-data directly to >" the application before the 3-way handshake completes. This is correct, if a bit hard for the reader to grok... >>- draft-nishida-tcpm-apaws "can provide protection against old duplicates" >> without using timestamps. (Timestamps will eat up ten bytes in _every_ >> packet.) This should reduce the demand for option space in the SYN. > > Most certainly agree. See quoted text under the next point... >... >> Hopefully I don't need to draw attention to draft-touch-tcpm-edo. >> This seems to be moving towards consensus on how to increase the option >> space on every packet _after_ the initial SYN. >> >> Thus, in most cases, for today's traffic there is little need to >> worry about extending the option space in the initial SYN. There seems >> to be plenty of time to experiment... > > Not sure I'm so relaxed. Quoting > > >" 1.1. Motivation for Adoption (to be removed before publication) (I think the point deserves to be made in the published RFC.) >" It is recognised that there could be potential for compressing >" together multiple options in order to mitigate the option space >" problem. However, it seems inevitable that ultimately more option >" space will be needed, particularly given that many of the TCP options >" introduced recently consume large numbers of bits in order to provide >" sufficient information entropy, which is not amenable to compression. I agree on the ultimate need. But it will necessarily be postponed until we finish Experimental status and move to Proposed Standard. >" Extension of TCP option space on a SYN requires support from both >" ends. This means it will take many years before the facility is >" functional for most pairs of end-points. Therefore, given the >" problem is already becoming pressing, a solution needs to start being >" deployed now. (No objection to that text.) >> For any Experimental-status document, I recommend: >> >> - that the various on-the-wire formats be kept as similar as possible; >> >> - that any acknowledgment of extra option space in an initial SYN >> include a checksum or hash of the extra options to ensure that both >> ends have the same view of what options have been signaled; > > Not convinced on this one. Each TCP option has its own way for the > 'server' to confirm whether it supports an option requested by the > client. And this one should also have its own way. I see so many things that could get in the way that I _strongly_ recommend some checksum/hash. > And support for the option to extend the option space is confirmed by > the server. One bit of information (support-yes-or-no) just isn't sufficient, IMHO. > So it seems redundant for the server to feedback yet another > confirmation via a checksum of all the extra options requested. Redundancy is your friend when complexity multiplies. >> IMHO, Bob's SYN-U cases are best condensed into a single format >> where the SYN sender explicitly notes the position in the payload to be >> occupied by additional TCP options, and guarantees that no application- >> layer data will follow these. > > Good point about the guarantee. > >> The receiving endpoint would search for the extra options whether or >> not it found the SYN-U option in the initial SYN, (Did I write that?? I was thinking MAY...) > This won't work. This would require every server to hold a list of > valid TCP options and their valid length fields. This list is large, > and the list of future options yet to be defined is even larger (and > obviously unknown). But that's exactly what you solve in you "non-deterministic" version. >... >> and reply including a checksum/hash of the options it found. (The >> receiving endpoint MUST find some confirmation that these options >> were intended, or _it_ bears the responsibility to reverse any >> action on the extended options and pass the payload where it >> otherwise would have gone.) > > No need for all this - see above and see drafts. Your non-deterministic version does this with a magic-number. That is an obvious weakness. I intended to draw attention to the issue -- not propose a particular solution. But obviously: if the SYN sender sends a SYN-U which the receiver doesn't get because a meddlebox removed it, the sender can learn of the problem when a returned checksum fails -- but the receiver won't know of the problem until the sender aborts. The receiver might choose to delay sending fastopen data in every case where no SYN-U was received -- or there are other possibilities. Pick your poison... >> I'm not sure this entire middlebox-transit idea is worth the trouble; >> but it probably deserves to be an optional part of the experiment. > > The reason I came up with syn-op-sis is to be able to be near-certain > that it will get through current middleboxes. I think the group will > find such near-certainty to be liberating, compared to the minefield > we currently have to tip-toe through. But it does add complexity. I won't pre-judge what balance of complexity the WG may chooose. > The only case I can think of where there could be a blockage is where > a split TCP connection holds back any payload on the SYN until the > 3WHS completes. ... which _will_ happen... :^( >> The SYN-U sender MUST deal with the danger of its additional options >> being passed to the application as data. For legacy receivers it can do >> this by aborting before the end of the three-way handshake. But there >> must be coordination with tcpm-fastopen to protect against such data >> being passed to the application before the SYN-U sender can abort. >> (This is not a trivial consideration!) > > Altho certainly not a trivial consideration, it is trivial to be safe > against this - see the rule already in the syn-op-sis draft, quoted > above, which is careful to be specific about TFO, as well as > generalising to anything in the future that might be like TFO (e.g. > tcpcrypt uses the TCP payload for control messages). I expect fastopen to see widespread use -- and I expect it to be programmed by different folks that program syn-op-sis. Our warning label (IMHO) needs to be rather prominent... >> The question of separating payload data to go to the application >> from extended TCP options clearly requires action by the SYN receiver. >> This is fairly simple if the SYN sender can ensure that _none_ of the >> payload data should go to the application (and thus not use fastopen >> at all): of course the connection must still be aborted if the SYN >> receiver doesn't acknowledge separating out the extended options. >> >> IMHO, the SYN sender should never use SYN-U unless extra option >> space in the SYN is needed; and it's probably better to never use >> SYN-U for connections where latency of setup is the over-riding factor. >> But YMMV. I wonder whether such overlap is worth the trouble to try >> to design into the protocol. > > In the syn-op-sis spec there is a choice between two variants of the > protocol (I recommend the choice can be made by implementers, not the > IETF). Hmm... This is a dangerous idea. Experimental results get hopelessly cloudy when implementations are _fundamentally_ different... > The choice I've recommended removes any risk of extra latency > on the upgraded connection. I've included a discussion of the > tradeoff between them in Appendix B.1: > > > BTW, I spend most of my time these days working on a project to > remove latency from protocols. :^) (Can you spell ECN?) -- John Leslie From nobody Fri Sep 26 14:10:35 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB3571A0364 for ; Fri, 26 Sep 2014 14:10:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.986 X-Spam-Level: X-Spam-Status: No, score=-4.986 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786] autolearn=ham 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 wvv8VwdHr0-x for ; Fri, 26 Sep 2014 14:10:24 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 933611A0233 for ; Fri, 26 Sep 2014 14:10:24 -0700 (PDT) Received: from [128.9.160.81] (nib.isi.edu [128.9.160.81]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id s8QL97s2023719 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 26 Sep 2014 14:09:07 -0700 (PDT) Message-ID: <5425D5F3.40304@isi.edu> Date: Fri, 26 Sep 2014 14:09:07 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: John Leslie , Bob Briscoe References: <201409222045.s8MKjZdD002071@bagheera.jungle.bt.co.uk> <542344DA.9020905@isi.edu> <201409250956.s8P9uae9013452@bagheera.jungle.bt.co.uk> <201409251842.s8PIgUdQ015414@bagheera.jungle.bt.co.uk> <201409260957.s8Q9vmEd018560@bagheera.jungle.bt.co.uk> <20140926145037.GA82183@verdi> <201409261716.s8QHGC7I020142@bagheera.jungle.bt.co.uk> <20140926195338.GH83009@verdi> In-Reply-To: <20140926195338.GH83009@verdi> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/L3GvwOFLsJ7o6afoNn59dn_M1CA Cc: tcpm IETF list Subject: Re: [tcpm] More TCP option space in a SYN: draft-briscoe-tcpm-syn-op-sis-02 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Sep 2014 21:10:27 -0000 On 9/26/2014 12:53 PM, John Leslie wrote: > Bob Briscoe wrote: ... >> BTW, I spend most of my time these days working on a project to >> remove latency from protocols. > > :^) > > (Can you spell ECN?) Congestion is only one of a half-dozen fundamental causes of latency, FWIW. Joe From nobody Mon Sep 29 08:28:19 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EA331A8799 for ; Mon, 29 Sep 2014 08:28:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.986 X-Spam-Level: X-Spam-Status: No, score=-4.986 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786] autolearn=ham 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 tYFRQwojwyWr for ; Mon, 29 Sep 2014 08:28:12 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A57CC1A87C0 for ; Mon, 29 Sep 2014 08:28:12 -0700 (PDT) Received: from [192.168.1.10] (pool-71-103-148-36.lsanca.dsl-w.verizon.net [71.103.148.36]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id s8TFPGgB023730 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 29 Sep 2014 08:25:25 -0700 (PDT) Message-ID: <542979DC.7090601@isi.edu> Date: Mon, 29 Sep 2014 08:25:16 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: John Leslie , Bob Briscoe References: <201409222045.s8MKjZdD002071@bagheera.jungle.bt.co.uk> <542344DA.9020905@isi.edu> <201409250956.s8P9uae9013452@bagheera.jungle.bt.co.uk> <201409251842.s8PIgUdQ015414@bagheera.jungle.bt.co.uk> <201409260957.s8Q9vmEd018560@bagheera.jungle.bt.co.uk> <20140926145037.GA82183@verdi> <201409261716.s8QHGC7I020142@bagheera.jungle.bt.co.uk> <20140926195338.GH83009@verdi> In-Reply-To: <20140926195338.GH83009@verdi> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/7y-sTB5FKlp6gz53e83sI_BEUsM Cc: tcpm IETF list Subject: Re: [tcpm] More TCP option space in a SYN: draft-briscoe-tcpm-syn-op-sis-02 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Sep 2014 15:28:16 -0000 On 9/26/2014 12:53 PM, John Leslie wrote: > Bob Briscoe wrote: >> " If an upgraded TCP client includes the TCP Fast Open option >> " [I-D.ietf-tcpm-fastopen] in the SYN, it MUST be placed with the extra >> " TCP options after the end of the payload. > > Indeed, that is a good way to ensure that the SYN receiver is aware > of the sender's intent to place something _after_ the data intended to > be passed to the application. I'd like to understand the logic behind this claim. Regardless of where signalling information is placed: - legacy servers will (irrevocably) accept it as application data; the only way to undo it is to terminate the connection* - upgraded servers will know where to find it Except to make parsing more complex, what is the perceived benefit of using trailer-based signalling? Joe *- TCP-FO is particularly dangerous when coupled with dual-SYN (DS) variants when the connection uses a cookie from a previous connection; non-DS FO servers can't prevent passing invalid data to the application by terminating the connection when the SYN-ACK is received by the client. From nobody Mon Sep 29 09:58:45 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0646F1A88B1 for ; Mon, 29 Sep 2014 09:58:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.986 X-Spam-Level: X-Spam-Status: No, score=-4.986 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786] autolearn=ham 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 3Zp7uj31X0SB for ; Mon, 29 Sep 2014 09:58:42 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 0F47A1A883A for ; Mon, 29 Sep 2014 09:58:42 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id 5FE2EC94C0; Mon, 29 Sep 2014 12:58:39 -0400 (EDT) Date: Mon, 29 Sep 2014 12:58:39 -0400 From: John Leslie To: Joe Touch Message-ID: <20140929165839.GJ83009@verdi> References: <542344DA.9020905@isi.edu> <201409250956.s8P9uae9013452@bagheera.jungle.bt.co.uk> <201409251842.s8PIgUdQ015414@bagheera.jungle.bt.co.uk> <201409260957.s8Q9vmEd018560@bagheera.jungle.bt.co.uk> <20140926145037.GA82183@verdi> <201409261716.s8QHGC7I020142@bagheera.jungle.bt.co.uk> <20140926195338.GH83009@verdi> <542979DC.7090601@isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <542979DC.7090601@isi.edu> User-Agent: Mutt/1.4.1i Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/oh-gbXU6UF1wG6XB62PPFotdzPg Cc: tcpm IETF list Subject: Re: [tcpm] More TCP option space in a SYN: draft-briscoe-tcpm-syn-op-sis-02 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Sep 2014 16:58:44 -0000 Joe Touch wrote: > On 9/26/2014 12:53 PM, John Leslie wrote: >> Bob Briscoe wrote: >>> " If an upgraded TCP client includes the TCP Fast Open option >>> " [I-D.ietf-tcpm-fastopen] in the SYN, it MUST be placed with the extra >>> " TCP options after the end of the payload. >> >> Indeed, that is a good way to ensure that the SYN receiver is aware >> of the sender's intent to place something _after_ the data intended to >> be passed to the application. > > I'd like to understand the logic behind this claim. Good! > Regardless of where signalling information is placed: > > - legacy servers will (irrevocably) accept it as > application data; the only way to undo it is to > terminate the connection* > > - upgraded servers will know where to find it > > Except to make parsing more complex, what is the perceived benefit of > using trailer-based signalling? Bob, I believe, thinks he can outwit meddleboxes. I'll let him make that case. Myself, I see it a a way to coexist with things to come. Joe, I suspect, is thinking how to do this in hardware. Indeed, to a middlebox, harder-to-find translates to "expensive", possibly prohibitively expensive. To an actual endpoint, the expense is bearable -- if you need to act on both anyway, it's a toss-up... But myself, I think in terms of how to coexist with future things like FastOpen. I believe we've got a better shot at ensuring that nothing _follows_ our extended options than ensuring that nothing precedes them. Repeating Bob's words: > >>> " If an upgraded TCP client includes the TCP Fast Open option >>> " [I-D.ietf-tcpm-fastopen] in the SYN, it MUST be placed with the extra >>> " TCP options after the end of the payload. and recalling that extended options _can't_ be parsed until the inital TCP option invoking extended options is parsed, we see that the receiving endpoint _must_ know about the overlap of extended-options and fast-open. That brings us to the tussle of whether either _must_ play with the data the other wants to add. To me, the simplest case is that fast-open does its job first (hopefully someday to include a byte-count), while extended-options comes along and puts its data after fast-open's data (and anything else which may come along), trusting the receiver to remove it from anything to be passed to the application. I am convinced we will see cases where both fast-open and extended- options need to be used. While this tussle could go either way, I prefer to place the complexity in extended-options. > *- TCP-FO is particularly dangerous when coupled with dual-SYN (DS) > variants when the connection uses a cookie from a previous connection; > non-DS FO servers can't prevent passing invalid data to the application > by terminating the connection when the SYN-ACK is received by the client. I had to read this twice to get Joe's point. :^( Dual-SYN solutions would be expected to place fast-open in both SYNs, probably with the same cookie. In the legacy case, nothing can prevent the payload being passed to the application long before the sender becomes aware of the state of the other SYN. This probably deserves mention in any dual-SYN proposal. (Obviously, if the legacy SYN is postponed long enough, this ceases to be a problem; but by then you've lost most of the latency advantage.) -- John Leslie From nobody Mon Sep 29 11:12:41 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 312731A8A15 for ; Mon, 29 Sep 2014 11:12:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.986 X-Spam-Level: X-Spam-Status: No, score=-4.986 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786] autolearn=ham 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 xpMmdg7bhBjj for ; Mon, 29 Sep 2014 11:12:37 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18E761A1B7F for ; Mon, 29 Sep 2014 11:12:37 -0700 (PDT) Received: from [128.9.160.211] (mul.isi.edu [128.9.160.211]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id s8TIBrgF026695 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 29 Sep 2014 11:11:53 -0700 (PDT) Message-ID: <5429A0E8.3080704@isi.edu> Date: Mon, 29 Sep 2014 11:11:52 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: John Leslie References: <542344DA.9020905@isi.edu> <201409250956.s8P9uae9013452@bagheera.jungle.bt.co.uk> <201409251842.s8PIgUdQ015414@bagheera.jungle.bt.co.uk> <201409260957.s8Q9vmEd018560@bagheera.jungle.bt.co.uk> <20140926145037.GA82183@verdi> <201409261716.s8QHGC7I020142@bagheera.jungle.bt.co.uk> <20140926195338.GH83009@verdi> <542979DC.7090601@isi.edu> <20140929165839.GJ83009@verdi> In-Reply-To: <20140929165839.GJ83009@verdi> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/OLnpFgqhHmn7-smXrSgJN46rCYU Cc: tcpm IETF list Subject: Re: [tcpm] More TCP option space in a SYN: draft-briscoe-tcpm-syn-op-sis-02 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Sep 2014 18:12:39 -0000 On 9/29/2014 9:58 AM, John Leslie wrote: > Joe Touch wrote: >> On 9/26/2014 12:53 PM, John Leslie wrote: >>> Bob Briscoe wrote: >>>> " If an upgraded TCP client includes the TCP Fast Open option >>>> " [I-D.ietf-tcpm-fastopen] in the SYN, it MUST be placed with the extra >>>> " TCP options after the end of the payload. >>> >>> Indeed, that is a good way to ensure that the SYN receiver is aware >>> of the sender's intent to place something _after_ the data intended to >>> be passed to the application. >> >> I'd like to understand the logic behind this claim. > > Good! > >> Regardless of where signalling information is placed: >> >> - legacy servers will (irrevocably) accept it as >> application data; the only way to undo it is to >> terminate the connection* >> >> - upgraded servers will know where to find it >> >> Except to make parsing more complex, what is the perceived benefit of >> using trailer-based signalling? > > Bob, I believe, thinks he can outwit meddleboxes. I'll let him make > that case. > > Myself, I see it a a way to coexist with things to come. > > Joe, I suspect, is thinking how to do this in hardware. Not specifically. IMO, might create another opportunity to get things wrong because it's now how we currently process options. > Indeed, to a middlebox, harder-to-find translates to "expensive", > possibly prohibitively expensive. To an actual endpoint, the expense > is bearable -- if you need to act on both anyway, it's a toss-up... > > But myself, I think in terms of how to coexist with future things > like FastOpen. I believe we've got a better shot at ensuring that > nothing _follows_ our extended options than ensuring that nothing > precedes them. > > Repeating Bob's words: >> >>>> " If an upgraded TCP client includes the TCP Fast Open option >>>> " [I-D.ietf-tcpm-fastopen] in the SYN, it MUST be placed with the extra >>>> " TCP options after the end of the payload. > > and recalling that extended options _can't_ be parsed until the inital > TCP option invoking extended options is parsed, we see that the receiving > endpoint _must_ know about the overlap of extended-options and fast-open. > > That brings us to the tussle of whether either _must_ play with the > data the other wants to add. To me, the simplest case is that fast-open > does its job first (hopefully someday to include a byte-count), while > extended-options comes along and puts its data after fast-open's data > (and anything else which may come along), trusting the receiver to > remove it from anything to be passed to the application. I'm not sure I understand this. User data can't be placed in (or removed from) the segment until after all the options are handled anyway. > I am convinced we will see cases where both fast-open and extended- > options need to be used. > > While this tussle could go either way, I prefer to place the > complexity in extended-options. It's clearly only the option processing that should ever care where the options are... >> *- TCP-FO is particularly dangerous when coupled with dual-SYN (DS) >> variants when the connection uses a cookie from a previous connection; >> non-DS FO servers can't prevent passing invalid data to the application >> by terminating the connection when the SYN-ACK is received by the client. > > I had to read this twice to get Joe's point. :^( > > Dual-SYN solutions would be expected to place fast-open in both SYNs, > probably with the same cookie. In the legacy case, nothing can prevent > the payload being passed to the application long before the sender > becomes aware of the state of the other SYN. Right - the legacy case of FO + any dual-SYN approach has this problem. It's one that the OOB method is not susceptible to, though. > (Obviously, if the legacy SYN is postponed long enough, this ceases > to be a problem; but by then you've lost most of the latency advantage.) That would happen only on a DS-capable server. I'm also thinking of the legacy server case - which might not only open two TCP connections but (with TFO) would send data to the user too early in the upgraded-SYN case - and it's corrupt data because the server is interpreting the extended option as user data. Joe From nobody Mon Sep 29 13:36:50 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BB5F1ACC86; Mon, 29 Sep 2014 13:36:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 C2g02RPL1dTD; Mon, 29 Sep 2014 13:36:47 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5840A1ACCE5; Mon, 29 Sep 2014 13:36:43 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.3.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140929203643.20758.76452.idtracker@ietfa.amsl.com> Date: Mon, 29 Sep 2014 13:36:43 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/LFyyooYkXMOBOCSASPITtaXw0RI Cc: tcpm@ietf.org Subject: [tcpm] I-D Action: draft-ietf-tcpm-fastopen-10.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Sep 2014 20:36:48 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the TCP Maintenance and Minor Extensions Working Group of the IETF. Title : TCP Fast Open Authors : Yuchung Cheng Jerry Chu Sivasankar Radhakrishnan Arvind Jain Filename : draft-ietf-tcpm-fastopen-10.txt Pages : 24 Date : 2014-09-29 Abstract: This document describes an experimental TCP mechanism TCP Fast Open (TFO). TFO allows data to be carried in the SYN and SYN-ACK packets and consumed by the receiving end during the initial connection handshake, and saves up to one full round trip time (RTT) compared to the standard TCP, which requires a three-way handshake (3WHS) to complete before data can be exchanged. However TFO deviates from the standard TCP semantics since the data in the SYN could be replayed to an application in some rare circumstances. Applications should not use TFO unless they can tolerate this issue detailed in the Applicability section. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tcpm-fastopen/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-tcpm-fastopen-10 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-fastopen-10 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Sep 29 15:48:18 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FBF51ACD5E for ; Mon, 29 Sep 2014 15:48:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.986 X-Spam-Level: X-Spam-Status: No, score=-4.986 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786] autolearn=ham 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 jEavEFloTdx5 for ; Mon, 29 Sep 2014 15:48:12 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 870601ACD73 for ; Mon, 29 Sep 2014 15:48:12 -0700 (PDT) Received: from [128.9.160.211] (mul.isi.edu [128.9.160.211]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id s8TMlbTT028671 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 29 Sep 2014 15:47:37 -0700 (PDT) Message-ID: <5429E189.4010505@isi.edu> Date: Mon, 29 Sep 2014 15:47:37 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: "tcpm@ietf.org" References: <20140929224033.10289.24011.idtracker@ietfa.amsl.com> In-Reply-To: <20140929224033.10289.24011.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20140929224033.10289.24011.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/uGtK5HoxiFjf1TnRqoKtUQVDjF0 Subject: [tcpm] Fwd: New Version Notification for draft-touch-tcpm-tcp-syn-ext-opt-01.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Sep 2014 22:48:14 -0000 Hi, all, An updated version of this draft has just been posted. As per off-line coordination and agreement with Bob Briscoe, this version has been updated to focus on the approach that does not use dual SYNs (i.e., SYN + out-of-band segment), and thus there are two separate drafts that don't overlap now. This should simplify the discussion of alternatives; Bob's is known as "Sister SYNs", and this is known as "SYN-EOS OOB" or simply "SYN+OOB". Joe -------- Forwarded Message -------- Subject: New Version Notification for draft-touch-tcpm-tcp-syn-ext-opt-01.txt Date: Mon, 29 Sep 2014 15:40:33 -0700 From: internet-drafts@ietf.org To: Ted Faber , Dr. Joseph D. Touch , Joe Touch , Ted Faber A new version of I-D, draft-touch-tcpm-tcp-syn-ext-opt-01.txt has been successfully submitted by Joe Touch and posted to the IETF repository. Name: draft-touch-tcpm-tcp-syn-ext-opt Revision: 01 Title: TCP SYN Extended Option Space Using an Out-of-Band Segment Document date: 2014-09-29 Group: Individual Submission Pages: 14 URL: http://www.ietf.org/internet-drafts/draft-touch-tcpm-tcp-syn-ext-opt-01.txt Status: https://datatracker.ietf.org/doc/draft-touch-tcpm-tcp-syn-ext-opt/ Htmlized: http://tools.ietf.org/html/draft-touch-tcpm-tcp-syn-ext-opt-01 Diff: http://www.ietf.org/rfcdiff?url2=draft-touch-tcpm-tcp-syn-ext-opt-01 Abstract: This document describes an experimental method to extend the option space for connection parameters within the initial TCP SYN segment, at the start of a TCP connection. This method effectively extends the option space of an initial SYN by using an additional coupled segment that is sent 'out-of-band'. It complements the proposed Extended Data Offset (EDO) option that is applicable only after the initial segment. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat From nobody Mon Sep 29 23:11:11 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 549C61A01EA; Mon, 29 Sep 2014 23:10:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=unavailable 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 AiHQlmINlty5; Mon, 29 Sep 2014 23:10:26 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B06291A019C; Mon, 29 Sep 2014 23:10:26 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.3.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140930061026.13961.13586.idtracker@ietfa.amsl.com> Date: Mon, 29 Sep 2014 23:10:26 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/fohht-soog_NZlwA_uca50OqLmY Cc: tcpm@ietf.org Subject: [tcpm] I-D Action: draft-ietf-tcpm-tcp-edo-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Sep 2014 06:10:39 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the TCP Maintenance and Minor Extensions Working Group of the IETF. Title : TCP Extended Data Offset Option Authors : Joe Touch Wesley M. Eddy Filename : draft-ietf-tcpm-tcp-edo-00.txt Pages : 17 Date : 2014-09-29 Abstract: TCP segments include a Data Offset field to indicate space for TCP options, but the size of the field can limit the space available for complex options that have evolved. This document updates RFC 793 with an optional TCP extension to that space to support the use of multiple large options such as SACK with either TCP Multipath or TCP AO. It also explains why the initial SYN of a connection cannot be extending as a single segment. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tcpm-tcp-edo/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-tcpm-tcp-edo-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Sep 29 23:13:59 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82A0E1A01D5 for ; Mon, 29 Sep 2014 23:13:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 DXUUg9q3c2mF for ; Mon, 29 Sep 2014 23:13:49 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 126351A01F2 for ; Mon, 29 Sep 2014 23:13:47 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: tcpm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.3.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140930061347.13961.97326.idtracker@ietfa.amsl.com> Date: Mon, 29 Sep 2014 23:13:47 -0700 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/nSF5oDxdmkTk0gHAJyIsDQeB66w Subject: [tcpm] Milestones changed for tcpm WG X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Sep 2014 06:13:57 -0000 Changed milestone "Submit document on a TCP Extended Data Offset Option to the IESG as a Proposed Standard RFC", added draft-ietf-tcpm-tcp-edo to milestone. URL: http://datatracker.ietf.org/wg/tcpm/charter/ From nobody Tue Sep 30 07:45:39 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 894091A1A33 for ; Tue, 30 Sep 2014 07:45:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.387 X-Spam-Level: X-Spam-Status: No, score=-3.387 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=ham 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 0jbuh9gKEm7r for ; Tue, 30 Sep 2014 07:45:30 -0700 (PDT) Received: from hubrelay-rd.bt.com (hubrelay-rd.bt.com [62.239.224.99]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D739A1A1A3B for ; Tue, 30 Sep 2014 07:45:29 -0700 (PDT) Received: from EVMHR71-UKRD.domain1.systemhost.net (10.36.3.109) by EVMHR68-UKRD.bt.com (10.187.101.23) with Microsoft SMTP Server (TLS) id 8.3.348.2; Tue, 30 Sep 2014 15:45:27 +0100 Received: from EPHR02-UKIP.domain1.systemhost.net (147.149.100.81) by EVMHR71-UKRD.domain1.systemhost.net (10.36.3.109) with Microsoft SMTP Server (TLS) id 8.3.348.2; Tue, 30 Sep 2014 15:45:26 +0100 Received: from bagheera.jungle.bt.co.uk (132.146.168.158) by EPHR02-UKIP.domain1.systemhost.net (147.149.100.81) with Microsoft SMTP Server id 14.3.181.6; Tue, 30 Sep 2014 15:45:25 +0100 Received: from BTP075694.jungle.bt.co.uk ([10.111.111.253]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id s8UEjMis005998; Tue, 30 Sep 2014 15:45:22 +0100 Message-ID: <201409301445.s8UEjMis005998@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 30 Sep 2014 15:45:22 +0100 To: Joe Touch From: Bob Briscoe In-Reply-To: <5429A0E8.3080704@isi.edu> References: <542344DA.9020905@isi.edu> <201409250956.s8P9uae9013452@bagheera.jungle.bt.co.uk> <201409251842.s8PIgUdQ015414@bagheera.jungle.bt.co.uk> <201409260957.s8Q9vmEd018560@bagheera.jungle.bt.co.uk> <20140926145037.GA82183@verdi> <201409261716.s8QHGC7I020142@bagheera.jungle.bt.co.uk> <20140926195338.GH83009@verdi> <542979DC.7090601@isi.edu> <20140929165839.GJ83009@verdi> <5429A0E8.3080704@isi.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/IKMbPjbtBSuLSvYFg-3m0MmJgUs Cc: tcpm IETF list Subject: Re: [tcpm] More TCP option space in a SYN: draft-briscoe-tcpm-syn-op-sis-02 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Sep 2014 14:45:37 -0000 Joe & John, At 19:11 29/09/2014, Joe Touch wrote: >On 9/29/2014 9:58 AM, John Leslie wrote: > > Joe Touch wrote: > >> On 9/26/2014 12:53 PM, John Leslie wrote: > >>> Bob Briscoe wrote: > >>>> " If an upgraded TCP client includes the TCP Fast Open option > >>>> " [I-D.ietf-tcpm-fastopen] in the SYN, it MUST be placed with the extra > >>>> " TCP options after the end of the payload. > >>> > >>> Indeed, that is a good way to ensure that the SYN receiver is aware > >>> of the sender's intent to place something _after_ the data intended to > >>> be passed to the application. > >> > >> I'd like to understand the logic behind this claim. > > > > Good! > > > >> Regardless of where signalling information is placed: > >> > >> - legacy servers will (irrevocably) accept it as > >> application data; the only way to undo it is to > >> terminate the connection* As you know, syn-op-sis is designed so the client detects a legacy SYN/ACK and terminates that connection. The reason for requiring a syn-op-sis client to only ever locate TFO beyond the Data Offset in a SYN with extra options is precisely so that it will never use TFO to ask a legacy server to pass the payload to the app at the same time as it is placing (other) options in the payload. And the wording in the draft generalises this to any future option that might cause a server to pass payload to the app during the 3WHS, not just TFO. > >> > >> - upgraded servers will know where to find it > >> > >> Except to make parsing more complex, what is the perceived benefit of > >> using trailer-based signalling? The fact that you (Joe) are asking the same question that I've already answered (on the list and in the draft) implies you don't accept the answer. But unless I can understand what you don't accept about the answer, I can only answer it the same way as I already have. However, I will try to spell it out more fully... a) Ultimately, locating options as a trailer is not intrinsic to syn-op-sis. At this pre-implementation stage, a quick edit to the draft could locate them straight after the Data Offset. b) However, as the initial proposition, I have located the options as a trailer, because middleboxes exist that look at the dest port, and they assume that the app-layer protocol is that associated with the port (eg. http if the port is 80). [Acting on this assumption violates layering, but I'll come to that.] Then they parse the first X bytes of the payload, where the choice of X depends on the expect protocol and how much they can do at line rate. If the payload does not start with the expected app-layer commands, what they do next depends on the box function: * If it's an intrusion detection system, it will probably drop the packet. * If it's a app-layer filter, it will probably drop the packet (e.g. a Web filter is looking for the requested Web page to determine whether to block it, and it becomes suspicious when it's not even http). * If it's a performance accelerator, it will probably forward the packet without being able to use any of its app-specific acceleration capabilities, because it doesn't recognise the app-layer protocol. I would be very happy if experiments showed such middleboxes are a corner-case, but I suspect they are not. I know these boxes violate layering and we do not have to dance to their tune. However, my goal is simple: There is no point in providing extra option space in a SYN if it does not get delivered. There is a tradeoff between the probability of getting delivered and the complexity introduced to the protocol. My simple view is that I would rather do (limited) extra processing on all packets so that a greater proportion get delivered. What use is it if an implementation doesn't work but it's efficient? > > > > Bob, I believe, thinks he can outwit meddleboxes. I'll let him make > > that case. > > > > Myself, I see it a a way to coexist with things to come. * Locating extra options beyond the Data Offset (whether before or after the payload) provides a distinction between middlebox and destination options for the future. * Locating extra options after the payload is to avoid certain classes of existing muddleboxes, but with no intention to outwit meddleboxes (spelled out below). > > > > Joe, I suspect, is thinking how to do this in hardware. > >Not specifically. IMO, might create another opportunity to get things >wrong because it's now how we currently process options. Noted. > > Indeed, to a middlebox, harder-to-find translates to "expensive", > > possibly prohibitively expensive. To an actual endpoint, the expense > > is bearable -- if you need to act on both anyway, it's a toss-up... That's why I'm happy to evolve to a position where the current TCP options are intended for middleboxes, and it's at least acceptable if extra 'destination' options are 'harder-to-find'. > > > > But myself, I think in terms of how to coexist with future things > > like FastOpen. I believe we've got a better shot at ensuring that > > nothing _follows_ our extended options than ensuring that nothing > > precedes them. > > > > Repeating Bob's words: > >> > >>>> " If an upgraded TCP client includes the TCP Fast Open option > >>>> " [I-D.ietf-tcpm-fastopen] in the SYN, it MUST be placed with the extra > >>>> " TCP options after the end of the payload. > > > > and recalling that extended options _can't_ be parsed until the inital > > TCP option invoking extended options is parsed, we see that the receiving > > endpoint _must_ know about the overlap of extended-options and fast-open. Correct, John (in the case of an upgraded receiving endpoint). > > > > That brings us to the tussle of whether either _must_ play with the > > data the other wants to add. To me, the simplest case is that fast-open > > does its job first (hopefully someday to include a byte-count), while > > extended-options comes along and puts its data after fast-open's data > > (and anything else which may come along), trusting the receiver to > > remove it from anything to be passed to the application. I think/hope you have switched to talking about the processing order on the sender here, because of the word 'puts'. I don't understand tho what you (John) mean by "extended-options comes along and puts its data". What do you mean by 'data' in this case? User-data related to an extended option? Or the option fields themselves? >I'm not sure I understand this. User data can't be placed in (or removed >from) the segment until after all the options are handled anyway. I'm not sure why the sender has any constraint on the order in which it serialises a segment. Surely it can construct the segment in memory in any order, then serialise it? John and Joe, I'm actually unclear what the context is for this part of the conversation. As a general point, it's not healthy to have email conversations where all the participants start with the words, "I haven't properly read the draft but...", then proceed to say there are probably problems, and then try to solve those probable problems. It would be more useful for participants to trust that the author(s) of a draft wrote it because they have a solution, and they have taken some care to write it up carefully. Then it would be useful to hear critique (or praise) if there are problems with the draft (or not). > > I am convinced we will see cases where both fast-open and extended- > > options need to be used. > > > > While this tussle could go either way, I prefer to place the > > complexity in extended-options. > >It's clearly only the option processing that should ever care where the >options are... > > >> *- TCP-FO is particularly dangerous when coupled with dual-SYN (DS) > >> variants when the connection uses a cookie from a previous connection; > >> non-DS FO servers can't prevent passing invalid data to the application > >> by terminating the connection when the SYN-ACK is received by the client. > > > > I had to read this twice to get Joe's point. :^( > > > > Dual-SYN solutions would be expected to place fast-open in both SYNs, > > probably with the same cookie. In the legacy case, nothing can prevent > > the payload being passed to the application long before the sender > > becomes aware of the state of the other SYN. > >Right - the legacy case of FO + any dual-SYN approach has this problem. Wrong. It is easy to solve for dual-SYN as explained in the draft (and above). As long as TFO is after the Data Offset, a legacy server won't pass the payload to the app during the 3WHS. >It's one that the OOB method is not susceptible to, though. Correct. > > (Obviously, if the legacy SYN is postponed long enough, this ceases > > to be a problem; but by then you've lost most of the latency advantage.) > >That would happen only on a DS-capable server. It would not. As above. >I'm also thinking of the >legacy server case - which might not only open two TCP connections but >(with TFO) would send data to the user too early in the upgraded-SYN >case - and it's corrupt data because the server is interpreting the >extended option as user data. It would not. As above. In summary, TFO is not a problem for all three dual-segment approaches on the table: - SYN-EOS OOB - SYN-EOS DS - syn-op-sis. Bob >Joe ________________________________________________________________ Bob Briscoe, BT From nobody Tue Sep 30 08:16:36 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFCED1A1A62 for ; Tue, 30 Sep 2014 08:16:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.986 X-Spam-Level: X-Spam-Status: No, score=-4.986 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786] autolearn=ham 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 S06wtCgLS2-k for ; Tue, 30 Sep 2014 08:16:20 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C58621A1A5D for ; Tue, 30 Sep 2014 08:16:19 -0700 (PDT) Received: from [192.168.1.10] (pool-71-103-148-36.lsanca.dsl-w.verizon.net [71.103.148.36]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id s8UFF2mg017392 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 30 Sep 2014 08:15:11 -0700 (PDT) Message-ID: <542AC8F7.5080108@isi.edu> Date: Tue, 30 Sep 2014 08:15:03 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Bob Briscoe References: <542344DA.9020905@isi.edu> <201409250956.s8P9uae9013452@bagheera.jungle.bt.co.uk> <201409251842.s8PIgUdQ015414@bagheera.jungle.bt.co.uk> <201409260957.s8Q9vmEd018560@bagheera.jungle.bt.co.uk> <20140926145037.GA82183@verdi> <201409261716.s8QHGC7I020142@bagheera.jungle.bt.co.uk> <20140926195338.GH83009@verdi> <542979DC.7090601@isi.edu> <20140929165839.GJ83009@verdi> <5429A0E8.3080704@isi.edu> <201409301445.s8UEjMis005998@bagheera.jungle.bt.co.uk> In-Reply-To: <201409301445.s8UEjMis005998@bagheera.jungle.bt.co.uk> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/5f_zl2PaHOTH4zAVCy-ISgBX1AM Cc: tcpm IETF list Subject: Re: [tcpm] More TCP option space in a SYN: draft-briscoe-tcpm-syn-op-sis-02 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Sep 2014 15:16:22 -0000 On 9/30/2014 7:45 AM, Bob Briscoe wrote: > Joe & John, > > At 19:11 29/09/2014, Joe Touch wrote: > > >> On 9/29/2014 9:58 AM, John Leslie wrote: >> > Joe Touch wrote: >> >> On 9/26/2014 12:53 PM, John Leslie wrote: >> >>> Bob Briscoe wrote: >> >>>> " If an upgraded TCP client includes the TCP Fast Open option >> >>>> " [I-D.ietf-tcpm-fastopen] in the SYN, it MUST be placed with the >> extra >> >>>> " TCP options after the end of the payload. >> >>> >> >>> Indeed, that is a good way to ensure that the SYN receiver is aware >> >>> of the sender's intent to place something _after_ the data >> intended to >> >>> be passed to the application. >> >> >> >> I'd like to understand the logic behind this claim. >> > >> > Good! >> > >> >> Regardless of where signalling information is placed: >> >> >> >> - legacy servers will (irrevocably) accept it as >> >> application data; the only way to undo it is to >> >> terminate the connection* > > As you know, syn-op-sis is designed so the client detects a legacy > SYN/ACK and terminates that connection. By the time the client receives the SYN/ACK, the legacy server would have already forwarded FTO data to the user. > The reason for requiring a syn-op-sis client to only ever locate TFO > beyond the Data Offset in a SYN with extra options is precisely so that > it will never use TFO to ask a legacy server to pass the payload to the > app at the same time as it is placing (other) options in the payload. Ahh - I see. > And the wording in the draft generalises this to any future option that > might cause a server to pass payload to the app during the 3WHS, not > just TFO. The problem is that you can't necessarily make assertions about options that already exist, and this might complicate TCP option processing -- you need to enforce it on both client and server, and legacy receivers can't know that this is a problem. >> >> - upgraded servers will know where to find it >> >> >> >> Except to make parsing more complex, what is the perceived benefit of >> >> using trailer-based signalling? > > The fact that you (Joe) are asking the same question that I've already > answered (on the list and in the draft) implies you don't accept the > answer. But unless I can understand what you don't accept about the > answer, I can only answer it the same way as I already have. However, I > will try to spell it out more fully... > > a) Ultimately, locating options as a trailer is not intrinsic to > syn-op-sis. At this pre-implementation stage, a quick edit to the draft > could locate them straight after the Data Offset. > > b) However, as the initial proposition, I have located the options as a > trailer, because middleboxes exist that look at the dest port, and they > assume that the app-layer protocol is that associated with the port (eg. > http if the port is 80). [Acting on this assumption violates layering, > but I'll come to that.] > > Then they parse the first X bytes of the payload, where the choice of X > depends on the expect protocol and how much they can do at line rate. ... I am skeptical that middleboxes parse SYN payloads, but even if they did this might still not work. It depends on the size of the segment and the size of the extension option space. > * Locating extra options beyond the Data Offset (whether before or after > the payload) provides a distinction between middlebox and destination > options for the future. That's necessary because the DO field is limited anyway. > * Locating extra options after the payload is to avoid certain classes > of existing muddleboxes, but with no intention to outwit meddleboxes > (spelled out below). ... >> > Indeed, to a middlebox, harder-to-find translates to "expensive", >> > possibly prohibitively expensive. To an actual endpoint, the expense >> > is bearable -- if you need to act on both anyway, it's a toss-up... > > That's why I'm happy to evolve to a position where the current TCP > options are intended for middleboxes, and it's at least acceptable if > extra 'destination' options are 'harder-to-find'. All TCP options are "destination" options. However, the nature of dual-SYN requires that certain options always come after the extension (as above) - but that also means it might interfere with this partitioning by option type. E.g., I would not be surprised at all to see TFO be of particular interest to middleboxes - esp. to support load balancing while supporting TFO. >> I'm not sure I understand this. User data can't be placed in (or removed >> from) the segment until after all the options are handled anyway. > > I'm not sure why the sender has any constraint on the order in which it > serialises a segment. Surely it can construct the segment in memory in > any order, then serialise it? It can, but I don't understand the need to support more esoteric middleboxes (including those I still consider meddlers) but not the typical case where headers are built then data is added (or headers are built in one place, data in the other, and the two combined). Putting trailing options into that mix complicates lots of implementations - and can be difficult to support in offload engines, depending on how they handle buffers. > John and Joe, I'm actually unclear what the context is for this part of > the conversation. As a general point, it's not healthy to have email > conversations where all the participants start with the words, "I > haven't properly read the draft but...", then proceed to say there are > probably problems, and then try to solve those probable problems. I didn't start my email with that statement. ... > It would be more useful for participants to trust that the author(s) of > a draft wrote it because they have a solution, and they have taken some > care to write it up carefully. Then it would be useful to hear critique > (or praise) if there are problems with the draft (or not). I disagree; it's useful to post directed questions and have direct answers. Not everyone wants to try to infer intent from pages of text. ... >> > Dual-SYN solutions would be expected to place fast-open in both >> SYNs, >> > probably with the same cookie. In the legacy case, nothing can prevent >> > the payload being passed to the application long before the sender >> > becomes aware of the state of the other SYN. >> >> Right - the legacy case of FO + any dual-SYN approach has this problem. > > Wrong. It is easy to solve for dual-SYN as explained in the draft (and > above). As long as TFO is after the Data Offset, a legacy server won't > pass the payload to the app during the 3WHS. Agreed. As long as TFO is after the DO. Joe From nobody Tue Sep 30 08:54:56 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F8A21A1A88 for ; Tue, 30 Sep 2014 08:54:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.313 X-Spam-Level: X-Spam-Status: No, score=0.313 tagged_above=-999 required=5 tests=[BAYES_50=0.8, GB_SUMOF=1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=ham 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 dvMh9Ek369bm for ; Tue, 30 Sep 2014 08:54:50 -0700 (PDT) Received: from hubrelay-by-03.bt.com (hubrelay-by-03.bt.com [62.7.242.139]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F27AE1A0395 for ; Tue, 30 Sep 2014 08:54:49 -0700 (PDT) Received: from EVMHR72-UKRD.domain1.systemhost.net (10.36.3.110) by EVMHR03-UKBR.bt.com (10.216.161.35) with Microsoft SMTP Server (TLS) id 8.3.348.2; Tue, 30 Sep 2014 16:54:44 +0100 Received: from EPHR02-UKIP.domain1.systemhost.net (147.149.100.81) by EVMHR72-UKRD.domain1.systemhost.net (10.36.3.110) with Microsoft SMTP Server (TLS) id 8.3.348.2; Tue, 30 Sep 2014 16:54:47 +0100 Received: from bagheera.jungle.bt.co.uk (132.146.168.158) by EPHR02-UKIP.domain1.systemhost.net (147.149.100.81) with Microsoft SMTP Server id 14.3.181.6; Tue, 30 Sep 2014 16:54:46 +0100 Received: from BTP075694.jungle.bt.co.uk ([10.111.111.253]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id s8UFsjCl006183; Tue, 30 Sep 2014 16:54:45 +0100 Message-ID: <201409301554.s8UFsjCl006183@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 30 Sep 2014 16:54:43 +0100 To: John Leslie From: Bob Briscoe In-Reply-To: <20140926195338.GH83009@verdi> References: <201409222045.s8MKjZdD002071@bagheera.jungle.bt.co.uk> <542344DA.9020905@isi.edu> <201409250956.s8P9uae9013452@bagheera.jungle.bt.co.uk> <201409251842.s8PIgUdQ015414@bagheera.jungle.bt.co.uk> <201409260957.s8Q9vmEd018560@bagheera.jungle.bt.co.uk> <20140926145037.GA82183@verdi> <201409261716.s8QHGC7I020142@bagheera.jungle.bt.co.uk> <20140926195338.GH83009@verdi> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/FMtIkO1kFXdAi6UpoxhUlrxa4hs Cc: tcpm IETF list Subject: Re: [tcpm] More TCP option space in a SYN: draft-briscoe-tcpm-syn-op-sis-02 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Sep 2014 15:54:54 -0000 John, I've got a bit behind in this conversation - I'm on another part of my job at the mo. So apologies that my response to this old posting on this thread arrives out of order. At 20:53 26/09/2014, John Leslie wrote: >Bob Briscoe wrote: > > At 15:50 26/09/2014, John Leslie wrote: > >>Bob Briscoe wrote: > >... > >> I'd like to remind folks of two other drafts: > >> > >>- draft-ietf-tcpm-fastopen "allows data to be carried in the SYN" packet. > >> Something like this is inevitable; and _will_ put application-layer > >> data in the inital SYN (to reduce experienced latency). > > > > This is referenced from both drafts. > > Yes. I felt a need to emphasize it... > > > You have to be careful using fast open as well as putting TCP options > > in the payload. I've written the following into > > draft-briscoe-syn-op-sis, and a similar rule will be needed in > > draft-touch-tcpm-tcp-syn-ext-opt: > > > >" If an upgraded TCP client includes the TCP Fast Open option > >" [I-D.ietf-tcpm-fastopen] in the SYN, it MUST be placed with the extra > >" TCP options after the end of the payload. > > Indeed, that is a good way to ensure that the SYN receiver is aware >of the sender's intent to place something _after_ the data intended to >be passed to the application. > > >" An upgraded TCP client MUST NOT place any TCP option in the TCP header > >" of a SYN that might cause a TCP server to pass user-data directly to > >" the application before the 3-way handshake completes. > > This is correct, if a bit hard for the reader to grok... I wanted to state it both for the specific case of TFO and in general terms in case some other option is invented in future that passes data to the app before the 3WHS completes. > >>- draft-nishida-tcpm-apaws "can provide protection against old duplicates" > >> without using timestamps. (Timestamps will eat up ten bytes in _every_ > >> packet.) This should reduce the demand for option space in the SYN. > > > > Most certainly agree. See quoted text under the next point... > >... > >> Hopefully I don't need to draw attention to draft-touch-tcpm-edo. > >> This seems to be moving towards consensus on how to increase the option > >> space on every packet _after_ the initial SYN. > >> > >> Thus, in most cases, for today's traffic there is little need to > >> worry about extending the option space in the initial SYN. There seems > >> to be plenty of time to experiment... > > > > Not sure I'm so relaxed. Quoting > > > > > >" 1.1. Motivation for Adoption (to be removed before publication) > > (I think the point deserves to be made in the published RFC.) These paras are about what the IETF's wider agenda should be and where this draft fits in, which isn't appropriate in an RFC. And they are not timeless, which an RFC should also avoid. > >" It is recognised that there could be potential for compressing > >" together multiple options in order to mitigate the option space > >" problem. However, it seems inevitable that ultimately more option > >" space will be needed, particularly given that many of the TCP options > >" introduced recently consume large numbers of bits in order to provide > >" sufficient information entropy, which is not amenable to compression. > > I agree on the ultimate need. But it will necessarily be postponed >until we finish Experimental status and move to Proposed Standard. > > >" Extension of TCP option space on a SYN requires support from both > >" ends. This means it will take many years before the facility is > >" functional for most pairs of end-points. Therefore, given the > >" problem is already becoming pressing, a solution needs to start being > >" deployed now. > > (No objection to that text.) > > >> For any Experimental-status document, I recommend: > >> > >> - that the various on-the-wire formats be kept as similar as possible; > >> > >> - that any acknowledgment of extra option space in an initial SYN > >> include a checksum or hash of the extra options to ensure that both > >> ends have the same view of what options have been signaled; > > > > Not convinced on this one. Each TCP option has its own way for the > > 'server' to confirm whether it supports an option requested by the > > client. > > And this one should also have its own way. I see so many things that >could get in the way that I _strongly_ recommend some checksum/hash. > > > And support for the option to extend the option space is confirmed by > > the server. > > One bit of information (support-yes-or-no) just isn't sufficient, >IMHO. I believe you're trying to recover some determinism because of the non-determinism I've introduced. If so, I strongly believe that it's better to lessen the original non-determinism (e.g. by a larger magic number), rather than to add more message exchanges. If both achieve the same higher level of determinism, I'd much rather use the one that avoids adding more branches to the protocol logic. > > So it seems redundant for the server to feedback yet another > > confirmation via a checksum of all the extra options requested. > > Redundancy is your friend when complexity multiplies. I believe the opposite is true. If you provide two different ways to say the same thing, you create more complexity - to check they are both saying the same thing. And if they are not, you have to decide which one not to believe. This makes the spec and the code more complex. > >> IMHO, Bob's SYN-U cases are best condensed into a single format > >> where the SYN sender explicitly notes the position in the payload to be > >> occupied by additional TCP options, and guarantees that no application- > >> layer data will follow these. > > > > Good point about the guarantee. > > > >> The receiving endpoint would search for the extra options whether or > >> not it found the SYN-U option in the initial SYN, > > (Did I write that?? I was thinking MAY...) > > > This won't work. This would require every server to hold a list of > > valid TCP options and their valid length fields. This list is large, > > and the list of future options yet to be defined is even larger (and > > obviously unknown). > > But that's exactly what you solve in you "non-deterministic" version. I think you've read something into it that isn't there. The draft doesn't say an implementation has to "search for the extra options". Perhaps you didn't mean that? It specifies a deterministic location for the SYNOPSIS option that tells you where the other extra TCP options start. The draft doesn't say or imply that an implementation has to know anything about any valid TCP options. Maybe you've wrongly jumped to that conclusion? Was it the last bullet in the quoted list below that made you think this?: " an upgraded server MUST determine whether there is a SynOpSis TCP option at the end of the packet by checking all the following conditions: o The Kind value is the SynOpSis Kind value; o The length is 8; o The next 4 octets match the magic number; o The sum of the value of the EOO field, and all the length fields found by walking along the TCP options at the end of the payload exactly reaches the end of the packet. " Perhaps I need to spell out what that means... First note that the implementation only needs to continue down this list of tests if all the previous tests have passed. So it will only have to do the last test if, at the end of the payload, there is arbitrary user-data that happens to contain exactly the same bytes as a SYNOPSIS TCP option (i.e. it has passed the first three tests). The only assumption the fourth test makes about TCP options is that their length field is at the second octet, and that the number in that field specifies the length of the TCP option in octets. This should be true for all TCP options, past and future. "Walking along the TCP options" means that the implementation: * looks at the byte where the SYNOPSIS option says the first length field will be (one byte forward from where the extra options start), * jumps forward by the value in this byte to the byte where the next length field would be if there was a TCP option there, * and so on. And if there really are TCP options there, stepping along the bytes where the length fields should be will land on the length field of the SYNOPSIS option at the end packet. On the other hand, if it's just user-data that happens to have bytes that look like a SYNOPSIS option at the end, there will be some arbitrary byte in the location where the extended options offset (EOO) would be if it was a SYNOPSIS option. Even though that byte is not really an offset, there will be some number in that byte. If that number is taken to be an offset, it will point to somewhere else in the segment. One byte forward from there will be another byte where the first length field seems to be, even though it's just an arbitrary byte in user-data. So jumping forward by the value in that byte will find another arbitrary byte and so on. If this process eventually lands beyond the point where the length field of the SYNOPSIS option is, the implementation knows with certainty that there aren't really TCP options there; it's just been following arbitrary bytes in arbitrary user-data. Altho this took a long time to say, these tests require minimal cycles. They just involve reading a byte at a location and using it as an offset to the next location, then checking whether that is still within the payload. It cannot continue for long, because it's always going in one direction (because an option length is defined as an unsigned int). > >... > >> and reply including a checksum/hash of the options it found. (The > >> receiving endpoint MUST find some confirmation that these options > >> were intended, or _it_ bears the responsibility to reverse any > >> action on the extended options and pass the payload where it > >> otherwise would have gone.) > > > > No need for all this - see above and see drafts. > > Your non-deterministic version does this with a magic-number. That >is an obvious weakness. I intended to draw attention to the issue -- >not propose a particular solution. > > But obviously: if the SYN sender sends a SYN-U which the receiver >doesn't get because a meddlebox removed it, the sender can learn of >the problem when a returned checksum fails -- but the receiver won't >know of the problem until the sender aborts. In syn-op-sis the sender will learn of the problem without the checksum approach. If a middlebox removes the SYNOPSIS option, the server will respond to the SYN-U with a regular SYN/ACK, not a SYN/ACK-U. This is why step 3 is needed in Table 1. And the required client behaviour is formalized in the five bullets at the end of section 2.1. With the explicit variant of the dual-handshake is used (Section 6), because a middlebox might removing the SYNOPSIS option, the draft requires the client behaviour to be the same as for the implicit variant. Search for the text "a middlebox might strip the SynOpSis TCP option" in the syn-op-sis draft. > The receiver might choose to delay sending fastopen data in every >case where no SYN-U was received -- or there are other possibilities. >Pick your poison... > > >> I'm not sure this entire middlebox-transit idea is worth the trouble; > >> but it probably deserves to be an optional part of the experiment. > > > > The reason I came up with syn-op-sis is to be able to be near-certain > > that it will get through current middleboxes. I think the group will > > find such near-certainty to be liberating, compared to the minefield > > we currently have to tip-toe through. > > But it does add complexity. I won't pre-judge what balance of >complexity the WG may chooose. Fully agree. > > The only case I can think of where there could be a blockage is where > > a split TCP connection holds back any payload on the SYN until the > > 3WHS completes. > > ... which _will_ happen... :^( > > >> The SYN-U sender MUST deal with the danger of its additional options > >> being passed to the application as data. For legacy receivers it can do > >> this by aborting before the end of the three-way handshake. But there > >> must be coordination with tcpm-fastopen to protect against such data > >> being passed to the application before the SYN-U sender can abort. > >> (This is not a trivial consideration!) > > > > Altho certainly not a trivial consideration, it is trivial to be safe > > against this - see the rule already in the syn-op-sis draft, quoted > > above, which is careful to be specific about TFO, as well as > > generalising to anything in the future that might be like TFO (e.g. > > tcpcrypt uses the TCP payload for control messages). > > I expect fastopen to see widespread use -- and I expect it to be >programmed by different folks that program syn-op-sis. Our warning >label (IMHO) needs to be rather prominent... > > >> The question of separating payload data to go to the application > >> from extended TCP options clearly requires action by the SYN receiver. > >> This is fairly simple if the SYN sender can ensure that _none_ of the > >> payload data should go to the application (and thus not use fastopen > >> at all): of course the connection must still be aborted if the SYN > >> receiver doesn't acknowledge separating out the extended options. > >> I've already dealt with the points about TFO in the rest of your email in my other recent email on this thread. > >> IMHO, the SYN sender should never use SYN-U unless extra option > >> space in the SYN is needed; and it's probably better to never use > >> SYN-U for connections where latency of setup is the over-riding factor. > >> But YMMV. I wonder whether such overlap is worth the trouble to try > >> to design into the protocol. You're allowed your humble opinion. However, if you analyse the SYNOPSIS protocol, you will conclude with absolute certainty that the upgraded SYNOPSIS connection has no latency cost. So if a SYN-U gets options through middleboxes, I predict it will be used whether or not the extra space is needed. > > > > In the syn-op-sis spec there is a choice between two variants of the > > protocol (I recommend the choice can be made by implementers, not the > > IETF). > > Hmm... > > This is a dangerous idea. Experimental results get hopelessly cloudy >when implementations are _fundamentally_ different... I've put forward two pairs of variants. For the first pair of variants, I have asked the IETF to decide between them (so I put the one I least recommend in an Appendix). But for the other pair of variants, I realised that the choice of variants can be left to the implementer, so I put it in the body (Section 6). I didn't come to these conclusions without a lot of thought (whereas up to draft-01 I hadn't fully thought this through)... The only difference in the section 6 variant is the SYN-L. It became clear to me that this is not a fundamental difference when I realised that a middlebox could reduce the SYN-L to a SYN and it would turn the protocol into the other variant. So the rest of the protocol is identical. The reason for allowing either at run-time is that the SYN-L variant is more likely to be preferred after most servers have been upgraded, but not at the start of deployment (explained in the Appendix linked below). > > The choice I've recommended removes any risk of extra latency > > on the upgraded connection. I've included a discussion of the > > tradeoff between them in Appendix B.1: > > > > Regards Bob >-- >John Leslie ________________________________________________________________ Bob Briscoe, BT From nobody Tue Sep 30 09:37:17 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AAA21A1AE3 for ; Tue, 30 Sep 2014 09:37:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.387 X-Spam-Level: X-Spam-Status: No, score=-3.387 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=ham 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 b-bioFYOZlp1 for ; Tue, 30 Sep 2014 09:37:11 -0700 (PDT) Received: from hubrelay-rd.bt.com (hubrelay-rd.bt.com [62.239.224.99]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C8AA1A1A67 for ; Tue, 30 Sep 2014 09:37:11 -0700 (PDT) Received: from EVMHR01-UKBR.domain1.systemhost.net (193.113.108.40) by EVMHR68-UKRD.bt.com (10.187.101.23) with Microsoft SMTP Server (TLS) id 8.3.348.2; Tue, 30 Sep 2014 17:37:08 +0100 Received: from EPHR02-UKIP.domain1.systemhost.net (147.149.100.81) by EVMHR01-UKBR.domain1.systemhost.net (193.113.108.40) with Microsoft SMTP Server (TLS) id 8.3.348.2; Tue, 30 Sep 2014 17:37:07 +0100 Received: from bagheera.jungle.bt.co.uk (132.146.168.158) by EPHR02-UKIP.domain1.systemhost.net (147.149.100.81) with Microsoft SMTP Server id 14.3.181.6; Tue, 30 Sep 2014 17:37:01 +0100 Received: from BTP075694.jungle.bt.co.uk ([10.111.111.253]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id s8UGaxpB006271; Tue, 30 Sep 2014 17:36:59 +0100 Message-ID: <201409301636.s8UGaxpB006271@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 30 Sep 2014 17:36:58 +0100 To: Joe Touch From: Bob Briscoe In-Reply-To: <542AC8F7.5080108@isi.edu> References: <542344DA.9020905@isi.edu> <201409250956.s8P9uae9013452@bagheera.jungle.bt.co.uk> <201409251842.s8PIgUdQ015414@bagheera.jungle.bt.co.uk> <201409260957.s8Q9vmEd018560@bagheera.jungle.bt.co.uk> <20140926145037.GA82183@verdi> <201409261716.s8QHGC7I020142@bagheera.jungle.bt.co.uk> <20140926195338.GH83009@verdi> <542979DC.7090601@isi.edu> <20140929165839.GJ83009@verdi> <5429A0E8.3080704@isi.edu> <201409301445.s8UEjMis005998@bagheera.jungle.bt.co.uk> <542AC8F7.5080108@isi.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/2alODbFqFlH0ql7AyNB8dJDEJzc Cc: tcpm IETF list Subject: Re: [tcpm] More TCP option space in a SYN: draft-briscoe-tcpm-syn-op-sis-02 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Sep 2014 16:37:14 -0000 Joe, At 16:15 30/09/2014, Joe Touch wrote: >On 9/30/2014 7:45 AM, Bob Briscoe wrote: > > Joe & John, > > > > At 19:11 29/09/2014, Joe Touch wrote: > > > > > >> On 9/29/2014 9:58 AM, John Leslie wrote: > >> > Joe Touch wrote: > >> >> On 9/26/2014 12:53 PM, John Leslie wrote: > >> >>> Bob Briscoe wrote: > >> >>>> " If an upgraded TCP client includes the TCP Fast Open option > >> >>>> " [I-D.ietf-tcpm-fastopen] in the SYN, it MUST be placed with the > >> extra > >> >>>> " TCP options after the end of the payload. > >> >>> > >> >>> Indeed, that is a good way to ensure that the SYN receiver is aware > >> >>> of the sender's intent to place something _after_ the data > >> intended to > >> >>> be passed to the application. > >> >> > >> >> I'd like to understand the logic behind this claim. > >> > > >> > Good! > >> > > >> >> Regardless of where signalling information is placed: > >> >> > >> >> - legacy servers will (irrevocably) accept it as > >> >> application data; the only way to undo it is to > >> >> terminate the connection* > > > > As you know, syn-op-sis is designed so the client detects a legacy > > SYN/ACK and terminates that connection. > >By the time the client receives the SYN/ACK, the legacy server would >have already forwarded FTO data to the user. > > > The reason for requiring a syn-op-sis client to only ever locate TFO > > beyond the Data Offset in a SYN with extra options is precisely so that > > it will never use TFO to ask a legacy server to pass the payload to the > > app at the same time as it is placing (other) options in the payload. > >Ahh - I see. > > > And the wording in the draft generalises this to any future option that > > might cause a server to pass payload to the app during the 3WHS, not > > just TFO. > >The problem is that you can't necessarily make assertions about options >that already exist, and this might complicate TCP option processing -- >you need to enforce it on both client and server, and legacy receivers >can't know that this is a problem. I can make this assertion, because it only applies to the behaviour of a client that has been upgraded for SYNOPSIS. This text requires such an update to also alter any pre-existing TFO code. > >> >> - upgraded servers will know where to find it > >> >> > >> >> Except to make parsing more complex, what is the perceived benefit of > >> >> using trailer-based signalling? > > > > The fact that you (Joe) are asking the same question that I've already > > answered (on the list and in the draft) implies you don't accept the > > answer. But unless I can understand what you don't accept about the > > answer, I can only answer it the same way as I already have. However, I > > will try to spell it out more fully... > > > > a) Ultimately, locating options as a trailer is not intrinsic to > > syn-op-sis. At this pre-implementation stage, a quick edit to the draft > > could locate them straight after the Data Offset. > > > > b) However, as the initial proposition, I have located the options as a > > trailer, because middleboxes exist that look at the dest port, and they > > assume that the app-layer protocol is that associated with the port (eg. > > http if the port is 80). [Acting on this assumption violates layering, > > but I'll come to that.] > > > > Then they parse the first X bytes of the payload, where the choice of X > > depends on the expect protocol and how much they can do at line rate. >... > >I am skeptical that middleboxes parse SYN payloads, but even if they did >this might still not work. It depends on the size of the segment and the >size of the extension option space. If a box does parse a SYN payload, it is much more likely to work if it works from the start, because usually the parsing stops once it has found what it wants. If the parsing comes to the clean end of the app-layer commands, a really paranoid box (e.g. an intrusion detection system) might be programmed to be suspicious of odd inexplicable bytes afterwards. But I figure that's much less likely than tripping up on unrecognisable bytes before it's even got started. > > * Locating extra options beyond the Data Offset (whether before or after > > the payload) provides a distinction between middlebox and destination > > options for the future. > >That's necessary because the DO field is limited anyway. > > > * Locating extra options after the payload is to avoid certain classes > > of existing muddleboxes, but with no intention to outwit meddleboxes > > (spelled out below). >... > >> > Indeed, to a middlebox, harder-to-find translates to "expensive", > >> > possibly prohibitively expensive. To an actual endpoint, the expense > >> > is bearable -- if you need to act on both anyway, it's a toss-up... > > > > That's why I'm happy to evolve to a position where the current TCP > > options are intended for middleboxes, and it's at least acceptable if > > extra 'destination' options are 'harder-to-find'. > >All TCP options are "destination" options. I forgot to add an tag to the destination adjective. >However, the nature of dual-SYN requires that certain options always >come after the extension (as above) - but that also means it might >interfere with this partitioning by option type. > >E.g., I would not be surprised at all to see TFO be of particular >interest to middleboxes - esp. to support load balancing while >supporting TFO. The critical point here is that there are two viewpoints on which options are for middleboxes: - the sender's viewpoint - the middlebox's viewpoint. Enabling the sender to separating options into two sets allows it to express its viewpoint. A middlebox does not have to /express/ its viewpoint. It just /acts/ in whatever way it chooses. Nonetheless, once the separation is in place, it might be possible for the sender to encyrypt the extra options. Then the power to act unilaterally swings the other way. > >> I'm not sure I understand this. User data can't be placed in (or removed > >> from) the segment until after all the options are handled anyway. > > > > I'm not sure why the sender has any constraint on the order in which it > > serialises a segment. Surely it can construct the segment in memory in > > any order, then serialise it? > >It can, but I don't understand the need to support more esoteric >middleboxes (including those I still consider meddlers) but not the >typical case where headers are built then data is added (or headers are >built in one place, data in the other, and the two combined). > >Putting trailing options into that mix complicates lots of >implementations - and can be difficult to support in offload engines, >depending on how they handle buffers. > > > John and Joe, I'm actually unclear what the context is for this part of > > the conversation. As a general point, it's not healthy to have email > > conversations where all the participants start with the words, "I > > haven't properly read the draft but...", then proceed to say there are > > probably problems, and then try to solve those probable problems. > >I didn't start my email with that statement. Sorry, I noticed John did and I thought I recalled that you had in the email before that, but, checking back, you actually said "I did not follow the latest discussions very closely" >... > > > It would be more useful for participants to trust that the author(s) of > > a draft wrote it because they have a solution, and they have taken some > > care to write it up carefully. Then it would be useful to hear critique > > (or praise) if there are problems with the draft (or not). > >I disagree; it's useful to post directed questions and have direct >answers. Not everyone wants to try to infer intent from pages of text. Certainly. But only after having read the draft under discussion. >... > >> > Dual-SYN solutions would be expected to place fast-open in both > >> SYNs, > >> > probably with the same cookie. In the legacy case, nothing can prevent > >> > the payload being passed to the application long before the sender > >> > becomes aware of the state of the other SYN. > >> > >> Right - the legacy case of FO + any dual-SYN approach has this problem. > > > > Wrong. It is easy to solve for dual-SYN as explained in the draft (and > > above). As long as TFO is after the Data Offset, a legacy server won't > > pass the payload to the app during the 3WHS. > >Agreed. As long as TFO is after the DO. Great. We're making progress. Cheers Bob >Joe ________________________________________________________________ Bob Briscoe, BT From nobody Tue Sep 30 14:36:07 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3508E1A916E; Tue, 30 Sep 2014 14:36:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 aE8Mmee0REnq; Tue, 30 Sep 2014 14:36:03 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 833E81A923D; Tue, 30 Sep 2014 14:35:57 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 5.6.3.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140930213557.21354.28395.idtracker@ietfa.amsl.com> Date: Tue, 30 Sep 2014 14:35:57 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/wronoubU_Jh79VDt9rt1TVgGvV0 Cc: tcpm chair , tcpm mailing list , RFC Editor Subject: [tcpm] Document Action: 'TCP Fast Open' to Experimental RFC (draft-ietf-tcpm-fastopen-10.txt) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Sep 2014 21:36:04 -0000 The IESG has approved the following document: - 'TCP Fast Open' (draft-ietf-tcpm-fastopen-10.txt) as Experimental RFC This document is the product of the TCP Maintenance and Minor Extensions Working Group. The IESG contact persons are Martin Stiemerling and Spencer Dawkins. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-tcpm-fastopen/ Technical Summary This document describes an experimental TCP mechanism TCP Fast Open (TFO). TFO allows data to be carried in the SYN and SYN-ACK packets and consumed by the receiving end during the initial connection handshake, thus saving up to one full round trip time (RTT) compared to the standard TCP, which requires a three-way handshake (3WHS) to complete before data can be exchanged. However TFO deviates from the standard TCP semantics since the data in the SYN could be replayed to an application in some rare circumstances. Applications should not use TFO unless they can tolerate this issue detailed in the Applicability section. Working Group Summary This document was extensively discussed and reviewed by the TCPM working group and there is strong support to publish the document. While being an experimental document, the TCPM working group decided to ask IESG for approving an IANA allocation of a new TCP option codepoint. Document Quality The protocol extension described in this document is implemented and deployed in the Linux TCP/IP stack, and it is supported by the Chrome Web browser and all Google servers. Experimental results have been discussed in the TCPM working group. An early SECDIR review concluded that the document had no substantive issues. Personnel The Document Shepherd is Michael Scharf . The Responsible Area Director is Martin Stiemerling . From nobody Tue Sep 30 15:54:47 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E023B1ACC86 for ; Tue, 30 Sep 2014 15:54:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.999 X-Spam-Level: X-Spam-Status: No, score=-101.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham 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 L7l9cslnUKXb for ; Tue, 30 Sep 2014 15:54:40 -0700 (PDT) Received: from mail-lb0-x22c.google.com (mail-lb0-x22c.google.com [IPv6:2a00:1450:4010:c04::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF1D11ABD37 for ; Tue, 30 Sep 2014 15:53:28 -0700 (PDT) Received: by mail-lb0-f172.google.com with SMTP id b6so5505101lbj.31 for ; Tue, 30 Sep 2014 15:53:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=vZ2UoI9rNqu0YRaxrZ//L1S3qW3gYqr0EOUvQgv/19A=; b=fjsIMzTGG56e/t8dKoZVpReP3Bs9/cKfupIjyOWvf3Mr/SpKizdJiVtgr6MT7f9U9n LIWyQM//gWuzGI71w0zsBy4PbEB2zj2KNowDS9w/mEcU9VRFAZU/r/Cn3Py1s7Mp6rkR xZKVxBIOdyxVFlRVPp87R/7OayX9voMWfNGperEsL/JkqmQBcmRuxq0WrOjJTQPX6WeV sI/kKHELA4gYPq9RP66mzXdEoLZ4AEtWymzq3TEb0KWP1QSFgfyEV9mveg0uDnI2Adm0 HKa+VoTofLGyfN0GIgE/OWaihCt/4j+Qnx4SgFPTfCgpUbK5wfGdW2ZZRdf9z2QGDTl7 HOTg== MIME-Version: 1.0 X-Received: by 10.152.29.129 with SMTP id k1mr51040230lah.81.1412117606960; Tue, 30 Sep 2014 15:53:26 -0700 (PDT) Received: by 10.112.133.138 with HTTP; Tue, 30 Sep 2014 15:53:26 -0700 (PDT) In-Reply-To: <53A1CCCF.20804@isi.edu> References: <538E0FCE.8030905@isi.edu> <7940AE67-BB4B-4A06-A277-465940C469B3@cisco.com> <53A1CCCF.20804@isi.edu> Date: Tue, 30 Sep 2014 15:53:26 -0700 Message-ID: From: Gregory Lebovitz To: Joe Touch Content-Type: multipart/alternative; boundary=089e0160b7da58141d05045040fa Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/X0ZWCh37h6sZc3pBp38yVQ52ZCg Cc: "tcpm@ietf.org" , "Rohit M \(rrohit\)" , "Sujeet Nayak A \(sua\)" Subject: Re: [tcpm] SHA-2 auth draft on TCP-AO X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Sep 2014 22:54:43 -0000 --089e0160b7da58141d05045040fa Content-Type: text/plain; charset=UTF-8 Folks, I haven't been monitoring the -AO work for a few years now, but happened to be scanning and see this thread today. Pls excuse the late entry. Comments inline... On Wed, Jun 18, 2014 at 10:30 AM, Joe Touch wrote: > > > On 6/18/2014 9:12 AM, Brian Weis wrote: > >> Hi Joe, >> >> On Jun 18, 2014, at 5:04 AM, Sujeet Nayak A (sua) wrote: >> >> Hi Joe, >>> Thanks a lot of your quick and valuable comments: >>> >>> This doc should, AFAICT, update RFC 5926 >>>>> >>>> >> We're proposing updates to the IANA registries to add new >> algorithms,but it is not our goal to change the requirements language in >> RFC 5926. >> > > RFC 5926 indicates the security algs for TCP-AO; this doc proposes to > augment that list. Yes, that's captured by the IANA registry, but the way > RFC 5926 is written appears to indicate that additions to that registry > should UPDATE that RFC. If the WG or IESG sees otherwise, that's fine with > me. As its primary author/editor, and with the agreement of the TCPM WG and Security Directorate at the time, the goal of creating 5926 was that it would be the "short and sweet pluggable module" for crypto algos for 5925. This allowed any implementor of 5925 to have one and only one doc to read re: specified crypto algos AT ANY GIVEN POINT IN HISTORY. The idea was that when it was time to add another algo, like SHA2 (it was the one in mind at that time, in fact), or to deprecate an algo, all one would need to do is a (relatively painless) revision to 5926. I recommend we keep it that way, rather than take any short cuts that would result in spinning out additional RFC riders to 5925. All that needs to be done for a 5926bis is: 1) Add the new Auth Algo & Corresponding KDF to the tables in sect 2.2 2) Insert new KDF into the bullet list in sect 3.1.1 intro 3) insert new sect 3.1.1.x with the new KDF implementation details 4) insert new Auth Algo into bullet list in intro of sect 3.2 5) insert new sect 3.2.x with new Auth Algo implementation details 6) add any new Auth Algo / KDF security considerations to SCs section, if applicable 7) add new line to IANA table in sect 5 Pretty simple, really. If you'll provide the details above in an email to the list, I'd be happy to place them into the document and send out an update, adding the contributor (Rohit?) as an author. Let me know, Gregory > > > There isn't any compelling reason to change the existing algorithm >> requirements as both algorithms remain acceptable. We should clarify >> that the algorithm recommendations are really only relevant when this >> Internet-Draft is implemented. An implementation of TCP-AO still is >> required to comply with RFC 5926, but if it also implements this draft >> then it would need to pay attention to the algorithm recommendations in >> this draft. >> > > That's how all RFCs work, though. It would certainly be useful to be more > clear about the impact of this doc - i.e., that it adds additional optional > algorithms, rather than deprecating existing ones. > > Joe > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > -- ---- IETF related email from Gregory M. Lebovitz --089e0160b7da58141d05045040fa Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Folks,
I haven't been monitoring the -AO work for = a few years now, but happened to be scanning and see this thread today. Pls= excuse the late entry. Comments inline...
=
On Wed, Jun 18, 2014 at 10:30 AM, Joe Touch = <to= uch@isi.edu> wrote:


On 6/18/2014 9:12 AM, Brian Weis wrote:
Hi Joe,

On Jun 18, 2014, at 5:04 AM, Sujeet Nayak A (sua) <sua@cisco.com> wrote:

Hi Joe,
Thanks a lot of your quick and valuable comments:

This doc should, AFAICT, update RFC 5926

We're proposing updates to the IANA registries to add new
 algorithms,but it is not our goal to change the requirements language in RF= C 5926.

RFC 5926 indicates the security algs for TCP-AO; this doc proposes to augme= nt that list. Yes, that's captured by the IANA registry, but the way RF= C 5926 is written appears to indicate that additions to that registry shoul= d UPDATE that RFC. If the WG or IESG sees otherwise, that's fine with m= e.

As its primary author/editor, and with t= he agreement of the TCPM WG and Security Directorate at the time, the goal = of creating 5926 was that it would be the "short and sweet pluggable m= odule" for crypto algos for 5925. This allowed any implementor of 5925= to have one and only one doc to read re: specified crypto algos AT ANY GIV= EN POINT IN HISTORY. The idea was that when it was time to add another algo= , like SHA2 (it was the one in mind at that time, in fact), or to deprecate= an algo, all one would need to do is a (relatively painless) revision to 5= 926. I recommend we keep it that way, rather than take any short cuts that = would result in spinning out additional RFC riders to 5925.

<= /div>
All that needs to be done for a 5926bis is:
1) Add the = new Auth Algo & Corresponding KDF to the tables in sect 2.2
2= ) Insert new KDF into the bullet list in sect 3.1.1 intro
3) inse= rt new sect 3.1.1.x with the new KDF implementation details
4) in= sert new Auth Algo into bullet list in intro of sect 3.2
5) inser= t new sect 3.2.x with new Auth Algo implementation details
6) add= any new Auth Algo / KDF security considerations to SCs section, if applica= ble
7) add new line to IANA table in sect 5

<= div>Pretty simple, really.

If you'll provide t= he details above in an email to the list, I'd be happy to place them in= to the document and send out an update, adding the contributor (Rohit?) as = an author.

Let me know,

G= regory
=C2=A0


There isn't any compelling reason to change the existing algorithm
requirements as both algorithms remain acceptable. We should clarify
that the algorithm recommendations are really only relevant when this
Internet-Draft is implemented. An implementation of TCP-AO still is
required to comply with RFC 5926, but if it also implements this draft
then it would need to pay attention to the algorithm recommendations in
this draft.

 That's how all RFCs work, though. It would certainly be useful to be mo= re clear about the impact of this doc - i.e., that it adds additional optio= nal algorithms, rather than deprecating existing ones.

Joe


_______________________________________________
tcpm mailing list
tcpm@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/tcpm



--
= ----
IETF related email from
Gregory M. Lebovitz
--089e0160b7da58141d05045040fa-- From nobody Tue Sep 30 16:19:11 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B95011ACD19 for ; Tue, 30 Sep 2014 16:19:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.999 X-Spam-Level: X-Spam-Status: No, score=-101.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham 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 Gy-mLF6J81F4 for ; Tue, 30 Sep 2014 16:19:06 -0700 (PDT) Received: from mail-qc0-x231.google.com (mail-qc0-x231.google.com [IPv6:2607:f8b0:400d:c01::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E2BF51ACD18 for ; Tue, 30 Sep 2014 16:19:05 -0700 (PDT) Received: by mail-qc0-f177.google.com with SMTP id c9so9338qcz.36 for ; Tue, 30 Sep 2014 16:19:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=OiZ9rl+yZSx8tlEgmbIfhBCSADdpIeTdaPOfJHvIvIY=; b=DeUHE/TCP+fULL19bWfIBUzAcb8LqYaQrN1APDQ/43+PtQVe+qRgMW5qo3hhr7caM2 TmIqMkJbOSyYvE7pqicPuEYonOQOzmb+uWA3QNjHK9+idh1IcqXybs3ZF7Ocsy1E3miS DBfeyii4AygUJ9/nlMcXL8h3sErvtIK+rhavJQRfGZWS0At0SqzqHeNNUs1znVL/6TVB 9OquJq+MEEzCRh4WqjHgU/GirVr5L50uFYGic75PVoB67diZ3fQ3+IT/DIDkDaT4hdgi L2qw5QzDpxoSSvmIF8buUyaANnaWN1L7W4slMAFNJ2uKY1KRnpQm8wwZz/y1AK6swLXc bEsw== MIME-Version: 1.0 X-Received: by 10.224.11.132 with SMTP id t4mr17028749qat.98.1412119145136; Tue, 30 Sep 2014 16:19:05 -0700 (PDT) Received: by 10.140.81.166 with HTTP; Tue, 30 Sep 2014 16:19:05 -0700 (PDT) Date: Tue, 30 Sep 2014 16:19:05 -0700 Message-ID: From: Gregory Lebovitz To: Joe Touch Content-Type: multipart/alternative; boundary=001a11c2c20a06d1c90504509caa Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/DdEh5ZtiJ0iE8KVnZncPtCf1qbM Cc: "tcpm@ietf.org" Subject: [tcpm] TCP-AO crypto, SHA-2 MAC_Length (was: "Re: SHA-2 auth draft on TCP-AO") X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Sep 2014 23:19:08 -0000 --001a11c2c20a06d1c90504509caa Content-Type: text/plain; charset=UTF-8 On Fri, Jun 20, 2014 at 11:04 AM, Joe Touch wrote: > > > On 6/20/2014 9:11 AM, Brian Weis wrote: > >> Hi Joe, >> >> On Jun 18, 2014, at 11:53 AM, Joe Touch wrote: >> >> >>> >>> On 6/18/2014 11:46 AM, Brian Weis wrote: >>> >>>> Hi Joe & Brandon, >>>> >>>> On Jun 18, 2014, at 10:37 AM, Joe Touch wrote: >>>> >>>> >>>>> >>>>> On 6/18/2014 6:29 AM, Brandon Williams wrote: >>>>> >>>>>> Hi Sunjeet, >>>>>> >>>>>> The mac lengths of the algorithms specified here increase the option >>>>>> size, don't they? There is a detailed discussion of the option space >>>>>> tradeoffs for tcp-ao in rfc5925 section 7.6, which is based on the >>>>>> fact >>>>>> that all mac lengths would be 96 bits. An I.D. that increases the >>>>>> possible mac lengths should probably revisit that discussion. >>>>>> >>>>> >>>>> +1. >>>>> >>>>> I ought to be trivial to have this approach truncate the MAC, as other >>>>> algorithms do, and for the same reason. >>>>> >>>> >>>> The proposed methods do already truncate the output down to the >>>> minimum recommended by HMAC (RFC 2104), which is 1/2 the size of the MAC >>>> output. >>>> >>> >>> IMO if they cannot be truncated to 96 bits for this use then they >>> are not appropriate for TCP-AO. Using a longer HMAC directly in the >>> TCP-AO field would require this doc to UPDATE RFC 5925, as well as >>> addressing the comments already made on the impact of using the >>> additional space, and I don't think that's a good idea. >>> >> >> I understand the concerns of using too much option space. But can >> you point me to the requirements language requires a maximum of 96 >> bits for the MAC? Although that may have been your intent, I can find >> no such requirement in either RFC 5925 or RFC 5926. >> > > You're correct; TCP-AO allows MACs of (nearly) any length. We had a > discussion on the lengths specified for the specific algorithms in RFC > 5926, and came up with 96 bits. The key question here is "why should these > algorithms be different"? GML> 5296, 3.2 states: - MAC_Length: The final length of the bits used in the TCP-AO MAC field. This value may be a truncation of the MAC function's original output length. GML> and An important aspect to note about these algorithms' definitions for use in TCP-AO is the fact that the MAC outputs are truncated to 96 bits. AES-128-CMAC-96 produces a 128-bit MAC, and HMAC SHA-1 produces a 160-bit result. The MAC output is then truncated to 96 bits to provide a reasonable trade-off between security and message size, for fitting into the TCP-AO option field. GML> we clearly didn't say "MUST be 96 bits, no more", but the last sentence was meant to guide people toward a truncation of the MAC down to 96-bits in order to fit nicely into the -AO option field. There was security review and consensus that truncating a MAC output > 96 bits would be fine. GML> Further, we specifically used known and crypto-industry-vetted specifications for MACs with 96 bit output truncations, to ensure that there would be no crypto issues truncating either MAC down to 96 bits. GML> I haven't researched it, but is there a published NIST spec for HMAC-SHA-256-96. I know there is HMAC-SHA-256-128 in RFC 4868. Are there issues simply truncating further from 128 to 96? (Though I authored the doc, I'm not a cryptographer, so if this is a ridiculous statement to said community, pls forgive my ignorance :-) GML> NOTE: Regardless of the HMAC truncation, the variant PRF (e.g. PRF-HMAC-SHA256) would be un-truncated. GML> Gregory > > > Joe > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > -- ---- IETF related email from Gregory M. Lebovitz --001a11c2c20a06d1c90504509caa Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Fri, Jun 20, 2014 at 11:04 AM, Joe Touch &l= t;touch@isi.edu><= /span> wrote:


On 6/20/2014 9:11 AM, Brian Weis wrote:
Hi Joe,

On Jun 18, 2014, at 11:53 AM, Joe Touch <touch@isi.edu> wrote:



On 6/18/2014 11:46 AM, Brian Weis wrote:
Hi Joe & Brandon,

On Jun 18, 2014, at 10:37 AM, Joe Touch <touch@isi.edu> wrote:



On 6/18/2014 6:29 AM, Brandon Williams wrote:
Hi Sunjeet,

The mac lengths of the algorithms specified here increase the option
size, don't they? There is a detailed discussion of the option space tradeoffs for tcp-ao in rfc5925 section 7.6, which is based on the fact
that all mac lengths would be 96 bits. An I.D. that increases the
possible mac lengths should probably revisit that discussion.

+1.

I ought to be trivial to have this approach truncate the MAC, as other algo= rithms do, and for the same reason.

The proposed methods do already truncate the output down to the
minimum recommended by HMAC (RFC 2104), which is 1/2 the size of the MAC output.

IMO if they cannot be truncated to 96 bits for this use then they
are not appropriate for TCP-AO. Using a longer HMAC directly in the
TCP-AO field would require this doc to UPDATE RFC 5925, as well as
addressing the comments already made on the impact of using the
additional space, and I don't think that's a good idea.

I understand the concerns of using too much option space. But can
you point me to the requirements language requires a maximum of 96
bits for the MAC? Although that may have been your intent, I can find
no such requirement in either RFC 5925 or RFC 5926.

You're correct; TCP-AO allows MACs of (nearly) any length. We had a dis= cussion on the lengths specified for the specific algorithms in RFC 5926, a= nd came up with 96 bits. The key question here is "why should these al= gorithms be different"?

GML> 5296, = 3.2 states:

   - MAC_Length:  The f=
inal length of the bits used in the TCP-AO MAC
                  field.  This value may be a truncation of the MAC
                  function's original output length.
GM= L> and

An important aspect to no=
te about these algorithms' definitions for
   use in TCP-AO is the fact that the MAC outputs are truncated to 96
   bits.  AES-128-CMAC-96 produces a 128-bit MAC, and HMAC SHA-1
   produces a 160-bit result.  The MAC output is then truncated to 96
   bits to provide a reasonable trade-off between security and message
   size, for fitting into the TCP-AO option field.

GML> =C2=A0we clearly didn't say &qu= ot;MUST be 96 bits, no more", but the last sentence was meant to guide= people toward a truncation of the MAC down to 96-bits in order to fit nice= ly into the -AO option field. There was security review and consensus that = truncating a MAC output > 96 bits would be fine.

GML> =C2=A0Further, we specifically used known and crypto-industry-vet= ted specifications for MACs with 96 bit output truncations, to ensure that = there would be no crypto issues truncating either MAC down to 96 bits.

GML> I haven't researched it, but is there a pu= blished NIST spec for HMAC-SHA-256-96. I know there is HMAC-SHA-256-128 in = RFC 4868. Are there issues simply truncating further from 128 to 96? (Thoug= h I authored the doc, I'm not a cryptographer, so if this is a ridiculo= us statement to said community, pls forgive my ignorance :-)

=
GML> NOTE: Regardless of the HMAC truncation, the variant PRF= (e.g. PRF-HMAC-SHA256) would be un-truncated.

GML= > Gregory
=C2=A0


Joe


_______________________________________________
tcpm mailing list
tcpm@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/tcpm



--
= ----
IETF related email from
Gregory M. Lebovitz
--001a11c2c20a06d1c90504509caa-- From nobody Tue Sep 30 16:55:03 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F9201ACCE3 for ; Tue, 30 Sep 2014 16:55:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.986 X-Spam-Level: X-Spam-Status: No, score=-4.986 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786] autolearn=ham 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 S_R82O71Y4RJ for ; Tue, 30 Sep 2014 16:54:56 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BDE371ABD3F for ; Tue, 30 Sep 2014 16:54:56 -0700 (PDT) Received: from [192.168.1.10] (pool-71-103-148-36.lsanca.dsl-w.verizon.net [71.103.148.36]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id s8UNsVx5027052 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 30 Sep 2014 16:54:40 -0700 (PDT) Message-ID: <542B42B9.8070605@isi.edu> Date: Tue, 30 Sep 2014 16:54:33 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Gregory Lebovitz References: In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/9Q3wrFFbnoX7jagh6y00NiY2GGA Cc: "tcpm@ietf.org" Subject: Re: [tcpm] TCP-AO crypto, SHA-2 MAC_Length (was: "Re: SHA-2 auth draft on TCP-AO") X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Sep 2014 23:55:01 -0000 On 9/30/2014 4:19 PM, Gregory Lebovitz wrote: ... > GML> we clearly didn't say "MUST be 96 bits, no more", but the last > sentence was meant to guide people toward a truncation of the MAC down > to 96-bits in order to fit nicely into the -AO option field. The -AO option supports any MAC length. The issue is conservation of TCP header option space and its interaction with other TCP options. > There was > security review and consensus that truncating a MAC output > 96 bits > would be fine. "fine" was determined at the time by both Security and Transport, i.e., Security felt it was large enough for the desired protection and Transport felt it was small enough to "play nice" with other options. Joe