From nobody Fri May 2 04:18: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 C538C1A6F2A for ; Fri, 2 May 2014 04:18:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.002 X-Spam-Level: X-Spam-Status: No, score=-0.002 tagged_above=-999 required=5 tests=[BAYES_20=-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 koX_0BxpaY-m for ; Fri, 2 May 2014 04:18:47 -0700 (PDT) Received: from kirsi1.inet.fi (mta-out1.inet.fi [62.71.2.198]) by ietfa.amsl.com (Postfix) with ESMTP id 688121A084E for ; Fri, 2 May 2014 04:18:47 -0700 (PDT) Received: from pc112.netlab.hut.fi (130.233.154.112) by kirsi1.inet.fi (8.5.140.03) (authenticated as saropa-1) id 534D34B50145FBEE; Fri, 2 May 2014 14:18:32 +0300 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Pasi Sarolahti In-Reply-To: <2586_1398464386_535ADF82_2586_915_1_535ADF56.9050106@isi.edu> Date: Fri, 2 May 2014 14:18:29 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20140425221257.12559.43206.idtracker@ietfa.amsl.com> <2586_1398464386_535ADF82_2586_915_1_535ADF56.9050106@isi.edu> To: Joe Touch X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/dhSksze9ONoDnlKdw15sKwo9zTc Cc: "tcpm@ietf.org" Subject: Re: [tcpm] New Version Notification for draft-touch-tcpm-tcp-edo-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: Fri, 02 May 2014 11:18:48 -0000 On 26 Apr 2014, at 01:19, Joe Touch wrote: > I'd like to ask the chairs if we can consider a call to make this a WG = doc? >=20 > (given the work of the group is supposed to happen on the list - and I = don't attend meetings in person these days -this doesn't seem like it = needs to wait for a meeting to proceed) We should discuss the possible WG adoption on the list before the = meeting, and some people have already voiced their support. But there is = value in discussing this in the f2f meeting, too, before confirming WG = adoption (hum). Perhaps Wes can present this, or as the last resort the = presentation could be proxied by chairs. I don't see any reason to hurry = this so that we couldn't wait until the Toronto meeting. - Pasi From nobody Fri May 2 07:45:51 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 453BA1A08DE for ; Fri, 2 May 2014 07:45:49 -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, RCVD_IN_DNSWL_NONE=-0.0001] 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 xIVrMShoKiFL for ; Fri, 2 May 2014 07:45:47 -0700 (PDT) Received: from atl4mhob07.myregisteredsite.com (atl4mhob07.myregisteredsite.com [209.17.115.45]) by ietfa.amsl.com (Postfix) with ESMTP id A34D41A08DA for ; Fri, 2 May 2014 07:45:47 -0700 (PDT) Received: from mailpod.hostingplatform.com ([10.30.71.204]) by atl4mhob07.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id s42EjhmT025643 for ; Fri, 2 May 2014 10:45:43 -0400 Received: (qmail 16150 invoked by uid 0); 2 May 2014 14:45:43 -0000 X-TCPREMOTEIP: 107.47.36.237 X-Authenticated-UID: wes@mti-systems.com Received: from unknown (HELO ?192.168.43.65?) (wes@mti-systems.com@107.47.36.237) by 0 with ESMTPA; 2 May 2014 14:45:43 -0000 Message-ID: <5363AF84.8090701@mti-systems.com> Date: Fri, 02 May 2014 10:45:24 -0400 From: Wesley Eddy Organization: MTI Systems User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Pasi Sarolahti , Joe Touch References: <20140425221257.12559.43206.idtracker@ietfa.amsl.com> <2586_1398464386_535ADF82_2586_915_1_535ADF56.9050106@isi.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/JSbLc48Z8XUTnAETxoCoesrRyGY Cc: "tcpm@ietf.org" Subject: Re: [tcpm] New Version Notification for draft-touch-tcpm-tcp-edo-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: Fri, 02 May 2014 14:45:49 -0000 On 5/2/2014 7:18 AM, Pasi Sarolahti wrote: > > On 26 Apr 2014, at 01:19, Joe Touch wrote: > >> I'd like to ask the chairs if we can consider a call to make this a >> WG doc? >> >> (given the work of the group is supposed to happen on the list - >> and I don't attend meetings in person these days -this doesn't seem >> like it needs to wait for a meeting to proceed) > > We should discuss the possible WG adoption on the list before the > meeting, and some people have already voiced their support. But there > is value in discussing this in the f2f meeting, too, before > confirming WG adoption (hum). Perhaps Wes can present this, or as the > last resort the presentation could be proxied by chairs. I don't see > any reason to hurry this so that we couldn't wait until the Toronto > meeting. > That would be fine with me. IMO, it would be nice to know what the perceived mailing list consensus is, and use the meeting to confirm that. It's only a couple months away. I think Joe would agree that once adopted, this should be able to proceed relatively rapidly. -- Wes Eddy MTI Systems From nobody Fri May 2 08:03:33 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 3B81D1A0A0D for ; Fri, 2 May 2014 08:03:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] 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 ln9TxPaD-jr3 for ; Fri, 2 May 2014 08:03:31 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 118001A08DA for ; Fri, 2 May 2014 08:03:31 -0700 (PDT) Received: from [192.168.1.93] (pool-71-105-87-112.lsanca.dsl-w.verizon.net [71.105.87.112]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id s42F2j5h016777 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 2 May 2014 08:02:54 -0700 (PDT) Message-ID: <5363B397.8090009@isi.edu> Date: Fri, 02 May 2014 08:02:47 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Wesley Eddy , Pasi Sarolahti References: <20140425221257.12559.43206.idtracker@ietfa.amsl.com> <2586_1398464386_535ADF82_2586_915_1_535ADF56.9050106@isi.edu> <5363AF84.8090701@mti-systems.com> In-Reply-To: <5363AF84.8090701@mti-systems.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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/Mff9WAQ2gEDcmu2kX1N-fiI_iqo Cc: "tcpm@ietf.org" Subject: Re: [tcpm] New Version Notification for draft-touch-tcpm-tcp-edo-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: Fri, 02 May 2014 15:03:32 -0000 On 5/2/2014 7:45 AM, Wesley Eddy wrote: > On 5/2/2014 7:18 AM, Pasi Sarolahti wrote: >> >> On 26 Apr 2014, at 01:19, Joe Touch wrote: >> >>> I'd like to ask the chairs if we can consider a call to make this a >>> WG doc? >>> >>> (given the work of the group is supposed to happen on the list - >>> and I don't attend meetings in person these days -this doesn't seem >>> like it needs to wait for a meeting to proceed) >> >> We should discuss the possible WG adoption on the list before the >> meeting, and some people have already voiced their support. But there >> is value in discussing this in the f2f meeting, too, before >> confirming WG adoption (hum). Perhaps Wes can present this, or as the >> last resort the presentation could be proxied by chairs. I don't see >> any reason to hurry this so that we couldn't wait until the Toronto >> meeting. > > That would be fine with me. IMO, it would be nice to know what > the perceived mailing list consensus is, and use the meeting to > confirm that. It's only a couple months away. I'm not in a rush, but as a point of order: - work happens on the mailing list, NOT at the meetings - decisions at the meeting are confirmed on the list, not the other way around That's why I don't see why we need to wait for the meeting. Meetings are places where we typically hash out issues that arise on the list, e.g.: a. post to the list b. need for interactive clarification arises c. meeting supports interactive clarification d. decision happens back on the list Somewhere along the line this all got reversed. I would like to encourage the chairs to use case as an opportunity to try the intended process. Joe From nobody Fri May 2 08:27: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 CA60B1A7000 for ; Fri, 2 May 2014 08:27:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] 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 7slTQa788kZR for ; Fri, 2 May 2014 08:27:49 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 2190D1A6FF9 for ; Fri, 2 May 2014 08:27:49 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id 96F85C94A8; Fri, 2 May 2014 11:27:44 -0400 (EDT) Date: Fri, 2 May 2014 11:27:44 -0400 From: John Leslie To: Joe Touch Message-ID: <20140502152744.GK44329@verdi> References: <20140425221257.12559.43206.idtracker@ietfa.amsl.com> <2586_1398464386_535ADF82_2586_915_1_535ADF56.9050106@isi.edu> <5363AF84.8090701@mti-systems.com> <5363B397.8090009@isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5363B397.8090009@isi.edu> User-Agent: Mutt/1.4.1i Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/ulcZvSKmUFo-HCI1kaNsUAxXidE Cc: "tcpm@ietf.org" Subject: Re: [tcpm] New Version Notification for draft-touch-tcpm-tcp-edo-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: Fri, 02 May 2014 15:27:50 -0000 Joe Touch wrote: > > Meetings are places where we typically hash out issues that arise > on the list, e.g.: > a. post to the list > b. need for interactive clarification arises > c. meeting supports interactive clarification > d. decision happens back on the list > > Somewhere along the line this all got reversed. I would like to > encourage the chairs to use case as an opportunity to try the > intended process. +1 -- John Leslie From nobody Fri May 2 13:27: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 BC5CC1A6F38 for ; Fri, 2 May 2014 13:27:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.36 X-Spam-Level: * X-Spam-Status: No, score=1.36 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651, 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 DFQFJOpEJh4M for ; Fri, 2 May 2014 13:27:21 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (ns.sfc.wide.ad.jp [IPv6:2001:200:0:8803:203:178:142:143]) by ietfa.amsl.com (Postfix) with ESMTP id DE8081A0928 for ; Fri, 2 May 2014 13:27:20 -0700 (PDT) Received: from mail-lb0-f173.google.com (mail-lb0-f173.google.com [209.85.217.173]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id CD3F6278239 for ; Sat, 3 May 2014 05:27:16 +0900 (JST) Received: by mail-lb0-f173.google.com with SMTP id u14so1136795lbd.4 for ; Fri, 02 May 2014 13:27:14 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.112.235.229 with SMTP id up5mr77549lbc.62.1399062434070; Fri, 02 May 2014 13:27:14 -0700 (PDT) Received: by 10.114.95.101 with HTTP; Fri, 2 May 2014 13:27:14 -0700 (PDT) In-Reply-To: <5363B397.8090009@isi.edu> References: <20140425221257.12559.43206.idtracker@ietfa.amsl.com> <2586_1398464386_535ADF82_2586_915_1_535ADF56.9050106@isi.edu> <5363AF84.8090701@mti-systems.com> <5363B397.8090009@isi.edu> Date: Fri, 2 May 2014 13:27:14 -0700 Message-ID: From: Yoshifumi Nishida To: Joe Touch Content-Type: multipart/alternative; boundary=001a11c3d9d467452704f8709b68 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/vNNrGtrk8k6Z90Xc_nLIrcI_KsI Cc: "tcpm@ietf.org" Subject: Re: [tcpm] New Version Notification for draft-touch-tcpm-tcp-edo-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: Fri, 02 May 2014 20:27:22 -0000 --001a11c3d9d467452704f8709b68 Content-Type: text/plain; charset=UTF-8 Hi Joe, On Fri, May 2, 2014 at 8:02 AM, Joe Touch wrote: > > > On 5/2/2014 7:45 AM, Wesley Eddy wrote: > >> On 5/2/2014 7:18 AM, Pasi Sarolahti wrote: >> >>> >>> On 26 Apr 2014, at 01:19, Joe Touch wrote: >>> >>> I'd like to ask the chairs if we can consider a call to make this a >>>> WG doc? >>>> >>>> (given the work of the group is supposed to happen on the list - >>>> and I don't attend meetings in person these days -this doesn't seem >>>> like it needs to wait for a meeting to proceed) >>>> >>> >>> We should discuss the possible WG adoption on the list before the >>> meeting, and some people have already voiced their support. But there >>> is value in discussing this in the f2f meeting, too, before >>> confirming WG adoption (hum). Perhaps Wes can present this, or as the >>> last resort the presentation could be proxied by chairs. I don't see >>> any reason to hurry this so that we couldn't wait until the Toronto >>> meeting. >>> >> >> That would be fine with me. IMO, it would be nice to know what >> the perceived mailing list consensus is, and use the meeting to >> confirm that. It's only a couple months away. >> > > I'm not in a rush, but as a point of order: > > - work happens on the mailing list, NOT at the meetings > > - decisions at the meeting are confirmed on the list, > not the other way around > > That's why I don't see why we need to wait for the meeting. Meetings are > places where we typically hash out issues that arise on the list, e.g.: > a. post to the list > b. need for interactive clarification arises > c. meeting supports interactive clarification > d. decision happens back on the list > I personally would like to put a line between c. and d. like: c1. gauge consensus from both the list and the meetings I think having two ways to gauge consensus is good thing. -- Yoshi --001a11c3d9d467452704f8709b68 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Joe,

On Fri, May 2, 2014 at 8:02 AM, Joe Touch <touch@isi.edu>= wrote:


On 5/2/2014 7:45 AM, Wesley Eddy wrote:
On 5/2/2014 7:18 AM, Pasi Sarolahti wrote:

On 26 Apr 2014, at 01:19, Joe Touch <touch@ISI.EDU> wrote:

I'd like to ask the chairs if we can consider a call to make this a
WG doc?

(given the work of the group is supposed to happen on the list -
and I don't attend meetings in person these days -this doesn't seem=
like it needs to wait for a meeting to proceed)

We should discuss the possible WG adoption on the list before the
meeting, and some people have already voiced their support. But there
is value in discussing this in the f2f meeting, too, before
confirming WG adoption (hum). Perhaps Wes can present this, or as the
last resort the presentation could be proxied by chairs. I don't see any reason to hurry this so that we couldn't wait until the Toronto
meeting.

That would be fine with me. =C2=A0IMO, it would be nice to know what
the perceived mailing list consensus is, and use the meeting to
confirm that. =C2=A0It's only a couple months away.

I'm not in a rush, but as a point of order:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 - work happens on the mailing list, NOT at the = meetings

=C2=A0 =C2=A0 =C2=A0 =C2=A0 - decisions at the meeting are confirmed on the= list,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 not the other way around

That's why I don't see why we need to wait for the meeting. Meeting= s are places where we typically hash out issues that arise on the list, e.g= .:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 a. post to the list
=C2=A0 =C2=A0 =C2=A0 =C2=A0 b. need for interactive clarification arises =C2=A0 =C2=A0 =C2=A0 =C2=A0 c. meeting supports interactive clarification =C2=A0 =C2=A0 =C2=A0 =C2=A0 d. decision happens back on the list

I personally would like to put a line between c. = and d. like:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0c1. gauge c= onsensus from both the list and the meetings
I think having two ways to gauge consensus is good thing.
--=
Yoshi

--001a11c3d9d467452704f8709b68-- From nobody Fri May 2 13:34: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 E209B1A6FAE for ; Fri, 2 May 2014 13:34:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.85 X-Spam-Level: X-Spam-Status: No, score=-4.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] 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 1siVP44E7Jw2 for ; Fri, 2 May 2014 13:34:39 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 150591A6F38 for ; Fri, 2 May 2014 13:34:39 -0700 (PDT) Received: from [10.78.182.222] (mobile-198-228-210-217.mycingular.net [198.228.210.217]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id s42KXi1s011425 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 2 May 2014 13:33:54 -0700 (PDT) References: <20140425221257.12559.43206.idtracker@ietfa.amsl.com> <2586_1398464386_535ADF82_2586_915_1_535ADF56.9050106@isi.edu> <5363AF84.8090701@mti-systems.com> <5363B397.8090009@isi.edu> In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary=Apple-Mail-9C539E1E-8648-43FF-8C0B-32ACD8F11083 Message-Id: X-Mailer: iPhone Mail (11D201) From: Joe Touch Date: Fri, 2 May 2014 13:33:46 -0700 To: Yoshifumi Nishida 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/S2V38TRcnQJokIRQ4ZV0SqXnAAU Cc: "tcpm@ietf.org" Subject: Re: [tcpm] New Version Notification for draft-touch-tcpm-tcp-edo-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: Fri, 02 May 2014 20:34:41 -0000 --Apple-Mail-9C539E1E-8648-43FF-8C0B-32ACD8F11083 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable > On May 2, 2014, at 1:27 PM, Yoshifumi Nishida wro= te: >=20 > Hi Joe, >=20 >> On Fri, May 2, 2014 at 8:02 AM, Joe Touch wrote: >>=20 >>=20 >>> On 5/2/2014 7:45 AM, Wesley Eddy wrote: >>>> On 5/2/2014 7:18 AM, Pasi Sarolahti wrote: >>>>=20 >>>> On 26 Apr 2014, at 01:19, Joe Touch wrote: >>>>=20 >>>>> I'd like to ask the chairs if we can consider a call to make this a >>>>> WG doc? >>>>>=20 >>>>> (given the work of the group is supposed to happen on the list - >>>>> and I don't attend meetings in person these days -this doesn't seem >>>>> like it needs to wait for a meeting to proceed) >>>>=20 >>>> We should discuss the possible WG adoption on the list before the >>>> meeting, and some people have already voiced their support. But there >>>> is value in discussing this in the f2f meeting, too, before >>>> confirming WG adoption (hum). Perhaps Wes can present this, or as the >>>> last resort the presentation could be proxied by chairs. I don't see >>>> any reason to hurry this so that we couldn't wait until the Toronto >>>> meeting. >>>=20 >>> That would be fine with me. IMO, it would be nice to know what >>> the perceived mailing list consensus is, and use the meeting to >>> confirm that. It's only a couple months away. >>=20 >> I'm not in a rush, but as a point of order: >>=20 >> - work happens on the mailing list, NOT at the meetings >>=20 >> - decisions at the meeting are confirmed on the list, >> not the other way around >>=20 >> That's why I don't see why we need to wait for the meeting. Meetings are p= laces where we typically hash out issues that arise on the list, e.g.: >> a. post to the list >> b. need for interactive clarification arises >> c. meeting supports interactive clarification >> d. decision happens back on the list >=20 > I personally would like to put a line between c. and d. like: > c1. gauge consensus from both the list and the meetings > I think having two ways to gauge consensus is good thing. It's good but should not be required. Meeting attendance isn't required and= officially all IETF business is supposed to happen on the list. So holding u= p work to involve meetings should not ever happen IMO.=20 Joe > -- > Yoshi >=20 --Apple-Mail-9C539E1E-8648-43FF-8C0B-32ACD8F11083 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit


On May 2, 2014, at 1:27 PM, Yoshifumi Nishida <nishida@sfc.wide.ad.jp> wrote:

Hi Joe,

On Fri, May 2, 2014 at 8:02 AM, Joe Touch <touch@isi.edu> wrote:


On 5/2/2014 7:45 AM, Wesley Eddy wrote:
On 5/2/2014 7:18 AM, Pasi Sarolahti wrote:

On 26 Apr 2014, at 01:19, Joe Touch <touch@ISI.EDU> wrote:

I'd like to ask the chairs if we can consider a call to make this a
WG doc?

(given the work of the group is supposed to happen on the list -
and I don't attend meetings in person these days -this doesn't seem
like it needs to wait for a meeting to proceed)

We should discuss the possible WG adoption on the list before the
meeting, and some people have already voiced their support. But there
is value in discussing this in the f2f meeting, too, before
confirming WG adoption (hum). Perhaps Wes can present this, or as the
last resort the presentation could be proxied by chairs. I don't see
any reason to hurry this so that we couldn't wait until the Toronto
meeting.

That would be fine with me.  IMO, it would be nice to know what
the perceived mailing list consensus is, and use the meeting to
confirm that.  It's only a couple months away.

I'm not in a rush, but as a point of order:

        - work happens on the mailing list, NOT at the meetings

        - decisions at the meeting are confirmed on the list,
        not the other way around

That's why I don't see why we need to wait for the meeting. Meetings are places where we typically hash out issues that arise on the list, e.g.:
        a. post to the list
        b. need for interactive clarification arises
        c. meeting supports interactive clarification
        d. decision happens back on the list

I personally would like to put a line between c. and d. like:
           c1. gauge consensus from both the list and the meetings
I think having two ways to gauge consensus is good thing.

It's good but should not be required.  Meeting attendance isn't required and officially all IETF business is supposed to happen on the list. So holding up work to involve meetings should not ever happen IMO. 

Joe


--
Yoshi

--Apple-Mail-9C539E1E-8648-43FF-8C0B-32ACD8F11083-- From nobody Sat May 3 01:54: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 F3D811A0054 for ; Sat, 3 May 2014 01:54:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-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 ZN2A41ZTBRP9 for ; Sat, 3 May 2014 01:54:56 -0700 (PDT) Received: from hoemail1.alcatel.com (hoemail1.alcatel.com [192.160.6.148]) by ietfa.amsl.com (Postfix) with ESMTP id 905101A0053 for ; Sat, 3 May 2014 01:54:56 -0700 (PDT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (h135-239-2-122.lucent.com [135.239.2.122]) by hoemail1.alcatel.com (8.13.8/IER-o) with ESMTP id s438sqXx011736 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 3 May 2014 03:54:53 -0500 (CDT) Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id s438sp0c017080 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 3 May 2014 10:54:51 +0200 Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.94]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.02.0247.003; Sat, 3 May 2014 10:54:51 +0200 From: "Scharf, Michael (Michael)" To: Joe Touch Thread-Topic: [tcpm] New Version Notification for draft-touch-tcpm-tcp-edo-01.txt Thread-Index: AQHPZfhmeY9ISCS3G0i0FqD83czy1JstPNQAgAAE3ICAAFqmAIAAAdMAgADXt2A= Date: Sat, 3 May 2014 08:54:50 +0000 Message-ID: <655C07320163294895BBADA28372AF5D2CFE36@FR712WXCHMBA15.zeu.alcatel-lucent.com> References: <20140425221257.12559.43206.idtracker@ietfa.amsl.com> <2586_1398464386_535ADF82_2586_915_1_535ADF56.9050106@isi.edu> <5363AF84.8090701@mti-systems.com> <5363B397.8090009@isi.edu> 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: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/dnp-rFuCegxdT9wR82WJ2tfd9mc Cc: "tcpm@ietf.org" Subject: Re: [tcpm] New Version Notification for draft-touch-tcpm-tcp-edo-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: Sat, 03 May 2014 08:54:58 -0000 SGkgSm9lLA0KDQo+IEl0J3MgZ29vZCBidXQgc2hvdWxkIG5vdCBiZSByZXF1aXJlZC4gwqBNZWV0 aW5nIGF0dGVuZGFuY2UgaXNuJ3QgcmVxdWlyZWQgYW5kIG9mZmljaWFsbHkgYWxsIElFVEYgYnVz aW5lc3MgaXMgc3VwcG9zZWQgdG8gaGFwcGVuIG9uIHRoZSBsaXN0LiBTbyBob2xkaW5nIHVwIHdv cmsgdG8gaW52b2x2ZSBtZWV0aW5ncyBzaG91bGQgbm90IGV2ZXIgaGFwcGVuIElNTy7CoA0KDQpN ZWV0aW5nIGF0dGVuZGFuY2UgaXMgbm90IHJlcXVpcmVkLiBTdGlsbCwgSSBkb24ndCB1bmRlcnN0 YW5kIHdoeSBub3QgcnVubmluZyBhbiBhZG9wdGlvbiBjYWxsIGFib3V0IHR3byB3ZWVrcyBhZnRl ciBwb3N0aW5nIC0wMCByZWFsbHkgaG9sZHMgdXAgd29yay4NCg0KVENQTSBpcyBub3QgdGhlIG9u bHkgd29ya2luZyBncm91cCB0aGF0IGhhcyBhIGhpZ2ggYmFyIGZvciBhZG9wdGluZyBuZXcgd29y aywgYW5kIEkgdGhpbmsgYmVpbmcgY29uc2VydmF0aXZlIHJlZ2FyZGluZyBzdGQgdHJhY2sgVENQ IGNoYW5nZXMgaGFzIGFsd2F5cyBiZWVuIGEgY29tbXVuaXR5IGNvbnNlbnN1cyAoZS5nLiwgb3Vy IHByZXZpb3VzIGNoYXJ0ZXIgZXZlbiB0b2xkIHVzIHRoYXQgZXZlcnkgbmV3IFRDUE0gbWlsZXN0 b25lIHJlcXVpcmVzIElFU0cgYXBwcm92YWwgLSB0aGF0IHdhcyBjZXJ0YWlubHkgdG9vIGNvbnNl cnZhdGl2ZSkuIEFsc28sIGluIFRDUE0gcmV2aWV3IGN5Y2xlcyBhcmUgdW5mb3J0dW5hdGVseSBh IHJhdGhlciBzY2FyY2UgcmVzb3VyY2UsIGFuZCB0aGUgY2hhaXJzIGhhdmUgdG8gY29uc2lkZXIg dGhpcyBhcyB3ZWxsIHdoZW4gYWRvcHRpbmcgbmV3IHdvcmsuIEFsbCB0aGlzIGhhcyBub3RoaW5n IHRvIGRvIHdpdGggdGhpcyBkcmFmdCBzcGVjaWZpY2FsbHkuDQogDQpSZWdhcmRpbmcgZHJhZnQt dG91Y2gtdGNwbS10Y3AtZWRvLCBJIGFtIHBhcnRpY3VsYXJseSBpbnRlcmVzdGVkIGluIG1vcmUg ZmVlZGJhY2sgZnJvbSBpbXBsZW1lbnRlcnMgYW5kIHVzZXJzIGJlZm9yZSBzdGFydGluZyB0aGUg Zm9ybWFsIGFkb3B0aW9uIGNhbGwuIFdlIHVzdWFsbHkgZ2V0IHZlcnkgdmFsdWFibGUgZmVlZGJh Y2sgZnJvbSBpbXBsZW1lbnRlcnMgZHVyaW5nIG1lZXRpbmdzLCBhbmQgdGhhdCB3b3VsZCBiZSBv bmUgcmVhc29uIG5vdCB0byBydXNoIHJpZ2h0IG5vdyAtIGJ1dCBpdCBpcyB0aGUgZmVlZGJhY2sg SSBhbSBpbnRlcmVzdGVkIGluLCBub3QgdGhlIG1lZXRpbmcuIElmIGNvcnJlc3BvbmRpbmcgYXNw ZWN0cyBhcmUgZGlzY3Vzc2VkIG9uIHRoZSBsaXN0IGJlZm9yZSB0aGUgbmV4dCBtZWV0aW5nLCBJ J2xsIGJlIG1vcmUgdGhhbiBoYXBweSBhcyB3ZWxsLg0KDQpUaHVzLCBpbnN0ZWFkIG9mIGZ1cnRo ZXIgYXJndWluZyBhYm91dCBwcm9jZXNzIGFzcGVjdHMsIEkgYW0gbW9yZSBpbnRlcmVzdGVkIGlu IHRob3VnaHRzIG9uOg0KDQoqIEZyb20gZGVzaWduZXJzIG9mIFRDUCBleHRlbnNpb25zIHJlcXVp cmluZyBtb3JlIG9wdGlvbiBzcGFjZTogSXMgZHJhZnQtdG91Y2gtdGNwbS10Y3AtZWRvIGEgZ29v ZCBzb2x1dGlvbiBmb3IgeW91ciBuZWVkcyBhbmQgdGh1cyB0aGUgcmlnaHQgd2F5IHRvIG1vdmUg Zm9yd2FyZD8NCg0KKiBGcm9tIGltcGxlbWVudGVyczogQXJlIHRoZXJlIGRlcGxveW1lbnQgaXNz dWVzIGJleW9uZCB3aGF0IGlzIGRlc2NyaWJlZCBpbiB0aGUgZHJhZnQgYWxyZWFkeT8gQW5kLCB3 b3VsZCB0aGlzIG1lY2hhbmlzbSBiZSBpbXBsZW1lbnRlZCBpbiB0aGUgSW50ZXJuZXQ/IA0KDQpN aWNoYWVsDQo= From nobody Sat May 3 05:29: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 CE2701A0088 for ; Sat, 3 May 2014 05:29:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] 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 rNk9KVhzdx06 for ; Sat, 3 May 2014 05:29:55 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 494361A007D for ; Sat, 3 May 2014 05:29:55 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id 7507AC94A8; Sat, 3 May 2014 08:29:50 -0400 (EDT) Date: Sat, 3 May 2014 08:29:50 -0400 From: John Leslie To: "Scharf, Michael (Michael)" Message-ID: <20140503122950.GM44329@verdi> References: <20140425221257.12559.43206.idtracker@ietfa.amsl.com> <2586_1398464386_535ADF82_2586_915_1_535ADF56.9050106@isi.edu> <5363AF84.8090701@mti-systems.com> <5363B397.8090009@isi.edu> <655C07320163294895BBADA28372AF5D2CFE36@FR712WXCHMBA15.zeu.alcatel-lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <655C07320163294895BBADA28372AF5D2CFE36@FR712WXCHMBA15.zeu.alcatel-lucent.com> User-Agent: Mutt/1.4.1i Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/V14ZoN3DMSzrQvfgjVQucncY4B8 Cc: Martin Stiemerling , tcpm@ietf.org Subject: Re: [tcpm] New Version Notification for draft-touch-tcpm-tcp-edo-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: Sat, 03 May 2014 12:29:58 -0000 Scharf, Michael (Michael) wrote: > > Meeting attendance is not required. Still, I don't understand why not > running an adoption call about two weeks after posting -00 really > holds up work. (I don't understand how you're measuring "two weeks".) To me, it's more a question of how putting this question off until the rush of IETF week can possibly help. We need to determine whether this work can get traction it TCPM; and we need to get IETF support for doing this work in TCPM -- whose charter, lest we forget, is quite clear about us doing "small" TCP changes. > TCPM is not the only working group that has a high bar for adopting > new work, A 30-second hum after a ten-minute presentation isn't my idea of what "a high bar" should mean. > and I think being conservative regarding std track TCP changes has > always been a community consensus (e.g., our previous charter even > told us that every new TCPM milestone requires IESG approval - > that was certainly too conservative). The IESG today doesn't require "milestone" changes to come before a formal telechat; but I can imagine some concern about whether this particular change (invalidating the "Data offset" field) fits within our charter or requires a change to the charter wording. I'd much prefer that such a question not be squeezed into the IETF week rush. > Also, in TCPM review cycles are unfortunately a rather scarce resource, > and the chairs have to consider this as well when adopting new work. Absolutely: new work should not be started without commitments for enough review cycles! > Regarding draft-touch-tcpm-tcp-edo, I am particularly interested in > more feedback from implementers and users before starting the formal > adoption call. Ah, but _what_ feedback? Commitment to review, certainly. Do you need data on how crowded the option space is? Do you need security considerations? Does that include what happens as the IP-layer path changes to include more or less middleboxes? Do you need analysis of how this sort of change interacts with MPTCP? Do you need analysis of which middleboxes can't be modified to recognize this proposed option? Please be specific. > We usually get very valuable feedback from implementers during > meetings, and that would be one reason not to rush right now - I really don't follow why adoption as a Working Group Draft would get in the way of considering such feedback. > but it is the feedback I am interested in, not the meeting. If > corresponding aspects are discussed on the list before the next > meeting, I'll be more than happy as well. Fair enough! > Thus, instead of further arguing about process aspects, I am more > interested in thoughts on: > > * From designers of TCP extensions requiring more option space: Is > draft-touch-tcpm-tcp-edo a good solution for your needs and thus > the right way to move forward? We're desperate! We'll get behind anything! > * From implementers: Are there deployment issues beyond what is > described in the draft already? Good lord, yes! (That deserves a separate thread -- but again, surely that can be discussed for a WG Draft as easily as for an individual draft, can't it?) > And, would this mechanism be implemented in the Internet? I'd be astounded if it wouldn't be implemented in Linux! What beyond that do you need? -- John Leslie From nobody Sat May 3 12:52:06 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 85DC71A011B for ; Sat, 3 May 2014 12:52:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 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_MED=-2.3, 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 GTG1sBd75QQv for ; Sat, 3 May 2014 12:52:03 -0700 (PDT) Received: from smtp6.sgsi.ucl.ac.be (smtp.sgsi.ucl.ac.be [130.104.5.67]) by ietfa.amsl.com (Postfix) with ESMTP id 3B4B01A0110 for ; Sat, 3 May 2014 12:52:02 -0700 (PDT) Received: from mbpobo.local (host-212-68-230-69.brutele.be [212.68.230.69]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: obonaventure@smtp6.sgsi.ucl.ac.be) by smtp6.sgsi.ucl.ac.be (Postfix) with ESMTPSA id 15F1E1833E4; Sat, 3 May 2014 21:51:52 +0200 (CEST) X-DKIM: Sendmail DKIM Filter v2.8.3 smtp6.sgsi.ucl.ac.be 15F1E1833E4 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1399146712; bh=93IDkXQ4CzNxiVV16yEJJH2FQatmeAD0cB3iWs+Dzpc=; h=Message-ID:Date:From:Reply-To:MIME-Version:To:CC:Subject: References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=wsFLojJJulUiPz5qAkUHKFKvkTIKdHXCyFV4kmPMRm9cy+VcMZl4mrdvG7ad9bFJ5 uvA/4GKTmOBPNPdwucnpd7LO4UOOZ+1FevqdH4IDePY6d+O//5bavF812m/H7Lw2I/ 0IESLp2J/hQ2Td/9PXOad9VVOwRL8frfjKgVb7qM= Message-ID: <536548D7.5030802@uclouvain.be> Date: Sat, 03 May 2014 21:51:51 +0200 From: Olivier Bonaventure User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: "Scharf, Michael (Michael)" , Joe Touch References: <20140425221257.12559.43206.idtracker@ietfa.amsl.com> <2586_1398464386_535ADF82_2586_915_1_535ADF56.9050106@isi.edu> <5363AF84.8090701@mti-systems.com> <5363B397.8090009@isi.edu> <655C07320163294895BBADA28372AF5D2CFE36@FR712WXCHMBA15.zeu.alcatel-lucent.com> In-Reply-To: <655C07320163294895BBADA28372AF5D2CFE36@FR712WXCHMBA15.zeu.alcatel-lucent.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.97.7-exp at smtp-6.sipr-dc.ucl.ac.be X-Virus-Status: Clean X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-MailScanner-ID: 15F1E1833E4.A6D26 X-SGSI-MailScanner: Found to be clean X-SGSI-From: olivier.bonaventure@uclouvain.be X-SGSI-Spam-Status: No Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/AVSzKZetmCXkSVLvCTrwE2uhGuw Cc: "tcpm@ietf.org" Subject: Re: [tcpm] New Version Notification for draft-touch-tcpm-tcp-edo-01.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Olivier.Bonaventure@uclouvain.be List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 May 2014 19:52:05 -0000 Michael, > Thus, instead of further arguing about process aspects, I am more interested in thoughts on: > > * From designers of TCP extensions requiring more option space: Is draft-touch-tcpm-tcp-edo a good solution for your needs and thus the right way to move forward? > > * From implementers: Are there deployment issues beyond what is described in the draft already? And, would this mechanism be implemented in the Internet? My main concern with this draft are the possible interactions with segment splitting/coalescing middleboxes. The draft considers that these middleboxes are rare and should not constitute a problem. Unfortunately, I have to disagree with this statement. An important concern are the recent NICs that support TSO or GRO. These NICs are very widely used today and there are environments where it is very difficult for a TCP stack to determine whether it runs with such a NIC a not. A typical case is a virtual machine running on a host that exposes a driver that does not correspond to the physical NIC that is actually used. The EDO option proposed in this draft does not unfortunately work correctly through a middlebox that splits segments. Concerning the following example. A host that has negotiated EDO during the three way handshake sends a segment that contains : - TCP header indicates 4 bytes of option, followed by EDO option indicating an option of 100 bytes, 100 bytes of option (e.g. a very long SACK), 1000 bytes of data The middlebox does not understand the EDO option but needs to split the segment. Some middleboxes will copy all options in the two segments. This results in : segment 1 : TCP header indicates 4 bytes of option, followed by EDO option indicating an option of 100 bytes, 100 bytes of option (e.g. a very long SACK), 500 bytes of data segment 2 : TCP header indicates 4 bytes of option, followed by EDO option indicating an option of 100 bytes, 500 bytes of data The receiver will try to parse 100 bytes of option in the second segment... In their IMC paper entitled "Is it Still Possible to Extend TCP?", Michio Honda et al. provide the following recommendation http://conferences.sigcomm.org/imc/2011/docs/p181.pdf "All the NICs we tested correctly copied the options to all the split segments. TSO is now sufficiently commonplace so that designers of extensions to TCP should assume it. The implication is that TCP options must be designed so that when they are duplicated on consecutive segments, this does not adversely affect correctness or performance." EDO should be modified to take this recommendation into account to be deployable in today's Internet. One possibility could be to include a checksum inside the EDO option. +--------+--------+--------+--------+----------+----------+ | Kind | Length | Header_length | Checksum | +--------+--------+--------+--------+----------+----------+ The checksum should be computed over the entire extended option by the sender. When a receiver receives a segment with the EDO option, it MUST verify the EDO checksum. If the checksum is correct, then the extended option can be parsed. Otherwise, the entire segment should be silently dropped. The checksum could solve the problem mentionned above with the NIC that segment data, but additional work is required to check whether such modification would solve all possible problems with middleboxes. With Multipath TCP, we managed to extend TCP while preserving connectivity. Multipath TCP can cope with various types of middleboxes but not all possible behaviours. For some of these behaviours, Multipath TCP fallsback to regular TCP to ensure that the application continues to operate without any loss of connectivity. The EDO option should also have this goal in mind. Best regards, Olivier -- INL, ICTEAM, UCLouvain, Belgium, http://inl.info.ucl.ac.be From nobody Sun May 4 02:54:37 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 121121A011F for ; Sun, 4 May 2014 02:54:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-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 uHneyNwiEn7f for ; Sun, 4 May 2014 02:54:33 -0700 (PDT) Received: from hoemail1.alcatel.com (hoemail1.alcatel.com [192.160.6.148]) by ietfa.amsl.com (Postfix) with ESMTP id 094311A005B for ; Sun, 4 May 2014 02:54:32 -0700 (PDT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (h135-239-2-122.lucent.com [135.239.2.122]) by hoemail1.alcatel.com (8.13.8/IER-o) with ESMTP id s449sP3j014075 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 4 May 2014 04:54:26 -0500 (CDT) Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id s449sNRl023827 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 4 May 2014 11:54:24 +0200 Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.94]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.02.0247.003; Sun, 4 May 2014 11:54:23 +0200 From: "Scharf, Michael (Michael)" To: John Leslie Thread-Topic: [tcpm] New Version Notification for draft-touch-tcpm-tcp-edo-01.txt Thread-Index: AQHPZfhmeY9ISCS3G0i0FqD83czy1JstPNQAgAAE3ICAAFqmAIAAAdMAgADXt2CAADNpAIABfGjy Date: Sun, 4 May 2014 09:54:23 +0000 Message-ID: <655C07320163294895BBADA28372AF5D2D009E@FR712WXCHMBA15.zeu.alcatel-lucent.com> References: <20140425221257.12559.43206.idtracker@ietfa.amsl.com> <2586_1398464386_535ADF82_2586_915_1_535ADF56.9050106@isi.edu> <5363AF84.8090701@mti-systems.com> <5363B397.8090009@isi.edu> <655C07320163294895BBADA28372AF5D2CFE36@FR712WXCHMBA15.zeu.alcatel-lucent.com>, <20140503122950.GM44329@verdi> In-Reply-To: <20140503122950.GM44329@verdi> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [155.132.188.47] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/2zZHQM5BrquQl3_VOECinxkpse4 Cc: Martin Stiemerling , "tcpm@ietf.org" Subject: Re: [tcpm] New Version Notification for draft-touch-tcpm-tcp-edo-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: Sun, 04 May 2014 09:54:35 -0000 John,=0A= =0A= I am convinced that TCPM is the right place to discuss draft-touch-tcpm-tcp= -edo. If we have strong support and commitments regarding the technical app= roach, we'll sort out the question whether we need a charter update or not.= =0A= =0A= Regarding implementer and user feedback, I'd really be interested in a stud= y like the IMC 2011 paper (or a verification that those insights still appl= y). I might be wrong, but my assumption is that due to deployments of MPTCP= , fast open, etc. it may perhaps become simpler to deploy new TCP extension= s in parts of the Internet. That would be important to know.=0A= =0A= But this kind of work may require help from the TCPM community, and it will= require time to complete. For instance, just as a thought from an individu= al community member, the outcome of such a study could become an informatio= nal companion document like RFC 2416, RFC 2884, etc.=0A= =0A= Michael=0A= =0A= =0A= ________________________________________=0A= Von: John Leslie [john@jlc.net]=0A= Gesendet: Samstag, 3. Mai 2014 14:29=0A= An: Scharf, Michael (Michael)=0A= Cc: Martin Stiemerling; tcpm@ietf.org=0A= Betreff: Re: [tcpm] New Version Notification for draft-touch-tcpm-tcp-edo-0= 1.txt=0A= =0A= Scharf, Michael (Michael) wrote:=0A= >=0A= > Meeting attendance is not required. Still, I don't understand why not=0A= > running an adoption call about two weeks after posting -00 really=0A= > holds up work.=0A= =0A= (I don't understand how you're measuring "two weeks".)=0A= =0A= To me, it's more a question of how putting this question off until=0A= the rush of IETF week can possibly help.=0A= =0A= We need to determine whether this work can get traction it TCPM; and=0A= we need to get IETF support for doing this work in TCPM -- whose charter,= =0A= lest we forget, is quite clear about us doing "small" TCP changes.=0A= =0A= > TCPM is not the only working group that has a high bar for adopting=0A= > new work,=0A= =0A= A 30-second hum after a ten-minute presentation isn't my idea of=0A= what "a high bar" should mean.=0A= =0A= > and I think being conservative regarding std track TCP changes has=0A= > always been a community consensus (e.g., our previous charter even=0A= > told us that every new TCPM milestone requires IESG approval -=0A= > that was certainly too conservative).=0A= =0A= The IESG today doesn't require "milestone" changes to come before=0A= a formal telechat; but I can imagine some concern about whether this=0A= particular change (invalidating the "Data offset" field) fits within=0A= our charter or requires a change to the charter wording. I'd much=0A= prefer that such a question not be squeezed into the IETF week rush.=0A= =0A= > Also, in TCPM review cycles are unfortunately a rather scarce resource,= =0A= > and the chairs have to consider this as well when adopting new work.=0A= =0A= Absolutely: new work should not be started without commitments for=0A= enough review cycles!=0A= =0A= > Regarding draft-touch-tcpm-tcp-edo, I am particularly interested in=0A= > more feedback from implementers and users before starting the formal=0A= > adoption call.=0A= =0A= Ah, but _what_ feedback?=0A= =0A= Commitment to review, certainly.=0A= =0A= Do you need data on how crowded the option space is?=0A= =0A= Do you need security considerations? Does that include what happens=0A= as the IP-layer path changes to include more or less middleboxes?=0A= =0A= Do you need analysis of how this sort of change interacts with=0A= MPTCP?=0A= =0A= Do you need analysis of which middleboxes can't be modified to=0A= recognize this proposed option?=0A= =0A= Please be specific.=0A= =0A= > We usually get very valuable feedback from implementers during=0A= > meetings, and that would be one reason not to rush right now -=0A= =0A= I really don't follow why adoption as a Working Group Draft would=0A= get in the way of considering such feedback.=0A= =0A= > but it is the feedback I am interested in, not the meeting. If=0A= > corresponding aspects are discussed on the list before the next=0A= > meeting, I'll be more than happy as well.=0A= =0A= Fair enough!=0A= =0A= > Thus, instead of further arguing about process aspects, I am more=0A= > interested in thoughts on:=0A= >=0A= > * From designers of TCP extensions requiring more option space: Is=0A= > draft-touch-tcpm-tcp-edo a good solution for your needs and thus=0A= > the right way to move forward?=0A= =0A= We're desperate! We'll get behind anything!=0A= =0A= > * From implementers: Are there deployment issues beyond what is=0A= > described in the draft already?=0A= =0A= Good lord, yes! (That deserves a separate thread -- but again,=0A= surely that can be discussed for a WG Draft as easily as for an=0A= individual draft, can't it?)=0A= =0A= > And, would this mechanism be implemented in the Internet?=0A= =0A= I'd be astounded if it wouldn't be implemented in Linux!=0A= =0A= What beyond that do you need?=0A= =0A= --=0A= John Leslie =0A= From nobody Mon May 5 00:49:29 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 343AD1A0275 for ; Mon, 5 May 2014 00:49:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] 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 1D0oHA79ABRy for ; Mon, 5 May 2014 00:49:24 -0700 (PDT) Received: from bells2.cs.ucl.ac.uk (bells2.cs.ucl.ac.uk [128.16.5.33]) by ietfa.amsl.com (Postfix) with ESMTP id 77C5E1A027A for ; Mon, 5 May 2014 00:49:24 -0700 (PDT) Received: from [141.85.37.157] (helo=[10.0.0.106]) by bells2.cs.ucl.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (C.Raiciu authenticated) (Exim 4.54) id 1WhDe9-0004ws-7Q; Mon, 05 May 2014 08:49:09 +0100 Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Costin Raiciu In-Reply-To: <536548D7.5030802@uclouvain.be> Date: Mon, 5 May 2014 10:49:05 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <68C69A33-3733-48FB-AED6-E1DBC121C5B7@cs.ucl.ac.uk> References: <20140425221257.12559.43206.idtracker@ietfa.amsl.com> <2586_1398464386_535ADF82_2586_915_1_535ADF56.9050106@isi.edu> <5363AF84.8090701@mti-systems.com> <5363B397.8090009@isi.edu> <655C07320163294895BBADA28372AF5D2CFE36@FR712WXCHMBA15.zeu.alcatel-lucent.com> <536548D7.5030802@uclouvain.be> To: Olivier.Bonaventure@uclouvain.be X-Mailer: Apple Mail (2.1085) Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/EbwjMciLyVxJwRUeujridxt764o Cc: "tcpm@ietf.org" , Joe Touch Subject: Re: [tcpm] New Version Notification for draft-touch-tcpm-tcp-edo-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, 05 May 2014 07:49:27 -0000 I'd like to add to what Olivier has said. One question I had about this draft is whether the options included in = the EDO are supposed to be carrying sequence numbers or not. Two = options: 1. they carry sequence numbers: in this case we are changing the = semantics of options in TCP, sending them reliably, orderly and subject = to flow control. Which may be just fine for most types of options, but = its not conforming to the spec and I suspect it opens a can of worms = when we consider retransmissions of old options etc. For instance, if = one would send MPTCP's Data ACKs in EDO reliably and subject to flow = control we can end up with deadlocks. 2. they don't carry sequence numbers. In this case, a box that does not = know EDO and looks at packets it will see more data sent sent the = combination of sequence number / length allows. Many boxes will just = drop the extra bytes, others may reset the connection. Based on our IMC = 11 experience, I expect that at least 1/3 of access networks (e.g. DSL / = Cellular / Hotspot / etc) will break EDO. So this option is a no go, in = my opinion. Another thing: the draft says that NAT will work with EDO. However, most = NATs have a passive FTP mode - which means they will look through the = TCP payload for the host's IP address and rewrite with their own.=20 With EDO, the NAT could be messing up options placed in EDO space in the = payload. To avoid this you need a checksum, as Olivier says.=20 I suspect that the solution has to be something in the direction of (1), = where the EDO space is quoted explicitly (have an SACK like options = that says bytes XX-YY from the payload carry in fact options). On top = of that, we need a review of what options can be sent over EDO and what = options cannot be sent over it. It's not going to be easy, in my = opinion. Cheers. Costin =20 On 3 May 2014, at 22:51, Olivier Bonaventure wrote: > Michael, >=20 >=20 >> Thus, instead of further arguing about process aspects, I am more = interested in thoughts on: >>=20 >> * =46rom designers of TCP extensions requiring more option space: Is = draft-touch-tcpm-tcp-edo a good solution for your needs and thus the = right way to move forward? >>=20 >> * =46rom implementers: Are there deployment issues beyond what is = described in the draft already? And, would this mechanism be implemented = in the Internet? >=20 > My main concern with this draft are the possible interactions with = segment splitting/coalescing middleboxes. >=20 > The draft considers that these middleboxes are rare and should not = constitute a problem. Unfortunately, I have to disagree with this = statement. An important concern are the recent NICs that support TSO or = GRO. These NICs are very widely used today and there are environments = where it is very difficult for a TCP stack to determine whether it runs = with such a NIC a not. A typical case is a virtual machine running on a = host that exposes a driver that does not correspond to the physical NIC = that is actually used. >=20 > The EDO option proposed in this draft does not unfortunately work = correctly through a middlebox that splits segments. Concerning the = following example. >=20 > A host that has negotiated EDO during the three way handshake sends a = segment that contains : > - TCP header indicates 4 bytes of option, followed by EDO option = indicating an option of 100 bytes, 100 bytes of option (e.g. a very long = SACK), 1000 bytes of data >=20 > The middlebox does not understand the EDO option but needs to split = the segment. Some middleboxes will copy all options in the two segments. = This results in : >=20 > segment 1 : TCP header indicates 4 bytes of option, followed by EDO = option indicating an option of 100 bytes, 100 bytes of option (e.g. a = very long SACK), 500 bytes of data >=20 > segment 2 : TCP header indicates 4 bytes of option, followed by EDO = option indicating an option of 100 bytes, 500 bytes of data >=20 > The receiver will try to parse 100 bytes of option in the second = segment... >=20 > In their IMC paper entitled "Is it Still Possible to Extend TCP?", = Michio Honda et al. provide the following recommendation > http://conferences.sigcomm.org/imc/2011/docs/p181.pdf >=20 > "All the NICs we tested correctly copied the options to all the split = segments. TSO is now sufficiently commonplace so that designers of = extensions to TCP should assume it. The implication is that TCP options = must be designed so that when they are duplicated on consecutive = segments, this does not adversely affect correctness or performance." >=20 > EDO should be modified to take this recommendation into account to be = deployable in today's Internet. >=20 > One possibility could be to include a checksum inside the EDO option. >=20 >=20 > +--------+--------+--------+--------+----------+----------+ > | Kind | Length | Header_length | Checksum | > +--------+--------+--------+--------+----------+----------+ >=20 > The checksum should be computed over the entire extended option by the = sender. When a receiver receives a segment with the EDO option, it MUST = verify the EDO checksum. If the checksum is correct, then the extended = option can be parsed. Otherwise, the entire segment should be silently = dropped. >=20 > The checksum could solve the problem mentionned above with the NIC = that segment data, but additional work is required to check whether such = modification would solve all possible problems with middleboxes. >=20 > With Multipath TCP, we managed to extend TCP while preserving = connectivity. Multipath TCP can cope with various types of middleboxes = but not all possible behaviours. For some of these behaviours, Multipath = TCP fallsback to regular TCP to ensure that the application continues to = operate without any loss of connectivity. The EDO option should also = have this goal in mind. >=20 > Best regards, >=20 >=20 > Olivier >=20 >=20 > --=20 > INL, ICTEAM, UCLouvain, Belgium, http://inl.info.ucl.ac.be >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Mon May 5 07:16:05 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 7DF911A034A for ; Mon, 5 May 2014 07:16:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] 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 03ZBDwQ2RCAS for ; Mon, 5 May 2014 07:16:02 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 743F81A0359 for ; Mon, 5 May 2014 07:16:01 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id F2A2CC94BD; Mon, 5 May 2014 10:15:55 -0400 (EDT) Date: Mon, 5 May 2014 10:15:55 -0400 From: John Leslie To: "Scharf, Michael (Michael)" Message-ID: <20140505141555.GP44329@verdi> References: <20140425221257.12559.43206.idtracker@ietfa.amsl.com> <2586_1398464386_535ADF82_2586_915_1_535ADF56.9050106@isi.edu> <5363AF84.8090701@mti-systems.com> <5363B397.8090009@isi.edu> <655C07320163294895BBADA28372AF5D2D009E@FR712WXCHMBA15.zeu.alcatel-lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <655C07320163294895BBADA28372AF5D2D009E@FR712WXCHMBA15.zeu.alcatel-lucent.com> User-Agent: Mutt/1.4.1i Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/rKh7R-Nhji307VT8z3mtOJuDTHo Cc: "tcpm@ietf.org" Subject: Re: [tcpm] New Version Notification for draft-touch-tcpm-tcp-edo-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, 05 May 2014 14:16:04 -0000 Scharf, Michael (Michael) wrote: > > I am convinced that TCPM is the right place to discuss > draft-touch-tcpm-tcp-edo. If we have strong support and commitments > regarding the technical approach, we'll sort out the question whether > we need a charter update or not. :^) > Regarding implementer and user feedback, I'd really be interested > in a study like the IMC 2011 paper I assume you mean "Is it still possible to extend TCP?" http://conferences.sigcomm.org/imc/2011/docs/p181.pdf > (or a verification that those insights still apply). This paper reported research on 135 paths using 3 port numbers: HTTP, HTTPS, and "middle-of-nowhere", and showed at best 96% passage of unknown options. It discussed the operation of middleboxes (including HTTP proxies), and concluded that MPTCP could detect damage and fallback, TcpCrypt is fragile (and can't fallback after being enabled), and TCP Extended Options (draft-eddy-tcp-loo) was unsafe. I take it on faith that those insights are still valid. > I might be wrong, but my assumption is that due to deployments of > MPTCP, fast open, etc. it may perhaps become simpler to deploy new > TCP extensions in parts of the Internet. That would be important > to know. I think it is a given that deployment will depend upon successful negotiation end-to-end. Given the (still-growing!) extent of middlebox damage, I suggest it will also be necessary to detect middlebox damage throughout the life of the connection. Nonetheless, I see large portions of the Internet where expanding the TCP Options field could function today. I predict that offending middleboxes will be replaced over time (perhaps five years). So long as on offending middlebox can be identified and folks understand the damage it causes, replacing them need not be expensive. > But this kind of work may require help from the TCPM community, > and it will require time to complete. For instance, just as a thought > from an individual community member, the outcome of such a study > could become an informational companion document like RFC 2416, > RFC 2884, etc. Repeating the IMC-2011/p181 study sounds more like an IRTF task; but I certainly agree it would be worthwhile. ==== I do expect a standardized EDO to be more complex than tcp-loo; but there are a number of approaches which are (IMHO) sufficiently safe. I believe touch-tcpm-tcp-edo to be a better starting point than eddy-tcp-loo was; but it will need significant work before submitting to the IESG. -- John Leslie From nobody Mon May 5 07:41: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 791791A00B3 for ; Mon, 5 May 2014 07:41:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] 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 z3wgTIJrD8RM for ; Mon, 5 May 2014 07:41:14 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 623E61A00A5 for ; Mon, 5 May 2014 07:41:14 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id 6AF6FC94A9; Mon, 5 May 2014 10:41:09 -0400 (EDT) Date: Mon, 5 May 2014 10:41:09 -0400 From: John Leslie To: Costin Raiciu Message-ID: <20140505144109.GQ44329@verdi> References: <20140425221257.12559.43206.idtracker@ietfa.amsl.com> <2586_1398464386_535ADF82_2586_915_1_535ADF56.9050106@isi.edu> <5363AF84.8090701@mti-systems.com> <5363B397.8090009@isi.edu> <655C07320163294895BBADA28372AF5D2CFE36@FR712WXCHMBA15.zeu.alcatel-lucent.com> <536548D7.5030802@uclouvain.be> <68C69A33-3733-48FB-AED6-E1DBC121C5B7@cs.ucl.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <68C69A33-3733-48FB-AED6-E1DBC121C5B7@cs.ucl.ac.uk> User-Agent: Mutt/1.4.1i Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/N-Wzn77zhG_PqbqC6wvVzJdEDzM Cc: "tcpm@ietf.org" , Joe Touch Subject: Re: [tcpm] New Version Notification for draft-touch-tcpm-tcp-edo-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, 05 May 2014 14:41:16 -0000 Costin Raiciu wrote: > > One question I had about this draft is whether the options included > in the EDO are supposed to be carrying sequence numbers... That's probably a bad idea: while we can depend upon the endpoints to negotiate a common understanding or visibly fail, the same is not true of middleboxes. A middlebox _can_ cause negotiation to fail, but it has no way to signal exactly how it _does_ interpret an option. > 1. they carry sequence numbers: in this case we are changing the > semantics of options in TCP... I suspect it opens a can of worms... Agreed. > 2. they don't carry sequence numbers. In this case, a box that does not > know EDO and looks at packets it will see more data sent sent... > Many boxes will just drop the extra bytes... Which would be a disaster. > So this option is a no go, in my opinion. I don't agree that adding sequence numbers can be made safe; so I don't agree with Costin's division into two parts. > Another thing: the draft says that NAT will work with EDO. I'd prefer not to argue that yet... > However, most NATs have a passive FTP mode - which means they will > look through the TCP payload for the host's IP address and rewrite > with their own. (That's one of the reasons I prefer to have "Data Offset" be a clearly invalid value whenever it is overridden by EDO: any middlebox will then have fair warning that it is clueless.) > With EDO, the NAT could be messing up options placed in EDO space in > the payload. To avoid this you need a checksum, as Olivier says. Checksum isn't the _only_ way; but some sort of checksum is probably a good idea. > I suspect that the solution has to be something in the direction of > (1), where the EDO space is quoted explicitly (have an SACK like > options that says bytes XX-YY from the payload carry in fact options). I don't quite follow; but that may be a workable approach... (I think of somehow overlaying the "Urgent pointer".) > On top of that, we need a review of what options can be sent over EDO > and what options cannot be sent over it. I don't think _anything_ should be "cannot" there; but we'll have some work in how to ration what options go in the SYN (which, alas, we're going to have to give up on expanding). > It's not going to be easy, in my opinion. It never was easy. :^( -- John Leslie From nobody Mon May 5 08:41: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 ACC301A03B9 for ; Mon, 5 May 2014 08:41:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] 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 4tmd-II3Kj07 for ; Mon, 5 May 2014 08:41:05 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 11A311A038D for ; Mon, 5 May 2014 08:41:05 -0700 (PDT) Received: from [192.168.1.93] (pool-71-105-87-112.lsanca.dsl-w.verizon.net [71.105.87.112]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id s45FeUD0002254 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 5 May 2014 08:40:33 -0700 (PDT) Message-ID: <5367B0F1.1000403@isi.edu> Date: Mon, 05 May 2014 08:40:33 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Olivier.Bonaventure@uclouvain.be, "Scharf, Michael (Michael)" References: <20140425221257.12559.43206.idtracker@ietfa.amsl.com> <2586_1398464386_535ADF82_2586_915_1_535ADF56.9050106@isi.edu> <5363AF84.8090701@mti-systems.com> <5363B397.8090009@isi.edu> <655C07320163294895BBADA28372AF5D2CFE36@FR712WXCHMBA15.zeu.alcatel-lucent.com> <536548D7.5030802@uclouvain.be> In-Reply-To: <536548D7.5030802@uclouvain.be> Content-Type: text/plain; charset=UTF-8; format=flowed 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/Jsa2WUdiMk49WeZI76PvCcZdTNQ Cc: "tcpm@ietf.org" Subject: Re: [tcpm] New Version Notification for draft-touch-tcpm-tcp-edo-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, 05 May 2014 15:41:06 -0000 On 5/3/2014 12:51 PM, Olivier Bonaventure wrote: > Michael, > > >> Thus, instead of further arguing about process aspects, I am more >> interested in thoughts on: >> >> * From designers of TCP extensions requiring more option space: Is >> draft-touch-tcpm-tcp-edo a good solution for your needs and thus the >> right way to move forward? >> >> * From implementers: Are there deployment issues beyond what is >> described in the draft already? And, would this mechanism be >> implemented in the Internet? > > My main concern with this draft are the possible interactions with > segment splitting/coalescing middleboxes. These already affect a few things - splitting replicates timestamps and repeats ACKs, and coalescing might need to drop SACK blocks and drops some of the timestamp info. A key question for the group is the extent to which we want to support these or even detect them in our core mechanisms, or whether we should suggest that they be detected (and replaced) by existing mechanisms (e.g., TCP-AO or IPsec). > The draft considers that these middleboxes are rare and should not > constitute a problem. Unfortunately, I have to disagree with this > statement. An important concern are the recent NICs that support TSO or > GRO. These are not merely middleboxes that resegment. They ought to be integrated with the endsystem sufficient to support TCP. So we should consider the impact of network rewriting boxes vs. TSO/GRO NICs as separate issues, IMO. > These NICs are very widely used today and there are environments > where it is very difficult for a TCP stack to determine whether it runs > with such a NIC a not. A typical case is a virtual machine running on a > host that exposes a driver that does not correspond to the physical NIC > that is actually used. > > The EDO option proposed in this draft does not unfortunately work > correctly through a middlebox that splits segments. Again, we're back to the middlebox example: > Concerning the > following example. > > A host that has negotiated EDO during the three way handshake sends a > segment that contains : > - TCP header indicates 4 bytes of option, followed by EDO option > indicating an option of 100 bytes, 100 bytes of option (e.g. a very long > SACK), 1000 bytes of data > > The middlebox does not understand the EDO option but needs to split the > segment. Some middleboxes will copy all options in the two segments. A middlebox that examines the contents of TCP traffic - or worse, modifies it - needs to follow all of RFC1122 host requirements. It's interpreting content - if it sees a SYN with an unknown option, it ought to have removed it or dropped the SYN. If it doesn't, you have a device that is broken and needs to be replaced. We should design TCP to be liberal in what it accepts, but no Internet protocol should be designed to overcome deliberate implementation errors. > This results in : > > segment 1 : TCP header indicates 4 bytes of option, followed by EDO > option indicating an option of 100 bytes, 100 bytes of option (e.g. a > very long SACK), 500 bytes of data > > segment 2 : TCP header indicates 4 bytes of option, followed by EDO > option indicating an option of 100 bytes, 500 bytes of data > > The receiver will try to parse 100 bytes of option in the second segment... Agreed. However, now you're back to the NIC issue (which ought not be related): > In their IMC paper entitled "Is it Still Possible to Extend TCP?", > Michio Honda et al. provide the following recommendation > http://conferences.sigcomm.org/imc/2011/docs/p181.pdf > > "All the NICs we tested correctly copied the options to all the split > segments. TSO is now sufficiently commonplace so that designers of > extensions to TCP should assume it. The implication is that TCP options > must be designed so that when they are duplicated on consecutive > segments, this does not adversely affect correctness or performance." This tells me your TCP interface was implemented incorrectly. The correct interface passes options (including the extended option *and its associated contents*) ***SEPARATELY*** from the user data. If that is done all the way down to the TSO, the TSO will correctly copy the option into individual segments correctly. If, however, you implement this badly - and pass TCP segments as a whole to the offload engine, then the offload engine *has no business* splitting or coalescing segments. > EDO should be modified to take this recommendation into account to be > deployable in today's Internet. > > One possibility could be to include a checksum inside the EDO option. > > > +--------+--------+--------+--------+----------+----------+ > | Kind | Length | Header_length | Checksum | > +--------+--------+--------+--------+----------+----------+ That logic would apply too EVERY option, and now we have a TCP that wastes space primarily to locate and debug implementation errors. I don't agree that TCP should be designed to overcome deliberate implementation errors. Joe From nobody Mon May 5 08:50: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 CBFD11A0298 for ; Mon, 5 May 2014 08:50:18 -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, RCVD_IN_DNSWL_NONE=-0.0001] 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 9jBqjkxj3pcJ for ; Mon, 5 May 2014 08:50:17 -0700 (PDT) Received: from atl4mhob05.myregisteredsite.com (atl4mhob05.myregisteredsite.com [209.17.115.43]) by ietfa.amsl.com (Postfix) with ESMTP id CB1FC1A00C6 for ; Mon, 5 May 2014 08:50:16 -0700 (PDT) Received: from mailpod.hostingplatform.com ([10.30.71.206]) by atl4mhob05.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id s45FoB1r011700 for ; Mon, 5 May 2014 11:50:11 -0400 Received: (qmail 11545 invoked by uid 0); 5 May 2014 15:50:11 -0000 X-TCPREMOTEIP: 107.46.91.152 X-Authenticated-UID: wes@mti-systems.com Received: from unknown (HELO ?192.168.43.65?) (wes@mti-systems.com@107.46.91.152) by 0 with ESMTPA; 5 May 2014 15:50:10 -0000 Message-ID: <5367B32C.3080702@mti-systems.com> Date: Mon, 05 May 2014 11:50:04 -0400 From: Wesley Eddy Organization: MTI Systems User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: John Leslie , Costin Raiciu References: <20140425221257.12559.43206.idtracker@ietfa.amsl.com> <2586_1398464386_535ADF82_2586_915_1_535ADF56.9050106@isi.edu> <5363AF84.8090701@mti-systems.com> <5363B397.8090009@isi.edu> <655C07320163294895BBADA28372AF5D2CFE36@FR712WXCHMBA15.zeu.alcatel-lucent.com> <536548D7.5030802@uclouvain.be> <68C69A33-3733-48FB-AED6-E1DBC121C5B7@cs.ucl.ac.uk> <20140505144109.GQ44329@verdi> In-Reply-To: <20140505144109.GQ44329@verdi> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/XRO00gnLQ8F7TfaHZiSN57_sKOA Cc: "tcpm@ietf.org" , Joe Touch Subject: Re: [tcpm] New Version Notification for draft-touch-tcpm-tcp-edo-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, 05 May 2014 15:50:19 -0000 On 5/5/2014 10:41 AM, John Leslie wrote: >> However, most NATs have a passive FTP mode - which means they will >> > look through the TCP payload for the host's IP address and rewrite >> > with their own. > > (That's one of the reasons I prefer to have "Data Offset" be a clearly > invalid value whenever it is overridden by EDO: any middlebox will then > have fair warning that it is clueless.) > I think I agree. IMHO, the tradeoff comes down to whether it's more desirable for the middlebox to end up doing something violent like: - dropping the segment - resetting the TCP connection - generating an ICMP - crashing versus just doing something to the segments which the receiver can detect and possibly work-around with greater size and complexity in the mechanism itself. It ends up being a matter of transition and whether we really expect offending nodes to be found and fixed over time, and can stand some deployment hassles and complaints in the meantime. If not, then the design needs to be a bit more complicated forever in order to accommodate today's legacy. If there are significant advantages to being able to use long options that relate to real business problems, then I think the legacy won't be as much of a problem, but don't really know. -- Wes Eddy MTI Systems From nobody Mon May 5 08:57: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 23E011A03BE for ; Mon, 5 May 2014 08:57:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] 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 NS1HXdBjhwJp for ; Mon, 5 May 2014 08:57:01 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id C78311A03BB for ; Mon, 5 May 2014 08:57:01 -0700 (PDT) Received: from [192.168.1.93] (pool-71-105-87-112.lsanca.dsl-w.verizon.net [71.105.87.112]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id s45FuDva007423 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 5 May 2014 08:56:16 -0700 (PDT) Message-ID: <5367B4A0.4090600@isi.edu> Date: Mon, 05 May 2014 08:56:16 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Costin Raiciu , Olivier.Bonaventure@uclouvain.be References: <20140425221257.12559.43206.idtracker@ietfa.amsl.com> <2586_1398464386_535ADF82_2586_915_1_535ADF56.9050106@isi.edu> <5363AF84.8090701@mti-systems.com> <5363B397.8090009@isi.edu> <655C07320163294895BBADA28372AF5D2CFE36@FR712WXCHMBA15.zeu.alcatel-lucent.com> <536548D7.5030802@uclouvain.be> <68C69A33-3733-48FB-AED6-E1DBC121C5B7@cs.ucl.ac.uk> In-Reply-To: <68C69A33-3733-48FB-AED6-E1DBC121C5B7@cs.ucl.ac.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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/EpBk7BcqGiD99mPDv52Xym3IHsc Cc: "tcpm@ietf.org" Subject: Re: [tcpm] New Version Notification for draft-touch-tcpm-tcp-edo-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, 05 May 2014 15:57:04 -0000 On 5/5/2014 12:49 AM, Costin Raiciu wrote: > I'd like to add to what Olivier has said. > > One question I had about this draft is whether the options included > in the EDO are supposed to be carrying sequence numbers or not. Two > options: > > 1. they carry sequence numbers: in this case we are changing the > semantics of options in TCP, sending them reliably, orderly and > subject to flow control. We're not doing that any more than the options in existing segments within the existing Data Offset are so covered. The option isn't buried in the data stream - this was considered for MPTCP, but rejected, for some of the reasons you mention. So EDO option space ought to be used the same way - with the same limitations (or not) of existing option space. ... > Another thing: the draft says that NAT will work with EDO. However, > most NATs have a passive FTP mode - which means they will look > through the TCP payload for the host's IP address and rewrite with > their own. With EDO, the NAT could be messing up options placed in > EDO space in the payload. To avoid this you need a checksum, as > Olivier says. See my response to Oliver's issue on this. Such a NAT ought to have either dropped the EDO in the initial SYN or dropped the SYN completely. Joe From nobody Mon May 5 08:58: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 1B5451A038A for ; Mon, 5 May 2014 08:58:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] 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 Shk_1JiNmFLC for ; Mon, 5 May 2014 08:58:10 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id BD7C71A0087 for ; Mon, 5 May 2014 08:58:10 -0700 (PDT) Received: from [192.168.1.93] (pool-71-105-87-112.lsanca.dsl-w.verizon.net [71.105.87.112]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id s45FvhRL008129 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 5 May 2014 08:57:46 -0700 (PDT) Message-ID: <5367B4FA.5000904@isi.edu> Date: Mon, 05 May 2014 08:57:46 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: John Leslie , Costin Raiciu References: <20140425221257.12559.43206.idtracker@ietfa.amsl.com> <2586_1398464386_535ADF82_2586_915_1_535ADF56.9050106@isi.edu> <5363AF84.8090701@mti-systems.com> <5363B397.8090009@isi.edu> <655C07320163294895BBADA28372AF5D2CFE36@FR712WXCHMBA15.zeu.alcatel-lucent.com> <536548D7.5030802@uclouvain.be> <68C69A33-3733-48FB-AED6-E1DBC121C5B7@cs.ucl.ac.uk> <20140505144109.GQ44329@verdi> In-Reply-To: <20140505144109.GQ44329@verdi> Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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/WGbXDdErQPtw95X169wlov2Ry0M Cc: "tcpm@ietf.org" Subject: Re: [tcpm] New Version Notification for draft-touch-tcpm-tcp-edo-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, 05 May 2014 15:58:13 -0000 On 5/5/2014 7:41 AM, John Leslie wrote: >> However, most NATs have a passive FTP mode - which means they will >> >look through the TCP payload for the host's IP address and rewrite >> >with their own. > > (That's one of the reasons I prefer to have "Data Offset" be a clearly > invalid value whenever it is overridden by EDO: any middlebox will then > have fair warning that it is clueless.) It had that warning when it saw the EDO option and decided that it could ignore it quietly. Joe From nobody Mon May 5 09:00: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 2E5FE1A03B7 for ; Mon, 5 May 2014 09:00:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] 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 aius4z5zUPdq for ; Mon, 5 May 2014 09:00:50 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 8A0131A02CF for ; Mon, 5 May 2014 09:00:50 -0700 (PDT) Received: from [192.168.1.93] (pool-71-105-87-112.lsanca.dsl-w.verizon.net [71.105.87.112]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id s45G0Ios008848 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 5 May 2014 09:00:22 -0700 (PDT) Message-ID: <5367B595.3000107@isi.edu> Date: Mon, 05 May 2014 09:00:21 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Wesley Eddy , John Leslie , Costin Raiciu References: <20140425221257.12559.43206.idtracker@ietfa.amsl.com> <2586_1398464386_535ADF82_2586_915_1_535ADF56.9050106@isi.edu> <5363AF84.8090701@mti-systems.com> <5363B397.8090009@isi.edu> <655C07320163294895BBADA28372AF5D2CFE36@FR712WXCHMBA15.zeu.alcatel-lucent.com> <536548D7.5030802@uclouvain.be> <68C69A33-3733-48FB-AED6-E1DBC121C5B7@cs.ucl.ac.uk> <20140505144109.GQ44329@verdi> <5367B32C.3080702@mti-systems.com> In-Reply-To: <5367B32C.3080702@mti-systems.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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/tF3fEynVdlyJHwsAVZhGZaOF4oc Cc: "tcpm@ietf.org" Subject: Re: [tcpm] New Version Notification for draft-touch-tcpm-tcp-edo-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, 05 May 2014 16:00:54 -0000 PS - one other alternative would be to allow the header checksum to be optional - users can turn it on or off as needed. It could be part of EDO (determined by the length of the EDO option itself) or as a separate option (which would then be useful for all other options as a "bad NAT traversal detection option".) Joe On 5/5/2014 8:50 AM, Wesley Eddy wrote: > On 5/5/2014 10:41 AM, John Leslie wrote: >>> However, most NATs have a passive FTP mode - which means they will >>>> look through the TCP payload for the host's IP address and rewrite >>>> with their own. >> >> (That's one of the reasons I prefer to have "Data Offset" be a clearly >> invalid value whenever it is overridden by EDO: any middlebox will then >> have fair warning that it is clueless.) >> > > > I think I agree. IMHO, the tradeoff comes down to whether it's more > desirable for the middlebox to end up doing something violent like: > > - dropping the segment > - resetting the TCP connection > - generating an ICMP > - crashing > > versus just doing something to the segments which the receiver can > detect and possibly work-around with greater size and complexity in > the mechanism itself. > > It ends up being a matter of transition and whether we really > expect offending nodes to be found and fixed over time, and can > stand some deployment hassles and complaints in the meantime. > If not, then the design needs to be a bit more complicated forever > in order to accommodate today's legacy. > > If there are significant advantages to being able to use long > options that relate to real business problems, then I think the > legacy won't be as much of a problem, but don't really know. > From nobody Mon May 5 09:04: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 6E15A1A03B9 for ; Mon, 5 May 2014 09:04:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] 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 XQLUiDJW1v8Y for ; Mon, 5 May 2014 09:04:19 -0700 (PDT) Received: from bells2.cs.ucl.ac.uk (bells2.cs.ucl.ac.uk [128.16.5.33]) by ietfa.amsl.com (Postfix) with ESMTP id 786FC1A038D for ; Mon, 5 May 2014 09:04:19 -0700 (PDT) Received: from 5-12-111-140.residential.rdsnet.ro ([5.12.111.140] helo=192-168-0-103.rdsnet.ro) by bells2.cs.ucl.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (C.Raiciu authenticated) (Exim 4.54) id 1WhLN3-0005P3-Jq; Mon, 05 May 2014 17:04:01 +0100 Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Costin Raiciu In-Reply-To: <5367B0F1.1000403@isi.edu> Date: Mon, 5 May 2014 19:04:01 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <45E71AD0-D376-4E59-A094-19DAEFCE22D3@cs.ucl.ac.uk> References: <20140425221257.12559.43206.idtracker@ietfa.amsl.com> <2586_1398464386_535ADF82_2586_915_1_535ADF56.9050106@isi.edu> <5363AF84.8090701@mti-systems.com> <5363B397.8090009@isi.edu> <655C07320163294895BBADA28372AF5D2CFE36@FR712WXCHMBA15.zeu.alcatel-lucent.com> <536548D7.5030802@uclouvain.be> <5367B0F1.1000403@isi.edu> To: Joe Touch X-Mailer: Apple Mail (2.1085) Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/7QxhrdcN-oMD0Dro77FUGZn0x5E Cc: "tcpm@ietf.org" Subject: Re: [tcpm] New Version Notification for draft-touch-tcpm-tcp-edo-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, 05 May 2014 16:04:22 -0000 > A middlebox that examines the contents of TCP traffic - or worse, = modifies it - needs to follow all of RFC1122 host requirements. It's = interpreting content - if it sees a SYN with an unknown option, it ought = to have removed it or dropped the SYN. >=20 > If it doesn't, you have a device that is broken and needs to be = replaced. >=20 > We should design TCP to be liberal in what it accepts, but no Internet = protocol should be designed to overcome deliberate implementation = errors. As much as I agree with this purist view of the Internet, I also believe = it is unworkable if we want stuff deployed.=20 Say we actually stuck to the plan and designed EDO for a world with = reasonable middleboxes. Then we implement it in Linux, then we turn it = on by default. Then, all of a sudden the Internet stops working, and you = have disgruntled users cursing Linux right and left.... Trouble is, for middleboxes to change you need to have a working = protocol (that is maybe suboptimal) and a strong need for the change, = and push from OS/app vendors etc.=20 Cheers. Costin >=20 >> This results in : >>=20 >> segment 1 : TCP header indicates 4 bytes of option, followed by EDO >> option indicating an option of 100 bytes, 100 bytes of option (e.g. a >> very long SACK), 500 bytes of data >>=20 >> segment 2 : TCP header indicates 4 bytes of option, followed by EDO >> option indicating an option of 100 bytes, 500 bytes of data >>=20 >> The receiver will try to parse 100 bytes of option in the second = segment... >=20 > Agreed. >=20 > However, now you're back to the NIC issue (which ought not be = related): >=20 >> In their IMC paper entitled "Is it Still Possible to Extend TCP?", >> Michio Honda et al. provide the following recommendation >> http://conferences.sigcomm.org/imc/2011/docs/p181.pdf >>=20 >> "All the NICs we tested correctly copied the options to all the split >> segments. TSO is now sufficiently commonplace so that designers of >> extensions to TCP should assume it. The implication is that TCP = options >> must be designed so that when they are duplicated on consecutive >> segments, this does not adversely affect correctness or performance." >=20 > This tells me your TCP interface was implemented incorrectly. >=20 > The correct interface passes options (including the extended option = *and its associated contents*) ***SEPARATELY*** from the user data. >=20 > If that is done all the way down to the TSO, the TSO will correctly = copy the option into individual segments correctly. >=20 > If, however, you implement this badly - and pass TCP segments as a = whole to the offload engine, then the offload engine *has no business* = splitting or coalescing segments. >=20 >> EDO should be modified to take this recommendation into account to be >> deployable in today's Internet. >>=20 >> One possibility could be to include a checksum inside the EDO option. >>=20 >>=20 >> +--------+--------+--------+--------+----------+----------+ >> | Kind | Length | Header_length | Checksum | >> +--------+--------+--------+--------+----------+----------+ >=20 > That logic would apply too EVERY option, and now we have a TCP that = wastes space primarily to locate and debug implementation errors. >=20 > I don't agree that TCP should be designed to overcome deliberate = implementation errors. >=20 > Joe >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Mon May 5 09:15:27 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 EAA5A1A037A for ; Mon, 5 May 2014 09:15:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] 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 a0fo2SQhjIzs for ; Mon, 5 May 2014 09:15:22 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id F048C1A03A6 for ; Mon, 5 May 2014 09:15:21 -0700 (PDT) Received: from [192.168.1.93] (pool-71-105-87-112.lsanca.dsl-w.verizon.net [71.105.87.112]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id s45GE61e025816 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 5 May 2014 09:14:25 -0700 (PDT) Message-ID: <5367B8D1.30500@isi.edu> Date: Mon, 05 May 2014 09:14:09 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Costin Raiciu References: <20140425221257.12559.43206.idtracker@ietfa.amsl.com> <2586_1398464386_535ADF82_2586_915_1_535ADF56.9050106@isi.edu> <5363AF84.8090701@mti-systems.com> <5363B397.8090009@isi.edu> <655C07320163294895BBADA28372AF5D2CFE36@FR712WXCHMBA15.zeu.alcatel-lucent.com> <536548D7.5030802@uclouvain.be> <5367B0F1.1000403@isi.edu> <45E71AD0-D376-4E59-A094-19DAEFCE22D3@cs.ucl.ac.uk> In-Reply-To: <45E71AD0-D376-4E59-A094-19DAEFCE22D3@cs.ucl.ac.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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/RbzVWUGe5tKuHtEK4UFBOsmD3-E Cc: "tcpm@ietf.org" Subject: Re: [tcpm] New Version Notification for draft-touch-tcpm-tcp-edo-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, 05 May 2014 16:15:25 -0000 On 5/5/2014 9:04 AM, Costin Raiciu wrote: >> A middlebox that examines the contents of TCP traffic - or worse, modifies it - needs to follow all of RFC1122 host requirements. It's interpreting content - if it sees a SYN with an unknown option, it ought to have removed it or dropped the SYN. >> >> If it doesn't, you have a device that is broken and needs to be >> replaced. >> >> We should design TCP to be liberal in what it accepts, but no >> Internet protocol should be designed to overcome deliberate >> implementation errors. >> > As much as I agree with this purist view of the Internet, I also > believe it is unworkable if we want stuff deployed. > > Say we actually stuck to the plan and designed EDO for a world with > reasonable middleboxes. Then we implement it in Linux, then we turn it > on by default. Then, all of a sudden the Internet stops working, and you > have disgruntled users cursing Linux right and left.... Linux already runs lots of things we didn't approve, and never seems to take any blame. I don't see avoiding Linux user ire as a viable approach. > Trouble is, for middleboxes to change you need to have a working > protocol (that is maybe suboptimal) and a strong need for the change, > and push from OS/app vendors etc. For middleboxes to change, they have to start breaking things. As long as we adapt to the errors they make, we're helping create their market. I agree with your overall point that we do need to consider how/whether this can avoid being held hostage by middleboxes, and a *temporary* header checksum might be a way. But ultimately, that still means the new option will not work through middleboxes, and lots of people will not consider that the fault of the middlebox. Joe From nobody Mon May 5 09:30: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 DD7F81A037A for ; Mon, 5 May 2014 09:30:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] 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 xhjxwqKPkIXN for ; Mon, 5 May 2014 09:30:31 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 3EE0C1A02CF for ; Mon, 5 May 2014 09:30:31 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id A65A3C94A9; Mon, 5 May 2014 12:30:25 -0400 (EDT) Date: Mon, 5 May 2014 12:30:25 -0400 From: John Leslie To: Wesley Eddy Message-ID: <20140505163025.GA27034@verdi> References: <5363AF84.8090701@mti-systems.com> <5363B397.8090009@isi.edu> <655C07320163294895BBADA28372AF5D2CFE36@FR712WXCHMBA15.zeu.alcatel-lucent.com> <536548D7.5030802@uclouvain.be> <68C69A33-3733-48FB-AED6-E1DBC121C5B7@cs.ucl.ac.uk> <20140505144109.GQ44329@verdi> <5367B32C.3080702@mti-systems.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5367B32C.3080702@mti-systems.com> User-Agent: Mutt/1.4.1i Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/rxMI6qxT24AooNzLaFyj54R8gjA Cc: "tcpm@ietf.org" Subject: Re: [tcpm] New Version Notification for draft-touch-tcpm-tcp-edo-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, 05 May 2014 16:30:34 -0000 Wesley Eddy wrote: > On 5/5/2014 10:41 AM, John Leslie wrote: >> >> (That's one of the reasons I prefer to have "Data Offset" be a clearly >> invalid value whenever it is overridden by EDO: any middlebox will then >> have fair warning that it is clueless.) > > I think I agree. IMHO, the tradeoff comes down to whether it's more > desirable for the middlebox to end up doing something violent like: > > - dropping the segment This should always be "legal" for a middlebox. (I certainly prefer it to damaging some unrelated part of the packet.) It's easy enough to detect. > - resetting the TCP connection This isn't quite "legal", but is certainly easy to detect. > - generating an ICMP Would anyone actually do this? (Hopefully, it would be in combination with dropping the packet.) > - crashing That's my most-preferred one. There's no excuse to blame anyone but the middlebox vendor. ;^) > versus just doing something to the segments which the receiver can > detect and possibly work-around with greater size and complexity in > the mechanism itself. I'd _much_ rather not start down the road of guessing what unrelated part of the packet has been damaged! > It ends up being a matter of transition and whether we really > expect offending nodes to be found and fixed over time, and can > stand some deployment hassles and complaints in the meantime. IMHO, that's always the case -- it just is, sometimes the transition takes decades. :^( > If not, then the design needs to be a bit more complicated forever > in order to accommodate today's legacy. Now we're arguing over price: how much is "a bit"? > If there are significant advantages to being able to use long > options that relate to real business problems, then I think the > legacy won't be as much of a problem, but don't really know. We've already over-packed the Options field: there are already _multiple_ business cases for supporting an expanded field. How much of a problem the legacy proves to be depends a lot on how we design EDO... -- John Leslie From nobody Mon May 5 09:36:25 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 BBD091A03E1 for ; Mon, 5 May 2014 09:36:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] 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 XiX86ICLrdFL for ; Mon, 5 May 2014 09:36:21 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 1FD661A00D7 for ; Mon, 5 May 2014 09:36:21 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id DAA6DC94BE; Mon, 5 May 2014 12:36:15 -0400 (EDT) Date: Mon, 5 May 2014 12:36:15 -0400 From: John Leslie To: Joe Touch Message-ID: <20140505163615.GB27034@verdi> References: <5363AF84.8090701@mti-systems.com> <5363B397.8090009@isi.edu> <655C07320163294895BBADA28372AF5D2CFE36@FR712WXCHMBA15.zeu.alcatel-lucent.com> <536548D7.5030802@uclouvain.be> <68C69A33-3733-48FB-AED6-E1DBC121C5B7@cs.ucl.ac.uk> <20140505144109.GQ44329@verdi> <5367B4FA.5000904@isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5367B4FA.5000904@isi.edu> User-Agent: Mutt/1.4.1i Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/CRSrboxg8WWl5KTSEkw8XcpBfc8 Cc: tcpm@ietf.org Subject: Re: [tcpm] New Version Notification for draft-touch-tcpm-tcp-edo-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, 05 May 2014 16:36:22 -0000 Joe Touch wrote: > On 5/5/2014 7:41 AM, John Leslie wrote: >> >> (That's one of the reasons I prefer to have "Data Offset" be a clearly >> invalid value whenever it is overridden by EDO: any middlebox will then >> have fair warning that it is clueless.) > > It had that warning when it saw the EDO option and decided that it could > ignore it quietly. This points out another failure of the TCP-Options design: for such a basic building block, Options should have carried an indicator of what to do with an unrecognized option -- e.g. ignore, drop the packet, etc. Joe is right that "conservative in what you send" sort-of implies that you don't pass on an option when you have no idea what it might actually mean... (But that horse left the barn many years ago.) -- John Leslie From nobody Mon May 5 09:52: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 E76BD1A03BB for ; Mon, 5 May 2014 09:52:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] 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 hUvB4v9EVFf4 for ; Mon, 5 May 2014 09:52:13 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id B69081A017E for ; Mon, 5 May 2014 09:52:13 -0700 (PDT) Received: from [192.168.1.93] (pool-71-105-87-112.lsanca.dsl-w.verizon.net [71.105.87.112]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id s45GpTWN002465 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 5 May 2014 09:51:38 -0700 (PDT) Message-ID: <5367C190.1040602@isi.edu> Date: Mon, 05 May 2014 09:51:28 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: John Leslie References: <5363AF84.8090701@mti-systems.com> <5363B397.8090009@isi.edu> <655C07320163294895BBADA28372AF5D2CFE36@FR712WXCHMBA15.zeu.alcatel-lucent.com> <536548D7.5030802@uclouvain.be> <68C69A33-3733-48FB-AED6-E1DBC121C5B7@cs.ucl.ac.uk> <20140505144109.GQ44329@verdi> <5367B4FA.5000904@isi.edu> <20140505163615.GB27034@verdi> In-Reply-To: <20140505163615.GB27034@verdi> Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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/z4PMj7wDZHb6rgIZk2qaOKj7N5o Cc: tcpm@ietf.org Subject: Re: [tcpm] New Version Notification for draft-touch-tcpm-tcp-edo-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, 05 May 2014 16:52:20 -0000 On 5/5/2014 9:36 AM, John Leslie wrote: > Joe Touch wrote: >> On 5/5/2014 7:41 AM, John Leslie wrote: >>> >>> (That's one of the reasons I prefer to have "Data Offset" be a clearly >>> invalid value whenever it is overridden by EDO: any middlebox will then >>> have fair warning that it is clueless.) >> >> It had that warning when it saw the EDO option and decided that it could >> ignore it quietly. > > This points out another failure of the TCP-Options design: for such > a basic building block, Options should have carried an indicator of > what to do with an unrecognized option -- e.g. ignore, drop the packet, > etc. Right - we built that into IPv6, but TCP missed that boat. However, it still requires that middleboxes would do the right thing; their incentive to "keep working" suggests they would treat this like all other Internet standards - something to violate if it makes them money. So even if the flag were there (it sort of is already - but "ignore" on pass-through should have been interpreted as "drop"), it's not clear middlebox vendors would do as we proscribe. Joe From nobody Mon May 5 14:41: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 187C41A063A for ; Mon, 5 May 2014 14:41:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] 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 a8iNorR3BPQM for ; Mon, 5 May 2014 14:41:55 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 4ED7B1A0522 for ; Mon, 5 May 2014 14:41:55 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id s45Lf42e023540 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 5 May 2014 14:41:04 -0700 (PDT) Message-ID: <53680570.2000903@isi.edu> Date: Mon, 05 May 2014 14:41:04 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: "tcpm@ietf.org" References: <20140505204727.17573.34634.idtracker@ietfa.amsl.com> In-Reply-To: <20140505204727.17573.34634.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20140505204727.17573.34634.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed 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/SAnugXaE1PZXzHKGhZuk5BxRy30 Subject: [tcpm] Fwd: New Version Notification for draft-touch-tcpm-tcp-edo-02.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, 05 May 2014 21:41:57 -0000 Hi, all, I've updated the doc to include some of the ideas suggested (checksum, DO=0) as issues to be discussed, including some ratinonale, as well as implementation issues like keeping data and options separate in the TCP API. My view is that these details can be considered and consensus reached in the WG, but there seems to be a reasonable path (or paths) forward either way, AFAICT. Joe -------- Original Message -------- Subject: New Version Notification for draft-touch-tcpm-tcp-edo-02.txt Date: Mon, 05 May 2014 13:47:27 -0700 From: internet-drafts@ietf.org To: Wesley M. Eddy , Dr. Joseph D. Touch , Joe Touch , Wesley Eddy A new version of I-D, draft-touch-tcpm-tcp-edo-02.txt has been successfully submitted by Joe Touch and posted to the IETF repository. Name: draft-touch-tcpm-tcp-edo Revision: 02 Title: TCP Extended Data Offset Option Document date: 2014-05-05 Group: Individual Submission Pages: 12 URL: http://www.ietf.org/internet-drafts/draft-touch-tcpm-tcp-edo-02.txt Status: https://datatracker.ietf.org/doc/draft-touch-tcpm-tcp-edo/ Htmlized: http://tools.ietf.org/html/draft-touch-tcpm-tcp-edo-02 Diff: http://www.ietf.org/rfcdiff?url2=draft-touch-tcpm-tcp-edo-02 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 and explains why such extensions cannot be used in the initial SYN of a connection. 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 May 5 14:59: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 1C4181A03F9 for ; Mon, 5 May 2014 14:59:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] 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 xsx8woesAmAX for ; Mon, 5 May 2014 14:59:22 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id C1BCA1A03D7 for ; Mon, 5 May 2014 14:59:22 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id s45LwKaJ026278 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 5 May 2014 14:58:20 -0700 (PDT) Message-ID: <5368097C.20003@isi.edu> Date: Mon, 05 May 2014 14:58:20 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: John Leslie , Wesley Eddy References: <5363AF84.8090701@mti-systems.com> <5363B397.8090009@isi.edu> <655C07320163294895BBADA28372AF5D2CFE36@FR712WXCHMBA15.zeu.alcatel-lucent.com> <536548D7.5030802@uclouvain.be> <68C69A33-3733-48FB-AED6-E1DBC121C5B7@cs.ucl.ac.uk> <20140505144109.GQ44329@verdi> <5367B32C.3080702@mti-systems.com> <20140505163025.GA27034@verdi> In-Reply-To: <20140505163025.GA27034@verdi> Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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/zKnmH79j7nxgkZdgyT8j5WR2bOQ Cc: "tcpm@ietf.org" Subject: Re: [tcpm] New Version Notification for draft-touch-tcpm-tcp-edo-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, 05 May 2014 21:59:24 -0000 Some comments on the approaches for handling the connection: On 5/5/2014 9:30 AM, John Leslie wrote: > Wesley Eddy wrote: ... >> I think I agree. IMHO, the tradeoff comes down to whether it's more >> desirable for the middlebox to end up doing something violent like: >> >> - dropping the segment > > This should always be "legal" for a middlebox. (I certainly prefer > it to damaging some unrelated part of the packet.) It's easy enough > to detect. Agreed. >> - resetting the TCP connection > > This isn't quite "legal", but is certainly easy to detect. Agreed. >> - generating an ICMP > > Would anyone actually do this? (Hopefully, it would be in combination > with dropping the packet.) This ought to be legal only when the midbox sends a router-like ICMP error. The only one that makes sense to me is "protocol unreachable". However, this could be interpreted by the source as the fact that TCP isn't reachable at all, not just TCP-with-EDO. So I don't think this is viable at all. >> - crashing > > That's my most-preferred one. There's no excuse to blame anyone but > the middlebox vendor. ;^) I like that one too. Joe From nobody Tue May 6 03:13: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 9E0A01A065C for ; Tue, 6 May 2014 03:13:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.553 X-Spam-Level: X-Spam-Status: No, score=-2.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, 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 mh1s2rAP0coJ for ; Tue, 6 May 2014 03:13:08 -0700 (PDT) Received: from mx11.netapp.com (mx11.netapp.com [216.240.18.76]) by ietfa.amsl.com (Postfix) with ESMTP id 3BA531A0660 for ; Tue, 6 May 2014 03:13:08 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.97,996,1389772800"; d="scan'208";a="121394532" Received: from vmwexceht02-prd.hq.netapp.com ([10.106.76.240]) by mx11-out.netapp.com with ESMTP; 06 May 2014 03:13:04 -0700 Received: from SACEXCMBX02-PRD.hq.netapp.com ([169.254.1.105]) by vmwexceht02-prd.hq.netapp.com ([10.106.76.240]) with mapi id 14.03.0123.003; Tue, 6 May 2014 03:13:04 -0700 From: "Scheffenegger, Richard" To: Joe Touch , "Olivier.Bonaventure@uclouvain.be" , "Scharf, Michael (Michael)" Thread-Topic: [tcpm] New Version Notification for draft-touch-tcpm-tcp-edo-01.txt Thread-Index: AQHPZfhMHEvWTWWf5EO6ubLhhdrrN5st07QAgAAE3ICAAFqmAIAAAdMAgADPDgCAALeRgIAC3nOAgAC/AXA= Date: Tue, 6 May 2014 10:13:03 +0000 Message-ID: <012C3117EDDB3C4781FD802A8C27DD4F4A376C7C@SACEXCMBX02-PRD.hq.netapp.com> References: <20140425221257.12559.43206.idtracker@ietfa.amsl.com> <2586_1398464386_535ADF82_2586_915_1_535ADF56.9050106@isi.edu> <5363AF84.8090701@mti-systems.com> <5363B397.8090009@isi.edu> <655C07320163294895BBADA28372AF5D2CFE36@FR712WXCHMBA15.zeu.alcatel-lucent.com> <536548D7.5030802@uclouvain.be> <5367B0F1.1000403@isi.edu> In-Reply-To: <5367B0F1.1000403@isi.edu> Accept-Language: de-AT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.106.53.53] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/Fl5NbgiN6oIXthLfh--6vaxtg9M Cc: "tcpm@ietf.org" Subject: Re: [tcpm] New Version Notification for draft-touch-tcpm-tcp-edo-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: Tue, 06 May 2014 10:13:10 -0000 >=20 > However, now you're back to the NIC issue (which ought not be related): >=20 > > In their IMC paper entitled "Is it Still Possible to Extend TCP?", > > Michio Honda et al. provide the following recommendation > > http://conferences.sigcomm.org/imc/2011/docs/p181.pdf > > > > "All the NICs we tested correctly copied the options to all the split > > segments. TSO is now sufficiently commonplace so that designers of > > extensions to TCP should assume it. The implication is that TCP > > options must be designed so that when they are duplicated on > > consecutive segments, this does not adversely affect correctness or > performance." >=20 > This tells me your TCP interface was implemented incorrectly. >=20 > The correct interface passes options (including the extended option *and > its associated contents*) ***SEPARATELY*** from the user data. >=20 > If that is done all the way down to the TSO, the TSO will correctly copy > the option into individual segments correctly. >=20 > If, however, you implement this badly - and pass TCP segments as a whole > to the offload engine, then the offload engine *has no business* splittin= g > or coalescing segments. I can agree with the assessment, that TSO is typically done wrong, and that= the API was not properly designed. Most TSO NICs only deal with "typical" header flags - from my ECN research = I know that non-ECT (CE; ECT(0); ECT(1)) IP flags are not necessarily deliv= ered correctly by LRO (only the IP bits of the first segment that was recei= ved are usually handed up to the software TCP stack, even when they change;= thus ECN information in up to 200 segments may never reach the TCP layer f= or handling (and recent measurements also indicate that for ECN, the gating= issue is not TCP ECN, but the IP ECN flags getting forwarded end-to-end pr= operly... On the LRO TCP side, any "unexpected" TCP header bits (EDO wouldn't account= for this; setting DO to an invalid value might) would typically stop the f= astpath processing, and get individual segments delivered - thus the RFC316= 8 ECN TCP signaling usually works (as ECE and/or CWR bits are set in those = segments). As for a TSO sender: if the NIC driver is broken, the sending TCP can ensur= e that the hardware doesn't perform invalid splits on segments containing E= DO - it has to be provided as a NIC driver workaround, sure;=20 Richard Scheffenegger =20 From F.Vaandrager@cs.ru.nl Wed May 7 06:11:25 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 51AD71A02B5 for ; Wed, 7 May 2014 06:11:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.545 X-Spam-Level: * X-Spam-Status: No, score=1.545 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651] 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 75Sv2l55Mpcf for ; Wed, 7 May 2014 06:11:16 -0700 (PDT) Received: from smeltpunt.science.ru.nl (smeltpunt.science.ru.nl [131.174.16.143]) by ietfa.amsl.com (Postfix) with ESMTP id 92D7A1A02A9 for ; Wed, 7 May 2014 06:11:14 -0700 (PDT) Received: from n142228.science.ru.nl (daphnis.cs.ru.nl [131.174.142.94]) (authen=fvaan) by smeltpunt.science.ru.nl (8.13.7/5.32) with ESMTP id s47DB431004698; Wed, 7 May 2014 15:11:04 +0200 (MEST) Message-ID: <536A30E8.8040702@cs.ru.nl> Date: Wed, 07 May 2014 15:11:04 +0200 From: Frits Vaandrager User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: tcpm@ietf.org Content-Type: multipart/alternative; boundary="------------050806030900030309030107" X-Scanned-By: MIMEDefang 2.63 on 131.174.16.143 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/DKafKW8GGMqbE0XDnchvN_qfC0o X-Mailman-Approved-At: Wed, 07 May 2014 08:01:55 -0700 Cc: fiteraup@yahoo.com Subject: [tcpm] TCP implementations in Windows8 and Ubuntu violate standard? 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, 07 May 2014 13:14:28 -0000 This is a multi-part message in MIME format. --------------050806030900030309030107 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit In my group at the Radboud University Nijmegen, the Netherlands, we do research on automata learning. We develop algorithms that allow us to learn state diagrams of black box systems by providing inputs and observing outputs. Together with my students Paul Fiterau and Ramon Janssen, we just completed a paper in which we describe how we learned models of small fragments of TCP for Windows8 and Ubuntu 13.10 implementations: http://www.mbsd.cs.ru.nl/publications/papers/fvaan/TCP/. Based on these results, we conclude that both Ubuntu 13.10 and Windows8 do not conform to the TCP standard. On page 37 RFC793 says: 3. If the connection is in a synchronized state (ESTABLISHED, FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, LAST-ACK, TIME-WAIT), any unacceptable segment (out of window sequence number or unacceptible acknowledgment number) must elicit only an empty acknowledgment segment containing the current send-sequence number and an acknowledgment indicating the next sequence number expected to be received, and the connection remains in the same state. We discovered that when an Ubuntu server is in CLOSE_WAIT state and the client sends an ACK or a FIN+ACK with a valid seq number but an invalid ack number, the server sometimes does not return any message. In Windows 8 the required acknowledgment segment is never sent. We would be very interested to hear your opinion on these findings. Is this indeed a violation of the standard? Is this a known issue? Thanks! Frits Vaandrager --------------050806030900030309030107 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit In my group at the Radboud University Nijmegen, the Netherlands, we do research on automata learning. We develop algorithms that allow us to learn state diagrams of black box systems by providing inputs and observing outputs.

Together with my students Paul Fiterau and Ramon Janssen, we just completed a paper in which we describe how we learned models of small fragments of TCP for Windows8 and Ubuntu 13.10 implementations: http://www.mbsd.cs.ru.nl/publications/papers/fvaan/TCP/.

Based on these results, we conclude that both Ubuntu 13.10 and Windows8 do not conform to the
TCP standard. On page 37 RFC793 says: 
3.  If the connection is in a synchronized state (ESTABLISHED,
    FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, LAST-ACK, TIME-WAIT),
    any unacceptable segment (out of window sequence number or
    unacceptible acknowledgment number) must elicit only an empty
    acknowledgment segment containing the current send-sequence number
    and an acknowledgment indicating the next sequence number expected
    to be received, and the connection remains in the same state.

We discovered that when an Ubuntu server is in CLOSE_WAIT state and the client sends an ACK or a FIN+ACK with a valid seq number but an invalid ack number, the server
sometimes does not return any message. In Windows 8 the required acknowledgment segment is never sent.
We would be very interested to hear your opinion on these findings. 
Is this indeed a violation of the standard? Is this a known issue?

Thanks!

Frits Vaandrager
--------------050806030900030309030107-- From nobody Thu May 8 00:48:32 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 08AD61A04A7 for ; Thu, 8 May 2014 00:48:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 urXZ0asdbiqv for ; Thu, 8 May 2014 00:48:28 -0700 (PDT) Received: from mail-vc0-f173.google.com (mail-vc0-f173.google.com [209.85.220.173]) by ietfa.amsl.com (Postfix) with ESMTP id 3CBBC1A04A3 for ; Thu, 8 May 2014 00:48:28 -0700 (PDT) Received: by mail-vc0-f173.google.com with SMTP id il7so2785227vcb.32 for ; Thu, 08 May 2014 00:48:23 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=88F2YXlx37cACWJlRTIxVLu3X/M7o+xFHAjG49Lwr2U=; b=H3I8MvfocI8vjF+e/c2rPTtpSAYVrzwJYroigsid4F6vVa9h/EP4LDaUTqaoAqE+r5 7JOvBU3FWQnm8CO4ssfuITAg1KxKJmiKnr7qKmFj26RgzObwWQaVT+Y9z8tgR/QV4S5C MLMuwVN1EFPQ37jn6LdUC6Y2DEl+eBkDWnL2FnSgWph+ta1YcZ08JCwuOf6n5Nj1FMFa ao7Rlb1CjHQBGSOi04AC6RA/7dPiEonue0qM/52X4OGWIA40k5CEb6LZIY1kQcPjPL6S yZuqWhkKDZcxQHMTXCMbAlvZo8MZdz2HXmR0Tpp8yPuxeSmrpN7O5mte/WnkX1efplFi HtHA== X-Gm-Message-State: ALoCoQkX6fUBbGzD1JDkwLnE3EDbNS/TDSqNyA8Zu0xAtZIAKDqCmDh+xHnnQ6ERcmZX0CdxFbT/ MIME-Version: 1.0 X-Received: by 10.221.20.199 with SMTP id qp7mr1928504vcb.24.1399535303610; Thu, 08 May 2014 00:48:23 -0700 (PDT) Received: by 10.58.127.100 with HTTP; Thu, 8 May 2014 00:48:23 -0700 (PDT) X-Originating-IP: [109.43.2.241] Received: by 10.58.127.100 with HTTP; Thu, 8 May 2014 00:48:23 -0700 (PDT) In-Reply-To: <536A30E8.8040702@cs.ru.nl> References: <536A30E8.8040702@cs.ru.nl> Date: Thu, 8 May 2014 09:48:23 +0200 Message-ID: From: Hagen Paul Pfeifer To: Frits Vaandrager Content-Type: multipart/alternative; boundary=001a11339e2e9f69d604f8deb4e8 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/_IdfL9q7ffkOs3sXe_A6JPoFA18 Cc: fiteraup@yahoo.com, tcpm@ietf.org Subject: Re: [tcpm] TCP implementations in Windows8 and Ubuntu violate standard? 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, 08 May 2014 07:48:30 -0000 --001a11339e2e9f69d604f8deb4e8 Content-Type: text/plain; charset=UTF-8 The scenario that you spotted MAY violate 793, but it has no real practical relevance. I.e. compared to 793 I see no performance or other negative impact where the behavior is counterproductive. Except it differs from 793. 2) why the Linux implementation differs should be asked in netdev. Sometimes standards are not fully implemented because of performance & security considerations or simple bugs Anyway: good catch! Hagen --001a11339e2e9f69d604f8deb4e8 Content-Type: text/html; charset=UTF-8

The scenario that you spotted MAY violate 793, but it has no real practical relevance. I.e. compared to 793 I see no performance or other negative impact where the behavior is counterproductive. Except it differs from 793.

2) why the Linux implementation differs should be asked in netdev. Sometimes standards are not fully implemented because of performance & security considerations or simple bugs

Anyway: good catch!

Hagen

--001a11339e2e9f69d604f8deb4e8-- From nobody Thu May 8 08:55:00 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 43AA31A007B for ; Thu, 8 May 2014 08:54:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.5 X-Spam-Level: X-Spam-Status: No, score=-1.5 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 05h3OwAV5I3E for ; Thu, 8 May 2014 08:54:56 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id C71FA1A007D for ; Thu, 8 May 2014 08:54:55 -0700 (PDT) X-AuditID: c1b4fb2d-f79036d00000126a-c5-536ba8cabded Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 37.C4.04714.AC8AB635; Thu, 8 May 2014 17:54:50 +0200 (CEST) Received: from ESESSMB205.ericsson.se ([169.254.5.151]) by ESESSHC019.ericsson.se ([153.88.183.75]) with mapi id 14.03.0174.001; Thu, 8 May 2014 17:54:50 +0200 From: Ingemar Johansson S To: "tcpm@ietf.org" Thread-Topic: Definition of flow control Thread-Index: Ac9q1P5l8lakquPSTkuQiSApD4VCwg== Date: Thu, 8 May 2014 15:54:49 +0000 Message-ID: <81564C0D7D4D2A4B9A86C8C7404A13DA31F5FDE0@ESESSMB205.ericsson.se> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.147] Content-Type: multipart/alternative; boundary="_000_81564C0D7D4D2A4B9A86C8C7404A13DA31F5FDE0ESESSMB205erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrKLMWRmVeSWpSXmKPExsUyM+Jvje6pFdnBBkvOaVlsOzmfyYHRY8mS n0wBjFFcNimpOZllqUX6dglcGRs+X2EsWG5TsfLqT6YGxu9mXYycHBICJhL3Lk5lgrDFJC7c W88GYgsJHGWUONIS3sXIBWQvZpRYvaqdBSTBJmAjsfLQd0YQW0RAWWL1/Q9gtjCQfWTifuYu Rg6guIbE7RZWiBI9iSM7L4HNZBFQkWiY8hisnFfAV+LlvDvMIDajgKzE/e/3wMYzC4hL3Hoy H+oeAYkle84zQ9iiEi8f/2MFGS8hoCQxbWsaRHm+xLHDP1kgRgpKnJz5hGUCo9AsJJNmISmb haQMIq4ncWPqFDYIW1ti2cLXzBC2rsSMf4dYkMUXMLKvYhQtTi0uzk03MtZLLcpMLi7Oz9PL Sy3ZxAiMh4NbfuvuYFz92vEQowAHoxIP74KSrGAh1sSy4srcQ4zSHCxK4rxtd72DhQTSE0tS s1NTC1KL4otKc1KLDzEycXBKNTBqHfO4edF597JMywMHbeY4f3u6Sue355J39eK9fSs27Mu8 ZnFjEnNg6eUXDSvnM52IseJIz+/eOT9VKnmT5ZK5/6NbXnWrfxLg2HwnYJ2Yp9lBs5jnux3y 4g37jdXn/lqVvs30VeQSuRPvV/B3XJvAmWj5Wttl8rttO/W3HE6/t/i241sDTZ6VSizFGYmG WsxFxYkAWEX1w2gCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/SXCVRA6SLl_cCBbpZUgirqOqBcE Subject: [tcpm] Definition of flow control 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, 08 May 2014 15:54:59 -0000 --_000_81564C0D7D4D2A4B9A86C8C7404A13DA31F5FDE0ESESSMB205erics_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi I am writing up a paper that is fairly TCP-ish. I have a problem regarding = the definition of the part of TCP that does the job to keep control over th= e packet transmission i.e the "simple" part that transmits segments wheneve= r the bytes in flight is less than the congestion window. I call this part = flow control but this is perhaps wrong ?. What is then the correct term, "r= ate control" or "rate limiting" or ? /Ingemar =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D Ingemar Johansson M.Sc. Senior Researcher Ericsson AB Wireless Access Networks Labratoriegr=E4nd 11 971 28, Lule=E5, Sweden Phone +46-1071 43042 SMS/MMS +46-73 078 3289 ingemar.s.johansson@ericsson.com www.ericsson.com "Those are my principles, and if you don't like them... well, I have others." Groucho Marx =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D --_000_81564C0D7D4D2A4B9A86C8C7404A13DA31F5FDE0ESESSMB205erics_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi

 

I am writing up a paper that is fairly TCP-ish. I ha= ve a problem regarding the definition of the part of TCP that does the job = to keep control over the packet transmission i.e the “simple” p= art that transmits segments whenever the bytes in flight is less than the congestion window. I call this part flow contro= l but this is perhaps wrong ?. What is then the correct term, “rate c= ontrol” or “rate limiting” or ?

 

/Ingemar

=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D

Ingemar Joh= ansson  M.Sc.

Senior Rese= archer

 =

Ericsson AB=

Wireless Ac= cess Networks

Labratorieg= r=E4nd 11

971 28, Lul= e=E5, Sweden

Phone += 46-1071 43042

SMS/MMS = 3;46-73 078 3289

ingemar.s.johansson@ericsson.com

www.ericsson.com

 =

“Those are my principles, and if you don't like them...
well, I have others.”  Groucho Marx
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

 

 

--_000_81564C0D7D4D2A4B9A86C8C7404A13DA31F5FDE0ESESSMB205erics_-- From nobody Thu May 8 09:36: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 64F0F1A0085 for ; Thu, 8 May 2014 09:36:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.552 X-Spam-Level: X-Spam-Status: No, score=-7.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, 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 pCA--8psZGqn for ; Thu, 8 May 2014 09:36:04 -0700 (PDT) Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) by ietfa.amsl.com (Postfix) with ESMTP id 25C6B1A0052 for ; Thu, 8 May 2014 09:36:04 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.97,1012,1389772800"; d="scan'208,217";a="163156726" Received: from vmwexceht06-prd.hq.netapp.com ([10.106.77.104]) by mx12-out.netapp.com with ESMTP; 08 May 2014 09:35:59 -0700 Received: from SACEXCMBX02-PRD.hq.netapp.com ([169.254.1.105]) by vmwexceht06-prd.hq.netapp.com ([10.106.77.104]) with mapi id 14.03.0123.003; Thu, 8 May 2014 09:35:59 -0700 From: "Scheffenegger, Richard" To: Ingemar Johansson S , "tcpm@ietf.org" Thread-Topic: Definition of flow control Thread-Index: Ac9q1P5l8lakquPSTkuQiSApD4VCwgABiV7A Date: Thu, 8 May 2014 16:35:58 +0000 Message-ID: <012C3117EDDB3C4781FD802A8C27DD4F4A384FAA@SACEXCMBX02-PRD.hq.netapp.com> References: <81564C0D7D4D2A4B9A86C8C7404A13DA31F5FDE0@ESESSMB205.ericsson.se> In-Reply-To: <81564C0D7D4D2A4B9A86C8C7404A13DA31F5FDE0@ESESSMB205.ericsson.se> Accept-Language: de-AT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.106.53.53] Content-Type: multipart/alternative; boundary="_000_012C3117EDDB3C4781FD802A8C27DD4F4A384FAASACEXCMBX02PRDh_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/yt-5q5A8gbBdeHj6UQQ0u1xt7AE Subject: Re: [tcpm] Definition of flow control 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, 08 May 2014 16:36:06 -0000 --_000_012C3117EDDB3C4781FD802A8C27DD4F4A384FAASACEXCMBX02PRDh_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Ingemar, if it really is only the function of "when to send" rather than "what to se= nd", that would probably be called scheduler (unfortunately, the "what"/"wh= en" are mingled together inseparable in most stacks - perhaps not in Lamina= r: https://developers.google.com/speed/protocols/tcp-laminar There, the term "transmission scheduling algorithm" is used... Richard Scheffenegger From: tcpm [mailto:tcpm-bounces@ietf.org] On Behalf Of Ingemar Johansson S Sent: Donnerstag, 08. Mai 2014 17:55 To: tcpm@ietf.org Subject: [tcpm] Definition of flow control Hi I am writing up a paper that is fairly TCP-ish. I have a problem regarding = the definition of the part of TCP that does the job to keep control over th= e packet transmission i.e the "simple" part that transmits segments wheneve= r the bytes in flight is less than the congestion window. I call this part = flow control but this is perhaps wrong ?. What is then the correct term, "r= ate control" or "rate limiting" or ? /Ingemar =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D Ingemar Johansson M.Sc. Senior Researcher Ericsson AB Wireless Access Networks Labratoriegr=E4nd 11 971 28, Lule=E5, Sweden Phone +46-1071 43042 SMS/MMS +46-73 078 3289 ingemar.s.johansson@ericsson.com www.ericsson.com "Those are my principles, and if you don't like them... well, I have others." Groucho Marx =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D --_000_012C3117EDDB3C4781FD802A8C27DD4F4A384FAASACEXCMBX02PRDh_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

 

Hi Ingemar,=

 

if it r= eally is only the function of „when to send“ rather than „= ;what to send“, that would probably be called scheduler (unfortunatel= y, the „what“/“when“ are mingled together inseparab= le in most stacks – perhaps not in Laminar:

&n= bsp;

https://deve= lopers.google.com/speed/protocols/tcp-laminar

&n= bsp;

There, = the term “transmission scheduling algorit= hm” is used…

&n= bsp;

&n= bsp;

Richard= Scheffenegger

&n= bsp;

From: tcpm [mailto:tcpm-bounces@ietf.org] On Behalf Of Ingemar Johansson S
Sent: Donnerstag, 08. Mai 2014 17:55
To: tcpm@ietf.org
Subject: [tcpm] Definition of flow control

 

Hi

 

I am writing up a paper that is= fairly TCP-ish. I have a problem regarding the definition of the part of T= CP that does the job to keep control over the packet transmission i.e the &= #8220;simple” part that transmits segments whenever the bytes in flight is less than the congestion window. I call th= is part flow control but this is perhaps wrong ?. What is then the correct = term, “rate control” or “rate limiting” or ?

 

/Ingemar

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Ingemar Johansson  M.Sc.

Senior Researcher

 

Ericsson AB

Wireless Access Networks

Labratoriegr=E4nd 11

971 28, Lule=E5, Sweden

Phone +46-1071 43042

SMS/MMS +46-73 078 3289

ingemar.s.johansson@ericsson.com

www.ericsson.com<= /span>

 

“Those are my principles, and if you don't like them.= ..
well, I have others.”  Groucho Marx
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D

 

 

--_000_012C3117EDDB3C4781FD802A8C27DD4F4A384FAASACEXCMBX02PRDh_-- From nobody Thu May 8 10:21:01 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 3B6B31A007D for ; Thu, 8 May 2014 10:20:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] 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 Z14qISoRqjoM for ; Thu, 8 May 2014 10:20:56 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id A0B861A0078 for ; Thu, 8 May 2014 10:20:56 -0700 (PDT) Received: from [128.9.184.167] ([128.9.184.167]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id s48HKA81028911 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 8 May 2014 10:20:10 -0700 (PDT) Message-ID: <536BBCCC.2000004@isi.edu> Date: Thu, 08 May 2014 10:20:12 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Ingemar Johansson S , "tcpm@ietf.org" References: <81564C0D7D4D2A4B9A86C8C7404A13DA31F5FDE0@ESESSMB205.ericsson.se> In-Reply-To: <81564C0D7D4D2A4B9A86C8C7404A13DA31F5FDE0@ESESSMB205.ericsson.se> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit 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/I8sw-Sonxb_mOzCHJcolJ2Kj7IM Subject: Re: [tcpm] Definition of flow control 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, 08 May 2014 17:20:58 -0000 AFAICT, you answer your own question... On 5/8/2014 8:54 AM, Ingemar Johansson S wrote: > Hi > > I am writing up a paper that is fairly TCP-ish. I have a problem > regarding the definition of the part of TCP that does the job to keep > control over the packet transmission i.e the “simple” part that > transmits segments whenever the bytes in flight is less than the ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > congestion window. I call this part flow control but this is perhaps ^^^^^^^^^^^^^^^^^^^ > wrong ?. What is then the correct term, “rate control” or “rate > limiting” or ? Congestion control. Flow control is managed by the receive window. TCP doesn't have rate control or rate limiting - it'll burst just fine, e.g., after the source goes idle during transactions like HTTP. Some variants have added rate management, but it's not part of the core required specification. Joe > > /Ingemar > > ================================= > > Ingemar Johansson M.Sc. > > Senior Researcher > > Ericsson AB > > Wireless Access Networks > > Labratoriegränd 11 > > 971 28, Luleå, Sweden > > Phone +46-1071 43042 > > SMS/MMS +46-73 078 3289 > > ingemar.s.johansson@ericsson.com > > www.ericsson.com > > “Those are my principles, and if you don't like them... > well, I have others.” Groucho Marx > > ================================= > > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > From nobody Thu May 8 12:15: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 7F9721A00EF for ; Thu, 8 May 2014 12:15:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.899 X-Spam-Level: X-Spam-Status: No, score=-5.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_SUMOF=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-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 2adXh4_x8ros for ; Thu, 8 May 2014 12:15:16 -0700 (PDT) Received: from hoemail1.alcatel.com (hoemail1.alcatel.com [192.160.6.148]) by ietfa.amsl.com (Postfix) with ESMTP id BAF551A0067 for ; Thu, 8 May 2014 12:15:16 -0700 (PDT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (h135-239-2-122.lucent.com [135.239.2.122]) by hoemail1.alcatel.com (8.13.8/IER-o) with ESMTP id s48JF8lA002392 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 8 May 2014 14:15:09 -0500 (CDT) Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id s48JF7ZE002408 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 8 May 2014 21:15:07 +0200 Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.94]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.02.0247.003; Thu, 8 May 2014 21:15:07 +0200 From: "Scharf, Michael (Michael)" To: Ingemar Johansson S , "tcpm@ietf.org" Thread-Topic: Definition of flow control Thread-Index: Ac9q1P5l8lakquPSTkuQiSApD4VCwgAG+QzA Date: Thu, 8 May 2014 19:15:07 +0000 Message-ID: <655C07320163294895BBADA28372AF5D2D573E@FR712WXCHMBA15.zeu.alcatel-lucent.com> References: <81564C0D7D4D2A4B9A86C8C7404A13DA31F5FDE0@ESESSMB205.ericsson.se> In-Reply-To: <81564C0D7D4D2A4B9A86C8C7404A13DA31F5FDE0@ESESSMB205.ericsson.se> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [155.132.188.47] Content-Type: multipart/alternative; boundary="_000_655C07320163294895BBADA28372AF5D2D573EFR712WXCHMBA15zeu_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/jxKqJfNn2PHYlekBd8dMOR9N0oY Subject: Re: [tcpm] Definition of flow control 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, 08 May 2014 19:15:18 -0000 --_000_655C07320163294895BBADA28372AF5D2D573EFR712WXCHMBA15zeu_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Keep in mind that there is not only the congestion window, but also the rec= eive window. >From RFC 5681: At any given time, a TCP MUST NOT send data with a sequence = number higher than the sum of the highest acknowledged sequence number and = the minimum of cwnd and rwnd. In TCP contect, the term "flow control" IMHO usually refers to the handling= of rwnd, while "congestion control" refers to the algorithms manipuiating = cwnd. However, the term "flow control" is not always used consistently, in = particular outside the IETF. Michael ________________________________ Von: tcpm [tcpm-bounces@ietf.org]" im Auftrag von "Ingemar Johansson S [ing= emar.s.johansson@ericsson.com] Gesendet: Donnerstag, 8. Mai 2014 17:54 Bis: tcpm@ietf.org Betreff: [tcpm] Definition of flow control Hi I am writing up a paper that is fairly TCP-ish. I have a problem regarding = the definition of the part of TCP that does the job to keep control over th= e packet transmission i.e the =93simple=94 part that transmits segments whe= never the bytes in flight is less than the congestion window. I call this p= art flow control but this is perhaps wrong ?. What is then the correct term= , =93rate control=94 or =93rate limiting=94 or ? /Ingemar =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D Ingemar Johansson M.Sc. Senior Researcher Ericsson AB Wireless Access Networks Labratoriegr=E4nd 11 971 28, Lule=E5, Sweden Phone +46-1071 43042 SMS/MMS +46-73 078 3289 ingemar.s.johansson@ericsson.com www.ericsson.com =93Those are my principles, and if you don't like them... well, I have others.=94 Groucho Marx =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D --_000_655C07320163294895BBADA28372AF5D2D573EFR712WXCHMBA15zeu_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Keep in mind that there is not only the congestion window, but also = the receive window.

>From RFC 5681: At any given time, a TCP MUST NOT send data with a sequence = number higher than the sum of the highest acknowledged sequence number and = the minimum of cwnd and rwnd.

In TCP contect, the term "flow control" IMHO usually refers to th= e handling of rwnd, while "congestion control" refers to the algo= rithms manipuiating cwnd. However, the term "flow control" is not= always used consistently, in particular outside the IETF.

Michael



Von: tcpm [tcpm-bounces@ietf.org]" im= Auftrag von "Ingemar Johansson S [ingemar.s.johansson@ericsson.com] Gesendet: Donnerstag, 8. Mai 2014 17:54
Bis: tcpm@ietf.org
Betreff: [tcpm] Definition of flow control

Hi

 

I am writing up a paper that is fairly TCP-ish. I ha= ve a problem regarding the definition of the part of TCP that does the job = to keep control over the packet transmission i.e the =93simple=94 part that= transmits segments whenever the bytes in flight is less than the congestion window. I call this part flow contro= l but this is perhaps wrong ?. What is then the correct term, =93rate contr= ol=94 or =93rate limiting=94 or ?

 

/Ingemar

=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D

Ingemar Jo= hansson  M.Sc.

Senior Res= earcher

 

Ericsson A= B

Wireless A= ccess Networks

Labratorie= gr=E4nd 11

971 28, Lu= le=E5, Sweden

Phone += ;46-1071 43042

SMS/MMS &#= 43;46-73 078 3289

ingemar.s.johansson@ericsson.c= om

www.ericsson.com

 

=93Those are my principles, and if you don't like them...
well, I have others.=94  Groucho Marx
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

 

 

--_000_655C07320163294895BBADA28372AF5D2D573EFR712WXCHMBA15zeu_-- From nobody Thu May 8 18:32:09 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 94A381A00C0 for ; Thu, 8 May 2014 18:32:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] 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 0SRFWyWRY-6v for ; Thu, 8 May 2014 18:32:04 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id 9B6291A00B7 for ; Thu, 8 May 2014 18:32:04 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id s491VHhc003632 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 8 May 2014 18:31:17 -0700 (PDT) Message-ID: <536C2FE5.8040506@isi.edu> Date: Thu, 08 May 2014 18:31:17 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Frits Vaandrager , tcpm@ietf.org References: <536A30E8.8040702@cs.ru.nl> In-Reply-To: <536A30E8.8040702@cs.ru.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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/7QEewL8QhL8pNQlzrEWHYU6shbU Cc: fiteraup@yahoo.com Subject: Re: [tcpm] TCP implementations in Windows8 and Ubuntu violate standard? 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, 09 May 2014 01:32:06 -0000 On 5/7/2014 6:11 AM, Frits Vaandrager wrote: > In my group at the Radboud University Nijmegen, the Netherlands, we do > research on automata learning. We develop algorithms that allow us to > learn state diagrams of black box systems by providing inputs and > observing outputs. > > Together with my students Paul Fiterau and Ramon Janssen, we just > completed a paper in which we describe how we learned models of small > fragments of TCP for Windows8 and Ubuntu 13.10 implementations: > http://www.mbsd.cs.ru.nl/publications/papers/fvaan/TCP/. > > Based on these results, we conclude that both Ubuntu 13.10 and Windows8 > do not conform to the > TCP standard. On page 37 RFC793 says: > > 3. If the connection is in a synchronized state (ESTABLISHED, > FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, LAST-ACK, TIME-WAIT), > any unacceptable segment (out of window sequence number or > unacceptible acknowledgment number) must elicit only an empty > acknowledgment segment containing the current send-sequence number > and an acknowledgment indicating the next sequence number expected > to be received, and the connection remains in the same state. > > We discovered that when an Ubuntu server is in CLOSE_WAIT state and > the client sends an ACK or a FIN+ACK with a valid seq number but an > invalid ack number, the server sometimes does not return any message. > In Windows 8 the required acknowledgment segment is never sent. > > We would be very interested to hear your opinion on these findings. > Is this indeed a violation of the standard? Is this a known issue? It seems so (we'd have to check in detail). I don't recall anyone raising it before. The key question is why this requirement was given. It seems like it's intended to help the sender of the unacceptable segment to determine that it had outstanding data to resend, or that it had exceeded the receiver's window. The behavior you saw might cause connections to not recover properly, to either retransmit data it already had or to drop connections that could have been recovered after a loss or receiver change (e.g., if the receive window were made smaller during a connection). The "practical" relevance depends on how often you expect this to occur, and whether the current behavior is acceptable vs. full recovery. Joe From nobody Fri May 9 04:29: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 6AA491A0277 for ; Fri, 9 May 2014 04:29:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 p27NbRC7Cags for ; Fri, 9 May 2014 04:29:29 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 6E94A1A0285 for ; Fri, 9 May 2014 04:29:27 -0700 (PDT) X-AuditID: c1b4fb2d-f79036d00000126a-b5-536cbc12bf06 Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id C1.0E.04714.21CBC635; Fri, 9 May 2014 13:29:22 +0200 (CEST) Received: from ESESSMB205.ericsson.se ([169.254.5.151]) by ESESSHC018.ericsson.se ([153.88.183.72]) with mapi id 14.03.0174.001; Fri, 9 May 2014 13:29:21 +0200 From: Ingemar Johansson S To: "Scheffenegger, Richard" , Joe Touch Thread-Topic: Definition of flow control Thread-Index: Ac9q1P5l8lakquPSTkuQiSApD4VCwgABiV7AACeczNA= Date: Fri, 9 May 2014 11:29:21 +0000 Message-ID: <81564C0D7D4D2A4B9A86C8C7404A13DA31F60858@ESESSMB205.ericsson.se> References: <81564C0D7D4D2A4B9A86C8C7404A13DA31F5FDE0@ESESSMB205.ericsson.se> <012C3117EDDB3C4781FD802A8C27DD4F4A384FAA@SACEXCMBX02-PRD.hq.netapp.com> In-Reply-To: <012C3117EDDB3C4781FD802A8C27DD4F4A384FAA@SACEXCMBX02-PRD.hq.netapp.com> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.147] Content-Type: multipart/alternative; boundary="_000_81564C0D7D4D2A4B9A86C8C7404A13DA31F60858ESESSMB205erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuphkeLIzCtJLcpLzFFi42KZGfG3RldoT06wwbo7GhYr/51ht9h2cj6T xbo/c1kcmD2WLPnJ5LH7/VYWjxmfvrAFMEdx2aSk5mSWpRbp2yVwZRxt+s9W0JBSseTmA/YG xq6oLkZODgkBE4mrE3exQthiEhfurWfrYuTiEBI4yijRMe88M4SzmFHi6uvNLCBVbAI2EisP fWcEsUUE3CW69jaB2cwCyhLLj01nB7GFBdQlGmfvY+pi5ACq0ZC43cIKUW4lsXbhY7ASFgEV iUuz/jCB2LwCvhIbrl8BiwsJzGCUePhMGcTmFAiV2P38Kth4RgFZifvf77FArBKXuPVkPhPE 0QISS/aA3Alii0q8fPyPFWSthICSxLStaSAms0C+xMEVgRCbBCVOznzCMoFRdBaSQbMQqmYh qYIo0ZO4MXUKG4StLbFs4WtmCFtXYsa/QyzI4gsY2VcxihanFhfnphsZ66UWZSYXF+fn6eWl lmxiBEbfwS2/dXcwrn7teIhRgINRiYdX4Vh2sBBrYllxZe4hRmkOFiVx3ra73sFCAumJJanZ qakFqUXxRaU5qcWHGJk4OKUaGNO6wg4nrXqw59y7+v3vV528Ha541eWN42ELvnJVl0v6qo9+ 1azlvs14vO/J3t7cR3vf65lxR7I/miLGt1d2zdFtWSH/Im9aTXlsOmfRzCUv/i1V/+Oq1nc0 Togjd0LwJHGHqApxud0x34LX2y0M3eJ8KpinNXEu7+7TZrc2m5WseFp/WqbzzAolluKMREMt 5qLiRACMfQwcnwIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/PjmQzASHBsMbGXCmxcOAuB8IyuE Cc: "tcpm@ietf.org" Subject: Re: [tcpm] Definition of flow control 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, 09 May 2014 11:29:32 -0000 --_000_81564C0D7D4D2A4B9A86C8C7404A13DA31F60858ESESSMB205erics_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thanks all, the TCP laminar definition "transmission scheduling algorithm" = helped me a lot, most important I did not need to rewrite the whole documen= t /Ingemar From: Scheffenegger, Richard [mailto:rs@netapp.com] Sent: den 8 maj 2014 18:36 To: Ingemar Johansson S; tcpm@ietf.org Subject: RE: Definition of flow control Hi Ingemar, if it really is only the function of "when to send" rather than "what to se= nd", that would probably be called scheduler (unfortunately, the "what"/"wh= en" are mingled together inseparable in most stacks - perhaps not in Lamina= r: https://developers.google.com/speed/protocols/tcp-laminar There, the term "transmission scheduling algorithm" is used... Richard Scheffenegger From: tcpm [mailto:tcpm-bounces@ietf.org] On Behalf Of Ingemar Johansson S Sent: Donnerstag, 08. Mai 2014 17:55 To: tcpm@ietf.org Subject: [tcpm] Definition of flow control Hi I am writing up a paper that is fairly TCP-ish. I have a problem regarding = the definition of the part of TCP that does the job to keep control over th= e packet transmission i.e the "simple" part that transmits segments wheneve= r the bytes in flight is less than the congestion window. I call this part = flow control but this is perhaps wrong ?. What is then the correct term, "r= ate control" or "rate limiting" or ? /Ingemar =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D Ingemar Johansson M.Sc. Senior Researcher Ericsson AB Wireless Access Networks Labratoriegr=E4nd 11 971 28, Lule=E5, Sweden Phone +46-1071 43042 SMS/MMS +46-73 078 3289 ingemar.s.johansson@ericsson.com www.ericsson.com "Those are my principles, and if you don't like them... well, I have others." Groucho Marx =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D --_000_81564C0D7D4D2A4B9A86C8C7404A13DA31F60858ESESSMB205erics_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Thanks all, the TCP la= minar definition “transmission scheduling algorithm” helped me a lot, most important I did not need t= o rewrite the whole document

 

/Ingemar

 

From: Scheffen= egger, Richard [mailto:rs@netapp.com]
Sent: den 8 maj 2014 18:36
To: Ingemar Johansson S; tcpm@ietf.org
Subject: RE: Definition of flow control

 

&n= bsp;

Hi Inge= mar,

&n= bsp;

if it really is only t= he function of „when to send“ rather than „what to send&#= 8220;, that would probably be called scheduler (unfortunately, the „w= hat“/“when“ are mingled together inseparable in most stac= ks – perhaps not in Laminar:

 

https://developers.google.c= om/speed/protocols/tcp-laminar

 

There, the term “= ;transmission scheduling algorithm” is used…<= /p>

 

 

Richard Scheffenegger

 

From: tcpm [mailto:tcpm-bounces@ietf.org] On Behalf Of Ingemar Johansson S
Sent: Donnerstag, 08. Mai 2014 17:55
To: tcpm@ietf.org
Subject: [tcpm] Definition of flow control

 

Hi

 

I am writing up a paper that is fairly TCP-ish. I ha= ve a problem regarding the definition of the part of TCP that does the job = to keep control over the packet transmission i.e the “simple” p= art that transmits segments whenever the bytes in flight is less than the congestion window. I call this part flow contro= l but this is perhaps wrong ?. What is then the correct term, “rate c= ontrol” or “rate limiting” or ?

 

/Ingemar

=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D

Ingemar Joh= ansson  M.Sc.

Senior Rese= archer

 =

Ericsson AB=

Wireless Ac= cess Networks

Labratorieg= r=E4nd 11

971 28, Lul= e=E5, Sweden

Phone += 46-1071 43042

SMS/MMS = 3;46-73 078 3289

ingemar.s.johansson@ericsson.com

www.ericsson.com

 =

“Those are my principles, and if you don't like them...
well, I have others.”  Groucho Marx
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D

 

 

--_000_81564C0D7D4D2A4B9A86C8C7404A13DA31F60858ESESSMB205erics_-- From nobody Fri May 9 07:45: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 576321A001A for ; Fri, 9 May 2014 07:45:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651] 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 tTWOhLW3FNE2 for ; Fri, 9 May 2014 07:45:38 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [72.246.2.115]) by ietfa.amsl.com (Postfix) with ESMTP id A03731A0010 for ; Fri, 9 May 2014 07:45:38 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id A2A6847576 for ; Fri, 9 May 2014 14:45:33 +0000 (GMT) Received: from prod-mail-relay02.akamai.com (prod-mail-relay02.akamai.com [172.17.50.21]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id 96C3347567 for ; Fri, 9 May 2014 14:45:33 +0000 (GMT) Received: from [172.28.115.172] (bowill.kendall.corp.akamai.com [172.28.115.172]) by prod-mail-relay02.akamai.com (Postfix) with ESMTP id 8D67FFE054 for ; Fri, 9 May 2014 14:45:33 +0000 (GMT) Message-ID: <536CEA0D.1040101@akamai.com> Date: Fri, 09 May 2014 10:45:33 -0400 From: Brandon Williams User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: tcpm@ietf.org References: <20140430142220.21274.18191.idtracker@ietfa.amsl.com> <53610C3B.6070006@akamai.com> <53614C68.8040301@mti-systems.com> In-Reply-To: <53614C68.8040301@mti-systems.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/kLFF5GFX_f5YZttzM94TWeCRjcM Subject: Re: [tcpm] New Version Notification for draft-williams-exp-tcp-host-id-opt-03.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: Fri, 09 May 2014 14:45:40 -0000 Lars and Wes, I understand and share the objections to adding options in-transit that have been raised on the list. It's bad and should be avoided if there is any other technically feasible option for solving a problem. On the other hand, I also recognize that NATs do exist and they frequently cause significant problems, including load-balancing, policy control, and attack-mitigation. Is there something specific in our analysis of the problem and possible solution sets that you consider to be flawed? Or is it simply your opinion that the negative side-affects of adding options in-transit are worse than the negative consequences of treating all hosts behind a NAT as if they were the same entity? Considering the fact that some day (fingers crossed) IPv6 will become the norm and NATs will fall out of use, I'm more interested in focusing on the proxy use case. I have a harder time understanding your objections in the context of this use case (esp. for transport layer proxies), since the option is applied to the packet by the TCP stack itself, rather than being applied in-transit. In reference to the application proxy use case, Wes has said previously "[It] is better done at the application layer. ... I wouldn't feel strongly against [this case], it's just not good architecture." But what about the case of transport layer proxies that aren't involved at the application layer? Or receiver-side use cases where the information must be applied before the data stream even shows up to be delivered? Is it that you just don't consider these to be legitimate use cases? In addition to the above, an argument was made on the list (by Wes) that there is value to driving vendors to converge on a common option rather than continuing with the fragmented solution space that exists today. It is already the case that multiple vendors (those the authors represent) are attempting to use the draft for this purpose, and we have every reason to believe, based on our interactions with other vendors (see for example a thread on the list re: the dante socks proxy), that some other vendors would move to the common format if the draft is adopted and published. What number of vendors moving to a common format would be considered large enough for this argument to be persuasive? If you have the time, any further elaboration from you on the above questions would be greatly appreciated. Thanks, --Brandon On 04/30/2014 03:18 PM, Wesley Eddy wrote: > On 4/30/2014 10:51 AM, Eggert, Lars wrote: >> For the record, I am opposed to the WG taking this document on, and I >> am opposed to it being published as an RFC on any stream. >> > > > My opinion is similar. > > An RFC isn't necessary to use an ExID. It doesn't require IETF > approval, and is unlikely to get IETF approval, in order to do > this in a system, if you really want to discount the problems > and do it anyways. > > -- Brandon Williams; Senior Principal Software Engineer Emerging Products Engineering; Akamai Technologies Inc. From nobody Mon May 12 11:48: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 396A21A077B for ; Mon, 12 May 2014 11:48:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] 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 gd3TEnkqV16T for ; Mon, 12 May 2014 11:48:33 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 24D841A076A for ; Mon, 12 May 2014 11:48:31 -0700 (PDT) Received: from [10.133.205.183] (UAPublic-35.guest.arizona.edu [206.207.225.35]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id s4CIltCo014148 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 12 May 2014 11:47:58 -0700 (PDT) Message-ID: <5371175B.4070608@isi.edu> Date: Mon, 12 May 2014 11:47:55 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: "tcpm@ietf.org" References: <20140512184357.12356.22258.idtracker@ietfa.amsl.com> In-Reply-To: <20140512184357.12356.22258.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20140512184357.12356.22258.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed 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/DAXaBUmblbBeVMceGcyTzpxMKX8 Subject: [tcpm] Fwd: New Version Notification for draft-touch-tcp-ao-encrypt-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, 12 May 2014 18:48:36 -0000 FYI - this may be of interest to TCPM, though it's primarily aimed at the TCPCRYPT discussions. Feedback welcome on either list. Joe -------- Original Message -------- Subject: New Version Notification for draft-touch-tcp-ao-encrypt-01.txt Date: Mon, 12 May 2014 11:43:57 -0700 From: internet-drafts@ietf.org To: Dr. Joseph D. Touch , Joe Touch A new version of I-D, draft-touch-tcp-ao-encrypt-01.txt has been successfully submitted by Joe Touch and posted to the IETF repository. Name: draft-touch-tcp-ao-encrypt Revision: 01 Title: A TCP Authentication Option Extension for Payload Encryption Document date: 2014-05-12 Group: Individual Submission Pages: 9 URL: http://www.ietf.org/internet-drafts/draft-touch-tcp-ao-encrypt-01.txt Status: https://datatracker.ietf.org/doc/draft-touch-tcp-ao-encrypt/ Htmlized: http://tools.ietf.org/html/draft-touch-tcp-ao-encrypt-01 Diff: http://www.ietf.org/rfcdiff?url2=draft-touch-tcp-ao-encrypt-01 Abstract: This document describes an extension to the TCP Authentication Option (TCP-AO) to encrypt the TCP segment payload in addition to providing TCP-AO's authentication of the payload, TCP header, and IP pseudoheader. This extension augments how the packet contents and headers are processed and which keys are derived, and adds a capability for in-band coordination of unauthenticated Diffie- Hellman key exchange at connection establishment. The extension preserves key rollover coordination and protection of long-lived connections. 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 May 12 14:34: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 0BCC81A0772 for ; Mon, 12 May 2014 14:34:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] 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 aG67p57vd5Cl for ; Mon, 12 May 2014 14:34:15 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id CE63A1A076F for ; Mon, 12 May 2014 14:34:15 -0700 (PDT) Received: from [10.133.205.183] (UAPublic-35.guest.arizona.edu [206.207.225.35]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id s4CLXQi1019854 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 12 May 2014 14:33:36 -0700 (PDT) Message-ID: <53713E27.9030902@isi.edu> Date: Mon, 12 May 2014 14:33:27 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Brandon Williams , tcpm@ietf.org References: <20140430142220.21274.18191.idtracker@ietfa.amsl.com> <53610C3B.6070006@akamai.com> <53614C68.8040301@mti-systems.com> <536CEA0D.1040101@akamai.com> In-Reply-To: <536CEA0D.1040101@akamai.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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/_RvxWlUaQglARBy_tDAsSyYi-Yo Subject: Re: [tcpm] New Version Notification for draft-williams-exp-tcp-host-id-opt-03.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, 12 May 2014 21:34:17 -0000 Hi, all, Although I appreciate some concerns about this doc, I don't quite share them. A key concern is whether this encourages middleboxes to alter TCP options. IMO, a middlebox that alters an IP address and TCP port is taking on the role of "host" to the public side. In that case, it is responsible for any options that are related to those values - including this one. I.e., so long as we restrict this to devices that set IP addresses and/or TCP ports, I see no problem. If the issue is that "middleboxes shouldn't alter TCP options", then the real issue is that such middleboxes shouldn't alter IP addresses or ports. Joe On 5/9/2014 7:45 AM, Brandon Williams wrote: > Lars and Wes, > > I understand and share the objections to adding options in-transit that > have been raised on the list. It's bad and should be avoided if there is > any other technically feasible option for solving a problem. On the > other hand, I also recognize that NATs do exist and they frequently > cause significant problems, including load-balancing, policy control, > and attack-mitigation. Is there something specific in our analysis of > the problem and possible solution sets that you consider to be flawed? > Or is it simply your opinion that the negative side-affects of adding > options in-transit are worse than the negative consequences of treating > all hosts behind a NAT as if they were the same entity? > > Considering the fact that some day (fingers crossed) IPv6 will become > the norm and NATs will fall out of use, I'm more interested in focusing > on the proxy use case. I have a harder time understanding your > objections in the context of this use case (esp. for transport layer > proxies), since the option is applied to the packet by the TCP stack > itself, rather than being applied in-transit. In reference to the > application proxy use case, Wes has said previously "[It] is better done > at the application layer. ... I wouldn't feel strongly against [this > case], it's just not good architecture." But what about the case of > transport layer proxies that aren't involved at the application layer? > Or receiver-side use cases where the information must be applied before > the data stream even shows up to be delivered? Is it that you just don't > consider these to be legitimate use cases? > > In addition to the above, an argument was made on the list (by Wes) that > there is value to driving vendors to converge on a common option rather > than continuing with the fragmented solution space that exists today. It > is already the case that multiple vendors (those the authors represent) > are attempting to use the draft for this purpose, and we have every > reason to believe, based on our interactions with other vendors (see for > example a thread on the list re: the dante socks proxy), that some other > vendors would move to the common format if the draft is adopted and > published. What number of vendors moving to a common format would be > considered large enough for this argument to be persuasive? > > If you have the time, any further elaboration from you on the above > questions would be greatly appreciated. > > Thanks, > --Brandon > > On 04/30/2014 03:18 PM, Wesley Eddy wrote: >> On 4/30/2014 10:51 AM, Eggert, Lars wrote: >>> For the record, I am opposed to the WG taking this document on, and I >>> am opposed to it being published as an RFC on any stream. >>> >> >> >> My opinion is similar. >> >> An RFC isn't necessary to use an ExID. It doesn't require IETF >> approval, and is unlikely to get IETF approval, in order to do >> this in a system, if you really want to discount the problems >> and do it anyways. >> >> > From nobody Tue May 13 00:15:25 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 9661B1A01AE for ; Tue, 13 May 2014 00:15:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.553 X-Spam-Level: X-Spam-Status: No, score=-7.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, 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 k615yUusbeT5 for ; Tue, 13 May 2014 00:15:23 -0700 (PDT) Received: from mx1.netapp.com (mx1.netapp.com [216.240.18.38]) by ietfa.amsl.com (Postfix) with ESMTP id 40F2F1A019A for ; Tue, 13 May 2014 00:15:22 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.97,1042,1389772800"; d="asc'?scan'208";a="325159629" Received: from vmwexceht03-prd.hq.netapp.com ([10.106.76.241]) by mx1-out.netapp.com with ESMTP; 13 May 2014 00:15:17 -0700 Received: from SACEXCMBX01-PRD.hq.netapp.com ([169.254.2.246]) by vmwexceht03-prd.hq.netapp.com ([10.106.76.241]) with mapi id 14.03.0123.003; Tue, 13 May 2014 00:15:16 -0700 From: "Eggert, Lars" To: Brandon Williams Thread-Topic: [tcpm] New Version Notification for draft-williams-exp-tcp-host-id-opt-03.txt Thread-Index: AQHPZIO1u/26rztc9k+fT3iqOb4u6Jsq/h4AgA3Y3ICABcuAAA== Date: Tue, 13 May 2014 07:15:16 +0000 Message-ID: <6605BCC3-034D-417C-8B6D-F701F4585887@netapp.com> References: <20140430142220.21274.18191.idtracker@ietfa.amsl.com> <53610C3B.6070006@akamai.com> <53614C68.8040301@mti-systems.com> <536CEA0D.1040101@akamai.com> In-Reply-To: <536CEA0D.1040101@akamai.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.122.105.25] Content-Type: multipart/signed; boundary="Apple-Mail=_13BAF21E-BA96-4323-8096-8A7EA240F517"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/XV0yt_6p-cu9XUFve4I0LO5hgTY Cc: "tcpm@ietf.org" Subject: Re: [tcpm] New Version Notification for draft-williams-exp-tcp-host-id-opt-03.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: Tue, 13 May 2014 07:15:24 -0000 --Apple-Mail=_13BAF21E-BA96-4323-8096-8A7EA240F517 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, apart from the technical disagreement I have with the document, there is = a broader political issue here. The IETF has come to broad consensus that pervasive surveillance = represents an attack on the Internet, and that we are taking engineering = steps to protect privacy. (See http://www.ietf.org/blog/2013/11/ for = example.) Having middleboxes tag flows with options that make identifying = individuals easier goes directly against that stated goal. Lars --Apple-Mail=_13BAF21E-BA96-4323-8096-8A7EA240F517 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----- iQCVAwUBU3HGgNZcnpRveo1xAQJRaAP/Zr/OReDOPnAMyM72sKurRYl6KjCyOxYi C9Wg6PQhD0SiohU4ck4Oc3ONB5tvIgsoHuT7WChj15wK3ipsWIrnJJl9H71tU/Yj BSRFrCcIpAUvTHfHomX8owtc6+9CoGwRz7Ok7PHfPj4Hat3NDdjNVjLDPrSJkEil 1/bBVzOeicQ= =bAYM -----END PGP SIGNATURE----- --Apple-Mail=_13BAF21E-BA96-4323-8096-8A7EA240F517-- From nobody Tue May 13 01:15:32 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 CF18C1A087E for ; Tue, 13 May 2014 01:15:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.301 X-Spam-Level: X-Spam-Status: No, score=-2.301 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 MKb6f6nq0-us for ; Tue, 13 May 2014 01:15:27 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id EDBDA1A087D for ; Tue, 13 May 2014 01:15:26 -0700 (PDT) X-AuditID: c1b4fb30-f790e6d000001067-92-5371d4972e2e Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id B5.C3.04199.794D1735; Tue, 13 May 2014 10:15:20 +0200 (CEST) Received: from ESESSMB205.ericsson.se ([169.254.5.151]) by ESESSHC006.ericsson.se ([153.88.183.36]) with mapi id 14.03.0174.001; Tue, 13 May 2014 10:15:19 +0200 From: Ingemar Johansson S To: "tcpm@ietf.org" Thread-Topic: Problem with Low SSThresh (was I-D Action: draft-ietf-tcpm-newcwv-03.txt) Thread-Index: Ac9uevrHDRZF5TP/SM+28Qj1oLeHCw== Date: Tue, 13 May 2014 08:15:19 +0000 Message-ID: <81564C0D7D4D2A4B9A86C8C7404A13DA31F62CA6@ESESSMB205.ericsson.se> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.16] Content-Type: multipart/alternative; boundary="_000_81564C0D7D4D2A4B9A86C8C7404A13DA31F62CA6ESESSMB205erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrPLMWRmVeSWpSXmKPExsUyM+Jvje6MK4XBBlsXMlr0LZnKbPG6bTaj xaHWmSwW207OZ3Jg8Xj54iarR8/nF0weS5b8ZPI49DwogCWKyyYlNSezLLVI3y6BK2Plmh9s BVv8K1ZckGlg/OfWxcjBISFgIrFljUAXIyeQKSZx4d56ti5GLg4hgaOMEv9O3GGCcJYwSsz6 2sEIUsUmYCOx8tB3MFtEQFli9f0PjCBFzAILGSX+X7jLCpIQFgiR2PJtPhPIBhGBSInHd9Mg 6vUkVj/+yw5iswioSly718IGYvMK+Eqs+rmfBcRmFJCVuP/9HpjNLCAucesJyBiQ6wQkluw5 zwxhi0q8fPyPFcJWlNh5tp0Zoj5fouERxBxeAUGJkzOfsExgFJ6FZNQsJGWzkJRBxPUkbkyd wgZha0ssW/iaGcLWlZjx7xALsvgCRvZVjKLFqcVJuelGRnqpRZnJxcX5eXp5qSWbGIExdnDL b4MdjC+fOx5iFOBgVOLhVeApDBZiTSwrrsw9xCjNwaIkzvvtrHuwkEB6YklqdmpqQWpRfFFp TmrxIUYmDk6pBsb+q7Ov13ntKH2+z2ZD/P3kqJS6eXrLLXrjXs6T3DonVbYu/CFrirTJjMcf vz8w7HSef0R5Tfq6P589C1/kshUknGsSY9voLtZiNfPOQoeHW05wRdXJf5905wfbYQ0nPoai fZucTGt/mj3cd7NB7UbV274rk6OFnJhO/n+0Nfd43LGAQPXUoplKLMUZiYZazEXFiQA1R/Wi kgIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/jhrp5jxuCbe8TO69ICNhUSdEReA Subject: [tcpm] Problem with Low SSThresh (was I-D Action: draft-ietf-tcpm-newcwv-03.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: Tue, 13 May 2014 08:15:31 -0000 --_000_81564C0D7D4D2A4B9A86C8C7404A13DA31F62CA6ESESSMB205erics_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Karen pointed out this thread to me http://www.ietf.org/mail-archive/web/tcpm/current/msg08315.html I started to look closer at this issue quite recently, the problem I have i= s that SSthresh can drop to very low values after only a few lost packets. = I have seen this odd effect earlier but have not bothered with it. The experiment is to run a large FTP transfer over a 1Mbps bottleneck with = min RTT =3D 40ms. No AQM or tail drop queue enabled i.e a buffer bloated sc= enario. TCP NewReno. After 10s I "pull the plug" for 100ms (100% packet drop), this= leads to 5 lost segments. at T =3D10.1s packets are forwarded as usual. What I have seen is that a retransmission timeout is immediately followed b= y a loss event, the effect of which is that SSThresh goes down to 2 MSS. I= t seems to me that the RTO timer value is too low, I have not understood th= e effect completely though. Could the RTO timer be the culprit or is there = some other effect ?. I am running these experiments in a proprietary LTE system simulator, we tr= y to keep it up to date to match the Linux TCP stack reasonably well, it ca= nnot be ruled out however that our implementation miss some important featu= re. /Ingemar =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D Ingemar Johansson M.Sc. Senior Researcher Ericsson AB Wireless Access Networks Labratoriegr=E4nd 11 971 28, Lule=E5, Sweden Phone +46-1071 43042 SMS/MMS +46-73 078 3289 ingemar.s.johansson@ericsson.com www.ericsson.com "Those are my principles, and if you don't like them... well, I have others." Groucho Marx =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D --_000_81564C0D7D4D2A4B9A86C8C7404A13DA31F62CA6ESESSMB205erics_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi

 

Karen pointed out this thread to me

http://www.ietf.org/mail-archive/web/tcpm/current/m= sg08315.html

I started to look closer at this issue quite recentl= y, the problem I have is that SSthresh can drop to very low values after on= ly a few lost packets. I have seen this odd effect earlier but have not bot= hered with it.

 

The experiment is to run a large FTP transfer ove= r a 1Mbps bottleneck with min RTT =3D 40ms. No AQM or tail drop queue enabl= ed i.e a buffer bloated scenario.

TCP NewReno. After 10s I “pull the plugR= 21; for 100ms (100% packet drop), this leads to 5 lost segments. at T =3D10= .1s packets are forwarded as usual.

 

What I have seen is that a retransmission timeout is= immediately followed by a loss event, the effect of which is that SSThresh= goes down to 2 MSS.  It seems to me that the RTO timer value is too l= ow, I have not understood the effect completely though. Could the RTO timer be the culprit or is there some other effect ?= .

 

I am running these experiments in a proprietary LTE = system simulator, we try to keep it up to date to match the Linux TCP stack= reasonably well, it cannot be ruled out however that our implementation mi= ss some important feature.

 

/Ingemar

 

=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D

Ingemar Joh= ansson  M.Sc.

Senior Rese= archer

 =

Ericsson AB=

Wireless Ac= cess Networks

Labratorieg= r=E4nd 11

971 28, Lul= e=E5, Sweden

Phone += 46-1071 43042

SMS/MMS = 3;46-73 078 3289

ingemar.s.johansson@ericsson.com

www.ericsson.com

 =

“Those are my principles, and if you don't like them...
well, I have others.”  Groucho Marx
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

 

 

--_000_81564C0D7D4D2A4B9A86C8C7404A13DA31F62CA6ESESSMB205erics_-- From nobody Tue May 13 02:50:09 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 7811E1A0013 for ; Tue, 13 May 2014 02:50:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.553 X-Spam-Level: X-Spam-Status: No, score=-7.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, 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 qQzfdD7FZa1j for ; Tue, 13 May 2014 02:50:02 -0700 (PDT) Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) by ietfa.amsl.com (Postfix) with ESMTP id 421451A0012 for ; Tue, 13 May 2014 02:50:02 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.97,1043,1389772800"; d="asc'?scan'208";a="164004398" Received: from vmwexceht05-prd.hq.netapp.com ([10.106.77.35]) by mx12-out.netapp.com with ESMTP; 13 May 2014 02:49:52 -0700 Received: from SACEXCMBX01-PRD.hq.netapp.com ([169.254.2.246]) by vmwexceht05-prd.hq.netapp.com ([10.106.77.35]) with mapi id 14.03.0123.003; Tue, 13 May 2014 02:49:52 -0700 From: "Eggert, Lars" To: Brandon Williams Thread-Topic: [tcpm] New Version Notification for draft-williams-exp-tcp-host-id-opt-03.txt Thread-Index: AQHPZIO1u/26rztc9k+fT3iqOb4u6Jsq/h4AgA3Y3ICABcuAAIAAKzQA Date: Tue, 13 May 2014 09:49:51 +0000 Message-ID: References: <20140430142220.21274.18191.idtracker@ietfa.amsl.com> <53610C3B.6070006@akamai.com> <53614C68.8040301@mti-systems.com> <536CEA0D.1040101@akamai.com> <6605BCC3-034D-417C-8B6D-F701F4585887@netapp.com> In-Reply-To: <6605BCC3-034D-417C-8B6D-F701F4585887@netapp.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.122.105.19] Content-Type: multipart/signed; boundary="Apple-Mail=_5A8C8FD5-AF6C-44DC-AFB9-CF10A512FDAA"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/JxsDKp3A_KlPjK5PZErC2nnvS5Y Cc: "tcpm@ietf.org" Subject: Re: [tcpm] New Version Notification for draft-williams-exp-tcp-host-id-opt-03.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: Tue, 13 May 2014 09:50:04 -0000 --Apple-Mail=_5A8C8FD5-AF6C-44DC-AFB9-CF10A512FDAA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii PS: http://tools.ietf.org/html/rfc7258 came out today On 2014-5-13, at 9:15, Eggert, Lars wrote: > Hi, >=20 > apart from the technical disagreement I have with the document, there = is a broader political issue here. >=20 > The IETF has come to broad consensus that pervasive surveillance = represents an attack on the Internet, and that we are taking engineering = steps to protect privacy. (See http://www.ietf.org/blog/2013/11/ for = example.) >=20 > Having middleboxes tag flows with options that make identifying = individuals easier goes directly against that stated goal. >=20 > Lars > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm --Apple-Mail=_5A8C8FD5-AF6C-44DC-AFB9-CF10A512FDAA 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----- iQCVAwUBU3HqvtZcnpRveo1xAQJa7gP9GkP0X8vOIH8uWiriMmE8vhf5KNss0dV9 kITjZwClv69Ti594tviQcuO/83egH4cU//y7fyAaFgjppQzWb2ReGcnBkvan+ztv XsmISpi4GUkrYGHQhP63TZJZuXNRdV4Ryny7hYeHUr1FSmsy/M0Bvqa7jAtoFyEa fr1+C8XJrC4= =KgxW -----END PGP SIGNATURE----- --Apple-Mail=_5A8C8FD5-AF6C-44DC-AFB9-CF10A512FDAA-- From nobody Tue May 13 02:58:04 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 2EB371A0020 for ; Tue, 13 May 2014 02:58:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.553 X-Spam-Level: X-Spam-Status: No, score=-7.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, 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 ovAZ2Zi4vMeT for ; Tue, 13 May 2014 02:57:59 -0700 (PDT) Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) by ietfa.amsl.com (Postfix) with ESMTP id 077231A000B for ; Tue, 13 May 2014 02:57:59 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.97,1043,1389772800"; d="asc'?scan'208";a="164005561" Received: from vmwexceht03-prd.hq.netapp.com ([10.106.76.241]) by mx12-out.netapp.com with ESMTP; 13 May 2014 02:57:53 -0700 Received: from SACEXCMBX04-PRD.hq.netapp.com ([169.254.6.187]) by vmwexceht03-prd.hq.netapp.com ([10.106.76.241]) with mapi id 14.03.0123.003; Tue, 13 May 2014 02:57:52 -0700 From: "Zimmermann, Alexander" To: "draft-ietf-tcpm-rtorestart@tools.ietf.org" , "tcpm@ietf.org Extensions" Thread-Topic: Review of draft-ietf-tcpm-rtorestart-02.txt Thread-Index: AQHPbpHOiZ6uKgZA3Uq6I4ykg9wmvg== Date: Tue, 13 May 2014 09:57:36 +0000 Message-ID: <38DA60FD-7629-4FCB-BD19-830FC7F5232C@netapp.com> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.122.105.18] Content-Type: multipart/signed; boundary="Apple-Mail=_A97F3183-89A8-4C76-960F-AC22490AB2DC"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/czf5I4Uj4wSypzFw5mG4CVe2qVE Subject: [tcpm] Review of draft-ietf-tcpm-rtorestart-02.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: Tue, 13 May 2014 09:58:01 -0000 --Apple-Mail=_A97F3183-89A8-4C76-960F-AC22490AB2DC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi folks, first of all thank you for writing this draft. The draft is clearly = written: the problem is well described, the doc is self-contained (it=92s not = necessary to read dozens of other RFCs to understand the problem), and the authors state = why the doc is experimental and what further experiments are needed for being a = STD. However, on the technical side I see some open points. In detail: * Sec 1, 4. para: =84a considerable number of flows have such = properties=93 Can you backup this with some numbers? This is exactly the point I = raised at the (last?) IETF. I would like to see some data on how severe the problem = is we would like to fix. * Sec 1.1: please change this subsection to a section (1.1 =3D> 2) and = also introduce your new state variable rrthresh here * Sec 1, 5. para: =84Spurious timeouts typically degrade the performance = of flows with multiple bursts of data, as a burst following a spurious timeout = might not fit within the reduced congestion window (cwnd)=93 This is (only) true with respect to your algo, not in general. The = general problem of a spurious timeout is the cwnd reduction, the go-back-N retransmissions, =85 See RFC 3522. After reading section 4.2 of your = draft I understand what you want to see here. Please rephrase the section and = maybe add the spurious RTO RFC as reference. * Sec 3: Suppose FlightSize is 2 and you have exactly one segment to = send, your algo doesn=92t trigger since step 2.b isn=92t true. Bug? I would = say yes. * Sec 3: Why the condition 2.b is different from the early = retransmission condition 2.b or 3.b? Is there any specific reason why we exclude the advertised receive window part from the condition? * Sec 3: IMO the algo/doc is too much Linux driven. I would like to see = a segment-based *and* byte-based version of the algo, like RFC 5827. * General: IMO I would be a little bit easier to read the doc if you = give the algo a proper name. By reading =84RTO restart=93 I had sometimes = trouble to know if mean your algo or the =84action=93 of restarting the RTO. Alex --Apple-Mail=_A97F3183-89A8-4C76-960F-AC22490AB2DC 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 iEYEARECAAYFAlNx7KAACgkQdyiq39b9uS7KOQCgvKrWlBb+ShF5gk+cV+SUQI5B xEEAni/TmWnDaLSR0WqwJriaUPJQyfvk =ulji -----END PGP SIGNATURE----- --Apple-Mail=_A97F3183-89A8-4C76-960F-AC22490AB2DC-- From nobody Tue May 13 05:56: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 C87491A00B3 for ; Tue, 13 May 2014 05:56:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.53 X-Spam-Level: X-Spam-Status: No, score=-1.53 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651] 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 Y-eodajtIrOz for ; Tue, 13 May 2014 05:56:43 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [72.246.2.115]) by ietfa.amsl.com (Postfix) with ESMTP id 64C8E1A00E5 for ; Tue, 13 May 2014 05:56:20 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id E575B4744C for ; Tue, 13 May 2014 12:56:13 +0000 (GMT) Received: from prod-mail-relay06.akamai.com (prod-mail-relay06.akamai.com [172.17.120.126]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id D975647413 for ; Tue, 13 May 2014 12:56:13 +0000 (GMT) Received: from [172.28.115.172] (bowill.kendall.corp.akamai.com [172.28.115.172]) by prod-mail-relay06.akamai.com (Postfix) with ESMTP id CC4602026 for ; Tue, 13 May 2014 12:56:13 +0000 (GMT) Message-ID: <5372166D.2070302@akamai.com> Date: Tue, 13 May 2014 08:56:13 -0400 From: Brandon Williams User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 CC: "tcpm@ietf.org" References: <20140430142220.21274.18191.idtracker@ietfa.amsl.com> <53610C3B.6070006@akamai.com> <53614C68.8040301@mti-systems.com> <536CEA0D.1040101@akamai.com> <6605BCC3-034D-417C-8B6D-F701F4585887@netapp.com> In-Reply-To: <6605BCC3-034D-417C-8B6D-F701F4585887@netapp.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/iWyGOEOdnQkhY2eXbOaANzt-ejk Subject: Re: [tcpm] New Version Notification for draft-williams-exp-tcp-host-id-opt-03.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: Tue, 13 May 2014 12:56:44 -0000 Hi Lars, Regarding the privacy concern, is there something that we have missed in the section about privacy contained in the document? If the guidance provided in the document is followed, then I don't see how the use of this option makes identifying individuals easier. In addition, I argue that the privacy concern is an argument in favor of adopting this draft. TCP options of this nature are in use on the Internet today and will continue to be used going forward. As long as there is no move toward consensus on the option format, number, etc. and as long as people active in the WG actively discourage authors from publishing documents related to this use of the option space, it will be difficult for anonymizing systems to recognize such options and protect anonymity. This is part of the reason why we give direct guidance on this topic in draft. --Brandon On 05/13/2014 03:15 AM, Eggert, Lars wrote: > Hi, > > apart from the technical disagreement I have with the document, there is a broader political issue here. > > The IETF has come to broad consensus that pervasive surveillance represents an attack on the Internet, and that we are taking engineering steps to protect privacy. (See http://www.ietf.org/blog/2013/11/ for example.) > > Having middleboxes tag flows with options that make identifying individuals easier goes directly against that stated goal. > > Lars > -- Brandon Williams; Senior Principal Software Engineer Emerging Products Engineering; Akamai Technologies Inc. From nobody Tue May 13 08:16:28 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 054BC1A0135 for ; Tue, 13 May 2014 08:16:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] 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 9Uz7BfzT-WLJ for ; Tue, 13 May 2014 08:16:06 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id 5765B1A0139 for ; Tue, 13 May 2014 08:16:06 -0700 (PDT) Received: from [10.133.205.183] (UAPublic-35.guest.arizona.edu [206.207.225.35]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id s4DFEodu011992 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 13 May 2014 08:15:00 -0700 (PDT) Message-ID: <537236EC.4090908@isi.edu> Date: Tue, 13 May 2014 08:14:52 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: "Eggert, Lars" , Brandon Williams References: <20140430142220.21274.18191.idtracker@ietfa.amsl.com> <53610C3B.6070006@akamai.com> <53614C68.8040301@mti-systems.com> <536CEA0D.1040101@akamai.com> <6605BCC3-034D-417C-8B6D-F701F4585887@netapp.com> In-Reply-To: <6605BCC3-034D-417C-8B6D-F701F4585887@netapp.com> Content-Type: text/plain; charset=UTF-8; format=flowed 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/eofVTAZL7dOKkYcLkFAaM4TT4C4 Cc: "tcpm@ietf.org" Subject: Re: [tcpm] New Version Notification for draft-williams-exp-tcp-host-id-opt-03.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: Tue, 13 May 2014 15:16:12 -0000 On 5/13/2014 12:15 AM, Eggert, Lars wrote: > Hi, > > apart from the technical disagreement I have with the document, there is a broader political issue here. I certainly hope not, but the IESG Chair warned us about this (see below), so we shouldn't be surprised. > The IETF has come to broad consensus that pervasive surveillance represents an attack on the Internet, It would be more useful for the iETF to take positions on devices that undermine its architecture (e.g., NATs) and protocols that are deployed against current technical advice (CUBIC). > and that we are taking engineering steps to protect privacy. (See http://www.ietf.org/blog/2013/11/ for example.) The IESG Chair's report on the conclusion of community discussion specifically addressed the use of this document to block other docs: --- 3) The document, particularly as a BCP, could be used to block documents by ADs in an unreasonable fashion. There was considerable concern about this. However, the IESG process for document approval is most commonly not based on specific rules in existing RFCs, but rather specific technical concerns of the individual AD reviewers. ADs occasionally raise invalid issues on documents, and we expect (and get) pushback when that happens. I have certainly made mistakes when filing a Discuss. These are resolved through discussion. In more severe cases, we have override procedures, appeals, discussions with the Nomcom, and recall procedures to deal with these issues. In other words, if we start from the assumption of a misbehaving AD, no new documents are needed to file an inappropriate Discuss. Any AD can raise concerns about pervasive monitoring under the current Discuss criteria, and this document doesn't change that. We don't think this document will significantly change things for the worse. However, the IESG felt that there is an opportunity to clarify our procedures with regards to this specific case: The IESG intends to make a change to its Discuss criteria statement [3]. While the general thrust of the statement already indicates that AD disagreement with informed WG consensus is a NOT an acceptable basis for a discuss, we wanted to say that more explicitly in the specific context of adequate consideration for pervasive monitoring issues. Section 3.2 of the Discuss criteria statement is about criteria that are not appropriate basis for a Discuss. We plan to say that while it is generally necessary that IETF work considers the impact of specific threats such as pervasive surveillance, informed and rational community decisions about the particular protocols and the possible need for mitigating mechanisms will be respected. > Having middleboxes tag flows with options that make identifying individuals easier goes directly against that stated goal. First, we're talking about use of this option by middleboxes and endpoints that already change host IDs (not personal IDs). Second, this mechanism can easily be used to obfuscate the identification hosts, to re-group them in alternate ways. Finally, I sincerely hope this draft's process doesn't become the poster child of the process fears raised by the IESG Chair in approving perpass and recommending it as BCP. Joe From nobody Tue May 13 09:30: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 4E7341A0126 for ; Tue, 13 May 2014 09:30:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.553 X-Spam-Level: X-Spam-Status: No, score=-2.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, 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 2yLS2W0dwC78 for ; Tue, 13 May 2014 09:30:33 -0700 (PDT) Received: from mx11.netapp.com (mx11.netapp.com [216.240.18.76]) by ietfa.amsl.com (Postfix) with ESMTP id A40D41A00DD for ; Tue, 13 May 2014 09:30:33 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.97,1044,1389772800"; d="asc'?scan'208";a="122859856" Received: from vmwexceht01-prd.hq.netapp.com ([10.106.76.239]) by mx11-out.netapp.com with ESMTP; 13 May 2014 09:30:27 -0700 Received: from SACEXCMBX01-PRD.hq.netapp.com ([169.254.2.246]) by vmwexceht01-prd.hq.netapp.com ([10.106.76.239]) with mapi id 14.03.0123.003; Tue, 13 May 2014 09:30:27 -0700 From: "Eggert, Lars" To: Joe Touch Thread-Topic: [tcpm] New Version Notification for draft-williams-exp-tcp-host-id-opt-03.txt Thread-Index: AQHPZIO1u/26rztc9k+fT3iqOb4u6Jsq/h4AgA3Y3ICABcuAAIAAhgQAgAAVGoA= Date: Tue, 13 May 2014 16:30:26 +0000 Message-ID: <48454865-68C8-4F93-BF64-D9F05C53DB6A@netapp.com> References: <20140430142220.21274.18191.idtracker@ietfa.amsl.com> <53610C3B.6070006@akamai.com> <53614C68.8040301@mti-systems.com> <536CEA0D.1040101@akamai.com> <6605BCC3-034D-417C-8B6D-F701F4585887@netapp.com> <537236EC.4090908@isi.edu> In-Reply-To: <537236EC.4090908@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.122.105.28] Content-Type: multipart/signed; boundary="Apple-Mail=_91ED03DA-F428-4901-84B8-23B1B730CD3D"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/v9y3ZRUP_GGoIvZ4M9ISbxOJ8i8 Cc: "tcpm@ietf.org" Subject: Re: [tcpm] New Version Notification for draft-williams-exp-tcp-host-id-opt-03.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: Tue, 13 May 2014 16:30:35 -0000 --Apple-Mail=_91ED03DA-F428-4901-84B8-23B1B730CD3D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, On 2014-5-13, at 17:14, Joe Touch wrote: > It would be more useful for the iETF to take positions on devices that = undermine its architecture (e.g., NATs) and protocols that are deployed = against current technical advice (CUBIC). We're getting off-topic here, but what "current technical advice" is = Cubic violating?=20 It's not an IETF standard, and it's on by default in Linux and that's = not so nice, but it doesn't seem to be have serious flaws (anymore). So = while I wish there was an ID we could progress (and I have it on my list = to talk to Injong and get his OK for someone else to carry the torch), I = think you're overstating things. >> and that we are taking engineering steps to protect privacy. (See = http://www.ietf.org/blog/2013/11/ for example.) >=20 > The IESG Chair's report on the conclusion of community discussion = specifically addressed the use of this document to block other docs: The text you quoted is entirely about what ADs should and should not do = *during IESG processing*. I'm not an AD (anymore), and I am certainly = free to make this argument as an individual *during a call for WG = adoption*. >> Having middleboxes tag flows with options that make identifying = individuals easier goes directly against that stated goal. >=20 > First, we're talking about use of this option by middleboxes and = endpoints that already change host IDs (not personal IDs). Sure. But I don't see why this is relevant. In some sense CGNs - as problematic as they are - actually increase = privacy, because more users share an IP address. This document is about = counteracting this increased privacy. And since we don't know by what = mechanism these host IDs get set, and given that the document talks = about potentially quite large ID namespace (32bits), you could actually = identify things at a finer granularity than hosts. > Second, this mechanism can easily be used to obfuscate the = identification hosts, to re-group them in alternate ways. How and by whom? Even if hosts end up setting it, it'll get stripped out = or rewritten by an ISP middlebox that can set it based on subscriber = information and current connection context. > Finally, I sincerely hope this draft's process doesn't become the = poster child of the process fears raised by the IESG Chair in approving = perpass and recommending it as BCP. So I actually hope it does. In my view, the reason that the text you = quoted was entirely about the IESG process was to not have late = surprises happen to stuff that are already WG documents or in IETF last = call. But that's not the case here. This is not a WG document, and using the = BCP - that we have IETF consensus on - as an argument to not *start* = problematic work is entirely reasonable. If not, what *can* we use that = consensus BCP for? Feeling good about ourselves without actually doing = anything? Lars --Apple-Mail=_91ED03DA-F428-4901-84B8-23B1B730CD3D 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----- iQCVAwUBU3JIn9ZcnpRveo1xAQINcgP7BBPztgPqD1mkkIAACooYa9VwXcaLDQIG PF9T5JVckWc6IAM7/QNb65p5k+bKYcxdtUPsa5r1KTmU8Jbup9YZN0n5IRrnWLNX 3oajesxy+AhhSzGSkkcl2/lT+FCLP/mpVZMN2mxOzqEmblO7M+qrUo2W8yBWGWRc r7VdSP1ze0c= =PDSt -----END PGP SIGNATURE----- --Apple-Mail=_91ED03DA-F428-4901-84B8-23B1B730CD3D-- From nobody Tue May 13 09:56: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 DA3AA1A0115 for ; Tue, 13 May 2014 09:56:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] 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 WtMY7PUx8yHQ for ; Tue, 13 May 2014 09:56:42 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id D6F5C1A0107 for ; Tue, 13 May 2014 09:56:42 -0700 (PDT) Received: from [10.133.205.183] (UAPublic-35.guest.arizona.edu [206.207.225.35]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id s4DGu9ru010268 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 13 May 2014 09:56:19 -0700 (PDT) Message-ID: <53724EAB.2040604@isi.edu> Date: Tue, 13 May 2014 09:56:11 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: "Eggert, Lars" References: <20140430142220.21274.18191.idtracker@ietfa.amsl.com> <53610C3B.6070006@akamai.com> <53614C68.8040301@mti-systems.com> <536CEA0D.1040101@akamai.com> <6605BCC3-034D-417C-8B6D-F701F4585887@netapp.com> <537236EC.4090908@isi.edu> <48454865-68C8-4F93-BF64-D9F05C53DB6A@netapp.com> In-Reply-To: <48454865-68C8-4F93-BF64-D9F05C53DB6A@netapp.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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/eKDoeN6qySTuUBjyavyurK6NVC8 Cc: "tcpm@ietf.org" Subject: Re: [tcpm] New Version Notification for draft-williams-exp-tcp-host-id-opt-03.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: Tue, 13 May 2014 16:56:45 -0000 On 5/13/2014 9:30 AM, Eggert, Lars wrote: > Hi, > > On 2014-5-13, at 17:14, Joe Touch wrote: >> It would be more useful for the iETF to take positions on devices that undermine its architecture (e.g., NATs) and protocols that are deployed against current technical advice (CUBIC). > > We're getting off-topic here, but what "current technical advice" is Cubic violating? > > It's not an IETF standard, RFC5681 >>> and that we are taking engineering steps to protect privacy. (See http://www.ietf.org/blog/2013/11/ for example.) >> >> The IESG Chair's report on the conclusion of community discussion specifically addressed the use of this document to block other docs: > > The text you quoted is entirely about what ADs should and should not > do *during IESG processing*. I'm not an AD (anymore), and I am certainly > free to make this argument as an individual *during a call for WG adoption*. Agreed. However, the entirety of the message indicated basically that the Chair was taking very rough - at best - consensus about a draft and making it BCP even though the community is widely split on the issue. >>> Having middleboxes tag flows with options that make identifying individuals easier goes directly against that stated goal. >> >> First, we're talking about use of this option by middleboxes and endpoints that already change host IDs (not personal IDs). > > Sure. But I don't see why this is relevant. Middleboxes create a problem that this is intended to let *them* fix. > In some sense CGNs - as problematic as they are - actually increase > privacy, because more users share an IP address. This document is about > counteracting this increased privacy. It's about letting *them* not provide that privacy where privacy wasn't intended. > And since we don't know by what > mechanism these host IDs get set, and given that the document talks > about potentially quite large ID namespace (32bits), you could actually > identify things at a finer granularity than hosts. You can also use ARP to find out the manufacturer of a NIC. We aren't deprecating ARP because of privacy concerns. You can also have existing NATs and CGNs expose host privacy in the source IP and port number selected, as well as in other fields that could easily be modified for their nefarious uses (e.g., ISNs). I don't see this new political statement as requiring WGs to scrub their protocols for all *potential* or *perceived* issues with privacy. >> Second, this mechanism can easily be used to obfuscate the identification hosts, to re-group them in alternate ways. > > How and by whom? > Even if hosts end up setting it, it'll get stripped > out or rewritten by an ISP middlebox that can set it based on subscriber > information and current connection context. First, that depends on whether they're protected by the endpoint or not - e.g., IPsec or TCP-AO could allow the source endpoint to set this information usefully, and prevent a middlebox from obfuscating it. >> Finally, I sincerely hope this draft's process doesn't become the >> poster child of the process fears raised by the IESG Chair in approving >> perpass and recommending it as BCP. > > So I actually hope it does. If so, I predict it will be the death of the IETF as a technical body. I can't speak for others, but I don't participate here to express my political positions. > But that's not the case here. This is not a WG document, and using > theBCP - that we have IETF consensus on Every rough consensus, and an IESG Chair that set the document type *after* last call. > - as an argument to not *start* > problematic work is entirely reasonable. If not, what *can* we use that > consensus BCP for? Feeling good about ourselves without actually doing > anything? In this case, it can and should drive the use cases discussed and security considerations presented. However, unless this mechanism provides more opportunity for tracking than existing protocols and mechanisms, I don't think it should be used to block it. Joe From nobody Thu May 15 03:00: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 918581A0492 for ; Thu, 15 May 2014 03:00:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.25 X-Spam-Level: X-Spam-Status: No, score=-2.25 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_LOW=-0.7] 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 hG4oViEQ-Q_S for ; Thu, 15 May 2014 03:00:44 -0700 (PDT) Received: from nasse.dc.kau.se (smtp.kau.se [193.10.220.39]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 585271A0471 for ; Thu, 15 May 2014 03:00:44 -0700 (PDT) X-Spam-Processed: mail.kau.se, Thu, 15 May 2014 12:00:17 +0200 (not processed: spam filter heuristic analysis disabled) X-Authenticated-Sender: perhurt@kau.se X-MDRemoteIP: 130.243.26.112 X-Return-Path: per.hurtig@kau.se X-Envelope-From: per.hurtig@kau.se Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Per Hurtig In-Reply-To: <38DA60FD-7629-4FCB-BD19-830FC7F5232C@netapp.com> Date: Thu, 15 May 2014 12:00:18 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <8CEBB7AD-88F3-45CA-A1C6-D5306EEE02B3@kau.se> References: <38DA60FD-7629-4FCB-BD19-830FC7F5232C@netapp.com> To: "Zimmermann, Alexander" X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/KKN2FUad0z1IMS5XAguTRJsoNQQ Cc: "draft-ietf-tcpm-rtorestart@tools.ietf.org" , "tcpm@ietf.org Extensions" Subject: Re: [tcpm] Review of draft-ietf-tcpm-rtorestart-02.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, 15 May 2014 10:00:46 -0000 Hi Alexander thanks for the review, please see my comments inline=85 On 13 May 2014, at 11:57, Zimmermann, Alexander = wrote: > Hi folks, >=20 > first of all thank you for writing this draft. The draft is clearly = written: the > problem is well described, the doc is self-contained (it=92s not = necessary to read > dozens of other RFCs to understand the problem), and the authors state = why the > doc is experimental and what further experiments are needed for being = a STD. > However, on the technical side I see some open points. In detail: >=20 > * Sec 1, 4. para: =84a considerable number of flows have such = properties=93 > Can you backup this with some numbers? This is exactly the point I = raised at the > (last?) IETF. I would like to see some data on how severe the problem = is we would > like to fix. >=20 For short flows (e.g. web) there are a number of references in the = draft. These are the primary target for the mechanism. We=92ll elaborate some more on the = importance for other types of traffic.=20 > * Sec 1.1: please change this subsection to a section (1.1 =3D> 2) and = also > introduce your new state variable rrthresh here >=20 I don=92t get why the section should be renumbered. The =93terminology=94 = is often the last subsection of the introduction of most drafts and RFCs. = Furthermore, it seems=20 slightly overkill to introduce the variable there. RFCs that manages = many more=20 variables, e.g. RFC6298 does not explicitly introduce any variable in = this section. > * Sec 1, 5. para: =84Spurious timeouts typically degrade the = performance of flows > with multiple bursts of data, as a burst following a spurious timeout = might > not fit within the reduced congestion window (cwnd)=93 >=20 > This is (only) true with respect to your algo, not in general. The = general > problem of a spurious timeout is the cwnd reduction, the go-back-N > retransmissions, =85 See RFC 3522. After reading section 4.2 of your = draft I > understand what you want to see here. Please rephrase the section and = maybe > add the spurious RTO RFC as reference. >=20 What is meant is the actual cwnd reduction. We should clarify this. > * Sec 3: Suppose FlightSize is 2 and you have exactly one segment to = send, > your algo doesn=92t trigger since step 2.b isn=92t true. Bug? I would = say yes. >=20 Good catch! The question is if it=92s worth fixing since the algorithm = will become more complex and the situation you mention is really a corner = case that requires either (i) the cwnd to be exactly 3 segments large; or (ii) = having a packet written to the socket just between previous data transmission and = the arrival of the acknowledgment. Furthermore, this mechanism is only an optimization to the standard = timer. So if it doesn=92t work in this particular scenario it won=92t break = anything. It will just not be triggered.=20 > * Sec 3: Why the condition 2.b is different from the early = retransmission > condition 2.b or 3.b? Is there any specific reason why we exclude the > advertised receive window part from the condition? >=20 Because the advertised window can be small in situations where it=92s = not preferable to use RTO restart. For instance, in the middle of a transfer = where it=92s better to wait for fast/early retransmit to kick in. > * Sec 3: IMO the algo/doc is too much Linux driven. I would like to = see a > segment-based *and* byte-based version of the algo, like RFC 5827. >=20 Yes, this comment was given by several people at the last IETF. We will = update the draft to address this. > * General: IMO I would be a little bit easier to read the doc if you = give the > algo a proper name. By reading =84RTO restart=93 I had sometimes = trouble to > know if mean your algo or the =84action=93 of restarting the RTO. >=20 Agreed, this will be fixed. Thank you, Per Hurtig >=20 > Alex >=20 >=20 >=20 From nobody Thu May 15 03:58:37 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 979AC1A0028 for ; Thu, 15 May 2014 03:58:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, 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 lhTiic_xt8rC for ; Thu, 15 May 2014 03:58:35 -0700 (PDT) Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05CF51A0027 for ; Thu, 15 May 2014 03:58:34 -0700 (PDT) Received: by mail-wi0-f172.google.com with SMTP id hi2so9561431wib.17 for ; Thu, 15 May 2014 03:58:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:from:date:message-id:subject:to:content-type; bh=s3WuN7bCDFc/iE6jDis4/gM691KNs7UP80rsk+H7Wc4=; b=H68Hxt9HSv9296QwE/c5qIyaI5If9gUbNBFozV7DGrF+nfcTVI0FqROECpf0KCOEAC CWwFmjRZsywIf++Fr1RrJIY4h51TjroSvi9UH+qdgNPjz8NS4dZ29dM5MAHxjfT55tc1 DTdPvFnHzw8NktJUzZyFt9VfOAeTPDPniX4wb+DjvldGeP4TdpWyuNsU7MaXVG3nmdfr 73BjjOI37GR1TPhOEdqcGQemrAVPZKVFiTF0t978WVBq0KAx/y4JlmXE+IMXyBACRYx+ Vqmf69TU1Zri5gnhvS/0kaWjktDs5uzD6jBWK9lg+IOrMjw1FdfXEbV/fo6RSnemRa4l rhdQ== X-Received: by 10.180.82.133 with SMTP id i5mr30879891wiy.50.1400151506865; Thu, 15 May 2014 03:58:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.217.6.8 with HTTP; Thu, 15 May 2014 03:58:06 -0700 (PDT) From: Raffaello Secchi Date: Thu, 15 May 2014 11:58:06 +0100 Message-ID: To: "tcpm@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/eUULgudBO9FTjFPJEChWZnvqCDE Subject: Re: [tcpm] Problem with Low SSThresh (was I-D Action: draft-ietf-tcpm-newcwv-03.txt) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: r.secchi@gmail.com List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 May 2014 10:58:36 -0000 Hi We believe that low ssthresh resetting is a real problem especially in data-limited conditions when few packets are in flight. We've also tried to see what happens when we drop a SYN in Linux. In this case TCP follows the standard and drop the ssthresh to 2 MSS being the SYN the only packet in flight. This is a real harm for a starting connection if the SYN was dropped for non-congestion related reasons (eg due to unsupported TCP options). Raffaello From nobody Thu May 15 10:22: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 B6C331A02D1 for ; Thu, 15 May 2014 10:22:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651, 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 nAJ88HlzWX4R for ; Thu, 15 May 2014 10:22:11 -0700 (PDT) Received: from plsvl-mailgw-01.bluecoat.com (spf.bluecoat.com [199.91.133.11]) by ietfa.amsl.com (Postfix) with ESMTP id 84EC61A02ED for ; Thu, 15 May 2014 10:22:11 -0700 (PDT) Received: from pwsvl-exchts-04.internal.cacheflow.com (esxprd03.bluecoat.com [10.2.2.162]) by plsvl-mailgw-01.bluecoat.com (Postfix) with ESMTP id 57FDB81A180; Thu, 15 May 2014 10:22:04 -0700 (PDT) Received: from pwsvl-excmbx-05.internal.cacheflow.com ([fe80::f848:d461:9aa9:59a8]) by pwsvl-exchts-04.internal.cacheflow.com ([fe80::9403:6f39:feac:adb1%12]) with mapi id 14.03.0123.003; Thu, 15 May 2014 10:22:03 -0700 From: "McAlpine, Gary" To: Ingemar Johansson S , "tcpm@ietf.org" Thread-Topic: Problem with Low SSThresh (was I-D Action: draft-ietf-tcpm-newcwv-03.txt) Thread-Index: Ac9uevrHDRZF5TP/SM+28Qj1oLeHCwB3WJig Date: Thu, 15 May 2014 17:21:57 +0000 Message-ID: References: <81564C0D7D4D2A4B9A86C8C7404A13DA31F62CA6@ESESSMB205.ericsson.se> In-Reply-To: <81564C0D7D4D2A4B9A86C8C7404A13DA31F62CA6@ESESSMB205.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.2.2.106] Content-Type: multipart/alternative; boundary="_000_FD2F17B9B55D72489D521ADC634E4628A44836pwsvlexcmbx05inte_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/YjL-mDlGMF_idqIY1SaxuHwCRSQ Subject: Re: [tcpm] Problem with Low SSThresh (was I-D Action: draft-ietf-tcpm-newcwv-03.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, 15 May 2014 17:22:15 -0000 --_000_FD2F17B9B55D72489D521ADC634E4628A44836pwsvlexcmbx05inte_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Ingemar, I'm not sure what the rational was for dropping ssthresh to 2*MSS, but it s= eems to me that there are too many non-congestion-related events that can c= ause this extreme setting of ssthresh. Once ssthresh gets set so low, the r= eal problem we have seen is recovery on long-lived connections or where an = ssthresh-host-cache is in use. In these cases, the current congestion RFCs = don't provide a specific mechanism for ssthresh to recover to a level that = represents the actual congestion level. So what we have seen are connection= s between a particular client and server go to very low throughput and not = recover for a very long time. In fact, the traffic between the client and s= erver may be such that it can never recover until the connection is dropped= (in the case of a long-lived connections) or the cached ssthresh is reset. To allow our customers to avoid this problem, we have provided two mechanis= ms in our software: 1. They can disable ssthresh-host-cache so that new connections will = always restart ssthresh. 2. Since RFC 5681 paragraph 4.1 is silent on what to do with ssthresh= when restarting idle connections, we assume ssthresh is no longer valid af= ter a sufficiently long idle period. Given the next transfer is going to pe= rform a slow-start that will (essentially) search for the appropriate cwnd = level and restart the ack clock, we also restart ssthresh so that the appr= opriate cwnd level can be found. These mechanisms seem to work quite well and we haven't seen any cases wher= e they have caused other problems, but I would be much happier if the conge= stion RFCs were not so silent on what to do with ssthresh to recover from c= ases where ssthresh gets set to an inappropriately low level. Thanks, Gary From: Ingemar Johansson S [mailto:ingemar.s.johansson@ericsson.com] Sent: Tuesday, May 13, 2014 1:15 AM To: tcpm@ietf.org Cc: Karen E. E. Nielsen; gorry@erg.abdn.ac.uk; McAlpine, Gary Subject: Problem with Low SSThresh (was I-D Action: draft-ietf-tcpm-newcwv-= 03.txt) Hi Karen pointed out this thread to me http://www.ietf.org/mail-archive/web/tcpm/current/msg08315.html I started to look closer at this issue quite recently, the problem I have i= s that SSthresh can drop to very low values after only a few lost packets. = I have seen this odd effect earlier but have not bothered with it. The experiment is to run a large FTP transfer over a 1Mbps bottleneck with = min RTT =3D 40ms. No AQM or tail drop queue enabled i.e a buffer bloated sc= enario. TCP NewReno. After 10s I "pull the plug" for 100ms (100% packet drop), this= leads to 5 lost segments. at T =3D10.1s packets are forwarded as usual. What I have seen is that a retransmission timeout is immediately followed b= y a loss event, the effect of which is that SSThresh goes down to 2 MSS. I= t seems to me that the RTO timer value is too low, I have not understood th= e effect completely though. Could the RTO timer be the culprit or is there = some other effect ?. I am running these experiments in a proprietary LTE system simulator, we tr= y to keep it up to date to match the Linux TCP stack reasonably well, it ca= nnot be ruled out however that our implementation miss some important featu= re. /Ingemar =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D Ingemar Johansson M.Sc. Senior Researcher Ericsson AB Wireless Access Networks Labratoriegr=E4nd 11 971 28, Lule=E5, Sweden Phone +46-1071 43042 SMS/MMS +46-73 078 3289 ingemar.s.johansson@ericsson.com www.ericsson.com "Those are my principles, and if you don't like them... well, I have others." Groucho Marx =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D --_000_FD2F17B9B55D72489D521ADC634E4628A44836pwsvlexcmbx05inte_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Ingemar,=

 

I’m not sure wha= t the rational was for dropping ssthresh to 2*MSS, but it seems to me that = there are too many non-congestion-related events that can cause this extrem= e setting of ssthresh. Once ssthresh gets set so low, the real problem we have seen is recovery on long-lived connec= tions or where an ssthresh-host-cache is in use. In these cases, the curren= t congestion RFCs don’t provide a specific mechanism for ssthresh to = recover to a level that represents the actual congestion level. So what we have seen are connections between a pa= rticular client and server go to very low throughput and not recover for a = very long time. In fact, the traffic between the client and server may be s= uch that it can never recover until the connection is dropped (in the case of a long-lived connections) or the= cached ssthresh is reset.

 

To allow our customers= to avoid this problem, we have provided two mechanisms in our software:

 

1.&n= bsp;      They can disab= le ssthresh-host-cache so that new connections will always restart ssthresh= .

2.&n= bsp;      Since RFC 5681= paragraph 4.1 is silent on what to do with ssthresh when restarting idle c= onnections, we assume ssthresh is no longer valid after a sufficiently long= idle period. Given the next transfer is going to perform a slow-start that will (essentially) search for the ap= propriate cwnd level and restart the ack clock,  we also restart ssthr= esh so that the appropriate cwnd level can be found.

 

These mechanisms seem = to work quite well and we haven’t seen any cases where they have caus= ed other problems, but I would be much happier if the congestion RFCs were = not so silent on what to do with ssthresh to recover from cases where ssthresh gets set to an inappropriately low le= vel.

 

Thanks,

Gary=

 

 

 

From: Ingemar = Johansson S [mailto:ingemar.s.johansson@ericsson.com]
Sent: Tuesday, May 13, 2014 1:15 AM
To: tcpm@ietf.org
Cc: Karen E. E. Nielsen; gorry@erg.abdn.ac.uk; McAlpine, Gary
Subject: Problem with Low SSThresh (was I-D Action: draft-ietf-tcpm-= newcwv-03.txt)

 

Hi

 

Karen pointed out this thread to me

http://www.ietf.org/mail-archive/web/tcpm/current/m= sg08315.html

I started to look closer at this issue quite recentl= y, the problem I have is that SSthresh can drop to very low values after on= ly a few lost packets. I have seen this odd effect earlier but have not bot= hered with it.

 

The experiment is to run a large FTP transfer ove= r a 1Mbps bottleneck with min RTT =3D 40ms. No AQM or tail drop queue enabl= ed i.e a buffer bloated scenario.

TCP NewReno. After 10s I “pull the plugR= 21; for 100ms (100% packet drop), this leads to 5 lost segments. at T =3D10= .1s packets are forwarded as usual.

 

What I have seen is that a retransmission timeout is= immediately followed by a loss event, the effect of which is that SSThresh= goes down to 2 MSS.  It seems to me that the RTO timer value is too l= ow, I have not understood the effect completely though. Could the RTO timer be the culprit or is there some other effect ?= .

 

I am running these experiments in a proprietary LTE = system simulator, we try to keep it up to date to match the Linux TCP stack= reasonably well, it cannot be ruled out however that our implementation mi= ss some important feature.

 

/Ingemar

 

=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D

Ingemar Joh= ansson  M.Sc.

Senior Rese= archer

 =

Ericsson AB=

Wireless Ac= cess Networks

Labratorieg= r=E4nd 11

971 28, Lul= e=E5, Sweden

Phone += 46-1071 43042

SMS/MMS = 3;46-73 078 3289

ingemar.s.johansson@ericsson.com

www.ericsson.com

 =

“Those are my principles, and if you don't like them...
well, I have others.”  Groucho Marx
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D

 

 

--_000_FD2F17B9B55D72489D521ADC634E4628A44836pwsvlexcmbx05inte_-- From nobody Fri May 16 06:49: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 EDB881A01F5 for ; Fri, 16 May 2014 06:49:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 kTS5GgRfzP8w for ; Fri, 16 May 2014 06:49:02 -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 17F651A01A0 for ; Fri, 16 May 2014 06:49:02 -0700 (PDT) Received: by spey.erg.abdn.ac.uk (Postfix, from userid 5001) id 389322B458B; Fri, 16 May 2014 14:48:54 +0100 (BST) Received: from ERG-research.local (gorry-mac.erg.abdn.ac.uk [139.133.207.5]) by spey.erg.abdn.ac.uk (Postfix) with ESMTPSA id 67B5B2B43B3; Fri, 16 May 2014 14:48:51 +0100 (BST) Message-ID: <53761743.6090906@erg.abdn.ac.uk> Date: Fri, 16 May 2014 14:48:51 +0100 From: Gorry Fairhurst Organization: The University of Aberdeen is a charity registered in Scotland, No SC013683. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: "McAlpine, Gary" , Ingemar Johansson S , "tcpm@ietf.org" References: <81564C0D7D4D2A4B9A86C8C7404A13DA31F62CA6@ESESSMB205.ericsson.se> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/b_okoqz1cOnIT_cK46yluO_7hhE Subject: Re: [tcpm] Problem with Low SSThresh (was I-D Action: draft-ietf-tcpm-newcwv-03.txt) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: gorry@erg.abdn.ac.uk List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 May 2014 13:49:05 -0000 Yes - this seems like an oversight in the way ssthresh was conceived. The value is intended to capture congestion history, and hence it's nice to cache this for new flows to prevent them overshooting the bottleneck capacity. I can think of 3 things where current ssthresh methods give unwarranted poor performance: - path changes, presumably uncommon. - historic information (an event hours ago has little bearing on a long-lived connection and is a real impediment when the RTT is large). - non-congestion loss (especially when FS was small) Gorry On 15/05/2014 18:21, McAlpine, Gary wrote: > Hi Ingemar, > > I'm not sure what the rational was for dropping ssthresh to 2*MSS, but it seems to me that there are too many non-congestion-related events that can cause this extreme setting of ssthresh. Once ssthresh gets set so low, the real problem we have seen is recovery on long-lived connections or where an ssthresh-host-cache is in use. In these cases, the current congestion RFCs don't provide a specific mechanism for ssthresh to recover to a level that represents the actual congestion level. So what we have seen are connections between a particular client and server go to very low throughput and not recover for a very long time. In fact, the traffic between the client and server may be such that it can never recover until the connection is dropped (in the case of a long-lived connections) or the cached ssthresh is reset. > > To allow our customers to avoid this problem, we have provided two mechanisms in our software: > > > 1. They can disable ssthresh-host-cache so that new connections will always restart ssthresh. > > 2. Since RFC 5681 paragraph 4.1 is silent on what to do with ssthresh when restarting idle connections, we assume ssthresh is no longer valid after a sufficiently long idle period. Given the next transfer is going to perform a slow-start that will (essentially) search for the appropriate cwnd level and restart the ack clock, we also restart ssthresh so that the appropriate cwnd level can be found. > > These mechanisms seem to work quite well and we haven't seen any cases where they have caused other problems, but I would be much happier if the congestion RFCs were not so silent on what to do with ssthresh to recover from cases where ssthresh gets set to an inappropriately low level. > > Thanks, > Gary > > > > From: Ingemar Johansson S [mailto:ingemar.s.johansson@ericsson.com] > Sent: Tuesday, May 13, 2014 1:15 AM > To: tcpm@ietf.org > Cc: Karen E. E. Nielsen; gorry@erg.abdn.ac.uk; McAlpine, Gary > Subject: Problem with Low SSThresh (was I-D Action: draft-ietf-tcpm-newcwv-03.txt) > > Hi > > Karen pointed out this thread to me > http://www.ietf.org/mail-archive/web/tcpm/current/msg08315.html > I started to look closer at this issue quite recently, the problem I have is that SSthresh can drop to very low values after only a few lost packets. I have seen this odd effect earlier but have not bothered with it. > > > The experiment is to run a large FTP transfer over a 1Mbps bottleneck with min RTT = 40ms. No AQM or tail drop queue enabled i.e a buffer bloated scenario. > > TCP NewReno. After 10s I "pull the plug" for 100ms (100% packet drop), this leads to 5 lost segments. at T =10.1s packets are forwarded as usual. > > What I have seen is that a retransmission timeout is immediately followed by a loss event, the effect of which is that SSThresh goes down to 2 MSS. It seems to me that the RTO timer value is too low, I have not understood the effect completely though. Could the RTO timer be the culprit or is there some other effect ?. > > I am running these experiments in a proprietary LTE system simulator, we try to keep it up to date to match the Linux TCP stack reasonably well, it cannot be ruled out however that our implementation miss some important feature. > > /Ingemar > > ================================= > Ingemar Johansson M.Sc. > Senior Researcher > > Ericsson AB > Wireless Access Networks > Labratoriegränd 11 > 971 28, Luleå, Sweden > Phone +46-1071 43042 > SMS/MMS +46-73 078 3289 > ingemar.s.johansson@ericsson.com > www.ericsson.com > > "Those are my principles, and if you don't like them... > well, I have others." Groucho Marx > ================================= > > > From nobody Mon May 19 10:54:04 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 506BB1A03A2 for ; Mon, 19 May 2014 10:54:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-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 PhP-B7EI42a0 for ; Mon, 19 May 2014 10:53:59 -0700 (PDT) Received: from hoemail2.alcatel.com (hoemail2.alcatel.com [192.160.6.149]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6ED721A0398 for ; Mon, 19 May 2014 10:53:59 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by hoemail2.alcatel.com (8.13.8/IER-o) with ESMTP id s4JHruoG026823 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 19 May 2014 12:53:57 -0500 (CDT) 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 s4JHrtM7005062 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 19 May 2014 19:53:55 +0200 Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.94]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.02.0247.003; Mon, 19 May 2014 19:53:55 +0200 From: "Scharf, Michael (Michael)" To: Brandon Williams Thread-Topic: [tcpm] Fwd: New Version Notification for draft-williams-exp-tcp-host-id-opt-03.txt Thread-Index: AQHPZIKzBDGcrsnFWUeUzfYjzMxHYZtIP+dQ Date: Mon, 19 May 2014 17:53:54 +0000 Message-ID: <655C07320163294895BBADA28372AF5D2DD865@FR712WXCHMBA15.zeu.alcatel-lucent.com> References: <20140430142220.21274.18191.idtracker@ietfa.amsl.com> <53610C3B.6070006@akamai.com> In-Reply-To: <53610C3B.6070006@akamai.com> 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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/MlPAnv8Dta_Wd0_2Vn4a8KSDpMw Cc: "tcpm@ietf.org" Subject: Re: [tcpm] Fwd: New Version Notification for draft-williams-exp-tcp-host-id-opt-03.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, 19 May 2014 17:54:01 -0000 Hi Brandon, all, Thanks a lot for this update. Indeed, the update takes into account TCPM fe= edback, and this is excellent. However, based on the list discussion so far, it seems to the chairs that t= his document would be a better fit to an independent stream submission. The= TCP option described in this document actually does not modify any TCP log= ic. Identifying the hosts that are hidden behind a shared address/prefix sh= aring device or application-layer proxy seems like a new service that curre= nt TCP does not offer. TCPM is only chartered for minor TCP extensions. Also, in its current form, it seems that this document formally does not re= quire TCPM adoption. While TCPM documents probably (hopefully!) have more w= eight among end-system TCP stack implementers, it is much less clear whethe= r a TCPM document on this specific topic will indeed foster implementation = convergence among middleboxes. We have no empirical evidence for that. TCPM is used to adopt new working group items based on rather strong consen= sus. According to the list discussion so far, the TCPM chairs currently und= erstand that there is no consensus in the TCPM community to adopt this docu= ment at this point in time.=20 Obviously, as usual in the IETF, further list discussion is welcome. Best regards Michael on behalf of the TCPM chairs=20 > -----Original Message----- > From: tcpm [mailto:tcpm-bounces@ietf.org] On Behalf Of Brandon Williams > Sent: Wednesday, April 30, 2014 4:44 PM > To: tcpm@ietf.org > Subject: [tcpm] Fwd: New Version Notification for draft-williams-exp- > tcp-host-id-opt-03.txt >=20 > We have updated the draft based on feedback on the list and in London. > In particular, we have attempted to provide a clearer explanation of > the > use cases we are attempting to address and why solutions at other > layers > in the protocol stack do not work for these use cases. Previous updates > had already attempted to provide stronger limiting guidance for option > usage. >=20 > As we have indicated previously on the list, we would prefer to see WG > adoption of this I.D. rather than working toward publishing as an > individual submission. We think WG adoption has a few benefits, even in > the absence of clear consensus on the question of whether this is a > good > idea. First and foremost, WG adoption would mean that the limiting > guidance on usage carries more weight. And second, WG adoption would > more strongly encourage individual implementations that are already in > use to converge on a single option format. >=20 > We look forward to your feedback. >=20 > Thanks, > --Brandon >=20 >=20 > -------- Original Message -------- > Subject: New Version Notification for > draft-williams-exp-tcp-host-id-opt-03.txt > Date: Wed, 30 Apr 2014 10:22:20 -0400 > From: internet-drafts@ietf.org > To: Williams, Brandon , Dan Wing > , Mohamed Boucadair , > Mohamed Boucadair , Dan Wing > , Williams, Brandon >=20 >=20 > A new version of I-D, draft-williams-exp-tcp-host-id-opt-03.txt > has been successfully submitted by Brandon Williams and posted to the > IETF repository. >=20 > Name: draft-williams-exp-tcp-host-id-opt > Revision: 03 > Title: Experimental Option for TCP Host Identification > Document date: 2014-04-29 > Group: Individual Submission > Pages: 11 > URL: > http://www.ietf.org/internet-drafts/draft-williams-exp-tcp-host-id-opt- > 03.txt > Status: > https://datatracker.ietf.org/doc/draft-williams-exp-tcp-host-id-opt/ > Htmlized: > http://tools.ietf.org/html/draft-williams-exp-tcp-host-id-opt-03 > Diff: > http://www.ietf.org/rfcdiff?url2=3Ddraft-williams-exp-tcp-host-id-opt-03 >=20 > Abstract: > Recent IETF proposals have identified benefits to more distinctly > identifying the hosts that are hidden behind a shared > address/prefix > sharing device or application-layer proxy. Analysis indicates that > the use of a TCP option for this purpose can be successfully > applied > to a broad range of use cases. This document describes a common > experimental TCP option format for host identification. >=20 >=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 > -- > Brandon Williams; Senior Principal Software Engineer > Emerging Products Engineering; Akamai Technologies Inc. >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Mon May 19 12:04:06 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 C72811A00BE for ; Mon, 19 May 2014 12:04:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.58 X-Spam-Level: X-Spam-Status: No, score=0.58 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] 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 R2YgjQ6xD3gP for ; Mon, 19 May 2014 12:04:01 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [IPv6:2001:200:0:8803::53]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 98EF21A01BB for ; Mon, 19 May 2014 12:04:01 -0700 (PDT) Received: from mail-lb0-f181.google.com (mail-lb0-f181.google.com [209.85.217.181]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 3A58F2781B3 for ; Tue, 20 May 2014 04:03:58 +0900 (JST) Received: by mail-lb0-f181.google.com with SMTP id u10so732851lbd.40 for ; Mon, 19 May 2014 12:03:56 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.152.37.72 with SMTP id w8mr3305001laj.71.1400526236828; Mon, 19 May 2014 12:03:56 -0700 (PDT) Received: by 10.114.95.101 with HTTP; Mon, 19 May 2014 12:03:56 -0700 (PDT) In-Reply-To: <20140519175422.3474.37064.idtracker@ietfa.amsl.com> References: <20140519175422.3474.37064.idtracker@ietfa.amsl.com> Date: Mon, 19 May 2014 12:03:56 -0700 Message-ID: From: Yoshifumi Nishida To: "tcpm@ietf.org" Content-Type: multipart/alternative; boundary=089e0160c156d84bdc04f9c56ce6 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/sKl8xUr_KdbDBeTgSWw0rqiQ7BU Subject: [tcpm] Fwd: Publication has been requested for draft-ietf-tcpm-tcp-rfc4614bis-05 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, 19 May 2014 19:04:03 -0000 --089e0160c156d84bdc04f9c56ce6 Content-Type: text/plain; charset=UTF-8 FYI. -- Yoshi ---------- Forwarded message ---------- From: Yoshifumi Nishida Date: Mon, May 19, 2014 at 10:54 AM Subject: Publication has been requested for draft-ietf-tcpm-tcp-rfc4614bis-05 To: mls.ietf@gmail.com Cc: tcpm-chairs@tools.ietf.org, iesg-secretary@ietf.org, draft-ietf-tcpm-tcp-rfc4614bis@tools.ietf.org Yoshifumi Nishida has requested publication of draft-ietf-tcpm-tcp-rfc4614bis-05 as Informational on behalf of the TCPM working group. Please verify the document's state at http://datatracker.ietf.org/doc/draft-ietf-tcpm-tcp-rfc4614bis/ --089e0160c156d84bdc04f9c56ce6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
FYI.
--
Yoshi

---------- Forwarded message ----------
From: Yoshifumi Nishida <nishida@sfc.wide.ad.jp>
Date: Mon, May 19, 2014 at 10:54 AM
Subject: Publication has been reques= ted for draft-ietf-tcpm-tcp-rfc4614bis-05
To: mls.ietf@gmail.com
Cc: tcpm-chairs@tools.ietf.org, iesg-secretary@ietf.org, draft-ietf-tcpm-tcp-rfc4614bis@tools.ietf.o= rg


Yoshifumi Nishida has requested publication of draft-ietf-tcpm-tcp-= rfc4614bis-05 as Informational on behalf of the TCPM working group.

Please verify the document's state at http://datatra= cker.ietf.org/doc/draft-ietf-tcpm-tcp-rfc4614bis/


--089e0160c156d84bdc04f9c56ce6-- From nobody Tue May 20 00:02: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 6CA711A0425 for ; Tue, 20 May 2014 00:02:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 9MF5nV29qS_u for ; Tue, 20 May 2014 00:02:12 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3E621A0285 for ; Tue, 20 May 2014 00:02:11 -0700 (PDT) X-AuditID: c1b4fb3a-f79746d000006fe2-f4-537afdf19671 Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 00.14.28642.1FDFA735; Tue, 20 May 2014 09:02:09 +0200 (CEST) Received: from ESESSMB205.ericsson.se ([169.254.5.196]) by ESESSHC011.ericsson.se ([153.88.183.51]) with mapi id 14.03.0174.001; Tue, 20 May 2014 09:02:08 +0200 From: Ingemar Johansson S To: "gorry@erg.abdn.ac.uk" , "McAlpine, Gary" , "tcpm@ietf.org" Thread-Topic: Problem with Low SSThresh (was I-D Action: draft-ietf-tcpm-newcwv-03.txt) Thread-Index: Ac9uevrHDRZF5TP/SM+28Qj1oLeHCwB3WJigACkcQIAAvg+zAA== Date: Tue, 20 May 2014 07:02:08 +0000 Message-ID: <81564C0D7D4D2A4B9A86C8C7404A13DA31F7FD7A@ESESSMB205.ericsson.se> References: <81564C0D7D4D2A4B9A86C8C7404A13DA31F62CA6@ESESSMB205.ericsson.se> <53761743.6090906@erg.abdn.ac.uk> In-Reply-To: <53761743.6090906@erg.abdn.ac.uk> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpgkeLIzCtJLcpLzFFi42KZGfG3Rvfj36pgg3fv5S36lkxltnjdNpvR 4lDrTBaLbSfnMzmweLx8cZPVo+fzCyaPJUt+Mnkceh4UwBLFZZOSmpNZllqkb5fAldF18zhT wSOzihN//zI2MC7S7mLk4JAQMJE49Cy4i5ETyBSTuHBvPVsXIxeHkMBRRomLOxaxQjhLGCX6 us+xglSxCdhIrDz0nREkISLQzCgxe3kzE0iCWcBY4mJ3AzuILSwQIXHy2VdGkA0iApESj++m gYRFBJwkXmy5BVbOIqAqca7zGAuIzSvgKzH5+A1miGWHGSXW7f4MVsQpoCdxb9F/ZhCbUUBW 4v73eywQu8Qlbj2ZzwRxtoDEkj3nmSFsUYmXj/+xQnymKLG8Xw6iXE/ixtQpbBC2tsSyha+Z IfYKSpyc+YRlAqPYLCRTZyFpmYWkZRaSlgWMLKsYRYtTi4tz042M9FKLMpOLi/Pz9PJSSzYx AqPs4JbfVjsYDz53PMQowMGoxMO7wK0qWIg1say4MvcQozQHi5I4r48MUEggPbEkNTs1tSC1 KL6oNCe1+BAjEwenVANjQRH/4WVH78m8mah0Tl7YW2+WyEK/lEa38G9HtZwkts66K7/l7SIG j+4WJrae9ka3qTnNX++wbFh7fbfwvKBUoydrT+iYTehx9npx8uWpy/GMUatnvanbnn1Yesu9 DkMmppw1kzoYmo9vPjOnuvpm7YHsBYd2diwPCTum+m6zgRRDIWPNrfOJSizFGYmGWsxFxYkA 2zCPOZMCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/NNZRloBYu1-BbW4lR_ZmPV3IFOc Subject: Re: [tcpm] Problem with Low SSThresh (was I-D Action: draft-ietf-tcpm-newcwv-03.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: Tue, 20 May 2014 07:02:16 -0000 Thanks for the response sofar I run a TCP stack that is part of a larger LTE system simulator, I know tha= t it is not a full match of e.g a Linux TCP stack, I am trying to dig into= the Linux TCP code as well as in ns2 code to see if something important is= missing that makes my results unreliable, or if this is infact a flaw in h= ow=20 The setup: 1Mbps bottleneck, RTT ~35ms Large FTP transfer (100MB) No AQM, infinite buffer =3D bufferbloated network Fake path change after 10s, packets are dropped for 100ms - Note! dropper after bottleneck The chain of events that I see are=20 1) DUPACKs received from from T~10.15 to T~14.2s 2) Fast retransmit at T=3D10.17s re-arms RTO timer (3.60s) 2a) CWND restriction. Only one segment transmitted at T=3D17 the remaini= ng segments transmitted at T =3D 12.18s due to CWND restriction, but RTO ti= mer not restarted at T=3D12.18 because of loss recovery state 3. Retransmission timeout at T=3D13.78s DUPACK counter and SACK scoreboard= is reset 4. DUPACK counter=3D3 at T=3D13.81s fast retransmit, SSThresh set to 2MSS = ! I have a few slides that show more detail, I can email them to anyone inter= ested.=20 A questions:=20 In my code the DUPACK counter and the SACK scoreboard is reset at retransm= ission timeout and this is what causes SSThresh to drop to 2MSS in this ca= se. Is this a bug in my code or that it is too simplistic ?, or is it just = the way it should be ?.=20 I am thankful for any pointers to a more comprehensible documentation on ho= w e.g a Linux TCP stack behaves. Now I believe that bufferbloat is at least partly to blame for this, but I = am not yet convinced that it is the full story. Regards /Ingemar > -----Original Message----- > From: Gorry Fairhurst [mailto:gorry@erg.abdn.ac.uk] > Sent: den 16 maj 2014 15:49 > To: McAlpine, Gary; Ingemar Johansson S; tcpm@ietf.org > Cc: Karen E. E. Nielsen > Subject: Re: Problem with Low SSThresh (was I-D Action: draft-ietf-tcpm- > newcwv-03.txt) >=20 > Yes - this seems like an oversight in the way ssthresh was conceived. > The value is intended to capture congestion history, and hence it's nice = to > cache this for new flows to prevent them overshooting the bottleneck > capacity. I can think of 3 things where current ssthresh methods give > unwarranted poor performance: >=20 > - path changes, presumably uncommon. > - historic information (an event hours ago has little bearing on a long= -lived > connection and is a real impediment when the RTT is large). > - non-congestion loss (especially when FS was small) >=20 > Gorry >=20 > On 15/05/2014 18:21, McAlpine, Gary wrote: > > Hi Ingemar, > > > > I'm not sure what the rational was for dropping ssthresh to 2*MSS, but = it > seems to me that there are too many non-congestion-related events that > can cause this extreme setting of ssthresh. Once ssthresh gets set so low= , > the real problem we have seen is recovery on long-lived connections or > where an ssthresh-host-cache is in use. In these cases, the current > congestion RFCs don't provide a specific mechanism for ssthresh to recove= r > to a level that represents the actual congestion level. So what we have s= een > are connections between a particular client and server go to very low > throughput and not recover for a very long time. In fact, the traffic bet= ween > the client and server may be such that it can never recover until the > connection is dropped (in the case of a long-lived connections) or the ca= ched > ssthresh is reset. > > > > To allow our customers to avoid this problem, we have provided two > mechanisms in our software: > > > > > > 1. They can disable ssthresh-host-cache so that new connections w= ill > always restart ssthresh. > > > > 2. Since RFC 5681 paragraph 4.1 is silent on what to do with ssth= resh > when restarting idle connections, we assume ssthresh is no longer valid a= fter > a sufficiently long idle period. Given the next transfer is going to perf= orm a > slow-start that will (essentially) search for the appropriate cwnd level = and > restart the ack clock, we also restart ssthresh so that the appropriate = cwnd > level can be found. > > > > These mechanisms seem to work quite well and we haven't seen any cases > where they have caused other problems, but I would be much happier if the > congestion RFCs were not so silent on what to do with ssthresh to recover > from cases where ssthresh gets set to an inappropriately low level. > > > > Thanks, > > Gary > > > > > > > > From: Ingemar Johansson S [mailto:ingemar.s.johansson@ericsson.com] > > Sent: Tuesday, May 13, 2014 1:15 AM > > To: tcpm@ietf.org > > Cc: Karen E. E. Nielsen; gorry@erg.abdn.ac.uk; McAlpine, Gary > > Subject: Problem with Low SSThresh (was I-D Action: > > draft-ietf-tcpm-newcwv-03.txt) > > > > Hi > > > > Karen pointed out this thread to me > > http://www.ietf.org/mail-archive/web/tcpm/current/msg08315.html > > I started to look closer at this issue quite recently, the problem I ha= ve is > that SSthresh can drop to very low values after only a few lost packets. = I have > seen this odd effect earlier but have not bothered with it. > > > > > > The experiment is to run a large FTP transfer over a 1Mbps bottleneck w= ith > min RTT =3D 40ms. No AQM or tail drop queue enabled i.e a buffer bloated > scenario. > > > > TCP NewReno. After 10s I "pull the plug" for 100ms (100% packet drop), = this > leads to 5 lost segments. at T =3D10.1s packets are forwarded as usual. > > > > What I have seen is that a retransmission timeout is immediately follow= ed > by a loss event, the effect of which is that SSThresh goes down to 2 MSS.= It > seems to me that the RTO timer value is too low, I have not understood th= e > effect completely though. Could the RTO timer be the culprit or is there > some other effect ?. > > > > I am running these experiments in a proprietary LTE system simulator, w= e > try to keep it up to date to match the Linux TCP stack reasonably well, i= t > cannot be ruled out however that our implementation miss some important > feature. > > > > /Ingemar > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > Ingemar Johansson M.Sc. > > Senior Researcher > > > > Ericsson AB > > Wireless Access Networks > > Labratoriegr=E4nd 11 > > 971 28, Lule=E5, Sweden > > Phone +46-1071 43042 > > SMS/MMS +46-73 078 3289 > > > ingemar.s.johansson@ericsson.com > om> > > www.ericsson.com > > > > "Those are my principles, and if you don't like them... > > well, I have others." Groucho > > > Marx > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > > > From nobody Wed May 21 00:36: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 6C57B1A0825 for ; Wed, 21 May 2014 00:36:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.601 X-Spam-Level: X-Spam-Status: No, score=-3.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_MED=-2.3, 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 chVMBLSC-rKN for ; Wed, 21 May 2014 00:36:15 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B4C5C1A0822 for ; Wed, 21 May 2014 00:36:14 -0700 (PDT) X-AuditID: c1b4fb30-f79a56d000006536-f3-537c576b5193 Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id F0.60.25910.B675C735; Wed, 21 May 2014 09:36:12 +0200 (CEST) Received: from eerihug-hybrid.rnd.ki.sw.ericsson.se (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.89) with Microsoft SMTP Server id 14.3.174.1; Wed, 21 May 2014 09:36:11 +0200 Date: Wed, 21 May 2014 09:36:11 +0200 From: Erik Hugne To: Message-ID: <20140521073611.GA1940@eerihug-hybrid.rnd.ki.sw.ericsson.se> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpgluLIzCtJLcpLzFFi42KZGfG3RjcnvCbYYOMBEYttJ+czOTB6LFny kymAMYrLJiU1J7MstUjfLoErY8ab9IJlbBXH//9iamBsYe1i5OSQEDCRePdsFzOELSZx4d56 ti5GLg4hgaOMEleu/YVyDjBKfH99iAWkikVAVeLxqYVMIDabgJbExOcTwWwRAWGJs2097CA2 s4CbxMIXr4CaOTiEBTQlThwTBQnzCnhI7L4xjQ3CFpQ4OfMJC0S5jsSC3Z/AypkFpCWW/+MA CYsKqEhMObkNrFwIyL7/cjb7BEb+WUi6ZyHpnoXQvYCReRWjaHFqcVJuupGRXmpRZnJxcX6e Xl5qySZGYJAd3PLbYAfjy+eOhxgFOBiVeHgVZlQHC7EmlhVX5h5ilOZgURLnvagBFBJITyxJ zU5NLUgtii8qzUktPsTIxMEp1cCYu1d2+92rR7aH8gZLzpJgdX63q20/64XH19xSly1tyGfg 7myYPTejPPryRHPTKP1lWT5KlzLXKM8P8Mifc1zx1VQx7YB74lx5PzpOPmeZfXVHsI18P5dr fGt5X/bsfb5RD/QFa4pZbdZ/37UpaeEUb+mOlV/euv9Rnr1+A0u/j4eT4BF7g8NKLMUZiYZa zEXFiQAdtguGEwIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/MX-4OMBcHCX3SEo_Pu7FObNIdDw Cc: ingemar.s.johansson@ericsson.com, martin.isaksson@ericsson.com Subject: [tcpm] RFC3465:TCP ABC and SACK'ed data 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, 21 May 2014 07:36:16 -0000 TCP ABC (still in the experimental track) defines a method to increase the cwnd based on the bytes being acknowledged, instead of the number of acks that arrive. I am assuming that SACK'ed (RFC2018) data should be included in this calculation, but i could find no mention of this in RFC3465. Could someone confirm this? What i'd like to achieve with this is to solve an issue that follows after a TCP path change where a large portion of the window have been lost. On the new path, the data that was successfully passed to the receiver is sacked and the rest is being retransmitted. This prevents the cwnd from growing and the throughput is very low. Am i correct in that a SACK-aware ABC implementation would allow the cwnd to grow and the "hole in the window" to be closed faster? //E From nobody Wed May 21 01:29: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 4FF8F1A0831 for ; Wed, 21 May 2014 01:29:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.553 X-Spam-Level: X-Spam-Status: No, score=-7.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, 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 bGMkA099ULeL for ; Wed, 21 May 2014 01:29:00 -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 77B281A0829 for ; Wed, 21 May 2014 01:29:00 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.98,878,1392192000"; d="asc'?scan'208";a="165662617" Received: from vmwexceht06-prd.hq.netapp.com ([10.106.77.104]) by mx12-out.netapp.com with ESMTP; 21 May 2014 01:28:58 -0700 Received: from SACEXCMBX04-PRD.hq.netapp.com ([169.254.6.187]) by vmwexceht06-prd.hq.netapp.com ([10.106.77.104]) with mapi id 14.03.0123.003; Wed, 21 May 2014 01:28:59 -0700 From: "Zimmermann, Alexander" To: Per Hurtig Thread-Topic: Review of draft-ietf-tcpm-rtorestart-02.txt Thread-Index: AQHPbpHOiZ6uKgZA3Uq6I4ykg9wmvptB4SgAgAlUdgA= Date: Wed, 21 May 2014 08:28:58 +0000 Message-ID: References: <38DA60FD-7629-4FCB-BD19-830FC7F5232C@netapp.com> <8CEBB7AD-88F3-45CA-A1C6-D5306EEE02B3@kau.se> In-Reply-To: <8CEBB7AD-88F3-45CA-A1C6-D5306EEE02B3@kau.se> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.122.105.30] Content-Type: multipart/signed; boundary="Apple-Mail=_32BC5F03-44C8-4184-902D-CCA4DC299A7F"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/SOcaYB9yWQ9Pb5d-VvOU25d1DfQ Cc: "draft-ietf-tcpm-rtorestart@tools.ietf.org" , "tcpm@ietf.org Extensions" Subject: Re: [tcpm] Review of draft-ietf-tcpm-rtorestart-02.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: Wed, 21 May 2014 08:29:05 -0000 --Apple-Mail=_32BC5F03-44C8-4184-902D-CCA4DC299A7F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi Per, Am 15.05.2014 um 12:00 schrieb Per Hurtig : > Hi Alexander >=20 > thanks for the review, please see my comments inline=85 >=20 >=20 > On 13 May 2014, at 11:57, Zimmermann, Alexander = wrote: >=20 >> Hi folks, >>=20 >> first of all thank you for writing this draft. The draft is clearly = written: the >> problem is well described, the doc is self-contained (it=92s not = necessary to read >> dozens of other RFCs to understand the problem), and the authors = state why the >> doc is experimental and what further experiments are needed for being = a STD. >> However, on the technical side I see some open points. In detail: >>=20 >> * Sec 1, 4. para: =84a considerable number of flows have such = properties=93 >> Can you backup this with some numbers? This is exactly the point I = raised at the >> (last?) IETF. I would like to see some data on how severe the problem = is we would >> like to fix. >>=20 >=20 > For short flows (e.g. web) there are a number of references in the = draft. These are > the primary target for the mechanism. We=92ll elaborate some more on = the importance > for other types of traffic.=20 Your draft focus on two different kinds of flows: a) on short flows and = b) on flows w/ low transmission rates. For the former you give two references [RJ10] = and [FDT13], but not for the latter. You say that =84a considerable number of flows = have such properties=93 and my question was, if you can backup this w/ some = numbers. Additionally, Yuchung reports that he wasn=92t able to see much improvements while = implementing your scheme. Do you have some data that you can share to see how much your = scheme helps to improve the latency? Also I=92m not sure if we really focus on short flows. Is it not rather = the case that we concentrate us on tail losses? Your scheme will not only kick in for = short flows, it gets activated at the end of any stream. Or do I miss something here? = (BTW [FDT13] reports that 77% of the RXmits are RTO-based, it doesn=92t say that 77% = are short flows.) >=20 >=20 >> * Sec 1.1: please change this subsection to a section (1.1 =3D> 2) = and also >> introduce your new state variable rrthresh here >>=20 >=20 > I don=92t get why the section should be renumbered. The =93terminology=94= is often the > last subsection of the introduction of most drafts and RFCs. This was only a nit. In German language we have the grammar rule that = you cannot introduce a subsection x.1 if you don=92t have a second subsection in = the same section. While searching a little bit in the web, it seems that is also valid in = English (http://www.cs.berkeley.edu/~pattrsn/talks/writingtips.html). Anyway, it = was only a nit :-) > Furthermore, it seems=20 > slightly overkill to introduce the variable there. RFCs that manages = many more=20 > variables, e.g. RFC6298 does not explicitly introduce any variable in = this section. and RFC 5681 or RFC 6675 are counterexamples :-) Anyway, the question is = more whether or not we need an additional state variable in the TCB. If you think = that they are cases possible where =82rrthresh=91 should not be initialized with =82dupthresh = + 1', then we should introduce the state variable and explain why we need it. Otherwise, I = recommend do use =82dupthresh + 1=92 instead of 'rrthresh=91 >=20 >> * Sec 1, 5. para: =84Spurious timeouts typically degrade the = performance of flows >> with multiple bursts of data, as a burst following a spurious timeout = might >> not fit within the reduced congestion window (cwnd)=93 >>=20 >> This is (only) true with respect to your algo, not in general. The = general >> problem of a spurious timeout is the cwnd reduction, the go-back-N >> retransmissions, =85 See RFC 3522. After reading section 4.2 of your = draft I >> understand what you want to see here. Please rephrase the section and = maybe >> add the spurious RTO RFC as reference. >>=20 > What is meant is the actual cwnd reduction. We should clarify this. >=20 >=20 >> * Sec 3: Suppose FlightSize is 2 and you have exactly one segment to = send, >> your algo doesn=92t trigger since step 2.b isn=92t true. Bug? I would = say yes. >>=20 > Good catch! The question is if it=92s worth fixing since the algorithm = will > become more complex Not really. You can 1) restart your RTO (as usual), 2) transmit new = data, 3) re-arm your RTO with RTO - T_earliest if FlightSize < 4. In terms of = =84re-arming=93 we did more or less the same in RFC6069=85 > and the situation you mention is really a corner case that > requires either (i) the cwnd to be exactly 3 segments large; less than 4, no? > or (ii) having a > packet written to the socket just between previous data transmission = and the > arrival of the acknowledgment. Yes >=20 > Furthermore, this mechanism is only an optimization to the standard = timer. So > if it doesn=92t work in this particular scenario it won=92t break = anything. Sure, but if we exclude some traffic pattern which we can on the other = hand easily include by a small algo change, we should do that. Nevertheless, = you are right if we only speak here about rare corner cases (and I don=92t = know the answer) we can ignore them. > It will > just not be triggered.=20 >=20 >> * Sec 3: Why the condition 2.b is different from the early = retransmission >> condition 2.b or 3.b? Is there any specific reason why we exclude the >> advertised receive window part from the condition? >>=20 > Because the advertised window can be small in situations where it=92s = not > preferable to use RTO restart. For instance, in the middle of a = transfer where > it=92s better to wait for fast/early retransmit to kick in. Ah, OK I see. Could you please explain this in the draft? Is it valid to = say that RTO restart try to cover all cases where early retransmit does=92t = work? I have the feeling that I not fully understand which cases should be = covered by which algo. >=20 >> * Sec 3: IMO the algo/doc is too much Linux driven. I would like to = see a >> segment-based *and* byte-based version of the algo, like RFC 5827. >>=20 > Yes, this comment was given by several people at the last IETF. We = will update > the draft to address this. >=20 >> * General: IMO I would be a little bit easier to read the doc if you = give the >> algo a proper name. By reading =84RTO restart=93 I had sometimes = trouble to >> know if mean your algo or the =84action=93 of restarting the RTO. >>=20 > Agreed, this will be fixed. >=20 >=20 >=20 > Thank you, > Per Hurtig >=20 >>=20 >> Alex >>=20 >>=20 >>=20 >=20 >=20 --Apple-Mail=_32BC5F03-44C8-4184-902D-CCA4DC299A7F 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 iEYEARECAAYFAlN8Y8gACgkQdyiq39b9uS6GxACgo0Rb2I+IZ6N02dzJiFGu/MTq PbUAoKjcGOst0HViQb1PUhhc9xq6BNTp =C7FO -----END PGP SIGNATURE----- --Apple-Mail=_32BC5F03-44C8-4184-902D-CCA4DC299A7F-- From nobody Wed May 21 01:57: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 7A99A1A031F for ; Wed, 21 May 2014 01:57:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.953 X-Spam-Level: X-Spam-Status: No, score=-1.953 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, 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 rZ3VAF6UteyV for ; Wed, 21 May 2014 01:57:11 -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 3E4691A02F4 for ; Wed, 21 May 2014 01:57:11 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.98,878,1392192000"; d="asc'?scan'208";a="124353878" Received: from vmwexceht03-prd.hq.netapp.com ([10.106.76.241]) by mx11-out.netapp.com with ESMTP; 21 May 2014 01:57:10 -0700 Received: from SACEXCMBX04-PRD.hq.netapp.com ([169.254.6.187]) by vmwexceht03-prd.hq.netapp.com ([10.106.76.241]) with mapi id 14.03.0123.003; Wed, 21 May 2014 01:57:09 -0700 From: "Zimmermann, Alexander" To: Erik Hugne Thread-Topic: [tcpm] RFC3465:TCP ABC and SACK'ed data Thread-Index: AQHPdMddddHPwgB//UW60ClLS35c7ZtLMRYA Date: Wed, 21 May 2014 08:57:09 +0000 Message-ID: <77CAA4D0-EA7F-4704-A185-78220E38F22F@netapp.com> References: <20140521073611.GA1940@eerihug-hybrid.rnd.ki.sw.ericsson.se> In-Reply-To: <20140521073611.GA1940@eerihug-hybrid.rnd.ki.sw.ericsson.se> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.122.105.30] Content-Type: multipart/signed; boundary="Apple-Mail=_A11685F9-C72E-4F09-9D5F-2B8732D831FF"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/ckh15gHc9mEvnF5YVatBQzvr9jc Cc: "ingemar.s.johansson@ericsson.com" , "martin.isaksson@ericsson.com" , "tcpm@ietf.org" Subject: Re: [tcpm] RFC3465:TCP ABC and SACK'ed data 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, 21 May 2014 08:57:12 -0000 --Apple-Mail=_A11685F9-C72E-4F09-9D5F-2B8732D831FF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi, Am 21.05.2014 um 09:36 schrieb Erik Hugne : > TCP ABC (still in the experimental track) defines a method to increase = the cwnd > based on the bytes being acknowledged, instead of the number of acks = that > arrive. I am assuming that SACK'ed (RFC2018) data should be included = in this > calculation, but i could find no mention of this in RFC3465. > Could someone confirm this? No, SACKed data is not included. RFC 5681 says that you increment the = CWND for each ACK received that *cumulatively* acknowledges new data. The same = applies for ABC. SACKed data =84counts=93 as DUPACKs. C&P from RFC 6675: =84For the = purposes of this specification, we define a =84duplicate acknowledgment=93 as a segment = that arrives carrying a SACK block that identifies previously unacknowledged and = un-SACKed octets=85 =84 >=20 > What i'd like to achieve with this is to solve an issue that follows = after a > TCP path change where a large portion of the window have been lost. On = the > new path, the data that was successfully passed to the receiver is = sacked > and the rest is being retransmitted. This prevents the cwnd from = growing and the > throughput is very low. Why? For each received SACK block you will later get a cumulative ACK = (as soon as the retransmission arrives) which includes the SACK block and which = increases the CWND. In other words: as soon as a full ACK arrives (an ACK which covers = the RecoveryPoint), the CWND will increased on the basis of all newly = cumulatively acknowledged data (if ABC is on) Alex >=20 > Am i correct in that a SACK-aware ABC implementation would allow the = cwnd > to grow and the "hole in the window" to be closed faster? >=20 > //E >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm --Apple-Mail=_A11685F9-C72E-4F09-9D5F-2B8732D831FF 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 iEYEARECAAYFAlN8amYACgkQdyiq39b9uS5biwCfbRD2EQWiGZMzO7vgORO8r86i qzAAoN4mSNvTSkF9ALQ2bC84AkqYbomm =0pt4 -----END PGP SIGNATURE----- --Apple-Mail=_A11685F9-C72E-4F09-9D5F-2B8732D831FF-- From nobody Wed May 21 04:46: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 E30251A0538 for ; Wed, 21 May 2014 04:46:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.602 X-Spam-Level: X-Spam-Status: No, score=-3.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_MED=-2.3, 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 rT4Spghsdga0 for ; Wed, 21 May 2014 04:46:33 -0700 (PDT) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF29F1A0537 for ; Wed, 21 May 2014 04:46:33 -0700 (PDT) Received: from lawyers.icir.org (envoy.icir.org [192.150.187.30]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id s4LBkSeB004771; Wed, 21 May 2014 04:46:28 -0700 (PDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id C72DB6B339F; Wed, 21 May 2014 07:46:28 -0400 (EDT) To: Erik Hugne From: Mark Allman In-Reply-To: <20140521073611.GA1940@eerihug-hybrid.rnd.ki.sw.ericsson.se> Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Sweet Home Alabama X-URL-0: http://www.icir.org/mallman-files/Document36567.docx X-URL-1: http://www.icir.org/mallman-files/Document35322.xlsx MIME-Version: 1.0 Content-Type: multipart/signed; boundary="--------ma37394-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Wed, 21 May 2014 07:46:28 -0400 Sender: mallman@icir.org Message-Id: <20140521114628.C72DB6B339F@lawyers.icir.org> Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/cx13mnrBRCS_FrF9gYRzm6gjc74 Cc: ingemar.s.johansson@ericsson.com, martin.isaksson@ericsson.com, tcpm@ietf.org Subject: Re: [tcpm] RFC3465:TCP ABC and SACK'ed data X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 May 2014 11:46:36 -0000 ----------ma37394-1 Content-Type: text/plain Content-Disposition: inline > TCP ABC (still in the experimental track) defines a method to increase > the cwnd based on the bytes being acknowledged, instead of the number > of acks that arrive. I am assuming that SACK'ed (RFC2018) data should > be included in this calculation, but i could find no mention of this > in RFC3465. Could someone confirm this? ABC does not include SACK information in its calculations and it cannot include SACK information. ABC applies to slow start---which ends when loss occurs. And, (essentially) SACKs only arrive during loss recovery. So, there is no need for ABC to deal with SACKs. allman ----------ma37394-1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlN8khQACgkQWyrrWs4yIs5kWQCfaviFpfFJ9z4j8maDQVHpfPmt zZgAn2Izsh8BfabrwYW/ck0OOd+p2C4m =Des9 -----END PGP SIGNATURE----- ----------ma37394-1-- From nobody Wed May 21 05:55:28 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 2C3391A0344 for ; Wed, 21 May 2014 05:55:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.601 X-Spam-Level: X-Spam-Status: No, score=-3.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_MED=-2.3, 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 bx9OuoOWHgH6 for ; Wed, 21 May 2014 05:55:22 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA4B41A05C3 for ; Wed, 21 May 2014 05:55:21 -0700 (PDT) X-AuditID: c1b4fb25-f79226d000004024-61-537ca237da45 Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id A7.D5.16420.732AC735; Wed, 21 May 2014 14:55:19 +0200 (CEST) Received: from eerihug-hybrid.rnd.ki.sw.ericsson.se (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.71) with Microsoft SMTP Server id 14.3.174.1; Wed, 21 May 2014 14:55:18 +0200 Date: Wed, 21 May 2014 14:55:18 +0200 From: Erik Hugne To: Mark Allman Message-ID: <20140521125518.GC1940@eerihug-hybrid.rnd.ki.sw.ericsson.se> References: <20140521073611.GA1940@eerihug-hybrid.rnd.ki.sw.ericsson.se> <20140521114628.C72DB6B339F@lawyers.icir.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <20140521114628.C72DB6B339F@lawyers.icir.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrMLMWRmVeSWpSXmKPExsUyM+Jvja75oppgg0evRSymrZnGZLHt5Hwm ByaPf4duMnssWfKTKYApissmJTUnsyy1SN8ugSuj88dO1oIGroof524xNTD+ZO9i5OCQEDCR 2PnSsouRE8gUk7hwbz1bFyMXh5DAUUaJ3RvPMEM4B4CcEx/YQKpYBFQl7rzZxghiswloSUx8 PpEJxBYRUJKYuW8lC4jNLBAp8fzFXLAaYaAFez8eBbN5BTwkGlfcZQWxhQQqJLZuv84EEReU ODnzCVSvjsSC3Z/YQI5jFpCWWP6PAyTMKWAlMWXuDbBWUQEViSknt7FBjFGRuP9yNvsERsFZ SCbNQjJpFsKkBYzMqxhFi1OLk3LTjYz1Uosyk4uL8/P08lJLNjECQ/Xglt+qOxgvv3E8xCjA wajEw6swozpYiDWxrLgy9xCjNAeLkjjvRQ2gkEB6YklqdmpqQWpRfFFpTmrxIUYmDk6pBsbQ 6e8NTm3k3bqoaa1T8X1djvbWlyxZdxgXfTmUt2jGva6ES+uTbl2PDzuyprOHPe7vpJanLB9q Pmx0f/nxq5XNrBkKQhOviXTc6uw66XScx/aIfJzE/D4//xBBFb6pdadU2Sv7FIr6Zllb5eUG 1W1du6uHVYNJXDmzWG29SOOzC23/O+1XpSqxFGckGmoxFxUnAgCT1aw7NgIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/tP-h3DmyHKFfypa10UB7iaHkazY Cc: ingemar.s.johansson@ericsson.com, martin.isaksson@ericsson.com, tcpm@ietf.org Subject: Re: [tcpm] RFC3465:TCP ABC and SACK'ed data 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, 21 May 2014 12:55:24 -0000 On Wed, May 21, 2014 at 07:46:28AM -0400, Mark Allman wrote: > > > TCP ABC (still in the experimental track) defines a method to increase > > the cwnd based on the bytes being acknowledged, instead of the number > > of acks that arrive. I am assuming that SACK'ed (RFC2018) data should > > be included in this calculation, but i could find no mention of this > > in RFC3465. Could someone confirm this? > > ABC does not include SACK information in its calculations and it cannot > include SACK information. ABC applies to slow start---which ends when > loss occurs. And, (essentially) SACKs only arrive during loss recovery. > So, there is no need for ABC to deal with SACKs. > Thanks for taking the time to explain this. The problem (this is related to Ingemars posts around "Problem with low SSthresh") is that following the path change, there is a large train of segments being lost (say 150k out of a 500k window). Data at the end of the window did make it through and is SACK'ed. Upon receiving these SACK's the sending side enters loss recovery. It will take a very long time before recovering the 100k lost segments. An aggressive recovery algorithm would mitigate the effects of this, but i was hoping for a more elegant solution. //E From nobody Wed May 21 06:02:28 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 536101A0675 for ; Wed, 21 May 2014 06:02:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.602 X-Spam-Level: X-Spam-Status: No, score=-3.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_MED=-2.3, 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 f3EZ041TMc06 for ; Wed, 21 May 2014 06:02:26 -0700 (PDT) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 483651A05C3 for ; Wed, 21 May 2014 06:02:26 -0700 (PDT) Received: from lawyers.icir.org (envoy.icir.org [192.150.187.30]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id s4LD2Jgp014064; Wed, 21 May 2014 06:02:19 -0700 (PDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 316366B41D6; Wed, 21 May 2014 09:02:20 -0400 (EDT) To: Erik Hugne From: Mark Allman In-Reply-To: <20140521125518.GC1940@eerihug-hybrid.rnd.ki.sw.ericsson.se> Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Sweet Home Alabama X-URL-0: http://www.icir.org/mallman-files/Document5807.docx X-URL-1: http://www.icir.org/mallman-files/Document91600.html MIME-Version: 1.0 Content-Type: multipart/signed; boundary="--------ma41948-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Wed, 21 May 2014 09:02:20 -0400 Sender: mallman@icir.org Message-Id: <20140521130220.316366B41D6@lawyers.icir.org> Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/9qt95n5kp6BMFc-YlgcrtVtEmdc Cc: ingemar.s.johansson@ericsson.com, martin.isaksson@ericsson.com, tcpm@ietf.org Subject: Re: [tcpm] RFC3465:TCP ABC and SACK'ed data X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 May 2014 13:02:27 -0000 ----------ma41948-1 Content-Type: text/plain Content-Disposition: inline > The problem (this is related to Ingemars posts around "Problem with > low SSthresh") is that following the path change, there is a large > train of segments being lost (say 150k out of a 500k window). Data at > the end of the window did make it through and is SACK'ed. Upon > receiving these SACK's the sending side enters loss recovery. It will > take a very long time before recovering the 100k lost segments. > > An aggressive recovery algorithm would mitigate the effects of this, > but i was hoping for a more elegant solution. You may be able to define some solution to this problem, but out of the box TCP is just going to see a loss event and going to use whatever usual loss recovery procedure it uses in this case. ABC is just a riff on slow start. And, not slow start that follows an RTO because the cumulative ACKs are not to be believed in that case (plus, delayed ACKs should not be in play anyway, making byte counting less needed). allman ----------ma41948-1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlN8o9wACgkQWyrrWs4yIs50wQCfRO0ZUEwAhN9SdYIim21iEb1B NWMAn2/btl7POomj7kisLntjhEwkiFLM =58rI -----END PGP SIGNATURE----- ----------ma41948-1-- From nobody Wed May 21 23:48: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 A882D1A00E8 for ; Wed, 21 May 2014 23:48:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.953 X-Spam-Level: X-Spam-Status: No, score=-6.953 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, 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 ANtBX4KFliZD for ; Wed, 21 May 2014 23:47:59 -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 30AC21A00E2 for ; Wed, 21 May 2014 23:47:58 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.98,885,1392192000"; d="scan'208";a="165871565" Received: from vmwexceht05-prd.hq.netapp.com ([10.106.77.35]) by mx12-out.netapp.com with ESMTP; 21 May 2014 23:47:57 -0700 Received: from SACEXCMBX02-PRD.hq.netapp.com ([169.254.1.105]) by vmwexceht05-prd.hq.netapp.com ([10.106.77.35]) with mapi id 14.03.0123.003; Wed, 21 May 2014 23:47:57 -0700 From: "Scheffenegger, Richard" To: Erik Hugne , Mark Allman Thread-Topic: [tcpm] RFC3465:TCP ABC and SACK'ed data Thread-Index: AQHPdOpMIkRphbR4jEewdEhoEX/3rZtLc1kAgAAcbSA= Date: Thu, 22 May 2014 06:47:56 +0000 Message-ID: <012C3117EDDB3C4781FD802A8C27DD4F4A3C3904@SACEXCMBX02-PRD.hq.netapp.com> References: <20140521073611.GA1940@eerihug-hybrid.rnd.ki.sw.ericsson.se> <20140521114628.C72DB6B339F@lawyers.icir.org> <20140521125518.GC1940@eerihug-hybrid.rnd.ki.sw.ericsson.se> In-Reply-To: <20140521125518.GC1940@eerihug-hybrid.rnd.ki.sw.ericsson.se> Accept-Language: de-AT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.122.105.20] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/J-b-RULgOQz7quOr4SydsmdhB6Y Cc: "ingemar.s.johansson@ericsson.com" , "martin.isaksson@ericsson.com" , "tcpm@ietf.org" Subject: Re: [tcpm] RFC3465:TCP ABC and SACK'ed data 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, 22 May 2014 06:48:00 -0000 Are you perhaps observing an effect of the ACK clock loss, when you refer t= o a huge number of consecutive lost segments? Standard SACK does suffer from an issue that during loss recovery, there ma= y be a gap (SACKs don't clock out new/retransmitted packets while flightsiz= e > cwnd (which is now 1/2); only during the 2nd half, SACK starts to clock= out packets, but at the same rate as before (which may not that bright an = idea if a path change with differnet characteristics is now there). RateHalving (Linux has some kind of variant of this) / Proportional Rate Re= duction RFC6937 may be the thing that you are after? ABC really only comes into play during slowstart, to make connections which= use delayed ACKs not perform much less aggressive than sessions where the = receiver features QuickAck (Linux non-standard). Best regards, Richard Scheffenegger > -----Original Message----- > From: tcpm [mailto:tcpm-bounces@ietf.org] On Behalf Of Erik Hugne > Sent: Mittwoch, 21. Mai 2014 14:55 > To: Mark Allman > Cc: ingemar.s.johansson@ericsson.com; martin.isaksson@ericsson.com; > tcpm@ietf.org > Subject: Re: [tcpm] RFC3465:TCP ABC and SACK'ed data >=20 > On Wed, May 21, 2014 at 07:46:28AM -0400, Mark Allman wrote: > > > > > TCP ABC (still in the experimental track) defines a method to > > > increase the cwnd based on the bytes being acknowledged, instead of > > > the number of acks that arrive. I am assuming that SACK'ed (RFC2018) > > > data should be included in this calculation, but i could find no > > > mention of this in RFC3465. Could someone confirm this? > > > > ABC does not include SACK information in its calculations and it > > cannot include SACK information. ABC applies to slow start---which > > ends when loss occurs. And, (essentially) SACKs only arrive during los= s > recovery. > > So, there is no need for ABC to deal with SACKs. > > >=20 > Thanks for taking the time to explain this. >=20 > The problem (this is related to Ingemars posts around "Problem with low > SSthresh") is that following the path change, there is a large train of > segments being lost (say 150k out of a 500k window). Data at the end of > the window did make it through and is SACK'ed. Upon receiving these SACK'= s > the sending side enters loss recovery. It will take a very long time > before recovering the 100k lost segments. >=20 > An aggressive recovery algorithm would mitigate the effects of this, but = i > was hoping for a more elegant solution. >=20 > //E >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Thu May 22 10:10: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 C46041A0252 for ; Thu, 22 May 2014 10:10:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.252 X-Spam-Level: X-Spam-Status: No, score=-3.252 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651, 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 RzugH0AziBIS for ; Thu, 22 May 2014 10:10:40 -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 3C2771A0270 for ; Thu, 22 May 2014 10:10:39 -0700 (PDT) Received: from EVMHR01-UKBR.domain1.systemhost.net (193.113.108.40) by EVMHR67-UKRD.bt.com (10.187.101.22) with Microsoft SMTP Server (TLS) id 8.3.348.2; Thu, 22 May 2014 18:10:36 +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; Thu, 22 May 2014 18:10:36 +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, 22 May 2014 18:10:35 +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 s4MHAY4S002037; Thu, 22 May 2014 18:10:34 +0100 Message-ID: <201405221710.s4MHAY4S002037@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 22 May 2014 18:10:33 +0100 To: Joe Touch From: Bob Briscoe In-Reply-To: <655C07320163294895BBADA28372AF5D2D009E@FR712WXCHMBA15.zeu. alcatel-lucent.com> References: <20140425221257.12559.43206.idtracker@ietfa.amsl.com> <2586_1398464386_535ADF82_2586_915_1_535ADF56.9050106@isi.edu> <5363AF84.8090701@mti-systems.com> <5363B397.8090009@isi.edu> <655C07320163294895BBADA28372AF5D2CFE36@FR712WXCHMBA15.zeu.alcatel-lucent.com> <20140503122950.GM44329@verdi> <655C07320163294895BBADA28372AF5D2D009E@FR712WXCHMBA15.zeu.alcatel-lucent.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/mx8wpzwlM_GKxERkwzh9eVPUzLk Cc: "tcpm@ietf.org" Subject: Re: [tcpm] New Version Notification for draft-touch-tcpm-tcp-edo-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: Thu, 22 May 2014 17:10:42 -0000 Joe, Returning to the question of adoption, we have to=20 address the question of why previous attempts to=20 do this have failed. I don't believe it is as=20 simple as that they tried to include options on=20 SYNs, so all we have to do is avoid the SYN problem. 1) There is obviously the re-segmentation=20 problem, which Olivier/Costin have usefully=20 highlighted, and I agree an optional checksum would at least detect this. 2) However, I think the main problem is that many=20 important cases will need as large or larger TCP=20 option space on the SYN as on non-SYNs. The option space pressure for all the following=20 (except SACK) is at least as critical for the SYN as for non-SYN segments: * SACK (SYN << non-SYN) * MPTCP (SYN > non-SYN - typically) * Timestamp (SYN =3D non-SYN) * Window scale (SYN > non-SYN) * TCP-AO (SYN =3D non-SYN) * TFO init (SYN << non-SYN - but no use without TFO resume as well) * TFO resume (SYN >> non-SYN) Given the above list, if bigger TCP options are=20 not available for SYNs, is a critical mass really=20 going to be persuaded that it is worth the effort=20 of implementing, deploying, debugging,=20 supporting, etc? And we need a critical mass,=20 because until EDO is deployed at both ends it=20 does nothing, so early implementers have to work on faith. Admittedly, EDO is partly trying to make space=20 for future options and partly trying to solve a=20 problem we already have with existing options.=20 So, I admit that the relative size of existing=20 options is not the whole story. However, even new=20 options have to fit with the existing ones. 3) The EDO draft implies that it is provably=20 impossible to increase the option space on a SYN.=20 A couple of ways have been proposed to solve this problem: * LOIC that sends=20 two parallel SYNs; a regular one and one with a=20 longer TCP option space AND a newly defined=20 checksum calculation, so that it will be discarded by legacy TCPs. * An out-of-band control channel, e.g. Much earlier in this thread, you dismissed the latter, wrongly I believe: > >At 16:00 25/04/2014, Zimmermann, Alexander wrote: > >> * Sec 4: > >> - Should we mention =84draft-paasch-mptcp-control-stream=93 here? > > > > I don't think so, any more than mentioning=20 > FTP's control channel. In both cases, a=20 > separate data channel is used for control info.=20 > The MPTCP approach isn't applicable to=20 > individual TCP connections - it only works in=20 > MPTCP because the group of connections is co-associated. This seems to miss the point that there could be=20 a whole class of solutions where we create an=20 associated connection, precisely in order to add=20 a control channel of unlimited size to one (or=20 more) data channels. This brings its own=20 problems, not least it loses the intrinsic=20 security binding when control and data are in the=20 same segment. So, I wouldn't separate off a=20 control channel if we were starting from scratch.=20 But it's probably the most promising approach,=20 given we have to add a carbuncle to a wart. In fact there are some similarities between=20 parallel SYNs and parallel channels. 4) Finally, the EDO draft cites=20 as if it is just=20 another solution. It's not. It's actually a very=20 useful survey of all the previous attempts to=20 solve this problem, including a useful=20 enumeration of the problems that have to be surmounted. The arguments on this thread show that we don't=20 agree on the problem space. So, I suggest we=20 adopt Anatha's draft, and as we develop it, we=20 agree on the problem we are trying to solve=20 first. Boring, but apparently necessary. You could precis this whole email as "Necessity=20 and impossibility are the mothers of invention". Regards Bob ________________________________________________________________ Bob Briscoe, BT=20 From nobody Thu May 22 10:54:04 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 5DE9C1A0271 for ; Thu, 22 May 2014 10:54:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] 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 t8svpZwee0DZ for ; Thu, 22 May 2014 10:53:55 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id F098E1A0248 for ; Thu, 22 May 2014 10:53:54 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id 45DBEC94A9; Thu, 22 May 2014 13:53:51 -0400 (EDT) Date: Thu, 22 May 2014 13:53:51 -0400 From: John Leslie To: Bob Briscoe Message-ID: <20140522175351.GP19803@verdi> References: <2586_1398464386_535ADF82_2586_915_1_535ADF56.9050106@isi.edu> <5363AF84.8090701@mti-systems.com> <5363B397.8090009@isi.edu> <655C07320163294895BBADA28372AF5D2CFE36@FR712WXCHMBA15.zeu.alcatel-lucent.com> <20140503122950.GM44329@verdi> <655C07320163294895BBADA28372AF5D2D009E@FR712WXCHMBA15.zeu.alcatel-lucent.com> <201405221710.s4MHAY4S002037@bagheera.jungle.bt.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201405221710.s4MHAY4S002037@bagheera.jungle.bt.co.uk> User-Agent: Mutt/1.4.1i Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/ZdkmOpTtBVCO-jZPQd9PP-7Eh_Q Cc: "tcpm@ietf.org" , Joe Touch Subject: Re: [tcpm] New Version Notification for draft-touch-tcpm-tcp-edo-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: Thu, 22 May 2014 17:54:02 -0000 Bob Briscoe wrote: > > Returning to the question of adoption, we have to > address the question of why previous attempts to > do this have failed. I don't believe it is as > simple as that they tried to include options on > SYNs, so all we have to do is avoid the SYN problem. Of course, it's not that simple; but we've so far failed to convince folks that the schemes for expanding option-space for SYNs are safe. > 1) There is obviously the re-segmentation > problem, which Olivier/Costin have usefully > highlighted, and I agree an optional checksum would at least detect this. Yes. > 2) However, I think the main problem is that many > important cases will need as large or larger TCP > option space on the SYN as on non-SYNs. No. We have not yet passed the point where the needed initial-negotiate can't fit in an un-expanded SYN. We will, of course, if we continue to do nothing. :^( > The option space pressure for all the following > (except SACK) is at least as critical for the SYN as for non-SYN segments: > * SACK (SYN << non-SYN) > * MPTCP (SYN > non-SYN - typically) > * Timestamp (SYN = non-SYN) > * Window scale (SYN > non-SYN) > * TCP-AO (SYN = non-SYN) > * TFO init (SYN << non-SYN - but no use without TFO resume as well) > * TFO resume (SYN >> non-SYN) Of those, certainly MPTCP can adapt to a really-small SYN. The Timestamp/Window-Scale is scary, but not actually fatal. (We may, of course, need to eventually design a way to push the initial-negotiate issue beyond the _initial_ SYN into the SYN-ACK, but that's not something we need to solve in tcpm-tcp-edo.) > Given the above list, if bigger TCP options are > not available for SYNs, is a critical mass really > going to be persuaded that it is worth the effort > of implementing, deploying, debugging, > supporting, etc? And we need a critical mass, > because until EDO is deployed at both ends it > does nothing, so early implementers have to work on faith. The critical-mass will be slow to develop anyway. What will drive the speed of adoption, IMHO, is whether it is perceived as risk-free. > Admittedly, EDO is partly trying to make space > for future options and partly trying to solve a > problem we already have with existing options. > So, I admit that the relative size of existing > options is not the whole story. However, even new > options have to fit with the existing ones. They can't, already. :^( > 3) The EDO draft implies that it is provably > impossible to increase the option space on a SYN. I don't read it that way. > A couple of ways have been proposed to solve this problem: > * LOIC that sends > two parallel SYNs; a regular one and one with a > longer TCP option space AND a newly defined > checksum calculation, so that it will be discarded by legacy TCPs. That's too big of a change to ask folks to believe it safe. > * An out-of-band control channel, e.g. That's workable, but really doesn't belong as part of an option-space expansion update to TCP. > Much earlier in this thread, you dismissed the latter, wrongly I believe: I don't agree; but that question is not germane. > This seems to miss the point that there could be > a whole class of solutions where we create an > associated connection, precisely in order to add > a control channel of unlimited size to one (or > more) data channels. This brings its own > problems, not least it loses the intrinsic > security binding when control and data are in the > same segment. So, I wouldn't separate off a > control channel if we were starting from scratch. > But it's probably the most promising approach, > given we have to add a carbuncle to a wart. Yes. > 4) Finally, the EDO draft cites > as if it is just > another solution. It's not. It's actually a very > useful survey of all the previous attempts to > solve this problem, including a useful > enumeration of the problems that have to be surmounted. How would _you_ like it cited? > The arguments on this thread show that we don't > agree on the problem space. So, I suggest we > adopt Anatha's draft, and as we develop it, we > agree on the problem we are trying to solve > first. Boring, but apparently necessary. I don't believe we'll be taken seriously trying to resurrect a two-year-old draft. IMHO, we need to concentrate on a smaller piece of the problem. YMMV, of course... -- John Leslie From nobody Thu May 22 10:59: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 19FF11A0216 for ; Thu, 22 May 2014 10:59:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] 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 MS7N_xZ_BRlv for ; Thu, 22 May 2014 10:59:13 -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 594AE1A026C for ; Thu, 22 May 2014 10:59:13 -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 s4MHwbWn010442 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 22 May 2014 10:58:37 -0700 (PDT) Message-ID: <537E3ACD.5000308@isi.edu> Date: Thu, 22 May 2014 10:58:37 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Bob Briscoe References: <20140425221257.12559.43206.idtracker@ietfa.amsl.com> <2586_1398464386_535ADF82_2586_915_1_535ADF56.9050106@isi.edu> <5363AF84.8090701@mti-systems.com> <5363B397.8090009@isi.edu> <655C07320163294895BBADA28372AF5D2CFE36@FR712WXCHMBA15.zeu.alcatel-lucent.com> <20140503122950.GM44329@verdi> <655C07320163294895BBADA28372AF5D2D009E@FR712WXCHMBA15.zeu.alcatel-lucent.com> <201405221710.s4MHAY4S002037@bagheera.jungle.bt.co.uk> In-Reply-To: <201405221710.s4MHAY4S002037@bagheera.jungle.bt.co.uk> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit 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/TzgTKU_4Tkc3tDB0MMvfydiDxOY Cc: "tcpm@ietf.org" Subject: Re: [tcpm] New Version Notification for draft-touch-tcpm-tcp-edo-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: Thu, 22 May 2014 17:59:15 -0000 Hi, Bob, On 5/22/2014 10:10 AM, Bob Briscoe wrote: > Joe, > > Returning to the question of adoption, we have to address the question > of why previous attempts to do this have failed. I don't believe it is > as simple as that they tried to include options on SYNs, so all we have > to do is avoid the SYN problem. There haven't been any I can recall that didn't either focus on SYN space extension or include it as a key component. > 1) There is obviously the re-segmentation problem, which Olivier/Costin > have usefully highlighted, and I agree an optional checksum would at > least detect this. An optional checksum would help protect TCP from such "attacks" - re-segmentation isn't supported, and already breaks a number of existing TCP features (TCP-AO, TCP MD5, ACK clocking requirements, etc.). > 2) However, I think the main problem is that many important cases will > need as large or larger TCP option space on the SYN as on non-SYNs. Oh, I certainly agree with this. The point of this proposal is twofold: a) (primary) to put to bed the notion that 'there is a way' to extend SYN option space without contaminating connections to legacy hosts b) (secondary) to do the only extension possible - post-SYN. > The option space pressure for all the following (except SACK) is at > least as critical for the SYN as for non-SYN segments: > * SACK (SYN << non-SYN) > * MPTCP (SYN > non-SYN - typically) > * Timestamp (SYN = non-SYN) > * Window scale (SYN > non-SYN) > * TCP-AO (SYN = non-SYN) > * TFO init (SYN << non-SYN - but no use without TFO resume as well) > * TFO resume (SYN >> non-SYN) > > Given the above list, if bigger TCP options are not available for SYNs, > is a critical mass really going to be persuaded that it is worth the > effort of implementing, deploying, debugging, supporting, etc? Maybe never; I don't know. This isn't a "build it and they will come" proposal; it's intended to document the 'negative' about SYN extension primarily. The extension of non-SYN is intended primarily to show how it can trivially be done, not to argue that it's a great thing to do it. > And we > need a critical mass, because until EDO is deployed at both ends it does > nothing, so early implementers have to work on faith. > > Admittedly, EDO is partly trying to make space for future options and > partly trying to solve a problem we already have with existing options. > So, I admit that the relative size of existing options is not the whole > story. However, even new options have to fit with the existing ones. > > 3) The EDO draft implies that it is provably impossible to increase the > option space on a SYN. It states it, with the condition of not contaminating connections to legacy TCPs. > A couple of ways have been proposed to solve this > problem: > * LOIC that sends two parallel SYNs; a > regular one and one with a longer TCP option space AND a newly defined > checksum calculation, so that it will be discarded by legacy TCPs. The problem happens when the non-legacy endpoint gets the legacy SYN first - or only. There's no good way to do support dual-stack without incurring huge delay penalties waiting for a SYN with the new feature. > * An out-of-band control channel, e.g. That won't work for the first SYN to a new endpoint, which is always where the problem exists. Subsequent SYNs can always be affected by persistent state, if desired. > Much earlier in this thread, you dismissed the latter, wrongly I believe: > >> >At 16:00 25/04/2014, Zimmermann, Alexander wrote: >> >> * Sec 4: >> >> - Should we mention „draft-paasch-mptcp-control-stream“ here? >> > >> > I don't think so, any more than mentioning FTP's control channel. In >> both cases, a separate data channel is used for control info. The >> MPTCP approach isn't applicable to individual TCP connections - it >> only works in MPTCP because the group of connections is co-associated. > > This seems to miss the point that there could be a whole class of > solutions where we create an associated connection, precisely in order > to add a control channel of unlimited size to one (or more) data > channels. This brings its own problems, not least it loses the intrinsic > security binding when control and data are in the same segment. So, I > wouldn't separate off a control channel if we were starting from > scratch. But it's probably the most promising approach, given we have to > add a carbuncle to a wart. > > In fact there are some similarities between parallel SYNs and parallel > channels. The problematic case is first-contact. All other contacts - either within a single connection or with subsequent connections can be handled in any number of ways - a control channel, state that's left-behind, etc. > 4) Finally, the EDO draft cites as if > it is just another solution. It's not. It's actually a very useful > survey of all the previous attempts to solve this problem, including a > useful enumeration of the problems that have to be surmounted. I'll correct that. > The arguments on this thread show that we don't agree on the problem > space. So, I suggest we adopt Anatha's draft, and as we develop it, we > agree on the problem we are trying to solve first. Boring, but > apparently necessary. I don't agree with much of the content of that doc regarding the enumeration of requirements. I don't agree that this is a useful place to start, nor did the WG when it was first proposed AFAIR. Joe From nobody Thu May 22 11:58: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 139831A02D5 for ; Thu, 22 May 2014 11:58:43 -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, RCVD_IN_DNSWL_NONE=-0.0001] 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 ATrGp6N6TnNc for ; Thu, 22 May 2014 11:58:39 -0700 (PDT) Received: from atl4mhob11.myregisteredsite.com (atl4mhob11.myregisteredsite.com [209.17.115.49]) by ietfa.amsl.com (Postfix) with ESMTP id 0AC231A02C9 for ; Thu, 22 May 2014 11:58:30 -0700 (PDT) Received: from mailpod.hostingplatform.com ([10.30.71.203]) by atl4mhob11.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id s4MIwSU3030500 for ; Thu, 22 May 2014 14:58:28 -0400 Received: (qmail 17197 invoked by uid 0); 22 May 2014 18:58:28 -0000 X-TCPREMOTEIP: 107.48.65.33 X-Authenticated-UID: wes@mti-systems.com Received: from unknown (HELO ?192.168.43.65?) (wes@mti-systems.com@107.48.65.33) by 0 with ESMTPA; 22 May 2014 18:58:27 -0000 Message-ID: <537E48CE.8040704@mti-systems.com> Date: Thu, 22 May 2014 14:58:22 -0400 From: Wesley Eddy Organization: MTI Systems User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Joe Touch , Bob Briscoe References: <20140425221257.12559.43206.idtracker@ietfa.amsl.com> <2586_1398464386_535ADF82_2586_915_1_535ADF56.9050106@isi.edu> <5363AF84.8090701@mti-systems.com> <5363B397.8090009@isi.edu> <655C07320163294895BBADA28372AF5D2CFE36@FR712WXCHMBA15.zeu.alcatel-lucent.com> <20140503122950.GM44329@verdi> <655C07320163294895BBADA28372AF5D2D009E@FR712WXCHMBA15.zeu.alcatel-lucent.com> <201405221710.s4MHAY4S002037@bagheera.jungle.bt.co.uk> <537E3ACD.5000308@isi.edu> In-Reply-To: <537E3ACD.5000308@isi.edu> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/ljI_vWl4TEtlR00-tg3r8g5lHWI Cc: "tcpm@ietf.org" Subject: Re: [tcpm] New Version Notification for draft-touch-tcpm-tcp-edo-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: Thu, 22 May 2014 18:58:43 -0000 On 5/22/2014 1:58 PM, Joe Touch wrote: >> 2) However, I think the main problem is that many important cases will >> need as large or larger TCP option space on the SYN as on non-SYNs. > > Oh, I certainly agree with this. The point of this proposal is twofold: > > a) (primary) to put to bed the notion that 'there is a way' > to extend SYN option space without contaminating connections to > legacy hosts > > b) (secondary) to do the only extension possible - post-SYN. I agree with this. In my view, we actually have had consensus for a long time that extending the SYN is "really hard" (requiring some creativity), whereas extending the options space on other packets can be done quite a bit more trivially. So, the problem is decomposed into 2 parts; the harder part and the easier part. EDO is leaving the harder part alone for now; although it may ultimately be the more useful one to solve. I don't see this as a problem with EDO or reason not to do it ... any future solution for SYNs may differ substantially, but would seem like it should not impact how options are extended on other segments. -- Wes Eddy MTI Systems From nobody Thu May 22 14:06: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 7601A1A0349 for ; Thu, 22 May 2014 14:06:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] 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 2Zkt0OmsYbUC for ; Thu, 22 May 2014 14:06: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 6E5611A032F for ; Thu, 22 May 2014 14:06: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 s4ML5iRh012990 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 22 May 2014 14:05:44 -0700 (PDT) Message-ID: <537E66A7.4080907@isi.edu> Date: Thu, 22 May 2014 14:05:43 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Wesley Eddy , Bob Briscoe References: <20140425221257.12559.43206.idtracker@ietfa.amsl.com> <2586_1398464386_535ADF82_2586_915_1_535ADF56.9050106@isi.edu> <5363AF84.8090701@mti-systems.com> <5363B397.8090009@isi.edu> <655C07320163294895BBADA28372AF5D2CFE36@FR712WXCHMBA15.zeu.alcatel-lucent.com> <20140503122950.GM44329@verdi> <655C07320163294895BBADA28372AF5D2D009E@FR712WXCHMBA15.zeu.alcatel-lucent.com> <201405221710.s4MHAY4S002037@bagheera.jungle.bt.co.uk> <537E3ACD.5000308@isi.edu> <537E48CE.8040704@mti-systems.com> In-Reply-To: <537E48CE.8040704@mti-systems.com> Content-Type: text/plain; charset=windows-1252; format=flowed 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/C1z1q_8OrhwrII45b-pihfsKaIc Cc: "tcpm@ietf.org" Subject: Re: [tcpm] New Version Notification for draft-touch-tcpm-tcp-edo-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: Thu, 22 May 2014 21:06:11 -0000 On 5/22/2014 11:58 AM, Wesley Eddy wrote: > On 5/22/2014 1:58 PM, Joe Touch wrote: >>> 2) However, I think the main problem is that many important cases will >>> need as large or larger TCP option space on the SYN as on non-SYNs. >> >> Oh, I certainly agree with this. The point of this proposal is twofold: >> >> a) (primary) to put to bed the notion that 'there is a way' >> to extend SYN option space without contaminating connections to >> legacy hosts >> >> b) (secondary) to do the only extension possible - post-SYN. > > > I agree with this. In my view, we actually have had consensus > for a long time that extending the SYN is "really hard" (requiring > some creativity), Well, AFAICT we've also known for a long time that it's basically impossible when needed - i.e., to new endpoints, without impacting legacy endpoints (i.e., making their connections to new systems slow or misinterpreting option info as user data). Yes, there are a few other potential solutions that need to be discussed as non-viable, but IMO that's an important part of this doc. At the very least, even if it's not provably impossible, the obvious solutions don't work and it's harder than it looks. Joe From nobody Thu May 22 14:13:05 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 DA9A31A02DE for ; Thu, 22 May 2014 14:13:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] 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 WaCcGfMtwinO for ; Thu, 22 May 2014 14:13:00 -0700 (PDT) Received: from frantic.weston.borman.com (frantic.weston.borman.com [70.57.156.33]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A33A1A0381 for ; Thu, 22 May 2014 14:13:00 -0700 (PDT) Received: from local-42.weston.borman.com (local-42.weston.borman.com [192.168.1.42]) by frantic.weston.borman.com (8.14.7/8.14.7) with ESMTP id s4MLCl5h006582 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Thu, 22 May 2014 16:12:47 -0500 (CDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: David Borman In-Reply-To: <537E3ACD.5000308@isi.edu> Date: Thu, 22 May 2014 16:12:47 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <1AD79820-22C1-4500-84D1-1383F264D68C@weston.borman.com> References: <20140425221257.12559.43206.idtracker@ietfa.amsl.com> <2586_1398464386_535ADF82_2586_915_1_535ADF56.9050106@isi.edu> <5363AF84.8090701@mti-systems.com> <5363B397.8090009@isi.edu> <655C07320163294895BBADA28372AF5D2CFE36@FR712WXCHMBA15.zeu.alcatel-lucent.com> <20140503122950.GM44329@verdi> <655C07320163294895BBADA28372AF5D2D009E@FR712WXCHMBA15.zeu.alcatel-lucent.com> <201405221710.s4MHAY4S002037@bagheera.jungle.bt.co.uk> <537E3ACD.5000308@isi.edu> To: Joe Touch X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/lspvzOwoL-r8E3efnUgYZTlbbao Cc: "tcpm@ietf.org" Subject: Re: [tcpm] New Version Notification for draft-touch-tcpm-tcp-edo-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: Thu, 22 May 2014 21:13:03 -0000 On May 22, 2014, at 12:58 PM, Joe Touch wrote: >> 2) However, I think the main problem is that many important cases = will >> need as large or larger TCP option space on the SYN as on non-SYNs. >=20 > Oh, I certainly agree with this. The point of this proposal is = twofold: >=20 > a) (primary) to put to bed the notion that 'there is a way' > to extend SYN option space without contaminating connections to > legacy hosts Add to that "without adding any additional packet exchanges." That=92s = really the issue. This can be done, within the existing TCP processing, = but at the cost of an additional RTT, which everyone tries to avoid. = The receiver could respond to the initial SYN with another SYN, which = *can* take advantage of an extended option space because it now knows = that the other side supports EDO. The originator incurs an additional = RTT before it can send data (2 vs 1 RTT), the receiver has no delay for = when it can send data (1.5 RTT). Besides the additional RTT for the originator, the biggest problem with = this would be all those blasted firewalls that would drop the returning = SYN-only responses. The other way to do this is that when the SYN/ACK = comes back indicating that the other side supports EDO, then the = originator sends another SYN with the expanded option space. That has a = cost of a full RTT in both directions. But the issue still remains the same: for that initial SYN packet, with = no a priori knowledge, there is no way to extend the option space and = maintain 100% backwards compatibility. -David Borman= From nobody Fri May 23 03:03:46 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 BFD581A03E4 for ; Fri, 23 May 2014 03:03:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, 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 5CW6S0xTJGp1 for ; Fri, 23 May 2014 03:03:42 -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 8D9901A03EE for ; Fri, 23 May 2014 03:03:34 -0700 (PDT) Received: from EVMHR01-UKBR.domain1.systemhost.net (193.113.108.40) by EVMHR65-UKRD.bt.com (10.187.101.20) with Microsoft SMTP Server (TLS) id 14.3.181.6; Fri, 23 May 2014 11:03:31 +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; Fri, 23 May 2014 11:03: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; Fri, 23 May 2014 11:03:27 +0100 Received: from BTP075694.jungle.bt.co.uk ([10.111.232.89]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id s4NA3PAB005137; Fri, 23 May 2014 11:03:26 +0100 Message-ID: <201405231003.s4NA3PAB005137@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 23 May 2014 11:03:25 +0100 To: Joe Touch From: Bob Briscoe In-Reply-To: <537E66A7.4080907@isi.edu> References: <20140425221257.12559.43206.idtracker@ietfa.amsl.com> <2586_1398464386_535ADF82_2586_915_1_535ADF56.9050106@isi.edu> <5363AF84.8090701@mti-systems.com> <5363B397.8090009@isi.edu> <655C07320163294895BBADA28372AF5D2CFE36@FR712WXCHMBA15.zeu.alcatel-lucent.com> <20140503122950.GM44329@verdi> <655C07320163294895BBADA28372AF5D2D009E@FR712WXCHMBA15.zeu.alcatel-lucent.com> <201405221710.s4MHAY4S002037@bagheera.jungle.bt.co.uk> <537E3ACD.5000308@isi.edu> <537E48CE.8040704@mti-systems.com> <537E66A7.4080907@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/6nCr9BKVNtMVUduSZlGenUavM-A Cc: "tcpm@ietf.org" Subject: Re: [tcpm] New Version Notification for draft-touch-tcpm-tcp-edo-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: Fri, 23 May 2014 10:03:43 -0000 Joe, and everyone else who wants to work on this, Just because it's easier to make a chocolate teapot than a cast-iron one, doesn't imply that there is any need for chocolate teapots. IOW, we will be asking the IESG to spend reviewer time on EDO, so we need to give some plausible indication that someone might find it useful and it's not just an academic exercise. The current draft solely gives SACK + MPTCP + TCP-AO as an example, but is that really something that can't be done today? Adding more complexity to the TCP stack (with the potential for more vulnerabilities) is only worthwhile if there's an identifiable benefit, otherwise few production stacks are going to implement it anyway. Bob At 22:05 22/05/2014, Joe Touch wrote: >On 5/22/2014 11:58 AM, Wesley Eddy wrote: >>On 5/22/2014 1:58 PM, Joe Touch wrote: >>>>2) However, I think the main problem is that many important cases will >>>>need as large or larger TCP option space on the SYN as on non-SYNs. >>> >>>Oh, I certainly agree with this. The point of this proposal is twofold: >>> >>> a) (primary) to put to bed the notion that 'there is a way' >>> to extend SYN option space without contaminating connections to >>> legacy hosts >>> >>> b) (secondary) to do the only extension possible - post-SYN. >> >> >>I agree with this. In my view, we actually have had consensus >>for a long time that extending the SYN is "really hard" (requiring >>some creativity), > >Well, AFAICT we've also known for a long time that it's basically >impossible when needed - i.e., to new endpoints, without impacting >legacy endpoints (i.e., making their connections to new systems slow >or misinterpreting option info as user data). > >Yes, there are a few other potential solutions that need to be >discussed as non-viable, but IMO that's an important part of this doc. > >At the very least, even if it's not provably impossible, the obvious >solutions don't work and it's harder than it looks. > >Joe ________________________________________________________________ Bob Briscoe, BT From nobody Fri May 23 05:13: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 2AB751A0177 for ; Fri, 23 May 2014 05:13:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, 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 qcD8o5MGr2JA for ; Fri, 23 May 2014 05:13:44 -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 276A11A0181 for ; Fri, 23 May 2014 05:13:44 -0700 (PDT) Received: from EVMHR01-UKBR.domain1.systemhost.net (193.113.108.40) by EVMHR66-UKRD.bt.com (10.187.101.21) with Microsoft SMTP Server (TLS) id 14.3.181.6; Fri, 23 May 2014 13:13:40 +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; Fri, 23 May 2014 13:13:39 +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, 23 May 2014 13:13:39 +0100 Received: from BTP075694.jungle.bt.co.uk ([10.111.232.89]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id s4NCDa5P005525; Fri, 23 May 2014 13:13:37 +0100 Message-ID: <201405231213.s4NCDa5P005525@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 23 May 2014 13:13:36 +0100 To: David Borman , Joe Touch From: Bob Briscoe In-Reply-To: <1AD79820-22C1-4500-84D1-1383F264D68C@weston.borman.com> References: <20140425221257.12559.43206.idtracker@ietfa.amsl.com> <2586_1398464386_535ADF82_2586_915_1_535ADF56.9050106@isi.edu> <5363AF84.8090701@mti-systems.com> <5363B397.8090009@isi.edu> <655C07320163294895BBADA28372AF5D2CFE36@FR712WXCHMBA15.zeu.alcatel-lucent.com> <20140503122950.GM44329@verdi> <655C07320163294895BBADA28372AF5D2D009E@FR712WXCHMBA15.zeu.alcatel-lucent.com> <201405221710.s4MHAY4S002037@bagheera.jungle.bt.co.uk> <537E3ACD.5000308@isi.edu> <1AD79820-22C1-4500-84D1-1383F264D68C@weston.borman.com> 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/YKmsL2GD60IHGjdJ3fKYrRcuJt8 Cc: "tcpm@ietf.org" Subject: Re: [tcpm] New Version Notification for draft-touch-tcpm-tcp-edo-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: Fri, 23 May 2014 12:13:47 -0000 David, There is certainly no need for an additional RTT. Let me propose a couple of concrete strawmen (concrete men?) to show this. I'm not claiming these are novel. I know Joe and others think that we've seen enough of attempts to extend the TCP options on the SYN, but Joe should know that when he claims something is impossible, he wakes sleeping dragons in people like me. 1) Parallel control channel ___________________________ Client A sends two SYNs back-to-back to an existing well-known port (e.g. 80). * SYN D, establishes a regular data connection, with sufficient TCP options to be workable but they still fit within the existing 40B option limit. * SYN C establishes another parallel connection to the same well-known port that looks like regular data from the outside (it could even be an extension to HTTP to ensure middleboxes will let it pass), but it talks a new app-layer 'TCP control' protocol inside. If there is no support for the new app-layer protocol on port 80 the control channel just shuts down with a suitable HTTP error, while SYN D has opened a data connection with sufficient TCP options to be workable. If the new app-layer TCP control protocol is supported on port 80, the parallel control channel (C) adds unlimited additional control flexibility to the data channel (D) hardly any added latency. Establishing a similar control channel in the opposite direction would be fairly trivial. There are few, if any, middlebox problems with the above approach. However, there are certainly other problems, but no more insurmountable than all the problems that have already been discussed with taking the 'easy' route of EDO: * A secure binding would have to be added to bind channel C to a secret known only to the originator of channel D, otherwise it would open up data channels to spoof control channel attacks. This binding could be built on a TCP-AO option in channel D. * Channel C would need some way to refer to the segments of channel D that was robust against re-segmentation. * The main problem is that the two channels don't share fate; a control packet can be delayed relative to the point in the data stream at which it is attempting to exert control, possibly for a RTT if it is lost and has to be retransmitted. However, this is not insurmountable. The control protocol could include a mode to "synthesise shared fate", by making the data channel buffer data until an associated control segment had arrived. This would duplicate the latency impact of a loss or delay on either channel, but one can imagine mitigations that would consign this latency impact to corner cases. * It's a bit of a mess, but that comes with the territory when trying to fix legacy protocol problems. * The internal stack architecture seems to require a trombone back down into the kernel from user-space, but that is not insurmountable - a shim within the kernel on port 80 (for example) could redirect control channel data across to the "TCP control channel module" in the kernel, while passing non-control channel connections to user-space. 2) Build on LOIC ______________________ Long option with invalid checksum At 18:53 22/05/2014, John Leslie wrote: > That's too big of a change to ask folks to believe it safe. When I read an idea, I don't take it as set in stone and just find a hole and dismiss it. I see it as a potential stepping stone to a solution and think about how it could be done better. In fact, Andrew Yourtchenko said that was the intention of his write-up of LOIC. I believe that an approach worth further thought would be a mixture of the control channel idea and the invalid checksum idea. I'm thinking of: * a pure control SYN (C) sent first, then a base SYN (D) sent back-to-back, both to the same port. * SYN C would contain something invalid to cause a legacy TCP stack or legacy app to discard it (and hopefully less probability that a middlebox would), e.g. a payload that is invalid for the application protocol on the port. * there would be additional TCP options in the payload of SYN C to be added to the TCP options that arrived separately on the base SYN * The control SYN could be bound crytographically to the base SYN (as already described). * It could use the shim-like control stack arangement described earlier. By focusing solely on extending the SYN, this would avoid the ongoing shared fate problems that a separate control channel suffers throughout the connection. There would still be shared fate problems with 2 SYNs (e.g. the two SYNs get re-ordered), but the protocol would have to be designed to be robust to that (naively, SYN D could include a new TCP option that told a new stack to wait a few ticks for a SYN C, but that would be vulnerable to meddleboxes). Not insurmountable. Bob At 22:12 22/05/2014, David Borman wrote: >On May 22, 2014, at 12:58 PM, Joe Touch wrote: > > >> 2) However, I think the main problem is that many important cases will > >> need as large or larger TCP option space on the SYN as on non-SYNs. > > > > Oh, I certainly agree with this. The point of this proposal is twofold: > > > > a) (primary) to put to bed the notion that 'there is a way' > > to extend SYN option space without contaminating connections to > > legacy hosts > >Add to that "without adding any additional packet >exchanges." That's really the issue. This can be done, within the >existing TCP processing, but at the cost of an additional RTT, which >everyone tries to avoid. The receiver could respond to the initial >SYN with another SYN, which *can* take advantage of an extended >option space because it now knows that the other side supports >EDO. The originator incurs an additional RTT before it can send >data (2 vs 1 RTT), the receiver has no delay for when it can send >data (1.5 RTT). > >Besides the additional RTT for the originator, the biggest problem >with this would be all those blasted firewalls that would drop the >returning SYN-only responses. The other way to do this is that when >the SYN/ACK comes back indicating that the other side supports EDO, >then the originator sends another SYN with the expanded option >space. That has a cost of a full RTT in both directions. > > >But the issue still remains the same: for that initial SYN packet, >with no a priori knowledge, there is no way to extend the option >space and maintain 100% backwards compatibility. > > -David Borman ________________________________________________________________ Bob Briscoe, BT From nobody Fri May 23 06:33:00 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 27B731A048C for ; Fri, 23 May 2014 06:32:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.601 X-Spam-Level: X-Spam-Status: No, score=-3.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_MED=-2.3, 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 PnnyMKd-2IlX for ; Fri, 23 May 2014 06:32:55 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 08B551A0476 for ; Fri, 23 May 2014 06:32:54 -0700 (PDT) X-AuditID: c1b4fb2d-f79ed6d000003d40-6e-537f4e035443 Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 49.F3.15680.30E4F735; Fri, 23 May 2014 15:32:51 +0200 (CEST) Received: from eerihug-hybrid.rnd.ki.sw.ericsson.se (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.44) with Microsoft SMTP Server id 14.3.174.1; Fri, 23 May 2014 15:32:51 +0200 Date: Fri, 23 May 2014 15:32:51 +0200 From: Erik Hugne To: "Scheffenegger, Richard" Message-ID: <20140523133251.GA28880@eerihug-hybrid.rnd.ki.sw.ericsson.se> References: <20140521073611.GA1940@eerihug-hybrid.rnd.ki.sw.ericsson.se> <20140521114628.C72DB6B339F@lawyers.icir.org> <20140521125518.GC1940@eerihug-hybrid.rnd.ki.sw.ericsson.se> <012C3117EDDB3C4781FD802A8C27DD4F4A3C3904@SACEXCMBX02-PRD.hq.netapp.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <012C3117EDDB3C4781FD802A8C27DD4F4A3C3904@SACEXCMBX02-PRD.hq.netapp.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrHLMWRmVeSWpSXmKPExsUyM+JvjS6zX32wQdNLa4tpa6YxWaz8d4bd YtvJ+UwOzB7/Dt1k9liy5CeTx4xPX9gCmKO4bFJSczLLUov07RK4Mq42tbAWfLKsmNVn38B4 QL+LkZNDQsBEYtOFdywQtpjEhXvr2UBsIYGjjBL//5R0MXIB2QcYJSaff80OkmARUJX4deAI I4jNJqAlMfH5RCYQW0RAR6KnfQ4TSAOzwFlGiSlXjoJNFQbasPfjUbAGXgFPiT0PpjNDTG1i kvh++jQrREJQ4uTMJ2ANzECTFuz+BHQGB5AtLbH8HwdImFMgVOL15Hdg14kKqEhMObkN6lIV ifsvZ7NPYBSchWTSLCSTZiFMWsDIvIpRtDi1uDg33chYL7UoM7m4OD9PLy+1ZBMjMIAPbvmt u4Nx9WvHQ4wCHIxKPLwPmOqChVgTy4orcw8xSnOwKInzXtKoDhYSSE8sSc1OTS1ILYovKs1J LT7EyMTBKdXAWL21aeGdXx+lnr1YaNnSorY1d6KdTf/KkwdFV69fvSLlceuRXpau8JC4rxnB G+M/3IpTZlv+P2W3wMFJNe8s/D8/OaLbW+GcK6/xNEDjw/H28nsJHI6zc7Qau5WMw52y+2dI fT7zW+ujn4LqpJz1fw8keWSsFTofFsyr/alrZszPaLMiKTlWJZbijERDLeai4kQAgOxVS0EC AAA= Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/9xnyE-C-9B6u7mMkXHZyJUMkCxk Cc: "ingemar.s.johansson@ericsson.com" , "martin.isaksson@ericsson.com" , "tcpm@ietf.org" , Mark Allman Subject: Re: [tcpm] RFC3465:TCP ABC and SACK'ed data 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, 23 May 2014 13:32:58 -0000 Maybe.. This is a standard Linux 3.0 kernel with sack and frto enabled. Additional lab experiments have shown that following the path change, a stream of lost packets occurs (almost a full window, ~400kB). The receiver sends dupacks on the new path to trigger fast retransmit, but then the retransmission timer on the sender side fires and all unacked data will be resent. At the RTO, we get the expected cwnd drop. While the receiver keeps kicking the the sender by sending dupacks, the retransmission is reasonably fast but after a few ms it grinds down to a stop-and-go behaviour. I failed in my efforts to find some explanation to this in the RFC's. What i did find was in VJ's paper from '88. -When starting or restarting after a loss, set cwnd to one packet. -On each ack for new data, increase cwnd by one packet If retransmitted data are not considered "new", that would explain the behavior i guess. Scripted ss -ti for the connection every 3 sec. In this test it wasn't even a path change, we just downed the interface on a router in the middle for some 300ms to simulate the packetloss (This was done at 15:06:18) Fri May 23 15:06:01 CEST 2014 reno wscale:9,7 rto:1892 rtt:1678/7 ato:40 cwnd:2215 send 15.3Mbps rcv_space:14480 Fri May 23 15:06:04 CEST 2014 reno wscale:9,7 rto:1888 rtt:1678/8 ato:40 cwnd:2215 send 15.3Mbps rcv_space:14480 Fri May 23 15:06:07 CEST 2014 reno wscale:9,7 rto:1888 rtt:1676/9 ato:40 cwnd:2215 send 15.3Mbps rcv_space:14480 Fri May 23 15:06:10 CEST 2014 reno wscale:9,7 rto:1884 rtt:1675.5/5 ato:40 cwnd:2215 send 15.3Mbps rcv_space:14480 Fri May 23 15:06:14 CEST 2014 reno wscale:9,7 rto:1816 rtt:1607.5/22 ato:40 cwnd:2215 send 16.0Mbps rcv_space:14480 Fri May 23 15:06:17 CEST 2014 reno wscale:9,7 rto:1892 rtt:1681.5/7 ato:40 cwnd:2215 send 15.3Mbps rcv_space:14480 Fri May 23 15:06:20 CEST 2014 reno wscale:9,7 rto:1548 rtt:651/225 ato:40 cwnd:3 ssthresh:1107 send 53.4Kbps rcv_space:14480 Fri May 23 15:06:23 CEST 2014 reno wscale:9,7 rto:1224 rtt:263/110 ato:40 cwnd:3 ssthresh:1107 send 132.1Kbps rcv_space:14480 Fri May 23 15:06:26 CEST 2014 reno wscale:9,7 rto:1172 rtt:210.5/18 ato:40 cwnd:3 ssthresh:1107 send 165.1Kbps rcv_space:14480 Fri May 23 15:06:29 CEST 2014 reno wscale:9,7 rto:1164 rtt:203.5/6 ato:40 cwnd:3 ssthresh:1107 send 170.8Kbps rcv_space:14480 Fri May 23 15:06:32 CEST 2014 reno wscale:9,7 rto:1164 rtt:203.5/3 ato:40 cwnd:3 ssthresh:1107 send 170.8Kbps rcv_space:14480 Fri May 23 15:06:35 CEST 2014 reno wscale:9,7 rto:1164 rtt:203.5/3 ato:40 cwnd:6 ssthresh:1107 send 341.5Kbps rcv_space:14480 Fri May 23 15:06:38 CEST 2014 reno wscale:9,7 rto:1164 rtt:203.5/4 ato:40 cwnd:6 ssthresh:1107 send 341.5Kbps rcv_space:14480 Fri May 23 15:06:41 CEST 2014 reno wscale:9,7 rto:1168 rtt:204/4 ato:40 cwnd:6 ssthresh:1107 send 340.7Kbps rcv_space:14480 Fri May 23 15:06:44 CEST 2014 reno wscale:9,7 rto:1164 rtt:203.5/3 ato:40 cwnd:6 ssthresh:1107 send 341.5Kbps rcv_space:14480 Fri May 23 15:06:47 CEST 2014 reno wscale:9,7 rto:1164 rtt:203.5/3 ato:40 cwnd:6 ssthresh:1107 send 341.5Kbps rcv_space:14480 Fri May 23 15:06:50 CEST 2014 reno wscale:9,7 rto:1164 rtt:203.5/3 ato:40 cwnd:6 ssthresh:1107 send 341.5Kbps rcv_space:14480 Fri May 23 15:06:53 CEST 2014 reno wscale:9,7 rto:1164 rtt:203.5/3 ato:40 cwnd:6 ssthresh:1107 send 341.5Kbps rcv_space:14480 Fri May 23 15:06:56 CEST 2014 reno wscale:9,7 rto:1164 rtt:203.5/3 ato:40 cwnd:6 ssthresh:1107 send 341.5Kbps rcv_space:14480 Fri May 23 15:06:59 CEST 2014 reno wscale:9,7 rto:1164 rtt:203.5/4 ato:40 cwnd:6 ssthresh:1107 send 341.5Kbps rcv_space:14480 Fri May 23 15:07:02 CEST 2014 reno wscale:9,7 rto:1164 rtt:203.5/3 ato:40 cwnd:9 ssthresh:1107 send 512.3Kbps rcv_space:14480 Fri May 23 15:07:05 CEST 2014 reno wscale:9,7 rto:1164 rtt:203.5/3 ato:40 cwnd:9 ssthresh:1107 send 512.3Kbps rcv_space:14480 Fri May 23 15:07:08 CEST 2014 reno wscale:9,7 rto:1164 rtt:203.5/3 ato:40 cwnd:9 ssthresh:1107 send 512.3Kbps rcv_space:14480 Fri May 23 15:07:11 CEST 2014 reno wscale:9,7 rto:1260 rtt:487.5/8 ato:40 cwnd:960 ssthresh:1107 send 22.8Mbps rcv_space:14480 Fri May 23 15:07:14 CEST 2014 reno wscale:9,7 rto:1244 rtt:863.5/6 ato:40 cwnd:1111 ssthresh:1107 send 14.9Mbps rcv_space:14480 Fri May 23 15:07:17 CEST 2014 reno wscale:9,7 rto:1148 rtt:864/6 ato:40 cwnd:1114 ssthresh:1107 send 14.9Mbps rcv_space:14480 Fri May 23 15:07:20 CEST 2014 reno wscale:9,7 rto:1096 rtt:868/8 ato:40 cwnd:1118 ssthresh:1107 send 14.9Mbps rcv_space:14480 On Thu, May 22, 2014 at 06:47:56AM +0000, Scheffenegger, Richard wrote: > > Are you perhaps observing an effect of the ACK clock loss, when you refer to a huge number of consecutive lost segments? > > Standard SACK does suffer from an issue that during loss recovery, there may be a gap (SACKs don't clock out new/retransmitted packets while flightsize > cwnd (which is now 1/2); only during the 2nd half, SACK starts to clock out packets, but at the same rate as before (which may not that bright an idea if a path change with differnet characteristics is now there). > > RateHalving (Linux has some kind of variant of this) / Proportional Rate Reduction RFC6937 may be the thing that you are after? > > > ABC really only comes into play during slowstart, to make connections which use delayed ACKs not perform much less aggressive than sessions where the receiver features QuickAck (Linux non-standard). > > Best regards, > > > Richard Scheffenegger > > > > -----Original Message----- > > From: tcpm [mailto:tcpm-bounces@ietf.org] On Behalf Of Erik Hugne > > Sent: Mittwoch, 21. Mai 2014 14:55 > > To: Mark Allman > > Cc: ingemar.s.johansson@ericsson.com; martin.isaksson@ericsson.com; > > tcpm@ietf.org > > Subject: Re: [tcpm] RFC3465:TCP ABC and SACK'ed data > > > > On Wed, May 21, 2014 at 07:46:28AM -0400, Mark Allman wrote: > > > > > > > TCP ABC (still in the experimental track) defines a method to > > > > increase the cwnd based on the bytes being acknowledged, instead of > > > > the number of acks that arrive. I am assuming that SACK'ed (RFC2018) > > > > data should be included in this calculation, but i could find no > > > > mention of this in RFC3465. Could someone confirm this? > > > > > > ABC does not include SACK information in its calculations and it > > > cannot include SACK information. ABC applies to slow start---which > > > ends when loss occurs. And, (essentially) SACKs only arrive during loss > > recovery. > > > So, there is no need for ABC to deal with SACKs. > > > > > > > Thanks for taking the time to explain this. > > > > The problem (this is related to Ingemars posts around "Problem with low > > SSthresh") is that following the path change, there is a large train of > > segments being lost (say 150k out of a 500k window). Data at the end of > > the window did make it through and is SACK'ed. Upon receiving these SACK's > > the sending side enters loss recovery. It will take a very long time > > before recovering the 100k lost segments. > > > > An aggressive recovery algorithm would mitigate the effects of this, but i > > was hoping for a more elegant solution. > > > > //E > > > > _______________________________________________ > > tcpm mailing list > > tcpm@ietf.org > > https://www.ietf.org/mailman/listinfo/tcpm From nobody Fri May 23 09:33:54 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 54DE31A06DA for ; Fri, 23 May 2014 09:33:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] 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 pmeE7XN6Ux1K for ; Fri, 23 May 2014 09:33:47 -0700 (PDT) Received: from frantic.weston.borman.com (frantic.weston.borman.com [70.57.156.33]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B0241A00E5 for ; Fri, 23 May 2014 09:33:40 -0700 (PDT) Received: from local-42.weston.borman.com (local-42.weston.borman.com [192.168.1.42]) by frantic.weston.borman.com (8.14.7/8.14.7) with ESMTP id s4NGXYBd020093 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Fri, 23 May 2014 11:33:34 -0500 (CDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: David Borman In-Reply-To: <201405231213.s4NCDa5P005525@bagheera.jungle.bt.co.uk> Date: Fri, 23 May 2014 11:33:34 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <6391C448-A917-4E66-9B73-CB840B193FD7@weston.borman.com> References: <20140425221257.12559.43206.idtracker@ietfa.amsl.com> <2586_1398464386_535ADF82_2586_915_1_535ADF56.9050106@isi.edu> <5363AF84.8090701@mti-systems.com> <5363B397.8090009@isi.edu> <655C07320163294895BBADA28372AF5D2CFE36@FR712WXCHMBA15.zeu.alcatel-lucent.com> <20140503122950.GM44329@verdi> <655C07320163294895BBADA28372AF5D2D009E@FR712WXCHMBA15.zeu.alcatel-lucent.com> <201405221710.s4MHAY4S002037@bagheera.jungle.bt.co.uk> <537E3ACD.5000308@isi.edu> <1AD79820-22C1-4500-84D1-1383F264D68C@weston.borman.com> <201405231213.s4NCDa5P005525@bagheera.jungle.bt.co.uk> To: Bob Briscoe X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/HY76rIqk38vc_o4AVylOSjJimIQ Cc: "tcpm@ietf.org" , Joe Touch Subject: Re: [tcpm] New Version Notification for draft-touch-tcpm-tcp-edo-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: Fri, 23 May 2014 16:33:49 -0000 Hi Bob, On May 23, 2014, at 7:13 AM, Bob Briscoe wrote: > David, >=20 > There is certainly no need for an additional RTT. Oh, there will always be proposals for ways to avoid the additional RTT, = but at what cost? A parallel control channel is a lot of complexity if = its only purpose is to get more option space for a single, initial SYN = packet. > Let me propose a couple of concrete strawmen (concrete men?) to show = this. I'm not claiming these are novel. I know Joe and others think that = we've seen enough of attempts to extend the TCP options on the SYN, but = Joe should know that when he claims something is impossible, he wakes = sleeping dragons in people like me. What is impossible is to expand the option space in the initial SYN = packet and maintain 100% backwards compatibility with the following = restrictions: 1) No additional packets are sent, just the initial SYN 2) There is no a priori knowledge as to whether or not the remote = host understands expanded option space. Every proposal that maintains 100% backwards compatibility has to send = additional data in other packets in some form. A parallel data channel, = a second SYN, whatever, they all require additional data in separate = packets. -David =20= From nobody Fri May 23 09:56:05 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 B0F0F1A073E for ; Fri, 23 May 2014 09:56:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] 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 uOx864p9aYME for ; Fri, 23 May 2014 09:56:02 -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 655021A0743 for ; Fri, 23 May 2014 09:56:02 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id s4NGtidO011346 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 23 May 2014 09:55:45 -0700 (PDT) Message-ID: <537F7D91.10802@isi.edu> Date: Fri, 23 May 2014 09:55:45 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Bob Briscoe References: <20140425221257.12559.43206.idtracker@ietfa.amsl.com> <2586_1398464386_535ADF82_2586_915_1_535ADF56.9050106@isi.edu> <5363AF84.8090701@mti-systems.com> <5363B397.8090009@isi.edu> <655C07320163294895BBADA28372AF5D2CFE36@FR712WXCHMBA15.zeu.alcatel-lucent.com> <20140503122950.GM44329@verdi> <655C07320163294895BBADA28372AF5D2D009E@FR712WXCHMBA15.zeu.alcatel-lucent.com> <201405221710.s4MHAY4S002037@bagheera.jungle.bt.co.uk> <537E3ACD.5000308@isi.edu> <537E48CE.8040704@mti-systems.com> <537E66A7.4080907@isi.edu> <201405231003.s4NA3PAB005137@bagheera.jungle.bt.co.uk> In-Reply-To: <201405231003.s4NA3PAB005137@bagheera.jungle.bt.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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/ugIkZ8kn7DgAIfkNicUZvycsXnk Cc: "tcpm@ietf.org" Subject: Re: [tcpm] New Version Notification for draft-touch-tcpm-tcp-edo-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: Fri, 23 May 2014 16:56:03 -0000 Hi, Bob, On 5/23/2014 3:03 AM, Bob Briscoe wrote: > Joe, and everyone else who wants to work on this, > > Just because it's easier to make a chocolate teapot than a cast-iron > one, doesn't imply that there is any need for chocolate teapots. You don't get a cast iron teapot just because you want one either ;-) > IOW, we will be asking the IESG to spend reviewer time on EDO, so we > need to give some plausible indication that someone might find it useful > and it's not just an academic exercise. Sometimes the answer "you can't have A, but at least here's B" is more than an exercise; it educates the community. By not providing either answer, we have continued to drag this issue around the block for far too long -- and spent far too many cycles in this and other WGs seeking solutions. > The current draft solely gives > SACK + MPTCP + TCP-AO as an example, but is that really something that > can't be done today? Current total for SYN options in widespread concurrent use (as already described in sec 6.4): 2 SACK permitted 10 timestamp 3 window scale 4 MSS ------------------ 11 bytes The current DO field is 4 bits, with a max value of 15 = 60 bytes for the total header, less 20 for the base TCP header which leaves 40 for options. So let's see what happens when we add: 11 widespread basic options 16 TCP-AO 20 MPTCP -------------------- 47 That's more than 40. > Adding more complexity to the TCP stack (with the potential for more > vulnerabilities) is only worthwhile if there's an identifiable benefit, > otherwise few production stacks are going to implement it anyway. There are two identifiable benefits: 1) explain the ways we already know we can't extend the SYN so we stop wasting time trying them repeatedly (i.e., education) 2) provide a solution for the other segments, so that can be used - e.g., for large SACK responses 3) educate the community Joe From nobody Fri May 23 10:03:29 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 4A3C01A06F9 for ; Fri, 23 May 2014 10:03:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] 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 kRxlmZbl2aim for ; Fri, 23 May 2014 10:03:16 -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 B2FBE1A0740 for ; Fri, 23 May 2014 10:03:16 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id s4NH1O7P013353 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 23 May 2014 10:01:24 -0700 (PDT) Message-ID: <537F7EE4.4080101@isi.edu> Date: Fri, 23 May 2014 10:01:24 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: David Borman , Bob Briscoe References: <20140425221257.12559.43206.idtracker@ietfa.amsl.com> <2586_1398464386_535ADF82_2586_915_1_535ADF56.9050106@isi.edu> <5363AF84.8090701@mti-systems.com> <5363B397.8090009@isi.edu> <655C07320163294895BBADA28372AF5D2CFE36@FR712WXCHMBA15.zeu.alcatel-lucent.com> <20140503122950.GM44329@verdi> <655C07320163294895BBADA28372AF5D2D009E@FR712WXCHMBA15.zeu.alcatel-lucent.com> <201405221710.s4MHAY4S002037@bagheera.jungle.bt.co.uk> <537E3ACD.5000308@isi.edu> <1AD79820-22C1-4500-84D1-1383F264D68C@weston.borman.com> <201405231213.s4NCDa5P005525@bagheera.jungle.bt.co.uk> <6391C448-A917-4E66-9B73-CB840B193FD7@weston.borman.com> In-Reply-To: <6391C448-A917-4E66-9B73-CB840B193FD7@weston.borman.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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/LaBg67ocQmlOeaE8rZIlffuz1Dc Cc: "tcpm@ietf.org" Subject: Re: [tcpm] New Version Notification for draft-touch-tcpm-tcp-edo-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: Fri, 23 May 2014 17:03:26 -0000 On 5/23/2014 9:33 AM, David Borman wrote: > Hi Bob, > > On May 23, 2014, at 7:13 AM, Bob Briscoe wrote: > >> David, >> >> There is certainly no need for an additional RTT. > > Oh, there will always be proposals for ways to avoid the additional RTT, but at what cost? A parallel control channel is a lot of complexity if its only purpose is to get more option space for a single, initial SYN packet. > > >> Let me propose a couple of concrete strawmen (concrete men?) to show this. I'm not claiming these are novel. I know Joe and others think that we've seen enough of attempts to extend the TCP options on the SYN, but Joe should know that when he claims something is impossible, he wakes sleeping dragons in people like me. > > What is impossible is to expand the option space in the initial SYN packet and maintain 100% backwards compatibility with the following restrictions: > 1) No additional packets are sent, just the initial SYN > 2) There is no a priori knowledge as to whether or not the remote host understands expanded option space. I would pose the conditions as follows: 1) is robust to packet loss, reordering, and alternate paths any assumption of "back to back" packets isn't 2) does not negatively impact legacy hosts e.g., dual-stack/multiple SYN approaches fail here when a legacy system is trying to connect to an updated one (which has to wait to see if the updated SYN will show) 3) succeeds through basic NAT/NAPTs anything that uses a nonstandard checksum will fail to support the extended space 4) addresses new connections to hosts not previously contacted it's trivial to retain state across sequences of connections, as per RFC 2140. > Every proposal that maintains 100% backwards compatibility has to > sendadditional data in other packets in some form. A parallel data channel, > a second SYN, whatever, they all require additional data in separate > packets. +1 From nobody Fri May 23 10:15:09 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 1F69F1A0783 for ; Fri, 23 May 2014 10:15:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.251 X-Spam-Level: X-Spam-Status: No, score=-4.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_41=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] 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 bUSa6bOJjYBC for ; Fri, 23 May 2014 10:15:05 -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 0E3C51A0760 for ; Fri, 23 May 2014 10:15:05 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id s4NHEgGP017198 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 23 May 2014 10:14:42 -0700 (PDT) Message-ID: <537F8202.4020907@isi.edu> Date: Fri, 23 May 2014 10:14:42 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Bob Briscoe , David Borman References: <20140425221257.12559.43206.idtracker@ietfa.amsl.com> <2586_1398464386_535ADF82_2586_915_1_535ADF56.9050106@isi.edu> <5363AF84.8090701@mti-systems.com> <5363B397.8090009@isi.edu> <655C07320163294895BBADA28372AF5D2CFE36@FR712WXCHMBA15.zeu.alcatel-lucent.com> <20140503122950.GM44329@verdi> <655C07320163294895BBADA28372AF5D2D009E@FR712WXCHMBA15.zeu.alcatel-lucent.com> <201405221710.s4MHAY4S002037@bagheera.jungle.bt.co.uk> <537E3ACD.5000308@isi.edu> <1AD79820-22C1-4500-84D1-1383F264D68C@weston.borman.com> <201405231213.s4NCDa5P005525@bagheera.jungle.bt.co.uk> In-Reply-To: <201405231213.s4NCDa5P005525@bagheera.jungle.bt.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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/HzQjPQ1jnxoX4rCoDt3VsvMm5Jw Cc: "tcpm@ietf.org" Subject: Re: [tcpm] New Version Notification for draft-touch-tcpm-tcp-edo-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: Fri, 23 May 2014 17:15:07 -0000 On 5/23/2014 5:13 AM, Bob Briscoe wrote: > David, > > There is certainly no need for an additional RTT. > > Let me propose a couple of concrete strawmen (concrete men?) to show > this. I'm not claiming these are novel. I know Joe and others think that > we've seen enough of attempts to extend the TCP options on the SYN, but > Joe should know that when he claims something is impossible, he wakes > sleeping dragons in people like me. I slay dragons all the time ;-) ("Defender of the cruciform packet"* is one of my mottos) > 1) Parallel control channel > ___________________________ > Client A sends two SYNs back-to-back to an existing well-known port > (e.g. 80). You can send in whatever order you want; packets will be reordered, lost, and sent along alternate paths. FWIW, do these use the same source port and ISN? - if they do, it'll reset the connection - if they don't, you're now limiting the number of concurrent connections to roughly half: http://www.isi.edu/touch/pubs/infocomm99/infocomm99-web/ > * SYN D, establishes a regular data connection, with sufficient TCP > options to be workable but they still fit within the existing 40B option > limit. > * SYN C establishes another parallel connection to the same well-known > port that looks like regular data from the outside (it could even be an > extension to HTTP to ensure middleboxes will let it pass), but it talks > a new app-layer 'TCP control' protocol inside. What happens when they arrive out of order? What happens when you get D but not yet C? How long do you wait for C? This is the problem with dual-stack approaches - new endpoints penalize legacy endpoints if there's a stall, and undermine new endpoints if they don't. > If there is no support for the new app-layer protocol on port 80 the > control channel just shuts down with a suitable HTTP error, while SYN D > has opened a data connection with sufficient TCP options to be workable. > If the new app-layer TCP control protocol is supported on port 80, the > parallel control channel (C) adds unlimited additional control > flexibility to the data channel (D) hardly any added latency. > > Establishing a similar control channel in the opposite direction would > be fairly trivial. > > There are few, if any, middlebox problems with the above approach. > However, there are certainly other problems, but no more insurmountable > than all the problems that have already been discussed with taking the > 'easy' route of EDO: > * A secure binding would have to be added to bind channel C to a secret > known only to the originator of channel D, otherwise it would open up > data channels to spoof control channel attacks. This binding could be > built on a TCP-AO option in channel D. Yes, that's another problem. > * Channel C would need some way to refer to the segments of channel D > that was robust against re-segmentation. Which means it won't work in the current Internet, because resegmentation is also widespread (though evil, IMO). > * The main problem is that the two channels don't share fate;a control > packet can be delayed relative to the point in the data stream at which > it is attempting to exert control, possibly for a RTT if it is lost and > has to be retransmitted. However, this is not insurmountable. The > control protocol could include a mode to "synthesise shared fate", by > making the data channel buffer data until an associated control segment > had arrived. This would duplicate the latency impact of a loss or delay > on either channel, but one can imagine mitigations that would consign > this latency impact to corner cases. > * It's a bit of a mess, but that comes with the territory when trying to > fix legacy protocol problems. > * The internal stack architecture seems to require a trombone back down > into the kernel from user-space, but that is not insurmountable - a shim > within the kernel on port 80 (for example) could redirect control > channel data across to the "TCP control channel module" in the kernel, > while passing non-control channel connections to user-space. > > 2) Build on LOIC > ______________________ > Long option with invalid checksum Won't work through current NATs, which won't recalculate the checksum properly. > > At 18:53 22/05/2014, John Leslie wrote: >> That's too big of a change to ask folks to believe it safe. > > When I read an idea, I don't take it as set in stone and just find a > hole and dismiss it. I see it as a potential stepping stone to a > solution and think about how it could be done better. In fact, Andrew > Yourtchenko said that was the intention of his write-up of LOIC. > > I believe that an approach worth further thought would be a mixture of > the control channel idea and the invalid checksum idea. I'm thinking of: > * a pure control SYN (C) sent first, then a base SYN (D) sent > back-to-back, both to the same port. Again, please don't assume back-to-back means anything. > * SYN C would contain something invalid to cause a legacy TCP stack or > legacy app to discard it (and hopefully less probability that a > middlebox would), e.g. a payload that is invalid for the application > protocol on the port. But so will a NAT, etc. > * there would be additional TCP options in the payload of SYN C to be > added to the TCP options that arrived separately on the base SYN > * The control SYN could be bound crytographically to the base SYN (as > already described). > * It could use the shim-like control stack arangement described earlier. > > By focusing solely on extending the SYN, this would avoid the ongoing > shared fate problems that a separate control channel suffers throughout > the connection. There would still be shared fate problems with 2 SYNs > (e.g. the two SYNs get re-ordered), but the protocol would have to be > designed to be robust to that (naively, SYN D could include a new TCP > option that told a new stack to wait a few ticks for a SYN C, but that > would be vulnerable to meddleboxes). Not insurmountable. AFAICT, it is. *with a nod to Raiders 3. From nobody Fri May 23 10:37: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 4DD991A01ED for ; Fri, 23 May 2014 10:37:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.43 X-Spam-Level: X-Spam-Status: No, score=-1.43 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, J_CHICKENPOX_42=0.6, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] 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 rkuZAC-Se0gB for ; Fri, 23 May 2014 10:37:34 -0700 (PDT) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6AE061A021B for ; Fri, 23 May 2014 10:37:22 -0700 (PDT) Received: by mail-wi0-f177.google.com with SMTP id f8so1256845wiw.4 for ; Fri, 23 May 2014 10:37:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=OdHb56vVXZhUrDsWv0TRYnXbXpPVytbPCcBE3qaKuO8=; b=YpVQe79iEM/T60Rn+U0f9DaLRsApRQdpD2kR3GzEi9P1V1faTE3bQIIxrf//NnyYHi xGeahaeLor4crIh3roop9VT3gr8y4l00a7v6TRL8XsTSArly5FyaMLJ1NaLvRNOpvJ9S Ic0foYZ9yUw3CuVsJbFQXEzO3ZfZ9TtlhEkIqSCuxiHtk5k/HmEEhxI5J5OCUBTYmr0O UkV1QOxhmCjKCIm3jNuIYiT7k8xgVkuC8bTP6lNoRbGWfITDjlg/z6nm32aRKEAkMaGu dOVnDIBAouMaTTZdNWGBI+htDuJ9QVPUtgjjqCaCP7zfTSPbeHSglNbvJ026pYBOzLqn 63Ow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=OdHb56vVXZhUrDsWv0TRYnXbXpPVytbPCcBE3qaKuO8=; b=Tt0QZqxnJRilSFS39DYDZUG+tnwxryEORD/Qvwumyej+9qmN29A6hfhHokHOnpJJea pzDzjv2ynYkrQ3HBFT0P0Al3NpleYhAoRZ3OODoLswFVXBMZPDUsE1KhgdjdpbG5jOvK 23vtu218WOBS7xiqidJLR68YTBlGea+9WB5AnkzRaqnNqShK4RueUUiipydbBg3piuwb XgK2Hj+Czh3o+Hmtpu5/lXng4LF2noXLNbdXGy31Q2wqSeSwaU/SJ4lriXnlCfYUDmvJ NAmvqadMuYL7Q8SrbeCEHR701aMCV7+kU7CIq7oIM900S6FQXs8qxpegr00eH2qUXDQ6 jD3g== X-Gm-Message-State: ALoCoQlOcjvnF/vK3dbqcs7JN/nxPoy7vwFpW81+DxeFM8+hSj44cYajCKR244VJS387mwtVMfs7 MIME-Version: 1.0 X-Received: by 10.194.19.161 with SMTP id g1mr5574439wje.20.1400866639664; Fri, 23 May 2014 10:37:19 -0700 (PDT) Received: by 10.194.36.166 with HTTP; Fri, 23 May 2014 10:37:19 -0700 (PDT) In-Reply-To: <20140523133251.GA28880@eerihug-hybrid.rnd.ki.sw.ericsson.se> References: <20140521073611.GA1940@eerihug-hybrid.rnd.ki.sw.ericsson.se> <20140521114628.C72DB6B339F@lawyers.icir.org> <20140521125518.GC1940@eerihug-hybrid.rnd.ki.sw.ericsson.se> <012C3117EDDB3C4781FD802A8C27DD4F4A3C3904@SACEXCMBX02-PRD.hq.netapp.com> <20140523133251.GA28880@eerihug-hybrid.rnd.ki.sw.ericsson.se> Date: Fri, 23 May 2014 13:37:19 -0400 Message-ID: From: Neal Cardwell To: Erik Hugne Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/xjMrEk4ccbFPU9gZvcjF63GU4ms Cc: "tcpm@ietf.org" , "martin.isaksson@ericsson.com" , Mark Allman , "ingemar.s.johansson@ericsson.com" Subject: Re: [tcpm] RFC3465:TCP ABC and SACK'ed data 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, 23 May 2014 17:37:36 -0000 On Fri, May 23, 2014 at 9:32 AM, Erik Hugne wrote= : > Maybe.. > This is a standard Linux 3.0 kernel with sack and frto enabled. > Additional lab experiments have shown that following the path change, a s= tream > of lost packets occurs (almost a full window, ~400kB). The receiver sends > dupacks on the new path to trigger fast retransmit, but then the retransm= ission > timer on the sender side fires and all unacked data will be resent. At th= e RTO, > we get the expected cwnd drop. While the receiver keeps kicking the the s= ender > by sending dupacks, the retransmission is reasonably fast but after a few= ms it > grinds down to a stop-and-go behaviour. It sounds like the big problems start with the RTO. In theory, if the sender is getting enough SACKs then it ought to be able to repair all those lost packets in one or a handful of RTTs, depending on just how many were lost, and how much the RTT jumps upward in the switch to the new path. Can you retry your experiments with Linux 3.13 or newer? Recent Linux kernels (3.13 and beyond) should do better in this regard: Yuchung Cheng (cc-ed) has made some nice changes that take RTT measurements from SACKs of unretransmitted data, and then keep updating the RTO timer accordingly. Regarding your scenario - what are the RTTs of the old and new paths? cheers, neal > I failed in my efforts to find some explanation to this in the RFC's. > What i did find was in VJ's paper from '88. > > -When starting or restarting after a loss, set cwnd to one packet. > -On each ack for new data, increase cwnd by one packet > > If retransmitted data are not considered "new", that would explain the be= havior > i guess. > > Scripted ss -ti for the connection every 3 sec. > In this test it wasn't even a path change, we just downed the interface o= n a > router in the middle for some 300ms to simulate the packetloss (This was = done at 15:06:18) > > Fri May 23 15:06:01 CEST 2014 > reno wscale:9,7 rto:1892 rtt:1678/7 ato:40 cwnd:2215 send 15.3Mbp= s rcv_space:14480 > Fri May 23 15:06:04 CEST 2014 > reno wscale:9,7 rto:1888 rtt:1678/8 ato:40 cwnd:2215 send 15.3Mbp= s rcv_space:14480 > Fri May 23 15:06:07 CEST 2014 > reno wscale:9,7 rto:1888 rtt:1676/9 ato:40 cwnd:2215 send 15.3Mbp= s rcv_space:14480 > Fri May 23 15:06:10 CEST 2014 > reno wscale:9,7 rto:1884 rtt:1675.5/5 ato:40 cwnd:2215 send 15.3M= bps rcv_space:14480 > Fri May 23 15:06:14 CEST 2014 > reno wscale:9,7 rto:1816 rtt:1607.5/22 ato:40 cwnd:2215 send 16.0= Mbps rcv_space:14480 > Fri May 23 15:06:17 CEST 2014 > reno wscale:9,7 rto:1892 rtt:1681.5/7 ato:40 cwnd:2215 send 15.3M= bps rcv_space:14480 > Fri May 23 15:06:20 CEST 2014 > reno wscale:9,7 rto:1548 rtt:651/225 ato:40 cwnd:3 ssthresh:1107 = send 53.4Kbps rcv_space:14480 > Fri May 23 15:06:23 CEST 2014 > reno wscale:9,7 rto:1224 rtt:263/110 ato:40 cwnd:3 ssthresh:1107 = send 132.1Kbps rcv_space:14480 > Fri May 23 15:06:26 CEST 2014 > reno wscale:9,7 rto:1172 rtt:210.5/18 ato:40 cwnd:3 ssthresh:1107= send 165.1Kbps rcv_space:14480 > Fri May 23 15:06:29 CEST 2014 > reno wscale:9,7 rto:1164 rtt:203.5/6 ato:40 cwnd:3 ssthresh:1107 = send 170.8Kbps rcv_space:14480 > Fri May 23 15:06:32 CEST 2014 > reno wscale:9,7 rto:1164 rtt:203.5/3 ato:40 cwnd:3 ssthresh:1107 = send 170.8Kbps rcv_space:14480 > Fri May 23 15:06:35 CEST 2014 > reno wscale:9,7 rto:1164 rtt:203.5/3 ato:40 cwnd:6 ssthresh:1107 = send 341.5Kbps rcv_space:14480 > Fri May 23 15:06:38 CEST 2014 > reno wscale:9,7 rto:1164 rtt:203.5/4 ato:40 cwnd:6 ssthresh:1107 = send 341.5Kbps rcv_space:14480 > Fri May 23 15:06:41 CEST 2014 > reno wscale:9,7 rto:1168 rtt:204/4 ato:40 cwnd:6 ssthresh:1107 se= nd 340.7Kbps rcv_space:14480 > Fri May 23 15:06:44 CEST 2014 > reno wscale:9,7 rto:1164 rtt:203.5/3 ato:40 cwnd:6 ssthresh:1107 = send 341.5Kbps rcv_space:14480 > Fri May 23 15:06:47 CEST 2014 > reno wscale:9,7 rto:1164 rtt:203.5/3 ato:40 cwnd:6 ssthresh:1107 = send 341.5Kbps rcv_space:14480 > Fri May 23 15:06:50 CEST 2014 > reno wscale:9,7 rto:1164 rtt:203.5/3 ato:40 cwnd:6 ssthresh:1107 = send 341.5Kbps rcv_space:14480 > Fri May 23 15:06:53 CEST 2014 > reno wscale:9,7 rto:1164 rtt:203.5/3 ato:40 cwnd:6 ssthresh:1107 = send 341.5Kbps rcv_space:14480 > Fri May 23 15:06:56 CEST 2014 > reno wscale:9,7 rto:1164 rtt:203.5/3 ato:40 cwnd:6 ssthresh:1107 = send 341.5Kbps rcv_space:14480 > Fri May 23 15:06:59 CEST 2014 > reno wscale:9,7 rto:1164 rtt:203.5/4 ato:40 cwnd:6 ssthresh:1107 = send 341.5Kbps rcv_space:14480 > Fri May 23 15:07:02 CEST 2014 > reno wscale:9,7 rto:1164 rtt:203.5/3 ato:40 cwnd:9 ssthresh:1107 = send 512.3Kbps rcv_space:14480 > Fri May 23 15:07:05 CEST 2014 > reno wscale:9,7 rto:1164 rtt:203.5/3 ato:40 cwnd:9 ssthresh:1107 = send 512.3Kbps rcv_space:14480 > Fri May 23 15:07:08 CEST 2014 > reno wscale:9,7 rto:1164 rtt:203.5/3 ato:40 cwnd:9 ssthresh:1107 = send 512.3Kbps rcv_space:14480 > Fri May 23 15:07:11 CEST 2014 > reno wscale:9,7 rto:1260 rtt:487.5/8 ato:40 cwnd:960 ssthresh:110= 7 send 22.8Mbps rcv_space:14480 > Fri May 23 15:07:14 CEST 2014 > reno wscale:9,7 rto:1244 rtt:863.5/6 ato:40 cwnd:1111 ssthresh:11= 07 send 14.9Mbps rcv_space:14480 > Fri May 23 15:07:17 CEST 2014 > reno wscale:9,7 rto:1148 rtt:864/6 ato:40 cwnd:1114 ssthresh:1107= send 14.9Mbps rcv_space:14480 > Fri May 23 15:07:20 CEST 2014 > reno wscale:9,7 rto:1096 rtt:868/8 ato:40 cwnd:1118 ssthresh:1107= send 14.9Mbps rcv_space:14480 > > On Thu, May 22, 2014 at 06:47:56AM +0000, Scheffenegger, Richard wrote: >> >> Are you perhaps observing an effect of the ACK clock loss, when you refe= r to a huge number of consecutive lost segments? >> >> Standard SACK does suffer from an issue that during loss recovery, there= may be a gap (SACKs don't clock out new/retransmitted packets while flight= size > cwnd (which is now 1/2); only during the 2nd half, SACK starts to cl= ock out packets, but at the same rate as before (which may not that bright = an idea if a path change with differnet characteristics is now there). >> >> RateHalving (Linux has some kind of variant of this) / Proportional Rate= Reduction RFC6937 may be the thing that you are after? >> >> >> ABC really only comes into play during slowstart, to make connections wh= ich use delayed ACKs not perform much less aggressive than sessions where t= he receiver features QuickAck (Linux non-standard). >> >> Best regards, >> >> >> Richard Scheffenegger >> >> >> > -----Original Message----- >> > From: tcpm [mailto:tcpm-bounces@ietf.org] On Behalf Of Erik Hugne >> > Sent: Mittwoch, 21. Mai 2014 14:55 >> > To: Mark Allman >> > Cc: ingemar.s.johansson@ericsson.com; martin.isaksson@ericsson.com; >> > tcpm@ietf.org >> > Subject: Re: [tcpm] RFC3465:TCP ABC and SACK'ed data >> > >> > On Wed, May 21, 2014 at 07:46:28AM -0400, Mark Allman wrote: >> > > >> > > > TCP ABC (still in the experimental track) defines a method to >> > > > increase the cwnd based on the bytes being acknowledged, instead o= f >> > > > the number of acks that arrive. I am assuming that SACK'ed (RFC201= 8) >> > > > data should be included in this calculation, but i could find no >> > > > mention of this in RFC3465. Could someone confirm this? >> > > >> > > ABC does not include SACK information in its calculations and it >> > > cannot include SACK information. ABC applies to slow start---which >> > > ends when loss occurs. And, (essentially) SACKs only arrive during = loss >> > recovery. >> > > So, there is no need for ABC to deal with SACKs. >> > > >> > >> > Thanks for taking the time to explain this. >> > >> > The problem (this is related to Ingemars posts around "Problem with lo= w >> > SSthresh") is that following the path change, there is a large train o= f >> > segments being lost (say 150k out of a 500k window). Data at the end o= f >> > the window did make it through and is SACK'ed. Upon receiving these SA= CK's >> > the sending side enters loss recovery. It will take a very long time >> > before recovering the 100k lost segments. >> > >> > An aggressive recovery algorithm would mitigate the effects of this, b= ut i >> > was hoping for a more elegant solution. >> > >> > //E >> > >> > _______________________________________________ >> > 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 From nobody Fri May 23 16:06:46 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 E63E61A0194 for ; Fri, 23 May 2014 16:06:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.174 X-Spam-Level: ** X-Spam-Status: No, score=2.174 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, HTML_MESSAGE=0.001, J_CHICKENPOX_42=0.6, RELAY_IS_203=0.994, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] 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 TJyxTfXP3BJS for ; Fri, 23 May 2014 16:06:24 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.142.130]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0BB521A018E for ; Fri, 23 May 2014 16:06:18 -0700 (PDT) Received: from mail-we0-f180.google.com (mail-we0-f180.google.com [74.125.82.180]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id E6BDD2782D0 for ; Sat, 24 May 2014 08:06:14 +0900 (JST) Received: by mail-we0-f180.google.com with SMTP id t61so5595837wes.11 for ; Fri, 23 May 2014 16:06:12 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.194.184.179 with SMTP id ev19mr5068823wjc.85.1400886372596; Fri, 23 May 2014 16:06:12 -0700 (PDT) Received: by 10.194.88.9 with HTTP; Fri, 23 May 2014 16:06:12 -0700 (PDT) In-Reply-To: <20140523133251.GA28880@eerihug-hybrid.rnd.ki.sw.ericsson.se> References: <20140521073611.GA1940@eerihug-hybrid.rnd.ki.sw.ericsson.se> <20140521114628.C72DB6B339F@lawyers.icir.org> <20140521125518.GC1940@eerihug-hybrid.rnd.ki.sw.ericsson.se> <012C3117EDDB3C4781FD802A8C27DD4F4A3C3904@SACEXCMBX02-PRD.hq.netapp.com> <20140523133251.GA28880@eerihug-hybrid.rnd.ki.sw.ericsson.se> Date: Fri, 23 May 2014 16:06:12 -0700 Message-ID: From: Yoshifumi Nishida To: Erik Hugne Content-Type: multipart/alternative; boundary=047d7b87371e9c043904fa19464b Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/ROOK5Onlqr8tcPmOuhYxBHQKZtQ Cc: "ingemar.s.johansson@ericsson.com" , "tcpm@ietf.org" , Mark Allman , "martin.isaksson@ericsson.com" Subject: [tcpm] RFC3465:TCP ABC and SACK'ed data 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, 23 May 2014 23:06:27 -0000 --047d7b87371e9c043904fa19464b Content-Type: text/plain; charset=UTF-8 This is just out of my curiosity, but can we share the tcpdump file for this? -- Yoshi On Friday, May 23, 2014, Erik Hugne > wrote: > Maybe.. > This is a standard Linux 3.0 kernel with sack and frto enabled. > Additional lab experiments have shown that following the path change, a > stream > of lost packets occurs (almost a full window, ~400kB). The receiver sends > dupacks on the new path to trigger fast retransmit, but then the > retransmission > timer on the sender side fires and all unacked data will be resent. At the > RTO, > we get the expected cwnd drop. While the receiver keeps kicking the the > sender > by sending dupacks, the retransmission is reasonably fast but after a few > ms it > grinds down to a stop-and-go behaviour. > > I failed in my efforts to find some explanation to this in the RFC's. > What i did find was in VJ's paper from '88. > > -When starting or restarting after a loss, set cwnd to one packet. > -On each ack for new data, increase cwnd by one packet > > If retransmitted data are not considered "new", that would explain the > behavior > i guess. > > Scripted ss -ti for the connection every 3 sec. > In this test it wasn't even a path change, we just downed the interface on > a > router in the middle for some 300ms to simulate the packetloss (This was > done at 15:06:18) > > Fri May 23 15:06:01 CEST 2014 > reno wscale:9,7 rto:1892 rtt:1678/7 ato:40 cwnd:2215 send 15.3Mbps > rcv_space:14480 > Fri May 23 15:06:04 CEST 2014 > reno wscale:9,7 rto:1888 rtt:1678/8 ato:40 cwnd:2215 send 15.3Mbps > rcv_space:14480 > Fri May 23 15:06:07 CEST 2014 > reno wscale:9,7 rto:1888 rtt:1676/9 ato:40 cwnd:2215 send 15.3Mbps > rcv_space:14480 > Fri May 23 15:06:10 CEST 2014 > reno wscale:9,7 rto:1884 rtt:1675.5/5 ato:40 cwnd:2215 send > 15.3Mbps rcv_space:14480 > Fri May 23 15:06:14 CEST 2014 > reno wscale:9,7 rto:1816 rtt:1607.5/22 ato:40 cwnd:2215 send > 16.0Mbps rcv_space:14480 > Fri May 23 15:06:17 CEST 2014 > reno wscale:9,7 rto:1892 rtt:1681.5/7 ato:40 cwnd:2215 send > 15.3Mbps rcv_space:14480 > Fri May 23 15:06:20 CEST 2014 > reno wscale:9,7 rto:1548 rtt:651/225 ato:40 cwnd:3 ssthresh:1107 > send 53.4Kbps rcv_space:14480 > Fri May 23 15:06:23 CEST 2014 > reno wscale:9,7 rto:1224 rtt:263/110 ato:40 cwnd:3 ssthresh:1107 > send 132.1Kbps rcv_space:14480 > Fri May 23 15:06:26 CEST 2014 > reno wscale:9,7 rto:1172 rtt:210.5/18 ato:40 cwnd:3 ssthresh:1107 > send 165.1Kbps rcv_space:14480 > Fri May 23 15:06:29 CEST 2014 > reno wscale:9,7 rto:1164 rtt:203.5/6 ato:40 cwnd:3 ssthresh:1107 > send 170.8Kbps rcv_space:14480 > Fri May 23 15:06:32 CEST 2014 > reno wscale:9,7 rto:1164 rtt:203.5/3 ato:40 cwnd:3 ssthresh:1107 > send 170.8Kbps rcv_space:14480 > Fri May 23 15:06:35 CEST 2014 > reno wscale:9,7 rto:1164 rtt:203.5/3 ato:40 cwnd:6 ssthresh:1107 > send 341.5Kbps rcv_space:14480 > Fri May 23 15:06:38 CEST 2014 > reno wscale:9,7 rto:1164 rtt:203.5/4 ato:40 cwnd:6 ssthresh:1107 > send 341.5Kbps rcv_space:14480 > Fri May 23 15:06:41 CEST 2014 > reno wscale:9,7 rto:1168 rtt:204/4 ato:40 cwnd:6 ssthresh:1107 > send 340.7Kbps rcv_space:14480 > Fri May 23 15:06:44 CEST 2014 > reno wscale:9,7 rto:1164 rtt:203.5/3 ato:40 cwnd:6 ssthresh:1107 > send 341.5Kbps rcv_space:14480 > Fri May 23 15:06:47 CEST 2014 > reno wscale:9,7 rto:1164 rtt:203.5/3 ato:40 cwnd:6 ssthresh:1107 > send 341.5Kbps rcv_space:14480 > Fri May 23 15:06:50 CEST 2014 > reno wscale:9,7 rto:1164 rtt:203.5/3 ato:40 cwnd:6 ssthresh:1107 > send 341.5Kbps rcv_space:14480 > Fri May 23 15:06:53 CEST 2014 > reno wscale:9,7 rto:1164 rtt:203.5/3 ato:40 cwnd:6 ssthresh:1107 > send 341.5Kbps rcv_space:14480 > Fri May 23 15:06:56 CEST 2014 > reno wscale:9,7 rto:1164 rtt:203.5/3 ato:40 cwnd:6 ssthresh:1107 > send 341.5Kbps rcv_space:14480 > Fri May 23 15:06:59 CEST 2014 > reno wscale:9,7 rto:1164 rtt:203.5/4 ato:40 cwnd:6 ssthresh:1107 > send 341.5Kbps rcv_space:14480 > Fri May 23 15:07:02 CEST 2014 > reno wscale:9,7 rto:1164 rtt:203.5/3 ato:40 cwnd:9 ssthresh:1107 > send 512.3Kbps rcv_space:14480 > Fri May 23 15:07:05 CEST 2014 > reno wscale:9,7 rto:1164 rtt:203.5/3 ato:40 cwnd:9 ssthresh:1107 > send 512.3Kbps rcv_space:14480 > Fri May 23 15:07:08 CEST 2014 > reno wscale:9,7 rto:1164 rtt:203.5/3 ato:40 cwnd:9 ssthresh:1107 > send 512.3Kbps rcv_space:14480 > Fri May 23 15:07:11 CEST 2014 > reno wscale:9,7 rto:1260 rtt:487.5/8 ato:40 cwnd:960 ssthresh:1107 > send 22.8Mbps rcv_space:14480 > Fri May 23 15:07:14 CEST 2014 > reno wscale:9,7 rto:1244 rtt:863.5/6 ato:40 cwnd:1111 > ssthresh:1107 send 14.9Mbps rcv_space:14480 > Fri May 23 15:07:17 CEST 2014 > reno wscale:9,7 rto:1148 rtt:864/6 ato:40 cwnd:1114 ssthresh:1107 > send 14.9Mbps rcv_space:14480 > Fri May 23 15:07:20 CEST 2014 > reno wscale:9,7 rto:1096 rtt:868/8 ato:40 cwnd:1118 ssthresh:1107 > send 14.9Mbps rcv_space:14480 > > On Thu, May 22, 2014 at 06:47:56AM +0000, Scheffenegger, Richard wrote: > > > > Are you perhaps observing an effect of the ACK clock loss, when you > refer to a huge number of consecutive lost segments? > > > > Standard SACK does suffer from an issue that during loss recovery, there > may be a gap (SACKs don't clock out new/retransmitted packets while > flightsize > cwnd (which is now 1/2); only during the 2nd half, SACK starts > to clock out packets, but at the same rate as before (which may not that > bright an idea if a path change with differnet characteristics is now > there). > > > > RateHalving (Linux has some kind of variant of this) / Proportional Rate > Reduction RFC6937 may be the thing that you are after? > > > > > > ABC really only comes into play during slowstart, to make connections > which use delayed ACKs not perform much less aggressive than sessions where > the receiver features QuickAck (Linux non-standard). > > > > Best regards, > > > > > > Richard Scheffenegger > > > > > > > -----Original Message----- > > > From: tcpm [mailto:tcpm-bounces@ietf.org] On Behalf Of Erik Hugne > > > Sent: Mittwoch, 21. Mai 2014 14:55 > > > To: Mark Allman > > > Cc: ingemar.s.johansson@ericsson.com; martin.isaksson@ericsson.com; > > > tcpm@ietf.org > > > Subject: Re: [tcpm] RFC3465:TCP ABC and SACK'ed data > > > > > > On Wed, May 21, 2014 at 07:46:28AM -0400, Mark Allman wrote: > > > > > > > > > TCP ABC (still in the experimental track) defines a method to > > > > > increase the cwnd based on the bytes being acknowledged, instead of > > > > > the number of acks that arrive. I am assuming that SACK'ed > (RFC2018) > > > > > data should be included in this calculation, but i could find no > > > > > mention of this in RFC3465. Could someone confirm this? > > > > > > > > ABC does not include SACK information in its calculations and it > > > > cannot include SACK information. ABC applies to slow start---which > > > > ends when loss occurs. And, (essentially) SACKs only arrive during > loss > > > recovery. > > > > So, there is no need for ABC to deal with SACKs. > > > > > > > > > > Thanks for taking the time to explain this. > > > > > > The problem (this is related to Ingemars posts around "Problem with low > > > SSthresh") is that following the path change, there is a large train of > > > segments being lost (say 150k out of a 500k window). Data at the end of > > > the window did make it through and is SACK'ed. Upon receiving these > SACK's > > > the sending side enters loss recovery. It will take a very long time > > > before recovering the 100k lost segments. > > > > > > An aggressive recovery algorithm would mitigate the effects of this, > but i > > > was hoping for a more elegant solution. > > > > > > //E > > > > > > _______________________________________________ > > > 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 > --047d7b87371e9c043904fa19464b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable This is just out of my curiosity, but can we share the tcpdump file for thi= s?
--
Yoshi

On Friday, May 23, 2014, Erik Hugne <erik.hugne@ericsson.com> wrote:
Maybe..
This is a standard Linux 3.0 kernel with sack and frto enabled.
Additional lab experiments have shown that following the path change, a str= eam
of lost packets occurs (almost a full window, ~400kB). The receiver sends dupacks on the new path to trigger fast retransmit, but then the retransmis= sion
timer on the sender side fires and all unacked data will be resent. At the = RTO,
we get the expected cwnd drop. While the receiver keeps kicking the the sen= der
by sending dupacks, the retransmission is reasonably fast but after a few m= s it
grinds down to a stop-and-go behaviour.

I failed in my efforts to find some explanation to this in the RFC's. What i did find was in VJ's paper from '88.

-When starting or restarting after a loss, set cwnd to one packet.
-On each ack for new data, increase cwnd by one packet

If retransmitted data are not considered "new", that would explai= n the behavior
i guess.

Scripted ss -ti for the connection every 3 sec.
In this test it wasn't even a path change, we just downed the interface= on a
router in the middle for some 300ms to simulate the packetloss (This was do= ne at 15:06:18)

Fri May 23 15:06:01 CEST 2014
=C2=A0 =C2=A0 =C2=A0 =C2=A0 reno wscale:9,7 rto:1892 rtt:1678/7 ato:40 cwnd= :2215 send 15.3Mbps rcv_space:14480
Fri May 23 15:06:04 CEST 2014
=C2=A0 =C2=A0 =C2=A0 =C2=A0 reno wscale:9,7 rto:1888 rtt:1678/8 ato:40 cwnd= :2215 send 15.3Mbps rcv_space:14480
Fri May 23 15:06:07 CEST 2014
=C2=A0 =C2=A0 =C2=A0 =C2=A0 reno wscale:9,7 rto:1888 rtt:1676/9 ato:40 cwnd= :2215 send 15.3Mbps rcv_space:14480
Fri May 23 15:06:10 CEST 2014
=C2=A0 =C2=A0 =C2=A0 =C2=A0 reno wscale:9,7 rto:1884 rtt:1675.5/5 ato:40 cw= nd:2215 send 15.3Mbps rcv_space:14480
Fri May 23 15:06:14 CEST 2014
=C2=A0 =C2=A0 =C2=A0 =C2=A0 reno wscale:9,7 rto:1816 rtt:1607.5/22 ato:40 c= wnd:2215 send 16.0Mbps rcv_space:14480
Fri May 23 15:06:17 CEST 2014
=C2=A0 =C2=A0 =C2=A0 =C2=A0 reno wscale:9,7 rto:1892 rtt:1681.5/7 ato:40 cw= nd:2215 send 15.3Mbps rcv_space:14480
Fri May 23 15:06:20 CEST 2014
=C2=A0 =C2=A0 =C2=A0 =C2=A0 reno wscale:9,7 rto:1548 rtt:651/225 ato:40 cwn= d:3 ssthresh:1107 send 53.4Kbps rcv_space:14480
Fri May 23 15:06:23 CEST 2014
=C2=A0 =C2=A0 =C2=A0 =C2=A0 reno wscale:9,7 rto:1224 rtt:263/110 ato:40 cwn= d:3 ssthresh:1107 send 132.1Kbps rcv_space:14480
Fri May 23 15:06:26 CEST 2014
=C2=A0 =C2=A0 =C2=A0 =C2=A0 reno wscale:9,7 rto:1172 rtt:210.5/18 ato:40 cw= nd:3 ssthresh:1107 send 165.1Kbps rcv_space:14480
Fri May 23 15:06:29 CEST 2014
=C2=A0 =C2=A0 =C2=A0 =C2=A0 reno wscale:9,7 rto:1164 rtt:203.5/6 ato:40 cwn= d:3 ssthresh:1107 send 170.8Kbps rcv_space:14480
Fri May 23 15:06:32 CEST 2014
=C2=A0 =C2=A0 =C2=A0 =C2=A0 reno wscale:9,7 rto:1164 rtt:203.5/3 ato:40 cwn= d:3 ssthresh:1107 send 170.8Kbps rcv_space:14480
Fri May 23 15:06:35 CEST 2014
=C2=A0 =C2=A0 =C2=A0 =C2=A0 reno wscale:9,7 rto:1164 rtt:203.5/3 ato:40 cwn= d:6 ssthresh:1107 send 341.5Kbps rcv_space:14480
Fri May 23 15:06:38 CEST 2014
=C2=A0 =C2=A0 =C2=A0 =C2=A0 reno wscale:9,7 rto:1164 rtt:203.5/4 ato:40 cwn= d:6 ssthresh:1107 send 341.5Kbps rcv_space:14480
Fri May 23 15:06:41 CEST 2014
=C2=A0 =C2=A0 =C2=A0 =C2=A0 reno wscale:9,7 rto:1168 rtt:204/4 ato:40 cwnd:= 6 ssthresh:1107 send 340.7Kbps rcv_space:14480
Fri May 23 15:06:44 CEST 2014
=C2=A0 =C2=A0 =C2=A0 =C2=A0 reno wscale:9,7 rto:1164 rtt:203.5/3 ato:40 cwn= d:6 ssthresh:1107 send 341.5Kbps rcv_space:14480
Fri May 23 15:06:47 CEST 2014
=C2=A0 =C2=A0 =C2=A0 =C2=A0 reno wscale:9,7 rto:1164 rtt:203.5/3 ato:40 cwn= d:6 ssthresh:1107 send 341.5Kbps rcv_space:14480
Fri May 23 15:06:50 CEST 2014
=C2=A0 =C2=A0 =C2=A0 =C2=A0 reno wscale:9,7 rto:1164 rtt:203.5/3 ato:40 cwn= d:6 ssthresh:1107 send 341.5Kbps rcv_space:14480
Fri May 23 15:06:53 CEST 2014
=C2=A0 =C2=A0 =C2=A0 =C2=A0 reno wscale:9,7 rto:1164 rtt:203.5/3 ato:40 cwn= d:6 ssthresh:1107 send 341.5Kbps rcv_space:14480
Fri May 23 15:06:56 CEST 2014
=C2=A0 =C2=A0 =C2=A0 =C2=A0 reno wscale:9,7 rto:1164 rtt:203.5/3 ato:40 cwn= d:6 ssthresh:1107 send 341.5Kbps rcv_space:14480
Fri May 23 15:06:59 CEST 2014
=C2=A0 =C2=A0 =C2=A0 =C2=A0 reno wscale:9,7 rto:1164 rtt:203.5/4 ato:40 cwn= d:6 ssthresh:1107 send 341.5Kbps rcv_space:14480
Fri May 23 15:07:02 CEST 2014
=C2=A0 =C2=A0 =C2=A0 =C2=A0 reno wscale:9,7 rto:1164 rtt:203.5/3 ato:40 cwn= d:9 ssthresh:1107 send 512.3Kbps rcv_space:14480
Fri May 23 15:07:05 CEST 2014
=C2=A0 =C2=A0 =C2=A0 =C2=A0 reno wscale:9,7 rto:1164 rtt:203.5/3 ato:40 cwn= d:9 ssthresh:1107 send 512.3Kbps rcv_space:14480
Fri May 23 15:07:08 CEST 2014
=C2=A0 =C2=A0 =C2=A0 =C2=A0 reno wscale:9,7 rto:1164 rtt:203.5/3 ato:40 cwn= d:9 ssthresh:1107 send 512.3Kbps rcv_space:14480
Fri May 23 15:07:11 CEST 2014
=C2=A0 =C2=A0 =C2=A0 =C2=A0 reno wscale:9,7 rto:1260 rtt:487.5/8 ato:40 cwn= d:960 ssthresh:1107 send 22.8Mbps rcv_space:14480
Fri May 23 15:07:14 CEST 2014
=C2=A0 =C2=A0 =C2=A0 =C2=A0 reno wscale:9,7 rto:1244 rtt:863.5/6 ato:40 cwn= d:1111 ssthresh:1107 send 14.9Mbps rcv_space:14480
Fri May 23 15:07:17 CEST 2014
=C2=A0 =C2=A0 =C2=A0 =C2=A0 reno wscale:9,7 rto:1148 rtt:864/6 ato:40 cwnd:= 1114 ssthresh:1107 send 14.9Mbps rcv_space:14480
Fri May 23 15:07:20 CEST 2014
=C2=A0 =C2=A0 =C2=A0 =C2=A0 reno wscale:9,7 rto:1096 rtt:868/8 ato:40 cwnd:= 1118 ssthresh:1107 send 14.9Mbps rcv_space:14480

On Thu, May 22, 2014 at 06:47:56AM +0000, Scheffenegger, Richard wrote:
>
> Are you perhaps observing an effect of the ACK clock loss, when you re= fer to a huge number of consecutive lost segments?
>
> Standard SACK does suffer from an issue that during loss recovery, the= re may be a gap (SACKs don't clock out new/retransmitted packets while = flightsize > cwnd (which is now 1/2); only during the 2nd half, SACK sta= rts to clock out packets, but at the same rate as before (which may not tha= t bright an idea if a path change with differnet characteristics is now the= re).
>
> RateHalving (Linux has some kind of variant of this) / Proportional Ra= te Reduction RFC6937 may be the thing that you are after?
>
>
> ABC really only comes into play during slowstart, to make connections = which use delayed ACKs not perform much less aggressive than sessions where= the receiver features QuickAck (Linux non-standard).
>
> Best regards,
>
>
> Richard Scheffenegger
>
>
> > -----Original Message-----
> > From: tcpm [mailto:tcpm-bounces@ietf.org] On Behalf Of Eri= k Hugne
> > Sent: Mittwoch, 21. Mai 2014 14:55
> > To: Mark Allman
> > Cc: ingemar.s.johansson@ericsson.com; martin.isaksson@e= ricsson.com;
> > tcpm@ietf.org
> > Subject: Re: [tcpm] RFC3465:TCP ABC and SACK'ed data
> >
> > On Wed, May 21, 2014 at 07:46:28AM -0400, Mark Allman wrote:
> > >
> > > > TCP ABC (still in the experimental track) defines a met= hod to
> > > > increase the cwnd based on the bytes being acknowledged= , instead of
> > > > the number of acks that arrive. I am assuming that SACK= 'ed (RFC2018)
> > > > data should be included in this calculation, but i coul= d find no
> > > > mention of this in RFC3465. =C2=A0Could someone confirm= this?
> > >
> > > ABC does not include SACK information in its calculations an= d it
> > > cannot include SACK information. =C2=A0ABC applies to slow s= tart---which
> > > ends when loss occurs. =C2=A0And, (essentially) SACKs only a= rrive during loss
> > recovery.
> > > So, there is no need for ABC to deal with SACKs.
> > >
> >
> > Thanks for taking the time to explain this.
> >
> > The problem (this is related to Ingemars posts around "Probl= em with low
> > SSthresh") is that following the path change, there is a lar= ge train of
> > segments being lost (say 150k out of a 500k window). Data at the = end of
> > the window did make it through and is SACK'ed. Upon receiving= these SACK's
> > the sending side enters loss recovery. It will take a very long t= ime
> > before recovering the 100k lost segments.
> >
> > An aggressive recovery algorithm would mitigate the effects of th= is, but i
> > was hoping for a more elegant solution.
> >
> > //E
> >
> > _______________________________________________
> > 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
--047d7b87371e9c043904fa19464b-- From nobody Mon May 26 02:12:42 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 B77971A008E for ; Mon, 26 May 2014 02:12:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.301 X-Spam-Level: X-Spam-Status: No, score=-1.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_42=0.6, SPF_PASS=-0.001] 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 2pBZ_TnVWG1m for ; Mon, 26 May 2014 02:12:38 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E5051A007E for ; Mon, 26 May 2014 02:12:38 -0700 (PDT) X-AuditID: c1b4fb3a-f79746d000006fe2-02-5383058153fe Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id F6.D8.28642.18503835; Mon, 26 May 2014 11:12:33 +0200 (CEST) Received: from eerihug-hybrid.rnd.ki.sw.ericsson.se (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.59) with Microsoft SMTP Server id 14.3.174.1; Mon, 26 May 2014 11:12:32 +0200 Date: Mon, 26 May 2014 11:12:32 +0200 From: Erik Hugne To: Yoshifumi Nishida Message-ID: <20140526091232.GN20942@eerihug-hybrid.rnd.ki.sw.ericsson.se> References: <20140521073611.GA1940@eerihug-hybrid.rnd.ki.sw.ericsson.se> <20140521114628.C72DB6B339F@lawyers.icir.org> <20140521125518.GC1940@eerihug-hybrid.rnd.ki.sw.ericsson.se> <012C3117EDDB3C4781FD802A8C27DD4F4A3C3904@SACEXCMBX02-PRD.hq.netapp.com> <20140523133251.GA28880@eerihug-hybrid.rnd.ki.sw.ericsson.se> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrJLMWRmVeSWpSXmKPExsUyM+JvjW4ja3OwwZ8XJhbT1kxjsti45Aab xcp/Z9gttp2cz+TA4vHv0E1mjyVLfjJ5zPj0hc3j4uvrzAEsUVw2Kak5mWWpRfp2CVwZ9x5s Yytocav4+2YzWwPjErMuRg4OCQETiV+PBbsYOYFMMYkL99azdTFycQgJHGWUOLT9JZRzgFFi w4L/zCBVLAKqEh2L5rKC2GwCWhITn09kArFFBPQkPnz/yATSwCzwk1HiXPcPsCJhoA17Px5l BLF5BTwlZvRuZ4GY2sks8ezESqiEoMTJmU9YQGxmAR2JBbs/sYGcxywgLbH8HwdImFMgUOLM my52EFtUQEViysltbCC2EJB9/+Vs9gmMgrOQTJqFZNIshEkLGJlXMYoWpxYX56YbGemlFmUm Fxfn5+nlpZZsYgSG9cEtv612MB587niIUYCDUYmH90F6U7AQa2JZcWXuIUZpDhYlcd6LGtXB QgLpiSWp2ampBalF8UWlOanFhxiZODilGhiTmh+517qsv935NTA94sAhU85bai+P/LDLuqDF verQ3gUN62ICf9gpqO0Mv7DnkqvqjF2HfCYfZrfYl6xT4834JCnw+MpG6ZYo0We9qw8eTci6 YxyymX+5Urgpz5qUaXwG8y18OPPSqrYs25H/o9rv2K3aAN/8ezOb0k7M8d7lzLGvjjNl0Rwl luKMREMt5qLiRABatAKhTAIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/Hee5BdAfqzhHeyry8gDaerBLLMQ Cc: "ingemar.s.johansson@ericsson.com" , "tcpm@ietf.org" , Mark Allman , "martin.isaksson@ericsson.com" Subject: Re: [tcpm] RFC3465:TCP ABC and SACK'ed data 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, 26 May 2014 09:12:40 -0000 Here's from a test just this morning, wgetting a 10MB file. https://www.dropbox.com/sh/86u3nzcwukjzpzv/AAAlp_Me7wXf7PRyuWFq9Lmwa //E On Fri, May 23, 2014 at 04:06:12PM -0700, Yoshifumi Nishida wrote: > This is just out of my curiosity, but can we share the tcpdump file for > this? > -- > Yoshi > > On Friday, May 23, 2014, Erik Hugne > > > wrote: > > > Maybe.. > > This is a standard Linux 3.0 kernel with sack and frto enabled. > > Additional lab experiments have shown that following the path change, a > > stream > > of lost packets occurs (almost a full window, ~400kB). The receiver sends > > dupacks on the new path to trigger fast retransmit, but then the > > retransmission > > timer on the sender side fires and all unacked data will be resent. At the > > RTO, > > we get the expected cwnd drop. While the receiver keeps kicking the the > > sender > > by sending dupacks, the retransmission is reasonably fast but after a few > > ms it > > grinds down to a stop-and-go behaviour. > > > > I failed in my efforts to find some explanation to this in the RFC's. > > What i did find was in VJ's paper from '88. > > > > -When starting or restarting after a loss, set cwnd to one packet. > > -On each ack for new data, increase cwnd by one packet > > > > If retransmitted data are not considered "new", that would explain the > > behavior > > i guess. > > > > Scripted ss -ti for the connection every 3 sec. > > In this test it wasn't even a path change, we just downed the interface on > > a > > router in the middle for some 300ms to simulate the packetloss (This was > > done at 15:06:18) > > > > Fri May 23 15:06:01 CEST 2014 > > reno wscale:9,7 rto:1892 rtt:1678/7 ato:40 cwnd:2215 send 15.3Mbps > > rcv_space:14480 > > Fri May 23 15:06:04 CEST 2014 > > reno wscale:9,7 rto:1888 rtt:1678/8 ato:40 cwnd:2215 send 15.3Mbps > > rcv_space:14480 > > Fri May 23 15:06:07 CEST 2014 > > reno wscale:9,7 rto:1888 rtt:1676/9 ato:40 cwnd:2215 send 15.3Mbps > > rcv_space:14480 > > Fri May 23 15:06:10 CEST 2014 > > reno wscale:9,7 rto:1884 rtt:1675.5/5 ato:40 cwnd:2215 send > > 15.3Mbps rcv_space:14480 > > Fri May 23 15:06:14 CEST 2014 > > reno wscale:9,7 rto:1816 rtt:1607.5/22 ato:40 cwnd:2215 send > > 16.0Mbps rcv_space:14480 > > Fri May 23 15:06:17 CEST 2014 > > reno wscale:9,7 rto:1892 rtt:1681.5/7 ato:40 cwnd:2215 send > > 15.3Mbps rcv_space:14480 > > Fri May 23 15:06:20 CEST 2014 > > reno wscale:9,7 rto:1548 rtt:651/225 ato:40 cwnd:3 ssthresh:1107 > > send 53.4Kbps rcv_space:14480 > > Fri May 23 15:06:23 CEST 2014 > > reno wscale:9,7 rto:1224 rtt:263/110 ato:40 cwnd:3 ssthresh:1107 > > send 132.1Kbps rcv_space:14480 > > Fri May 23 15:06:26 CEST 2014 > > reno wscale:9,7 rto:1172 rtt:210.5/18 ato:40 cwnd:3 ssthresh:1107 > > send 165.1Kbps rcv_space:14480 > > Fri May 23 15:06:29 CEST 2014 > > reno wscale:9,7 rto:1164 rtt:203.5/6 ato:40 cwnd:3 ssthresh:1107 > > send 170.8Kbps rcv_space:14480 > > Fri May 23 15:06:32 CEST 2014 > > reno wscale:9,7 rto:1164 rtt:203.5/3 ato:40 cwnd:3 ssthresh:1107 > > send 170.8Kbps rcv_space:14480 > > Fri May 23 15:06:35 CEST 2014 > > reno wscale:9,7 rto:1164 rtt:203.5/3 ato:40 cwnd:6 ssthresh:1107 > > send 341.5Kbps rcv_space:14480 > > Fri May 23 15:06:38 CEST 2014 > > reno wscale:9,7 rto:1164 rtt:203.5/4 ato:40 cwnd:6 ssthresh:1107 > > send 341.5Kbps rcv_space:14480 > > Fri May 23 15:06:41 CEST 2014 > > reno wscale:9,7 rto:1168 rtt:204/4 ato:40 cwnd:6 ssthresh:1107 > > send 340.7Kbps rcv_space:14480 > > Fri May 23 15:06:44 CEST 2014 > > reno wscale:9,7 rto:1164 rtt:203.5/3 ato:40 cwnd:6 ssthresh:1107 > > send 341.5Kbps rcv_space:14480 > > Fri May 23 15:06:47 CEST 2014 > > reno wscale:9,7 rto:1164 rtt:203.5/3 ato:40 cwnd:6 ssthresh:1107 > > send 341.5Kbps rcv_space:14480 > > Fri May 23 15:06:50 CEST 2014 > > reno wscale:9,7 rto:1164 rtt:203.5/3 ato:40 cwnd:6 ssthresh:1107 > > send 341.5Kbps rcv_space:14480 > > Fri May 23 15:06:53 CEST 2014 > > reno wscale:9,7 rto:1164 rtt:203.5/3 ato:40 cwnd:6 ssthresh:1107 > > send 341.5Kbps rcv_space:14480 > > Fri May 23 15:06:56 CEST 2014 > > reno wscale:9,7 rto:1164 rtt:203.5/3 ato:40 cwnd:6 ssthresh:1107 > > send 341.5Kbps rcv_space:14480 > > Fri May 23 15:06:59 CEST 2014 > > reno wscale:9,7 rto:1164 rtt:203.5/4 ato:40 cwnd:6 ssthresh:1107 > > send 341.5Kbps rcv_space:14480 > > Fri May 23 15:07:02 CEST 2014 > > reno wscale:9,7 rto:1164 rtt:203.5/3 ato:40 cwnd:9 ssthresh:1107 > > send 512.3Kbps rcv_space:14480 > > Fri May 23 15:07:05 CEST 2014 > > reno wscale:9,7 rto:1164 rtt:203.5/3 ato:40 cwnd:9 ssthresh:1107 > > send 512.3Kbps rcv_space:14480 > > Fri May 23 15:07:08 CEST 2014 > > reno wscale:9,7 rto:1164 rtt:203.5/3 ato:40 cwnd:9 ssthresh:1107 > > send 512.3Kbps rcv_space:14480 > > Fri May 23 15:07:11 CEST 2014 > > reno wscale:9,7 rto:1260 rtt:487.5/8 ato:40 cwnd:960 ssthresh:1107 > > send 22.8Mbps rcv_space:14480 > > Fri May 23 15:07:14 CEST 2014 > > reno wscale:9,7 rto:1244 rtt:863.5/6 ato:40 cwnd:1111 > > ssthresh:1107 send 14.9Mbps rcv_space:14480 > > Fri May 23 15:07:17 CEST 2014 > > reno wscale:9,7 rto:1148 rtt:864/6 ato:40 cwnd:1114 ssthresh:1107 > > send 14.9Mbps rcv_space:14480 > > Fri May 23 15:07:20 CEST 2014 > > reno wscale:9,7 rto:1096 rtt:868/8 ato:40 cwnd:1118 ssthresh:1107 > > send 14.9Mbps rcv_space:14480 > > > > On Thu, May 22, 2014 at 06:47:56AM +0000, Scheffenegger, Richard wrote: > > > > > > Are you perhaps observing an effect of the ACK clock loss, when you > > refer to a huge number of consecutive lost segments? > > > > > > Standard SACK does suffer from an issue that during loss recovery, there > > may be a gap (SACKs don't clock out new/retransmitted packets while > > flightsize > cwnd (which is now 1/2); only during the 2nd half, SACK starts > > to clock out packets, but at the same rate as before (which may not that > > bright an idea if a path change with differnet characteristics is now > > there). > > > > > > RateHalving (Linux has some kind of variant of this) / Proportional Rate > > Reduction RFC6937 may be the thing that you are after? > > > > > > > > > ABC really only comes into play during slowstart, to make connections > > which use delayed ACKs not perform much less aggressive than sessions where > > the receiver features QuickAck (Linux non-standard). > > > > > > Best regards, > > > > > > > > > Richard Scheffenegger > > > > > > > > > > -----Original Message----- > > > > From: tcpm [mailto:tcpm-bounces@ietf.org] On Behalf Of Erik Hugne > > > > Sent: Mittwoch, 21. Mai 2014 14:55 > > > > To: Mark Allman > > > > Cc: ingemar.s.johansson@ericsson.com; martin.isaksson@ericsson.com; > > > > tcpm@ietf.org > > > > Subject: Re: [tcpm] RFC3465:TCP ABC and SACK'ed data > > > > > > > > On Wed, May 21, 2014 at 07:46:28AM -0400, Mark Allman wrote: > > > > > > > > > > > TCP ABC (still in the experimental track) defines a method to > > > > > > increase the cwnd based on the bytes being acknowledged, instead of > > > > > > the number of acks that arrive. I am assuming that SACK'ed > > (RFC2018) > > > > > > data should be included in this calculation, but i could find no > > > > > > mention of this in RFC3465. Could someone confirm this? > > > > > > > > > > ABC does not include SACK information in its calculations and it > > > > > cannot include SACK information. ABC applies to slow start---which > > > > > ends when loss occurs. And, (essentially) SACKs only arrive during > > loss > > > > recovery. > > > > > So, there is no need for ABC to deal with SACKs. > > > > > > > > > > > > > Thanks for taking the time to explain this. > > > > > > > > The problem (this is related to Ingemars posts around "Problem with low > > > > SSthresh") is that following the path change, there is a large train of > > > > segments being lost (say 150k out of a 500k window). Data at the end of > > > > the window did make it through and is SACK'ed. Upon receiving these > > SACK's > > > > the sending side enters loss recovery. It will take a very long time > > > > before recovering the 100k lost segments. > > > > > > > > An aggressive recovery algorithm would mitigate the effects of this, > > but i > > > > was hoping for a more elegant solution. > > > > > > > > //E > > > > > > > > _______________________________________________ > > > > 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 > > From nobody Mon May 26 02:38:09 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 405901A00A3 for ; Mon, 26 May 2014 02:38:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.553 X-Spam-Level: X-Spam-Status: No, score=-2.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, 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 t4D-SwnB5TNQ for ; Mon, 26 May 2014 02:38:06 -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 4897E1A0092 for ; Mon, 26 May 2014 02:38:06 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.98,911,1392192000"; d="asc'?scan'208";a="125206157" Received: from vmwexceht03-prd.hq.netapp.com ([10.106.76.241]) by mx11-out.netapp.com with ESMTP; 26 May 2014 02:38:03 -0700 Received: from HIOEXCMBX01-PRD.hq.netapp.com (10.122.105.34) by vmwexceht03-prd.hq.netapp.com (10.106.76.241) with Microsoft SMTP Server (TLS) id 14.3.123.3; Mon, 26 May 2014 02:38:03 -0700 Received: from HIOEXCMBX07-PRD.hq.netapp.com (10.122.105.40) by hioexcmbx01-prd.hq.netapp.com (10.122.105.34) with Microsoft SMTP Server (TLS) id 15.0.847.32; Mon, 26 May 2014 02:38:02 -0700 Received: from HIOEXCMBX07-PRD.hq.netapp.com ([::1]) by hioexcmbx07-prd.hq.netapp.com ([fe80::d865:b6fe:275f:ffef%21]) with mapi id 15.00.0847.030; Mon, 26 May 2014 02:37:43 -0700 From: "Eggert, Lars" To: Joe Touch Thread-Topic: timestamp options (was Re: [tcpm] New Version Notification for draft-touch-tcpm-tcp-edo-01.txt) Thread-Index: AQHPeMYkJHajOrUzbEmQxvhW+sKU8g== Date: Mon, 26 May 2014 09:37:43 +0000 Message-ID: References: <20140425221257.12559.43206.idtracker@ietfa.amsl.com> <2586_1398464386_535ADF82_2586_915_1_535ADF56.9050106@isi.edu> <5363AF84.8090701@mti-systems.com> <5363B397.8090009@isi.edu> <655C07320163294895BBADA28372AF5D2CFE36@FR712WXCHMBA15.zeu.alcatel-lucent.com> <20140503122950.GM44329@verdi> <655C07320163294895BBADA28372AF5D2D009E@FR712WXCHMBA15.zeu.alcatel-lucent.com> <201405221710.s4MHAY4S002037@bagheera.jungle.bt.co.uk> <537E3ACD.5000308@isi.edu> <537E48CE.8040704@mti-systems.com> <537E66A7.4080907@isi.edu> <201405231003.s4NA3PAB005137@bagheera.jungle.bt.co.uk> <537F7D91.10802@isi.edu> In-Reply-To: <537F7D91.10802@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.122.56.79] Content-Type: multipart/signed; boundary="Apple-Mail=_18E79A9B-96B7-4B22-B9D7-4EB45EB51D8F"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/ut5XKmRe-HzhJJyUTsSYjlzSMxg Cc: "tcpm@ietf.org" Subject: [tcpm] timestamp options (was Re: New Version Notification for draft-touch-tcpm-tcp-edo-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, 26 May 2014 09:38:07 -0000 --Apple-Mail=_18E79A9B-96B7-4B22-B9D7-4EB45EB51D8F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, On 2014-5-23, at 18:55, Joe Touch wrote: > Current total for SYN options in widespread concurrent use (as already = described in sec 6.4): >=20 > 2 SACK permitted > 10 timestamp > 3 window scale > 4 MSS > ------------------ > 11 bytes I think it was Mark Allman who questioned a while ago whether the = benefits of the timestamp option are worth spending 10 bytes in every = packet. (But I can't find the email now.) > 11 widespread basic options > 16 TCP-AO > 20 MPTCP > -------------------- > 47 If we could shave those off, we'd be at 37 even with AO. It wouldn't = make the option space any bigger for the future, but it would get us out = of the current situation, and would make a combination of some crypto = and MPTCP be deployable. Lars --Apple-Mail=_18E79A9B-96B7-4B22-B9D7-4EB45EB51D8F 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----- iQCVAwUBU4MLZ9ZcnpRveo1xAQJn5gP+P3lcVIIQPE2p8yCBIsVn1W/RMuwDBi0P 3VFCrrIvfs1ON4aESh478roVQz5qq00DYAabEzfe9yNZKFPF1Bf6Cf/cC3Z1AZJb vJJ3oCj8TFsRQ7kmFTbqTQKh+De2nQrP5LYR4R9EttHLAaj1DVYPJmmjgpGbszKu GwQXw9jN9dE= =zuGX -----END PGP SIGNATURE----- --Apple-Mail=_18E79A9B-96B7-4B22-B9D7-4EB45EB51D8F-- From nobody Mon May 26 03:00: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 F41851A00AF for ; Mon, 26 May 2014 03:00:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 Nrq_n8fR6xUd for ; Mon, 26 May 2014 03:00:38 -0700 (PDT) Received: from trammell.ch (trammell1.nine.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id 061E31A0092 for ; Mon, 26 May 2014 03:00:38 -0700 (PDT) Received: from public-docking-etx-1877.ethz.ch (public-docking-pat-etx-mapped-0000.ethz.ch [195.176.110.225]) by trammell.ch (Postfix) with ESMTPSA id DE8DF1A0725; Mon, 26 May 2014 12:00:34 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Brian Trammell In-Reply-To: Date: Mon, 26 May 2014 12:00:33 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <80B1F1B4-B4DF-4DDF-8ED5-3029EF67EC15@trammell.ch> References: <20140425221257.12559.43206.idtracker@ietfa.amsl.com> <2586_1398464386_535ADF82_2586_915_1_535ADF56.9050106@isi.edu> <5363AF84.8090701@mti-systems.com> <5363B397.8090009@isi.edu> <655C07320163294895BBADA28372AF5D2CFE36@FR712WXCHMBA15.zeu.alcatel-lucent.com> <20140503122950.GM44329@verdi> <655C07320163294895BBADA28372AF5D2D009E@FR712WXCHMBA15.zeu.alcatel-lucent.com> <201405221710.s4MHAY4S002037@bagheera.jungle.bt.co.uk> <537E3ACD.5000308@isi.edu> <537E48CE.8040704@mti-systems.com> <537E66A7.4080907@isi.edu> <201405231003.s4NA3PAB005137@bagheera.jungle.bt.co.uk> <537F7D91.10802@isi.edu> To: "Eggert, Lars" X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/EkcKknViwrCVjab9BgD5LsR_3Ps Cc: "tcpm@ietf.org" , Joe Touch Subject: Re: [tcpm] timestamp options (was Re: New Version Notification for draft-touch-tcpm-tcp-edo-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, 26 May 2014 10:00:43 -0000 On 26 May 2014, at 11:37, Eggert, Lars wrote: > Hi, >=20 > On 2014-5-23, at 18:55, Joe Touch wrote: >> Current total for SYN options in widespread concurrent use (as = already described in sec 6.4): >>=20 >> 2 SACK permitted >> 10 timestamp >> 3 window scale >> 4 MSS >> ------------------ >> 11 bytes >=20 > I think it was Mark Allman who questioned a while ago whether the = benefits of the timestamp option are worth spending 10 bytes in every = packet. (But I can't find the email now.) >=20 >> 11 widespread basic options >> 16 TCP-AO >> 20 MPTCP >> -------------------- >> 47 >=20 > If we could shave those off, we'd be at 37 even with AO. It wouldn't = make the option space any bigger for the future, but it would get us out = of the current situation, and would make a combination of some crypto = and MPTCP be deployable. SACK and WScale are in use by the majority of sources, but (depending on = where you're looking from), only about a third of senders ever use the = timestamp options (lots of sources; the most recent is CCR April '14, = Honda et al "Rekindling Network Protocol Innovation with User-Level = Stacks", introduction), largely an effect of OS-level defaults. So an = either-or approach for TS or TCP-AO would probably work. (Doing this would make in-path passive measurement of RTT on = mostly-unidirectional flows basically impossible, but in a post-BCP188 = world we should probably be working on instrumenting endpoints for = debugging and monitoring, anyway...) Cheers, Brian From nobody Mon May 26 03:06: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 4FC731A00B6 for ; Mon, 26 May 2014 03:06:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-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 EinqtsJtk5Ap for ; Mon, 26 May 2014 03:06:30 -0700 (PDT) Received: from hoemail1.alcatel.com (hoemail1.alcatel.com [192.160.6.148]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3942C1A0092 for ; Mon, 26 May 2014 03:06:29 -0700 (PDT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (h135-239-2-122.lucent.com [135.239.2.122]) by hoemail1.alcatel.com (8.13.8/IER-o) with ESMTP id s4QA6Onr022862 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 26 May 2014 05:06:25 -0500 (CDT) Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id s4QA6NMT002515 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 26 May 2014 12:06:23 +0200 Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.185]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.02.0247.003; Mon, 26 May 2014 12:06:23 +0200 From: "Scharf, Michael (Michael)" To: "Eggert, Lars" , Joe Touch Thread-Topic: [tcpm] timestamp options (was Re: New Version Notification for draft-touch-tcpm-tcp-edo-01.txt) Thread-Index: AQHPeMY6BHtOWL7DHkmmOC47VuZhz5tSoFQw Date: Mon, 26 May 2014 10:06:22 +0000 Message-ID: <655C07320163294895BBADA28372AF5D305E00@FR712WXCHMBA15.zeu.alcatel-lucent.com> References: <20140425221257.12559.43206.idtracker@ietfa.amsl.com> <2586_1398464386_535ADF82_2586_915_1_535ADF56.9050106@isi.edu> <5363AF84.8090701@mti-systems.com> <5363B397.8090009@isi.edu> <655C07320163294895BBADA28372AF5D2CFE36@FR712WXCHMBA15.zeu.alcatel-lucent.com> <20140503122950.GM44329@verdi> <655C07320163294895BBADA28372AF5D2D009E@FR712WXCHMBA15.zeu.alcatel-lucent.com> <201405221710.s4MHAY4S002037@bagheera.jungle.bt.co.uk> <537E3ACD.5000308@isi.edu> <537E48CE.8040704@mti-systems.com> <537E66A7.4080907@isi.edu> <201405231003.s4NA3PAB005137@bagheera.jungle.bt.co.uk> <537F7D91.10802@isi.edu> 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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/sBYAOvlOrqmSCFxo2hElo29OeyE Cc: "tcpm@ietf.org" Subject: Re: [tcpm] timestamp options (was Re: New Version Notification for draft-touch-tcpm-tcp-edo-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, 26 May 2014 10:06:34 -0000 > -----Original Message----- > From: tcpm [mailto:tcpm-bounces@ietf.org] On Behalf Of Eggert, Lars > Sent: Monday, May 26, 2014 11:38 AM > To: Joe Touch > Cc: tcpm@ietf.org > Subject: [tcpm] timestamp options (was Re: New Version Notification for > draft-touch-tcpm-tcp-edo-01.txt) >=20 > Hi, >=20 > On 2014-5-23, at 18:55, Joe Touch wrote: > > Current total for SYN options in widespread concurrent use (as > already described in sec 6.4): > > > > 2 SACK permitted > > 10 timestamp > > 3 window scale > > 4 MSS > > ------------------ > > 11 bytes >=20 > I think it was Mark Allman who questioned a while ago whether the > benefits of the timestamp option are worth spending 10 bytes in every > packet. (But I can't find the email now.) And we have already had a long discussion on late enablement of timestamps.= Given that we submitted 1323bis in the meantime, I actually think we could= spend some cycles on saving those 10B from SYNs (if there was agreement th= at it is doable).=20 Michael (chair hat off) From nobody Mon May 26 03:32: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 429C21A00DE for ; Mon, 26 May 2014 03:32:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.601 X-Spam-Level: X-Spam-Status: No, score=-3.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_MED=-2.3, 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 l6CqKRrT5Zd1 for ; Mon, 26 May 2014 03:32:28 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DEA7D1A00DF for ; Mon, 26 May 2014 03:32:24 -0700 (PDT) X-AuditID: c1b4fb30-f79a56d000006536-6d-538318341c24 Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 2C.51.25910.43813835; Mon, 26 May 2014 12:32:20 +0200 (CEST) Received: from eerihug-hybrid.rnd.ki.sw.ericsson.se (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.23) with Microsoft SMTP Server id 14.3.174.1; Mon, 26 May 2014 12:32:20 +0200 Date: Mon, 26 May 2014 12:32:20 +0200 From: Erik Hugne To: Neal Cardwell Message-ID: <20140526103219.GP20942@eerihug-hybrid.rnd.ki.sw.ericsson.se> References: <20140521073611.GA1940@eerihug-hybrid.rnd.ki.sw.ericsson.se> <20140521114628.C72DB6B339F@lawyers.icir.org> <20140521125518.GC1940@eerihug-hybrid.rnd.ki.sw.ericsson.se> <012C3117EDDB3C4781FD802A8C27DD4F4A3C3904@SACEXCMBX02-PRD.hq.netapp.com> <20140523133251.GA28880@eerihug-hybrid.rnd.ki.sw.ericsson.se> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrHLMWRmVeSWpSXmKPExsUyM+Jvja6JRHOwwa2jZhbT1kxjsui4s5fF YuW/M+wW207OZ7L48vgqmwOrx4JNpR7/Dt1k9liy5CeTx4xPX9gCWKK4bFJSczLLUov07RK4 MpY8uc1acM6j4sjKfUwNjNMtuxg5OSQETCT+Xv/CDGGLSVy4t56ti5GLQ0jgKKPE8auLWSGc A4wSza9ns4JUsQioSuw98JsdxGYT0JKY+HwiE4gtIqAhcXfRA0aQBmaBeUwSbQ3XwRLCQCv2 fjzKCGLzCnhKXDzymxliaiezxL+PV9ghEoISJ2c+YQGxmQV0JBbs/gR0BweQLS2x/B8HSJhT IFBi6v6FYCWiAioSU05uYwOxhYDs+y9ns09gFJyFZNIsJJNmIUxawMi8ilG0OLU4KTfdyEgv tSgzubg4P08vL7VkEyMwwA9u+W2wg/Hlc8dDjAIcjEo8vA/Sm4KFWBPLiitzDzFKc7AoifNe 1KgOFhJITyxJzU5NLUgtii8qzUktPsTIxMEp1cDo5uV2kTW1jeHiQfH8YPHft97f337zjeRM U20DdvvZh7vixM86SvIlnK+aftO1d8UCzYkyc2u+CW2z//2zb92JjvrmWM+Z995PnveKpdx8 ofUl6Q3u+juunBYsmhR+7jHLgcud4tcTnhsVM15ImabAft3m2xoxx6d5JWLMP+Z0d0s+3r94 9s4IJZbijERDLeai4kQAyLjz4FECAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/GLIwsTNSfmCR85RygxO-P8a4gLY Cc: "tcpm@ietf.org" , "martin.isaksson@ericsson.com" , Mark Allman , "ingemar.s.johansson@ericsson.com" Subject: Re: [tcpm] RFC3465:TCP ABC and SACK'ed data 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, 26 May 2014 10:32:33 -0000 On Fri, May 23, 2014 at 01:37:19PM -0400, Neal Cardwell wrote: > On Fri, May 23, 2014 at 9:32 AM, Erik Hugne wrote: > > Maybe.. > > This is a standard Linux 3.0 kernel with sack and frto enabled. > > Additional lab experiments have shown that following the path change, a stream > > of lost packets occurs (almost a full window, ~400kB). The receiver sends > > dupacks on the new path to trigger fast retransmit, but then the retransmission > > timer on the sender side fires and all unacked data will be resent. At the RTO, > > we get the expected cwnd drop. While the receiver keeps kicking the the sender > > by sending dupacks, the retransmission is reasonably fast but after a few ms it > > grinds down to a stop-and-go behaviour. > > It sounds like the big problems start with the RTO. In theory, if the > sender is getting enough SACKs then it ought to be able to repair all > those lost packets in one or a handful of RTTs, depending on just how > many were lost, and how much the RTT jumps upward in the switch to the > new path. > > Can you retry your experiments with Linux 3.13 or newer? Recent Linux > kernels (3.13 and beyond) should do better in this regard: Yuchung > Cheng (cc-ed) has made some nice changes that take RTT measurements > from SACKs of unretransmitted data, and then keep updating the RTO > timer accordingly. > > Regarding your scenario - what are the RTTs of the old and new paths? In the synthetic experiment below, there is no path change, we just "insert" a transient loss and the RTT are the same before and after. I'll see if i can bump the kernel version to 3.13 and retry. //E > > cheers, > neal > > > I failed in my efforts to find some explanation to this in the RFC's. > > What i did find was in VJ's paper from '88. > > > > -When starting or restarting after a loss, set cwnd to one packet. > > -On each ack for new data, increase cwnd by one packet > > > > If retransmitted data are not considered "new", that would explain the behavior > > i guess. > > > > Scripted ss -ti for the connection every 3 sec. > > In this test it wasn't even a path change, we just downed the interface on a > > router in the middle for some 300ms to simulate the packetloss (This was done at 15:06:18) > > > > Fri May 23 15:06:01 CEST 2014 > > reno wscale:9,7 rto:1892 rtt:1678/7 ato:40 cwnd:2215 send 15.3Mbps rcv_space:14480 > > Fri May 23 15:06:04 CEST 2014 > > reno wscale:9,7 rto:1888 rtt:1678/8 ato:40 cwnd:2215 send 15.3Mbps rcv_space:14480 > > Fri May 23 15:06:07 CEST 2014 > > reno wscale:9,7 rto:1888 rtt:1676/9 ato:40 cwnd:2215 send 15.3Mbps rcv_space:14480 > > Fri May 23 15:06:10 CEST 2014 > > reno wscale:9,7 rto:1884 rtt:1675.5/5 ato:40 cwnd:2215 send 15.3Mbps rcv_space:14480 > > Fri May 23 15:06:14 CEST 2014 > > reno wscale:9,7 rto:1816 rtt:1607.5/22 ato:40 cwnd:2215 send 16.0Mbps rcv_space:14480 > > Fri May 23 15:06:17 CEST 2014 > > reno wscale:9,7 rto:1892 rtt:1681.5/7 ato:40 cwnd:2215 send 15.3Mbps rcv_space:14480 > > Fri May 23 15:06:20 CEST 2014 > > reno wscale:9,7 rto:1548 rtt:651/225 ato:40 cwnd:3 ssthresh:1107 send 53.4Kbps rcv_space:14480 > > Fri May 23 15:06:23 CEST 2014 > > reno wscale:9,7 rto:1224 rtt:263/110 ato:40 cwnd:3 ssthresh:1107 send 132.1Kbps rcv_space:14480 > > Fri May 23 15:06:26 CEST 2014 > > reno wscale:9,7 rto:1172 rtt:210.5/18 ato:40 cwnd:3 ssthresh:1107 send 165.1Kbps rcv_space:14480 > > Fri May 23 15:06:29 CEST 2014 > > reno wscale:9,7 rto:1164 rtt:203.5/6 ato:40 cwnd:3 ssthresh:1107 send 170.8Kbps rcv_space:14480 > > Fri May 23 15:06:32 CEST 2014 > > reno wscale:9,7 rto:1164 rtt:203.5/3 ato:40 cwnd:3 ssthresh:1107 send 170.8Kbps rcv_space:14480 > > Fri May 23 15:06:35 CEST 2014 > > reno wscale:9,7 rto:1164 rtt:203.5/3 ato:40 cwnd:6 ssthresh:1107 send 341.5Kbps rcv_space:14480 > > Fri May 23 15:06:38 CEST 2014 > > reno wscale:9,7 rto:1164 rtt:203.5/4 ato:40 cwnd:6 ssthresh:1107 send 341.5Kbps rcv_space:14480 > > Fri May 23 15:06:41 CEST 2014 > > reno wscale:9,7 rto:1168 rtt:204/4 ato:40 cwnd:6 ssthresh:1107 send 340.7Kbps rcv_space:14480 > > Fri May 23 15:06:44 CEST 2014 > > reno wscale:9,7 rto:1164 rtt:203.5/3 ato:40 cwnd:6 ssthresh:1107 send 341.5Kbps rcv_space:14480 > > Fri May 23 15:06:47 CEST 2014 > > reno wscale:9,7 rto:1164 rtt:203.5/3 ato:40 cwnd:6 ssthresh:1107 send 341.5Kbps rcv_space:14480 > > Fri May 23 15:06:50 CEST 2014 > > reno wscale:9,7 rto:1164 rtt:203.5/3 ato:40 cwnd:6 ssthresh:1107 send 341.5Kbps rcv_space:14480 > > Fri May 23 15:06:53 CEST 2014 > > reno wscale:9,7 rto:1164 rtt:203.5/3 ato:40 cwnd:6 ssthresh:1107 send 341.5Kbps rcv_space:14480 > > Fri May 23 15:06:56 CEST 2014 > > reno wscale:9,7 rto:1164 rtt:203.5/3 ato:40 cwnd:6 ssthresh:1107 send 341.5Kbps rcv_space:14480 > > Fri May 23 15:06:59 CEST 2014 > > reno wscale:9,7 rto:1164 rtt:203.5/4 ato:40 cwnd:6 ssthresh:1107 send 341.5Kbps rcv_space:14480 > > Fri May 23 15:07:02 CEST 2014 > > reno wscale:9,7 rto:1164 rtt:203.5/3 ato:40 cwnd:9 ssthresh:1107 send 512.3Kbps rcv_space:14480 > > Fri May 23 15:07:05 CEST 2014 > > reno wscale:9,7 rto:1164 rtt:203.5/3 ato:40 cwnd:9 ssthresh:1107 send 512.3Kbps rcv_space:14480 > > Fri May 23 15:07:08 CEST 2014 > > reno wscale:9,7 rto:1164 rtt:203.5/3 ato:40 cwnd:9 ssthresh:1107 send 512.3Kbps rcv_space:14480 > > Fri May 23 15:07:11 CEST 2014 > > reno wscale:9,7 rto:1260 rtt:487.5/8 ato:40 cwnd:960 ssthresh:1107 send 22.8Mbps rcv_space:14480 > > Fri May 23 15:07:14 CEST 2014 > > reno wscale:9,7 rto:1244 rtt:863.5/6 ato:40 cwnd:1111 ssthresh:1107 send 14.9Mbps rcv_space:14480 > > Fri May 23 15:07:17 CEST 2014 > > reno wscale:9,7 rto:1148 rtt:864/6 ato:40 cwnd:1114 ssthresh:1107 send 14.9Mbps rcv_space:14480 > > Fri May 23 15:07:20 CEST 2014 > > reno wscale:9,7 rto:1096 rtt:868/8 ato:40 cwnd:1118 ssthresh:1107 send 14.9Mbps rcv_space:14480 > > > > On Thu, May 22, 2014 at 06:47:56AM +0000, Scheffenegger, Richard wrote: > >> > >> Are you perhaps observing an effect of the ACK clock loss, when you refer to a huge number of consecutive lost segments? > >> > >> Standard SACK does suffer from an issue that during loss recovery, there may be a gap (SACKs don't clock out new/retransmitted packets while flightsize > cwnd (which is now 1/2); only during the 2nd half, SACK starts to clock out packets, but at the same rate as before (which may not that bright an idea if a path change with differnet characteristics is now there). > >> > >> RateHalving (Linux has some kind of variant of this) / Proportional Rate Reduction RFC6937 may be the thing that you are after? > >> > >> > >> ABC really only comes into play during slowstart, to make connections which use delayed ACKs not perform much less aggressive than sessions where the receiver features QuickAck (Linux non-standard). > >> > >> Best regards, > >> > >> > >> Richard Scheffenegger > >> > >> > >> > -----Original Message----- > >> > From: tcpm [mailto:tcpm-bounces@ietf.org] On Behalf Of Erik Hugne > >> > Sent: Mittwoch, 21. Mai 2014 14:55 > >> > To: Mark Allman > >> > Cc: ingemar.s.johansson@ericsson.com; martin.isaksson@ericsson.com; > >> > tcpm@ietf.org > >> > Subject: Re: [tcpm] RFC3465:TCP ABC and SACK'ed data > >> > > >> > On Wed, May 21, 2014 at 07:46:28AM -0400, Mark Allman wrote: > >> > > > >> > > > TCP ABC (still in the experimental track) defines a method to > >> > > > increase the cwnd based on the bytes being acknowledged, instead of > >> > > > the number of acks that arrive. I am assuming that SACK'ed (RFC2018) > >> > > > data should be included in this calculation, but i could find no > >> > > > mention of this in RFC3465. Could someone confirm this? > >> > > > >> > > ABC does not include SACK information in its calculations and it > >> > > cannot include SACK information. ABC applies to slow start---which > >> > > ends when loss occurs. And, (essentially) SACKs only arrive during loss > >> > recovery. > >> > > So, there is no need for ABC to deal with SACKs. > >> > > > >> > > >> > Thanks for taking the time to explain this. > >> > > >> > The problem (this is related to Ingemars posts around "Problem with low > >> > SSthresh") is that following the path change, there is a large train of > >> > segments being lost (say 150k out of a 500k window). Data at the end of > >> > the window did make it through and is SACK'ed. Upon receiving these SACK's > >> > the sending side enters loss recovery. It will take a very long time > >> > before recovering the 100k lost segments. > >> > > >> > An aggressive recovery algorithm would mitigate the effects of this, but i > >> > was hoping for a more elegant solution. > >> > > >> > //E > >> > > >> > _______________________________________________ > >> > 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 From nobody Tue May 27 04:36: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 082D61A00E5 for ; Tue, 27 May 2014 04:36:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.553 X-Spam-Level: X-Spam-Status: No, score=-7.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, 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 4LL2Es49CKT9 for ; Tue, 27 May 2014 04:36:54 -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 5113F1A00BE for ; Tue, 27 May 2014 04:36:54 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.98,918,1392192000"; d="scan'208";a="166698023" Received: from vmwexceht06-prd.hq.netapp.com ([10.106.77.104]) by mx12-out.netapp.com with ESMTP; 27 May 2014 04:36:51 -0700 Received: from SACEXCMBX06-PRD.hq.netapp.com ([169.254.9.198]) by vmwexceht06-prd.hq.netapp.com ([10.106.77.104]) with mapi id 14.03.0123.003; Tue, 27 May 2014 04:36:51 -0700 From: "Scheffenegger, Richard" To: "Scharf, Michael (Michael)" , "Eggert, Lars" , Joe Touch Thread-Topic: [tcpm] timestamp options (was Re: New Version Notification for draft-touch-tcpm-tcp-edo-01.txt) Thread-Index: AQHPeMY0X7ehqD8HfkGAXfnNjG9NiZtTGBYAgAExuVA= Date: Tue, 27 May 2014 11:36:50 +0000 Message-ID: <012C3117EDDB3C4781FD802A8C27DD4F6F3DD808@SACEXCMBX06-PRD.hq.netapp.com> References: <20140425221257.12559.43206.idtracker@ietfa.amsl.com> <2586_1398464386_535ADF82_2586_915_1_535ADF56.9050106@isi.edu> <5363AF84.8090701@mti-systems.com> <5363B397.8090009@isi.edu> <655C07320163294895BBADA28372AF5D2CFE36@FR712WXCHMBA15.zeu.alcatel-lucent.com> <20140503122950.GM44329@verdi> <655C07320163294895BBADA28372AF5D2D009E@FR712WXCHMBA15.zeu.alcatel-lucent.com> <201405221710.s4MHAY4S002037@bagheera.jungle.bt.co.uk> <537E3ACD.5000308@isi.edu> <537E48CE.8040704@mti-systems.com> <537E66A7.4080907@isi.edu> <201405231003.s4NA3PAB005137@bagheera.jungle.bt.co.uk> <537F7D91.10802@isi.edu> <655C07320163294895BBADA28372AF5D305E00@FR712WXCHMBA15.zeu.alcatel-lucent.com> In-Reply-To: <655C07320163294895BBADA28372AF5D305E00@FR712WXCHMBA15.zeu.alcatel-lucent.com> Accept-Language: de-AT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.106.53.53] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/Mx0Oyu7PvwL6Ddu5z0Ovfg1xnxw Cc: "tcpm@ietf.org" Subject: Re: [tcpm] timestamp options (was Re: New Version Notification for draft-touch-tcpm-tcp-edo-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: Tue, 27 May 2014 11:36:56 -0000 Well, (my arithmetic for the usual options comes to a total of 19 bytes, not 11). For late TS, we would still need at least 2 Bytes during / to= allow that capability. However, as the useful values of Window Scale only cover 0..14 [1], one app= roach to save SYN option space would be to negotiate up to 4 binary (on/off= ) plus WS in a new single 3-byte option. The following TCP options would lend themselves for that: SACK permitted=20 Late TS (new) EDO OK (new) Some recent scans did still reveal that quite a number of paths (port 80) o= nly negotiate MSS, but refrain from doing any other option. 2 SACK permitted 10 timestamp 3 window scale 4 MSS ------------------ 19 bytes Could become =09 4 MSS 3 WScale (new) + [SAckOk | LateTSOk | EDO ok] ------------------ 7 bytes But 7 compacted common options 16 TCP-AO 20 MPTCP -------------------- 43 bytes (still in need of EDO on SYN) Regards, Richard Scheffenegger [1] http://tools.ietf.org/html/draft-ietf-tcpm-1323bis-21#section-2.1 > -----Original Message----- > From: tcpm [mailto:tcpm-bounces@ietf.org] On Behalf Of Scharf, Michael > (Michael) > Sent: Montag, 26. Mai 2014 12:06 > To: Eggert, Lars; Joe Touch > Cc: tcpm@ietf.org > Subject: Re: [tcpm] timestamp options (was Re: New Version Notification > for draft-touch-tcpm-tcp-edo-01.txt) >=20 > > -----Original Message----- > > From: tcpm [mailto:tcpm-bounces@ietf.org] On Behalf Of Eggert, Lars > > Sent: Monday, May 26, 2014 11:38 AM > > To: Joe Touch > > Cc: tcpm@ietf.org > > Subject: [tcpm] timestamp options (was Re: New Version Notification > > for > > draft-touch-tcpm-tcp-edo-01.txt) > > > > Hi, > > > > On 2014-5-23, at 18:55, Joe Touch wrote: > > > Current total for SYN options in widespread concurrent use (as > > already described in sec 6.4): > > > > > > 2 SACK permitted > > > 10 timestamp > > > 3 window scale > > > 4 MSS > > > ------------------ > > > 11 bytes > > > > I think it was Mark Allman who questioned a while ago whether the > > benefits of the timestamp option are worth spending 10 bytes in every > > packet. (But I can't find the email now.) >=20 > And we have already had a long discussion on late enablement of > timestamps. Given that we submitted 1323bis in the meantime, I actually > think we could spend some cycles on saving those 10B from SYNs (if there > was agreement that it is doable). >=20 > Michael (chair hat off) >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Tue May 27 04:48: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 B8D571A0407 for ; Tue, 27 May 2014 04:48:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-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 MAp_ncIzxb5H for ; Tue, 27 May 2014 04:48:42 -0700 (PDT) Received: from hoemail1.alcatel.com (hoemail1.alcatel.com [192.160.6.148]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 151AB1A00E5 for ; Tue, 27 May 2014 04:48:42 -0700 (PDT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (h135-239-2-122.lucent.com [135.239.2.122]) by hoemail1.alcatel.com (8.13.8/IER-o) with ESMTP id s4RBmau6017636 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 27 May 2014 06:48:38 -0500 (CDT) Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id s4RBmaLC009130 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 27 May 2014 13:48:36 +0200 Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.185]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.02.0247.003; Tue, 27 May 2014 13:48:36 +0200 From: "Scharf, Michael (Michael)" To: "Scheffenegger, Richard" , "Eggert, Lars" , Joe Touch Thread-Topic: [tcpm] timestamp options (was Re: New Version Notification for draft-touch-tcpm-tcp-edo-01.txt) Thread-Index: AQHPeMY6BHtOWL7DHkmmOC47VuZhz5tSoFQwgAGMfgCAACHosA== Date: Tue, 27 May 2014 11:48:35 +0000 Message-ID: <655C07320163294895BBADA28372AF5D309C5D@FR712WXCHMBA15.zeu.alcatel-lucent.com> References: <20140425221257.12559.43206.idtracker@ietfa.amsl.com> <2586_1398464386_535ADF82_2586_915_1_535ADF56.9050106@isi.edu> <5363AF84.8090701@mti-systems.com> <5363B397.8090009@isi.edu> <655C07320163294895BBADA28372AF5D2CFE36@FR712WXCHMBA15.zeu.alcatel-lucent.com> <20140503122950.GM44329@verdi> <655C07320163294895BBADA28372AF5D2D009E@FR712WXCHMBA15.zeu.alcatel-lucent.com> <201405221710.s4MHAY4S002037@bagheera.jungle.bt.co.uk> <537E3ACD.5000308@isi.edu> <537E48CE.8040704@mti-systems.com> <537E66A7.4080907@isi.edu> <201405231003.s4NA3PAB005137@bagheera.jungle.bt.co.uk> <537F7D91.10802@isi.edu> <655C07320163294895BBADA28372AF5D305E00@FR712WXCHMBA15.zeu.alcatel-lucent.com> <012C3117EDDB3C4781FD802A8C27DD4F6F3DD808@SACEXCMBX06-PRD.hq.netapp.com> In-Reply-To: <012C3117EDDB3C4781FD802A8C27DD4F6F3DD808@SACEXCMBX06-PRD.hq.netapp.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/upvhD6EM9F7Go5DyCSbn9gaEf2M Cc: "tcpm@ietf.org" Subject: Re: [tcpm] timestamp options (was Re: New Version Notification for draft-touch-tcpm-tcp-edo-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: Tue, 27 May 2014 11:48:43 -0000 > For late TS, we would still need at least 2 Bytes during > / to allow that capability. >=20 > However, as the useful values of Window Scale only cover 0..14 [1], one > approach to save SYN option space would be to negotiate up to 4 binary > (on/off) plus WS in a new single 3-byte option. I might be wrong, but I've thought so far that "replacing" the window scale= option would be pretty difficult. We already had reports of middleboxes th= at parse this option because they try to understand rwnd (or they do not pa= rse the option even if they should, or they have entirely broken logic to m= ess up TCP...). I think one example are firewalls that try to detect whethe= r segments are in-window. Another example could be PEPs that try to tune rw= nd (if they still exist in the wild). My understanding so far was that a solution only for timestamps would be th= e most low-hanging fruit. Michael From nobody Tue May 27 04:56:09 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 A44BB1A00E7 for ; Tue, 27 May 2014 04:56:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.887 X-Spam-Level: X-Spam-Status: No, score=-6.887 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_SOFTFAIL=0.665] 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 L6DXaFhdY8PF for ; Tue, 27 May 2014 04:56:06 -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 50D2B1A004D for ; Tue, 27 May 2014 04:56:05 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.98,918,1392192000"; d="scan'208";a="166700973" Received: from vmwexceht06-prd.hq.netapp.com ([10.106.77.104]) by mx12-out.netapp.com with ESMTP; 27 May 2014 04:56:02 -0700 Received: from SACEXCMBX06-PRD.hq.netapp.com ([169.254.9.198]) by vmwexceht06-prd.hq.netapp.com ([10.106.77.104]) with mapi id 14.03.0123.003; Tue, 27 May 2014 04:56:02 -0700 From: "Scheffenegger, Richard" To: "Scharf, Michael (Michael)" , "Eggert, Lars" , Joe Touch Thread-Topic: [tcpm] timestamp options (was Re: New Version Notification for draft-touch-tcpm-tcp-edo-01.txt) Thread-Index: AQHPeMY0X7ehqD8HfkGAXfnNjG9NiZtTGBYAgAExuVCAAH0rgP//i9XQ Date: Tue, 27 May 2014 11:56:02 +0000 Message-ID: <012C3117EDDB3C4781FD802A8C27DD4F6F3E09CF@SACEXCMBX06-PRD.hq.netapp.com> References: <20140425221257.12559.43206.idtracker@ietfa.amsl.com> <2586_1398464386_535ADF82_2586_915_1_535ADF56.9050106@isi.edu> <5363AF84.8090701@mti-systems.com> <5363B397.8090009@isi.edu> <655C07320163294895BBADA28372AF5D2CFE36@FR712WXCHMBA15.zeu.alcatel-lucent.com> <20140503122950.GM44329@verdi> <655C07320163294895BBADA28372AF5D2D009E@FR712WXCHMBA15.zeu.alcatel-lucent.com> <201405221710.s4MHAY4S002037@bagheera.jungle.bt.co.uk> <537E3ACD.5000308@isi.edu> <537E48CE.8040704@mti-systems.com> <537E66A7.4080907@isi.edu> <201405231003.s4NA3PAB005137@bagheera.jungle.bt.co.uk> <537F7D91.10802@isi.edu> <655C07320163294895BBADA28372AF5D305E00@FR712WXCHMBA15.zeu.alcatel-lucent.com> <012C3117EDDB3C4781FD802A8C27DD4F6F3DD808@SACEXCMBX06-PRD.hq.netapp.com> <655C07320163294895BBADA28372AF5D309C5D@FR712WXCHMBA15.zeu.alcatel-lucent.com> In-Reply-To: <655C07320163294895BBADA28372AF5D309C5D@FR712WXCHMBA15.zeu.alcatel-lucent.com> Accept-Language: de-AT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.106.53.53] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/OOOIH5j5x-yfjdolWaccyobFaIo Cc: "tcpm@ietf.org" Subject: Re: [tcpm] timestamp options (was Re: New Version Notification for draft-touch-tcpm-tcp-edo-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: Tue, 27 May 2014 11:56:07 -0000 Hi Michael, Well, if it's just for Timestamps, just use an "invalid" length of 2 as a "= Late TS permitted".=20 Maintaining the same option value and this would be rather straight forward= .=20 Personally, I'd like to combine this with a change in semantics, if SACK is= negotiated on the same session as well, to allow more efficient loss recov= ery (lost retransmission detection during a loss recovery episode). I shoul= d have a unpublished draft sitting around here about that aspect. The TS option handling seems to be rather generous by middleboxes, in gener= al.=20 Richard Scheffenegger > -----Original Message----- > From: tcpm [mailto:tcpm-bounces@ietf.org] On Behalf Of Scharf, Michael > (Michael) > Sent: Dienstag, 27. Mai 2014 13:49 > To: Scheffenegger, Richard; Eggert, Lars; Joe Touch > Cc: tcpm@ietf.org > Subject: Re: [tcpm] timestamp options (was Re: New Version Notification > for draft-touch-tcpm-tcp-edo-01.txt) >=20 > > For late TS, we would still need at least 2 Bytes during > > / to allow that capability. > > > > However, as the useful values of Window Scale only cover 0..14 [1], > > one approach to save SYN option space would be to negotiate up to 4 > > binary > > (on/off) plus WS in a new single 3-byte option. >=20 > I might be wrong, but I've thought so far that "replacing" the window > scale option would be pretty difficult. We already had reports of > middleboxes that parse this option because they try to understand rwnd (o= r > they do not parse the option even if they should, or they have entirely > broken logic to mess up TCP...). I think one example are firewalls that > try to detect whether segments are in-window. Another example could be > PEPs that try to tune rwnd (if they still exist in the wild). >=20 > My understanding so far was that a solution only for timestamps would be > the most low-hanging fruit. >=20 > Michael >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Tue May 27 05:12:32 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 4690B1A00F5 for ; Tue, 27 May 2014 05:12:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-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 i0Lhwr3AeDI5 for ; Tue, 27 May 2014 05:12:27 -0700 (PDT) Received: from hoemail1.alcatel.com (hoemail1.alcatel.com [192.160.6.148]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3CF181A0037 for ; Tue, 27 May 2014 05:12:26 -0700 (PDT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (h135-239-2-122.lucent.com [135.239.2.122]) by hoemail1.alcatel.com (8.13.8/IER-o) with ESMTP id s4RCCKdc012688 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 27 May 2014 07:12:22 -0500 (CDT) Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id s4RCCHp8021981 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 27 May 2014 14:12:19 +0200 Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.185]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.02.0247.003; Tue, 27 May 2014 14:12:18 +0200 From: "Scharf, Michael (Michael)" To: "Scheffenegger, Richard" , "Eggert, Lars" , Joe Touch Thread-Topic: [tcpm] timestamp options (was Re: New Version Notification for draft-touch-tcpm-tcp-edo-01.txt) Thread-Index: AQHPeMY6BHtOWL7DHkmmOC47VuZhz5tSoFQwgAGMfgCAACHosP//43UAgAAiEJA= Date: Tue, 27 May 2014 12:12:17 +0000 Message-ID: <655C07320163294895BBADA28372AF5D309CC7@FR712WXCHMBA15.zeu.alcatel-lucent.com> References: <20140425221257.12559.43206.idtracker@ietfa.amsl.com> <2586_1398464386_535ADF82_2586_915_1_535ADF56.9050106@isi.edu> <5363AF84.8090701@mti-systems.com> <5363B397.8090009@isi.edu> <655C07320163294895BBADA28372AF5D2CFE36@FR712WXCHMBA15.zeu.alcatel-lucent.com> <20140503122950.GM44329@verdi> <655C07320163294895BBADA28372AF5D2D009E@FR712WXCHMBA15.zeu.alcatel-lucent.com> <201405221710.s4MHAY4S002037@bagheera.jungle.bt.co.uk> <537E3ACD.5000308@isi.edu> <537E48CE.8040704@mti-systems.com> <537E66A7.4080907@isi.edu> <201405231003.s4NA3PAB005137@bagheera.jungle.bt.co.uk> <537F7D91.10802@isi.edu> <655C07320163294895BBADA28372AF5D305E00@FR712WXCHMBA15.zeu.alcatel-lucent.com> <012C3117EDDB3C4781FD802A8C27DD4F6F3DD808@SACEXCMBX06-PRD.hq.netapp.com> <655C07320163294895BBADA28372AF5D309C5D@FR712WXCHMBA15.zeu.alcatel-lucent.com> <012C3117EDDB3C4781FD802A8C27DD4F6F3E09CF@SACEXCMBX06-PRD.hq.netapp.com> In-Reply-To: <012C3117EDDB3C4781FD802A8C27DD4F6F3E09CF@SACEXCMBX06-PRD.hq.netapp.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/X-RFDpCSCujmBTyHF5OmNCutBik Cc: "tcpm@ietf.org" Subject: Re: [tcpm] timestamp options (was Re: New Version Notification for draft-touch-tcpm-tcp-edo-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: Tue, 27 May 2014 12:12:29 -0000 > Well, if it's just for Timestamps, just use an "invalid" length of 2 as > a "Late TS permitted". >=20 > Maintaining the same option value and this would be rather straight > forward. Interesting proposal. But actually we are not really short of option number= s. If we get e.g. 8 bytes in a significant number of SYNs (which is our rea= l bottleneck), I think we could also spend a new option codepoint. > Personally, I'd like to combine this with a change in semantics, if > SACK is negotiated on the same session as well, to allow more efficient > loss recovery (lost retransmission detection during a loss recovery > episode). I should have a unpublished draft sitting around here about > that aspect. A change in semantics would also be a reason for a new codepoint, imho. Michael > The TS option handling seems to be rather generous by middleboxes, in > general. > > Richard Scheffenegger >=20 > > -----Original Message----- > > From: tcpm [mailto:tcpm-bounces@ietf.org] On Behalf Of Scharf, > Michael > > (Michael) > > Sent: Dienstag, 27. Mai 2014 13:49 > > To: Scheffenegger, Richard; Eggert, Lars; Joe Touch > > Cc: tcpm@ietf.org > > Subject: Re: [tcpm] timestamp options (was Re: New Version > Notification > > for draft-touch-tcpm-tcp-edo-01.txt) > > > > > For late TS, we would still need at least 2 Bytes during > > > / to allow that capability. > > > > > > However, as the useful values of Window Scale only cover 0..14 [1], > > > one approach to save SYN option space would be to negotiate up to 4 > > > binary > > > (on/off) plus WS in a new single 3-byte option. > > > > I might be wrong, but I've thought so far that "replacing" the window > > scale option would be pretty difficult. We already had reports of > > middleboxes that parse this option because they try to understand > rwnd (or > > they do not parse the option even if they should, or they have > entirely > > broken logic to mess up TCP...). I think one example are firewalls > that > > try to detect whether segments are in-window. Another example could > be > > PEPs that try to tune rwnd (if they still exist in the wild). > > > > My understanding so far was that a solution only for timestamps would > be > > the most low-hanging fruit. > > > > Michael > > > > _______________________________________________ > > tcpm mailing list > > tcpm@ietf.org > > https://www.ietf.org/mailman/listinfo/tcpm From nobody Tue May 27 11:37: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 95D8A1A06AC for ; Tue, 27 May 2014 11:37:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.574 X-Spam-Level: * X-Spam-Status: No, score=1.574 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, HTML_MESSAGE=0.001, RELAY_IS_203=0.994, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] 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 e0krRITDp17l for ; Tue, 27 May 2014 11:36:59 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.142.130]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A57621A06A6 for ; Tue, 27 May 2014 11:36:55 -0700 (PDT) Received: from mail-wi0-f176.google.com (mail-wi0-f176.google.com [209.85.212.176]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id CB33E278223 for ; Wed, 28 May 2014 03:36:50 +0900 (JST) Received: by mail-wi0-f176.google.com with SMTP id n15so2334665wiw.3 for ; Tue, 27 May 2014 11:36:48 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.194.184.179 with SMTP id ev19mr42001609wjc.85.1401215808437; Tue, 27 May 2014 11:36:48 -0700 (PDT) Received: by 10.194.88.9 with HTTP; Tue, 27 May 2014 11:36:48 -0700 (PDT) In-Reply-To: <655C07320163294895BBADA28372AF5D309CC7@FR712WXCHMBA15.zeu.alcatel-lucent.com> References: <20140425221257.12559.43206.idtracker@ietfa.amsl.com> <2586_1398464386_535ADF82_2586_915_1_535ADF56.9050106@isi.edu> <5363AF84.8090701@mti-systems.com> <5363B397.8090009@isi.edu> <655C07320163294895BBADA28372AF5D2CFE36@FR712WXCHMBA15.zeu.alcatel-lucent.com> <20140503122950.GM44329@verdi> <655C07320163294895BBADA28372AF5D2D009E@FR712WXCHMBA15.zeu.alcatel-lucent.com> <201405221710.s4MHAY4S002037@bagheera.jungle.bt.co.uk> <537E3ACD.5000308@isi.edu> <537E48CE.8040704@mti-systems.com> <537E66A7.4080907@isi.edu> <201405231003.s4NA3PAB005137@bagheera.jungle.bt.co.uk> <537F7D91.10802@isi.edu> <655C07320163294895BBADA28372AF5D305E00@FR712WXCHMBA15.zeu.alcatel-lucent.com> <012C3117EDDB3C4781FD802A8C27DD4F6F3DD808@SACEXCMBX06-PRD.hq.netapp.com> <655C07320163294895BBADA28372AF5D309C5D@FR712WXCHMBA15.zeu.alcatel-lucent.com> <012C3117EDDB3C4781FD802A8C27DD4F6F3E09CF@SACEXCMBX06-PRD.hq.netapp.com> <655C07320163294895BBADA28372AF5D309CC7@FR712WXCHMBA15.zeu.alcatel-lucent.com> Date: Tue, 27 May 2014 11:36:48 -0700 Message-ID: From: Yoshifumi Nishida To: "Scharf, Michael (Michael)" Content-Type: multipart/alternative; boundary=047d7b87371e848ef304fa65fac9 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/XC45jtejLYDOAT-4ylXkxwoDt14 Cc: "tcpm@ietf.org" , Joe Touch Subject: Re: [tcpm] timestamp options (was Re: New Version Notification for draft-touch-tcpm-tcp-edo-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: Tue, 27 May 2014 18:37:01 -0000 --047d7b87371e848ef304fa65fac9 Content-Type: text/plain; charset=UTF-8 Hi folks, I've submitted a proposal for this a while ago: http://tools.ietf.org/html/draft-nishida-tcpm-apaws-00 Although it's expired now, I will submit a new version within a couple of weeks or so. The late negotiation is also discussed in the draft. As it will change the semantics of TS, it presumes to use new code point (or use timestamp field in SYN). But, I'm happy to discuss on this point. One tricky thing for RFC1323 is that it uses TS for two purposes: timestamping and PAWS and one purpose of the draft is to separate them. I appreciate any feedback on the draft. Thanks, -- Yoshi On Tue, May 27, 2014 at 5:12 AM, Scharf, Michael (Michael) < michael.scharf@alcatel-lucent.com> wrote: > > Well, if it's just for Timestamps, just use an "invalid" length of 2 as > > a "Late TS permitted". > > > > Maintaining the same option value and this would be rather straight > > forward. > > Interesting proposal. But actually we are not really short of option > numbers. If we get e.g. 8 bytes in a significant number of SYNs (which is > our real bottleneck), I think we could also spend a new option codepoint. > > > Personally, I'd like to combine this with a change in semantics, if > > SACK is negotiated on the same session as well, to allow more efficient > > loss recovery (lost retransmission detection during a loss recovery > > episode). I should have a unpublished draft sitting around here about > > that aspect. > > A change in semantics would also be a reason for a new codepoint, imho. > > Michael > > > > The TS option handling seems to be rather generous by middleboxes, in > > general. > > > > Richard Scheffenegger > > > > > -----Original Message----- > > > From: tcpm [mailto:tcpm-bounces@ietf.org] On Behalf Of Scharf, > > Michael > > > (Michael) > > > Sent: Dienstag, 27. Mai 2014 13:49 > > > To: Scheffenegger, Richard; Eggert, Lars; Joe Touch > > > Cc: tcpm@ietf.org > > > Subject: Re: [tcpm] timestamp options (was Re: New Version > > Notification > > > for draft-touch-tcpm-tcp-edo-01.txt) > > > > > > > For late TS, we would still need at least 2 Bytes during > > > > / to allow that capability. > > > > > > > > However, as the useful values of Window Scale only cover 0..14 [1], > > > > one approach to save SYN option space would be to negotiate up to 4 > > > > binary > > > > (on/off) plus WS in a new single 3-byte option. > > > > > > I might be wrong, but I've thought so far that "replacing" the window > > > scale option would be pretty difficult. We already had reports of > > > middleboxes that parse this option because they try to understand > > rwnd (or > > > they do not parse the option even if they should, or they have > > entirely > > > broken logic to mess up TCP...). I think one example are firewalls > > that > > > try to detect whether segments are in-window. Another example could > > be > > > PEPs that try to tune rwnd (if they still exist in the wild). > > > > > > My understanding so far was that a solution only for timestamps would > > be > > > the most low-hanging fruit. > > > > > > Michael > > > > > > _______________________________________________ > > > 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 > --047d7b87371e848ef304fa65fac9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi folks,

I've submitted a proposal= for this a while ago: http://tools.ietf.org/html/draft-nishida-tcpm-apaws-00
Although it's expired now, I will submit a new version within a co= uple of weeks or so.
The late negotiation is also discussed in th= e draft.=C2=A0
As it will change the semantics of TS, it presumes= to use new code point (or use timestamp field in SYN). But, I'm happy = to discuss on this point.

One tricky thing for RFC1323 is that it uses TS for two= purposes: timestamping and PAWS and one purpose of the draft is to separat= e them.
I appreciate any feedback on the draft.

Thanks,
--
Yoshi

On Tue, May 27, 2014 at 5:12 AM, S= charf, Michael (Michael) <michael.scharf@alcatel-lucent.co= m> wrote:
> Well, if it's just for Timestamps= , just use an "invalid" length of 2 as
> a "Late TS permitted".
>
> Maintaining the same option value and this would be rather straight > forward.

Interesting proposal. But actually we are not really short of option = numbers. If we get e.g. 8 bytes in a significant number of SYNs (which is o= ur real bottleneck), I think we could also spend a new option codepoint.

> Personally, I'd like to combine this with a change in semantics, i= f
> SACK is negotiated on the same session as well, to allow more efficien= t
> loss recovery (lost retransmission detection during a loss recovery > episode). I should have a unpublished draft sitting around here about<= br> > that aspect.

A change in semantics would also be a reason for a new codepoint, imh= o.

Michael


> The TS option handling seems to be rather generous by middleboxes, in<= br> > general.
>
> Richard Scheffenegger
>
> > -----Original Message-----
> > From: tcpm [mailto:tcpm-= bounces@ietf.org] On Behalf Of Scharf,
> Michael
> > (Michael)
> > Sent: Dienstag, 27. Mai 2014 13:49
> > To: Scheffenegger, Richard; Eggert, Lars; Joe Touch
> > Cc: tcpm@ietf.org
> > Subject: Re: [tcpm] timestamp options (was Re: New Version
> Notification
> > for draft-touch-tcpm-tcp-edo-01.txt)
> >
> > > For late TS, we would still need at least 2 Bytes during
> > > <SYN>/<SYN,ACK> to allow that capability.
> > >
> > > However, as the useful values of Window Scale only cover 0..= 14 [1],
> > > one approach to save SYN option space would be to negotiate = up to 4
> > > binary
> > > (on/off) plus WS in a new single 3-byte option.
> >
> > I might be wrong, but I've thought so far that "replacin= g" the window
> > scale option would be pretty difficult. We already had reports of=
> > middleboxes that parse this option because they try to understand=
> rwnd (or
> > they do not parse the option even if they should, or they have > entirely
> > broken logic to mess up TCP...). I think one example are firewall= s
> that
> > try to detect whether segments are in-window. Another example cou= ld
> be
> > PEPs that try to tune rwnd (if they still exist in the wild).
> >
> > My understanding so far was that a solution only for timestamps w= ould
> be
> > the most low-hanging fruit.
> >
> > Michael
> >
> > _______________________________________________
> > 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

--047d7b87371e848ef304fa65fac9-- From nobody Tue May 27 13:04: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 E5FC11A06D2 for ; Tue, 27 May 2014 13:04:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] 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 8k6CtIxlqZNw for ; Tue, 27 May 2014 13:04:40 -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 004391A06CF for ; Tue, 27 May 2014 13:04:39 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id s4RK4FNN013299 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 27 May 2014 13:04:20 -0700 (PDT) Message-ID: <5384EFC3.50803@isi.edu> Date: Tue, 27 May 2014 13:04:19 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Yoshifumi Nishida , "Scharf, Michael (Michael)" References: <20140425221257.12559.43206.idtracker@ietfa.amsl.com> <655C07320163294895BBADA28372AF5D2CFE36@FR712WXCHMBA15.zeu.alcatel-lucent.com> <20140503122950.GM44329@verdi> <655C07320163294895BBADA28372AF5D2D009E@FR712WXCHMBA15.zeu.alcatel-lucent.com> <201405221710.s4MHAY4S002037@bagheera.jungle.bt.co.uk> <537E3ACD.5000308@isi.edu> <537E48CE.8040704@mti-systems.com> <537E66A7.4080907@isi.edu> <201405231003.s4NA3PAB005137@bagheera.jungle.bt.co.uk> <537F7D91.10802@isi.edu> <655C07320163294895BBADA28372AF5D305E00@FR712WXCHMBA15.zeu.alcatel-lucent.com> <012C3117EDDB3C4781FD802A8C27DD4F6F3DD808@SACEXCMBX06-PRD.hq.netapp.com> <655C07320163294895BBADA28372AF5D309C5D@FR712WXCHMBA15.zeu.alcatel-lucent.com> <012C3117EDDB3C4781FD802A8C27DD4F6F3E09CF@SACEXCMBX06-PRD.hq.netapp.com> <655C07320163294895BBADA28372AF5D309CC7@FR712WXCHMBA15.zeu.alcatel-lucent.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed 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/St-WatVK_U8zPktOqq_mZr95aIs Cc: "tcpm@ietf.org" Subject: Re: [tcpm] timestamp options (was Re: New Version Notification for draft-touch-tcpm-tcp-edo-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: Tue, 27 May 2014 20:04:42 -0000 Hi, all, Late negotiation has too many problems, as have been repeatedly raised on this list: - prevents use of the timestamp to help address PAWS for the initial SYN - a new connection that either avoids TS in SYN or uses just "use TS" (two-byte) flag can't know when to engage the timestamp and what initial value to use Joe On 5/27/2014 11:36 AM, Yoshifumi Nishida wrote: > Hi folks, > > I've submitted a proposal for this a while ago: > http://tools.ietf.org/html/draft-nishida-tcpm-apaws-00 > Although it's expired now, I will submit a new version within a couple > of weeks or so. > The late negotiation is also discussed in the draft. > As it will change the semantics of TS, it presumes to use new code point > (or use timestamp field in SYN). But, I'm happy to discuss on this point. > > One tricky thing for RFC1323 is that it uses TS for two purposes: > timestamping and PAWS and one purpose of the draft is to separate them. > I appreciate any feedback on the draft. > > Thanks, > -- > Yoshi > > On Tue, May 27, 2014 at 5:12 AM, Scharf, Michael (Michael) > > wrote: > > > Well, if it's just for Timestamps, just use an "invalid" length > of 2 as > > a "Late TS permitted". > > > > Maintaining the same option value and this would be rather straight > > forward. > > Interesting proposal. But actually we are not really short of option > numbers. If we get e.g. 8 bytes in a significant number of SYNs > (which is our real bottleneck), I think we could also spend a new > option codepoint. > > > Personally, I'd like to combine this with a change in semantics, if > > SACK is negotiated on the same session as well, to allow more > efficient > > loss recovery (lost retransmission detection during a loss recovery > > episode). I should have a unpublished draft sitting around here about > > that aspect. > > A change in semantics would also be a reason for a new codepoint, imho. > > Michael > > > > The TS option handling seems to be rather generous by middleboxes, in > > general. > > > > Richard Scheffenegger > > > > > -----Original Message----- > > > From: tcpm [mailto:tcpm-bounces@ietf.org > ] On Behalf Of Scharf, > > Michael > > > (Michael) > > > Sent: Dienstag, 27. Mai 2014 13:49 > > > To: Scheffenegger, Richard; Eggert, Lars; Joe Touch > > > Cc: tcpm@ietf.org > > > Subject: Re: [tcpm] timestamp options (was Re: New Version > > Notification > > > for draft-touch-tcpm-tcp-edo-01.txt) > > > > > > > For late TS, we would still need at least 2 Bytes during > > > > / to allow that capability. > > > > > > > > However, as the useful values of Window Scale only cover > 0..14 [1], > > > > one approach to save SYN option space would be to negotiate > up to 4 > > > > binary > > > > (on/off) plus WS in a new single 3-byte option. > > > > > > I might be wrong, but I've thought so far that "replacing" the > window > > > scale option would be pretty difficult. We already had reports of > > > middleboxes that parse this option because they try to understand > > rwnd (or > > > they do not parse the option even if they should, or they have > > entirely > > > broken logic to mess up TCP...). I think one example are firewalls > > that > > > try to detect whether segments are in-window. Another example could > > be > > > PEPs that try to tune rwnd (if they still exist in the wild). > > > > > > My understanding so far was that a solution only for timestamps > would > > be > > > the most low-hanging fruit. > > > > > > Michael > > > > > > _______________________________________________ > > > 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 > > From nobody Tue May 27 23:06:54 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 18BAE1A0359 for ; Tue, 27 May 2014 23:06:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.58 X-Spam-Level: X-Spam-Status: No, score=0.58 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] 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 abfUtDcH8Fc3 for ; Tue, 27 May 2014 23:06:43 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [IPv6:2001:200:0:8803::53]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24D891A0357 for ; Tue, 27 May 2014 23:06:42 -0700 (PDT) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 84F562781CB for ; Wed, 28 May 2014 15:06:37 +0900 (JST) Received: by mail-we0-f182.google.com with SMTP id t60so10735184wes.13 for ; Tue, 27 May 2014 23:06:35 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.194.184.179 with SMTP id ev19mr47055258wjc.85.1401257195168; Tue, 27 May 2014 23:06:35 -0700 (PDT) Received: by 10.194.88.9 with HTTP; Tue, 27 May 2014 23:06:35 -0700 (PDT) In-Reply-To: <5384EFC3.50803@isi.edu> References: <20140425221257.12559.43206.idtracker@ietfa.amsl.com> <655C07320163294895BBADA28372AF5D2CFE36@FR712WXCHMBA15.zeu.alcatel-lucent.com> <20140503122950.GM44329@verdi> <655C07320163294895BBADA28372AF5D2D009E@FR712WXCHMBA15.zeu.alcatel-lucent.com> <201405221710.s4MHAY4S002037@bagheera.jungle.bt.co.uk> <537E3ACD.5000308@isi.edu> <537E48CE.8040704@mti-systems.com> <537E66A7.4080907@isi.edu> <201405231003.s4NA3PAB005137@bagheera.jungle.bt.co.uk> <537F7D91.10802@isi.edu> <655C07320163294895BBADA28372AF5D305E00@FR712WXCHMBA15.zeu.alcatel-lucent.com> <012C3117EDDB3C4781FD802A8C27DD4F6F3DD808@SACEXCMBX06-PRD.hq.netapp.com> <655C07320163294895BBADA28372AF5D309C5D@FR712WXCHMBA15.zeu.alcatel-lucent.com> <012C3117EDDB3C4781FD802A8C27DD4F6F3E09CF@SACEXCMBX06-PRD.hq.netapp.com> <655C07320163294895BBADA28372AF5D309CC7@FR712WXCHMBA15.zeu.alcatel-lucent.com> <5384EFC3.50803@isi.edu> Date: Tue, 27 May 2014 23:06:35 -0700 Message-ID: From: Yoshifumi Nishida To: Joe Touch Content-Type: multipart/alternative; boundary=047d7b87371e5b69ff04fa6f9d11 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/pXJw41hHiypoi_ozeCJFP-JydY0 Cc: "tcpm@ietf.org" Subject: Re: [tcpm] timestamp options (was Re: New Version Notification for draft-touch-tcpm-tcp-edo-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: Wed, 28 May 2014 06:06:46 -0000 --047d7b87371e5b69ff04fa6f9d11 Content-Type: text/plain; charset=UTF-8 Hi Joe, I'm wondering if you presume that using the existing code point for late negotiation. Suppose If we use new code point, do we still have problems you mentioned below? Thanks, -- Yoshi On Tue, May 27, 2014 at 1:04 PM, Joe Touch wrote: > Hi, all, > > Late negotiation has too many problems, as have been repeatedly raised on > this list: > > - prevents use of the timestamp to help address PAWS for > the initial SYN > > - a new connection that either avoids TS in SYN or > uses just "use TS" (two-byte) flag can't know when > to engage the timestamp and what initial value to use > > Joe > > > On 5/27/2014 11:36 AM, Yoshifumi Nishida wrote: > >> Hi folks, >> >> I've submitted a proposal for this a while ago: >> http://tools.ietf.org/html/draft-nishida-tcpm-apaws-00 >> Although it's expired now, I will submit a new version within a couple >> of weeks or so. >> The late negotiation is also discussed in the draft. >> As it will change the semantics of TS, it presumes to use new code point >> (or use timestamp field in SYN). But, I'm happy to discuss on this point. >> >> One tricky thing for RFC1323 is that it uses TS for two purposes: >> timestamping and PAWS and one purpose of the draft is to separate them. >> I appreciate any feedback on the draft. >> >> Thanks, >> -- >> Yoshi >> >> On Tue, May 27, 2014 at 5:12 AM, Scharf, Michael (Michael) >> > > wrote: >> >> > Well, if it's just for Timestamps, just use an "invalid" length >> of 2 as >> > a "Late TS permitted". >> > >> > Maintaining the same option value and this would be rather straight >> > forward. >> >> Interesting proposal. But actually we are not really short of option >> numbers. If we get e.g. 8 bytes in a significant number of SYNs >> (which is our real bottleneck), I think we could also spend a new >> option codepoint. >> >> > Personally, I'd like to combine this with a change in semantics, if >> > SACK is negotiated on the same session as well, to allow more >> efficient >> > loss recovery (lost retransmission detection during a loss recovery >> > episode). I should have a unpublished draft sitting around here >> about >> > that aspect. >> >> A change in semantics would also be a reason for a new codepoint, >> imho. >> >> Michael >> >> >> > The TS option handling seems to be rather generous by middleboxes, >> in >> > general. >> > >> > Richard Scheffenegger >> > >> > > -----Original Message----- >> > > From: tcpm [mailto:tcpm-bounces@ietf.org >> ] On Behalf Of Scharf, >> > Michael >> > > (Michael) >> > > Sent: Dienstag, 27. Mai 2014 13:49 >> > > To: Scheffenegger, Richard; Eggert, Lars; Joe Touch >> > > Cc: tcpm@ietf.org >> > > Subject: Re: [tcpm] timestamp options (was Re: New Version >> > Notification >> > > for draft-touch-tcpm-tcp-edo-01.txt) >> > > >> > > > For late TS, we would still need at least 2 Bytes during >> > > > / to allow that capability. >> > > > >> > > > However, as the useful values of Window Scale only cover >> 0..14 [1], >> > > > one approach to save SYN option space would be to negotiate >> up to 4 >> > > > binary >> > > > (on/off) plus WS in a new single 3-byte option. >> > > >> > > I might be wrong, but I've thought so far that "replacing" the >> window >> > > scale option would be pretty difficult. We already had reports of >> > > middleboxes that parse this option because they try to understand >> > rwnd (or >> > > they do not parse the option even if they should, or they have >> > entirely >> > > broken logic to mess up TCP...). I think one example are >> firewalls >> > that >> > > try to detect whether segments are in-window. Another example >> could >> > be >> > > PEPs that try to tune rwnd (if they still exist in the wild). >> > > >> > > My understanding so far was that a solution only for timestamps >> would >> > be >> > > the most low-hanging fruit. >> > > >> > > Michael >> > > >> > > _______________________________________________ >> > > 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 >> >> >> --047d7b87371e5b69ff04fa6f9d11 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Joe,

I'm wondering if you presum= e that using the existing code point for late negotiation.
Suppos= e If we use new code point, do we still have problems you mentioned below?<= /div>

Thanks,
--
Yoshi

On Tue, May 27, 2014 at 1:04 PM, Joe= Touch <touch@isi.edu> wrote:
Hi, all,

Late negotiation has too many problems, as have been repeatedly raised on t= his list:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 - prevents use of the timestamp to help address= PAWS for
=C2=A0 =C2=A0 =C2=A0 =C2=A0 the initial SYN

=C2=A0 =C2=A0 =C2=A0 =C2=A0 - a new connection that either avoids TS in SYN= or
=C2=A0 =C2=A0 =C2=A0 =C2=A0 uses just "use TS" (two-byte) flag ca= n't know when
=C2=A0 =C2=A0 =C2=A0 =C2=A0 to engage the timestamp and what initial value = to use

Joe


On 5/27/2014 11:36 AM, Yoshifumi Nishida wrote:
Hi folks,

I've submitted a proposal for this a while ago:
http://tools.ietf.org/html/draft-nishida-tcpm-apaws-00
Although it's expired now, I will submit a new version within a couple<= br> of weeks or so.
The late negotiation is also discussed in the draft.
As it will change the semantics of TS, it presumes to use new code point (or use timestamp field in SYN). But, I'm happy to discuss on this poin= t.

One tricky thing for RFC1323 is that it uses TS for two purposes:
timestamping and PAWS and one purpose of the draft is to separate them.
I appreciate any feedback on the draft.

Thanks,
--
Yoshi

On Tue, May 27, 2014 at 5:12 AM, Scharf, Michael (Michael)
<= michael.scharf@alcatel-lucent.com
<mailto:michael.scharf@alcatel-lucent.com>> wrote:

=C2=A0 =C2=A0 =C2=A0> Well, if it's just for Timestamps, just use an= "invalid" length
=C2=A0 =C2=A0 of 2 as
=C2=A0 =C2=A0 =C2=A0> a "Late TS permitted".
=C2=A0 =C2=A0 =C2=A0>
=C2=A0 =C2=A0 =C2=A0> Maintaining the same option value and this would b= e rather straight
=C2=A0 =C2=A0 =C2=A0> forward.

=C2=A0 =C2=A0 Interesting proposal. But actually we are not really short of= option
=C2=A0 =C2=A0 numbers. If we get e.g. 8 bytes in a significant number of SY= Ns
=C2=A0 =C2=A0 (which is our real bottleneck), I think we could also spend a= new
=C2=A0 =C2=A0 option codepoint.

=C2=A0 =C2=A0 =C2=A0> Personally, I'd like to combine this with a ch= ange in semantics, if
=C2=A0 =C2=A0 =C2=A0> SACK is negotiated on the same session as well, to= allow more
=C2=A0 =C2=A0 efficient
=C2=A0 =C2=A0 =C2=A0> loss recovery (lost retransmission detection durin= g a loss recovery
=C2=A0 =C2=A0 =C2=A0> episode). I should have a unpublished draft sittin= g around here about
=C2=A0 =C2=A0 =C2=A0> that aspect.

=C2=A0 =C2=A0 A change in semantics would also be a reason for a new codepo= int, imho.

=C2=A0 =C2=A0 Michael


=C2=A0 =C2=A0 =C2=A0> The TS option handling seems to be rather generous= by middleboxes, in
=C2=A0 =C2=A0 =C2=A0> general.
=C2=A0 =C2=A0 =C2=A0>
=C2=A0 =C2=A0 =C2=A0> Richard Scheffenegger
=C2=A0 =C2=A0 =C2=A0>
=C2=A0 =C2=A0 =C2=A0> > -----Original Message-----
=C2=A0 =C2=A0 =C2=A0> > From: tcpm [mailto:tcpm-bounces@ietf.org
=C2=A0 =C2=A0 <mailto:tcpm-bounces@ietf.org>] On Behalf Of Scharf,
=C2=A0 =C2=A0 =C2=A0> Michael
=C2=A0 =C2=A0 =C2=A0> > (Michael)
=C2=A0 =C2=A0 =C2=A0> > Sent: Dienstag, 27. Mai 2014 13:49
=C2=A0 =C2=A0 =C2=A0> > To: Scheffenegger, Richard; Eggert, Lars; Joe= Touch
=C2=A0 =C2=A0 =C2=A0> > Cc: tcpm@ietf.org <mailto:tcpm@ietf.org>
=C2=A0 =C2=A0 =C2=A0> > Subject: Re: [tcpm] timestamp options (was Re= : New Version
=C2=A0 =C2=A0 =C2=A0> Notification
=C2=A0 =C2=A0 =C2=A0> > for draft-touch-tcpm-tcp-edo-01.txt) =C2=A0 =C2=A0 =C2=A0> >
=C2=A0 =C2=A0 =C2=A0> > > For late TS, we would still need at leas= t 2 Bytes during
=C2=A0 =C2=A0 =C2=A0> > > <SYN>/<SYN,ACK> to allow tha= t capability.
=C2=A0 =C2=A0 =C2=A0> > >
=C2=A0 =C2=A0 =C2=A0> > > However, as the useful values of Window = Scale only cover
=C2=A0 =C2=A0 0..14 [1],
=C2=A0 =C2=A0 =C2=A0> > > one approach to save SYN option space wo= uld be to negotiate
=C2=A0 =C2=A0 up to 4
=C2=A0 =C2=A0 =C2=A0> > > binary
=C2=A0 =C2=A0 =C2=A0> > > (on/off) plus WS in a new single 3-byte = option.
=C2=A0 =C2=A0 =C2=A0> >
=C2=A0 =C2=A0 =C2=A0> > I might be wrong, but I've thought so far= that "replacing" the
=C2=A0 =C2=A0 window
=C2=A0 =C2=A0 =C2=A0> > scale option would be pretty difficult. We al= ready had reports of
=C2=A0 =C2=A0 =C2=A0> > middleboxes that parse this option because th= ey try to understand
=C2=A0 =C2=A0 =C2=A0> rwnd (or
=C2=A0 =C2=A0 =C2=A0> > they do not parse the option even if they sho= uld, or they have
=C2=A0 =C2=A0 =C2=A0> entirely
=C2=A0 =C2=A0 =C2=A0> > broken logic to mess up TCP...). I think one = example are firewalls
=C2=A0 =C2=A0 =C2=A0> that
=C2=A0 =C2=A0 =C2=A0> > try to detect whether segments are in-window.= Another example could
=C2=A0 =C2=A0 =C2=A0> be
=C2=A0 =C2=A0 =C2=A0> > PEPs that try to tune rwnd (if they still exi= st in the wild).
=C2=A0 =C2=A0 =C2=A0> >
=C2=A0 =C2=A0 =C2=A0> > My understanding so far was that a solution o= nly for timestamps
=C2=A0 =C2=A0 would
=C2=A0 =C2=A0 =C2=A0> be
=C2=A0 =C2=A0 =C2=A0> > the most low-hanging fruit.
=C2=A0 =C2=A0 =C2=A0> >
=C2=A0 =C2=A0 =C2=A0> > Michael
=C2=A0 =C2=A0 =C2=A0> >
=C2=A0 =C2=A0 =C2=A0> > ______________________________________= _________
=C2=A0 =C2=A0 =C2=A0> > tcpm mailing list
=C2=A0 =C2=A0 =C2=A0> > tcpm@ietf.org <mailto:tcpm@ietf.org>

=C2=A0 =C2=A0 =C2=A0> > https://www.ietf.org/mailman/listinfo/tc= pm

=C2=A0 =C2=A0 _______________________________________________
=C2=A0 =C2=A0 tcpm mailing list
=C2=A0 =C2=A0 tcpm@ietf.= org <mailto:tcpm@= ietf.org>
=C2=A0 =C2=A0 https://www.ietf.org/mailman/listinfo/tcpm



--047d7b87371e5b69ff04fa6f9d11-- From nobody Wed May 28 01:17:37 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 86C0B1A01F2 for ; Wed, 28 May 2014 01:17:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.553 X-Spam-Level: X-Spam-Status: No, score=-7.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, 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 xGYYyV8aPVdb for ; Wed, 28 May 2014 01:17:33 -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 D4B851A01D2 for ; Wed, 28 May 2014 01:17:33 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.98,926,1392192000"; d="scan'208";a="166894260" Received: from vmwexceht04-prd.hq.netapp.com ([10.106.77.34]) by mx12-out.netapp.com with ESMTP; 28 May 2014 01:17:30 -0700 Received: from SACEXCMBX02-PRD.hq.netapp.com ([169.254.1.81]) by vmwexceht04-prd.hq.netapp.com ([10.106.77.34]) with mapi id 14.03.0123.003; Wed, 28 May 2014 01:17:30 -0700 From: "Scheffenegger, Richard" To: Joe Touch , Yoshifumi Nishida , "Scharf, Michael (Michael)" Thread-Topic: [tcpm] timestamp options (was Re: New Version Notification for draft-touch-tcpm-tcp-edo-01.txt) Thread-Index: AQHPeMY0X7ehqD8HfkGAXfnNjG9NiZtTGBYAgAExuVCAAH0rgP//i9XQgAB6yoCAAGtvAIAAGHSAgABT3wA= Date: Wed, 28 May 2014 08:17:29 +0000 Message-ID: <012C3117EDDB3C4781FD802A8C27DD4F6F4B7BB9@SACEXCMBX02-PRD.hq.netapp.com> References: <20140425221257.12559.43206.idtracker@ietfa.amsl.com> <655C07320163294895BBADA28372AF5D2CFE36@FR712WXCHMBA15.zeu.alcatel-lucent.com> <20140503122950.GM44329@verdi> <655C07320163294895BBADA28372AF5D2D009E@FR712WXCHMBA15.zeu.alcatel-lucent.com> <201405221710.s4MHAY4S002037@bagheera.jungle.bt.co.uk> <537E3ACD.5000308@isi.edu> <537E48CE.8040704@mti-systems.com> <537E66A7.4080907@isi.edu> <201405231003.s4NA3PAB005137@bagheera.jungle.bt.co.uk> <537F7D91.10802@isi.edu> <655C07320163294895BBADA28372AF5D305E00@FR712WXCHMBA15.zeu.alcatel-lucent.com> <012C3117EDDB3C4781FD802A8C27DD4F6F3DD808@SACEXCMBX06-PRD.hq.netapp.com> <655C07320163294895BBADA28372AF5D309C5D@FR712WXCHMBA15.zeu.alcatel-lucent.com> <012C3117EDDB3C4781FD802A8C27DD4F6F3E09CF@SACEXCMBX06-PRD.hq.netapp.com> <655C07320163294895BBADA28372AF5D309CC7@FR712WXCHMBA15.zeu.alcatel-lucent.com> <5384EFC3.50803@isi.edu> In-Reply-To: <5384EFC3.50803@isi.edu> Accept-Language: de-AT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.122.105.19] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/RiDDcMNNbXb6HXK5uQkjdYcIbKc Cc: "tcpm@ietf.org" Subject: Re: [tcpm] timestamp options (was Re: New Version Notification for draft-touch-tcpm-tcp-edo-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: Wed, 28 May 2014 08:17:35 -0000 SGkgSm9lLA0KDQo+IExhdGUgbmVnb3RpYXRpb24gaGFzIHRvbyBtYW55IHByb2JsZW1zLCBhcyBo YXZlIGJlZW4gcmVwZWF0ZWRseSByYWlzZWQgb24NCj4gdGhpcyBsaXN0Og0KPiANCj4gCS0gcHJl dmVudHMgdXNlIG9mIHRoZSB0aW1lc3RhbXAgdG8gaGVscCBhZGRyZXNzIFBBV1MgZm9yDQo+IAl0 aGUgaW5pdGlhbCBTWU4NCg0KVGhpcyBvbmUgaXMgZ2VudWluZS4gSG93ZXZlciwgZ2l2ZW4gdGhl IHByZXZhbGVuY2Ugb2Ygbm9uLVRTIFRDUCBzZXNzc2lvbnMgYW5kIG5vIHdpZGUtc3ByZWFkIGhh dm9jIGNhdXNlZCBieSBOT1QgaGF2aW5nIFBBV1Mgb24gdGhlIFNZTiwgaXQgYXBwZWFycyB0byBt ZSB0aGF0IHRoZSBpbXBhY3QgaXMgbWFuYWdlYWJsZS4gKE9mIGNvdXJzZSBpdCB3b3VsZCBiZSBu aWNlciB0byBoYXZlIFBBV1Mgb24gU1lOLCBidXQgYXMgbG9uZyBhcyBTWU4gb3B0aW9uIHNwYWNl IGlzIGxpbWl0ZWQuLi4pDQoNCj4gCS0gYSBuZXcgY29ubmVjdGlvbiB0aGF0IGVpdGhlciBhdm9p ZHMgVFMgaW4gU1lOIG9yDQo+IAl1c2VzIGp1c3QgInVzZSBUUyIgKHR3by1ieXRlKSBmbGFnIGNh bid0IGtub3cgd2hlbg0KPiAJdG8gZW5nYWdlIHRoZSB0aW1lc3RhbXAgYW5kIHdoYXQgaW5pdGlh bCB2YWx1ZSB0byB1c2UNCg0KV2VsbCwgYXMgdGhpcyB3b3VsZCBiZSBhIG5ldyBtZWNoYW5pc20s IHRoZXJlIHNob3VsZCBiZSBzb21lIGJyb2FkIGd1aWRhbmNlIGdpdmVuOyBJIHdvdWxkIGFzc3Vt ZSB0aGF0IHRoZSBsYXRlc3Qgb25zZXQgLSBpZiBsYXRlIFRTIGlzIG5lZ290aWF0ZWQgZm9yIC0g d291bGQgYmUgd2hlbiBlaXRoZXIgZGlyZWN0aW9uIGhhcyBzZW50IGF0IG1vc3QgMl4zMSAtICgy XjE2IDw8IFdpbmRvdy5zY2FsZSkgYnl0ZXM7IGFuZCBhIHJlY2VpdmVyIHRoYXQgc2VlcyB0aGUg ZnVsbCBUUyBtdXN0IHRoZW4gc3RhcnQgdG8gcmVmbGVjdCBUUyBhcyB1c3VhbCwgaW5kZXBlbmRl bnQgb2YgaXRzIG93biByZWxhdGl2ZSBvZmZzZXQgaW50byB0aGUgc2Vzc2lvbi4gQW5kIG5ldmVy IHJlbGlucXVpc2ggZnJvbSBzZW5kaW5nIFRTIGV2ZW4gd2hlbiBzb21lIHBhY2tldHMgLSBpZS4g cmV0cmFuc21pc3Npb25zLCBvciBkdWUgdG8gbWlkZGxlYm94ZXMgb24gYSBjaGFuZ2VkIHBhdGgg LSBub3QgY29udGFpbiBhIFRTIGZyb20gdGhlIG90aGVyIHNpZGUuDQoNCkFzIGZvciB0aGUgc2Vt YW50aWMgY2hhbmdlLCBJIHByb3Bvc2UgdGhhdCB3aGVuIHRoZSBzZXNzaW9uIGhhcyBTQUNLIGVu YWJsZWQgYXMgd2VsbCBhcyBsYXRlIFRTLCB0aGVuIHRoZSBUUyBzaG91bGQgcmVmbGVjdCB0aGUg VFMgb2YgdGhlIHNlZ21lbnQgdHJpZ2dlcmluZyB0aGUgQUNLICh3ZSBjYW4gZGlzY3VzcyB3aGF0 IHNob3VsZCBoYXBwZW4gZHVyaW5nIGluLXNlcXVlbmNlIGRlbGF5ZWQgQUNLIHByb2Nlc3Npbmcg dGhvdWdoOyB0aGUgcmVsZXZhbnQgYXNwZWN0IGZvciBtZSBpcyBkdXJpbmcgbG9zcyAtIFNBQ0sg cmVjb3ZlcnkgLSB0byBub3QgbWFzayB0aGUgdGltZXN0YW1wcyBvZiByZXRyYW5zbWl0dGVkIHBh Y2tldHMgYXMgcGVyIDEzMjNiaXM7IEZvciBsZWdhY3kgUlRUTSBwcm9jZXNzaW5nLCB0aGUgcHJl c2VuY2Ugb2YgYSBTQUNLIG9wdGlvbiBpcyBpbmRpY2F0aXZlIGVub3VnaCB0byBOT1QgZG8gbm9y bWFsIFJUVE0gcHJvY2Vzc2luZyAtIGFsdGhvdWdoIGEgc2VuZGVyIGNvdWxkIGNob29zZSB0byBk byBzbyBwYXJ0aWN1bGFybHkgZm9yIHRoZSBsb3NzIHJlY292ZXJ5IGVwaXNvZGVzLiBIYXZpbmcg dGhlICh1bmlxdWUpIFRpbWVzdGFtcC9TQUNLIGJsb2NrIGNvbWJpbmF0aW9ucyBkdXJpbmcgbG9z cyByZWNvdmVyeSB3b3VsZCBhbGxvdyBtb3JlIGVmZmljaWVudCwgZmFzdGVyIGFuZCBhbHNvIHBh Y2tldCBjb25zZXJ2aW5nIHJlY292ZXJ5IG9mIGxvc3QgcmV0cmFuc21pc3Npb25zIC0gdW5saWtl IHRoZSBjdXJyZW50IG1ldGhvZCBvZiBsYXN0IHJlc29ydCwgUlRPLg0KDQoNCkJlc3QgcmVnYXJk cywNCg0KUmljaGFyZCBTY2hlZmZlbmVnZ2VyDQoNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut LS0tLQ0KPiBGcm9tOiBKb2UgVG91Y2ggW21haWx0bzp0b3VjaEBpc2kuZWR1XQ0KPiBTZW50OiBE aWVuc3RhZywgMjcuIE1haSAyMDE0IDIyOjA0DQo+IFRvOiBZb3NoaWZ1bWkgTmlzaGlkYTsgU2No YXJmLCBNaWNoYWVsIChNaWNoYWVsKQ0KPiBDYzogU2NoZWZmZW5lZ2dlciwgUmljaGFyZDsgRWdn ZXJ0LCBMYXJzOyB0Y3BtQGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbdGNwbV0gdGltZXN0YW1w IG9wdGlvbnMgKHdhcyBSZTogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uDQo+IGZvciBkcmFmdC10 b3VjaC10Y3BtLXRjcC1lZG8tMDEudHh0KQ0KPiANCj4gSGksIGFsbCwNCj4gDQo+IExhdGUgbmVn b3RpYXRpb24gaGFzIHRvbyBtYW55IHByb2JsZW1zLCBhcyBoYXZlIGJlZW4gcmVwZWF0ZWRseSBy YWlzZWQgb24NCj4gdGhpcyBsaXN0Og0KPiANCj4gCS0gcHJldmVudHMgdXNlIG9mIHRoZSB0aW1l c3RhbXAgdG8gaGVscCBhZGRyZXNzIFBBV1MgZm9yDQo+IAl0aGUgaW5pdGlhbCBTWU4NCj4gDQo+ IAktIGEgbmV3IGNvbm5lY3Rpb24gdGhhdCBlaXRoZXIgYXZvaWRzIFRTIGluIFNZTiBvcg0KPiAJ dXNlcyBqdXN0ICJ1c2UgVFMiICh0d28tYnl0ZSkgZmxhZyBjYW4ndCBrbm93IHdoZW4NCj4gCXRv IGVuZ2FnZSB0aGUgdGltZXN0YW1wIGFuZCB3aGF0IGluaXRpYWwgdmFsdWUgdG8gdXNlDQo+IA0K PiBKb2UNCj4gDQo+IE9uIDUvMjcvMjAxNCAxMTozNiBBTSwgWW9zaGlmdW1pIE5pc2hpZGEgd3Jv dGU6DQo+ID4gSGkgZm9sa3MsDQo+ID4NCj4gPiBJJ3ZlIHN1Ym1pdHRlZCBhIHByb3Bvc2FsIGZv ciB0aGlzIGEgd2hpbGUgYWdvOg0KPiA+IGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0 LW5pc2hpZGEtdGNwbS1hcGF3cy0wMA0KPiA+IEFsdGhvdWdoIGl0J3MgZXhwaXJlZCBub3csIEkg d2lsbCBzdWJtaXQgYSBuZXcgdmVyc2lvbiB3aXRoaW4gYSBjb3VwbGUNCj4gPiBvZiB3ZWVrcyBv ciBzby4NCj4gPiBUaGUgbGF0ZSBuZWdvdGlhdGlvbiBpcyBhbHNvIGRpc2N1c3NlZCBpbiB0aGUg ZHJhZnQuDQo+ID4gQXMgaXQgd2lsbCBjaGFuZ2UgdGhlIHNlbWFudGljcyBvZiBUUywgaXQgcHJl c3VtZXMgdG8gdXNlIG5ldyBjb2RlDQo+ID4gcG9pbnQgKG9yIHVzZSB0aW1lc3RhbXAgZmllbGQg aW4gU1lOKS4gQnV0LCBJJ20gaGFwcHkgdG8gZGlzY3VzcyBvbiB0aGlzDQo+IHBvaW50Lg0KPiA+ DQo+ID4gT25lIHRyaWNreSB0aGluZyBmb3IgUkZDMTMyMyBpcyB0aGF0IGl0IHVzZXMgVFMgZm9y IHR3byBwdXJwb3NlczoNCj4gPiB0aW1lc3RhbXBpbmcgYW5kIFBBV1MgYW5kIG9uZSBwdXJwb3Nl IG9mIHRoZSBkcmFmdCBpcyB0byBzZXBhcmF0ZSB0aGVtLg0KPiA+IEkgYXBwcmVjaWF0ZSBhbnkg ZmVlZGJhY2sgb24gdGhlIGRyYWZ0Lg0KPiA+DQo+ID4gVGhhbmtzLA0KPiA+IC0tDQo+ID4gWW9z aGkNCj4gPg0KPiA+IE9uIFR1ZSwgTWF5IDI3LCAyMDE0IGF0IDU6MTIgQU0sIFNjaGFyZiwgTWlj aGFlbCAoTWljaGFlbCkNCj4gPiA8bWljaGFlbC5zY2hhcmZAYWxjYXRlbC1sdWNlbnQuY29tDQo+ ID4gPG1haWx0bzptaWNoYWVsLnNjaGFyZkBhbGNhdGVsLWx1Y2VudC5jb20+PiB3cm90ZToNCj4g Pg0KPiA+ICAgICAgPiBXZWxsLCBpZiBpdCdzIGp1c3QgZm9yIFRpbWVzdGFtcHMsIGp1c3QgdXNl IGFuICJpbnZhbGlkIiBsZW5ndGgNCj4gPiAgICAgb2YgMiBhcw0KPiA+ICAgICAgPiBhICJMYXRl IFRTIHBlcm1pdHRlZCIuDQo+ID4gICAgICA+DQo+ID4gICAgICA+IE1haW50YWluaW5nIHRoZSBz YW1lIG9wdGlvbiB2YWx1ZSBhbmQgdGhpcyB3b3VsZCBiZSByYXRoZXINCj4gc3RyYWlnaHQNCj4g PiAgICAgID4gZm9yd2FyZC4NCj4gPg0KPiA+ICAgICBJbnRlcmVzdGluZyBwcm9wb3NhbC4gQnV0 IGFjdHVhbGx5IHdlIGFyZSBub3QgcmVhbGx5IHNob3J0IG9mIG9wdGlvbg0KPiA+ICAgICBudW1i ZXJzLiBJZiB3ZSBnZXQgZS5nLiA4IGJ5dGVzIGluIGEgc2lnbmlmaWNhbnQgbnVtYmVyIG9mIFNZ TnMNCj4gPiAgICAgKHdoaWNoIGlzIG91ciByZWFsIGJvdHRsZW5lY2spLCBJIHRoaW5rIHdlIGNv dWxkIGFsc28gc3BlbmQgYSBuZXcNCj4gPiAgICAgb3B0aW9uIGNvZGVwb2ludC4NCj4gPg0KPiA+ ICAgICAgPiBQZXJzb25hbGx5LCBJJ2QgbGlrZSB0byBjb21iaW5lIHRoaXMgd2l0aCBhIGNoYW5n ZSBpbiBzZW1hbnRpY3MsDQo+IGlmDQo+ID4gICAgICA+IFNBQ0sgaXMgbmVnb3RpYXRlZCBvbiB0 aGUgc2FtZSBzZXNzaW9uIGFzIHdlbGwsIHRvIGFsbG93IG1vcmUNCj4gPiAgICAgZWZmaWNpZW50 DQo+ID4gICAgICA+IGxvc3MgcmVjb3ZlcnkgKGxvc3QgcmV0cmFuc21pc3Npb24gZGV0ZWN0aW9u IGR1cmluZyBhIGxvc3MNCj4gcmVjb3ZlcnkNCj4gPiAgICAgID4gZXBpc29kZSkuIEkgc2hvdWxk IGhhdmUgYSB1bnB1Ymxpc2hlZCBkcmFmdCBzaXR0aW5nIGFyb3VuZCBoZXJlDQo+IGFib3V0DQo+ ID4gICAgICA+IHRoYXQgYXNwZWN0Lg0KPiA+DQo+ID4gICAgIEEgY2hhbmdlIGluIHNlbWFudGlj cyB3b3VsZCBhbHNvIGJlIGEgcmVhc29uIGZvciBhIG5ldyBjb2RlcG9pbnQsDQo+IGltaG8uDQo+ ID4NCj4gPiAgICAgTWljaGFlbA0KPiA+DQo+ID4NCj4gPiAgICAgID4gVGhlIFRTIG9wdGlvbiBo YW5kbGluZyBzZWVtcyB0byBiZSByYXRoZXIgZ2VuZXJvdXMgYnkNCj4gbWlkZGxlYm94ZXMsIGlu DQo+ID4gICAgICA+IGdlbmVyYWwuDQo+ID4gICAgICA+DQo+ID4gICAgICA+IFJpY2hhcmQgU2No ZWZmZW5lZ2dlcg0KPiA+ICAgICAgPg0KPiA+ICAgICAgPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tDQo+ID4gICAgICA+ID4gRnJvbTogdGNwbSBbbWFpbHRvOnRjcG0tYm91bmNlc0BpZXRm Lm9yZw0KPiA+ICAgICA8bWFpbHRvOnRjcG0tYm91bmNlc0BpZXRmLm9yZz5dIE9uIEJlaGFsZiBP ZiBTY2hhcmYsDQo+ID4gICAgICA+IE1pY2hhZWwNCj4gPiAgICAgID4gPiAoTWljaGFlbCkNCj4g PiAgICAgID4gPiBTZW50OiBEaWVuc3RhZywgMjcuIE1haSAyMDE0IDEzOjQ5DQo+ID4gICAgICA+ ID4gVG86IFNjaGVmZmVuZWdnZXIsIFJpY2hhcmQ7IEVnZ2VydCwgTGFyczsgSm9lIFRvdWNoDQo+ ID4gICAgICA+ID4gQ2M6IHRjcG1AaWV0Zi5vcmcgPG1haWx0bzp0Y3BtQGlldGYub3JnPg0KPiA+ ICAgICAgPiA+IFN1YmplY3Q6IFJlOiBbdGNwbV0gdGltZXN0YW1wIG9wdGlvbnMgKHdhcyBSZTog TmV3IFZlcnNpb24NCj4gPiAgICAgID4gTm90aWZpY2F0aW9uDQo+ID4gICAgICA+ID4gZm9yIGRy YWZ0LXRvdWNoLXRjcG0tdGNwLWVkby0wMS50eHQpDQo+ID4gICAgICA+ID4NCj4gPiAgICAgID4g PiA+IEZvciBsYXRlIFRTLCB3ZSB3b3VsZCBzdGlsbCBuZWVkIGF0IGxlYXN0IDIgQnl0ZXMgZHVy aW5nDQo+ID4gICAgICA+ID4gPiA8U1lOPi88U1lOLEFDSz4gdG8gYWxsb3cgdGhhdCBjYXBhYmls aXR5Lg0KPiA+ICAgICAgPiA+ID4NCj4gPiAgICAgID4gPiA+IEhvd2V2ZXIsIGFzIHRoZSB1c2Vm dWwgdmFsdWVzIG9mIFdpbmRvdyBTY2FsZSBvbmx5IGNvdmVyDQo+ID4gICAgIDAuLjE0IFsxXSwN Cj4gPiAgICAgID4gPiA+IG9uZSBhcHByb2FjaCB0byBzYXZlIFNZTiBvcHRpb24gc3BhY2Ugd291 bGQgYmUgdG8gbmVnb3RpYXRlDQo+ID4gICAgIHVwIHRvIDQNCj4gPiAgICAgID4gPiA+IGJpbmFy eQ0KPiA+ICAgICAgPiA+ID4gKG9uL29mZikgcGx1cyBXUyBpbiBhIG5ldyBzaW5nbGUgMy1ieXRl IG9wdGlvbi4NCj4gPiAgICAgID4gPg0KPiA+ICAgICAgPiA+IEkgbWlnaHQgYmUgd3JvbmcsIGJ1 dCBJJ3ZlIHRob3VnaHQgc28gZmFyIHRoYXQgInJlcGxhY2luZyIgdGhlDQo+ID4gICAgIHdpbmRv dw0KPiA+ICAgICAgPiA+IHNjYWxlIG9wdGlvbiB3b3VsZCBiZSBwcmV0dHkgZGlmZmljdWx0LiBX ZSBhbHJlYWR5IGhhZCByZXBvcnRzDQo+IG9mDQo+ID4gICAgICA+ID4gbWlkZGxlYm94ZXMgdGhh dCBwYXJzZSB0aGlzIG9wdGlvbiBiZWNhdXNlIHRoZXkgdHJ5IHRvDQo+IHVuZGVyc3RhbmQNCj4g PiAgICAgID4gcnduZCAob3INCj4gPiAgICAgID4gPiB0aGV5IGRvIG5vdCBwYXJzZSB0aGUgb3B0 aW9uIGV2ZW4gaWYgdGhleSBzaG91bGQsIG9yIHRoZXkgaGF2ZQ0KPiA+ICAgICAgPiBlbnRpcmVs eQ0KPiA+ICAgICAgPiA+IGJyb2tlbiBsb2dpYyB0byBtZXNzIHVwIFRDUC4uLikuIEkgdGhpbmsg b25lIGV4YW1wbGUgYXJlDQo+IGZpcmV3YWxscw0KPiA+ICAgICAgPiB0aGF0DQo+ID4gICAgICA+ ID4gdHJ5IHRvIGRldGVjdCB3aGV0aGVyIHNlZ21lbnRzIGFyZSBpbi13aW5kb3cuIEFub3RoZXIg ZXhhbXBsZQ0KPiBjb3VsZA0KPiA+ICAgICAgPiBiZQ0KPiA+ICAgICAgPiA+IFBFUHMgdGhhdCB0 cnkgdG8gdHVuZSByd25kIChpZiB0aGV5IHN0aWxsIGV4aXN0IGluIHRoZSB3aWxkKS4NCj4gPiAg ICAgID4gPg0KPiA+ICAgICAgPiA+IE15IHVuZGVyc3RhbmRpbmcgc28gZmFyIHdhcyB0aGF0IGEg c29sdXRpb24gb25seSBmb3IgdGltZXN0YW1wcw0KPiA+ICAgICB3b3VsZA0KPiA+ICAgICAgPiBi ZQ0KPiA+ICAgICAgPiA+IHRoZSBtb3N0IGxvdy1oYW5naW5nIGZydWl0Lg0KPiA+ICAgICAgPiA+ DQo+ID4gICAgICA+ID4gTWljaGFlbA0KPiA+ICAgICAgPiA+DQo+ID4gICAgICA+ID4gX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiAgICAgID4gPiB0 Y3BtIG1haWxpbmcgbGlzdA0KPiA+ICAgICAgPiA+IHRjcG1AaWV0Zi5vcmcgPG1haWx0bzp0Y3Bt QGlldGYub3JnPg0KPiA+ICAgICAgPiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vdGNwbQ0KPiA+DQo+ID4gICAgIF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQo+ID4gICAgIHRjcG0gbWFpbGluZyBsaXN0DQo+ID4gICAgIHRjcG1A aWV0Zi5vcmcgPG1haWx0bzp0Y3BtQGlldGYub3JnPg0KPiA+ICAgICBodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RjcG0NCj4gPg0KPiA+DQo= From nobody Wed May 28 10:15:38 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 5CA071A0499 for ; Wed, 28 May 2014 10:15:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.652 X-Spam-Level: X-Spam-Status: No, score=-2.652 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_41=0.6, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651, 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 jckYBfPhXlWa for ; Wed, 28 May 2014 10:15:33 -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 93BBE1A01C3 for ; Wed, 28 May 2014 10:15:32 -0700 (PDT) Received: from EVMHR71-UKRD.domain1.systemhost.net (10.36.3.109) by EVMHR03-UKBR.bt.com (10.216.161.35) with Microsoft SMTP Server (TLS) id 8.3.348.2; Wed, 28 May 2014 18:15:26 +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; Wed, 28 May 2014 18:15:25 +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; Wed, 28 May 2014 18:15:25 +0100 Received: from BTP075694.jungle.bt.co.uk ([10.109.233.189]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id s4SHFMm0014634; Wed, 28 May 2014 18:15:22 +0100 Message-ID: <201405281715.s4SHFMm0014634@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 28 May 2014 18:13:24 +0100 To: Joe Touch From: Bob Briscoe In-Reply-To: <537F8202.4020907@isi.edu> References: <20140425221257.12559.43206.idtracker@ietfa.amsl.com> <2586_1398464386_535ADF82_2586_915_1_535ADF56.9050106@isi.edu> <5363AF84.8090701@mti-systems.com> <5363B397.8090009@isi.edu> <655C07320163294895BBADA28372AF5D2CFE36@FR712WXCHMBA15.zeu.alcatel-lucent.com> <20140503122950.GM44329@verdi> <655C07320163294895BBADA28372AF5D2D009E@FR712WXCHMBA15.zeu.alcatel-lucent.com> <201405221710.s4MHAY4S002037@bagheera.jungle.bt.co.uk> <537E3ACD.5000308@isi.edu> <1AD79820-22C1-4500-84D1-1383F264D68C@weston.borman.com> <201405231213.s4NCDa5P005525@bagheera.jungle.bt.co.uk> <537F8202.4020907@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/RuqQtgLAbNhspmx7wSx9f0azYYw Cc: David Borman , "tcpm@ietf.org" Subject: Re: [tcpm] New Version Notification for draft-touch-tcpm-tcp-edo-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: Wed, 28 May 2014 17:15:36 -0000 Joe, At 18:14 23/05/2014, Joe Touch wrote: >On 5/23/2014 5:13 AM, Bob Briscoe wrote: >>David, >> >>1) Parallel control channel >>___________________________ >>Client A sends two SYNs back-to-back to an existing well-known port >>(e.g. 80). > >You can send in whatever order you want; packets will be reordered, >lost, and sent along alternate paths. Of course. But as I suggested initially, we can standardise the protocol so that an upgraded host synthesises shared fate. Eg. a 2-octet TCP option on the D-type SYN that says "Hold for x [ms] to wait for the supplementary C-type SYN, where x is a lot less than the usual time you hold SYN connection state (e.g. x=2). If SYN C hasn't arrived by then, continue without it, and discard it if it arrives." And if the C-SYN arrives first, hold it for y [ms] waiting for the corresponding D-SYN. Where for example y=2 as well. >FWIW, do these use the same source port and ISN? > - if they do, it'll reset the connection > - if they don't, you're now limiting the number of > concurrent connections to roughly half: > http://www.isi.edu/touch/pubs/infocomm99/infocomm99-web/ Unless we can think of a way for the C-SYN to be discarded by a legacy TCP stack (but not a middlebox), I'm assuming we need to get the C-SYN up to the legacy app-layer before discard... So, I was assuming they use different source ports (otherwise, as you say, a legacy TCP stack could reset the D SYN connection if it arrived second) The ISN on the C-SYN is redundant - we might be able to think of another use for that field. On an upgraded host, max concurrent connections would only be slightly impacted, because of the v small timeout of C-SYNs. The semantics of the option-space-extension option would be to only hold the C-type SYN for a timeout and only the D-type SYN creates full connection state (I'm deferring SYN cookie behaviour to tomorrow for now - this is a straw man). Admittedly, the number of concurrent connections a /legacy/ host can support could reduce by up to half (if all remote TCP clients are sending the new option). But they have the choice of upgrading to the new stack to stop wasting their memory. >>* SYN D, establishes a regular data connection, with sufficient TCP >>options to be workable but they still fit within the existing 40B option >>limit. >>* SYN C establishes another parallel connection to the same well-known >>port that looks like regular data from the outside (it could even be an >>extension to HTTP to ensure middleboxes will let it pass), but it talks >>a new app-layer 'TCP control' protocol inside. > >What happens when they arrive out of order? What happens when you >get D but not yet C? How long do you wait for C? See above. The timeouts might be standardised, or they might be declared in the option as a hint (for the host to ignore if it is under stress). >This is the problem with dual-stack approaches - new endpoints >penalize legacy endpoints if there's a stall, and undermine new >endpoints if they don't. Have I satisfied you that this can be solved sufficiently? Bearing in mind the gain, it's reasonable to have to accept some pain. >>If there is no support for the new app-layer protocol on port 80 the >>control channel just shuts down with a suitable HTTP error, while SYN D >>has opened a data connection with sufficient TCP options to be workable. >>If the new app-layer TCP control protocol is supported on port 80, the >>parallel control channel (C) adds unlimited additional control >>flexibility to the data channel (D) hardly any added latency. >> >>Establishing a similar control channel in the opposite direction would >>be fairly trivial. >> >>There are few, if any, middlebox problems with the above approach. >>However, there are certainly other problems, but no more insurmountable >>than all the problems that have already been discussed with taking the >>'easy' route of EDO: >>* A secure binding would have to be added to bind channel C to a secret >>known only to the originator of channel D, otherwise it would open up >>data channels to spoof control channel attacks. This binding could be >>built on a TCP-AO option in channel D. > >Yes, that's another problem. Fairly straightforward to solve using standard techniques. >>* Channel C would need some way to refer to the segments of channel D >>that was robust against re-segmentation. > >Which means it won't work in the current Internet, because >resegmentation is also widespread (though evil, IMO). Well, resegmentation isn't usually a problem on a SYN anyway. We can't improve on the general pain caused by resegmentation. I was only talking about the delta pain that my strawman would suffer, where a resegmenting function sees data on my SYN and doesn't understand my strawman, so it won't patch up the damage in my strawman protocol that it would have patched up by altering sequence numbers in a regular single SYN with a payload. I think this is a corner case. >>* The main problem is that the two channels don't share fate;a control >>packet can be delayed relative to the point in the data stream at which >>it is attempting to exert control, possibly for a RTT if it is lost and >>has to be retransmitted. However, this is not insurmountable. The >>control protocol could include a mode to "synthesise shared fate", by >>making the data channel buffer data until an associated control segment >>had arrived. This would duplicate the latency impact of a loss or delay >>on either channel, but one can imagine mitigations that would consign >>this latency impact to corner cases. >>* It's a bit of a mess, but that comes with the territory when trying to >>fix legacy protocol problems. >>* The internal stack architecture seems to require a trombone back down >>into the kernel from user-space, but that is not insurmountable - a shim >>within the kernel on port 80 (for example) could redirect control >>channel data across to the "TCP control channel module" in the kernel, >>while passing non-control channel connections to user-space. >> >>2) Build on LOIC >>______________________ >>Long option with invalid checksum > >Won't work through current NATs, which won't recalculate the >checksum properly. I'm building on the general idea of using something invalid, not using the checksum idea specifically. >>At 18:53 22/05/2014, John Leslie wrote: >>> That's too big of a change to ask folks to believe it safe. >> >>When I read an idea, I don't take it as set in stone and just find a >>hole and dismiss it. I see it as a potential stepping stone to a >>solution and think about how it could be done better. In fact, Andrew >>Yourtchenko said that was the intention of his write-up of LOIC. >> >>I believe that an approach worth further thought would be a mixture of >>the control channel idea and the invalid checksum idea. I'm thinking of: >>* a pure control SYN (C) sent first, then a base SYN (D) sent >>back-to-back, both to the same port. > >Again, please don't assume back-to-back means anything. See above. Actually, even tho order isn'[t guaranteed, it is important to get them in the right order to optimise performance (much as TCP doesn't assume perfect order, but it goes smoothest with reasonable ordering). >>* SYN C would contain something invalid to cause a legacy TCP stack or >>legacy app to discard it (and hopefully less probability that a >>middlebox would), e.g. a payload that is invalid for the application >>protocol on the port. > >But so will a NAT, etc. No. You can design a payload that has headers that a NAT will ignore but an end-host will have to process. E.g. HTTP connection control headers newly defined for this protocol that would be ignored by NATs, without any other HTTP behaviour, so a legacy host does nothing at the app layer. >>* there would be additional TCP options in the payload of SYN C to be >>added to the TCP options that arrived separately on the base SYN >>* The control SYN could be bound crytographically to the base SYN (as >>already described). >>* It could use the shim-like control stack arangement described earlier. >> >>By focusing solely on extending the SYN, this would avoid the ongoing >>shared fate problems that a separate control channel suffers throughout >>the connection. There would still be shared fate problems with 2 SYNs >>(e.g. the two SYNs get re-ordered), but the protocol would have to be >>designed to be robust to that (naively, SYN D could include a new TCP >>option that told a new stack to wait a few ticks for a SYN C, but that >>would be vulnerable to meddleboxes). Not insurmountable. > >AFAICT, it is. Still? Bob >*with a nod to Raiders 3. ________________________________________________________________ Bob Briscoe, BT From nobody Wed May 28 10:16:23 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 771051A0197 for ; Wed, 28 May 2014 10:16:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.252 X-Spam-Level: X-Spam-Status: No, score=-3.252 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651, 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 E4qm93WeJJib for ; Wed, 28 May 2014 10:16:14 -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 9EA301A042D for ; Wed, 28 May 2014 10:16:13 -0700 (PDT) Received: from EVMHR72-UKRD.domain1.systemhost.net (10.36.3.110) by EVMHR68-UKRD.bt.com (10.187.101.23) with Microsoft SMTP Server (TLS) id 8.3.348.2; Wed, 28 May 2014 18:16:08 +0100 Received: from EPHR01-UKIP.domain1.systemhost.net (147.149.196.177) by EVMHR72-UKRD.domain1.systemhost.net (10.36.3.110) with Microsoft SMTP Server (TLS) id 8.3.348.2; Wed, 28 May 2014 18:16:07 +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; Wed, 28 May 2014 18:16:06 +0100 Received: from BTP075694.jungle.bt.co.uk ([10.109.233.189]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id s4SHG29Y014642; Wed, 28 May 2014 18:16:03 +0100 Message-ID: <201405281716.s4SHG29Y014642@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 28 May 2014 18:16:02 +0100 To: Joe Touch From: Bob Briscoe In-Reply-To: <537F7D91.10802@isi.edu> References: <20140425221257.12559.43206.idtracker@ietfa.amsl.com> <2586_1398464386_535ADF82_2586_915_1_535ADF56.9050106@isi.edu> <5363AF84.8090701@mti-systems.com> <5363B397.8090009@isi.edu> <655C07320163294895BBADA28372AF5D2CFE36@FR712WXCHMBA15.zeu.alcatel-lucent.com> <20140503122950.GM44329@verdi> <655C07320163294895BBADA28372AF5D2D009E@FR712WXCHMBA15.zeu.alcatel-lucent.com> <201405221710.s4MHAY4S002037@bagheera.jungle.bt.co.uk> <537E3ACD.5000308@isi.edu> <537E48CE.8040704@mti-systems.com> <537E66A7.4080907@isi.edu> <201405231003.s4NA3PAB005137@bagheera.jungle.bt.co.uk> <537F7D91.10802@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/4SMCHKb6n1srat8XCZ7yLkOrIKY Cc: "tcpm@ietf.org" Subject: Re: [tcpm] New Version Notification for draft-touch-tcpm-tcp-edo-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: Wed, 28 May 2014 17:16:17 -0000 Joe, I don't think this sufficiently answers the question to justify WG adoption. You seem to be confirming that this is an academic exercise. Bob At 17:55 23/05/2014, Joe Touch wrote: >Hi, Bob, > >On 5/23/2014 3:03 AM, Bob Briscoe wrote: >>Joe, and everyone else who wants to work on this, >> >>Just because it's easier to make a chocolate teapot than a cast-iron >>one, doesn't imply that there is any need for chocolate teapots. > >You don't get a cast iron teapot just because you want one either ;-) > >>IOW, we will be asking the IESG to spend reviewer time on EDO, so we >>need to give some plausible indication that someone might find it useful >>and it's not just an academic exercise. > >Sometimes the answer "you can't have A, but at least here's B" is >more than an exercise; it educates the community. By not providing >either answer, we have continued to drag this issue around the block >for far too long -- and spent far too many cycles in this and other >WGs seeking solutions. > > > The current draft solely gives >>SACK + MPTCP + TCP-AO as an example, but is that really something that >>can't be done today? > >Current total for SYN options in widespread concurrent use (as >already described in sec 6.4): > > 2 SACK permitted > 10 timestamp > 3 window scale > 4 MSS > ------------------ > 11 bytes > >The current DO field is 4 bits, with a max value of 15 = 60 bytes >for the total header, less 20 for the base TCP header which leaves >40 for options. > >So let's see what happens when we add: > > 11 widespread basic options > 16 TCP-AO > 20 MPTCP > -------------------- > 47 > >That's more than 40. > >>Adding more complexity to the TCP stack (with the potential for more >>vulnerabilities) is only worthwhile if there's an identifiable benefit, >>otherwise few production stacks are going to implement it anyway. > >There are two identifiable benefits: > > 1) explain the ways we already know we can't extend the SYN > so we stop wasting time trying them repeatedly (i.e., education) > > 2) provide a solution for the other segments, so that can be > used - e.g., for large SACK responses > > 3) educate the community > >Joe ________________________________________________________________ Bob Briscoe, BT From nobody Wed May 28 10:33:00 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 BDAC01A0522 for ; Wed, 28 May 2014 10:32:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] 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 HdQyHscWVqdF for ; Wed, 28 May 2014 10:32:52 -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 618AE1A042D for ; Wed, 28 May 2014 10:32:43 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id s4SHUtgc009133 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 28 May 2014 10:30:55 -0700 (PDT) Message-ID: <53861D4F.60709@isi.edu> Date: Wed, 28 May 2014 10:30:55 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Bob Briscoe References: <20140425221257.12559.43206.idtracker@ietfa.amsl.com> <2586_1398464386_535ADF82_2586_915_1_535ADF56.9050106@isi.edu> <5363AF84.8090701@mti-systems.com> <5363B397.8090009@isi.edu> <655C07320163294895BBADA28372AF5D2CFE36@FR712WXCHMBA15.zeu.alcatel-lucent.com> <20140503122950.GM44329@verdi> <655C07320163294895BBADA28372AF5D2D009E@FR712WXCHMBA15.zeu.alcatel-lucent.com> <201405221710.s4MHAY4S002037@bagheera.jungle.bt.co.uk> <537E3ACD.5000308@isi.edu> <537E48CE.8040704@mti-systems.com> <537E66A7.4080907@isi.edu> <201405231003.s4NA3PAB005137@bagheera.jungle.bt.co.uk> <537F7D91.10802@isi.edu> <201405281716.s4SHG29Y014642@bagheera.jungle.bt.co.uk> In-Reply-To: <201405281716.s4SHG29Y014642@bagheera.jungle.bt.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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/6JnUOwxeCL2PiyvUrTcOj21r8Tk Cc: "tcpm@ietf.org" Subject: Re: [tcpm] New Version Notification for draft-touch-tcpm-tcp-edo-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: Wed, 28 May 2014 17:32:57 -0000 On 5/28/2014 10:16 AM, Bob Briscoe wrote: > Joe, > > I don't think this sufficiently answers the question to justify WG > adoption. You seem to be confirming that this is an academic exercise. You asked for a specific example - one that the MPTCP community has raised. It's not a proof that there's "some set" that might overload the space; it's based on a *specific* request. I gave other reasons - including educating the community as to the issues. If you want to call that "academic", sure - in part. But I don't see that as interfering with WG adoption - we do that sort of thing all the time (that's the basis of a BCP). Joe > At 17:55 23/05/2014, Joe Touch wrote: >> Hi, Bob, >> >> On 5/23/2014 3:03 AM, Bob Briscoe wrote: >>> Joe, and everyone else who wants to work on this, >>> >>> Just because it's easier to make a chocolate teapot than a cast-iron >>> one, doesn't imply that there is any need for chocolate teapots. >> >> You don't get a cast iron teapot just because you want one either ;-) >> >>> IOW, we will be asking the IESG to spend reviewer time on EDO, so we >>> need to give some plausible indication that someone might find it useful >>> and it's not just an academic exercise. >> >> Sometimes the answer "you can't have A, but at least here's B" is more >> than an exercise; it educates the community. By not providing either >> answer, we have continued to drag this issue around the block for far >> too long -- and spent far too many cycles in this and other WGs >> seeking solutions. >> >> > The current draft solely gives >>> SACK + MPTCP + TCP-AO as an example, but is that really something that >>> can't be done today? >> >> Current total for SYN options in widespread concurrent use (as already >> described in sec 6.4): >> >> 2 SACK permitted >> 10 timestamp >> 3 window scale >> 4 MSS >> ------------------ >> 11 bytes >> >> The current DO field is 4 bits, with a max value of 15 = 60 bytes for >> the total header, less 20 for the base TCP header which leaves 40 for >> options. >> >> So let's see what happens when we add: >> >> 11 widespread basic options >> 16 TCP-AO >> 20 MPTCP >> -------------------- >> 47 >> >> That's more than 40. >> >>> Adding more complexity to the TCP stack (with the potential for more >>> vulnerabilities) is only worthwhile if there's an identifiable benefit, >>> otherwise few production stacks are going to implement it anyway. >> >> There are two identifiable benefits: >> >> 1) explain the ways we already know we can't extend the SYN >> so we stop wasting time trying them repeatedly (i.e., education) >> >> 2) provide a solution for the other segments, so that can be >> used - e.g., for large SACK responses >> >> 3) educate the community >> >> Joe > > ________________________________________________________________ > Bob Briscoe, BT From nobody Wed May 28 10:59: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 0A1A01A0B76 for ; Wed, 28 May 2014 10:59:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.651 X-Spam-Level: X-Spam-Status: No, score=-3.651 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_18=0.6, J_CHICKENPOX_41=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] 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 dx_6k9NEkAuh for ; Wed, 28 May 2014 10:59:45 -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 A74361A01AC for ; Wed, 28 May 2014 10:59:45 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id s4SHwHak018383 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 28 May 2014 10:58:17 -0700 (PDT) Message-ID: <538623B9.2060209@isi.edu> Date: Wed, 28 May 2014 10:58:17 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Bob Briscoe References: <20140425221257.12559.43206.idtracker@ietfa.amsl.com> <2586_1398464386_535ADF82_2586_915_1_535ADF56.9050106@isi.edu> <5363AF84.8090701@mti-systems.com> <5363B397.8090009@isi.edu> <655C07320163294895BBADA28372AF5D2CFE36@FR712WXCHMBA15.zeu.alcatel-lucent.com> <20140503122950.GM44329@verdi> <655C07320163294895BBADA28372AF5D2D009E@FR712WXCHMBA15.zeu.alcatel-lucent.com> <201405221710.s4MHAY4S002037@bagheera.jungle.bt.co.uk> <537E3ACD.5000308@isi.edu> <1AD79820-22C1-4500-84D1-1383F264D68C@weston.borman.com> <201405231213.s4NCDa5P005525@bagheera.jungle.bt.co.uk> <537F8202.4020907@isi.edu> <201405281715.s4SHFMm0014634@bagheera.jungle.bt.co.uk> In-Reply-To: <201405281715.s4SHFMm0014634@bagheera.jungle.bt.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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/sWS7n3o-WaHqR46QcCi7vDi-JmY Cc: David Borman , "tcpm@ietf.org" Subject: Re: [tcpm] New Version Notification for draft-touch-tcpm-tcp-edo-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: Wed, 28 May 2014 17:59:48 -0000 On 5/28/2014 10:13 AM, Bob Briscoe wrote: > Joe, > > At 18:14 23/05/2014, Joe Touch wrote: > > >> On 5/23/2014 5:13 AM, Bob Briscoe wrote: >>> David, >>> >>> 1) Parallel control channel >>> ___________________________ >>> Client A sends two SYNs back-to-back to an existing well-known port >>> (e.g. 80). >> >> You can send in whatever order you want; packets will be reordered, >> lost, and sent along alternate paths. > > Of course. > > But as I suggested initially, we can standardise the protocol so that an > upgraded host synthesises shared fate. Fate is dependent on path. > Eg. a 2-octet TCP option on the > D-type SYN that says "Hold for x [ms] to wait for the supplementary > C-type SYN, where x is a lot less than the usual time you hold SYN > connection state (e.g. x=2). If SYN C hasn't arrived by then, continue > without it, and discard it if it arrives." > > And if the C-SYN arrives first, hold it for y [ms] waiting for the > corresponding D-SYN. Where for example y=2 as well. (C=legacy; D=extended - from your earlier email, for context) Legacy clients now experience connection delays when contacting upgraded servers - why is that acceptable? FWIW, many endpoints don't hold SYN state at all if they implement SYN cookies, so 2ms would end up overloading the server with state much larger than it currently keeps. >> FWIW, do these use the same source port and ISN? >> - if they do, it'll reset the connection >> - if they don't, you're now limiting the number of >> concurrent connections to roughly half: >> http://www.isi.edu/touch/pubs/infocomm99/infocomm99-web/ > > Unless we can think of a way for the C-SYN to be discarded by a legacy > TCP stack (but not a middlebox), I'm assuming we need to get the C-SYN > up to the legacy app-layer before discard... So, I was assuming they use > different source ports (otherwise, as you say, a legacy TCP stack could > reset the D SYN connection if it arrived second) If they use different source ports, you could be limiting the connection rate. It's not enough to just "discard" late D-SYNs; they could be for new connections (how do you know the two are paired?), which means you need to RST them and keep state for 2MSL. > The ISN on the C-SYN is redundant - we might be able to think of another > use for that field. But it's not redundant if you're talking to a legacy server, so you can't do anything with that field. > On an upgraded host, max concurrent connections would only be slightly > impacted, because of the v small timeout of C-SYNs. See above; you need to know how to pair C-SYNs and D-SYNs. Consider that legacy hosts and upgraded hosts might be behind the same NAT, at which point how do you know the two SYNs are even from the same host? > The semantics of the option-space-extension option would be to only hold > the C-type SYN for a timeout and only the D-type SYN creates full > connection state (I'm deferring SYN cookie behaviour to tomorrow for now > - this is a straw man). I don't think you can defer a widely-deployed feature like SYN cookies, and that seems to kill this. > Admittedly, the number of concurrent connections a /legacy/ host can > support could reduce by up to half (if all remote TCP clients are > sending the new option). But they have the choice of upgrading to the > new stack to stop wasting their memory. Both legacy clients and legacy servers are impacted. We already know that servers are overloaded with connections, so halving that number seems like a non-starter. As does adding x ms delay for *each* legacy client. >>> * SYN D, establishes a regular data connection, with sufficient TCP >>> options to be workable but they still fit within the existing 40B option >>> limit. >>> * SYN C establishes another parallel connection to the same well-known >>> port that looks like regular data from the outside (it could even be an >>> extension to HTTP to ensure middleboxes will let it pass), but it talks >>> a new app-layer 'TCP control' protocol inside. >> >> What happens when they arrive out of order? What happens when you get >> D but not yet C? How long do you wait for C? > > See above. > The timeouts might be standardised, or they might be declared in the > option as a hint (for the host to ignore if it is under stress). > >> This is the problem with dual-stack approaches - new endpoints >> penalize legacy endpoints if there's a stall, and undermine new >> endpoints if they don't. > > Have I satisfied you that this can be solved sufficiently? Bearing in > mind the gain, it's reasonable to have to accept some pain. The pain is the problem. The smaller the timeout, the smaller the pain to legacy clients but the lower probability the extension will be useful to upgraded clients. The method cuts the rate of connections for legacy servers in half - which is *huge*. And it adds to the state overhead of the upgraded clients that need to do double the work for *every* connection. Ultimately, it's roughly equivalent to "try both and shut down the one you don't want" -- the dual-stack approach we already know about. >>> If there is no support for the new app-layer protocol on port 80 the >>> control channel just shuts down with a suitable HTTP error, while SYN D >>> has opened a data connection with sufficient TCP options to be workable. >>> If the new app-layer TCP control protocol is supported on port 80, the >>> parallel control channel (C) adds unlimited additional control >>> flexibility to the data channel (D) hardly any added latency. >>> >>> Establishing a similar control channel in the opposite direction would >>> be fairly trivial. >>> >>> There are few, if any, middlebox problems with the above approach. >>> However, there are certainly other problems, but no more insurmountable >>> than all the problems that have already been discussed with taking the >>> 'easy' route of EDO: >>> * A secure binding would have to be added to bind channel C to a secret >>> known only to the originator of channel D, otherwise it would open up >>> data channels to spoof control channel attacks. This binding could be >>> built on a TCP-AO option in channel D. >> >> Yes, that's another problem. > > Fairly straightforward to solve using standard techniques. I think that warrants more than a claim. You need to explain how you avoid false postives through NATs. >>> * Channel C would need some way to refer to the segments of channel D >>> that was robust against re-segmentation. >> >> Which means it won't work in the current Internet, because >> resegmentation is also widespread (though evil, IMO). > > Well, resegmentation isn't usually a problem on a SYN anyway. > > We can't improve on the general pain caused by resegmentation. I was > only talking about the delta pain that my strawman would suffer, where a > resegmenting function sees data on my SYN and doesn't understand my > strawman, so it won't patch up the damage in my strawman protocol that > it would have patched up by altering sequence numbers in a regular > single SYN with a payload. You're right, in the sense that SYN data would typically be discarded anyway at the endpoint if it implemented SYN cookies. > I think this is a corner case. It is, but you raised it in a general sense; were you thinking of it in terms of just SYNs or other segments? >>> * The main problem is that the two channels don't share fate;a control >>> packet can be delayed relative to the point in the data stream at which >>> it is attempting to exert control, possibly for a RTT if it is lost and >>> has to be retransmitted. However, this is not insurmountable. The >>> control protocol could include a mode to "synthesise shared fate", by >>> making the data channel buffer data until an associated control segment >>> had arrived. This would duplicate the latency impact of a loss or delay >>> on either channel, but one can imagine mitigations that would consign >>> this latency impact to corner cases. >>> * It's a bit of a mess, but that comes with the territory when trying to >>> fix legacy protocol problems. >>> * The internal stack architecture seems to require a trombone back down >>> into the kernel from user-space, but that is not insurmountable - a shim >>> within the kernel on port 80 (for example) could redirect control >>> channel data across to the "TCP control channel module" in the kernel, >>> while passing non-control channel connections to user-space. >>> >>> 2) Build on LOIC >>> ______________________ >>> Long option with invalid checksum >> >> Won't work through current NATs, which won't recalculate the checksum >> properly. > > I'm building on the general idea of using something invalid, not using > the checksum idea specifically. Anything considered invalid by an endpoint might be checked by an overzealous midbox. >>> At 18:53 22/05/2014, John Leslie wrote: >>>> That's too big of a change to ask folks to believe it safe. >>> >>> When I read an idea, I don't take it as set in stone and just find a >>> hole and dismiss it. I see it as a potential stepping stone to a >>> solution and think about how it could be done better. In fact, Andrew >>> Yourtchenko said that was the intention of his write-up of LOIC. >>> >>> I believe that an approach worth further thought would be a mixture of >>> the control channel idea and the invalid checksum idea. I'm thinking of: >>> * a pure control SYN (C) sent first, then a base SYN (D) sent >>> back-to-back, both to the same port. >> >> Again, please don't assume back-to-back means anything. > > See above. > Actually, even tho order isn'[t guaranteed, it is important to get them > in the right order to optimise performance (much as TCP doesn't assume > perfect order, but it goes smoothest with reasonable ordering). Right, but I want to emphasize that things emitted back-to-back could end up being delivered days later (e.g., when a link goes down, some routers just keep the queues there). The impact in those cases needs to be considered. >>> * SYN C would contain something invalid to cause a legacy TCP stack or >>> legacy app to discard it (and hopefully less probability that a >>> middlebox would), e.g. a payload that is invalid for the application >>> protocol on the port. >> >> But so will a NAT, etc. > > No. You can design a payload that has headers that a NAT will ignore but > an end-host will have to process. You can try, but if an end-host looks at it you can be sure that a midbox will do the same - if not today, then soon. > E.g. HTTP connection control headers > newly defined for this protocol that would be ignored by NATs, without > any other HTTP behaviour, so a legacy host does nothing at the app layer. Those are rewritten by "helpful" midboxes all the time, FWIW. >>> * there would be additional TCP options in the payload of SYN C to be >>> added to the TCP options that arrived separately on the base SYN >>> * The control SYN could be bound crytographically to the base SYN (as >>> already described). >>> * It could use the shim-like control stack arangement described earlier. >>> >>> By focusing solely on extending the SYN, this would avoid the ongoing >>> shared fate problems that a separate control channel suffers throughout >>> the connection. There would still be shared fate problems with 2 SYNs >>> (e.g. the two SYNs get re-ordered), but the protocol would have to be >>> designed to be robust to that (naively, SYN D could include a new TCP >>> option that told a new stack to wait a few ticks for a SYN C, but that >>> would be vulnerable to meddleboxes). Not insurmountable. >> >> AFAICT, it is. > > Still? If it means halving the performance of legacy servers and delaying legacy clients, yes. Joe From nobody Wed May 28 20:31: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 BAF861A0306 for ; Wed, 28 May 2014 20:31:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.43 X-Spam-Level: X-Spam-Status: No, score=-1.43 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, J_CHICKENPOX_42=0.6, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] 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 l3gENJOcHrdK for ; Wed, 28 May 2014 20:31:46 -0700 (PDT) Received: from mail-ie0-x230.google.com (mail-ie0-x230.google.com [IPv6:2607:f8b0:4001:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB5B11A02F3 for ; Wed, 28 May 2014 20:31:45 -0700 (PDT) Received: by mail-ie0-f176.google.com with SMTP id rl12so11151440iec.21 for ; Wed, 28 May 2014 20:31:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=YFhUpFy7/Gp3bZMK325AVC/2Ohn2f4/RSQirut8YbLI=; b=Rlu+w+zMSALxatDHlYgTpxZKwYzbmVcCe6cp8fjduuNZ6lNPycDaikdtM08KLAuTSQ LcIgx0wpHWoMPtXi3htrgdK8GsZB6ZiDawWfNN48yMDPjW+PtP+rEDFOFWJnfxyZifnc FErexPYnlMrxXyQa9l00esk9G4ncmr+Fku4hXgBTr2ghia2JQoYJQwWna+2k9lrvr595 AY+Tns+OIz1GVPaSjOlBVrGReUtUoZt2j/B2Idx7my3Z2NPxuHCNRZXAeptJLyxz931i 3DDd4u/IzSuFFOqft7Rgdp1+3G3Df2AxFr+W+2jWarQmI4vs+kCu5eDM4zZB6pzcgbTt lXng== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=YFhUpFy7/Gp3bZMK325AVC/2Ohn2f4/RSQirut8YbLI=; b=IylFpls4ozTalhNh468Dq0EJJ5nOT7XILmVYolybuI+7xtcQCRa0RsETuVBCO5rzOl LBg3IiuYh52T3qmw1cwaUvEaNwWNhN2L1iC2afTmMVlObqMCKFtOvKz0dfVWzaCQgBSA 1+Ps5ZeO056MDHVTBUHke46hbL3tJfjHyhhn42mRZBpBobo1TyLzbR+rF15FeRVUPwl4 zAiwkGjX65GihC78DbYt1JzkBF/SqTGmrb7PUb7/YcYZEqgi5LnCpjmGDoap6ahQOcrt fvMCXPpeBLVBpkLK7lRZqiJ1ofsldS3PK4rq34+bg74l4VV+odvGWJTNttHS6oy50gjw t3Zg== X-Gm-Message-State: ALoCoQml63h+GoE6gH6AgdjEJ0ODQT8NYn6zvvyaLJPl0cKg8bw991Jx+0P/Mm3p9CUyVcmPqJJg X-Received: by 10.50.46.100 with SMTP id u4mr6555527igm.23.1401334301889; Wed, 28 May 2014 20:31:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.223.163 with HTTP; Wed, 28 May 2014 20:31:01 -0700 (PDT) In-Reply-To: <20140526091232.GN20942@eerihug-hybrid.rnd.ki.sw.ericsson.se> References: <20140521073611.GA1940@eerihug-hybrid.rnd.ki.sw.ericsson.se> <20140521114628.C72DB6B339F@lawyers.icir.org> <20140521125518.GC1940@eerihug-hybrid.rnd.ki.sw.ericsson.se> <012C3117EDDB3C4781FD802A8C27DD4F4A3C3904@SACEXCMBX02-PRD.hq.netapp.com> <20140523133251.GA28880@eerihug-hybrid.rnd.ki.sw.ericsson.se> <20140526091232.GN20942@eerihug-hybrid.rnd.ki.sw.ericsson.se> From: Yuchung Cheng Date: Wed, 28 May 2014 20:31:01 -0700 Message-ID: To: Erik Hugne Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/Zt2XbP9yfxhTjL8MAwx0_Eko7Hg Cc: "ingemar.s.johansson@ericsson.com" , "martin.isaksson@ericsson.com" , "tcpm@ietf.org" , Mark Allman Subject: Re: [tcpm] RFC3465:TCP ABC and SACK'ed data 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, 29 May 2014 03:31:47 -0000 On Mon, May 26, 2014 at 2:12 AM, Erik Hugne wrote: > Here's from a test just this morning, wgetting a 10MB file. > https://www.dropbox.com/sh/86u3nzcwukjzpzv/AAAlp_Me7wXf7PRyuWFq9Lmwa The problem is neither ABC nor SACK. It's bad interaction of DSACK/undo, F-RTO, and rate-halving in the old kernel. These features have gone through major changes since 3.0 (F-RTO re-implementation, PRR, dozens fixes of TCP undo) so I'd recommend trying 3.12+ kernel as well. 00:00:00.000026 IP s > c: Flags [.], seq 83359754:83368442, ack 145, win 122, options [nop,nop,TS val 1294920005 ecr 1943986835], length 8688 // Timeout & retransmit the head 00:00:01.806873 IP s > c: Flags [.], seq 80269362:80270810, ack 145, win 122, options [nop,nop,TS val 1294920482 ecr 1943986836], length 1448 // a DSACK indicating the timeout is spurious, however cwnd is not reverted and F-RTO is activated to send a new data packet 00:00:00.305013 IP c > s: Flags [.], ack 80270810, win 6132, options [nop,nop,TS val 1943987388 ecr 1294920482,nop,nop,sack 1 {80269362:80270810}], length 0 00:00:00.000070 IP s > c: Flags [.], seq 83368442:83372786, ack 145, win 122, options [nop,nop,TS val 1294920558 ecr 1943987388], length 4344 // On receiving the SACK for the F-RTO probe, we got "stuck" in the stop and go, possibly a bug in rate-halving/loss-recovery/f-rto? 00:00:00.200690 IP c > s: Flags [.], ack 80270810, win 6132, options [nop,nop,TS val 1943987438 ecr 1294920482,nop,nop,sack 1 {83368442:83372786}], length 0 00:00:00.000053 IP s > c: Flags [.], seq 80270810:80272258, ack 145, win 122, options [nop,nop,TS val 1294920608 ecr 1943987438], length 1448 00:00:00.000009 IP s > c: Flags [.], seq 80272258:80273706, ack 145, win 122, options [nop,nop,TS val 1294920608 ecr 1943987438], length 1448 00:00:00.000003 IP s > c: Flags [.], seq 80273706:80275154, ack 145, win 122, options [nop,nop,TS val 1294920608 ecr 1943987438], length 1448 00:00:00.200629 IP c > s: Flags [.], ack 80275154, win 6126, options [nop,nop,TS val 1943987488 ecr 1294920608,nop,nop,sack 1 {83368442:83372786}], length 0 00:00:00.000033 IP s > c: Flags [.], seq 80275154:80276602, ack 145, win 122, options [nop,nop,TS val 1294920658 ecr 1943987488], length 1448 00:00:00.000007 IP s > c: Flags [.], seq 80276602:80278050, ack 145, win 122, options [nop,nop,TS val 1294920658 ecr 1943987488], length 1448 00:00:00.000004 IP s > c: Flags [.], seq 80278050:80279498, ack 145, win 122, options [nop,nop,TS val 1294920658 ecr 1943987488], length 1448 > > //E > > On Fri, May 23, 2014 at 04:06:12PM -0700, Yoshifumi Nishida wrote: >> This is just out of my curiosity, but can we share the tcpdump file for >> this? >> -- >> Yoshi >> >> On Friday, May 23, 2014, Erik Hugne >> > >> wrote: >> >> > Maybe.. >> > This is a standard Linux 3.0 kernel with sack and frto enabled. >> > Additional lab experiments have shown that following the path change, a >> > stream >> > of lost packets occurs (almost a full window, ~400kB). The receiver sends >> > dupacks on the new path to trigger fast retransmit, but then the >> > retransmission >> > timer on the sender side fires and all unacked data will be resent. At the >> > RTO, >> > we get the expected cwnd drop. While the receiver keeps kicking the the >> > sender >> > by sending dupacks, the retransmission is reasonably fast but after a few >> > ms it >> > grinds down to a stop-and-go behaviour. >> > >> > I failed in my efforts to find some explanation to this in the RFC's. >> > What i did find was in VJ's paper from '88. >> > >> > -When starting or restarting after a loss, set cwnd to one packet. >> > -On each ack for new data, increase cwnd by one packet >> > >> > If retransmitted data are not considered "new", that would explain the >> > behavior >> > i guess. >> > >> > Scripted ss -ti for the connection every 3 sec. >> > In this test it wasn't even a path change, we just downed the interface on >> > a >> > router in the middle for some 300ms to simulate the packetloss (This was >> > done at 15:06:18) >> > >> > Fri May 23 15:06:01 CEST 2014 >> > reno wscale:9,7 rto:1892 rtt:1678/7 ato:40 cwnd:2215 send 15.3Mbps >> > rcv_space:14480 >> > Fri May 23 15:06:04 CEST 2014 >> > reno wscale:9,7 rto:1888 rtt:1678/8 ato:40 cwnd:2215 send 15.3Mbps >> > rcv_space:14480 >> > Fri May 23 15:06:07 CEST 2014 >> > reno wscale:9,7 rto:1888 rtt:1676/9 ato:40 cwnd:2215 send 15.3Mbps >> > rcv_space:14480 >> > Fri May 23 15:06:10 CEST 2014 >> > reno wscale:9,7 rto:1884 rtt:1675.5/5 ato:40 cwnd:2215 send >> > 15.3Mbps rcv_space:14480 >> > Fri May 23 15:06:14 CEST 2014 >> > reno wscale:9,7 rto:1816 rtt:1607.5/22 ato:40 cwnd:2215 send >> > 16.0Mbps rcv_space:14480 >> > Fri May 23 15:06:17 CEST 2014 >> > reno wscale:9,7 rto:1892 rtt:1681.5/7 ato:40 cwnd:2215 send >> > 15.3Mbps rcv_space:14480 >> > Fri May 23 15:06:20 CEST 2014 >> > reno wscale:9,7 rto:1548 rtt:651/225 ato:40 cwnd:3 ssthresh:1107 >> > send 53.4Kbps rcv_space:14480 >> > Fri May 23 15:06:23 CEST 2014 >> > reno wscale:9,7 rto:1224 rtt:263/110 ato:40 cwnd:3 ssthresh:1107 >> > send 132.1Kbps rcv_space:14480 >> > Fri May 23 15:06:26 CEST 2014 >> > reno wscale:9,7 rto:1172 rtt:210.5/18 ato:40 cwnd:3 ssthresh:1107 >> > send 165.1Kbps rcv_space:14480 >> > Fri May 23 15:06:29 CEST 2014 >> > reno wscale:9,7 rto:1164 rtt:203.5/6 ato:40 cwnd:3 ssthresh:1107 >> > send 170.8Kbps rcv_space:14480 >> > Fri May 23 15:06:32 CEST 2014 >> > reno wscale:9,7 rto:1164 rtt:203.5/3 ato:40 cwnd:3 ssthresh:1107 >> > send 170.8Kbps rcv_space:14480 >> > Fri May 23 15:06:35 CEST 2014 >> > reno wscale:9,7 rto:1164 rtt:203.5/3 ato:40 cwnd:6 ssthresh:1107 >> > send 341.5Kbps rcv_space:14480 >> > Fri May 23 15:06:38 CEST 2014 >> > reno wscale:9,7 rto:1164 rtt:203.5/4 ato:40 cwnd:6 ssthresh:1107 >> > send 341.5Kbps rcv_space:14480 >> > Fri May 23 15:06:41 CEST 2014 >> > reno wscale:9,7 rto:1168 rtt:204/4 ato:40 cwnd:6 ssthresh:1107 >> > send 340.7Kbps rcv_space:14480 >> > Fri May 23 15:06:44 CEST 2014 >> > reno wscale:9,7 rto:1164 rtt:203.5/3 ato:40 cwnd:6 ssthresh:1107 >> > send 341.5Kbps rcv_space:14480 >> > Fri May 23 15:06:47 CEST 2014 >> > reno wscale:9,7 rto:1164 rtt:203.5/3 ato:40 cwnd:6 ssthresh:1107 >> > send 341.5Kbps rcv_space:14480 >> > Fri May 23 15:06:50 CEST 2014 >> > reno wscale:9,7 rto:1164 rtt:203.5/3 ato:40 cwnd:6 ssthresh:1107 >> > send 341.5Kbps rcv_space:14480 >> > Fri May 23 15:06:53 CEST 2014 >> > reno wscale:9,7 rto:1164 rtt:203.5/3 ato:40 cwnd:6 ssthresh:1107 >> > send 341.5Kbps rcv_space:14480 >> > Fri May 23 15:06:56 CEST 2014 >> > reno wscale:9,7 rto:1164 rtt:203.5/3 ato:40 cwnd:6 ssthresh:1107 >> > send 341.5Kbps rcv_space:14480 >> > Fri May 23 15:06:59 CEST 2014 >> > reno wscale:9,7 rto:1164 rtt:203.5/4 ato:40 cwnd:6 ssthresh:1107 >> > send 341.5Kbps rcv_space:14480 >> > Fri May 23 15:07:02 CEST 2014 >> > reno wscale:9,7 rto:1164 rtt:203.5/3 ato:40 cwnd:9 ssthresh:1107 >> > send 512.3Kbps rcv_space:14480 >> > Fri May 23 15:07:05 CEST 2014 >> > reno wscale:9,7 rto:1164 rtt:203.5/3 ato:40 cwnd:9 ssthresh:1107 >> > send 512.3Kbps rcv_space:14480 >> > Fri May 23 15:07:08 CEST 2014 >> > reno wscale:9,7 rto:1164 rtt:203.5/3 ato:40 cwnd:9 ssthresh:1107 >> > send 512.3Kbps rcv_space:14480 >> > Fri May 23 15:07:11 CEST 2014 >> > reno wscale:9,7 rto:1260 rtt:487.5/8 ato:40 cwnd:960 ssthresh:1107 >> > send 22.8Mbps rcv_space:14480 >> > Fri May 23 15:07:14 CEST 2014 >> > reno wscale:9,7 rto:1244 rtt:863.5/6 ato:40 cwnd:1111 >> > ssthresh:1107 send 14.9Mbps rcv_space:14480 >> > Fri May 23 15:07:17 CEST 2014 >> > reno wscale:9,7 rto:1148 rtt:864/6 ato:40 cwnd:1114 ssthresh:1107 >> > send 14.9Mbps rcv_space:14480 >> > Fri May 23 15:07:20 CEST 2014 >> > reno wscale:9,7 rto:1096 rtt:868/8 ato:40 cwnd:1118 ssthresh:1107 >> > send 14.9Mbps rcv_space:14480 >> > >> > On Thu, May 22, 2014 at 06:47:56AM +0000, Scheffenegger, Richard wrote: >> > > >> > > Are you perhaps observing an effect of the ACK clock loss, when you >> > refer to a huge number of consecutive lost segments? >> > > >> > > Standard SACK does suffer from an issue that during loss recovery, there >> > may be a gap (SACKs don't clock out new/retransmitted packets while >> > flightsize > cwnd (which is now 1/2); only during the 2nd half, SACK starts >> > to clock out packets, but at the same rate as before (which may not that >> > bright an idea if a path change with differnet characteristics is now >> > there). >> > > >> > > RateHalving (Linux has some kind of variant of this) / Proportional Rate >> > Reduction RFC6937 may be the thing that you are after? >> > > >> > > >> > > ABC really only comes into play during slowstart, to make connections >> > which use delayed ACKs not perform much less aggressive than sessions where >> > the receiver features QuickAck (Linux non-standard). >> > > >> > > Best regards, >> > > >> > > >> > > Richard Scheffenegger >> > > >> > > >> > > > -----Original Message----- >> > > > From: tcpm [mailto:tcpm-bounces@ietf.org] On Behalf Of Erik Hugne >> > > > Sent: Mittwoch, 21. Mai 2014 14:55 >> > > > To: Mark Allman >> > > > Cc: ingemar.s.johansson@ericsson.com; martin.isaksson@ericsson.com; >> > > > tcpm@ietf.org >> > > > Subject: Re: [tcpm] RFC3465:TCP ABC and SACK'ed data >> > > > >> > > > On Wed, May 21, 2014 at 07:46:28AM -0400, Mark Allman wrote: >> > > > > >> > > > > > TCP ABC (still in the experimental track) defines a method to >> > > > > > increase the cwnd based on the bytes being acknowledged, instead of >> > > > > > the number of acks that arrive. I am assuming that SACK'ed >> > (RFC2018) >> > > > > > data should be included in this calculation, but i could find no >> > > > > > mention of this in RFC3465. Could someone confirm this? >> > > > > >> > > > > ABC does not include SACK information in its calculations and it >> > > > > cannot include SACK information. ABC applies to slow start---which >> > > > > ends when loss occurs. And, (essentially) SACKs only arrive during >> > loss >> > > > recovery. >> > > > > So, there is no need for ABC to deal with SACKs. >> > > > > >> > > > >> > > > Thanks for taking the time to explain this. >> > > > >> > > > The problem (this is related to Ingemars posts around "Problem with low >> > > > SSthresh") is that following the path change, there is a large train of >> > > > segments being lost (say 150k out of a 500k window). Data at the end of >> > > > the window did make it through and is SACK'ed. Upon receiving these >> > SACK's >> > > > the sending side enters loss recovery. It will take a very long time >> > > > before recovering the 100k lost segments. >> > > > >> > > > An aggressive recovery algorithm would mitigate the effects of this, >> > but i >> > > > was hoping for a more elegant solution. >> > > > >> > > > //E >> > > > >> > > > _______________________________________________ >> > > > 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 >> > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Fri May 30 02:55:27 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 7727F1A084B for ; Fri, 30 May 2014 02:55:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.252 X-Spam-Level: X-Spam-Status: No, score=-3.252 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651, 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 JT5AoIUhRWBR for ; Fri, 30 May 2014 02:55:23 -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 2B1451A083C for ; Fri, 30 May 2014 02:55:23 -0700 (PDT) Received: from EVMHR72-UKRD.domain1.systemhost.net (10.36.3.110) by EVMHR67-UKRD.bt.com (10.187.101.22) with Microsoft SMTP Server (TLS) id 8.3.348.2; Fri, 30 May 2014 10:55:17 +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; Fri, 30 May 2014 10:55:12 +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, 30 May 2014 10:55:12 +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 s4U9tAto028369; Fri, 30 May 2014 10:55:11 +0100 Message-ID: <201405300955.s4U9tAto028369@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 30 May 2014 10:55:10 +0100 To: Joe Touch From: Bob Briscoe In-Reply-To: <53861D4F.60709@isi.edu> References: <20140425221257.12559.43206.idtracker@ietfa.amsl.com> <2586_1398464386_535ADF82_2586_915_1_535ADF56.9050106@isi.edu> <5363AF84.8090701@mti-systems.com> <5363B397.8090009@isi.edu> <655C07320163294895BBADA28372AF5D2CFE36@FR712WXCHMBA15.zeu.alcatel-lucent.com> <20140503122950.GM44329@verdi> <655C07320163294895BBADA28372AF5D2D009E@FR712WXCHMBA15.zeu.alcatel-lucent.com> <201405221710.s4MHAY4S002037@bagheera.jungle.bt.co.uk> <537E3ACD.5000308@isi.edu> <537E48CE.8040704@mti-systems.com> <537E66A7.4080907@isi.edu> <201405231003.s4NA3PAB005137@bagheera.jungle.bt.co.uk> <537F7D91.10802@isi.edu> <201405281716.s4SHG29Y014642@bagheera.jungle.bt.co.uk> <53861D4F.60709@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/baPWU7e_okmQTOmMMFz1dY4CJR8 Cc: "tcpm@ietf.org" Subject: Re: [tcpm] New Version Notification for draft-touch-tcpm-tcp-edo-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: Fri, 30 May 2014 09:55:25 -0000 Joe, I was asking for an example of something useful that /can/ be done with EDO. I'm sure you can come up with one. However, you have shown conclusively that the example in the draft (SACK + MPTCP + TCP-AO), when added to the widespread basic options, /cannot/ be done with EDO, because it needs 7 more bytes of options than a SYN allows. Bob At 18:30 28/05/2014, Joe Touch wrote: >On 5/28/2014 10:16 AM, Bob Briscoe wrote: >>Joe, >> >>I don't think this sufficiently answers the question to justify WG >>adoption. You seem to be confirming that this is an academic exercise. > >You asked for a specific example - one that the MPTCP community has >raised. It's not a proof that there's "some set" that might overload >the space; it's based on a *specific* request. > >I gave other reasons - including educating the community as to the >issues. If you want to call that "academic", sure - in part. > >But I don't see that as interfering with WG adoption - we do that >sort of thing all the time (that's the basis of a BCP). > >Joe > >>At 17:55 23/05/2014, Joe Touch wrote: >>>Hi, Bob, >>> >>>On 5/23/2014 3:03 AM, Bob Briscoe wrote: >>>>Joe, and everyone else who wants to work on this, >>>> >>>>Just because it's easier to make a chocolate teapot than a cast-iron >>>>one, doesn't imply that there is any need for chocolate teapots. >>> >>>You don't get a cast iron teapot just because you want one either ;-) >>> >>>>IOW, we will be asking the IESG to spend reviewer time on EDO, so we >>>>need to give some plausible indication that someone might find it useful >>>>and it's not just an academic exercise. >>> >>>Sometimes the answer "you can't have A, but at least here's B" is more >>>than an exercise; it educates the community. By not providing either >>>answer, we have continued to drag this issue around the block for far >>>too long -- and spent far too many cycles in this and other WGs >>>seeking solutions. >>> >>> > The current draft solely gives >>>>SACK + MPTCP + TCP-AO as an example, but is that really something that >>>>can't be done today? >>> >>>Current total for SYN options in widespread concurrent use (as already >>>described in sec 6.4): >>> >>> 2 SACK permitted >>> 10 timestamp >>> 3 window scale >>> 4 MSS >>> ------------------ >>> 11 bytes >>> >>>The current DO field is 4 bits, with a max value of 15 = 60 bytes for >>>the total header, less 20 for the base TCP header which leaves 40 for >>>options. >>> >>>So let's see what happens when we add: >>> >>> 11 widespread basic options >>> 16 TCP-AO >>> 20 MPTCP >>> -------------------- >>> 47 >>> >>>That's more than 40. >>> >>>>Adding more complexity to the TCP stack (with the potential for more >>>>vulnerabilities) is only worthwhile if there's an identifiable benefit, >>>>otherwise few production stacks are going to implement it anyway. >>> >>>There are two identifiable benefits: >>> >>> 1) explain the ways we already know we can't extend the SYN >>> so we stop wasting time trying them repeatedly (i.e., education) >>> >>> 2) provide a solution for the other segments, so that can be >>> used - e.g., for large SACK responses >>> >>> 3) educate the community >>> >>>Joe >> >>________________________________________________________________ >>Bob Briscoe, BT > >________________________________________________________________ >Bob Briscoe, BT From nobody Fri May 30 06:50:54 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 AC4C41A090F for ; Fri, 30 May 2014 06:50:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] 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 SIKvg2ZUM3L6 for ; Fri, 30 May 2014 06:50:50 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id A5EC01A08FA for ; Fri, 30 May 2014 06:50:50 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id B7001C94C3; Fri, 30 May 2014 09:50:44 -0400 (EDT) Date: Fri, 30 May 2014 09:50:44 -0400 From: John Leslie To: Bob Briscoe Message-ID: <20140530135044.GE23373@verdi> References: <655C07320163294895BBADA28372AF5D2D009E@FR712WXCHMBA15.zeu.alcatel-lucent.com> <201405221710.s4MHAY4S002037@bagheera.jungle.bt.co.uk> <537E3ACD.5000308@isi.edu> <537E48CE.8040704@mti-systems.com> <537E66A7.4080907@isi.edu> <201405231003.s4NA3PAB005137@bagheera.jungle.bt.co.uk> <537F7D91.10802@isi.edu> <201405281716.s4SHG29Y014642@bagheera.jungle.bt.co.uk> <53861D4F.60709@isi.edu> <201405300955.s4U9tAto028369@bagheera.jungle.bt.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201405300955.s4U9tAto028369@bagheera.jungle.bt.co.uk> User-Agent: Mutt/1.4.1i Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/t6AI-6DlVouvmnE2aZ46Vz7gBGY Cc: "tcpm@ietf.org" , Joe Touch Subject: Re: [tcpm] New Version Notification for draft-touch-tcpm-tcp-edo-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: Fri, 30 May 2014 13:50:52 -0000 Bob Briscoe wrote: > > I was asking for an example of something useful that /can/ be done with EDO. > > I'm sure you can come up with one. However, you have shown > conclusively that the example in the draft (SACK + MPTCP + TCP-AO), > when added to the widespread basic options, /cannot/ be done with > EDO, because it needs 7 more bytes of options than a SYN allows. The claim that MPTCP needs 20 bytes in the SYN is getting on my nerves... As I read RFC 6824, it seems pretty clear that the initial SYN calls for 12 bytes, not 20. It's the SYN-ACK that uses 20. Somebody please correct me if I'm reading this wrong. -- John Leslie From nobody Fri May 30 07:14:38 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 6FA971A08F6 for ; Fri, 30 May 2014 07:14:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 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_MED=-2.3, 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 4fYNOYQnVKjb for ; Fri, 30 May 2014 07:14:33 -0700 (PDT) Received: from smtp6.sgsi.ucl.ac.be (smtp.sgsi.ucl.ac.be [130.104.5.67]) by ietfa.amsl.com (Postfix) with ESMTP id 0ADBE1A08BD for ; Fri, 30 May 2014 07:14:33 -0700 (PDT) Received: from localhost (cpaasch-mac.dhcp.info.ucl.ac.be [130.104.228.20]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: cpaasch@smtp6.sgsi.ucl.ac.be) by smtp6.sgsi.ucl.ac.be (Postfix) with ESMTPSA id 46CE618350A; Fri, 30 May 2014 16:14:11 +0200 (CEST) X-DKIM: Sendmail DKIM Filter v2.8.3 smtp6.sgsi.ucl.ac.be 46CE618350A DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1401459251; bh=fLkbGHf2UNvzw7q8nXv8Qahj9bhZqMsmCrsWRhcfaOM=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:In-Reply-To; b=s3e39b9EgdIjegkBRzvmxUxCWHHlvu2ToTndM/Sh0ve29AyOYnmIJFrdvueFBCtVU dJmYGvrUOrNVZPm9KXSmBcOKt96ZB5+57e5pjGbUE1rfnOA1Jm3O2AGaFBle2IcrRV vxPjfbElte30v+M3/9cjhwucZVpbAtL4bQV/TzUE= Date: Fri, 30 May 2014 16:14:11 +0200 From: Christoph Paasch To: John Leslie Message-ID: <20140530141411.GE4765@cpaasch-mac> References: <201405221710.s4MHAY4S002037@bagheera.jungle.bt.co.uk> <537E3ACD.5000308@isi.edu> <537E48CE.8040704@mti-systems.com> <537E66A7.4080907@isi.edu> <201405231003.s4NA3PAB005137@bagheera.jungle.bt.co.uk> <537F7D91.10802@isi.edu> <201405281716.s4SHG29Y014642@bagheera.jungle.bt.co.uk> <53861D4F.60709@isi.edu> <201405300955.s4U9tAto028369@bagheera.jungle.bt.co.uk> <585d073725d54c45927872774a3f4bf1@UCL-MBX03.OASIS.UCLOUVAIN.BE> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <585d073725d54c45927872774a3f4bf1@UCL-MBX03.OASIS.UCLOUVAIN.BE> User-Agent: Mutt/1.5.21 (2010-09-15) X-Virus-Scanned: clamav-milter 0.97.7-exp at smtp-6.sipr-dc.ucl.ac.be X-Virus-Status: Clean X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-MailScanner-ID: 46CE618350A.AE94F X-SGSI-MailScanner: Found to be clean X-SGSI-From: christoph.paasch@uclouvain.be X-SGSI-Spam-Status: No Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/kErq69zTWWBZREcKiU2K1OkNrro Cc: "tcpm@ietf.org" , Joe Touch Subject: Re: [tcpm] New Version Notification for draft-touch-tcpm-tcp-edo-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: Fri, 30 May 2014 14:14:36 -0000 On 30/05/14 - 13:50:44, John Leslie wrote: > Bob Briscoe wrote: > > > > I was asking for an example of something useful that /can/ be done with EDO. > > > > I'm sure you can come up with one. However, you have shown > > conclusively that the example in the draft (SACK + MPTCP + TCP-AO), > > when added to the widespread basic options, /cannot/ be done with > > EDO, because it needs 7 more bytes of options than a SYN allows. > > The claim that MPTCP needs 20 bytes in the SYN is getting on my > nerves... > > As I read RFC 6824, it seems pretty clear that the initial SYN calls > for 12 bytes, not 20. It's the SYN-ACK that uses 20. Somebody please > correct me if I'm reading this wrong. Indeed, it uses 12 bytes on both the SYN and the SYN/ACK. Only the third ACK carries 20 bytes. Cheers, Christoph From nobody Fri May 30 09:42: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 815441A09A9 for ; Fri, 30 May 2014 09:42:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.352 X-Spam-Level: X-Spam-Status: No, score=-1.352 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_18=0.6, J_CHICKENPOX_41=0.6, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] 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 NJ1HBd0Xi6M8 for ; Fri, 30 May 2014 09:42:49 -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 B4B5E1A09A5 for ; Fri, 30 May 2014 09:42:48 -0700 (PDT) Received: from EVMHR72-UKRD.domain1.systemhost.net (10.36.3.110) by EVMHR65-UKRD.bt.com (10.187.101.20) with Microsoft SMTP Server (TLS) id 14.3.181.6; Fri, 30 May 2014 17:42:42 +0100 Received: from EPHR01-UKIP.domain1.systemhost.net (147.149.196.177) by EVMHR72-UKRD.domain1.systemhost.net (10.36.3.110) with Microsoft SMTP Server (TLS) id 8.3.348.2; Fri, 30 May 2014 17:42:41 +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, 30 May 2014 17:42:40 +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 s4UGgcvY030471; Fri, 30 May 2014 17:42:39 +0100 Message-ID: <201405301642.s4UGgcvY030471@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 30 May 2014 17:42:37 +0100 To: Joe Touch From: Bob Briscoe In-Reply-To: <538623B9.2060209@isi.edu> References: <20140425221257.12559.43206.idtracker@ietfa.amsl.com> <2586_1398464386_535ADF82_2586_915_1_535ADF56.9050106@isi.edu> <5363AF84.8090701@mti-systems.com> <5363B397.8090009@isi.edu> <655C07320163294895BBADA28372AF5D2CFE36@FR712WXCHMBA15.zeu.alcatel-lucent.com> <20140503122950.GM44329@verdi> <655C07320163294895BBADA28372AF5D2D009E@FR712WXCHMBA15.zeu.alcatel-lucent.com> <201405221710.s4MHAY4S002037@bagheera.jungle.bt.co.uk> <537E3ACD.5000308@isi.edu> <1AD79820-22C1-4500-84D1-1383F264D68C@weston.borman.com> <201405231213.s4NCDa5P005525@bagheera.jungle.bt.co.uk> <537F8202.4020907@isi.edu> <201405281715.s4SHFMm0014634@bagheera.jungle.bt.co.uk> <538623B9.2060209@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/dPXSYiEmo2ydz5f-qdSI31NXMIA Cc: David Borman , "tcpm@ietf.org" Subject: Re: [tcpm] New Version Notification for draft-touch-tcpm-tcp-edo-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: Fri, 30 May 2014 16:42:52 -0000 Joe, At 18:58 28/05/2014, Joe Touch wrote: >On 5/28/2014 10:13 AM, Bob Briscoe wrote: >>Joe, >>At 18:14 23/05/2014, Joe Touch wrote: >>>On 5/23/2014 5:13 AM, Bob Briscoe wrote: >>>>David, >>>> >>>>1) Parallel control channel >>>>___________________________ >>>>Client A sends two SYNs back-to-back to an existing well-known port >>>>(e.g. 80). >>> >>>You can send in whatever order you want; packets will be reordered, >>>lost, and sent along alternate paths. >> >>Of course. >> >>But as I suggested initially, we can standardise the protocol so that an >>upgraded host synthesises shared fate. > >Fate is dependent on path. > >>Eg. a 2-octet TCP option on the >>D-type SYN that says "Hold for x [ms] to wait for the supplementary >>C-type SYN, where x is a lot less than the usual time you hold SYN >>connection state (e.g. x=2). If SYN C hasn't arrived by then, continue >>without it, and discard it if it arrives." > > >>And if the C-SYN arrives first, hold it for y [ms] waiting for the >>corresponding D-SYN. Where for example y=2 as well. > >(C=legacy; D=extended - from your earlier email, for context) THis is not a good way to describe them, because neither SYN is legacy, but even if you did think this way, it would be the other way round (mnemonic: D = primary *D*ata connection, C = additional *C*ontrol options). >Legacy clients now experience connection delays when contacting >upgraded servers - why is that acceptable? Nope. A legacy client experiences no extra delay. As I said, both non-legacy SYNs carry a flag TCP option that says that the server should wait for the other if it hasn't seen it yet. A legacy client wouldn't add this option, so there would never be any delay. Only upgraded clients see any extra delay, and then only if the C-SYN is lost. In the 'regular' case where the two SYNs both arrive, even upgraded clients see no delay. There's only additional delay if the C-SYN is lost AND both client and server are upgraded. If the D-SYN is lost, there would have been a delay anyway. >FWIW, many endpoints don't hold SYN state at all if they implement >SYN cookies, so 2ms would end up overloading the server with state >much larger than it currently keeps. Let's deal with whether SYN cookies can be supported alongside this dual-SYN scheme first... Because both client and server have to support using a pair of SYNs, the server doesn't have to exactly mimic the SYN cookie mechanism, it just has to achieve the same outcome as a SYN cookie. So the generalised question is: how does a server accept C-SYNs and D-SYNs, but also reflect all its connection state back off the client, without holding any state itself, while at the same time responding to any negotiation requests in the TCP options on both SYNs, so as not to delay negotiations. ==SYN Cookie v2== The high level answer would surely be for the server to use an EDO TCP option on the SYN-ACK, and put all the connection state in a suitably large TCP option, for the client to reflect back. On the SYN-ACK, the server would also include any responses to TCP options (on either SYN) that expected responses. Back to your original question, paraphrasing: "Doesn't holding state for 2ms risk more overload?" The answer comes in two parts: 1) The server reduces y (the time it holds C-SYNs) the more it is under pressure. Then if necessary it reduces x (the time it holds D-SYNs), until both are zero. 2) This seems to allow a flooding attack to make a server remove the SYN extension facility, but we can prevent that... For either SYN, a server doesn't just discard it when it reaches the timeout. For SYN-D it returns a SYN cookie, and for SYN-C it returns a SYN Cookie v2 (described eariler). For a genuine client this doesn't mean that an attack prevents the use of dual SYNs, it merely defers binding the two SYNs together until the next round. This only affects any options that depend on being combined with information in the other SYN, which should be a corner case. (...I'm making this up as I go along, but it's still holding water pretty well isn't it.) Perhaps this points to an alternative solution, where SYN cookie v2 is always used, and the binding between the two SYNs only happens on the second round. >>>FWIW, do these use the same source port and ISN? >>> - if they do, it'll reset the connection >>> - if they don't, you're now limiting the number of >>> concurrent connections to roughly half: >>> http://www.isi.edu/touch/pubs/infocomm99/infocomm99-web/ >> >>Unless we can think of a way for the C-SYN to be discarded by a legacy >>TCP stack (but not a middlebox), I'm assuming we need to get the C-SYN >>up to the legacy app-layer before discard... So, I was assuming they use >>different source ports (otherwise, as you say, a legacy TCP stack could >>reset the D SYN connection if it arrived second) > >If they use different source ports, you could be limiting the >connection rate. It's not enough to just "discard" late D-SYNs; they >could be for new connections (how do you know the two are paired?), >which means you need to RST them and keep state for 2MSL. The upgraded listener knows which D-SYN that a C-SYN is paired with as follows: 1) On the D-SYN, the TCP option declaring that it is a D-SYN would have to carry a parameter duplicating the src port in the main TCP header of the D-SYN (so it would survive NATing, unlike the src port itself). 2) On the C-SYN, the TCP option declaring that it is a C-SYN makes the server read the payload of the C-SYN, which contains the original value of the source port of the D-SYN. 3) The server can then match the src port inside the C-SYN to the original src port of the D-SYN. Once the server has both SYNs, it can check they are cryptographically paired, using other material that would have to be included in the C-SYN payload (tbd). Assuming you really meant discarding late C-SYNs,... Two cases, both don't need a 2MSL wait: 1) A legacy server doesn't have to RST the connection, because the app-layer payload is a valid app-layer header. Normally, of course, the server will hold back the payload on a SYN so it won't get to the app-layer unless the client responds to the SYN-ACK with an ACK. But that's OK, 'cos we don't need the paylkoad to get to the app-layer, we just need it to look like it would be valid if it did. The upgraded client could complete the 3WHS with a regular ACK, or it could respond with a RST. When a TCP server in SYN_SENT state receives a RST it returns to LISTEN state, and I believe it immediately discards connection state, because it never synchronised the connection. 2) If an upgraded host gets the C-SYN late, it knows it's a C-SYN, so when it tries to match it to a D-SYN it finds it already gave up waiting and went ahead with a connection based on the D-SYN alone. So it just silently discards the C-SYN with no need to keep to the TCP timeout rules (because it understands that a C-SYN doesn't open a connection itself). >>The ISN on the C-SYN is redundant - we might be able to think of another >>use for that field. > >But it's not redundant if you're talking to a legacy server, so you >can't do anything with that field. The ISN can be any number, and legacy TCPs will accept it. I just meant the field could be used for a number with some other useful meaning, because it never has to be used to synch any TCP sequence space. >>On an upgraded host, max concurrent connections would only be slightly >>impacted, because of the v small timeout of C-SYNs. > >See above; you need to know how to pair C-SYNs and D-SYNs. Consider >that legacy hosts and upgraded hosts might be behind the same NAT, >at which point how do you know the two SYNs are even from the same host? The crypto binding info in the C-SYN payload (tbd) would distinguish two hosts that a NAT had given the same src IP address. If the NAT gives different IP addresses to two connections from the same host, that would be a problem. We could get round that using a similar trick to that we already used to protect the src port value, but perhaps we don't need to, 'cos I think NATs like this are fairly rare (?). >>The semantics of the option-space-extension option would be to only hold >>the C-type SYN for a timeout and only the D-type SYN creates full >>connection state (I'm deferring SYN cookie behaviour to tomorrow for now >>- this is a straw man). > >I don't think you can defer a widely-deployed feature like SYN >cookies, and that seems to kill this. Solved above, I think. >>Admittedly, the number of concurrent connections a /legacy/ host can >>support could reduce by up to half (if all remote TCP clients are >>sending the new option). But they have the choice of upgrading to the >>new stack to stop wasting their memory. > >Both legacy clients and legacy servers are impacted. We already know >that servers are overloaded with connections, so halving that number >seems like a non-starter. As does adding x ms delay for *each* legacy client. Legacy clients are not impacted at all (as explained above). Legacy servers impact upgraded clients with delay ~2ms only if a C-SYN is lost. Zero otherwise. Legacy servers have to hold more connection state, but half is the worst case for the last legacy server on the planet after all clients have upgraded. If fraction f of clients have upgraded, a legacy server's connection state for n connections increases to n(1-f) + n(2f) = n(1+f). Ie. Legacy server connection state increases by fraction f, and at any time it can solve this by upgrading to coupled SYNs. Usually servers upgrade earlier than clients anyway. (Assumption: connection durations used by upgraded and legacy clients follow a similar distribution.) >>>>* SYN D, establishes a regular data connection, with sufficient TCP >>>>options to be workable but they still fit within the existing 40B option >>>>limit. >>>>* SYN C establishes another parallel connection to the same well-known >>>>port that looks like regular data from the outside (it could even be an >>>>extension to HTTP to ensure middleboxes will let it pass), but it talks >>>>a new app-layer 'TCP control' protocol inside. >>> >>>What happens when they arrive out of order? What happens when you get >>>D but not yet C? How long do you wait for C? >> >>See above. >>The timeouts might be standardised, or they might be declared in the >>option as a hint (for the host to ignore if it is under stress). > > > >> This is the problem with dual-stack approaches - new endpoints >>>penalize legacy endpoints if there's a stall, and undermine new >>>endpoints if they don't. >> >>Have I satisfied you that this can be solved sufficiently? Bearing in >>mind the gain, it's reasonable to have to accept some pain. > >The pain is the problem. The smaller the timeout, the smaller the >pain to legacy clients but the lower probability the extension will >be useful to upgraded clients. Solved using the SYN cookie 2 idea above. >The method cuts the rate of connections for legacy servers in half - >which is *huge*. Nope. It's cut by 1/(1+f) where f is the fraction of upgraded clients. And the legacy server can itself upgrade to avoid this completely. >And it adds to the state overhead of the upgraded clients that need >to do double the work for *every* connection. Accepted. However, state overhead is rarely a concern on clients. Anyway, they don't need to use more TCP options on every connection - only those connections that need them. >Ultimately, it's roughly equivalent to "try both and shut down the >one you don't want" -- the dual-stack approach we already know about. That's a bit of a wild dismissal of a scheme that so far seems to have pretty useful properties. >>>>If there is no support for the new app-layer protocol on port 80 the >>>>control channel just shuts down with a suitable HTTP error, while SYN D >>>>has opened a data connection with sufficient TCP options to be workable. >>>>If the new app-layer TCP control protocol is supported on port 80, the >>>>parallel control channel (C) adds unlimited additional control >>>>flexibility to the data channel (D) hardly any added latency. >>>> >>>>Establishing a similar control channel in the opposite direction would >>>>be fairly trivial. >>>> >>>>There are few, if any, middlebox problems with the above approach. >>>>However, there are certainly other problems, but no more insurmountable >>>>than all the problems that have already been discussed with taking the >>>>'easy' route of EDO: >>>>* A secure binding would have to be added to bind channel C to a secret >>>>known only to the originator of channel D, otherwise it would open up >>>>data channels to spoof control channel attacks. This binding could be >>>>built on a TCP-AO option in channel D. >>> >>>Yes, that's another problem. >> >>Fairly straightforward to solve using standard techniques. > >I think that warrants more than a claim. You need to explain how you >avoid false postives through NATs. Certainly. But I'm not going to do that now. I have no need for bigger TCP options in my day job (or my night job), so I would hope someone else would pick this up and specify it fully if they need it. I was just irked by your impossibility claim. I won't believe this dual SYN idea is useful myself until it's fully specified, implemented and tested. Bitter experience of trying to extend major protocols like IP has taught me that one little niggle can ruin years of work, even if it looked promising until the last moment. However, I still don't give up, or discourage others by burning time writing RFCs that claim it's impossible. >>>>* Channel C would need some way to refer to the segments of channel D >>>>that was robust against re-segmentation. >>> >>>Which means it won't work in the current Internet, because >>>resegmentation is also widespread (though evil, IMO). >> >>Well, resegmentation isn't usually a problem on a SYN anyway. >> >>We can't improve on the general pain caused by resegmentation. I was >>only talking about the delta pain that my strawman would suffer, where a >>resegmenting function sees data on my SYN and doesn't understand my >>strawman, so it won't patch up the damage in my strawman protocol that >>it would have patched up by altering sequence numbers in a regular >>single SYN with a payload. > >You're right, in the sense that SYN data would typically be >discarded anyway at the endpoint if it implemented SYN cookies. > >>I think this is a corner case. > >It is, but you raised it in a general sense; were you thinking of it >in terms of just SYNs or other segments? It was a general point that I figured might affect any scheme that enables TCP options that might want to refer to byte offsets, when those bytes are in a different packet. For the scheme that has developed over the course of this email thread, I don't think it's a concern now. >>>>* The main problem is that the two channels don't share fate;a control >>>>packet can be delayed relative to the point in the data stream at which >>>>it is attempting to exert control, possibly for a RTT if it is lost and >>>>has to be retransmitted. However, this is not insurmountable. The >>>>control protocol could include a mode to "synthesise shared fate", by >>>>making the data channel buffer data until an associated control segment >>>>had arrived. This would duplicate the latency impact of a loss or delay >>>>on either channel, but one can imagine mitigations that would consign >>>>this latency impact to corner cases. >>>>* It's a bit of a mess, but that comes with the territory when trying to >>>>fix legacy protocol problems. >>>>* The internal stack architecture seems to require a trombone back down >>>>into the kernel from user-space, but that is not insurmountable - a shim >>>>within the kernel on port 80 (for example) could redirect control >>>>channel data across to the "TCP control channel module" in the kernel, >>>>while passing non-control channel connections to user-space. >>>> >>>>2) Build on LOIC >>>>______________________ >>>>Long option with invalid checksum >>> >>>Won't work through current NATs, which won't recalculate the checksum >>>properly. >> >>I'm building on the general idea of using something invalid, not using >>the checksum idea specifically. > >Anything considered invalid by an endpoint might be checked by an >overzealous midbox. True. But in this case, the client can put something perfectly valid in the app-layer payload, because it can even RST the connection to stop the payload getting to the app. Theoretically, we could even encode the extended TCP options in HTML as the argument to an HTTP PUT, so that if an HTTP server did ever parse them, it might even display a prettily rendered list of extended TCP options :) >>>>At 18:53 22/05/2014, John Leslie wrote: >>>>> That's too big of a change to ask folks to believe it safe. >>>> >>>>When I read an idea, I don't take it as set in stone and just find a >>>>hole and dismiss it. I see it as a potential stepping stone to a >>>>solution and think about how it could be done better. In fact, Andrew >>>>Yourtchenko said that was the intention of his write-up of LOIC. >>>> >>>>I believe that an approach worth further thought would be a mixture of >>>>the control channel idea and the invalid checksum idea. I'm thinking of: >>>>* a pure control SYN (C) sent first, then a base SYN (D) sent >>>>back-to-back, both to the same port. >>> >>>Again, please don't assume back-to-back means anything. >> >>See above. >>Actually, even tho order isn'[t guaranteed, it is important to get them >>in the right order to optimise performance (much as TCP doesn't assume >>perfect order, but it goes smoothest with reasonable ordering). > >Right, but I want to emphasize that things emitted back-to-back >could end up being delivered days later (e.g., when a link goes >down, some routers just keep the queues there). The impact in those >cases needs to be considered. Considered, certainly. >>>>* SYN C would contain something invalid to cause a legacy TCP stack or >>>>legacy app to discard it (and hopefully less probability that a >>>>middlebox would), e.g. a payload that is invalid for the application >>>>protocol on the port. >>> >>>But so will a NAT, etc. >> >>No. You can design a payload that has headers that a NAT will ignore but >>an end-host will have to process. > >You can try, but if an end-host looks at it you can be sure that a >midbox will do the same - if not today, then soon. Agree in general. But see above re HTML & PUT. > > E.g. HTTP connection control headers >>newly defined for this protocol that would be ignored by NATs, without >>any other HTTP behaviour, so a legacy host does nothing at the app layer. > >Those are rewritten by "helpful" midboxes all the time, FWIW. Again, see HTML-PUT commment. >>>>* there would be additional TCP options in the payload of SYN C to be >>>>added to the TCP options that arrived separately on the base SYN >>>>* The control SYN could be bound crytographically to the base SYN (as >>>>already described). >>>>* It could use the shim-like control stack arangement described earlier. >>>> >>>>By focusing solely on extending the SYN, this would avoid the ongoing >>>>shared fate problems that a separate control channel suffers throughout >>>>the connection. There would still be shared fate problems with 2 SYNs >>>>(e.g. the two SYNs get re-ordered), but the protocol would have to be >>>>designed to be robust to that (naively, SYN D could include a new TCP >>>>option that told a new stack to wait a few ticks for a SYN C, but that >>>>would be vulnerable to meddleboxes). Not insurmountable. >>> >>>AFAICT, it is. >> >>Still? > >If it means halving the performance of legacy servers and delaying >legacy clients, yes. Not so. See above. Regards Bob >Joe ________________________________________________________________ Bob Briscoe, BT From nobody Fri May 30 10:13: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 790111A04E8 for ; Fri, 30 May 2014 10:13:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.252 X-Spam-Level: X-Spam-Status: No, score=-3.252 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651, 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 S9SsTZQ39-IB for ; Fri, 30 May 2014 10:13:36 -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 26E221A011D for ; Fri, 30 May 2014 10:13:36 -0700 (PDT) Received: from EVMHR02-UKBR.domain1.systemhost.net (193.113.108.41) by EVMHR04-UKBR.bt.com (10.216.161.36) with Microsoft SMTP Server (TLS) id 8.3.348.2; Fri, 30 May 2014 18:13:27 +0100 Received: from EPHR01-UKIP.domain1.systemhost.net (147.149.196.177) by EVMHR02-UKBR.domain1.systemhost.net (193.113.108.41) with Microsoft SMTP Server (TLS) id 8.3.348.2; Fri, 30 May 2014 18:13:29 +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, 30 May 2014 18:13:29 +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 s4UHDRJJ030638; Fri, 30 May 2014 18:13:27 +0100 Message-ID: <201405301713.s4UHDRJJ030638@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 30 May 2014 18:13:26 +0100 To: John Leslie From: Bob Briscoe In-Reply-To: <20140530141411.GE4765@cpaasch-mac> References: <201405221710.s4MHAY4S002037@bagheera.jungle.bt.co.uk> <537E3ACD.5000308@isi.edu> <537E48CE.8040704@mti-systems.com> <537E66A7.4080907@isi.edu> <201405231003.s4NA3PAB005137@bagheera.jungle.bt.co.uk> <537F7D91.10802@isi.edu> <201405281716.s4SHG29Y014642@bagheera.jungle.bt.co.uk> <53861D4F.60709@isi.edu> <201405300955.s4U9tAto028369@bagheera.jungle.bt.co.uk> <585d073725d54c45927872774a3f4bf1@UCL-MBX03.OASIS.UCLOUVAIN.BE> <20140530141411.GE4765@cpaasch-mac> 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/l7V8ZjgcRk4_AzndkIDdiLBz-68 Cc: "tcpm@ietf.org" , Joe Touch Subject: Re: [tcpm] New Version Notification for draft-touch-tcpm-tcp-edo-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: Fri, 30 May 2014 17:13:38 -0000 John, We needed to lose 7B and we've lost 8B. So (SACK + MPTCP + TCP-AO + widespread basic options, incl TCPtimestamp) do fit in a SYN, therefore the example in the draft is valid. However, as everyone has pointed out, jubilation may be short-lived. For instance, even now, people are working on a lower latency MPTCP that will need more option space. Thx. Bob At 15:14 30/05/2014, Christoph Paasch wrote: >On 30/05/14 - 13:50:44, John Leslie wrote: > > Bob Briscoe wrote: > > > > > > I was asking for an example of something useful that /can/ be > done with EDO. > > > > > > I'm sure you can come up with one. However, you have shown > > > conclusively that the example in the draft (SACK + MPTCP + TCP-AO), > > > when added to the widespread basic options, /cannot/ be done with > > > EDO, because it needs 7 more bytes of options than a SYN allows. > > > > The claim that MPTCP needs 20 bytes in the SYN is getting on my > > nerves... > > > > As I read RFC 6824, it seems pretty clear that the initial SYN calls > > for 12 bytes, not 20. It's the SYN-ACK that uses 20. Somebody please > > correct me if I'm reading this wrong. > >Indeed, it uses 12 bytes on both the SYN and the SYN/ACK. > >Only the third ACK carries 20 bytes. > > >Cheers, >Christoph ________________________________________________________________ Bob Briscoe, BT From nobody Fri May 30 10:32: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 8C9E81A6F97 for ; Fri, 30 May 2014 10:32:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] 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 igl6GjHxpepz for ; Fri, 30 May 2014 10:32:47 -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 6AAE11A0A19 for ; Fri, 30 May 2014 10:32:47 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id s4UHRjh5008165 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 30 May 2014 10:27:47 -0700 (PDT) Message-ID: <5388BF91.2020201@isi.edu> Date: Fri, 30 May 2014 10:27:45 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Bob Briscoe , John Leslie References: <201405221710.s4MHAY4S002037@bagheera.jungle.bt.co.uk> <537E3ACD.5000308@isi.edu> <537E48CE.8040704@mti-systems.com> <537E66A7.4080907@isi.edu> <201405231003.s4NA3PAB005137@bagheera.jungle.bt.co.uk> <537F7D91.10802@isi.edu> <201405281716.s4SHG29Y014642@bagheera.jungle.bt.co.uk> <53861D4F.60709@isi.edu> <201405300955.s4U9tAto028369@bagheera.jungle.bt.co.uk> <585d073725d54c45927872774a3f4bf1@UCL-MBX03.OASIS.UCLOUVAIN.BE> <20140530141411.GE4765@cpaasch-mac> <201405301713.s4UHDRJJ030638@bagheera.jungle.bt.co.uk> In-Reply-To: <201405301713.s4UHDRJJ030638@bagheera.jungle.bt.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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/JaL4iRXFhBJ8OXkzqqwEPZyO_KA Cc: "tcpm@ietf.org" Subject: Re: [tcpm] New Version Notification for draft-touch-tcpm-tcp-edo-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: Fri, 30 May 2014 17:32:48 -0000 I'll update the doc accordingly. I had also been thinking of SACK not being as limited in its use of space, nor MPTCP. Joe On 5/30/2014 10:13 AM, Bob Briscoe wrote: > John, > > We needed to lose 7B and we've lost 8B. > So (SACK + MPTCP + TCP-AO + widespread basic options, incl TCPtimestamp) > do fit in a SYN, therefore the example in the draft is valid. > > However, as everyone has pointed out, jubilation may be short-lived. For > instance, even now, people are working on a lower latency MPTCP that > will need more option space. > > Thx. > > > Bob > > > At 15:14 30/05/2014, Christoph Paasch wrote: >> On 30/05/14 - 13:50:44, John Leslie wrote: >> > Bob Briscoe wrote: >> > > >> > > I was asking for an example of something useful that /can/ be done >> with EDO. >> > > >> > > I'm sure you can come up with one. However, you have shown >> > > conclusively that the example in the draft (SACK + MPTCP + TCP-AO), >> > > when added to the widespread basic options, /cannot/ be done with >> > > EDO, because it needs 7 more bytes of options than a SYN allows. >> > >> > The claim that MPTCP needs 20 bytes in the SYN is getting on my >> > nerves... >> > >> > As I read RFC 6824, it seems pretty clear that the initial SYN calls >> > for 12 bytes, not 20. It's the SYN-ACK that uses 20. Somebody please >> > correct me if I'm reading this wrong. >> >> Indeed, it uses 12 bytes on both the SYN and the SYN/ACK. >> >> Only the third ACK carries 20 bytes. >> >> >> Cheers, >> Christoph > > ________________________________________________________________ > Bob Briscoe, BT From nobody Fri May 30 10:42: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 E05C01A6FB7 for ; Fri, 30 May 2014 10:42:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 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_MED=-2.3, 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 waXUnZIrIsHx for ; Fri, 30 May 2014 10:42:31 -0700 (PDT) Received: from smtp6.sgsi.ucl.ac.be (smtp.sgsi.ucl.ac.be [130.104.5.67]) by ietfa.amsl.com (Postfix) with ESMTP id 39AB71A6FB6 for ; Fri, 30 May 2014 10:42:31 -0700 (PDT) Received: from mbpobo.local (host-212-68-230-69.brutele.be [212.68.230.69]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: obonaventure@smtp6.sgsi.ucl.ac.be) by smtp6.sgsi.ucl.ac.be (Postfix) with ESMTPSA id 6DD88183444; Fri, 30 May 2014 19:42:22 +0200 (CEST) X-DKIM: Sendmail DKIM Filter v2.8.3 smtp6.sgsi.ucl.ac.be 6DD88183444 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1401471742; bh=VPrxm8iNIIO0vjrFdQoWhQLOlQHQArPTI2doyjDRxxY=; h=Message-ID:Date:From:Reply-To:MIME-Version:To:CC:Subject: References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=J3L/j7uuZAi5JmUyBQJp0k80BxQHfqINaLVqi6fE1x+OnhxJKgc7r0hAnS16z20o5 wBKGYxjKYOdUz/LqqVZ5ocVKyK+z88AHMEa1L+95NFhHpur8+nwvEZWMboBLJp7W1W n5VXkY6mLMADyxJTnD3XR43mV9reSDV+eDvnwGCo= Message-ID: <5388C2FE.9060105@uclouvain.be> Date: Fri, 30 May 2014 19:42:22 +0200 From: Olivier Bonaventure User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Bob Briscoe References: <20140425221257.12559.43206.idtracker@ietfa.amsl.com> <2586_1398464386_535ADF82_2586_915_1_535ADF56.9050106@isi.edu> <5363AF84.8090701@mti-systems.com> <5363B397.8090009@isi.edu> <655C07320163294895BBADA28372AF5D2CFE36@FR712WXCHMBA15.zeu.alcatel-lucent.com> <20140503122950.GM44329@verdi> <655C07320163294895BBADA28372AF5D2D009E@FR712WXCHMBA15.zeu.alcatel-lucent.com> <201405221710.s4MHAY4S002037@bagheera.jungle.bt.co.uk> In-Reply-To: <201405221710.s4MHAY4S002037@bagheera.jungle.bt.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.97.7-exp at smtp-6.sipr-dc.ucl.ac.be X-Virus-Status: Clean X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-MailScanner-ID: 6DD88183444.A009D X-SGSI-MailScanner: Found to be clean X-SGSI-From: olivier.bonaventure@uclouvain.be X-SGSI-Spam-Status: No Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/L7gMtGR9A-HuRlqe1s0pTD5RnV8 Cc: "tcpm@ietf.org" Subject: Re: [tcpm] New Version Notification for draft-touch-tcpm-tcp-edo-01.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Olivier.Bonaventure@uclouvain.be List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 May 2014 17:42:33 -0000 Bob, > > Returning to the question of adoption, we have to address the question > of why previous attempts to do this have failed. I don't believe it is > as simple as that they tried to include options on SYNs, so all we have > to do is avoid the SYN problem. ... > > 4) Finally, the EDO draft cites as if > it is just another solution. It's not. It's actually a very useful > survey of all the previous attempts to solve this problem, including a > useful enumeration of the problems that have to be surmounted. > > The arguments on this thread show that we don't agree on the problem > space. So, I suggest we adopt Anatha's draft, and as we develop it, we > agree on the problem we are trying to solve first. Boring, but > apparently necessary. I was offline this week and am now catching up the email thread. I agree that starting from this draft would be an excellent idea to document in an information draft the existing solutions and their advantages and drawbacks. With this documentation, we could then build another solution that works efficiently. Olivier From nobody Fri May 30 10:53:38 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 70BF11A0452 for ; Fri, 30 May 2014 10:53:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 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_MED=-2.3, 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 1Cb3yatCzjxQ for ; Fri, 30 May 2014 10:53:36 -0700 (PDT) Received: from smtp6.sgsi.ucl.ac.be (smtp.sgsi.ucl.ac.be [130.104.5.67]) by ietfa.amsl.com (Postfix) with ESMTP id 09BF21A036A for ; Fri, 30 May 2014 10:53:36 -0700 (PDT) Received: from mbpobo.local (host-212-68-230-69.brutele.be [212.68.230.69]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: obonaventure@smtp6.sgsi.ucl.ac.be) by smtp6.sgsi.ucl.ac.be (Postfix) with ESMTPSA id 411E91834B5; Fri, 30 May 2014 19:53:27 +0200 (CEST) X-DKIM: Sendmail DKIM Filter v2.8.3 smtp6.sgsi.ucl.ac.be 411E91834B5 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1401472407; bh=CixPznpyFDzREwJ0Fjg6+m2Wr3M+DYi/oKpwdPl5wPI=; h=Message-ID:Date:From:Reply-To:MIME-Version:To:CC:Subject: References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=fy42vtrfoC2WyPQAJqNbDeZ9GHD4K40pXqgvugmp9SFB9FMepvhjbb2XEkYRNi6TE 2fVh4f164NY2T3zk4nFiRIB7EKO8DIlrDFvzQ24+/rNgF0He9KvzfG9Iq2wi6pSdCg /cX8OvSF8SQNNMIG5u/uwngj98GCmT+B/GmThAyo= Message-ID: <5388C597.2030202@uclouvain.be> Date: Fri, 30 May 2014 19:53:27 +0200 From: Olivier Bonaventure User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Joe Touch , David Borman , Bob Briscoe References: <20140425221257.12559.43206.idtracker@ietfa.amsl.com> <2586_1398464386_535ADF82_2586_915_1_535ADF56.9050106@isi.edu> <5363AF84.8090701@mti-systems.com> <5363B397.8090009@isi.edu> <655C07320163294895BBADA28372AF5D2CFE36@FR712WXCHMBA15.zeu.alcatel-lucent.com> <20140503122950.GM44329@verdi> <655C07320163294895BBADA28372AF5D2D009E@FR712WXCHMBA15.zeu.alcatel-lucent.com> <201405221710.s4MHAY4S002037@bagheera.jungle.bt.co.uk> <537E3ACD.5000308@isi.edu> <1AD79820-22C1-4500-84D1-1383F264D68C@weston.borman.com> <201405231213.s4NCDa5P005525@bagheera.jungle.bt.co.uk> <6391C448-A917-4E66-9B73-CB840B193FD7@weston.borman.com> <537F7EE4.4080101@isi.edu> In-Reply-To: <537F7EE4.4080101@isi.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.97.7-exp at smtp-6.sipr-dc.ucl.ac.be X-Virus-Status: Clean X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-MailScanner-ID: 411E91834B5.AFF5B X-SGSI-MailScanner: Found to be clean X-SGSI-From: olivier.bonaventure@uclouvain.be X-SGSI-Spam-Status: No Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/jB8v4revNDR6yaa-B9wAzR1pwDQ Cc: "tcpm@ietf.org" Subject: Re: [tcpm] New Version Notification for draft-touch-tcpm-tcp-edo-01.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Olivier.Bonaventure@uclouvain.be List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 May 2014 17:53:37 -0000 David, Joe, Bob, >> What is impossible is to expand the option space in the initial SYN >> packet and maintain 100% backwards compatibility with the following >> restrictions: >> 1) No additional packets are sent, just the initial SYN >> 2) There is no a priori knowledge as to whether or not the remote >> host understands expanded option space. > > I would pose the conditions as follows: > > 1) is robust to packet loss, reordering, and alternate paths > any assumption of "back to back" packets isn't > > 2) does not negatively impact legacy hosts > e.g., dual-stack/multiple SYN approaches fail here when > a legacy system is trying to connect to an updated one > (which has to wait to see if the updated SYN will show) > > 3) succeeds through basic NAT/NAPTs > anything that uses a nonstandard checksum will fail > to support the extended space > > 4) addresses new connections to hosts not previously contacted > it's trivial to retain state across sequences of > connections, as per RFC 2140. Let me make two rough proposals that could be worth being explored or at least documented. 1. The TCP option space is limited, but not the IPv6 destination options in the IPv6 header. One possibility to extend the TCP option space, notably (but not only) in the SYN would be to place part of the TCP option inside an IPv6 destination option. Given that the IPv6 destination option is only limited by the IPv6 packet size, we are safe for the long term and the solution seems to be clean. This approach has two limitations : - It is a violation of the layering principle since the receiving host needs to provide the content of the IPv6 destination option to the TCP stack. - It only works with IPv6 and does not work with IPv4. In the short term, IPv4 support is mandatory, but in the long term IPv6 support is clearly more important. 2. TCP assumes that the client proposes the TCP extensions and the server selects the ones that it supports. In practice, measurements show that the TCP stack running on servers is usually upgraded after the stack running on clients. It might be interesting to allow the client to insert in the SYN a special option that indicates that it would accept new options proposed in the SYN+ACK (or perhaps later). These options proposed in the SYN+ACK would be confirmed in the third ACK. If one of these solutions does not seems completely crazy, I can write a more detailed proposal to see how it would work in practice Olivier From nobody Fri May 30 13:36: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 AC2301A6EE6 for ; Fri, 30 May 2014 13:36:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] 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 wBOG0X6wVaSN for ; Fri, 30 May 2014 13:36:39 -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 806D81A212D for ; Fri, 30 May 2014 13:36:37 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id s4UKYtK2028140 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 30 May 2014 13:34:55 -0700 (PDT) Message-ID: <5388EB6F.4010405@isi.edu> Date: Fri, 30 May 2014 13:34:55 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Bob Briscoe References: <20140425221257.12559.43206.idtracker@ietfa.amsl.com> <2586_1398464386_535ADF82_2586_915_1_535ADF56.9050106@isi.edu> <5363AF84.8090701@mti-systems.com> <5363B397.8090009@isi.edu> <655C07320163294895BBADA28372AF5D2CFE36@FR712WXCHMBA15.zeu.alcatel-lucent.com> <20140503122950.GM44329@verdi> <655C07320163294895BBADA28372AF5D2D009E@FR712WXCHMBA15.zeu.alcatel-lucent.com> <201405221710.s4MHAY4S002037@bagheera.jungle.bt.co.uk> <537E3ACD.5000308@isi.edu> <1AD79820-22C1-4500-84D1-1383F264D68C@weston.borman.com> <201405231213.s4NCDa5P005525@bagheera.jungle.bt.co.uk> <537F8202.4020907@isi.edu> <201405281715.s4SHFMm0014634@bagheera.jungle.bt.co.uk> <538623B9.2060209@isi.edu> <201405301642.s4UGgcvY030471@bagheera.jungle.bt.co.uk> In-Reply-To: <201405301642.s4UGgcvY030471@bagheera.jungle.bt.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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/TGI_LALLl5oRBNx-zkUJxOQolmw Cc: David Borman , "tcpm@ietf.org" Subject: Re: [tcpm] New Version Notification for draft-touch-tcpm-tcp-edo-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: Fri, 30 May 2014 20:36:41 -0000 Hi, Bob, Let's get back to the core, in a simpler fashion, so other can follow it. I stand by my "there's no way to extend the space in the initial SYN", but you've convinced me there *might* be a way to provide extended space that can occur during the first phase of the TWHS. I think the dual-SYN approach still isn't viable, but I've outlined an alternative below that's similar but doesn't have the same baggage, IMO. Again, I'm still concerned by what midboxes might do to this... What do others think?? Joe For quick review, here's what I understand: dso = dual-syn option dso-D = data dso-C = control conn_id = identifier to link the two SYNs together extra_opt = options that didn't fit in legacy SYN fit_opt = options that do fit in the legacy SYN new endpoint sends port A SYN + dso-D + conn_id + fit_opt port B SYN + dso-C + conn_id + extra_opt legacy endpoint sends back two connections: port A SYN-ACK + fit_opt port B SYN-ACK + ?? (it's interpretation of extra_opt) new endpoint responds: port A ACK (established) port B RST Notes about legacy servers: - they do twice the work on SYNs - they might keep twice the state (if not using cookies) - they might clean state if the RST is received, but that state might persist indefinitely (until the next connection, depending on timeouts, etc.) ----- new endpoint sends back one connection: port A SYN=ACK + dso-D + .... Notes: - can stall when dso-D SYN arrives before dso-C SYN, up to some limit - twice the work on SYNs (or more) Here's what I was assuming, though admittedly it's not documented (yet): - no significant impact on TCP connection rate for legacy servers - no significant impact on TCP connection rate for legacy clients - impact dominated by processing the extended option space for extended clients - impact dominated by processing the extended option space for extended servers - compatible with typical TCP processing optimizations, notably SYN cookies you did provide a potential way forward for these - capable of successfully traversing typical NATs Your approach has the following properties: - halves the server connection rate for updated servers from legacy clients when this option is in use - lowers (to some extent, if not halves) the client connection rate of updated clients to all servers when this option is in use - halves (roughly) the server rate for all servers when this option is in use It also: - doubles the number of SYNs in the network - susceptible to lack of fate-sharing problems, e.g., if the two SYNs experience different firewall configurations - reduces the space available for fit_opt due to the need for the conn_id even in the fall-back D-SYN, which means less option space in the SYNs for fall-back connections the conn_id which may need to be very large because it needs to be unique per source port and source IP address because that information is lost during NAT translation - requires the ISNs to be related (see RFC6528 - if there's a rule to generate it, there will be code to validate that rule, and eventually a BCP to encourage that validation - typically from the same RFC author) I agree that you have proposed potentially viable ways to deal with the SYN cookie, and that RST state is not an issue. However, there are too many problems with this, IMO, to call it viable. >> Ultimately, it's roughly equivalent to "try both and shut down the one >> you don't want" -- the dual-stack approach we already know about. > > That's a bit of a wild dismissal of a scheme that so far seems to have > pretty useful properties. I said it was roughly equivalent - if you call that "wild dismissal", so be it. Here's another trick that might clean up the above a little: aso - after SYN option FBP - front bumper packet (best I could do on names today) a packet with a sequence number BEFORE the ISN of the SYN new endpoint sends: SYN + aso + fix_opt FBP + aso + extra_opt + seqno-outsidewindow legacy endpoint sends back one connections: SYN-ACK + fix_opt if seg arrives before SYN, legacy will send a RST - which the new endpoint can ignore if seg arrives after SYN, it'll be discarded as out of window ---- new endpoint sends back one connection: SYN-ACK + options + .... a) if FBP arrives before SYN, it will generate a RST - which the new endpoint will ignore b) if FPB arrives with the SYN, they can be processed together the SYN-ACK can include responses to the extra_opts in addition to the fix_opts, and says "FBP received" c) if FPB arrives after the SYN: SYN-ACK proceeds, but sends back "wait for option response". at this point, the source re-sends FBP until an ACK is received that indicates "FBP received", or times-out as with any connection that doesn't finish TWHS I'm still thinking as to whether the ACK number might indicate whether FBP has been received, e.g., send back ACK = ISN -1 until FBP, at which point it sends back ISN. The connection proceeds when ISN is ACK'd. This is cleaner as follows: - no need for conn_id coordination - no need for conn_id to consume option space for fall-back - avoids double-load for legacy servers - no problem with fate-sharing - traverses a NAT just fine Upgraded servers still need to wait for the 'seg', but they could get that retransmitted if necessary. It causes additional processing for legacy endpoints, but not necessarily in a way that decreases the rate because it's not trying to start a second connection; the RSTs sent back are lightweight, and the additional ACK. ---- From nobody Fri May 30 14:11: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 00A491A6F9F for ; Fri, 30 May 2014 14:11:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] 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 tDd9DU7ZcGtP for ; Fri, 30 May 2014 14:11:41 -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 05B8D1A0A6E for ; Fri, 30 May 2014 14:11:41 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id s4ULB3h8008732 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 30 May 2014 14:11:03 -0700 (PDT) Message-ID: <5388F3E7.9040201@isi.edu> Date: Fri, 30 May 2014 14:11:03 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Olivier.Bonaventure@uclouvain.be, David Borman , Bob Briscoe References: <20140425221257.12559.43206.idtracker@ietfa.amsl.com> <2586_1398464386_535ADF82_2586_915_1_535ADF56.9050106@isi.edu> <5363AF84.8090701@mti-systems.com> <5363B397.8090009@isi.edu> <655C07320163294895BBADA28372AF5D2CFE36@FR712WXCHMBA15.zeu.alcatel-lucent.com> <20140503122950.GM44329@verdi> <655C07320163294895BBADA28372AF5D2D009E@FR712WXCHMBA15.zeu.alcatel-lucent.com> <201405221710.s4MHAY4S002037@bagheera.jungle.bt.co.uk> <537E3ACD.5000308@isi.edu> <1AD79820-22C1-4500-84D1-1383F264D68C@weston.borman.com> <201405231213.s4NCDa5P005525@bagheera.jungle.bt.co.uk> <6391C448-A917-4E66-9B73-CB840B193FD7@weston.borman.com> <537F7EE4.4080101@isi.edu> <5388C597.2030202@uclouvain.be> In-Reply-To: <5388C597.2030202@uclouvain.be> Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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/C_2-O40zrvd3NqSvRLkHzfXkm2E Cc: "tcpm@ietf.org" Subject: Re: [tcpm] New Version Notification for draft-touch-tcpm-tcp-edo-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: Fri, 30 May 2014 21:11:49 -0000 Hi, Oliver, On 5/30/2014 10:53 AM, Olivier Bonaventure wrote: ... > Let me make two rough proposals that could be worth being explored or at > least documented. > > 1. The TCP option space is limited, but not the IPv6 destination options > in the IPv6 header. IP option space would not be protected by TCP-AO, and likely not by whatever the TCPUSEC WG creates (e.g.,my proposal is here: http://tools.ietf.org/html/draft-touch-tcp-ao-encrypt-01) Additionally, DPI, NAT processing, etc. are all impacted by IPv6 options, so they're generally discouraged AFAIR. Joe From nobody Fri May 30 14:12: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 9B2031A01E5 for ; Fri, 30 May 2014 14:12:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] 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 oqd7VpCXz0mO for ; Fri, 30 May 2014 14:12:13 -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 B97D61A8842 for ; Fri, 30 May 2014 14:12:12 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id s4ULBaBu009174 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 30 May 2014 14:11:36 -0700 (PDT) Message-ID: <5388F407.6070508@isi.edu> Date: Fri, 30 May 2014 14:11:35 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Bob Briscoe References: <20140425221257.12559.43206.idtracker@ietfa.amsl.com> <2586_1398464386_535ADF82_2586_915_1_535ADF56.9050106@isi.edu> <5363AF84.8090701@mti-systems.com> <5363B397.8090009@isi.edu> <655C07320163294895BBADA28372AF5D2CFE36@FR712WXCHMBA15.zeu.alcatel-lucent.com> <20140503122950.GM44329@verdi> <655C07320163294895BBADA28372AF5D2D009E@FR712WXCHMBA15.zeu.alcatel-lucent.com> <201405221710.s4MHAY4S002037@bagheera.jungle.bt.co.uk> <537E3ACD.5000308@isi.edu> <537E48CE.8040704@mti-systems.com> <537E66A7.4080907@isi.edu> <201405231003.s4NA3PAB005137@bagheera.jungle.bt.co.uk> <537F7D91.10802@isi.edu> <201405281716.s4SHG29Y014642@bagheera.jungle.bt.co.uk> <53861D4F.60709@isi.edu> <201405300955.s4U9tAto028369@bagheera.jungle.bt.co.uk> In-Reply-To: <201405300955.s4U9tAto028369@bagheera.jungle.bt.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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/eO3-OaupTrwlc_8gbapmFHhjU4E Cc: "tcpm@ietf.org" Subject: Re: [tcpm] New Version Notification for draft-touch-tcpm-tcp-edo-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: Fri, 30 May 2014 21:12:14 -0000 On 5/30/2014 2:55 AM, Bob Briscoe wrote: > Joe, > > I was asking for an example of something useful that /can/ be done with > EDO. The obvious one is larger amounts of SACK feedback and space for MPTCP information. Joe From nobody Fri May 30 17:46: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 BA5A01A043C for ; Fri, 30 May 2014 17:46:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] 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 qmOq7qSY4Hi8 for ; Fri, 30 May 2014 17:46:06 -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 148511A030D for ; Fri, 30 May 2014 17:46:06 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id s4V0jmB3000524 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 30 May 2014 17:45:48 -0700 (PDT) Message-ID: <5389263C.8010202@isi.edu> Date: Fri, 30 May 2014 17:45:48 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Bob Briscoe References: <20140425221257.12559.43206.idtracker@ietfa.amsl.com> <2586_1398464386_535ADF82_2586_915_1_535ADF56.9050106@isi.edu> <5363AF84.8090701@mti-systems.com> <5363B397.8090009@isi.edu> <655C07320163294895BBADA28372AF5D2CFE36@FR712WXCHMBA15.zeu.alcatel-lucent.com> <20140503122950.GM44329@verdi> <655C07320163294895BBADA28372AF5D2D009E@FR712WXCHMBA15.zeu.alcatel-lucent.com> <201405221710.s4MHAY4S002037@bagheera.jungle.bt.co.uk> <537E3ACD.5000308@isi.edu> <1AD79820-22C1-4500-84D1-1383F264D68C@weston.borman.com> <201405231213.s4NCDa5P005525@bagheera.jungle.bt.co.uk> <537F8202.4020907@isi.edu> <201405281715.s4SHFMm0014634@bagheera.jungle.bt.co.uk> <538623B9.2060209@isi.edu> <201405301642.s4UGgcvY030471@bagheera.jungle.bt.co.uk> <5388EB6F.4010405@isi.edu> In-Reply-To: <5388EB6F.4010405@isi.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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/N3KdrroN1jCU4ua9PUlRCOEsIeA Cc: David Borman , "tcpm@ietf.org" Subject: Re: [tcpm] New Version Notification for draft-touch-tcpm-tcp-edo-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: Sat, 31 May 2014 00:46:07 -0000 Hi, all, Some additional information below about "another trick" I proposed, inspired by Bob's dual-SYN mechanism, courtesy a few long discussions today with Ted Faber. I'll be glad to offer this as a potential solution in the doc. Joe On 5/30/2014 1:34 PM, Joe Touch wrote: ... > Here's another trick that might clean up the above a little: FWIW, I had explained it below as being based on sending out-of-window data; Ted pointed out that I had been assuming that the FBP ACK bit wasn't set - which means the sequence number might be more usefully matched to that of the SYN. See below... > aso - after SYN option length = 2 (just a flag) length = 3 (or 4) indicating the length of the FBP expected > FBP - front bumper packet (best I could do on names today) > a packet ISN = same as the associated SYN ACK = cleared (i.e., a data packet NOT part of synchronized connection - see why that's useful below) > new endpoint sends: > > SYN + aso + fix_opt > FBP + aso + extra_opt extra_opt in the data field total length < min MTU (576 for IPv4, 1280 for IPv6) again ACK bit is zero > legacy endpoint sends back one connections: > SYN-ACK + fix_opt > > if seg arrives before SYN, it is silently dropped, because the ACK bit is clear (this is explicit in RFC793) > if seg arrives after SYN, it is silently dropped, because the ACK bit is clear (this is also explicit in RFC793) > ---- > > new endpoint sends back one connection: > > SYN-ACK + options + .... > > a) if FBP arrives before SYN, it can be silently dropped, but it's probably useful for new endpoints to hold onto these (without action) for a while; they can be silently discarded if there are too many (which will just result in a retransmission and an extra RTT) > b) if FPB arrives with the SYN, they can be > processed together > > the SYN-ACK can include responses to > the extra_opts in addition to the > fix_opts, and says "FBP received" > > c) if FPB arrives after the SYN: > > SYN-ACK proceeds, but sends > back "wait for option response". > > at this point, the source re-sends FBP > until an ACK is received that indicates > "FBP received", or times-out as with > any connection that doesn't finish TWHS > > I'm still thinking as to whether the ACK number > might indicate whether FBP has been received, There are a few ways to handle this, but IMO the best is to have: SYN-ACK aso with length=2 means "waiting for FBP" SYN-ACK aso with length=3 (or 4) could mean "got the FBP", or might even indicate how many bytes the FBP extension contained Note - the SYN-ACK and all subsequent segments can assume that aso == edo, i.e., they can use the same EDO as spec'd in version 01 of this draft. > This is cleaner as follows: > > - no need for conn_id coordination > > - no need for conn_id to consume option space for fall-back > > - avoids double-load for legacy servers > > - no problem with fate-sharing > > - traverses a NAT just fine > > Upgraded servers still need to wait for the 'seg', but they could get > that retransmitted if necessary. And there's a small amount of additional processing to discard the FBP at legacy endpoints, but silently discarding one packet per connection doesn't seem like a huge effort to me. Note - there's no special RST processing, based on Ted's observation about "data without ACK" being considered "data sent in the unsynchronzed state" -- something legacy TCP explicitly silently discards. ----- From nobody Fri May 30 17:58: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 DB47D1A0463 for ; Fri, 30 May 2014 17:58:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] 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 ew97qY6dg43j for ; Fri, 30 May 2014 17:58:50 -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 989FB1A030D for ; Fri, 30 May 2014 17:58:50 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id s4V0w9rm003305 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 30 May 2014 17:58:09 -0700 (PDT) Message-ID: <53892921.2040301@isi.edu> Date: Fri, 30 May 2014 17:58:09 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Yoshifumi Nishida References: <20140425221257.12559.43206.idtracker@ietfa.amsl.com> <20140503122950.GM44329@verdi> <655C07320163294895BBADA28372AF5D2D009E@FR712WXCHMBA15.zeu.alcatel-lucent.com> <201405221710.s4MHAY4S002037@bagheera.jungle.bt.co.uk> <537E3ACD.5000308@isi.edu> <537E48CE.8040704@mti-systems.com> <537E66A7.4080907@isi.edu> <201405231003.s4NA3PAB005137@bagheera.jungle.bt.co.uk> <537F7D91.10802@isi.edu> <655C07320163294895BBADA28372AF5D305E00@FR712WXCHMBA15.zeu.alcatel-lucent.com> <012C3117EDDB3C4781FD802A8C27DD4F6F3DD808@SACEXCMBX06-PRD.hq.netapp.com> <655C07320163294895BBADA28372AF5D309C5D@FR712WXCHMBA15.zeu.alcatel-lucent.com> <012C3117EDDB3C4781FD802A8C27DD4F6F3E09CF@SACEXCMBX06-PRD.hq.netapp.com> <655C07320163294895BBADA28372AF5D309CC7@FR712WXCHMBA15.zeu.alcatel-lucent.com> <5384EFC3.50803@isi.edu> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed 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/_OLuQQ1VXgO_dAvMe5s4y_AhpXQ Cc: "tcpm@ietf.org" Subject: Re: [tcpm] timestamp options (was Re: New Version Notification for draft-touch-tcpm-tcp-edo-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: Sat, 31 May 2014 00:58:53 -0000 On 5/27/2014 11:06 PM, Yoshifumi Nishida wrote: > Hi Joe, > > I'm wondering if you presume that using the existing code point for late > negotiation. I had. > Suppose If we use new code point, do we still have problems you > mentioned below? It depends: - I don't think it matters vs. using the existing codepoint with a different length (e.g., as a flag in the SYN); they are equivalent in being uniquely identifiable. - I don't like the idea of setting new TCP flags or changing the meaning of flags in the middle of a connection. That undermines the notion of a connection IMO. To do so, the source would have to keep track of the last byte of the segment in which the change occurs, and wait for a confirmation in the ACK of that byte; ditto for the other end. They'd need to resend things if lost *with the same flags* to indicate the change. I.e., you'd need to implement a new TWHS per option that changes state. That's a mess. And I don't even want to think about what happens when you have multiple options that change state at the same time. IMO, it's not worth the trouble. Joe > > Thanks, > -- > Yoshi > > On Tue, May 27, 2014 at 1:04 PM, Joe Touch > wrote: > > Hi, all, > > Late negotiation has too many problems, as have been repeatedly > raised on this list: > > - prevents use of the timestamp to help address PAWS for > the initial SYN > > - a new connection that either avoids TS in SYN or > uses just "use TS" (two-byte) flag can't know when > to engage the timestamp and what initial value to use > > Joe > > > On 5/27/2014 11:36 AM, Yoshifumi Nishida wrote: > > Hi folks, > > I've submitted a proposal for this a while ago: > http://tools.ietf.org/html/__draft-nishida-tcpm-apaws-00 > > Although it's expired now, I will submit a new version within a > couple > of weeks or so. > The late negotiation is also discussed in the draft. > As it will change the semantics of TS, it presumes to use new > code point > (or use timestamp field in SYN). But, I'm happy to discuss on > this point. > > One tricky thing for RFC1323 is that it uses TS for two purposes: > timestamping and PAWS and one purpose of the draft is to > separate them. > I appreciate any feedback on the draft. > > Thanks, > -- > Yoshi > > On Tue, May 27, 2014 at 5:12 AM, Scharf, Michael (Michael) > > >> wrote: > > > Well, if it's just for Timestamps, just use an "invalid" > length > of 2 as > > a "Late TS permitted". > > > > Maintaining the same option value and this would be > rather straight > > forward. > > Interesting proposal. But actually we are not really short > of option > numbers. If we get e.g. 8 bytes in a significant number of SYNs > (which is our real bottleneck), I think we could also spend > a new > option codepoint. > > > Personally, I'd like to combine this with a change in > semantics, if > > SACK is negotiated on the same session as well, to allow > more > efficient > > loss recovery (lost retransmission detection during a > loss recovery > > episode). I should have a unpublished draft sitting > around here about > > that aspect. > > A change in semantics would also be a reason for a new > codepoint, imho. > > Michael > > > > The TS option handling seems to be rather generous by > middleboxes, in > > general. > > > > Richard Scheffenegger > > > > > -----Original Message----- > > > From: tcpm [mailto:tcpm-bounces@ietf.org > > >__] On Behalf Of Scharf, > > Michael > > > (Michael) > > > Sent: Dienstag, 27. Mai 2014 13:49 > > > To: Scheffenegger, Richard; Eggert, Lars; Joe Touch > > > Cc: tcpm@ietf.org > > > > > Subject: Re: [tcpm] timestamp options (was Re: New Version > > Notification > > > for draft-touch-tcpm-tcp-edo-01.__txt) > > > > > > > For late TS, we would still need at least 2 Bytes during > > > > / to allow that capability. > > > > > > > > However, as the useful values of Window Scale only cover > 0..14 [1], > > > > one approach to save SYN option space would be to > negotiate > up to 4 > > > > binary > > > > (on/off) plus WS in a new single 3-byte option. > > > > > > I might be wrong, but I've thought so far that > "replacing" the > window > > > scale option would be pretty difficult. We already had > reports of > > > middleboxes that parse this option because they try to > understand > > rwnd (or > > > they do not parse the option even if they should, or > they have > > entirely > > > broken logic to mess up TCP...). I think one example > are firewalls > > that > > > try to detect whether segments are in-window. Another > example could > > be > > > PEPs that try to tune rwnd (if they still exist in the > wild). > > > > > > My understanding so far was that a solution only for > timestamps > would > > be > > > the most low-hanging fruit. > > > > > > Michael > > > > > > _________________________________________________ > > > 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 > > > > From nobody Fri May 30 18:10:23 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 E43301A06D6 for ; Fri, 30 May 2014 18:10:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] 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 dHQpkPa5dmMV for ; Fri, 30 May 2014 18:10:05 -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 1D7F71A06C3 for ; Fri, 30 May 2014 18:09:10 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id s4V17TLZ005532 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 30 May 2014 18:07:29 -0700 (PDT) Message-ID: <53892B51.1000003@isi.edu> Date: Fri, 30 May 2014 18:07:29 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: "Scheffenegger, Richard" , Yoshifumi Nishida , "Scharf, Michael (Michael)" References: <20140425221257.12559.43206.idtracker@ietfa.amsl.com> <655C07320163294895BBADA28372AF5D2D009E@FR712WXCHMBA15.zeu.alcatel-lucent.com> <201405221710.s4MHAY4S002037@bagheera.jungle.bt.co.uk> <537E3ACD.5000308@isi.edu> <537E48CE.8040704@mti-systems.com> <537E66A7.4080907@isi.edu> <201405231003.s4NA3PAB005137@bagheera.jungle.bt.co.uk> <537F7D91.10802@isi.edu> <655C07320163294895BBADA28372AF5D305E00@FR712WXCHMBA15.zeu.alcatel-lucent.com> <012C3117EDDB3C4781FD802A8C27DD4F6F3DD808@SACEXCMBX06-PRD.hq.netapp.com> <655C07320163294895BBADA28372AF5D309C5D@FR712WXCHMBA15.zeu.alcatel-lucent.com> <012C3117EDDB3C4781FD802A8C27DD4F6F3E09CF@SACEXCMBX06-PRD.hq.netapp.com> <655C07320163294895BBADA28372AF5D309CC7@FR712WXCHMBA15.zeu.alcatel-lucent.com> <5384EFC3.50803@isi.edu> <012C3117EDDB3C4781FD802A8C27DD4F6F4B7BB9@SACEXCMBX02-PRD.hq.netapp.com> In-Reply-To: <012C3117EDDB3C4781FD802A8C27DD4F6F4B7BB9@SACEXCMBX02-PRD.hq.netapp.com> Content-Type: text/plain; charset=UTF-8; format=flowed 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/dHhc5nzLUwgtgeo8O388du14Xgs Cc: "tcpm@ietf.org" Subject: Re: [tcpm] timestamp options (was Re: New Version Notification for draft-touch-tcpm-tcp-edo-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: Sat, 31 May 2014 01:10:13 -0000 On 5/28/2014 1:17 AM, Scheffenegger, Richard wrote: > Hi Joe, > >> Late negotiation has too many problems, as have been repeatedly raised on >> this list: >> >> - prevents use of the timestamp to help address PAWS for >> the initial SYN > > This one is genuine. However, given the prevalence of non-TS TCP > sessions and no wide-spread havoc caused by NOT having PAWS on the SYN, > it appears to me that the impact is manageable. (Of course it would be > nicer to have PAWS on SYN, but as long as SYN option space is limited...) I don't know the stats, but I'd prefer if initial connections were PAWS-protected. >> - a new connection that either avoids TS in SYN or >> uses just "use TS" (two-byte) flag can't know when >> to engage the timestamp and what initial value to use > > Well, as this would be a new mechanism, there should be some broad > guidance given; I would assume that the latest onset - if late TS is > negotiated for - would be when either direction has sent at most 2^31 - > (2^16 << Window.scale) bytes; and a receiver that sees the full TS must > then start to reflect TS as usual, independent of its own relative > offset into the session. And never relinquish from sending TS even when > some packets - ie. retransmissions, or due to middleboxes on a changed > path - not contain a TS from the other side. I had thought of a similar mechanism, e.g., where there would be an extended sequence number (ESN), and the upper bits would be assumed zero until actually needed. The advantage to that would be: ESN flag would occur in all segments length = 2 until needed length can increase as additional bytes/words are needed i.e., the meaning and use of the flag would never change; it would be synchronized at the start in both directions. It would just be compressed until actually needed. If you have a recent connection that already wrapped, you might start with ESN of length = 4 rather than length = 2 (0 in both directions), so you can sync non-zero ESNs. The only benefit would be that this is a lot shorter than timestamps - i.e., it'd be 4 rather than 10 bytes. (is this "Extended Sequence Number" option worth explaining in detail, e.g., in a separate draft?) --- Doing real TS's later in the connection requires a new sort of synchronization in the middle of the connection - which, as I noted in my other post, seems to require a TWHS mechanism, and I think that's too cumbersome. > As for the semantic change, I propose that when the session has SACK > enabled as well as late TS, then the TS should reflect the TS of the > segment triggering the ACK (we can discuss what should happen during > in-sequence delayed ACK processing though; the relevant aspect for me is > during loss - SACK recovery - to not mask the timestamps of > retransmitted packets as per 1323bis; For legacy RTTM processing, the > presence of a SACK option is indicative enough to NOT do normal RTTM > processing - although a sender could choose to do so particularly for > the loss recovery episodes. Having the (unique) Timestamp/SACK block > combinations during loss recovery would allow more efficient, faster and > also packet conserving recovery of lost retransmissions - unlike the > current method of last resort, RTO. Perhaps, but I don't see this paragraph as being related to late TS. Joe From nobody Fri May 30 18:46:23 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 581251A0671 for ; Fri, 30 May 2014 18:46:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] 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 JdTC7lbM5BbH for ; Fri, 30 May 2014 18:46:20 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 045D11A02BE for ; Fri, 30 May 2014 18:46:20 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id 07EC0C94BF; Fri, 30 May 2014 21:46:12 -0400 (EDT) Date: Fri, 30 May 2014 21:46:12 -0400 From: John Leslie To: Joe Touch Message-ID: <20140531014612.GF23373@verdi> References: <201405221710.s4MHAY4S002037@bagheera.jungle.bt.co.uk> <537E3ACD.5000308@isi.edu> <1AD79820-22C1-4500-84D1-1383F264D68C@weston.borman.com> <201405231213.s4NCDa5P005525@bagheera.jungle.bt.co.uk> <537F8202.4020907@isi.edu> <201405281715.s4SHFMm0014634@bagheera.jungle.bt.co.uk> <538623B9.2060209@isi.edu> <201405301642.s4UGgcvY030471@bagheera.jungle.bt.co.uk> <5388EB6F.4010405@isi.edu> <5389263C.8010202@isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5389263C.8010202@isi.edu> User-Agent: Mutt/1.4.1i Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/QtZlSjSTagXMMCUKeHL-n05IyGo Cc: "tcpm@ietf.org" Subject: Re: [tcpm] New Version Notification for draft-touch-tcpm-tcp-edo-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: Sat, 31 May 2014 01:46:22 -0000 Joe Touch wrote: > > Some additional information below about "another trick" I proposed, > inspired by Bob's dual-SYN mechanism, courtesy a few long discussions > today with Ted Faber. This _is- as interesting idea... > I'll be glad to offer this as a potential solution in the doc. I'd _much_ rather this be detailed in a separate document. The edo proposal is reasonably easy to understand, while this contains multiple layers of complexity. I _don't_ claim to understand it all -- if we try to publish this in an RFC, a _lot_ of work will be needed to clarify everything... > On 5/30/2014 1:34 PM, Joe Touch wrote: > ... >> Here's another trick that might clean up the above a little: > > FWIW, I had explained it below as being based on sending out-of-window > data; Ted pointed out that I had been assuming that the FBP ACK bit > wasn't set - which means the sequence number might be more usefully > matched to that of the SYN. I see you now give the "second" packet the same sequence number. I feel a need to describe the FBP more exactly. I'm guessing it's the same port pair (but I very much dislike guessing!). Obviously it's the same IP-address pair (but can we really depend upon middleboxes to translate both packets the same?). I won't venture a guess as to whether it has the SYN bit set (but thanks for saying the ACK bit is clear). Et cetera... > See below... > >> aso - after SYN option This is an option within the Options field of the first SYN, right? > length = 2 (just a flag) > length = 3 (or 4) indicating the length of the > FBP expected What does length==2 tell us about the FBP? >> FBP - front bumper packet (best I could do on names today) >> a packet > ISN = same as the associated SYN > ACK = cleared (i.e., a data packet NOT part of > synchronized connection - see why that's useful below) Does this have SYN set? How does the sender of the FBP learn what the receiver of the FBP took it to mean? (Assuming, of course, it was received at all...) >> new endpoint sends: What's a "new endpoint"? >> SYN + aso + fix_opt >> FBP + aso + extra_opt > > extra_opt in the data field > total length < min MTU (576 for IPv4, 1280 for IPv6) > again ACK bit is zero I get very nervous about using the data field before the handshake is complete. >> legacy endpoint sends back one connections: >> SYN-ACK + fix_opt Presumably the legacy endpoint ignores the FBP... but what happens if only the FBP arrives (the initial SYN being lost or mangled by a middlebox)? >> if seg arrives before SYN, Am I supposed to assume "seg" here means FBP? > it is silently dropped, because > the ACK bit is clear (this is > explicit in RFC793) > > > if seg arrives after SYN, > > it is silently dropped, because > the ACK bit is clear (this is also > explicit in RFC793) >> ---- >> >> new endpoint sends back one connection: >> >> SYN-ACK + options + .... >> >> a) if FBP arrives before SYN, > > it can be silently dropped, but > it's probably useful for new endpoints > to hold onto these (without action) > for a while; they can be silently > discarded if there are too many > (which will just result in a > retransmission and an extra RTT) Your hands are waving... >> b) if FPB arrives with the SYN, they can be >> processed together >> >> the SYN-ACK can include responses to >> the extra_opts in addition to the >> fix_opts, and says "FBP received" How would it say "FBP received"? >> c) if FPB arrives after the SYN: >> >> SYN-ACK proceeds, but sends >> back "wait for option response". How would it send that? >> at this point, the source re-sends FBP >> until an ACK is received that indicates >> "FBP received", or times-out as with >> any connection that doesn't finish TWHS This sounds like the timeout wouldn't be rare -- a middlebox might pretty automatically drop the FBP, depending... >> I'm still thinking as to whether the ACK number >> might indicate whether FBP has been received, That sounds strange... > There are a few ways to handle this, but IMO the best is to have: > > SYN-ACK aso with length=2 means "waiting for FBP" > > SYN-ACK aso with length=3 (or 4) could mean > "got the FBP", or might even indicate how > many bytes the FBP extension contained That's limiting... > Note - the SYN-ACK and all subsequent segments can assume that aso == > edo, i.e., they can use the same EDO as spec'd in version 01 of this draft. Please! No! (Option numbers aren't that scarce.) -- John Leslie From nobody Fri May 30 20:59: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 0B9ED1A06DA for ; Fri, 30 May 2014 20:59:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] 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 RW9Y-h-e7r2M for ; Fri, 30 May 2014 20:59:18 -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 15B591A031B for ; Fri, 30 May 2014 20:59:18 -0700 (PDT) Received: from [192.168.1.93] (pool-71-105-87-112.lsanca.dsl-w.verizon.net [71.105.87.112]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id s4V3wpkU013613 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 30 May 2014 20:58:55 -0700 (PDT) Message-ID: <5389537C.20104@isi.edu> Date: Fri, 30 May 2014 20:58:52 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: John Leslie References: <201405221710.s4MHAY4S002037@bagheera.jungle.bt.co.uk> <537E3ACD.5000308@isi.edu> <1AD79820-22C1-4500-84D1-1383F264D68C@weston.borman.com> <201405231213.s4NCDa5P005525@bagheera.jungle.bt.co.uk> <537F8202.4020907@isi.edu> <201405281715.s4SHFMm0014634@bagheera.jungle.bt.co.uk> <538623B9.2060209@isi.edu> <201405301642.s4UGgcvY030471@bagheera.jungle.bt.co.uk> <5388EB6F.4010405@isi.edu> <5389263C.8010202@isi.edu> <20140531014612.GF23373@verdi> In-Reply-To: <20140531014612.GF23373@verdi> Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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/uiyq6uzhohQh4Ben12EY8uKf4JQ Cc: "tcpm@ietf.org" Subject: Re: [tcpm] New Version Notification for draft-touch-tcpm-tcp-edo-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: Sat, 31 May 2014 03:59:21 -0000 On 5/30/2014 6:46 PM, John Leslie wrote: > Joe Touch wrote: >> >> Some additional information below about "another trick" I proposed, >> inspired by Bob's dual-SYN mechanism, courtesy a few long discussions >> today with Ted Faber. > > This _is- as interesting idea... > >> I'll be glad to offer this as a potential solution in the doc. > > I'd _much_ rather this be detailed in a separate document. The edo > proposal is reasonably easy to understand, while this contains multiple > layers of complexity. > > I _don't_ claim to understand it all -- if we try to publish this > in an RFC, a _lot_ of work will be needed to clarify everything... Sure... >> On 5/30/2014 1:34 PM, Joe Touch wrote: >> ... >>> Here's another trick that might clean up the above a little: >> >> FWIW, I had explained it below as being based on sending out-of-window >> data; Ted pointed out that I had been assuming that the FBP ACK bit >> wasn't set - which means the sequence number might be more usefully >> matched to that of the SYN. > > I see you now give the "second" packet the same sequence number. Yes. > I feel a need to describe the FBP more exactly. Of course. > I'm guessing it's the > same port pair (but I very much dislike guessing!). Oh, yes - that's the way it ensures fate-sharing with the SYN. > Obviously it's > the same IP-address pair Yes. > (but can we really depend upon middleboxes > to translate both packets the same?). If the FBP comes after the SYN, yes. If not, the FBP will be dropped, and retransmitted when the SYN-ACK indicates the FBP hasn't been received (for upgraded servers). > I won't venture a guess as to > whether it has the SYN bit set (but thanks for saying the ACK bit > is clear). Et cetera... It can't have the SYN bit - that would be two SYNs to the same place, and if they have different options that'd be confusing for legacy servers. If they had the same options, there'd be no increase in space - it's not possible to use the data field of a SYN for options because legacy hosts will interpret that as user data. >> See below... >> >>> aso - after SYN option > > This is an option within the Options field of the first SYN, right? > >> length = 2 (just a flag) >> length = 3 (or 4) indicating the length of the >> FBP expected > > What does length==2 tell us about the FBP? Here's more specifically what I was thinking: Length = 2 (1 byte), Kind = fpb-option-codepoint (1 byte) or Length = 3, Kind = fbp-option-codepoint, fbp-length (1 byte) Length == 4 just means a longer fbp-length field, or maybe it means: Length, Kind, Flags, FBP-length (you'll see below where the flags might come in) Length == 2 just means there's no fbp-length field. That could mean that the length of the FBP should be determined from the FBP packet itself (using fbp-length operates as a double-check that the FBP packet matches); alternately, it could mean that there's no FBP - i.e., that this is just the EDO that extends non-SYN packets. Alternately, we could use different option codepoints for FBP and EDO, in which case the FBP option just means "FBP packet should be expected". >>> FBP - front bumper packet (best I could do on names today) >>> a packet >> ISN = same as the associated SYN >> ACK = cleared (i.e., a data packet NOT part of >> synchronized connection - see why that's useful below) > > Does this have SYN set? No. that would be a second SYN, which causes load problems for legacy servers. > How does the sender of the FBP learn what the receiver of the FBP > took it to mean? (Assuming, of course, it was received at all...) The ACK that comes back, either in the SYN-ACK (if the FBP has been received) or a second ACK after that will have the response to the FBP options. >>> new endpoint sends: > > What's a "new endpoint"? An upgraded one, i.e., one that supports this new option... >>> SYN + aso + fix_opt >>> FBP + aso + extra_opt >> >> extra_opt in the data field >> total length < min MTU (576 for IPv4, 1280 for IPv6) >> again ACK bit is zero > > I get very nervous about using the data field before the handshake > is complete. It's safe - as per RFC793. This packet is outside the connection because the ACK isn't set. That's effectively saying "this packet is for the unsynchronized state". RFC793 says all such packets get silently dropped (we're talking about a packet with ACK clear, and NO other control flags set - no SYN, no RST, no FIN). >>> legacy endpoint sends back one connections: >>> SYN-ACK + fix_opt > > Presumably the legacy endpoint ignores the FBP... but what happens > if only the FBP arrives (the initial SYN being lost or mangled by a > middlebox)? They ignore it at all times, except if received in CLOSED at which point they send a RST (just like receiving any other packet in that state). If the SYN is lost, the same thing happens as any time the SYN is lost - the client resends the SYN after a timeout, and after some number of failed timeouts it gives up. Upgraded endpoints might keep FBPs for a short time in the hope of getting a matching SYN, but if they don't or discard it before it comes, the client will resend it when the SYN-ACK indicates its missing. >>> if seg arrives before SYN, > > Am I supposed to assume "seg" here means FBP? Sorry - typed too fast. Yes, here and throughout the rest... >> it is silently dropped, because >> the ACK bit is clear (this is >> explicit in RFC793) >> >>> if seg arrives after SYN, >> >> it is silently dropped, because >> the ACK bit is clear (this is also >> explicit in RFC793) >>> ---- >>> >>> new endpoint sends back one connection: >>> >>> SYN-ACK + options + .... >>> >>> a) if FBP arrives before SYN, >> >> it can be silently dropped, but >> it's probably useful for new endpoints >> to hold onto these (without action) >> for a while; they can be silently >> discarded if there are too many >> (which will just result in a >> retransmission and an extra RTT) > > Your hands are waving... Not that hard. Keeping a cache of recently received FBPs is a simple thing to do, and the mechanism is robust to that cache either not existing or being small. >>> b) if FPB arrives with the SYN, they can be >>> processed together >>> >>> the SYN-ACK can include responses to >>> the extra_opts in addition to the >>> fix_opts, and says "FBP received" > > How would it say "FBP received"? I thought of a few ways - they all end up being equivalent in spirit to a flag in an option field in the SYN-ACK, so let's say it's that for now: set FBP-received flag in the aso option >>> c) if FPB arrives after the SYN: >>> >>> SYN-ACK proceeds, but sends >>> back "wait for option response". > > How would it send that? The FBP-received flag in the SYN-ACK aso option isn't set. >>> at this point, the source re-sends FBP >>> until an ACK is received that indicates >>> "FBP received", or times-out as with >>> any connection that doesn't finish TWHS > > This sounds like the timeout wouldn't be rare -- a middlebox might > pretty automatically drop the FBP, depending... If the FBP comes before the SYN, yes. If not, it shouldn't AFAICT. >>> I'm still thinking as to whether the ACK number >>> might indicate whether FBP has been received, > > That sounds strange... Yeah - nevermind that. >> There are a few ways to handle this, but IMO the best is to have: >> >> SYN-ACK aso with length=2 means "waiting for FBP" >> >> SYN-ACK aso with length=3 (or 4) could mean >> "got the FBP", or might even indicate how >> many bytes the FBP extension contained > > That's limiting... I don't see why (FBP can indicate 32-bit words, just like the current Data Offset field, which means 255 = 1020 bytes of option space in the FBP -- note that this is all contained in the data portion of the FBP segment). >> Note - the SYN-ACK and all subsequent segments can assume that aso == >> edo, i.e., they can use the same EDO as spec'd in version 01 of this draft. > > Please! No! > > (Option numbers aren't that scarce.) See above. We could say: EDO length = 0 in a SYN means no FBP EDO length = N in a SYN means FBP with length N But let's not get hung on that detail either, IMO. Joe From nobody Sat May 31 06:13: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 638FD1A08A4 for ; Sat, 31 May 2014 06:13:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 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_MED=-2.3, 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 pTpNxTtVFvl0 for ; Sat, 31 May 2014 06:13:30 -0700 (PDT) Received: from smtp5.sgsi.ucl.ac.be (smtp.sgsi.ucl.ac.be [130.104.5.67]) by ietfa.amsl.com (Postfix) with ESMTP id 64C801A08B2 for ; Sat, 31 May 2014 06:13:29 -0700 (PDT) Received: from mbpobo.local (unknown [149.154.235.41]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: obonaventure@smtp5.sgsi.ucl.ac.be) by smtp5.sgsi.ucl.ac.be (Postfix) with ESMTPSA id DC66219841F; Sat, 31 May 2014 15:13:19 +0200 (CEST) X-DKIM: Sendmail DKIM Filter v2.8.3 smtp5.sgsi.ucl.ac.be DC66219841F DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1401542000; bh=iGYrWd4HwugpC1369e3FTe39s8LUa6Imm8EfYYzIk6E=; h=Message-ID:Date:From:Reply-To:MIME-Version:To:CC:Subject: References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=C+0tvYQemwCWpqOPAGJceXZEc6SOjFJCUIQk5BUO0liXLe12sVyvkDINZlstoxuoN Er0n9tgDuQoLf4MiRyOE/myC+C/TDAiIIDMhvXoa8NzHvwwAU4ahC3/BLriP3wRW2u upL0ieSkHDoCY8mcvQDkR3ePXNIODISKGG3/LP/4= Message-ID: <5389D1BC.2000702@uclouvain.be> Date: Sat, 31 May 2014 14:57:32 +0200 From: Olivier Bonaventure User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Joe Touch , Bob Briscoe References: <20140425221257.12559.43206.idtracker@ietfa.amsl.com> <2586_1398464386_535ADF82_2586_915_1_535ADF56.9050106@isi.edu> <5363AF84.8090701@mti-systems.com> <5363B397.8090009@isi.edu> <655C07320163294895BBADA28372AF5D2CFE36@FR712WXCHMBA15.zeu.alcatel-lucent.com> <20140503122950.GM44329@verdi> <655C07320163294895BBADA28372AF5D2D009E@FR712WXCHMBA15.zeu.alcatel-lucent.com> <201405221710.s4MHAY4S002037@bagheera.jungle.bt.co.uk> <537E3ACD.5000308@isi.edu> <537E48CE.8040704@mti-systems.com> <537E66A7.4080907@isi.edu> <201405231003.s4NA3PAB005137@bagheera.jungle.bt.co.uk> <537F7D91.10802@isi.edu> <201405281716.s4SHG29Y014642@bagheera.jungle.bt.co.uk> <53861D4F.60709@isi.edu> <201405300955.s4U9tAto028369@bagheera.jungle.bt.co.uk> <5388F407.6070508@isi.edu> In-Reply-To: <5388F407.6070508@isi.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.97.7-exp at smtp-5.sipr-dc.ucl.ac.be X-Virus-Status: Clean X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-MailScanner-ID: DC66219841F.A2E1C X-SGSI-MailScanner: Found to be clean X-SGSI-From: olivier.bonaventure@uclouvain.be X-SGSI-Spam-Status: No Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/yUN0lGNWolWAB5U3XzB5FF2B6ns Cc: "tcpm@ietf.org" Subject: Re: [tcpm] New Version Notification for draft-touch-tcpm-tcp-edo-01.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Olivier.Bonaventure@uclouvain.be List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 May 2014 13:13:31 -0000 Joe, >> >> I was asking for an example of something useful that /can/ be done with >> EDO. > > The obvious one is larger amounts of SACK feedback and space for MPTCP > information. It would be intersting to look at packet traces to see how often the SACK option is not large enough to fit into x bytes. This would give an indication of its impact. Has someone already seen such a study in the literature ? Olivier -- INL, ICTEAM, UCLouvain, Belgium, http://inl.info.ucl.ac.be From nobody Sat May 31 06:13:37 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 5310F1A08A4 for ; Sat, 31 May 2014 06:13:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 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_MED=-2.3, 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 PdbH9z5uEysU for ; Sat, 31 May 2014 06:13:29 -0700 (PDT) Received: from smtp5.sgsi.ucl.ac.be (smtp.sgsi.ucl.ac.be [130.104.5.67]) by ietfa.amsl.com (Postfix) with ESMTP id 682E81A08BC for ; Sat, 31 May 2014 06:13:29 -0700 (PDT) Received: from mbpobo.local (unknown [149.154.235.41]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: obonaventure@smtp5.sgsi.ucl.ac.be) by smtp5.sgsi.ucl.ac.be (Postfix) with ESMTPSA id 23AF61983B8; Sat, 31 May 2014 15:13:19 +0200 (CEST) X-DKIM: Sendmail DKIM Filter v2.8.3 smtp5.sgsi.ucl.ac.be 23AF61983B8 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1401541999; bh=xC1Ysuc6r0HZweOBrb04ZwmHBWGS5I5cy51lK9FShLg=; h=Message-ID:Date:From:Reply-To:MIME-Version:To:CC:Subject: References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=LMJ68Wgl9SSF6Ra/DbWefh4sbItxV3oC5PeNZhxmOKYkT0KtDDDWtMKBf54+hKgUS fJXXjApOCnXwqEoG6AboPaKLtaPCa4cebpsqZE1cEvI9lqM4H/JWgmVGqHpR1Mip2M l/xY6jN+hkgAoco1VvUnsPUe0OKYWGbktoQcpPeI= Message-ID: <5389D15B.80102@uclouvain.be> Date: Sat, 31 May 2014 14:55:55 +0200 From: Olivier Bonaventure User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Joe Touch , David Borman , Bob Briscoe References: <20140425221257.12559.43206.idtracker@ietfa.amsl.com> <2586_1398464386_535ADF82_2586_915_1_535ADF56.9050106@isi.edu> <5363AF84.8090701@mti-systems.com> <5363B397.8090009@isi.edu> <655C07320163294895BBADA28372AF5D2CFE36@FR712WXCHMBA15.zeu.alcatel-lucent.com> <20140503122950.GM44329@verdi> <655C07320163294895BBADA28372AF5D2D009E@FR712WXCHMBA15.zeu.alcatel-lucent.com> <201405221710.s4MHAY4S002037@bagheera.jungle.bt.co.uk> <537E3ACD.5000308@isi.edu> <1AD79820-22C1-4500-84D1-1383F264D68C@weston.borman.com> <201405231213.s4NCDa5P005525@bagheera.jungle.bt.co.uk> <6391C448-A917-4E66-9B73-CB840B193FD7@weston.borman.com> <537F7EE4.4080101@isi.edu> <5388C597.2030202@uclouvain.be> <5388F3E7.9040201@isi.edu> In-Reply-To: <5388F3E7.9040201@isi.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.97.7-exp at smtp-5.sipr-dc.ucl.ac.be X-Virus-Status: Clean X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-MailScanner-ID: 23AF61983B8.A1DFD X-SGSI-MailScanner: Found to be clean X-SGSI-From: olivier.bonaventure@uclouvain.be X-SGSI-Spam-Status: No Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/KAec0SUEUrptf_Km_PuOuyyz5rE Cc: "tcpm@ietf.org" Subject: Re: [tcpm] New Version Notification for draft-touch-tcpm-tcp-edo-01.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Olivier.Bonaventure@uclouvain.be List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 May 2014 13:13:32 -0000 Joe, > > On 5/30/2014 10:53 AM, Olivier Bonaventure wrote: > ... >> Let me make two rough proposals that could be worth being explored or at >> least documented. >> >> 1. The TCP option space is limited, but not the IPv6 destination options >> in the IPv6 header. > > IP option space would not be protected by TCP-AO, and likely not by > whatever the TCPUSEC WG creates (e.g.,my proposal is here: > http://tools.ietf.org/html/draft-touch-tcp-ao-encrypt-01) If the destination option is used to transport TCP options, then it would define how AO would need to take into account the TCP option inserted by the sender in the IPv6 option. > Additionally, DPI, NAT processing, etc. are all impacted by IPv6 > options, so they're generally discouraged AFAIR. IPv6 options are much cleaner than IPv4 options. IPv4 options are discouraged because they impact the forwarding on routers. For IPv6 options, this is easier since the option type indicates that the option should only be processed by the destination. For NATs or DPI, supporting TCP options as an IPv6 destination option or as any other proposal would be the same problem Olivier -- INL, ICTEAM, UCLouvain, Belgium, http://inl.info.ucl.ac.be From nobody Sat May 31 11:20:15 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 393061A0058 for ; Sat, 31 May 2014 11:20:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.252 X-Spam-Level: X-Spam-Status: No, score=-1.252 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651, 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 UCQMRR-elKPP for ; Sat, 31 May 2014 11:20:05 -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 E86EC1A0063 for ; Sat, 31 May 2014 11:20:04 -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; Sat, 31 May 2014 19:19:58 +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; Sat, 31 May 2014 19:19:57 +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; Sat, 31 May 2014 19:19:57 +0100 Received: from BTP075694.jungle.bt.co.uk ([10.111.109.114]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id s4VIJt2V003823; Sat, 31 May 2014 19:19:55 +0100 Message-ID: <201405311819.s4VIJt2V003823@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sat, 31 May 2014 19:19:53 +0100 To: Joe Touch From: Bob Briscoe In-Reply-To: <5388EB6F.4010405@isi.edu> References: <20140425221257.12559.43206.idtracker@ietfa.amsl.com> <2586_1398464386_535ADF82_2586_915_1_535ADF56.9050106@isi.edu> <5363AF84.8090701@mti-systems.com> <5363B397.8090009@isi.edu> <655C07320163294895BBADA28372AF5D2CFE36@FR712WXCHMBA15.zeu.alcatel-lucent.com> <20140503122950.GM44329@verdi> <655C07320163294895BBADA28372AF5D2D009E@FR712WXCHMBA15.zeu.alcatel-lucent.com> <201405221710.s4MHAY4S002037@bagheera.jungle.bt.co.uk> <537E3ACD.5000308@isi.edu> <1AD79820-22C1-4500-84D1-1383F264D68C@weston.borman.com> <201405231213.s4NCDa5P005525@bagheera.jungle.bt.co.uk> <537F8202.4020907@isi.edu> <201405281715.s4SHFMm0014634@bagheera.jungle.bt.co.uk> <538623B9.2060209@isi.edu> <201405301642.s4UGgcvY030471@bagheera.jungle.bt.co.uk> <5388EB6F.4010405@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/-QxOlgqe00Vr-1QvhZR4bYdB434 Cc: "tcpm@ietf.org" Subject: [tcpm] More TCP option space on SYNs 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: Sat, 31 May 2014 18:20:10 -0000 Joe, Thx for consolidating this thread. I've given it a new subject line. 1) You've silently made an important alteration to the proposed protocol. You've put the extra-options directly in the TCP option space of the C-SYN, not within the payload. This creates problems: a) it limits additional options to another 40B, beyond which we will need a third SYN, then a fourth. b) it perpetuates the deployment problem that every newly defined TCP option will have: when deployed in year y, there will be a new crop of middleboxes that only forward options defined up to year y-1. I had deliberately squirrelled the options away in the app layer to: a) provide expansion space for options on a SYN, limited only by the max segment size b) reduce the chances that middleboxes will alter the extra options, given there is a higher bar to altering the payload. c) allow for future structured ways to make extra options invisible and/or immutable by middleboxes. Yes, your altered proposal is cleaner. However, don't imagine I didn't think of this. I did and I deliberately didn't do it this way. We have a choice: clean and vulnerable vs. messy but robust. I'm not wedded to using port 80 and http headers, but this is perhaps the most pragmatic approach. It will be really unorthodox to define such a protocol I know. We would have to say something like "The dst port of the C-SYN MUST be 80, and the payload MUST start with the constant magic_token, where magic_token = 'PUT / HTTP/1.1Connection : DSO' " I'm sorry if even thinking about this makes you feel dirty :| Other suggestions for inner protocols are welcome, including tunnelled protocols, as long as middleboxes widely forward them, given their dst port. 2) The main problem with your notation is it doesn't say /where/ the info is placed. I've added notation as follows: TCP(base header [TCP options [APP(header[payload])]]) And for the record I've made the if-else logic clearer. Where I've made more than clarifying edits inline, I've described them and tagged them with [BB]. At 21:34 30/05/2014, Joe Touch wrote: >Hi, Bob, > >Let's get back to the core, in a simpler fashion, so other can follow it. > >I stand by my "there's no way to extend the space in the initial >SYN", but you've convinced me there *might* be a way to provide >extended space that can occur during the first phase of the TWHS. I >think the dual-SYN approach still isn't viable, but I've outlined an >alternative below that's similar but doesn't have the same baggage, IMO. > >Again, I'm still concerned by what midboxes might do to this... > >What do others think?? > >Joe > >For quick review, here's what I understand: > > dso = dual-syn option > dso-D = data > dso-C = control > conn_id = identifier to link the two SYNs together > extra_opt = options that didn't fit in legacy SYN > fit_opt = options that do fit in the legacy SYN new client endpoint sends TCP(port A SYN [dso-D(conn_id) + fit_opt] ) TCP(port B SYN [dso-C [APP(headers [conn_id + extra_opt] ) ] ] ) [BB]: i/APP(headers...)/ if (legacy server endpoint) { sends back two connections: TCP(port A SYN-ACK [fit_opt] ) TCP(port B SYN-ACK [??] ) > (it's interpretation of extra_opt) new client endpoint responds: TCP(port A ACK) (established) TCP(port B RST) > Notes about legacy servers: > - they do twice the work on SYNs > - they might keep twice the state > (if not using cookies) > - they might clean state if the RST > is received, but that state might > persist indefinitely (until the next > connection, depending on timeouts, etc.) > > ----- } elif (new server endpoint) { sends back one connection: TCP(port A SYN-ACK [edo + fit_opt + extra_opt] ) [BB]: s/dso-d/edo/ new client endpoint responds: TCP(port A ACK) (established) > > Notes: > - can stall when dso-D SYN arrives > before dso-C SYN, up to some limit > - twice the work on SYNs (or more) } >Here's what I was assuming, though admittedly it's not documented (yet): > > - no significant impact on TCP connection rate for > legacy servers > > - no significant impact on TCP connection rate for > legacy clients > > - impact dominated by processing the extended option space > for extended clients > > - impact dominated by processing the extended option space > for extended servers > > - compatible with typical TCP processing optimizations, > notably SYN cookies > you did provide a potential way forward for these > > - capable of successfully traversing typical NATs > >Your approach has the following properties: The 3 bullets below are not useful ways to describe performance impact. They selectively describe whichever gives the most pessimistic picture out of: a) either the instantaneous performance change at the moment of connection b) or the worst-case long-run performance impact They don't describe the average long-run performance impact, which is important for sizing machines. Worse, the instantaneous performance impact is only significant when a machine's SYN processing time is large relative to the e2e delay, which would be a highly unusual scenario on public networks (even in scenarios such as intra-data-centre, it's hard to reduce e2e delay to approach SYN processing time, but you could for intra-machine connections). > - halves the server connection rate for updated servers > from legacy clients when this option is in use Eh? The long-run server connection rate will be fractionally decreased due to updated clients using extra options (which is your third case below), but the instantaneous server connection rate seen by a legacy client is unchanged, because it only sends one SYN. > - lowers (to some extent, if not halves) the client > connection rate of updated clients to all servers > when this option is in use > > - halves (roughly) the server rate for all servers > when this option is in use Nope. All long-run server rates are reduced by 1/(1+e), where e is the fraction of connections using extra options. >It also: > > - doubles the number of SYNs in the network Nope. The number of SYNs in the network is inflated by e where e is the fraction of connections using extra options. > - susceptible to lack of fate-sharing problems, e.g., > if the two SYNs experience different firewall configurations Nope. It's fairer to say it's potentially susceptible to second-order fate-sharing problems like your firewall example (the first-order fate sharing problems have been addressed). > - reduces the space available for fit_opt due to the need > for the conn_id even in the fall-back D-SYN, which means > less option space in the SYNs for fall-back connections Yup. > the conn_id which may need to be very large because it > needs to be unique per source port and source IP address > because that information is lost during NAT translation Given many NATs will typically make the src IPs of both SYNs the same, I suggest a larger conn_id should be a fall-back option for the client, not a default. Even if the src IPs of both SYNs are different once they reach the server, the high end bits will invariably be the same. So the max size of the contents of the DSO TCP option can be 6B, and the server can take the rest of conn_id from the higher bits of the src IP addr of each SYN. This is a variant of the idea in . In fact, the server doesn't even need a small conn_id for clients that know they are not behind a NAT and that want more option space in the D-SYN - then the server could use the src port & src IP for the conn_id. To summarise, these options could be distinguished by the length field of the dual-syn option. Length = 2B => conn_id = src netaddr + src port Length = 6B = 2B +4B conn_id_short => conn_id = src netaddr + conn_id_short Length = 8B = 2B +6B conn_id_long => conn_id = hsb(src netaddr) + conn_id_long Given there have been numerous other attempts to reveal a connection ID that is preserved through middleboxes [RFC6967], rather than defining a dual-syn option that carries a conn_id, we might want to design a TCP connection ID option with a flag to say whether it is also part of a dual SYN pair or not. Where * hsb(src netaddr) is the netaddr with the lowest 16 bits truncated * src netaddr is the network address (IPv4, IPv6, or any other network protocol) To reduce latency, a host could use the default short_conn_id for all connections at first, then: - if it finds that DSO persistently doesn't work it falls back to the long_conn_id for all connections - it occasionally tests the short and zero options to see if it can use shorter DSO options. > - requires the ISNs to be related (see RFC6528 - if there's > a rule to generate it, there will be code to validate that > rule, and eventually a BCP to encourage that validation - > typically from the same RFC author) Eh? The ISNs can and should be independent. To be robust against middleboxes that rewrite sequence numbers, we must not required ISNs to be related. >I agree that you have proposed potentially viable ways to deal with >the SYN cookie, and that RST state is not an issue. A feature that I think it's fair to add: - Good chance of passing through app-layer middleboxes that forward unrecognised TCP options unchanged, but not those that discard them. >However, there are too many problems with this, IMO, to call it viable. Once your over-pessimistic analyses of the performance impact are corrected, and my ideas to reduce the size of the conn_id are taken into account, it's a different story. But it's up to the WG to decide whether this is worth taking further. Not just you or I. >Here's another trick that might clean up the above a little: Cheers Bob ________________________________________________________________ Bob Briscoe, BT From nobody Sat May 31 12:21:29 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 3F00D1A0073 for ; Sat, 31 May 2014 12:21:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.951 X-Spam-Level: X-Spam-Status: No, score=-1.951 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_34=0.6, RP_MATCHES_RCVD=-0.651] 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 vefdfiYCSmnu for ; Sat, 31 May 2014 12:21:25 -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 2290C1A0063 for ; Sat, 31 May 2014 12:21:25 -0700 (PDT) Received: from [192.168.1.93] (pool-71-105-87-112.lsanca.dsl-w.verizon.net [71.105.87.112]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id s4VJKrKC023160 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sat, 31 May 2014 12:20:56 -0700 (PDT) Message-ID: <538A2B96.3030900@isi.edu> Date: Sat, 31 May 2014 12:20:54 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Bob Briscoe References: <20140425221257.12559.43206.idtracker@ietfa.amsl.com> <2586_1398464386_535ADF82_2586_915_1_535ADF56.9050106@isi.edu> <5363AF84.8090701@mti-systems.com> <5363B397.8090009@isi.edu> <655C07320163294895BBADA28372AF5D2CFE36@FR712WXCHMBA15.zeu.alcatel-lucent.com> <20140503122950.GM44329@verdi> <655C07320163294895BBADA28372AF5D2D009E@FR712WXCHMBA15.zeu.alcatel-lucent.com> <201405221710.s4MHAY4S002037@bagheera.jungle.bt.co.uk> <537E3ACD.5000308@isi.edu> <1AD79820-22C1-4500-84D1-1383F264D68C@weston.borman.com> <201405231213.s4NCDa5P005525@bagheera.jungle.bt.co.uk> <537F8202.4020907@isi.edu> <201405281715.s4SHFMm0014634@bagheera.jungle.bt.co.uk> <538623B9.2060209@isi.edu> <201405301642.s4UGgcvY030471@bagheera.jungle.bt.co.uk> <5388EB6F.4010405@isi.edu> <201405311819.s4VIJt2V003823@bagheera.jungle.bt.co.uk> In-Reply-To: <201405311819.s4VIJt2V003823@bagheera.jungle.bt.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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/jh0F6fxRratSUpRzEADeILr8xN4 Cc: "tcpm@ietf.org" Subject: Re: [tcpm] More TCP option space on SYNs 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: Sat, 31 May 2014 19:21:27 -0000 Hi, Bob, On 5/31/2014 11:19 AM, Bob Briscoe wrote: > Joe, > > Thx for consolidating this thread. I've given it a new subject line. > > 1) You've silently made an important alteration to the proposed > protocol. You've put the extra-options directly in the TCP option space > of the C-SYN, not within the payload. I hadn't assumed that; I was describing only which SYN carried which options, not where they were. As you do, I was assuming the C-SYN options were in the data space. To be clear, in my variant - using data outside the sync'd connection (with ACK clear), the option space is similarly in the data portion of the 'extra' segment. > Yes, your altered proposal is cleaner. However, don't imagine I didn't > think of this. I did and I deliberately didn't do it this way.We have a > choice: > clean and vulnerable vs. messy but robust. > > I'm not wedded to using port 80 and http headers, but this is perhaps > the most pragmatic approach. That's fraught with a whole slew of other problems, notably the middleboxes that currently try to translate, proxy, or otherwise modify anything they see as port 80. Further, that would limit the number of pending connections. > It will be really unorthodox to define such > a protocol I know. We would have to say something like > > "The dst port of the C-SYN MUST be 80, and the payload MUST start > with the constant magic_token, where > magic_token = 'PUT / HTTP/1.1Connection : DSO' > " > > I'm sorry if even thinking about this makes you feel dirty :| > > Other suggestions for inner protocols are welcome, including tunnelled > protocols, as long as middleboxes widely forward them, given their dst > port. I don't see what this gets us other than potential interactions. There's no reason to use HTTP to format TCP options, and it would necessitate new encodings and new processing for existing options that might end up in the extended space. > 2) The main problem with your notation is it doesn't say /where/ the > info is placed. EDO says the options are at the head of the data segment, just with a longer pointer - the same way as current options. For extending the SYN using a separate segment - whether a C-SYN or unsync'd data segment - the data similarly comes at the head of the data, just that there's no user data permitted after it. > I've added notation as follows: > TCP(base header [TCP options [APP(header[payload])]]) > > And for the record I've made the if-else logic clearer. > > Where I've made more than clarifying edits inline, I've described them > and tagged them with [BB]. > > At 21:34 30/05/2014, Joe Touch wrote: >> Hi, Bob, >> >> Let's get back to the core, in a simpler fashion, so other can follow it. >> >> I stand by my "there's no way to extend the space in the initial SYN", >> but you've convinced me there *might* be a way to provide extended >> space that can occur during the first phase of the TWHS. I think the >> dual-SYN approach still isn't viable, but I've outlined an alternative >> below that's similar but doesn't have the same baggage, IMO. >> >> Again, I'm still concerned by what midboxes might do to this... >> >> What do others think?? >> >> Joe >> >> For quick review, here's what I understand: >> >> dso = dual-syn option >> dso-D = data >> dso-C = control >> conn_id = identifier to link the two SYNs together >> extra_opt = options that didn't fit in legacy SYN >> fit_opt = options that do fit in the legacy SYN > new client endpoint sends > TCP(port A SYN [dso-D(conn_id) + fit_opt] ) > TCP(port B SYN [dso-C [APP(headers [conn_id + > extra_opt] ) ] ] ) IMO, the conn_ID in the C-SYN should similarly be in the regular option space, but I don't think it matters. > [BB]: i/APP(headers...)/ > > if (legacy server endpoint) { sends back two > connections: > TCP(port A SYN-ACK [fit_opt] ) > TCP(port B SYN-ACK [??] ) >> (it's interpretation of extra_opt) I'm assuming EDO after the SYN, which means the SYN-ACK has as much space as it wants for options, as would every other segment. > new client endpoint responds: > TCP(port A ACK) (established) > TCP(port B RST) > >> Notes about legacy servers: >> - they do twice the work on SYNs >> - they might keep twice the state >> (if not using cookies) >> - they might clean state if the RST >> is received, but that state might >> persist indefinitely (until the next >> connection, depending on timeouts, etc.) >> >> ----- > } elif (new server endpoint) { sends back one > connection: > TCP(port A SYN-ACK [edo + fit_opt + > extra_opt] ) > > [BB]: s/dso-d/edo/ Sure. At this point we're basically in EDO-land. > new client endpoint responds: > TCP(port A ACK) (established) > >> >> Notes: >> - can stall when dso-D SYN arrives >> before dso-C SYN, up to some limit >> - twice the work on SYNs (or more) > } > >> Here's what I was assuming, though admittedly it's not documented (yet): >> >> - no significant impact on TCP connection rate for >> legacy servers >> >> - no significant impact on TCP connection rate for >> legacy clients >> >> - impact dominated by processing the extended option space >> for extended clients >> >> - impact dominated by processing the extended option space >> for extended servers >> >> - compatible with typical TCP processing optimizations, >> notably SYN cookies >> you did provide a potential way forward for these >> >> - capable of successfully traversing typical NATs >> >> Your approach has the following properties: > > The 3 bullets below are not useful ways to describe performance impact. > They selectively describe whichever gives the most pessimistic picture > out of: > a) either the instantaneous performance change at the moment of connection > b) or the worst-case long-run performance impact > > They don't describe the average long-run performance impact, which is > important for sizing machines. > > Worse, the instantaneous performance impact is only significant when a > machine's SYN processing time is large relative to the e2e delay, which > would be a highly unusual scenario on public networks (even in scenarios > such as intra-data-centre, it's hard to reduce e2e delay to approach SYN > processing time, but you could for intra-machine connections). SYN processing is a known load - and potential overload - on machines. That's why it's reasonable to focus on it. >> - halves the server connection rate for updated servers >> from legacy clients when this option is in use > > Eh? The long-run server connection rate will be fractionally decreased > due to updated clients using extra options (which is your third case > below), but the instantaneous server connection rate seen by a legacy > client is unchanged, because it only sends one SYN. Agreed. I was doing too many of these at once... >> - lowers (to some extent, if not halves) the client >> connection rate of updated clients to all servers >> when this option is in use >> >> - halves (roughly) the server rate for all servers >> when this option is in use > > Nope. All long-run server rates are reduced by 1/(1+e), where e is the > fraction of connections using extra options. the rate for connections when this option is in use is halved - I didn't see that the sentence above could be parsed the other way. the overall rate depends on the fraction of connections using the option. >> It also: >> >> - doubles the number of SYNs in the network > > Nope. The number of SYNs in the network is inflated by e where e is the > fraction of connections using extra options. You keep bringing this up - I don't like a solution that should be used only a little. If it works, we should assume it works everywhere all the time. >> - susceptible to lack of fate-sharing problems, e.g., >> if the two SYNs experience different firewall configurations > > Nope. It's fairer to say it's potentially susceptible to second-order > fate-sharing problems like your firewall example (the first-order fate > sharing problems have been addressed). I have no idea why you think firewalls are a second-order fate-sharing, or what that even means. Fate sharing means fate is shared. When fate is not shared by the SYNs, this method has problems. There's no mechanism to recover the missing D-SYN or C-SYN. >> - reduces the space available for fit_opt due to the need >> for the conn_id even in the fall-back D-SYN, which means >> less option space in the SYNs for fall-back connections > > Yup. > > >> the conn_id which may need to be very large because it >> needs to be unique per source port and source IP address >> because that information is lost during NAT translation > > Given many NATs will typically make the src IPs of both SYNs the same, I > suggest a larger conn_id should be a fall-back option for the client, > not a default. Multiple NATs are quite common - carrier grade NATs in the net, and user NATs at the home WIFI point. Any multiple-NAT, or any path through even a single carrier-grade NAT will end up potentially un-doing or over-doing source IP overlap, creating false positives and false negatives that break this mechanism. That's really the crux - fate sharing and the need to bind the two SYNs - that make this untenable, IMO. > Even if the src IPs of both SYNs are different once they reach the > server, the high end bits will invariably be the same. You can't know this - the two SYNs could have gone through different numbers of NATs or different NATs entirely, so the bits could change arbitrarily. > So the max size > of the contents of the DSO TCP option can be 6B, and the server can take > the rest of conn_id from the higher bits of the src IP addr of each SYN. > This is a variant of the idea in . FWIW, you're now in the land where we would have to start explaining the privacy and tracking implications of those bits. I'd really like to avoid that. > In fact, the server doesn't even need a small conn_id for clients that > know they are not behind a NAT and that want more option space in the > D-SYN - then the server could use the src port & src IP for the conn_id. > > To summarise, these options could be distinguished by the length field > of the dual-syn option. > Length = 2B => conn_id = src netaddr + src port > Length = 6B = 2B +4B conn_id_short => conn_id = src netaddr + > conn_id_short > Length = 8B = 2B +6B conn_id_long => conn_id = hsb(src netaddr) + > conn_id_long > > Given there have been numerous other attempts to reveal a connection ID > that is preserved through middleboxes [RFC6967], rather than defining a > dual-syn option that carries a conn_id, we might want to design a TCP > connection ID option with a flag to say whether it is also part of a > dual SYN pair or not. > > Where > * hsb(src netaddr) is the netaddr with the lowest 16 bits truncated > * src netaddr is the network address (IPv4, IPv6, or any other network > protocol) > > To reduce latency, a host could use the default short_conn_id for all > connections at first, then: > - if it finds that DSO persistently doesn't work it falls back to the > long_conn_id for all connections > - it occasionally tests the short and zero options to see if it can use > shorter DSO options. > > >> - requires the ISNs to be related (see RFC6528 - if there's >> a rule to generate it, there will be code to validate that >> rule, and eventually a BCP to encourage that validation - >> typically from the same RFC author) > > Eh? The ISNs can and should be independent. To be robust against > middleboxes that rewrite sequence numbers, we must not required ISNs to > be related. > > >> I agree that you have proposed potentially viable ways to deal with >> the SYN cookie, and that RST state is not an issue. > > A feature that I think it's fair to add: > - Good chance of passing through app-layer middleboxes that > forward > unrecognised TCP options unchanged, but not those that discard > them. > > >> However, there are too many problems with this, IMO, to call it viable. > > Once your over-pessimistic analyses of the performance impact are > corrected, and my ideas to reduce the size of the conn_id are taken into > account, it's a different story. > > But it's up to the WG to decide whether this is worth taking further. > Not just you or I. Agreed. >> Here's another trick that might clean up the above a little: > > with ACK=0> > > Cheers > > > Bob > > > ________________________________________________________________ > Bob Briscoe, BT From nobody Sat May 31 13:43:13 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 D06681A00A8 for ; Sat, 31 May 2014 13:43:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] 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 3mnoXAwIgUf1 for ; Sat, 31 May 2014 13:43:11 -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 778D61A00A3 for ; Sat, 31 May 2014 13:43:11 -0700 (PDT) Received: from [192.168.1.91] (pool-71-105-87-112.lsanca.dsl-w.verizon.net [71.105.87.112]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id s4VKgQpC006619 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sat, 31 May 2014 13:42:34 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) Content-Type: text/plain; charset=iso-8859-1 From: Joe Touch In-Reply-To: <5389D15B.80102@uclouvain.be> Date: Sat, 31 May 2014 13:42:25 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <30A19140-A978-4FE6-9A0E-63F78AF44CF3@isi.edu> References: <20140425221257.12559.43206.idtracker@ietfa.amsl.com> <2586_1398464386_535ADF82_2586_915_1_535ADF56.9050106@isi.edu> <5363AF84.8090701@mti-systems.com> <5363B397.8090009@isi.edu> <655C07320163294895BBADA28372AF5D2CFE36@FR712WXCHMBA15.zeu.alcatel-lucent.com> <20140503122950.GM44329@verdi> <655C07320163294895BBADA28372AF5D2D009E@FR712WXCHMBA15.zeu.alcatel-lucent.com> <201405221710.s4MHAY4S002037@bagheera.jungle.bt.co.uk> <537E3ACD.5000308@isi.edu> <1AD79820-22C1-4500-84D1-1383F264D68C@weston.borman.com> <201405231213.s4NCDa5P005525@bagheera.jungle.bt.co.uk> <6391C448-A917-4E66-9B73-CB840B193FD7@weston.borman.com> <537F7EE4.4080101@isi.edu> <5388C597.2030202@uclouvain.be> <5388F3E7.9040201@isi.edu> <5389D15B.80102@uclouvain.be> To: Olivier.Bonaventure@uclouvain.be X-Mailer: Apple Mail (2.1878.2) 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/y2e6_B1BGvkK_NTq3ndqkHorLhw Cc: David Borman , "tcpm@ietf.org" Subject: Re: [tcpm] New Version Notification for draft-touch-tcpm-tcp-edo-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: Sat, 31 May 2014 20:43:13 -0000 On May 31, 2014, at 5:55 AM, Olivier Bonaventure = wrote: > Joe, >>=20 >> On 5/30/2014 10:53 AM, Olivier Bonaventure wrote: >> ... >>> Let me make two rough proposals that could be worth being explored = or at >>> least documented. >>>=20 >>> 1. The TCP option space is limited, but not the IPv6 destination = options >>> in the IPv6 header. >>=20 >> IP option space would not be protected by TCP-AO, and likely not by >> whatever the TCPUSEC WG creates (e.g.,my proposal is here: >> http://tools.ietf.org/html/draft-touch-tcp-ao-encrypt-01) >=20 > If the destination option is used to transport TCP options, > then it would define how AO would need to take into account the TCP = option inserted by the sender in the IPv6 option. TCP doesn't necessarily get the entire IP header. It's not practical to = claim that TCP-AO can protect something it might never see - and = certainly might not have control over once it's inserted in the IPv6 = header. >> Additionally, DPI, NAT processing, etc. are all impacted by IPv6 >> options, so they're generally discouraged AFAIR. >=20 >=20 > IPv6 options are much cleaner than IPv4 options. IPv4 options are = discouraged because they impact the forwarding on routers. For IPv6 = options, this is easier since the option type indicates that the option = should only be processed by the destination. For NATs or DPI, supporting = TCP options as an IPv6 destination option or as any other proposal would = be the same problem IPv6 options push the location of TCP port numbers to places that need = to be computed, rather than being known in advance - and wired into = hardware. Anything that looks at ports might toss something with *any* IP options = - v4 or v6 - to slow-path. Joe= From nobody Sat May 31 13:44:15 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 2ED291A00A3 for ; Sat, 31 May 2014 13:44:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] 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 C-mOaq5h3jg3 for ; Sat, 31 May 2014 13:44:12 -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 1997E1A00B0 for ; Sat, 31 May 2014 13:44:11 -0700 (PDT) Received: from [192.168.1.91] (pool-71-105-87-112.lsanca.dsl-w.verizon.net [71.105.87.112]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id s4VKgQpD006619 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sat, 31 May 2014 13:43:40 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) Content-Type: text/plain; charset=iso-8859-1 From: Joe Touch In-Reply-To: <5389D1BC.2000702@uclouvain.be> Date: Sat, 31 May 2014 13:43:38 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <01E96243-EF38-4AA2-9F83-ECEEAF0D3C34@isi.edu> References: <20140425221257.12559.43206.idtracker@ietfa.amsl.com> <2586_1398464386_535ADF82_2586_915_1_535ADF56.9050106@isi.edu> <5363AF84.8090701@mti-systems.com> <5363B397.8090009@isi.edu> <655C07320163294895BBADA28372AF5D2CFE36@FR712WXCHMBA15.zeu.alcatel-lucent.com> <20140503122950.GM44329@verdi> <655C07320163294895BBADA28372AF5D2D009E@FR712WXCHMBA15.zeu.alcatel-lucent.com> <201405221710.s4MHAY4S002037@bagheera.jungle.bt.co.uk> <537E3ACD.5000308@isi.edu> <537E48CE.8040704@mti-systems.com> <537E66A7.4080907@isi.edu> <201405231003.s4NA3PAB005137@bagheera.jungle.bt.co.uk> <537F7D91.10802@isi.edu> <201405281716.s4SHG29Y014642@bagheera.jungle.bt.co.uk> <53861D4F.60709@isi.edu> <201405300955.s4U9tAto028369@bagheera.jungle.bt.co.uk> <5388F407.6070508@isi.edu> <5389D1BC.2000702@uclouvain.be> To: Olivier.Bonaventure@uclouvain.be X-Mailer: Apple Mail (2.1878.2) 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/ao_DnEcxsw2tDfHRwEfVFmkXF98 Cc: "tcpm@ietf.org" Subject: Re: [tcpm] New Version Notification for draft-touch-tcpm-tcp-edo-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: Sat, 31 May 2014 20:44:13 -0000 On May 31, 2014, at 5:57 AM, Olivier Bonaventure = wrote: > Joe, >>>=20 >>> I was asking for an example of something useful that /can/ be done = with >>> EDO. >>=20 >> The obvious one is larger amounts of SACK feedback and space for = MPTCP >> information. >=20 > It would be intersting to look at packet traces to see how often the = SACK option is not large enough to fit into x bytes. You'll never see that in a trace - what you'll see is SACK options that = fit, of course. > This would give an indication of its impact. Has someone already seen = such a study in the literature ? I don't know, though there are armies that mine traces for all sorts of = stuff, so I wouldn't be surprised. Joe= From nobody Sat May 31 14:13:31 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 D1BFE1A00C2 for ; Sat, 31 May 2014 14:13:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.252 X-Spam-Level: X-Spam-Status: No, score=-3.252 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651, 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 hgGrLUfRZF8T for ; Sat, 31 May 2014 14:13:25 -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 8C4DB1A00C0 for ; Sat, 31 May 2014 14:13:24 -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; Sat, 31 May 2014 22:13:13 +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; Sat, 31 May 2014 22:13: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; Sat, 31 May 2014 22:13:17 +0100 Received: from BTP075694.jungle.bt.co.uk ([10.111.109.114]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id s4VLDEbG004301; Sat, 31 May 2014 22:13:15 +0100 Message-ID: <201405312113.s4VLDEbG004301@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sat, 31 May 2014 22:13:13 +0100 To: Joe Touch From: Bob Briscoe In-Reply-To: <5389263C.8010202@isi.edu> References: <20140425221257.12559.43206.idtracker@ietfa.amsl.com> <2586_1398464386_535ADF82_2586_915_1_535ADF56.9050106@isi.edu> <5363AF84.8090701@mti-systems.com> <5363B397.8090009@isi.edu> <655C07320163294895BBADA28372AF5D2CFE36@FR712WXCHMBA15.zeu.alcatel-lucent.com> <20140503122950.GM44329@verdi> <655C07320163294895BBADA28372AF5D2D009E@FR712WXCHMBA15.zeu.alcatel-lucent.com> <201405221710.s4MHAY4S002037@bagheera.jungle.bt.co.uk> <537E3ACD.5000308@isi.edu> <1AD79820-22C1-4500-84D1-1383F264D68C@weston.borman.com> <201405231213.s4NCDa5P005525@bagheera.jungle.bt.co.uk> <537F8202.4020907@isi.edu> <201405281715.s4SHFMm0014634@bagheera.jungle.bt.co.uk> <538623B9.2060209@isi.edu> <201405301642.s4UGgcvY030471@bagheera.jungle.bt.co.uk> <5388EB6F.4010405@isi.edu> <5389263C.8010202@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/C9qcYi_O1JVCcuVBdskG5lHGxDw Cc: "tcpm@ietf.org" Subject: [tcpm] SYN extension using ACK=0 data packets 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: Sat, 31 May 2014 21:13:28 -0000 Joe, Hope it's ok to have changed the subject line, with tcpm still in cc. I'm afraid I'm not as excited about ACK=0 as you are. It's certainly cleaner than anything we've come up with so far. However, I see the goal as finding a way to send a supplement to a SYN that is invalid in some way to legacy TCP servers, but likely to appear valid to many/most middleboxes. I suspect many middleboxes and firewalls will discard the ACK=0 segment. When assessing the DSO scheme, you were adamant that anything invalid to an endpoint would always eventually become invalid to middleboxes. In the excitement of finding a nice clean way of doing ASO, that critique seems to have suddenly become unimportant. Whatever, there may be a place for both solutions: a) ASO (ACK=0) for paths where a NAT might be the worst middlebox on the path b) DSO for paths with stateful firewalls, TCP normalisers etc. The cellular world is certainly more like (b). Whether there are many parts of the public Internet left like (a) is unclear. (b) seems to have become the norm for most paths. More inline... At 01:45 31/05/2014, Joe Touch wrote: >Hi, all, > >Some additional information below about "another trick" I proposed, >inspired by Bob's dual-SYN mechanism, courtesy a few long >discussions today with Ted Faber. > >I'll be glad to offer this as a potential solution in the doc. > >Joe > >On 5/30/2014 1:34 PM, Joe Touch wrote: >... >>Here's another trick that might clean up the above a little: > >FWIW, I had explained it below as being based on sending >out-of-window data; Ted pointed out that I had been assuming that >the FBP ACK bit wasn't set - which means the sequence number might >be more usefully matched to that of the SYN. > >See below... > >> aso - after SYN option > > length = 2 (just a flag) > length = 3 (or 4) indicating the length of the > FBP expected > >> FBP - front bumper packet (best I could do on names today) >> a packet > ISN = same as the associated SYN > ACK = cleared (i.e., a data packet NOT part of > synchronized connection - see why that's useful below) For the avoidance of doubt, I assume these two packets have the same src port. and I assume the FBP has SYN=0. Coincidentally, a couple of weeks ago, when I was looking for places to find more bits in the TCP header, I noted that during an established connection ACK=0 is never used, so I looked into setting ACK=0 and overloading the ack_number field. >> new endpoint sends: >> >> SYN + aso + fix_opt >> FBP + aso + extra_opt > > extra_opt in the data field > total length < min MTU (576 for IPv4, 1280 for IPv6) > again ACK bit is zero > >> legacy endpoint sends back one connections: >> SYN-ACK + fix_opt >> >> if seg arrives before SYN, > > it is silently dropped, because > the ACK bit is clear (this is > explicit in RFC793) > >> if seg arrives after SYN, > > it is silently dropped, because > the ACK bit is clear (this is also > explicit in RFC793) Two important questions: 1) are most/all legacy TCP implementations faithful to the spec? 2) if a TCP endpoint is meant to drop SYN=0, ACK=0, then many middleboxes surely will. Both these will need experimental testing. Nit: I wouldn't exactly say RFC793 is clear. You have to follow 2 pages of quite imprecise descriptive logic, starting from p66. But, yes it is eventually fairly unambiguous. Paraphrasing, it says: SEGMENT ARRIVES ... if state = SYN-SENT 1. Check ACK bit if ACK = 1 do stuff 2. Check RST bit if RST = 1 if ACK OK enter CLOSED state elif no ACK, drop 3. Check security & precedence Do stuff 4. Check SYN bit Should only get here if ACK OK, or no ACK and no RST if SYN = 1 do stuff 5. if SYN = 0 and RST = 0 drop >> ---- >> >> new endpoint sends back one connection: >> >> SYN-ACK + options + .... >> >> a) if FBP arrives before SYN, > > it can be silently dropped, but > it's probably useful for new endpoints > to hold onto these (without action) > for a while; they can be silently > discarded if there are too many > (which will just result in a > retransmission and an extra RTT) > >> b) if FPB arrives with the SYN, they can be >> processed together By 'arrives with' I assume you mean 'within some time duration'. >> the SYN-ACK can include responses to >> the extra_opts in addition to the >> fix_opts, and says "FBP received" >> >> >> c) if FPB arrives after the SYN: >> >> SYN-ACK proceeds, but sends >> back "wait for option response". >> >> at this point, the source re-sends FBP >> until an ACK is received that indicates >> "FBP received", or times-out as with >> any connection that doesn't finish TWHS There's a dilemma whether the server: * prioritises latency and goes ahead without the extra options, * or prioritise completeness and blocks until the extra options arrive. I would take the view that if the FBP is late there's a chance it got snarled up in a middlebox, and it will never get through no matter how many times it's retransmitted. Rather than make the choice between latency and completeness at protocol design time, we need a flag in either scheme (on the DSO or ASO option) for the client to say which it wants. Then: * the client can choose latency if it knows the extra_opts are not critical. * otherwise it can choose completeness, and if it doesn't work after a retransmit or two, the client won't block for ever; it can work out the compromise set of options that fit in a single SYN but still 'work'. >> I'm still thinking as to whether the ACK number >> might indicate whether FBP has been received, > >There are a few ways to handle this, but IMO the best is to have: > > SYN-ACK aso with length=2 means "waiting for FBP" > > SYN-ACK aso with length=3 (or 4) could mean > "got the FBP", or might even indicate how > many bytes the FBP extension contained > >Note - the SYN-ACK and all subsequent segments can assume that aso >== edo, i.e., they can use the same EDO as spec'd in version 01 of this draft. > >>This is cleaner as follows: >> >> - no need for conn_id coordination >> >> - no need for conn_id to consume option space for fall-back >> >> - avoids double-load for legacy servers With a typical legacy server that reflects SYN cookies, less activity is doubled: * my scheme: sends out two SYN cookies * your scheme: sends out one SYN cookie and drops one packet, probably after a long chain of logic, because the FBP is an unusual packet. >> - no problem with fate-sharing To be as consistently pessimistic as you were with my scheme, I think you mean that you have created machinery to synthesise fate sharing between a connection and an invalid segment, and it may not work in cases that you may not have thought of. >> - traverses a NAT just fine As above, surely TCP normalising middleboxes and incoming stateful firewalls at the server end are likely to discard the FBP. >>Upgraded servers still need to wait for the 'seg', but they could get >>that retransmitted if necessary. See discussion of latency vs completeness dilemma above. >And there's a small amount of additional processing to discard the >FBP at legacy endpoints, but silently discarding one packet per >connection doesn't seem like a huge effort to me. Despite this being an exceptional drop (see earlier), this is still a reasonably fair statement. >Note - there's no special RST processing, based on Ted's observation >about "data without ACK" being considered "data sent in the >unsynchronzed state" -- something legacy TCP explicitly silently discards. ...at least in theory. Cheers Bob ________________________________________________________________ Bob Briscoe, BT From nobody Sat May 31 15:01:51 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 1F2FC1A0108 for ; Sat, 31 May 2014 15:01:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] 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 xdx4BzJu3qJz for ; Sat, 31 May 2014 15:01:46 -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 913561A00B2 for ; Sat, 31 May 2014 15:01:46 -0700 (PDT) Received: from [192.168.1.91] (pool-71-105-87-112.lsanca.dsl-w.verizon.net [71.105.87.112]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id s4VM1PqN018870 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sat, 31 May 2014 15:01:30 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) Content-Type: text/plain; charset=us-ascii From: Joe Touch In-Reply-To: <201405312113.s4VLDEbG004301@bagheera.jungle.bt.co.uk> Date: Sat, 31 May 2014 15:01:25 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <6C4E6E63-F3F4-4364-9459-794957DC8799@isi.edu> References: <20140425221257.12559.43206.idtracker@ietfa.amsl.com> <2586_1398464386_535ADF82_2586_915_1_535ADF56.9050106@isi.edu> <5363AF84.8090701@mti-systems.com> <5363B397.8090009@isi.edu> <655C07320163294895BBADA28372AF5D2CFE36@FR712WXCHMBA15.zeu.alcatel-lucent.com> <20140503122950.GM44329@verdi> <655C07320163294895BBADA28372AF5D2D009E@FR712WXCHMBA15.zeu.alcatel-lucent.com> <201405221710.s4MHAY4S002037@bagheera.jungle.bt.co.uk> <537E3ACD.5000308@isi.edu> <1AD79820-22C1-4500-84D1-1383F264D68C@weston.borman.com> <201405231213.s4NCDa5P005525@bagheera.jungle.bt.co.uk> <537F8202.4020907@isi.edu> <201405281715.s4SHFMm0014634@bagheera.jungle.bt.co.uk> <538623B9.2060209@isi.edu> <201405301642.s4UGgcvY030471@bagheera.jungle.bt.co.uk> <5388EB6F.4010405@isi.edu> <5389263C.8010202@isi.edu> <201405312113.s4VLDEbG004301@baghee! ra.jungle.bt.co.uk> To: Bob Briscoe X-Mailer: Apple Mail (2.1878.2) 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/k-PHZSMGo-Y0tRNiAam5sLqxY50 Cc: "tcpm@ietf.org" Subject: Re: [tcpm] SYN extension using ACK=0 data packets 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: Sat, 31 May 2014 22:01:49 -0000 Hi, Bob, On May 31, 2014, at 2:13 PM, Bob Briscoe wrote: > Joe, >=20 > Hope it's ok to have changed the subject line, with tcpm still in cc. >=20 > I'm afraid I'm not as excited about ACK=3D0 as you are. It's certainly = cleaner than anything we've come up with so far. >=20 > However, I see the goal as finding a way to send a supplement to a SYN = that is invalid in some way to legacy TCP servers, but likely to appear = valid to many/most middleboxes. I suspect many middleboxes and firewalls = will discard the ACK=3D0 segment. >=20 > When assessing the DSO scheme, you were adamant that anything invalid = to an endpoint would always eventually become invalid to middleboxes. In = the excitement of finding a nice clean way of doing ASO, that critique = seems to have suddenly become unimportant. I worry about checksums in particular - which get recalculated, so using = a different checksum means we're sure to fail through a middlebox that = doesn't recalculate it properly (if it's stored in a new place), or that = won't validate it (if it's in the current checksum field). I can't say that middleboxes don't check for ACK=3D0 packets, but it = seems a lot of work to do unless they're perceived to be an issue. I = doubt they look at the ACK at all unless the SYN or FIN is set. > Whatever, there may be a place for both solutions: > a) ASO (ACK=3D0) for paths where a NAT might be the worst middlebox on = the path > b) DSO for paths with stateful firewalls, TCP normalisers etc. DSO is better through stateful firewalls only when the FBP packet = precedes the SYN. Keep in mind that the FBP can also be sent multiple = times after the SYN anyway, with small (1ms) delays; only the first will = end up being used, and loss of all of them would still be recoverable. > The cellular world is certainly more like (b). Cellular uses GGN (carrier-grade NATs), which could make DSO SYN pairing = more difficult. > Whether there are many parts of the public Internet left like (a) is = unclear. (b) seems to have become the norm for most paths. If we're counting numbers, there are a *lot* more hosts behind NATs. The = ones behind CGNs probably swamp all others combined. > More inline... >=20 > At 01:45 31/05/2014, Joe Touch wrote: >> Hi, all, >>=20 >> Some additional information below about "another trick" I proposed, = inspired by Bob's dual-SYN mechanism, courtesy a few long discussions = today with Ted Faber. >>=20 >> I'll be glad to offer this as a potential solution in the doc. >>=20 >> Joe >>=20 >> On 5/30/2014 1:34 PM, Joe Touch wrote: >> ... >>> Here's another trick that might clean up the above a little: >>=20 >> FWIW, I had explained it below as being based on sending = out-of-window data; Ted pointed out that I had been assuming that the = FBP ACK bit wasn't set - which means the sequence number might be more = usefully matched to that of the SYN. >>=20 >> See below... >>=20 >>> aso - after SYN option >>=20 >> length =3D 2 (just a flag) >> length =3D 3 (or 4) indicating the length of the >> FBP expected >>=20 >>> FBP - front bumper packet (best I could do on names today) >>> a packet >> ISN =3D same as the associated SYN >> ACK =3D cleared (i.e., a data packet NOT part of >> synchronized connection - see why that's useful below) >=20 > For the avoidance of doubt, > I assume these two packets have the same src port. Same IP addresses, same ports, *because* they're associated with the = same connection. > and I assume the FBP has SYN=3D0. Yes. All control bits are 0, including ACK. > Coincidentally, a couple of weeks ago, when I was looking for places = to find more bits in the TCP header, I noted that during an established = connection ACK=3D0 is never used, so I looked into setting ACK=3D0 and = overloading the ack_number field. >=20 >=20 >>> new endpoint sends: >>>=20 >>> SYN + aso + fix_opt >>> FBP + aso + extra_opt >>=20 >> extra_opt in the data field >> total length < min MTU (576 for IPv4, 1280 for IPv6) >> again ACK bit is zero >>=20 >>> legacy endpoint sends back one connections: >>> SYN-ACK + fix_opt >>>=20 >>> if seg arrives before SYN, >>=20 >> it is silently dropped, because >> the ACK bit is clear (this is >> explicit in RFC793) >>=20 >>> if seg arrives after SYN, >>=20 >> it is silently dropped, because >> the ACK bit is clear (this is also >> explicit in RFC793) >=20 > Two important questions: > 1) are most/all legacy TCP implementations faithful to the spec? That's something I'll take a look at.=20 > 2) if a TCP endpoint is meant to drop SYN=3D0, ACK=3D0, then many = middleboxes surely will. Middleboxes drop things whose checksum fails, or when a packet comes in = for a connection that hasn't been established. They don't go out of = their way to do a lot of other work AFAICT. > Both these will need experimental testing. Certainly. > Nit: I wouldn't exactly say RFC793 is clear. You have to follow 2 = pages of quite imprecise descriptive logic, starting from p66. But, yes = it is eventually fairly unambiguous. Paraphrasing, it says: >=20 > SEGMENT ARRIVES > ... > if state =3D SYN-SENT > 1. Check ACK bit > if ACK =3D 1 > do stuff > 2. Check RST bit > if RST =3D 1 > if ACK OK enter CLOSED state > elif no ACK, drop > 3. Check security & precedence > Do stuff > 4. Check SYN bit > Should only get here if ACK OK, or no ACK and = no RST > if SYN =3D 1 > do stuff > 5. if SYN =3D 0 and RST =3D 0 > drop In CLOSED, it says to send a RST (like any other packet for a = non-connection). In LISTEN, it says: Any other control or text-bearing segment (not containing SYN) must have an ACK and thus would be discarded by the ACK processing. An incoming RST segment could not be valid, since it could not have been sent in response to anything sent by this incarnation of the connection. So you are unlikely to get here, (where 'here' is a segment with ACK=3D0 and no other control bits set) but if you do, drop the segment, and return. In SYN-SENT, it says: fifth, if neither of the SYN or RST bits is set then drop the segment and return. In all other states, it says: if the ACK bit is off drop the segment and return If that's not direct and explicit, I don't know what is. >>> ---- >>>=20 >>> new endpoint sends back one connection: >>>=20 >>> SYN-ACK + options + .... >>>=20 >>> a) if FBP arrives before SYN, >>=20 >> it can be silently dropped, but >> it's probably useful for new endpoints >> to hold onto these (without action) >> for a while; they can be silently >> discarded if there are too many >> (which will just result in a >> retransmission and an extra RTT) >>=20 >>> b) if FPB arrives with the SYN, they can be >>> processed together >=20 > By 'arrives with' I assume you mean 'within some time duration'. Yes - I was thinking of the case where the FBP is either cached (as per = (a)), or is in the segment queue at the time the SYN is being processed. >>> the SYN-ACK can include responses to >>> the extra_opts in addition to the >>> fix_opts, and says "FBP received" >>>=20 >>>=20 >>> c) if FPB arrives after the SYN: >>>=20 >>> SYN-ACK proceeds, but sends >>> back "wait for option response". >>>=20 >>> at this point, the source re-sends FBP >>> until an ACK is received that indicates >>> "FBP received", or times-out as with >>> any connection that doesn't finish TWHS >=20 > There's a dilemma whether the server: > * prioritises latency and goes ahead without the extra options, > * or prioritise completeness and blocks until the extra options = arrive. There's no dilemma - if the SYN says "FBP is coming", then it means that = an upgraded server MUST wait for the FBP. I.e., the FBP is paired with the SYN-ACK, and the handshake doesn't = complete at the client - the client should NOT send the final ACK of the = TWHS - until the SYN-ACK is received *and* confirmation that the FBP has = been received. That can happen together inside the SYN-ACK if known, or = the SYN-ACK would say "FBP missing" and the client would retransmit the = FBP *until* the server confirms it (it would send an option = confirmation, not an ACK). > I would take the view that if the FBP is late there's a chance it got = snarled up in a middlebox, and it will never get through no matter how = many times it's retransmitted. The client can timeout, and can retry without the extended SYN space in = that case. > Rather than make the choice between latency and completeness at = protocol design time, we need a flag in either scheme (on the DSO or ASO = option) for the client to say which it wants. Then: > * the client can choose latency if it knows the extra_opts are not = critical. > * otherwise it can choose completeness, and if it doesn't work after a = retransmit or two, the client won't block for ever; it can work out the = compromise set of options that fit in a single SYN but still 'work'. A flag that says "do what a legacy server would do if you have to wait X = ms" seems fine to me too. >>> I'm still thinking as to whether the ACK number >>> might indicate whether FBP has been received, >>=20 >> There are a few ways to handle this, but IMO the best is to have: >>=20 >> SYN-ACK aso with length=3D2 means "waiting for FBP" >>=20 >> SYN-ACK aso with length=3D3 (or 4) could mean >> "got the FBP", or might even indicate how >> many bytes the FBP extension contained >>=20 >> Note - the SYN-ACK and all subsequent segments can assume that aso =3D=3D= edo, i.e., they can use the same EDO as spec'd in version 01 of this = draft. >>=20 >>> This is cleaner as follows: >>>=20 >>> - no need for conn_id coordination >>>=20 >>> - no need for conn_id to consume option space for fall-back >>>=20 >>> - avoids double-load for legacy servers >=20 > With a typical legacy server that reflects SYN cookies, less activity = is doubled: > * my scheme: sends out two SYN cookies > * your scheme: sends out one SYN cookie and drops one packet, probably = after a long chain of logic, because the FBP is an unusual packet. The activity involved in parsing a packet is small compared to that of = setting up a SYN cookie or creating TCB state (where SYN cookies aren't = used). >>> - no problem with fate-sharing >=20 > To be as consistently pessimistic as you were with my scheme, I think = you mean that you have created machinery to synthesise fate sharing = between a connection and an invalid segment, and it may not work in = cases that you may not have thought of. Your scheme uses two different SYNs on different ports - that's a recipe = for fates NOT being shared. Mine uses two segments on the same addresses with the same ports - if = they're not fate-shared, then neither will the rest of the TCP = connection be, and TCP won't work (if that fate matters, e.g., through = different NATs). >>> - traverses a NAT just fine >=20 > As above, surely TCP normalising middleboxes and incoming stateful = firewalls at the server end are likely to discard the FBP. I don't think so, but I agree we'll have to try. This is a completely = different situation, IMO, than expecting boxes that *already* are known = to validate TCP checksums to do otherwise. In this case, we don't *know* = the solution won't work from the start. >>> Upgraded servers still need to wait for the 'seg', but they could = get >>> that retransmitted if necessary. >=20 > See discussion of latency vs completeness dilemma above. Latency vs. completeness is true for all variants that use multiple = packets - that's one reason I don't like that aspect of any of these = approaches. >> And there's a small amount of additional processing to discard the = FBP at legacy endpoints, but silently discarding one packet per = connection doesn't seem like a huge effort to me. >=20 > Despite this being an exceptional drop (see earlier), this is still a = reasonably fair statement. And I'm glad to concede that we don't know the cost on the code cache, = etc. of exercising a dusty, dark path of processing.=20 >> Note - there's no special RST processing, based on Ted's observation = about "data without ACK" being considered "data sent in the = unsynchronzed state" -- something legacy TCP explicitly silently = discards. >=20 > ...at least in theory. And in requirements. Yes, I'll see if I can find out what BSD and Linux = do - though I have more hope of BSD being correct than Linux. Joe= From nobody Sat May 31 15:35: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 C4F161A0117 for ; Sat, 31 May 2014 15:35:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.652 X-Spam-Level: X-Spam-Status: No, score=-4.652 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651, 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 aB22I02k6c2W for ; Sat, 31 May 2014 15:35:10 -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 0D9F91A011C for ; Sat, 31 May 2014 15:35:09 -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; Sat, 31 May 2014 23:34:57 +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; Sat, 31 May 2014 23:35:02 +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; Sat, 31 May 2014 23:35:00 +0100 Received: from BTP075694.jungle.bt.co.uk ([10.111.109.114]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id s4VMYwGW004526; Sat, 31 May 2014 23:34:58 +0100 Message-ID: <201405312234.s4VMYwGW004526@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sat, 31 May 2014 23:34:56 +0100 To: Joe Touch From: Bob Briscoe In-Reply-To: <538A2B96.3030900@isi.edu> References: <20140425221257.12559.43206.idtracker@ietfa.amsl.com> <2586_1398464386_535ADF82_2586_915_1_535ADF56.9050106@isi.edu> <5363AF84.8090701@mti-systems.com> <5363B397.8090009@isi.edu> <655C07320163294895BBADA28372AF5D2CFE36@FR712WXCHMBA15.zeu.alcatel-lucent.com> <20140503122950.GM44329@verdi> <655C07320163294895BBADA28372AF5D2D009E@FR712WXCHMBA15.zeu.alcatel-lucent.com> <201405221710.s4MHAY4S002037@bagheera.jungle.bt.co.uk> <537E3ACD.5000308@isi.edu> <1AD79820-22C1-4500-84D1-1383F264D68C@weston.borman.com> <201405231213.s4NCDa5P005525@bagheera.jungle.bt.co.uk> <537F8202.4020907@isi.edu> <201405281715.s4SHFMm0014634@bagheera.jungle.bt.co.uk> <538623B9.2060209@isi.edu> <201405301642.s4UGgcvY030471@bagheera.jungle.bt.co.uk> <5388EB6F.4010405@isi.edu> <201405311819.s4VIJt2V003823@bagheera.jungle.bt.co.uk> <538A2B96.3030900@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/SAXyvQG_wibDABLyo6vy9sviCY8 Cc: "tcpm@ietf.org" Subject: Re: [tcpm] More TCP option space on SYNs 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: Sat, 31 May 2014 22:35:14 -0000 Joe, At 20:20 31/05/2014, Joe Touch wrote: >Hi, Bob, > >On 5/31/2014 11:19 AM, Bob Briscoe wrote: >>Joe, >> >>Thx for consolidating this thread. I've given it a new subject line. >> >>1) You've silently made an important alteration to the proposed >>protocol. You've put the extra-options directly in the TCP option space >>of the C-SYN, not within the payload. > >I hadn't assumed that; I was describing only which SYN carried which >options, not where they were. As you do, I was assuming the C-SYN >options were in the data space. OK. >To be clear, in my variant - using data outside the sync'd >connection (with ACK clear), the option space is similarly in the >data portion of the 'extra' segment. Yup, that was understood already. >>Yes, your altered proposal is cleaner. However, don't imagine I didn't >>think of this. I did and I deliberately didn't do it this way.We have a >>choice: >> clean and vulnerable vs. messy but robust. >> >>I'm not wedded to using port 80 and http headers, but this is perhaps >>the most pragmatic approach. > >That's fraught with a whole slew of other problems, notably the >middleboxes that currently try to translate, proxy, or otherwise >modify anything they see as port 80. > >Further, that would limit the number of pending connections. > >>It will be really unorthodox to define such >>a protocol I know. We would have to say something like >> >> "The dst port of the C-SYN MUST be 80, and the payload MUST start >> with the constant magic_token, where >> magic_token = 'PUT / HTTP/1.1Connection : DSO' >> " >> >>I'm sorry if even thinking about this makes you feel dirty :| >> >>Other suggestions for inner protocols are welcome, including tunnelled >>protocols, as long as middleboxes widely forward them, given their dst >>port. > >I don't see what this gets us other than potential interactions. >There's no reason to use HTTP to format TCP options, and it would >necessitate new encodings and new processing for existing options >that might end up in the extended space. To be clear, I would put the general requirement as : " Pick a port number, then make sure the app-layer headers at the start of the TCP payload appear valid for that port number, so that middleboxes will forward it, then include the extra TCP options as the body of this faked up app-layer protocol. " Then the dilemma becomes: pick a number, any number as long as it's 80. The alternative is often to be blocked. Particularly if you connect from inside a company that has bought one of those myopic Web gateways, or you connect to a cellular network, or... you just connect to the Internet via a box from a vendor beginning with a letter in the alphabet,... or a digit. >>2) The main problem with your notation is it doesn't say /where/ the >>info is placed. > >EDO says the options are at the head of the data segment, just with >a longer pointer - the same way as current options. > >For extending the SYN using a separate segment - whether a C-SYN or >unsync'd data segment - the data similarly comes at the head of the >data, just that there's no user data permitted after it. I understood all this. I just meant that the notation you introduced in your email didn't have the facility to specify at which layer fields were placed. >>I've added notation as follows: >>TCP(base header [TCP options [APP(header[payload])]]) >> >>And for the record I've made the if-else logic clearer. >> >>Where I've made more than clarifying edits inline, I've described them >>and tagged them with [BB]. >> >>At 21:34 30/05/2014, Joe Touch wrote: >>>Hi, Bob, >>> >>>Let's get back to the core, in a simpler fashion, so other can follow it. >>> >>>I stand by my "there's no way to extend the space in the initial SYN", >>>but you've convinced me there *might* be a way to provide extended >>>space that can occur during the first phase of the TWHS. I think the >>>dual-SYN approach still isn't viable, but I've outlined an alternative >>>below that's similar but doesn't have the same baggage, IMO. >>> >>>Again, I'm still concerned by what midboxes might do to this... >>> >>>What do others think?? >>> >>>Joe >>> >>>For quick review, here's what I understand: >>> >>> dso = dual-syn option >>> dso-D = data >>> dso-C = control >>> conn_id = identifier to link the two SYNs together >>> extra_opt = options that didn't fit in legacy SYN >>> fit_opt = options that do fit in the legacy SYN >> new client endpoint sends >> TCP(port A SYN [dso-D(conn_id) + fit_opt] ) >> TCP(port B SYN [dso-C [APP(headers [conn_id + >>extra_opt] ) ] ] ) > >IMO, the conn_ID in the C-SYN should similarly be in the regular >option space, but I don't think it matters. > >>[BB]: i/APP(headers...)/ >> >> if (legacy server endpoint) { sends back two >>connections: >> TCP(port A SYN-ACK [fit_opt] ) >> TCP(port B SYN-ACK [??] ) >>> (it's interpretation of extra_opt) > >I'm assuming EDO after the SYN, which means the SYN-ACK has as much >space as it wants for options, as would every other segment. > >> new client endpoint responds: >> TCP(port A ACK) (established) >> TCP(port B RST) >> >>> Notes about legacy servers: >>> - they do twice the work on SYNs >>> - they might keep twice the state >>> (if not using cookies) >>> - they might clean state if the RST >>> is received, but that state might >>> persist indefinitely (until the next >>> connection, depending on timeouts, etc.) >>> >>> ----- >> } elif (new server endpoint) { sends back one >>connection: >> TCP(port A SYN-ACK [edo + fit_opt + >>extra_opt] ) >> >>[BB]: s/dso-d/edo/ > >Sure. At this point we're basically in EDO-land. > >> new client endpoint responds: >> TCP(port A ACK) (established) >> >>> >>> Notes: >>> - can stall when dso-D SYN arrives >>> before dso-C SYN, up to some limit >>> - twice the work on SYNs (or more) >> } >> >>>Here's what I was assuming, though admittedly it's not documented (yet): >>> >>> - no significant impact on TCP connection rate for >>> legacy servers >>> >>> - no significant impact on TCP connection rate for >>> legacy clients >>> >>> - impact dominated by processing the extended option space >>> for extended clients >>> >>> - impact dominated by processing the extended option space >>> for extended servers >>> >>> - compatible with typical TCP processing optimizations, >>> notably SYN cookies >>> you did provide a potential way forward for these >>> >>> - capable of successfully traversing typical NATs >>> >>>Your approach has the following properties: >> >>The 3 bullets below are not useful ways to describe performance impact. >>They selectively describe whichever gives the most pessimistic picture >>out of: >>a) either the instantaneous performance change at the moment of connection >>b) or the worst-case long-run performance impact >> >>They don't describe the average long-run performance impact, which is >>important for sizing machines. >> >>Worse, the instantaneous performance impact is only significant when a >>machine's SYN processing time is large relative to the e2e delay, which >>would be a highly unusual scenario on public networks (even in scenarios >>such as intra-data-centre, it's hard to reduce e2e delay to approach SYN >>processing time, but you could for intra-machine connections). > >SYN processing is a known load - and potential overload - on >machines. That's why it's reasonable to focus on it. But we should primarily think in terms of SYN cookie processing for legacy hosts, and the equivalent for upgraded hosts. We should design thia as the norm, not the exception. Possibly the /only/ way to implement this new form of SYN processing. Then, for the dual-SYN scheme, the upgraded host doesn't have a normal SYN cookie processing load with a C-SYN, so we can no longer rely on known-load formulae. >>> - halves the server connection rate for updated servers >>> from legacy clients when this option is in use >> >>Eh? The long-run server connection rate will be fractionally decreased >>due to updated clients using extra options (which is your third case >>below), but the instantaneous server connection rate seen by a legacy >>client is unchanged, because it only sends one SYN. > >Agreed. I was doing too many of these at once... > >>> - lowers (to some extent, if not halves) the client >>> connection rate of updated clients to all servers >>> when this option is in use >>> >>> - halves (roughly) the server rate for all servers >>> when this option is in use >> >>Nope. All long-run server rates are reduced by 1/(1+e), where e is the >>fraction of connections using extra options. > >the rate for connections when this option is in use is halved - I >didn't see that the sentence above could be parsed the other way. >the overall rate depends on the fraction of connections using the option. > >>>It also: >>> >>> - doubles the number of SYNs in the network >> >>Nope. The number of SYNs in the network is inflated by e where e is the >>fraction of connections using extra options. > >You keep bringing this up - I don't like a solution that should be >used only a little. If it works, we should assume it works >everywhere all the time. It doesn't make sense to predict that all connections will always use MSS, timestamp, SACK, window-scale, MPTCP, TCP-AO, new option X, new option y, etc etc. For a start, less than 1% of connections contain enough packets to make MPTCP worth starting. The word option means optional. >>> - susceptible to lack of fate-sharing problems, e.g., >>> if the two SYNs experience different firewall configurations >> >>Nope. It's fairer to say it's potentially susceptible to second-order >>fate-sharing problems like your firewall example (the first-order fate >>sharing problems have been addressed). > >I have no idea why you think firewalls are a second-order >fate-sharing, or what that even means. Fate sharing means fate is >shared. When fate is not shared by the SYNs, this method has >problems. There's no mechanism to recover the missing D-SYN or C-SYN. What I mean by first-order fate-sharing problems is those obvious cases (reordering, drop) that we have addressed by resynthesising fate sharing. There is certainly a possibility that two SYNs between the same endpoints will pass through different firewalls, but it is small in the Internet as a whole. There is a further possibility that these two firewalls will be configured differently, but it is small. There is a further possibility that the differences in configuration will be significant enough to distinguish the behaviour wrt the two SYNs, but it is small. When three small probabilities are multiplied together, you get a really small probability. This is what I call a second-order fate-sharing problem. You must surely see that it is inconsistent to say: * "this method has problems" about the DSO idea, based on such a corner case * "no problem with fate-sharing" about the ASO idea, when all you mean is that the FBP will follow the same path as the SYN, and they will therefore likely pass through the same devices. In the ASO proposal, splitting the options on a SYN over two packets, one of which is considered invalid by TCP, will cause the FBP to be discarded by numerous TCP normalisers and stateful firewalls. That is a fate sharing problem of the first order. Likely to be on a much larger scale than the 'second-order' firewall problem above. >>> - reduces the space available for fit_opt due to the need >>> for the conn_id even in the fall-back D-SYN, which means >>> less option space in the SYNs for fall-back connections >> >>Yup. >> >> >>> the conn_id which may need to be very large because it >>> needs to be unique per source port and source IP address >>> because that information is lost during NAT translation >> >>Given many NATs will typically make the src IPs of both SYNs the same, I >>suggest a larger conn_id should be a fall-back option for the client, >>not a default. > >Multiple NATs are quite common - carrier grade NATs in the net, and >user NATs at the home WIFI point. > >Any multiple-NAT, or any path through even a single carrier-grade >NAT will end up potentially un-doing or over-doing source IP >overlap, creating false positives and false negatives that break >this mechanism. > >That's really the crux - fate sharing and the need to bind the two >SYNs - that make this untenable, IMO. > >>Even if the src IPs of both SYNs are different once they reach the >>server, the high end bits will invariably be the same. > >You can't know this - the two SYNs could have gone through different >numbers of NATs or different NATs entirely, so the bits could change >arbitrarily. That's what 'invariably' means. I'm not claiming this works 100%. I am saying I expect it to work sufficiently to be worth trying it out to see if I'm right. If it doesn't work, on some paths, the fall-back has been described - the client has to rely on the TCP options it can fit in a single SYN. >>So the max size >>of the contents of the DSO TCP option can be 6B, and the server can take >>the rest of conn_id from the higher bits of the src IP addr of each SYN. >>This is a variant of the idea in . > >FWIW, you're now in the land where we would have to start explaining >the privacy and tracking implications of those bits. I'd really like >to avoid that. Nope. I think you're reading this the wrong way round. I'm not revealing private IDs in TCP option fields. I'm reducing the size of the (random) conn_id in cases where the /public/ src port or the upper bits of the /public/ src IP have sufficient entropy to be used to construct the rest of the conn_id. I was acknowledging Dan Wing 'cos he gave us the idea. But it's a /variant/ that doesn't reveal anything private. I'm going offline, possibly until Tue now. Regards Bob >>In fact, the server doesn't even need a small conn_id for clients that >>know they are not behind a NAT and that want more option space in the >>D-SYN - then the server could use the src port & src IP for the conn_id. >> >>To summarise, these options could be distinguished by the length field >>of the dual-syn option. >>Length = 2B => conn_id = src netaddr + src port >>Length = 6B = 2B +4B conn_id_short => conn_id = src netaddr + >>conn_id_short >>Length = 8B = 2B +6B conn_id_long => conn_id = hsb(src netaddr) + >>conn_id_long >> >>Given there have been numerous other attempts to reveal a connection ID >>that is preserved through middleboxes [RFC6967], rather than defining a >>dual-syn option that carries a conn_id, we might want to design a TCP >>connection ID option with a flag to say whether it is also part of a >>dual SYN pair or not. >> >>Where >>* hsb(src netaddr) is the netaddr with the lowest 16 bits truncated >>* src netaddr is the network address (IPv4, IPv6, or any other network >>protocol) >> >>To reduce latency, a host could use the default short_conn_id for all >>connections at first, then: >>- if it finds that DSO persistently doesn't work it falls back to the >>long_conn_id for all connections >>- it occasionally tests the short and zero options to see if it can use >>shorter DSO options. >> >> >>> - requires the ISNs to be related (see RFC6528 - if there's >>> a rule to generate it, there will be code to validate that >>> rule, and eventually a BCP to encourage that validation - >>> typically from the same RFC author) >> >>Eh? The ISNs can and should be independent. To be robust against >>middleboxes that rewrite sequence numbers, we must not required ISNs to >>be related. >> >> >>>I agree that you have proposed potentially viable ways to deal with >>>the SYN cookie, and that RST state is not an issue. >> >>A feature that I think it's fair to add: >> - Good chance of passing through app-layer middleboxes that >>forward >> unrecognised TCP options unchanged, but not those that discard >>them. >> >> >>>However, there are too many problems with this, IMO, to call it viable. >> >>Once your over-pessimistic analyses of the performance impact are >>corrected, and my ideas to reduce the size of the conn_id are taken into >>account, it's a different story. >> >>But it's up to the WG to decide whether this is worth taking further. >>Not just you or I. > >Agreed. > >>>Here's another trick that might clean up the above a little: >> >>>with ACK=0> >> >>Cheers >> >> >>Bob >> >> >>________________________________________________________________ >>Bob Briscoe, BT > >________________________________________________________________ >Bob Briscoe, BT From nobody Sat May 31 15:45: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 3E6AF1A011F for ; Sat, 31 May 2014 15:45:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.252 X-Spam-Level: X-Spam-Status: No, score=-3.252 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651, 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 HTHkb5qVEBRy for ; Sat, 31 May 2014 15:45:45 -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 1A2521A011C for ; Sat, 31 May 2014 15:45:44 -0700 (PDT) Received: from EVMHR01-UKBR.domain1.systemhost.net (193.113.108.40) by EVMHR03-UKBR.bt.com (10.216.161.35) with Microsoft SMTP Server (TLS) id 8.3.348.2; Sat, 31 May 2014 23:45:34 +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; Sat, 31 May 2014 23:45:38 +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; Sat, 31 May 2014 23:45:38 +0100 Received: from BTP075694.jungle.bt.co.uk ([10.111.109.114]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id s4VMjaen004557; Sat, 31 May 2014 23:45:36 +0100 Message-ID: <201405312245.s4VMjaen004557@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sat, 31 May 2014 23:45:34 +0100 To: Joe Touch From: Bob Briscoe In-Reply-To: <6C4E6E63-F3F4-4364-9459-794957DC8799@isi.edu> References: <20140425221257.12559.43206.idtracker@ietfa.amsl.com> <2586_1398464386_535ADF82_2586_915_1_535ADF56.9050106@isi.edu> <5363AF84.8090701@mti-systems.com> <5363B397.8090009@isi.edu> <655C07320163294895BBADA28372AF5D2CFE36@FR712WXCHMBA15.zeu.alcatel-lucent.com> <20140503122950.GM44329@verdi> <655C07320163294895BBADA28372AF5D2D009E@FR712WXCHMBA15.zeu.alcatel-lucent.com> <201405221710.s4MHAY4S002037@bagheera.jungle.bt.co.uk> <537E3ACD.5000308@isi.edu> <1AD79820-22C1-4500-84D1-1383F264D68C@weston.borman.com> <201405231213.s4NCDa5P005525@bagheera.jungle.bt.co.uk> <537F8202.4020907@isi.edu> <201405281715.s4SHFMm0014634@bagheera.jungle.bt.co.uk> <538623B9.2060209@isi.edu> <201405301642.s4UGgcvY030471@bagheera.jungle.bt.co.uk> <5388EB6F.4010405@isi.edu> <5389263C.8010202@isi.edu> <201405312113.s4VLDEbG004301@baghee! ra.jungle.bt.co.uk> <6C4E6E63-F3F4-4364-9459-794957DC8799@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/3sbMeJz0G6RzDzPfpgBi6WWkJIY Cc: "tcpm@ietf.org" Subject: Re: [tcpm] SYN extension using ACK=0 data packets 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: Sat, 31 May 2014 22:45:49 -0000 Joe, Nothing further to add on this thread. I do think you're seeing the ASO scheme thru rose-coloured spectacles. Cheers Bob At 23:01 31/05/2014, Joe Touch wrote: >Hi, Bob, > >On May 31, 2014, at 2:13 PM, Bob Briscoe wrote: > > > Joe, > > > > Hope it's ok to have changed the subject line, with tcpm still in cc. > > > > I'm afraid I'm not as excited about ACK=0 as you are. It's > certainly cleaner than anything we've come up with so far. > > > > However, I see the goal as finding a way to send a supplement to > a SYN that is invalid in some way to legacy TCP servers, but likely > to appear valid to many/most middleboxes. I suspect many > middleboxes and firewalls will discard the ACK=0 segment. > > > > When assessing the DSO scheme, you were adamant that anything > invalid to an endpoint would always eventually become invalid to > middleboxes. In the excitement of finding a nice clean way of doing > ASO, that critique seems to have suddenly become unimportant. > >I worry about checksums in particular - which get recalculated, so >using a different checksum means we're sure to fail through a >middlebox that doesn't recalculate it properly (if it's stored in a >new place), or that won't validate it (if it's in the current checksum field). > >I can't say that middleboxes don't check for ACK=0 packets, but it >seems a lot of work to do unless they're perceived to be an issue. I >doubt they look at the ACK at all unless the SYN or FIN is set. > > > Whatever, there may be a place for both solutions: > > a) ASO (ACK=0) for paths where a NAT might be the worst middlebox > on the path > > b) DSO for paths with stateful firewalls, TCP normalisers etc. > >DSO is better through stateful firewalls only when the FBP packet >precedes the SYN. Keep in mind that the FBP can also be sent >multiple times after the SYN anyway, with small (1ms) delays; only >the first will end up being used, and loss of all of them would >still be recoverable. > > > The cellular world is certainly more like (b). > >Cellular uses GGN (carrier-grade NATs), which could make DSO SYN >pairing more difficult. > > > Whether there are many parts of the public Internet left like (a) > is unclear. (b) seems to have become the norm for most paths. > >If we're counting numbers, there are a *lot* more hosts behind NATs. >The ones behind CGNs probably swamp all others combined. > > > More inline... > > > > At 01:45 31/05/2014, Joe Touch wrote: > >> Hi, all, > >> > >> Some additional information below about "another trick" I > proposed, inspired by Bob's dual-SYN mechanism, courtesy a few long > discussions today with Ted Faber. > >> > >> I'll be glad to offer this as a potential solution in the doc. > >> > >> Joe > >> > >> On 5/30/2014 1:34 PM, Joe Touch wrote: > >> ... > >>> Here's another trick that might clean up the above a little: > >> > >> FWIW, I had explained it below as being based on sending > out-of-window data; Ted pointed out that I had been assuming that > the FBP ACK bit wasn't set - which means the sequence number might > be more usefully matched to that of the SYN. > >> > >> See below... > >> > >>> aso - after SYN option > >> > >> length = 2 (just a flag) > >> length = 3 (or 4) indicating the length of the > >> FBP expected > >> > >>> FBP - front bumper packet (best I could do on names today) > >>> a packet > >> ISN = same as the associated SYN > >> ACK = cleared (i.e., a data packet NOT part of > >> synchronized connection - see why that's useful below) > > > > For the avoidance of doubt, > > I assume these two packets have the same src port. > >Same IP addresses, same ports, *because* they're associated with the >same connection. > > > and I assume the FBP has SYN=0. > >Yes. All control bits are 0, including ACK. > > > Coincidentally, a couple of weeks ago, when I was looking for > places to find more bits in the TCP header, I noted that during an > established connection ACK=0 is never used, so I looked into > setting ACK=0 and overloading the ack_number field. > > > > > >>> new endpoint sends: > >>> > >>> SYN + aso + fix_opt > >>> FBP + aso + extra_opt > >> > >> extra_opt in the data field > >> total length < min MTU (576 for IPv4, 1280 for IPv6) > >> again ACK bit is zero > >> > >>> legacy endpoint sends back one connections: > >>> SYN-ACK + fix_opt > >>> > >>> if seg arrives before SYN, > >> > >> it is silently dropped, because > >> the ACK bit is clear (this is > >> explicit in RFC793) > >> > >>> if seg arrives after SYN, > >> > >> it is silently dropped, because > >> the ACK bit is clear (this is also > >> explicit in RFC793) > > > > Two important questions: > > 1) are most/all legacy TCP implementations faithful to the spec? > >That's something I'll take a look at. > > > 2) if a TCP endpoint is meant to drop SYN=0, ACK=0, then many > middleboxes surely will. > >Middleboxes drop things whose checksum fails, or when a packet comes >in for a connection that hasn't been established. They don't go out >of their way to do a lot of other work AFAICT. > > > Both these will need experimental testing. > >Certainly. > > > Nit: I wouldn't exactly say RFC793 is clear. You have to follow 2 > pages of quite imprecise descriptive logic, starting from p66. But, > yes it is eventually fairly unambiguous. Paraphrasing, it says: > > > > SEGMENT ARRIVES > > ... > > if state = SYN-SENT > > 1. Check ACK bit > > if ACK = 1 > > do stuff > > 2. Check RST bit > > if RST = 1 > > if ACK OK enter CLOSED state > > elif no ACK, drop > > 3. Check security & precedence > > Do stuff > > 4. Check SYN bit > > Should only get here if ACK OK, or no ACK and no RST > > if SYN = 1 > > do stuff > > 5. if SYN = 0 and RST = 0 > > drop > >In CLOSED, it says to send a RST (like any other packet for a non-connection). > >In LISTEN, it says: > > Any other control or text-bearing segment (not containing SYN) > must have an ACK and thus would be discarded by the ACK > processing. An incoming RST segment could not be valid, since > it could not have been sent in response to anything sent by this > incarnation of the connection. So you are unlikely to get here, >(where 'here' is a segment with ACK=0 and no other control bits set) > but if you do, drop the segment, and return. > >In SYN-SENT, it says: > > fifth, if neither of the SYN or RST bits is set then drop the > segment and return. > >In all other states, it says: > > if the ACK bit is off drop the segment and return > >If that's not direct and explicit, I don't know what is. > > >>> ---- > >>> > >>> new endpoint sends back one connection: > >>> > >>> SYN-ACK + options + .... > >>> > >>> a) if FBP arrives before SYN, > >> > >> it can be silently dropped, but > >> it's probably useful for new endpoints > >> to hold onto these (without action) > >> for a while; they can be silently > >> discarded if there are too many > >> (which will just result in a > >> retransmission and an extra RTT) > >> > >>> b) if FPB arrives with the SYN, they can be > >>> processed together > > > > By 'arrives with' I assume you mean 'within some time duration'. > >Yes - I was thinking of the case where the FBP is either cached (as >per (a)), or is in the segment queue at the time the SYN is being processed. > > >>> the SYN-ACK can include responses to > >>> the extra_opts in addition to the > >>> fix_opts, and says "FBP received" > >>> > >>> > >>> c) if FPB arrives after the SYN: > >>> > >>> SYN-ACK proceeds, but sends > >>> back "wait for option response". > >>> > >>> at this point, the source re-sends FBP > >>> until an ACK is received that indicates > >>> "FBP received", or times-out as with > >>> any connection that doesn't finish TWHS > > > > There's a dilemma whether the server: > > * prioritises latency and goes ahead without the extra options, > > * or prioritise completeness and blocks until the extra options arrive. > >There's no dilemma - if the SYN says "FBP is coming", then it means >that an upgraded server MUST wait for the FBP. > >I.e., the FBP is paired with the SYN-ACK, and the handshake doesn't >complete at the client - the client should NOT send the final ACK of >the TWHS - until the SYN-ACK is received *and* confirmation that the >FBP has been received. That can happen together inside the SYN-ACK >if known, or the SYN-ACK would say "FBP missing" and the client >would retransmit the FBP *until* the server confirms it (it would >send an option confirmation, not an ACK). > > > I would take the view that if the FBP is late there's a chance it > got snarled up in a middlebox, and it will never get through no > matter how many times it's retransmitted. > >The client can timeout, and can retry without the extended SYN space >in that case. > > > Rather than make the choice between latency and completeness at > protocol design time, we need a flag in either scheme (on the DSO > or ASO option) for the client to say which it wants. Then: > > * the client can choose latency if it knows the extra_opts are > not critical. > > * otherwise it can choose completeness, and if it doesn't work > after a retransmit or two, the client won't block for ever; it can > work out the compromise set of options that fit in a single SYN but > still 'work'. > >A flag that says "do what a legacy server would do if you have to >wait X ms" seems fine to me too. > > >>> I'm still thinking as to whether the ACK number > >>> might indicate whether FBP has been received, > >> > >> There are a few ways to handle this, but IMO the best is to have: > >> > >> SYN-ACK aso with length=2 means "waiting for FBP" > >> > >> SYN-ACK aso with length=3 (or 4) could mean > >> "got the FBP", or might even indicate how > >> many bytes the FBP extension contained > >> > >> Note - the SYN-ACK and all subsequent segments can assume that > aso == edo, i.e., they can use the same EDO as spec'd in version 01 > of this draft. > >> > >>> This is cleaner as follows: > >>> > >>> - no need for conn_id coordination > >>> > >>> - no need for conn_id to consume option space for fall-back > >>> > >>> - avoids double-load for legacy servers > > > > With a typical legacy server that reflects SYN cookies, less > activity is doubled: > > * my scheme: sends out two SYN cookies > > * your scheme: sends out one SYN cookie and drops one packet, > probably after a long chain of logic, because the FBP is an unusual packet. > >The activity involved in parsing a packet is small compared to that >of setting up a SYN cookie or creating TCB state (where SYN cookies >aren't used). > > >>> - no problem with fate-sharing > > > > To be as consistently pessimistic as you were with my scheme, I > think you mean that you have created machinery to synthesise fate > sharing between a connection and an invalid segment, and it may not > work in cases that you may not have thought of. > >Your scheme uses two different SYNs on different ports - that's a >recipe for fates NOT being shared. > >Mine uses two segments on the same addresses with the same ports - >if they're not fate-shared, then neither will the rest of the TCP >connection be, and TCP won't work (if that fate matters, e.g., >through different NATs). > > >>> - traverses a NAT just fine > > > > As above, surely TCP normalising middleboxes and incoming > stateful firewalls at the server end are likely to discard the FBP. > >I don't think so, but I agree we'll have to try. This is a >completely different situation, IMO, than expecting boxes that >*already* are known to validate TCP checksums to do otherwise. In >this case, we don't *know* the solution won't work from the start. > > >>> Upgraded servers still need to wait for the 'seg', but they could get > >>> that retransmitted if necessary. > > > > See discussion of latency vs completeness dilemma above. > >Latency vs. completeness is true for all variants that use multiple >packets - that's one reason I don't like that aspect of any of these >approaches. > > >> And there's a small amount of additional processing to discard > the FBP at legacy endpoints, but silently discarding one packet per > connection doesn't seem like a huge effort to me. > > > > Despite this being an exceptional drop (see earlier), this is > still a reasonably fair statement. > >And I'm glad to concede that we don't know the cost on the code >cache, etc. of exercising a dusty, dark path of processing. > > >> Note - there's no special RST processing, based on Ted's > observation about "data without ACK" being considered "data sent in > the unsynchronzed state" -- something legacy TCP explicitly silently discards. > > > > ...at least in theory. > >And in requirements. Yes, I'll see if I can find out what BSD and >Linux do - though I have more hope of BSD being correct than Linux. > >Joe ________________________________________________________________ Bob Briscoe, BT