From nobody Thu Jun 1 00:19:56 2017 Return-Path: X-Original-To: tcpm@ietf.org Delivered-To: tcpm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D700127909; Thu, 1 Jun 2017 00:19:47 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: tcpm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.52.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149630158721.19877.17356856200156572664@ietfa.amsl.com> Date: Thu, 01 Jun 2017 00:19:47 -0700 Archived-At: Subject: [tcpm] I-D Action: draft-ietf-tcpm-dctcp-07.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jun 2017 07:19:47 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the TCP Maintenance and Minor Extensions of the IETF. Title : Datacenter TCP (DCTCP): TCP Congestion Control for Datacenters Authors : Stephen Bensley Dave Thaler Praveen Balasubramanian Lars Eggert Glenn Judd Filename : draft-ietf-tcpm-dctcp-07.txt Pages : 15 Date : 2017-06-01 Abstract: This informational memo describes Datacenter TCP (DCTCP), a TCP congestion control scheme for datacenter traffic. DCTCP extends the Explicit Congestion Notification (ECN) processing to estimate the fraction of bytes that encounter congestion, rather than simply detecting that some congestion has occurred. DCTCP then scales the TCP congestion window based on this estimate. This method achieves high burst tolerance, low latency, and high throughput with shallow- buffered switches. This memo also discusses deployment issues related to the coexistence of DCTCP and conventional TCP, the lack of a negotiating mechanism between sender and receiver, and presents some possible mitigations. This memo documents existing DCTCP implementations ([WINDOWS], [LINUX], [FREEBSD]) and deployment experience ([MORGANSTANLEY]). DCTCP as described in this draft is applicable to deployments in controlled environments like datacenters but it must not be deployed over the public Internet without additional measures, as detailed in Section 5. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tcpm-dctcp/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tcpm-dctcp-07 https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-dctcp-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-dctcp-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Jun 1 01:27:39 2017 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 6481512D0C3 for ; Thu, 1 Jun 2017 01:27:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.821 X-Spam-Level: X-Spam-Status: No, score=-2.821 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jUjN14QlOzqA for ; Thu, 1 Jun 2017 01:27:36 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E081512EB30 for ; Thu, 1 Jun 2017 01:27:35 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml708-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DOF03931; Thu, 01 Jun 2017 08:27:34 +0000 (GMT) Received: from DGGEMA406-HUB.china.huawei.com (10.3.20.47) by lhreml708-cah.china.huawei.com (10.201.108.49) with Microsoft SMTP Server (TLS) id 14.3.301.0; Thu, 1 Jun 2017 09:27:33 +0100 Received: from DGGEMA502-MBX.china.huawei.com ([169.254.2.207]) by DGGEMA406-HUB.china.huawei.com ([10.3.20.47]) with mapi id 14.03.0301.000; Thu, 1 Jun 2017 16:27:25 +0800 From: "zhangyali (D)" To: "tcpm@ietf.org" Thread-Topic: How about data packets and ACKs go through different paths? Thread-Index: AdLarrOB/UkFSRchRkaYbOvtQfTFQw== Date: Thu, 1 Jun 2017 08:27:25 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.189.228] Content-Type: multipart/alternative; boundary="_000_A747A0713F56294D8FBE33E5C6B8F5815F58BE74DGGEMA502MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020205.592FCFF6.00D2, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.2.207, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 3880660f3caab9037c02f4dc4d6e4d51 Archived-At: Subject: [tcpm] How about data packets and ACKs go through different paths? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jun 2017 08:27:37 -0000 --_000_A747A0713F56294D8FBE33E5C6B8F5815F58BE74DGGEMA502MBXchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, I notice that TCP mechanism does not require data packets and their ACKs sh= are the same path, that is simple implemented in the network. But some prob= lems may happen if the sender does not perceive it. For example, the data p= acket is transmitted successfully without any congestion, while the ACK pac= ket is dropped since it goes through a very congested path. But the sender= could not ascertain the real reason of "the data packet is lost". If this = event repeats three times, the sender will cut its window by half wrongly, = which will hurt its throughput. But in effect, this bad phenomenon should n= ot happen if the ACK packet go through any uncongested way. Best Regards, Yali --_000_A747A0713F56294D8FBE33E5C6B8F5815F58BE74DGGEMA502MBXchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,<= /span>

 

I notice that TCP m= echanism does not require data packets and their ACKs share the same path, = that is simple implemented in the network. But some problems may happen if = the sender does not perceive it. For example, the data packet is transmitted successfully without any congestio= n, while the ACK packet is dropped since it  goes through a very conge= sted path. But the sender could not ascertain the real reason of “the= data packet is lost”. If this event repeats three times, the sender will cut its window by half wrongly, which will hu= rt its throughput. But in effect, this bad phenomenon should not happen &nb= sp;if the ACK packet go through any uncongested way.

 

Best Regards,

Yali

--_000_A747A0713F56294D8FBE33E5C6B8F5815F58BE74DGGEMA502MBXchi_-- From nobody Thu Jun 1 02:54:45 2017 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 C684612EB59 for ; Thu, 1 Jun 2017 02:54:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.688 X-Spam-Level: X-Spam-Status: No, score=-2.688 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Kf658f69k6T for ; Thu, 1 Jun 2017 02:54:33 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A250127867 for ; Thu, 1 Jun 2017 02:54:33 -0700 (PDT) Received: from srichardlxp2 ([213.143.121.76]) by mail.gmx.com (mrgmx002 [212.227.17.190]) with ESMTPSA (Nemesis) id 0LvENG-1dxZm91gLi-010MWu; Thu, 01 Jun 2017 11:54:23 +0200 Message-ID: <570162BE751147C9841878AC82CACA1C@srichardlxp2> From: "Richard Scheffenegger" To: "zhangyali \(D\)" , References: Date: Thu, 1 Jun 2017 11:14:57 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_145F_01D2DAC8.4EF57830" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Provags-ID: V03:K0:+2wFOomeu3feipYtBUD4hQqM7W6xfg8E4SH0xYQSSm7F+oQkwuO tUO985nWvEw8gWRDdBK9hCDG32hHeFPptOtObN0Cvfr4MspELhQmEyYXuBGMKDgAAlS9z+x xNq2oT8WcAlQHuKcuDN8zLhiEvLX5+YwfKH41OO6wnThLyG1+ZSoneM8YybJiaIMCJ/nTyZ qppOFdgdieDfkWM5PeRww== X-UI-Out-Filterresults: notjunk:1;V01:K0:Dj6TitGkSLo=:UISi8CVUaxkU85HyYZzg4e s+HzztSQICiChPA3rnFXlfVmRjYmHo4sw2O8eNsvm7gXTlAHv5CUbxo6qsV+qLt5A6+6p5RMM 5A4UAtJDyELf5Em+VPaOdagyCDLADflAG83XlC7mI15xeh2H3xNuea/Db7TmvcqOeQttJ0O2v 4KXFQZLVn04DOD+pmkAxXXL8dE8rmO7/v7gcgpyTo88LQC1X7PoVb14q2elvfqxUYXrLX0KhF X4Rq1v0TUdsTcxwiQE8q+Px+iYD5J/vr4+vXBoY4Ho3nY3cbGI0pBeE0Coc3W2kvKGlOdrYxW 9Qi47VgxUwRhfhYjLk7s0jCX3Sdu47h98hxVhkTLBplDhwWHoNd0axLMGNAULlkzFN+07pcAg oYMQTsxkoauHftB5NzqisTx6KH8l9544PAmpzxbEuZL30e9jpuAnRS30DEXLYiQ/0cEOm9nwo lZwfocwqZNTmUGzREPKOXva3WZ6sXO1JalExktde0VmIxM+Ek6G0HMQsf+FE4lvbth85RY6HL yOIL2+G58qoISaC6iwxKs7Gabw/1EJ9ghZ3P093u8HlOASBl+vCnUGh8GNvf8HwrQg/0x3D4q +Pshjij5EZWzypUzeVVTBs3dTMUvZxESXjBiDrhpKCEQY2wOE5pXu1MCk5XAQwQSnBgwH5FqC A4UZ5oQOkdF9Ye2nIuPVsScJrspPL/NEkM0DxLqnGYhKcbZfx11h+1xLy2sz07X+EkGfsT2QI 5EKDHYr30gdxHSf9ux1JUGG5FMR5YIoNUlMNv+ZqJOaQxh5tSku0EP3QO7MxZ4ylAz/rpyFqs it+OF45 Archived-At: Subject: Re: [tcpm] How about data packets and ACKs go through different paths? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jun 2017 09:54:38 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_145F_01D2DAC8.4EF57830 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Yali, this is not what will happen typically; As ACKs are cumulative, and = often contains additional information about lost data packets (SACK = option) and timing (timestamps), all the sender needs is a fraction of = ACKs (depending on bandwidth-delay product and current state of the = sender) for it to utilize most of the forward path. Also, when the return (ACK) path is heavily congested, it's arguably a = good idea for the sender to throttle the sending rate, in order to = reduce the number of ACKs contributing to congestion on the return = path... Btw - ACK thinning (deliberate dropping of some ACKs) has been observed = on some paths... Best regards, Richard ----- Original Message -----=20 From: zhangyali (D)=20 To: tcpm@ietf.org=20 Sent: Thursday, June 01, 2017 10:27 AM Subject: [tcpm] How about data packets and ACKs go through different = paths? Hi all, =20 I notice that TCP mechanism does not require data packets and their = ACKs share the same path, that is simple implemented in the network. But = some problems may happen if the sender does not perceive it. For = example, the data packet is transmitted successfully without any = congestion, while the ACK packet is dropped since it goes through a = very congested path. But the sender could not ascertain the real reason = of "the data packet is lost". If this event repeats three times, the = sender will cut its window by half wrongly, which will hurt its = throughput. But in effect, this bad phenomenon should not happen if the = ACK packet go through any uncongested way. =20 Best Regards, Yali Virus-free. www.avg.com =20 -------------------------------------------------------------------------= ----- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm ------=_NextPart_000_145F_01D2DAC8.4EF57830 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Yali,
 
this is not what will happen typically; = As ACKs are=20 cumulative, and often contains additional information about lost data = packets=20 (SACK option) and timing (timestamps), all the sender needs is a = fraction of=20 ACKs (depending on bandwidth-delay product and current state of the = sender) for=20 it to utilize most of the forward path.
 
Also, when the return (ACK) path is = heavily=20 congested, it's arguably a good idea for the sender to throttle the = sending=20 rate, in order to reduce the number of ACKs contributing to congestion = on the=20 return path...
 
Btw - ACK thinning (deliberate dropping = of some=20 ACKs) has been observed on some paths...
 
Best regards,
   Richard
 
----- Original Message -----
From:=20 zhangyali (D)
Sent: Thursday, June 01, 2017 = 10:27=20 AM
Subject: [tcpm] How about data = packets=20 and ACKs go through different paths?

Hi = all,

 

I notice that TCP = mechanism=20 does not require data packets and their ACKs share the same path, that = is=20 simple implemented in the network. But some problems may happen if the = sender=20 does not perceive it. For example, the data packet is transmitted = successfully=20 without any congestion, while the ACK packet is dropped since it =  goes=20 through a very congested path. But the sender could not ascertain the = real=20 reason of =93the data packet is lost=94. If this event repeats three = times, the=20 sender will cut its window by half wrongly, which will hurt its = throughput.=20 But in effect, this bad phenomenon should not happen  if the ACK = packet=20 go through any uncongested way.

 

Best Regards,

Yali


Virus-free.=20 www.avg.com

_______________________________________________
tcpm mailing = = list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm
------=_NextPart_000_145F_01D2DAC8.4EF57830-- From nobody Thu Jun 1 04:50:34 2017 Return-Path: X-Original-To: tcpm@ietf.org Delivered-To: tcpm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EB4C212EB8A; Thu, 1 Jun 2017 04:50:31 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.52.0 Auto-Submitted: auto-generated Precedence: bulk CC: tcpm@ietf.org, Michael Scharf , michael.scharf@nokia.com, draft-ietf-tcpm-dctcp@ietf.org, ietf@kuehlewind.net, tcpm-chairs@ietf.org Reply-To: ietf@ietf.org Sender: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <149631783186.22297.8209168017435474281.idtracker@ietfa.amsl.com> Date: Thu, 01 Jun 2017 04:50:31 -0700 Archived-At: Subject: [tcpm] Last Call: (Datacenter TCP (DCTCP): TCP Congestion Control for Datacenters) to Informational RFC X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jun 2017 11:50:32 -0000 The IESG has received a request from the TCP Maintenance and Minor Extensions WG (tcpm) to consider the following document: - 'Datacenter TCP (DCTCP): TCP Congestion Control for Datacenters' as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2017-06-15. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This informational memo describes Datacenter TCP (DCTCP), a TCP congestion control scheme for datacenter traffic. DCTCP extends the Explicit Congestion Notification (ECN) processing to estimate the fraction of bytes that encounter congestion, rather than simply detecting that some congestion has occurred. DCTCP then scales the TCP congestion window based on this estimate. This method achieves high burst tolerance, low latency, and high throughput with shallow- buffered switches. This memo also discusses deployment issues related to the coexistence of DCTCP and conventional TCP, the lack of a negotiating mechanism between sender and receiver, and presents some possible mitigations. This memo documents existing DCTCP implementations ([WINDOWS], [LINUX], [FREEBSD]) and deployment experience ([MORGANSTANLEY]). DCTCP as described in this draft is applicable to deployments in controlled environments like datacenters but it must not be deployed over the public Internet without additional measures, as detailed in Section 5. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-tcpm-dctcp/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-tcpm-dctcp/ballot/ The following IPR Declarations may be related to this I-D: https://datatracker.ietf.org/ipr/2319/ From nobody Thu Jun 1 10:36:22 2017 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 B09E012F27C for ; Thu, 1 Jun 2017 10:36:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yw3i_Goi4oPn for ; Thu, 1 Jun 2017 10:36:20 -0700 (PDT) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D11EC12EB0D for ; Thu, 1 Jun 2017 10:36:20 -0700 (PDT) Received: from [128.9.184.76] ([128.9.184.76]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id v51HZt4E017546 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 1 Jun 2017 10:35:56 -0700 (PDT) To: "zhangyali (D)" , "tcpm@ietf.org" References: From: Joe Touch Message-ID: <30c6b6a3-5136-7e75-1426-f3261ef4d0af@isi.edu> Date: Thu, 1 Jun 2017 10:35:57 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------6405A34C2891B16C933614A0" Content-Language: en-US X-MailScanner-ID: v51HZt4E017546 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [tcpm] How about data packets and ACKs go through different paths? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jun 2017 17:36:21 -0000 This is a multi-part message in MIME format. --------------6405A34C2891B16C933614A0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit On 6/1/2017 1:27 AM, zhangyali (D) wrote: > > Hi all, > > > > I notice that TCP mechanism does not require data packets and their > ACKs share the same path, > The Internet does not require that forward and reverse paths are identical. > that is simple implemented in the network. But some problems may > happen if the sender does not perceive it. For example, the data > packet is transmitted successfully without any congestion, while the > ACK packet is dropped since it goes through a very congested path. > If ACKs are dropped due to congestion, then backing off transmission might be a valid response. However, as Richard noted, ACKs are cumulative, so if any of the later ACKs get through, the system may slow down (due to the increased delay and bursting) but won't necessarily backoff. > ut the sender could not ascertain the real reason of “the data packet > is lost”. > TCP always interprets loss as congestion, because it is safer than assuming otherwise (e.g., corruption, which would expect immediate retransmission). > If this event repeats three times, the sender will cut its window by > half wrongly, which will hurt its throughput.... > Again, maybe that's actually a good thing. Joe --------------6405A34C2891B16C933614A0 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit



On 6/1/2017 1:27 AM, zhangyali (D) wrote:

Hi all,

 

I notice that TCP mechanism does not require data packets and their ACKs share the same path,

The Internet does not require that forward and reverse paths are identical.

that is simple implemented in the network. But some problems may happen if the sender does not perceive it. For example, the data packet is transmitted successfully without any congestion, while the ACK packet is dropped since it  goes through a very congested path.

If ACKs are dropped due to congestion, then backing off transmission might be a valid response.

However, as Richard noted, ACKs are cumulative, so if any of the later ACKs get through, the system may slow down (due to the increased delay and bursting) but won't necessarily backoff.

ut the sender could not ascertain the real reason of “the data packet is lost”.

TCP always interprets loss as congestion, because it is safer than assuming otherwise (e.g., corruption, which would expect immediate retransmission).

If this event repeats three times, the sender will cut its window by half wrongly, which will hurt its throughput....


Again, maybe that's actually a good thing.

Joe
--------------6405A34C2891B16C933614A0-- From nobody Thu Jun 1 18:49:36 2017 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 D391B12948E for ; Thu, 1 Jun 2017 18:49:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4JbgciVIbP9m for ; Thu, 1 Jun 2017 18:49:34 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C281C126B6E for ; Thu, 1 Jun 2017 18:49:33 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml708-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DHT09463; Fri, 02 Jun 2017 01:49:31 +0000 (GMT) Received: from DGGEMA403-HUB.china.huawei.com (10.3.20.44) by lhreml708-cah.china.huawei.com (10.201.108.49) with Microsoft SMTP Server (TLS) id 14.3.301.0; Fri, 2 Jun 2017 02:49:29 +0100 Received: from DGGEMA502-MBX.china.huawei.com ([169.254.2.207]) by DGGEMA403-HUB.china.huawei.com ([10.3.20.44]) with mapi id 14.03.0301.000; Fri, 2 Jun 2017 09:49:22 +0800 From: "zhangyali (D)" To: Richard Scheffenegger CC: "tcpm@ietf.org" Thread-Topic: [tcpm] How about data packets and ACKs go through different paths? Thread-Index: AdLarrOB/UkFSRchRkaYbOvtQfTFQwADmD/OACCxBQA= Date: Fri, 2 Jun 2017 01:49:22 +0000 Message-ID: References: <570162BE751147C9841878AC82CACA1C@srichardlxp2> In-Reply-To: <570162BE751147C9841878AC82CACA1C@srichardlxp2> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.189.228] Content-Type: multipart/alternative; boundary="_000_A747A0713F56294D8FBE33E5C6B8F5815F58C054DGGEMA502MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020202.5930C42B.01A4, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.2.207, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 64dd8b3560a384b0cf0dc8c260c712d6 Archived-At: Subject: [tcpm] =?gb2312?b?tPC4tDogIEhvdyBhYm91dCBkYXRhIHBhY2tldHMgYW5k?= =?gb2312?b?IEFDS3MgZ28gdGhyb3VnaCBkaWZmZXJlbnQgcGF0aHM/?= X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2017 01:49:36 -0000 --_000_A747A0713F56294D8FBE33E5C6B8F5815F58C054DGGEMA502MBXchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgUmljaGFyZCwNCg0KVGhhbmsgeW91IGZvciB5b3VyIHByb21wdCByZXBseS4NCg0KSW5kZWVk LCBzZW5kZXIgc2hvdWxkIGRlY2VsZXJhdGUgdG8gZWFzZSBjb25nZXN0aW9uIGlmIGl0IGZpbmRz IEFDSyBwYWNrZXQgaGFzIGJlZW4gZHJvcHBlZC4gQnV0IHRoYXQgcmVsYXRlIHRvIGhvdyB0byBh Y2hpZXZlIGEgaGlnaCB1dGlsaXphdGlvbiBvZiBuZXR3b3JrIHJlc291cmNlLiBBIHNpbXBsZSB0 aGluayBpcyB0aGF0IG5ldHdvcmsgdXRpbGl6YXRpb24gd2lsbCBiZSBsb3dlciBpZiBzZW5kZXIg ZG8gbm90IGRpZmZlciB0aGUgY29uZ2VzdGlvbiBkZWdyZWUgYmV0d2VlbiBkYXRhIHBhY2tldCBw YXRoIGFuZCBhY2sgcGFja2V0IHBhdGguDQoNCkFub3RoZXIgcXVlc3Rpb24gaXMgdGhhdCBzb21l IGNvbmdlc3Rpb24gY29udHJvbCBtZWNoYW5pc20gdGFrZSB1c2Ugb2YgZGVsYXkgbWVhc3VyZWQg YnkgQUNLIHRpbWVzdGFtcHMgdG8gZGVub3RlIGNvbmdlc3Rpb24gZGVncmVlLiBJZiBkYXRhIHBh Y2tldHMgYW5kIHRoZWlyIEFDSyBwYWNrZXRzIGdvIHRocm91Z2ggZGlmZmVyZW50IHdheXMsIHRo ZSBtZWFzdXJlbWVudCBvZiBkZWxheSBtYXkgY29uZnVzZSByZXZlcnNlIHBhdGggY29uZ2VzdGlv biBleHBlcmllbmNlZCBieSBBQ0tzIHdpdGggZm9yd2FyZCBwYXRoIGNvbmdlc3Rpb24gZXhwZXJp ZW5jZWQgYnkgZGF0YSBwYWNrZXRzLiBJIHRoaW5rIFZlZ2FzLCBhIGRlbGF5LWJhc2VkIGNvbmdl c3Rpb24gY29udHJvbCBtZWNoYW5pc20sIHdpbGwgZXhwZXJpZW5jZSB0aGlzIHByb2JsZW0uDQoN CkJlc3QsDQpZYWxpDQoNCreivP7IyzogUmljaGFyZCBTY2hlZmZlbmVnZ2VyIFttYWlsdG86cnMu aWV0ZkBnbXguYXRdDQq3osvNyrG85DogMjAxN8TqNtTCMcjVIDE3OjE1DQrK1bz+yMs6IHpoYW5n eWFsaSAoRCkgPHpoYW5neWFsaTM2OUBodWF3ZWkuY29tPjsgdGNwbUBpZXRmLm9yZw0K1vfM4jog UmU6IFt0Y3BtXSBIb3cgYWJvdXQgZGF0YSBwYWNrZXRzIGFuZCBBQ0tzIGdvIHRocm91Z2ggZGlm ZmVyZW50IHBhdGhzPw0KDQpIaSBZYWxpLA0KDQp0aGlzIGlzIG5vdCB3aGF0IHdpbGwgaGFwcGVu IHR5cGljYWxseTsgQXMgQUNLcyBhcmUgY3VtdWxhdGl2ZSwgYW5kIG9mdGVuIGNvbnRhaW5zIGFk ZGl0aW9uYWwgaW5mb3JtYXRpb24gYWJvdXQgbG9zdCBkYXRhIHBhY2tldHMgKFNBQ0sgb3B0aW9u KSBhbmQgdGltaW5nICh0aW1lc3RhbXBzKSwgYWxsIHRoZSBzZW5kZXIgbmVlZHMgaXMgYSBmcmFj dGlvbiBvZiBBQ0tzIChkZXBlbmRpbmcgb24gYmFuZHdpZHRoLWRlbGF5IHByb2R1Y3QgYW5kIGN1 cnJlbnQgc3RhdGUgb2YgdGhlIHNlbmRlcikgZm9yIGl0IHRvIHV0aWxpemUgbW9zdCBvZiB0aGUg Zm9yd2FyZCBwYXRoLg0KDQpBbHNvLCB3aGVuIHRoZSByZXR1cm4gKEFDSykgcGF0aCBpcyBoZWF2 aWx5IGNvbmdlc3RlZCwgaXQncyBhcmd1YWJseSBhIGdvb2QgaWRlYSBmb3IgdGhlIHNlbmRlciB0 byB0aHJvdHRsZSB0aGUgc2VuZGluZyByYXRlLCBpbiBvcmRlciB0byByZWR1Y2UgdGhlIG51bWJl ciBvZiBBQ0tzIGNvbnRyaWJ1dGluZyB0byBjb25nZXN0aW9uIG9uIHRoZSByZXR1cm4gcGF0aC4u Lg0KDQpCdHcgLSBBQ0sgdGhpbm5pbmcgKGRlbGliZXJhdGUgZHJvcHBpbmcgb2Ygc29tZSBBQ0tz KSBoYXMgYmVlbiBvYnNlcnZlZCBvbiBzb21lIHBhdGhzLi4uDQoNCkJlc3QgcmVnYXJkcywNCiAg IFJpY2hhcmQNCg0KLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLQ0KRnJvbTogemhhbmd5YWxp IChEKTxtYWlsdG86emhhbmd5YWxpMzY5QGh1YXdlaS5jb20+DQpUbzogdGNwbUBpZXRmLm9yZzxt YWlsdG86dGNwbUBpZXRmLm9yZz4NClNlbnQ6IFRodXJzZGF5LCBKdW5lIDAxLCAyMDE3IDEwOjI3 IEFNDQpTdWJqZWN0OiBbdGNwbV0gSG93IGFib3V0IGRhdGEgcGFja2V0cyBhbmQgQUNLcyBnbyB0 aHJvdWdoIGRpZmZlcmVudCBwYXRocz8NCg0KSGkgYWxsLA0KDQpJIG5vdGljZSB0aGF0IFRDUCBt ZWNoYW5pc20gZG9lcyBub3QgcmVxdWlyZSBkYXRhIHBhY2tldHMgYW5kIHRoZWlyIEFDS3Mgc2hh cmUgdGhlIHNhbWUgcGF0aCwgdGhhdCBpcyBzaW1wbGUgaW1wbGVtZW50ZWQgaW4gdGhlIG5ldHdv cmsuIEJ1dCBzb21lIHByb2JsZW1zIG1heSBoYXBwZW4gaWYgdGhlIHNlbmRlciBkb2VzIG5vdCBw ZXJjZWl2ZSBpdC4gRm9yIGV4YW1wbGUsIHRoZSBkYXRhIHBhY2tldCBpcyB0cmFuc21pdHRlZCBz dWNjZXNzZnVsbHkgd2l0aG91dCBhbnkgY29uZ2VzdGlvbiwgd2hpbGUgdGhlIEFDSyBwYWNrZXQg aXMgZHJvcHBlZCBzaW5jZSBpdCAgZ29lcyB0aHJvdWdoIGEgdmVyeSBjb25nZXN0ZWQgcGF0aC4g QnV0IHRoZSBzZW5kZXIgY291bGQgbm90IGFzY2VydGFpbiB0aGUgcmVhbCByZWFzb24gb2YgobB0 aGUgZGF0YSBwYWNrZXQgaXMgbG9zdKGxLiBJZiB0aGlzIGV2ZW50IHJlcGVhdHMgdGhyZWUgdGlt ZXMsIHRoZSBzZW5kZXIgd2lsbCBjdXQgaXRzIHdpbmRvdyBieSBoYWxmIHdyb25nbHksIHdoaWNo IHdpbGwgaHVydCBpdHMgdGhyb3VnaHB1dC4gQnV0IGluIGVmZmVjdCwgdGhpcyBiYWQgcGhlbm9t ZW5vbiBzaG91bGQgbm90IGhhcHBlbiAgaWYgdGhlIEFDSyBwYWNrZXQgZ28gdGhyb3VnaCBhbnkg dW5jb25nZXN0ZWQgd2F5Lg0KDQpCZXN0IFJlZ2FyZHMsDQpZYWxpDQoNCltodHRwczovL2lwbWNk bi5hdmFzdC5jb20vaW1hZ2VzL2ljb25zL2ljb24tZW52ZWxvcGUtdGljay1ncmVlbi1hdmctdjEu cG5nXTxodHRwOi8vd3d3LmF2Zy5jb20vZW1haWwtc2lnbmF0dXJlP3V0bV9tZWRpdW09ZW1haWwm dXRtX3NvdXJjZT1saW5rJnV0bV9jYW1wYWlnbj1zaWctZW1haWwmdXRtX2NvbnRlbnQ9ZW1haWxj bGllbnQ+DQoNClZpcnVzLWZyZWUuIHd3dy5hdmcuY29tPGh0dHA6Ly93d3cuYXZnLmNvbS9lbWFp bC1zaWduYXR1cmU/dXRtX21lZGl1bT1lbWFpbCZ1dG1fc291cmNlPWxpbmsmdXRtX2NhbXBhaWdu PXNpZy1lbWFpbCZ1dG1fY29udGVudD1lbWFpbGNsaWVudD4NCg0KX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQp0Y3BtIG1haWxpbmcgbGlzdA0KdGNwbUBpZXRmLm9yZzxtYWlsdG86dGNwbUBpZXRm Lm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdGNwbQ0K --_000_A747A0713F56294D8FBE33E5C6B8F5815F58C054DGGEMA502MBXchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi Richard,=

 

Thank you for your pro= mpt reply.

 

Indeed, sender should = decelerate to ease congestion if it finds ACK packet has been dropped. But = that relate to how to achieve a high utilization of network resource. A sim= ple think is that network utilization will be lower if sender do not differ the congestion degree between data p= acket path and ack packet path.

 

Another question is th= at some congestion control mechanism take use of delay measured by ACK time= stamps to denote congestion degree. If data packets and their ACK packets g= o through different ways, the measurement of delay may confuse reverse path congestion experienced by ACKs with forw= ard path congestion experienced by data packets. I think Vegas, a delay-bas= ed congestion control mechanism, will experience this problem.

 

Best,

Yali=

 

=B7=A2=BC=FE=C8=CB= : Richard Scheffenegger [mailto:rs.ietf@gmx.at]
=B7=A2=CB=CD=CA=B1=BC=E4: 2017=C4=EA6=D4=C21=C8=D5 17:15
=CA=D5=BC=FE=C8=CB: zhangyali (D) <zh= angyali369@huawei.com>; tcpm@ietf.org
=D6=F7=CC=E2: Re: [tcpm] How about data = packets and ACKs go through different paths?

 

Hi Yali,

 

this is not what will happen typically; As ACKs are c= umulative, and often contains additional information about lost data packet= s (SACK option) and timing (timestamps), all the sender needs is a fraction of ACKs (depending on bandwidth-delay product a= nd current state of the sender) for it to utilize most of the forward path.=

 

Also, when the return (ACK) path is heavily congested= , it's arguably a good idea for the sender to throttle the sending rate, in= order to reduce the number of ACKs contributing to congestion on the return path...

 

Btw - ACK thinning (deliberate dropping of some ACKs)= has been observed on some paths...

 

Best regards,

   Richard

 

----- Original Message -----

Sent: Thursday, June 01, 2017 10:27 AM

Subject: [tcpm] How about data packets a= nd ACKs go through different paths?

 

Hi all,<= /span>

 

I notice that TCP m= echanism does not require data packets and their ACKs share the same path, = that is simple implemented in the network. But some problems may happen if = the sender does not perceive it. For example, the data packet is transmitted successfully without any congestio= n, while the ACK packet is dropped since it  goes through a very conge= sted path. But the sender could not ascertain the real reason of =A1=B0the = data packet is lost=A1=B1. If this event repeats three times, the sender will cut its window by half wrongly, which will hu= rt its throughput. But in effect, this bad phenomenon should not happen &nb= sp;if the ACK packet go through any uncongested way.

 

Best Regards,

Yali

 

Virus-free= . www.avg.com

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

--_000_A747A0713F56294D8FBE33E5C6B8F5815F58C054DGGEMA502MBXchi_-- From nobody Thu Jun 1 22:12:10 2017 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 357201294D4 for ; Thu, 1 Jun 2017 22:12:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BKqFthp2y3bf for ; Thu, 1 Jun 2017 22:12:07 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.142.130]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD1B8126D05 for ; Thu, 1 Jun 2017 22:12:06 -0700 (PDT) Received: from mail-oi0-f44.google.com (mail-oi0-f44.google.com [209.85.218.44]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id C206F2783BA for ; Fri, 2 Jun 2017 14:12:03 +0900 (JST) Received: by mail-oi0-f44.google.com with SMTP id w10so79010060oif.0 for ; Thu, 01 Jun 2017 22:12:03 -0700 (PDT) X-Gm-Message-State: AODbwcCfZQ4Seca9td8Gz5r/rjTBDIkGhM2ieWc/ZvbsZ8iQQddwqCTo losXqd2qkwGBKWS5E2f6RONk5zFsWQ== X-Received: by 10.202.206.193 with SMTP id e184mr3229189oig.91.1496380322445; Thu, 01 Jun 2017 22:12:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.67.148 with HTTP; Thu, 1 Jun 2017 22:12:02 -0700 (PDT) In-Reply-To: References: <570162BE751147C9841878AC82CACA1C@srichardlxp2> From: Yoshifumi Nishida Date: Thu, 1 Jun 2017 22:12:02 -0700 X-Gmail-Original-Message-ID: Message-ID: To: "zhangyali (D)" Cc: Richard Scheffenegger , "tcpm@ietf.org" Content-Type: multipart/alternative; boundary="001a113d2e729185af0550f33156" Archived-At: Subject: Re: [tcpm] =?utf-8?b?562U5aSNOiBIb3cgYWJvdXQgZGF0YSBwYWNrZXRzIGFu?= =?utf-8?q?d_ACKs_go_through_different_paths=3F?= X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2017 05:12:09 -0000 --001a113d2e729185af0550f33156 Content-Type: text/plain; charset="UTF-8" On Thu, Jun 1, 2017 at 6:49 PM, zhangyali (D) wrote: > Hi Richard, > > > > Thank you for your prompt reply. > > > > Indeed, sender should decelerate to ease congestion if it finds ACK packet > has been dropped. But that relate to how to achieve a high utilization of > network resource. A simple think is that network utilization will be lower > if sender do not differ the congestion degree between data packet path and > ack packet path. > > > > Another question is that some congestion control mechanism take use of > delay measured by ACK timestamps to denote congestion degree. If data > packets and their ACK packets go through different ways, the measurement of > delay may confuse reverse path congestion experienced by ACKs with forward > path congestion experienced by data packets. I think Vegas, a delay-based > congestion control mechanism, will experience this problem. > Right, I think you'll need to measure one-way delay, which vegas doesn't. -- Yoshi --001a113d2e729185af0550f33156 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu, Jun 1, 2017 at 6:49 PM, zhangyali (D) <zhangyali369@huaw= ei.com> wrote:

Hi Richard,<= /u>

=C2=A0

Thank you for your pro= mpt reply.

=C2=A0

Indeed, sender should = decelerate to ease congestion if it finds ACK packet has been dropped. But = that relate to how to achieve a high utilization of network resource. A sim= ple think is that network utilization will be lower if sender do not differ the congestion degree between data p= acket path and ack packet path.

=C2=A0

Another question is th= at some congestion control mechanism take use of delay measured by ACK time= stamps to denote congestion degree. If data packets and their ACK packets g= o through different ways, the measurement of delay may confuse reverse path congestion experienced by ACKs with forw= ard path congestion experienced by data packets. I think Vegas, a delay-bas= ed congestion control mechanism, will experience this problem.


Right, I think you'll need t= o measure one-way delay, which vegas doesn't.
--
Yo= shi
=C2=A0
--001a113d2e729185af0550f33156-- From nobody Mon Jun 5 00:56:27 2017 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 70E67129BDA for ; Mon, 5 Jun 2017 00:56:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2yQkMSpsqnro for ; Mon, 5 Jun 2017 00:56:17 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 04B1B129BF8 for ; Mon, 5 Jun 2017 00:56:16 -0700 (PDT) X-AuditID: c1b4fb3a-6e3519a000004a6a-cf-59350e9e0983 Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.183.72]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 58.59.19050.E9E05395; Mon, 5 Jun 2017 09:56:15 +0200 (CEST) Received: from EUR02-VE1-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.72) with Microsoft SMTP Server (TLS) id 14.3.339.0; Mon, 5 Jun 2017 09:55:08 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=1PMN85yA8qJd4zYrOwBpfGt5b/PitbyIjXmfjGbrOE8=; b=KEf3V24vYsQ0EXy1icTJ1FlW3KNqUtCpgUS7ggypArG6u1qRHGETjBEvqrPTpM3pY2RmzTFMnLkh/HzR3+OpfmVetNYc5qx0iAImzb7HL89nCJfIk+LCPFPNqOlZfJVuxDBOjpG7CTQMJbrqF6Nkkk5wowRsRmww1qUaq1NmDB4= Received: from DB4PR07MB348.eurprd07.prod.outlook.com (10.141.234.148) by DB4PR07MB347.eurprd07.prod.outlook.com (10.141.234.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1143.6; Mon, 5 Jun 2017 07:55:04 +0000 Received: from DB4PR07MB348.eurprd07.prod.outlook.com ([fe80::4826:37de:a243:ea2f]) by DB4PR07MB348.eurprd07.prod.outlook.com ([fe80::4826:37de:a243:ea2f%17]) with mapi id 15.01.1143.018; Mon, 5 Jun 2017 07:55:04 +0000 From: Ingemar Johansson S To: "tcpm@ietf.org" Thread-Topic: ??: How about data packets and ACKs go through different paths? Thread-Index: AdLdz7vckLuaL76hTgenuAOwZvCqfQ== Date: Mon, 5 Jun 2017 07:55:04 +0000 Message-ID: Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [192.176.1.84] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DB4PR07MB347; 7:hzHnwLWVLJ8T+xemLRHBxFbY1yE2CC+SMfn/aMB9xxZPV1EVz/N49jB8sLEdpuCLHQI2D8PxN7oAaSojgcqAF+CnaArLCo0scx7wYklB4UWdEorXQh9GErJ/w5WOIl5y163zU45WsTitor510zn/pxAU4lF9FHh42/trrslZIdf785oHbjj5MglRC6o6Xw5MqYMYJ/hHrQjYq2+eF6p1KvNV+FIGHCItZJnvLptAXf/M6dg5Ox75U7n7yKf0ZVpoTPdqL4Pp+EnWy8RsnLuuzUYeXmSIdv0/Gv2y7faMK9Vh4ZOTxRqwoJ2Q2WRxJHnMTrzJeUkapmEoxJBQYfpj7g== x-ms-traffictypediagnostic: DB4PR07MB347: x-ms-office365-filtering-correlation-id: 295b21ad-a4eb-4a67-85e4-08d4abe82d1e x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081); SRVR:DB4PR07MB347; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(50582790962513); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(5005006)(8121501046)(93006095)(93001095)(100000703101)(100105400095)(10201501046)(3002001)(6041248)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123562025)(20161123558100)(20161123560025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DB4PR07MB347; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DB4PR07MB347; x-forefront-prvs: 0329B15C8A x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39450400003)(39840400002)(39850400002)(39400400002)(39410400002)(24454002)(377454003)(25786009)(53546009)(102836003)(5660300001)(229853002)(189998001)(5250100002)(5890100001)(6116002)(53936002)(2501003)(74316002)(2351001)(6436002)(55016002)(54356999)(6916009)(2906002)(8936002)(8676002)(478600001)(50986999)(5640700003)(3280700002)(33656002)(2900100001)(99286003)(966005)(7736002)(14454004)(1730700003)(8666007)(7696004)(81166006)(305945005)(6306002)(4326008)(110136004)(66066001)(3846002)(9686003)(38730400002)(3660700001)(86362001)(512874002)(345774005)(6506006); DIR:OUT; SFP:1101; SCL:1; SRVR:DB4PR07MB347; H:DB4PR07MB348.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Jun 2017 07:55:04.2257 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB4PR07MB347 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02Se0hTURzHObv3zrvR4jQ1f5iGLCN8pGkaIipGFkNUoigfEDX0oiudsrs0 g2AuwXKIQo5QclMxa1pBWrpwmY5BmWgv36QWSj7WwleaFpruLui/z+98v78v53s4NCGupjxp uULFKBWybAlfSFaltEsPG3aHpx7RaIQRTxtG+BFvV6mIth4DL2K5/haKJaVbDytcpMVWOyVt aFjnST/YhonTZJowKoPJluczyuCYS8IsU/0cL2/d/Zq17StfjTb3lCIBDTgMvjeNoFIkpMXY iqBovpXihtcI7t+rdygkLiPgyYTRhVN0PLD1r/O44QuCaX0V2gnj4ygwWtYc7IYPQPPkgmOd wOUIuvtKiB3BFSdCf8cbpykJtHVzJMdBMFjU6rLDJPaF4RczDr8Ip8FNrZ3aYYS9YXJtwuEn sAeMTRt4XAsMDeZ3BMfuMDe16SiBsBbBgn7IafKBea2az7E3fDRoHbcDrCVgpOc5yQl+oJ0w OTkRBpfN2wv0Nt8ATWM0dyyH8ooyZ04kPC42U1xOFwW9db0UJ3hB/U8r4niKgtX2Q1x7Txgf uI049oLZzy+pCuRX/V8hjgOhtmOJz3EANNbZiGrHY+yBnqppshaRTcidZVg2JzM0NIhRytNZ NlcRpGBULWj7x3Q/+x1pQt0zxy0I00iyS7TBD08VU7J8tjDHgoAmJG4idjgsVSzKkBVeZ5S5 F5VXsxnWgvbRpMRDFNv5PkWMM2Uq5grD5DHKfyqPFniqUXr7VkBBb3CHmj3X9ePVtxNCe1zC o6OjcV1DU2d/Na8YD8Zo+pJPSkmfNa9FVVukUmT8U5bgKsAhel0Nc8e0P/7TuN50Pvxyi8Cg 20yamC/xl8TbAmvkgkq6IH9g9IyL2deysbJEXOhk4ppnc+3H7ur2RpvLKpNXxhYjHxhOSUg2 SxbiTyhZ2V8vNZ3yLQMAAA== Archived-At: Subject: Re: [tcpm] ??: How about data packets and ACKs go through different paths? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jun 2017 07:56:21 -0000 Hi LEDBAT (rfc6817) is one example that estimated one way queue delay based on= ACK timestamps, SCReAM (https://tools.ietf.org/wg/rmcat/draft-ietf-rmcat-s= cream-cc/ ) for real time media is another example , yet another example su= ggest a slight modification to Cubic (https://tools.ietf.org/html/draft-joh= ansson-cc-for-4g-5g-02 ) The positive thing is that there is less impact from congestion in the ACK = return path.=20 There are however some less good properties.=20 1) Late comers advantage 2) The timestamp clock in the remote end must be known #2 above may be solved for Linux clients/servers, I recall that support for= 1000Hz time base for timestamps is being added ? /Ingemar > Date: Thu, 1 Jun 2017 22:12:02 -0700 > From: Yoshifumi Nishida > To: "zhangyali (D)" > Cc: Richard Scheffenegger , "tcpm@ietf.org" > > Subject: Re: [tcpm] ??: How about data packets and ACKs go through > different paths? > Message-ID: > Wv+TxA@mail.gmail.com> > Content-Type: text/plain; charset=3D"utf-8" >=20 > On Thu, Jun 1, 2017 at 6:49 PM, zhangyali (D) > wrote: >=20 > > Hi Richard, > > > > > > > > Thank you for your prompt reply. > > > > > > > > Indeed, sender should decelerate to ease congestion if it finds ACK > > packet has been dropped. But that relate to how to achieve a high > > utilization of network resource. A simple think is that network > > utilization will be lower if sender do not differ the congestion > > degree between data packet path and ack packet path. > > > > > > > > Another question is that some congestion control mechanism take use of > > delay measured by ACK timestamps to denote congestion degree. If data > > packets and their ACK packets go through different ways, the > > measurement of delay may confuse reverse path congestion experienced > > by ACKs with forward path congestion experienced by data packets. I > > think Vegas, a delay-based congestion control mechanism, will experienc= e > this problem. > > >=20 > Right, I think you'll need to measure one-way delay, which vegas doesn't. > -- > Yoshi > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > 97e40/attachment.html> >=20 > ------------------------------ >=20 > Subject: Digest Footer >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm >=20 >=20 > ------------------------------ >=20 > End of tcpm Digest, Vol 158, Issue 2 > ************************************ From nobody Thu Jun 8 08:02:57 2017 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 F136312EB1B for ; Wed, 7 Jun 2017 02:03:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RZysabJr7xwR for ; Wed, 7 Jun 2017 02:03:40 -0700 (PDT) Received: from mail-qk0-x232.google.com (mail-qk0-x232.google.com [IPv6:2607:f8b0:400d:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 262B412EB2C for ; Wed, 7 Jun 2017 02:03:24 -0700 (PDT) Received: by mail-qk0-x232.google.com with SMTP id r62so3430633qkf.0 for ; Wed, 07 Jun 2017 02:03:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=ETUwzG80gc/ioIR6qL3bVjPuelKgkmfxix4r1RBtUGM=; b=ea/lJkmnq1kmEd/4RmNTxHHQqkg0OLcnqC5v0/3Tsv1Xd3CrEj+c5jTCYJuglhSUF5 3fWoOkQ+ijQ4vrhMyir3b/d9rcFz1NKlvkYiD/UuSLoAMGKFLZlYnILVkNINbrEePwnd fdjwc3myW8Cs+Jgi6L1cUseMLG6E4z5ak6+idl+uYa6qBfqVyfOdWG4/T+gudOSrdva0 iyF6Y6dPc7adDBWgiMF/imgHYNw/DFNa+09HMJ1Qg1nI0ZFyyZ+9JSchIh35PfSw882Z t56JJJRa4nxiLEIMqhwH/1tvw0dzu3TabS3TlA9TkmoHOpznfAtyqdkCH62WQnMXwqYq iscQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=ETUwzG80gc/ioIR6qL3bVjPuelKgkmfxix4r1RBtUGM=; b=YA5pjZrb48BPy5DQqaHKuMYO04ttpxKDT9Z4VRwsPQuJqZYjN8/CEx6qOWocIoK2aE PjWw86RMcalqyyuKa9o9eydRwWoC2LJ2tizsW5eVZf2EuzcIwDXJyYHve46hvFj7wB9w dDtv9wExsc7JJA+9unwksnpu3XssiaONAVjT4gLGA6tBjncM2L82bQKoso3YzSOE6eOy /VU07hM00AeqD3WHTNpUu8hqhpjtrAggDkJWqcN0QFXFYuOU6HTv1jC2MaNYI4zaH73B CcNzXBb0/EDxLEwqRUgzTPVw9MdXUmpyyx7bk80NE9ICoipHys1p4dhwX/QF8ghDrJfC nICQ== X-Gm-Message-State: AKS2vOys1/xMs8d4IIwUC9I4WReI5AnnVjPhHuCx/w7ys1OGfr6rN8UD H74hOPxgM6Oq4/55xr8RFUWmcxc+vLe2 X-Received: by 10.55.212.3 with SMTP id l3mr25308703qki.112.1496826203084; Wed, 07 Jun 2017 02:03:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.97.66 with HTTP; Wed, 7 Jun 2017 02:03:22 -0700 (PDT) From: Amritbir Singh Date: Wed, 7 Jun 2017 14:33:22 +0530 Message-ID: To: tcpm@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: X-Mailman-Approved-At: Thu, 08 Jun 2017 08:02:57 -0700 Subject: [tcpm] Help X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2017 09:03:43 -0000 Respected Sir, Kindly provide me RFC for TCP variants Tahoe,Reno,New Reno,Sack.I urgently required for my research.I search it but not found.Kindly help me. From nobody Thu Jun 8 08:08:38 2017 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 C1573128768 for ; Thu, 8 Jun 2017 08:08:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q5S0etv_Ddd7 for ; Thu, 8 Jun 2017 08:08:34 -0700 (PDT) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0098.outbound.protection.outlook.com [104.47.0.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F014128616 for ; Thu, 8 Jun 2017 08:08:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=nfYmk1VwajrBmrTQbY+F8DuKc10/BpwrDBBZC3BMZHo=; b=Jh0x8po1FQSJOBXqDs1Nzf0Am/qBCTtRc4P6bvX6GAv1JSsIIMItFx3/XPaP/wyKSDsUIDy+45y14MCP77MCi4fQc6cLvHhEp8nPP1GiUD3RV5TnJFrBRxioqWtdg5p3iZ1k4RhO5QeQdIaHaObapxJSMwJlsXENliLfoK89dg4= Received: from AM5PR0701MB2547.eurprd07.prod.outlook.com (10.173.92.15) by AM5PR0701MB2850.eurprd07.prod.outlook.com (10.168.155.141) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1143.1; Thu, 8 Jun 2017 15:08:31 +0000 Received: from AM5PR0701MB2547.eurprd07.prod.outlook.com ([fe80::1143:f4ba:ef68:5da9]) by AM5PR0701MB2547.eurprd07.prod.outlook.com ([fe80::1143:f4ba:ef68:5da9%18]) with mapi id 15.01.1157.010; Thu, 8 Jun 2017 15:08:31 +0000 From: "Scharf, Michael (Nokia - DE/Stuttgart)" To: Amritbir Singh , "tcpm@ietf.org" Thread-Topic: [tcpm] Help Thread-Index: AQHS4GhUBEWSNUw3AEaqMTa5zeAvyKIbECNw Date: Thu, 8 Jun 2017 15:08:31 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=nokia.com; x-originating-ip: [135.245.212.24] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM5PR0701MB2850; 7:SpGZMHJ8iBA0cvO2sQawSkGZxJQBnPo+AU/keWW4HA+p7XS3SWdeevT3jvGnqG8p9vHWbR6iYVauP+1mLhD+ubwqkuxKByYz5xFrkan22ZI5wo2RCL/mjPjGZr6FtfZWOdHf/APVeX+HWcwebFh7z/b9tloYVmN3A1+cX0+8GMi0ayo+U/B03Wr8G4/+Zs65DGGZi/BQ2zgNTxrqajXmswWLLaRRdSPshVw0iOCOkzA0Yv+0pRIqlcqwjc0hYcQKSpdNYPFDcGpztwKyUqu3eMmkjG51+kTt5L1YuCaVWoaU5RveqnnQicTUdi9iVVi8EnHjuk56r5eVKNexPS0x/Q== x-ms-traffictypediagnostic: AM5PR0701MB2850: x-ms-office365-filtering-correlation-id: 78ffc3a9-436c-4028-3262-08d4ae80399e x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081)(201702281549075); SRVR:AM5PR0701MB2850; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(93006095)(93001095)(100000703101)(100105400095)(3002001)(10201501046)(6055026)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123555025)(20161123562025)(20161123564025)(20161123558100)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM5PR0701MB2850; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM5PR0701MB2850; x-forefront-prvs: 0332AACBC3 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(979002)(6009001)(39850400002)(39400400002)(39410400002)(39860400002)(39840400002)(39450400003)(377454003)(13464003)(6306002)(55016002)(9686003)(99286003)(39060400002)(53546009)(6506006)(6436002)(25786009)(53936002)(5250100002)(6246003)(66066001)(14454004)(189998001)(86362001)(38730400002)(3660700001)(3280700002)(5660300001)(478600001)(54356999)(74316002)(7736002)(305945005)(50986999)(229853002)(76176999)(8936002)(966005)(2501003)(2906002)(81166006)(2950100002)(8676002)(6116002)(7696004)(2900100001)(3846002)(102836003)(33656002)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:AM5PR0701MB2850; H:AM5PR0701MB2547.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Jun 2017 15:08:31.1017 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0701MB2850 Archived-At: Subject: Re: [tcpm] Help X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jun 2017 15:08:37 -0000 Hi Amritbir, A comprehensive overview of the TCP RFCs with the references can be found i= n: https://tools.ietf.org/html/rfc7414 Note that "Tahoe" is pretty far away from what modern TCP stacks implement.= Most TCP stacks support SACK these days. For TCP research, it usually help= s to look into real protocol stacks. Thanks Michael > -----Original Message----- > From: tcpm [mailto:tcpm-bounces@ietf.org] On Behalf Of Amritbir Singh > Sent: Wednesday, June 07, 2017 11:03 AM > To: tcpm@ietf.org > Subject: [tcpm] Help >=20 > Respected Sir, > Kindly provide me RFC for TCP variants Tahoe,Reno,New Reno,Sack.I > urgently required for my research.I search it but not found.Kindly help m= e. >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Thu Jun 8 08:53:55 2017 Return-Path: X-Original-To: tcpm@ietf.org Delivered-To: tcpm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E78E8129473; Thu, 8 Jun 2017 08:53:37 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Joe Clarke To: Cc: draft-ietf-tcpm-dctcp.all@ietf.org, tcpm@ietf.org, ietf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.54.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149693721791.15103.13571928856211954021@ietfa.amsl.com> Date: Thu, 08 Jun 2017 08:53:37 -0700 Archived-At: Subject: [tcpm] Opsdir last call review of draft-ietf-tcpm-dctcp-07 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jun 2017 15:53:38 -0000 Reviewer: Joe Clarke Review result: Has Nits Hello, WG and authors. I have reviewed rev -07 of the draft-ietf-tcpm-dctcp as requested by the OPS-DIR. This review focuses on improving operational aspects as well as any nits found in the text. This document is an informational draft that describes Data Center TCP (DCTCP), a congestion control mechanism for TCP in Data Center environments. Overall, I believe this document to be ready, with some nits and perhaps small areas for improved clarity and readability. First, I'd like to say that I appreciate the fact that this has been implemented on a number of kernels, and the authors included real-world implementation results and thoughts. From an operational perspective, that is very helpful. I also appreciated the fact that there are interoperability challenges, and those were called out in the document. My specific comments are below. There are a lot of abbreviations, variables and other terminology used throughout this document. It might be helpful for the reader to have an expanded terminology section at the top that one can refer to for all of these things. Some of the abbreviations are called out in the description of the algorithm, but not all (e.g., DCTCP.Alpha, CWR, RTT, etc.). === Section 3.2: You refer to DCTCP.Alpha before defining it. While you refer to Section 3.3 here, the impact of an incorrect Alpha value is not fully appreciated in this text. Perhaps this could be changed to reflect the impact the incorrect Alpha value would have? === Section 3.2: My abbreviating DCTCP.CE as CE in your state machine diagram, it is a bit confusing as to the difference between CE and DCTCP.CE. The description of the state machine above requires the CE codepoint to have a certain value in order for DCTCP.CE to change. Perhaps you can use D.CE as an abbreviation to be a bit clearer here. === Section 3.3: It is not clear if 'g' can be inclusive of 0 and 1. === Section 3.3: You define DCTCP.WindowEnd as the threshold for beginning a new observation window, but maybe to complement the state variable name, you should define it as the following: The TCP sequence number threshold when one observation window ends and other is to begin; initialized to SND.UNA. === Section 3.3: You state: Thus, when no bytes sent experienced congestion, DCTCP.Alpha equals zero, and cwnd is left unchanged But if I use a value of 1/16 for g, with DCTCP.Alpha initialized to 1 as you say, I get a value of DCTCP.Alpha == 15/16 when there is no congestion (i.e., M == 0). === Section 3.5: You have an extra space here before the comma: If SYN , SYN-ACK and RST packets for DCTCP connections have ECT set This should be: If SYN, SYN-ACK and RST packets for DCTCP connections have ECT set === Section 3.5: You do not define ECT before using it. === Section 4.1: Can you provide a reference for NewReno? === Section 5: Can you reference or define AQM and RED? From nobody Thu Jun 8 13:56:44 2017 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 A280B129484 for ; Thu, 8 Jun 2017 13:56:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4syQQrit9Tum for ; Thu, 8 Jun 2017 13:56:37 -0700 (PDT) Received: from mail-vk0-x233.google.com (mail-vk0-x233.google.com [IPv6:2607:f8b0:400c:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CDA1A127876 for ; Thu, 8 Jun 2017 13:56:34 -0700 (PDT) Received: by mail-vk0-x233.google.com with SMTP id 191so21605702vko.2 for ; Thu, 08 Jun 2017 13:56:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=LOMO1IIVl8yVb/pVNVwrvGQOQTLpD+LrmINW7OLoqfE=; b=r89c+gmpNFPlz5RJhxrZLsRGZ3rt4ijdFtMF4tWn++nUdLKyTT63/j1fAu9nuilsJk exvJ38LpjEPgj5dyEk77sjgPe8EzILq6vdl1kc0L75e6tSm9rQ4vF4eyCY3Bf/A1l7Yr isagK83Lie3JlwJXR8HIcHGntWGQqFfKnnnxA+xKpdzc5IHhaKE52IR0zQ8n0wrThK1A Lh0//Frjwt/vJwTZvdO1uIMMpfzZKnq5Jq9eF8Y9ZhuCX85hmqs5I5yWVPSq4QzGKBHj LyZuTL38Y68qJAqWUNOklDxPANE4JMBnsqbGlvKKb9SEXXPPJbYZ+s6FfwEJqPef5wDA bK+Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=LOMO1IIVl8yVb/pVNVwrvGQOQTLpD+LrmINW7OLoqfE=; b=BVlS4uOLTUrPuX/VGh8DyuoVH1IQRoeNP5fwUPlSSN63YyOO8HfnhE1knZttfBTIsX 6/40Foh6vBHQaBL3VNRIE0P/+jgByTX77JCkSOE0/7Lp3/WE9PeKhpUmakxpSZrL/lkC Y0WSgHhmyI0CtbeVKwfC7EjwaJgiIP9N5nK5V5qhQpig8A0l4RJetkKe/aV1tRzY8L/2 OahIUc+xdGokcmEaem6aiOt3+wq8SjNDwCx57+mMHDZ6+mAqGLkJuZR8Ol3y/aMoxeIR rWeOWAH5XPJ2J5kXir6Tnvj8711WwFGVKvEPKeRhjMa3HtgS0xE7T6WPls01oGEDP4ev /KdA== X-Gm-Message-State: AODbwcAGm/Pa4QvbsscgEOz57nzZmqOIWUSCgDaWFMOzeYUoCgTNWL1B Z+s2tagwExcVU6RB7RYeY5fMoERb5WtT X-Received: by 10.31.96.150 with SMTP id u144mr12017937vkb.124.1496955393771; Thu, 08 Jun 2017 13:56:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.82.198 with HTTP; Thu, 8 Jun 2017 13:55:53 -0700 (PDT) In-Reply-To: <149693721791.15103.13571928856211954021@ietfa.amsl.com> References: <149693721791.15103.13571928856211954021@ietfa.amsl.com> From: Warren Kumari Date: Thu, 8 Jun 2017 16:55:53 -0400 Message-ID: To: Joe Clarke Cc: ops-dir@ietf.org, draft-ietf-tcpm-dctcp.all@ietf.org, tcpm@ietf.org, IETF Discuss Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [tcpm] [OPS-DIR] Opsdir last call review of draft-ietf-tcpm-dctcp-07 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jun 2017 20:56:40 -0000 On Thu, Jun 8, 2017 at 11:53 AM, Joe Clarke wrote: > Reviewer: Joe Clarke > Review result: Has Nits > > Hello, WG and authors. I have reviewed rev -07 of the draft-ietf-tcpm-dctcp as > requested by the OPS-DIR. This review focuses on improving operational aspects > as well as any nits found in the text. ... and I'd quickly like to thank Joe for his review. Fixing issues like this make the documents progress through the IESG with much less drama... W > > This document is an informational draft that describes Data Center TCP (DCTCP), > a congestion control mechanism for TCP in Data Center environments. > > Overall, I believe this document to be ready, with some nits and perhaps small > areas for improved clarity and readability. First, I'd like to say that I > appreciate the fact that this has been implemented on a number of kernels, and > the authors included real-world implementation results and thoughts. From an > operational perspective, that is very helpful. I also appreciated the fact > that there are interoperability challenges, and those were called out in the > document. My specific comments are below. > > There are a lot of abbreviations, variables and other terminology used > throughout this document. It might be helpful for the reader to have an > expanded terminology section at the top that one can refer to for all of these > things. Some of the abbreviations are called out in the description of the > algorithm, but not all (e.g., DCTCP.Alpha, CWR, RTT, etc.). > > === > > Section 3.2: > > You refer to DCTCP.Alpha before defining it. While you refer to Section 3.3 > here, the impact of an incorrect Alpha value is not fully appreciated in this > text. Perhaps this could be changed to reflect the impact the incorrect Alpha > value would have? > > === > > Section 3.2: > > My abbreviating DCTCP.CE as CE in your state machine diagram, it is a bit > confusing as to the difference between CE and DCTCP.CE. The description of the > state machine above requires the CE codepoint to have a certain value in order > for DCTCP.CE to change. Perhaps you can use D.CE as an abbreviation to be a > bit clearer here. > > === > > Section 3.3: > > It is not clear if 'g' can be inclusive of 0 and 1. > > === > > Section 3.3: > > You define DCTCP.WindowEnd as the threshold for beginning a new observation > window, but maybe to complement the state variable name, you should define it > as the following: > > The TCP sequence number threshold when one observation window ends and other is > to begin; initialized to SND.UNA. > > === > > Section 3.3: > > You state: > > Thus, when no bytes sent experienced congestion, DCTCP.Alpha equals > zero, and cwnd is left unchanged > > But if I use a value of 1/16 for g, with DCTCP.Alpha initialized to 1 as you > say, I get a value of DCTCP.Alpha == 15/16 when there is no congestion (i.e., M > == 0). > > === > > Section 3.5: > > You have an extra space here before the comma: > > If SYN , SYN-ACK and RST packets for DCTCP connections have ECT set > > This should be: > > If SYN, SYN-ACK and RST packets for DCTCP connections have ECT set > > === > > Section 3.5: > > You do not define ECT before using it. > > === > > Section 4.1: > > Can you provide a reference for NewReno? > > === > > Section 5: > > Can you reference or define AQM and RED? > > > _______________________________________________ > OPS-DIR mailing list > OPS-DIR@ietf.org > https://www.ietf.org/mailman/listinfo/ops-dir -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf From nobody Fri Jun 9 08:02:40 2017 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 933A412949F for ; Thu, 8 Jun 2017 21:57:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7C-ytbayciB2 for ; Thu, 8 Jun 2017 21:57:48 -0700 (PDT) Received: from mail-qt0-x236.google.com (mail-qt0-x236.google.com [IPv6:2607:f8b0:400d:c0d::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA8F5128B8E for ; Thu, 8 Jun 2017 21:57:47 -0700 (PDT) Received: by mail-qt0-x236.google.com with SMTP id u12so64444448qth.0 for ; Thu, 08 Jun 2017 21:57:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=pZiHPDcPDAlFiSYq1Fkh5zNdwGkhr5Rht+OOx9ewaDw=; b=iQF0g440Dpdorp8pZxmUTc+MMxIq9fTZ0ZIv8x8dYemMGwki9ysgu0e5jTe0f9d2fW UfLdTXI3h+kGyGc7K1KJRa+oXzKLS5FSQaHhvsQ/7uhm6uBM6IJ1v/saUNeiVmKgrCEq AeV7Nb2hAv4PON47AGOb8p9XyL7EYzBauZZSRgw0FiySKQqtGOg6O7fwEHuoMHfG3/ps FW+Ti66Qbv733IF008tc6h6isKzzBZNYd0FO5V8KdQLSD83RLYyKcw7tlcCCZtjS6RT3 jbXSeGfI9GdyXsCcRCd9uovUokYUWKtncnLWrai49LnTT3Ug/1pFsnQleVdn5LHmOGUN xaww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=pZiHPDcPDAlFiSYq1Fkh5zNdwGkhr5Rht+OOx9ewaDw=; b=RsJxP3e9SB9sz1Wfa4x1hE6lHM8/YkHgR1Fa+RZA3jGhwzFA6KiMTnpmZSWfJIS/cX vCWfxq+UwtnnlWkeaiXRWXNMbW2Chso04SRxjPWHPsOmdS/1VGdlAhc3UGNGC01WNoQE 6vMMZZL2qVQty9MuOet5btSnX+pQ+/JaUjj6R2mg8PfK2CwnVLhKIN8JP3Bm7e55DEuC 8FDK+xgT9x/6NCmL1mtI/A2U6RmT36WPLXFNzUk39nk38yHHBc16B6AJ7+VYFrqHGzZb 9Nn1FQJIldV1V6aHE96DytzvmG2ylj6IRk3sVO8HjXLPLXW7lwdGvx5KskE12EPbLRLl NGZw== X-Gm-Message-State: AODbwcCtp8fYFqfnC41X9Kc7MD1m3OTdCW6BtuITUmRnlY2vk9MzgrT3 GeA7DmQOeDEk7dSHPNwiJNZVlP1g9A== X-Received: by 10.237.38.37 with SMTP id z34mr16679640qtc.225.1496984267050; Thu, 08 Jun 2017 21:57:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.97.66 with HTTP; Thu, 8 Jun 2017 21:57:46 -0700 (PDT) In-Reply-To: References: From: Amritbir Singh Date: Fri, 9 Jun 2017 10:27:46 +0530 Message-ID: To: "Scharf, Michael (Nokia - DE/Stuttgart)" Cc: tcpm Content-Type: text/plain; charset="UTF-8" Archived-At: X-Mailman-Approved-At: Fri, 09 Jun 2017 08:02:36 -0700 Subject: Re: [tcpm] Help X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jun 2017 04:57:50 -0000 Respected Sir, I am not found RFC for TCP variants Tahoe,Reno,New Reno,Sack in your link provided to me by email.Kindly help me I need it urgently for my research.My research based on it. From nobody Mon Jun 12 15:07:23 2017 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 27EF112EB58; Mon, 12 Jun 2017 15:07:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.702 X-Spam-Level: X-Spam-Status: No, score=-4.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OeBFgFme2SbW; Mon, 12 Jun 2017 15:07:20 -0700 (PDT) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0112.outbound.protection.outlook.com [104.47.0.112]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38A6D129420; Mon, 12 Jun 2017 15:07:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=ikFMugICy3gxzvAIhnABN7mwv3yhiLc5uNRbJDbWpLo=; b=rMsCpMoUNLe28Y/pnX+356xByPDxc5Rt4e4tmLa+xloCy/wKBE11+o94q9BdEMoW6eG1sGiDZTLaRXx9gwvZ89ivaRfC0DGowzl+/yFTe9yq1Pyt55jecyV6wFevzdAx4xpHtte1FGzvoqDwNbJm/eEPdiLH8eCTCDls4RjhrO4= Received: from AM5PR0701MB2547.eurprd07.prod.outlook.com (10.173.92.15) by AM5PR0701MB1844.eurprd07.prod.outlook.com (10.167.216.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1178.10; Mon, 12 Jun 2017 22:07:17 +0000 Received: from AM5PR0701MB2547.eurprd07.prod.outlook.com ([fe80::246b:3303:57f6:26a]) by AM5PR0701MB2547.eurprd07.prod.outlook.com ([fe80::246b:3303:57f6:26a%18]) with mapi id 15.01.1178.008; Mon, 12 Jun 2017 22:07:17 +0000 From: "Scharf, Michael (Nokia - DE/Stuttgart)" To: "tcpm@ietf.org" CC: "tcpm-chairs@ietf.org" Thread-Topic: Working group acceptance call for draft-touch-tcpm-2140bis Thread-Index: AQHS48M0ISVhrXZ5kEa3orYvVjUz6w== Date: Mon, 12 Jun 2017 22:07:17 +0000 Message-ID: Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=nokia.com; x-originating-ip: [2a01:111:e400:5365:cafe::f4] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM5PR0701MB1844; 7:oh/wLLcPkWCal8ptIkwK/S2JTwgm/VxLCW7ko3uJTYTFcrBR6wT9Z2IDVm7slpHniLBqoftdfXZP4SCNDTovGGY1DTaNPPVo/p+Wmw3prhGfJdiM+/YRJctd/Z0T+OONRP4BMzbMlv4vSWkEuhNVVwbA/3YAfmTuAdTYU/YRtSGYKMNn6WQWoi0mB/wYd6vFiZy+i29f2w+l2+9mrftxqo7CqKR65ucBIXOtfzgUe7HUta2t+W1NXBBCP0AzLWoo6J+mcqVo6SZABT17Wx4Zfw/WONPn3D+SnUujfthm/vDxvE9jOu3xb+4xHHlBcwNstcV1vGdvZCYgReWPs2deaTfFeYZWMWUBQCLxYFpdOa67RkDgLBoAXRK+35kEobNideDUuvUVtSPvoPZuxDiEeB1rdF5aA1cEtQC6Y+2RZt9H5ApaN0a9aGfL/usaTRtnHyQiPXtx3KJuDgq9Gq04t6LaMOz4gOIU+pOM1Tza1mgDkvN+KSO0+mO4O43fxHV9+mgl1JkNM2rKX1PNodgPS+aNOKein529IceulFhkPQM8h4V/jg7/tP2TVaWtCihIxWXx56IIZISbe8bNwJ6KjI5z9h+Nquich3o420VKqyad0qYLtfZt/vpqbepYDh5lr/OaPWrVctdNe7Tb9dB7hlM2/HRZ7QjWPn/N04gd7LzNW7eiaUZqFvDrJDGFPcv6CM1nHdmIQ1RhAzB93XhPKSDLlrPTZpGCiu4r1/zTJldxIExiWItsnwd4s7PTNX+HYIHVUuhALHXYB/wpMpAbnNXOKYp6hKXfIjOlOkGNVE0= x-ms-office365-filtering-correlation-id: 7c62e94c-4d14-4759-1367-08d4b1df63f2 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081); SRVR:AM5PR0701MB1844; x-ms-traffictypediagnostic: AM5PR0701MB1844: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(100405760836317); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(93006095)(93001095)(10201501046)(100000703101)(100105400095)(3002001)(6055026)(6041248)(20161123560025)(20161123555025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123562025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM5PR0701MB1844; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM5PR0701MB1844; x-forefront-prvs: 03361FCC43 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39450400003)(39400400002)(39840400002)(39860400002)(39850400002)(39410400002)(53754006)(33656002)(5660300001)(230783001)(478600001)(99286003)(2351001)(55016002)(4326008)(6916009)(81166006)(2906002)(3280700002)(1730700003)(2900100001)(3660700001)(102836003)(8676002)(7736002)(9686003)(6436002)(305945005)(53936002)(7696004)(86362001)(14454004)(561944003)(74316002)(25786009)(8936002)(38730400002)(110136004)(5640700003)(450100002)(54356999)(50986999)(6506006)(2501003)(5250100002)(189998001); DIR:OUT; SFP:1102; SCL:1; SRVR:AM5PR0701MB1844; H:AM5PR0701MB2547.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Jun 2017 22:07:17.7308 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0701MB1844 Archived-At: Subject: [tcpm] Working group acceptance call for draft-touch-tcpm-2140bis X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jun 2017 22:07:22 -0000 Hi all, As requested by the authors, this e-mail starts a working group acceptance = call for draft-touch-tcpm-2140bis-02, which will run on the list until June= 30. The proposal is to add a new milestone to the TCPM charter and to use draf= t-touch-tcpm-2140bis as a starting point.=20 More specifically, the TCPM chairs look for community feedback on the targe= t status. Two options for a charter milestone would be: (1) "Submit document on TCP Control Block Interdependence to the IESG for p= ublication as Informational RFC" or (2) "Submit document on TCP Control Block Interdependence to the IESG for p= ublication as either Informational RFC or BCP; the status will be decided b= y working group consensus prior to the WGLC" Note that RFC 2140 is informational. Feedback on the charter wording would = be highly welcome. It is understood that the document content requires significant further wor= k and discussion in TCPM. The purpose of this adoption call is to check whe= ther there is sufficient interest to discuss and further improve the docume= nt under change control of the TCPM working group.=20 If you believe that TCPM should work on a document in this space, and in pa= rticular if you are willing to review it, please reply to this e-mails. Ple= ase also speak up if you have any concerns or objections. Thanks Michael TCPM cat herder= From nobody Thu Jun 15 23:07:59 2017 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 8022D129405; Thu, 15 Jun 2017 23:07:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.701 X-Spam-Level: X-Spam-Status: No, score=-4.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QK5moGPrGQNz; Thu, 15 Jun 2017 23:07:54 -0700 (PDT) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0112.outbound.protection.outlook.com [104.47.2.112]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B3D9128CFF; Thu, 15 Jun 2017 23:07:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=NP6QlCIbChaL3fkugO1CpbiPnhCOqCLdihY/FuFXV5E=; b=PUVktxeMppWE/kB9aTF04vQjII5ABjdbng591P/Olx+LtBOiDc8yaN2ZHR1jWXB6TRhMG5mGD+opRaMsQ2osII3o75B6QKR9rZOSydxh/iyRtWCn2lSTKDY0NaDBAJ2iD1peCOg00jaoEfCzqCYvWzIe2xpqE/YgIx3DZHACmM4= Received: from AM5PR0701MB2547.eurprd07.prod.outlook.com (10.173.92.15) by AM5PR0701MB2660.eurprd07.prod.outlook.com (10.173.93.10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1143.6; Fri, 16 Jun 2017 06:07:51 +0000 Received: from AM5PR0701MB2547.eurprd07.prod.outlook.com ([fe80::246b:3303:57f6:26a]) by AM5PR0701MB2547.eurprd07.prod.outlook.com ([fe80::246b:3303:57f6:26a%18]) with mapi id 15.01.1178.018; Fri, 16 Jun 2017 06:06:43 +0000 From: "Scharf, Michael (Nokia - DE/Stuttgart)" To: "tcpm@ietf.org" CC: "tcpm-chairs@ietf.org" Thread-Topic: Working group acceptance call draft-bagnulo-tcpm-generalized-ecn-04 Thread-Index: AdLmZeQ+oR9BQwLNQFmQZTzsHuSPOg== Date: Fri, 16 Jun 2017 06:06:43 +0000 Message-ID: Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=nokia.com; x-originating-ip: [92.203.220.7] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM5PR0701MB2660; 7:rnlff7MO2tEePygrScOhIsbcR/QuhZJCaN4Xc4zzKov3z9fli7UatPvxyGZOQ/LfL8XMXIk6V0KdLGKo4RGz74YrgMe/cXbNMr1HLhHpfcHZHeJ4CKv7FnZ1AsrNdoAoh2yhhgxF2xF6Zhh2B/DStS6gvKOYx5hg41fuchhplp970lr2CVBczNLdvhExx+wS8GzHp6YwuHoYos0rxnnYI9xInif1hT5QfPzpZO+MKKH1dQejPf7RJHWl+TGpvSPQNImjvr2e7ejEh1xp301Q9WUIcl0JgS8VvPVonnmTvYeq26zEb9Gw5D80s05BVjee9hds7PkMzZT/ygDerdQUmpUg3/G6aMsOHxKxD5c5XxPEaICFNhbZO/m/10fMTX4jHd63deooiY0S5UqWCrQHQGeUhFfTeM4HOvNZTgVtUoq+UJ13ecCsVkGQWpPJ2kO0KIOSPh4GgFuc4rFkM5n4aw3Y47z3gpPTxeOJg1pP8dWc806biQvKQfyHeBtVoMQlZdPqAiEOaGqsoEIvzYWSXCpMqBvMllEtFV7R/ELpyKiQ1jDBwdrlGN2bzqIE+g/ZhhhUiviSVsveLNatyNHHhJmB5kdFZ1p8wS1pIlNtNR9rJvA+wzOvrBys0JMaOwhy5/zeqOo+BR1ZxL6cH7fOc++akuNlTM10pi/gYsNyETTSfxEQTRnOPb7W2L7NyZKFRiTsHovOfnUn0Wnyn7CS+44CTM/beeqpZxyx2eQBbptonpQGlGP4wPx8iqJDSvDTzj4NeEvKQ9ming8ucAoie/hMGBW8XItKpZV6gK+Qnwo= x-ms-traffictypediagnostic: AM5PR0701MB2660: x-ms-office365-filtering-correlation-id: 109e8f9f-2e4f-4541-8b85-08d4b47ddcb8 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500041)(300135000095)(300000501041)(300135300095)(22001)(300000502041)(300135100095)(2017030254075)(48565401081)(300000503041)(300135400095)(201703131423075)(201703031133081)(201702281549075)(300000504041)(300135200095)(300000505041)(300135600095)(300000506037)(300135500095); SRVR:AM5PR0701MB2660; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(93006095)(93001095)(3002001)(100000703101)(100105400095)(10201501046)(6055026)(6041248)(20161123562025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123564025)(20161123555025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM5PR0701MB2660; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM5PR0701MB2660; x-forefront-prvs: 0340850FCD x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39450400003)(39860400002)(39410400002)(39400400002)(39850400002)(39840400002)(53754006)(2900100001)(2351001)(189998001)(38730400002)(99286003)(7696004)(9686003)(3280700002)(3660700001)(53936002)(4326008)(6916009)(2906002)(2501003)(66066001)(81166006)(6116002)(3846002)(5250100002)(14454004)(102836003)(5640700003)(54356999)(110136004)(55016002)(5630700001)(5660300001)(478600001)(8936002)(6306002)(450100002)(8676002)(25786009)(230783001)(561944003)(6506006)(74316002)(790700001)(54896002)(50986999)(106356001)(33656002)(7736002)(86362001)(6436002)(1730700003); DIR:OUT; SFP:1102; SCL:1; SRVR:AM5PR0701MB2660; H:AM5PR0701MB2547.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_AM5PR0701MB2547FBCDE61B1757560F217993C10AM5PR0701MB2547_" MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Jun 2017 06:06:43.1334 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0701MB2660 Archived-At: Subject: [tcpm] Working group acceptance call draft-bagnulo-tcpm-generalized-ecn-04 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jun 2017 06:07:57 -0000 --_000_AM5PR0701MB2547FBCDE61B1757560F217993C10AM5PR0701MB2547_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, As requested by the authors, this e-mail starts a working group acceptance = call for draft-bagnulo-tcpm-generalized-ecn-04, which will run on the list = until June 30. The proposal is to add a new milestone to the TCPM charter Submit document on adding Explicit Congestion Notification (ECN) to TCP C= ontrol Packets to the IESG for publication as Experimental RFC and to use draft-bagnulo-tcpm-generalized-ecn as a starting point. If you believe that TCPM should work on a document in this space, and in pa= rticular if you are willing to review it, please reply to this e-mails. Ple= ase also speak up if you have any concerns or objections. Thanks Michael --_000_AM5PR0701MB2547FBCDE61B1757560F217993C10AM5PR0701MB2547_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

 

As requested by the authors, this e-mail starts a wo= rking group acceptance call for draft-bagnulo-tcpm-generalized-ecn-04, whic= h will run on the list until June 30.

 

The proposal is to add a new milestone to the  = TCPM charter

 

  Submit document on adding Explicit Congestion= Notification (ECN) to TCP Control Packets to the IESG for publication as E= xperimental RFC

 

and to use draft-bagnulo-tcpm-generalized-ecn as a s= tarting point.

 

If you believe that TCPM should work on a document i= n this space, and in particular if you are willing to review it, please rep= ly to this e-mails. Please also speak up if you have any concerns or object= ions.

 

Thanks

 

Michael

--_000_AM5PR0701MB2547FBCDE61B1757560F217993C10AM5PR0701MB2547_-- From nobody Sat Jun 17 09:27:33 2017 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 C4178124234 for ; Sat, 17 Jun 2017 09:27:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.291 X-Spam-Level: X-Spam-Status: No, score=-4.291 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_MIME_MALF=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id da_OaKxVp35w for ; Sat, 17 Jun 2017 09:27:29 -0700 (PDT) Received: from mail-in21.apple.com (mail-out21.apple.com [17.171.2.31]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C49831201F8 for ; Sat, 17 Jun 2017 09:27:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1497716847; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=AwlhISOG/QGNw8V+hDVaATWm8ksubSe0eyl1oAj0xeg=; b=nTI7V3Ppn1SoIFtH4c3Y6qAoL4kCn73U0PlNnKQuI7fZKFy7/19OKw4rbyldoU2G uhWFXYvNzWBSg/oPsL3EAvvfYl2hERGp3106qi7NKR5d0tdOyV7xnJz7ciOYA/zO Lm4veoyeOqkW4K3fgX5/k/GTiCj0rEldZbYjJdmhrRm1X8LSdu8BJjcPxQuCoarK 4VccsSvR5jTD3jKz/puwA3+W1JpcJVtkZxlSfgD9i9hSrh3LTmf1VteWxO3+k8DG fQMPNUmqKwgjZ4cX9UH28BReeq8WAOIpsHUJKdNCibPFygvVVP+t9N7bk36pUwNn oWAp6aLwsVQjwVB1Aatz7Q==; Received: from relay5.apple.com (relay5.apple.com [17.128.113.88]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail-in21.apple.com (Apple Secure Mail Relay) with SMTP id 0E.FA.03314.F6855495; Sat, 17 Jun 2017 09:27:27 -0700 (PDT) X-AuditID: 11ab0215-ab5fb70000000cf2-31-5945586e0361 Received: from nwk-mmpp-sz09.apple.com (nwk-mmpp-sz09.apple.com [17.128.115.80]) by relay5.apple.com (Apple SCV relay) with SMTP id 67.71.02326.E6855495; Sat, 17 Jun 2017 09:27:26 -0700 (PDT) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_YZ1Y/3AZcog7aSRSNKEvlA)" Received: from [17.234.3.109] (unknown [17.234.3.109]) by nwk-mmpp-sz09.apple.com (Oracle Communications Messaging Server 8.0.1.2.20170210 64bit (built Feb 10 2017)) with ESMTPSA id <0ORP00HFA9POAD20@nwk-mmpp-sz09.apple.com> for tcpm@ietf.org; Sat, 17 Jun 2017 09:27:26 -0700 (PDT) Sender: bhooma@apple.com From: Padma Bhooma Date: Sat, 17 Jun 2017 09:27:24 -0700 References: To: tcpm@ietf.org In-reply-to: Message-id: X-Mailer: Apple Mail (2.3273) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrLLMWRmVeSWpSXmKPExsUi2FAYoZsf4RppcOSBmcW2k/OZHBg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVse1eF3PB9nWMFYvu/mBsYLw8mbGLkYNDQsBEoul0chcjJ4eQ wBomib33w2DCFxrruxi5gMIHGSV2XrzJDlLDKyAo8WPyPRYQm1kgTGLikzmMEEULmSTmn/0G ViQsICFx+MQGsCI2AVWJk3/uMEPEAySWzrjKCrKABSj+81MRxF5zibNvz4KViwDNXzh1KyuI zSlgIfFj+TFWiL02Et3/tjOC2BICshK3Zl9iBtkrIbCCTeLNmYdMExgFZyG5bxaS+2YBrWMW UJeYMiUXIqwt8eTdBVYIW01i4e9FTMjiCxjZVjEK5yZm5uhm5hkZ6iUWFOSk6iXn525iBIX3 aibRHYzzXxkeYhTgYFTi4V1xwzlSiDWxrLgy9xCjNAeLkjhvaZZLpJBAemJJanZqakFqUXxR aU5q8SFGJg5OqQbGmLsvTJiYji24eWidvZ/z3Rl1r+7o79wsaXt6YUq13YL6d0u+iMT++hoR dXO5Q8/yNttNl76sjfZave3qbfc3d/8dSe3JO/dxxaOSfj3n4NWV9Va9YfqRYTvnTujRnvX1 1PXFKV+lnP9sOBpccHwy8zt1Y6bEZ7X/Hi0yLTBkvPuo4+4Hr7duvEosxRmJhlrMRcWJAJz4 bnJQAgAA X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrBIsWRmVeSWpSXmKPExsUi2FAcoJsX4RppsKlb1mLbyflMDoweS5b8 ZApgjOKySUnNySxLLdK3S+DK2Havi7lg+zrGikV3fzA2MF6ezNjFyMEhIWAicaGxvouRi0NI 4CCjxM6LN9m7GDk5eAUEJX5MvscCYjMLhElMfDKHEaJoIZPE/LPfwIqEBSQkDp/YAFbEJqAq cfLPHWaIeIDE0hlXWUEWsADFf34qAgkLCZhLnH17FqxcBGj+wqlbWUFsTgELiR/Lj7FC7LWR 6P63nRHElhCQlbg1+xLzBEa+WUhOmoXkpFlAG5gF1CWmTMmFCGtLPHl3gRXCVpNY+HsRE7L4 Aka2VYwCRak5iZWmeokFBTmpesn5uZsYwQFZGLGD8f8yq0OMAhyMSjy8PzJdIoVYE8uKK3MP MUpwMCuJ8D4ydo0U4k1JrKxKLcqPLyrNSS0+xDiREejHicxSosn5wHjJK4k3NDExMDE2NjM2 Njcxp6WwkjhvcYBTpJBAemJJanZqakFqEcxRTBycUg2MNcy/p7qsCXaLiskPubVSQOSgX1BA xF73s5ECcZO/rLzv2nb15bKL+37yzYyZk7Pgz25NM9X5S7c568WcvbFpa5ae7NNLLGcemjDu 4dzRcfTGlIbTL5yVdj9iuGKU3nZlbfBfpf5z3xcuMnnn2646jUVGaqvSIrbAiipN36XrXuws nPqVc8bsDUosxRmJhlrMRcWJAIhhhAy7AgAA Archived-At: Subject: Re: [tcpm] Working group acceptance call draft-bagnulo-tcpm-generalized-ecn-04 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 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, 17 Jun 2017 16:27:32 -0000 --Boundary_(ID_YZ1Y/3AZcog7aSRSNKEvlA) Content-type: text/plain; charset=utf-8 Content-transfer-encoding: quoted-printable Hi Marcelo and Bob, I have reviewed the document draft-bagnulo-tcpm-generalized-ecn-04 and I = am sending my comments below. Overall, I think there is value in working = on these additions or enhancements to RFC 3168 in tcpm working group. I = am willing to review and provide feedback as needed. Section 3.2.1.3 - If the SYN-ACK does not support AccECN, TCP must = conservatively reduce its IW and SHOULD reduce it to 1 SMSS. This clause = is very conservative because AccECN support can be deployed on servers = slowly. Even if both end hosts support AccECN, there are networks with = performance proxies that will not allow the feedback to propagate = correctly. On those networks, TCP connections with ECT on SYN will = always start with 1MSS of IW. I think this is too conservative and might = add multiple RTT to grow the window. I agree with the value in adding = ECT marking to SYN and SYN-ACK in terms of the latency benefits that = might bring to an end user. I think =E2=80=9Cpessimistic ECT and cache = successes=E2=80=9D strategy described in 4.2.1 sounds like a reasonable = one. Section 3.2.3 ECT marking on Pure Acks - It felt like the document = suggested further discussion on setting ECT on pure Acks, please correct = me if I am wrong here. Setting ECT on pure Acks can increase the load on = an AQM that might already be under load. This is because the number of = Acks can be large and the information conveyed to the peer is redundant = because asks are cumulative. TCP acknowledgements also do not solicit a = response from the peer most of the times. So the chances of not echoing = CE on an Ack is high. It is also difficult to detect if an Ack is = dropped by an incompatible middle box because of ECT marking on it since = we do not retransmit Acks.. So the fallback mechanisms will be limited. = In Section 4.4.1 (Cwnd response to CE-marking on Pure Acks), the = document says that we can echo a CE received on a pure ack on a data = segment that will be sent later. In general, I think any congestion = notification is relevant only for a short period of time probably in the = order of a typical RTT. Once that time window passes, it may not be = correct to respond to a delayed congestion notification. So echoing CE = from a pure Ack on a data segment sent much later may not be the correct = thing to do. Section 3.2.4 Window Probe - Adding ECT to window probes is really good = because this traffic is not too large on any connection and it requires = the peer to respond so that there is a way to echo the CE marking. One = modification that might be worth discussing is to require congestion = response to CE marking on a window probe only when the receive window is = opened. I will try to explain why this is reasonable. If congestion at = the bottleneck link is transient, then lowering the congestion window in = response to CE on a window probe that does not open the receive window = might not be necessary because there won=E2=80=99t be any data sent = afterwards. This can actually happen multiple times on a connection = because a connection can go on for a long time sending multiple window = probes when the peer does not open the window. So reducing congestion = window only when the receive window is opened as a response to CE seems = to be accurate in terms of timing and reaction to congestion = notification. Section 3.2.7 Retransmissions - If a connection doesn=E2=80=99t set ECT = on a SYN because it does not support AccECN feedback (due to fallback = mechanisms or something else), then the first data packet will be the = first packet on a connection with ECT marking on it. If it is dropped, = sending retransmissions without ECT might make it go through if there is = a middle box that incorrectly drops packets with ECT marking. I think, = this detection and fallback mechanism must be somehow included in the = proposal to mark retransmissions with ECT. Another point to note is that a connection should be already in recovery = and must have adjusted it=E2=80=99s congestion window before sending a = retransmission because it detected loss. If it further detects that = there was CE marking on a retransmitted packet then it is not clear if = it needs to adjust the congestion window again. Adding some = clarification here will be good. Tail loss probe - I think it will also be useful to include some text = about CE marking on probe packets that a connection might send in = response to tail loss (draft-dukkipati-tcpm-tcp-loss-probe-01.txt). Implementation or deployment related comments - The document refers to = other drafts or experimental RFCs as possible actions that can be taken = in several scenarios. For example AccECN, RFC 5690, RFC 7567 etc,. Even = though implementing and deploying these specifications is possible, they = may not be implemented unless these specifications are tightly bound = together. A casual reader might understand that implementing multiple of = these RFCS will make the system work well. But for someone to implement = and deploy these specifications, it is not clear if some or all of these = implementations will need to be supported. It will be good to make a = recommendation for the minimum set of specifications that need to be = implemented =E2=80=94 may be after some more discussion. Fallback mechanisms - The document also discusses several fallback = mechanisms to handle incompatibilities in the network. If we want = implementations to consider these cases, it will be useful to formalize = these detection and fallback mechanisms. I found that some of these = mechanisms are being discussed in section 4 which was tagged as = informative. Overall, the document is written well and discusses multiple aspects of = the proposed changes both on the end hosts and in the network. It is = useful to have discussions on the proposed changes and to drive = measurements that are needed to collect data to support or validate some = of the assumptions made. Thanks, Padma >=20 >=20 > 1. Working group acceptance call > draft-bagnulo-tcpm-generalized-ecn-04 > (Scharf, Michael (Nokia - DE/Stuttgart)) >=20 >=20 > ---------------------------------------------------------------------- >=20 > Message: 1 > Date: Fri, 16 Jun 2017 06:06:43 +0000 > From: "Scharf, Michael (Nokia - DE/Stuttgart)" > > To: "tcpm@ietf.org" > Cc: "tcpm-chairs@ietf.org" > Subject: [tcpm] Working group acceptance call > draft-bagnulo-tcpm-generalized-ecn-04 > Message-ID: > = > =09 > Content-Type: text/plain; charset=3D"us-ascii" >=20 > Hi all, >=20 > As requested by the authors, this e-mail starts a working group = acceptance call for draft-bagnulo-tcpm-generalized-ecn-04, which will = run on the list until June 30. >=20 > The proposal is to add a new milestone to the TCPM charter >=20 > Submit document on adding Explicit Congestion Notification (ECN) to = TCP Control Packets to the IESG for publication as Experimental RFC >=20 > and to use draft-bagnulo-tcpm-generalized-ecn as a starting point. >=20 > If you believe that TCPM should work on a document in this space, and = in particular if you are willing to review it, please reply to this = e-mails. Please also speak up if you have any concerns or objections. >=20 > Thanks >=20 > Michael > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: = >=20 > ------------------------------ >=20 > Subject: Digest Footer >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm >=20 >=20 > ------------------------------ >=20 > End of tcpm Digest, Vol 158, Issue 7 > ************************************ --Boundary_(ID_YZ1Y/3AZcog7aSRSNKEvlA) Content-type: text/html; charset=utf-8 Content-transfer-encoding: quoted-printable
Hi Marcelo and Bob,

I have reviewed the = document draft-bagnulo-tcpm-generalized-ecn-04 and I am sending my = comments below. Overall, I think there is value in working on these = additions or enhancements to RFC 3168 in tcpm working group. I am = willing to review and provide feedback as needed.
  • Section 3.2.1.3 - If the SYN-ACK does not = support AccECN, TCP must conservatively reduce its IW and SHOULD reduce = it to 1 SMSS. This clause is very conservative because AccECN support = can be deployed on servers slowly. Even if both end hosts support = AccECN, there are networks with performance proxies that will not allow = the feedback to propagate correctly. On those networks, TCP connections = with ECT on SYN will always start with 1MSS of IW. I think this is too = conservative and might add multiple RTT to grow the window. I agree with = the value in adding ECT marking to SYN and SYN-ACK in terms of the = latency benefits that might bring to an end user. I think =E2=80=9Cpessimi= stic ECT and cache successes=E2=80=9D strategy described in 4.2.1 sounds = like a reasonable one.

  • Section 3.2.3 ECT = marking on Pure Acks - It felt like the document suggested further = discussion on setting ECT on pure Acks, please correct me if I am wrong = here. Setting ECT on pure Acks can increase the load on an AQM that = might already be under load. This is because the number of Acks can be = large and the information conveyed to the peer is redundant because asks = are cumulative. TCP acknowledgements also do not solicit a response from = the peer most of the times. So the chances of not echoing CE on an Ack = is high. It is also difficult to detect if an Ack is dropped by an = incompatible middle box because of ECT marking on it since we do not = retransmit Acks.. So the fallback mechanisms will be limited. In Section = 4.4.1 (Cwnd response to CE-marking on Pure Acks), the document says that = we can echo a CE received on a pure ack on a data segment that will be = sent later. In general, I think any congestion notification is relevant = only for a short period of time probably in the order of a typical RTT. = Once that time window passes, it may not be correct to respond to a = delayed congestion notification. So echoing CE from a pure Ack on a data = segment sent much later may not be the correct thing to = do.

  • Section 3.2.4 Window Probe - Adding ECT to = window probes is really good because this traffic is not too large on = any connection and it requires the peer to respond so that there is a = way to echo the CE marking. One modification that might be worth = discussing is to require congestion response to CE marking on a window = probe only when the receive window is opened. I will try to explain why = this is reasonable. If congestion at the bottleneck link is transient, = then lowering the congestion window in response to CE on a window probe = that does not open the receive window might not be necessary because = there won=E2=80=99t be any data sent afterwards. This can actually = happen multiple times on a connection because a connection can go on for = a long time sending multiple window probes when the peer does not open = the window. So reducing congestion window only when the receive window = is opened as a response to CE seems to be accurate in terms of timing = and reaction to congestion notification.

  • Section = 3.2.7 Retransmissions - If a connection doesn=E2=80=99t set ECT on a = SYN because it does not support AccECN feedback (due to fallback = mechanisms or something else), then the first data packet will be the = first packet on a connection with ECT marking on it. If it is dropped, = sending retransmissions without ECT might make it go through if there is = a middle box that incorrectly drops packets with ECT marking. I think, = this detection and fallback mechanism must be somehow included in the = proposal to mark retransmissions with ECT.

Another point to note is that a = connection should be already in recovery and must have adjusted it=E2=80=99= s congestion window before sending a retransmission because it detected = loss. If it further detects that there was CE marking on a retransmitted = packet then it is not clear if it needs to adjust the congestion window = again. Adding some clarification here will be = good.

  • Tail loss probe - I think it will = also be useful to include some text about CE marking on probe packets = that a connection might send in response to tail loss (draft-dukkipati-tcpm-tcp-loss-probe-01.txt).

  • Implementation or = deployment related comments - The document refers to other = drafts or experimental RFCs as possible actions that can be taken in = several scenarios. For example AccECN, RFC 5690, RFC 7567 etc,. Even = though implementing and deploying these specifications is possible, they = may not be implemented unless these specifications are tightly bound = together. A casual reader might understand that implementing multiple of = these RFCS will make the system work well. But for someone to implement = and deploy these specifications, it is not clear if some or all of these = implementations will need to be supported. It will be good to make a = recommendation for the minimum set of specifications that need to be = implemented =E2=80=94 may be after some more discussion.

  • Fallback mechanisms - The document also discusses several = fallback mechanisms to handle incompatibilities in the network. If we = want implementations to consider these cases, it will be useful to = formalize these detection and fallback mechanisms. I found that some of = these mechanisms are being discussed in section 4 which was tagged as = informative.

Overall, the document is written well and discusses = multiple aspects of the proposed changes both on the end hosts and in = the network. It is useful to have discussions on the proposed changes = and to drive measurements that are needed to collect data to support or = validate some of the assumptions made.

Thanks,
Padma




  1. Working group = acceptance call
=      draft-bagnulo-tcpm-generalized-ecn-04
     (Scharf, Michael (Nokia - = DE/Stuttgart))


---------------------------------------------------------------= -------

Message: 1
Date: Fri, = 16 Jun 2017 06:06:43 +0000
From: "Scharf, Michael (Nokia - = DE/Stuttgart)"
<michael.scharf@nokia.com>
To: "tcpm@ietf.org" <tcpm@ietf.org>
Cc: "tcpm-chairs@ietf.org" <tcpm-chairs@ietf.org>
Subject: [tcpm] = Working group acceptance call
= draft-bagnulo-tcpm-generalized-ecn-04
Message-ID:
= <AM5PR0701MB2547FBCDE61B1757560F217993C10@AM5PR0701MB2547.eurprd= 07.prod.outlook.com>

Content-Type: = text/plain; charset=3D"us-ascii"

Hi all,

As requested by the authors, this e-mail = starts a working group acceptance call for = draft-bagnulo-tcpm-generalized-ecn-04, which will run on the list until = June 30.

The proposal is to add a new = milestone to the  TCPM charter

=  Submit document on adding Explicit Congestion Notification (ECN) = to TCP Control Packets to the IESG for publication as Experimental = RFC

and to use = draft-bagnulo-tcpm-generalized-ecn as a starting point.

If you believe that TCPM should work on a document in this = space, and in particular if you are willing to review it, please reply = to this e-mails. Please also speak up if you have any concerns or = objections.

Thanks

Michael
-------------- next part = --------------
An HTML attachment was scrubbed...
URL: <https://mailarchive.ietf.org/arch/browse/tcpm/attachments/20170= 616/151f93e9/attachment.html>

------------------------------

Subject: Digest Footer

_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm


------------------------------
End of tcpm Digest, Vol 158, Issue 7
************************************

= --Boundary_(ID_YZ1Y/3AZcog7aSRSNKEvlA)-- From nobody Mon Jun 19 10:00:01 2017 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 6684F131607 for ; Mon, 19 Jun 2017 09:59:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.989 X-Spam-Level: X-Spam-Status: No, score=-1.989 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_MIME_MALF=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=bobbriscoe.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oQyqoJ_iVDfg for ; Mon, 19 Jun 2017 09:59:49 -0700 (PDT) Received: from server.dnsblock1.com (server.dnsblock1.com [85.13.236.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37E371315BC for ; Mon, 19 Jun 2017 09:56:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Type:In-Reply-To:MIME-Version:Date: Message-ID:Cc:From:References:To:Subject:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=Cqq/ekLsGO7mTSADm0qsY8ZfETVl2+Hh1AiM5RgeAxA=; b=c1mFlGDGNL1Yv/C6XH42plaXc F3+1JdSGHQc4U/cL/iULa6417yOu7d6TVP92TJZTFkdraKPfBPCqZr+DRchT0zXU5zChxo6UjoPVd uA0mDNtQRHNO+PNsW4UkTV/M/xacEy9Gl8Z+Fic/s4pGr7dMnPXyy44Q8Ia/v7H8qau1a32gxnedp xlIsVC6xLGtvK1HUmXXkSco5+mCvKrzPFLpN1hDXkb4WFO9J4JDv/K6aFtZL6NvvlqOwU0aZrjCVD +HRAU35xhHaM5Q/NSMazhSr7+oFNt+SnJOiKqaSvu+xXXos77TjyUjDNt3ACAGgeVyhKi+8eElJyP bqxcQ6teg==; Received: from 167.6.208.46.dyn.plus.net ([46.208.6.167]:33806 helo=[192.168.0.6]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89) (envelope-from ) id 1dMzyO-0008LY-Bg; Mon, 19 Jun 2017 17:56:21 +0100 To: tcpm@ietf.org References: From: Bob Briscoe Message-ID: <59715f8c-3850-a5cf-b267-ac39b11d962f@bobbriscoe.net> Date: Mon, 19 Jun 2017 17:56:19 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------CEDFA5E62218A302B96D53B8" Content-Language: en-GB X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.dnsblock1.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - bobbriscoe.net X-Get-Message-Sender-Via: server.dnsblock1.com: authenticated_id: in@bobbriscoe.net X-Authenticated-Sender: server.dnsblock1.com: in@bobbriscoe.net Archived-At: Subject: Re: [tcpm] Working group acceptance call draft-bagnulo-tcpm-generalized-ecn-04 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jun 2017 16:59:59 -0000 This is a multi-part message in MIME format. --------------CEDFA5E62218A302B96D53B8 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Padma, On 17/06/17 17:27, Padma Bhooma wrote: > Hi Marcelo and Bob, > > I have reviewed the document draft-bagnulo-tcpm-generalized-ecn-04 and > I am sending my comments below. Overall, I think there is value in > working on these additions or enhancements to RFC 3168 in tcpm working > group. I am willing to review and provide feedback as needed. > > * *Section 3.2.1.3 *- If the SYN-ACK does not support AccECN, TCP > must conservatively reduce its IW and SHOULD reduce it to 1 SMSS. > This clause is very conservative because AccECN support can be > deployed on servers slowly. Even if both end hosts support AccECN, > there are networks with performance proxies that will not allow > the feedback to propagate correctly. On those networks, TCP > connections with ECT on SYN will always start with 1MSS of IW. I > think this is too conservative and might add multiple RTT to grow > the window. I agree with the value in adding ECT marking to SYN > and SYN-ACK in terms of the latency benefits that might bring to > an end user. > [BB] We have structured the document to just recommend the preferred approach in the normative spec (section 3), then discuss the rationale and possible alternatives in section 4. The sections just before 3.2.1.3 recommend: - 3.2.1.1: the client uses ECT optimistically - 3.2.1.2: but the client caches servers that don't recognize ECT. This is the "optimistic ECT and cache failures" strategy discussed in 4.2.1 (tagged as 'S2B'). The requirement to reduce IW to 1SMSS only applies if the client is adopting this strategy and discovers the server does not support AccECN. Perhaps we didn't make that clear? We have given 3 reasons for why this conservatism will rarely harm performance: 1) With this strategy, IW=1SMSS will only be needed the first time a client accesses a non-AccECN proxy or server. 2) During transition, this conservative IW=1SMSS will only ever be necessary for the client to server half-connection, not server to client. According to Yuchung Cheng, client Web requests are rarely greater than 1 segment (no data openly available). Do you have any data to corroborate (or contradict) this? I think in non-Web apps, the initial client request would often fit within 1 packet too (e.g. email, ftp, ssh, scp, etc). 3) Fall-back to 1SMSS is written as SHOULD rather than MUST. And refers to text later that says under what conditions you can use a higher IW. > * I think “pessimistic ECT and cache successes†strategy described > in 4.2.1 sounds like a reasonable one. > [BB] What's your reasoning for preferring this one? We recommended "optimistic ECT and cache failures". > > * *Section 3.2.3 ECT marking on Pure Acks* - It felt like the > document suggested further discussion on setting ECT on pure Acks, > please correct me if I am wrong here. Setting ECT on pure Acks can > increase the load on an AQM that might already be under load. This > is because the number of Acks can be large and the information > conveyed to the peer is redundant because asks are cumulative. TCP > acknowledgements also do not solicit a response from the peer most > of the times. So the chances of not echoing CE on an Ack is high. > [BB] Let's take these points one at a time: PB: Setting ECT on pure ACKs could increase the load on an AQM BB: An AQM processes packets of all sizes anyway. If pure ACKs are not ECT, it still has to decide whether to drop each pure ACK. Marking instead of dropping doesn't make any more work for the AQM. PB: The information conveyed to the peer is redundant because ACKs are cumulative. BB: Just because the ACKnumber info is superseded by the next ACK does not mean the ECN marking is superseded. PB: TCP acknowledgements do not solicit a response from the peer most of the times. So the chances of not echoing CE on an Ack is high. BB: Just because pure ACKs do not solicit a specific response (no ACK of an ACK) does not mean the data sender is not continuing to send data packets, on which ECE can be set (if RFC3168 feedback) or on which the CE counter can be increased (AccECN feedback). RFC3168 actually says this: (One simple possibility would be for the sender to reduce its congestion window when it receives a pure ACK packet with the CE codepoint set). Consider this pure ACK example with data solely in the S->C direction, where S is the server. * Say 3 in 1000 pure ACKs in the C->S direction are CE-marked, meaning the C->S marking probability is 0.3% * This might be because 0.3% of data packets in other flows (e.g. a YouTube upload) are being CE-marked as well. * So S needs to tell C that it has seen 3 CE marked packets (which it will do on the data packets it is sending, whether with RFC3168 feedback or AccECN feedback). * C is not (currently) sending any data to S, but it will reduce its cwnd for if it does start sending data. > * It is also difficult to detect if an Ack is dropped by an > incompatible middle box because of ECT marking on it since we do > not retransmit Acks.. So the fallback mechanisms will be limited. > [BB] You're correct in all respects here. Nonetheless, I have three responses: * We have been doing millions of measurements over fixed and mobile networks, using a machine we control on both sides and checking a sent ECT packet is also received. So far, we have not seen any difference in the treatment of any control packet if set to ECT vs not-ECT. * Section 6.1.4 of RFC3168 hinted that in future pure ACKs might be set to ECT. So if a security middlebox is trying to enforce RFC3168, it still might allow ECT pure ACKs to pass. * Nonetheless, if there were a middlebox that dropped ECT pure ACKs, you are right that it could black-hole all ECT pure ACKs and stall a connection. And there would be no easy way to detect the specific cause of the problem and stop setting ECT on pure ACKs. * We should at least say that if fall-back has to be used because ECT SYNs or SYN-ACKs are not getting through, then ECT ought not to be used on pure ACKs either. This is a good reason for why this protocol is experimental. However, given we have not so far found this problem in practice, I think it's OK to go ahead. But I agree that we should note that this is an open issue. > * In Section 4.4.1 (Cwnd response to CE-marking on Pure Acks), the > document says that we can echo a CE received on a pure ack on a > data segment that will be sent later. In general, I think any > congestion notification is relevant only for a short period of > time probably in the order of a typical RTT. Once that time window > passes, it may not be correct to respond to a delayed congestion > notification. So echoing CE from a pure Ack on a data segment sent > much later may not be the correct thing to do. > [BB] This is true. However, this point applies generally to idle periods, not just when pure ACKs are marked. TCP can always enter an idle period just after a loss or CE mark is received, then if later the sender has something to send, cwnd will be lower. Cwnd is already reduced exponentially during an idle period. This is all part of the fairly arbitrary rules on how to evolve cwnd during an idle period. Nonetheless, while idling, I think it is sensible to reduce cwnd more, if more of any pure ACKs sent during the idle period are picking up congestion markings. I don't think we should recommend the converse: i.e. if the congestion was a long time ago, we should not recommend that cwnd can be increased again. However, this is an area where I think implementers should be allowed to experiment, and I think the specs allow enough flexibility to do so. > > * *Section 3.2.4 Window Probe* - Adding ECT to window probes is > really good because this traffic is not too large on any > connection and it requires the peer to respond so that there is a > way to echo the CE marking. One modification that might be worth > discussing is to require congestion response to CE marking on a > window probe only when the receive window is opened. I will try to > explain why this is reasonable. If congestion at the bottleneck > link is transient, then lowering the congestion window in response > to CE on a window probe that does not open the receive window > might not be necessary because there won’t be any data sent > afterwards. This can actually happen multiple times on a > connection because a connection can go on for a long time sending > multiple window probes when the peer does not open the window. So > reducing congestion window only when the receive window is opened > as a response to CE seems to be accurate in terms of timing and > reaction to congestion notification. > [BB] On the other hand, if the window was constrained solely because the receive window was low and there had been a CE mark on a window probe many round trips ago, but not on more recent window probes, it would not be correct to reduce cwnd such a long time after the congestion had occurred. I think it would be better to reduce cwnd immediately there is a CE on a window probe, increase cwnd as normal for every non-CE-marked window probe (even if rwnd is still the limiting factor). But also rely on cwnd validation so that cwnd cannot grow excessively if it is not being used. > > * *Section 3.2.7 Retransmissions *- If a connection doesn’t set ECT > on a SYN because it does not support AccECN feedback (due to > fallback mechanisms or something else), then the first data packet > will be the first packet on a connection with ECT marking on it. > If it is dropped, sending retransmissions without ECT might make > it go through if there is a middle box that incorrectly drops > packets with ECT marking. I think, this detection and fallback > mechanism must be somehow included in the proposal to mark > retransmissions with ECT. > [BB] Good point. I had figured that fall-back only needed to be considered for the SYN or SYN-ACK. But you're right that, if the SYN is not-ECT, fall-back might be needed later (altho, as already mentioned, we have not seen a need in measurements so far). This will generally only apply to the C->S half-connection. This is a general point about fall-back that happens to be noticed when both data and retransmissions fail to get through. So I think we ought to add a general point about fall-back as a new subsection of section 3, rather than writing this in the retransmissions subjection. I propose this text: 3.2.8 General Fall-Back Consider a host that has sent the first packet on a half-connection (SYN or SYN/ACK) without ECT set and it has been acknowledged. If this host's retransmission timer expires more than once for all subsequent packet(s) it sends with ECT set, it SHOULD retransmit the packet(s) with not-ECT set. If these not-ECT packet(s) are acknowledged without any further losses, it is RECOMMENDED that the host disables setting ECT on all subsequent packets of the half-connection. It could also cache this failure. > > Another point to note is that a connection should be already in > recovery and must have adjusted it’s congestion window before > sending a retransmission because it detected loss. If it further > detects that there was CE marking on a retransmitted packet then > it is not clear if it needs to adjust the congestion window again. > Adding some clarification here will be good. > [BB] Yes. We already say: If the TCP sender receives feedback that a retransmitted packet was CE-marked, it will react as it would to any feedback of CE-marking on a data packet. Do you have a suggestion for clearer text? Perhaps: If the TCP sender receives feedback that a retransmitted packet was CE-marked, it will react as it would to any feedback of CE-marking on a data packet, in addition to its original reaction to the loss that caused the retransmission. RFC5681 already says: Loss in two successive windows of data, or the loss of a retransmission, should be taken as two indications of congestion and, therefore, cwnd (and ssthresh) MUST be lowered twice in this case. It's hard to be more specific because we didn't want to contradict other congestion control schemes (e.g. some respond to at least one mark per RTT, others respond to the extent of CE marking). > > * *Tail loss probe *- I think it will also be useful to include some > text about CE marking on probe packets that a connection might > send in response to tail loss > (draft-dukkipati-tcpm-tcp-loss-probe-01.txt). > [BB] Well, I would like to resist mission creep. The scope of our draft is intended to be about setting ECT on packets where it was previously prohibited. We have included interactions with SCTP, TFO and IW10 in "5. Interaction with popular variants or derivatives of TCP " because they have been published and can no longer be easily changed. For TLP, it's not even adopted in TCP yet (although I'm sure it is widely used). So I think it's up to the authors of this draft to say whether ECT should be set on a TLP and what the response to a CE-marked TLP should be. > > * *Implementation or deployment related comments - *The document > refers to other drafts or experimental RFCs as possible actions > that can be taken in several scenarios. For example AccECN, RFC > 5690, RFC 7567 etc,. Even though implementing and deploying these > specifications is possible, they may not be implemented unless > these specifications are tightly bound together. A casual reader > might understand that implementing multiple of these RFCS will > make the system work well. But for someone to implement and deploy > these specifications, it is not clear if some or all of these > implementations will need to be supported. It will be good to make > a recommendation for the minimum set of specifications that need > to be implemented — may be after some more discussion. > [BB] If my co-author agrees, we can do this. I would recommend the following complements (both normatively referenced): * AccECN * RFC5691 (robustness to blind in-window attacks). As a reciprocal recommendation, currently, the Intro to the AccECN draft says: It is likely (but not required) that the AccECN protocol will be implemented along with the following experimental additions to the TCP-ECN protocol: ECN-capable TCP control packets and retransmissions [I-D.bagnulo-tcpm-generalized-ecn ], which includes the ECN-capable SYN-ACK experiment [RFC5562 ]; and testing receiver non-compliance [I-D.moncaster-tcpm-rcv-cheat ]. The following are good, but I don't think they qualify as complementary to ECN++: * RFC5690 (ACKcc). It is merely optional and "not incompatible". * Similarly for TFO and IW10. Optional but not incompatible. * RFC7567 is about AQM in the network, so I don't it would help an implementer to say it is complementary, as host implementers cannot control where their implementation is used. * Originally we were going to recommend RFC5562 (ECN+ i.e. ECT on SYN-ACK packets), but once we realized it was over-conservative, we wrote a less conservative alternative directly into this ECN++ draft. More generally, I know some people are starting to get really confused over how to put together all the piecemeal modifications to ECN. I think that would require an informational "ECN roadmap" draft. No promises, but I guess I am someone who would be well-placed to know what to write in such a draft. > > * > *Fallback mechanisms *- The document also discusses several > fallback mechanisms to handle incompatibilities in the network. If > we want implementations to consider these cases, it will be useful > to formalize these detection and fallback mechanisms. I found that > some of these mechanisms are being discussed in section 4 which > was tagged as informative. > [BB] I have just checked, and I cannot find any case where there is fall-back text in section 4 that ought to be normative. If you found any, pls say where. We tried to ensure that the recommended approach was always in section 3, even if section 4 discussed (then rejected) alternatives. > Overall, the document is written well and discusses multiple aspects > of the proposed changes both on the end hosts and in the network. It > is useful to have discussions on the proposed changes and to drive > measurements that are needed to collect data to support or validate > some of the assumptions made. [BB] Thanks. In summary, as this conversation progresses, we might agree further changes. However, so far I have queued up the following list of changes to the text to address your points: * Intro: Recommend complementary RFCs or drafts * 3.2.1.3: Clarify that using IW=1SMSS only applies when using the strategies recommended in the previous two sections. * When fall-back due to ECT on SYN (3.2.1.4) or SYN-ACK (3.2.2.3), consider disabling ECT on other control packets (esp. pure ACKs). * Add detection of black-holing of pure ACKs as an open issue (hence why we have to take the approach in the previous bullet) * Add extra section on general fall-back if no ECT packet has ever been ack'd * And we will certainly acknowledge your contribution, and I hope you will continue to track changes to this draft carefully and let us know if you have implementation experience - thank you. Bob > > Thanks, > Padma > > >> >> >> 1. Working group acceptance call >> draft-bagnulo-tcpm-generalized-ecn-04 >> (Scharf, Michael (Nokia - DE/Stuttgart)) >> >> >> ---------------------------------------------------------------------- >> >> Message: 1 >> Date: Fri, 16 Jun 2017 06:06:43 +0000 >> From: "Scharf, Michael (Nokia - DE/Stuttgart)" >> > >> To: "tcpm@ietf.org " > > >> Cc: "tcpm-chairs@ietf.org " >> > >> Subject: [tcpm] Working group acceptance call >> draft-bagnulo-tcpm-generalized-ecn-04 >> Message-ID: >> > > >> >> Content-Type: text/plain; charset="us-ascii" >> >> Hi all, >> >> As requested by the authors, this e-mail starts a working group >> acceptance call for draft-bagnulo-tcpm-generalized-ecn-04, which will >> run on the list until June 30. >> >> The proposal is to add a new milestone to the TCPM charter >> >> Submit document on adding Explicit Congestion Notification (ECN) to >> TCP Control Packets to the IESG for publication as Experimental RFC >> >> and to use draft-bagnulo-tcpm-generalized-ecn as a starting point. >> >> If you believe that TCPM should work on a document in this space, and >> in particular if you are willing to review it, please reply to this >> e-mails. Please also speak up if you have any concerns or objections. >> >> Thanks >> >> Michael >> -------------- next part -------------- >> An HTML attachment was scrubbed... >> URL: >> >> >> ------------------------------ >> >> Subject: Digest Footer >> >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm >> >> >> ------------------------------ >> >> End of tcpm Digest, Vol 158, Issue 7 >> ************************************ > > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ --------------CEDFA5E62218A302B96D53B8 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Padma,

On 17/06/17 17:27, Padma Bhooma wrote:
Hi Marcelo and Bob,

I have reviewed the document draft-bagnulo-tcpm-generalized-ecn-04 and I am sending my comments below. Overall, I think there is value in working on these additions or enhancements to RFC 3168 in tcpm working group. I am willing to review and provide feedback as needed.

  • Section 3.2.1.3 - If the SYN-ACK does not support AccECN, TCP must conservatively reduce its IW and SHOULD reduce it to 1 SMSS. This clause is very conservative because AccECN support can be deployed on servers slowly. Even if both end hosts support AccECN, there are networks with performance proxies that will not allow the feedback to propagate correctly. On those networks, TCP connections with ECT on SYN will always start with 1MSS of IW. I think this is too conservative and might add multiple RTT to grow the window. I agree with the value in adding ECT marking to SYN and SYN-ACK in terms of the latency benefits that might bring to an end user.
[BB] We have structured the document to just recommend the preferred approach in the normative spec (section 3), then discuss the rationale and possible alternatives in section 4. The sections just before 3.2.1.3 recommend:
  - 3.2.1.1: the client uses ECT optimistically
  - 3.2.1.2: but the client caches servers that don't recognize ECT.
This is the "optimistic ECT and cache failures" strategy discussed in 4.2.1 (tagged as 'S2B').

The requirement to reduce IW to 1SMSS only applies if the client is adopting this strategy and discovers the server does not support AccECN. Perhaps we didn't make that clear?

We have given 3 reasons for why this conservatism will rarely harm performance:

1) With this strategy, IW=1SMSS will only be needed the first time a client accesses a non-AccECN proxy or server.

2) During transition, this conservative IW=1SMSS will only ever be necessary for the client to server half-connection, not server to client.
According to Yuchung Cheng, client Web requests are rarely greater than 1 segment (no data openly available). Do you have any data to corroborate (or contradict) this? I think in non-Web apps, the initial client request would often fit within 1 packet too (e.g. email, ftp, ssh, scp, etc).

3) Fall-back to 1SMSS is written as SHOULD rather than MUST. And refers to text later that says under what conditions you can use a higher IW.

  • I think “pessimistic ECT and cache successes†strategy described in 4.2.1 sounds like a reasonable one.
[BB] What's your reasoning for preferring this one? We recommended "optimistic ECT and cache failures".


  • Section 3.2.3 ECT marking on Pure Acks - It felt like the document suggested further discussion on setting ECT on pure Acks, please correct me if I am wrong here. Setting ECT on pure Acks can increase the load on an AQM that might already be under load. This is because the number of Acks can be large and the information conveyed to the peer is redundant because asks are cumulative. TCP acknowledgements also do not solicit a response from the peer most of the times. So the chances of not echoing CE on an Ack is high.
[BB] Let's take these points one at a time:
PB: Setting ECT on pure ACKs could increase the load on an AQM
BB: An AQM processes packets of all sizes anyway. If pure ACKs are not ECT, it still has to decide whether to drop each pure ACK. Marking instead of dropping doesn't make any more work for the AQM.

PB: The information conveyed to the peer is redundant because ACKs are cumulative.
BB: Just because the ACKnumber info is superseded by the next ACK does not mean the ECN marking is superseded.

PB: TCP acknowledgements do not solicit a response from the peer most of the times. So the chances of not echoing CE on an Ack is high.
BB: Just because pure ACKs do not solicit a specific response (no ACK of an ACK) does not mean the data sender is not continuing to send data packets, on which ECE can be set (if RFC3168 feedback) or on which the CE counter can be increased (AccECN feedback).

RFC3168 actually says this:
   (One simple possibility would be for the sender to reduce its
   congestion window when it receives a pure ACK packet with the CE
   codepoint set).
Consider this pure ACK example with data solely in the S->C direction, where S is the server.
  * Say 3 in 1000 pure ACKs in the C->S direction are CE-marked, meaning the C->S marking probability is 0.3%
  * This might be because 0.3% of data packets in other flows (e.g. a YouTube upload) are being CE-marked as well.
  * So S needs to tell C that it has seen 3 CE marked packets (which it will do on the data packets it is sending, whether with RFC3168 feedback or AccECN feedback).
  * C is not (currently) sending any data to S, but it will reduce its cwnd for if it does start sending data.

  • It is also difficult to detect if an Ack is dropped by an incompatible middle box because of ECT marking on it since we do not retransmit Acks.. So the fallback mechanisms will be limited.
[BB] You're correct in all respects here. Nonetheless, I have three responses:
  * We have been doing millions of measurements over fixed and mobile networks, using a machine we control on both sides and checking a sent ECT packet is also received. So far, we have not seen any difference in the treatment of any control packet if set to ECT vs not-ECT.
  * Section 6.1.4 of RFC3168 hinted that in future pure ACKs might be set to ECT. So if a security middlebox is trying to enforce RFC3168, it still might allow ECT pure ACKs to pass.
  * Nonetheless, if there were a middlebox that dropped ECT pure ACKs, you are right that it could black-hole all ECT pure ACKs and stall a connection. And there would be no easy way to detect the specific cause of the problem and stop setting ECT on pure ACKs.
  * We should at least say that if fall-back has to be used because ECT SYNs or SYN-ACKs are not getting through, then ECT ought not to be used on pure ACKs either.

This is a good reason for why this protocol is experimental. However, given we have not so far found this problem in practice, I think it's OK to go ahead. But I agree that we should note that this is an open issue.

  • In Section 4.4.1 (Cwnd response to CE-marking on Pure Acks), the document says that we can echo a CE received on a pure ack on a data segment that will be sent later. In general, I think any congestion notification is relevant only for a short period of time probably in the order of a typical RTT. Once that time window passes, it may not be correct to respond to a delayed congestion notification. So echoing CE from a pure Ack on a data segment sent much later may not be the correct thing to do.
[BB] This is true.
However, this point applies generally to idle periods, not just when pure ACKs are marked. TCP can always enter an idle period just after a loss or CE mark is received, then if later the sender has something to send, cwnd will be lower. Cwnd is already reduced exponentially during an idle period.

This is all part of the fairly arbitrary rules on how to evolve cwnd during an idle period. Nonetheless, while idling, I think it is sensible to reduce cwnd more, if more of any pure ACKs sent during the idle period are picking up congestion markings. I don't think we should recommend the converse: i.e. if the congestion was a long time ago, we should not recommend that cwnd can be increased again.

However, this is an area where I think implementers should be allowed to experiment, and I think the specs allow enough flexibility to do so.



  • Section 3.2.4 Window Probe - Adding ECT to window probes is really good because this traffic is not too large on any connection and it requires the peer to respond so that there is a way to echo the CE marking. One modification that might be worth discussing is to require congestion response to CE marking on a window probe only when the receive window is opened. I will try to explain why this is reasonable. If congestion at the bottleneck link is transient, then lowering the congestion window in response to CE on a window probe that does not open the receive window might not be necessary because there won’t be any data sent afterwards. This can actually happen multiple times on a connection because a connection can go on for a long time sending multiple window probes when the peer does not open the window. So reducing congestion window only when the receive window is opened as a response to CE seems to be accurate in terms of timing and reaction to congestion notification.
[BB] On the other hand, if the window was constrained solely because the receive window was low and there had been a CE mark on a window probe many round trips ago, but not on more recent window probes, it would not be correct to reduce cwnd such a long time after the congestion had occurred.

I think it would be better to reduce cwnd immediately there is a CE on a window probe, increase cwnd as normal for every non-CE-marked window probe (even if rwnd is still the limiting factor). But also rely on cwnd validation so that cwnd cannot grow excessively if it is not being used.


  • Section 3.2.7 Retransmissions - If a connection doesn’t set ECT on a SYN because it does not support AccECN feedback (due to fallback mechanisms or something else), then the first data packet will be the first packet on a connection with ECT marking on it. If it is dropped, sending retransmissions without ECT might make it go through if there is a middle box that incorrectly drops packets with ECT marking. I think, this detection and fallback mechanism must be somehow included in the proposal to mark retransmissions with ECT.
[BB] Good point. I had figured that fall-back only needed to be considered for the SYN or SYN-ACK. But you're right that, if the SYN is not-ECT, fall-back might be needed later (altho, as already mentioned, we have not seen a need in measurements so far). This will generally only apply to the C->S half-connection.

This is a general point about fall-back that happens to be noticed when both data and retransmissions fail to get through. So I think we ought to add a general point about fall-back as a new subsection of section 3, rather than writing this in the retransmissions subjection. I propose this text:
3.2.8 General Fall-Back

Consider a host that has sent the first packet on a half-connection (SYN or SYN/ACK) without ECT set and it has been acknowledged. If this host's retransmission timer expires more than once for all subsequent packet(s) it sends with ECT set, it SHOULD retransmit the packet(s) with not-ECT set. If these not-ECT packet(s) are acknowledged without any further losses, it is RECOMMENDED that the host disables setting ECT on all subsequent packets of the half-connection. It could also cache this failure.



Another point to note is that a connection should be already in recovery and must have adjusted it’s congestion window before sending a retransmission because it detected loss. If it further detects that there was CE marking on a retransmitted packet then it is not clear if it needs to adjust the congestion window again. Adding some clarification here will be good.
[BB] Yes. We already say:
   If the TCP sender receives feedback that a retransmitted packet was
   CE-marked, it will react as it would to any feedback of CE-marking on
   a data packet.
Do you have a suggestion for clearer text? Perhaps:
   If the TCP sender receives feedback that a retransmitted packet was
   CE-marked, it will react as it would to any feedback of CE-marking on
   a data packet, in addition to its original reaction to the loss that 
   caused the retransmission.

RFC5681 already says:
   Loss in two successive windows of data, or the loss of a
   retransmission, should be taken as two indications of congestion and,
   therefore, cwnd (and ssthresh) MUST be lowered twice in this case.
It's hard to be more specific because we didn't want to contradict other congestion control schemes (e.g. some respond to at least one mark per RTT, others respond to the extent of CE marking).



  • Tail loss probe - I think it will also be useful to include some text about CE marking on probe packets that a connection might send in response to tail loss (draft-dukkipati-tcpm-tcp-loss-probe-01.txt).
[BB] Well, I would like to resist mission creep. The scope of our draft is intended to be about setting ECT on packets where it was previously prohibited.

We have included interactions with SCTP, TFO and IW10 in "5.  Interaction with popular variants or derivatives of TCP" because they have been published and can no longer be easily changed.

For TLP, it's not even adopted in TCP yet (although I'm sure it is widely used). So I think it's up to the authors of this draft to say whether ECT should be set on a TLP and what the response to a CE-marked TLP should be.


  • Implementation or deployment related comments - The document refers to other drafts or experimental RFCs as possible actions that can be taken in several scenarios. For example AccECN, RFC 5690, RFC 7567 etc,. Even though implementing and deploying these specifications is possible, they may not be implemented unless these specifications are tightly bound together. A casual reader might understand that implementing multiple of these RFCS will make the system work well. But for someone to implement and deploy these specifications, it is not clear if some or all of these implementations will need to be supported. It will be good to make a recommendation for the minimum set of specifications that need to be implemented — may be after some more discussion.
[BB] If my co-author agrees, we can do this. I would recommend the following complements (both normatively referenced):
* AccECN
* RFC5691 (robustness to blind in-window attacks).

As a reciprocal recommendation, currently, the Intro to the AccECN draft says:
   It is likely (but not required) that the AccECN protocol will be
   implemented along with the following experimental additions to the
   TCP-ECN protocol: ECN-capable TCP control packets and retransmissions
   [I-D.bagnulo-tcpm-generalized-ecn], which includes the ECN-capable
   SYN-ACK experiment [RFC5562]; and testing receiver non-compliance
   [I-D.moncaster-tcpm-rcv-cheat].


The following are good, but I don't think they qualify as complementary to ECN++:
* RFC5690 (ACKcc). It is merely optional and "not incompatible".
* Similarly for TFO and IW10. Optional but not incompatible.
* RFC7567 is about AQM in the network, so I don't it would help an implementer to say it is complementary, as host implementers cannot control where their implementation is used.
* Originally we were going to recommend RFC5562 (ECN+ i.e. ECT on SYN-ACK packets), but once we realized it was over-conservative, we wrote a less conservative alternative directly into this ECN++ draft.


More generally, I know some people are starting to get really confused over how to put together all the piecemeal modifications to ECN. I think that would require an informational "ECN roadmap" draft. No promises, but I guess I am someone who would be well-placed to know what to write in such a draft.



  • Fallback mechanisms - The document also discusses several fallback mechanisms to handle incompatibilities in the network. If we want implementations to consider these cases, it will be useful to formalize these detection and fallback mechanisms. I found that some of these mechanisms are being discussed in section 4 which was tagged as informative.

[BB] I have just checked, and I cannot find any case where there is fall-back text in section 4 that ought to be normative. If you found any, pls say where. We tried to ensure that the recommended approach was always in section 3, even if section 4 discussed (then rejected) alternatives.

Overall, the document is written well and discusses multiple aspects of the proposed changes both on the end hosts and in the network. It is useful to have discussions on the proposed changes and to drive measurements that are needed to collect data to support or validate some of the assumptions made.

[BB] Thanks.

In summary, as this conversation progresses, we might agree further changes. However, so far I have queued up the following list of changes to the text to address your points:
* Intro: Recommend complementary RFCs or drafts
* 3.2.1.3: Clarify that using IW=1SMSS only applies when using the strategies recommended in the previous two sections.
* When fall-back due to ECT on SYN (3.2.1.4) or SYN-ACK (3.2.2.3), consider disabling ECT on other control packets (esp. pure ACKs).
* Add detection of black-holing of pure ACKs as an open issue (hence why we have to take the approach in the previous bullet)
* Add extra section on general fall-back if no ECT packet has ever been ack'd
* And we will certainly acknowledge your contribution, and I hope you will continue to track changes to this draft carefully and let us know if you have implementation experience - thank you.


Bob


Thanks,
Padma




  1. Working group acceptance call
     draft-bagnulo-tcpm-generalized-ecn-04
     (Scharf, Michael (Nokia - DE/Stuttgart))


----------------------------------------------------------------------

Message: 1
Date: Fri, 16 Jun 2017 06:06:43 +0000
From: "Scharf, Michael (Nokia - DE/Stuttgart)"
<michael.scharf@nokia.com>
To: "tcpm@ietf.org" <tcpm@ietf.org>
Cc: "tcpm-chairs@ietf.org" <tcpm-chairs@ietf.org>
Subject: [tcpm] Working group acceptance call
draft-bagnulo-tcpm-generalized-ecn-04
Message-ID:
<AM5PR0701MB2547FBCDE61B1757560F217993C10@AM5PR0701MB2547.eurprd07.prod.outlook.com>

Content-Type: text/plain; charset="us-ascii"

Hi all,

As requested by the authors, this e-mail starts a working group acceptance call for draft-bagnulo-tcpm-generalized-ecn-04, which will run on the list until June 30.

The proposal is to add a new milestone to the  TCPM charter

 Submit document on adding Explicit Congestion Notification (ECN) to TCP Control Packets to the IESG for publication as Experimental RFC

and to use draft-bagnulo-tcpm-generalized-ecn as a starting point.

If you believe that TCPM should work on a document in this space, and in particular if you are willing to review it, please reply to this e-mails. Please also speak up if you have any concerns or objections.

Thanks

Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailarchive.ietf.org/arch/browse/tcpm/attachments/20170616/151f93e9/attachment.html>

------------------------------

Subject: Digest Footer

_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm


------------------------------

End of tcpm Digest, Vol 158, Issue 7
************************************



_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm


-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/
--------------CEDFA5E62218A302B96D53B8-- From nobody Mon Jun 19 11:38:53 2017 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 07E9313154D for ; Mon, 19 Jun 2017 11:38:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.989 X-Spam-Level: X-Spam-Status: No, score=-1.989 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_MIME_MALF=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=bobbriscoe.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rDUqn_vCDM2N for ; Mon, 19 Jun 2017 11:38:47 -0700 (PDT) Received: from server.dnsblock1.com (server.dnsblock1.com [85.13.236.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB2281317FF for ; Mon, 19 Jun 2017 11:38:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Type:In-Reply-To:MIME-Version:Date: Message-ID:References:Cc:To:Subject:From:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=d9vc6X9xAckgwYutJTtaU1w+/7w6xmcp03xee6I/0o4=; b=U9DjzR23rFLRTorAObgyKcU73 kOM74j2n6T0cJ3HDrJWqdb16FJd1VjSzyFyj/N7PTlVYRHnRMhgonlq/bqNrdVKywr72lTuFdwthm 6iOEBzLk5YcnB6zfgFaDI6Q8ejYYRVwtTYvReX5eO/GmoJcHOqtfgjtRS52hRBeYhk034w1IJIFDD fF7FsXQysLhK0LvZEb9r4o4jq2vTsnC50aIVN007IifNpBzmEGxiV7SsIoz1yrlhYuUThCZu4WnRv 8+eYrPNs7mo7nlQzyhUBizKKRP+SeuASST0O0MF9Rww9wBFP5xi1hThys+X4tFW6CFzkSe7nLBHyU SFBReGzCw==; Received: from 167.6.208.46.dyn.plus.net ([46.208.6.167]:35494 helo=[192.168.0.6]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89) (envelope-from ) id 1dN1ZU-0001cx-BR; Mon, 19 Jun 2017 19:38:45 +0100 From: Bob Briscoe To: Padma Bhooma Cc: tcpm@ietf.org, marcelo bagnulo braun References: Message-ID: Date: Mon, 19 Jun 2017 19:38:43 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------21B4D23B7319942F3EDDB943" Content-Language: en-GB X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.dnsblock1.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - bobbriscoe.net X-Get-Message-Sender-Via: server.dnsblock1.com: authenticated_id: in@bobbriscoe.net X-Authenticated-Sender: server.dnsblock1.com: in@bobbriscoe.net Archived-At: Subject: Re: [tcpm] Working group acceptance call draft-bagnulo-tcpm-generalized-ecn-04 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jun 2017 18:38:52 -0000 This is a multi-part message in MIME format. --------------21B4D23B7319942F3EDDB943 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Padma, [re-sending - somehow my email client missed you off the distr.] On 17/06/17 17:27, Padma Bhooma wrote: > Hi Marcelo and Bob, > > I have reviewed the document draft-bagnulo-tcpm-generalized-ecn-04 and > I am sending my comments below. Overall, I think there is value in > working on these additions or enhancements to RFC 3168 in tcpm working > group. I am willing to review and provide feedback as needed. > > * *Section 3.2.1.3 *- If the SYN-ACK does not support AccECN, TCP > must conservatively reduce its IW and SHOULD reduce it to 1 SMSS. > This clause is very conservative because AccECN support can be > deployed on servers slowly. Even if both end hosts support AccECN, > there are networks with performance proxies that will not allow > the feedback to propagate correctly. On those networks, TCP > connections with ECT on SYN will always start with 1MSS of IW. I > think this is too conservative and might add multiple RTT to grow > the window. I agree with the value in adding ECT marking to SYN > and SYN-ACK in terms of the latency benefits that might bring to > an end user. > [BB] We have structured the document to just recommend the preferred approach in the normative spec (section 3), then discuss the rationale and possible alternatives in section 4. The sections just before 3.2.1.3 recommend: - 3.2.1.1: the client uses ECT optimistically - 3.2.1.2: but the client caches servers that don't recognize ECT. This is the "optimistic ECT and cache failures" strategy discussed in 4.2.1 (tagged as 'S2B'). The requirement to reduce IW to 1SMSS only applies if the client is adopting this strategy and discovers the server does not support AccECN. Perhaps we didn't make that clear? We have given 3 reasons for why this conservatism will rarely harm performance: 1) With this strategy, IW=1SMSS will only be needed the first time a client accesses a non-AccECN proxy or server. 2) During transition, this conservative IW=1SMSS will only ever be necessary for the client to server half-connection, not server to client. According to Yuchung Cheng, client Web requests are rarely greater than 1 segment (no data openly available). Do you have any data to corroborate (or contradict) this? I think in non-Web apps, the initial client request would often fit within 1 packet too (e.g. email, ftp, ssh, scp, etc). 3) Fall-back to 1SMSS is written as SHOULD rather than MUST. And refers to text later that says under what conditions you can use a higher IW. > * I think “pessimistic ECT and cache successes†strategy described > in 4.2.1 sounds like a reasonable one. > [BB] What's your reasoning for preferring this one? We recommended "optimistic ECT and cache failures". > > * *Section 3.2.3 ECT marking on Pure Acks* - It felt like the > document suggested further discussion on setting ECT on pure Acks, > please correct me if I am wrong here. Setting ECT on pure Acks can > increase the load on an AQM that might already be under load. This > is because the number of Acks can be large and the information > conveyed to the peer is redundant because asks are cumulative. TCP > acknowledgements also do not solicit a response from the peer most > of the times. So the chances of not echoing CE on an Ack is high. > [BB] Let's take these points one at a time: PB: Setting ECT on pure ACKs could increase the load on an AQM BB: An AQM processes packets of all sizes anyway. If pure ACKs are not ECT, it still has to decide whether to drop each pure ACK. Marking instead of dropping doesn't make any more work for the AQM. PB: The information conveyed to the peer is redundant because ACKs are cumulative. BB: Just because the ACKnumber info is superseded by the next ACK does not mean the ECN marking is superseded. PB: TCP acknowledgements do not solicit a response from the peer most of the times. So the chances of not echoing CE on an Ack is high. BB: Just because pure ACKs do not solicit a specific response (no ACK of an ACK) does not mean the data sender is not continuing to send data packets, on which ECE can be set (if RFC3168 feedback) or on which the CE counter can be increased (AccECN feedback). RFC3168 actually says this: (One simple possibility would be for the sender to reduce its congestion window when it receives a pure ACK packet with the CE codepoint set). Consider this pure ACK example with data solely in the S->C direction, where S is the server. * Say 3 in 1000 pure ACKs in the C->S direction are CE-marked, meaning the C->S marking probability is 0.3% * This might be because 0.3% of data packets in other flows (e.g. a YouTube upload) are being CE-marked as well. * So S needs to tell C that it has seen 3 CE marked packets (which it will do on the data packets it is sending, whether with RFC3168 feedback or AccECN feedback). * C is not (currently) sending any data to S, but it will reduce its cwnd for if it does start sending data. > * It is also difficult to detect if an Ack is dropped by an > incompatible middle box because of ECT marking on it since we do > not retransmit Acks.. So the fallback mechanisms will be limited. > [BB] You're correct in all respects here. Nonetheless, I have three responses: * We have been doing millions of measurements over fixed and mobile networks, using a machine we control on both sides and checking a sent ECT packet is also received. So far, we have not seen any difference in the treatment of any control packet if set to ECT vs not-ECT. * Section 6.1.4 of RFC3168 hinted that in future pure ACKs might be set to ECT. So if a security middlebox is trying to enforce RFC3168, it still might allow ECT pure ACKs to pass. * Nonetheless, if there were a middlebox that dropped ECT pure ACKs, you are right that it could black-hole all ECT pure ACKs and stall a connection. And there would be no easy way to detect the specific cause of the problem and stop setting ECT on pure ACKs. * We should at least say that if fall-back has to be used because ECT SYNs or SYN-ACKs are not getting through, then ECT ought not to be used on pure ACKs either. This is a good reason for why this protocol is experimental. However, given we have not so far found this problem in practice, I think it's OK to go ahead. But I agree that we should note that this is an open issue. > * In Section 4.4.1 (Cwnd response to CE-marking on Pure Acks), the > document says that we can echo a CE received on a pure ack on a > data segment that will be sent later. In general, I think any > congestion notification is relevant only for a short period of > time probably in the order of a typical RTT. Once that time window > passes, it may not be correct to respond to a delayed congestion > notification. So echoing CE from a pure Ack on a data segment sent > much later may not be the correct thing to do. > [BB] This is true. However, this point applies generally to idle periods, not just when pure ACKs are marked. TCP can always enter an idle period just after a loss or CE mark is received, then if later the sender has something to send, cwnd will be lower. Cwnd is already reduced exponentially during an idle period. This is all part of the fairly arbitrary rules on how to evolve cwnd during an idle period. Nonetheless, while idling, I think it is sensible to reduce cwnd more, if more of any pure ACKs sent during the idle period are picking up congestion markings. I don't think we should recommend the converse: i.e. if the congestion was a long time ago, we should not recommend that cwnd can be increased again. However, this is an area where I think implementers should be allowed to experiment, and I think the specs allow enough flexibility to do so. > > * *Section 3.2.4 Window Probe* - Adding ECT to window probes is > really good because this traffic is not too large on any > connection and it requires the peer to respond so that there is a > way to echo the CE marking. One modification that might be worth > discussing is to require congestion response to CE marking on a > window probe only when the receive window is opened. I will try to > explain why this is reasonable. If congestion at the bottleneck > link is transient, then lowering the congestion window in response > to CE on a window probe that does not open the receive window > might not be necessary because there won’t be any data sent > afterwards. This can actually happen multiple times on a > connection because a connection can go on for a long time sending > multiple window probes when the peer does not open the window. So > reducing congestion window only when the receive window is opened > as a response to CE seems to be accurate in terms of timing and > reaction to congestion notification. > [BB] On the other hand, if the window was constrained solely because the receive window was low and there had been a CE mark on a window probe many round trips ago, but not on more recent window probes, it would not be correct to reduce cwnd such a long time after the congestion had occurred. I think it would be better to reduce cwnd immediately there is a CE on a window probe, increase cwnd as normal for every non-CE-marked window probe (even if rwnd is still the limiting factor). But also rely on cwnd validation so that cwnd cannot grow excessively if it is not being used. > > * *Section 3.2.7 Retransmissions *- If a connection doesn’t set ECT > on a SYN because it does not support AccECN feedback (due to > fallback mechanisms or something else), then the first data packet > will be the first packet on a connection with ECT marking on it. > If it is dropped, sending retransmissions without ECT might make > it go through if there is a middle box that incorrectly drops > packets with ECT marking. I think, this detection and fallback > mechanism must be somehow included in the proposal to mark > retransmissions with ECT. > [BB] Good point. I had figured that fall-back only needed to be considered for the SYN or SYN-ACK. But you're right that, if the SYN is not-ECT, fall-back might be needed later (altho, as already mentioned, we have not seen a need in measurements so far). This will generally only apply to the C->S half-connection. This is a general point about fall-back that happens to be noticed when both data and retransmissions fail to get through. So I think we ought to add a general point about fall-back as a new subsection of section 3, rather than writing this in the retransmissions subjection. I propose this text: 3.2.8 General Fall-Back Consider a host that has sent the first packet on a half-connection (SYN or SYN/ACK) without ECT set and it has been acknowledged. If this host's retransmission timer expires more than once for all subsequent packet(s) it sends with ECT set, it SHOULD retransmit the packet(s) with not-ECT set. If these not-ECT packet(s) are acknowledged without any further losses, it is RECOMMENDED that the host disables setting ECT on all subsequent packets of the half-connection. It could also cache this failure. > > Another point to note is that a connection should be already in > recovery and must have adjusted it’s congestion window before > sending a retransmission because it detected loss. If it further > detects that there was CE marking on a retransmitted packet then > it is not clear if it needs to adjust the congestion window again. > Adding some clarification here will be good. > [BB] Yes. We already say: If the TCP sender receives feedback that a retransmitted packet was CE-marked, it will react as it would to any feedback of CE-marking on a data packet. Do you have a suggestion for clearer text? Perhaps: If the TCP sender receives feedback that a retransmitted packet was CE-marked, it will react as it would to any feedback of CE-marking on a data packet, in addition to its original reaction to the loss that caused the retransmission. RFC5681 already says: Loss in two successive windows of data, or the loss of a retransmission, should be taken as two indications of congestion and, therefore, cwnd (and ssthresh) MUST be lowered twice in this case. It's hard to be more specific because we didn't want to contradict other congestion control schemes (e.g. some respond to at least one mark per RTT, others respond to the extent of CE marking). > > * *Tail loss probe *- I think it will also be useful to include some > text about CE marking on probe packets that a connection might > send in response to tail loss > (draft-dukkipati-tcpm-tcp-loss-probe-01.txt). > [BB] Well, I would like to resist mission creep. The scope of our draft is intended to be about setting ECT on packets where it was previously prohibited. We have included interactions with SCTP, TFO and IW10 in "5. Interaction with popular variants or derivatives of TCP " because they have been published and can no longer be easily changed. For TLP, it's not even adopted in TCP yet (although I'm sure it is widely used). So I think it's up to the authors of this draft to say whether ECT should be set on a TLP and what the response to a CE-marked TLP should be. > > * *Implementation or deployment related comments - *The document > refers to other drafts or experimental RFCs as possible actions > that can be taken in several scenarios. For example AccECN, RFC > 5690, RFC 7567 etc,. Even though implementing and deploying these > specifications is possible, they may not be implemented unless > these specifications are tightly bound together. A casual reader > might understand that implementing multiple of these RFCS will > make the system work well. But for someone to implement and deploy > these specifications, it is not clear if some or all of these > implementations will need to be supported. It will be good to make > a recommendation for the minimum set of specifications that need > to be implemented — may be after some more discussion. > [BB] If my co-author agrees, we can do this. I would recommend the following complements (both normatively referenced): * AccECN * RFC5691 (robustness to blind in-window attacks). As a reciprocal recommendation, currently, the Intro to the AccECN draft says: It is likely (but not required) that the AccECN protocol will be implemented along with the following experimental additions to the TCP-ECN protocol: ECN-capable TCP control packets and retransmissions [I-D.bagnulo-tcpm-generalized-ecn ], which includes the ECN-capable SYN-ACK experiment [RFC5562 ]; and testing receiver non-compliance [I-D.moncaster-tcpm-rcv-cheat ]. The following are good, but I don't think they qualify as complementary to ECN++: * RFC5690 (ACKcc). It is merely optional and "not incompatible". * Similarly for TFO and IW10. Optional but not incompatible. * RFC7567 is about AQM in the network, so I don't it would help an implementer to say it is complementary, as host implementers cannot control where their implementation is used. * Originally we were going to recommend RFC5562 (ECN+ i.e. ECT on SYN-ACK packets), but once we realized it was over-conservative, we wrote a less conservative alternative directly into this ECN++ draft. More generally, I know some people are starting to get really confused over how to put together all the piecemeal modifications to ECN. I think that would require an informational "ECN roadmap" draft. No promises, but I guess I am someone who would be well-placed to know what to write in such a draft. > > * > *Fallback mechanisms *- The document also discusses several > fallback mechanisms to handle incompatibilities in the network. If > we want implementations to consider these cases, it will be useful > to formalize these detection and fallback mechanisms. I found that > some of these mechanisms are being discussed in section 4 which > was tagged as informative. > [BB] I have just checked, and I cannot find any case where there is fall-back text in section 4 that ought to be normative. If you found any, pls say where. We tried to ensure that the recommended approach was always in section 3, even if section 4 discussed (then rejected) alternatives. > Overall, the document is written well and discusses multiple aspects > of the proposed changes both on the end hosts and in the network. It > is useful to have discussions on the proposed changes and to drive > measurements that are needed to collect data to support or validate > some of the assumptions made. [BB] Thanks. In summary, as this conversation progresses, we might agree further changes. However, so far I have queued up the following list of changes to the text to address your points: * Intro: Recommend complementary RFCs or drafts * 3.2.1.3: Clarify that using IW=1SMSS only applies when using the strategies recommended in the previous two sections. * When fall-back due to ECT on SYN (3.2.1.4) or SYN-ACK (3.2.2.3), consider disabling ECT on other control packets (esp. pure ACKs). * Add detection of black-holing of pure ACKs as an open issue (hence why we have to take the approach in the previous bullet) * Add extra section on general fall-back if no ECT packet has ever been ack'd * And we will certainly acknowledge your contribution, and I hope you will continue to track changes to this draft carefully and let us know if you have implementation experience - thank you. Bob > > Thanks, > Padma > > >> >> >> 1. Working group acceptance call >> draft-bagnulo-tcpm-generalized-ecn-04 >> (Scharf, Michael (Nokia - DE/Stuttgart)) >> >> >> ---------------------------------------------------------------------- >> >> Message: 1 >> Date: Fri, 16 Jun 2017 06:06:43 +0000 >> From: "Scharf, Michael (Nokia - DE/Stuttgart)" >> > >> To: "tcpm@ietf.org " > > >> Cc: "tcpm-chairs@ietf.org " >> > >> Subject: [tcpm] Working group acceptance call >> draft-bagnulo-tcpm-generalized-ecn-04 >> Message-ID: >> > > >> >> Content-Type: text/plain; charset="us-ascii" >> >> Hi all, >> >> As requested by the authors, this e-mail starts a working group >> acceptance call for draft-bagnulo-tcpm-generalized-ecn-04, which will >> run on the list until June 30. >> >> The proposal is to add a new milestone to the TCPM charter >> >> Submit document on adding Explicit Congestion Notification (ECN) to >> TCP Control Packets to the IESG for publication as Experimental RFC >> >> and to use draft-bagnulo-tcpm-generalized-ecn as a starting point. >> >> If you believe that TCPM should work on a document in this space, and >> in particular if you are willing to review it, please reply to this >> e-mails. Please also speak up if you have any concerns or objections. >> >> Thanks >> >> Michael >> -------------- next part -------------- >> An HTML attachment was scrubbed... >> URL: >> >> >> ------------------------------ >> >> Subject: Digest Footer >> >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm >> >> >> ------------------------------ >> >> End of tcpm Digest, Vol 158, Issue 7 >> ************************************ > > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm -- ________________________________________________________________ Bob Briscoehttp://bobbriscoe.net/ --------------21B4D23B7319942F3EDDB943 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Padma, [re-sending - somehow my email client missed you off the distr.]

On 17/06/17 17:27, Padma Bhooma wrote:
Hi Marcelo and Bob,

I have reviewed the document draft-bagnulo-tcpm-generalized-ecn-04 and I am sending my comments below. Overall, I think there is value in working on these additions or enhancements to RFC 3168 in tcpm working group. I am willing to review and provide feedback as needed.

  • Section 3.2.1.3 - If the SYN-ACK does not support AccECN, TCP must conservatively reduce its IW and SHOULD reduce it to 1 SMSS. This clause is very conservative because AccECN support can be deployed on servers slowly. Even if both end hosts support AccECN, there are networks with performance proxies that will not allow the feedback to propagate correctly. On those networks, TCP connections with ECT on SYN will always start with 1MSS of IW. I think this is too conservative and might add multiple RTT to grow the window. I agree with the value in adding ECT marking to SYN and SYN-ACK in terms of the latency benefits that might bring to an end user.
[BB] We have structured the document to just recommend the preferred approach in the normative spec (section 3), then discuss the rationale and possible alternatives in section 4. The sections just before 3.2.1.3 recommend:
  - 3.2.1.1: the client uses ECT optimistically
  - 3.2.1.2: but the client caches servers that don't recognize ECT.
This is the "optimistic ECT and cache failures" strategy discussed in 4.2.1 (tagged as 'S2B').

The requirement to reduce IW to 1SMSS only applies if the client is adopting this strategy and discovers the server does not support AccECN. Perhaps we didn't make that clear?

We have given 3 reasons for why this conservatism will rarely harm performance:

1) With this strategy, IW=1SMSS will only be needed the first time a client accesses a non-AccECN proxy or server.

2) During transition, this conservative IW=1SMSS will only ever be necessary for the client to server half-connection, not server to client.
According to Yuchung Cheng, client Web requests are rarely greater than 1 segment (no data openly available). Do you have any data to corroborate (or contradict) this? I think in non-Web apps, the initial client request would often fit within 1 packet too (e.g. email, ftp, ssh, scp, etc).

3) Fall-back to 1SMSS is written as SHOULD rather than MUST. And refers to text later that says under what conditions you can use a higher IW.

  • I think “pessimistic ECT and cache successes†strategy described in 4.2.1 sounds like a reasonable one.
[BB] What's your reasoning for preferring this one? We recommended "optimistic ECT and cache failures".


  • Section 3.2.3 ECT marking on Pure Acks - It felt like the document suggested further discussion on setting ECT on pure Acks, please correct me if I am wrong here. Setting ECT on pure Acks can increase the load on an AQM that might already be under load. This is because the number of Acks can be large and the information conveyed to the peer is redundant because asks are cumulative. TCP acknowledgements also do not solicit a response from the peer most of the times. So the chances of not echoing CE on an Ack is high.
[BB] Let's take these points one at a time:
PB: Setting ECT on pure ACKs could increase the load on an AQM
BB: An AQM processes packets of all sizes anyway. If pure ACKs are not ECT, it still has to decide whether to drop each pure ACK. Marking instead of dropping doesn't make any more work for the AQM.

PB: The information conveyed to the peer is redundant because ACKs are cumulative.
BB: Just because the ACKnumber info is superseded by the next ACK does not mean the ECN marking is superseded.

PB: TCP acknowledgements do not solicit a response from the peer most of the times. So the chances of not echoing CE on an Ack is high.
BB: Just because pure ACKs do not solicit a specific response (no ACK of an ACK) does not mean the data sender is not continuing to send data packets, on which ECE can be set (if RFC3168 feedback) or on which the CE counter can be increased (AccECN feedback).

RFC3168 actually says this:
   (One simple possibility would be for the sender to reduce its
   congestion window when it receives a pure ACK packet with the CE
   codepoint set).
Consider this pure ACK example with data solely in the S->C direction, where S is the server.
  * Say 3 in 1000 pure ACKs in the C->S direction are CE-marked, meaning the C->S marking probability is 0.3%
  * This might be because 0.3% of data packets in other flows (e.g. a YouTube upload) are being CE-marked as well.
  * So S needs to tell C that it has seen 3 CE marked packets (which it will do on the data packets it is sending, whether with RFC3168 feedback or AccECN feedback).
  * C is not (currently) sending any data to S, but it will reduce its cwnd for if it does start sending data.

  • It is also difficult to detect if an Ack is dropped by an incompatible middle box because of ECT marking on it since we do not retransmit Acks.. So the fallback mechanisms will be limited.
[BB] You're correct in all respects here. Nonetheless, I have three responses:
  * We have been doing millions of measurements over fixed and mobile networks, using a machine we control on both sides and checking a sent ECT packet is also received. So far, we have not seen any difference in the treatment of any control packet if set to ECT vs not-ECT.
  * Section 6.1.4 of RFC3168 hinted that in future pure ACKs might be set to ECT. So if a security middlebox is trying to enforce RFC3168, it still might allow ECT pure ACKs to pass.
  * Nonetheless, if there were a middlebox that dropped ECT pure ACKs, you are right that it could black-hole all ECT pure ACKs and stall a connection. And there would be no easy way to detect the specific cause of the problem and stop setting ECT on pure ACKs.
  * We should at least say that if fall-back has to be used because ECT SYNs or SYN-ACKs are not getting through, then ECT ought not to be used on pure ACKs either.

This is a good reason for why this protocol is experimental. However, given we have not so far found this problem in practice, I think it's OK to go ahead. But I agree that we should note that this is an open issue.

  • In Section 4.4.1 (Cwnd response to CE-marking on Pure Acks), the document says that we can echo a CE received on a pure ack on a data segment that will be sent later. In general, I think any congestion notification is relevant only for a short period of time probably in the order of a typical RTT. Once that time window passes, it may not be correct to respond to a delayed congestion notification. So echoing CE from a pure Ack on a data segment sent much later may not be the correct thing to do.
[BB] This is true.
However, this point applies generally to idle periods, not just when pure ACKs are marked. TCP can always enter an idle period just after a loss or CE mark is received, then if later the sender has something to send, cwnd will be lower. Cwnd is already reduced exponentially during an idle period.

This is all part of the fairly arbitrary rules on how to evolve cwnd during an idle period. Nonetheless, while idling, I think it is sensible to reduce cwnd more, if more of any pure ACKs sent during the idle period are picking up congestion markings. I don't think we should recommend the converse: i.e. if the congestion was a long time ago, we should not recommend that cwnd can be increased again.

However, this is an area where I think implementers should be allowed to experiment, and I think the specs allow enough flexibility to do so.



  • Section 3.2.4 Window Probe - Adding ECT to window probes is really good because this traffic is not too large on any connection and it requires the peer to respond so that there is a way to echo the CE marking. One modification that might be worth discussing is to require congestion response to CE marking on a window probe only when the receive window is opened. I will try to explain why this is reasonable. If congestion at the bottleneck link is transient, then lowering the congestion window in response to CE on a window probe that does not open the receive window might not be necessary because there won’t be any data sent afterwards. This can actually happen multiple times on a connection because a connection can go on for a long time sending multiple window probes when the peer does not open the window. So reducing congestion window only when the receive window is opened as a response to CE seems to be accurate in terms of timing and reaction to congestion notification.
[BB] On the other hand, if the window was constrained solely because the receive window was low and there had been a CE mark on a window probe many round trips ago, but not on more recent window probes, it would not be correct to reduce cwnd such a long time after the congestion had occurred.

I think it would be better to reduce cwnd immediately there is a CE on a window probe, increase cwnd as normal for every non-CE-marked window probe (even if rwnd is still the limiting factor). But also rely on cwnd validation so that cwnd cannot grow excessively if it is not being used.


  • Section 3.2.7 Retransmissions - If a connection doesn’t set ECT on a SYN because it does not support AccECN feedback (due to fallback mechanisms or something else), then the first data packet will be the first packet on a connection with ECT marking on it. If it is dropped, sending retransmissions without ECT might make it go through if there is a middle box that incorrectly drops packets with ECT marking. I think, this detection and fallback mechanism must be somehow included in the proposal to mark retransmissions with ECT.
[BB] Good point. I had figured that fall-back only needed to be considered for the SYN or SYN-ACK. But you're right that, if the SYN is not-ECT, fall-back might be needed later (altho, as already mentioned, we have not seen a need in measurements so far). This will generally only apply to the C->S half-connection.

This is a general point about fall-back that happens to be noticed when both data and retransmissions fail to get through. So I think we ought to add a general point about fall-back as a new subsection of section 3, rather than writing this in the retransmissions subjection. I propose this text:
3.2.8 General Fall-Back

Consider a host that has sent the first packet on a half-connection (SYN or SYN/ACK) without ECT set and it has been acknowledged. If this host's retransmission timer expires more than once for all subsequent packet(s) it sends with ECT set, it SHOULD retransmit the packet(s) with not-ECT set. If these not-ECT packet(s) are acknowledged without any further losses, it is RECOMMENDED that the host disables setting ECT on all subsequent packets of the half-connection. It could also cache this failure.



Another point to note is that a connection should be already in recovery and must have adjusted it’s congestion window before sending a retransmission because it detected loss. If it further detects that there was CE marking on a retransmitted packet then it is not clear if it needs to adjust the congestion window again. Adding some clarification here will be good.
[BB] Yes. We already say:
   If the TCP sender receives feedback that a retransmitted packet was
   CE-marked, it will react as it would to any feedback of CE-marking on
   a data packet.
Do you have a suggestion for clearer text? Perhaps:
   If the TCP sender receives feedback that a retransmitted packet was
   CE-marked, it will react as it would to any feedback of CE-marking on
   a data packet, in addition to its original reaction to the loss that 
   caused the retransmission.

RFC5681 already says:
   Loss in two successive windows of data, or the loss of a
   retransmission, should be taken as two indications of congestion and,
   therefore, cwnd (and ssthresh) MUST be lowered twice in this case.
It's hard to be more specific because we didn't want to contradict other congestion control schemes (e.g. some respond to at least one mark per RTT, others respond to the extent of CE marking).



  • Tail loss probe - I think it will also be useful to include some text about CE marking on probe packets that a connection might send in response to tail loss (draft-dukkipati-tcpm-tcp-loss-probe-01.txt).
[BB] Well, I would like to resist mission creep. The scope of our draft is intended to be about setting ECT on packets where it was previously prohibited.

We have included interactions with SCTP, TFO and IW10 in "5.  Interaction with popular variants or derivatives of TCP" because they have been published and can no longer be easily changed.

For TLP, it's not even adopted in TCP yet (although I'm sure it is widely used). So I think it's up to the authors of this draft to say whether ECT should be set on a TLP and what the response to a CE-marked TLP should be.


  • Implementation or deployment related comments - The document refers to other drafts or experimental RFCs as possible actions that can be taken in several scenarios. For example AccECN, RFC 5690, RFC 7567 etc,. Even though implementing and deploying these specifications is possible, they may not be implemented unless these specifications are tightly bound together. A casual reader might understand that implementing multiple of these RFCS will make the system work well. But for someone to implement and deploy these specifications, it is not clear if some or all of these implementations will need to be supported. It will be good to make a recommendation for the minimum set of specifications that need to be implemented — may be after some more discussion.
[BB] If my co-author agrees, we can do this. I would recommend the following complements (both normatively referenced):
* AccECN
* RFC5691 (robustness to blind in-window attacks).

As a reciprocal recommendation, currently, the Intro to the AccECN draft says:
   It is likely (but not required) that the AccECN protocol will be
   implemented along with the following experimental additions to the
   TCP-ECN protocol: ECN-capable TCP control packets and retransmissions
   [I-D.bagnulo-tcpm-generalized-ecn], which includes the ECN-capable
   SYN-ACK experiment [RFC5562]; and testing receiver non-compliance
   [I-D.moncaster-tcpm-rcv-cheat].


The following are good, but I don't think they qualify as complementary to ECN++:
* RFC5690 (ACKcc). It is merely optional and "not incompatible".
* Similarly for TFO and IW10. Optional but not incompatible.
* RFC7567 is about AQM in the network, so I don't it would help an implementer to say it is complementary, as host implementers cannot control where their implementation is used.
* Originally we were going to recommend RFC5562 (ECN+ i.e. ECT on SYN-ACK packets), but once we realized it was over-conservative, we wrote a less conservative alternative directly into this ECN++ draft.


More generally, I know some people are starting to get really confused over how to put together all the piecemeal modifications to ECN. I think that would require an informational "ECN roadmap" draft. No promises, but I guess I am someone who would be well-placed to know what to write in such a draft.



  • Fallback mechanisms - The document also discusses several fallback mechanisms to handle incompatibilities in the network. If we want implementations to consider these cases, it will be useful to formalize these detection and fallback mechanisms. I found that some of these mechanisms are being discussed in section 4 which was tagged as informative.

[BB] I have just checked, and I cannot find any case where there is fall-back text in section 4 that ought to be normative. If you found any, pls say where. We tried to ensure that the recommended approach was always in section 3, even if section 4 discussed (then rejected) alternatives.

Overall, the document is written well and discusses multiple aspects of the proposed changes both on the end hosts and in the network. It is useful to have discussions on the proposed changes and to drive measurements that are needed to collect data to support or validate some of the assumptions made.

[BB] Thanks.

In summary, as this conversation progresses, we might agree further changes. However, so far I have queued up the following list of changes to the text to address your points:
* Intro: Recommend complementary RFCs or drafts
* 3.2.1.3: Clarify that using IW=1SMSS only applies when using the strategies recommended in the previous two sections.
* When fall-back due to ECT on SYN (3.2.1.4) or SYN-ACK (3.2.2.3), consider disabling ECT on other control packets (esp. pure ACKs).
* Add detection of black-holing of pure ACKs as an open issue (hence why we have to take the approach in the previous bullet)
* Add extra section on general fall-back if no ECT packet has ever been ack'd
* And we will certainly acknowledge your contribution, and I hope you will continue to track changes to this draft carefully and let us know if you have implementation experience - thank you.


Bob


Thanks,
Padma




  1. Working group acceptance call
     draft-bagnulo-tcpm-generalized-ecn-04
     (Scharf, Michael (Nokia - DE/Stuttgart))


----------------------------------------------------------------------

Message: 1
Date: Fri, 16 Jun 2017 06:06:43 +0000
From: "Scharf, Michael (Nokia - DE/Stuttgart)"
<michael.scharf@nokia.com>
To: "tcpm@ietf.org" <tcpm@ietf.org>
Cc: "tcpm-chairs@ietf.org" <tcpm-chairs@ietf.org>
Subject: [tcpm] Working group acceptance call
draft-bagnulo-tcpm-generalized-ecn-04
Message-ID:
<AM5PR0701MB2547FBCDE61B1757560F217993C10@AM5PR0701MB2547.eurprd07.prod.outlook.com>

Content-Type: text/plain; charset="us-ascii"

Hi all,

As requested by the authors, this e-mail starts a working group acceptance call for draft-bagnulo-tcpm-generalized-ecn-04, which will run on the list until June 30.

The proposal is to add a new milestone to the  TCPM charter

 Submit document on adding Explicit Congestion Notification (ECN) to TCP Control Packets to the IESG for publication as Experimental RFC

and to use draft-bagnulo-tcpm-generalized-ecn as a starting point.

If you believe that TCPM should work on a document in this space, and in particular if you are willing to review it, please reply to this e-mails. Please also speak up if you have any concerns or objections.

Thanks

Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailarchive.ietf.org/arch/browse/tcpm/attachments/20170616/151f93e9/attachment.html>

------------------------------

Subject: Digest Footer

_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm


------------------------------

End of tcpm Digest, Vol 158, Issue 7
************************************



_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm


-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/
--------------21B4D23B7319942F3EDDB943-- From nobody Tue Jun 20 10:32:13 2017 Return-Path: X-Original-To: tcpm@ietf.org Delivered-To: tcpm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FCDB13155E; Tue, 20 Jun 2017 10:32:11 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alvaro Retana To: "The IESG" Cc: draft-ietf-tcpm-dctcp@ietf.org, Michael Scharf , tcpm-chairs@ietf.org, tcpm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.55.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149797993105.24954.10383641844605203192.idtracker@ietfa.amsl.com> Date: Tue, 20 Jun 2017 10:32:11 -0700 Archived-At: Subject: [tcpm] Alvaro Retana's No Objection on draft-ietf-tcpm-dctcp-07: (with COMMENT) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jun 2017 17:32:11 -0000 Alvaro Retana has entered the following ballot position for draft-ietf-tcpm-dctcp-07: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-tcpm-dctcp/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Several nits: - The Abstract says that "This memo documents existing DCTCP implementations ([WINDOWS], [LINUX], [FREEBSD])..." But in reality it doesn't, it just points to those references that presumably contain implementation information. The [WINDOWS] reference is only used in the Abstract -- last I looked, there shouldn't be references there [rfc7322]. - "...and deployment experience ([MORGANSTANLEY])." Again, this draft doesn't document deployment experience, just points at it. - rfc7942 recommends that the Implementation Status section be removed. If the intent is to keep it, then consider putting a note so that the RFC Editor doesn't remove it.. - The fact that this document describes the Microsoft Windows Server 2012 implementation should be made clear from the start (in the Introduction). You could then also get rid of the extra text in Section 2. - The reference to [RFC3168-ERRATA3639] seems strange to me...not because it is pointing to the report, but because it is Informative, when the reference to RFC3168 is Normative. I would assume that because Errata3639 has been Verified, then it means it is now "part of" RFC3168, so I would think that there's no need to mention it separately... From nobody Tue Jun 20 12:54:45 2017 Return-Path: X-Original-To: tcpm@ietf.org Delivered-To: tcpm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B72B131634; Tue, 20 Jun 2017 12:54:37 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Spencer Dawkins To: "The IESG" Cc: draft-ietf-tcpm-dctcp@ietf.org, Michael Scharf , tcpm-chairs@ietf.org, michael.scharf@nokia.com, tcpm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.55.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149798847762.25011.10515345600177875775.idtracker@ietfa.amsl.com> Date: Tue, 20 Jun 2017 12:54:37 -0700 Archived-At: Subject: [tcpm] Spencer Dawkins' Yes on draft-ietf-tcpm-dctcp-07: (with COMMENT) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jun 2017 19:54:43 -0000 Spencer Dawkins has entered the following ballot position for draft-ietf-tcpm-dctcp-07: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-tcpm-dctcp/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I think Alvaro's nits in his ballot are worth a look, but I'm really glad to see this work moving forward, and wanted to thank the authors for a clear explanation of a TCP mechanism that I think I could implement myself. From nobody Tue Jun 20 22:53:58 2017 Return-Path: X-Original-To: tcpm@ietf.org Delivered-To: tcpm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 58E0E126DC2; Tue, 20 Jun 2017 22:53:56 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Terry Manderson To: "The IESG" Cc: draft-ietf-tcpm-dctcp@ietf.org, Michael Scharf , tcpm-chairs@ietf.org, michael.scharf@nokia.com, tcpm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.55.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149802443635.15737.7356677226773396033.idtracker@ietfa.amsl.com> Date: Tue, 20 Jun 2017 22:53:56 -0700 Archived-At: Subject: [tcpm] Terry Manderson's Yes on draft-ietf-tcpm-dctcp-07: (with COMMENT) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jun 2017 05:53:56 -0000 Terry Manderson has entered the following ballot position for draft-ietf-tcpm-dctcp-07: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-tcpm-dctcp/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for a well constructed document, and (IMHO) a nice approach to the issue. I noticed a few nits (some caught by Alvaro) and others that are either me reading late at night or typographical concerns (such as "If SYN , SYN-ACK" [comma placement] first line of section 3.5 - so please give it a thorough read through) From nobody Wed Jun 21 00:59:06 2017 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 949271317D0; Wed, 21 Jun 2017 00:58:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=netapp.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I09L2WtRhwOh; Wed, 21 Jun 2017 00:58:55 -0700 (PDT) Received: from mx142.netapp.com (mx142.netapp.com [216.240.21.19]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 64EFB131705; Wed, 21 Jun 2017 00:58:55 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.39,368,1493708400"; d="asc'?scan'208";a="195893426" Received: from vmwexchts04-prd.hq.netapp.com ([10.122.105.32]) by mx142-out.netapp.com with ESMTP; 21 Jun 2017 00:35:22 -0700 Received: from VMWEXCCAS06-PRD.hq.netapp.com (10.122.105.22) by VMWEXCHTS04-PRD.hq.netapp.com (10.122.105.32) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 21 Jun 2017 00:53:48 -0700 Received: from NAM01-BN3-obe.outbound.protection.outlook.com (10.120.60.153) by VMWEXCCAS06-PRD.hq.netapp.com (10.122.105.22) with Microsoft SMTP Server (TLS) id 15.0.1210.3 via Frontend Transport; Wed, 21 Jun 2017 00:53:48 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netapp.onmicrosoft.com; s=selector1-netapp-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=IHLZX6IoutsdbGYGOqI0LBhWyHWOIemQNYmyuEwzaTA=; b=P65QdijB5lLP0TRwmLSmca+zNagRH1njkFBtXFabdUYS5bPF23DG/odsxcG3j6bX9EFfXvpeZwJ3UJ1WddPRLeXeLaRLsusLc0sZNSls8PWlRSUL0VjQtXMYK636baMRSFz9nxlmk0PAyPS3JE6T9Pm9m9EIvOXKVCjQKr2YwLg= Received: from BLUPR06MB1764.namprd06.prod.outlook.com (10.162.224.150) by BLUPR06MB1761.namprd06.prod.outlook.com (10.162.224.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1178.14; Wed, 21 Jun 2017 07:53:52 +0000 Received: from BLUPR06MB1764.namprd06.prod.outlook.com ([10.162.224.150]) by BLUPR06MB1764.namprd06.prod.outlook.com ([10.162.224.150]) with mapi id 15.01.1178.023; Wed, 21 Jun 2017 07:53:52 +0000 From: "Eggert, Lars" To: Alvaro Retana CC: The IESG , "draft-ietf-tcpm-dctcp@ietf.org" , Michael Scharf , "tcpm-chairs@ietf.org" , "tcpm@ietf.org" Thread-Topic: Alvaro Retana's No Objection on draft-ietf-tcpm-dctcp-07: (with COMMENT) Thread-Index: AQHS6es9M5qrSk6lcUqg0cYHTwOgsqIu8zAA Date: Wed, 21 Jun 2017 07:53:52 +0000 Message-ID: <339DF022-9BB2-4484-9E87-8E059EE1EAD3@netapp.com> References: <149797993105.24954.10383641844605203192.idtracker@ietfa.amsl.com> In-Reply-To: <149797993105.24954.10383641844605203192.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3273) authentication-results: cisco.com; dkim=none (message not signed) header.d=none;cisco.com; dmarc=none action=none header.from=netapp.com; x-originating-ip: [2001:4ca0:0:f223:85e1:755e:7a96:46e2] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BLUPR06MB1761; 7:cfR8uYXBnArNEsyTUsf6J8kS/yajdjrotYD74m0AtsYn8Jphkc1XhsybRsSolKpzzYo2UWroh4egOTdKOqWkX/Zm4/JQ2FzKEg8kirVqJ3SzxoD8QaiBiJyrNncl690y4D1qrKZPe2bxp95LwWleQ0uv5lIWSBWkhxIX11ksqGaeKb5p8Uq10F4yGDSL5fZwCHUCM/FeWQjNcrcKkiP0qm3WRwYLxPKa+3gISFDFxZj3y9SSIB9iP+aSlWpDPkUEmc7eHKJ4V0loVFur4BOhppTpWICBhnJFZlMllCrPCTsdyFj1oLOtkRS3olA5EpvFtMYrp5Pq6AFU7W3bhzWTUAcpVCl8hnF1naE5/mRLNCu4aJtumQ4TCA4kgasgdWwdc6Qknxm1mToXoXNdD0GtraxUnXFp/027CAV+BK1cDwWeDeHIt05bM8mjLzeUuCfhpPoFp6m8W+jhaZ5l+13cj8E2NwV6kFq2mvH6WKjC9TFm2DvicG18LKBYuXJdrDiz/AtT3eRsz1d/ZRBs9HhYmCslKOjaW8NxQNsBMYW9R1O14Vojn56YryUfeOBEUTCD2BcGx7z7kbRgUmmc3SLcrdIdG++J84QEj/UV/aKmUFuSzLmm6QnoD3bDfixJv9mkWxQjGSZKxIrgz5U6in/BAiD/7xh1c9Cu7swylSHBbzyEQJb5ZYL7bG6zcLo7pfSJ5pg1PdEmc/xPkpQGgmWliM6pU8gqO4/4QkLUxOshTEJxAlBuUd1CGTEBYcVkPgzVC1Zvk+4wxKbHJUzW6CmfufzKgwQ3y7P+YO8rVa1N3CM= x-ms-office365-filtering-correlation-id: f68ec066-095c-4250-647f-08d4b87aa8e0 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(49563074)(201703131423075)(201703031133081); SRVR:BLUPR06MB1761; x-ms-traffictypediagnostic: BLUPR06MB1761: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(95692535739014); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(102415395)(6040450)(601004)(2401047)(8121501046)(5005006)(93006095)(93001095)(100000703101)(100105400095)(10201501046)(3002001)(6055026)(6041248)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123564025)(20161123560025)(20161123555025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BLUPR06MB1761; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BLUPR06MB1761; x-forefront-prvs: 0345CFD558 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39410400002)(39450400003)(39400400002)(39850400002)(39840400002)(24454002)(377424004)(76176999)(99286003)(54906002)(36756003)(8936002)(99936001)(50986999)(8676002)(81166006)(6512007)(53936002)(57306001)(478600001)(102836003)(6116002)(305945005)(45080400002)(4326008)(25786009)(122556002)(77096006)(14454004)(6486002)(229853002)(230783001)(33656002)(189998001)(6506006)(6436002)(5660300001)(6916009)(2950100002)(4001150100001)(7736002)(2900100001)(3660700001)(82746002)(3280700002)(86362001)(38730400002)(110136004)(83716003)(53546010); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR06MB1761; H:BLUPR06MB1764.namprd06.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/signed; boundary="Apple-Mail=_0FADD707-FD08-4ABE-B7AE-4B2D128C739E"; protocol="application/pgp-signature"; micalg=pgp-sha512 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Jun 2017 07:53:52.3943 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4b0911a0-929b-4715-944b-c03745165b3a X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR06MB1761 X-OriginatorOrg: netapp.com Archived-At: Subject: Re: [tcpm] Alvaro Retana's No Objection on draft-ietf-tcpm-dctcp-07: (with COMMENT) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jun 2017 07:58:58 -0000 --Apple-Mail=_0FADD707-FD08-4ABE-B7AE-4B2D128C739E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, thanks for the feddback. I have not discussed this with my co-authors, = but here is my personal response: On 2017-6-20, at 19:32, Alvaro Retana wrote: > Several nits: >=20 > - The Abstract says that "This memo documents existing DCTCP = implementations > ([WINDOWS], [LINUX], [FREEBSD])..." But in reality it doesn't, it = just points > to those references that presumably contain implementation = information. The draft documents what those implementations implement. I'm not sure = how to express this better. > The > [WINDOWS] reference is only used in the Abstract -- last I looked, = there > shouldn't be references there [rfc7322]. We can move those references to the introduction. > - "...and deployment experience ([MORGANSTANLEY])." Again, this draft = doesn't > document deployment experience, just points at it. Fair point. We'll rephrase. > - rfc7942 recommends that the Implementation Status section be = removed. If the > intent is to keep it, then consider putting a note so that the RFC = Editor > doesn't remove it.. No strong opinion here. I think we only added this since someone said we = should. I think all the content is mentioned elsewhere anyway. > - The fact that this document describes the Microsoft Windows Server = 2012 > implementation should be made clear from the start (in the = Introduction). You > could then also get rid of the extra text in Section 2. ACK > - The reference to [RFC3168-ERRATA3639] seems strange to me...not = because it is > pointing to the report, but because it is Informative, when the = reference to > RFC3168 is Normative. I would assume that because Errata3639 has been > Verified, then it means it is now "part of" RFC3168, so I would think = that > there's no need to mention it separately... I don't think errata can be normative references. Hence the choice. If = the IESG believes they can, we can certainly change that. Lars --Apple-Mail=_0FADD707-FD08-4ABE-B7AE-4B2D128C739E Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEmpq0ZpSoejRmyhheVLXDCb9wwVcFAllKJgwACgkQVLXDCb9w wVfDlhAAwwrh6UR21LF0tIVNFO8INwLB8Ju84L0ysbMxYQYbj+y1GnI/uJlfcmV6 Qc/D/ePMQu3VCf75yvl8ZeBRcBqjCbJ0BxB3PQnjYPSwg1gAmKKnH+YP/yvZHHWi XqbQaEwFo+W6i5ItqxijgOOVA1CDLMIxBVmohs+SqmR/dDjHVh/l4lVT2t+Cr3nZ 8xBjMJVcXUcTohqVFPr9hFYjCo517BExuUGvYjARDm0siQvOa+TNsQBxDV2iaOYs wBzycDxltM4bi4LCvQUtOFLak6LEZsoX3AQRpSlWW7C+DPXJaroxiGdvULmQQgKj PJQFMP07mYl5QI0Zah9RQIRGLlB1zdsaOTOBynaVcK0AvW1chEZtqYX3lmhjd5Lk ixc6XxbuSL8Z00cvA0XcZ4+ZUoCCNIY9X1pgAvqopc1nnzSli1KaM1hCEoUB2/Yc XJgFNZBu4OoK6lNStwvEhQhJMapya2uQohILwzNyGDmmfAr3yOakvG44NiaWf9rd C1OKy4k45XStVIWfbMme0dAhxBA7P46qUlGA5f6lKIZVUY/bG/9NSiEYMg6JKeOe uYb9OWDxkZ0BCRbF+j+HnAx+ucgG0t4LUKUbMenWrH5qp9cWm19dZI28/e6YpveT /Elv5X6WB6U5bN5mlb2KoMOteFcLF0QCy/wmKOnqD9yITr5iiqY= =o5J1 -----END PGP SIGNATURE----- --Apple-Mail=_0FADD707-FD08-4ABE-B7AE-4B2D128C739E-- From nobody Wed Jun 21 03:08:18 2017 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 1F5C7131D1A; Wed, 21 Jun 2017 03:08:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ssNLIInmpEYW; Wed, 21 Jun 2017 03:08:14 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45F80131D15; Wed, 21 Jun 2017 03:08:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1248; q=dns/txt; s=iport; t=1498039694; x=1499249294; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=cKIEVOQV/8fy03lOvkl8VxsKz43vDrXjFn8PNN14rig=; b=CJ8q341TeEpV7Ly0/V4AjpwAViPW5jN6o094HLBdfO0dPgu+ePnPWtPB s7kXO6R/biCAp/w4gCO/Kx+xn67qCworTq3e88ig++m2AbnD2Utq5DE1A 93VNbaInsPlYLWCmObTMiRzkE8KLNgmLhPSzSDgDzBMqpKj9+IPQxJsr4 g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BBAQAoRUpZ/5xdJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1iBbweDZYoZkV+WGoIRhiQCGoJUPxgBAgEBAQEBAQFrKIUZBiM?= =?us-ascii?q?RRRACAQgaAiYCAgIwFRACBA4FiiyqAoImi1sBAQEBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?R6BC4VigWArC4JuhGqDEjCCMQEElx2HRQKTYJIOlRABHziBCnQVWwGEehyBZna?= =?us-ascii?q?IXYENAQEB?= X-IronPort-AV: E=Sophos;i="5.39,368,1493683200"; d="scan'208";a="443615390" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 Jun 2017 10:08:05 +0000 Received: from XCH-ALN-005.cisco.com (xch-aln-005.cisco.com [173.36.7.15]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id v5LA85iv001289 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 21 Jun 2017 10:08:05 GMT Received: from xch-aln-002.cisco.com (173.36.7.12) by XCH-ALN-005.cisco.com (173.36.7.15) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 21 Jun 2017 05:08:04 -0500 Received: from xch-aln-002.cisco.com ([173.36.7.12]) by XCH-ALN-002.cisco.com ([173.36.7.12]) with mapi id 15.00.1210.000; Wed, 21 Jun 2017 05:08:04 -0500 From: "Alvaro Retana (aretana)" To: "Eggert, Lars" CC: The IESG , "draft-ietf-tcpm-dctcp@ietf.org" , Michael Scharf , "tcpm-chairs@ietf.org" , "tcpm@ietf.org" Thread-Topic: Alvaro Retana's No Objection on draft-ietf-tcpm-dctcp-07: (with COMMENT) Thread-Index: AQHS6essoVR8XmasP0qGo2dIVUQDJKIvRwcAgABHAwA= Date: Wed, 21 Jun 2017 10:08:04 +0000 Message-ID: <3950435F-386F-4B0F-8021-72FDAC4C4E46@cisco.com> References: <149797993105.24954.10383641844605203192.idtracker@ietfa.amsl.com> <339DF022-9BB2-4484-9E87-8E059EE1EAD3@netapp.com> In-Reply-To: <339DF022-9BB2-4484-9E87-8E059EE1EAD3@netapp.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.20.0.170309 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.61.208.170] Content-Type: text/plain; charset="utf-8" Content-ID: <50A621B60B14384D9F597635EF96239E@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [tcpm] Alvaro Retana's No Objection on draft-ietf-tcpm-dctcp-07: (with COMMENT) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jun 2017 10:08:16 -0000 T24gNi8yMS8xNywgOTo1MyBBTSwgIkVnZ2VydCwgTGFycyIgPGxhcnNAbmV0YXBwLmNvbT4gd3Jv dGU6DQoNCkxhcnM6DQoNCkhpIQ0KDQrigKYNCj4gPi0gVGhlIHJlZmVyZW5jZSB0byBbUkZDMzE2 OC1FUlJBVEEzNjM5XSBzZWVtcyBzdHJhbmdlIHRvIG1lLi4ubm90IGJlY2F1c2UgaXQgaXMNCj4g PnBvaW50aW5nIHRvIHRoZSByZXBvcnQsIGJ1dCBiZWNhdXNlIGl0IGlzIEluZm9ybWF0aXZlLCB3 aGVuIHRoZSByZWZlcmVuY2UgdG8NCj4gPlJGQzMxNjggaXMgTm9ybWF0aXZlLiAgSSB3b3VsZCBh c3N1bWUgdGhhdCBiZWNhdXNlIEVycmF0YTM2MzkgaGFzIGJlZW4NCj4gPlZlcmlmaWVkLCB0aGVu IGl0IG1lYW5zIGl0IGlzIG5vdyAicGFydCBvZiIgUkZDMzE2OCwgc28gSSB3b3VsZCB0aGluayB0 aGF0DQo+ID50aGVyZSdzIG5vIG5lZWQgdG8gbWVudGlvbiBpdCBzZXBhcmF0ZWx5Li4uDQo+DQo+ IEkgZG9uJ3QgdGhpbmsgZXJyYXRhIGNhbiBiZSBub3JtYXRpdmUgcmVmZXJlbmNlcy4gSGVuY2Ug dGhlIGNob2ljZS4gSWYgdGhlIElFU0cgDQo+IGJlbGlldmVzIHRoZXkgY2FuLCB3ZSBjYW4gY2Vy dGFpbmx5IGNoYW5nZSB0aGF0Lg0KDQpNYXliZSBzb21ldGhpbmcgdG8gdGFsayBhYm91dCBvbiB0 aGUgVGVsZWNoYXTigKYNCg0KQXMgSSBzYWlkIGFib3ZlLCBJIHRoaW5rIHRoYXQgYmVjYXVzZSB0 aGUgcmVwb3J0IHdhcyBWZXJpZmllZCB0aGVuIGl0IGlzIG5vdyBwYXJ0IG9mIHRoZSBSRkMsIHNv IHdlIHNob3VsZCBiZSBhYmxlIHRvIHJlZmVyZW5jZSBpdCBhcyB3ZSBkbyB0aGUgUkZDLiAgSG93 ZXZlciwgSSBhbHNvIHRoaW5rIHRoYXQgcmVmZXJlbmNpbmcgdGhlIFJGQyBpcyBlbm91Z2ggYmVj YXVzZSB0aGF0IHNob3VsZCBpbmNsdWRlIHRoZSBlcnJhdGEuDQoNCkFsdmFyby4NCg0KDQoNCg== From nobody Wed Jun 21 11:52:59 2017 Return-Path: X-Original-To: tcpm@ietf.org Delivered-To: tcpm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 58377128B44; Wed, 21 Jun 2017 11:52:49 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Ben Campbell To: "The IESG" Cc: draft-ietf-tcpm-dctcp@ietf.org, Michael Scharf , tcpm-chairs@ietf.org, michael.scharf@nokia.com, tcpm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.55.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149807116935.15620.7561139175975610205.idtracker@ietfa.amsl.com> Date: Wed, 21 Jun 2017 11:52:49 -0700 Archived-At: Subject: [tcpm] Ben Campbell's No Objection on draft-ietf-tcpm-dctcp-07: (with COMMENT) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jun 2017 18:52:49 -0000 Ben Campbell has entered the following ballot position for draft-ietf-tcpm-dctcp-07: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-tcpm-dctcp/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Substantive Comments: - General: The purpose of this draft is not clear to me. Is the point to document the Microsoft implementation just for people's information? Do you have hopes other people will implement this? As written, this seems like a case of an informational draft defining protocol. That's not necessarily a problem, but it's helpful to put a paragraph near the beginning to describe why this is being published and what expectations people have of the outcome. (If the answer is along the lines of "We'd like people to implement this so we can get more operational experience", then I will wonder why the status was not "experimental".) -1, last paragraph: I assume this means that all participants need to live in the datacenter, right? That is, no flows where only one end lives in the datacenter? (I think you clarify that later, but it would be helpful to state it here.) - 3.3: first paragraph: Why not MUST? -- "The congestion estimator on the sender SHOULD process acceptable ACKs as follows:" Why not MUST? Nits: - 1: Can you offer a citation for MapReduce? - 2: The additional text assumes the usage of 2119 keywords here do not quite map to the 2119 definitions. -- "but even compliant implementations without the measures in sections 4-6 would still only be safe to deploy in controlled environments.": That seems too important of a statement to be buried in the terminology section. - 4.1: Citation for NewReno? From nobody Wed Jun 21 18:24:05 2017 Return-Path: X-Original-To: tcpm@ietf.org Delivered-To: tcpm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CC104120721; Wed, 21 Jun 2017 18:23:57 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Adam Roach To: "The IESG" Cc: draft-ietf-tcpm-dctcp@ietf.org, Michael Scharf , tcpm-chairs@ietf.org, michael.scharf@nokia.com, tcpm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.55.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149809463782.30623.12609738398514289191.idtracker@ietfa.amsl.com> Date: Wed, 21 Jun 2017 18:23:57 -0700 Archived-At: Subject: [tcpm] Adam Roach's No Objection on draft-ietf-tcpm-dctcp-07: (with COMMENT) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2017 01:23:58 -0000 Adam Roach has entered the following ballot position for draft-ietf-tcpm-dctcp-07: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-tcpm-dctcp/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Given the nature of this mechanism, I would have expected some qualitative analysis of its performance under typical data center conditions, rather than the somewhat vague descriptions of it being an "improvement." If the cited literature contains such numbers, I would suggest (a) specifically citing where such data can be found; and (b) copying a very high-level summary into this document (e.g., something like: "Under typical data center load conditions, intra-center transfers of large (muti-gigabyte) files were improved by approximately 12% over Standard TCP using commodity switches in their default configuration. See [REFERENCE] for details.") Please expand the following acronyms upon first use; see https://www.rfc-editor.org/materials/abbrev.expansion.txt for guidance. - L3 - Level 3 - ECT - ECN-Capable Transport - DSCP - Differentiated Services Code Point - AQM - Active Queue Management - RED - Random Early Detection From nobody Thu Jun 22 00:20:28 2017 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 34DA3129B0D; Thu, 22 Jun 2017 00:20:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=netapp.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 536ap7dJHhao; Thu, 22 Jun 2017 00:20:25 -0700 (PDT) Received: from mx143.netapp.com (mx143.netapp.com [216.240.21.24]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 546F9129B08; Thu, 22 Jun 2017 00:20:25 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.39,372,1493708400"; d="asc'?scan'208";a="201307312" Received: from vmwexchts02-prd.hq.netapp.com ([10.122.105.23]) by mx143-out.netapp.com with ESMTP; 22 Jun 2017 00:01:22 -0700 Received: from VMWEXCCAS12-PRD.hq.netapp.com (10.122.105.30) by VMWEXCHTS02-PRD.hq.netapp.com (10.122.105.23) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 22 Jun 2017 00:20:03 -0700 Received: from NAM01-BY2-obe.outbound.protection.outlook.com (10.120.60.153) by VMWEXCCAS12-PRD.hq.netapp.com (10.122.105.30) with Microsoft SMTP Server (TLS) id 15.0.1210.3 via Frontend Transport; Thu, 22 Jun 2017 00:20:03 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netapp.onmicrosoft.com; s=selector1-netapp-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=MG3UtQM7NjmcLhhD68hRyAXVs3B/6Co/z/2Y+7GCc6g=; b=qhCE98zyOgT8w/yzdDcTcyc4YofLzb2uidD+go6KR6XzG5CeOd0jVoizryIEJfUxbFKm/QYv+6yXfNkoB1Z8+Wk+olwykaj75m6lN3xXsn0RDdZxOiyalks3B3eDdffql+jTe3IWrWq5cYVwssH21l2ECEKW/rgoNIYyp7VcYnY= Received: from BLUPR06MB1764.namprd06.prod.outlook.com (10.162.224.150) by BLUPR06MB1762.namprd06.prod.outlook.com (10.162.224.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1178.14; Thu, 22 Jun 2017 07:20:09 +0000 Received: from BLUPR06MB1764.namprd06.prod.outlook.com ([10.162.224.150]) by BLUPR06MB1764.namprd06.prod.outlook.com ([10.162.224.150]) with mapi id 15.01.1199.016; Thu, 22 Jun 2017 07:20:09 +0000 From: "Eggert, Lars" To: Adam Roach CC: The IESG , "draft-ietf-tcpm-dctcp@ietf.org" , Michael Scharf , "tcpm-chairs@ietf.org" , "tcpm@ietf.org" Thread-Topic: Adam Roach's No Objection on draft-ietf-tcpm-dctcp-07: (with COMMENT) Thread-Index: AQHS6vY7puEAdcAQd0aONcigdA3TMaIwegMA Date: Thu, 22 Jun 2017 07:20:09 +0000 Message-ID: <225892CB-5FF6-407D-9CAF-21C592256622@netapp.com> References: <149809463782.30623.12609738398514289191.idtracker@ietfa.amsl.com> In-Reply-To: <149809463782.30623.12609738398514289191.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3273) authentication-results: nostrum.com; dkim=none (message not signed) header.d=none;nostrum.com; dmarc=none action=none header.from=netapp.com; x-originating-ip: [217.70.211.15] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BLUPR06MB1762; 7:jTL/xz6mfCS6i66REp08WBNdIVJPNCNmtZ4a8v+AkcIh3nVreCG1LmLZjCFBUiIodQcyIqR2y6eNoNLx6vVYYdgv/LHgDjiJwNcC63bia4FjznOOUSxYJ8mZDI6NivqAk7+mh5HghHIz+kga7aQB1nvMoEsCFb4uM5eF1fhjR/ehgdrrUCZUv1vcJ0OhmOdLAj/2UUXVvvH+witzXpTIOQR3i1Oq2Sam177g7U2p6PoBsRbTsakUOFgUCr4MpVUb1a/P7Q83ji+VFbb+tr+oOtd73vmxIYNCk7exHq082CFMFC+KLAT+TXpQKHIpfO9HIuHsF5yzNyq4D59S6MbMUxgCJO77Vr8uhs31wadHvoq9CZfS3zpav6mxhyejli9Zb6A6bMk9dnR1Bb+m4t9x+8X/mzYAI4Ef2fXuke96GzJg+zAiHGIKM4eDuMKcyDty2tAlwhlxV65yWrhF3+BCZaziWN5V9B6LtLlhSnj7pn+Cqd25n/ib/FHUJC0jn+hYGjdXDfQz/E5XZhOblAQZ2UPY1IP6pNPo0v/cn3j9xEcvGDfh7a+AN+X+nSTZrKnUSoLiWYKOn8oyXpQwC1OstFHzIgll0hVhi40M6enPK/LRq/ZuZrJ2fWRoOgvR2PSTHzoj/G4o5zGxQqbzEz0PBdpGRjT5jPoLmutMlL+JGRnbo5mS6vbbU+aJvvu3ghOemHfwADCP0152L7tNFE1HTShp0CcrmPnby9NrpkB5MOCVX4LhCWMnDPQ+spwou5SoBB7nzYzjjeY5pmq4gpzS2eCI88KvwVEfmAa7Ok18Bw0= x-ms-office365-filtering-correlation-id: 5229817f-d152-4398-67ca-08d4b93f1d6c x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(49563074)(201703131423075)(201703031133081); SRVR:BLUPR06MB1762; x-ms-traffictypediagnostic: BLUPR06MB1762: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(102415395)(6040450)(601004)(2401047)(8121501046)(5005006)(3002001)(93006095)(93001095)(100000703101)(100105400095)(10201501046)(6055026)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123555025)(20161123558100)(20161123560025)(20161123564025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BLUPR06MB1762; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BLUPR06MB1762; x-forefront-prvs: 03468CBA43 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39410400002)(39400400002)(39450400003)(39850400002)(39840400002)(24454002)(377424004)(2900100001)(102836003)(8936002)(6116002)(230783001)(50226002)(8676002)(36756003)(6486002)(77096006)(6306002)(54906002)(6512007)(189998001)(4001150100001)(53936002)(3280700002)(3660700001)(57306001)(53546010)(2906002)(7736002)(122556002)(33656002)(86362001)(99286003)(66066001)(81166006)(4326008)(6246003)(305945005)(14454004)(2950100002)(6916009)(5660300001)(6506006)(229853002)(83716003)(99936001)(76176999)(82746002)(50986999)(3846002)(25786009)(110136004)(966005)(38730400002)(478600001)(6436002); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR06MB1762; H:BLUPR06MB1764.namprd06.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/signed; boundary="Apple-Mail=_94A91BBE-8349-45EF-8B60-F219E5D8B1BF"; protocol="application/pgp-signature"; micalg=pgp-sha512 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Jun 2017 07:20:09.2843 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4b0911a0-929b-4715-944b-c03745165b3a X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR06MB1762 X-OriginatorOrg: netapp.com Archived-At: Subject: Re: [tcpm] Adam Roach's No Objection on draft-ietf-tcpm-dctcp-07: (with COMMENT) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2017 07:20:27 -0000 --Apple-Mail=_94A91BBE-8349-45EF-8B60-F219E5D8B1BF Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Fixed in the editors' copy; thanks On 2017-6-22, at 3:23, Adam Roach wrote: > > Please expand the following acronyms upon first use; > see https://www.rfc-editor.org/materials/abbrev.expansion.txt for guidance. > > - L3 - Level 3 > - ECT - ECN-Capable Transport > - DSCP - Differentiated Services Code Point > - AQM - Active Queue Management > - RED - Random Early Detection --Apple-Mail=_94A91BBE-8349-45EF-8B60-F219E5D8B1BF Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEmpq0ZpSoejRmyhheVLXDCb9wwVcFAllLb6QACgkQVLXDCb9w wVfVxhAAuczajb9jCtplqarHwPjtp0tRt8ytfI7IFV1wgAQXodAP70tu9raPe97a 4WMaol52GzbOasIQo/dqnYhJdhUQVw0EV4TpMuqGC9b9cQ32GxYRScm7Y54/4jm7 kA2td8S+QMidMF2QMOE6vdpChzoqk869ARMLN6dMH4kzcpoyoP84Hj63enTj5yY4 yGTBJ2FV15pEF4hY0mO3PWX1uhu8bmbxhBWdrr/I715VbWxEMXrmPDtd7JZF7yH+ qaZHIRjw1s5TcfrTetgD3r8U06Q/Qp1Hll/GatfkJyInySE3jyLwnx4ADK0DOdfc u9VeU5BK5Tr+leZELO/aKbhL/4dm1SfGagXBY42d3jkM4lgyRbTqUal2TAb1N1mt ISVoOs/7PS4S0yu4uTtnEze80vrVkYkSRThqH2B1NsRbFf+h3+r7Hzt0fShgFNoK NItCOeQsG0a4VWxsqhTvHMNs/waUiiYy3OBo6ObA5XF4ih58jNXZmFA3Jdxuc3HT 62gOw1uTdJXqCDqOp2aGb4ee468LlIlT3AxM7NC8DvjGI+kx8h/cNuQP0el2exkI uwiHh1uJmT3x/edrmnZHPK1nSahTpOZGQ7I0krXoaJij+Cwcyibn3ZtLbmMM1IT8 4WQRtyGF1TPI7kFYOdNkI3zBm/XJ/DKzfwsc2eG+SUp4W+mka78= =TYbB -----END PGP SIGNATURE----- --Apple-Mail=_94A91BBE-8349-45EF-8B60-F219E5D8B1BF-- From nobody Thu Jun 22 00:20:44 2017 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 D1D77129B1B; Thu, 22 Jun 2017 00:20:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=netapp.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HMSa1-C-LbdA; Thu, 22 Jun 2017 00:20:25 -0700 (PDT) Received: from mx143.netapp.com (mx143.netapp.com [216.240.21.24]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 10D1C1296B3; Thu, 22 Jun 2017 00:20:25 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.39,372,1493708400"; d="asc'?scan'208";a="201306733" Received: from vmwexchts01-prd.hq.netapp.com ([10.122.105.12]) by mx143-out.netapp.com with ESMTP; 21 Jun 2017 23:56:36 -0700 Received: from VMWEXCCAS09-PRD.hq.netapp.com (10.122.105.27) by VMWEXCHTS01-PRD.hq.netapp.com (10.122.105.12) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 22 Jun 2017 00:15:16 -0700 Received: from NAM02-SN1-obe.outbound.protection.outlook.com (10.120.60.153) by VMWEXCCAS09-PRD.hq.netapp.com (10.122.105.27) with Microsoft SMTP Server (TLS) id 15.0.1210.3 via Frontend Transport; Thu, 22 Jun 2017 00:15:15 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netapp.onmicrosoft.com; s=selector1-netapp-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=RkoWC68G/7gfy9P863NZNFCaorG3CdFuZxsk704zvJc=; b=emZ8vm0S1gFCcMzYlhbFmatKMGDey9OxdQq4wnS8xr8lemwFp/W/ioXmHF4sptO/xzaZqNLA8PrrTPYLM6SMUgghGdm0W90trH9/qsNT6zTZulHxyP6lMq52ipEbGsxopwRynV+p+v28r+x0Y2lkJ164xbPJRzPmgIojmAUX0kI= Received: from BLUPR06MB1764.namprd06.prod.outlook.com (10.162.224.150) by BLUPR06MB1762.namprd06.prod.outlook.com (10.162.224.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1178.14; Thu, 22 Jun 2017 07:15:22 +0000 Received: from BLUPR06MB1764.namprd06.prod.outlook.com ([10.162.224.150]) by BLUPR06MB1764.namprd06.prod.outlook.com ([10.162.224.150]) with mapi id 15.01.1199.016; Thu, 22 Jun 2017 07:15:22 +0000 From: "Eggert, Lars" To: Ben Campbell CC: The IESG , "draft-ietf-tcpm-dctcp@ietf.org" , Michael Scharf , "tcpm-chairs@ietf.org" , "tcpm@ietf.org" Thread-Topic: Ben Campbell's No Objection on draft-ietf-tcpm-dctcp-07: (with COMMENT) Thread-Index: AQHS6r/bDoxQRZwJ4EqgoI8OV2iMZqIweRmA Date: Thu, 22 Jun 2017 07:15:21 +0000 Message-ID: References: <149807116935.15620.7561139175975610205.idtracker@ietfa.amsl.com> In-Reply-To: <149807116935.15620.7561139175975610205.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3273) authentication-results: nostrum.com; dkim=none (message not signed) header.d=none;nostrum.com; dmarc=none action=none header.from=netapp.com; x-originating-ip: [217.70.211.15] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BLUPR06MB1762; 7:Zd7foD/dchLdtjE0hKushsdl6FoxvdcwGQqIllKc3AKN3whucYYe4f7wfMeVR8SW35MRjK1x2sfTYJ5txPRq9wiWjM+XKHuJd4DrzoBNCDo6X0aYYmm7syAhXEZ8f17sHa8gpdVIzHGsMxVH74xwWTx/yaMCVYuKBIvQF/ha6o0Zd/+foq22+Qmp2Xba7tk53YHatJiNbiCGVoOhDH21iiPzl8Io7oWvYLZQ7rV7ggxPxDCXwa8lpKEKdlRB38ijCz2aQpze4fd8I7MuqPhW3dmWUT16J/jGt0FuEEgq6oOcSrjOYwqx0W6VSZ6Owkc7I5yzkzU6wubapOG+W2fqAXaKPz7J8vjsbH6xRoSQboPQg+0Ud5Euw4y7wsa+qC3r5xaaCKMo0JQskmT6cGk5r1631iDnMiNbtQSf46aPY5UnE1FtCuwhCtQMvRsyllfFaf+WZUoy68M73mlqm+4pIlXbjlAZXmeExWFqDatX3mWIVp4WkYxgm1u8+IVfuADDcf0HvvWxEw4OxhbHX/afvZNJkkIxmj7BGihVFP3Y4NRIY/eS71EpUF5eAv8vi/Yvcql43OCxodo5woNuuMm7Qc1ulkTu+8HkS600p3QsQeNuxI5Rk+Dt+8g4JOzjEI/UjS/ELKrteuC/x/pZWKHfB+2KrXBuov8tl69BujAwEA3w8VmKKNCBuN86UR4dKG357gRTesEgs7HCBxp+ewAEYfrRrjRm0FRpaFdLs07Jrup8yINhmrUbZlZAkU/L/3hK81CAsCFkp0ZTKtzepnqloZXI4OLsy8+MIxO2TzLNI9c= x-ms-office365-filtering-correlation-id: 283c3a54-4b8b-496c-9c4c-08d4b93e7224 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(49563074)(201703131423075)(201703031133081); SRVR:BLUPR06MB1762; x-ms-traffictypediagnostic: BLUPR06MB1762: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(211936372134217); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(102415395)(6040450)(601004)(2401047)(8121501046)(5005006)(3002001)(93006095)(93001095)(100000703101)(100105400095)(10201501046)(6055026)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123555025)(20161123558100)(20161123560025)(20161123564025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BLUPR06MB1762; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BLUPR06MB1762; x-forefront-prvs: 03468CBA43 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39410400002)(39400400002)(39450400003)(39850400002)(39840400002)(24454002)(377424004)(2900100001)(102836003)(8936002)(6116002)(230783001)(50226002)(8676002)(36756003)(6486002)(77096006)(6306002)(54906002)(6512007)(189998001)(4001150100001)(53936002)(3280700002)(3660700001)(57306001)(53546010)(2906002)(7736002)(122556002)(33656002)(86362001)(99286003)(66066001)(81166006)(4326008)(6246003)(305945005)(14454004)(2950100002)(6916009)(5660300001)(6506006)(229853002)(83716003)(99936001)(76176999)(82746002)(50986999)(3846002)(25786009)(110136004)(45080400002)(966005)(38730400002)(478600001)(6436002); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR06MB1762; H:BLUPR06MB1764.namprd06.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/signed; boundary="Apple-Mail=_4AB1CD56-D504-4E62-908C-764CFD07CC3A"; protocol="application/pgp-signature"; micalg=pgp-sha512 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Jun 2017 07:15:21.8814 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4b0911a0-929b-4715-944b-c03745165b3a X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR06MB1762 X-OriginatorOrg: netapp.com Archived-At: Subject: Re: [tcpm] Ben Campbell's No Objection on draft-ietf-tcpm-dctcp-07: (with COMMENT) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2017 07:20:29 -0000 --Apple-Mail=_4AB1CD56-D504-4E62-908C-764CFD07CC3A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, On 2017-6-21, at 20:52, Ben Campbell wrote: > - General: The purpose of this draft is not clear to me. Is the point = to > document the Microsoft implementation just for people's information? = Do you > have hopes other people will implement this? As written, this seems = like a case > of an informational draft defining protocol. That's not necessarily a = problem, > but it's helpful to put a paragraph near the beginning to describe why = this is > being published and what expectations people have of the outcome. (If = the > answer is along the lines of "We'd like people to implement this so we = can get > more operational experience", then I will wonder why the status was = not > "experimental".) This doesn't describe "the Microsoft implementation". It describes a TCP = variant that originated with Microsoft but has also been shipping as = part of Linux and FreeBSD for at least a few years now. The purpose of = describing it is so that others can produce interoperable = implementations without need to resort to reading (licensed) code. > -1, last paragraph: I assume this means that all participants need to = live in > the datacenter, right? That is, no flows where only one end lives in = the > datacenter? (I think you clarify that later, but it would be helpful = to state > it here.) Yes. > - 3.3: first paragraph: Why not MUST? > -- "The congestion estimator on the sender SHOULD process acceptable = ACKs > as follows:" Why not MUST? I think because it's not needed for interoperability, but I'll Praveen = should chime in here. > Nits: >=20 > - 1: Can you offer a citation for MapReduce? Sure, we'll add a pointer to = https://research.google.com/archive/mapreduce.html > - 2: The additional text assumes the usage of 2119 keywords here do = not quite > map to the 2119 definitions. -- "but even compliant implementations = without the > measures in sections 4-6 would still only be safe to deploy in = controlled > environments.": That seems too important of a statement to be buried = in the > terminology section. This is probably the wrong section for this statement, will revise. >=20 > - 4.1: Citation for NewReno? We can point to RFC6582. Lars --Apple-Mail=_4AB1CD56-D504-4E62-908C-764CFD07CC3A Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEmpq0ZpSoejRmyhheVLXDCb9wwVcFAllLboUACgkQVLXDCb9w wVfibBAAwpEMqnTI9flksOlbShHI3mZ+uASQuvtOCNrsovT3Bz8oTd9h5x/vYBJP Oaj3QBorN/NyOcY0xuwnPpZMCoSusThjC5yPjt/7G3GEAbYz3toGkr1NDkqTJamq hG36PCHDr2uHrBwlI61zEWOFi/+7f2M/pLn3vBpjO3f+aDH/n3xkFxDqUI0xIU3c Gp3QfbaJKRhGQdn6Phtbhqb9RIEo7rrP24mr2bX3sDaKVC3/VoJLFXMZz0Be0Gl2 YTi9yU6gxhnM+YLv7aa/948VWJ8YtBeUKq/CanDP6bVGxNhz8ji2/io6drZBnoYQ 4u8ZJl3U1WXsREu87En994ix9XuOIMNPJcgQnYs/WJnRepMwmsEip/DmFa258XiI 12oTWCChyC77JJBUYsGb6uWWgJbGiABw28eoJ4+Af2P7b7U8sdjdfq7Unu5pg4V9 jjt2Tn282f5HXszfOx1eho55G7uuVAkrxTSjG7dkhpKm7kzgtxNBiOSyQW0qtxb/ eqbjwkuHt5pH+fXQdCNP5FLc344v4mkPyOxPVkoermga4iaQFIpqd8FQTDYPD52o 1GuSDhcLW95tz7V7CTVRkvdMCfgCWS+Ho8JUUBMTSvePRN1/V6tZyDcrJOP0iuvr /2F9AL8xY9YjnQWgwpXWPIlW3rdbA5PfNv6LRAgm7jf7cLXCuTc= =GUUJ -----END PGP SIGNATURE----- --Apple-Mail=_4AB1CD56-D504-4E62-908C-764CFD07CC3A-- From nobody Thu Jun 22 06:51:21 2017 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 A4EB2126B71; Thu, 22 Jun 2017 06:51:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.881 X-Spam-Level: X-Spam-Status: No, score=-1.881 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XbMH6yyKU9EN; Thu, 22 Jun 2017 06:51:17 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF888129476; Thu, 22 Jun 2017 06:51:16 -0700 (PDT) Received: from [10.0.1.63] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v5MDpF9m028773 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 22 Jun 2017 08:51:16 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.63] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Ben Campbell In-Reply-To: Date: Thu, 22 Jun 2017 08:51:16 -0500 Cc: The IESG , "draft-ietf-tcpm-dctcp@ietf.org" , Michael Scharf , "tcpm-chairs@ietf.org" , "tcpm@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <149807116935.15620.7561139175975610205.idtracker@ietfa.amsl.com> To: "Eggert, Lars" X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [tcpm] Ben Campbell's No Objection on draft-ietf-tcpm-dctcp-07: (with COMMENT) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2017 13:51:19 -0000 > On Jun 22, 2017, at 2:15 AM, Eggert, Lars wrote: >=20 > Hi, >=20 > On 2017-6-21, at 20:52, Ben Campbell wrote: >> - General: The purpose of this draft is not clear to me. Is the point = to >> document the Microsoft implementation just for people's information? = Do you >> have hopes other people will implement this? As written, this seems = like a case >> of an informational draft defining protocol. That's not necessarily a = problem, >> but it's helpful to put a paragraph near the beginning to describe = why this is >> being published and what expectations people have of the outcome. (If = the >> answer is along the lines of "We'd like people to implement this so = we can get >> more operational experience", then I will wonder why the status was = not >> "experimental".) >=20 > This doesn't describe "the Microsoft implementation". It describes a = TCP variant that originated with Microsoft but has also been shipping as = part of Linux and FreeBSD for at least a few years now. The purpose of = describing it is so that others can produce interoperable = implementations without need to resort to reading (licensed) code. That really seems to be a case of defining a standard in an = informational RFC. Why is it appropriate to publish this as = informational? [The rest of your response look good.] Thanks! Ben.= From nobody Thu Jun 22 07:18:14 2017 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 5DC29129486; Thu, 22 Jun 2017 07:18:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=netapp.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8P4gryZ07gcC; Thu, 22 Jun 2017 07:18:03 -0700 (PDT) Received: from mx144.netapp.com (mx144.netapp.com [216.240.21.25]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59AF912944F; Thu, 22 Jun 2017 07:18:03 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.39,373,1493708400"; d="asc'?scan'208";a="201099891" Received: from vmwexchts04-prd.hq.netapp.com ([10.122.105.32]) by mx144-out.netapp.com with ESMTP; 22 Jun 2017 06:52:44 -0700 Received: from VMWEXCCAS01-PRD.hq.netapp.com (10.122.105.11) by VMWEXCHTS04-PRD.hq.netapp.com (10.122.105.32) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 22 Jun 2017 07:12:54 -0700 Received: from NAM02-CY1-obe.outbound.protection.outlook.com (10.120.60.153) by VMWEXCCAS01-PRD.hq.netapp.com (10.122.105.11) with Microsoft SMTP Server (TLS) id 15.0.1210.3 via Frontend Transport; Thu, 22 Jun 2017 07:12:54 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netapp.onmicrosoft.com; s=selector1-netapp-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=rhWDxIpQLb/TmGLs1pvjGSvhsE8Jyou5tVvRndPEkzI=; b=YcBfvHV8Qa8XrPgCNK+TwrEmIRGhVgPGMHr3+YGz8czhvurmWJed/X90GwpuvSE9BzEX1ogWRGaejmZRggbt1NAgy7AuQja9PNj/a9EZFAwecddaetxz0hi/4UN/fVmKVZ9ud5hgU15GSR09wUS7O1WL9gSlWtt9As5wrLXItc0= Received: from BLUPR06MB1764.namprd06.prod.outlook.com (10.162.224.150) by BLUPR06MB1764.namprd06.prod.outlook.com (10.162.224.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1199.15; Thu, 22 Jun 2017 14:13:00 +0000 Received: from BLUPR06MB1764.namprd06.prod.outlook.com ([10.162.224.150]) by BLUPR06MB1764.namprd06.prod.outlook.com ([10.162.224.150]) with mapi id 15.01.1199.016; Thu, 22 Jun 2017 14:13:00 +0000 From: "Eggert, Lars" To: Ben Campbell CC: The IESG , "draft-ietf-tcpm-dctcp@ietf.org" , Michael Scharf , "tcpm-chairs@ietf.org" , "tcpm@ietf.org" Thread-Topic: Ben Campbell's No Objection on draft-ietf-tcpm-dctcp-07: (with COMMENT) Thread-Index: AQHS6r/bDoxQRZwJ4EqgoI8OV2iMZqIweRmAgABuowCAAAYQAA== Date: Thu, 22 Jun 2017 14:13:00 +0000 Message-ID: <5016F105-106C-4D5E-865E-76DF3A8F0AC0@netapp.com> References: <149807116935.15620.7561139175975610205.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3273) authentication-results: nostrum.com; dkim=none (message not signed) header.d=none;nostrum.com; dmarc=none action=none header.from=netapp.com; x-originating-ip: [217.70.211.15] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BLUPR06MB1764; 7:as7dXBixaS6/gG+hCVMu0QC6dmmgWPc3aLnI0Y/DlVBro6K8PnOE3cxRV1u1QdKCaeu/eEHL+Yt3EVyQEJgBHyBUXSdzwYLyvhPWg/a4fiiLNpAzBxMoNu68xcSx2B3VftVkhlQWpQA/o4mVvyKnLA1Xfe0vtfEP45DV3iEPdQWoJu/aGJyoF5jFKBGyIIAKzsmY3OBnp853RGT9AHy9Nx0/EDcABLrnkAI06KkKJDwZxDz0BCHQEX485n1RTyVDDIX9GFqNavPMA9LerjVXG3vAi7CxUJQOu2OmG0OWlxz1R6Yq0BLpGc0YZHVaI12KP0/+m0plnJFpSVxhDcIDrI19knRzCAwjRKnSEQbBE5mVqfthfkOTC93fc6Znif4Xho8rLrnc+Y1ntrUj7Rr6DLoU0GF60cE5B6k6LMkVG/EG2xc7Gk96NFR0+o808tIOAcCrN6Fe+6mhs0w1mf5UlK6BV/NA8Dy9Y7zP7RQPOmAiHDA7YjbHqUedj9tAQj0PSR23IquiuopgaOf7sTY5ka6CZTMoWQG/8Ri9sPfbSTJjcAYgtnKI8nG9g0aqYgU7rmqqfGK5BAOKeZZEXrbYr5xTx0JQ7Z3j43KaHps/Vaa00/wZ7o2DbuHFncRcso2uZjn6jl3DnYTJNL1sFTyt1cJgxW1fDELfoSApw+yQKJwU3JMAIvujWOap4prpSUDSuXJX62yPo4mCcEiX1eQu4LJtHPbTYkOw663T1eMTzax5WkWHDViGqnOKv8EwHOYLX3QOegiqnt3xvvQFpMLSKbJfYat9zPdGYfjnkYcLGPk= x-ms-office365-filtering-correlation-id: 5aeec7cf-5259-4dc1-dda3-08d4b978ca08 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(49563074)(201703131423075)(201703031133081); SRVR:BLUPR06MB1764; x-ms-traffictypediagnostic: BLUPR06MB1764: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(102415395)(6040450)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(100000703101)(100105400095)(93006095)(93001095)(6055026)(6041248)(20161123558100)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123555025)(20161123562025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BLUPR06MB1764; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BLUPR06MB1764; x-forefront-prvs: 03468CBA43 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39410400002)(39400400002)(39850400002)(39840400002)(39450400003)(377454003)(377424004)(24454002)(6436002)(6506006)(3280700002)(6512007)(3660700001)(86362001)(2906002)(54906002)(122556002)(99286003)(229853002)(77096006)(6486002)(50226002)(230783001)(2900100001)(2950100002)(36756003)(33656002)(5660300001)(6916009)(305945005)(8676002)(7736002)(8936002)(81166006)(102836003)(3846002)(6116002)(66066001)(53546010)(189998001)(45080400002)(83716003)(478600001)(14454004)(25786009)(38730400002)(4001150100001)(4326008)(99936001)(50986999)(82746002)(110136004)(53936002)(76176999); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR06MB1764; H:BLUPR06MB1764.namprd06.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/signed; boundary="Apple-Mail=_33C48012-C6E2-4B28-B24B-E3F23164018C"; protocol="application/pgp-signature"; micalg=pgp-sha512 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Jun 2017 14:13:00.0643 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4b0911a0-929b-4715-944b-c03745165b3a X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR06MB1764 X-OriginatorOrg: netapp.com Archived-At: Subject: Re: [tcpm] Ben Campbell's No Objection on draft-ietf-tcpm-dctcp-07: (with COMMENT) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2017 14:18:05 -0000 --Apple-Mail=_33C48012-C6E2-4B28-B24B-E3F23164018C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 2017-6-22, at 15:51, Ben Campbell wrote: >> On Jun 22, 2017, at 2:15 AM, Eggert, Lars wrote: >>=20 >> This doesn't describe "the Microsoft implementation". It describes a = TCP variant that originated with Microsoft but has also been shipping as = part of Linux and FreeBSD for at least a few years now. The purpose of = describing it is so that others can produce interoperable = implementations without need to resort to reading (licensed) code. >=20 > That really seems to be a case of defining a standard in an = informational RFC. Why is it appropriate to publish this as = informational? Because TCPM didn't want to recommend the currently implemented DCTCP as = a PS. For a PS, the WG would have liked to make changes. And those = changes would be unlikely to see implementation for at least a while. So the options were: (1) document what current implementations do, but = as Informational or (2) have the WG do a PS, but one without an = implementation. We picked (1). If the IESG felt that the current doc should be PS, none of the authors = would (I believe) object, but the WG probably would. Lars --Apple-Mail=_33C48012-C6E2-4B28-B24B-E3F23164018C Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEmpq0ZpSoejRmyhheVLXDCb9wwVcFAllL0GoACgkQVLXDCb9w wVcaJBAAqvueQalG5mgSslVXzgpkXziTtTlF/KohOW+eOxJSgLnc8CUyhAMH/hDI W0VSF4aqQhzCW1TOHxiFU/wZ9VGBCYd2iKDsoO1D81a0je/eAZNkLvB5ny6gWbaF z/a2qkHS25Fb52Qxc1uWZMW4lqtVR8AolarO6SYmvtQ/9W9UKPs38Yvdgd7NpTdb 0pq+AUxFbswRsVftHbCW5KTEOqi8QwK5SsQ1RscDOI2ekX7tM6KDwhEPuJBTwGKp jxEJfSzePnuRrFoFEPooZdhDOFMgJjnV9iP67hKdT7r5BSL77YXn29E6apDWB0tu ePZYIKhubtUiaNo+eo/YGk96PrSlrQlaAyuVrt0wYKo5xMSmMTsIVSc41+FsJCZU yx+VKLw/R1nYVMyYXVma07S01n/ihYcqnYP5dPkvjUlL4jGk976c+A5eo32APMCL 8UI2x6g0gHWLOGAB3SpojeMErsRbm8Vhz4gp0VE5ddmqjDSwEeqb/me3PNnWUuS2 VzCWGjttjHKlLfYwK2qjsuouOjpnaXKtLiIxvtmz1kzeC3s0uznpXdRSlOLojpa3 u2z+doo2JxUcI0khFp9y3+514w5vLAg6vqgM+Qjuv76nDD39HaHOZDUPs9vPwIX4 3F6dGMbD7kMNNOrpY67Vtj9qEEoym9pfGXYkeKYTGbSI1FQ3yzI= =sa0J -----END PGP SIGNATURE----- --Apple-Mail=_33C48012-C6E2-4B28-B24B-E3F23164018C-- From nobody Thu Jun 22 07:33:54 2017 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 C6508129540; Thu, 22 Jun 2017 07:33:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.702 X-Spam-Level: X-Spam-Status: No, score=-4.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DYZmUYdIVXCF; Thu, 22 Jun 2017 07:33:51 -0700 (PDT) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0104.outbound.protection.outlook.com [104.47.2.104]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 664A1129535; Thu, 22 Jun 2017 07:33:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=E8zxCBYRc65Hj6Zihv0+YuYUbnFQ5jzJ7RDbRMynz5g=; b=ONdne15VZ0M9FAv9wN2+sRNE+UnIdeMj0EJXrGBqzbVKEnul1jBnJXxgsxijFc5eC0u6kD246OJ6M/sM/5fsxmxwJIzFuKg3evCN5PS0Vz0dgXZRXOgBU2fjioE0Bd0ddmZUWRZAD2ddh887holZKrZsF38m5KOJlodwid44TdA= Received: from AM5PR0701MB2547.eurprd07.prod.outlook.com (10.173.92.15) by AM5PR0701MB1859.eurprd07.prod.outlook.com (10.167.216.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1199.6; Thu, 22 Jun 2017 14:33:49 +0000 Received: from AM5PR0701MB2547.eurprd07.prod.outlook.com ([fe80::8c06:20b8:4ca1:4bf8]) by AM5PR0701MB2547.eurprd07.prod.outlook.com ([fe80::8c06:20b8:4ca1:4bf8%18]) with mapi id 15.01.1199.012; Thu, 22 Jun 2017 14:33:49 +0000 From: "Scharf, Michael (Nokia - DE/Stuttgart)" To: "Eggert, Lars" , Ben Campbell CC: The IESG , "draft-ietf-tcpm-dctcp@ietf.org" , "tcpm-chairs@ietf.org" , "tcpm@ietf.org" Thread-Topic: Ben Campbell's No Objection on draft-ietf-tcpm-dctcp-07: (with COMMENT) Thread-Index: AQHS6r+WxSiDuzqCb02JLHHzAVKTF6IweR6AgABunwCAAAYSAIAAAMtQ Date: Thu, 22 Jun 2017 14:33:48 +0000 Message-ID: References: <149807116935.15620.7561139175975610205.idtracker@ietfa.amsl.com> <5016F105-106C-4D5E-865E-76DF3A8F0AC0@netapp.com> In-Reply-To: <5016F105-106C-4D5E-865E-76DF3A8F0AC0@netapp.com> Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: netapp.com; dkim=none (message not signed) header.d=none;netapp.com; dmarc=none action=none header.from=nokia.com; x-originating-ip: [135.245.212.24] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM5PR0701MB1859; 7:f+d+q06T3Erkn+TonUCQ/h3xOFQaG4Sxf094PmaiX+AEajwoJta1YRyBQm8QVmCj+1lJ38zx0eJ7xaHTrbURhZ2OrD4nzOqIPypPRqfwcKY/Oyt3/xx7PmS1GetY4UAJjy2mi6ESntRasiHQs3ETkLjy9NT6vfe2uMG6pWJ3g9U/dJ3gdhO5A4Uk9VaAJlZL+M9HhoHyN+EXVE4Iipxkn8Bo7O7q8k2KJs1GsVVKimunyyJoykUhdtCsVbpEpAlGby10rGLB1siER8vJywTy1tD3bemVuF0pQ7o5AVsTS3HSrQQQUjfd5MaZ3JWrGK1dtd7fxDvnuv8i2vpFi7GHuKudOgGJOqdr+j4vYArl0+GdZli3I1mfbsdwPB3rldTShZ5XUtA/jTJ0pytorDNEpyGo+VLBV4XTbbKdUn+NiTHVHRBgbBnB49v8sOjoA0mEMfnQaA9t0I+HyAid2nf4Ga8d0FuTd2FDcp86GW7bB225MSg8EYKZ6Bro+8YIyDu1dHpu8RClQxSOjX6bN7mu5XQj4Tq8pSpXrgnWFXHLA+SKfyioxk3Ycr8N5xt27CbgvV61MCLoCY14h1eiBFT0xue5xr1qZ3fAIrjOcjc1dgzTsjCn9tzp75Wa+RnAKEDKmkcZyOpsR0Tjw9aXJN4CYMm7sis8Oq20HM8YPP8lv3FosEMZWxurzSh2ijOvAERLS2OOVtdtvxztHTHUJtwL1bTFWekv7ob0OgD9Q57OuYOxitULA3RDbWsy94gYRMgtsbArh2uWr2rMT1G6/aB6+nyYN53Bgcm9jv0+Eec2DMU= x-ms-office365-filtering-correlation-id: eb676220-7cae-4af6-356b-08d4b97bb263 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500055)(300135000095)(300000501055)(300135300095)(22001)(300000502055)(300135100095)(2017030254075)(300000503055)(300135400095)(48565401081)(201703131423075)(201703031133081)(300000504055)(300135200095)(300000505055)(300135600095)(300000506048)(300135500095); SRVR:AM5PR0701MB1859; x-ms-traffictypediagnostic: AM5PR0701MB1859: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(5005006)(8121501046)(100000703101)(100105400095)(93006095)(93001095)(10201501046)(3002001)(6055026)(6041248)(20161123555025)(20161123560025)(20161123562025)(20161123564025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM5PR0701MB1859; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM5PR0701MB1859; x-forefront-prvs: 03468CBA43 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39860400002)(39840400002)(39450400003)(39850400002)(39410400002)(39400400002)(24454002)(377424004)(377454003)(2900100001)(38730400002)(305945005)(5660300001)(53936002)(2906002)(4326008)(6116002)(102836003)(3846002)(25786009)(55016002)(6436002)(230783001)(54906002)(99286003)(9686003)(3660700001)(3280700002)(66066001)(93886004)(86362001)(6506006)(189998001)(478600001)(14454004)(45080400002)(2950100002)(33656002)(7696004)(53546010)(74316002)(81166006)(229853002)(50986999)(54356999)(7736002)(8936002)(8676002)(76176999)(4001150100001)(5250100002); DIR:OUT; SFP:1102; SCL:1; SRVR:AM5PR0701MB1859; H:AM5PR0701MB2547.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Jun 2017 14:33:48.9903 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0701MB1859 Archived-At: Subject: Re: [tcpm] Ben Campbell's No Objection on draft-ietf-tcpm-dctcp-07: (with COMMENT) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2017 14:33:54 -0000 > On 2017-6-22, at 15:51, Ben Campbell wrote: > >> On Jun 22, 2017, at 2:15 AM, Eggert, Lars wrote: > >> > >> This doesn't describe "the Microsoft implementation". It describes a T= CP > variant that originated with Microsoft but has also been shipping as part= of > Linux and FreeBSD for at least a few years now. The purpose of describing= it > is so that others can produce interoperable implementations without need > to resort to reading (licensed) code. > > > > That really seems to be a case of defining a standard in an information= al > RFC. Why is it appropriate to publish this as informational? >=20 > Because TCPM didn't want to recommend the currently implemented DCTCP > as a PS. For a PS, the WG would have liked to make changes. And those > changes would be unlikely to see implementation for at least a while. >=20 > So the options were: (1) document what current implementations do, but as > Informational or (2) have the WG do a PS, but one without an > implementation. We picked (1). >=20 > If the IESG felt that the current doc should be PS, none of the authors w= ould > (I believe) object, but the WG probably would. Publishing this doc on standards track would IMHO at least require another = working group last call. Michael From nobody Thu Jun 22 07:38:05 2017 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 4DDD2129A9A; Thu, 22 Jun 2017 07:37:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.881 X-Spam-Level: X-Spam-Status: No, score=-1.881 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e_zVN4U0AgLd; Thu, 22 Jun 2017 07:37:55 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 504C6129A92; Thu, 22 Jun 2017 07:37:52 -0700 (PDT) Received: from [10.0.1.63] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v5MEboe4036214 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 22 Jun 2017 09:37:51 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.63] Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Ben Campbell In-Reply-To: Date: Thu, 22 Jun 2017 09:37:50 -0500 Cc: "Eggert, Lars" , The IESG , "draft-ietf-tcpm-dctcp@ietf.org" , "tcpm-chairs@ietf.org" , "tcpm@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <149807116935.15620.7561139175975610205.idtracker@ietfa.amsl.com> <5016F105-106C-4D5E-865E-76DF3A8F0AC0@netapp.com> To: "Scharf, Michael (Nokia - DE/Stuttgart)" X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [tcpm] Ben Campbell's No Objection on draft-ietf-tcpm-dctcp-07: (with COMMENT) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2017 14:37:57 -0000 > On Jun 22, 2017, at 9:33 AM, Scharf, Michael (Nokia - DE/Stuttgart) = wrote: >=20 >> On 2017-6-22, at 15:51, Ben Campbell wrote: >>>> On Jun 22, 2017, at 2:15 AM, Eggert, Lars wrote: >>>>=20 >>>> This doesn't describe "the Microsoft implementation". It describes = a TCP >> variant that originated with Microsoft but has also been shipping as = part of >> Linux and FreeBSD for at least a few years now. The purpose of = describing it >> is so that others can produce interoperable implementations without = need >> to resort to reading (licensed) code. >>>=20 >>> That really seems to be a case of defining a standard in an = informational >> RFC. Why is it appropriate to publish this as informational? >>=20 >> Because TCPM didn't want to recommend the currently implemented DCTCP >> as a PS. For a PS, the WG would have liked to make changes. And those >> changes would be unlikely to see implementation for at least a while. >>=20 >> So the options were: (1) document what current implementations do, = but as >> Informational or (2) have the WG do a PS, but one without an >> implementation. We picked (1). >>=20 >> If the IESG felt that the current doc should be PS, none of the = authors would >> (I believe) object, but the WG probably would. >=20 > Publishing this doc on standards track would IMHO at least require = another working group last call. Sure, and I think some of the documented issues might prevent = publication on standards track anyway. But that still does not = necessarily make =E2=80=9Cinformational=E2=80=9D appropriate. But to be clear, I am not asking for the status to be changed. I am = asking for a paragraph to describe the reasoning and expectations behind = making it informational. Thanks, Ben.= From nobody Thu Jun 22 07:43:22 2017 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 C4A4C1296C9; Thu, 22 Jun 2017 07:43:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vut_zl3jQ0_P; Thu, 22 Jun 2017 07:43:19 -0700 (PDT) Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-eopbgr30099.outbound.protection.outlook.com [40.107.3.99]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E92AD129572; Thu, 22 Jun 2017 07:43:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=rS4qtTm3ZgzbDeRN0XR0yah4sgiccIAO6+N17fEi1qE=; b=AooyP1rMQuQOW5+L2+390lXW04ub+vfbb/xl4xcG++ajI+p1dp6iJmRWg+OrKpU4HG4Kzc9QG/CAvpP+mHJefMt91xrZ3EesmRD90iTCHELTbL/ZzVwIHTtxXnCUJ2hthHfKBISNOCQks5VdKPX4bEOBDk+SGwT3cqDXoRjg9qY= Received: from AM5PR0701MB2547.eurprd07.prod.outlook.com (10.173.92.15) by AM5PR0701MB2369.eurprd07.prod.outlook.com (10.169.152.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1220.5; Thu, 22 Jun 2017 14:43:16 +0000 Received: from AM5PR0701MB2547.eurprd07.prod.outlook.com ([fe80::8c06:20b8:4ca1:4bf8]) by AM5PR0701MB2547.eurprd07.prod.outlook.com ([fe80::8c06:20b8:4ca1:4bf8%18]) with mapi id 15.01.1199.012; Thu, 22 Jun 2017 14:43:16 +0000 From: "Scharf, Michael (Nokia - DE/Stuttgart)" To: Ben Campbell CC: "Eggert, Lars" , The IESG , "draft-ietf-tcpm-dctcp@ietf.org" , "tcpm-chairs@ietf.org" , "tcpm@ietf.org" Thread-Topic: Ben Campbell's No Objection on draft-ietf-tcpm-dctcp-07: (with COMMENT) Thread-Index: AQHS6r+WxSiDuzqCb02JLHHzAVKTF6IweR6AgABunwCAAAYSAIAAAMtQgAAGJQCAAAFJUA== Date: Thu, 22 Jun 2017 14:43:16 +0000 Message-ID: References: <149807116935.15620.7561139175975610205.idtracker@ietfa.amsl.com> <5016F105-106C-4D5E-865E-76DF3A8F0AC0@netapp.com> In-Reply-To: Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: nostrum.com; dkim=none (message not signed) header.d=none;nostrum.com; dmarc=none action=none header.from=nokia.com; x-originating-ip: [135.245.212.24] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM5PR0701MB2369; 7:dSSj2Iu0O9Bi3+k5d+npO6FsumrukYLA9jR9T9UCpOa8UklVTLSInkL8URI6Jl+IIdOofh6MoP8fvneHhrkjjsEKuaGEwGL0/Vlu65B/9DkBs4uixc0zYIz9QBqQwld/UrmnxEP24dezF8NA/jzhpF2P46aVpC9ZP8zYn/HSSpfj55rNKev1cNMlMbDj02UVIurYddbf5w4f9W2TIaHMIy5Fvzt04aYWGquMC4Z+9KkuvOa+XkoPguWtov/Dp69gT59F1UHrjPDmkXjIWhVjToujUdunQA81IPXB/fKxe6ZRCcXXZMrzXu5EDh2hulTZeZZE6MyqySOF4MLXvgEUJV/5Dh2NqyojG+2EeW2E6MOIzcPMKpN6VmoOJlULq4ovsPu8uHIjhNVwk+D0bkM702S08+yRWijbVskZiia1HRXSloRcZt33EWlJ9AD5xjLBKXw1PoxRBopRUMr/PvqSJCBZOoRBOeH6TxVeUo+sOYaSYkF/4M2JmXbCOEZe0g4x6ZdBSEWLZonohM5j1pVDJko1xH+QeuzEeeInVcQpcPGcyCSZI1PlP64BkpeqVE7mB9UuV/gz5+3gjmdCFS8MsdUatYUbG84Z5nxVaCWqbnYoN81kt7s6E1XJhEFN87K7R4DxbbZR+1LGIcBmVYcuKt1K0UPi7Hgwp7abBNKLxvC9IEgI2nKPRMqhYsgNeHGBkyYGc9ao63bagMyCp0d26QjWzVWSmrdxXC89/GiLoLjD5p8Icu9EEyi05QDyecozWIrus4kyxfF+hGKZnjVL7xTKwkzBbVOs1TEnvbAO0qE= x-ms-office365-filtering-correlation-id: 2a4d8290-2a57-48a5-7419-08d4b97d0495 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500055)(300135000095)(300000501055)(300135300095)(22001)(300000502055)(300135100095)(2017030254075)(48565401081)(300000503055)(300135400095)(201703131423075)(201703031133081)(201702281549075)(300000504055)(300135200095)(300000505055)(300135600095)(300000506048)(300135500095); SRVR:AM5PR0701MB2369; x-ms-traffictypediagnostic: AM5PR0701MB2369: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105)(100405760836317); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(93006095)(93001095)(3002001)(100000703101)(100105400095)(10201501046)(6055026)(6041248)(20161123564025)(20161123558100)(20161123560025)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM5PR0701MB2369; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM5PR0701MB2369; x-forefront-prvs: 03468CBA43 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39860400002)(39840400002)(39450400003)(39400400002)(39410400002)(39850400002)(24454002)(377454003)(377424004)(45080400002)(5250100002)(81166006)(8936002)(9686003)(54906002)(99286003)(66066001)(53546010)(7696004)(478600001)(54356999)(50986999)(966005)(76176999)(4001150100001)(4326008)(230783001)(25786009)(93886004)(305945005)(14454004)(189998001)(229853002)(5660300001)(74316002)(2950100002)(6916009)(2906002)(2900100001)(6116002)(102836003)(7736002)(86362001)(110136004)(6436002)(6506006)(6306002)(8676002)(3280700002)(53936002)(38730400002)(33656002)(3660700001)(55016002)(3846002); DIR:OUT; SFP:1102; SCL:1; SRVR:AM5PR0701MB2369; H:AM5PR0701MB2547.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Jun 2017 14:43:16.4706 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0701MB2369 Archived-At: Subject: Re: [tcpm] Ben Campbell's No Objection on draft-ietf-tcpm-dctcp-07: (with COMMENT) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2017 14:43:22 -0000 PiA+PiBPbiAyMDE3LTYtMjIsIGF0IDE1OjUxLCBCZW4gQ2FtcGJlbGwgPGJlbkBub3N0cnVtLmNv bT4gd3JvdGU6DQo+ID4+Pj4gT24gSnVuIDIyLCAyMDE3LCBhdCAyOjE1IEFNLCBFZ2dlcnQsIExh cnMgPGxhcnNAbmV0YXBwLmNvbT4gd3JvdGU6DQo+ID4+Pj4NCj4gPj4+PiBUaGlzIGRvZXNuJ3Qg ZGVzY3JpYmUgInRoZSBNaWNyb3NvZnQgaW1wbGVtZW50YXRpb24iLiBJdCBkZXNjcmliZXMNCj4g Pj4+PiBhIFRDUA0KPiA+PiB2YXJpYW50IHRoYXQgb3JpZ2luYXRlZCB3aXRoIE1pY3Jvc29mdCBi dXQgaGFzIGFsc28gYmVlbiBzaGlwcGluZyBhcw0KPiA+PiBwYXJ0IG9mIExpbnV4IGFuZCBGcmVl QlNEIGZvciBhdCBsZWFzdCBhIGZldyB5ZWFycyBub3cuIFRoZSBwdXJwb3NlDQo+ID4+IG9mIGRl c2NyaWJpbmcgaXQgaXMgc28gdGhhdCBvdGhlcnMgY2FuIHByb2R1Y2UgaW50ZXJvcGVyYWJsZQ0K PiA+PiBpbXBsZW1lbnRhdGlvbnMgd2l0aG91dCBuZWVkIHRvIHJlc29ydCB0byByZWFkaW5nIChs aWNlbnNlZCkgY29kZS4NCj4gPj4+DQo+ID4+PiBUaGF0IHJlYWxseSBzZWVtcyB0byBiZSBhIGNh c2Ugb2YgZGVmaW5pbmcgYSBzdGFuZGFyZCBpbiBhbg0KPiA+Pj4gaW5mb3JtYXRpb25hbA0KPiA+ PiBSRkMuIFdoeSBpcyBpdCBhcHByb3ByaWF0ZSB0byBwdWJsaXNoIHRoaXMgYXMgaW5mb3JtYXRp b25hbD8NCj4gPj4NCj4gPj4gQmVjYXVzZSBUQ1BNIGRpZG4ndCB3YW50IHRvIHJlY29tbWVuZCB0 aGUgY3VycmVudGx5IGltcGxlbWVudGVkDQo+IERDVENQDQo+ID4+IGFzIGEgUFMuIEZvciBhIFBT LCB0aGUgV0cgd291bGQgaGF2ZSBsaWtlZCB0byBtYWtlIGNoYW5nZXMuIEFuZCB0aG9zZQ0KPiA+ PiBjaGFuZ2VzIHdvdWxkIGJlIHVubGlrZWx5IHRvIHNlZSBpbXBsZW1lbnRhdGlvbiBmb3IgYXQg bGVhc3QgYSB3aGlsZS4NCj4gPj4NCj4gPj4gU28gdGhlIG9wdGlvbnMgd2VyZTogKDEpIGRvY3Vt ZW50IHdoYXQgY3VycmVudCBpbXBsZW1lbnRhdGlvbnMgZG8sDQo+ID4+IGJ1dCBhcyBJbmZvcm1h dGlvbmFsIG9yICgyKSBoYXZlIHRoZSBXRyBkbyBhIFBTLCBidXQgb25lIHdpdGhvdXQgYW4NCj4g Pj4gaW1wbGVtZW50YXRpb24uIFdlIHBpY2tlZCAoMSkuDQo+ID4+DQo+ID4+IElmIHRoZSBJRVNH IGZlbHQgdGhhdCB0aGUgY3VycmVudCBkb2Mgc2hvdWxkIGJlIFBTLCBub25lIG9mIHRoZQ0KPiA+ PiBhdXRob3JzIHdvdWxkIChJIGJlbGlldmUpIG9iamVjdCwgYnV0IHRoZSBXRyBwcm9iYWJseSB3 b3VsZC4NCj4gPg0KPiA+IFB1Ymxpc2hpbmcgdGhpcyBkb2Mgb24gc3RhbmRhcmRzIHRyYWNrIHdv dWxkIElNSE8gYXQgbGVhc3QgcmVxdWlyZSBhbm90aGVyDQo+IHdvcmtpbmcgZ3JvdXAgbGFzdCBj YWxsLg0KPiANCj4gU3VyZSwgYW5kIEkgdGhpbmsgc29tZSBvZiB0aGUgZG9jdW1lbnRlZCBpc3N1 ZXMgbWlnaHQgcHJldmVudCBwdWJsaWNhdGlvbg0KPiBvbiBzdGFuZGFyZHMgdHJhY2sgYW55d2F5 LiBCdXQgdGhhdCBzdGlsbCBkb2VzIG5vdCBuZWNlc3NhcmlseSBtYWtlDQo+IOKAnGluZm9ybWF0 aW9uYWzigJ0gYXBwcm9wcmlhdGUuDQo+IA0KPiBCdXQgdG8gYmUgY2xlYXIsIEkgYW0gbm90IGFz a2luZyBmb3IgdGhlIHN0YXR1cyB0byBiZSBjaGFuZ2VkLiBJIGFtIGFza2luZyBmb3IgYQ0KPiBw YXJhZ3JhcGggdG8gZGVzY3JpYmUgdGhlIHJlYXNvbmluZyBhbmQgZXhwZWN0YXRpb25zIGJlaGlu ZCBtYWtpbmcgaXQNCj4gaW5mb3JtYXRpb25hbC4NCg0KRm9yIHdoYXQgaXQgaXMgd29ydGgsIGZy b20gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi10Y3BtLWRjdGNw L3NoZXBoZXJkd3JpdGV1cC8NCg0KIlRoZSBvYmplY3RpdmUgb2YgdGhpcyBpbmZvcm1hdGlvbmFs IG1lbW8gaXMgdG8gZG9jdW1lbnQgYW4gYWx0ZXJuYXRpdmUgVENQIGNvbmdlc3Rpb24gY29udHJv bCBhbGdvcml0aG0gdGhhdCBpcyBrbm93biB0byBiZSB3aWRlbHkgZGVwbG95ZWQuIEl0IGlzIGNv bnNlbnN1cyBpbiB0aGUgVENQTSB3b3JraW5nIGdyb3VwIHRoYXQgYSBEQ1RDUCBzdGFuZGFyZCB3 b3VsZCByZXF1aXJlIGZ1cnRoZXIgd29yay4gQSBwcmVjaXNlIGRvY3VtZW50YXRpb24gb2YgcnVu bmluZyBjb2RlIGVuYWJsZXMgZm9sbG93LXVwIGV4cGVyaW1lbnRhbCBvciBzdGFuZGFyZHMgdHJh Y2sgUkZDcy4iDQoNCk1pY2hhZWwNCg0KDQo= From nobody Thu Jun 22 07:47:51 2017 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 C42521296B3; Thu, 22 Jun 2017 07:47:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.881 X-Spam-Level: X-Spam-Status: No, score=-1.881 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EVbAHgAsZeOL; Thu, 22 Jun 2017 07:47:44 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A38712702E; Thu, 22 Jun 2017 07:47:44 -0700 (PDT) Received: from [10.0.1.63] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v5MElgEg037819 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 22 Jun 2017 09:47:43 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.63] Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Ben Campbell In-Reply-To: <5016F105-106C-4D5E-865E-76DF3A8F0AC0@netapp.com> Date: Thu, 22 Jun 2017 09:47:42 -0500 Cc: The IESG , "draft-ietf-tcpm-dctcp@ietf.org" , Michael Scharf , "tcpm-chairs@ietf.org" , "tcpm@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <149807116935.15620.7561139175975610205.idtracker@ietfa.amsl.com> <5016F105-106C-4D5E-865E-76DF3A8F0AC0@netapp.com> To: "Eggert, Lars" X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [tcpm] Ben Campbell's No Objection on draft-ietf-tcpm-dctcp-07: (with COMMENT) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2017 14:47:46 -0000 > On Jun 22, 2017, at 9:13 AM, Eggert, Lars wrote: >=20 > On 2017-6-22, at 15:51, Ben Campbell wrote: >>> On Jun 22, 2017, at 2:15 AM, Eggert, Lars wrote: >>>=20 >>> This doesn't describe "the Microsoft implementation". It describes a = TCP variant that originated with Microsoft but has also been shipping as = part of Linux and FreeBSD for at least a few years now. The purpose of = describing it is so that others can produce interoperable = implementations without need to resort to reading (licensed) code. >>=20 >> That really seems to be a case of defining a standard in an = informational RFC. Why is it appropriate to publish this as = informational? >=20 > Because TCPM didn't want to recommend the currently implemented DCTCP = as a PS. For a PS, the WG would have liked to make changes. And those = changes would be unlikely to see implementation for at least a while. >=20 > So the options were: (1) document what current implementations do, but = as Informational or (2) have the WG do a PS, but one without an = implementation. We picked (1). >=20 > If the IESG felt that the current doc should be PS, none of the = authors would (I believe) object, but the WG probably would. As I mentioned to Michael, I am not asking for a status change, just an = explanation in the text. Would it make sense to add a paragraph to the = effect of =E2=80=9CThis documents existing implementations but is not = mature enough to be considered a standard. Use at your own risk=E2=80=9D? = (With some wordsmithing, of course.) Thanks, Ben. From nobody Thu Jun 22 08:00:54 2017 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 02389129AB2; Thu, 22 Jun 2017 08:00:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.881 X-Spam-Level: X-Spam-Status: No, score=-1.881 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dXzba2hCPqd5; Thu, 22 Jun 2017 08:00:51 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D860129AAD; Thu, 22 Jun 2017 08:00:51 -0700 (PDT) Received: from [10.0.1.63] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v5MF0nqS040093 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 22 Jun 2017 10:00:50 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.63] Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Ben Campbell In-Reply-To: <0096924A-FC51-41F0-B2AA-7FCD58B0E1EA@netapp.com> Date: Thu, 22 Jun 2017 10:00:49 -0500 Cc: The IESG , "draft-ietf-tcpm-dctcp@ietf.org" , Michael Scharf , "tcpm-chairs@ietf.org" , "tcpm@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <1BC33BF7-6143-44D3-BBA4-757086D8821E@nostrum.com> References: <149807116935.15620.7561139175975610205.idtracker@ietfa.amsl.com> <5016F105-106C-4D5E-865E-76DF3A8F0AC0@netapp.com> <0096924A-FC51-41F0-B2AA-7FCD58B0E1EA@netapp.com> To: "Eggert, Lars" X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [tcpm] Ben Campbell's No Objection on draft-ietf-tcpm-dctcp-07: (with COMMENT) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2017 15:00:53 -0000 > On Jun 22, 2017, at 9:57 AM, Eggert, Lars wrote: >=20 > Hi, >=20 > On 2017-6-22, at 16:47, Ben Campbell wrote: >> As I mentioned to Michael, I am not asking for a status change, just = an explanation in the text. Would it make sense to add a paragraph to = the effect of =E2=80=9CThis documents existing implementations but is = not mature enough to be considered a standard. Use at your own risk=E2=80=9D= ? (With some wordsmithing, of course.) >=20 > I don't think documenting the reasons why an RFC is not a Standards = Track document is current practice. At least I don't see text related to = this in other Informational RFCs. Well, technically, I am asking to document why it is informational. = There have been repeated discussions over time about whether it=E2=80=99s = appropriate to put 2119 language in an informational at all. Opinions = are mixed. My personal opinion is that it is okay to do so as long as = the reasons for doing so are clear. I do not believe they are clear in = the existing text. Ben.= From nobody Thu Jun 22 08:02:08 2017 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 BE7851204DA; Thu, 22 Jun 2017 08:02:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=netapp.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RxKpUEvc50tp; Thu, 22 Jun 2017 08:02:05 -0700 (PDT) Received: from mx144.netapp.com (mx144.netapp.com [216.240.21.25]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 029CA127419; Thu, 22 Jun 2017 08:02:04 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.39,373,1493708400"; d="asc'?scan'208";a="201109233" Received: from hioexcmbx07-prd.hq.netapp.com ([10.122.105.40]) by mx144-out.netapp.com with ESMTP; 22 Jun 2017 07:36:45 -0700 Received: from VMWEXCCAS03-PRD.hq.netapp.com (10.122.105.19) by hioexcmbx07-prd.hq.netapp.com (10.122.105.40) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 22 Jun 2017 07:56:55 -0700 Received: from NAM02-CY1-obe.outbound.protection.outlook.com (10.120.60.153) by VMWEXCCAS03-PRD.hq.netapp.com (10.122.105.19) with Microsoft SMTP Server (TLS) id 15.0.1210.3 via Frontend Transport; Thu, 22 Jun 2017 07:56:55 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netapp.onmicrosoft.com; s=selector1-netapp-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=hPJgdIqrT7vRTer48H/WqfN2G+NsoHSWsp4XIMzmEak=; b=DgwOSqD3x93gPX4aahpGQzbvQ0zrTH5MkQ8onkPsriJaC0v1BAxnOIhHjzfCKS1O0u6IF6pMUUrfL7/rkaOskQzbFaz9EYz9x+ovSKbDLTHoglmAeDw5anpHXscXvVp4jZ+XwvFrmeefvHv37SWhd9cWb7vMThKv+rIpLsHuFP0= Received: from BLUPR06MB1764.namprd06.prod.outlook.com (10.162.224.150) by BLUPR06MB1762.namprd06.prod.outlook.com (10.162.224.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1178.14; Thu, 22 Jun 2017 14:57:01 +0000 Received: from BLUPR06MB1764.namprd06.prod.outlook.com ([10.162.224.150]) by BLUPR06MB1764.namprd06.prod.outlook.com ([10.162.224.150]) with mapi id 15.01.1199.016; Thu, 22 Jun 2017 14:57:01 +0000 From: "Eggert, Lars" To: Ben Campbell CC: The IESG , "draft-ietf-tcpm-dctcp@ietf.org" , Michael Scharf , "tcpm-chairs@ietf.org" , "tcpm@ietf.org" Thread-Topic: Ben Campbell's No Objection on draft-ietf-tcpm-dctcp-07: (with COMMENT) Thread-Index: AQHS6r/bDoxQRZwJ4EqgoI8OV2iMZqIweRmAgABuowCAAAYQAIAACbUAgAACmIA= Date: Thu, 22 Jun 2017 14:57:01 +0000 Message-ID: <0096924A-FC51-41F0-B2AA-7FCD58B0E1EA@netapp.com> References: <149807116935.15620.7561139175975610205.idtracker@ietfa.amsl.com> <5016F105-106C-4D5E-865E-76DF3A8F0AC0@netapp.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3273) authentication-results: nostrum.com; dkim=none (message not signed) header.d=none;nostrum.com; dmarc=none action=none header.from=netapp.com; x-originating-ip: [217.70.211.15] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BLUPR06MB1762; 7:KLSESx1c5rU1ESLVpqBjFw9CWYcOXrQoo6hcBmid3bVrsoWKfTTDcXjQUardiTEFakRuy/qRpBm2VbDZ6iHNvOVpDW6+cDDNZgGd4LJhd+Or+Evom1KwikULtV/AZIyJgNCbCfeOsTzDC+Fb8ELMS9Ryi95vrMkmU5sqdnPqDRNUPRhWSr3Hy+bcWtmPNJWG5W6cQrhKwBUL1dQFLm9hNVGMaFvB5ZnwcJbq/792fXDLWj1YYDAU0VIYvRqaxjWdnm+44TEP+JIutwt7TMl7I8f73g2xLjSRDlS7YylBOQFLhyWsOKstpCpFf8sg1Z/FGuQVJYkka5WPLJDxEy7uZDvivmbF7rxFNl3D92iPm5CfBASI8+EsvEDTyy+6KKWyTc0ZfqO9uTC2mDQRNdkZYNrOcOnQFHFthiqyUGOB1OUkKsjnzl9sKWhexqETIaqRCRqsNyCsg2RQcqPp57mf5aCLjU9ARBF7Tqx0AbludqtFnv8wBp1SNzfq2Oy0VMR9ygfLCizMFl5VVAJp99ltA6JvGCGi0brDOTcHfCi3IE+vfJwUDn9ylR8rcKYnEF7ADkDwEtVC6ExF4pHTCwOQGPznlvf9Lbl3n0NnLFITuEAfdGkDmyXd7r7lpTUu0KgPweaW0jX/gLMP8eVmv67n+p8ibbFsMP+hW9JbdHReXX6Q+i07EOSmZkdO0kOjoyFQRzBJLzxfgT8l97lMsd9UaRY2wTXRssDUesTtMABzEtd06M88EF5cPPf8tj/CCv2Np1RpRf41dxuOUgLOS5+gRN4U9ifYgGGbcugilgykgOc= x-ms-office365-filtering-correlation-id: 00089595-e9e3-4223-ca72-08d4b97ef046 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(49563074)(201703131423075)(201703031133081); SRVR:BLUPR06MB1762; x-ms-traffictypediagnostic: BLUPR06MB1762: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(102415395)(6040450)(601004)(2401047)(8121501046)(5005006)(3002001)(93006095)(93001095)(100000703101)(100105400095)(10201501046)(6055026)(6041248)(20161123558100)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123564025)(20161123560025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BLUPR06MB1762; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BLUPR06MB1762; x-forefront-prvs: 03468CBA43 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(979002)(6009001)(39410400002)(39850400002)(39450400003)(39400400002)(39840400002)(24454002)(377424004)(102836003)(2900100001)(8936002)(6116002)(230783001)(50226002)(93886004)(8676002)(36756003)(6486002)(77096006)(54906002)(6512007)(189998001)(53546010)(33656002)(3660700001)(3280700002)(2906002)(7736002)(122556002)(86362001)(57306001)(99286003)(66066001)(81166006)(81156014)(4326008)(53936002)(4001150100001)(6246003)(305945005)(14454004)(2950100002)(6916009)(6506006)(5660300001)(229853002)(99936001)(83716003)(50986999)(76176999)(82746002)(25786009)(110136004)(3846002)(38730400002)(6436002)(478600001)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR06MB1762; H:BLUPR06MB1764.namprd06.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/signed; boundary="Apple-Mail=_F576A0AC-E9E9-46F6-AA18-3B4D02757260"; protocol="application/pgp-signature"; micalg=pgp-sha512 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Jun 2017 14:57:01.1228 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4b0911a0-929b-4715-944b-c03745165b3a X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR06MB1762 X-OriginatorOrg: netapp.com Archived-At: Subject: Re: [tcpm] Ben Campbell's No Objection on draft-ietf-tcpm-dctcp-07: (with COMMENT) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2017 15:02:07 -0000 --Apple-Mail=_F576A0AC-E9E9-46F6-AA18-3B4D02757260 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, On 2017-6-22, at 16:47, Ben Campbell wrote: > As I mentioned to Michael, I am not asking for a status change, just = an explanation in the text. Would it make sense to add a paragraph to = the effect of =E2=80=9CThis documents existing implementations but is = not mature enough to be considered a standard. Use at your own risk=E2=80=9D= ? (With some wordsmithing, of course.) I don't think documenting the reasons why an RFC is not a Standards = Track document is current practice. At least I don't see text related to = this in other Informational RFCs. Lars --Apple-Mail=_F576A0AC-E9E9-46F6-AA18-3B4D02757260 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEmpq0ZpSoejRmyhheVLXDCb9wwVcFAllL2rsACgkQVLXDCb9w wVelWBAApWsI38Cfp+2Uq0dhK8F7df3UH+edkGdfh+BjW+2b/XB0O4oe1inN7/Sx 4DQWCEhkViNUvoIJWHl9dOKlX/FpFIhaZxaH37xjKnoVGsR7+0bPMX0t3kvnBy5g ckvO+rrGYaFc2OImlYkgCnqj0Dxcy9Bt2aG7SEALqKauig79UWlzvkGc+68f2z7v 60hY6ZVDpwnurOs/LNHPTwdMwKVjQDakcjrgWiJBTFIYKoBoMRa/Kk+PTE0PTgHj lJv4JskrpTya6EXMxcROOyMgZPdw/q5lFyXRmTNpI2j2ePdJZm1cezeJj0xHg8RG M39ON7ZTp0ouMZduQSf0KiVnRjqv78ks6/Cys3myUejYGL5OiNk9hLq0vxPIRwx1 69/4bJpr25evLH/q+R5Bl9OrC+XkitshVdhiMLY3cEENp9VZ/GtrZ+jU0SkMt9PD qtqbtuRj/sBlXgXRBGJTpJKtSFdRTGaRjdmowNeIOKET5b70J1vPu69cXXB/AB3f OeH/wJyw9/aynoiBEn3pBZbQYMpy3L6zhLgyUXv6dYaOV/byrJ5fVALOsiHgu0pF xZ6Fb2vGRSPz47dX7kImDECqJGw3QukCIq0qC/W3+UFNUOSL/jSIpV1YZneHbxyi VwH8nPGJuy+zKNhm8RlF6UDmm+fpN/4oHCP95dQtm247KaF1OVo= =wYG+ -----END PGP SIGNATURE----- --Apple-Mail=_F576A0AC-E9E9-46F6-AA18-3B4D02757260-- From nobody Thu Jun 22 08:07:34 2017 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 C517C126C22; Thu, 22 Jun 2017 08:07:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rGF1dLC5_b4u; Thu, 22 Jun 2017 08:07:21 -0700 (PDT) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F36412025C; Thu, 22 Jun 2017 08:07:21 -0700 (PDT) Received: from lawyers.icir.org (envoy.icir.org [192.150.187.30]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id v5MF7KMC029105; Thu, 22 Jun 2017 08:07:20 -0700 (PDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 212FB7B8BE83; Thu, 22 Jun 2017 11:07:20 -0400 (EDT) To: "Eggert\, Lars" From: Mark Allman Reply-To: mallman@icir.org cc: Ben Campbell , "tcpm\@ietf.org" , "draft-ietf-tcpm-dctcp\@ietf.org" , The IESG , "tcpm-chairs\@ietf.org" In-Reply-To: <0096924A-FC51-41F0-B2AA-7FCD58B0E1EA@netapp.com> Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Drift Away X-URL-0: https://www.icir.org/mallman-files/Document20964.docx MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-------459435943823349593450"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Thu, 22 Jun 2017 11:07:20 -0400 Message-ID: <75031.1498144040@lawyers.icir.org> Sender: mallman@icir.org Archived-At: Subject: Re: [tcpm] Ben Campbell's No Objection on draft-ietf-tcpm-dctcp-07: (with COMMENT) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2017 15:07:26 -0000 --=-------459435943823349593450 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Hi Lars! > I don't think documenting the reasons why an RFC is not a > Standards Track document is current practice. At least I don't see > text related to this in other Informational RFCs.=20 What's the harm? Michael wrote it in the shepherd writeup. Why not just chuck it in the doc to provide context? How to take a spec that is an informational is an obvious question. Why not just say what we're doing? Is there a downside I am missing here? Is there some disagreement to why we're doing this? allman, going back into my hole now ... --=-------459435943823349593450 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAllL3ScACgkQWyrrWs4yIs6Z2gCcDL5vtnYABg/9EuaRw9DgtK7I 2X0AoJXbdvBcIZeNdaJKcSJZ1fMYS6zs =1XZD -----END PGP SIGNATURE----- --=-------459435943823349593450-- From nobody Thu Jun 22 10:51:38 2017 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 1FC4112751F; Thu, 22 Jun 2017 10:51:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.881 X-Spam-Level: X-Spam-Status: No, score=-1.881 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8sJovFfSqvjo; Thu, 22 Jun 2017 10:51:27 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8FBD127B5A; Thu, 22 Jun 2017 10:51:27 -0700 (PDT) Received: from [10.0.1.63] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v5MHpQOr067799 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 22 Jun 2017 12:51:26 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.63] Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Ben Campbell In-Reply-To: Date: Thu, 22 Jun 2017 12:51:25 -0500 Cc: "Eggert, Lars" , The IESG , "draft-ietf-tcpm-dctcp@ietf.org" , "tcpm-chairs@ietf.org" , "tcpm@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <149807116935.15620.7561139175975610205.idtracker@ietfa.amsl.com> <5016F105-106C-4D5E-865E-76DF3A8F0AC0@netapp.com> To: "Scharf, Michael (Nokia - DE/Stuttgart)" X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [tcpm] Ben Campbell's No Objection on draft-ietf-tcpm-dctcp-07: (with COMMENT) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2017 17:51:30 -0000 > On Jun 22, 2017, at 9:43 AM, Scharf, Michael (Nokia - DE/Stuttgart) = wrote: >=20 >>>> On 2017-6-22, at 15:51, Ben Campbell wrote: >>>>>> On Jun 22, 2017, at 2:15 AM, Eggert, Lars = wrote: >>>>>>=20 >>>>>> This doesn't describe "the Microsoft implementation". It = describes >>>>>> a TCP >>>> variant that originated with Microsoft but has also been shipping = as >>>> part of Linux and FreeBSD for at least a few years now. The purpose >>>> of describing it is so that others can produce interoperable >>>> implementations without need to resort to reading (licensed) code. >>>>>=20 >>>>> That really seems to be a case of defining a standard in an >>>>> informational >>>> RFC. Why is it appropriate to publish this as informational? >>>>=20 >>>> Because TCPM didn't want to recommend the currently implemented >> DCTCP >>>> as a PS. For a PS, the WG would have liked to make changes. And = those >>>> changes would be unlikely to see implementation for at least a = while. >>>>=20 >>>> So the options were: (1) document what current implementations do, >>>> but as Informational or (2) have the WG do a PS, but one without an >>>> implementation. We picked (1). >>>>=20 >>>> If the IESG felt that the current doc should be PS, none of the >>>> authors would (I believe) object, but the WG probably would. >>>=20 >>> Publishing this doc on standards track would IMHO at least require = another >> working group last call. >>=20 >> Sure, and I think some of the documented issues might prevent = publication >> on standards track anyway. But that still does not necessarily make >> =E2=80=9Cinformational=E2=80=9D appropriate. >>=20 >> But to be clear, I am not asking for the status to be changed. I am = asking for a >> paragraph to describe the reasoning and expectations behind making it >> informational. >=20 > For what it is worth, from = https://datatracker.ietf.org/doc/draft-ietf-tcpm-dctcp/shepherdwriteup/ >=20 > "The objective of this informational memo is to document an = alternative TCP congestion control algorithm that is known to be widely = deployed. It is consensus in the TCPM working group that a DCTCP = standard would require further work. A precise documentation of running = code enables follow-up experimental or standards track RFCs.=E2=80=9D Those exact words or something to their effect in the document would = resolve my comment. I don=E2=80=99t think we can expect readers to look = at the shepherd writeup. Thanks! Ben. From nobody Fri Jun 23 09:31:50 2017 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 51166128ACA; Fri, 23 Jun 2017 09:31:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=bobbriscoe.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xh-ZCrNGi771; Fri, 23 Jun 2017 09:31:38 -0700 (PDT) Received: from server.dnsblock1.com (server.dnsblock1.com [85.13.236.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F0C401200B9; Fri, 23 Jun 2017 09:31:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Type:In-Reply-To:MIME-Version:Date: Message-ID:From:References:Cc:To:Subject:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=oj+nLGegbJZOKTfrplvweRqoTqgVpGx/9M4tZr0Xiy4=; b=WBjz8ZqaeqSZCfpHRzQJMSz3W yTwx57BFYLx9X0G4RPNKO9E8tMVJXCS96hvl2VDBZZnn04PPNZukOpIo7b1ITLUMK93fXplTomdFl 5w2oXBa3QULT9mksbnMEK8OhqOSpcuL4pIQJ6sVaC/ljorSpt2gQxnK/ODSlytzkGshoZggS3Hfu0 ADsV/0ZjMPODz03LeDr1LkOkkkCQu46t59Z+tEnhBxWHv4Em/ln1OaRwZzWw7z6AZ3CG2+oW57GYG N00/a4FAUFrYUZmn7X9j/73Qd+HvilA/0OHk0IONMz3OyS64Kfgo7RunA5x2W+EY2upiao6neYd5/ +VE7JamRg==; Received: from [31.185.128.124] (port=58798 helo=[192.168.0.6]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89) (envelope-from ) id 1dORUd-00082q-UG; Fri, 23 Jun 2017 17:31:36 +0100 To: "Eggert, Lars" , Ben Campbell Cc: "tcpm@ietf.org" , "draft-ietf-tcpm-dctcp@ietf.org" , The IESG , "tcpm-chairs@ietf.org" References: <149807116935.15620.7561139175975610205.idtracker@ietfa.amsl.com> From: Bob Briscoe Message-ID: <6f31d42e-8b4c-5f26-a5a9-560fb1f0ba0b@bobbriscoe.net> Date: Fri, 23 Jun 2017 17:31:34 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------5BCA6AA236054F0723EAED07" Content-Language: en-GB X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.dnsblock1.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - bobbriscoe.net X-Get-Message-Sender-Via: server.dnsblock1.com: authenticated_id: in@bobbriscoe.net X-Authenticated-Sender: server.dnsblock1.com: in@bobbriscoe.net Archived-At: Subject: Re: [tcpm] Ben Campbell's No Objection on draft-ietf-tcpm-dctcp-07: (with COMMENT) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jun 2017 16:31:40 -0000 This is a multi-part message in MIME format. --------------5BCA6AA236054F0723EAED07 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Lars, On 22/06/17 08:15, Eggert, Lars wrote: >> - 4.1: Citation for NewReno? > We can point to RFC6582. In the context of the DCTCP draft: It is useful to implement DCTCP as additional actions on top of an existing congestion control algorithm like NewReno. So the text should probably say Reno, rather than NewReno, and the citation should be to Reno congestion control [RFC5681], not the NewReno addition, which is solely about responding to partial ACKs. Bob -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ --------------5BCA6AA236054F0723EAED07 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 7bit Lars,

On 22/06/17 08:15, Eggert, Lars wrote:
- 4.1: Citation for NewReno?

We can point to RFC6582.
In the context of the DCTCP draft:
   It is useful to implement DCTCP as additional actions on top of an
   existing congestion control algorithm like NewReno.
So the text should probably say Reno, rather than NewReno, and the citation should be to Reno congestion control [RFC5681], not the NewReno addition, which is solely about responding to partial ACKs.


Bob


-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/
--------------5BCA6AA236054F0723EAED07-- From nobody Fri Jun 23 10:51:06 2017 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 5BDD8128DE7 for ; Fri, 23 Jun 2017 10:51:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=bobbriscoe.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wN0VZuRjn7xe for ; Fri, 23 Jun 2017 10:51:03 -0700 (PDT) Received: from server.dnsblock1.com (server.dnsblock1.com [85.13.236.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1BD30126DCA for ; Fri, 23 Jun 2017 10:51:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Type:In-Reply-To:MIME-Version:Date: Message-ID:Cc:References:To:Subject:From:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=4S7vBhL1l6JJ/sht/0snzORZ8XcnEKB1S/fje0VjAD8=; b=CWgWLLDy3KRyCW0dSP08xQa+V A8/UVmP+f7bZ3dTUYmvc5p8Got4xfYc/pQkqVAGJvDXFD1DYPvusbu81K0Sekf8T0gGmy+iCrjYFF myLvZohhdV1y2AobJbW5qVF/0LKnh2kudoeONn2IPEjgwsQSS9orB2/+TzuY1GMgZJpCVMotR7c0w fEVoiBVUaRTEyKJV4S6m7TYS5oh7mqbZ7KNeYDDUsB/S0ZZmzxsP8ltAdiCald9ARAlqa+D3UJDC8 R0vXOib3F8l25i755GLiHhG/wDcj4Nv+NbODqaWNVxc9jmTkFRVG54Nia/yU7Af3jsuLaO06GOMtR Qkd4YPuBw==; Received: from [31.185.128.124] (port=59212 helo=[192.168.0.6]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89) (envelope-from ) id 1dOSjR-0005uX-61; Fri, 23 Jun 2017 18:50:57 +0100 From: Bob Briscoe To: Michael Tuexen , Randall Stewart , Xuesong Dong References: Cc: tcpm IETF list , marcelo bagnulo braun Message-ID: <4219b826-5034-c280-5f67-b03b98ea0a45@bobbriscoe.net> Date: Fri, 23 Jun 2017 18:50:56 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------A58BDABC9E88C8B5FA7A1743" Content-Language: en-GB X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.dnsblock1.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - bobbriscoe.net X-Get-Message-Sender-Via: server.dnsblock1.com: authenticated_id: in@bobbriscoe.net X-Authenticated-Sender: server.dnsblock1.com: in@bobbriscoe.net Archived-At: Subject: [tcpm] ECN++ (draft-bagnulo-tcpm-generalized-ecn-04) and SCTP X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jun 2017 17:51:05 -0000 This is a multi-part message in MIME format. --------------A58BDABC9E88C8B5FA7A1743 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Michael, Randall, Xuesong, Are you considering implementing ECN in SCTP? I noticed that your initial SCTP/ECN draft prohibits ECN on similar control packets to those prohibited in TCP. So I wrote this section about transferability to SCTP into the ECN++ draft, which is targeted at TCP but also has a section on variants. (The adoption call for the draft is below - deadline: 30 Jun). I know the details of handshake and other control packets are different, but I think the principles are transferable. Is this a correct understanding of the position wrt SCTP? Cheers Bob -------- Forwarded Message -------- Subject: [tcpm] Working group acceptance call draft-bagnulo-tcpm-generalized-ecn-04 Date: Fri, 16 Jun 2017 06:06:43 +0000 From: Scharf, Michael (Nokia - DE/Stuttgart) To: tcpm@ietf.org CC: tcpm-chairs@ietf.org Hi all, As requested by the authors, this e-mail starts a working group acceptance call for draft-bagnulo-tcpm-generalized-ecn-04, which will run on the list until June 30. The proposal is to add a new milestone to the TCPM charter Submit document on adding Explicit Congestion Notification (ECN) to TCP Control Packets to the IESG for publication as Experimental RFC and to use draft-bagnulo-tcpm-generalized-ecn as a starting point. If you believe that TCPM should work on a document in this space, and in particular if you are willing to review it, please reply to this e-mails. Please also speak up if you have any concerns or objections. Thanks Michael -- ________________________________________________________________ Bob Briscoehttp://bobbriscoe.net/ --------------A58BDABC9E88C8B5FA7A1743 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Michael, Randall, Xuesong,

Are you considering implementing ECN in SCTP? I noticed that your initial SCTP/ECN draft prohibits ECN on similar control packets to those prohibited in TCP. So I wrote this section about transferability to SCTP into the ECN++ draft, which is targeted at TCP but also has a section on variants.
(The adoption call for the draft is below - deadline: 30 Jun).
   
I know the details of handshake and other control packets are different, but I think the principles are transferable.
Is this a correct understanding of the position wrt SCTP?


Cheers


Bob


-------- Forwarded Message --------
Subject: [tcpm] Working group acceptance call draft-bagnulo-tcpm-generalized-ecn-04
Date: Fri, 16 Jun 2017 06:06:43 +0000
From: Scharf, Michael (Nokia - DE/Stuttgart) <michael.scharf@nokia.com>
To: tcpm@ietf.org <tcpm@ietf.org>
CC: tcpm-chairs@ietf.org <tcpm-chairs@ietf.org>


Hi all,

 

As requested by the authors, this e-mail starts a working group acceptance call for draft-bagnulo-tcpm-generalized-ecn-04, which will run on the list until June 30.

 

The proposal is to add a new milestone to the  TCPM charter

 

  Submit document on adding Explicit Congestion Notification (ECN) to TCP Control Packets to the IESG for publication as Experimental RFC

 

and to use draft-bagnulo-tcpm-generalized-ecn as a starting point.

 

If you believe that TCPM should work on a document in this space, and in particular if you are willing to review it, please reply to this e-mails. Please also speak up if you have any concerns or objections.

 

Thanks

 

Michael


-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/
--------------A58BDABC9E88C8B5FA7A1743-- From nobody Fri Jun 23 17:08:13 2017 Return-Path: X-Original-To: tcpm@ietf.org Delivered-To: tcpm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 82016129B2B; Fri, 23 Jun 2017 17:06:59 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: tcpm@ietf.org, ietf@kuehlewind.net X-Test-IDTracker: no X-IETF-IDTracker: 6.55.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149826281952.7840.14670113381364126190.idtracker@ietfa.amsl.com> Date: Fri, 23 Jun 2017 17:06:59 -0700 Archived-At: Subject: [tcpm] tcpm - Requested session has been scheduled for IETF 99 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jun 2017 00:06:59 -0000 Dear Michael Scharf, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. tcpm Session 1 (2:30:00) Monday, Morning Session I 0930-1200 Room Name: Karlin I/II size: 150 --------------------------------------------- Request Information: --------------------------------------------------------- Working Group Name: TCP Maintenance and Minor Extensions Area Name: Transport Area Session Requester: Michael Scharf Number of Sessions: 1 Length of Session(s): 2.5 Hours Number of Attendees: 80 Conflicts to Avoid: First Priority: iccrg tcpinc mptcp taps tsvarea tsvwg quic Second Priority: httpbis lwig maprg rtcweb rmcat teas People who must be present: Yoshifumi Nishida Michael Tuexen Michael Scharf Mirja Kuehlewind Resources Requested: Special Requests: --------------------------------------------------------- From nobody Fri Jun 23 18:56:30 2017 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 19899126DD9 for ; Fri, 23 Jun 2017 18:56:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P-eYpycwb9E2 for ; Fri, 23 Jun 2017 18:56:27 -0700 (PDT) Received: from mail-in2.apple.com (mail-out2.apple.com [17.151.62.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54698126D74 for ; Fri, 23 Jun 2017 18:56:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1498269387; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=27/ccOGaY0UgBefakM/CZPFDxTvtZ62Vl7PNEqqXFWQ=; b=i3fezoAMEoSl5KSb6N+L0TmSTWize6oGmiSZKXoymTIQZE9DlQ5Pm27qqONlQsq8 PtaLI+IbxSb1ie/VRpS91n9Wu9PBz/aAFv2WebWeFt5tS1MGIqrXGIH9dMKR+v4X DNxteAwSJb3AfDa96zPnwQ6orcl2JT0tVBnjhoZzEfp3v6c1N0Mdgf8l+yzuxw/C L7FaPYUxrK0UMggrfCWcLIMeydVTJF5M1k39y+VABDMX5BcCoGuNA3c1rki+/NQd uvyy3o+aGjWAmxNgFs8Bo7UzV+r6+OIwvwe2guhsiXxHgbS/mJNhNjbauS5N1oqM p+ObPmGIoUmFjUF+hAmtCg==; Received: from relay6.apple.com (relay6.apple.com [17.128.113.90]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail-in2.apple.com (Apple Secure Mail Relay) with SMTP id 8D.96.12614.9C6CD495; Fri, 23 Jun 2017 18:56:27 -0700 (PDT) X-AuditID: 11973e11-c83ff70000003146-f8-594dc6c97883 Received: from koseret (koseret.apple.com [17.151.62.39]) by relay6.apple.com (Apple SCV relay) with SMTP id A4.A2.05199.8C6CD495; Fri, 23 Jun 2017 18:56:25 -0700 (PDT) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_AM3zz0NvlndWKLVdrfe2cQ)" Received: from [17.234.97.171] (unknown [17.234.97.171]) by koseret.apple.com (Oracle Communications Messaging Server 8.0.1.2.20170210 64bit (built Feb 10 2017)) with ESMTPSA id <0OS1006MK41M1P30@koseret.apple.com>; Fri, 23 Jun 2017 18:56:24 -0700 (PDT) Sender: dschinazi@apple.com From: David Schinazi Message-id: Date: Fri, 23 Jun 2017 18:56:09 -0700 In-reply-to: Cc: "tcpm@ietf.org" , "tcpm-chairs@ietf.org" To: "Scharf, Michael (Nokia - DE/Stuttgart)" References: X-Mailer: Apple Mail (2.3273) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrGLMWRmVeSWpSXmKPExsUi2FAYpXv6mG+kwdw1LBY/L2pZ9Cz+y2ax 7eR8JgdmjyVLfjJ53L11iSmAKYrLJiU1J7MstUjfLoEr48iKL0wF3+0remb1Mzcwtlp0MXJy SAiYSMxu3csKYgsJrGaS2DTTBCb+dtpS9i5GLqD4KkaJqS+/s4AkeAUEJX5MvgdmMwuESTTu 74AqamWS2Hd2J9gkYQFpia4Ld4FsDg42AS2JA2uMIHptJF7032GHKImUuHJ0JpjNIqAqcaO9 C8zmFEiWuLzyHBvE/BCJs1eugsVFBNwl7i5+CnVoksTR8xuYIA6Vlbg1+xIzyA0SAgfYJC5d fsI2gVFoFpJbZyG5FcLWkvj+qBUozgFky0scPC8LEdaUeHbvE1SJtsSTdxdYFzCyrWIUyk3M zNHNzDPSSywoyEnVS87P3cQIiojpdoI7GI+vsjrEKMDBqMTDK+DpGynEmlhWXJl7iFGag0VJ nPf1UqCQQHpiSWp2ampBalF8UWlOavEhRiYOTqkGxiqXrTwzHj59J7u33rT1er8198IkiTNf kr8svpN4wHGfh9LRPMGLcV939XKGd0tbzde+e7yndr5ineH6DTfZTxzUlCzIP9wi4NkZYRTG /Kes71XAlG2ZHzyWM3cqCaZwTd51w9X10XtGtvf+Xw3PKinJ330401U+a+bO7mN/59w40ZvU m63GpcRSnJFoqMVcVJwIAOd7nEVpAgAA X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrIIsWRmVeSWpSXmKPExsUiON1OXffkMd9Igwk/eS1+XtSy6Fn8l81i 28n5TA7MHkuW/GTyuHvrElMAUxSXTUpqTmZZapG+XQJXxpEVX5gKvttX9MzqZ25gbLXoYuTk kBAwkXg7bSl7FyMXh5DAKkaJqS+/s4AkeAUEJX5MvgdmMwuESTTu74AqamWS2Hd2JytIQlhA WqLrwl0gm4ODTUBL4sAaI4heG4kX/XfYIUoiJa4cnQlmswioStxo7wKzOQWSJS6vPMcGMT9E 4uyVq2BxEQF3ibuLn4KNFxJIkjh6fgMTxKGyErdmX2KewMg/C8l5s5CcB2FrSXx/1AoU5wCy 5SUOnpeFCGtKPLv3CapEW+LJuwusCxjZVjEKFKXmJFaa6SUWFOSk6iXn525iBIVwQ2HUDsaG 5VaHGAU4GJV4eAU8fSOFWBPLiitzDzFKcDArifAyHwUK8aYkVlalFuXHF5XmpBYfYpzICPTk RGYp0eR8YITllcQbmpgYmBgbmxkbm5uY01JYSZz381qgiwTSE0tSs1NTC1KLYI5i4uCUamCc 7dB0jj1g/e6wiUoH5/D4z5/ToLJDRVlGYJ8MW/V/xlKF+fECIf1eocF8lflql09IyDHcuLf5 4bOg11lSRYFh7XWBz/qfLpqY0OGtv5VvEzujR7tY67yqjVJx3M7yzrMKdC98f/+7WbfwxdZl 4g9Ksn6syPSrdXBjcp7Lu2Y1U7SD31SGViWW4oxEQy3mouJEAMeq897UAgAA Archived-At: Subject: Re: [tcpm] Working group acceptance call draft-bagnulo-tcpm-generalized-ecn-04 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 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, 24 Jun 2017 01:56:29 -0000 --Boundary_(ID_AM3zz0NvlndWKLVdrfe2cQ) Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT Hi, I believe there is value in this work and I think it should be adopted by the working group. Thanks, David Schinazi > On Jun 15, 2017, at 23:06, Scharf, Michael (Nokia - DE/Stuttgart) wrote: > > Hi all, > > As requested by the authors, this e-mail starts a working group acceptance call for draft-bagnulo-tcpm-generalized-ecn-04, which will run on the list until June 30. > > The proposal is to add a new milestone to the TCPM charter > > Submit document on adding Explicit Congestion Notification (ECN) to TCP Control Packets to the IESG for publication as Experimental RFC > > and to use draft-bagnulo-tcpm-generalized-ecn as a starting point. > > If you believe that TCPM should work on a document in this space, and in particular if you are willing to review it, please reply to this e-mails. Please also speak up if you have any concerns or objections. > > Thanks > > Michael > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm --Boundary_(ID_AM3zz0NvlndWKLVdrfe2cQ) Content-type: text/html; CHARSET=US-ASCII Content-transfer-encoding: quoted-printable Hi,

I = believe there is value in this work and I think it should be adopted by = the working group.

Thanks,
David Schinazi


On = Jun 15, 2017, at 23:06, Scharf, Michael (Nokia - DE/Stuttgart) <michael.scharf@nokia.com> wrote:

Hi all,
 
As requested by the authors, this e-mail starts a working = group acceptance call for draft-bagnulo-tcpm-generalized-ecn-04, which = will run on the list until June 30.
 
The proposal is to add a new milestone = to the  TCPM charter
 
  Submit document on adding Explicit Congestion = Notification (ECN) to TCP Control Packets to the IESG for publication as = Experimental RFC
 
and to use draft-bagnulo-tcpm-generalized-ecn as a starting = point.
 
If you believe that TCPM should work on a document in this = space, and in particular if you are willing to review it, please reply = to this e-mails. Please also speak up if you have any concerns or = objections.
 
Thanks
 
Michael
_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm

= --Boundary_(ID_AM3zz0NvlndWKLVdrfe2cQ)-- From nobody Sat Jun 24 02:17:32 2017 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 4CB6C12896F for ; Sat, 24 Jun 2017 02:17:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1im7HtwM8uRY for ; Sat, 24 Jun 2017 02:17:26 -0700 (PDT) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id 96C7B1242F5 for ; Sat, 24 Jun 2017 02:17:26 -0700 (PDT) Received: from [10.239.76.72] (unknown [85.255.236.248]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id E5A9E1B0025E; Sat, 24 Jun 2017 12:11:42 +0100 (BST) Content-Type: multipart/alternative; boundary=Apple-Mail-D03D1F4F-EB82-407D-BED8-6A59EA83F099 Mime-Version: 1.0 (1.0) From: "Gorry (erg)" X-Mailer: iPhone Mail (14F89) In-Reply-To: <4219b826-5034-c280-5f67-b03b98ea0a45@bobbriscoe.net> Date: Sat, 24 Jun 2017 10:17:23 +0100 Cc: Michael Tuexen , Randall Stewart , Xuesong Dong , tcpm IETF list Content-Transfer-Encoding: 7bit Message-Id: <83949A4B-6CFE-4D0D-B13A-4FEC83A37095@erg.abdn.ac.uk> References: <4219b826-5034-c280-5f67-b03b98ea0a45@bobbriscoe.net> To: Bob Briscoe Archived-At: Subject: Re: [tcpm] ECN++ (draft-bagnulo-tcpm-generalized-ecn-04) and SCTP X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 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, 24 Jun 2017 09:17:30 -0000 --Apple-Mail-D03D1F4F-EB82-407D-BED8-6A59EA83F099 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable I do have this on my list to review. I did not expect this draft to mention S= CTP. I will certainly comment, but do not expect to see new protocol work fo= r SCTP being done in TCPM. Gorry=20 > On 23 Jun 2017, at 18:50, Bob Briscoe wrote: >=20 > Michael, Randall, Xuesong, >=20 > Are you considering implementing ECN in SCTP? I noticed that your initial S= CTP/ECN draft prohibits ECN on similar control packets to those prohibited i= n TCP. So I wrote this section about transferability to SCTP into the ECN++ d= raft, which is targeted at TCP but also has a section on variants.=20 > (The adoption call for the draft is below - deadline: 30 Jun). > =20 > I know the details of handshake and other control packets are different, b= ut I think the principles are transferable. > Is this a correct understanding of the position wrt SCTP?=20 >=20 >=20 > Cheers >=20 >=20 > Bob >=20 >=20 > -------- Forwarded Message -------- > Subject: [tcpm] Working group acceptance call draft-bagnulo-tcpm-gen= eralized-ecn-04 > Date: Fri, 16 Jun 2017 06:06:43 +0000 > From: Scharf, Michael (Nokia - DE/Stuttgart) > To: tcpm@ietf.org > CC: tcpm-chairs@ietf.org >=20 > Hi all, > =20 > As requested by the authors, this e-mail starts a working group acceptance= call for draft-bagnulo-tcpm-generalized-ecn-04, which will run on the list u= ntil June 30. > =20 > The proposal is to add a new milestone to the TCPM charter > =20 > Submit document on adding Explicit Congestion Notification (ECN) to TCP C= ontrol Packets to the IESG for publication as Experimental RFC > =20 > and to use draft-bagnulo-tcpm-generalized-ecn as a starting point. > =20 > If you believe that TCPM should work on a document in this space, and in p= articular if you are willing to review it, please reply to this e-mails. Ple= ase also speak up if you have any concerns or objections. > =20 > Thanks > =20 > Michael >=20 > --=20 > ________________________________________________________________ > Bob Briscoe http://bobbriscoe.net/ > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm --Apple-Mail-D03D1F4F-EB82-407D-BED8-6A59EA83F099 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
I do have this on my list to review. I did not expect this draft to mention SCTP. I will certainly comment, but do not expect to see new protocol work for SCTP being done in TCPM.

Gorry 

On 23 Jun 2017, at 18:50, Bob Briscoe <ietf@bobbriscoe.net> wrote:

Michael, Randall, Xuesong,

Are you considering implementing ECN in SCTP? I noticed that your initial SCTP/ECN draft prohibits ECN on similar control packets to those prohibited in TCP. So I wrote this section about transferability to SCTP into the ECN++ draft, which is targeted at TCP but also has a section on variants.
(The adoption call for the draft is below - deadline: 30 Jun).
   
I know the details of handshake and other control packets are different, but I think the principles are transferable.
Is this a correct understanding of the position wrt SCTP?


Cheers


Bob


-------- Forwarded Message --------
Subject: [tcpm] Working group acceptance call draft-bagnulo-tcpm-generalized-ecn-04
Date: Fri, 16 Jun 2017 06:06:43 +0000
From: Scharf, Michael (Nokia - DE/Stuttgart) <michael.scharf@nokia.com>
To: tcpm@ietf.org <tcpm@ietf.org>
CC: tcpm-chairs@ietf.org <tcpm-chairs@ietf.org>


Hi all,

 

As requested by the authors, this e-mail starts a working group acceptance call for draft-bagnulo-tcpm-generalized-ecn-04, which will run on the list until June 30.

 

The proposal is to add a new milestone to the  TCPM charter

 

  Submit document on adding Explicit Congestion Notification (ECN) to TCP Control Packets to the IESG for publication as Experimental RFC

 

and to use draft-bagnulo-tcpm-generalized-ecn as a starting point.

 

If you believe that TCPM should work on a document in this space, and in particular if you are willing to review it, please reply to this e-mails. Please also speak up if you have any concerns or objections.

 

Thanks

 

Michael


-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/
_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm
--Apple-Mail-D03D1F4F-EB82-407D-BED8-6A59EA83F099-- From nobody Sat Jun 24 02:49:41 2017 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 B4883129BF0 for ; Sat, 24 Jun 2017 02:49:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=bobbriscoe.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZdWQN1uzz4BS for ; Sat, 24 Jun 2017 02:49:36 -0700 (PDT) Received: from server.dnsblock1.com (server.dnsblock1.com [85.13.236.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B1D8129BB0 for ; Sat, 24 Jun 2017 02:49:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Type:In-Reply-To:MIME-Version:Date: Message-ID:From:References:Cc:To:Subject:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=gFh/6BnONAckU4qYP2DQDxNDnV8PIZ94ifYopVlHiJo=; b=HzagsSyPv6TH9T+BXJaT3sGww 2LP5gOdjQwCvvRQQOQyND/CU961iFUEnxjs1oPn/oTYGttwZrLpWmPKPTUQN0jUOvzOYn/fbGrsdu 1L91kq3PKkGFL87mafITgZWXAVW7CCRUCK22W8FVn9xwx0hTfELelxYSF7MIK52ej/77VVDE739uV TvWCktSnz6uhM8VbZfgegTNaa8E0HAnXMpib78TPCxNX8nkdC+JJ+S+sFwjpnziU4xRBUnyuPZ+cd s/2Q0OzhWQ5TEEgyS1dVWPq1fsZhaEsL1atuhHVivz0u+Ig2YbuGn2yeGPhG5cJzT7ATaHugUSnuD 8g8oeHMBw==; Received: from [31.185.128.124] (port=33632 helo=[192.168.0.6]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89) (envelope-from ) id 1dOhh3-0004CW-R3; Sat, 24 Jun 2017 10:49:30 +0100 To: "Gorry (erg)" Cc: Michael Tuexen , Randall Stewart , tcpm IETF list References: <4219b826-5034-c280-5f67-b03b98ea0a45@bobbriscoe.net> <83949A4B-6CFE-4D0D-B13A-4FEC83A37095@erg.abdn.ac.uk> From: Bob Briscoe Message-ID: <4a8544e3-3e9f-3eae-c499-3b024676321d@bobbriscoe.net> Date: Sat, 24 Jun 2017 10:49:28 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <83949A4B-6CFE-4D0D-B13A-4FEC83A37095@erg.abdn.ac.uk> Content-Type: multipart/alternative; boundary="------------68ABCC936C1D7CFCCB674ABD" Content-Language: en-GB X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.dnsblock1.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - bobbriscoe.net X-Get-Message-Sender-Via: server.dnsblock1.com: authenticated_id: in@bobbriscoe.net X-Authenticated-Sender: server.dnsblock1.com: in@bobbriscoe.net Archived-At: Subject: Re: [tcpm] ECN++ (draft-bagnulo-tcpm-generalized-ecn-04) and SCTP X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 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, 24 Jun 2017 09:49:40 -0000 This is a multi-part message in MIME format. --------------68ABCC936C1D7CFCCB674ABD Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Gorry, Thx for promising to review. The draft does not affect SCTP. We have included a section at the end on the (non-)interaction of Generalized ECN with TCP variants (SCTP, TFO, IW10, SYN cookies, L4S). https://tools.ietf.org/html/draft-bagnulo-tcpm-generalized-ecn-04#section-5 We note that, currently, the only draft on adding ECN to SCTP mimics RFC3168 by prohibiting ECN support on all control packets. We then merely note that: "When ECN is finally added to SCTP, experience from experiments on adding ECN support to all TCP packets ought to be directly transferable to SCTP." I know TFO, IW10, etc in depth. However, I was just checking with the authors whether this statement hides complexity in SCTP that I'm not aware of (cos I don't know SCTP in depth). Bob On 24/06/17 10:17, Gorry (erg) wrote: > I do have this on my list to review. I did not expect this draft to > mention SCTP. I will certainly comment, but do not expect to see new > protocol work for SCTP being done in TCPM. > > Gorry > > On 23 Jun 2017, at 18:50, Bob Briscoe > wrote: > >> Michael, Randall, Xuesong, >> >> Are you considering implementing ECN in SCTP? I noticed that your >> initial SCTP/ECN draft prohibits ECN on similar control packets to >> those prohibited in TCP. So I wrote this section about >> transferability to SCTP >> >> into the ECN++ draft, which is targeted at TCP but also has a section >> on variants. >> (The adoption call for the draft is below - deadline: 30 Jun). >> >> I know the details of handshake and other control packets are >> different, but I think the principles are transferable. >> Is this a correct understanding of the position wrt SCTP? >> >> >> Cheers >> Gorry >> >> Bob >> >> >> -------- Forwarded Message -------- >> Subject: [tcpm] Working group acceptance call >> draft-bagnulo-tcpm-generalized-ecn-04 >> Date: Fri, 16 Jun 2017 06:06:43 +0000 >> From: Scharf, Michael (Nokia - DE/Stuttgart) >> To: tcpm@ietf.org >> CC: tcpm-chairs@ietf.org >> >> >> >> Hi all, >> >> As requested by the authors, this e-mail starts a working group >> acceptance call for draft-bagnulo-tcpm-generalized-ecn-04, which will >> run on the list until June 30. >> >> The proposal is to add a new milestone to the TCPM charter >> >> Submit document on adding Explicit Congestion Notification (ECN) to >> TCP Control Packets to the IESG for publication as Experimental RFC >> >> and to use draft-bagnulo-tcpm-generalized-ecn as a starting point. >> >> If you believe that TCPM should work on a document in this space, and >> in particular if you are willing to review it, please reply to this >> e-mails. Please also speak up if you have any concerns or objections. >> >> Thanks >> >> Michael >> >> >> -- >> ________________________________________________________________ >> Bob Briscoehttp://bobbriscoe.net/ >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ --------------68ABCC936C1D7CFCCB674ABD Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Gorry,

Thx for promising to review.

The draft does not affect SCTP. We have included a section at the end on the (non-)interaction of Generalized ECN with TCP variants (SCTP, TFO, IW10, SYN cookies, L4S).
https://tools.ietf.org/html/draft-bagnulo-tcpm-generalized-ecn-04#section-5

We note that, currently, the only draft on adding ECN to SCTP mimics RFC3168 by prohibiting ECN support on all control packets. We then merely note that:
   "When ECN is finally added to SCTP, experience
   from experiments on adding ECN support to all TCP packets ought to be
   directly transferable to SCTP."

I know TFO, IW10, etc in depth. However, I was just checking with the authors whether this statement hides complexity in SCTP that I'm not aware of (cos I don't know SCTP in depth).


Bob

On 24/06/17 10:17, Gorry (erg) wrote:
I do have this on my list to review. I did not expect this draft to mention SCTP. I will certainly comment, but do not expect to see new protocol work for SCTP being done in TCPM.

Gorry 

On 23 Jun 2017, at 18:50, Bob Briscoe <ietf@bobbriscoe.net> wrote:

Michael, Randall, Xuesong,

Are you considering implementing ECN in SCTP? I noticed that your initial SCTP/ECN draft prohibits ECN on similar control packets to those prohibited in TCP. So I wrote this section about transferability to SCTP into the ECN++ draft, which is targeted at TCP but also has a section on variants.
(The adoption call for the draft is below - deadline: 30 Jun).
   
I know the details of handshake and other control packets are different, but I think the principles are transferable.
Is this a correct understanding of the position wrt SCTP?


Cheers
Gorry

Bob


-------- Forwarded Message --------
Subject: [tcpm] Working group acceptance call draft-bagnulo-tcpm-generalized-ecn-04
Date: Fri, 16 Jun 2017 06:06:43 +0000
From: Scharf, Michael (Nokia - DE/Stuttgart) <michael.scharf@nokia.com>
To: tcpm@ietf.org <tcpm@ietf.org>
CC: tcpm-chairs@ietf.org <tcpm-chairs@ietf.org>


Hi all,

 

As requested by the authors, this e-mail starts a working group acceptance call for draft-bagnulo-tcpm-generalized-ecn-04, which will run on the list until June 30.

 

The proposal is to add a new milestone to the  TCPM charter

 

  Submit document on adding Explicit Congestion Notification (ECN) to TCP Control Packets to the IESG for publication as Experimental RFC

 

and to use draft-bagnulo-tcpm-generalized-ecn as a starting point.

 

If you believe that TCPM should work on a document in this space, and in particular if you are willing to review it, please reply to this e-mails. Please also speak up if you have any concerns or objections.

 

Thanks

 

Michael


-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/
_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/
--------------68ABCC936C1D7CFCCB674ABD-- From nobody Sat Jun 24 13:02:19 2017 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 742CC129439; Sat, 24 Jun 2017 13:02:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZieeqaHWnvF9; Sat, 24 Jun 2017 13:02:15 -0700 (PDT) Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40115.outbound.protection.outlook.com [40.107.4.115]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9EDD3128961; Sat, 24 Jun 2017 13:02:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=qyWjGLahAWgldLMq/3pVbT8Ako1DZ7vA3S4rsTxryMA=; b=nvX6Xn06EJZ/l8xp+bQPD1/MpBSfZUf0AK3oi3hpFphKAmbih1l+0OGFZ4iiN6W1Q4E5UiG/DFxpGWPstZAsCuI1QJtPEapTdMTHabX+2fnYohqNoLDNeQU5QS/GDL/D3GvTPeGtFCApRjl1nmGWgsCURE4K8oMjMqQCTh6XzHg= Received: from AM5PR0701MB2547.eurprd07.prod.outlook.com (10.173.92.15) by AM5PR0701MB2338.eurprd07.prod.outlook.com (10.169.152.136) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1220.5; Sat, 24 Jun 2017 20:02:12 +0000 Received: from AM5PR0701MB2547.eurprd07.prod.outlook.com ([fe80::a0a5:bdaf:13ae:89c4]) by AM5PR0701MB2547.eurprd07.prod.outlook.com ([fe80::a0a5:bdaf:13ae:89c4%17]) with mapi id 15.01.1220.009; Sat, 24 Jun 2017 20:02:12 +0000 From: "Scharf, Michael (Nokia - DE/Stuttgart)" To: "tcpm@ietf.org" CC: "tcpm-chairs@ietf.org" Thread-Topic: [tcpm] Working group acceptance call draft-bagnulo-tcpm-generalized-ecn-04 Thread-Index: AdLmZeQ+oR9BQwLNQFmQZTzsHuSPOgGJyguAACXJqkA= Date: Sat, 24 Jun 2017 20:02:12 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=nokia.com; x-originating-ip: [135.245.212.1] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM5PR0701MB2338; 7:2Mt0PAlZMnMs//1/gyLFYgVI6SXmRHRbEUuBlhi3EEiO2Y0U8V+8uhAg4Z/W4LkBiZ+dkIgOMJbDe+JlyBZY4LWlgKCx8moNuPlQg9dazsv4q4ekkTWXwKTnJCpgYukZfhVhMZBF4s1XKvQc/Kx5CwfNzGhtRpPUfxMpkLKqtK4+/Y6dV0PQ6TKPGezpsHYMct1GGBLM01q/xYUqZmryyHO7cmanPKGbxIpF3Bpz2KUYp1dUOgIsxrhVp5YiF28tzRCOHu84iYlQnn3B5XY/GcUxOST0FT5FxOqBe+2PkdQz6YzkAIZk/kAlhjKJGFauR3Ue/pKSkqGVDWgM7KVGbbN3XuhlPoful3CN0lr2r2vtItWrWClt5fFUvAt+KQn4Kfm3rExUPNu5J0cS9PDjkzJb4yjF5Pm/imHwHW0Frsq1iPI40jNZwpBmJLiQUZk43TxrhktlG0HNukmX2p1/LlNvFqd5Ke7WLRroKV5nCiKLRUn8vg2vLoKY4F+mqF4NXEe4Jp3CPgWAqNWmncDupUV5TSx5edTtfxZ0Y7ezDzIPfDLJi29wgx1b9TT5AJ4mVBhs5B/M2QQantolWFR/REYPJeWlO1Bpd0xHRYGIlfbI+163biY2/KlIRl+hvQ7oHn8t/4IxrKKrtI5qYgEu7yGLIc7grGWa6e0wRHsoTfkCjatl9XpYdickB9yXBZEv32tcJzP0iSETsmh61EgC2qwdMqKwraekYHrtmP/X/my7a8N3AD5JT7BBP/ALbNsl5z5euwZ/8nmPP5VoGg5I4cRz1AlvvfsEZv5Kg3VxR88= x-ms-office365-filtering-correlation-id: 900450d6-d047-4c5f-d903-08d4bb3be728 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(48565401081)(300000503095)(300135400095)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095); SRVR:AM5PR0701MB2338; x-ms-traffictypediagnostic: AM5PR0701MB2338: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(151999592597050)(278178393323532)(26388249023172)(236129657087228)(82608151540597)(148574349560750)(21748063052155)(31960201722614); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(5005006)(8121501046)(93006095)(93001095)(10201501046)(3002001)(100000703101)(100105400095)(6055026)(6041248)(20161123564025)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123555025)(20161123558100)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM5PR0701MB2338; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM5PR0701MB2338; x-forefront-prvs: 03484C0ABF x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39840400002)(39450400003)(39860400002)(39850400002)(39400400002)(39410400002)(24454002)(53754006)(230783001)(2501003)(790700001)(3846002)(6116002)(102836003)(2900100001)(25786009)(2351001)(86362001)(966005)(54356999)(5250100002)(14454004)(478600001)(561944003)(76176999)(66066001)(50986999)(6246003)(2906002)(3660700001)(3280700002)(38730400002)(110136004)(19609705001)(189998001)(53546010)(54896002)(6306002)(6506006)(5630700001)(53936002)(236005)(9686003)(2950100002)(606005)(6436002)(99286003)(55016002)(229853002)(6916009)(5640700003)(74316002)(7736002)(7906003)(81166006)(1730700003)(450100002)(5660300001)(7696004)(33656002)(8936002)(4326008)(8676002); DIR:OUT; SFP:1102; SCL:1; SRVR:AM5PR0701MB2338; H:AM5PR0701MB2547.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_AM5PR0701MB2547E531C8C97ACBFD1B753193D90AM5PR0701MB2547_" MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Jun 2017 20:02:12.0667 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0701MB2338 Archived-At: Subject: Re: [tcpm] Working group acceptance call draft-bagnulo-tcpm-generalized-ecn-04 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 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, 24 Jun 2017 20:02:17 -0000 --_000_AM5PR0701MB2547E531C8C97ACBFD1B753193D90AM5PR0701MB2547_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable As a reminder, we have two ongoing working group adoption calls. Further fe= edback would be highly welcome. Michael From: dschinazi@apple.com [mailto:dschinazi@apple.com] Sent: Samstag, 24. Juni 2017 03:56 To: Scharf, Michael (Nokia - DE/Stuttgart) Cc: tcpm@ietf.org; tcpm-chairs@ietf.org Subject: Re: [tcpm] Working group acceptance call draft-bagnulo-tcpm-genera= lized-ecn-04 Hi, I believe there is value in this work and I think it should be adopted by t= he working group. Thanks, David Schinazi On Jun 15, 2017, at 23:06, Scharf, Michael (Nokia - DE/Stuttgart) > wrote: Hi all, As requested by the authors, this e-mail starts a working group acceptance = call for draft-bagnulo-tcpm-generalized-ecn-04, which will run on the list = until June 30. The proposal is to add a new milestone to the TCPM charter Submit document on adding Explicit Congestion Notification (ECN) to TCP C= ontrol Packets to the IESG for publication as Experimental RFC and to use draft-bagnulo-tcpm-generalized-ecn as a starting point. If you believe that TCPM should work on a document in this space, and in pa= rticular if you are willing to review it, please reply to this e-mails. Ple= ase also speak up if you have any concerns or objections. Thanks Michael _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm --_000_AM5PR0701MB2547E531C8C97ACBFD1B753193D90AM5PR0701MB2547_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

As a reminder, we have two ongoing working group ad= option calls. Further feedback would be highly welcome.

 

Michael

 

 

 

From: dschinazi@apple.com [mailto:ds= chinazi@apple.com]
Sent: Samstag, 24. Juni 2017 03:56
To: Scharf, Michael (Nokia - DE/Stuttgart) <michael.scharf@nokia.= com>
Cc: tcpm@ietf.org; tcpm-chairs@ietf.org
Subject: Re: [tcpm] Working group acceptance call draft-bagnulo-tcpm= -generalized-ecn-04

 

Hi,

 

I believe there is value in this work and I think it= should be adopted by the working group.

 

Thanks,

David Schinazi

 

 

On Jun 15, 2017, at 23:06, Scharf, Michael (Nokia - = DE/Stuttgart) <michael.schar= f@nokia.com> wrote:

 

Hi all,

 

As requested by the authors, this e-mail starts a w= orking group acceptance call for draft-bagnulo-tcpm-generalized-ecn-04, whi= ch will run on the list until June 30.

 

The proposal is to add a new milestone to the = TCPM charter

 

  Submit document on adding Explicit Congestio= n Notification (ECN) to TCP Control Packets to the IESG for publication as = Experimental RFC

 

and to use draft-bagnulo-tcpm-generalized-ecn as a = starting point.

 

If you believe that TCPM should work on a document = in this space, and in particular if you are willing to review it, please re= ply to this e-mails. Please also speak up if you have any concerns or objections.

 

Thanks

 

Michael

_______________________________________________ tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm

 

--_000_AM5PR0701MB2547E531C8C97ACBFD1B753193D90AM5PR0701MB2547_-- From nobody Sun Jun 25 11:03:26 2017 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 E4FC612441E; Sun, 25 Jun 2017 11:03:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IfAFqph_1AJE; Sun, 25 Jun 2017 11:03:22 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43D091201F2; Sun, 25 Jun 2017 11:03:22 -0700 (PDT) X-AuditID: c1b4fb3a-81bff70000001b2f-16-594ffae80438 Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.183.24]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 8C.38.06959.8EAFF495; Sun, 25 Jun 2017 20:03:20 +0200 (CEST) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.24) with Microsoft SMTP Server (TLS) id 14.3.352.0; Sun, 25 Jun 2017 20:03:19 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=v5BQ2c91tO73epsohBQ2RRVis6xxXI8u6Neq3v7M/aQ=; b=AnHEGkhu35/HX1W8BVVzA6N+zptlD8OCHzl818K/TQ1+vxGkTMPGdZw6INu7oTruO71G8jcsDYmTK0R0ebq6W8cyQBr1gOObyAIewXHl6NejV54IkpdGmd+kgtYQEsfTHQIPOhpbaxtP0V3/vUcSH9F6SLvqWJER7+ulYFaVApo= Received: from DB4PR07MB348.eurprd07.prod.outlook.com (10.141.234.148) by DB4PR07MB249.eurprd07.prod.outlook.com (10.242.231.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1220.5; Sun, 25 Jun 2017 18:03:18 +0000 Received: from DB4PR07MB348.eurprd07.prod.outlook.com ([fe80::9c18:1ce7:ff80:8f56]) by DB4PR07MB348.eurprd07.prod.outlook.com ([fe80::9c18:1ce7:ff80:8f56%13]) with mapi id 15.01.1199.017; Sun, 25 Jun 2017 18:03:18 +0000 From: Ingemar Johansson S To: "tcpm@ietf.org" CC: "tcpm-chairs@ietf.org" , "Bob Briscoe (ietf@bobbriscoe.net)" , marcelo bagnulo braun Thread-Topic: Working group acceptance call draft-bagnulo-tcpm-generalized-ecn-04 Thread-Index: AdLt3HWa9cAL1IW3RDi4MVCsUHppsQ== Date: Sun, 25 Jun 2017 18:03:18 +0000 Message-ID: Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [213.113.27.92] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DB4PR07MB249; 7:nbcVXEqClrkXZ5mAxLhzm3kxRFCxglOfmPaKWuJv/UKbm8CIVRHvlfReFnavstTV4uwSfui6snkUW5dl4p1HkCB9Qr6E8bzGtJZpSamWVr+c2yyU+sZCmeRoqlfwX3PmfunVxomP1dsrKZD9YKaeoXCjA54CGLsFaYCxgtY3Tn6DNCupBhtDbNjiJew1DwGQVVzp+cc7E9zkQthrmYGXHFDAvrEmqByM6PBkTaAiTL47/PYnR6xotzwo32ZG03x+P9nkmLu24x2RO/8hAsLVwRqSGNYrzGGrRwRsjSCxQPjZWym6yk3+1RJf3/XFqxQytcMBEyfhLHmj7Ix2ihOC/JC6htq54Xi0DV7jSWT7ZHZ/zT1kf7MBhR9+eEhUyBNVvDKAWPr54WeK7ZXkB1ZhgdS6V4xHxMHy71695EBlQpC4xTOJtfvMe1kq29+EYjWZPNLP7JEn8uTPLqWUd/b7C57HhNi69W+GEscvh1XiErxXxuvJgupd1IJCufE5yTIL5LJKvXLSxEUwtDHrWhYlq5YJE1C7uhYL4lBRvoP5CLmfy6HxjzSVAKoJaePayveBJV/R+rYF9dWa8kvlDI0u8evW4CTJM6AAdJtFf71pb5gf1tc58OXfEHgshPE2A1X8bOj0zD8usUtYbQU014LW0omauoQxy+zWM8sOzXfij45w2NxnW2NC3IQsCTP/P0giWp8YSITYfZ2xbMYGOKBApU9jGb93TKyXmNIw4c4+RCzxP26HKY2oguPqaxbS+ysioBtX7NupuhYSw53L8RM+lYSViyxHpeMnQRUJ7PqvePw= x-ms-office365-filtering-correlation-id: 020385f6-5fe8-45e0-bc6c-08d4bbf4759d x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(300000503095)(300135400095)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506067)(300135500095); SRVR:DB4PR07MB249; x-ms-traffictypediagnostic: DB4PR07MB249: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(278178393323532)(133145235818549)(236129657087228)(189930954265078)(82608151540597)(148574349560750)(49204369933175); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(100000703101)(100105400095)(93006095)(93001095)(6041248)(20161123555025)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123560025)(20161123558100)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DB4PR07MB249; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DB4PR07MB249; x-forefront-prvs: 034902F5BC x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39850400002)(39450400003)(39860400002)(39840400002)(39400400002)(39410400002)(53754006)(3660700001)(102836003)(966005)(3846002)(3280700002)(478600001)(7696004)(8936002)(5660300001)(14454004)(305945005)(6916009)(230783001)(1730700003)(33656002)(81166006)(6116002)(5250100002)(2906002)(189998001)(5890100001)(8676002)(50986999)(6306002)(38730400002)(7736002)(54356999)(99286003)(9686003)(55016002)(110136004)(45080400002)(6436002)(6506006)(2351001)(512954002)(66066001)(5640700003)(86362001)(2900100001)(561944003)(25786009)(74316002)(53936002)(4326008); DIR:OUT; SFP:1101; SCL:1; SRVR:DB4PR07MB249; H:DB4PR07MB348.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Jun 2017 18:03:18.3796 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB4PR07MB249 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02SfyzUYRzH93x/3dfp6kl+fHax1jV/SCRkZir+syI2WvijXHzz+87ui8ja qLD8aNYqI7krJFL5UfmRjJsW1RbWHIZzSyFbQ5OoLOfR1n+vz/N+7Xn2ee/haatSVs7Hq1IF jUqZpOCkTFl4K7jMrgVHuLUN7vB+bdKx3rmf6znvoqo/nPeLfi3lxwR8NQ6wAdXVq1TAD0MT G0JHSn1jhKT4dEFz8GiUNG6le4pOacAZl2fz6Gz0TlaALHjAntCXW0YXIClvhXsR5E8scmTo Q7CuuyUxDwwupqFusJEiyW0Kpt9ObWkmBK3fcljzZRz2hTr9CjKzNd4Hj4wLyCzRuALBzPLE ZrALh0JRxaiESKHwZXl5i12hc2aRMTODHWF0dY0zswxHQk9+P2VmhB3AuDK56dDYDsamtRTZ AkN15weasA3MfVpnzQ8jXIhgoXJ4Q+I3gr3Qe/MCcRxgSFuICBs5WCzaQzgIlmqMm20AHqLg zryBI4ETDHbVMoTjocYwyRFJi6Cg3SghQTcLb4whhO1h3NSMiDTMQl+OQULWl8PEx2tbVdjD 7PgrtgQ5lf+3EeEDoHu5xBF2hgf35unyzTZ2Qn/ZNKNDTD2yEQVRTI51d3cVNPHRoqhWuaqE 1Ga08V16nv3yaUM9M/56hHmk2CZrXg2OsGKV6WJmsh4BTyusZfkzG0eyGGXmRUGjPqtJSxJE PdrNMwo7mV/XQLgVjlWmComCkCJo/qUUbyHPRnYeXqaS3jR1VEIC1dQeduMSFzj1WN12rsGl IszNVve++MjIw8pGeZUjVfZU7VJ13SO6dnHEb87Z4Dn2U3d+uqijQ+pfGu6V9+R3VkT/5Jjk pG19suPVlqiMmvbyAMuWLP397XJLrcWZY999Agf4w5LQU8eDEk9fcVa11Zx4Xn23QsGIccpD +2mNqPwLK+Vg5CoDAAA= Archived-At: Subject: Re: [tcpm] Working group acceptance call draft-bagnulo-tcpm-generalized-ecn-04 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 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, 25 Jun 2017 18:03:25 -0000 Hi I support this work. In addition, parts of the findings and recommendations in this TCP generali= zed ECN work may also be useful for the specification of the ECN support in= QUIC, currently outlined in (https://tools.ietf.org/id/draft-johansson-qui= c-ecn-03.txt ). Regards Ingemar Johansson >=20 > Message: 1 > Date: Fri, 16 Jun 2017 06:06:43 +0000 > From: "Scharf, Michael (Nokia - DE/Stuttgart)" > > To: "tcpm@ietf.org" > Cc: "tcpm-chairs@ietf.org" > Subject: [tcpm] Working group acceptance call > draft-bagnulo-tcpm-generalized-ecn-04 > Message-ID: > 2547.eurprd07.prod.outlook.com> >=20 > Content-Type: text/plain; charset=3D"us-ascii" >=20 > Hi all, >=20 > As requested by the authors, this e-mail starts a working group acceptanc= e > call for draft-bagnulo-tcpm-generalized-ecn-04, which will run on the lis= t until > June 30. >=20 > The proposal is to add a new milestone to the TCPM charter >=20 > Submit document on adding Explicit Congestion Notification (ECN) to TCP > Control Packets to the IESG for publication as Experimental RFC >=20 > and to use draft-bagnulo-tcpm-generalized-ecn as a starting point. >=20 > If you believe that TCPM should work on a document in this space, and in > particular if you are willing to review it, please reply to this e-mails.= Please > also speak up if you have any concerns or objections. >=20 > Thanks >=20 > Michael > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > f93e9/attachment.html> >=20 > ------------------------------ >=20 > Subject: Digest Footer >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm >=20 >=20 > ------------------------------ >=20 > End of tcpm Digest, Vol 158, Issue 7 > ************************************ From nobody Sun Jun 25 11:22:05 2017 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 AD1B4126B71; Sun, 25 Jun 2017 11:22:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PLA3HjfXTFZc; Sun, 25 Jun 2017 11:22:00 -0700 (PDT) Received: from mail-out01.uio.no (mail-out01.uio.no [IPv6:2001:700:100:10::50]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4131E127201; Sun, 25 Jun 2017 11:22:00 -0700 (PDT) Received: from mail-mx05.uio.no ([129.240.10.49]) by mail-out01.uio.no with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1dPCAY-0002Oj-L4; Sun, 25 Jun 2017 20:21:58 +0200 Received: from 234.133.189.109.customer.cdi.no ([109.189.133.234] helo=[192.168.1.8]) by mail-mx05.uio.no with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) user michawe (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1dPCAY-00087D-25; Sun, 25 Jun 2017 20:21:58 +0200 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Michael Welzl In-Reply-To: Date: Sun, 25 Jun 2017 20:22:04 +0200 Cc: "tcpm@ietf.org" , "tcpm-chairs@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <9E4E55C4-0E8D-4127-90B5-6715AF716226@ifi.uio.no> References: To: Ingemar Johansson S X-Mailer: Apple Mail (2.3273) X-UiO-SPF-Received: Received-SPF: neutral (mail-mx05.uio.no: 109.189.133.234 is neither permitted nor denied by domain of ifi.uio.no) client-ip=109.189.133.234; envelope-from=michawe@ifi.uio.no; helo=[192.168.1.8]; X-UiO-Ratelimit-Test: rcpts/h 3 msgs/h 1 sum rcpts/h 4 sum msgs/h 1 total rcpts 55922 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-4.9, required=5.0, autolearn=disabled, AWL=0.091, TVD_RCVD_IP=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 2723E27A641E7BABEA183BF1884EE05FE61CDA5F X-UiO-SPAM-Test: remote_host: 109.189.133.234 spam_score: -48 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 1619 max/h 13 blacklist 0 greylist 0 ratelimit 0 Archived-At: Subject: Re: [tcpm] Working group acceptance call draft-bagnulo-tcpm-generalized-ecn-04 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 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, 25 Jun 2017 18:22:04 -0000 +1, I support this too and I agree with what Ingemar says about QUIC Cheers, Michael > On Jun 25, 2017, at 8:03 PM, Ingemar Johansson S = wrote: >=20 > Hi >=20 > I support this work. > In addition, parts of the findings and recommendations in this TCP = generalized ECN work may also be useful for the specification of the ECN = support in QUIC, currently outlined in = (https://tools.ietf.org/id/draft-johansson-quic-ecn-03.txt ). >=20 > Regards > Ingemar Johansson >=20 >>=20 >> Message: 1 >> Date: Fri, 16 Jun 2017 06:06:43 +0000 >> From: "Scharf, Michael (Nokia - DE/Stuttgart)" >> >> To: "tcpm@ietf.org" >> Cc: "tcpm-chairs@ietf.org" >> Subject: [tcpm] Working group acceptance call >> draft-bagnulo-tcpm-generalized-ecn-04 >> Message-ID: >> > 2547.eurprd07.prod.outlook.com> >>=20 >> Content-Type: text/plain; charset=3D"us-ascii" >>=20 >> Hi all, >>=20 >> As requested by the authors, this e-mail starts a working group = acceptance >> call for draft-bagnulo-tcpm-generalized-ecn-04, which will run on the = list until >> June 30. >>=20 >> The proposal is to add a new milestone to the TCPM charter >>=20 >> Submit document on adding Explicit Congestion Notification (ECN) to = TCP >> Control Packets to the IESG for publication as Experimental RFC >>=20 >> and to use draft-bagnulo-tcpm-generalized-ecn as a starting point. >>=20 >> If you believe that TCPM should work on a document in this space, and = in >> particular if you are willing to review it, please reply to this = e-mails. Please >> also speak up if you have any concerns or objections. >>=20 >> Thanks >>=20 >> Michael >> -------------- next part -------------- >> An HTML attachment was scrubbed... >> URL: >> = > f93e9/attachment.html> >>=20 >> ------------------------------ >>=20 >> Subject: Digest Footer >>=20 >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm >>=20 >>=20 >> ------------------------------ >>=20 >> End of tcpm Digest, Vol 158, Issue 7 >> ************************************ >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Sun Jun 25 15:18:10 2017 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 12FED126CF9; Sun, 25 Jun 2017 15:18:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=bobbriscoe.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k8qatl7qTOF3; Sun, 25 Jun 2017 15:18:05 -0700 (PDT) Received: from server.dnsblock1.com (server.dnsblock1.com [85.13.236.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B0AF1205F0; Sun, 25 Jun 2017 15:17:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender :Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=THaZT3vsKuOvWve+JfAejSmsNHUg8EHSEFHOGFXm+nI=; b=S6dt+tH7uJ8vq0ODCzCT+jBT42 5o5H3iwP+6MG5vSPcXixVvD4z3gQ7r9xzrXOqh/9aDJdzUVquBUMD0fbvMAiCZH2tLVSTqtGNDWSV LaOxBIOH+D0RKxTMxOsJF0sw1YllN7V6qH+m0yRdW3hWfCu7eEfn+5Mo2qr2tW3maHsdyWonc3Ozf 1CR/hfY7dXaRInmcatPXI/oNwfLTCIPI945zNbdo5t0HjzHOoJR4mRQAx3bU/ZHI7Py7D+zEUvo1v At7OtYcRjdp4JD5U5Q7LnQA4PXw527u0QrgXzBkEU1Y014rAKsPoGKU6j2NXmTf92eThqDZh/IDi5 WKmm2GKg==; Received: from [31.185.128.124] (port=45692 helo=[192.168.0.6]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89) (envelope-from ) id 1dPFqh-0003ml-HR; Sun, 25 Jun 2017 23:17:43 +0100 To: Ingemar Johansson S , "tcpm@ietf.org" Cc: "tcpm-chairs@ietf.org" , marcelo bagnulo braun References: From: Bob Briscoe Message-ID: Date: Sun, 25 Jun 2017 23:17:42 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-GB X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.dnsblock1.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - bobbriscoe.net X-Get-Message-Sender-Via: server.dnsblock1.com: authenticated_id: in@bobbriscoe.net X-Authenticated-Sender: server.dnsblock1.com: in@bobbriscoe.net Archived-At: Subject: Re: [tcpm] Working group acceptance call draft-bagnulo-tcpm-generalized-ecn-04 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 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, 25 Jun 2017 22:18:08 -0000 Ingemar, The draft already says this work shoul be transferable to SCTP. I might also add a note that it could also benefit QUIC, altho I'd like to see some detail before presuming this will work. Coincidentally, I just read your ECN in QUIC draft yesterday. And, also coincidentally, one of my main comments was going to be that it seems disappointing that it only "sends an ECN negotiation frame when connection setup is completed." Retransmission timeouts have to be conservative during connection set-up whatever the protocol. So the background level of congestion loss will then lead to unnecessarily protracted intermittent delays, which will particularly hit short QUIC flows. So I was going to suggest that you might be able to protect QUIC connection setup from random congestion loss by an approach similar to ECN++. I cannot guarantee that I will have time to write up the other comments from my review in time for you to use it before the IETF deadline (I am about to take a week off, returning on 3 Jul). But I will try to do a quick summary for the QUIC list now. Bob On 25/06/17 19:03, Ingemar Johansson S wrote: > Hi > > I support this work. > In addition, parts of the findings and recommendations in this TCP generalized ECN work may also be useful for the specification of the ECN support in QUIC, currently outlined in (https://tools.ietf.org/id/draft-johansson-quic-ecn-03.txt ). > > Regards > Ingemar Johansson > >> Message: 1 >> Date: Fri, 16 Jun 2017 06:06:43 +0000 >> From: "Scharf, Michael (Nokia - DE/Stuttgart)" >> >> To: "tcpm@ietf.org" >> Cc: "tcpm-chairs@ietf.org" >> Subject: [tcpm] Working group acceptance call >> draft-bagnulo-tcpm-generalized-ecn-04 >> Message-ID: >> > 2547.eurprd07.prod.outlook.com> >> >> Content-Type: text/plain; charset="us-ascii" >> >> Hi all, >> >> As requested by the authors, this e-mail starts a working group acceptance >> call for draft-bagnulo-tcpm-generalized-ecn-04, which will run on the list until >> June 30. >> >> The proposal is to add a new milestone to the TCPM charter >> >> Submit document on adding Explicit Congestion Notification (ECN) to TCP >> Control Packets to the IESG for publication as Experimental RFC >> >> and to use draft-bagnulo-tcpm-generalized-ecn as a starting point. >> >> If you believe that TCPM should work on a document in this space, and in >> particular if you are willing to review it, please reply to this e-mails. Please >> also speak up if you have any concerns or objections. >> >> Thanks >> >> Michael >> -------------- next part -------------- >> An HTML attachment was scrubbed... >> URL: >> > f93e9/attachment.html> >> >> ------------------------------ >> >> Subject: Digest Footer >> >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm >> >> >> ------------------------------ >> >> End of tcpm Digest, Vol 158, Issue 7 >> ************************************ -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ From nobody Mon Jun 26 12:55:30 2017 Return-Path: X-Original-To: tcpm@ietf.org Delivered-To: tcpm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B13D812EB5B; Mon, 26 Jun 2017 12:55:28 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: tcpm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.55.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149850692868.18460.1112273198342569110@ietfa.amsl.com> Date: Mon, 26 Jun 2017 12:55:28 -0700 Archived-At: Subject: [tcpm] I-D Action: draft-ietf-tcpm-tcp-edo-08.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jun 2017 19:55:29 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the TCP Maintenance and Minor Extensions of the IETF. Title : TCP Extended Data Offset Option Authors : Joe Touch Wesley M. Eddy Filename : draft-ietf-tcpm-tcp-edo-08.txt Pages : 23 Date : 2017-06-26 Abstract: TCP segments include a Data Offset field to indicate space for TCP options but the size of the field can limit the space available for complex options such as SACK and Multipath TCP and can limit the combination of such options supported in a single connection. This document updates RFC 793 with an optional TCP extension to that space to support the use of multiple large options. It also explains why the initial SYN of a connection cannot be extending a single segment. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tcpm-tcp-edo/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tcpm-tcp-edo-08 https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-tcp-edo-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-tcp-edo-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jun 26 13:03:33 2017 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 730D912EB5B for ; Mon, 26 Jun 2017 13:03:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4S-Lr4zN-JgX for ; Mon, 26 Jun 2017 13:03:30 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 68BAD12EB2E for ; Mon, 26 Jun 2017 13:03:30 -0700 (PDT) Received: from [128.9.160.211] (mul.isi.edu [128.9.160.211]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id v5QK3CHQ016754 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 26 Jun 2017 13:03:12 -0700 (PDT) References: <149850693393.18448.2828663054201245566.idtracker@ietfa.amsl.com> To: "tcpm@ietf.org" From: Joe Touch X-Forwarded-Message-Id: <149850693393.18448.2828663054201245566.idtracker@ietfa.amsl.com> Message-ID: <4053e775-7265-0cb7-fa74-7463c1f1e225@isi.edu> Date: Mon, 26 Jun 2017 13:03:12 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <149850693393.18448.2828663054201245566.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------2A951B87AF4EEC181C4FE80E" Content-Language: en-US X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: [tcpm] Fwd: New Version Notification for draft-touch-tcpm-tcp-syn-ext-opt-07.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jun 2017 20:03:32 -0000 This is a multi-part message in MIME format. --------------2A951B87AF4EEC181C4FE80E Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit FYI - issued to update a pending expiration. Joe -------- Forwarded Message -------- Subject: New Version Notification for draft-touch-tcpm-tcp-syn-ext-opt-07.txt Date: Mon, 26 Jun 2017 12:55:33 -0700 From: internet-drafts@ietf.org To: Joseph Touch , Joe Touch , Ted Faber A new version of I-D, draft-touch-tcpm-tcp-syn-ext-opt-07.txt has been successfully submitted by Joe Touch and posted to the IETF repository. Name: draft-touch-tcpm-tcp-syn-ext-opt Revision: 07 Title: TCP SYN Extended Option Space Using an Out-of-Band Segment Document date: 2017-06-26 Group: Individual Submission Pages: 14 URL: https://www.ietf.org/internet-drafts/draft-touch-tcpm-tcp-syn-ext-opt-07.txt Status: https://datatracker.ietf.org/doc/draft-touch-tcpm-tcp-syn-ext-opt/ Htmlized: https://tools.ietf.org/html/draft-touch-tcpm-tcp-syn-ext-opt-07 Htmlized: https://datatracker.ietf.org/doc/html/draft-touch-tcpm-tcp-syn-ext-opt-07 Diff: https://www.ietf.org/rfcdiff?url2=draft-touch-tcpm-tcp-syn-ext-opt-07 Abstract: This document describes an experimental method to extend the option space for connection parameters within the initial TCP SYN segment, at the start of a TCP connection. This method effectively extends the option space of an initial SYN by using an additional coupled segment that is sent 'out-of-band'. It complements the proposed Extended Data Offset (EDO) option that is applicable only after the initial segment. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --------------2A951B87AF4EEC181C4FE80E Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit

FYI - issued to update a pending expiration.

Joe



-------- Forwarded Message --------
Subject: New Version Notification for draft-touch-tcpm-tcp-syn-ext-opt-07.txt
Date: Mon, 26 Jun 2017 12:55:33 -0700
From: internet-drafts@ietf.org
To: Joseph Touch <touch@isi.edu>, Joe Touch <touch@isi.edu>, Ted Faber <theodore.v.faber@aero.org> 


A new version of I-D, draft-touch-tcpm-tcp-syn-ext-opt-07.txt
has been successfully submitted by Joe Touch and posted to the
IETF repository.

Name:		draft-touch-tcpm-tcp-syn-ext-opt
Revision:	07
Title:		TCP SYN Extended Option Space Using an Out-of-Band Segment
Document date:	2017-06-26
Group:		Individual Submission
Pages:		14
URL:            https://www.ietf.org/internet-drafts/draft-touch-tcpm-tcp-syn-ext-opt-07.txt
Status:         https://datatracker.ietf.org/doc/draft-touch-tcpm-tcp-syn-ext-opt/
Htmlized:       https://tools.ietf.org/html/draft-touch-tcpm-tcp-syn-ext-opt-07
Htmlized:       https://datatracker.ietf.org/doc/html/draft-touch-tcpm-tcp-syn-ext-opt-07
Diff:           https://www.ietf.org/rfcdiff?url2=draft-touch-tcpm-tcp-syn-ext-opt-07

Abstract:
   This document describes an experimental method to extend the option
   space for connection parameters within the initial TCP SYN segment,
   at the start of a TCP connection. This method effectively extends
   the option space of an initial SYN by using an additional coupled
   segment that is sent 'out-of-band'. It complements the proposed
   Extended Data Offset (EDO) option that is applicable only after the
   initial segment.

                                                                                  


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

The IETF Secretariat
--------------2A951B87AF4EEC181C4FE80E-- From nobody Mon Jun 26 13:05:35 2017 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 3323512EB2F; Mon, 26 Jun 2017 13:05:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mv0dJGwKd-W8; Mon, 26 Jun 2017 13:05:31 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E070129461; Mon, 26 Jun 2017 13:05:31 -0700 (PDT) Received: from [128.9.160.211] (mul.isi.edu [128.9.160.211]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id v5QK4nOE016843 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 26 Jun 2017 13:04:50 -0700 (PDT) To: internet-drafts@ietf.org, i-d-announce@ietf.org Cc: tcpm@ietf.org References: <149850692868.18460.1112273198342569110@ietfa.amsl.com> From: Joe Touch Message-ID: <1be25878-5615-9890-3b9b-968bb997b1a7@isi.edu> Date: Mon, 26 Jun 2017 13:04:49 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <149850692868.18460.1112273198342569110@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-tcp-edo-08.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jun 2017 20:05:33 -0000 Hi, all, This update addresses primarily document expiration. There are minor updates to clarify that the segment merging and/or splitting that might occur due to TCP offloading is a violation of the TCP spec. Joe On 6/26/2017 12:55 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 of the IETF. > > Title : TCP Extended Data Offset Option > Authors : Joe Touch > Wesley M. Eddy > Filename : draft-ietf-tcpm-tcp-edo-08.txt > Pages : 23 > Date : 2017-06-26 > > Abstract: > TCP segments include a Data Offset field to indicate space for TCP > options but the size of the field can limit the space available for > complex options such as SACK and Multipath TCP and can limit the > combination of such options supported in a single connection. This > document updates RFC 793 with an optional TCP extension to that > space to support the use of multiple large options. It also explains > why the initial SYN of a connection cannot be extending a single > segment. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-tcpm-tcp-edo/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-tcpm-tcp-edo-08 > https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-tcp-edo-08 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-tcp-edo-08 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Tue Jun 27 06:42:06 2017 Return-Path: X-Original-To: tcpm@ietf.org Delivered-To: tcpm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 652181274D2; Tue, 27 Jun 2017 06:41:58 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: tcpm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.55.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149857091835.14901.4928249566465863078@ietfa.amsl.com> Date: Tue, 27 Jun 2017 06:41:58 -0700 Archived-At: Subject: [tcpm] I-D Action: draft-ietf-tcpm-dctcp-08.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jun 2017 13:41:58 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the TCP Maintenance and Minor Extensions of the IETF. Title : Datacenter TCP (DCTCP): TCP Congestion Control for Datacenters Authors : Stephen Bensley Dave Thaler Praveen Balasubramanian Lars Eggert Glenn Judd Filename : draft-ietf-tcpm-dctcp-08.txt Pages : 16 Date : 2017-06-27 Abstract: This informational memo describes Datacenter TCP (DCTCP), a TCP congestion control scheme for datacenter traffic. DCTCP extends the Explicit Congestion Notification (ECN) processing to estimate the fraction of bytes that encounter congestion, rather than simply detecting that some congestion has occurred. DCTCP then scales the TCP congestion window based on this estimate. This method achieves high burst tolerance, low latency, and high throughput with shallow- buffered switches. This memo also discusses deployment issues related to the coexistence of DCTCP and conventional TCP, the lack of a negotiating mechanism between sender and receiver, and presents some possible mitigations. This memo documents DCTCP as currently implemented by several major operating systems. DCTCP as described in this draft is applicable to deployments in controlled environments like datacenters but it must not be deployed over the public Internet without additional measures. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tcpm-dctcp/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tcpm-dctcp-08 https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-dctcp-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-dctcp-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Jun 27 12:55:18 2017 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 77D4C12EB1E for ; Tue, 27 Jun 2017 12:55:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.88 X-Spam-Level: X-Spam-Status: No, score=-5.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=netapp.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id naicB0Ix2XEv for ; Tue, 27 Jun 2017 12:55:15 -0700 (PDT) Received: from mx142.netapp.com (mx142.netapp.com [216.240.21.19]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 372C11270A7 for ; Tue, 27 Jun 2017 12:55:15 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.40,271,1496127600"; d="asc'?scan'208";a="197274896" Received: from vmwexchts04-prd.hq.netapp.com ([10.122.105.32]) by mx142-out.netapp.com with ESMTP; 27 Jun 2017 12:31:09 -0700 Received: from VMWEXCCAS07-PRD.hq.netapp.com (10.122.105.25) by VMWEXCHTS04-PRD.hq.netapp.com (10.122.105.32) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 27 Jun 2017 12:49:57 -0700 Received: from NAM03-BY2-obe.outbound.protection.outlook.com (10.120.60.153) by VMWEXCCAS07-PRD.hq.netapp.com (10.122.105.25) with Microsoft SMTP Server (TLS) id 15.0.1210.3 via Frontend Transport; Tue, 27 Jun 2017 12:49:57 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netapp.onmicrosoft.com; s=selector1-netapp-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=85VOsh0mh5eAUZ+uVmpya1vmOe831XpqtyAaRH6mAJ0=; b=pCMtivL/96yJGHPnpzFF3Jywu8XoRaDJdrPRhOPM9ZyDriwCPGo48FnUu21zaDvzd0ugDPXvAC7axxbdhbDeJP6WwDBVDjYeMEC2qztksWrHLeN+NYDmiuHPV+2UqPMP8kYcxDdxGkdFjpz7/REcz9xxbhGOCv+a84YsxTWjgQU= Received: from BLUPR06MB1764.namprd06.prod.outlook.com (10.162.224.150) by BLUPR06MB1764.namprd06.prod.outlook.com (10.162.224.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1220.11; Tue, 27 Jun 2017 19:50:12 +0000 Received: from BLUPR06MB1764.namprd06.prod.outlook.com ([10.162.224.150]) by BLUPR06MB1764.namprd06.prod.outlook.com ([10.162.224.150]) with mapi id 15.01.1220.011; Tue, 27 Jun 2017 19:50:12 +0000 From: "Eggert, Lars" CC: "tcpm@ietf.org" Thread-Topic: [tcpm] I-D Action: draft-ietf-tcpm-dctcp-08.txt Thread-Index: AQHS70tSSKr4aslgXk29FsNflVLWH6I5HpQA Date: Tue, 27 Jun 2017 19:50:12 +0000 Message-ID: <82BC1F53-A32A-441B-AF92-A2BCF24B9D66@netapp.com> References: <149857091835.14901.4928249566465863078@ietfa.amsl.com> In-Reply-To: <149857091835.14901.4928249566465863078@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3273) authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=netapp.com; x-originating-ip: [2001:a61:3101:ad01:6cf0:35c2:790a:6c15] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BLUPR06MB1764; 7:+i7WNdQy7hQAe2ODGwPCWe0UaEvh4g3PVCxScwKqOJp/Uu8PQLUzGr+AuQmOnxhkHLdaB40eKZwYyEaIQZLmmQOm291oj6puQ0Bkacw7NbSc5Z1pERpcTe3067g+WWbnui1P0FuA/YY0N1QE17qukMilzFArimyCksOa7zDHSFfBymht89XAYvRV7qlKesqFYAE2HrJA1JDo7PzB0eq0m8OqULk1nPLEI5bvAaUHtuAYRTcYjWWoXtam4LL4lnxUE+v5Cce5cL3a40H61CjszPw1naRqmwQ06uWRL7MvYMor41DiwQAnlAh/IDPQYNSSw+KRTDtnoP8+47zlLisOnS0z/mqPe9pzXLQuownbpLXmt5EzEBy4gGWuSoG8lNV+LObzY2ebeKY/pARqtkWxg3N6X6DvUuFsZ0l0qz88oDU2ICCEM25hoXzKkIPFn/G1h0WxBLjQHodcI+45rdbIFlmR+ZS+pwTBO085+OQxUCnQ2cBb+DHOWyMBMlV2PufYEvH9xDcCwOHxM6TKfTd0H7M/ZaTc/UY7r3jAtJntfFJO1ssZYQ6+ZiXItlZLNmIeSKZJyVHOTkunXWTj6Ucgn0Srij6AHOTc/vhJZPxivI5lIIRJrZt1D1zH/oQIAQNjwuZ59XEa1fLmTxAudAc9qAMUob+w1LoAofb6n+hvYAsAssTqY+/KNx/AIM1j/SXHGb1eXvVGBlmSc5aeb4ckviS6D82z8yKNbmXctgI9MEyVHhY7XByoLx2lClaxlWK1W4gs5Rqj3GTmTp+QhLRn6LK2HxvRSQQR4Cw83yXZQ9A= x-ms-office365-filtering-correlation-id: a49e6166-600b-4257-c47a-08d4bd95b96e x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(300000502095)(300135100095)(22001)(2017030254075)(300000503095)(300135400095)(49563074)(201703131423075)(201703031133081)(300000504095)(300135200095)(300000505095)(300135600095); SRVR:BLUPR06MB1764; x-ms-traffictypediagnostic: BLUPR06MB1764: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105)(236129657087228)(148574349560750); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(102415395)(6040450)(601004)(2401047)(8121501046)(5005006)(93006095)(93001095)(10201501046)(100000703101)(100105400095)(3002001)(6055026)(6041248)(20161123562025)(20161123555025)(20161123558100)(20161123564025)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BLUPR06MB1764; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BLUPR06MB1764; x-forefront-prvs: 0351D213B3 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39840400002)(39410400002)(39850400002)(39400400002)(39450400003)(24454002)(377424004)(76176999)(5660300001)(50986999)(99936001)(50226002)(102836003)(6116002)(3660700001)(2950100002)(6486002)(2906002)(6512007)(77096006)(7736002)(305945005)(2900100001)(3280700002)(38730400002)(6306002)(82746002)(4001150100001)(6246003)(6436002)(99286003)(109986005)(6506006)(53936002)(110136004)(81166006)(8676002)(36756003)(8936002)(33656002)(83716003)(966005)(14454004)(4326008)(57306001)(86362001)(53546010)(25786009)(478600001)(230783001)(189998001)(1671002)(229853002)(59246006); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR06MB1764; H:BLUPR06MB1764.namprd06.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/signed; boundary="Apple-Mail=_B2CA081B-CB65-45DC-9A83-986AAD52910D"; protocol="application/pgp-signature"; micalg=pgp-sha512 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Jun 2017 19:50:12.1650 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4b0911a0-929b-4715-944b-c03745165b3a X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR06MB1764 X-OriginatorOrg: netapp.com Archived-At: Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-dctcp-08.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jun 2017 19:55:17 -0000 --Apple-Mail=_B2CA081B-CB65-45DC-9A83-986AAD52910D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii This version is attempting to address the IESG and other reviews that = were recently posted. Lars > On 2017-6-27, at 15:41, internet-drafts@ietf.org wrote: >=20 >=20 > 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 = of the IETF. >=20 > Title : Datacenter TCP (DCTCP): TCP Congestion = Control for Datacenters > Authors : Stephen Bensley > Dave Thaler > Praveen Balasubramanian > Lars Eggert > Glenn Judd > Filename : draft-ietf-tcpm-dctcp-08.txt > Pages : 16 > Date : 2017-06-27 >=20 > Abstract: > This informational memo describes Datacenter TCP (DCTCP), a TCP > congestion control scheme for datacenter traffic. DCTCP extends the > Explicit Congestion Notification (ECN) processing to estimate the > fraction of bytes that encounter congestion, rather than simply > detecting that some congestion has occurred. DCTCP then scales the > TCP congestion window based on this estimate. This method achieves > high burst tolerance, low latency, and high throughput with shallow- > buffered switches. This memo also discusses deployment issues > related to the coexistence of DCTCP and conventional TCP, the lack = of > a negotiating mechanism between sender and receiver, and presents > some possible mitigations. This memo documents DCTCP as currently > implemented by several major operating systems. DCTCP as described > in this draft is applicable to deployments in controlled = environments > like datacenters but it must not be deployed over the public = Internet > without additional measures. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-tcpm-dctcp/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-tcpm-dctcp-08 > https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-dctcp-08 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tcpm-dctcp-08 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm --Apple-Mail=_B2CA081B-CB65-45DC-9A83-986AAD52910D Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEmpq0ZpSoejRmyhheVLXDCb9wwVcFAllStvIACgkQVLXDCb9w wVfICBAAvsRyhwcQQ67fmiCl2sOlGJp/LW7o3STB3uaqnKqJps/l/pGGOP9pGcvJ 7Gczs7uXXv3PPtx7mYR46OClc+TxJ8QrdvT3cSXaOaqjf/Q+pt2XmugvDPA1KlFy avX0BdqD5v5YlO9C8MdfFgCo8chyVLp6fP/0WJ+Q4FqKhbRGmwSBrR5kmAaZIArM stOiEFGc1p/wHVVQsn+EL7bMeZwRhMlDsuee5BCkilVUSY9iJZUd4+S5XPsfLdUv Tup4DkFYBvjTaol/iDBPYc5m3n0FmLbrnkmx4r7bQ6ZlN2AfpqK5kkLCMt8JfGSS PdIpFUL3QemGbS6JrTVg6hD5g2vlUGvtJe8od67iRkhgsqCdHNk2kIzMjSdaN7It 6QnsXwCtodZdits6sqhFbYXdxYcrN41i1TaIQOqJanKv9cjhEJBxeMQxEyR6oOLn k4neoDJxMDB1Ndq1c9b+51Sk453XaVzWW3HY6hdWwcwytzHGtP4yJNCnxkzQI6WH CbnAZ6AoyE1o0MhXI9/xDl9iMEx8PvUJrZVip/ksAB6Uk7L4T2B1tZkTNSpQYECK NS+lLr9DflHqHXUiixyoCu3ASPYx/seiYQLbJw8tLSDmB1ge41j4Jm/k3gGIAoIu dBWjgLSaNXHltc5eh5VQLfsFZz64t3YAWvHid504TCDsGtGB/ng= =UBqn -----END PGP SIGNATURE----- --Apple-Mail=_B2CA081B-CB65-45DC-9A83-986AAD52910D-- From nobody Wed Jun 28 01:40:29 2017 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 65BF7128C83; Wed, 28 Jun 2017 01:40:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uUQjGbJegAbk; Wed, 28 Jun 2017 01:40:26 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51A5A127869; Wed, 28 Jun 2017 01:40:26 -0700 (PDT) X-AuditID: c1b4fb2d-7ebff70000005faa-d7-59536b7845af Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.183.39]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 17.98.24490.87B63595; Wed, 28 Jun 2017 10:40:24 +0200 (CEST) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.39) with Microsoft SMTP Server (TLS) id 14.3.352.0; Wed, 28 Jun 2017 10:40:23 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=59fACdSJz4ttI1dRYO1OBMDqCRo/hwBKatR/LEBHBIE=; b=cv7EaPNFEFYsk682Rzd3FgvrKFL9JiEGzAOi8j8N03R6PFP8U85dzPhipTG2AlIDpwSV2slHkKVIgw4jvBGSgLNbOyf0EFzhSpJ4QPZOs6KXuQ15ZL8Wz8xMixDqqgWSdlsw0TBDDWGhwm4urzVOxaMGQKnSHnkHBQtnRb3Q+3o= Received: from DB4PR07MB348.eurprd07.prod.outlook.com (10.141.234.148) by DB4PR07MB460.eurprd07.prod.outlook.com (10.141.238.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1220.5; Wed, 28 Jun 2017 08:40:23 +0000 Received: from DB4PR07MB348.eurprd07.prod.outlook.com ([fe80::4ce9:7bec:5be9:91b5]) by DB4PR07MB348.eurprd07.prod.outlook.com ([fe80::4ce9:7bec:5be9:91b5%18]) with mapi id 15.01.1220.014; Wed, 28 Jun 2017 08:40:22 +0000 From: Ingemar Johansson S To: Bob Briscoe , "tcpm@ietf.org" CC: "tcpm-chairs@ietf.org" , marcelo bagnulo braun , Ingemar Johansson S Thread-Topic: Re : Working group acceptance call draft-bagnulo-tcpm-generalized-ecn-04 Thread-Index: AdLt3HWa9cAL1IW3RDi4MVCsUHppsQAJGdAAAHoapwA= Date: Wed, 28 Jun 2017 08:40:22 +0000 Message-ID: References: In-Reply-To: Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: bobbriscoe.net; dkim=none (message not signed) header.d=none;bobbriscoe.net; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [192.176.1.90] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DB4PR07MB460; 7:pgr38cEG46PhcAIyeDbKBABrrxcshZ5DkiCmL6TWEItDCyJvrwVV8saJ67QA79VGknwZzNmdZyCFeZnu9YNCR5l079gmIJLEpmo1OhvExBmQ7DMipMAaD6okApNzmLdJ758auKsYSlvXHibw8Af1nRIRDRY2aDtBl4sz7IA2VOm1pLn5DzAKa9svIhefXfJfrCvwKwJJWBM64c6oJkY3CRyr2zpTHuDh1ju57aFzX+1awG8avrUCsr+sdazlCrJIFlo/125aVgcJtlYDJacc/GWSKjjjvtNzWoiMqmd3nXUaH+FOF23Lhrrrh+Mb43plKIudEh12hmLBS8AnNZusHx5F7LF//GCdqPOrAHw3S4MvVJ8JGbIU5eOCYytPZ7wQzfTiqbSK//VScOLPrKhCai4eKw1FPMb1HBf5hsmgExVGhvgP6am4EJniNY5thUPPENe/YfDqn62YMZdu8Io4LB2IR/cXQsCNb5gebIeIWHrU0mbxOcv52GsC9lX+EIC4SQj9E16sVhk1A1wmHpEaZSOy88/G/J2uQT9atdjiHxML75YJQJZVB7CMjFuY7/1knEmrj4ULKfhjK0Y6JEJJKeVwUmpEsCoBt7mQ3xF4JMjaAv1p9veCcEkH74ZE/6Q7XBzpgWX+Hufr+/MDUq1Mg7I93J/UPzv/eLzu6L1bOi3BpP8hE5ND6DUYWOq8aHCSLC36Ht+nWQ/LhqhG1t/fOM0T6YBu++Eu2brspuz2omlSTtKdVshtc7Qnr9vHwwIyviQtjPgjvNtQkn33clugQZYFKM3MWjmbtyB0NfQD1ls= x-forefront-antispam-report: SFV:SKI; SCL:-1SFV:NSPM; SFS:(10009020)(6009001)(39860400002)(39840400002)(39850400002)(39450400003)(39400400002)(39410400002)(53754006)(13464003)(24454002)(55016002)(9686003)(86362001)(6506006)(2501003)(3660700001)(512954002)(966005)(478600001)(45080400002)(3280700002)(7696004)(6306002)(53376002)(102836003)(6246003)(38730400002)(3846002)(6116002)(229853002)(107886003)(5660300001)(5890100001)(6436002)(54906002)(99286003)(5250100002)(2950100002)(2900100001)(66066001)(4326008)(74316002)(53936002)(230783001)(2906002)(25786009)(305945005)(189998001)(8936002)(81166006)(7736002)(54356999)(53546010)(561944003)(50986999)(8676002)(76176999)(33656002)(336755003)(18886065003); DIR:OUT; SFP:1101; SCL:1; SRVR:DB4PR07MB460; H:DB4PR07MB348.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-ms-office365-filtering-correlation-id: 73a2f902-8966-44e3-9064-08d4be0150d2 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(300000503095)(300135400095)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506086)(300135500095); SRVR:DB4PR07MB460; x-ms-traffictypediagnostic: DB4PR07MB460: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322)(278178393323532)(133145235818549)(236129657087228)(189930954265078)(82608151540597)(48057245064654)(148574349560750)(49204369933175)(247924648384137); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(100000703101)(100105400095)(93006095)(93001095)(10201501046)(3002001)(6041248)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123560025)(20161123555025)(20161123562025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DB4PR07MB460; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DB4PR07MB460; x-forefront-prvs: 03524FBD26 spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Jun 2017 08:40:22.5366 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB4PR07MB460 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA01Sa0hTYRjmOzeP1uprKr5ZUg0qsrxlwSyRFV2kiEKDVII86MmJbo6dKeov 8VI5L10IzVG5UGlZakaaWGoOM1dampW1yjVvK4N+GKghRtvOgv49z/s87/O+78fHktIqOpBN V+t4rZrLlDE+VE3Co60huRnxieHFE4HyZ3YjLS+ZbmTk5XXLjLzdUksoqNhZ2zAdW1//m4id H2ulT5BJPtGpfGZ6Dq8Ni0n2Ub7oHyE0E6G5M5PtXgVoIESPvFnAu+DioInSIx9WivsQdH0d okUygMDm0BMuQuEKEsymc4yoVBFQca3TY7MjqDYbGVcYg6PhjnkBubAfPgTdBivlwiSuRmBp O+LCvvgUdBUPkqInASyzVi8R74HFqhZ3ncKbofljA+3CEpwEvz69J8VhVxBcH5lxD/PG+8Gh t7kbEA4C28K4Z1gAWKdqCfE6DPVPXpMi9ofvk3/cWyNc47y0p9m5KesUNkLFaJLoCYI3tWXI 5QFsY8AyX0qIpImBQuMAJbqOQd1ir0d4Q0BR9yQlJm0Da6UnNB1Ki5JFyzCCtlcjtEie0tDh WPIErYfux0Vel9B2w3+bG5z9pDOqpTNMLG+Cq2V2L4P7NdaApWaKMiKqEfkLvCCo0nZGhvLa 9BRByFKHqnndA+T8Lb0Pl0I60N0f+8wIs0i2UmJLjU+U0lyOkKcyI2BJmZ8knHOWJKlcXj6v zTqjzc7kBTNax1KyAImiezhBitM4HZ/B8xpe+08lWO/AAqTUjcd6n//Qt/donYKLibNjOKxI KS3+3A+a1uS3L9ve5cRIfY/X7S6JLomavnywPllhcmRxZ3suREjiRvPy7xfGrF2Szs0dkI6p bsiinpPB94jVWzgds2NQP6Ac0p4u7zOGVt4OivSL+rkBvqhWZN9MNCnDTi5/u7WqgdOkNMko QclFBJNagfsLsSYPBikDAAA= Archived-At: Subject: Re: [tcpm] Working group acceptance call draft-bagnulo-tcpm-generalized-ecn-04 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jun 2017 08:40:28 -0000 SGkNCg0KWWVzLCB0aGUgaW5pdGlhbCBRVUlDIGFwcHJvYWNoIGlzIHRvIHJ1biB0aGUgIkVDTiBu ZWdvdGlhdGlvbiIgYWZ0ZXIgdGhlIGNvbm5lY3Rpb24gc2V0dXAuIEkgd2FzIHRvIGJyaW5nIHRo aXMgdXAgYXQgdGhlIFFVSUMgaW50ZXJpbSBidXQgdGhlcmUgd2FzIG5vIHRpbWUgdG8gZGlzY3Vz cyBFQ04uIEkgd291bGQgdmVyeSBtdWNoIHdlbGNvbWUgdGhhdCB0aGUgRUNOIG5lZ290aWF0aW9u IGlzIGRvbmUgYWxyZWFkeSBhdCB0aGUgY29ubmVjdGlvbiBzZXR1cCwgdG8gYXZvaWQgdGhlIGlz c3VlcyB5b3UgZGVzY3JpYmUgYmVsb3cuIEVDTisrICh0Y3BtLWdlbmVyYWxpemVkLWVjbikgd2ls bCBwcm92aWRlIHdpdGggdmVyeSB1c2VmdWwgZ3VpZGFuY2UgaGVyZS4NCg0KL0luZ2VtYXINCg0K PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBCb2IgQnJpc2NvZSBbbWFpbHRv OmlldGZAYm9iYnJpc2NvZS5uZXRdDQo+IFNlbnQ6IGRlbiAyNiBqdW5pIDIwMTcgMDA6MTgNCj4g VG86IEluZ2VtYXIgSm9oYW5zc29uIFMgPGluZ2VtYXIucy5qb2hhbnNzb25AZXJpY3Nzb24uY29t PjsNCj4gdGNwbUBpZXRmLm9yZw0KPiBDYzogdGNwbS1jaGFpcnNAaWV0Zi5vcmc7IG1hcmNlbG8g YmFnbnVsbyBicmF1biA8bWFyY2Vsb0BpdC51YzNtLmVzPg0KPiBTdWJqZWN0OiBSZTogUmUgOiBX b3JraW5nIGdyb3VwIGFjY2VwdGFuY2UgY2FsbCBkcmFmdC1iYWdudWxvLXRjcG0tDQo+IGdlbmVy YWxpemVkLWVjbi0wNA0KPiANCj4gSW5nZW1hciwNCj4gDQo+IFRoZSBkcmFmdCBhbHJlYWR5IHNh eXMgdGhpcyB3b3JrIHNob3VsIGJlIHRyYW5zZmVyYWJsZSB0byBTQ1RQLiBJIG1pZ2h0IGFsc28N Cj4gYWRkIGEgbm90ZSB0aGF0IGl0IGNvdWxkIGFsc28gYmVuZWZpdCBRVUlDLCBhbHRobyBJJ2Qg bGlrZSB0byBzZWUgc29tZSBkZXRhaWwNCj4gYmVmb3JlIHByZXN1bWluZyB0aGlzIHdpbGwgd29y ay4NCj4gDQo+IENvaW5jaWRlbnRhbGx5LCBJIGp1c3QgcmVhZCB5b3VyIEVDTiBpbiBRVUlDIGRy YWZ0IHllc3RlcmRheS4gQW5kLCBhbHNvDQo+IGNvaW5jaWRlbnRhbGx5LCBvbmUgb2YgbXkgbWFp biBjb21tZW50cyB3YXMgZ29pbmcgdG8gYmUgdGhhdCBpdCBzZWVtcw0KPiBkaXNhcHBvaW50aW5n IHRoYXQgaXQgb25seSAic2VuZHMgYW4gRUNOIG5lZ290aWF0aW9uIGZyYW1lIHdoZW4gY29ubmVj dGlvbg0KPiBzZXR1cCBpcyBjb21wbGV0ZWQuIiBSZXRyYW5zbWlzc2lvbiB0aW1lb3V0cyBoYXZl IHRvIGJlIGNvbnNlcnZhdGl2ZQ0KPiBkdXJpbmcgY29ubmVjdGlvbiBzZXQtdXAgd2hhdGV2ZXIg dGhlIHByb3RvY29sLiBTbyB0aGUgYmFja2dyb3VuZCBsZXZlbCBvZg0KPiBjb25nZXN0aW9uIGxv c3Mgd2lsbCB0aGVuIGxlYWQgdG8gdW5uZWNlc3NhcmlseSBwcm90cmFjdGVkIGludGVybWl0dGVu dA0KPiBkZWxheXMsIHdoaWNoIHdpbGwgcGFydGljdWxhcmx5IGhpdCBzaG9ydCBRVUlDIGZsb3dz LiBTbyBJIHdhcyBnb2luZyB0byBzdWdnZXN0DQo+IHRoYXQgeW91IG1pZ2h0IGJlIGFibGUgdG8g cHJvdGVjdCBRVUlDIGNvbm5lY3Rpb24gc2V0dXAgZnJvbSByYW5kb20NCj4gY29uZ2VzdGlvbiBs b3NzIGJ5IGFuIGFwcHJvYWNoIHNpbWlsYXIgdG8NCj4gRUNOKysuDQoNCj4gDQo+IA0KPiBJIGNh bm5vdCBndWFyYW50ZWUgdGhhdCBJIHdpbGwgaGF2ZSB0aW1lIHRvIHdyaXRlIHVwIHRoZSBvdGhl ciBjb21tZW50cyBmcm9tDQo+IG15IHJldmlldyBpbiB0aW1lIGZvciB5b3UgdG8gdXNlIGl0IGJl Zm9yZSB0aGUgSUVURiBkZWFkbGluZSAoSSBhbSBhYm91dCB0bw0KPiB0YWtlIGEgd2VlayBvZmYs IHJldHVybmluZyBvbiAzIEp1bCkuIEJ1dCBJIHdpbGwgdHJ5IHRvIGRvIGEgcXVpY2sgc3VtbWFy eSBmb3INCj4gdGhlIFFVSUMgbGlzdCBub3cuDQo+IA0KPiANCj4gDQo+IEJvYg0KPiANCj4gT24g MjUvMDYvMTcgMTk6MDMsIEluZ2VtYXIgSm9oYW5zc29uIFMgd3JvdGU6DQo+ID4gSGkNCj4gPg0K PiA+IEkgc3VwcG9ydCB0aGlzIHdvcmsuDQo+ID4gSW4gYWRkaXRpb24sIHBhcnRzIG9mIHRoZSBm aW5kaW5ncyBhbmQgcmVjb21tZW5kYXRpb25zIGluIHRoaXMgVENQDQo+IGdlbmVyYWxpemVkIEVD TiB3b3JrIG1heSBhbHNvIGJlIHVzZWZ1bCBmb3IgdGhlIHNwZWNpZmljYXRpb24gb2YgdGhlIEVD Tg0KPiBzdXBwb3J0IGluIFFVSUMsIGN1cnJlbnRseSBvdXRsaW5lZCBpbiAoaHR0cHM6Ly90b29s cy5pZXRmLm9yZy9pZC9kcmFmdC0NCj4gam9oYW5zc29uLXF1aWMtZWNuLTAzLnR4dCApLg0KPiA+ DQo+ID4gUmVnYXJkcw0KPiA+IEluZ2VtYXIgSm9oYW5zc29uDQo+ID4NCj4gPj4gTWVzc2FnZTog MQ0KPiA+PiBEYXRlOiBGcmksIDE2IEp1biAyMDE3IDA2OjA2OjQzICswMDAwDQo+ID4+IEZyb206 ICJTY2hhcmYsIE1pY2hhZWwgKE5va2lhIC0gREUvU3R1dHRnYXJ0KSINCj4gPj4gCTxtaWNoYWVs LnNjaGFyZkBub2tpYS5jb20+DQo+ID4+IFRvOiAidGNwbUBpZXRmLm9yZyIgPHRjcG1AaWV0Zi5v cmc+DQo+ID4+IENjOiAidGNwbS1jaGFpcnNAaWV0Zi5vcmciIDx0Y3BtLWNoYWlyc0BpZXRmLm9y Zz4NCj4gPj4gU3ViamVjdDogW3RjcG1dIFdvcmtpbmcgZ3JvdXAgYWNjZXB0YW5jZSBjYWxsDQo+ ID4+IAlkcmFmdC1iYWdudWxvLXRjcG0tZ2VuZXJhbGl6ZWQtZWNuLTA0DQo+ID4+IE1lc3NhZ2Ut SUQ6DQo+ID4+IAk8QU01UFIwNzAxTUIyNTQ3RkJDREU2MUIxNzU3NTYwRjIxNzk5M0MxMEBBTTVQ UjA3MDFNQg0KPiA+PiAyNTQ3LmV1cnByZDA3LnByb2Qub3V0bG9vay5jb20+DQo+ID4+DQo+ID4+ IENvbnRlbnQtVHlwZTogdGV4dC9wbGFpbjsgY2hhcnNldD0idXMtYXNjaWkiDQo+ID4+DQo+ID4+ IEhpIGFsbCwNCj4gPj4NCj4gPj4gQXMgcmVxdWVzdGVkIGJ5IHRoZSBhdXRob3JzLCB0aGlzIGUt bWFpbCBzdGFydHMgYSB3b3JraW5nIGdyb3VwDQo+ID4+IGFjY2VwdGFuY2UgY2FsbCBmb3IgZHJh ZnQtYmFnbnVsby10Y3BtLWdlbmVyYWxpemVkLWVjbi0wNCwgd2hpY2ggd2lsbA0KPiA+PiBydW4g b24gdGhlIGxpc3QgdW50aWwgSnVuZSAzMC4NCj4gPj4NCj4gPj4gVGhlIHByb3Bvc2FsIGlzIHRv IGFkZCBhIG5ldyBtaWxlc3RvbmUgdG8gdGhlICBUQ1BNIGNoYXJ0ZXINCj4gPj4NCj4gPj4gICAg U3VibWl0IGRvY3VtZW50IG9uIGFkZGluZyBFeHBsaWNpdCBDb25nZXN0aW9uIE5vdGlmaWNhdGlv biAoRUNOKQ0KPiA+PiB0byBUQ1AgQ29udHJvbCBQYWNrZXRzIHRvIHRoZSBJRVNHIGZvciBwdWJs aWNhdGlvbiBhcyBFeHBlcmltZW50YWwNCj4gPj4gUkZDDQo+ID4+DQo+ID4+IGFuZCB0byB1c2Ug ZHJhZnQtYmFnbnVsby10Y3BtLWdlbmVyYWxpemVkLWVjbiBhcyBhIHN0YXJ0aW5nIHBvaW50Lg0K PiA+Pg0KPiA+PiBJZiB5b3UgYmVsaWV2ZSB0aGF0IFRDUE0gc2hvdWxkIHdvcmsgb24gYSBkb2N1 bWVudCBpbiB0aGlzIHNwYWNlLCBhbmQNCj4gPj4gaW4gcGFydGljdWxhciBpZiB5b3UgYXJlIHdp bGxpbmcgdG8gcmV2aWV3IGl0LCBwbGVhc2UgcmVwbHkgdG8gdGhpcw0KPiA+PiBlLW1haWxzLiBQ bGVhc2UgYWxzbyBzcGVhayB1cCBpZiB5b3UgaGF2ZSBhbnkgY29uY2VybnMgb3Igb2JqZWN0aW9u cy4NCj4gPj4NCj4gPj4gVGhhbmtzDQo+ID4+DQo+ID4+IE1pY2hhZWwNCj4gPj4gLS0tLS0tLS0t LS0tLS0gbmV4dCBwYXJ0IC0tLS0tLS0tLS0tLS0tIEFuIEhUTUwgYXR0YWNobWVudCB3YXMNCj4g Pj4gc2NydWJiZWQuLi4NCj4gPj4gVVJMOg0KPiA+Pg0KPiA8aHR0cHM6Ly9tYWlsYXJjaGl2ZS5p ZXRmLm9yZy9hcmNoL2Jyb3dzZS90Y3BtL2F0dGFjaG1lbnRzLzIwMTcwNjE2LzENCj4gPj4gNTEN Cj4gPj4gZjkzZTkvYXR0YWNobWVudC5odG1sPg0KPiA+Pg0KPiA+PiAtLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0NCj4gPj4NCj4gPj4gU3ViamVjdDogRGlnZXN0IEZvb3Rlcg0KPiA+Pg0K PiA+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+ PiB0Y3BtIG1haWxpbmcgbGlzdA0KPiA+PiB0Y3BtQGlldGYub3JnDQo+ID4+IGh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdGNwbQ0KPiA+Pg0KPiA+Pg0KPiA+PiAtLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gPj4NCj4gPj4gRW5kIG9mIHRjcG0gRGlnZXN0LCBW b2wgMTU4LCBJc3N1ZSA3DQo+ID4+ICoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq Kg0KPiANCj4gLS0NCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KPiBfX19fX18NCj4gQm9iIEJyaXNjb2UgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgaHR0cDovL2JvYmJyaXNjb2UubmV0Lw0KDQo= From nobody Wed Jun 28 02:40:50 2017 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 E3F9012EB9A; Wed, 28 Jun 2017 02:40:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cu3HDt6Eh83u; Wed, 28 Jun 2017 02:40:45 -0700 (PDT) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id 6462F12EC03; Wed, 28 Jun 2017 02:40:45 -0700 (PDT) Received: from Gs-MacBook-Pro.local (fgrpf.plus.com [212.159.18.54]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPA id AE8491B001AA; Wed, 28 Jun 2017 12:34:35 +0100 (BST) Message-ID: <59537985.5010603@erg.abdn.ac.uk> Date: Wed, 28 Jun 2017 10:40:21 +0100 From: Gorry Fairhurst Reply-To: gorry@erg.abdn.ac.uk Organization: University of Aberdeen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: "tcpm@ietf.org" CC: "tcpm-chairs@ietf.org" References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [tcpm] Working group acceptance call draft-bagnulo-tcpm-generalized-ecn-04 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jun 2017 09:40:49 -0000 I support adoption of this work. I think there this is useful, and I will review future versions. I would also like to contribute measurements to inform the deployment of ECN methods. However, I query the inclusion of SCTP-specific text in this draft, and suggest this can be removed and contributions made to the related TSVWG work item to update the SCTP Spec. (Please see suggestions below.) Best wishes, Gorry — TEXT (SCTP): The present document also considers the implications for common derivatives and variants of TCP, such as SCTP [RFC4960], if the experiment is successful. - I am not sure this is appropriate, in particular, I doubt it is helpful to explicitly speculate about changes to addd ECN to SCTP that have yet to be progressed in the IETF. I’d much prefer this to refer to more general advice saying that similar methods may apply also to other transports that provide ECN support. (But see later, because I try to suggest a different approach). - Similarly I am not sure why section 5.1 is helpful in a TCPM document. — TEXT (SCTP): The following subsections discuss any interactions between setting ECT on all all packets and using the following popular variants or derivatives of TCP: SCTP, IW10 and TFO. - Section 5 discusses SCTP as a variant of TCP, I do not think this is appropriate. While SCTP can - and does - share congestion control mechanisms with TCP, it is regarded as a separate protocol. I think if kept, a change in wording would be really helpful. — My recommendations to consider regarding SCTP: (1) I would encourage you to remove the SCTP-specific text and think whether the draft could instead have a section saying something a little like: /If the IETF specifies ECN for other IETF protocols, it is expected that these specifications should also mark IP packets for their transport flows in the same way as described in this specification for TCP./ … with detail as required. I would see such text as informative, but very useful for UDP-based methods as well as for SCTP, DCCP, etc. (2) I suggest instead that if this is adopted by TCPM, some appropriate text is proposed to the TSVWG document: draft-ietf-tsvwg-rfc4960-errata. This document is a set of corrections that TSVWG will use to update the annexe to refer to this EXP spec. The paragraphs in this spec seem like a great starting point for such text and would be welcome in TSVWG. — TEXT (DCTCP): Finally, there are ongoing experimental efforts to promote the adoption of a slightly modified variant of DCTCP (and similar congestion controls) I dislike text in RFCs that can be seen in some way to promote Internet deployment of protocols specified for constrained deployment. Can we please consider more careful wording here? DCTCP is specified INFO - for use in controlled environments). I’d much rather see the current draft as a generic issue for any transport that uses the L4S ID to identify the ECN treatment. --- TEXT (NiT): By using the ECN capability, switches performing Active Queue Management (AQM) - Why switches? Isn’t the IETF primarily concerned with routers? - I’d suggest this is replaced by /network devices (e.g., routers, switches)/. —— TEXT (NiT): Therefore it is RECOMMENDED that the experimental AccECN specification [I-D.ietf-tcpm-accurate-ecn] is implemented (as well as the present specification), because it is expected that ECT on the SYN will give the most significant performance gain, particularly for short flows. - I think much care is needed to ensure this recommendation can not be interpreted as a requirement to implement AccECN, … is it possible to rewrite this as something like: - / Implementations of this specification are also RECOMMENDED to implement the experimental AccECN specification [I-D.ietf-tcpm-accurate-ecn], because it is expected that ECT on the SYN will give the most significant performance gain, particularly for short flows./ —— TEXT (NiT): SYN packets are dropped because having the the ECT(0)/ECT(1)/CE - Maybe should be /are dropped because they have/ —— TEXT (?): to learn if the network clears SYN packet - Unsure what /clear/ mean here? - (The measurement block in 3.2.1.1. has several typos that make it hard to read). —— TEXT (Question on retransmissions): It can ignore the prohibition in section 6.1.5 of RFC 3168 against setting ECT on retransmissions. - I am not sure this is quite thought through yet: When loss occurs as a result of a path change - i.e. encountering a middlebox-like behaviour that does not allow "normal" ECN on the new path, an updated path may not allow ECN to work in the way it is envisaged. This is actually a very similar case of ECN SYN negotiation. To me, this means a need for some form of fall-back and caching may need to be invoked when a retransmission is triggered and fails. - The measurement section probably would be improved in there was some note made that network path changes need to be considered as a potential cause of loss that could result in change of the ECN handling of the end-to-end path. - When the retransmission occurs, TCP is already reacting to loss detection. DCTCP and ABE both call loss out as a form of congestion detection that can not be handled by the ECN logic - i.e. the cwnd is reduced according to the loss reaction, not teh CE-marking. A CE-mark in this case offers little extra congestion information - somehow the text I think needs to be clearer here. — TEXT (Comment racing different SYN options): So it is questionable whether sending two SYNs will be necessary, particularly given failures at well-maintained sites could reduce further once ECT SYNs are standardized. - I think there are also downsides in racing SYNs - So, I’d personally urge more even more caution around the idea of sending two sets of SYNs with different sets of capabilities for the same connection. — TEXT (Comment FIN/RST): 4.6. FINs - When the congestion state is re-used due to congestion state sharing, a CE-marked segment **could** have implications on the shared window. However, I think this could be just a corner case that we could ignore - since there is no further protocol interaction after a FIN or RST, I don’t really see this as important. Whatever, if we allow ECT on other segments, it seems OK to allow them (and more consistent). — COMMENT: [ecn-pam] - The ECN measurements did not include access-side infrastructure, e.g., firewalls and ISP networks. This comment simply motivates the need for measurements at the edge of the network. --- From nobody Wed Jun 28 07:24:20 2017 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 164F7129B18; Wed, 28 Jun 2017 07:24:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.702 X-Spam-Level: X-Spam-Status: No, score=-4.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aWhkjlrFtadc; Wed, 28 Jun 2017 07:24:16 -0700 (PDT) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0113.outbound.protection.outlook.com [104.47.2.113]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6BF0912EC47; Wed, 28 Jun 2017 07:24:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector2-nokia-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=xun31kIMb9LZRC4bwZznIS2VggSkGCyDVwq6Bhb39JM=; b=X4PkSN2QH5CkYPTXMQPFjx5a6GkxAaq2KV8HoudMzAKvm1uYU0Ozow5N+PVTOGD7hVW3/NBvFSf7Nk/9lBlU2jEvyjiMO8Vfpx4R4gzQU64EJsB1pUV2HXUj9pYTzw9HghWQPdmryVwXZ861dsON7cdS4/jCtC8f2e8MN3HttpI= Received: from VI1PR0701MB2126.eurprd07.prod.outlook.com (10.169.137.7) by VI1PR0701MB1885.eurprd07.prod.outlook.com (10.167.197.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1220.5; Wed, 28 Jun 2017 14:24:12 +0000 Received: from VI1PR0701MB2126.eurprd07.prod.outlook.com ([fe80::34f3:3201:c0d4:17ef]) by VI1PR0701MB2126.eurprd07.prod.outlook.com ([fe80::34f3:3201:c0d4:17ef%13]) with mapi id 15.01.1220.013; Wed, 28 Jun 2017 14:24:12 +0000 From: "De Schepper, Koen (Nokia - BE/Antwerp)" To: Ingemar Johansson S , Bob Briscoe , "tcpm@ietf.org" CC: "tcpm-chairs@ietf.org" Thread-Topic: [tcpm] Working group acceptance call draft-bagnulo-tcpm-generalized-ecn-04 Thread-Index: AdLt3HWa9cAL1IW3RDi4MVCsUHppsQAJGdAAAHoapwAADB1uUA== Date: Wed, 28 Jun 2017 14:24:12 +0000 Message-ID: References: In-Reply-To: Accept-Language: nl-BE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ericsson.com; dkim=none (message not signed) header.d=none;ericsson.com; dmarc=none action=none header.from=nokia-bell-labs.com; x-originating-ip: [135.245.212.29] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR0701MB1885; 7:CiCG2+ta+IsQfFoOXqnAkSkxg3cMW3OhQb8jLqaWXuiq+9xfi6D0GqgAKxeK1cZjgJffMG5XAFl3HVyMYayZG851f8xvqP3cZ/iA7eFb3ZHpUwtTE0MtwOPNeOW2bOrdb7zmPyXxxhItzdnrwYMVcnUthMC7R3qLuaKkFTN2SNCyeveloJZuQ33gXCelbrnEjKMzBrjboxO6oYv5Ypu+XUXuOjk/sUKpS7HEbE+jdc5fDiPUjwJEjH6iqcw3inMQFabQU/azbbrgb25jBc7rIPddsTsCkJoYV7liCuV0geTDmhT3nDCfiALNf8Go+DHMPDuMatg5XGOzXFuIByqLVdi/I+qaBZL5IMCooUffZIKpgRWLSPqklDEMqZCELs6B3Efz7eL8IOJEtqYo2VHRVZaEEZ3r79R8GVxUyJ3qNzgZrkZMl537NyiELKVHoxMMqWZods7dpxT0Cctg4fVewqsJyjxnInuWBJhGuW0/9Atl2g1vaogfqldt3E5E/gQy01J/PwYrGLYudqzpXJlQ8030L5PpF78Ci0n87HpZoc++CzoEmiiRF0owpY+0bYLeN5djwGAIA/vXpSp76Cx1JJsEjJmFF+mqnxVWdQBdnsTc/0D3jS7ef81dksBf8fe1YRmSQ76VNIX0lmpDUiWAclBdeQ6udBjOkSfgnR0UOvkn43B/U7eg3NxI/IQ9JPHnPSS90Y9oohBoGnClpJtLpyMhmcsek3j5YJkChjbU2+rK6j5k5csAb+TCydQ8OwwqKoaEfz5HZOezXCqt0Y+b1cxoxgeSrulIbUvKjWKl4JU= x-ms-office365-filtering-correlation-id: 1288658f-a66c-4b18-5dcc-08d4be31591b x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(48565401081)(300000503095)(300135400095)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:VI1PR0701MB1885; x-ms-traffictypediagnostic: VI1PR0701MB1885: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322)(278178393323532)(133145235818549)(236129657087228)(189930954265078)(82608151540597)(48057245064654)(148574349560750)(49204369933175)(247924648384137); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(10201501046)(100000703101)(100105400095)(93006095)(93001095)(3002001)(6055026)(6041248)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123560025)(20161123562025)(20161123558100)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:VI1PR0701MB1885; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:VI1PR0701MB1885; x-forefront-prvs: 03524FBD26 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39450400003)(39400400002)(39840400002)(39860400002)(39850400002)(39410400002)(13464003)(53754006)(24454002)(74316002)(45080400002)(2900100001)(4326008)(6116002)(230783001)(50986999)(2950100002)(3846002)(25786009)(305945005)(66066001)(14454004)(3280700002)(966005)(478600001)(76176999)(54356999)(81166006)(8936002)(3660700001)(2906002)(5660300001)(561944003)(189998001)(6306002)(7696004)(53936002)(33656002)(99286003)(5250100002)(6506006)(55016002)(5890100001)(9686003)(2501003)(8676002)(6436002)(53376002)(512954002)(229853002)(86362001)(53546010)(6246003)(7736002)(38730400002)(90052001); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR0701MB1885; H:VI1PR0701MB2126.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nokia-bell-labs.com X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Jun 2017 14:24:12.1848 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0701MB1885 Archived-At: Subject: Re: [tcpm] Working group acceptance call draft-bagnulo-tcpm-generalized-ecn-04 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jun 2017 14:24:19 -0000 Hi, I also support acceptance of this draft and I'm willing to review it. Koen. > -----Original Message----- > From: tcpm [mailto:tcpm-bounces@ietf.org] On Behalf Of Ingemar > Johansson S > Sent: woensdag 28 juni 2017 10:40 > To: Bob Briscoe ; tcpm@ietf.org > Cc: Ingemar Johansson S ; tcpm- > chairs@ietf.org > Subject: Re: [tcpm] Working group acceptance call draft-bagnulo-tcpm- > generalized-ecn-04 >=20 > Hi >=20 > Yes, the initial QUIC approach is to run the "ECN negotiation" after the > connection setup. I was to bring this up at the QUIC interim but there wa= s no > time to discuss ECN. I would very much welcome that the ECN negotiation i= s > done already at the connection setup, to avoid the issues you describe > below. ECN++ (tcpm-generalized-ecn) will provide with very useful guidanc= e > here. >=20 > /Ingemar >=20 > > -----Original Message----- > > From: Bob Briscoe [mailto:ietf@bobbriscoe.net] > > Sent: den 26 juni 2017 00:18 > > To: Ingemar Johansson S ; > > tcpm@ietf.org > > Cc: tcpm-chairs@ietf.org; marcelo bagnulo braun > > Subject: Re: Re : Working group acceptance call draft-bagnulo-tcpm- > > generalized-ecn-04 > > > > Ingemar, > > > > The draft already says this work shoul be transferable to SCTP. I might= also > > add a note that it could also benefit QUIC, altho I'd like to see some = detail > > before presuming this will work. > > > > Coincidentally, I just read your ECN in QUIC draft yesterday. And, also > > coincidentally, one of my main comments was going to be that it seems > > disappointing that it only "sends an ECN negotiation frame when > connection > > setup is completed." Retransmission timeouts have to be conservative > > during connection set-up whatever the protocol. So the background level > of > > congestion loss will then lead to unnecessarily protracted intermittent > > delays, which will particularly hit short QUIC flows. So I was going to= suggest > > that you might be able to protect QUIC connection setup from random > > congestion loss by an approach similar to > > ECN++. >=20 > > > > > > I cannot guarantee that I will have time to write up the other comments > from > > my review in time for you to use it before the IETF deadline (I am abou= t to > > take a week off, returning on 3 Jul). But I will try to do a quick summ= ary for > > the QUIC list now. > > > > > > > > Bob > > > > On 25/06/17 19:03, Ingemar Johansson S wrote: > > > Hi > > > > > > I support this work. > > > In addition, parts of the findings and recommendations in this TCP > > generalized ECN work may also be useful for the specification of the EC= N > > support in QUIC, currently outlined in (https://tools.ietf.org/id/draft= - > > johansson-quic-ecn-03.txt ). > > > > > > Regards > > > Ingemar Johansson > > > > > >> Message: 1 > > >> Date: Fri, 16 Jun 2017 06:06:43 +0000 > > >> From: "Scharf, Michael (Nokia - DE/Stuttgart)" > > >> > > >> To: "tcpm@ietf.org" > > >> Cc: "tcpm-chairs@ietf.org" > > >> Subject: [tcpm] Working group acceptance call > > >> draft-bagnulo-tcpm-generalized-ecn-04 > > >> Message-ID: > > >> > >> 2547.eurprd07.prod.outlook.com> > > >> > > >> Content-Type: text/plain; charset=3D"us-ascii" > > >> > > >> Hi all, > > >> > > >> As requested by the authors, this e-mail starts a working group > > >> acceptance call for draft-bagnulo-tcpm-generalized-ecn-04, which wil= l > > >> run on the list until June 30. > > >> > > >> The proposal is to add a new milestone to the TCPM charter > > >> > > >> Submit document on adding Explicit Congestion Notification (ECN) > > >> to TCP Control Packets to the IESG for publication as Experimental > > >> RFC > > >> > > >> and to use draft-bagnulo-tcpm-generalized-ecn as a starting point. > > >> > > >> If you believe that TCPM should work on a document in this space, an= d > > >> in particular if you are willing to review it, please reply to this > > >> e-mails. Please also speak up if you have any concerns or objections= . > > >> > > >> Thanks > > >> > > >> Michael > > >> -------------- next part -------------- An HTML attachment was > > >> scrubbed... > > >> URL: > > >> > > > >> 51 > > >> f93e9/attachment.html> > > >> > > >> ------------------------------ > > >> > > >> Subject: Digest Footer > > >> > > >> _______________________________________________ > > >> tcpm mailing list > > >> tcpm@ietf.org > > >> https://www.ietf.org/mailman/listinfo/tcpm > > >> > > >> > > >> ------------------------------ > > >> > > >> End of tcpm Digest, Vol 158, Issue 7 > > >> ************************************ > > > > -- > > > __________________________________________________________ > > ______ > > Bob Briscoe http://bobbriscoe.net/ >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Wed Jun 28 07:36:32 2017 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 EB98A129B09; Wed, 28 Jun 2017 07:36:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jp8tu24sXp8v; Wed, 28 Jun 2017 07:36:30 -0700 (PDT) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0113.outbound.protection.outlook.com [104.47.0.113]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91DFF129AB8; Wed, 28 Jun 2017 07:36:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=BPyHwJ046notWGtOntqUXak0QVz8jJTWJhj+GaS4umA=; b=XKJINqby4+1gFKCLW5LRkv34ThO2UWQ1jSxXyvTFa2P27jNX+fGzg8A45sLbZhj5WxQ7dCk6xStT+20NzSQve/vlF3knsIYRA3nBXg4y+S6pNC/6knajOpwGRGozrn83rBQTfqinZ84myNGQxPdNyAbcBqZog3F2i57JT0hoI3s= Received: from AM5PR0701MB2547.eurprd07.prod.outlook.com (10.173.92.15) by AM5PR0701MB2577.eurprd07.prod.outlook.com (10.173.92.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1220.5; Wed, 28 Jun 2017 14:36:26 +0000 Received: from AM5PR0701MB2547.eurprd07.prod.outlook.com ([fe80::a0a5:bdaf:13ae:89c4]) by AM5PR0701MB2547.eurprd07.prod.outlook.com ([fe80::a0a5:bdaf:13ae:89c4%17]) with mapi id 15.01.1220.011; Wed, 28 Jun 2017 14:36:25 +0000 From: "Scharf, Michael (Nokia - DE/Stuttgart)" To: "tcpm@ietf.org" CC: "tcpm-chairs@ietf.org" Thread-Topic: IETF 99 agenda requests Thread-Index: AdLwG61gNBj27RzEQuq/S0jh2UIaFA== Date: Wed, 28 Jun 2017 14:36:25 +0000 Message-ID: Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=nokia.com; x-originating-ip: [92.203.132.219] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM5PR0701MB2577; 7:7Eo040z70rqM6NTn6C4s4eLTPTnX59sG2yirYrtMJD3ATYp4Fujj5Jc+Dtho5OTRg1pu1f44VcTf+x9DbjitPHZhxg8qs7vdRoTJUPlbt+AIbkcX2FuoHhBsjrS/n4lG1qQZ8UXBXeBGSgMvjzLk+K5Zgx/MrAjM+rjIMAEiAOrkZJSt2O9H+cfGtONub40zc1QLDl+1z23aPBCM2I7/faVO1jFpYiAuQz4sjHfI6vhi/Dt1ocFMhCjikwjAPee3QoZt2LcCLIpKwe98pi7aiQl+tDvp1LPfQol8PN+ARLWYVdV9ZreSjM0pzk2MArUm3S1WFy+jjywwKPNC2FsQrOJuhxv1OpwswQ/Ig5OAPy/VWbXpbanJW11PnUcuhJhLuG2nXvDc7BYFdEWGP/P1Hhbhi8FJ6rYZsT0ui1YQAsBM7zHcmt/gwLTvHzZRPsNluOwFn+hj/cGAqfi4Rvgnt/mMN6SbmW996QoyEDtEHmaXPGf2o304IFMwhbmPsPeW2ZGJ2qqTD1d0xf9qmDUd6J0hftTpiv6G6tgEgIChxpw/CPEoep7VTQo1KBo8UotoNf7Shg5K++CDue8h8Dk30RgbTKxEBgYxpKw23ND4O21+hInXRhoxCXI6tfQ96Le+//0tw+twjYHkXvTzP016SozyCjs2drX9CFytGZpCOVdhuAaAfsEjQmRDpnQ0Lqe8wSEmo1P7leOLHC/GTQDE/ebRvnbzbFhHPXnTP0jTsBQ00kDEHhEX19oI9NAoCW+rGinEfeEzadjD+pB4UvCfiB5wGc2xhDB9M9KDS1eI1W8= x-ms-office365-filtering-correlation-id: a1ffefcf-53ed-464f-b660-08d4be330e17 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(48565401081)(300000503095)(300135400095)(201703131423075)(201703031133081)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:AM5PR0701MB2577; x-ms-traffictypediagnostic: AM5PR0701MB2577: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(236129657087228); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(100000703101)(100105400095)(3002001)(10201501046)(93006095)(93001095)(6055026)(6041248)(20161123555025)(20161123562025)(20161123560025)(20161123564025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM5PR0701MB2577; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM5PR0701MB2577; x-forefront-prvs: 03524FBD26 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39840400002)(39450400003)(39410400002)(39400400002)(39850400002)(39860400002)(53754006)(99286003)(8936002)(6916009)(55016002)(9686003)(450100002)(53936002)(3660700001)(25786009)(14454004)(2351001)(7696004)(66066001)(7736002)(189998001)(6436002)(38730400002)(4326008)(110136004)(6506006)(8676002)(3846002)(5660300001)(86362001)(478600001)(7116003)(2906002)(50986999)(2501003)(2900100001)(5250100002)(305945005)(81166006)(54356999)(6116002)(33656002)(1730700003)(74316002)(3280700002); DIR:OUT; SFP:1102; SCL:1; SRVR:AM5PR0701MB2577; H:AM5PR0701MB2547.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Jun 2017 14:36:25.4033 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0701MB2577 Archived-At: Subject: [tcpm] IETF 99 agenda requests X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jun 2017 14:36:32 -0000 Hi all, We have our usual 2.5h slot in Prague. Please send slot requests for the T= CPM session to the chairs by the end of the day on Monday, July 3, indicati= ng: * Title / draft name * Presenter * Total time (including Q/A) As TCPM meets in the first slot on Monday, we'll need slides for presentati= on by Saturday, July 15. Thanks Michael From nobody Wed Jun 28 08:01:09 2017 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 D3AB7129C04 for ; Wed, 28 Jun 2017 07:54:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.292 X-Spam-Level: X-Spam-Status: No, score=-4.292 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_MIME_MALF=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LmJMPFYKu3Y3 for ; Wed, 28 Jun 2017 07:53:56 -0700 (PDT) Received: from mail-in2.apple.com (mail-out2.apple.com [17.151.62.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C28DD129B50 for ; Wed, 28 Jun 2017 07:53:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1498661636; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=kJB+14LOcPOwtE/ySX2MGl/zhcm2nzwHjEbT8mM16Rw=; b=RzKGknpjn7ubk9ruse5riIl3MRO+xmTSMm/m+ERJqGtsyqRq/pIXoXdwLxSNFkgY V0i4cLdWN5vlULMAbdbYtQEtuYU+QH1SrklyaFYk+9tPvs5UDpx16YXSf7jgd5J7 NrJJ0xrhesRoKh1wiEJ14CUEOudCpqOPIOvlWjMLHv5a21jXN0+ozKdqNtLygSii rm/JHB9QC9jPMf79INoz3Gd19AJxrYjWt7fRGsPdGRWe6U++kI+sBojBuWJgbnDe KF2+48ZNnrJ99POKkGsrsmorRdaP6SgFXKFUag8i+UsDyExi/hQLYTWp0Tn//K7J nhC+Tf2We6y8FHx2HwZIiQ==; Received: from relay6.apple.com (relay6.apple.com [17.128.113.90]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail-in2.apple.com (Apple Secure Mail Relay) with SMTP id 5E.E1.07214.403C3595; Wed, 28 Jun 2017 07:53:56 -0700 (PDT) X-AuditID: 11973e11-327ff70000001c2e-b6-5953c3049576 Received: from nwk-mmpp-sz12.apple.com (nwk-mmpp-sz12.apple.com [17.128.115.204]) by relay6.apple.com (Apple SCV relay) with SMTP id 0E.40.05199.303C3595; Wed, 28 Jun 2017 07:53:56 -0700 (PDT) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_IjFhySFtC3x8Z6xr7+9NBQ)" Received: from [17.149.236.120] (unknown [17.149.236.120]) by nwk-mmpp-sz12.apple.com (Oracle Communications Messaging Server 8.0.1.2.20170210 64bit (built Feb 10 2017)) with ESMTPSA id <0OS900CWGIPSFV60@nwk-mmpp-sz12.apple.com>; Wed, 28 Jun 2017 07:53:55 -0700 (PDT) Sender: bhooma@apple.com From: Padma Bhooma Message-id: Date: Wed, 28 Jun 2017 07:53:52 -0700 In-reply-to: Cc: tcpm@ietf.org, marcelo bagnulo braun To: Bob Briscoe References: X-Mailer: Apple Mail (2.3273) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrFLMWRmVeSWpSXmKPExsUi2FAYpctyODjS4N4DUYujDxewWrQ+XcVm se3kfCYHZo9X9y+weixZ8pPJ49v1jawBzFFcNimpOZllqUX6dglcGWfvTmcu+LqZo+Lv/3lM DYxnF7J3MXJySAiYSDz+cISxi5GLQ0hgNZNE36zFTF2MHGCJ3hUZEPFDjBK3npxiA2ngFRCU +DH5HgtIDbNAmMTj2/YgYSGByUwSl9o4QWxhAQmJwyc2sIDYbAKqEif/3GGGaLWRuDlrNRtE TaTElaMz2UHGsADV7DlpDRLmFHCS2PJsE1grs4CtxJeNXxlBSkSASla2q0Bcs4hRovVxMyPE +bISt2ZfYoawz7BJnNolP4FRaBaSQ2chHAphqktMmZI7C2yBtsSTdxdYIWw1iYW/FzEhiy9g ZFvFKJSbmJmjm5lnpJdYUJCTqpecn7uJERQZ0+0EdzAeX2V1iFGAg1GJh3fFquBIIdbEsuLK 3EOM0hwsSuK8+XMCI4UE0hNLUrNTUwtSi+KLSnNSiw8xMnFwSjUw5ocEnmGqMTk1yyXdZ95C oS+LVxrohegWielyS1V+zi+L23aq8OsCycRD0bO+cird1D9XvpE74d7jyds+RFxaMt1/zeqi fT9CV51K+2Sy5/Bk5zse2tMk59qXK4hv4F07fQ5DmDePnFKjbz/bCbM7H+UV20XTjsm0X/eo e5hh6Vp1Y1P2DI52JZbijERDLeai4kQAdZkvBm0CAAA= X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrKIsWRmVeSWpSXmKPExsUi2FB8RpflcHCkwZoXXBZHHy5gtWh9uorN YtvJ+UwOzB6v7l9g9Viy5CeTx7frG1kDmKO4bFJSczLLUov07RK4Ms7enc5c8HUzR8Xf//OY GhjPLmTvYuTgkBAwkehdkdHFyMUhJHCIUeLWk1NsXYycHLwCghI/Jt9jAalhFgiTeHzbHiQs JDCZSeJSGyeILSwgIXH4xAYWEJtNQFXi5J87zBCtNhI3Z61mg6iJlLhydCbYKhagmj0nrUHC nAJOEluebQJrZRawlfiy8SsjSIkIUMnKdhWIaxYxSrQ+bmYEqZEQkJW4NfsS8wRG/llIjpuF cByEqS4xZUruLLCh2hJP3l1ghbDVJBb+XsSELL6AkW0Vo0BRak5ipZleYkFBTqpecn7uJkZw KBdG7WBsWG51iFGAg1GJh3fFquBIIdbEsuLKXGAAcTArifC2LgQK8aYkVlalFuXHF5XmpBYf YpzICPTiRGYp0eR8YKTllcQbmpgYmBgbmxkbm5uY01JYSZxXpicoUkggPbEkNTs1tSC1COYo Jg5OqQZGnanXKk9Fxum8+9ezac9a7RONzS5suywu5ruKuOvkv3BcekZj1QuLXS/mrF62tk1Q gv3kqh2Ok5d6aOu9eF33omt5+Ez9o8seHGDZu3ZVWeNnpctLZQ5c0gssttvC2nDYj+VB12dN ixuFgfdMVkd789T+uqY3b7bxt6Vi7k6LTQ8cuhBxlHl+sxJLcUaioRZzUXEiAFB2JfHYAgAA Archived-At: X-Mailman-Approved-At: Wed, 28 Jun 2017 08:01:07 -0700 Subject: Re: [tcpm] Working group acceptance call draft-bagnulo-tcpm-generalized-ecn-04 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jun 2017 14:54:01 -0000 --Boundary_(ID_IjFhySFtC3x8Z6xr7+9NBQ) Content-type: text/plain; charset=utf-8 Content-transfer-encoding: quoted-printable Hi Bob Thanks for your responses. Please see inline. > On Jun 19, 2017, at 11:38 AM, Bob Briscoe wrote: >=20 > Padma, [re-sending - somehow my email client missed you off the = distr.] >=20 > On 17/06/17 17:27, Padma Bhooma wrote: >> Hi Marcelo and Bob, >>=20 >> I have reviewed the document draft-bagnulo-tcpm-generalized-ecn-04 = and I am sending my comments below. Overall, I think there is value in = working on these additions or enhancements to RFC 3168 in tcpm working = group. I am willing to review and provide feedback as needed. >>=20 >> Section 3.2.1.3 - If the SYN-ACK does not support AccECN, TCP must = conservatively reduce its IW and SHOULD reduce it to 1 SMSS. This clause = is very conservative because AccECN support can be deployed on servers = slowly. Even if both end hosts support AccECN, there are networks with = performance proxies that will not allow the feedback to propagate = correctly. On those networks, TCP connections with ECT on SYN will = always start with 1MSS of IW. I think this is too conservative and might = add multiple RTT to grow the window. I agree with the value in adding = ECT marking to SYN and SYN-ACK in terms of the latency benefits that = might bring to an end user. > [BB] We have structured the document to just recommend the preferred = approach in the normative spec (section 3), then discuss the rationale = and possible alternatives in section 4. The sections just before 3.2.1.3 = recommend: > - 3.2.1.1: the client uses ECT optimistically=20 > - 3.2.1.2: but the client caches servers that don't recognize ECT. > This is the "optimistic ECT and cache failures" strategy discussed in = 4.2.1 (tagged as 'S2B'). >=20 > The requirement to reduce IW to 1SMSS only applies if the client is = adopting this strategy and discovers the server does not support AccECN. = Perhaps we didn't make that clear? [PB] No I think this point was clear. >=20 > We have given 3 reasons for why this conservatism will rarely harm = performance: >=20 > 1) With this strategy, IW=3D1SMSS will only be needed the first time a = client accesses a non-AccECN proxy or server. >=20 > 2) During transition, this conservative IW=3D1SMSS will only ever be = necessary for the client to server half-connection, not server to = client.=20 > According to Yuchung Cheng, client Web requests are rarely greater = than 1 segment (no data openly available). Do you have any data to = corroborate (or contradict) this? I think in non-Web apps, the initial = client request would often fit within 1 packet too (e.g. email, ftp, = ssh, scp, etc). >=20 > 3) Fall-back to 1SMSS is written as SHOULD rather than MUST. And = refers to text later that says under what conditions you can use a = higher IW. >=20 >> I think =E2=80=9Cpessimistic ECT and cache successes=E2=80=9D = strategy described in 4.2.1 sounds like a reasonable one. > [BB] What's your reasoning for preferring this one? We recommended = "optimistic ECT and cache failures=E2=80=9D. [PB] I think, 1MSS may not be enough for clients that are not web based. = This assumption may not apply to connections that multiplex data on a = single connection. Starting at 1MSS will make the client need more RTTs = to reach the congestion window that is needed if the client wants to = send more than an HTTP get. =46rom the client side, the number of = servers they connect to can be large (one-to-many) and using 1MSS on = every one of them can effect performance. When there are performance = proxies or other kind of middle boxes in the network that will not make = AccECN work end-to-end, trying optimistic ECT can potentially have a = performance hit. >=20 >>=20 >> Section 3.2.3 ECT marking on Pure Acks - It felt like the document = suggested further discussion on setting ECT on pure Acks, please correct = me if I am wrong here. Setting ECT on pure Acks can increase the load on = an AQM that might already be under load. This is because the number of = Acks can be large and the information conveyed to the peer is redundant = because asks are cumulative. TCP acknowledgements also do not solicit a = response from the peer most of the times. So the chances of not echoing = CE on an Ack is high.=20 > [BB] Let's take these points one at a time: > PB: Setting ECT on pure ACKs could increase the load on an AQM > BB: An AQM processes packets of all sizes anyway. If pure ACKs are not = ECT, it still has to decide whether to drop each pure ACK. Marking = instead of dropping doesn't make any more work for the AQM. [PB] Here by "load" I meant that the queue sizes can grow and increase = the probability of a drop for all traffic. I agree that if the queue = sizes are manageable it will be great to not drop Acks also.=20 >=20 > PB: The information conveyed to the peer is redundant because ACKs are = cumulative. > BB: Just because the ACKnumber info is superseded by the next ACK does = not mean the ECN marking is superseded. [PB] Yes, agreed. That is also true for other information like SACK that = can be on an ACK. >=20 > PB: TCP acknowledgements do not solicit a response from the peer most = of the times. So the chances of not echoing CE on an Ack is high. > BB: Just because pure ACKs do not solicit a specific response (no ACK = of an ACK) does not mean the data sender is not continuing to send data = packets, on which ECE can be set (if RFC3168 feedback) or on which the = CE counter can be increased (AccECN feedback). >=20 > RFC3168 actually says this: > (One simple possibility would be for the sender to reduce its > congestion window when it receives a pure ACK packet with the CE > codepoint set). > Consider this pure ACK example with data solely in the S->C direction, = where S is the server. > * Say 3 in 1000 pure ACKs in the C->S direction are CE-marked, = meaning the C->S marking probability is 0.3% > * This might be because 0.3% of data packets in other flows (e.g. a = YouTube upload) are being CE-marked as well. > * So S needs to tell C that it has seen 3 CE marked packets (which = it will do on the data packets it is sending, whether with RFC3168 = feedback or AccECN feedback). > * C is not (currently) sending any data to S, but it will reduce its = cwnd for if it does start sending data. [PB] I think, it will be good to make AccECN feedback a strong = requirement for propagating CE marking on Acks also. Imagine a = bottleneck link that is congested due to a large flow and a few other = flows sending Acks alone. Then propagating CE marking on Acks can make = flows that will never send respond to congestion unnecessarily.=20 >=20 >> It is also difficult to detect if an Ack is dropped by an = incompatible middle box because of ECT marking on it since we do not = retransmit Acks.. So the fallback mechanisms will be limited.=20 > [BB] You're correct in all respects here. Nonetheless, I have three = responses: > * We have been doing millions of measurements over fixed and mobile = networks, using a machine we control on both sides and checking a sent = ECT packet is also received. So far, we have not seen any difference in = the treatment of any control packet if set to ECT vs not-ECT.=20 > * Section 6.1.4 of RFC3168 = hinted that in = future pure ACKs might be set to ECT. So if a security middlebox is = trying to enforce RFC3168, it still might allow ECT pure ACKs to pass. > * Nonetheless, if there were a middlebox that dropped ECT pure ACKs, = you are right that it could black-hole all ECT pure ACKs and stall a = connection. And there would be no easy way to detect the specific cause = of the problem and stop setting ECT on pure ACKs.=20 > * We should at least say that if fall-back has to be used because = ECT SYNs or SYN-ACKs are not getting through, then ECT ought not to be = used on pure ACKs either. [PB] Yes, that will be a good addition to the fallback mechanisms. >=20 > This is a good reason for why this protocol is experimental. However, = given we have not so far found this problem in practice, I think it's OK = to go ahead. But I agree that we should note that this is an open issue.=20= >=20 >> In Section 4.4.1 (Cwnd response to CE-marking on Pure Acks), the = document says that we can echo a CE received on a pure ack on a data = segment that will be sent later. In general, I think any congestion = notification is relevant only for a short period of time probably in the = order of a typical RTT. Once that time window passes, it may not be = correct to respond to a delayed congestion notification. So echoing CE = from a pure Ack on a data segment sent much later may not be the correct = thing to do. > [BB] This is true.=20 > However, this point applies generally to idle periods, not just when = pure ACKs are marked. TCP can always enter an idle period just after a = loss or CE mark is received, then if later the sender has something to = send, cwnd will be lower. Cwnd is already reduced exponentially during = an idle period.=20 >=20 > This is all part of the fairly arbitrary rules on how to evolve cwnd = during an idle period. Nonetheless, while idling, I think it is sensible = to reduce cwnd more, if more of any pure ACKs sent during the idle = period are picking up congestion markings. I don't think we should = recommend the converse: i.e. if the congestion was a long time ago, we = should not recommend that cwnd can be increased again. [PB] Yes, I agree. It might be a good idea to refer to work on idle = periods here because this connection was not obvious to me :) >=20 > However, this is an area where I think implementers should be allowed = to experiment, and I think the specs allow enough flexibility to do so. >=20 >=20 >>=20 >> Section 3.2.4 Window Probe - Adding ECT to window probes is really = good because this traffic is not too large on any connection and it = requires the peer to respond so that there is a way to echo the CE = marking. One modification that might be worth = discussing is to require congestion response to CE marking on a window = probe only when the receive window is opened. I will try to explain why = this is reasonable. If congestion at the bottleneck link is transient, = then lowering the congestion window in response to CE on a window probe = that does not open the receive window might not be necessary because = there won=E2=80=99t be any data sent afterwards. This can actually = happen multiple times on a connection because a connection can go on for = a long time sending multiple window probes when the peer does not open = the window. So reducing congestion window only when the receive window = is opened as a response to CE seems to be accurate in terms of timing = and reaction to congestion notification. > [BB] On the other hand, if the window was constrained solely because = the receive window was low and there had been a CE mark on a window = probe many round trips ago, but not on more recent window probes, it = would not be correct to reduce cwnd such a long time after the = congestion had occurred. >=20 > I think it would be better to reduce cwnd immediately there is a CE on = a window probe, increase cwnd as normal for every non-CE-marked window = probe (even if rwnd is still the limiting factor). But also rely on cwnd = validation so that cwnd cannot grow excessively if it is not being used. [PB] I think, it will be good to have some clarifying text here. Both = the points that I made above (about Section 3.2.4 and Section 4.4.1) are = kind of related to connections that see CE marking on control packets = but do not have a lot of data to send or they are limited by receive = window. The mechanisms for maintaining congestion window correctly when = a CE marking is received in these scenarios is not well documented in = RFC 3168 or in this draft. I agree that there are congestion window = validation mechanisms (RFC 7661) that might apply here. So it will be = good to give some recommendation here. >=20 >>=20 >> Section 3.2.7 Retransmissions - If a connection doesn=E2=80=99t set = ECT on a SYN because it does not support AccECN feedback (due to = fallback mechanisms or something else), then the first data packet will = be the first packet on a connection with ECT marking on it. If it is = dropped, sending retransmissions without ECT might make it go through if = there is a middle box that incorrectly drops packets with ECT marking. I = think, this detection and fallback mechanism must be somehow included in = the proposal to mark retransmissions with ECT. > [BB] Good point. I had figured that fall-back only needed to be = considered for the SYN or SYN-ACK. But you're right that, if the SYN is = not-ECT, fall-back might be needed later (altho, as already mentioned, = we have not seen a need in measurements so far). This will generally = only apply to the C->S half-connection.=20 >=20 > This is a general point about fall-back that happens to be noticed = when both data and retransmissions fail to get through. So I think we = ought to add a general point about fall-back as a new subsection of = section 3, rather than writing this in the retransmissions subjection. I = propose this text: > 3.2.8 General Fall-Back >=20 > Consider a host that has sent the first packet on a half-connection = (SYN or SYN/ACK) without ECT set and it has been acknowledged. If this = host's retransmission timer expires more than once for all subsequent = packet(s) it sends with ECT set, it SHOULD retransmit the packet(s) with = not-ECT set. If these not-ECT packet(s) are acknowledged without any = further losses, it is RECOMMENDED that the host disables setting ECT on = all subsequent packets of the half-connection. It could also cache this = failure. >=20 [PB] Yes, this is good. >=20 >>=20 >> Another point to note is that a connection should be already in = recovery and must have adjusted it=E2=80=99s congestion window before = sending a retransmission because it detected loss. If it further detects = that there was CE marking on a retransmitted packet then it is not clear = if it needs to adjust the congestion window again. Adding some = clarification here will be good. > [BB] Yes. We already say: > If the TCP sender receives feedback that a retransmitted packet was > CE-marked, it will react as it would to any feedback of CE-marking = on > a data packet. > Do you have a suggestion for clearer text? Perhaps: > If the TCP sender receives feedback that a retransmitted packet was > CE-marked, it will react as it would to any feedback of CE-marking = on > a data packet, in addition to its original reaction to the loss = that=20 > caused the retransmission. >=20 > RFC5681 already says: > Loss in two successive windows of data, or the loss of a > retransmission, should be taken as two indications of congestion = and, > therefore, cwnd (and ssthresh) MUST be lowered twice in this case. > It's hard to be more specific because we didn't want to contradict = other congestion control schemes (e.g. some respond to at least one mark = per RTT, others respond to the extent of CE marking). [PB] I agree. I did not fully grasp that text. I think this is good. >=20 >=20 >>=20 >> Tail loss probe - I think it will also be useful to include some text = about CE marking on probe packets that a connection might send in = response to tail loss (draft-dukkipati-tcpm-tcp-loss-probe-01.txt). > [BB] Well, I would like to resist mission creep. The scope of our = draft is intended to be about setting ECT on packets where it was = previously prohibited. >=20 > We have included interactions with SCTP, TFO and IW10 in "5.=C2=A0 = Interaction with popular variants or derivatives of TCP = " because they have been published and can no longer be easily = changed. >=20 > For TLP, it's not even adopted in TCP yet (although I'm sure it is = widely used). So I think it's up to the authors of this draft to say = whether ECT should be set on a TLP and what the response to a CE-marked = TLP should be. [PB] Ok, sounds good. >=20 >>=20 >> Implementation or deployment related comments - The document refers = to other drafts or experimental RFCs as possible actions that can be = taken in several scenarios. For example AccECN, RFC 5690, RFC 7567 etc,. = Even though implementing and deploying these specifications is possible, = they may not be implemented unless these specifications are tightly = bound together. A casual reader might understand that implementing = multiple of these RFCS will make the system work well. But for someone = to implement and deploy these specifications, it is not clear if some or = all of these implementations will need to be supported. It will be good = to make a recommendation for the minimum set of specifications that need = to be implemented =E2=80=94 may be after some more discussion. > [BB] If my co-author agrees, we can do this. I would recommend the = following complements (both normatively referenced):=20 > * AccECN=20 > * RFC5691 (robustness to blind in-window attacks). >=20 > As a reciprocal recommendation, currently, the Intro to the AccECN = draft says: > It is likely (but not required) that the AccECN protocol will be > implemented along with the following experimental additions to the > TCP-ECN protocol: ECN-capable TCP control packets and = retransmissions > [I-D.bagnulo-tcpm-generalized-ecn = ], which includes the ECN-capable > SYN-ACK experiment [RFC5562 ]; = and testing receiver non-compliance > [I-D.moncaster-tcpm-rcv-cheat = ]. >=20 >=20 > The following are good, but I don't think they qualify as = complementary to ECN++: > * RFC5690 (ACKcc). It is merely optional and "not incompatible". > * Similarly for TFO and IW10. Optional but not incompatible. > * RFC7567 is about AQM in the network, so I don't it would help an = implementer to say it is complementary, as host implementers cannot = control where their implementation is used. > * Originally we were going to recommend RFC5562 (ECN+ i.e. ECT on = SYN-ACK packets), but once we realized it was over-conservative, we = wrote a less conservative alternative directly into this ECN++ draft. [PB] Are there any changes needed on the AQM side in the network to = support CE marking on control packets? I do not think so but it will be = good to get a clarification. >=20 >=20 > More generally, I know some people are starting to get really confused = over how to put together all the piecemeal modifications to ECN. I think = that would require an informational "ECN roadmap" draft. No promises, = but I guess I am someone who would be well-placed to know what to write = in such a draft. >=20 [PB] Yes, this is true, especially with the latest experimentation = around RFC 3168. It will be good to have an ECN roadmap. >=20 >>=20 >> Fallback mechanisms - The document also discusses several fallback = mechanisms to handle incompatibilities in the network. If we want = implementations to consider these cases, it will be useful to formalize = these detection and fallback mechanisms. I found that some of these = mechanisms are being discussed in section 4 which was tagged as = informative. >>=20 > [BB] I have just checked, and I cannot find any case where there is = fall-back text in section 4 that ought to be normative. If you found = any, pls say where. We tried to ensure that the recommended approach was = always in section 3, even if section 4 discussed (then rejected) = alternatives. [PB] Ok. Some measurements in the field will help to support the need = for these fallback mechanisms. I wonder if there is a way to make them = as "strong recommendations=E2=80=9D so that the implementors do not = think of them as optional. >=20 >> Overall, the document is written well and discusses multiple aspects = of the proposed changes both on the end hosts and in the network. It is = useful to have discussions on the proposed changes and to drive = measurements that are needed to collect data to support or validate some = of the assumptions made. >=20 > [BB] Thanks.=20 >=20 > In summary, as this conversation progresses, we might agree further = changes. However, so far I have queued up the following list of changes = to the text to address your points: > * Intro: Recommend complementary RFCs or drafts > * 3.2.1.3: Clarify that using IW=3D1SMSS only applies when using the = strategies recommended in the previous two sections. > * When fall-back due to ECT on SYN (3.2.1.4) or SYN-ACK (3.2.2.3), = consider disabling ECT on other control packets (esp. pure ACKs). > * Add detection of black-holing of pure ACKs as an open issue (hence = why we have to take the approach in the previous bullet) > * Add extra section on general fall-back if no ECT packet has ever = been ack'd > * And we will certainly acknowledge your contribution, and I hope you = will continue to track changes to this draft carefully and let us know = if you have implementation experience - thank you. Sounds good. Thank you! Padma >=20 >=20 > Bob >=20 >>=20 >>=20 >> Thanks, >> Padma >>=20 >>=20 >>>=20 >>>=20 >>> 1. Working group acceptance call >>> draft-bagnulo-tcpm-generalized-ecn-04 >>> (Scharf, Michael (Nokia - DE/Stuttgart)) >>>=20 >>>=20 >>> = ---------------------------------------------------------------------- >>>=20 >>> Message: 1 >>> Date: Fri, 16 Jun 2017 06:06:43 +0000 >>> From: "Scharf, Michael (Nokia - DE/Stuttgart)" >>> > >>> To: "tcpm@ietf.org " > >>> Cc: "tcpm-chairs@ietf.org " = > >>> Subject: [tcpm] Working group acceptance call >>> draft-bagnulo-tcpm-generalized-ecn-04 >>> Message-ID: >>> = > >>> =09 >>> Content-Type: text/plain; charset=3D"us-ascii" >>>=20 >>> Hi all, >>>=20 >>> As requested by the authors, this e-mail starts a working group = acceptance call for draft-bagnulo-tcpm-generalized-ecn-04, which will = run on the list until June 30. >>>=20 >>> The proposal is to add a new milestone to the TCPM charter >>>=20 >>> Submit document on adding Explicit Congestion Notification (ECN) to = TCP Control Packets to the IESG for publication as Experimental RFC >>>=20 >>> and to use draft-bagnulo-tcpm-generalized-ecn as a starting point. >>>=20 >>> If you believe that TCPM should work on a document in this space, = and in particular if you are willing to review it, please reply to this = e-mails. Please also speak up if you have any concerns or objections. >>>=20 >>> Thanks >>>=20 >>> Michael >>> -------------- next part -------------- >>> An HTML attachment was scrubbed... >>> URL: = > >>>=20 >>> ------------------------------ >>>=20 >>> Subject: Digest Footer >>>=20 >>> _______________________________________________ >>> tcpm mailing list >>> tcpm@ietf.org >>> https://www.ietf.org/mailman/listinfo/tcpm = >>>=20 >>>=20 >>> ------------------------------ >>>=20 >>> End of tcpm Digest, Vol 158, Issue 7 >>> ************************************ >>=20 >>=20 >>=20 >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm = >=20 > --=20 > ________________________________________________________________ > Bob Briscoe http://bobbriscoe.net/ = --Boundary_(ID_IjFhySFtC3x8Z6xr7+9NBQ) Content-type: text/html; charset=utf-8 Content-transfer-encoding: quoted-printable Hi Bob

Thanks for your responses. Please see inline.

On Jun 19, 2017, at 11:38 AM, Bob Briscoe <ietf@bobbriscoe.net>= wrote:

Padma, [re-sending - somehow my email client = missed you off the distr.]

On 17/06/17 17:27, Padma Bhooma = wrote:
Hi Marcelo and = Bob,

I have = reviewed the document draft-bagnulo-tcpm-generalized-ecn-04 and I = am sending my comments below. Overall, I think there is value in working = on these additions or enhancements to RFC 3168 in tcpm working group. I = am willing to review and provide feedback as needed.

  • Section 3.2.1.3 - If the SYN-ACK does = not support AccECN, TCP must conservatively reduce its IW and SHOULD = reduce it to 1 SMSS. This clause is very conservative because AccECN = support can be deployed on servers slowly. Even if both end hosts = support AccECN, there are networks with performance proxies that will = not allow the feedback to propagate correctly. On those networks, TCP = connections with ECT on SYN will always start with 1MSS of IW. I think = this is too conservative and might add multiple RTT to grow the window. = I agree with the value in adding ECT marking to SYN and SYN-ACK in terms = of the latency benefits that might bring to an end = user.
[BB] We have structured the document to just = recommend the preferred approach in the normative spec (section 3), then = discuss the rationale and possible alternatives in section 4. The = sections just before 3.2.1.3 recommend:
  - 3.2.1.1: the client uses ECT optimistically 
  - 3.2.1.2: but the client caches servers = that don't recognize ECT.
This is the "optimistic ECT and cache failures" strategy = discussed in 4.2.1 (tagged as 'S2B').

The requirement to reduce IW to 1SMSS only applies if the = client is adopting this strategy and discovers the server does not = support AccECN. Perhaps we didn't make that clear?

[PB] No I = think this point was clear.


We have given 3 reasons for why this conservatism will rarely = harm performance:

1) With this = strategy, IW=3D1SMSS will only be needed the first time a client = accesses a non-AccECN proxy or server.

2) During transition, this conservative IW=3D1SMSS will only = ever be necessary for the client to server half-connection, not server = to client. 
According to Yuchung Cheng, client Web requests = are rarely greater than 1 segment (no data openly available). Do you = have any data to corroborate (or contradict) this? I think in non-Web = apps, the initial client request would often fit within 1 packet too = (e.g. email, ftp, ssh, scp, etc).

3) Fall-back to 1SMSS is written as SHOULD rather than MUST. = And refers to text later that says under what conditions you can use a = higher IW.

  • I think =E2=80=9Cpessimistic ECT and cache successes=E2=80=9D = strategy described in 4.2.1 sounds like a reasonable = one.
[BB] What's your reasoning for preferring this = one? We recommended "optimistic ECT and cache failures=E2=80=9D.

[PB] I = think, 1MSS may not be enough for clients that are not web based. This = assumption may not apply to connections that multiplex data on a single = connection. Starting at 1MSS will make the client need more RTTs to = reach the congestion window that is needed if the client wants to send = more than an HTTP get. =46rom the client side, the number of servers = they connect to can be large (one-to-many) and using 1MSS on every one = of them can effect performance. When there are performance proxies or = other kind of middle boxes in the network that will not make AccECN work = end-to-end, trying optimistic ECT can potentially have a performance = hit.




  • Section = 3.2.3 ECT marking on Pure Acks - It felt like the document = suggested further discussion on setting ECT on pure Acks, please correct = me if I am wrong here. Setting ECT on pure Acks can increase the load on = an AQM that might already be under load. This is because the number of = Acks can be large and the information conveyed to the peer is redundant = because asks are cumulative. TCP acknowledgements also do not solicit a = response from the peer most of the times. So the chances of not echoing = CE on an Ack is high. 
<= /div>
[BB] Let's take = these points one at a time:
PB: Setting ECT on pure ACKs could increase the load on an = AQM
BB: An AQM = processes packets of all sizes anyway. If pure ACKs are not ECT, it = still has to decide whether to drop each pure ACK. Marking instead of = dropping doesn't make any more work for the AQM.

[PB] Here = by "load" I meant that the queue sizes can grow and increase the = probability of a drop for all traffic. I agree that if the queue sizes = are manageable it will be great to not drop Acks also. 


PB: The information conveyed to the peer is = redundant because ACKs are cumulative.
BB: Just because the ACKnumber info is superseded by the next = ACK does not mean the ECN marking is superseded.

[PB] Yes, = agreed. That is also true for other information like SACK that can be on = an ACK.

PB: TCP = acknowledgements do not solicit a response from the peer most of the = times. So the chances of not echoing CE on an Ack is high.
BB: Just because pure ACKs do not solicit a = specific response (no ACK of an ACK) does not mean the data sender is = not continuing to send data packets, on which ECE can be set (if RFC3168 = feedback) or on which the CE counter can be increased (AccECN = feedback).

RFC3168 actually = says this:
   (One simple possibility would be for the sender =
to reduce its
   congestion window when it receives a pure ACK packet with the CE
   codepoint set).
Consider this pure ACK example with data solely in the = S->C direction, where S is the server.
  * Say 3 in 1000 pure ACKs in the C->S direction are = CE-marked, meaning the C->S marking probability is 0.3%
  * This might be because 0.3% of data = packets in other flows (e.g. a YouTube upload) are being CE-marked as = well.
  * So S needs = to tell C that it has seen 3 CE marked packets (which it will do on the = data packets it is sending, whether with RFC3168 feedback or AccECN = feedback).
  * C is not = (currently) sending any data to S, but it will reduce its cwnd for if it = does start sending data.

[PB] I think, it will be good to make AccECN = feedback a strong requirement for propagating CE marking on Acks also. = Imagine a bottleneck link that is congested due to a large flow and a = few other flows sending Acks alone. Then propagating CE marking on Acks = can make flows that will never send respond to congestion = unnecessarily. 


  • It is also difficult to detect if an Ack is dropped by an = incompatible middle box because of ECT marking on it since we do not = retransmit Acks.. So the fallback mechanisms will be limited. 
<= /div>
[BB] You're correct = in all respects here. Nonetheless, I have three responses:
  * We have been doing millions of = measurements over fixed and mobile networks, using a machine we control = on both sides and checking a sent ECT packet is also received. So far, = we have not seen any difference in the treatment of any control packet = if set to ECT vs not-ECT. 
  * Section 6.1.4 of = RFC3168 hinted that in future pure = ACKs might be set to ECT. So if a security middlebox is trying to = enforce RFC3168, it still might allow ECT pure ACKs to pass.
  * Nonetheless, if there were a middlebox = that dropped ECT pure ACKs, you are right that it could black-hole all = ECT pure ACKs and stall a connection. And there would be no easy way to = detect the specific cause of the problem and stop setting ECT on pure = ACKs. 
  * We should at least say that if = fall-back has to be used because ECT SYNs or SYN-ACKs are not getting = through, then ECT ought not to be used on pure ACKs either.

[PB] Yes, = that will be a good addition to the fallback mechanisms.


This is a good reason for why this protocol is = experimental. However, given we have not so far found this problem in = practice, I think it's OK to go ahead. But I agree that we should note = that this is an open issue. 

  • In Section 4.4.1 (Cwnd response to CE-marking on Pure Acks), = the document says that we can echo a CE received on a pure ack on a data = segment that will be sent later. In general, I think any congestion = notification is relevant only for a short period of time probably in the = order of a typical RTT. Once that time window passes, it may not be = correct to respond to a delayed congestion notification. So echoing CE = from a pure Ack on a data segment sent much later may not be the correct = thing to do.
[BB] This is true. 
However, this point applies generally to idle = periods, not just when pure ACKs are marked. TCP can always enter an = idle period just after a loss or CE mark is received, then if later the = sender has something to send, cwnd will be lower. Cwnd is already = reduced exponentially during an idle period. 

This is all part of the fairly arbitrary rules = on how to evolve cwnd during an idle period. Nonetheless, while idling, = I think it is sensible to reduce cwnd more, if more of any pure ACKs = sent during the idle period are picking up congestion markings. I don't = think we should recommend the converse: i.e. if the congestion was a = long time ago, we should not recommend that cwnd can be increased = again.

[PB] Yes, I = agree. It might be  a good idea to refer to work on idle periods = here because this connection was not obvious to me :)


However, this is an area where I think = implementers should be allowed to experiment, and I think the specs = allow enough flexibility to do so.



  • Section = 3.2.4 Window Probe -= Adding ECT to window probes is really good because this traffic is not = too large on any connection and it requires the peer to respond so that = there is a way to echo the CE marking. One modification that might be =                   worth discussing is to = require congestion response to CE marking on a window probe only when = the receive window is opened. I will try to explain why this is = reasonable. If congestion at the bottleneck link is transient, then = lowering the congestion window in response to CE on a window probe that = does not open the receive window might not be necessary because there = won=E2=80=99t be any data sent afterwards. This can actually happen = multiple times on a connection because a connection can go on for a long = time sending multiple window probes when the peer does not open the = window. So reducing congestion window only when the receive window is = opened as a response to CE seems to be accurate in terms of timing and = reaction to congestion = notification.
[BB] On the other hand, if the window was = constrained solely because the receive window was low and there had been = a CE mark on a window probe many round trips ago, but not on more recent = window probes, it would not be correct to reduce cwnd such a long time = after the congestion had occurred.

I= think it would be better to reduce cwnd immediately there is a CE on a = window probe, increase cwnd as normal for every non-CE-marked window = probe (even if rwnd is still the limiting factor). But also rely on cwnd = validation so that cwnd cannot grow excessively if it is not being = used.

[PB] I = think, it will be good to have some clarifying text here. Both the = points that I made above (about Section 3.2.4 and Section 4.4.1) are = kind of related to connections that see CE marking on control packets = but do not have a lot of data to send or they are limited by receive = window. The mechanisms for maintaining congestion window correctly when = a CE marking is received in these scenarios is not well documented in = RFC 3168 or in this draft. I agree that there are congestion window = validation mechanisms (RFC 7661) that might apply here. So it will be = good to give some recommendation here.



  • Section = 3.2.7 Retransmissions - If a connection = doesn=E2=80=99t set ECT on a SYN because it does not support AccECN = feedback (due to fallback mechanisms or something else), then the first = data packet will be the first packet on a connection with ECT marking on = it. If it is dropped, sending retransmissions without ECT might make it = go through if there is a middle box that incorrectly drops packets with = ECT marking. I think, this detection and fallback mechanism must be = somehow included in the                   proposal to mark = retransmissions with = ECT.
[BB] Good point. I had figured that fall-back = only needed to be considered for the SYN or SYN-ACK. But you're right = that, if the SYN is not-ECT, fall-back might be needed later (altho, as = already mentioned, we have not seen a need in measurements so far). This = will generally only apply to the C->S half-connection. 

This is a general point about fall-back that = happens to be noticed when both data and retransmissions fail to get = through. So I think we ought to add a general point about fall-back as a = new subsection of section 3, rather than writing this in the = retransmissions subjection. I propose this text:
3.2.8 = General Fall-Back

Consider a host that has = sent the first packet on a half-connection (SYN or SYN/ACK) without ECT = set and it has been acknowledged. If this host's retransmission timer = expires more than once for all subsequent packet(s) it sends with ECT = set, it SHOULD retransmit the packet(s) with not-ECT set. If these = not-ECT packet(s) are acknowledged without any further losses, it is = RECOMMENDED that the host disables setting ECT on all subsequent packets = of the half-connection. It could also cache this failure.


[PB] Yes, = this is good.




Another point to note is that a = connection should be already in recovery and must have adjusted it=E2=80=99= s congestion window before sending a retransmission because it detected = loss. If it further detects that there was CE marking on a retransmitted = packet then it is not clear if it needs to adjust the congestion window = again. Adding some clarification here will be = good.
[BB] Yes. We already say:
  =
 If the TCP sender receives feedback that a retransmitted packet was
   CE-marked, it will react as it would to any feedback of CE-marking on
   a data packet.
Do you have a = suggestion for clearer text? Perhaps:
   If the TCP sender receives =
feedback that a retransmitted packet was
   CE-marked, it will react as it would to any feedback of CE-marking on
   a data packet, in addition to its original reaction to the loss that=20=

   caused the retransmission.

RFC5681 already says:
  =
 Loss in two successive windows of data, or the loss of a
   retransmission, should be taken as two indications of congestion and,
   therefore, cwnd (and ssthresh) MUST be lowered twice in this =
case.
It's hard to be = more specific because we didn't want to contradict other congestion = control schemes (e.g. some respond to at least one mark per RTT, others = respond to the extent of CE marking).

[PB] I agree. I did not fully grasp that text. I = think this is good.




  • Tail loss probe - I think it will also = be useful to include some text about CE marking on probe packets that a = connection might send in response to tail loss (draft-dukkipati-tcpm-tcp-loss-probe-01.txt).
[BB] Well, I would like to resist mission creep. = The scope of our draft is intended to be about setting ECT on packets = where it was previously prohibited.

We have included interactions with SCTP, TFO and IW10 in = "5.  Interaction = with popular variants or derivatives of TCP"= because they have been published and can no longer be easily = changed.

For TLP, it's not = even adopted in TCP yet (although I'm sure it is widely used). So I = think it's up to the authors of this draft to say whether ECT should be = set on a TLP and what the response to a CE-marked TLP should = be.

[PB] Ok, = sounds good.




  • Implementation or = deployment related comments - The document refers to other = drafts or experimental RFCs as possible actions that can be taken in = several scenarios. For example AccECN, RFC 5690, RFC 7567 etc,. Even = though implementing and deploying these specifications is possible, they = may not be implemented unless these specifications are tightly bound = together. A casual reader might understand that implementing multiple of = these RFCS will make the system work well. But for someone to implement = and deploy these specifications, it is not clear if some or all of these = implementations will need to be supported. It will be good to make a = recommendation for the minimum set of specifications that need to be = implemented =E2=80=94 may be after some more = discussion.
[BB] If my co-author agrees, we can do this. I = would recommend the following complements (both normatively = referenced): 
* AccECN 
* RFC5691 (robustness to blind in-window = attacks).

As a reciprocal = recommendation, currently, the Intro to the AccECN draft says:
  =
 It is likely (but not required) that the AccECN protocol will be
   implemented along with the following experimental additions to the
   TCP-ECN protocol: ECN-capable TCP control packets and retransmissions
   [I-D.bagnulo-tcpm-generalized-ecn], which includes the =
ECN-capable
   SYN-ACK experiment [RFC5562]; and testing =
receiver non-compliance
   [I-D.moncaster-tcpm-rcv-cheat].


The following are good, but I don't think they = qualify as complementary to ECN++:
*= RFC5690 (ACKcc). It is merely optional and "not = incompatible".
* Similarly for TFO = and IW10. Optional but not incompatible.
*= RFC7567 is about AQM in the network, so I don't it would help an = implementer to say it is complementary, as host implementers cannot = control where their implementation is used.
* Originally we were going to recommend RFC5562 = (ECN+ i.e. ECT on SYN-ACK packets), but once we realized it was = over-conservative, we wrote a less conservative alternative directly = into this ECN++ draft.

[PB] Are there any changes needed on the AQM side = in the network to support CE marking on control packets? I do not think = so but it will be good to get a clarification.



More generally, I know some people are starting = to get really confused over how to put together all the piecemeal = modifications to ECN. I think that would require an informational "ECN = roadmap" draft. No promises, but I guess I am someone who would be = well-placed to know what to write in such a draft.


[PB] Yes, = this is true, especially with the latest experimentation around RFC = 3168. It will be good to have an ECN roadmap.



  • Fallback mechanisms - The document also = discusses several fallback mechanisms to handle incompatibilities in the = network. If we want implementations to consider these cases, it will be = useful to formalize these detection and fallback mechanisms. I found = that some of these mechanisms are being discussed in section 4 which was = tagged as informative.

[BB] I have just checked, and I cannot find any = case where there is fall-back text in section 4 that ought to be = normative. If you found any, pls say where. We tried to ensure that the = recommended approach was always in section 3, even if section 4 = discussed (then rejected) alternatives.

[PB] Ok. Some measurements in the field will help = to support the need for these fallback mechanisms. I wonder if there is = a way to make them as "strong recommendations=E2=80=9D so that the = implementors do not think of them as optional.


Overall, the document is = written well and discusses multiple aspects of the proposed changes = both on the end hosts and in the network. It is useful to have = discussions on the proposed changes and to drive measurements that are = needed to collect data to support or validate some of the assumptions = made.

[BB] Thanks. 

In summary, as this conversation progresses, we = might agree further changes. However, so far I have queued up the = following list of changes to the text to address your points:
* Intro: Recommend complementary RFCs or = drafts
* 3.2.1.3: Clarify = that using IW=3D1SMSS only applies when using the strategies recommended = in the previous two sections.
*= When fall-back due to ECT on SYN (3.2.1.4) or SYN-ACK (3.2.2.3), = consider disabling ECT on other control packets (esp. pure = ACKs).
* Add detection of = black-holing of pure ACKs as an open issue (hence why we have to take = the approach in the previous bullet)
*= Add extra section on general fall-back if no ECT packet has ever been = ack'd
* And we will = certainly acknowledge your contribution, and I hope you will continue to = track changes to this draft carefully and let us know if you have = implementation experience - thank you.

Sounds good. Thank you!

Padma



Bob


Thanks,
Padma




  1. Working group = acceptance call
     draft-bagnulo-tcpm-generalized-ec= n-04
     (Scharf, Michael (Nokia = - DE/Stuttgart))


---------------------------------------------------------------= -------

Message: 1
Date: Fri, = 16 Jun 2017 06:06:43 +0000
From: "Scharf, Michael (Nokia - = DE/Stuttgart)"
<michael.scharf@nokia.com>
To: "tcpm@ietf.org" <tcpm@ietf.org>
Cc: "tcpm-chairs@ietf.org" <tcpm-chairs@ietf.org>
Subject: [tcpm] Working group acceptance call
= draft-bagnulo-tcpm-generalized-ecn-04
Message-ID:
= <AM5PR0701MB2547FBCDE61B1757560F217993C10@AM5PR070= 1MB2547.eurprd07.prod.outlook.com>

Content-Type: text/plain; charset=3D"us-ascii"

Hi all,

As = requested by the authors, this e-mail starts a working group acceptance = call for draft-bagnulo-tcpm-generalized-ecn-04, which will run on the = list until June 30.

The proposal is to add = a new milestone to the  TCPM charter

 Submit document on adding Explicit Congestion = Notification (ECN) to TCP Control Packets to the IESG for publication as = Experimental RFC

and to use = draft-bagnulo-tcpm-generalized-ecn as a starting point.

If you believe that TCPM should work on a document in this = space, and in particular if you are willing to review it, please reply = to this e-mails. Please also speak up if you have any concerns or = objections.

Thanks

Michael
-------------- next part = --------------
An HTML attachment was scrubbed...
URL: <https://mailarchive.ietf.org/arch/browse/tcpm/att= achments/20170616/151f93e9/attachment.html>

------------------------------

Subject: Digest Footer

_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/m= ailman/listinfo/tcpm


------------------------------

End= of tcpm Digest, Vol 158, Issue 7
************************************



_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/m=
ailman/listinfo/tcpm


--=20
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/

= --Boundary_(ID_IjFhySFtC3x8Z6xr7+9NBQ)-- From nobody Wed Jun 28 09:45:06 2017 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 44754129B7E for ; Wed, 28 Jun 2017 09:45:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AOg0xrWFUcBb for ; Wed, 28 Jun 2017 09:45:02 -0700 (PDT) Received: from mail-ua0-x229.google.com (mail-ua0-x229.google.com [IPv6:2607:f8b0:400c:c08::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E49A41200B9 for ; Wed, 28 Jun 2017 09:45:01 -0700 (PDT) Received: by mail-ua0-x229.google.com with SMTP id z22so41497791uah.1 for ; Wed, 28 Jun 2017 09:45:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=6/U+Cf/MVgAUeyqCtwCldPy0sLVkXZrojOcdtFJ0G7M=; b=c09DT1vxHOn5ngf18M63ADKRkkrIjOgz+sHHjY61lUlqZ2+SpUgH6Ephj+65DR6FSF 2JLGeJpW138odLGv/qKSVxQeVqv8FM8v29N9nVzcHYPfGdQ4v9ECopMJnc6mKcLiAYex YOItgS3YvtekIywHmRvA60/yykoVuM4NhqrIb4NF9QHQZULqsML024OsBtje7F3KsZcU Bk3UXvbATq25cMRviQ7boeypkYSAjhGnHqrZTw1PSGHMIiUogj2WZHI4MOOitwkK7g6m smmNCjlsCHg+np2JTMw4HfISrUQrXH+yk5St8OQXycSdz4fy8xbeK7QdFtYNn5vauR5c Bz1w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=6/U+Cf/MVgAUeyqCtwCldPy0sLVkXZrojOcdtFJ0G7M=; b=ZzMM6AM3U/xGaptUn9c55B/oFSpJOBT4480Z6PE4RzwgnBoutxlzy9/SA3n1THFLyE eLeLompZSBRXN+x1H6WKvKAP4oVzew4Lq1y60esjp43zURJO9U/erhAVxTbZzbfhZSGg K/5J4VV4olDTw0Ks9S1NolqfrAtS5FjYd03C5RcZ5HJY88niL9o/F9ryKIyI8hhWjbEH LG2vicUMq/l9padLU3d/S5GtQHZjVI2GCZfCsbeG+p+9ks8tYwZlOzeIzXa3b+Sb4tr6 7B46L5VibyDzhzpoCf/nnANeqUbbakrioqFUswlOYJJ0aNpJWfCcF5jdt6xHkWn5a7ln dm/A== X-Gm-Message-State: AKS2vOx0mSSEa7Vxb0ga/3mDRLmAblFAOocNxabF5D75o43JVyrj7jhp /prOgBTQEf1W07w7rbhCiFWCDJkId9fD X-Received: by 10.176.76.96 with SMTP id d32mr5848613uag.4.1498668300835; Wed, 28 Jun 2017 09:45:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.21.147 with HTTP; Wed, 28 Jun 2017 09:45:00 -0700 (PDT) From: Wei Wang Date: Wed, 28 Jun 2017 09:45:00 -0700 Message-ID: To: "tcpm-chairs@ietf.org" Cc: "tcpm@ietf.org" , "Scharf, Michael (Nokia - DE/Stuttgart)" Content-Type: multipart/alternative; boundary="f40304361536b58e6e055307e7d3" Archived-At: Subject: Re: [tcpm] IETF 99 agenda requests X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jun 2017 16:45:04 -0000 --f40304361536b58e6e055307e7d3 Content-Type: text/plain; charset="UTF-8" Hi, I would like to request a slot in the TCPM session: * Title / Draft: TCP Low Latency Option (https://tools.ietf.org/html/ draft-wang-tcpm-low-latency-opt-00) * Presenter: Wei Wang * Total time (including Q/A): 20min Thanks. Wei On Wed, Jun 28, 2017 at 7:36 AM, Scharf, Michael (Nokia - DE/Stuttgart) < michael.scharf@nokia.com> wrote: > Hi all, > > We have our usual 2.5h slot in Prague. Please send slot requests for the > TCPM session to the chairs by the end of the day on Monday, July 3, > indicating: > > * Title / draft name > * Presenter > * Total time (including Q/A) > > As TCPM meets in the first slot on Monday, we'll need slides for > presentation by Saturday, July 15. > > Thanks > > Michael > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > --f40304361536b58e6e055307e7d3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

I would like to request a slot in the TCPM sess= ion:

* Title / Draft: TCP Low Latency Option (http= s://tools.ietf.org/html/draft-wang-tcpm-low-latency-opt-00)* Presenter: Wei Wang
* Total time (including Q/A): 20min

Thank= s.
Wei

On Wed, = Jun 28, 2017 at 7:36 AM, Scharf, Michael (Nokia - DE/Stuttgart) <= michael.scharf@nokia.com> wrote:
Hi all,

We have our usual 2.5h slot in Prague.=C2=A0 Please send slot requests for = the TCPM session to the chairs by the end of the day on Monday, July 3, ind= icating:

* Title / draft name
* Presenter
* Total time (including Q/A)

As TCPM meets in the first slot on Monday, we'll need slides for presen= tation by Saturday, July 15.

Thanks

Michael

_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm

--f40304361536b58e6e055307e7d3-- From nobody Wed Jun 28 10:57:17 2017 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 7AAE8127078; Wed, 28 Jun 2017 10:57:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E3fa6S4THkjH; Wed, 28 Jun 2017 10:57:13 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9575B129B94; Wed, 28 Jun 2017 10:57:13 -0700 (PDT) Received: from [128.9.184.234] ([128.9.184.234]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id v5SHuam2005400 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 28 Jun 2017 10:56:37 -0700 (PDT) To: Wei Wang , "tcpm-chairs@ietf.org" Cc: "tcpm@ietf.org" References: From: Joe Touch Message-ID: Date: Wed, 28 Jun 2017 10:56:34 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------85306541D48540A92C0C9487" Content-Language: en-US X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [tcpm] IETF 99 agenda requests X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jun 2017 17:57:15 -0000 This is a multi-part message in MIME format. --------------85306541D48540A92C0C9487 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Wei, You should confirm your request for the TCP Experimental option 0xF990 with IANA. They're FCFS, so you'll probably get it immediately. For future reference, though, you should do that step *before* publishing a value in a draft. Joe On 6/28/2017 9:45 AM, Wei Wang wrote: > Hi, > > I would like to request a slot in the TCPM session: > > * Title / Draft: TCP Low Latency Option > (https://tools.ietf.org/html/draft-wang-tcpm-low-latency-opt-00 > ) > * Presenter: Wei Wang > * Total time (including Q/A): 20min > > Thanks. > Wei > > On Wed, Jun 28, 2017 at 7:36 AM, Scharf, Michael (Nokia - > DE/Stuttgart) > wrote: > > Hi all, > > We have our usual 2.5h slot in Prague. Please send slot requests > for the TCPM session to the chairs by the end of the day on > Monday, July 3, indicating: > > * Title / draft name > * Presenter > * Total time (including Q/A) > > As TCPM meets in the first slot on Monday, we'll need slides for > presentation by Saturday, July 15. > > Thanks > > Michael > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > > > > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm --------------85306541D48540A92C0C9487 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Wei,

You should confirm your request for the TCP Experimental option 0xF990 with IANA. They're FCFS, so you'll probably get it immediately.

For future reference, though, you should do that step *before* publishing a value in a draft.

Joe


On 6/28/2017 9:45 AM, Wei Wang wrote:
Hi,

I would like to request a slot in the TCPM session:

* Title / Draft: TCP Low Latency Option (https://tools.ietf.org/html/draft-wang-tcpm-low-latency-opt-00)
* Presenter: Wei Wang
* Total time (including Q/A): 20min

Thanks.
Wei

On Wed, Jun 28, 2017 at 7:36 AM, Scharf, Michael (Nokia - DE/Stuttgart) <michael.scharf@nokia.com> wrote:
Hi all,

We have our usual 2.5h slot in Prague.  Please send slot requests for the TCPM session to the chairs by the end of the day on Monday, July 3, indicating:

* Title / draft name
* Presenter
* Total time (including Q/A)

As TCPM meets in the first slot on Monday, we'll need slides for presentation by Saturday, July 15.

Thanks

Michael

_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm



_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm

--------------85306541D48540A92C0C9487-- From nobody Thu Jun 29 09:51:20 2017 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 ED7DC12EC44 for ; Thu, 29 Jun 2017 09:51:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XHwLMUnDBWkO for ; Thu, 29 Jun 2017 09:51:15 -0700 (PDT) Received: from mail-ua0-x236.google.com (mail-ua0-x236.google.com [IPv6:2607:f8b0:400c:c08::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 98A5F12EC60 for ; Thu, 29 Jun 2017 09:51:15 -0700 (PDT) Received: by mail-ua0-x236.google.com with SMTP id w19so39899180uac.0 for ; Thu, 29 Jun 2017 09:51:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=75jyzM1ojBq7MMKrnIPqKT2SSPAJOm+4U4FAfoLYKKU=; b=qgzeaGg3aOji08Dq1Dfa0VGtrbTM6+qhlaIORjS+A3osMSNJiJWyDLz7D5U04oVLWq enSdrWcdLo9UQl7ZQHkifg6cJIHIgly9Fp3EO9NiXZIky+N8TmgL6Gyx2VLo7GnuHKAh EqXQXNiEpXEvgqEQSz055HLVc/vW+KMnt3D+R7BnTqbPS0vlNmfrZJKu6dolE7KjwTJj cXWzftPM91J0Lr8GEjVIDknphOEX+Quv5ZDJkGRtgD3NMXtPkgQv8nlikYc2S2BAhHM5 6UGyfW9NSe6aU7vigsMV7OWXT/DrlMz4MkdBtKX39WXGkob4sYEnhBx3A/y2hEfhJIbT Ci1g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=75jyzM1ojBq7MMKrnIPqKT2SSPAJOm+4U4FAfoLYKKU=; b=sQ3Ddv0YnuqRxKHfVXycK4ZgTEwrnOjPV7AZhkJnJeSRpQMEb/Ah9NlE+/Th7WYwDr wmbJk02yqd6vy/bkaxvINBoOeBQ/1BZMQqIobUQOzHhL31rv9loQbfljdCEJsJPcpKbl BVp7uzWL8EziFOqgvbc3WQVM5kEo8PINMtosrB8Lz7Ibw2VUTwkO2gXEqo3muIHUbM7D 7X0GCZY6be5cx70Ek6ieyzFrP82gRQ+2eGwmVbbNd2mRC4DretUMixELSvAraJNp9lGP MRPzXnwFP5dx4/9erpT+ARFvYdIgkqiVFs5dde/C49QHojjo73EVi+jn15jCRkt6W9/p wFNA== X-Gm-Message-State: AKS2vOyfX009BD1tmgajyW2Efl94gc9Rr9FQ6yax9Hd1av5PInFxSFkj Z4LDdTfO0DYY9fLA/ZpASuTVzHPFr/oni8CI5g== X-Received: by 10.176.84.3 with SMTP id n3mr10762998uaa.49.1498755074566; Thu, 29 Jun 2017 09:51:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.21.147 with HTTP; Thu, 29 Jun 2017 09:51:14 -0700 (PDT) In-Reply-To: References: From: Wei Wang Date: Thu, 29 Jun 2017 09:51:14 -0700 Message-ID: To: Joe Touch Cc: "tcpm-chairs@ietf.org" , "tcpm@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c1b0e2cd3915705531c1b4e" Archived-At: Subject: Re: [tcpm] IETF 99 agenda requests X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jun 2017 16:51:18 -0000 --94eb2c1b0e2cd3915705531c1b4e Content-Type: text/plain; charset="UTF-8" Thanks Joe for this info. I just generated a request on IANA General request for assignment webpage to request for the use of the TCP Experimental option 0xF990. On Wed, Jun 28, 2017 at 10:56 AM, Joe Touch wrote: > Wei, > > You should confirm your request for the TCP Experimental option 0xF990 > with IANA. They're FCFS, so you'll probably get it immediately. > > For future reference, though, you should do that step *before* publishing > a value in a draft. > > Joe > > On 6/28/2017 9:45 AM, Wei Wang wrote: > > Hi, > > I would like to request a slot in the TCPM session: > > * Title / Draft: TCP Low Latency Option (https://tools.ietf.org/html/d > raft-wang-tcpm-low-latency-opt-00) > * Presenter: Wei Wang > * Total time (including Q/A): 20min > > Thanks. > Wei > > On Wed, Jun 28, 2017 at 7:36 AM, Scharf, Michael (Nokia - DE/Stuttgart) < > michael.scharf@nokia.com> wrote: > >> Hi all, >> >> We have our usual 2.5h slot in Prague. Please send slot requests for the >> TCPM session to the chairs by the end of the day on Monday, July 3, >> indicating: >> >> * Title / draft name >> * Presenter >> * Total time (including Q/A) >> >> As TCPM meets in the first slot on Monday, we'll need slides for >> presentation by Saturday, July 15. >> >> Thanks >> >> Michael >> >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm >> > > > > _______________________________________________ > tcpm mailing listtcpm@ietf.orghttps://www.ietf.org/mailman/listinfo/tcpm > > > --94eb2c1b0e2cd3915705531c1b4e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks Joe for this info.
I just generated a request o= n IANA General request for assignment webpage to request for the use of the= =C2=A0TCP Experimental option 0xF990.

On = Wed, Jun 28, 2017 at 10:56 AM, Joe Touch <touch@isi.edu> wrote:<= br>
=20 =20 =20

Wei,

You should confirm your request for the TCP Experimental option 0xF990 with IANA. They're FCFS, so you'll probably get it immediately.

For future reference, though, you should do that step *before* publishing a value in a draft.

Joe


On 6/28/2017 9:45 A= M, Wei Wang wrote:
Hi,

I would like to request a slot in the TCPM session:

* Title / Draft: TCP Low Latency Option (https://= tools.ietf.org/html/draft-wang-tcpm-low-latency-opt-00)
* Presenter: Wei Wang
* Total time (including Q/A): 20min

Thanks.
Wei

On Wed, Jun 28, 2017 at 7:36 AM, Scharf, Michael (Nokia - DE/Stuttgart) <michael.scharf@= nokia.com> wrote:
Hi all,

We have our usual 2.5h slot in Prague.=C2=A0 Please send slot requests for the TCPM session to the chairs by the end of the day on Monday, July 3, indicating:

* Title / draft name
* Presenter
* Total time (including Q/A)

As TCPM meets in the first slot on Monday, we'll need slides for presentation by Saturday, July 15.

Thanks

Michael

_______________________________________________
tcpm mailing list
tcpm@ietf.= org
https://www.ietf.org/mailman/listinfo/t= cpm



_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mai=
lman/listinfo/tcpm


--94eb2c1b0e2cd3915705531c1b4e-- From nobody Thu Jun 29 15:58:50 2017 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 55309129AD2 for ; Thu, 29 Jun 2017 15:58:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dell.com header.b=RI97z4wK; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=emc.com header.b=FnPs3Qj/ Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sYwQ5QDw3-UC for ; Thu, 29 Jun 2017 15:58:46 -0700 (PDT) Received: from esa7.dell-outbound.iphmx.com (esa7.dell-outbound.iphmx.com [68.232.153.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 96886128C81 for ; Thu, 29 Jun 2017 15:58:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dell.com; i=@dell.com; q=dns/txt; s=smtpout; t=1498777033; x=1530313033; h=from:cc:to:subject:date:message-id:mime-version; bh=D02fsM6MCP7RIbWMUBU52JYRUIOS+3qZ6OJ4UWHv090=; b=RI97z4wKpTDmOLQzGJE5y3cVeCQZ2HadDPXl8HntFoAhiDPmsu5/QLjJ 6kXqyCGU3MSdbZsI/n7RTTj10xTpbz7ClwKYaEZDxyawtespjmpCZUHjx sVrYNspYCGWaacL8If7WAi2qZcsuhlAUx4c7J1HzLxGjvdSeZhHPKT9f0 I=; Received: from esa2.dell-outbound2.iphmx.com ([68.232.153.202]) by esa7.dell-outbound.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 29 Jun 2017 17:57:13 -0500 From: "Black, David" Cc: "Black, David" Received: from mailuogwhop.emc.com ([168.159.213.141]) by esa2.dell-outbound2.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 30 Jun 2017 04:51:28 +0600 Received: from maildlpprd01.lss.emc.com (maildlpprd01.lss.emc.com [10.253.24.33]) by mailuogwprd01.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id v5TMwixH019977 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 29 Jun 2017 18:58:45 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd01.lss.emc.com v5TMwixH019977 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1498777125; bh=8FATZ5erHIz1UiSy8Ee3CHnT3l4=; h=From:To:CC:Subject:Date:Message-ID:Content-Type:MIME-Version; b=FnPs3Qj/6i3M5Umgxl+i9r1iZPs5HxSeligB7/4m5LLwZtOiUqgWOkeyzzN/42yQn O5BMYGThiNJbPgtbThMzKPxvmQ7GJAh7IffvQVKXg88U+D+G60pgL1W3CSwrq3ji8T u7/SIm6O4feo/rdHGnDBk+TXFLWriN9ahajNpABo= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd01.lss.emc.com v5TMwixH019977 Received: from mailusrhubprd53.lss.emc.com (mailusrhubprd53.lss.emc.com [10.106.48.18]) by maildlpprd01.lss.emc.com (RSA Interceptor) for ; Thu, 29 Jun 2017 18:57:43 -0400 Received: from MXHUB301.corp.emc.com (MXHUB301.corp.emc.com [10.146.3.27]) by mailusrhubprd53.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id v5TMwWuu011221 (version=TLSv1.2 cipher=AES128-SHA256 bits=128 verify=FAIL) for ; Thu, 29 Jun 2017 18:58:33 -0400 Received: from MX307CL04.corp.emc.com ([fe80::849f:5da2:11b:4385]) by MXHUB301.corp.emc.com ([10.146.3.27]) with mapi id 14.03.0352.000; Thu, 29 Jun 2017 18:58:30 -0400 To: "tcpm@ietf.org" Thread-Topic: Re: Working group acceptance call draft-bagnulo-tcpm-generalized-ecn-04 Thread-Index: AdLxKu0P2/GioKjwTUGg3xtw9QVj1A== Date: Thu, 29 Jun 2017 22:58:30 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.238.44.149] Content-Type: multipart/alternative; boundary="_000_CE03DB3D7B45C245BCA0D243277949362FB54B27MX307CL04corpem_" MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd53.lss.emc.com X-RSA-Classifications: public, GIS Solicitation Archived-At: Subject: Re: [tcpm] Working group acceptance call draft-bagnulo-tcpm-generalized-ecn-04 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jun 2017 22:58:48 -0000 --_000_CE03DB3D7B45C245BCA0D243277949362FB54B27MX307CL04corpem_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable > As requested by the authors, this e-mail starts a working group acceptanc= e call for draft-bagnulo-tcpm-generalized-ecn-04, which will run on the lis= t until June 30. > > The proposal is to add a new milestone to the TCPM charter > > Submit document on adding Explicit Congestion Notification (ECN) to TC= P Control Packets to the IESG for publication as Experimental RFC > > and to use draft-bagnulo-tcpm-generalized-ecn as a starting point. > > If you believe that TCPM should work on a document in this space, and in = particular if you are willing to review it, please reply to this e-mails. P= lease also speak up if you have any concerns or objections. I support TCPM work in this space - I write as an individual and note the e= xistence of draft-ietf-tsvwg-ecn-experimentation, one of whose goals is to = enable experimental work in this space. TCPM is the appropriate WG for thi= s TCP work, and draft-bagnulo-tcpm-generalized-ecn is a fine starting point= . Thanks, --David ---------------------------------------------------------------- David L. Black, Distinguished Engineer Dell EMC, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 Mobile: +1 (978) 394-7754 David.Black@dell.com ---------------------------------------------------------------- --_000_CE03DB3D7B45C245BCA0D243277949362FB54B27MX307CL04corpem_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

> As requested by the authors, this e-mail starts= a working group acceptance call for draft-bagnulo-tcpm-generalized-ecn-04,= which will run on the list until June 30.

> 

> The proposal is to add a new milestone to the T= CPM charter

> 

>    Submit document on adding Exp= licit Congestion Notification (ECN) to TCP Control Packets to the IESG for = publication as Experimental RFC

> 

> and to use draft-bagnulo-tcpm-generalized-ecn a= s a starting point.

>

> If you believe that TCPM should work on a docum= ent in this space, and in particular if you are willing to review it, pleas= e reply to this e-mails. Please also speak up if you have any concerns or o= bjections.

 

I support TCPM work in this space – I write as= an individual and note the existence of draft-ietf-tsvwg-ecn-experimentati= on, one of whose goals is to enable experimental work in this space.  = TCPM is the appropriate WG for this TCP work, and draft-bagnulo-tcpm-generalized-ecn is a fine starting point.

 

Thanks, --David

----------------------------------------------------= ------------

David L. Black, Distinguished Engineer

Dell EMC, 176 South St., Hopkinton, MA  01748

+1 (508) 293-7953    Mobile: += ;1 (978) 394-7754

David.Black@dell.com

----------------------------------------------------= ------------

 

--_000_CE03DB3D7B45C245BCA0D243277949362FB54B27MX307CL04corpem_--