From michael.scharf@alcatel-lucent.com Thu Oct 4 01:24:18 2012 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 D16E121F867C for ; Thu, 4 Oct 2012 01:24:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.249 X-Spam-Level: X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H6jVWlItkxAq for ; Thu, 4 Oct 2012 01:24:18 -0700 (PDT) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by ietfa.amsl.com (Postfix) with ESMTP id 0E08821F8673 for ; Thu, 4 Oct 2012 01:24:17 -0700 (PDT) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail5.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q948Nr2h003725 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Thu, 4 Oct 2012 10:24:15 +0200 Received: from FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com ([135.120.45.56]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Thu, 4 Oct 2012 10:24:08 +0200 From: "Scharf, Michael (Michael)" To: "tcpm@ietf.org" Date: Thu, 4 Oct 2012 10:24:06 +0200 Thread-Topic: TCPM charter milestone for detailed ECN feedback Thread-Index: Ac2iCZ605xXFq0drRGWMbaI9zIErew== Message-ID: <2A886F9088894347A3BE0CC5B7A85F3E98789F4D0B@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.13 Subject: [tcpm] TCPM charter milestone for detailed ECN feedback 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, 04 Oct 2012 08:24:19 -0000 Dear all, In the last meeting, we had quite strong interest in more detailed ECN feed= back, and I therefore proposed the following milestone for the TCPM charter= : "Sep 2013 Submit document on more detailed ECN feedback in TCP to the IE= SG for publication as an Experimental RFC" Due to the recent IPR statement on related drafts (https://datatracker.ietf= .org/ipr/1881/), the chairs want to verify that there is still strong inter= est and support for that potential charter item. Could you please send a short note if you are willing to work on that miles= tone, by contributing text, reviewing drafts, evaluating/implementing mecha= nisms, etc.? Thanks Michael (TCPM co-chair) From rs@netapp.com Thu Oct 4 01:33:52 2012 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 9A80921F8620 for ; Thu, 4 Oct 2012 01:33:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uroaW-4QTDC9 for ; Thu, 4 Oct 2012 01:33:52 -0700 (PDT) Received: from mx2.netapp.com (mx2.netapp.com [216.240.18.37]) by ietfa.amsl.com (Postfix) with ESMTP id 2277821F8581 for ; Thu, 4 Oct 2012 01:33:52 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.80,533,1344236400"; d="scan'208";a="697171436" Received: from smtp1.corp.netapp.com ([10.57.156.124]) by mx2-out.netapp.com with ESMTP; 04 Oct 2012 01:33:51 -0700 Received: from vmwexceht04-prd.hq.netapp.com (vmwexceht04-prd.hq.netapp.com [10.106.77.34]) by smtp1.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id q948Xp8Y010577; Thu, 4 Oct 2012 01:33:51 -0700 (PDT) Received: from SACEXCMBX02-PRD.hq.netapp.com ([169.254.1.210]) by vmwexceht04-prd.hq.netapp.com ([10.106.77.34]) with mapi id 14.02.0309.002; Thu, 4 Oct 2012 01:33:50 -0700 From: "Scheffenegger, Richard" To: "Scharf, Michael (Michael)" , "tcpm@ietf.org" Thread-Topic: TCPM charter milestone for detailed ECN feedback Thread-Index: Ac2iCZ605xXFq0drRGWMbaI9zIErewAAIldA Date: Thu, 4 Oct 2012 08:33:50 +0000 Message-ID: <012C3117EDDB3C4781FD802A8C27DD4F0D5FD08F@SACEXCMBX02-PRD.hq.netapp.com> References: <2A886F9088894347A3BE0CC5B7A85F3E98789F4D0B@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> In-Reply-To: <2A886F9088894347A3BE0CC5B7A85F3E98789F4D0B@FRMRSSXCHMBSE3.dc-m.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 Subject: Re: [tcpm] TCPM charter milestone for detailed ECN feedback 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, 04 Oct 2012 08:33:52 -0000 Hi Michael, I'm biased (obviously), but yes. I'm trying to learn if the current draft (= or extensions of it) can be implemented efficiently in hardware without bre= aking fastpath processing. [I understand that current hw reverts to slowpat= h as soon as any "uncommon" TCP or IP header bits like ECE/CWR or ECT/CE ar= e present, diminishing throughput often below wirespeed]. Best regards, Richard Scheffenegger > -----Original Message----- > From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf Of > Scharf, Michael (Michael) > Sent: Donnerstag, 04. Oktober 2012 10:24 > To: tcpm@ietf.org > Subject: [tcpm] TCPM charter milestone for detailed ECN feedback >=20 > Dear all, >=20 > In the last meeting, we had quite strong interest in more detailed ECN > feedback, and I therefore proposed the following milestone for the TCPM > charter: >=20 > "Sep 2013 Submit document on more detailed ECN feedback in TCP to > the IESG for publication as an Experimental RFC" >=20 > Due to the recent IPR statement on related drafts > (https://datatracker.ietf.org/ipr/1881/), the chairs want to verify that > there is still strong interest and support for that potential charter > item. >=20 > Could you please send a short note if you are willing to work on that > milestone, by contributing text, reviewing drafts, evaluating/implementin= g > mechanisms, etc.? >=20 > Thanks >=20 > Michael (TCPM co-chair) > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From pasi.sarolahti@iki.fi Thu Oct 4 07:21:00 2012 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 D1B5221F86E3 for ; Thu, 4 Oct 2012 07:20:59 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id seEMUO+fH9tA for ; Thu, 4 Oct 2012 07:20:59 -0700 (PDT) Received: from kirsi2.inet.fi (mta-out.inet.fi [195.156.147.13]) by ietfa.amsl.com (Postfix) with ESMTP id 34AF521F86A7 for ; Thu, 4 Oct 2012 07:20:58 -0700 (PDT) Received: from pc122.netlab.hut.fi (130.233.154.122) by kirsi2.inet.fi (8.5.140.03) (authenticated as saropa-1) id 502AD360005FEDFD for tcpm@ietf.org; Thu, 4 Oct 2012 17:20:56 +0300 From: Pasi Sarolahti Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 4 Oct 2012 17:20:55 +0300 Message-Id: <34FAB560-F1DA-4682-8898-1F1AE4F4C815@iki.fi> To: tcpm@ietf.org Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) Subject: [tcpm] TCPM agenda preparation for IETF-85 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, 04 Oct 2012 14:21:00 -0000 Hi, It's time to start the agenda preparation for the upcoming meeting. = After discussing this among the chairs, this time we thought to take a = little different approach than earlier, trying to ensure enough = discussion time for some of the important topics. The proposal is to = pre-allocate our 2.5-hour meeting into following parts: 1. WG drafts (45 minutes) 2. More accurate ECN (30 minutes) 3. TCP Loss Probe / RTO Restart (30 minutes) 4. Other items (45 minutes) For each part, we should aim for short presentations, to have enough = time for discussion. Especially for the "Other items" presentation = requests we'd like to see some mailing list traffic before deciding on a = presentation slot. Any comments? As before, please send your talk requests to chairs, including title, = draft name, name of the speaker and time request, within the next couple = of weeks. - Pasi From michawe@ifi.uio.no Thu Oct 4 14:49:24 2012 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 E79E821F860F for ; Thu, 4 Oct 2012 14:49:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.466 X-Spam-Level: X-Spam-Status: No, score=-102.466 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p2rAhfw-sy86 for ; Thu, 4 Oct 2012 14:49:24 -0700 (PDT) Received: from mail-out2.uio.no (mail-out2.uio.no [IPv6:2001:700:100:10::58]) by ietfa.amsl.com (Postfix) with ESMTP id 52BDA21F8514 for ; Thu, 4 Oct 2012 14:49:24 -0700 (PDT) Received: from mail-mx2.uio.no ([129.240.10.30]) by mail-out2.uio.no with esmtp (Exim 4.75) (envelope-from ) id 1TJtII-0005KI-UA; Thu, 04 Oct 2012 23:49:22 +0200 Received: from 108.134.189.109.customer.cdi.no ([109.189.134.108] helo=[192.168.0.197]) by mail-mx2.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1TJtII-0006Ol-Ga; Thu, 04 Oct 2012 23:49:22 +0200 Message-Id: <11A90A62-AF78-4724-96D1-C61610DBC012@ifi.uio.no> From: Michael Welzl To: Pasi Sarolahti In-Reply-To: <34FAB560-F1DA-4682-8898-1F1AE4F4C815@iki.fi> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 4 Oct 2012 23:49:00 +0200 References: <34FAB560-F1DA-4682-8898-1F1AE4F4C815@iki.fi> X-Mailer: Apple Mail (2.936) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 3 msgs/h 2 sum rcpts/h 13 sum msgs/h 4 total rcpts 24301 max rcpts/h 58 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, FSL_RCVD_USER=0.001, TVD_RCVD_IP=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 1154865EAEB9064D0CFB85A101E181EA6B993DBB X-UiO-SPAM-Test: remote_host: 109.189.134.108 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 2 total 1492 max/h 15 blacklist 0 greylist 0 ratelimit 0 Cc: tcpm@ietf.org Subject: Re: [tcpm] TCPM agenda preparation for IETF-85 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, 04 Oct 2012 21:49:25 -0000 I like it! Indeed RTO restart has undergone / is undergoing quite some changes... I'll be the one presenting our update. Cheers, Michael On Oct 4, 2012, at 4:20 PM, Pasi Sarolahti wrote: > Hi, > > It's time to start the agenda preparation for the upcoming meeting. > After discussing this among the chairs, this time we thought to take > a little different approach than earlier, trying to ensure enough > discussion time for some of the important topics. The proposal is to > pre-allocate our 2.5-hour meeting into following parts: > > 1. WG drafts (45 minutes) > 2. More accurate ECN (30 minutes) > 3. TCP Loss Probe / RTO Restart (30 minutes) > 4. Other items (45 minutes) > > For each part, we should aim for short presentations, to have enough > time for discussion. Especially for the "Other items" presentation > requests we'd like to see some mailing list traffic before deciding > on a presentation slot. Any comments? > > As before, please send your talk requests to chairs, including > title, draft name, name of the speaker and time request, within the > next couple of weeks. > > - Pasi > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From ycheng@google.com Thu Oct 4 15:58:31 2012 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 AB24D21F84FE for ; Thu, 4 Oct 2012 15:58:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.955 X-Spam-Level: X-Spam-Status: No, score=-102.955 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tZHX3jxh8ejZ for ; Thu, 4 Oct 2012 15:58:31 -0700 (PDT) Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by ietfa.amsl.com (Postfix) with ESMTP id 35DA021F84F1 for ; Thu, 4 Oct 2012 15:58:30 -0700 (PDT) Received: by mail-oa0-f44.google.com with SMTP id n5so1343539oag.31 for ; Thu, 04 Oct 2012 15:58:30 -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:content-transfer-encoding:x-system-of-record; bh=GoplzXj30ZcRyrJ5jis63CbfZWB1QlGP5J49HRGdBTw=; b=YS2hyLYBjbxr2uQ6Fw+QqD/jpFyW5BPL1mcjVewiubQ9uKypVcXWgwFhaLRX0pLF0F nM/2NI3IegRUdcFmZqZVgwEMexZDc9Z+L0bqAWJUDZ8NtVCE01mqWDpBAJOrVo8i/fLj WL0unCDzWKGiXzejVc6zI6gwS1yr1MUxBrGdAIuG/E+caxkIgdqjRW4qXnwvd3cE9VaJ FK7BHuxc4gReKl7cZj+ZBkD3qkE0OulRf/iMvcIhUSZGX3rkHWo9z+fhdkGcm51uyh7n LsNXYbF62dI4Fpva92Klxt/4KRuIF1YcdeOhPFIPdPfJtArHS2hC+8PgQ+oiIgHDLDhD bfcA== X-Google-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:content-transfer-encoding:x-system-of-record :x-gm-message-state; bh=GoplzXj30ZcRyrJ5jis63CbfZWB1QlGP5J49HRGdBTw=; b=JaH3+1kU9DLaT10WxguxXwoFBfkn5c7XP1KCdkcDFNcnaLaYtROEiEatuuA9GT4Zzt BxEP/L6Yq3svsc9tq6mWpV03IWHqR/N1IdOz0QAX3hZJbP7cS3gFblc4McvqaGa+GeHG w5D1FioQPmn4N3WjB3ZCIQdtg/+N2kS8YaDip/zJJvEwsOVuOXdRqTsyRG3/rjSccCvW j5gOto5X40kB4KRoSu6lgwqSzTRebn48x+20SnM4srWvWG9rwxyib1SW1ff+sWP0i8ku J7j6JwOjSINS3SvOGx4jmFOjD6GES/aNnIPqFl4a6cZIOUmRzXAKM8ZgUXn8KOhLheqI w6ww== Received: by 10.182.207.71 with SMTP id lu7mr5548205obc.78.1349391510586; Thu, 04 Oct 2012 15:58:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.60.169.80 with HTTP; Thu, 4 Oct 2012 15:58:10 -0700 (PDT) In-Reply-To: <34FAB560-F1DA-4682-8898-1F1AE4F4C815@iki.fi> References: <34FAB560-F1DA-4682-8898-1F1AE4F4C815@iki.fi> From: Yuchung Cheng Date: Thu, 4 Oct 2012 15:58:10 -0700 Message-ID: To: Pasi Sarolahti Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true X-Gm-Message-State: ALoCoQk7udRHJw/jLY9m+ZmucU0HKLBo89dMQUEC//0GjIjlLe/qti7Q2z3Pmste0JRei7fNqEqpzWiYrB0G3LAJHbeRuOfsCnnA0snuezYq4Z1rvw4AqH5ZyNyEiTLdLJvAZbkniTUjrQtIeMEKS/WqJlsxXXQ9xupBMkeIupf3vUJ5SmFQKLzUwpg74U8U/u/iG++f64XS Cc: tcpm@ietf.org Subject: Re: [tcpm] TCPM agenda preparation for IETF-85 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, 04 Oct 2012 22:58:31 -0000 On Thu, Oct 4, 2012 at 7:20 AM, Pasi Sarolahti wrot= e: > Hi, > > It's time to start the agenda preparation for the upcoming meeting. After= discussing this among the chairs, this time we thought to take a little di= fferent approach than earlier, trying to ensure enough discussion time for = some of the important topics. The proposal is to pre-allocate our 2.5-hour = meeting into following parts: > > 1. WG drafts (45 minutes) > 2. More accurate ECN (30 minutes) > 3. TCP Loss Probe / RTO Restart (30 minutes) Sounds good. I am happy to present our developments in Loss Probe. > 4. Other items (45 minutes) > > For each part, we should aim for short presentations, to have enough time= for discussion. Especially for the "Other items" presentation requests we'= d like to see some mailing list traffic before deciding on a presentation s= lot. Any comments? > > As before, please send your talk requests to chairs, including title, dra= ft name, name of the speaker and time request, within the next couple of we= eks. > > - Pasi > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From pasi.sarolahti@iki.fi Fri Oct 5 06:20:38 2012 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 5FBAC21F8720 for ; Fri, 5 Oct 2012 06:20:38 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dDK5OH6PfHWt for ; Fri, 5 Oct 2012 06:20:37 -0700 (PDT) Received: from kirsi1.inet.fi (mta-out.inet.fi [195.156.147.13]) by ietfa.amsl.com (Postfix) with ESMTP id 016C921F8489 for ; Fri, 5 Oct 2012 06:20:21 -0700 (PDT) Received: from pc127.netlab.hut.fi (130.233.154.127) by kirsi1.inet.fi (8.5.140.03) (authenticated as saropa-1) id 502B83D80318DF42; Fri, 5 Oct 2012 16:20:16 +0300 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Pasi Sarolahti In-Reply-To: <11A90A62-AF78-4724-96D1-C61610DBC012@ifi.uio.no> Date: Fri, 5 Oct 2012 16:20:18 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <7AA294DF-9DE6-42E4-BF81-0B9D1D9DE759@iki.fi> References: <34FAB560-F1DA-4682-8898-1F1AE4F4C815@iki.fi> <11A90A62-AF78-4724-96D1-C61610DBC012@ifi.uio.no> To: Michael Welzl X-Mailer: Apple Mail (2.1283) Cc: tcpm@ietf.org Subject: Re: [tcpm] TCPM agenda preparation for IETF-85 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, 05 Oct 2012 13:20:38 -0000 Good to hear that. In addition to short updates of recent changes on both of the drafts, we = as a WG should decide how to proceed with addressing the tail loss = problem. In the last meeting we saw pretty good support for this, but = one question is whether the WG should produce one RFC or two RFCs = addressing this. If there were going to be two RFCs, it would be good to = be quite clear about how do they relate with each other. Does it make = sense to implement both at the same time, or should implementor choose = between them, and on what basis? - Pasi On Oct 5, 2012, at 12:49 AM, Michael Welzl wrote: > I like it! > Indeed RTO restart has undergone / is undergoing quite some changes... = I'll be the one presenting our update. >=20 > Cheers, > Michael >=20 >=20 > On Oct 4, 2012, at 4:20 PM, Pasi Sarolahti wrote: >=20 >> Hi, >>=20 >> It's time to start the agenda preparation for the upcoming meeting. = After discussing this among the chairs, this time we thought to take a = little different approach than earlier, trying to ensure enough = discussion time for some of the important topics. The proposal is to = pre-allocate our 2.5-hour meeting into following parts: >>=20 >> 1. WG drafts (45 minutes) >> 2. More accurate ECN (30 minutes) >> 3. TCP Loss Probe / RTO Restart (30 minutes) >> 4. Other items (45 minutes) >>=20 >> For each part, we should aim for short presentations, to have enough = time for discussion. Especially for the "Other items" presentation = requests we'd like to see some mailing list traffic before deciding on a = presentation slot. Any comments? >>=20 >> As before, please send your talk requests to chairs, including title, = draft name, name of the speaker and time request, within the next couple = of weeks. >>=20 >> - Pasi >>=20 >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm >=20 From michawe@ifi.uio.no Fri Oct 5 06:25:15 2012 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 BD12821F874F for ; Fri, 5 Oct 2012 06:25:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.515 X-Spam-Level: X-Spam-Status: No, score=-102.515 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G+V6dGrFdCXW for ; Fri, 5 Oct 2012 06:25:14 -0700 (PDT) Received: from mail-out1.uio.no (mail-out1.uio.no [IPv6:2001:700:100:10::57]) by ietfa.amsl.com (Postfix) with ESMTP id C34CE21F8731 for ; Fri, 5 Oct 2012 06:25:05 -0700 (PDT) Received: from mail-mx2.uio.no ([129.240.10.30]) by mail-out1.uio.no with esmtp (Exim 4.75) (envelope-from ) id 1TK7to-0000MN-HQ; Fri, 05 Oct 2012 15:25:04 +0200 Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx2.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1TK7to-0001zw-3P; Fri, 05 Oct 2012 15:25:04 +0200 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Michael Welzl In-Reply-To: <7AA294DF-9DE6-42E4-BF81-0B9D1D9DE759@iki.fi> Date: Fri, 5 Oct 2012 15:25:03 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <34FAB560-F1DA-4682-8898-1F1AE4F4C815@iki.fi> <11A90A62-AF78-4724-96D1-C61610DBC012@ifi.uio.no> <7AA294DF-9DE6-42E4-BF81-0B9D1D9DE759@iki.fi> To: Pasi Sarolahti X-Mailer: Apple Mail (2.1283) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 8 msgs/h 4 sum rcpts/h 11 sum msgs/h 5 total rcpts 24342 max rcpts/h 58 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-6.2, required=5.0, autolearn=disabled, FSL_RCVD_USER=0.001, RP_MATCHES_RCVD=-1.17, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 5ED91B845C4E6D910F20AF069B0BB4BAAD2AE44A X-UiO-SPAM-Test: remote_host: 129.240.68.135 spam_score: -61 maxlevel 80 minaction 2 bait 0 mail/h: 4 total 9836 max/h 20 blacklist 0 greylist 0 ratelimit 0 Cc: tcpm@ietf.org Subject: Re: [tcpm] TCPM agenda preparation for IETF-85 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, 05 Oct 2012 13:25:15 -0000 Sure, these are reasonable questions to ask. Let's try to come to a = conclusion at the meeting. Our update will try to clarify the differences, and I'll do my best to = explain them at the meeting. Then we should be in a good position to = decide, I think. Cheers, Michael On 5. okt. 2012, at 15:20, Pasi Sarolahti wrote: > Good to hear that. >=20 > In addition to short updates of recent changes on both of the drafts, = we as a WG should decide how to proceed with addressing the tail loss = problem. In the last meeting we saw pretty good support for this, but = one question is whether the WG should produce one RFC or two RFCs = addressing this. If there were going to be two RFCs, it would be good to = be quite clear about how do they relate with each other. Does it make = sense to implement both at the same time, or should implementor choose = between them, and on what basis? >=20 > - Pasi >=20 >=20 > On Oct 5, 2012, at 12:49 AM, Michael Welzl wrote: >=20 >> I like it! >> Indeed RTO restart has undergone / is undergoing quite some = changes... I'll be the one presenting our update. >>=20 >> Cheers, >> Michael >>=20 >>=20 >> On Oct 4, 2012, at 4:20 PM, Pasi Sarolahti wrote: >>=20 >>> Hi, >>>=20 >>> It's time to start the agenda preparation for the upcoming meeting. = After discussing this among the chairs, this time we thought to take a = little different approach than earlier, trying to ensure enough = discussion time for some of the important topics. The proposal is to = pre-allocate our 2.5-hour meeting into following parts: >>>=20 >>> 1. WG drafts (45 minutes) >>> 2. More accurate ECN (30 minutes) >>> 3. TCP Loss Probe / RTO Restart (30 minutes) >>> 4. Other items (45 minutes) >>>=20 >>> For each part, we should aim for short presentations, to have enough = time for discussion. Especially for the "Other items" presentation = requests we'd like to see some mailing list traffic before deciding on a = presentation slot. Any comments? >>>=20 >>> As before, please send your talk requests to chairs, including = title, draft name, name of the speaker and time request, within the next = couple of weeks. >>>=20 >>> - Pasi >>>=20 >>> _______________________________________________ >>> tcpm mailing list >>> tcpm@ietf.org >>> https://www.ietf.org/mailman/listinfo/tcpm >>=20 >=20 From internet-drafts@ietf.org Fri Oct 5 14:49:02 2012 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 0888C21F870A; Fri, 5 Oct 2012 14:49:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.5 X-Spam-Level: X-Spam-Status: No, score=-102.5 tagged_above=-999 required=5 tests=[AWL=0.099, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zJPvtIxsJjkv; Fri, 5 Oct 2012 14:49:01 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 969B321F86DD; Fri, 5 Oct 2012 14:49:01 -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: 4.34 Message-ID: <20121005214901.20621.54555.idtracker@ietfa.amsl.com> Date: Fri, 05 Oct 2012 14:49:01 -0700 Cc: tcpm@ietf.org Subject: [tcpm] I-D Action: draft-ietf-tcpm-experimental-options-02.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, 05 Oct 2012 21:49:02 -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 Work= ing Group of the IETF. Title : Shared Use of Experimental TCP Options Author(s) : Joe Touch Filename : draft-ietf-tcpm-experimental-options-02.txt Pages : 8 Date : 2012-10-05 Abstract: This document describes how TCP option codepoints can support concurrent experiments using a magic number field. This mechanism avoids the need for a coordinated registry, and is backward- compatible with currently known uses. It is recommended for all new experimental RFCs that require TCP option codepoints. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tcpm-experimental-options There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-tcpm-experimental-options-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tcpm-experimental-options-02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From touch@isi.edu Fri Oct 5 15:19:26 2012 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 1CED221F8525; Fri, 5 Oct 2012 15:19:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.599 X-Spam-Level: X-Spam-Status: No, score=-105.599 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XIfIQ82xjja2; Fri, 5 Oct 2012 15:19:25 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 9DFC021F8523; Fri, 5 Oct 2012 15:19:25 -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 q95MHx8c002326 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 5 Oct 2012 15:17:59 -0700 (PDT) Message-ID: <506F5C97.5050205@isi.edu> Date: Fri, 05 Oct 2012 15:17:59 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: internet-drafts@ietf.org References: <20121005214901.20621.54555.idtracker@ietfa.amsl.com> In-Reply-To: <20121005214901.20621.54555.idtracker@ietfa.amsl.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, i-d-announce@ietf.org Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-experimental-options-02.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, 05 Oct 2012 22:19:26 -0000 Hi, all, This change reflects feedback on the need for a more explicit discussion of two things: - specific recommendation for its use - specific recommendation for a transition plan It should be ready for WGLC. Joe On 10/5/2012 2:49 PM, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the TCP Maintenance and Minor Extensions Working Group of the IETF. > > Title : Shared Use of Experimental TCP Options > Author(s) : Joe Touch > Filename : draft-ietf-tcpm-experimental-options-02.txt > Pages : 8 > Date : 2012-10-05 > > Abstract: > This document describes how TCP option codepoints can support > concurrent experiments using a magic number field. This mechanism > avoids the need for a coordinated registry, and is backward- > compatible with currently known uses. It is recommended for all new > experimental RFCs that require TCP option codepoints. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-tcpm-experimental-options > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-tcpm-experimental-options-02 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-experimental-options-02 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > From michael.scharf@alcatel-lucent.com Sun Oct 7 13:36:50 2012 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 7279421F8712 for ; Sun, 7 Oct 2012 13:36:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.249 X-Spam-Level: X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MDEdUKD4GsWn for ; Sun, 7 Oct 2012 13:36:50 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by ietfa.amsl.com (Postfix) with ESMTP id 906FB21F86E8 for ; Sun, 7 Oct 2012 13:36:49 -0700 (PDT) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q97KalGo015453 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Sun, 7 Oct 2012 22:36:47 +0200 Received: from FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com ([135.120.45.56]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Sun, 7 Oct 2012 22:36:47 +0200 From: "Scharf, Michael (Michael)" To: "tcpm@ietf.org" Date: Sun, 7 Oct 2012 22:36:46 +0200 Thread-Topic: WGLC for draft-ietf-tcpm-experimental-options Thread-Index: Ac2ky3gXd/mQVm+dSD2NjlMqIfwnoQ== Message-ID: <2A886F9088894347A3BE0CC5B7A85F3E98789F4D46@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.80 Subject: [tcpm] WGLC for draft-ietf-tcpm-experimental-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: Sun, 07 Oct 2012 20:36:50 -0000 Hi all, This e-mail starts a working group last call for the document "Shared Use o= f Experimental TCP Options" (draft-ietf-tcpm-experimental-options-02). The = WGLC runs until Friday, Oct. 26. Please read the draft and send comments by= then. If you think that the document should be published, sending a corresponding= short note would be very helpful, even if you don't have any further comme= nts. The draft is available at http://tools.ietf.org/html/draft-ietf-tcpm-experi= mental-options-02 . Thanks! Michael= From ycheng@google.com Mon Oct 8 17:17:42 2012 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 0952021F87E4 for ; Mon, 8 Oct 2012 17:17:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.961 X-Spam-Level: X-Spam-Status: No, score=-102.961 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PBgz94eYtO4N for ; Mon, 8 Oct 2012 17:17:41 -0700 (PDT) Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5CAAC21F87E0 for ; Mon, 8 Oct 2012 17:17:41 -0700 (PDT) Received: by mail-oa0-f44.google.com with SMTP id n5so856396oag.31 for ; Mon, 08 Oct 2012 17:17:41 -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:x-system-of-record; bh=VQp8sXHT8mXQ3PNNZlcrzOVBS27BfEWW0bkW/wa2ERM=; b=kVoEpZHa0i8plYbivIIBlSEKNcYwthsa/Ob4kf9E0qpUjulbFPQLpZD9FtF8Wd4S1J qLTMBINPkiyOA2na932utkeq4zvwpw9qyBnv3ynRMeHTN7BNyl/VBtuwgvQbE5NoWry5 162hkK0wrJAV0w0vNsAO7YqllAGgt9mFlot8Gy4FBTTkSRZs1B5CApC+FssG56mXScww 53eu7i8XkQE3jeLZJxa0ANbzdVZykSEckrk24wLBXpwnGqfGklsrcaTimfG3a/mBNQXp 2JVOWw691FI3dBtAA8+nvoA1xb2DxpRXXCVFsmVpodWvdSo8vSGqxO1XzoyAPdHY7gzX wWqw== X-Google-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:x-system-of-record:x-gm-message-state; bh=VQp8sXHT8mXQ3PNNZlcrzOVBS27BfEWW0bkW/wa2ERM=; b=T/NDhz6h4y8PE1JY17R6nMSbBdaHsTk2cFhMd3IP0twEwDHgMNuGyPD1Dpe6E7E1s2 6ZBYCdxNumMJciEMUhb+bO+tjN0dgrMpQr0Zw0rMqOJ5Ehl7nTk7+99t4ZBem81oB6+W yAas+iNlVgs6lmc/seBnOcMVLQuWxvwlIK8yJxTtad0p9uJlrbelKP7w0fdyNbkjs0IK /mfzn1CM1lMVGxNv+/RZAHwwhtRUA79rp6HjFA/SYm4z9paFkGDgF9ODvHxNktC5pcod 219lFlbbKMgv3MwNsBJUXM+idTuV7NS80dD9AxLdxnR2zkTgesZs21HdwQsTQhAVW+YF /LFQ== Received: by 10.60.32.19 with SMTP id e19mr15015189oei.9.1349741860888; Mon, 08 Oct 2012 17:17:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.60.118.202 with HTTP; Mon, 8 Oct 2012 17:17:20 -0700 (PDT) In-Reply-To: <2A886F9088894347A3BE0CC5B7A85F3E98789F4D46@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> References: <2A886F9088894347A3BE0CC5B7A85F3E98789F4D46@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> From: Yuchung Cheng Date: Mon, 8 Oct 2012 17:17:20 -0700 Message-ID: To: "Scharf, Michael (Michael)" Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true X-Gm-Message-State: ALoCoQlp6q/fcVHL5WzYdn5+NURzimUy4xHwPaFJheYuGMyDZH4gzsoGIpQUj+/7FeCZxLFyuh/sGr1CONXt8EICmRyDgpT61fl4MTSHn/6dfYJeuqNPYYWv5fsHgEU3i9nMBQMHkTrzfRF2dr780xF0A6bqWuiTqojuABEuGaOPbrG+AEbp6XDzD6CqHkCS3L4dl7OydCfh Cc: "tcpm@ietf.org" Subject: Re: [tcpm] WGLC for draft-ietf-tcpm-experimental-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: Tue, 09 Oct 2012 00:17:42 -0000 On Sun, Oct 7, 2012 at 1:36 PM, Scharf, Michael (Michael) wrote: > Hi all, > > This e-mail starts a working group last call for the document "Shared Use of Experimental TCP Options" (draft-ietf-tcpm-experimental-options-02). The WGLC runs until Friday, Oct. 26. Please read the draft and send comments by then. > > If you think that the document should be published, sending a corresponding short note would be very helpful, even if you don't have any further comments. > > The draft is available at http://tools.ietf.org/html/draft-ietf-tcpm-experimental-options-02 . Where should the new drafts note the experimental magic number? in the IANA section? There are many ">>" markers in the doc. Do they mean anything? > > Thanks! > > Michael > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From touch@isi.edu Tue Oct 9 09:11:48 2012 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 318C811E80C5 for ; Tue, 9 Oct 2012 09:11:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.208 X-Spam-Level: X-Spam-Status: No, score=-105.208 tagged_above=-999 required=5 tests=[AWL=1.391, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A1HUit3cGwK6 for ; Tue, 9 Oct 2012 09:11:47 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id B255421F8569 for ; Tue, 9 Oct 2012 09:11:47 -0700 (PDT) Received: from [192.168.1.94] (pool-71-105-94-82.lsanca.dsl-w.verizon.net [71.105.94.82]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q99GAUGs018994 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 9 Oct 2012 09:10:39 -0700 (PDT) Message-ID: <50744C76.9050301@isi.edu> Date: Tue, 09 Oct 2012 09:10:30 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Yuchung Cheng References: <2A886F9088894347A3BE0CC5B7A85F3E98789F4D46@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> 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 Cc: "tcpm@ietf.org" Subject: Re: [tcpm] WGLC for draft-ietf-tcpm-experimental-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: Tue, 09 Oct 2012 16:11:48 -0000 Hi, all, On 10/8/2012 5:17 PM, Yuchung Cheng wrote: > On Sun, Oct 7, 2012 at 1:36 PM, Scharf, Michael (Michael) > wrote: >> Hi all, >> >> This e-mail starts a working group last call for the document "Shared Use of Experimental TCP Options" (draft-ietf-tcpm-experimental-options-02). The WGLC runs until Friday, Oct. 26. Please read the draft and send comments by then. >> >> If you think that the document should be published, sending a corresponding short note would be very helpful, even if you don't have any further comments. >> >> The draft is available at http://tools.ietf.org/html/draft-ietf-tcpm-experimental-options-02 . > > Where should the new drafts note the experimental magic number? Anywhere in the new draft, as would be the case for any other protocol values that are not managed by IANA. > in the > IANA section? The point of self-selected magic numbers is to avoid the need for IANA coordination. The number could be reported in the IANA section for IANA's consideration if they decide to voluntarily collect a list of such numbers, but there are no IANA actions associated with magic numbers. > > There are many ">>" markers in the doc. Do they mean anything? These are explained in Section 2. Joe From mirja.kuehlewind@ikr.uni-stuttgart.de Tue Oct 9 10:27:25 2012 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 123C31F0CA4 for ; Tue, 9 Oct 2012 10:27:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.199 X-Spam-Level: X-Spam-Status: No, score=-2.199 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2WulJm0qHak9 for ; Tue, 9 Oct 2012 10:27:24 -0700 (PDT) Received: from mailsrv.ikr.uni-stuttgart.de (mailsrv.ikr.uni-stuttgart.de [129.69.170.2]) by ietfa.amsl.com (Postfix) with ESMTP id 2384E1F0CA3 for ; Tue, 9 Oct 2012 10:27:24 -0700 (PDT) Received: from netsrv1.ikr.uni-stuttgart.de (netsrv1-c [10.11.12.12]) by mailsrv.ikr.uni-stuttgart.de (Postfix) with ESMTP id 9C9DE633B1; Tue, 9 Oct 2012 19:27:22 +0200 (CEST) Received: from vpn-2-cl177 (vpn-2-cl177 [10.41.21.177]) by netsrv1.ikr.uni-stuttgart.de (Postfix) with ESMTP id 8238C59A8A; Tue, 9 Oct 2012 19:27:22 +0200 (CEST) From: Mirja Kuehlewind Organization: University of Stuttgart (Germany), IKR To: tcpm@ietf.org Date: Tue, 9 Oct 2012 19:27:21 +0200 User-Agent: KMail/1.9.10 (enterprise35 0.20101217.1207316) References: <2A886F9088894347A3BE0CC5B7A85F3E98789F4D0B@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> In-Reply-To: <2A886F9088894347A3BE0CC5B7A85F3E98789F4D0B@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> X-KMail-QuotePrefix: > MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <201210091927.21948.mirja.kuehlewind@ikr.uni-stuttgart.de> Subject: Re: [tcpm] TCPM charter milestone for detailed ECN feedback 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, 09 Oct 2012 17:27:25 -0000 Hi Michael, I want to try and submitt a draft on requirement and kind of a problem=20 statement for the more accurate ECN before the initial draft deadline. Mayb= e=20 also including some discussion on pros and cons of different solutions=20 (re-using ECN bits, new header bits, tcp option). You think that's anythin= g=20 useful? Mirja On Thursday 04 October 2012 10:24:06 Scharf, Michael (Michael) wrote: > Dear all, > > In the last meeting, we had quite strong interest in more detailed ECN > feedback, and I therefore proposed the following milestone for the TCPM > charter: > > "Sep 2013 Submit document on more detailed ECN feedback in TCP to the > IESG for publication as an Experimental RFC" > > Due to the recent IPR statement on related drafts > (https://datatracker.ietf.org/ipr/1881/), the chairs want to verify that > there is still strong interest and support for that potential charter ite= m. > > Could you please send a short note if you are willing to work on that > milestone, by contributing text, reviewing drafts, evaluating/implementing > mechanisms, etc.? > > Thanks > > Michael (TCPM co-chair) > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm =2D-=20 =2D------------------------------------------------------------------ Dipl.-Ing. Mirja K=FChlewind Institute of Communication Networks and Computer Engineering (IKR) University of Stuttgart, Germany Pfaffenwaldring 47, D-70569 Stuttgart tel: +49(0)711/685-67973 email: mirja.kuehlewind@ikr.uni-stuttgart.de web: www.ikr.uni-stuttgart.de =2D------------------------------------------------------------------ From gorry@erg.abdn.ac.uk Tue Oct 9 12:19:01 2012 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 1940C21F8616 for ; Tue, 9 Oct 2012 12:19:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.511 X-Spam-Level: X-Spam-Status: No, score=-102.511 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id as5S9V9Qwect for ; Tue, 9 Oct 2012 12:19:00 -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 62B1621F8681 for ; Tue, 9 Oct 2012 12:18:58 -0700 (PDT) Received: from www.erg.abdn.ac.uk (blake.erg.abdn.ac.uk [139.133.210.30]) by spey.erg.abdn.ac.uk (Postfix) with ESMTPSA id 6EAC92B4039; Tue, 9 Oct 2012 20:18:56 +0100 (BST) Received: from 212.159.18.54 (SquirrelMail authenticated user gorry) by www.erg.abdn.ac.uk with HTTP; Tue, 9 Oct 2012 20:18:56 +0100 Message-ID: In-Reply-To: <201210091927.21948.mirja.kuehlewind@ikr.uni-stuttgart.de> References: <2A886F9088894347A3BE0CC5B7A85F3E98789F4D0B@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> <201210091927.21948.mirja.kuehlewind@ikr.uni-stuttgart.de> Date: Tue, 9 Oct 2012 20:18:56 +0100 From: gorry@erg.abdn.ac.uk To: "Mirja Kuehlewind" User-Agent: SquirrelMail/1.4.22 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: tcpm@ietf.org Subject: Re: [tcpm] TCPM charter milestone for detailed ECN feedback 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, 09 Oct 2012 19:19:01 -0000 Mirja, Will the new draft also assess variants that are not known to be covered by IPR disclosures? That may be indeed be a useful point for input. Gorry > Hi Michael, > > I want to try and submitt a draft on requirement and kind of a problem > statement for the more accurate ECN before the initial draft deadline. > Maybe > also including some discussion on pros and cons of different solutions > (re-using ECN bits, new header bits, tcp option). You think that's > anything > useful? > > Mirja > > > On Thursday 04 October 2012 10:24:06 Scharf, Michael (Michael) wrote: >> Dear all, >> >> In the last meeting, we had quite strong interest in more detailed ECN >> feedback, and I therefore proposed the following milestone for the TCPM >> charter: >> >> "Sep 2013 Submit document on more detailed ECN feedback in TCP to the >> IESG for publication as an Experimental RFC" >> >> Due to the recent IPR statement on related drafts >> (https://datatracker.ietf.org/ipr/1881/), the chairs want to verify that >> there is still strong interest and support for that potential charter >> item. >> >> Could you please send a short note if you are willing to work on that >> milestone, by contributing text, reviewing drafts, >> evaluating/implementing >> mechanisms, etc.? >> >> Thanks >> >> Michael (TCPM co-chair) >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm > > > > -- > ------------------------------------------------------------------- > Dipl.-Ing. Mirja Kühlewind > Institute of Communication Networks and Computer Engineering (IKR) > University of Stuttgart, Germany > Pfaffenwaldring 47, D-70569 Stuttgart > > tel: +49(0)711/685-67973 > email: mirja.kuehlewind@ikr.uni-stuttgart.de > web: www.ikr.uni-stuttgart.de > ------------------------------------------------------------------- > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > From michael.scharf@alcatel-lucent.com Wed Oct 10 00:32:54 2012 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 19D7521F8747 for ; Wed, 10 Oct 2012 00:32:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.249 X-Spam-Level: X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H1LGnvUmxT7Q for ; Wed, 10 Oct 2012 00:32:52 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by ietfa.amsl.com (Postfix) with ESMTP id 6DBBA21F8746 for ; Wed, 10 Oct 2012 00:32:51 -0700 (PDT) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q9A7UsiC004233 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 10 Oct 2012 09:32:49 +0200 Received: from FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com ([135.120.45.56]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Wed, 10 Oct 2012 09:32:43 +0200 From: "Scharf, Michael (Michael)" To: Mirja Kuehlewind , "tcpm@ietf.org" Date: Wed, 10 Oct 2012 09:32:41 +0200 Thread-Topic: [tcpm] TCPM charter milestone for detailed ECN feedback Thread-Index: Ac2mQ1zGhTKKZbv4R6OgoZTe8N+0OgAdHYTg Message-ID: <2A886F9088894347A3BE0CC5B7A85F3E98789F4DB3@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> References: <2A886F9088894347A3BE0CC5B7A85F3E98789F4D0B@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> <201210091927.21948.mirja.kuehlewind@ikr.uni-stuttgart.de> In-Reply-To: <201210091927.21948.mirja.kuehlewind@ikr.uni-stuttgart.de> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.83 Subject: Re: [tcpm] TCPM charter milestone for detailed ECN feedback 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: Wed, 10 Oct 2012 07:32:54 -0000 Hi Mirja, As individual TCPM contributor, I think that we still lack a full understan= ding of the pros and cons of the different variants, and it is worth to dis= cuss this (also in the next meeting). But the group first has to decide whether to indeed add the charter milesto= ne. Given the complexity and impact of this topic, we need sufficient inter= est in TCPM. As far as I recall, in Vancouver there was broad support (betw= een 15 and 20 participants) for working on detailed ECN feedback. It would = help a lot if those participants could confirm their willingness to contrib= ute on the list. Michael > -----Original Message----- > From: Mirja Kuehlewind [mailto:mirja.kuehlewind@ikr.uni-stuttgart.de]=20 > Sent: Tuesday, October 09, 2012 7:27 PM > To: tcpm@ietf.org > Cc: Scharf, Michael (Michael) > Subject: Re: [tcpm] TCPM charter milestone for detailed ECN feedback >=20 > Hi Michael, >=20 > I want to try and submitt a draft on requirement and kind of=20 > a problem statement for the more accurate ECN before the=20 > initial draft deadline. Maybe also including some discussion=20 > on pros and cons of different solutions (re-using ECN bits,=20 > new header bits, tcp option). You think that's anything useful? >=20 > Mirja >=20 >=20 > On Thursday 04 October 2012 10:24:06 Scharf, Michael (Michael) wrote: > > Dear all, > > > > In the last meeting, we had quite strong interest in more=20 > detailed ECN=20 > > feedback, and I therefore proposed the following milestone for the=20 > > TCPM > > charter: > > > > "Sep 2013 Submit document on more detailed ECN=20 > feedback in TCP to the > > IESG for publication as an Experimental RFC" > > > > Due to the recent IPR statement on related drafts=20 > > (https://datatracker.ietf.org/ipr/1881/), the chairs want to verify=20 > > that there is still strong interest and support for that=20 > potential charter item. > > > > Could you please send a short note if you are willing to=20 > work on that=20 > > milestone, by contributing text, reviewing drafts,=20 > > evaluating/implementing mechanisms, etc.? > > > > Thanks > > > > Michael (TCPM co-chair) > > _______________________________________________ > > tcpm mailing list > > tcpm@ietf.org > > https://www.ietf.org/mailman/listinfo/tcpm >=20 >=20 >=20 > -- > ------------------------------------------------------------------- > Dipl.-Ing. Mirja K=FChlewind > Institute of Communication Networks and Computer Engineering=20 > (IKR) University of Stuttgart, Germany Pfaffenwaldring 47,=20 > D-70569 Stuttgart >=20 > tel: +49(0)711/685-67973 > email: mirja.kuehlewind@ikr.uni-stuttgart.de > web: www.ikr.uni-stuttgart.de > ------------------------------------------------------------------- > = From michawe@ifi.uio.no Wed Oct 10 01:50:31 2012 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 931EA21F86F8 for ; Wed, 10 Oct 2012 01:50:31 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id THhLY8UOFGy4 for ; Wed, 10 Oct 2012 01:50:28 -0700 (PDT) Received: from mail-out1.uio.no (mail-out1.uio.no [IPv6:2001:700:100:10::57]) by ietfa.amsl.com (Postfix) with ESMTP id 5A08521F8585 for ; Wed, 10 Oct 2012 01:50:27 -0700 (PDT) Received: from mail-mx3.uio.no ([129.240.10.44]) by mail-out1.uio.no with esmtp (Exim 4.75) (envelope-from ) id 1TLrzm-0000mL-Mb; Wed, 10 Oct 2012 10:50:26 +0200 Received: from [81.253.45.114] (helo=[172.18.14.157]) by mail-mx3.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1TLrzm-00049O-8x; Wed, 10 Oct 2012 10:50:26 +0200 Message-Id: From: Michael Welzl To: "Scharf, Michael (Michael)" In-Reply-To: <2A886F9088894347A3BE0CC5B7A85F3E98789F4DB3@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 10 Oct 2012 10:50:23 +0200 References: <2A886F9088894347A3BE0CC5B7A85F3E98789F4D0B@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> <201210091927.21948.mirja.kuehlewind@ikr.uni-stuttgart.de> <2A886F9088894347A3BE0CC5B7A85F3E98789F4DB3@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> X-Mailer: Apple Mail (2.936) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 4 msgs/h 2 sum rcpts/h 4 sum msgs/h 2 total rcpts 24514 max rcpts/h 58 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: F97ABA092CFE9E48BFC73F3421A25F2D8E780790 X-UiO-SPAM-Test: remote_host: 81.253.45.114 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 1 max/h 1 blacklist 0 greylist 0 ratelimit 0 Cc: "tcpm@ietf.org" Subject: Re: [tcpm] TCPM charter milestone for detailed ECN feedback 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: Wed, 10 Oct 2012 08:50:31 -0000 On Oct 10, 2012, at 9:32 AM, Scharf, Michael (Michael) wrote: > Hi Mirja, > > As individual TCPM contributor, I think that we still lack a full > understanding of the pros and cons of the different variants, and it > is worth to discuss this (also in the next meeting). > > But the group first has to decide whether to indeed add the charter > milestone. Given the complexity and impact of this topic, we need > sufficient interest in TCPM. As far as I recall, in Vancouver there > was broad support (between 15 and 20 participants) for working on > detailed ECN feedback. It would help a lot if those participants > could confirm their willingness to contribute on the list. I confirm my willingness to contribute. Cheers, Michael From pasi.sarolahti@iki.fi Thu Oct 18 01:48:17 2012 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 799CE21F8619 for ; Thu, 18 Oct 2012 01:48:17 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A9NxsKy2GnlI for ; Thu, 18 Oct 2012 01:48:17 -0700 (PDT) Received: from kirsi1.inet.fi (mta-out.inet.fi [195.156.147.13]) by ietfa.amsl.com (Postfix) with ESMTP id 9914621F8618 for ; Thu, 18 Oct 2012 01:48:16 -0700 (PDT) Received: from [192.168.1.65] (80.223.92.46) by kirsi1.inet.fi (8.5.140.03) (authenticated as saropa-1) id 502B83D803DA4756 for tcpm@ietf.org; Thu, 18 Oct 2012 11:48:15 +0300 From: Pasi Sarolahti Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 18 Oct 2012 11:48:12 +0300 References: <14477_1349360472_506D9B58_14477_783_1_34FAB560-F1DA-4682-8898-1F1AE4F4C815@iki.fi> To: tcpm@ietf.org Message-Id: <229DD106-8938-48E2-B37B-F115710B2D26@iki.fi> Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) Subject: [tcpm] Fwd: TCPM agenda preparation for IETF-85 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, 18 Oct 2012 08:48:17 -0000 We haven't got awfully many presentation requests so far. If you would = like to give a talk in the TCPM meeting, please send mail to chairs = ASAP. TCPM session is on Tuesday, Nov 6 at 9:00. - Pasi Begin forwarded message: > Hi, >=20 > It's time to start the agenda preparation for the upcoming meeting. = After discussing this among the chairs, this time we thought to take a = little different approach than earlier, trying to ensure enough = discussion time for some of the important topics. The proposal is to = pre-allocate our 2.5-hour meeting into following parts: >=20 > 1. WG drafts (45 minutes) > 2. More accurate ECN (30 minutes) > 3. TCP Loss Probe / RTO Restart (30 minutes) > 4. Other items (45 minutes) >=20 > For each part, we should aim for short presentations, to have enough = time for discussion. Especially for the "Other items" presentation = requests we'd like to see some mailing list traffic before deciding on a = presentation slot. Any comments? >=20 > As before, please send your talk requests to chairs, including title, = draft name, name of the speaker and time request, within the next couple = of weeks. >=20 > - Pasi >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From rs@netapp.com Thu Oct 18 03:28:53 2012 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 4BFDC21F85AF for ; Thu, 18 Oct 2012 03:28:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PFy++jEE6W-6 for ; Thu, 18 Oct 2012 03:28:52 -0700 (PDT) Received: from mx2.netapp.com (mx2.netapp.com [216.240.18.37]) by ietfa.amsl.com (Postfix) with ESMTP id 86D0921F85AC for ; Thu, 18 Oct 2012 03:28:52 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.80,606,1344236400"; d="scan'208";a="701920466" Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx2-out.netapp.com with ESMTP; 18 Oct 2012 03:28:52 -0700 Received: from vmwexceht03-prd.hq.netapp.com (exchsmtp.hq.netapp.com [10.106.76.241]) by smtp2.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id q9IASp4H026996; Thu, 18 Oct 2012 03:28:51 -0700 (PDT) Received: from SACEXCMBX02-PRD.hq.netapp.com ([169.254.1.114]) by vmwexceht03-prd.hq.netapp.com ([10.106.76.241]) with mapi id 14.02.0318.001; Thu, 18 Oct 2012 03:28:51 -0700 From: "Scheffenegger, Richard" To: Michael Welzl , "Scharf, Michael (Michael)" Thread-Topic: [tcpm] TCPM charter milestone for detailed ECN feedback Thread-Index: Ac2iCZ605xXFq0drRGWMbaI9zIErewEdGRKAAB2F34AAAraxgAGGzMMQ Date: Thu, 18 Oct 2012 10:28:50 +0000 Message-ID: <012C3117EDDB3C4781FD802A8C27DD4F0D687BBE@SACEXCMBX02-PRD.hq.netapp.com> References: <2A886F9088894347A3BE0CC5B7A85F3E98789F4D0B@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> <201210091927.21948.mirja.kuehlewind@ikr.uni-stuttgart.de> <2A886F9088894347A3BE0CC5B7A85F3E98789F4DB3@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> In-Reply-To: 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 Cc: "tcpm@ietf.org" Subject: Re: [tcpm] TCPM charter milestone for detailed ECN feedback 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, 18 Oct 2012 10:28:53 -0000 Hi Michael, Same here... (I guess co-authorship is active participation) I did have an offline discussion with Matt in between, discussing some of t= he limitations the current proposals have. http://tools.ietf.org/html/draft-kuehlewind-tcpm-accurate-ecn-option-01 http://tools.ietf.org/html/draft-kuehlewind-tcpm-accurate-ecn-01 Even though we did agree on the definitive usefulness of having that inform= ation available, it was unclear what are the exact circumstances the signal= ing protocol has to fulfill eventually and to what extent... Thus we didn't arrive at a conclusion, if these proposals fit all the (pote= ntial) needs, but we also didn't came up with an example mechanism, that wo= uld need more information than what is available with these proposals. Best regards, Richard Scheffenegger > -----Original Message----- > From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf Of > Michael Welzl > Sent: Mittwoch, 10. Oktober 2012 10:50 > To: Scharf, Michael (Michael) > Cc: tcpm@ietf.org > Subject: Re: [tcpm] TCPM charter milestone for detailed ECN feedback >=20 >=20 > On Oct 10, 2012, at 9:32 AM, Scharf, Michael (Michael) wrote: >=20 > > Hi Mirja, > > > > As individual TCPM contributor, I think that we still lack a full > > understanding of the pros and cons of the different variants, and it > > is worth to discuss this (also in the next meeting). > > > > But the group first has to decide whether to indeed add the charter > > milestone. Given the complexity and impact of this topic, we need > > sufficient interest in TCPM. As far as I recall, in Vancouver there > > was broad support (between 15 and 20 participants) for working on > > detailed ECN feedback. It would help a lot if those participants could > > confirm their willingness to contribute on the list. >=20 > I confirm my willingness to contribute. >=20 > Cheers, > Michael >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From pasi.sarolahti@iki.fi Thu Oct 18 07:40:29 2012 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 74B4421F873D for ; Thu, 18 Oct 2012 07:40:29 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kdqTS5kLTn7C for ; Thu, 18 Oct 2012 07:40:29 -0700 (PDT) Received: from kirsi2.inet.fi (mta-out.inet.fi [195.156.147.13]) by ietfa.amsl.com (Postfix) with ESMTP id C99CB21F8442 for ; Thu, 18 Oct 2012 07:40:28 -0700 (PDT) Received: from [192.168.1.65] (80.223.92.46) by kirsi2.inet.fi (8.5.140.03) (authenticated as saropa-1) id 502AD360007934A9 for tcpm@ietf.org; Thu, 18 Oct 2012 17:40:27 +0300 From: Pasi Sarolahti Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 18 Oct 2012 17:40:26 +0300 Message-Id: To: tcpm@ietf.org Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) Subject: [tcpm] Please review RFC 1323bis 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, 18 Oct 2012 14:40:29 -0000 Hi, We should make progress with RFC 1323bis, and therefore need people to = review it, so that we can assess how close the draft is to being ready. = Because RFC 1323 one of the key specs implemented in most stacks, it is = important that this draft goes through a careful review before it is = published. The latest version of the draft is at = http://tools.ietf.org/html/draft-ietf-tcpm-1323bis-04 So please read the draft and send comments, preferably to the mailing = list. - Pasi From David.Malone@nuim.ie Thu Oct 18 08:36:18 2012 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 3F9A421F8794 for ; Thu, 18 Oct 2012 08:36:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0SvF4Q-0Btcr for ; Thu, 18 Oct 2012 08:36:17 -0700 (PDT) Received: from lotus.nuim.ie (lotus.nuim.ie [149.157.1.189]) by ietfa.amsl.com (Postfix) with ESMTP id 99CEB21F845C for ; Thu, 18 Oct 2012 08:36:17 -0700 (PDT) Received: from localhost (localhost.test.com [127.0.0.1]) by lotus.nuim.ie (Postfix) with ESMTP id D87F07DD16A; Thu, 18 Oct 2012 16:39:05 +0100 (IST) X-Virus-Scanned: by Copperfasten Mail Firewall at nuim.ie Received: from mango.nuim.ie (banyan.nuim.ie [149.157.1.4]) by lotus.nuim.ie (Postfix) with ESMTP id B4DBE7DD169; Thu, 18 Oct 2012 16:39:05 +0100 (IST) Received: from marble.hamilton.local ([149.157.192.251]) by mango.nuim.ie (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTPS id <0MC300C66I0GTOD0@mango.nuim.ie>; Thu, 18 Oct 2012 16:36:16 +0100 (IST) Received: (from dwmalone@localhost) by marble.hamilton.local (8.14.5/8.14.5/Submit) id q9IFaGCD077439; Thu, 18 Oct 2012 16:36:16 +0100 (IST envelope-from David.Malone@nuim.ie) X-Authentication-warning: marble.hamilton.local: dwmalone set sender to David.Malone@nuim.ie using -f Date: Thu, 18 Oct 2012 16:36:16 +0100 From: David Malone To: Pasi Sarolahti Message-id: <20121018153616.GA77317@marble.hamilton.local> References: MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-disposition: inline In-reply-to: User-Agent: Mutt/1.4.2.3i Cc: tcpm@ietf.org Subject: Re: [tcpm] Please review RFC 1323bis 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, 18 Oct 2012 15:36:18 -0000 I wonder if the text in Section 4.3 needs modification: It is vitally important to use the RTTM mechanism with big windows; otherwise, the door is opened to some dangerous instabilities due to aliasing. Furthermore, the option is probably useful for all TCP's, since it simplifies the sender. I believe that Linux hasn't used the echoed timestamp to calculate RTTs for some years (though I haven't looked at the code recently, Matt Mathis could probably say). I believe the book-keeping is just done internally, as much as possible. I also wonder if it is worth mentioning the issue of a reciever who echos modified timestamps? If the timestamps are used without sanity checking, then the timeout can be controlled by the reciever (without changing the actual RTT). The security section has some comments on middle boxes that remove timestamp options. I don't know if we need to offer any advice on scrubbing timestamp options? I haven't heard any problems being caused by this, so maybe there is nothing to be said. David. From hkchu@google.com Sat Oct 20 23:13:37 2012 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 3253C21F8894 for ; Sat, 20 Oct 2012 23:13:37 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vorB+qnHP8Ye for ; Sat, 20 Oct 2012 23:13:35 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1575321F8890 for ; Sat, 20 Oct 2012 23:13:34 -0700 (PDT) Received: by mail-we0-f172.google.com with SMTP id u46so1044089wey.31 for ; Sat, 20 Oct 2012 23:13:33 -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:x-system-of-record; bh=2eAtQt7L9yYFPb7ekUwn6+2X9VLXKdMgmNKQkvMoziw=; b=ONVk4bv6mw+Kojma/hSSzrEV8h/LBWBP3eIx6dzafwtumLNuLquDJMEMFpQYmLCcMs N+Li41MOUz/K6+yF8VCOXlH5d01LZfQwX6e9Aao6i9dZ8Y8zvs0o9oteQkaD4nhXKSL7 G4VwHCEWCcDQUkGGUIcrIQbxTiN/cO5TgpWLhJjayPvOaR2qtUEQ1UqC3HFRpSHKHuaI q9b/koJXKuN+M8CzPMu1exdOS6MEy9IRNMraCmhdgihM6Ep6GUzoK97gbKo+UXDziMq5 4jvsfkhwFxsXWr4iks803qdlWqx/2PHJAn6la7jVgP0XQDEiYlU+SYiu3TpItaoCgMN1 otOg== X-Google-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:x-system-of-record :x-gm-message-state; bh=2eAtQt7L9yYFPb7ekUwn6+2X9VLXKdMgmNKQkvMoziw=; b=mdw16gsbmCL/iHIysTypwzpCJ1OzafjJumznaZ22j348KWk9x97C3DukD54VFEHsqY L9HPTpmQu278E8ZP1vUP7iLTaepxry59bUhwSrr6ns06c9o9fZS4MzXIqcPTlXU/OVHd aHVxhiVfhygcXAslrAoYDxrnaezjqud2rNsmXmYaWPqrm9s+kUuIMR9uRUync5adu2ID 20gDpxv0F1CR8s1a6HonsbLNLq5OTl3UTkJMGID3La6xzyIaouNYpIgtqLWJmMnIpTDA qFftRTjSS+owfTv4DfOZKRViwk147xMS5vPYA35rb075CV63TKH6KAkLbKVGSEB4RERY R3DQ== MIME-Version: 1.0 Received: by 10.180.8.40 with SMTP id o8mr28853828wia.9.1350800013659; Sat, 20 Oct 2012 23:13:33 -0700 (PDT) Received: by 10.194.61.72 with HTTP; Sat, 20 Oct 2012 23:13:33 -0700 (PDT) In-Reply-To: <201208132239.04933.mirja.kuehlewind@ikr.uni-stuttgart.de> References: <201207251811.40438.mkuehle@ikr.uni-stuttgart.de> <201208132239.04933.mirja.kuehlewind@ikr.uni-stuttgart.de> Date: Sat, 20 Oct 2012 23:13:33 -0700 Message-ID: From: Jerry Chu To: Mirja Kuehlewind Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true X-Gm-Message-State: ALoCoQmIGU7Q4MKRX8kUquoPrNSZ+b/fDONu7i3rdxlDDDoT3uwMWENKF8D3izNoQbxN+0F+Rnn/cd0QmriYvbdYrmwLKBVH+jCHeM8eDPNWpZq5xCDIzIQ9jkPTTgYHPtBSqYi0FVQv2xfWp1wXq3bweI9kvq8xCni6BZ/tNcRPtiBVfRVOZnxipnVtWcJiyUBFM8Y6+d6f Cc: tcpm@ietf.org Subject: Re: [tcpm] Review of draft-ietf-tcpm-initcwnd-04 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: Sun, 21 Oct 2012 06:13:37 -0000 On Mon, Aug 13, 2012 at 1:39 PM, Mirja Kuehlewind wrote: > Hi Jerry, > > I still believe restructuring the document would help to make it better > readable but I'm okay to keep the same structure than RFC 3390. Please ch= eck > if all paragraph are actually in the right section or more subsection are > needed to improve readability. Someone who wants to implement the change > might not read the whole document and might very easy overread any > SHOULDs/MUSTs in any later section than section 3. Maybe it is an option = to > add a reference to the later SHOULDs/MUSTs in section 2? Like I said the only other sections containing specification related language are section 9 and section 12. Since section 12 has been mentioned prominently in the Introduction, I'm adding a reference to section 9 at the end of sect= ion 2 per your suggestion. > > Regarding the comments below. You several times named a reference to > slides/papers/mails instead of actually addressing my comment in the draf= t. I I don't understand. When did I name any reference not already in the draft in order to address your comments on the draft, and why would I do that if the discu= ssion here is about the text of the draft itself, not about further debating on I= W10? The only case I can possibly think of wrt this was your question about TCP SACK. Frankly I don't remember the content of the email discussion but it w= as studied as part of [CW10] as mentioned in the draft. > know where to find the information as I've been following the discussion.= But > someone who later reads the document, might not have followed mail discus= sion > or ieft slides. Thus you really should add the references in the document= or Again the draft is self-contained. All the references are included. I think you've asked repeatedly to expand the links, i.e., to provide a summary of each study/paper/report... But I felt we've done enough. Interesting readers can always follow the references provided by the draft to find all the info. I will submit an updated draft soon. Jerry > even better, explain the outcome better in the document such that the > references are not need anymore. > > Mirja > > > On Wednesday 01 August 2012 07:32:31 Jerry Chu wrote: >> On Wed, Jul 25, 2012 at 2:58 PM, Jerry Chu wrote: >> > On Wed, Jul 25, 2012 at 11:12 AM, Mirja Kuehlewind >> > >> > wrote: >> >> Hi Jerry, >> >> >> >> just one quick comment: >> >>> Moreover, the TOC provides a very clear index of the contents so a >> >>> savvy reader can >> >>> quickly pick the sections of interesting. E.g., if you only want to >> >>> focus on the change >> >>> you'll know to read section 1 and 2 only. That's it. >> >> >> >> And that's not really true (anymore). There are several SHOULD and MU= ST >> >> in the other sections as well. Thus you have to read all the doc to >> >> correctly implement the changes. I know that the intent was to have >> >> everything in section 1 and 2 that is of interest for implementers bu= t >> >> due to the many changes that have been done in previous versions, it'= s >> >> not the case anymore. >> > >> > Actually the only other specification related languages is section 9, >> > and it's not >> > essential as it simply reiterates what is described in rfc6298. >> > >> > Yes other SHOULD and MUST can be found in the newly added section 12 >> > "Usage and Deployment Recommendations", but that section is mainly abo= ut >> > what one must do in any future large scale experiment, closely monitor= ing >> > a number of key metrics... and not really about protocol specification= . >> > >> > So to summarize, this draft is not just about protocol specification, >> > it also addresses >> > many other questions like why, and how to go about doing more >> > experiments safely. >> > >> >> That why I said, all the content is there, would be nice to >> >> clean-up/restructure a little and then it's done. >> >> >> >> It's good to have a similar structure than RFC3390 (didn't realize th= at >> >> you tried to have exactly the same sections here) but if the content >> >> would fit >> > >> > It was spelled out up front in 1. Introduction >> > >> > "This document proposes to raise the upper bound on TCP's initial >> > window (IW) to 10 segments or roughly 15KB. It is patterned after a= nd >> > borrows heavily from RFC 3390 [RFC3390] and earlier work in this >> > area." >> > >> >> better with a different structure, I'd prefer to have a good readable >> >> doc over having a doc that looks similar to RFC3390. >> > >> > Let's stick to the current format but I will respond to your one other >> > criticism on >> > section 12 first. The section is quite specific about the metrics to >> > monitor: "A key metric to monitor is the rate of packet losses, ECN >> > marking, or segment retransmissions during the initial burst." But as >> > others have pointed out it can be >> > quite difficult to try to get more specific than that, i.e., how much >> > performance >> > deteriorates before one must back off. As such all we can do for now i= s >> > to have enough warning signs for now but leave some details for future >> > investigation. >> > >> > Jerry >> > >> >> Mirja >> >> >> >>> >Hence I'd like to >> >>> > propose quite a little restructuring before moving the document >> >>> > forward as it is hard to easily catch the main points at the momen= t. >> >>> > More concrete, I'd move at least section 4, 10 and 11, maybe also = 5, >> >>> > 6 and 7 (or at least partly) to the appendix. The first two paragr= aph >> >>> > of section 7 might actually belong in >> >>> >> >>> Yes it's doable but I think the current flow is fine if you realize >> >>> the main purpose of >> >>> the document is to justify the change, not the change itself. Also T= OC >> >>> will make it >> >>> much easier to navigate through. >> >>> >> >>> > the security consideration section. And section 15 (conclusion) is >> >>> > not needed at all. More detailed comments below. >> >>> > >> >>> > Mirja >> >>> > >> >>> > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> >>> > Section 1 Introduction: >> >>> > ---------------------------- >> >>> > - s/roughly 15KB/maxium 14600B/ >> >>> >> >>> Ok. >> >>> >> >>> > - 2. paragraph: Don't like this two sentences at all. I hope the >> >>> > reason to increase IW is not just the fact there the queues are la= rge >> >>> > enough to store 10 packets. You basically saying "Let's send more >> >>> > packets at once to blow the queues!". I'd say the reason is that f= low >> >>> > sizes have increased and therefore IW10 would improve latency a lo= t. >> >>> > Only because queues are likely to be large than 10 packets today, = it >> >>> > is possible at all to send more than 10 packet at once. Btw. even = if >> >>> > the queue would be small, pacing could help to still allow an IW o= f >> >>> > 10. Moreover, the fact that there might be several concurrent flow= s, >> >>> > does not mean that the buffer has to be larger (only if those flow >> >>> > start at the same time with IW10). And even if there is a large >> >>> > buffer, if there is a long-lived TCP connection, this flow will fi= ll >> >>> > up the queue and there might be by chance still no space in the qu= eue >> >>> > for 10 additional packets. >> >>> >> >>> Guess you read the paragraph differently from what the authors had i= n >> >>> mind. What we have in mind was "Ten segments are likely to fit into >> >>> queue space" because access link drains much faster these days (due = to >> >>> b/w growth)... >> >>> >> >>> Will try to make it more clear. >> >>> >> >>> Will continue later, >> >>> >> >>> Jerry >> >>> >> >>> > - 3. paragraph: Don't agree. You might not know that there is a lo= w >> >>> > speed link somewhere on the path. There are cases where the endpoi= nt >> >>> > can protect its path by setting the receiver window but that's not >> >>> > the general case. >> >> This is exactly the point - it's not the general case but may be the >> vast majority. >> I.e., 95% of severely b/w limited hosts may be just 1 hop away or even >> directly attached to a slow link (e.g., dailup modem) hence can be >> mitigated much easily. No one suggested a solution here to solve the >> general problem of >> detecting bottleneck >> b/w. That's the job TCP's CC algorithm. >> >> >>> > - 5. paragraph: "We recommend that all TCP implementations have a >> >>> > settable TCP IW parameter..." >> >>> > -> I'd like to see this not only in the introduction but also in >> >>> > the main section (2.) that is describing the changes and maybe eve= n >> >>> > as a SHOULD >> >>> > >> >>> > >> >>> > Section 2 TCP Modifications >> >>> > ------------- >> >>> > - Maybe have a more specific title like "Setting the IW" and some >> >>> > subsections >> >> Plagiarized from RFC3390 :) >> >> >>> > - equation 1: say somewhere that numbers are in KByte >> >> Not really. >> >> >>> > - 4. paragraph ("Note that...") does not belong in this section >> >> Why not? (It's more or less a disclaim because no one has done any study >> on non-Ethernet MTU. >> >> >>> > - maybe new subsection for paragraph 5 "Resetting the IW after SYN >> >>> > loss"; what are "multiple SYN or SYN/ACK retransmissions" -> maybe >> >>> > say a number >> >> Ok. Changed to "more than one". >> >> >>> > - last paragraph: maybe s/implementations SHOULD fall >> >>> > back/implementations MUST fall back/ ? >> >>> > >> >>> > >> >>> > Section 3 Implementation Issues >> >>> > ------------- >> >>> > - Maybe move the 3 paragraph into section 2 such that the setting = of >> >>> > the receive window is a MUST or SHOULD of the changes to TCP >> >> Non-essential. Remember even IW10 is just an upperbound. >> >> >>> > - 4. paragraph: Please give some explanation (or remove) >> >> This was brought up and discussed on the list long ago. >> >> >>> > Section 4 Background >> >>> > ------------ >> >>> > - Move most parts in the appendix >> >>> > >> >>> > - Move 2. paragraph into Introduction >> >>> > >> >>> > - Maybe improve structure with subsections e.g. paragraph 5 and 6 >> >>> > as "Recommendation for HTTP Traffic" or something >> >> See my other response. I prefer not to change the structure at this time= . >> >> >>> > - 7. paragraph: "pacing will not be necessary" >> >>> > -> I can't remember having seen any results on this. Please expl= ain >> >>> > further or remove! >> >> The statement was really "We suspect" pacing will not be necessary becau= se >> our test results do not show any severe congestion from IW10... >> >> >>> > Section 5 Advantages of a Larger Initial Window >> >>> > ----------- >> >>> > - section 5.1 Reducing Latency >> >>> > You should also mention that for larger transmission with sever= al >> >>> > 100s of RTT a save of 4 RTT does not really help. Thus transmissio= ns >> >>> > which will finish within a small number of RTT will benefit the mo= st. >> >> Isn't it obvious already? >> >> >>> > - section 5.2 >> >>> > You make some quite general statements here and then u only refe= r >> >>> > to google data. Maybe you can find some other references as well. >> >> It's not just google data (see all the refs.) >> >> >>> > Section 6 >> >>> > ---------- >> >>> > - paragraph 3 and 4 belong in an evaluation section/appendix (mayb= e >> >>> > own subsection on "Influence of simultaneous opened connections") >> >>> > >> >>> > Section 7 >> >>> > -------- >> >>> > - Move 1. paragraph to security consideration >> >>> > >> >>> > - Move rest in appendix or even parts in the introduction >> >>> > >> >>> > Section 9 >> >>> > ---------- >> >>> > - move to main section which is introducing the TCP changes as ow= n >> >>> > subsection as a MUST is in here >> >> Non-essential because it simply restates what is said in rfc6298. It was >> added to address some concern (or confusion) that was brought up in the >> past that the initial burst of 10 pkts won't bid well for RTO hence caus= ing >> spurious rexmits. >> >> >>> > - can you explain better why this is need or what would happen >> >>> > otherwise? >> >>> > >> >>> > Section 10 >> >>> > ---------- >> >>> > - Move to appendix, have more subsections and better titles for th= e >> >>> > subsections e.g. "Improvements in Latency", "Impact on the >> >>> > Retransmission Rate" and "Multiple TCP Connections" >> >>> > >> >>> > - The numbers for the latency improvement are only on (google) web >> >>> > search. Of course there are quite large improvements possible but = the >> >>> > Internet contains also other traffic. Not sure if your number are >> >>> > really that significant...? >> >> We just stated what we have. >> >> >>> > Section 11 >> >>> > --------- >> >>> > - move to appendix >> >>> > >> >>> > - It's nice that you list all the studies. Could you please quickl= y >> >>> > summarize their results/findings, too? Because I guess that the >> >>> > intersting part to know. >> >> If you are interested please go read them yourself. >> >> >>> > Section 12 >> >>> > -------- >> >>> > - Its good to have this section but it's quite unspecific. E.g. yo= u >> >>> > say "An increased initial window MUST NOT be turned on by default = on >> >>> > systems without such monitoring capabilities." But what exactly >> >>> > should be monitored and how frequently and so on. Also "any >> >>> > significant deterioration" doesn't say anything to me. Is it possi= ble >> >>> > to have a concrete approach/algorithm here what to monitor when an= d >> >>> > what to do in which cases? And than have this even as part of the >> >>> > main section with TCP changes as this section has also some SHOULD >> >>> > and MUST and might be overread otherwise. >> >>> > >> >>> > Section 14 >> >>> > --------- >> >>> > - "highly unlikely to lead to a persistent state of network >> >>> > congestion" -> Even a "highly unlikely" is concerning me in this >> >>> > case! Also there is no reasoning for this. But I guess you can eve= n >> >>> > say, that this change cannot cause persistent network congestion a= s >> >>> > congestion control is still used.... >> >> See 1st paragraph of section 7. >> >> >>> > Section 15 Conclusion >> >>> > -------- >> >>> > - Is not needed here at all, as no new information >> >> Most rfcs have a conclusion section for those who have time only for >> the 1st and last sections. >> >> >>> > Appendix >> >>> > --------- >> >>> > - "One notable exception is YouTube because we don't think >> >>> > the large initial window will have much material impact, eith= er >> >>> > positive or negative, on bulk data services." >> >>> > -> Why is this document than not recommending to NOT use IW10 fo= r >> >>> > bulk data services? >> >> Why should it recommend NOT? How would the TCP stack know apriori bulk >> or not? So it will require input from the apps... Is it really worth >> the complexity? >> >> >>> > - "[CW10] contains some result from a testbed study on how short >> >>> > flows with a larger initial window might affect the throughput >> >>> > performance of other co-existing, long lived, bulk data transfers.= " >> >>> > -> Please also describe what the results are! >> >> Read the slides please. >> >> >>> > - paragraph on "Why 10 segment?" >> >>> > -> This is something I would prefer to have in the body of the >> >>> > document not in the appendix >> >>> > >> >>> > - "Some simulation studies [JNDK10, JNDK10-1] have been conducted = to >> >>> > study the effect of a larger initial window on wireless links >> >>> > from 2G to 4G networks (EGDE/HSPA/LTE). The overall result seems >> >>> > mixed in both raw performance and the fairness index." >> >>> > -> Should it be recommend to not use IW10 in wireless scenarios = (if >> >>> > known)? >> >> Studies are still on-going. I don't remember there has been a conclusive >> result. >> >> Jerry >> >> >> -- >> >> ------------------------------------------------------------------- >> >> Dipl.-Ing. Mirja K=FChlewind >> >> Institute of Communication Networks and Computer Engineering (IKR) >> >> University of Stuttgart, Germany >> >> Pfaffenwaldring 47, D-70569 Stuttgart >> >> >> >> tel: +49(0)711/685-67973 >> >> email: mirja.kuehlewind@ikr.uni-stuttgart.de >> >> web: www.ikr.uni-stuttgart.de >> >> ------------------------------------------------------------------- > > > > -- > ------------------------------------------------------------------- > Dipl.-Ing. Mirja K=FChlewind > Institute of Communication Networks and Computer Engineering (IKR) > University of Stuttgart, Germany > Pfaffenwaldring 47, D-70569 Stuttgart > > tel: +49(0)711/685-67973 > email: mirja.kuehlewind@ikr.uni-stuttgart.de > web: www.ikr.uni-stuttgart.de > ------------------------------------------------------------------- From internet-drafts@ietf.org Sun Oct 21 18:19:29 2012 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 051A521F8A5E; Sun, 21 Oct 2012 18:19:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.52 X-Spam-Level: X-Spam-Status: No, score=-102.52 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fvvXb7Dl2Uj2; Sun, 21 Oct 2012 18:19:27 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDBC921F8A5C; Sun, 21 Oct 2012 18:19:27 -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: 4.34 Message-ID: <20121022011927.9426.72422.idtracker@ietfa.amsl.com> Date: Sun, 21 Oct 2012 18:19:27 -0700 Cc: tcpm@ietf.org Subject: [tcpm] I-D Action: draft-ietf-tcpm-initcwnd-05.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: Mon, 22 Oct 2012 01:19:29 -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 Work= ing Group of the IETF. Title : Increasing TCP's Initial Window Author(s) : Jerry Chu Nandita Dukkipati Yuchung Cheng Matt Mathis Filename : draft-ietf-tcpm-initcwnd-05.txt Pages : 24 Date : 2012-10-21 Abstract: This document proposes an experiment to increase the permitted TCP initial window (IW) from between 2 and 4 segments, as specified in RFC 3390, to 10 segments, with a fallback to the existing recommendation when performance issues are detected. It discusses the motivation behind the increase, the advantages and disadvantages of the higher initial window, and presents results from several large scale experiments showing that the higher initial window improves the overall performance of many web services without resulting in a congestion collapse. The document closes with a discussion of usage and deployment for further experimental purpose recommended by the IETF TCP Maintenance and Minor Extensions (TCPM) working group. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tcpm-initcwnd There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-tcpm-initcwnd-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tcpm-initcwnd-05 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From michawe@ifi.uio.no Mon Oct 22 06:41:01 2012 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 CF18621F8BB7 for ; Mon, 22 Oct 2012 06:41:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.52 X-Spam-Level: X-Spam-Status: No, score=-102.52 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r4ohOtpAQB6M for ; Mon, 22 Oct 2012 06:41:01 -0700 (PDT) Received: from mail-out1.uio.no (mail-out1.uio.no [IPv6:2001:700:100:10::57]) by ietfa.amsl.com (Postfix) with ESMTP id 8942521F872E for ; Mon, 22 Oct 2012 06:41:00 -0700 (PDT) Received: from mail-mx3.uio.no ([129.240.10.44]) by mail-out1.uio.no with esmtp (Exim 4.75) (envelope-from ) id 1TQIFX-0002Yx-1z; Mon, 22 Oct 2012 15:40:59 +0200 Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx3.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1TQIFW-0006o1-BU; Mon, 22 Oct 2012 15:40:59 +0200 From: Michael Welzl Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_54AAF596-9EE9-4F93-A52B-569F2DC63BED" Date: Mon, 22 Oct 2012 15:40:57 +0200 References: <20121022133535.29919.13549.idtracker@ietfa.amsl.com> To: "tcpm@ietf.org Extensions" Message-Id: X-Mailer: Apple Mail (2.1283) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 11 msgs/h 3 sum rcpts/h 14 sum msgs/h 6 total rcpts 24873 max rcpts/h 58 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.9, required=5.0, autolearn=disabled, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.912, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: DEEC3CD2B9B8B414D3B3C2D88DCC8E2EF4364BB6 X-UiO-SPAM-Test: remote_host: 129.240.68.135 spam_score: -58 maxlevel 80 minaction 1 bait 0 mail/h: 3 total 10042 max/h 21 blacklist 0 greylist 0 ratelimit 0 Cc: Per Hurtig Subject: [tcpm] Fwd: New Version Notification for draft-hurtig-tcpm-rtorestart-03.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: Mon, 22 Oct 2012 13:41:01 -0000 --Apple-Mail=_54AAF596-9EE9-4F93-A52B-569F2DC63BED Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii FYI, We have submitted an update. The algorithm is unchanged - I had promised = a simplification in Vancouver, but we have found that this doesn't work. There is now some discussion of how this complements some other = algorithms, and how it relates to TLP. I will try to make this = relationship very clear in my presentation in Atlanta. Cheers, Michael Begin forwarded message: > From: internet-drafts@ietf.org > Subject: New Version Notification for = draft-hurtig-tcpm-rtorestart-03.txt > Date: 22. oktober 2012 15:35:35 GMT+02:00 > To: michawe@ifi.uio.no > Cc: per.hurtig@kau.se, apetlund@simula.no >=20 >=20 > A new version of I-D, draft-hurtig-tcpm-rtorestart-03.txt > has been successfully submitted by Michael Welzl and posted to the > IETF repository. >=20 > Filename: draft-hurtig-tcpm-rtorestart > Revision: 03 > Title: TCP and SCTP RTO Restart > Creation date: 2012-10-22 > WG ID: Individual Submission > Number of pages: 10 > URL: = http://www.ietf.org/internet-drafts/draft-hurtig-tcpm-rtorestart-03.txt > Status: = http://datatracker.ietf.org/doc/draft-hurtig-tcpm-rtorestart > Htmlized: = http://tools.ietf.org/html/draft-hurtig-tcpm-rtorestart-03 > Diff: = http://www.ietf.org/rfcdiff?url2=3Ddraft-hurtig-tcpm-rtorestart-03 >=20 > Abstract: > This document describes a modified algorithm for managing the TCP = and > SCTP retransmission timers that provides faster loss recovery when a > connection's amount of outstanding data is small. The modification > allows the transport to restart its retransmission timer more > aggressively in situations where fast retransmit cannot be used. > This enables faster loss detection and recovery for connections that > are short-lived or application-limited. >=20 >=20 >=20 >=20 > The IETF Secretariat >=20 --Apple-Mail=_54AAF596-9EE9-4F93-A52B-569F2DC63BED Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Subject: New Version Notification for = draft-hurtig-tcpm-rtorestart-03.txt
Date: 22. oktober 2012 = 15:35:35 GMT+02:00
= =

A new version of I-D, = draft-hurtig-tcpm-rtorestart-03.txt
has been successfully submitted = by Michael Welzl and posted to the
IETF = repository.

Filename: = draft-hurtig-tcpm-rtorestart
Revision: 03
Title: TCP and = SCTP RTO Restart
Creation date: 2012-10-22
WG ID: = Individual Submission
Number of pages: 10
URL: =             http://www.ietf.org/internet-drafts/draft-hurtig-tcpm-rtorestart-03= .txt
Status: =          http= ://datatracker.ietf.org/doc/draft-hurtig-tcpm-rtorestart
Htmlized: =        http:/= /tools.ietf.org/html/draft-hurtig-tcpm-rtorestart-03
Diff: =            http://www.ietf.org/rfcdiff?url2=3Ddraft-hurtig-tcpm-rtorestart-03
Abstract:
  This document describes a modified = algorithm for managing the TCP and
  SCTP retransmission = timers that provides faster loss recovery when a
=   connection's amount of outstanding data is small.  The = modification
  allows the transport to restart its = retransmission timer more
  aggressively in situations = where fast retransmit cannot be used.
  This enables = faster loss detection and recovery for connections that
=   are short-lived or = application-limited.




The IETF = Secretariat


= --Apple-Mail=_54AAF596-9EE9-4F93-A52B-569F2DC63BED-- From internet-drafts@ietf.org Mon Oct 22 11:57:40 2012 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 A0D701F0425; Mon, 22 Oct 2012 11:57:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.541 X-Spam-Level: X-Spam-Status: No, score=-102.541 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GJ5pfizMMwQ7; Mon, 22 Oct 2012 11:57:39 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A3501F0C3E; Mon, 22 Oct 2012 11:57:39 -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: 4.34 Message-ID: <20121022185739.7534.69954.idtracker@ietfa.amsl.com> Date: Mon, 22 Oct 2012 11:57:39 -0700 Cc: tcpm@ietf.org Subject: [tcpm] I-D Action: draft-ietf-tcpm-fastopen-02.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: Mon, 22 Oct 2012 18:57:40 -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 Work= ing Group of the IETF. Title : TCP Fast Open Author(s) : Yuchung Cheng Jerry Chu Sivasankar Radhakrishnan Arvind Jain Filename : draft-ietf-tcpm-fastopen-02.txt Pages : 22 Date : 2012-10-22 Abstract: TCP Fast Open (TFO) allows data to be carried in the SYN and SYN-ACK packets and consumed by the receiving end during the initial connection handshake, thus saving up to one full round trip time (RTT) compared to standard TCP which requires a three-way handshake (3WHS) to complete before data can be exchanged. Terminology The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tcpm-fastopen There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-tcpm-fastopen-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tcpm-fastopen-02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Mon Oct 22 13:33:54 2012 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 3E36B21F8470; Mon, 22 Oct 2012 13:33:54 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EFkGhQy5AV8E; Mon, 22 Oct 2012 13:33:53 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B762A21F8475; Mon, 22 Oct 2012 13:33:53 -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: 4.34 Message-ID: <20121022203353.15926.29199.idtracker@ietfa.amsl.com> Date: Mon, 22 Oct 2012 13:33:53 -0700 Cc: tcpm@ietf.org Subject: [tcpm] I-D Action: draft-ietf-tcpm-proportional-rate-reduction-03.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: Mon, 22 Oct 2012 20:33:54 -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 Work= ing Group of the IETF. Title : Proportional Rate Reduction for TCP Author(s) : Matt Mathis Nandita Dukkipati Yuchung Cheng Filename : draft-ietf-tcpm-proportional-rate-reduction-03.txt Pages : 16 Date : 2012-10-22 Abstract: This document describes an experimental algorithm, Proportional Rate Reduction (PPR) to improve the accuracy of the amount of data sent by TCP during loss recovery. Standard Congestion Control requires that TCP and other protocols reduce their congestion window in response to losses. This window reduction naturally occurs in the same round trip as the data retransmissions to repair the losses, and is implemented by choosing not to transmit any data in response to some ACKs arriving from the receiver. Two widely deployed algorithms are used to implement this window reduction: Fast Recovery and Rate Halving. Both algorithms are needlessly fragile under a number of conditions, particularly when there is a burst of losses such that the number of ACKs returning to the sender is small. Proportional Rate Reduction minimizes these excess window adjustments such that at the end of recovery the actual window size will be as close as possible to ssthresh, the window size determined by the congestion control algorithm. It is patterned after Rate Halving, but using the fraction that is appropriate for target window chosen by the congestion control algorithm. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tcpm-proportional-rate-reduction There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-tcpm-proportional-rate-reduction-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tcpm-proportional-rate-reduct= ion-03 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From ycheng@google.com Mon Oct 22 15:22:46 2012 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 0DCBD11E80D9 for ; Mon, 22 Oct 2012 15:22:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.969 X-Spam-Level: X-Spam-Status: No, score=-102.969 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R88GFYhUJCFS for ; Mon, 22 Oct 2012 15:22:44 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 36E3D11E8099 for ; Mon, 22 Oct 2012 15:22:44 -0700 (PDT) Received: by mail-ob0-f172.google.com with SMTP id v19so3511344obq.31 for ; Mon, 22 Oct 2012 15:22:43 -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 :content-type:x-system-of-record; bh=4JXbooO6FQfXUEadmmnQzKVlCiK8SCRidORzxwVtqFw=; b=hixWPWT/NktbBxidwQVff2kF/RF+4G5bBMSJxrXsUJrS6DBBWVVNuaBez9uz+NBViY 9g5xhod67n3pM4UfMNAJVsz0Q2tF5CYIzArxwHv+bTJeoVDU2goxsTUeVG8uegLcvZPO +l4D0CCy49h0HNYdEI8gWjNe0wjvt2p1uUwDH0LSk5L0jQweiwkjk+Az0NXYn3d2VabA bHLwi3TXmaGBo/qgXX7OPQh39Fi2hgiv8k74hY7g4JV8eXXHhnY+E9JDB7CAWwrmUxNb 6JCmw7B034A1WhhrWeDZdja+baUVX/Mlh0GF8APUxNo5rUoKFEVI7P/XbKTJ500YfnVc SVAA== X-Google-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 :content-type:x-system-of-record:x-gm-message-state; bh=4JXbooO6FQfXUEadmmnQzKVlCiK8SCRidORzxwVtqFw=; b=nacqCWE4VdaVX8pwkNjNxrDydiEF4guO/ftWKrQ3yTgcdZpDSRRAxa+78kxxGecMMP 865/EBjfWuf/mzgLWvky/hL/ax91R+5TdnwI8X6Y9TO3Gt8BVmB2uA6d5QtmkBSEiCfJ h9VF3fyD/P9wzKZTqaNifFBlFHxS2QFGnKiMdYYPrcoAH4AV0/8ki6dDGLXzjYXQfPAp 5j9PBvswtuPmA3ixdsNxRNtuuOxahbzgJxoQ25kGycuoNBww2vgU2P+E6WpLHYvNBO4v 3m7uVIcbVuvMqpSb7nR6+ND4zmu+4jNExQQJcr1tG2YV6o/fL4rK4S8Nre2NT76LPOcX sn0A== Received: by 10.182.69.50 with SMTP id b18mr8250243obu.75.1350944563856; Mon, 22 Oct 2012 15:22:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.60.4.70 with HTTP; Mon, 22 Oct 2012 15:22:23 -0700 (PDT) In-Reply-To: <20121022185739.7534.69954.idtracker@ietfa.amsl.com> References: <20121022185739.7534.69954.idtracker@ietfa.amsl.com> From: Yuchung Cheng Date: Mon, 22 Oct 2012 15:22:23 -0700 Message-ID: To: tcpm@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true X-Gm-Message-State: ALoCoQkK2U+GyfxfxeCdWBlcfNU0bXnTUUWg+nz6AH5IDGAzl4Cv1NrUe9X/gmbQojE18LF8DIz8OEa50ebUE2LGGTcBkAlUf4JuChvmSGPTg63eBmbrRGNxJYNEP6VKyB2tuuPuVDQ1IZvzIvDkbMY3VaTtCimdzMiyPvZJykEuJsm0tRYTudEVFyL+SMhkv4p/OQtSwOpr Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-fastopen-02.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: Mon, 22 Oct 2012 22:22:47 -0000 On Mon, Oct 22, 2012 at 11:57 AM, wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the TCP Maintenance and Minor Extensions Working Group of the IETF. > > Title : TCP Fast Open > Author(s) : Yuchung Cheng > Jerry Chu > Sivasankar Radhakrishnan > Arvind Jain > Filename : draft-ietf-tcpm-fastopen-02.txt > Pages : 22 > Date : 2012-10-22 > > Abstract: > TCP Fast Open (TFO) allows data to be carried in the SYN and SYN-ACK > packets and consumed by the receiving end during the initial > connection handshake, thus saving up to one full round trip time > (RTT) compared to standard TCP which requires a three-way handshake > (3WHS) to complete before data can be exchanged. ChangeLog since 01: - elaborate more on the issue of duplicate SYN-data (sec 2.1) - use draft-tcpm-experimental-options (sec 10) - add a new subsection about attacks from behind NAT (sec 6.3) and discuss Bob Briscoe's idea on defending with TCP-TS and cookies - use null cookie (end of sec 4.1.2) (courtesy of Bob Briscoe) - explain the problem of cookie option in FIN (end of 4.2.1) - re-emphasize other than including data in SYN packet. TFO draft does not change any part of congestion control, and the transmission MUST be governed by CC (sec 4.2.2) - a bunch of minor edits > > Terminology > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-tcpm-fastopen > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-tcpm-fastopen-02 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-fastopen-02 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From pasi.sarolahti@iki.fi Tue Oct 23 02:37:57 2012 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 972E821F867B for ; Tue, 23 Oct 2012 02:37:57 -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=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nTFdfJjS7Vme for ; Tue, 23 Oct 2012 02:37:56 -0700 (PDT) Received: from kirsi2.inet.fi (mta-out.inet.fi [195.156.147.13]) by ietfa.amsl.com (Postfix) with ESMTP id 635BD21F8686 for ; Tue, 23 Oct 2012 02:37:56 -0700 (PDT) Received: from pc117.netlab.hut.fi (130.233.154.117) by kirsi2.inet.fi (8.5.140.03) (authenticated as saropa-1) id 502AD36000816E26 for tcpm@ietf.org; Tue, 23 Oct 2012 12:37:54 +0300 From: Pasi Sarolahti Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 23 Oct 2012 12:37:56 +0300 Message-Id: To: tcpm@ietf.org Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) Subject: [tcpm] TCPM status 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, 23 Oct 2012 09:37:57 -0000 Hi, Below is the chairs' understanding of the current status of various WG = documents, or individual documents that have recently been discussed in = TCPM. Please let us know of any corrections or clarifications. Thanks! - Pasi Recent RFCs ----------- Conservative SACK-based Recovery Algorithm / RFC 3517bis (draft-ietf-tcpm-3517bis) * Milestone Target: Proposed Standard in October 2010 * Status: RFC 6675 (August 2012) MSS Option (draft-ietf-tcpm-tcpmss) * Milestone Target: Proposed Standard in July 2009 * Status: RFC 6691 (July 2012) The NewReno Modification to TCP's Fast Recovery Algorithm (draft-ietf-tcpm-rfc3782-bis) * Milestone Target: Proposed Standard in April 2011 * Status: RFC 6582 (April 2012) WG Items Nearing RFC Publication -------------------------------- Increasing the Initial Window (draft-ietf-tcpm-initcwnd) * Milestone Target: Experimental in September 2011 * Status: WGLC concluded, authors have revised draft based on comments * Action: Chairs to submit for publication (Yoshifumi will shepherd) Proportional Rate Reduction for TCP (draft-ietf-tcpm-proportional-rate-reduction) * Milestone Target: Experimental in May 2012 * Status: WGLC concluded, authors have revised draft based on comments * Action: Chairs to submit for publication (Pasi will shepherd) WG Items in WGLC or being revised after WGLC -------------------------------------------- Shared Use of Experimental TCP Options (draft-ietf-tcpm-experimental-options) * Milestone Target: PS in Sept. 2012 * Status: WGLC ongoing until Oct 26 * Action: Michael to conclude WGLC, review comments, submit for = publication Active WG Items --------------- 1323bis (draft-ietf-tcpm-1323bis) * Milestone Target: Proposed Standard in July 2009 * Status: Revised after IETF-84, waiting for reviews from WG * Action: WG to review the draft (some volunteers from last meeting) TCP Fast Open (draft-ietf-tcpm-fastopen) * Milestone Target: Experimental in Sept. 2012 * Status: Revised after IETF-84 * Action: Needs WG review Active Individual Internet-Drafts --------------------------------- Problem Statement and Requirements for a More Accurate ECN Feedback (draft-kuehlewind-tcpm-accecn-reqs) * Status: New draft submitted after IETF-84 * Action: Will be discussed in IETF-85 Accurate ECN Feedback Option in TCP (draft-kuehlewind-tcpm-accurate-ecn) (draft-kuehlewind-tcpm-accurate-ecn-option) * Status: Not updated since IETF-84 * Action: Will be discussed in IETF-85 TCP and SCTP RTO Restart (draft-hurtig-tcpm-rtorestart) * Status: Updated ver-03 after IETF-84 * Action: Presentation at IETF-85 TCP Loss Probe (TLP): An Algorithm for Fast Recovery of Tail Losses (draft-dukkipati-tcpm-tcp-loss-probe) * Status: Not updated since IETF-84 * Action: Will be discussed in IETF-85 Updating TCP to support Variable-Rate Traffic (draft-fairhurst-tcpm-newcwv) * Status: ver -05 updated in Sep 2012 * Action: To be discussed at IETF-85 Additional negotiation in the TCP Timestamp Option field during the TCP = handshake (draft-scheffenegger-tcpm-timestamp-negotiation) * Status: Updated ver-05 after IETF-84 Exposure of Time Intervals for the TCP Timestamp Option (draft-trammell-tcpm-timestamp-interval) * Status: New draft after IETF-84 Laminar TCP and the case for refactoring TCP congestion control (draft-mathis-tcpm-tcp-laminar) * Status: No updates since IETF-84 A Roadmap for TCP Specification Documents (draft-zimmermann-tcpm-tcp-rfc4614bis) * Status: Not updated since IETF-84 A TCP Authentication Option NAT Extension (draft-touch-tcp-ao-nat) * Status: No updates since IETF-84 Automating the Initial Window in TCP (draft-touch-tcpm-automatic-iw) * Status: Not updated since IETF-84 Highly Efficient Selective Acknowledgement (SACK) for TCP (draft-sabatini-tcp-sack) * Status: Updated ver-01 after IETF-84 From trammell@tik.ee.ethz.ch Tue Oct 23 07:09:03 2012 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 B577C21F8440 for ; Tue, 23 Oct 2012 07:09:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rOq3wVEQBJPu for ; Tue, 23 Oct 2012 07:09:03 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 2153C11E80A5 for ; Tue, 23 Oct 2012 07:09:03 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 1119ED9494 for ; Tue, 23 Oct 2012 16:09:01 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id kM8ihVbYYLUr for ; Tue, 23 Oct 2012 16:09:00 +0200 (MEST) Received: from public-docking-etx-3-45.ethz.ch (public-docking-etx-3-45.ethz.ch [129.132.128.45]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id CE86DD9315 for ; Tue, 23 Oct 2012 16:09:00 +0200 (MEST) From: Brian Trammell Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <375E72D8-E2CC-4318-814C-9B9E574FE7E5@tik.ee.ethz.ch> Date: Tue, 23 Oct 2012 16:09:30 +0200 To: tcpm@ietf.org Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) Subject: [tcpm] timestamp negotiation and interval exposure 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, 23 Oct 2012 14:09:03 -0000 Greetings, all, We've recently submitted = draft-scheffenegger-tcpm-timestamp-negotiation-05 and = draft-trammell-tcpm-timestamp-interval-00. As discussed in Vancouver and = on the list, we've split the text on timestamp interval exposure out = into its own draft, separating interval encoding from the negotiation = mechanism. We additionally specify an experimental TCP option encoding = for interval exposure, such that it could be used on its own. This is still very much a work in progress, as the present revisions of = the draft reflect the work to split them but little in the way of other = enhancements. We plan to submit new revisions shortly after the Atlanta = IETF meeting.=20 Best regards, Brian= From pasi.sarolahti@iki.fi Wed Oct 24 09:33:34 2012 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 9F4FE21F867B for ; Wed, 24 Oct 2012 09:33:34 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HqPLVGThcofA for ; Wed, 24 Oct 2012 09:33:34 -0700 (PDT) Received: from kirsi2.inet.fi (mta-out.inet.fi [195.156.147.13]) by ietfa.amsl.com (Postfix) with ESMTP id 7F48421F8444 for ; Wed, 24 Oct 2012 09:33:32 -0700 (PDT) Received: from [192.168.1.65] (80.223.92.46) by kirsi2.inet.fi (8.5.140.03) (authenticated as saropa-1) id 5087141600030D70 for tcpm@ietf.org; Wed, 24 Oct 2012 19:33:30 +0300 From: Pasi Sarolahti Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 24 Oct 2012 19:33:28 +0300 Message-Id: <117E20C3-F8C3-4DFE-868A-74A2BFF2F8A8@iki.fi> To: tcpm@ietf.org Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) Subject: [tcpm] Draft TCPM agenda 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: Wed, 24 Oct 2012 16:33:35 -0000 Hi, Below is the draft agenda for the TCPM meeting in Atlanta. Comments are = welcome. - Pasi TCPM meeting, IETF-85, Atlanta, GA, USA Tuesday, November 6, 09:00 - 11:30 WG Status --------- Time: 5 minutes Working Group Items ------------------- * RFC 1323bis draft-ietf-tcpm-1323bis Speaker: Richard Scheffenegger Time: 10 minutes for presentation + 10 minutes for discussion * TCP Fast Open draft-ietf-tcpm-fastopen Speaker: Yuchung Cheng Time: 10 + 10 minutes More Accurate ECN discussion ---------------------------- * Problem statement and draft progress draft-kuehlewind-tcpm-accecn-reqs draft-kuehlewind-tcpm-accurate-ecn draft-kuehlewind-tcpm-accurate-ecn-option Speaker: Mirja Kuehlewind Time: 15 minutes * Discussion Time: 15 minutes RTO loss recovery enhancements ------------------------------ * TCP and SCTP RTO Restart draft-hurtig-tcpm-rtorestart Speaker: Michael Welzl Time: 10 minutes * TCP Loss Probe (TLP): An Algorithm for Fast Recovery of Tail Losses draft-dukkipati-tcpm-tcp-loss-probe Speaker: Yuchung Cheng Time: 10 minutes * Discussion Time: 10 minutes Other Items ----------- * Updating TCP to support Rate-Limited Traffic draft-fairhurst-tcpm-newcwv Speaker: Gorry Fairhurst Time: 10 + 10 minutes From michael.scharf@alcatel-lucent.com Fri Oct 26 12:57:31 2012 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 34B3C21F85B3 for ; Fri, 26 Oct 2012 12:57:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.949 X-Spam-Level: X-Spam-Status: No, score=-7.949 tagged_above=-999 required=5 tests=[AWL=-2.300, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZYjOimD844dW for ; Fri, 26 Oct 2012 12:57:30 -0700 (PDT) Received: from smail5.alcatel.fr (smail5.alcatel.fr [62.23.212.27]) by ietfa.amsl.com (Postfix) with ESMTP id E7E0821F8634 for ; Fri, 26 Oct 2012 12:57:29 -0700 (PDT) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail5.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q9QJvRdx000990 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 26 Oct 2012 21:57:27 +0200 Received: from FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com ([135.120.45.56]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Fri, 26 Oct 2012 21:57:26 +0200 From: "Scharf, Michael (Michael)" To: Yuchung Cheng Date: Fri, 26 Oct 2012 21:57:25 +0200 Thread-Topic: draft-ietf-tcpm-fastopen-02 vs. congestion control Thread-Index: Ac2wo8kzuIcCOOAbSai4cwNylqzwxADCrh0w Message-ID: <2A886F9088894347A3BE0CC5B7A85F3E9AA0F0A61B@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> References: <20121022185739.7534.69954.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.13 Cc: "tcpm@ietf.org" Subject: [tcpm] draft-ietf-tcpm-fastopen-02 vs. congestion control 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, 26 Oct 2012 19:57:31 -0000 Yuchung, You state that fast open does not change the congestion control, but I am s= till wondering whether this is actually true. My impression is that fast op= en can have side effects that affect congestion control, at least in corner= cases. But please correct me if I am wrong. Let's assume that the downlink between a HTTP server and a HTTP client is s= everely congested. With current TCP, the client will send a SYN, and the server will respond b= y SYN-ACK. Even if the SYN carries data, the server cannot respond. That im= plies that the server sends one packet to a congested downlink. If it gets = dropped, the whole connection backs off for a moment. That may help to redu= ce the congestion. With fast open, the client will send SYN+data, and the server will potentia= lly respond by a series of packets as allowed by the initial congestion win= dow. According to RFC 3390, this implies sending 3 packets to the severely = congested downlink. That is apparently worse... Thus, unless I miss something here, the amount of data that a server could = send to a severely congested link can be significantly larger with fast ope= n. Fast open may thus cause self-congestion in such a scenario. Theoretical= ly it could maybe also harm other traffic (fairness...). It is not entirely clear to me whether that difference indeed matters in re= ality with RFC 3390, since fast open mostly affects *when* data is sent. Ma= ybe this is a corner case only. But at least it might be worthwile to menti= on that side-effect in the draft. That might also help to understand what w= ould happen if fast open and IW10 are used at the same time. That question = was raised several times already. Thanks Michael (as individual) > -----Original Message----- > From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On=20 > Behalf Of Yuchung Cheng > Sent: Tuesday, October 23, 2012 12:22 AM > To: tcpm@ietf.org > Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-fastopen-02.txt >=20 > On Mon, Oct 22, 2012 at 11:57 AM, wrote: > > > > A New Internet-Draft is available from the on-line=20 > Internet-Drafts directories. > > This draft is a work item of the TCP Maintenance and Minor=20 > Extensions Working Group of the IETF. > > > > Title : TCP Fast Open > > Author(s) : Yuchung Cheng > > Jerry Chu > > Sivasankar Radhakrishnan > > Arvind Jain > > Filename : draft-ietf-tcpm-fastopen-02.txt > > Pages : 22 > > Date : 2012-10-22 > > > > Abstract: > > TCP Fast Open (TFO) allows data to be carried in the SYN=20 > and SYN-ACK > > packets and consumed by the receiving end during the initial > > connection handshake, thus saving up to one full round trip time > > (RTT) compared to standard TCP which requires a=20 > three-way handshake > > (3WHS) to complete before data can be exchanged. > ChangeLog since 01: >=20 > - elaborate more on the issue of duplicate SYN-data (sec 2.1) >=20 > - use draft-tcpm-experimental-options (sec 10) >=20 > - add a new subsection about attacks from behind NAT (sec 6.3) > and discuss Bob Briscoe's idea on defending with TCP-TS and > cookies >=20 > - use null cookie (end of sec 4.1.2) (courtesy of Bob Briscoe) >=20 > - explain the problem of cookie option in FIN (end of 4.2.1) >=20 > - re-emphasize other than including data in SYN packet. TFO > draft does not change any part of congestion control, and > the transmission MUST be governed by CC (sec 4.2.2) >=20 > - a bunch of minor edits >=20 > > > > Terminology > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-tcpm-fastopen > > > > There's also a htmlized version available at: > > http://tools.ietf.org/html/draft-ietf-tcpm-fastopen-02 > > > > A diff from the previous version is available at: > > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tcpm-fastopen-02 > > > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > _______________________________________________ > > 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 ycheng@google.com Sat Oct 27 13:03:44 2012 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 6421721F854F for ; Sat, 27 Oct 2012 13:03:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.778 X-Spam-Level: X-Spam-Status: No, score=-99.778 tagged_above=-999 required=5 tests=[FM_FORGED_GMAIL=0.622, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U8di0BUFDdb2 for ; Sat, 27 Oct 2012 13:03:43 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0217D21F8540 for ; Sat, 27 Oct 2012 13:03:39 -0700 (PDT) Received: by mail-ob0-f172.google.com with SMTP id v19so4015121obq.31 for ; Sat, 27 Oct 2012 13:03:39 -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:content-transfer-encoding:x-system-of-record; bh=YpV5AYo0TziJq1fhYAj84E7bivwU6eLmEnrvFC+5EpU=; b=XH8lwq7cxkNXodBlc5JWhFza/yjDoHMAwl3IwqbIxecv8sidWLk5QXwWFSFDIBFNOZ a7pJPQzzXYR9GrgCvYLbkP6oVF+fFdfosMM1rFerAp0JyxRLyF/4el1O6TPxR6k472OY 3lON8IMb+J1sNrYJEleJ69J0JJ5PIMyK8DKVrMTab2N7JjG2ixp2zNjY23j3YvA0aAIO NW5nObFr/ALlYJH1gSVJ2XGVtD8i9RR0keNbzc2VoO0gyvnNWVhuXsXme3oKCzIltS7K jtBE0lNoTj++wbKBoOIRJ/MSzUwaMrs7hrg46UqUPbAoXDK+hHcuVJMcW3P8nBrcnPxa ttKg== X-Google-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:content-transfer-encoding:x-system-of-record :x-gm-message-state; bh=YpV5AYo0TziJq1fhYAj84E7bivwU6eLmEnrvFC+5EpU=; b=kC8SwVNlnD81YNi+HL+l6V+GT7UHNkhiKFC+gAW9sltolKfXAIGaxkJxTLRfUF95xg M88uBBBndDxSKfGOCm8qVxxORNGzFArUuyyg+OrRzPGgAYMsHB2ZuM73JG+werasv2kz H1pnW2jlgk+wNDyCKX8XHF5O3FRWhfPk+Tju/8XJ/pAQDULmm1HRXhxWrmknnPzitFXS FhFYfqGTA6RKojmOMk5BK49MgZxWE/m74AdPFKk/zUZGlD0Q6oWBjeuCzw5wbL2mgzNb RPTJAfEQa6sLsaD/aeLvmB+Um3CDc84+TdvfglUmT1mY2TtNMUP4fnWmfiNohBuTMJRr AkTA== Received: by 10.60.14.200 with SMTP id r8mr16639855oec.45.1351368219256; Sat, 27 Oct 2012 13:03:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.60.28.6 with HTTP; Sat, 27 Oct 2012 13:03:19 -0700 (PDT) In-Reply-To: <2A886F9088894347A3BE0CC5B7A85F3E9AA0F0A61B@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> References: <20121022185739.7534.69954.idtracker@ietfa.amsl.com> <2A886F9088894347A3BE0CC5B7A85F3E9AA0F0A61B@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> From: Yuchung Cheng Date: Sat, 27 Oct 2012 13:03:19 -0700 Message-ID: To: "Scharf, Michael (Michael)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true X-Gm-Message-State: ALoCoQka8AY84ISZon/FU/87TDukFCR5C8i+WZUtdJxTBDbLHF++ILT8UeI/3r1ExcfUGLcyIAwZnh4UWCRaBBg0IcPNJwY/zvXlRTUKCrndgEvP8sJ3wIs/jd9sb4fCurKFxyzBs/3GEcpdk2u+NQewM855abk/zC7NYi9Ru4+4Xl0vh9mP4Rfn4Aw1NndW2em0bjBxzic5 Cc: "tcpm@ietf.org" Subject: Re: [tcpm] draft-ietf-tcpm-fastopen-02 vs. congestion control 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: Sat, 27 Oct 2012 20:03:44 -0000 On Fri, Oct 26, 2012 at 12:57 PM, Scharf, Michael (Michael) wrote: > Yuchung, > > You state that fast open does not change the congestion control, but I am= still wondering whether this is actually true. My impression is that fast = open can have side effects that affect congestion control, at least in corn= er cases. But please correct me if I am wrong. Which part in RFC5681 needs to be updated by Fast Open if you don't think it's true? > > Let's assume that the downlink between a HTTP server and a HTTP client is= severely congested. > > With current TCP, the client will send a SYN, and the server will respond= by SYN-ACK. Even if the SYN carries data, the server cannot respond. That = implies that the server sends one packet to a congested downlink. If it get= s dropped, the whole connection backs off for a moment. That may help to re= duce the congestion. > > With fast open, the client will send SYN+data, and the server will potent= ially respond by a series of packets as allowed by the initial congestion w= indow. According to RFC 3390, this implies sending 3 packets to the severel= y congested downlink. That is apparently worse... > > Thus, unless I miss something here, the amount of data that a server coul= d send to a severely congested link can be significantly larger with fast o= pen. Fast open may thus cause self-congestion in such a scenario. Theoretic= ally it could maybe also harm other traffic (fairness...). What if the handshakes finish smoothly in current TCP, but the network becomes congested as you sketched by the time server is ready to send? and many servers today do not change cwnd after idle. It's certainly not a corner case then. How about changing the scenarios with syn-cookies? We appreciate you scrutinizing the draft. but I suggest you experts look congestion control on at higher level. How about loss-based algorithm causing huge queues with BB. Ok I am deviating now ... > > It is not entirely clear to me whether that difference indeed matters in = reality with RFC 3390, since fast open mostly affects *when* data is sent. = Maybe this is a corner case only. But at least it might be worthwile to men= tion that side-effect in the draft. That might also help to understand what= would happen if fast open and IW10 are used at the same time. That questio= n was raised several times already. > As I said, IW10 is part of RFC5681. TFO does not update RFC5681 currently. Should I mention TCP-SACK in TFO too? > Thanks > > Michael (as individual) > > >> -----Original Message----- >> From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On >> Behalf Of Yuchung Cheng >> Sent: Tuesday, October 23, 2012 12:22 AM >> To: tcpm@ietf.org >> Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-fastopen-02.txt >> >> On Mon, Oct 22, 2012 at 11:57 AM, wrote: >> > >> > A New Internet-Draft is available from the on-line >> Internet-Drafts directories. >> > This draft is a work item of the TCP Maintenance and Minor >> Extensions Working Group of the IETF. >> > >> > Title : TCP Fast Open >> > Author(s) : Yuchung Cheng >> > Jerry Chu >> > Sivasankar Radhakrishnan >> > Arvind Jain >> > Filename : draft-ietf-tcpm-fastopen-02.txt >> > Pages : 22 >> > Date : 2012-10-22 >> > >> > Abstract: >> > TCP Fast Open (TFO) allows data to be carried in the SYN >> and SYN-ACK >> > packets and consumed by the receiving end during the initial >> > connection handshake, thus saving up to one full round trip time >> > (RTT) compared to standard TCP which requires a >> three-way handshake >> > (3WHS) to complete before data can be exchanged. >> ChangeLog since 01: >> >> - elaborate more on the issue of duplicate SYN-data (sec 2.1) >> >> - use draft-tcpm-experimental-options (sec 10) >> >> - add a new subsection about attacks from behind NAT (sec 6.3) >> and discuss Bob Briscoe's idea on defending with TCP-TS and >> cookies >> >> - use null cookie (end of sec 4.1.2) (courtesy of Bob Briscoe) >> >> - explain the problem of cookie option in FIN (end of 4.2.1) >> >> - re-emphasize other than including data in SYN packet. TFO >> draft does not change any part of congestion control, and >> the transmission MUST be governed by CC (sec 4.2.2) >> >> - a bunch of minor edits >> >> > >> > Terminology >> > >> > The IETF datatracker status page for this draft is: >> > https://datatracker.ietf.org/doc/draft-ietf-tcpm-fastopen >> > >> > There's also a htmlized version available at: >> > http://tools.ietf.org/html/draft-ietf-tcpm-fastopen-02 >> > >> > A diff from the previous version is available at: >> > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tcpm-fastopen-02 >> > >> > >> > Internet-Drafts are also available by anonymous FTP at: >> > ftp://ftp.ietf.org/internet-drafts/ >> > >> > _______________________________________________ >> > 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 michael.scharf@alcatel-lucent.com Sun Oct 28 13:14:31 2012 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 4D33321F85A5 for ; Sun, 28 Oct 2012 13:14:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.649 X-Spam-Level: X-Spam-Status: No, score=-9.649 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 58HPdaz12a5s for ; Sun, 28 Oct 2012 13:14:29 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by ietfa.amsl.com (Postfix) with ESMTP id DA95021F8566 for ; Sun, 28 Oct 2012 13:14:28 -0700 (PDT) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q9SKEOc4025973 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Sun, 28 Oct 2012 21:14:24 +0100 Received: from FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com ([135.120.45.56]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Sun, 28 Oct 2012 21:14:24 +0100 From: "Scharf, Michael (Michael)" To: Yuchung Cheng Date: Sun, 28 Oct 2012 21:14:23 +0100 Thread-Topic: draft-ietf-tcpm-fastopen-02 vs. congestion control Thread-Index: Ac20fioJskyQD0dcQ32EPzO9EsA55gAxm89M Message-ID: <2A886F9088894347A3BE0CC5B7A85F3E9AA0F39987@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> References: <20121022185739.7534.69954.idtracker@ietfa.amsl.com> <2A886F9088894347A3BE0CC5B7A85F3E9AA0F0A61B@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com>, In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.80 Cc: "tcpm@ietf.org" Subject: Re: [tcpm] draft-ietf-tcpm-fastopen-02 vs. congestion control 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: Sun, 28 Oct 2012 20:14:31 -0000 Yuchung, I did not suggest that the draft must update RFC 5681. My proposal is that the draft discusses more explicitly what the different = sending behavior implies to a (congested) network. Right now, the draft mai= nly stresses the performance benefit for applications. Well understood. But= it seems to me a valid question whether this benefit comes at some cost fo= r the network, at least in corner cases. I think that some text on that would be good to complete the document. This= could be a short paragraph e. g. in Section 5. This is a quite low-hanging= fruit. It could basically be a better phrasing of our discussion here. Michael (as individual) ________________________________________ Von: Yuchung Cheng [ycheng@google.com] Gesendet: Samstag, 27. Oktober 2012 22:03 An: Scharf, Michael (Michael) Cc: tcpm@ietf.org Betreff: Re: draft-ietf-tcpm-fastopen-02 vs. congestion control On Fri, Oct 26, 2012 at 12:57 PM, Scharf, Michael (Michael) wrote: > Yuchung, > > You state that fast open does not change the congestion control, but I am= still wondering whether this is actually true. My impression is that fast = open can have side effects that affect congestion control, at least in corn= er cases. But please correct me if I am wrong. Which part in RFC5681 needs to be updated by Fast Open if you don't think it's true? > > Let's assume that the downlink between a HTTP server and a HTTP client is= severely congested. > > With current TCP, the client will send a SYN, and the server will respond= by SYN-ACK. Even if the SYN carries data, the server cannot respond. That = implies that the server sends one packet to a congested downlink. If it get= s dropped, the whole connection backs off for a moment. That may help to re= duce the congestion. > > With fast open, the client will send SYN+data, and the server will potent= ially respond by a series of packets as allowed by the initial congestion w= indow. According to RFC 3390, this implies sending 3 packets to the severel= y congested downlink. That is apparently worse... > > Thus, unless I miss something here, the amount of data that a server coul= d send to a severely congested link can be significantly larger with fast o= pen. Fast open may thus cause self-congestion in such a scenario. Theoretic= ally it could maybe also harm other traffic (fairness...). What if the handshakes finish smoothly in current TCP, but the network becomes congested as you sketched by the time server is ready to send? and many servers today do not change cwnd after idle. It's certainly not a corner case then. How about changing the scenarios with syn-cookies? We appreciate you scrutinizing the draft. but I suggest you experts look congestion control on at higher level. How about loss-based algorithm causing huge queues with BB. Ok I am deviating now ... > > It is not entirely clear to me whether that difference indeed matters in = reality with RFC 3390, since fast open mostly affects *when* data is sent. = Maybe this is a corner case only. But at least it might be worthwile to men= tion that side-effect in the draft. That might also help to understand what= would happen if fast open and IW10 are used at the same time. That questio= n was raised several times already. > As I said, IW10 is part of RFC5681. TFO does not update RFC5681 currently. Should I mention TCP-SACK in TFO too? > Thanks > > Michael (as individual) > > >> -----Original Message----- >> From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On >> Behalf Of Yuchung Cheng >> Sent: Tuesday, October 23, 2012 12:22 AM >> To: tcpm@ietf.org >> Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-fastopen-02.txt >> >> On Mon, Oct 22, 2012 at 11:57 AM, wrote: >> > >> > A New Internet-Draft is available from the on-line >> Internet-Drafts directories. >> > This draft is a work item of the TCP Maintenance and Minor >> Extensions Working Group of the IETF. >> > >> > Title : TCP Fast Open >> > Author(s) : Yuchung Cheng >> > Jerry Chu >> > Sivasankar Radhakrishnan >> > Arvind Jain >> > Filename : draft-ietf-tcpm-fastopen-02.txt >> > Pages : 22 >> > Date : 2012-10-22 >> > >> > Abstract: >> > TCP Fast Open (TFO) allows data to be carried in the SYN >> and SYN-ACK >> > packets and consumed by the receiving end during the initial >> > connection handshake, thus saving up to one full round trip time >> > (RTT) compared to standard TCP which requires a >> three-way handshake >> > (3WHS) to complete before data can be exchanged. >> ChangeLog since 01: >> >> - elaborate more on the issue of duplicate SYN-data (sec 2.1) >> >> - use draft-tcpm-experimental-options (sec 10) >> >> - add a new subsection about attacks from behind NAT (sec 6.3) >> and discuss Bob Briscoe's idea on defending with TCP-TS and >> cookies >> >> - use null cookie (end of sec 4.1.2) (courtesy of Bob Briscoe) >> >> - explain the problem of cookie option in FIN (end of 4.2.1) >> >> - re-emphasize other than including data in SYN packet. TFO >> draft does not change any part of congestion control, and >> the transmission MUST be governed by CC (sec 4.2.2) >> >> - a bunch of minor edits >> >> > >> > Terminology >> > >> > The IETF datatracker status page for this draft is: >> > https://datatracker.ietf.org/doc/draft-ietf-tcpm-fastopen >> > >> > There's also a htmlized version available at: >> > http://tools.ietf.org/html/draft-ietf-tcpm-fastopen-02 >> > >> > A diff from the previous version is available at: >> > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tcpm-fastopen-02 >> > >> > >> > Internet-Drafts are also available by anonymous FTP at: >> > ftp://ftp.ietf.org/internet-drafts/ >> > >> > _______________________________________________ >> > 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 ycheng@google.com Tue Oct 30 14:42:58 2012 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 F1B7021F8450 for ; Tue, 30 Oct 2012 14:42:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.077 X-Spam-Level: X-Spam-Status: No, score=-101.077 tagged_above=-999 required=5 tests=[AWL=1.299, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WkG1y4UAas5K for ; Tue, 30 Oct 2012 14:42:57 -0700 (PDT) Received: from mail-ia0-f172.google.com (mail-ia0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id C75F621F8455 for ; Tue, 30 Oct 2012 14:42:56 -0700 (PDT) Received: by mail-ia0-f172.google.com with SMTP id x24so618296iak.31 for ; Tue, 30 Oct 2012 14:42:55 -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:x-system-of-record; bh=Qu3OhzH7+A1lIngFUHjR9R2qX9c/ChqFACPxTAPaM5o=; b=J9UDNe+NlL24QTVmxNCHNXocYOlMNfAgSB8WErMLRnHr8+3MnE7U7NlUFwK2UjFpmG ZML/z9H5yzMReJ47i9cT97+qJwGJMUG17SRtEu9rGM8dmdboF6yhUCaMMDROGRY2koKK EzO2NeLkZ8AuFxbB1XGbr6+a7Xh6Yka4lxtafno3C281xWa9ItdTD6IFY54N8RCZx2W8 ln4dUY0n3cTtdqkS5k4XY8N9GQZwT0d/leI9J45IHYsPuxaa+HHj475AQVzleLVrAsg8 +wwsN9MyFfSuORBSF28yUv2tYUOfA8zfTDwgPGEpWgLBzC988CUDUZQodRgs7oD/3lzm IDLw== X-Google-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:x-system-of-record:x-gm-message-state; bh=Qu3OhzH7+A1lIngFUHjR9R2qX9c/ChqFACPxTAPaM5o=; b=TtN2xC4iqR9Hdg4acPlT2AgG8SHl0NKfj7VAXs0jwv6kYYr5Ms6KNZtg/nDxSdJSvT muln4lwTw0/YIeBkrEsyuZa6XBJuQqcfMyLXaQT2m1XLQRmZ/tf2iqyldCR58D+ShfWy R9pKnv+TX/JLtlvM/BgS9CNU8Mok8+Kci5BjDzVfVBLZ7Dzd3eeX18Vd04qCFWTNnfQ7 OoDFVbDAjUdC7kFlWSVI7A6+0O/TucCfPV6rrphrf22npJQ9c1/AK4lsqr1Y1l8m3ATH Xbh6It9PNc1CYMXgsO2mzWpDiYZsdUPKCTtLMAi7426K5qOM1K2Z+zV3DSfc2QqgjP37 RIrA== Received: by 10.50.0.241 with SMTP id 17mr2891444igh.40.1351633375030; Tue, 30 Oct 2012 14:42:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.9.170 with HTTP; Tue, 30 Oct 2012 14:42:34 -0700 (PDT) In-Reply-To: <2A886F9088894347A3BE0CC5B7A85F3E9AA0F39987@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> References: <20121022185739.7534.69954.idtracker@ietfa.amsl.com> <2A886F9088894347A3BE0CC5B7A85F3E9AA0F0A61B@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> <2A886F9088894347A3BE0CC5B7A85F3E9AA0F39987@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> From: Yuchung Cheng Date: Tue, 30 Oct 2012 14:42:34 -0700 Message-ID: To: "Scharf, Michael (Michael)" Content-Type: multipart/alternative; boundary=e89a8f5034582f6f1204cd4dab97 X-System-Of-Record: true X-Gm-Message-State: ALoCoQmOZQl0s4AIbFAe0M9viL3pCYJdWT+lu3s7XIc6ksusTmiEIrCesv/IPy/mt2ApQnUJ2752sJtN7Hd1fAJMPISR8zMp1OjBYuRBJLNDKT0jyf1ZzBOFcwcaSbRXKiFGvSQZ1/3UZMD1Cw35hbml+4DoV5k0B3ThH2ICN1rDmxcNA5EgSWgPdX5lTE2h523fhuX8NiSt Cc: "tcpm@ietf.org" Subject: Re: [tcpm] draft-ietf-tcpm-fastopen-02 vs. congestion control 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, 30 Oct 2012 21:42:58 -0000 --e89a8f5034582f6f1204cd4dab97 Content-Type: text/plain; charset=ISO-8859-1 On Sun, Oct 28, 2012 at 1:14 PM, Scharf, Michael (Michael) < michael.scharf@alcatel-lucent.com> wrote: > Yuchung, > > I did not suggest that the draft must update RFC 5681. > > My proposal is that the draft discusses more explicitly what the different > sending behavior implies to a (congested) network. Right now, the draft > mainly stresses the performance benefit for applications. Well understood. > But it seems to me a valid question whether this benefit comes at some cost > for the network, at least in corner cases. > > I think that some text on that would be good to complete the document. > This could be a short paragraph e. g. in Section 5. This is a quite > low-hanging fruit. It could basically be a better phrasing of our > discussion here. > How about this "If SYNACK is lost during handshake, in Fast Open the server may send up to an initial window of data because the loss is detected afterwards. But in regular handshake, the server detects the loss first and reduces the initial congestion window according to RFC". > > Michael (as individual) > > > ________________________________________ > Von: Yuchung Cheng [ycheng@google.com] > Gesendet: Samstag, 27. Oktober 2012 22:03 > An: Scharf, Michael (Michael) > Cc: tcpm@ietf.org > Betreff: Re: draft-ietf-tcpm-fastopen-02 vs. congestion control > > On Fri, Oct 26, 2012 at 12:57 PM, Scharf, Michael (Michael) > wrote: > > Yuchung, > > > > You state that fast open does not change the congestion control, but I > am still wondering whether this is actually true. My impression is that > fast open can have side effects that affect congestion control, at least in > corner cases. But please correct me if I am wrong. > > Which part in RFC5681 needs to be updated by Fast Open if you don't > think it's true? > > > > > Let's assume that the downlink between a HTTP server and a HTTP client > is severely congested. > > > > With current TCP, the client will send a SYN, and the server will > respond by SYN-ACK. Even if the SYN carries data, the server cannot > respond. That implies that the server sends one packet to a congested > downlink. If it gets dropped, the whole connection backs off for a moment. > That may help to reduce the congestion. > > > > With fast open, the client will send SYN+data, and the server will > potentially respond by a series of packets as allowed by the initial > congestion window. According to RFC 3390, this implies sending 3 packets to > the severely congested downlink. That is apparently worse... > > > > Thus, unless I miss something here, the amount of data that a server > could send to a severely congested link can be significantly larger with > fast open. Fast open may thus cause self-congestion in such a scenario. > Theoretically it could maybe also harm other traffic (fairness...). > > What if the handshakes finish smoothly in current TCP, but the network > becomes congested as you sketched by the time server is ready to send? > and many servers today do not change cwnd after idle. It's certainly > not a corner case then. How about changing the scenarios with > syn-cookies? > > We appreciate you scrutinizing the draft. but I suggest you experts > look congestion control on at higher level. How about loss-based > algorithm causing huge queues with BB. Ok I am deviating now ... > > > > > It is not entirely clear to me whether that difference indeed matters in > reality with RFC 3390, since fast open mostly affects *when* data is sent. > Maybe this is a corner case only. But at least it might be worthwile to > mention that side-effect in the draft. That might also help to understand > what would happen if fast open and IW10 are used at the same time. That > question was raised several times already. > > > As I said, IW10 is part of RFC5681. TFO does not update RFC5681 > currently. Should I mention TCP-SACK in TFO too? > > > > Thanks > > > > Michael (as individual) > > > > > >> -----Original Message----- > >> From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On > >> Behalf Of Yuchung Cheng > >> Sent: Tuesday, October 23, 2012 12:22 AM > >> To: tcpm@ietf.org > >> Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-fastopen-02.txt > >> > >> On Mon, Oct 22, 2012 at 11:57 AM, wrote: > >> > > >> > A New Internet-Draft is available from the on-line > >> Internet-Drafts directories. > >> > This draft is a work item of the TCP Maintenance and Minor > >> Extensions Working Group of the IETF. > >> > > >> > Title : TCP Fast Open > >> > Author(s) : Yuchung Cheng > >> > Jerry Chu > >> > Sivasankar Radhakrishnan > >> > Arvind Jain > >> > Filename : draft-ietf-tcpm-fastopen-02.txt > >> > Pages : 22 > >> > Date : 2012-10-22 > >> > > >> > Abstract: > >> > TCP Fast Open (TFO) allows data to be carried in the SYN > >> and SYN-ACK > >> > packets and consumed by the receiving end during the initial > >> > connection handshake, thus saving up to one full round trip time > >> > (RTT) compared to standard TCP which requires a > >> three-way handshake > >> > (3WHS) to complete before data can be exchanged. > >> ChangeLog since 01: > >> > >> - elaborate more on the issue of duplicate SYN-data (sec 2.1) > >> > >> - use draft-tcpm-experimental-options (sec 10) > >> > >> - add a new subsection about attacks from behind NAT (sec 6.3) > >> and discuss Bob Briscoe's idea on defending with TCP-TS and > >> cookies > >> > >> - use null cookie (end of sec 4.1.2) (courtesy of Bob Briscoe) > >> > >> - explain the problem of cookie option in FIN (end of 4.2.1) > >> > >> - re-emphasize other than including data in SYN packet. TFO > >> draft does not change any part of congestion control, and > >> the transmission MUST be governed by CC (sec 4.2.2) > >> > >> - a bunch of minor edits > >> > >> > > >> > Terminology > >> > > >> > The IETF datatracker status page for this draft is: > >> > https://datatracker.ietf.org/doc/draft-ietf-tcpm-fastopen > >> > > >> > There's also a htmlized version available at: > >> > http://tools.ietf.org/html/draft-ietf-tcpm-fastopen-02 > >> > > >> > A diff from the previous version is available at: > >> > http://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-fastopen-02 > >> > > >> > > >> > Internet-Drafts are also available by anonymous FTP at: > >> > ftp://ftp.ietf.org/internet-drafts/ > >> > > >> > _______________________________________________ > >> > 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 > >> > --e89a8f5034582f6f1204cd4dab97 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Sun, Oct 28, 2012 at 1:14 PM, Scharf,= Michael (Michael) <michael.scharf@alcatel-lucent.com&= gt; wrote:
Yuchung,

I did not suggest that the draft must update RFC 5681.

My proposal is that the draft discusses more explicitly what the different = sending behavior implies to a (congested) network. Right now, the draft mai= nly stresses the performance benefit for applications. Well understood. But= it seems to me a valid question whether this benefit comes at some cost fo= r the network, at least in corner cases.

I think that some text on that would be good to complete the document. This= could be a short paragraph e. g. in Section 5. This is a quite low-hanging= fruit. It could basically be a better phrasing of our discussion here.
How about this
"If SYNACK is lost during h= andshake,=A0in Fast Open=A0the server may send up to an initial window of d= ata because the loss is detected afterwards. But in regular handshake, the = server detects the loss first and reduces the initial congestion window acc= ording to RFC".

=A0

Michael (as individual)


________________________________________
Von: Yuchung Cheng [ycheng@google.com<= /a>]
Gesendet: Samstag, 27. Oktober 2012 22:03
An: Scharf, Michael (Michael)
Cc: tcpm@ietf.org
Betreff: Re: draft-ietf-tcpm-fastopen-02 vs. congestion control

On Fri, Oct 26, 2012 at 12:57 PM, Scharf, Michael (Michael)
<michael.scharf@alc= atel-lucent.com> wrote:
> Yuchung,
>
> You state that fast open does not change the congestion control, but I= am still wondering whether this is actually true. My impression is that fa= st open can have side effects that affect congestion control, at least in c= orner cases. But please correct me if I am wrong.

Which part in RFC5681 needs to be updated by Fast Open if you don't
think it's true?

>
> Let's assume that the downlink between a HTTP server and a HTTP cl= ient is severely congested.
>
> With current TCP, the client will send a SYN, and the server will resp= ond by SYN-ACK. Even if the SYN carries data, the server cannot respond. Th= at implies that the server sends one packet to a congested downlink. If it = gets dropped, the whole connection backs off for a moment. That may help to= reduce the congestion.
>
> With fast open, the client will send SYN+data, and the server will pot= entially respond by a series of packets as allowed by the initial congestio= n window. According to RFC 3390, this implies sending 3 packets to the seve= rely congested downlink. That is apparently worse...
>
> Thus, unless I miss something here, the amount of data that a server c= ould send to a severely congested link can be significantly larger with fas= t open. Fast open may thus cause self-congestion in such a scenario. Theore= tically it could maybe also harm other traffic (fairness...).

What if the handshakes finish smoothly in current TCP, but the network
becomes congested as you sketched by the time server is ready to send?
and many servers today do not change cwnd after idle. It's certainly not a corner case then. How about changing the scenarios with
syn-cookies?

We appreciate you scrutinizing the draft. but I suggest you experts
look congestion control on at higher level. How about loss-based
algorithm causing huge queues with BB. Ok I am deviating now ...

>
> It is not entirely clear to me whether that difference indeed matters = in reality with RFC 3390, since fast open mostly affects *when* data is sen= t. Maybe this is a corner case only. But at least it might be worthwile to = mention that side-effect in the draft. That might also help to understand w= hat would happen if fast open and IW10 are used at the same time. That ques= tion was raised several times already.
>
As I said, IW10 is part of RFC5681. TFO does not update RFC5681
currently. Should I mention TCP-SACK in TFO too?


> Thanks
>
> Michael (as individual)
>
>
>> -----Original Message-----
>> From: tcpm-bounces@ietf.o= rg [mailto:tcpm-bounces@ietf.o= rg] On
>> Behalf Of Yuchung Cheng
>> Sent: Tuesday, October 23, 2012 12:22 AM
>> To: tcpm@ietf.org
>> Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-fastopen-02.txt >>
>> On Mon, Oct 22, 2012 at 11:57 AM, =A0<internet-drafts@ietf.org> wrote:
>> >
>> > A New Internet-Draft is available from the on-line
>> Internet-Drafts directories.
>> > =A0This draft is a work item of the TCP Maintenance and Minor=
>> Extensions Working Group of the IETF.
>> >
>> > =A0 =A0 =A0 =A0 Title =A0 =A0 =A0 =A0 =A0 : TCP Fast Open
>> > =A0 =A0 =A0 =A0 Author(s) =A0 =A0 =A0 : Yuchung Cheng
>> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Jerry Chu=
>> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Sivasanka= r Radhakrishnan
>> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Arvind Ja= in
>> > =A0 =A0 =A0 =A0 Filename =A0 =A0 =A0 =A0: draft-ietf-tcpm-fas= topen-02.txt
>> > =A0 =A0 =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 : 22
>> > =A0 =A0 =A0 =A0 Date =A0 =A0 =A0 =A0 =A0 =A0: 2012-10-22
>> >
>> > Abstract:
>> > =A0 =A0TCP Fast Open (TFO) allows data to be carried in the S= YN
>> and SYN-ACK
>> > =A0 =A0packets and consumed by the receiving end during the i= nitial
>> > =A0 =A0connection handshake, thus saving up to one full round= trip time
>> > =A0 =A0(RTT) compared to standard TCP which requires a
>> three-way handshake
>> > =A0 =A0(3WHS) to complete before data can be exchanged.
>> ChangeLog since 01:
>>
>> - elaborate more on the issue of duplicate SYN-data (sec 2.1)
>>
>> - use draft-tcpm-experimental-options (sec 10)
>>
>> - add a new subsection about attacks from behind NAT (sec 6.3)
>> =A0 and discuss Bob Briscoe's idea on defending with TCP-TS an= d
>> =A0 cookies
>>
>> - use null cookie (end of sec 4.1.2) (courtesy of Bob Briscoe)
>>
>> - explain the problem of cookie option in FIN (end of 4.2.1)
>>
>> - re-emphasize other than including data in SYN packet. TFO
>> =A0 draft does not change any part of congestion control, and
>> =A0 the transmission MUST be governed by CC (sec 4.2.2)
>>
>> - a bunch of minor edits
>>
>> >
>> > Terminology
>> >
>> > The IETF datatracker status page for this draft is:
>> > https://datatracker.ietf.org/doc/draft-ietf-tcpm= -fastopen
>> >
>> > There's also a htmlized version available at:
>> > http://tools.ietf.org/html/draft-ietf-tcpm-fastopen= -02
>> >
>> > A diff from the previous version is available at:
>> > http://www.ietf.org/rfcdiff?url2=3Ddraft-ie= tf-tcpm-fastopen-02
>> >
>> >
>> > Internet-Drafts are also available by anonymous FTP at:
>> > ftp://ftp.ietf.org/internet-drafts/
>> >
>> > _______________________________________________
>> > 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
>>

--e89a8f5034582f6f1204cd4dab97-- From nishida@sfc.wide.ad.jp Wed Oct 31 03:01:24 2012 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 09F6E21F882F for ; Wed, 31 Oct 2012 03:01:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -95.874 X-Spam-Level: X-Spam-Status: No, score=-95.874 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FM_FORGED_GMAIL=0.622, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RELAY_IS_203=0.994, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fHMRaGWf9tP9 for ; Wed, 31 Oct 2012 03:01:23 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.142.130]) by ietfa.amsl.com (Postfix) with ESMTP id 36A4221F87B3 for ; Wed, 31 Oct 2012 03:01:23 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 8EB122780A3 for ; Wed, 31 Oct 2012 19:01:15 +0900 (JST) Received: by mail-wg0-f44.google.com with SMTP id dr13so585801wgb.13 for ; Wed, 31 Oct 2012 03:01:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.131.132 with SMTP id m4mr20052208wei.23.1351677671856; Wed, 31 Oct 2012 03:01:11 -0700 (PDT) Received: by 10.194.75.196 with HTTP; Wed, 31 Oct 2012 03:01:11 -0700 (PDT) Date: Wed, 31 Oct 2012 03:01:11 -0700 Message-ID: From: Yoshifumi Nishida To: "tcpm@ietf.org\"" Content-Type: text/plain; charset=ISO-8859-1 Subject: [tcpm] slides for Atlanta meeting 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: Wed, 31 Oct 2012 10:01:24 -0000 Hello, We would like to ask presenters to send the presentation materials before the meeting so that people have chances to take a look at them. We would like to ask presenters to send the materials by Monday(11/5) noon. It doesn't have to be final version and you can send refined versions later. We really appreciate your cooperation. Thanks, -- Yoshifumi & Pasi & Michael From nishida@sfc.wide.ad.jp Wed Oct 31 03:57:31 2012 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 BBFD121F8527 for ; Wed, 31 Oct 2012 03:57:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.473 X-Spam-Level: X-Spam-Status: No, score=-98.473 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, HTML_MESSAGE=0.001, RELAY_IS_203=0.994, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ppX54mLzhhu8 for ; Wed, 31 Oct 2012 03:57:29 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.142.130]) by ietfa.amsl.com (Postfix) with ESMTP id 3949121F8524 for ; Wed, 31 Oct 2012 03:57:29 -0700 (PDT) Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com [209.85.212.170]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id BDD102780B6 for ; Wed, 31 Oct 2012 19:57:21 +0900 (JST) Received: by mail-wi0-f170.google.com with SMTP id hm2so3549227wib.1 for ; Wed, 31 Oct 2012 03:57:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.134.145 with SMTP id s17mr19566405wei.127.1351681039262; Wed, 31 Oct 2012 03:57:19 -0700 (PDT) Received: by 10.194.75.196 with HTTP; Wed, 31 Oct 2012 03:57:19 -0700 (PDT) In-Reply-To: <201208132239.04933.mirja.kuehlewind@ikr.uni-stuttgart.de> References: <201207251811.40438.mkuehle@ikr.uni-stuttgart.de> <201208132239.04933.mirja.kuehlewind@ikr.uni-stuttgart.de> Date: Wed, 31 Oct 2012 03:57:19 -0700 Message-ID: From: Yoshifumi Nishida To: Mirja Kuehlewind Content-Type: multipart/alternative; boundary=0016e6de006e31e5fc04cd58c406 Cc: tcpm@ietf.org Subject: Re: [tcpm] Review of draft-ietf-tcpm-initcwnd-04 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: Wed, 31 Oct 2012 10:57:31 -0000 --0016e6de006e31e5fc04cd58c406 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello Mirja, On Mon, Aug 13, 2012 at 1:39 PM, Mirja Kuehlewind < mirja.kuehlewind@ikr.uni-stuttgart.de> wrote: > Hi Jerry, > > I still believe restructuring the document would help to make it better > readable but I'm okay to keep the same structure than RFC 3390. Please > check > if all paragraph are actually in the right section or more subsection are > needed to improve readability. Someone who wants to implement the change > might not read the whole document and might very easy overread any > SHOULDs/MUSTs in any later section than section 3. Maybe it is an option = to > add a reference to the later SHOULDs/MUSTs in section 2? > I just would like to check if updated texts works for your concern here. > > Regarding the comments below. You several times named a reference to > slides/papers/mails instead of actually addressing my comment in the > draft. I > know where to find the information as I've been following the discussion. > But > someone who later reads the document, might not have followed mail > discussion > or ieft slides. Thus you really should add the references in the document > or > even better, explain the outcome better in the document such that the > references are not need anymore. > One thing in my mind is this is a draft for experimental RFC which people should think about carefully its concern and implication before implement it. So, I personally think people are generally expected to check the references if they have any concerns. Also, we basically don't know what kinds of concerns readers will have for this draft, so answering all concerns in the draft for readers would be impossible. I personally think the draft is doing a good job on this, but if you have concerns which are really important to be addressed, but it's not mentioned in the draft yet, could you point it out? Regards, -- Yoshifumi > On Wednesday 01 August 2012 07:32:31 Jerry Chu wrote: > > On Wed, Jul 25, 2012 at 2:58 PM, Jerry Chu wrote: > > > On Wed, Jul 25, 2012 at 11:12 AM, Mirja Kuehlewind > > > > > > wrote: > > >> Hi Jerry, > > >> > > >> just one quick comment: > > >>> Moreover, the TOC provides a very clear index of the contents so a > > >>> savvy reader can > > >>> quickly pick the sections of interesting. E.g., if you only want to > > >>> focus on the change > > >>> you'll know to read section 1 and 2 only. That's it. > > >> > > >> And that's not really true (anymore). There are several SHOULD and > MUST > > >> in the other sections as well. Thus you have to read all the doc to > > >> correctly implement the changes. I know that the intent was to have > > >> everything in section 1 and 2 that is of interest for implementers b= ut > > >> due to the many changes that have been done in previous versions, it= 's > > >> not the case anymore. > > > > > > Actually the only other specification related languages is section 9, > > > and it's not > > > essential as it simply reiterates what is described in rfc6298. > > > > > > Yes other SHOULD and MUST can be found in the newly added section 12 > > > "Usage and Deployment Recommendations", but that section is mainly > about > > > what one must do in any future large scale experiment, closely > monitoring > > > a number of key metrics... and not really about protocol specificatio= n. > > > > > > So to summarize, this draft is not just about protocol specification, > > > it also addresses > > > many other questions like why, and how to go about doing more > > > experiments safely. > > > > > >> That why I said, all the content is there, would be nice to > > >> clean-up/restructure a little and then it's done. > > >> > > >> It's good to have a similar structure than RFC3390 (didn't realize > that > > >> you tried to have exactly the same sections here) but if the content > > >> would fit > > > > > > It was spelled out up front in 1. Introduction > > > > > > "This document proposes to raise the upper bound on TCP's initial > > > window (IW) to 10 segments or roughly 15KB. It is patterned after > and > > > borrows heavily from RFC 3390 [RFC3390] and earlier work in this > > > area." > > > > > >> better with a different structure, I'd prefer to have a good readabl= e > > >> doc over having a doc that looks similar to RFC3390. > > > > > > Let's stick to the current format but I will respond to your one othe= r > > > criticism on > > > section 12 first. The section is quite specific about the metrics to > > > monitor: "A key metric to monitor is the rate of packet losses, ECN > > > marking, or segment retransmissions during the initial burst." But as > > > others have pointed out it can be > > > quite difficult to try to get more specific than that, i.e., how much > > > performance > > > deteriorates before one must back off. As such all we can do for now = is > > > to have enough warning signs for now but leave some details for futur= e > > > investigation. > > > > > > Jerry > > > > > >> Mirja > > >> > > >>> >Hence I'd like to > > >>> > propose quite a little restructuring before moving the document > > >>> > forward as it is hard to easily catch the main points at the > moment. > > >>> > More concrete, I'd move at least section 4, 10 and 11, maybe also > 5, > > >>> > 6 and 7 (or at least partly) to the appendix. The first two > paragraph > > >>> > of section 7 might actually belong in > > >>> > > >>> Yes it's doable but I think the current flow is fine if you realize > > >>> the main purpose of > > >>> the document is to justify the change, not the change itself. Also > TOC > > >>> will make it > > >>> much easier to navigate through. > > >>> > > >>> > the security consideration section. And section 15 (conclusion) i= s > > >>> > not needed at all. More detailed comments below. > > >>> > > > >>> > Mirja > > >>> > > > >>> > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > >>> > Section 1 Introduction: > > >>> > ---------------------------- > > >>> > - s/roughly 15KB/maxium 14600B/ > > >>> > > >>> Ok. > > >>> > > >>> > - 2. paragraph: Don't like this two sentences at all. I hope the > > >>> > reason to increase IW is not just the fact there the queues are > large > > >>> > enough to store 10 packets. You basically saying "Let's send more > > >>> > packets at once to blow the queues!". I'd say the reason is that > flow > > >>> > sizes have increased and therefore IW10 would improve latency a > lot. > > >>> > Only because queues are likely to be large than 10 packets today, > it > > >>> > is possible at all to send more than 10 packet at once. Btw. even > if > > >>> > the queue would be small, pacing could help to still allow an IW = of > > >>> > 10. Moreover, the fact that there might be several concurrent > flows, > > >>> > does not mean that the buffer has to be larger (only if those flo= w > > >>> > start at the same time with IW10). And even if there is a large > > >>> > buffer, if there is a long-lived TCP connection, this flow will > fill > > >>> > up the queue and there might be by chance still no space in the > queue > > >>> > for 10 additional packets. > > >>> > > >>> Guess you read the paragraph differently from what the authors had = in > > >>> mind. What we have in mind was "Ten segments are likely to fit int= o > > >>> queue space" because access link drains much faster these days (due > to > > >>> b/w growth)... > > >>> > > >>> Will try to make it more clear. > > >>> > > >>> Will continue later, > > >>> > > >>> Jerry > > >>> > > >>> > - 3. paragraph: Don't agree. You might not know that there is a l= ow > > >>> > speed link somewhere on the path. There are cases where the > endpoint > > >>> > can protect its path by setting the receiver window but that's no= t > > >>> > the general case. > > > > This is exactly the point - it's not the general case but may be the > > vast majority. > > I.e., 95% of severely b/w limited hosts may be just 1 hop away or even > > directly attached to a slow link (e.g., dailup modem) hence can be > > mitigated much easily. No one suggested a solution here to solve the > > general problem of > > detecting bottleneck > > b/w. That's the job TCP's CC algorithm. > > > > >>> > - 5. paragraph: "We recommend that all TCP implementations have a > > >>> > settable TCP IW parameter..." > > >>> > -> I'd like to see this not only in the introduction but also i= n > > >>> > the main section (2.) that is describing the changes and maybe ev= en > > >>> > as a SHOULD > > >>> > > > >>> > > > >>> > Section 2 TCP Modifications > > >>> > ------------- > > >>> > - Maybe have a more specific title like "Setting the IW" and some > > >>> > subsections > > > > Plagiarized from RFC3390 :) > > > > >>> > - equation 1: say somewhere that numbers are in KByte > > > > Not really. > > > > >>> > - 4. paragraph ("Note that...") does not belong in this section > > > > Why not? (It's more or less a disclaim because no one has done any stud= y > > on non-Ethernet MTU. > > > > >>> > - maybe new subsection for paragraph 5 "Resetting the IW after SY= N > > >>> > loss"; what are "multiple SYN or SYN/ACK retransmissions" -> mayb= e > > >>> > say a number > > > > Ok. Changed to "more than one". > > > > >>> > - last paragraph: maybe s/implementations SHOULD fall > > >>> > back/implementations MUST fall back/ ? > > >>> > > > >>> > > > >>> > Section 3 Implementation Issues > > >>> > ------------- > > >>> > - Maybe move the 3 paragraph into section 2 such that the setting > of > > >>> > the receive window is a MUST or SHOULD of the changes to TCP > > > > Non-essential. Remember even IW10 is just an upperbound. > > > > >>> > - 4. paragraph: Please give some explanation (or remove) > > > > This was brought up and discussed on the list long ago. > > > > >>> > Section 4 Background > > >>> > ------------ > > >>> > - Move most parts in the appendix > > >>> > > > >>> > - Move 2. paragraph into Introduction > > >>> > > > >>> > - Maybe improve structure with subsections e.g. paragraph 5 and 6 > > >>> > as "Recommendation for HTTP Traffic" or something > > > > See my other response. I prefer not to change the structure at this tim= e. > > > > >>> > - 7. paragraph: "pacing will not be necessary" > > >>> > -> I can't remember having seen any results on this. Please > explain > > >>> > further or remove! > > > > The statement was really "We suspect" pacing will not be necessary > because > > our test results do not show any severe congestion from IW10... > > > > >>> > Section 5 Advantages of a Larger Initial Window > > >>> > ----------- > > >>> > - section 5.1 Reducing Latency > > >>> > You should also mention that for larger transmission with > several > > >>> > 100s of RTT a save of 4 RTT does not really help. Thus > transmissions > > >>> > which will finish within a small number of RTT will benefit the > most. > > > > Isn't it obvious already? > > > > >>> > - section 5.2 > > >>> > You make some quite general statements here and then u only ref= er > > >>> > to google data. Maybe you can find some other references as well. > > > > It's not just google data (see all the refs.) > > > > >>> > Section 6 > > >>> > ---------- > > >>> > - paragraph 3 and 4 belong in an evaluation section/appendix (may= be > > >>> > own subsection on "Influence of simultaneous opened connections") > > >>> > > > >>> > Section 7 > > >>> > -------- > > >>> > - Move 1. paragraph to security consideration > > >>> > > > >>> > - Move rest in appendix or even parts in the introduction > > >>> > > > >>> > Section 9 > > >>> > ---------- > > >>> > - move to main section which is introducing the TCP changes as o= wn > > >>> > subsection as a MUST is in here > > > > Non-essential because it simply restates what is said in rfc6298. It wa= s > > added to address some concern (or confusion) that was brought up in the > > past that the initial burst of 10 pkts won't bid well for RTO hence > causing > > spurious rexmits. > > > > >>> > - can you explain better why this is need or what would happen > > >>> > otherwise? > > >>> > > > >>> > Section 10 > > >>> > ---------- > > >>> > - Move to appendix, have more subsections and better titles for t= he > > >>> > subsections e.g. "Improvements in Latency", "Impact on the > > >>> > Retransmission Rate" and "Multiple TCP Connections" > > >>> > > > >>> > - The numbers for the latency improvement are only on (google) we= b > > >>> > search. Of course there are quite large improvements possible but > the > > >>> > Internet contains also other traffic. Not sure if your number are > > >>> > really that significant...? > > > > We just stated what we have. > > > > >>> > Section 11 > > >>> > --------- > > >>> > - move to appendix > > >>> > > > >>> > - It's nice that you list all the studies. Could you please quick= ly > > >>> > summarize their results/findings, too? Because I guess that the > > >>> > intersting part to know. > > > > If you are interested please go read them yourself. > > > > >>> > Section 12 > > >>> > -------- > > >>> > - Its good to have this section but it's quite unspecific. E.g. y= ou > > >>> > say "An increased initial window MUST NOT be turned on by default > on > > >>> > systems without such monitoring capabilities." But what exactly > > >>> > should be monitored and how frequently and so on. Also "any > > >>> > significant deterioration" doesn't say anything to me. Is it > possible > > >>> > to have a concrete approach/algorithm here what to monitor when a= nd > > >>> > what to do in which cases? And than have this even as part of the > > >>> > main section with TCP changes as this section has also some SHOUL= D > > >>> > and MUST and might be overread otherwise. > > >>> > > > >>> > Section 14 > > >>> > --------- > > >>> > - "highly unlikely to lead to a persistent state of network > > >>> > congestion" -> Even a "highly unlikely" is concerning me in this > > >>> > case! Also there is no reasoning for this. But I guess you can ev= en > > >>> > say, that this change cannot cause persistent network congestion = as > > >>> > congestion control is still used.... > > > > See 1st paragraph of section 7. > > > > >>> > Section 15 Conclusion > > >>> > -------- > > >>> > - Is not needed here at all, as no new information > > > > Most rfcs have a conclusion section for those who have time only for > > the 1st and last sections. > > > > >>> > Appendix > > >>> > --------- > > >>> > - "One notable exception is YouTube because we don't think > > >>> > the large initial window will have much material impact, > either > > >>> > positive or negative, on bulk data services." > > >>> > -> Why is this document than not recommending to NOT use IW10 f= or > > >>> > bulk data services? > > > > Why should it recommend NOT? How would the TCP stack know apriori bulk > > or not? So it will require input from the apps... Is it really worth > > the complexity? > > > > >>> > - "[CW10] contains some result from a testbed study on how short > > >>> > flows with a larger initial window might affect the throughput > > >>> > performance of other co-existing, long lived, bulk data transfers= ." > > >>> > -> Please also describe what the results are! > > > > Read the slides please. > > > > >>> > - paragraph on "Why 10 segment?" > > >>> > -> This is something I would prefer to have in the body of the > > >>> > document not in the appendix > > >>> > > > >>> > - "Some simulation studies [JNDK10, JNDK10-1] have been conducted > to > > >>> > study the effect of a larger initial window on wireless link= s > > >>> > from 2G to 4G networks (EGDE/HSPA/LTE). The overall result seems > > >>> > mixed in both raw performance and the fairness index." > > >>> > -> Should it be recommend to not use IW10 in wireless scenarios > (if > > >>> > known)? > > > > Studies are still on-going. I don't remember there has been a conclusiv= e > > result. > > > > Jerry > > > > >> -- > > >> ------------------------------------------------------------------- > > >> Dipl.-Ing. Mirja K=FChlewind > > >> Institute of Communication Networks and Computer Engineering (IKR) > > >> University of Stuttgart, Germany > > >> Pfaffenwaldring 47, D-70569 Stuttgart > > >> > > >> tel: +49(0)711/685-67973 > > >> email: mirja.kuehlewind@ikr.uni-stuttgart.de > > >> web: www.ikr.uni-stuttgart.de > > >> ------------------------------------------------------------------- > > > > -- > ------------------------------------------------------------------- > Dipl.-Ing. Mirja K=FChlewind > Institute of Communication Networks and Computer Engineering (IKR) > University of Stuttgart, Germany > Pfaffenwaldring 47, D-70569 Stuttgart > > tel: +49(0)711/685-67973 > email: mirja.kuehlewind@ikr.uni-stuttgart.de > web: www.ikr.uni-stuttgart.de > ------------------------------------------------------------------- > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > --0016e6de006e31e5fc04cd58c406 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello Mirja,

On Mon, Aug 13, 2012 at 1:39= PM, Mirja Kuehlewind <mirja.kuehlewind@ikr.uni-stuttg= art.de> wrote:
Hi Jerry,

I still believe restructuring the document would help to make it better
readable but I'm okay to keep the same structure than RFC 3390. Please = check
if all paragraph are actually in the right section or more subsection are needed to improve readability. Someone who wants to implement the change might not read the whole document and might very easy overread any
SHOULDs/MUSTs in any later section than section 3. Maybe it is an option to=
add a reference to the later SHOULDs/MUSTs =A0in section 2?

I just would like to check if updated texts works for your concer= n here.
=A0

Regarding the comments below. You several times named a reference to
slides/papers/mails instead of actually addressing my comment in the draft.= I
know where to find the information as I've been following the discussio= n. But
someone who later reads the document, might not have followed mail discussi= on
or ieft slides. Thus you really should add the references in the document o= r
even better, explain the outcome better in the document such that the
references are not need anymore.
=A0
One thing in m= y mind is this is a draft for experimental RFC which people should think ab= out carefully its concern and implication before implement it. So, I person= ally think people are generally expected to check the references if they ha= ve any concerns.
Also, we basically don't know what kinds of concerns readers will have = for this draft, so answering all concerns in the draft for readers would be= impossible.
I personally think the draft is doing a good job on this, = but if you have concerns which are really important to be addressed, but it= 's not mentioned in the draft yet, could you point it out?

Regards,
--
Yoshifumi



On Wednesday 01 August 2012 07:32:31 Jerry Chu wrote:
> On Wed, Jul 25, 2012 at 2:58 PM, Jerry Chu <hkchu@google.com> wrote:
> > On Wed, Jul 25, 2012 at 11:12 AM, Mirja Kuehlewind
> >
> > <mirj= a.kuehlewind@ikr.uni-stuttgart.de> wrote:
> >> Hi Jerry,
> >>
> >> just one quick comment:
> >>> Moreover, the TOC provides a very clear index of the cont= ents so a
> >>> savvy reader can
> >>> quickly pick the sections of interesting. E.g., if you on= ly want to
> >>> focus on the change
> >>> you'll know to read section 1 and 2 only. That's = it.
> >>
> >> And that's not really true (anymore). There are several S= HOULD and MUST
> >> in the other sections as well. Thus you have to read all the = doc to
> >> correctly implement the changes. I know that the intent was t= o have
> >> everything in section 1 and 2 that is of interest for impleme= nters but
> >> due to the many changes that have been done in previous versi= ons, it's
> >> not the case anymore.
> >
> > Actually the only other specification related languages is sectio= n 9,
> > and it's not
> > essential as it simply reiterates what is described in rfc6298. > >
> > Yes other SHOULD and MUST can be found in the newly added section= 12
> > "Usage and Deployment Recommendations", but that sectio= n is mainly about
> > what one must do in any future large scale experiment, closely mo= nitoring
> > a number of key metrics... and not really about protocol specific= ation.
> >
> > So to summarize, this draft is not just about protocol specificat= ion,
> > it also addresses
> > many other questions like why, and how to go about doing more
> > experiments safely.
> >
> >> That why I said, all the content is there, would be nice to > >> clean-up/restructure a little and then it's done.
> >>
> >> It's good to have a similar structure than RFC3390 (didn&= #39;t realize that
> >> you tried to have exactly the same sections here) but if the = content
> >> would fit
> >
> > It was spelled out up front in 1. =A0Introduction
> >
> > =A0 =A0"This document proposes to raise the upper bound on T= CP's initial
> > =A0 =A0window (IW) to 10 segments or roughly 15KB. It is patterne= d after and
> > =A0 =A0borrows heavily from RFC 3390 [RFC3390] and earlier work i= n this
> > =A0 =A0area."
> >
> >> better with a different structure, I'd prefer to have a g= ood readable
> >> doc over having a doc that looks similar to RFC3390.
> >
> > Let's stick to the current format but I will respond to your = one other
> > criticism on
> > section 12 first. The section is quite specific about the metrics= to
> > monitor: "A key metric to monitor is the rate of packet loss= es, ECN
> > marking, or segment retransmissions during the initial burst.&quo= t; But as
> > others have pointed out it can be
> > quite difficult to try to get more specific than that, i.e., how = much
> > performance
> > deteriorates before one must back off. As such all we can do for = now is
> > to have enough warning signs for now but leave some details for f= uture
> > investigation.
> >
> > Jerry
> >
> >> Mirja
> >>
> >>> >Hence I'd like to
> >>> > propose quite a little restructuring before moving t= he document
> >>> > forward as it is hard to easily catch the main point= s at the moment.
> >>> > More concrete, I'd move at least section 4, 10 a= nd 11, maybe also 5,
> >>> > 6 and 7 (or at least partly) to the appendix. The fi= rst two paragraph
> >>> > of section 7 might actually belong in
> >>>
> >>> Yes it's doable but I think the current flow is fine = if you realize
> >>> the main purpose of
> >>> the document is to justify the change, not the change its= elf. Also TOC
> >>> will make it
> >>> much easier to navigate through.
> >>>
> >>> > the security consideration section. And section 15 (= conclusion) is
> >>> > not needed at all. More detailed comments below.
> >>> >
> >>> > Mirja
> >>> >
> >>> > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> >>> > Section 1 Introduction:
> >>> > ----------------------------
> >>> > - s/roughly 15KB/maxium 14600B/
> >>>
> >>> Ok.
> >>>
> >>> > - 2. paragraph: Don't like this two sentences at= all. I hope the
> >>> > reason to increase IW is not just the fact there the= queues are large
> >>> > enough to store 10 packets. You basically saying &qu= ot;Let's send more
> >>> > packets at once to blow the queues!". I'd s= ay the reason is that flow
> >>> > sizes have increased and therefore IW10 would improv= e latency a lot.
> >>> > Only because queues are likely to be large than 10 p= ackets today, it
> >>> > is possible at all to send more than 10 packet at on= ce. Btw. even if
> >>> > the queue would be small, pacing could help to still= allow an IW of
> >>> > 10. Moreover, the fact that there might be several c= oncurrent flows,
> >>> > does not mean that the buffer has to be larger (only= if those flow
> >>> > start at the same time with IW10). And even if there= is a large
> >>> > buffer, if there is a long-lived TCP connection, thi= s flow will fill
> >>> > up the queue and there might be by chance still no s= pace in the queue
> >>> > for 10 additional packets.
> >>>
> >>> Guess you read the paragraph differently from what the au= thors had in
> >>> mind. What we have in mind was =A0"Ten segments are = likely to fit into
> >>> queue space" because access link drains much faster = these days (due to
> >>> b/w growth)...
> >>>
> >>> Will try to make it more clear.
> >>>
> >>> Will continue later,
> >>>
> >>> Jerry
> >>>
> >>> > - 3. paragraph: Don't agree. You might not know = that there is a low
> >>> > speed link somewhere on the path. There are cases wh= ere the endpoint
> >>> > can protect its path by setting the receiver window = but that's not
> >>> > the general case.
>
> This is exactly the point - it's not the general case but may be t= he
> vast majority.
> I.e., 95% of severely b/w limited hosts may be just 1 hop away or even=
> directly attached to a slow link (e.g., dailup modem) hence can be
> mitigated much easily. No one suggested a solution here to solve the > general problem of
> detecting bottleneck
> b/w. That's the job TCP's CC algorithm.
>
> >>> > - 5. paragraph: "We recommend that all TCP impl= ementations have a
> >>> > settable TCP IW parameter..."
> >>> > =A0 -> I'd like to see this not only in the i= ntroduction but also in
> >>> > the main section (2.) that is describing the changes= and maybe even
> >>> > as a SHOULD
> >>> >
> >>> >
> >>> > Section 2 TCP Modifications
> >>> > -------------
> >>> > - Maybe have a more specific title like "Settin= g the IW" and some
> >>> > subsections
>
> Plagiarized from RFC3390 :)
>
> >>> > - equation 1: say somewhere that numbers are in KByt= e
>
> Not really.
>
> >>> > - 4. paragraph ("Note that...") does not b= elong in this section
>
> Why not? (It's more or less a disclaim because no one has done any= study
> on non-Ethernet MTU.
>
> >>> > - maybe new subsection for paragraph 5 "Resetti= ng the IW after SYN
> >>> > loss"; what are "multiple SYN or SYN/ACK r= etransmissions" -> maybe
> >>> > say a number
>
> Ok. Changed to "more than one".
>
> >>> > - last paragraph: maybe s/implementations SHOULD fal= l
> >>> > back/implementations MUST fall back/ ?
> >>> >
> >>> >
> >>> > Section 3 Implementation Issues
> >>> > -------------
> >>> > - Maybe move the 3 paragraph into section 2 such tha= t the setting of
> >>> > the receive window is a MUST or SHOULD of the change= s to TCP
>
> Non-essential. Remember even IW10 is just an upperbound.
>
> >>> > - 4. paragraph: Please give some explanation (or rem= ove)
>
> This was brought up and discussed on the list long ago.
>
> >>> > Section 4 Background
> >>> > ------------
> >>> > - Move most parts in the appendix
> >>> >
> >>> > - Move 2. paragraph into Introduction
> >>> >
> >>> > - Maybe improve structure with subsections e.g. para= graph 5 and 6
> >>> > as "Recommendation for HTTP Traffic" or so= mething
>
> See my other response. I prefer not to change the structure at this ti= me.
>
> >>> > - 7. paragraph: "pacing will not be necessary&q= uot;
> >>> > =A0 -> I can't remember having seen any resul= ts on this. Please explain
> >>> > further or remove!
>
> The statement was really "We suspect" pacing will not be nec= essary because
> our test results do not show any severe congestion from IW10...
>
> >>> > Section 5 Advantages of a Larger Initial Window
> >>> > -----------
> >>> > - section 5.1 Reducing Latency
> >>> > =A0 =A0You should also mention that for larger trans= mission with several
> >>> > 100s of RTT a save of 4 RTT does not really help. Th= us transmissions
> >>> > which will finish within a small number of RTT will = benefit the most.
>
> Isn't it obvious already?
>
> >>> > - section 5.2
> >>> > =A0 You make some quite general statements here and = then u only refer
> >>> > to google data. Maybe you can find some other refere= nces as well.
>
> It's not just google data (see all the refs.)
>
> >>> > Section 6
> >>> > ----------
> >>> > - paragraph 3 and 4 belong in an evaluation section/= appendix (maybe
> >>> > own subsection on "Influence of simultaneous op= ened connections")
> >>> >
> >>> > Section 7
> >>> > --------
> >>> > - Move 1. paragraph to security consideration
> >>> >
> >>> > - Move rest in appendix or even parts in =A0the intr= oduction
> >>> >
> >>> > Section 9
> >>> > ----------
> >>> > - move to main section which =A0is introducing the T= CP changes as own
> >>> > subsection as a MUST is in here
>
> Non-essential because it simply restates what is said in rfc6298. It w= as
> added to address some concern (or confusion) that was brought up in th= e
> past that the initial burst of 10 pkts won't bid well for RTO henc= e causing
> spurious rexmits.
>
> >>> > - can you explain better why this is need or what wo= uld happen
> >>> > otherwise?
> >>> >
> >>> > Section 10
> >>> > ----------
> >>> > - Move to appendix, have more subsections and better= titles for the
> >>> > subsections e.g. "Improvements in Latency"= , "Impact on the
> >>> > Retransmission Rate" and "Multiple TCP Con= nections"
> >>> >
> >>> > - The numbers for the latency improvement are only o= n (google) web
> >>> > search. Of course there are quite large improvements= possible but the
> >>> > Internet contains also other traffic. Not sure if yo= ur number are
> >>> > really that significant...?
>
> We just stated what we have.
>
> >>> > Section 11
> >>> > ---------
> >>> > - move to appendix
> >>> >
> >>> > - It's nice that you list all the studies. Could= you please quickly
> >>> > summarize their results/findings, too? Because I gue= ss that the
> >>> > intersting part to know.
>
> If you are interested please go read them yourself.
>
> >>> > Section 12
> >>> > --------
> >>> > - Its good to have this section but it's quite u= nspecific. E.g. you
> >>> > say "An increased initial window MUST NOT be tu= rned on by default on
> >>> > systems without such monitoring capabilities." = But what exactly
> >>> > should be monitored and how frequently and so on. Al= so "any
> >>> > significant deterioration" doesn't say anyt= hing to me. Is it possible
> >>> > to have a concrete approach/algorithm here what to m= onitor when and
> >>> > what to do in which cases? And than have this even a= s part of the
> >>> > main section with TCP changes as this section has al= so some SHOULD
> >>> > and MUST and might be overread otherwise.
> >>> >
> >>> > Section 14
> >>> > ---------
> >>> > - "highly unlikely to lead to a persistent stat= e of network
> >>> > congestion" -> Even a "highly unlikely&= quot; is concerning me in this
> >>> > case! Also there is no reasoning for this. But I gue= ss you can even
> >>> > say, that this change cannot cause persistent networ= k congestion as
> >>> > congestion control is still used....
>
> See 1st paragraph of section 7.
>
> >>> > Section 15 Conclusion
> >>> > --------
> >>> > - Is not needed here at all, as no new information >
> Most rfcs have a conclusion section for those who have time only for > the 1st and last sections.
>
> >>> > Appendix
> >>> > ---------
> >>> > - "One notable exception is YouTube because we = don't think
> >>> > =A0 =A0 =A0the large initial window will have much m= aterial impact, either
> >>> > =A0 =A0 =A0positive or negative, on bulk data servic= es."
> >>> > =A0 -> Why is this document than not recommending= to NOT use IW10 for
> >>> > bulk data services?
>
> Why should it recommend NOT? How would the TCP stack know apriori bulk=
> or not? So it will require input from the apps... Is it really worth > the complexity?
>
> >>> > - "[CW10] contains some result from a testbed s= tudy on how short
> >>> > flows with a larger initial window might affect the = throughput
> >>> > performance of other co-existing, long lived, bulk d= ata transfers."
> >>> > -> Please also describe what the results are!
>
> Read the slides please.
>
> >>> > - paragraph on "Why 10 segment?"
> >>> > =A0 -> This is something I would prefer to have i= n the body of the
> >>> > document not in the appendix
> >>> >
> >>> > - "Some simulation studies [JNDK10, JNDK10-1] h= ave been conducted to
> >>> > =A0 =A0 =A0study the effect of a larger initial wind= ow on wireless links
> >>> > from 2G to 4G networks (EGDE/HSPA/LTE). The overall = result seems
> >>> > mixed in both raw performance and the fairness index= ."
> >>> > =A0 -> Should it be recommend to not use IW10 in = wireless scenarios (if
> >>> > known)?
>
> Studies are still on-going. I don't remember there has been a conc= lusive
> result.
>
> Jerry
>
> >> --
> >> -------------------------------------------------------------= ------
> >> Dipl.-Ing. Mirja K=FChlewind
> >> Institute of Communication Networks and Computer Engineering = (IKR)
> >> University of Stuttgart, Germany
> >> Pfaffenwaldring 47, D-70569 Stuttgart
> >>
> >> tel: +49(0)711/685-67973
> >> email: mirja.kuehlewind@ikr.uni-stuttgart.de
> >> web: www.ikr.uni-stuttgart.de
> >> -------------------------------------------------------------= ------



--
-------------------------------------------------------------------
Dipl.-Ing. Mirja K=FChlewind
Institute of Communication Networks and Computer Engineering (IKR)
University of Stuttgart, Germany
Pfaffenwaldring 47, D-70569 Stuttgart

tel: +49(0)711/685-67973
email: mirja.kuehl= ewind@ikr.uni-stuttgart.de
web: www.ikr.= uni-stuttgart.de
-------------------------------------------------------------------
_______________________________________________
tcpm mailing list
tcpm@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/tcpm

--0016e6de006e31e5fc04cd58c406-- From nishida@sfc.wide.ad.jp Wed Oct 31 12:46:02 2012 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 97E8821F89F5 for ; Wed, 31 Oct 2012 12:46:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.173 X-Spam-Level: X-Spam-Status: No, score=-98.173 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, RELAY_IS_203=0.994, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e4-xbyyRboz5 for ; Wed, 31 Oct 2012 12:46:01 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.142.130]) by ietfa.amsl.com (Postfix) with ESMTP id D09E021F88E3 for ; Wed, 31 Oct 2012 12:46:00 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 543A62780BB for ; Thu, 1 Nov 2012 04:45:52 +0900 (JST) Received: by mail-lb0-f172.google.com with SMTP id k13so1476871lbo.31 for ; Wed, 31 Oct 2012 12:45:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.152.106.171 with SMTP id gv11mr35102442lab.26.1351712749803; Wed, 31 Oct 2012 12:45:49 -0700 (PDT) Received: by 10.112.103.193 with HTTP; Wed, 31 Oct 2012 12:45:49 -0700 (PDT) In-Reply-To: References: <20121022185739.7534.69954.idtracker@ietfa.amsl.com> <2A886F9088894347A3BE0CC5B7A85F3E9AA0F0A61B@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> <2A886F9088894347A3BE0CC5B7A85F3E9AA0F39987@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> Date: Wed, 31 Oct 2012 12:45:49 -0700 Message-ID: From: Yoshifumi Nishida To: Yuchung Cheng Content-Type: multipart/alternative; boundary=f46d0407166d4a585504cd602661 Cc: "tcpm@ietf.org" Subject: Re: [tcpm] draft-ietf-tcpm-fastopen-02 vs. congestion control 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: Wed, 31 Oct 2012 19:46:02 -0000 --f46d0407166d4a585504cd602661 Content-Type: text/plain; charset=ISO-8859-1 Hi Yuchung, On Tue, Oct 30, 2012 at 2:42 PM, Yuchung Cheng wrote: > > > On Sun, Oct 28, 2012 at 1:14 PM, Scharf, Michael (Michael) < > michael.scharf@alcatel-lucent.com> wrote: > >> Yuchung, >> >> I did not suggest that the draft must update RFC 5681. >> >> My proposal is that the draft discusses more explicitly what the >> different sending behavior implies to a (congested) network. Right now, the >> draft mainly stresses the performance benefit for applications. Well >> understood. But it seems to me a valid question whether this benefit comes >> at some cost for the network, at least in corner cases. >> >> I think that some text on that would be good to complete the document. >> This could be a short paragraph e. g. in Section 5. This is a quite >> low-hanging fruit. It could basically be a better phrasing of our >> discussion here. >> > How about this > "If SYNACK is lost during handshake, in Fast Open the server may send up > to an initial window of data because the loss is detected afterwards. But > in regular handshake, the server detects the loss first and reduces the > initial congestion window according to RFC". > I'm wondering it might be advisable to have a mechanism which can invalidate the cookie for lossy destinations. Or, it could be a job for the drafts like IW10 to recommend to set appropriate IW size for lossy destinations. Any thoughts on this? Thanks, -- Yoshifumi >> ________________________________________ >> Von: Yuchung Cheng [ycheng@google.com] >> Gesendet: Samstag, 27. Oktober 2012 22:03 >> An: Scharf, Michael (Michael) >> Cc: tcpm@ietf.org >> Betreff: Re: draft-ietf-tcpm-fastopen-02 vs. congestion control >> >> On Fri, Oct 26, 2012 at 12:57 PM, Scharf, Michael (Michael) >> wrote: >> > Yuchung, >> > >> > You state that fast open does not change the congestion control, but I >> am still wondering whether this is actually true. My impression is that >> fast open can have side effects that affect congestion control, at least in >> corner cases. But please correct me if I am wrong. >> >> Which part in RFC5681 needs to be updated by Fast Open if you don't >> think it's true? >> >> > >> > Let's assume that the downlink between a HTTP server and a HTTP client >> is severely congested. >> > >> > With current TCP, the client will send a SYN, and the server will >> respond by SYN-ACK. Even if the SYN carries data, the server cannot >> respond. That implies that the server sends one packet to a congested >> downlink. If it gets dropped, the whole connection backs off for a moment. >> That may help to reduce the congestion. >> > >> > With fast open, the client will send SYN+data, and the server will >> potentially respond by a series of packets as allowed by the initial >> congestion window. According to RFC 3390, this implies sending 3 packets to >> the severely congested downlink. That is apparently worse... >> > >> > Thus, unless I miss something here, the amount of data that a server >> could send to a severely congested link can be significantly larger with >> fast open. Fast open may thus cause self-congestion in such a scenario. >> Theoretically it could maybe also harm other traffic (fairness...). >> >> What if the handshakes finish smoothly in current TCP, but the network >> becomes congested as you sketched by the time server is ready to send? >> and many servers today do not change cwnd after idle. It's certainly >> not a corner case then. How about changing the scenarios with >> syn-cookies? >> >> We appreciate you scrutinizing the draft. but I suggest you experts >> look congestion control on at higher level. How about loss-based >> algorithm causing huge queues with BB. Ok I am deviating now ... >> >> > >> > It is not entirely clear to me whether that difference indeed matters >> in reality with RFC 3390, since fast open mostly affects *when* data is >> sent. Maybe this is a corner case only. But at least it might be worthwile >> to mention that side-effect in the draft. That might also help to >> understand what would happen if fast open and IW10 are used at the same >> time. That question was raised several times already. >> > >> As I said, IW10 is part of RFC5681. TFO does not update RFC5681 >> currently. Should I mention TCP-SACK in TFO too? >> >> >> > Thanks >> > >> > Michael (as individual) >> > >> > >> >> -----Original Message----- >> >> From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On >> >> Behalf Of Yuchung Cheng >> >> Sent: Tuesday, October 23, 2012 12:22 AM >> >> To: tcpm@ietf.org >> >> Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-fastopen-02.txt >> >> >> >> On Mon, Oct 22, 2012 at 11:57 AM, wrote: >> >> > >> >> > A New Internet-Draft is available from the on-line >> >> Internet-Drafts directories. >> >> > This draft is a work item of the TCP Maintenance and Minor >> >> Extensions Working Group of the IETF. >> >> > >> >> > Title : TCP Fast Open >> >> > Author(s) : Yuchung Cheng >> >> > Jerry Chu >> >> > Sivasankar Radhakrishnan >> >> > Arvind Jain >> >> > Filename : draft-ietf-tcpm-fastopen-02.txt >> >> > Pages : 22 >> >> > Date : 2012-10-22 >> >> > >> >> > Abstract: >> >> > TCP Fast Open (TFO) allows data to be carried in the SYN >> >> and SYN-ACK >> >> > packets and consumed by the receiving end during the initial >> >> > connection handshake, thus saving up to one full round trip time >> >> > (RTT) compared to standard TCP which requires a >> >> three-way handshake >> >> > (3WHS) to complete before data can be exchanged. >> >> ChangeLog since 01: >> >> >> >> - elaborate more on the issue of duplicate SYN-data (sec 2.1) >> >> >> >> - use draft-tcpm-experimental-options (sec 10) >> >> >> >> - add a new subsection about attacks from behind NAT (sec 6.3) >> >> and discuss Bob Briscoe's idea on defending with TCP-TS and >> >> cookies >> >> >> >> - use null cookie (end of sec 4.1.2) (courtesy of Bob Briscoe) >> >> >> >> - explain the problem of cookie option in FIN (end of 4.2.1) >> >> >> >> - re-emphasize other than including data in SYN packet. TFO >> >> draft does not change any part of congestion control, and >> >> the transmission MUST be governed by CC (sec 4.2.2) >> >> >> >> - a bunch of minor edits >> >> >> >> > >> >> > Terminology >> >> > >> >> > The IETF datatracker status page for this draft is: >> >> > https://datatracker.ietf.org/doc/draft-ietf-tcpm-fastopen >> >> > >> >> > There's also a htmlized version available at: >> >> > http://tools.ietf.org/html/draft-ietf-tcpm-fastopen-02 >> >> > >> >> > A diff from the previous version is available at: >> >> > http://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-fastopen-02 >> >> > >> >> > >> >> > Internet-Drafts are also available by anonymous FTP at: >> >> > ftp://ftp.ietf.org/internet-drafts/ >> >> > >> >> > _______________________________________________ >> >> > 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 > > --f46d0407166d4a585504cd602661 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Yuchung,

On Tue, Oct 30, 2012 at 2:42 = PM, Yuchung Cheng <ycheng@google.com> wrote:


On Sun, Oct 28, 2012 at 1:14 PM, Sc= harf, Michael (Michael) <michael.scharf@alcatel-lucent.com= > wrote:
Yuchung,

I did not suggest that the draft must update RFC 5681.

My proposal is that the draft discusses more explicitly what the different = sending behavior implies to a (congested) network. Right now, the draft mai= nly stresses the performance benefit for applications. Well understood. But= it seems to me a valid question whether this benefit comes at some cost fo= r the network, at least in corner cases.

I think that some text on that would be good to complete the document. This= could be a short paragraph e. g. in Section 5. This is a quite low-hanging= fruit. It could basically be a better phrasing of our discussion here.
How about this
"If SYNACK is lost du= ring handshake,=A0in Fast Open=A0the server may send up to an initial windo= w of data because the loss is detected afterwards. But in regular handshake= , the server detects the loss first and reduces the initial congestion wind= ow according to RFC".

I'm wondering it might be=A0advi= sable to have a mechanism which can invalidate the cookie for lossy destina= tions.
Or, it could be a job for the drafts like IW10 to recommen= d to set appropriate IW size for lossy destinations. Any thoughts on this?<= /div>

Thanks,
--
Yoshifumi


________________________________________
Von: Yuchung Cheng [= ycheng@google.com]
Gesendet: Samstag, 27. Oktober 2012 22:03
An: Scharf, Michael (Michael)
Cc: tcpm@ietf.org Betreff: Re: draft-ietf-tcpm-fastopen-02 vs. congestion control

On Fri, Oct 26, 2012 at 12:57 PM, Scharf, Michael (Michael)
<= michael.scharf@alcatel-lucent.com> wrote:
> Yuchung,
>
> You state that fast open does not change the congestion control, but I= am still wondering whether this is actually true. My impression is that fa= st open can have side effects that affect congestion control, at least in c= orner cases. But please correct me if I am wrong.

Which part in RFC5681 needs to be updated by Fast Open if you don't
think it's true?

>
> Let's assume that the downlink between a HTTP server and a HTTP cl= ient is severely congested.
>
> With current TCP, the client will send a SYN, and the server will resp= ond by SYN-ACK. Even if the SYN carries data, the server cannot respond. Th= at implies that the server sends one packet to a congested downlink. If it = gets dropped, the whole connection backs off for a moment. That may help to= reduce the congestion.
>
> With fast open, the client will send SYN+data, and the server will pot= entially respond by a series of packets as allowed by the initial congestio= n window. According to RFC 3390, this implies sending 3 packets to the seve= rely congested downlink. That is apparently worse...
>
> Thus, unless I miss something here, the amount of data that a server c= ould send to a severely congested link can be significantly larger with fas= t open. Fast open may thus cause self-congestion in such a scenario. Theore= tically it could maybe also harm other traffic (fairness...).

What if the handshakes finish smoothly in current TCP, but the network
becomes congested as you sketched by the time server is ready to send?
and many servers today do not change cwnd after idle. It's certainly not a corner case then. How about changing the scenarios with
syn-cookies?

We appreciate you scrutinizing the draft. but I suggest you experts
look congestion control on at higher level. How about loss-based
algorithm causing huge queues with BB. Ok I am deviating now ...

>
> It is not entirely clear to me whether that difference indeed matters = in reality with RFC 3390, since fast open mostly affects *when* data is sen= t. Maybe this is a corner case only. But at least it might be worthwile to = mention that side-effect in the draft. That might also help to understand w= hat would happen if fast open and IW10 are used at the same time. That ques= tion was raised several times already.
>
As I said, IW10 is part of RFC5681. TFO does not update RFC5681
currently. Should I mention TCP-SACK in TFO too?


> Thanks
>
> Michael (as individual)
>
>
>> -----Original Message-----
>> From: t= cpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On
>> Behalf Of Yuchung Cheng
>> Sent: Tuesday, October 23, 2012 12:22 AM
>> To: tcpm@ietf.o= rg
>> Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-fastopen-02.txt >>
>> On Mon, Oct 22, 2012 at 11:57 AM, =A0<internet-drafts@ietf.org> wrote= :
>> >
>> > A New Internet-Draft is available from the on-line
>> Internet-Drafts directories.
>> > =A0This draft is a work item of the TCP Maintenance and Minor=
>> Extensions Working Group of the IETF.
>> >
>> > =A0 =A0 =A0 =A0 Title =A0 =A0 =A0 =A0 =A0 : TCP Fast Open
>> > =A0 =A0 =A0 =A0 Author(s) =A0 =A0 =A0 : Yuchung Cheng
>> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Jerry Chu=
>> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Sivasanka= r Radhakrishnan
>> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Arvind Ja= in
>> > =A0 =A0 =A0 =A0 Filename =A0 =A0 =A0 =A0: draft-ietf-tcpm-fas= topen-02.txt
>> > =A0 =A0 =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 : 22
>> > =A0 =A0 =A0 =A0 Date =A0 =A0 =A0 =A0 =A0 =A0: 2012-10-22
>> >
>> > Abstract:
>> > =A0 =A0TCP Fast Open (TFO) allows data to be carried in the S= YN
>> and SYN-ACK
>> > =A0 =A0packets and consumed by the receiving end during the i= nitial
>> > =A0 =A0connection handshake, thus saving up to one full round= trip time
>> > =A0 =A0(RTT) compared to standard TCP which requires a
>> three-way handshake
>> > =A0 =A0(3WHS) to complete before data can be exchanged.
>> ChangeLog since 01:
>>
>> - elaborate more on the issue of duplicate SYN-data (sec 2.1)
>>
>> - use draft-tcpm-experimental-options (sec 10)
>>
>> - add a new subsection about attacks from behind NAT (sec 6.3)
>> =A0 and discuss Bob Briscoe's idea on defending with TCP-TS an= d
>> =A0 cookies
>>
>> - use null cookie (end of sec 4.1.2) (courtesy of Bob Briscoe)
>>
>> - explain the problem of cookie option in FIN (end of 4.2.1)
>>
>> - re-emphasize other than including data in SYN packet. TFO
>> =A0 draft does not change any part of congestion control, and
>> =A0 the transmission MUST be governed by CC (sec 4.2.2)
>>
>> - a bunch of minor edits
>>
>> >
>> > Terminology
>> >
>> > The IETF datatracker status page for this draft is:
>> > https://datatracker.ietf.org/doc/draft-ietf-tcpm= -fastopen
>> >
>> > There's also a htmlized version available at:
>> > http://tools.ietf.org/html/draft-ietf-tcpm-fastopen= -02
>> >
>> > A diff from the previous version is available at:
>> > http://www.ietf.org/rfcdiff?url2=3Ddraft-ie= tf-tcpm-fastopen-02
>> >
>> >
>> > Internet-Drafts are also available by anonymous FTP at:
>> > ftp://ftp.ietf.org/internet-drafts/
>> >
>> > _______________________________________________
>> > 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
ht= tps://www.ietf.org/mailman/listinfo/tcpm


--f46d0407166d4a585504cd602661--