From Michael.Scharf@alcatel-lucent.com Thu Sep 1 00:13:26 2011 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAF5721F8AF0 for ; Thu, 1 Sep 2011 00:13:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.197 X-Spam-Level: X-Spam-Status: No, score=-6.197 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KBX1Q6hNYdrM for ; Thu, 1 Sep 2011 00:13:26 -0700 (PDT) Received: from mailrelay2.alcatel.de (mailrelay2.alcatel.de [194.113.59.96]) by ietfa.amsl.com (Postfix) with ESMTP id 917D621F8AE9 for ; Thu, 1 Sep 2011 00:13:23 -0700 (PDT) Received: from SLFSNX.rcs.alcatel-research.de (slfsn1.rcs.de.alcatel-lucent.com [149.204.60.98]) by mailrelay2.alcatel.de (8.14.3/8.14.3/ICT) with ESMTP id p817EqlQ029631 for ; Thu, 1 Sep 2011 09:14:52 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 1 Sep 2011 09:14:11 +0200 Message-ID: <133D9897FB9C5E4E9DF2779DC91E947C066832D1@SLFSNX.rcs.alcatel-research.de> In-Reply-To: <4E5E5A34.1030707@isi.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] Extending TCP option space Thread-Index: Acxn9vIy/mvA5xlASRyva2z7bC0nkQAfnIQw References: <4E5E5A34.1030707@isi.edu> From: "SCHARF, Michael" To: X-Scanned-By: MIMEDefang 2.69 on 149.204.45.73 Subject: Re: [tcpm] Extending TCP option space X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 01 Sep 2011 07:13:26 -0000 > In a nutshell: >=20 > - extending option space after then TWHS is trivial > define a new option, confirm it with a SYN exchange, > and either the SYN gets dropped (some midboxes), > the option is dropped (others), or it works. >=20 > if the SYN is retransmitted, retransmit without the > option and tell the user it failed ;-( And, just to mention an obvious alternative: Unless one needs reliable transport one can always piggyback options <=3D40B individually to empty ACKs. And if one needs options >40B after SYNs: Maybe we could just run TCP with MSS=3D40B inside the option channel ;) Michael From wes@mti-systems.com Thu Sep 1 06:11:10 2011 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DADF21F9E5F for ; Thu, 1 Sep 2011 06:11:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id utG7VWYPAfrU for ; Thu, 1 Sep 2011 06:11:06 -0700 (PDT) Received: from omr1.networksolutionsemail.com (omr1.networksolutionsemail.com [205.178.146.51]) by ietfa.amsl.com (Postfix) with ESMTP id 0F59021F9E5E for ; Thu, 1 Sep 2011 06:11:05 -0700 (PDT) Received: from cm-omr14 (mail.networksolutionsemail.com [205.178.146.50]) by omr1.networksolutionsemail.com (8.13.6/8.13.6) with ESMTP id p81DCadG023300 for ; Thu, 1 Sep 2011 09:12:38 -0400 Authentication-Results: cm-omr14 smtp.user=wes@mti-systems.com; auth=pass (PLAIN) X-Authenticated-UID: wes@mti-systems.com Received: from [107.50.244.189] ([107.50.244.189:8515] helo=[68.245.171.115]) by cm-omr14 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id E7/CB-09278-3C48F5E4; Thu, 01 Sep 2011 09:12:36 -0400 Message-ID: <4E5F84C4.9050606@mti-systems.com> Date: Thu, 01 Sep 2011 09:12:36 -0400 From: Wesley Eddy Organization: MTI Systems User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0.1) Gecko/20110830 Thunderbird/6.0.1 MIME-Version: 1.0 To: tcpm@ietf.org References: <4E5E5A34.1030707@isi.edu> <133D9897FB9C5E4E9DF2779DC91E947C066832D1@SLFSNX.rcs.alcatel-research.de> In-Reply-To: <133D9897FB9C5E4E9DF2779DC91E947C066832D1@SLFSNX.rcs.alcatel-research.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [tcpm] Extending TCP option space X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 01 Sep 2011 13:11:10 -0000 On 9/1/2011 3:14 AM, SCHARF, Michael wrote: >> In a nutshell: >> >> - extending option space after then TWHS is trivial >> define a new option, confirm it with a SYN exchange, >> and either the SYN gets dropped (some midboxes), >> the option is dropped (others), or it works. >> >> if the SYN is retransmitted, retransmit without the >> option and tell the user it failed ;-( > > And, just to mention an obvious alternative: Unless one needs reliable > transport one can always piggyback options<=40B individually to empty > ACKs. > > And if one needs options>40B after SYNs: Maybe we could just run TCP > with MSS=40B inside the option channel ;) > I don't have a better reference, but that's essentially what these guys did for the "in-band, secondary data channel" mentioned on slide 9 of this presentation: http://www.saloits.com/papers/SIW-ETA2004.pdf I'm not sure if there was IPR or not. -- Wes Eddy MTI Systems From wes@mti-systems.com Thu Sep 1 06:55:20 2011 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2743321F9910 for ; Thu, 1 Sep 2011 06:55:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hXT38VG-sdrr for ; Thu, 1 Sep 2011 06:55:19 -0700 (PDT) Received: from omr12.networksolutionsemail.com (omr12.networksolutionsemail.com [205.178.146.62]) by ietfa.amsl.com (Postfix) with ESMTP id 5266221F990C for ; Thu, 1 Sep 2011 06:55:19 -0700 (PDT) Received: from cm-omr14 (mail.networksolutionsemail.com [205.178.146.50]) by omr12.networksolutionsemail.com (8.13.6/8.13.6) with ESMTP id p81Dunh0029779 for ; Thu, 1 Sep 2011 09:56:52 -0400 Authentication-Results: cm-omr14 smtp.user=wes@mti-systems.com; auth=pass (PLAIN) X-Authenticated-UID: wes@mti-systems.com Received: from [107.50.244.189] ([107.50.244.189:19513] helo=[68.245.171.115]) by cm-omr14 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id 33/DD-09278-12F8F5E4; Thu, 01 Sep 2011 09:56:49 -0400 Message-ID: <4E5F8F1E.2040804@mti-systems.com> Date: Thu, 01 Sep 2011 09:56:46 -0400 From: Wesley Eddy Organization: MTI Systems User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0.1) Gecko/20110830 Thunderbird/6.0.1 MIME-Version: 1.0 To: tcpm@ietf.org References: <9605EAA4-F1C4-4D83-B76E-88C81BFE1555@iki.fi> <4E5E79AC.6030605@gmail.com> In-Reply-To: <4E5E79AC.6030605@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [tcpm] Extending TCP option space X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 01 Sep 2011 13:55:20 -0000 On 8/31/2011 2:13 PM, William Allen Simpson wrote: > On 8/31/11 9:57 AM, Pasi Sarolahti wrote: >> TCP's option space has been under increasing demand recently, with new >> option-space hungry extensions such as MPTCP, and some recent ideas in >> the research domain. In the past there have been some discussion about >> mechanisms to extend the option space, and an extension option was >> proposed in draft-eddy-tcp-loo, but since then these efforts have died >> down. I'm wondering if there would be any interest in the tcpm >> community to resume this work. >> > Already done, already tested. RFC-6013. > > >> I recall that re-segmenting middleboxes were mentioned as one >> potential problem for such extension, and there might be other >> problems. Nevertheless, I would find it useful, if there was an RFC >> that a) documented the known problems with option space extension; and >> b) defined an option format and assigned the needed type codes, to >> enable experimentations with larger than 40-byte option space. >> > I'm using options 31 and 32. See > https://tools.ietf.org/html/draft-simpson-tcpct-api-04 AD hat on ... Just so there is no confusion: - those numbers have *not* been allocated from IANA - picking your own numbers and notifying IANA later is *not* the process - RFC 6013 specifically says that it uses 253 and 254, which is not consistent with the draft linked to above There is a sentence in section 9.3 of RFC 2780 that says: Values in the Option Kind field are assigned following an IESG Approval or Standards Action process. This in no way suggests that people select their own kind numbers and then notify IANA later. Vendors and others who are disregarding this are being anti-social and making the Internet more brittle in the long term. Honest mistakes are one thing, but please let's learn from them and stop continuously making them, as this problem has come up several times in the recent past. -- Wes Eddy MTI Systems From william.allen.simpson@gmail.com Thu Sep 1 07:08:27 2011 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8909B21F9B30 for ; Thu, 1 Sep 2011 07:08:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.432 X-Spam-Level: X-Spam-Status: No, score=-3.432 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4K5tsmTxi2O5 for ; Thu, 1 Sep 2011 07:08:27 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 09AA421F9AB8 for ; Thu, 1 Sep 2011 07:08:26 -0700 (PDT) Received: by iakc1 with SMTP id c1so2473927iak.31 for ; Thu, 01 Sep 2011 07:09:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=UHdrssm4/INgLHgv+OPKoESqeib9tAWGjxV134wIcaA=; b=eKdNF/q38XY20iUiX9Psfb7baAesdY3R3f3uAa64hMkMhE9dKUQspa30Vx+2qGtqsZ WWF3pqP8i++ZeekUf/s1M/3h279rgnzTNjz6asojXvc+yFqywwItvkG43w9yJvTRsg8l K2OdSm4g+0+1o2SJG4/Dnmarbirk+yjmwyECE= Received: by 10.231.57.90 with SMTP id b26mr459115ibh.6.1314886195876; Thu, 01 Sep 2011 07:09:55 -0700 (PDT) Received: from Wastrel-3.local (c-68-40-194-239.hsd1.mi.comcast.net [68.40.194.239]) by mx.google.com with ESMTPS id v16sm34267ibe.51.2011.09.01.07.09.53 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 01 Sep 2011 07:09:54 -0700 (PDT) Message-ID: <4E5F9230.9040308@gmail.com> Date: Thu, 01 Sep 2011 10:09:52 -0400 From: William Allen Simpson User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.21) Gecko/20110830 Thunderbird/3.1.13 MIME-Version: 1.0 To: Joe Touch , tcpm@ietf.org References: <9605EAA4-F1C4-4D83-B76E-88C81BFE1555@iki.fi> <4E5E79AC.6030605@gmail.com> <4E5E990A.5090804@isi.edu> In-Reply-To: <4E5E990A.5090804@isi.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [tcpm] Extending TCP option space X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 01 Sep 2011 14:08:27 -0000 On 8/31/11 4:26 PM, Joe Touch wrote: > On 8/31/2011 11:13 AM, William Allen Simpson wrote: >> I'm using options 31 and 32. See >> https://tools.ietf.org/html/draft-simpson-tcpct-api-04 > > Thanks for letting us know. I'll let IANA to mark those as (further) unauthorized uses. > Already told this list long ago, and already told IANA even longer ago. But thanks for getting IANA to add them to its listing? > In the meantime, please stop and use the experimental options until you get an assignment, IMO. > No. They don't work. There are too many conflicts -- as you well know, and has already been documented and discussed on this list. From william.allen.simpson@gmail.com Thu Sep 1 07:21:38 2011 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F027521F9656 for ; Thu, 1 Sep 2011 07:21:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.443 X-Spam-Level: X-Spam-Status: No, score=-3.443 tagged_above=-999 required=5 tests=[AWL=0.156, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZX-+iMS9Gznv for ; Thu, 1 Sep 2011 07:21:37 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 19A0121F963C for ; Thu, 1 Sep 2011 07:21:31 -0700 (PDT) Received: by ywe9 with SMTP id 9so1765476ywe.31 for ; Thu, 01 Sep 2011 07:23:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=8LoINHNNLC1p8vW5g3dIsuGa6GCcsV8UKqYJye+mtq8=; b=N7654MlLfBCDYm9ywWM8jRECxt//SsbH+VAaRqVF0HHZMM61HWJ4RHZ0eYl1Js4zQ+ IPT7tifpcKar0oOyjQP3UTrx7AcJV6z/pDu9EVmhHkcuI4kNTg5uop2l9TWsniSulhSP I7SBjZipOz7UHPLQkOVzTHuduwFXr2G86VyuY= Received: by 10.42.161.131 with SMTP id t3mr185631icx.404.1314886982519; Thu, 01 Sep 2011 07:23:02 -0700 (PDT) Received: from Wastrel-3.local (c-68-40-194-239.hsd1.mi.comcast.net [68.40.194.239]) by mx.google.com with ESMTPS id h3sm86724icx.9.2011.09.01.07.23.00 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 01 Sep 2011 07:23:01 -0700 (PDT) Message-ID: <4E5F9543.7000809@gmail.com> Date: Thu, 01 Sep 2011 10:22:59 -0400 From: William Allen Simpson User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.21) Gecko/20110830 Thunderbird/3.1.13 MIME-Version: 1.0 To: tcpm@ietf.org References: <4E5E5A34.1030707@isi.edu> <4E5ED768.8070703@gont.com.ar> In-Reply-To: <4E5ED768.8070703@gont.com.ar> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [tcpm] Extending TCP option space X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 01 Sep 2011 14:21:38 -0000 On 8/31/11 8:52 PM, Fernando Gont wrote: > On 08/31/2011 12:58 PM, Joe Touch wrote: >> Options are exchanged reliably only during connection establishment. >> There is no TWHS after that. So starting a new option after the >> connection starts seems difficult at best - > > Stick the option to a given SEQ. Whenever you retransmit that SEQ, you > retransmit the option. And when that SEQ is ACKed, that means the option > arrived to the other end (assuming no packet scrubber stripped the > option, obviously). > Of course, this is the technique used by TCPCT [RFC-6013], although slightly more liberally. Any option can be sent by either peer at *any* time, simply by inclusion after (Extend part) the TCP Timestamps Extended Option. If the option wasn't in a data-bearing segment, it is retransmitted with every successive packet and doesn't take effect until a data Ack is received. From william.allen.simpson@gmail.com Thu Sep 1 07:47:03 2011 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70A2D21F8C26 for ; Thu, 1 Sep 2011 07:47:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.452 X-Spam-Level: X-Spam-Status: No, score=-3.452 tagged_above=-999 required=5 tests=[AWL=0.147, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kPc7ixmaEcRZ for ; Thu, 1 Sep 2011 07:47:03 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id D47BC21F84F8 for ; Thu, 1 Sep 2011 07:47:02 -0700 (PDT) Received: by gwb20 with SMTP id 20so1161529gwb.31 for ; Thu, 01 Sep 2011 07:48:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=G3G8wv4KAWqJjJbMhsOW/DZOjqUK8wPtef2rG6EuZhQ=; b=YtYQRkgeRahFyIGUO2hpbn7pwVxtPISSycLIpyd/PnY8OFXse1I1c/G24mwYIKuQMV tWjVY0v+Ww0q+ywq2rMewLliEA4bXCrX6nvlJmYh+tdfVBpcw25DFjOGL4FxHf4iJcKm 7ggHrx602oteozO3+ETijT2cL+pl+/dG21ybo= Received: by 10.42.159.196 with SMTP id m4mr204914icx.407.1314888515786; Thu, 01 Sep 2011 07:48:35 -0700 (PDT) Received: from Wastrel-3.local (c-68-40-194-239.hsd1.mi.comcast.net [68.40.194.239]) by mx.google.com with ESMTPS id v2sm110496icw.4.2011.09.01.07.48.34 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 01 Sep 2011 07:48:34 -0700 (PDT) Message-ID: <4E5F9B40.6010708@gmail.com> Date: Thu, 01 Sep 2011 10:48:32 -0400 From: William Allen Simpson User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.21) Gecko/20110830 Thunderbird/3.1.13 MIME-Version: 1.0 To: tcpm@ietf.org References: <9605EAA4-F1C4-4D83-B76E-88C81BFE1555@iki.fi> <4E5E79AC.6030605@gmail.com> <4E5F8F1E.2040804@mti-systems.com> In-Reply-To: <4E5F8F1E.2040804@mti-systems.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [tcpm] Extending TCP option space X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 01 Sep 2011 14:47:03 -0000 On 9/1/11 9:56 AM, Wesley Eddy wrote: > There is a sentence in section 9.3 of RFC 2780 that says: > Values in the Option Kind field are assigned following an IESG > Approval or Standards Action process. > This in no way suggests that people select their own kind numbers > and then notify IANA later. Vendors and others who are disregarding > this are being anti-social and making the Internet more brittle in > the long term. Honest mistakes are one thing, but please let's > learn from them and stop continuously making them, as this problem > has come up several times in the recent past. > Either that, or the IESG is "being anti-social and making the Internet more brittle in the long term." Many organizations now, some of them very large, are ignoring the IESG (and thence IANA). At least we tried to engage the IESG. Waste of time, but still we tried.... The IESG has repeatedly broken the social compact. They seem to think they have a lever of control (protocol numbers), but that's only true to the extent that *everybody* agrees the IESG is relevant. "Rough consensus and running code." From touch@isi.edu Thu Sep 1 07:53:51 2011 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C35B921F9425 for ; Thu, 1 Sep 2011 07:53:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.145 X-Spam-Level: X-Spam-Status: No, score=-105.145 tagged_above=-999 required=5 tests=[AWL=1.454, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Ug8wIDaKQrI for ; Thu, 1 Sep 2011 07:53:51 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 55F3F21F9413 for ; Thu, 1 Sep 2011 07:53:51 -0700 (PDT) Received: from [198.123.60.66] ([198.123.60.66]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id p81EsZae017505 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 1 Sep 2011 07:54:49 -0700 (PDT) Message-ID: <4E5F9CAA.20600@isi.edu> Date: Thu, 01 Sep 2011 07:54:34 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: William Allen Simpson References: <9605EAA4-F1C4-4D83-B76E-88C81BFE1555@iki.fi> <4E5E79AC.6030605@gmail.com> <4E5E990A.5090804@isi.edu> <4E5F9230.9040308@gmail.com> In-Reply-To: <4E5F9230.9040308@gmail.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 Cc: tcpm@ietf.org Subject: Re: [tcpm] Extending TCP option space X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 01 Sep 2011 14:53:51 -0000 On 9/1/2011 7:09 AM, William Allen Simpson wrote: ... >> In the meantime, please stop and use the experimental options until >> you get an assignment, IMO. >> > No. They don't work. There are too many conflicts -- as you well know, > and has already been documented and discussed on this list. The only way they don't work is if you've deployed an experiment outside a controlled environment AND haven't used a nonce to differentiate your experiment from others. The former is a requirement of an experiment. The latter was discussed on this list. If that's still not enough for you, YOU'RE NOT RUNNING JUST AN EXPERIMENT - you are ***contaminating*** the Internet with a protocol that is squatting on a scarce and reserved community resource -- and need to stop. Joe From william.allen.simpson@gmail.com Thu Sep 1 08:11:20 2011 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB5AE21F9893 for ; Thu, 1 Sep 2011 08:11:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.46 X-Spam-Level: X-Spam-Status: No, score=-3.46 tagged_above=-999 required=5 tests=[AWL=0.139, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rOLaW4W6EYYQ for ; Thu, 1 Sep 2011 08:11:20 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1384C21F9891 for ; Thu, 1 Sep 2011 08:11:20 -0700 (PDT) Received: by ywe9 with SMTP id 9so1815980ywe.31 for ; Thu, 01 Sep 2011 08:12:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=4rKdU7Dm9Sk/k6EEtYe9Zyxt5b11HJRpfsjs7jPXRjc=; b=EsiH2SJqCnz8BP2A+dIKfRuvskerRzTk2Hpb/6spR1Q95kz5g1YeBf5rdvSvXyMWqz 42c4l8DtK60YS8iJ25hp+RhuLztRh3ihSYBTFjM9ZQvrcACZfMQYvaoMQwdGD2WJT/2T fsEd5B+28iqFzeDV4GHvrG+1DM4BUGfuYzTP8= Received: by 10.151.155.3 with SMTP id h3mr152083ybo.330.1314889972458; Thu, 01 Sep 2011 08:12:52 -0700 (PDT) Received: from Wastrel-3.local (c-68-40-194-239.hsd1.mi.comcast.net [68.40.194.239]) by mx.google.com with ESMTPS id e7sm88041ybg.3.2011.09.01.08.12.50 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 01 Sep 2011 08:12:51 -0700 (PDT) Message-ID: <4E5FA0F1.6020203@gmail.com> Date: Thu, 01 Sep 2011 11:12:49 -0400 From: William Allen Simpson User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.21) Gecko/20110830 Thunderbird/3.1.13 MIME-Version: 1.0 To: tcpm@ietf.org References: <4E5E5A34.1030707@isi.edu> In-Reply-To: <4E5E5A34.1030707@isi.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [tcpm] Extending TCP option space X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 01 Sep 2011 15:11:20 -0000 Farther up the thread a bit: On 8/31/11 11:58 AM, Joe Touch wrote: > .... My recollection is that we've dragged this dog around the block every few years, and realize the same thing: > > TCP SYN option space cannot be extended > I'm certainly in agreement. > Option negotiation on subsequent packets needs to build in enough of a state machine to consider what happens when packets are replayed or come out of order. The TWHS already handles that, but there doesn't appear to be a good way to do that once a > connection is established. > Or design it to be entirely relative, as we did with TCPCT [RFC-6013], obviating the need for any state machine revision. The monster under the bed that folks keep forgetting, that Joe forgot to mention in his list, and that keeps getting swept under the rug: no matter how elegant the design, it has to function with dropped packets and changes in the routing path. A simple SYN-option to extend the option space on later packets is utterly useless after the path changes to pass through a different middlebox. The extension option might be dropped or munged or re-segmented into oblivion. The only solution is security. TCPCT provides a modicum of security. That's the reason I combined the baker's dozen features into: One Kind to aid them all, One Kind to find them, One Kind to hold them all and in the header bind them. From touch@isi.edu Thu Sep 1 08:27:43 2011 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD31E21F986F for ; Thu, 1 Sep 2011 08:27:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.206 X-Spam-Level: X-Spam-Status: No, score=-103.206 tagged_above=-999 required=5 tests=[AWL=-0.607, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IuZOKE1GQwRi for ; Thu, 1 Sep 2011 08:27:43 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id 4099B21F953E for ; Thu, 1 Sep 2011 08:27:43 -0700 (PDT) Received: from [198.123.60.66] ([198.123.60.66]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id p81FS2Z7026775 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 1 Sep 2011 08:28:12 -0700 (PDT) Message-ID: <4E5FA481.9000602@isi.edu> Date: Thu, 01 Sep 2011 08:28:01 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: William Allen Simpson References: <4E5E5A34.1030707@isi.edu> <4E5FA0F1.6020203@gmail.com> In-Reply-To: <4E5FA0F1.6020203@gmail.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 Cc: tcpm@ietf.org Subject: Re: [tcpm] Extending TCP option space X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 01 Sep 2011 15:27:43 -0000 On 9/1/2011 8:12 AM, William Allen Simpson wrote: > Farther up the thread a bit: ... > > The monster under the bed that folks keep forgetting, that Joe forgot to > mention in his list, and that keeps getting swept under the rug: no > matter how elegant the design, it has to function with dropped packets > and changes in the routing path. Thanks for noting this; I am in complete agreement. That means that any rewriting middlebox cannot be traversed with an option extension it doesn't understand. ... > The only solution is security. Security helps you know when it works or not, but doesn't force it to work. The only way to force it to work through rewriting middleboxes is essentially a tunnel over vanilla TCP. Joe From pasi.sarolahti@iki.fi Thu Sep 1 11:52:55 2011 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 663CA21F97E4 for ; Thu, 1 Sep 2011 11:52:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jufr5+QdKBTr for ; Thu, 1 Sep 2011 11:52:54 -0700 (PDT) Received: from smtp.netlab.hut.fi (luuri.netlab.hut.fi [130.233.154.177]) by ietfa.amsl.com (Postfix) with ESMTP id 5A8CF21F97BC for ; Thu, 1 Sep 2011 11:52:54 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp.netlab.hut.fi (Postfix) with ESMTP id A290C1E0E4; Thu, 1 Sep 2011 21:54:26 +0300 (EEST) X-Virus-Scanned: by amavisd-new at luuri.netlab.hut.fi Received: from smtp.netlab.hut.fi ([127.0.0.1]) by localhost (luuri.netlab.hut.fi [127.0.0.1]) (amavisd-new, port 10024) with LMTP id neKo4mnrpnVL; Thu, 1 Sep 2011 21:54:23 +0300 (EEST) Received: from [192.168.1.66] (dsl-hkibrasgw4-fe5cdf00-46.dhcp.inet.fi [80.223.92.46]) by smtp.netlab.hut.fi (Postfix) with ESMTPSA id CBCCD1E0E3; Thu, 1 Sep 2011 21:54:22 +0300 (EEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Pasi Sarolahti In-Reply-To: <4E5E5A34.1030707@isi.edu> Date: Thu, 1 Sep 2011 21:54:22 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <151B4317-48FC-4F99-A01E-D42E52992F79@iki.fi> References: <4E5E5A34.1030707@isi.edu> To: Joe Touch X-Mailer: Apple Mail (2.1084) Cc: tcpm@ietf.org, Tim Shepard Subject: Re: [tcpm] Extending TCP option space X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 01 Sep 2011 18:52:55 -0000 Thanks, all, for responses! So... * Extending option space after the SYN is trivial, and for example the = LO option in Wes' draft would do the trick. * Reliably extending space for the first SYN is difficult, if not = impossible, but extending the SYN option negotiation could be supported = with some trick, such as the SLO option in the above mentioned draft. I don't see why it would be a big problem if some options are introduced = later than at SYN time (even without the IAMACAHYAT option), when = possible for the purpose of the option (e.g., not window scaling). There = are some risks with middleboxes or possibly crashing hosts, but the = available measurements seem to suggest that such risks are pretty small. = So even just the LO option could be quite helpful, and I think it would = be useful to see that idea go forward, with discussion of the possible = risks or shortcomings. People may have ideas of cool new extensions they would like to play = with, and it would be nice to be able to try these out in an = IETF-approved manner, without having to disable the earlier standardized = options first to make room in the header. - Pasi On Aug 31, 2011, at 6:58 PM, Joe Touch wrote: >=20 >=20 > On 8/31/2011 7:26 AM, Tim Shepard wrote: >>=20 >>=20 >> Several years ago, I posted to the TCPM list a ha-ha-only-serious >> proposal that what we need is a single new minimal size option called >> IAMACAHYAT which could be exchanged on the SYN and SYN-ACK packets. >>=20 >> This would be used to allow both ends to signal to each other that >> they are fully prepared to negotiate further options on later >> segments. >=20 > Whether this works or not - as per middlebox interactions - is less = important than it not solving the problem. >=20 > In a nutshell: >=20 > - extending option space after then TWHS is trivial > define a new option, confirm it with a SYN exchange, > and either the SYN gets dropped (some midboxes), > the option is dropped (others), or it works. >=20 > if the SYN is retransmitted, retransmit without the > option and tell the user it failed ;-( >=20 > - extending the SYN option space is the real issue anyway > - put in an option and extend the options right then > this breaks under 'ignore unknown options', > since the end of the options will be mis- > read as data >=20 > - put in an option and use the data in the SYN > this breaks under 'ignore unknown options', > since the option-as-data will be mis- > read as data >=20 > - put in something that breaks if unknown > this is the same as using a new transport > protocol number, and won't pass through NATs >=20 > If anyone sees a way around #2, please speak up. My recollection is = that we've dragged this dog around the block every few years, and = realize the same thing: >=20 > TCP SYN option space cannot be extended >=20 > There may be use to extending the space after the SYNs (someone can = propose that), but doing it in the SYNs doesn't appear to be possible. >=20 > NOTE: >=20 >> There was a belief at least among some that unexpected options on >> anything other than the SYN are dangerous because there might be >> stacks out there that handle them badly, like crashing. So we seemed >> to be stuck requiring all new options to somehow fit in the >> SYN/SYN-ACK exchange. >=20 > Options are exchanged reliably only during connection establishment. = There is no TWHS after that. So starting a new option after the = connection starts seems difficult at best - however, it fails to solve = the key issue: >=20 > - starting after the SYN has no real use given you can > start the option during the SYN with 2 bytes >=20 > - extending the SYN option space isn't helped by starting > after the SYN >=20 > Another suggestion was to set an option that can affect future TCP = connections, but this is a problem because: > a) hosts that restart could use new stacks that don't > support the option, and have no way to safely ignore it > b) IP addrs can be/are shared among endpoints (behind NATs, > or via L2 muxing) >=20 >> And now that I think of it, perhaps it would have been good if MPTCP >> had not filled up most all of the remaining option space on the SYN >> with its new options but had instead required use of the IAMACAHYAT >> option on the initial SYN/SYN-ACK exchange, and then did its >> own option negotiation on later packets. >=20 > Option negotiation on subsequent packets needs to build in enough of a = state machine to consider what happens when packets are replayed or come = out of order. The TWHS already handles that, but there doesn't appear to = be a good way to do that once a connection is established. >=20 > Joe From yoshifumi.nishida@gmail.com Thu Sep 1 12:57:28 2011 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F65E21F9888 for ; Thu, 1 Sep 2011 12:57:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BD7xT8THceVM for ; Thu, 1 Sep 2011 12:57:27 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7D1EA21F9886 for ; Thu, 1 Sep 2011 12:57:27 -0700 (PDT) Received: by gwb20 with SMTP id 20so1447681gwb.31 for ; Thu, 01 Sep 2011 12:59:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; bh=w1kO/6BXkbA8p6Eq/wCPSOQT0+3fvzL82tPqUheTazc=; b=PG7Fg2GIqznpKZ7oattEM8rT4+M5LeRRnqdyAqGHX1Lg/uJWP/oGwJ5fCmBZAYyT64 t+pxXAXAy9yTYK+EH9JZNKKD1EgddVhIQO1fa2ZEnW6RrwcGcyYZHUdtbz7ec01njOhV 8jALQxa9MpZ0T/mbo2zoldUUGxPnjD8lI4bWI= MIME-Version: 1.0 Received: by 10.42.162.134 with SMTP id y6mr216306icx.103.1314907140732; Thu, 01 Sep 2011 12:59:00 -0700 (PDT) Sender: yoshifumi.nishida@gmail.com Received: by 10.231.199.12 with HTTP; Thu, 1 Sep 2011 12:59:00 -0700 (PDT) Date: Thu, 1 Sep 2011 12:59:00 -0700 X-Google-Sender-Auth: z0s76YgTBP9qOKI_HIKGx8WbkvI Message-ID: From: Yoshifumi Nishida To: "tcpm@ietf.org\"" Content-Type: text/plain; charset=ISO-8859-1 Subject: [tcpm] an idea for experimental TCP options X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 01 Sep 2011 19:57:28 -0000 Hi, I'm not sure if this is a valid idea yet, but I'm thinking about a simple (and may be silly?) proposal for tcp options for experimental use. I'm sorry if we've already discussed this kind of things before. 1: Allocate one new option kind for new experimental use. 2: When a proposal that requires new option kinds is approved, IANA can allocate "candidate" option kind numbers. 3: If an implementation wants to use the "candidate" option kind, it has to be *encapsulated* into the new experimental option. If implementers don't like encapsulated format, they can always use the conventional experimental values as suggested in rfc4727. 4: Once we reach consensus to deploy the proposal, change the candidate status to assigned status. Implementations are now free to use this number in the option kind field. Pros It can be safely used without contaminating. It can explicitly specify this is an experimental use. Ugliness of this approach makes people motivate to move from experimental status to standard more seriously? Cons It won't be a true experiments since the option format will be changed? Changing option format is troublesome thing? It will add another complexity for option processing? Thanks, -- Yoshifumi Nishida nishida@sfc.wide.ad.jp From wes@mti-systems.com Wed Sep 7 20:54:54 2011 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E048A21F8AE6 for ; Wed, 7 Sep 2011 20:54:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SGL00xxkuMrA for ; Wed, 7 Sep 2011 20:54:54 -0700 (PDT) Received: from omr8.networksolutionsemail.com (omr8.networksolutionsemail.com [205.178.146.58]) by ietfa.amsl.com (Postfix) with ESMTP id 3DAE921F8AE1 for ; Wed, 7 Sep 2011 20:54:54 -0700 (PDT) Received: from cm-omr14 (mail.networksolutionsemail.com [205.178.146.50]) by omr8.networksolutionsemail.com (8.13.6/8.13.6) with ESMTP id p883ugr6015693 for ; Wed, 7 Sep 2011 23:56:45 -0400 Authentication-Results: cm-omr14 smtp.user=wes@mti-systems.com; auth=pass (PLAIN) X-Authenticated-UID: wes@mti-systems.com Received: from [174.130.101.139] ([174.130.101.139:37026] helo=[192.168.1.100]) by cm-omr14 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id B6/BB-13864-AFC386E4; Wed, 07 Sep 2011 23:56:42 -0400 Message-ID: <4E683CFB.60604@mti-systems.com> Date: Wed, 07 Sep 2011 23:56:43 -0400 From: Wesley Eddy Organization: MTI Systems User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0.1) Gecko/20110830 Thunderbird/6.0.1 MIME-Version: 1.0 To: tcpm@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [tcpm] an idea for experimental TCP options X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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 Sep 2011 03:54:55 -0000 On 9/1/2011 3:59 PM, Yoshifumi Nishida wrote: > Hi, I'm not sure if this is a valid idea yet, but I'm thinking about a > simple (and may be silly?) proposal for > tcp options for experimental use. I'm sorry if we've already discussed > this kind of things before. > > 1: Allocate one new option kind for new experimental use. > > 2: When a proposal that requires new option kinds is approved, IANA > can allocate "candidate" option kind numbers. > > 3: If an implementation wants to use the "candidate" option kind, it > has to be *encapsulated* into the new experimental option. > If implementers don't like encapsulated format, they can always > use the conventional experimental values as suggested in rfc4727. > > 4: Once we reach consensus to deploy the proposal, change the > candidate status to assigned status. > Implementations are now free to use this number in the option kind field. > > Pros > It can be safely used without contaminating. > It can explicitly specify this is an experimental use. > Ugliness of this approach makes people motivate to move from > experimental status to standard more seriously? > > Cons > It won't be a true experiments since the option format will be changed? > Changing option format is troublesome thing? > It will add another complexity for option processing? > Hi Yoshifumi, this is an interesting variation on Joe's idea. The difference seems to be that instead of using a timestamp or a random value to identify the sub-kind for the options involved in an experiment, IANA would pre-register a Kind number to be used encapsulated within an experimental option Kind. I think the drawback is that the Kind field is too small to make error-free use of in this way. It's only a single byte and there's no way to tell in a given option with one of the experimental outer Kinds whether to process its body as encapsulated with an inner Kind or in some other way. With Joe's method, at least there could be more bits (like 32) to provide a higher-probability that an option will be processed as intended. -- Wes Eddy MTI Systems From yoshifumi.nishida@gmail.com Thu Sep 8 12:59:18 2011 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3588721F8B3C for ; Thu, 8 Sep 2011 12:59:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZzKX+YVWpZ+N for ; Thu, 8 Sep 2011 12:59:17 -0700 (PDT) Received: from mail-gw0-f42.google.com (mail-gw0-f42.google.com [74.125.83.42]) by ietfa.amsl.com (Postfix) with ESMTP id 8EB9421F8AF0 for ; Thu, 8 Sep 2011 12:59:17 -0700 (PDT) Received: by gwb17 with SMTP id 17so398682gwb.15 for ; Thu, 08 Sep 2011 13:01:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=cWlCNFHURXOjmzjfKtPZyRHKrTXYpAbDw0yJoclTgeY=; b=P3VCx51IeevhtzpRMe+S/4/qhOdbT8ghEVl5etPCD+qMawdjph9j78LoedtiflNT0x wOpQdGMe0J/8SBy9Oh7K2NJNTjDQiJtMgdfd2PcbXKU4teSKuEVQ5o8LG1CH73wB5z6v oYxsP4U2HpY0MTx0jv5qQKVIlvR7IUQCs4X5s= MIME-Version: 1.0 Received: by 10.231.47.17 with SMTP id l17mr1018152ibf.24.1315512067949; Thu, 08 Sep 2011 13:01:07 -0700 (PDT) Sender: yoshifumi.nishida@gmail.com Received: by 10.231.199.80 with HTTP; Thu, 8 Sep 2011 13:01:07 -0700 (PDT) In-Reply-To: <4E683CFB.60604@mti-systems.com> References: <4E683CFB.60604@mti-systems.com> Date: Thu, 8 Sep 2011 13:01:07 -0700 X-Google-Sender-Auth: E949-MfTrCBx7E61OjgK42JQEwM Message-ID: From: Yoshifumi Nishida To: Wesley Eddy Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: tcpm@ietf.org Subject: Re: [tcpm] an idea for experimental TCP options X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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 Sep 2011 19:59:18 -0000 Hello Wes, Thanks for your response. 2011/9/7 Wesley Eddy : > On 9/1/2011 3:59 PM, Yoshifumi Nishida wrote: >> >> Hi, I'm not sure if this is a valid idea yet, but I'm thinking about a >> simple (and may be silly?) proposal for >> tcp options for experimental use. I'm sorry if we've already discussed >> this kind of things before. >> >> 1: Allocate one new option kind for new experimental use. >> >> 2: When a proposal that requires new option kinds is approved, IANA >> can allocate "candidate" option kind numbers. >> >> 3: If an implementation wants to use the "candidate" option kind, it >> has to be *encapsulated* into the new experimental option. >> =A0 =A0 If implementers don't like encapsulated format, they can always >> use the conventional experimental values as suggested in rfc4727. >> >> 4: Once we reach consensus to deploy the proposal, change the >> candidate status to assigned status. >> =A0 =A0 Implementations are now free to use this number in the option ki= nd >> field. >> >> Pros >> =A0 =A0It can be safely used without contaminating. >> =A0 =A0It can explicitly specify this is an experimental use. >> =A0 =A0Ugliness of this approach makes people motivate to move from >> experimental status to standard more seriously? >> >> Cons >> =A0 =A0It won't be a true experiments since the option format will be ch= anged? >> =A0 =A0Changing option format is troublesome thing? >> =A0 =A0It will add another complexity for option processing? >> > > > Hi Yoshifumi, this is an interesting variation on Joe's idea. > The difference seems to be that instead of using a timestamp > or a random value to identify the sub-kind for the options > involved in an experiment, IANA would pre-register a Kind number > to be used encapsulated within an experimental option Kind. > > I think the drawback is that the Kind field is too small to > make error-free use of in this way. =A0It's only a single byte > and there's no way to tell in a given option with one of the > experimental outer Kinds whether to process its body as > encapsulated with an inner Kind or in some other way. =A0With Joe's > method, at least there could be more bits (like 32) to provide a > higher-probability that an option will be processed as intended. I guess I don't not fully understand joe's proposal yet and I might miss some points, but here's my opinion on this. 1: I think 32bit length is coming from self-assigning nature. If IANA can control the sub-kind number, I think 1 byte might be suffici= ent. There are also similar kind of risks in using normal TCP options. I don't see strong reason to set higher security on this yet. 2: We might want to distinguish the proposals for experimental RFCs from so= me random TCP experiments. The pre-registered number might be used as an indication of the green-light for large-scale experiments. It's probably impossible to control small-scale random TCP experiments. So, I think we should focus on the proposals which need more experiments to be standards. Thanks, -- Yoshifumi Nishida nishida@sfc.wide.ad.jp From internet-drafts@ietf.org Fri Sep 9 08:54:19 2011 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D8E821F8B1D; Fri, 9 Sep 2011 08:54:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.585 X-Spam-Level: X-Spam-Status: No, score=-102.585 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VBzDbLjCp5uq; Fri, 9 Sep 2011 08:54:19 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1451D21F86AA; Fri, 9 Sep 2011 08:54:19 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.60 Message-ID: <20110909155419.518.40505.idtracker@ietfa.amsl.com> Date: Fri, 09 Sep 2011 08:54:19 -0700 Cc: tcpm@ietf.org Subject: [tcpm] I-D Action: draft-ietf-tcpm-persist-06.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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 Sep 2011 15:54:19 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the TCP Maintenance and Minor Extensions = Working Group of the IETF. Title : Clarification of sender behavior in persist condition. Author(s) : Murali Bashyam Mahesh Jethanandani Anantha Ramaiah Filename : draft-ietf-tcpm-persist-06.txt Pages : 11 Date : 2011-09-09 This document clarifies the Zero Window Probes (ZWP) described in Requirements for Internet Hosts [RFC1122]. In particular, it clarifies the actions that can be taken on connections which are experiencing the ZWP condition. This draft clarifies what has been till now a misinterpretation of the standard as specified in RFC 1122 [RFC1122] rather than making a change to the standard. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tcpm-persist-06.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-tcpm-persist-06.txt From touch@isi.edu Tue Sep 13 14:10:42 2011 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25D7721F8CC2 for ; Tue, 13 Sep 2011 14:10:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.153 X-Spam-Level: X-Spam-Status: No, score=-103.153 tagged_above=-999 required=5 tests=[AWL=-0.554, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MaFV+O3I38Cf for ; Tue, 13 Sep 2011 14:10:41 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id 9A23921F8CCE for ; Tue, 13 Sep 2011 14:10:19 -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 p8DLBvkb029306 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 13 Sep 2011 14:11:57 -0700 (PDT) Message-ID: <4E6FC71D.3000100@isi.edu> Date: Tue, 13 Sep 2011 14:11:57 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: "tcpm@ietf.org Extensions" References: <20110308004501.27770.44908.idtracker@localhost> In-Reply-To: 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 Subject: Re: [tcpm] Fwd: I-D Action:draft-cheng-tcpm-fastopen-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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 Sep 2011 21:10:42 -0000 Hi, all, The chair asked a few of us who had concerns about this doc to indicate whether the presentation in Quebec at IETF 81 had addressed our concerns. Mine remain: - any system designed for the web that relies on cookies needs to show a benefit over persistent connections - I have ongoing concerns with the change in TCP semantics this presents (assuming that the data is idempotent, as too briefly noted in Sec 2.1) I saw *no* changes in the protocol presented at IETF 81 to address these issues. The draft has not been updated, and the presentation only argues for nearly imperceptible improvements in page loading (which are likely obliterated by web proxies commonly used in mobile networks). I further remain concerned with yet another production deployment of a new TCP option - this MUST use the experimental option numbers. Joe From internet-drafts@ietf.org Thu Sep 15 13:33:09 2011 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E4A011E809A; Thu, 15 Sep 2011 13:33:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.486 X-Spam-Level: X-Spam-Status: No, score=-102.486 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id axbtsaEuSoV0; Thu, 15 Sep 2011 13:33:08 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB4BF21F84D2; Thu, 15 Sep 2011 13:33:08 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.60 Message-ID: <20110915203308.16885.46898.idtracker@ietfa.amsl.com> Date: Thu, 15 Sep 2011 13:33:08 -0700 Cc: tcpm@ietf.org Subject: [tcpm] I-D Action: draft-ietf-tcpm-persist-07.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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 Sep 2011 20:33:09 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the TCP Maintenance and Minor Extensions = Working Group of the IETF. Title : TCP sender clarification for Persist Condition. Author(s) : Murali Bashyam Mahesh Jethanandani Anantha Ramaiah Filename : draft-ietf-tcpm-persist-07.txt Pages : 11 Date : 2011-09-15 This document clarifies the Zero Window Probes (ZWP) described in Requirements for Internet Hosts [RFC1122]. In particular, it clarifies the actions that can be taken on connections which are experiencing the ZWP condition. This draft clarifies what has been till now a misinterpretation of the standard as specified in RFC 1122 [RFC1122] rather than making a change to the standard. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tcpm-persist-07.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-tcpm-persist-07.txt From iesg-secretary@ietf.org Fri Sep 16 08:08:45 2011 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81D4D21F8CA7; Fri, 16 Sep 2011 08:08:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y7A5Rm14hhJx; Fri, 16 Sep 2011 08:08:45 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADCDC21F8CAA; Fri, 16 Sep 2011 08:08:44 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.60 Message-ID: <20110916150844.1520.31722.idtracker@ietfa.amsl.com> Date: Fri, 16 Sep 2011 08:08:44 -0700 Cc: tcpm chair , tcpm mailing list , RFC Editor Subject: [tcpm] Document Action: 'TCP sender clarification for Persist Condition.' to Informational RFC (draft-ietf-tcpm-persist-07.txt) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 16 Sep 2011 15:08:45 -0000 The IESG has approved the following document: - 'TCP sender clarification for Persist Condition.' (draft-ietf-tcpm-persist-07.txt) as an Informational RFC This document is the product of the TCP Maintenance and Minor Extensions Working Group. The IESG contact persons are Wesley Eddy and David Harrington. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-tcpm-persist/ Technical Summary Abstract: This document clarifies the Zero Window Probes (ZWP) described in Requirements for Internet Hosts [RFC1122]. In particular, it clarifies the actions that can be taken on connections which are experiencing the ZWP condition. Working Group Summary There was an initial issue in limiting the scope of this document as a simple clarification. Early on, it included additional content, and specifically outlined a socket option, which has since been elided from the document after a number of discussions. In its current format, the document reflects those changes to limit the scope of the document to just identify what has been mis-interpreted in some past implementations and clarify that a TCP connection in a persist state is treated the same as any other TCP connection. Document Quality This is a short informational document that does not specify a protocol. It is published to clarify the intentions of RFC 1122. Personnel Michael Scharf (michael.scharf@alcatel-lucent.com) is the document shepherd. He has personally reviewed this version and believes it is ready for forwarding to the IESG for publication. Wesley Eddy (wes@mti-systems.com) is the responsible area director. From Michael.Scharf@alcatel-lucent.com Mon Sep 26 05:05:07 2011 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03D2F21F8BEF; Mon, 26 Sep 2011 05:05:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.212 X-Spam-Level: X-Spam-Status: No, score=-6.212 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nxQrs2oKQOKp; Mon, 26 Sep 2011 05:05:06 -0700 (PDT) Received: from mailrelay2.alcatel.de (mailrelay2.alcatel.de [194.113.59.96]) by ietfa.amsl.com (Postfix) with ESMTP id 3A57D21F8BD5; Mon, 26 Sep 2011 05:05:06 -0700 (PDT) Received: from SLFSNX.rcs.alcatel-research.de (slfsn1.rcs.de.alcatel-lucent.com [149.204.60.98]) by mailrelay2.alcatel.de (8.14.3/8.14.3/ICT) with ESMTP id p8QC7lF5031367; Mon, 26 Sep 2011 14:07:47 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 26 Sep 2011 14:07:45 +0200 Message-ID: <133D9897FB9C5E4E9DF2779DC91E947C0680D62F@SLFSNX.rcs.alcatel-research.de> In-Reply-To: <4E802AF0.4040605@unice.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: On the deployment of Explicit Rate Notification protocols Thread-Index: Acx8HrUclXzrZkuBSyKPN3YOqLu+GwAJN1lA References: <4E802AF0.4040605@unice.fr> From: "SCHARF, Michael" To: "Dino LOPEZ" , X-Scanned-By: MIMEDefang 2.69 on 149.204.45.73 Cc: tcpm@ietf.org Subject: Re: [tcpm] On the deployment of Explicit Rate Notification protocols X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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 Sep 2011 12:05:07 -0000 Speaking not as researcher, but as TCPM co-chair: Since you are proposing at least one new TCP option, please note that TCP option space in particular in SYNs is somehow scarce. Michael > -----Original Message----- > From: tsv-area-bounces@ietf.org=20 > [mailto:tsv-area-bounces@ietf.org] On Behalf Of Dino LOPEZ > Sent: Monday, September 26, 2011 9:34 AM > To: tsv-area@ietf.org > Subject: On the deployment of Explicit Rate Notification protocols >=20 > Dear all, >=20 > We have submitted a new Internet draft which provides an=20 > architecture to allow the deployment of congestion control=20 > protocols with explicit rate notification from forwarding=20 > devices (Explicit Rate Notification protocols). >=20 > This draft is currently available at > http://www.ietf.org/internet-drafts/draft-lopez-ietf-tsvwg-ipe > rn-00.txt >=20 > It will be a pleasure to receive any feedback from you. >=20 > Best Regards, >=20 > The authors > Lochin, Emmanuel (emmanuel.lochin@isae.fr) Lopez Pacheco,=20 > Dino (dino.lopez@unice.fr) Sathiaseelan, Arjuna=20 > (arjuna.sathiaseelan@gmail.com) >=20