From nobody Tue Mar 1 02:53:56 2016 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75DEF1B3F5D for ; Tue, 1 Mar 2016 02:53:54 -0800 (PST) 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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GBHeYzlC58ss for ; Tue, 1 Mar 2016 02:53:53 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 11F681B3F54 for ; Tue, 1 Mar 2016 02:53:52 -0800 (PST) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id 92F3580BB6253; Tue, 1 Mar 2016 10:53:48 +0000 (GMT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (fr712usmtp2.zeu.alcatel-lucent.com [135.239.2.42]) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u21AroU4003593 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 1 Mar 2016 10:53:50 GMT Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id u21ArWqx000561 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 1 Mar 2016 11:53:49 +0100 Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.15]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0195.001; Tue, 1 Mar 2016 11:53:39 +0100 From: "Scharf, Michael (Nokia - DE)" To: "mallman@icir.org" , "tcpm@ietf.org Extensions" Thread-Topic: [tcpm] FW: I-D Action: draft-ietf-tcpm-rto-consider-00.txt Thread-Index: AQHRcvmh72SueUa7DE+iNtPMpHUDep9EZdGw Date: Tue, 1 Mar 2016 10:53:38 +0000 Message-ID: <655C07320163294895BBADA28372AF5D486DDDE6@FR712WXCHMBA15.zeu.alcatel-lucent.com> References: <655C07320163294895BBADA28372AF5D4862C817@FR712WXCHMBA15.zeu.alcatel-lucent.com> <63373.1456754452@lawyers.icir.org> In-Reply-To: <63373.1456754452@lawyers.icir.org> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [tcpm] FW: I-D Action: draft-ietf-tcpm-rto-consider-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2016 10:53:54 -0000 Thanks. The new wording addresses my comment. @all: The chairs' plan is to run a WGLC after IETF 95. Unfortunately, TCPM = will not meet during IETF 95, but if there are no further comments we may s= till head towards WGLC as originally planned. In the meantime, please read = the new version and let us know any comments. Note that this document targe= ts BCP status. It is very short and simple to review. Michael -----Original Message----- From: mallman@icir.org [mailto:mallman@icir.org]=20 Sent: Monday, February 29, 2016 3:01 PM To: Scharf, Michael (Nokia - DE) Cc: tcpm@ietf.org Extensions Subject: Re: [tcpm] FW: I-D Action: draft-ietf-tcpm-rto-consider-00.txt=20 > To me, the sentence on page 5 "In such a case a congestion control=20 > action is not required." does not really cover an undo of congestion=20 > control actions once a non-congestion event is detected. But this may=20 > really be nitpicking... I just submitted a new version (-01) that includes a tweaked version of the= text referenced above. I have received no other comments and so this is the only change between -0= 0 and -01. Please advise on next steps. allman From nobody Wed Mar 2 01:39:55 2016 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B266E1AC3F2 for ; Wed, 2 Mar 2016 01:39:53 -0800 (PST) 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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OCErOG76Ua8b for ; Wed, 2 Mar 2016 01:39:51 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-02.alcatel-lucent.com [135.245.210.23]) (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 6F34A1AC3F4 for ; Wed, 2 Mar 2016 01:39:50 -0800 (PST) Received: from fr711umx2.dmz.alcatel-lucent.com (unknown [135.245.210.39]) by Websense Email Security Gateway with ESMTPS id B2E4A25E2AA90 for ; Wed, 2 Mar 2016 09:39:46 +0000 (GMT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (fr711usmtp1.zeu.alcatel-lucent.com [135.239.2.122]) by fr711umx2.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u229dmUa002847 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 2 Mar 2016 09:39:48 GMT Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id u229dlY7026683 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 2 Mar 2016 10:39:48 +0100 Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.15]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.03.0195.001; Wed, 2 Mar 2016 10:39:48 +0100 From: "Scharf, Michael (Nokia - DE)" To: "tcpm@ietf.org Extensions" Thread-Topic: Call for Adoption: TCP Tuning for HTTP Thread-Index: AQHRdEeh16Gz+pebXEm4eXrhOLtjJZ9F4wxAgAADIxA= Date: Wed, 2 Mar 2016 09:39:47 +0000 Message-ID: <655C07320163294895BBADA28372AF5D486E00B7@FR712WXCHMBA15.zeu.alcatel-lucent.com> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.41] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [tcpm] FW: Call for Adoption: TCP Tuning for HTTP X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2016 09:39:53 -0000 I assume this could be of interest to the TCPM community. Michael -----Original Message----- From: Scharf, Michael (Nokia - DE)=20 Sent: Wednesday, March 02, 2016 10:37 AM To: 'Mark Nottingham'; HTTP WG Cc: amankin@verisign.com; Daniel Stenberg Subject: RE: Call for Adoption: TCP Tuning for HTTP The document refers to several TCPM RFCs with experimental status, e.g., in= Section 3. That may have to be taken into account when heading towards BCP= status. Michael (TCPM co-chair) -----Original Message----- From: Mark Nottingham [mailto:mnot@mnot.net]=20 Sent: Wednesday, March 02, 2016 6:47 AM To: HTTP WG Cc: amankin@verisign.com; Daniel Stenberg Subject: Call for Adoption: TCP Tuning for HTTP [ copying Alison as our Transport Tech Advisor ] Daniel has kindly started a document about how HTTP uses TCP, both for /1 a= nd /2: We haven't explicitly discussed this at a meeting, but I have heard interes= t in this topic from a variety of folks. What do people think about adopting this with a target of Best Current Prac= tice? Please comment on-list. Regards, -- Mark Nottingham https://www.mnot.net/ From nobody Wed Mar 2 03:12:13 2016 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E4781AD182 for ; Wed, 2 Mar 2016 03:12:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.207 X-Spam-Level: X-Spam-Status: No, score=-4.207 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kmySTaIugbcT for ; Wed, 2 Mar 2016 03:12:09 -0800 (PST) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id 340451AD17F for ; Wed, 2 Mar 2016 03:12:09 -0800 (PST) Received: from erg.abdn.ac.uk (galactica.erg.abdn.ac.uk [139.133.210.32]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPA id C82921B001AA; Wed, 2 Mar 2016 11:23:18 +0000 (GMT) Received: from 212.159.18.54 (SquirrelMail authenticated user gorry) by erg.abdn.ac.uk with HTTP; Wed, 2 Mar 2016 11:12:07 -0000 Message-ID: In-Reply-To: <655C07320163294895BBADA28372AF5D486E00B7@FR712WXCHMBA15.zeu.alcatel-lucent.com> References: <655C07320163294895BBADA28372AF5D486E00B7@FR712WXCHMBA15.zeu.alcatel-lucent.com> Date: Wed, 2 Mar 2016 11:12:07 -0000 From: gorry@erg.abdn.ac.uk To: "Scharf, Michael (Nokia - DE)" User-Agent: SquirrelMail/1.4.23 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Archived-At: Cc: "tcpm@ietf.org Extensions" Subject: Re: [tcpm] FW: Call for Adoption: TCP Tuning for HTTP X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2016 11:12:12 -0000 I read the previous version, and I think this document needs to be talked about in TCPM. Some people may find it useful to have a document to point toIETF consensus on what to tune in the stack for HTTP. I do think this document needs to be talked about in TCPM. To me there are several parts to this document that appear to encourage a change the default behaviour of TCP. If this is published as a BCP, I think it needs to be aligned to current published RFCs, and describe the trade-offs that need to be considered. A few examples: “2.5. Lower the TCP FIN timeout High connection completion rates will consume ephemeral ports quickly. Lower the time during which connections are in FIN-WAIT-2/ TIME_WAIT states so that they can be purged faster and thus maintain a maximal number of available sockets. The primitives for the assignment of these values were described in [RFC0793], however significantly lower values are commonly used.” - This also has significant impact on the robustness of TCP in the face of deadly and reordering. I wonder, has this been discussed somewhere from a robustness/security perspective? It seems like the proposed BCP text encourages tuning without at the moment any suggestion of safe values. “2.6. Reuse sockets in TIME_WAIT state When running backend servers on a managed, low latency network you might allow the reuse of sockets in TIME_WAIT state for new connections when a protocol complete termination has occurred. There is no RFC that covers this behaviour.” - TIME-WAIT state that prevents delayed segments from one connection instance from interfering with a later one. Applications that are aware of and designed for this behavior can shift maintenance of the TIME-WAIT state to conserve resources by controlling which end closes a TCP connection, etc. Similarly, the current text could encourage a method that could be thought to be unsafe for general Internet deployment, without explaining this. “3.1. TCP Fast Open” - I think a BCP would need to note the experimental status of this RFC. “3.2. Initial Congestion Window” - I think a BCP would need to note the experimental status of this RFC. In addition, I’m concerned about the final sentence: “ IW10 has been reported to perform fairly well even in high volume servers.” - In a BCP, this would sound like a new recommendation, but it seems lot me to be a stronger claim than the RFC itself. There are side effects to raising IW on other traffic crossing slower bottlenecks, and known mitigations, such as pacing. “4.3. Nagle's Algorithm” - True disabling for HTTP is likely to help - However, this remains an option because it has significant performance benefits for low-speed bottlenecks. I think text needs to be clear on the trade-off. It would be nice to state the trade-off. “4.4. Keep-alive” - This maybe is confusing, to me, keep alive in TCP is important to TCP to verify a path is operational, rather than to keep a middle box happy. If it’s the latter, perhaps should likely need to refer to the behave RFCs?? “5.1. Slow Start after Idle Slow-start is one of the algorithms that TCP uses to control congestion inside the network. It is also known as the exponential growth phase. Each TCP connection will start off in slow-start but will also go back to slow-start after a certain amount of idle time. In Linux systems you can prevent the TCP stack from going back to slow-start after idle by settting net.ipv4.tcp_slow_start_after_idle = 0” - And TCPM has just published RFC7661 on this topic. I’m concerned the proposed text doesn’t make the recommendations of the IETF clear. Disabling slow-start-after-idle is possible in a stack, but is there an RFC that shows transport community consensus that we should recommend disabling? or caution about the implications? I’m not quite sure what the presented message is on timers, but again the values described in the IETF series appear not to be noted in the current version. Gorry > I assume this could be of interest to the TCPM community. > > Michael > > -----Original Message----- > From: Scharf, Michael (Nokia - DE) > Sent: Wednesday, March 02, 2016 10:37 AM > To: 'Mark Nottingham'; HTTP WG > Cc: amankin@verisign.com; Daniel Stenberg > Subject: RE: Call for Adoption: TCP Tuning for HTTP > > The document refers to several TCPM RFCs with experimental status, e.g., > in Section 3. That may have to be taken into account when heading towards > BCP status. > > Michael > (TCPM co-chair) > > > -----Original Message----- > From: Mark Nottingham [mailto:mnot@mnot.net] > Sent: Wednesday, March 02, 2016 6:47 AM > To: HTTP WG > Cc: amankin@verisign.com; Daniel Stenberg > Subject: Call for Adoption: TCP Tuning for HTTP > > [ copying Alison as our Transport Tech Advisor ] > > Daniel has kindly started a document about how HTTP uses TCP, both for /1 > and /2: > > > We haven't explicitly discussed this at a meeting, but I have heard > interest in this topic from a variety of folks. > > What do people think about adopting this with a target of Best Current > Practice? > > Please comment on-list. > > Regards, > > -- > Mark Nottingham https://www.mnot.net/ > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > From nobody Wed Mar 2 12:25:35 2016 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B56E1B2F84 for ; Wed, 2 Mar 2016 12:25:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.906 X-Spam-Level: X-Spam-Status: No, score=-6.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.006] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u5-l_eBB92lr for ; Wed, 2 Mar 2016 12:25:32 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 99C2D1B2F83 for ; Wed, 2 Mar 2016 12:25:32 -0800 (PST) Received: from [128.9.184.68] ([128.9.184.68]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id u22KPAAC016052 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 2 Mar 2016 12:25:10 -0800 (PST) To: "Scharf, Michael (Nokia - DE)" , "tcpm@ietf.org Extensions" References: <655C07320163294895BBADA28372AF5D486E00B7@FR712WXCHMBA15.zeu.alcatel-lucent.com> From: Joe Touch Message-ID: <56D74C23.5010705@isi.edu> Date: Wed, 2 Mar 2016 12:25:07 -0800 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <655C07320163294895BBADA28372AF5D486E00B7@FR712WXCHMBA15.zeu.alcatel-lucent.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: touch@isi.edu Subject: Re: [tcpm] FW: Call for Adoption: TCP Tuning for HTTP X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2016 20:25:34 -0000 On 3/2/2016 1:39 AM, Scharf, Michael (Nokia - DE) wrote: > I assume this could be of interest to the TCPM community. I have doubts: - it reads like a Linux manual page All Linux-specific references and commands would need to be moved to an appendix to be useful as an RFC. - this repeats (sometimes correctly, sometimes in error) existing advice J. Heidemann, K. Obraczka, J. Touch, “Modeling the Performance of HTTP Over Several Transport Protocols,” IEEE/ACM Transactions on Networking, V5, N5, Oct. 1997, pp.616-630. T. Faber, J. Touch, and W. Yue, “The TIME-WAIT state in TCP and Its Effect on Busy Servers,” in Proc. IEEE Infocom, 1999, pp. 1573-1583. - it has significant errors TIME-WAIT issues apply to servers, not clients. Nagle has been known to perform poorly for multibyte interactive traffic for a very long time, including not only web traffic but also multi-byte character or keyboard signals. Disabling slow-start after idle is safe only with pacing. Without pacing, the resulting traffic can generate a burst that was never experienced and result in both poor performance for the current connection and potential impact to competing traffic. (those are just a few) Overall, I think a man page might be useful, but this summary isn't useful for the IETF. Joe > -----Original Message----- > From: Scharf, Michael (Nokia - DE) > Sent: Wednesday, March 02, 2016 10:37 AM > To: 'Mark Nottingham'; HTTP WG > Cc: amankin@verisign.com; Daniel Stenberg > Subject: RE: Call for Adoption: TCP Tuning for HTTP > > The document refers to several TCPM RFCs with experimental status, e.g., in Section 3. That may have to be taken into account when heading towards BCP status. > > Michael > (TCPM co-chair) > > > -----Original Message----- > From: Mark Nottingham [mailto:mnot@mnot.net] > Sent: Wednesday, March 02, 2016 6:47 AM > To: HTTP WG > Cc: amankin@verisign.com; Daniel Stenberg > Subject: Call for Adoption: TCP Tuning for HTTP > > [ copying Alison as our Transport Tech Advisor ] > > Daniel has kindly started a document about how HTTP uses TCP, both for /1 and /2: > > > We haven't explicitly discussed this at a meeting, but I have heard interest in this topic from a variety of folks. > > What do people think about adopting this with a target of Best Current Practice? > > Please comment on-list. > > Regards, > > -- > Mark Nottingham https://www.mnot.net/ > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > From nobody Wed Mar 2 12:36:20 2016 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7FF71B2F57 for ; Wed, 2 Mar 2016 12:36:18 -0800 (PST) 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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z0X54dZDinAb for ; Wed, 2 Mar 2016 12:36:13 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-02.alcatel-lucent.com [135.245.210.23]) (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 B69471B2E6E for ; Wed, 2 Mar 2016 12:36:13 -0800 (PST) Received: from fr711umx2.dmz.alcatel-lucent.com (unknown [135.245.210.39]) by Websense Email Security Gateway with ESMTPS id 86EBFA8AEADEA; Wed, 2 Mar 2016 20:36:06 +0000 (GMT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (fr711usmtp1.zeu.alcatel-lucent.com [135.239.2.122]) by fr711umx2.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u22Ka9Xm014525 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 2 Mar 2016 20:36:10 GMT Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id u22Ka97N007583 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 2 Mar 2016 21:36:09 +0100 Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.15]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0195.001; Wed, 2 Mar 2016 21:36:09 +0100 From: "Scharf, Michael (Nokia - DE)" To: EXT Joe Touch , "tcpm@ietf.org Extensions" Thread-Topic: [tcpm] FW: Call for Adoption: TCP Tuning for HTTP Thread-Index: AQHRdEeh16Gz+pebXEm4eXrhOLtjJZ9F4wxAgAADIxCAAKO2gIAAEgIQ Date: Wed, 2 Mar 2016 20:36:08 +0000 Message-ID: <655C07320163294895BBADA28372AF5D486E1D87@FR712WXCHMBA15.zeu.alcatel-lucent.com> References: <655C07320163294895BBADA28372AF5D486E00B7@FR712WXCHMBA15.zeu.alcatel-lucent.com> <56D74C23.5010705@isi.edu> In-Reply-To: <56D74C23.5010705@isi.edu> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.41] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [tcpm] FW: Call for Adoption: TCP Tuning for HTTP X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2016 20:36:19 -0000 For the moment, I suggest to direct specific comments on the I-D to the HTT= Pbis list. I am not at all involved in this document and this adoption call. I just fo= und that e-mail this morning in my inbox. Michael From nobody Thu Mar 3 05:14:31 2016 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE4C51ACD0F for ; Thu, 3 Mar 2016 05:14:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.301 X-Spam-Level: X-Spam-Status: No, score=-2.301 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oOPDone18O2X for ; Thu, 3 Mar 2016 05:14:28 -0800 (PST) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1CB051ACD0E for ; Thu, 3 Mar 2016 05:14:27 -0800 (PST) X-AuditID: c1b4fb30-f79d26d000006389-7d-56d838b18938 Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.183.66]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id B7.71.25481.1B838D65; Thu, 3 Mar 2016 14:14:26 +0100 (CET) Received: from ESESSMB205.ericsson.se ([169.254.5.14]) by ESESSHC016.ericsson.se ([153.88.183.66]) with mapi id 14.03.0248.002; Thu, 3 Mar 2016 14:14:25 +0100 From: Ingemar Johansson S To: "tcpm@ietf.org" Thread-Topic: Question on RFC6298, Managing the RTO Timer and additional lost pakets in Recovery state Thread-Index: AdF1Sy7f2PFSI03WTo2IkJl2NCZHQA== Date: Thu, 3 Mar 2016 13:14:24 +0000 Message-ID: <81564C0D7D4D2A4B9A86C8C7404A13DA43D85BDD@ESESSMB205.ericsson.se> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.147] Content-Type: multipart/alternative; boundary="_000_81564C0D7D4D2A4B9A86C8C7404A13DA43D85BDDESESSMB205erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupgkeLIzCtJLcpLzFFi42KZGbHdSXeTxY0wg3l/OCx2n5vKYrHt5Hwm ByaPJUt+Mnl0HN/AHMAUxWWTkpqTWZZapG+XwJXxasJtxoKTfhUtq1vYGxib3LsYOTkkBEwk OiYtY4SwxSQu3FvP1sXIxSEkcJhR4tul/VDOIkaJUx/7WECq2ARsJFYe+g7WISKgLLH6/gcw m1mgWmLLyh3sILawQLLEtwNXmCBqMiTOvZjBCmHrSUy6dxSsnkVARaL57iywmbwCvhIXT70A 62UUkJW4//0eC8RMcYlbT+YzQVwnILFkz3lmCFtU4uXjf0AzOYBsJYlpW9MgyvMl1r75xQgx UlDi5MwnLBMYhWchmTQLSdksJGUQcT2JG1OnsEHY2hLLFr5mhrB1JWb8O8SCLL6AkX0Vo2hx anFSbrqRkV5qUWZycXF+nl5easkmRmD8HNzy22AH48vnjocYBTgYlXh4N6y4HibEmlhWXJl7 iFGCg1lJhPed4o0wId6UxMqq1KL8+KLSnNTiQ4zSHCxK4rysny6HCQmkJ5akZqemFqQWwWSZ ODilGhiTZ6741Tz37+bvyb2BiqtYzVecnTXzRrv2r2UzeL5G3bUT/y/UasMw19Eo/sike3/P Mj6coGhWzi/LLbFs5V29eQF7U+wbNjLar+J2crDVbCpXfCZ7ubCWr+naOaai8L6q799LJopJ Zs1UspfuerXHwuPLJv9I58MyD783zXOwdnMVneOvG6rEUpyRaKjFXFScCACwAUoNmwIAAA== Archived-At: Cc: Ingemar Johansson S , "end2end-interest@postel.org" Subject: [tcpm] Question on RFC6298, Managing the RTO Timer and additional lost pakets in Recovery state X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2016 13:14:31 -0000 --_000_81564C0D7D4D2A4B9A86C8C7404A13DA43D85BDDESESSMB205erics_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi I am trying to understand the Linux TCP stack and how it rearms the RTO tim= er, in the process I read section 5 in RFC6298. It says quote "(5.3) When an ACK is received that acknowledges new data, re= start the retransmission timer so that it will expire after RTO seconds (fo= r the current value of RTO)." What is the definition of new data ?. The strict interpretation is when SND= .UNA advances, but it can also be that the highest SACKed sequence number i= ncreases. The former case it is more likely that RTO happens. The second question is Linux related. Given that a lost packet puts the sta= ck in Recovery state, the congestion window reduces one step as an effect o= n this. What happens if additional packets are lost when in Recovery state.= I guess the congestion window should decrease more or ?. I am currently porting the Linux TCP stack to fit our Java based system sim= ulator, most things seem to be working but the above leaves me wondering. /Ingemar =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D Ingemar Johansson M.Sc. Master Researcher Ericsson AB Wireless Access Networks Labratoriegr=E4nd 11 971 28, Lule=E5, Sweden Phone +46-1071 43042 SMS/MMS +46-73 078 3289 ingemar.s.johansson@ericsson.com www.ericsson.com "We can be heroes, just for one day" David Bowie =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D --_000_81564C0D7D4D2A4B9A86C8C7404A13DA43D85BDDESESSMB205erics_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi

 

I am trying to understand the L= inux TCP stack and how it rearms the RTO timer, in the process I  read= section 5 in RFC6298.

It says quote “(5.3) When= an ACK is received that acknowledges new data, restart the retransmission = timer so that it will expire after RTO seconds (for the current value of RT= O).”

What is the definition of new d= ata ?. The strict interpretation is when SND.UNA advances, but it can also = be that the highest SACKed sequence number increases. The former case it is= more likely that RTO happens.

 

The second question is Linux re= lated. Given that a lost packet puts the stack in Recovery state, the conge= stion window reduces one step as an effect on this. What happens if additio= nal packets are lost when in Recovery state. I guess the congestion window should decrease more or ?.

 

I am currently porting the Linu= x TCP stack to fit our Java based system simulator, most things seem to be = working but the above leaves me wondering.

 

/Ingemar

 

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

Ingemar Johansson  M.Sc.

Master Researcher

 

Ericsson AB

Wireless Access Networks

Labratoriegr=E4nd 11

971 28, Lule=E5, Sweden

Phone +46-1071 43042

SMS/MMS +46-73 078 3289

ingemar.s.johansson@ericsson.com= =

www.ericsson.com

 

“We can be heroes,

  just for on= e day”
    David Bowie

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

 

--_000_81564C0D7D4D2A4B9A86C8C7404A13DA43D85BDDESESSMB205erics_-- From nobody Thu Mar 3 06:31:39 2016 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F1CC1ACEE0 for ; Thu, 3 Mar 2016 06:31:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.303 X-Spam-Level: X-Spam-Status: No, score=-2.303 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zmMvv6o-CeEA for ; Thu, 3 Mar 2016 06:31:35 -0800 (PST) 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 D75921ACEDD for ; Thu, 3 Mar 2016 06:31:35 -0800 (PST) Received: from lawyers.icir.org (obrien.ICSI.Berkeley.EDU [192.150.187.23]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id u23EVV2d002890; Thu, 3 Mar 2016 06:31:31 -0800 (PST) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 338803B26273; Thu, 3 Mar 2016 09:31:31 -0500 (EST) To: Ingemar Johansson S From: Mark Allman In-Reply-To: <81564C0D7D4D2A4B9A86C8C7404A13DA43D85BDD@ESESSMB205.ericsson.se> Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Can't Get Enough X-URL-0: http://www.icir.org/mallman-files/Document15282.pdf X-URL-1: http://www.icir.org/mallman-files/Document4865.xls MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-------459435943823349593450"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Thu, 03 Mar 2016 09:31:31 -0500 Message-ID: <40707.1457015491@lawyers.icir.org> Sender: mallman@icir.org Archived-At: Cc: "tcpm@ietf.org" , "end2end-interest@postel.org" Subject: Re: [tcpm] Question on RFC6298, Managing the RTO Timer and additional lost pakets in Recovery state X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2016 14:31:37 -0000 --=-------459435943823349593450 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable > It says quote =E2=80=9C(5.3) When an ACK is received that acknowledges new > data, restart the retransmission timer so that it will expire after > RTO seconds (for the current value of RTO).=E2=80=9D >=20 > What is the definition of new data ?. The strict interpretation is > when SND.UNA advances, but it can also be that the highest SACKed > sequence number increases. The former case it is more likely that > RTO happens.=20 Seems like something we should have nailed down in the spec at some point after SACK became widely prevalent. Alas. I think "new data" can be interpreted as "cumulative ACK advances". The spirit of (5.3) is that as long as the connection is making progress---from an application perspective---we can keep the RTO at arms length and so we just keep re-arming it. But, once we have a stall---or even an indication that we might stall---because a packet has been lost then we stop pushing the RTO off. > The second question is Linux related. Given that a lost packet > puts the stack in Recovery state, the congestion window reduces > one step as an effect on this. What happens if additional packets > are lost when in Recovery state. I guess the congestion window > should decrease more or ?. First, this is a more generic answer, I have no idea what linux does. I can't tell which of two cases you are talking about here. Let's say you send 20 packets into the network in some window. Now, the cases ... (1) We lose packets 1, 5, 13 and 17. I.e., multiple packets are lost from a single transmission window. So, retransmitting packet 1 puts us in recovery and causes congestion control action. I believe that the fact that packets 5, 13 and 17 are also lost does not mean we should react to congestion again. E.g., RFC 6675 calls for a single CC response regardless of how many packets are lost from a window of data. (2) We lose packets 1, 5, 13 and 17 and also the retransmit of packet 17. So, we lose 4 packets from the first single transmission window. This triggers one CC response. But, the retransmit of packet 17 is from a subsequent transmission window, indicating that perhaps we haven't yet done enough to relieve the congestion. Conservativeness would likely suggest that in this case, yes, we should take another CC action. And, e.g., RFC 6675 forces this second CC action by being unable to cope with lost retransmissions. Rather, in this case we fall back to the RTO which means another CC response. I am not claiming RFC 6675 is the right approach here. Just noting what some spec does. We left it this way because we didn't feel that the complexity of dealing with this case was really generally worth it. But, one could envision a different algorithm making a different choice. I hope that helps! allman =2D- http://www.icir.org/mallman/ --=-------459435943823349593450 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlbYSsIACgkQWyrrWs4yIs7IMgCfQiZ3ammqm3C++xVxzSc3WFL8 rnoAn1ulJKJUvdQTed+bXmRHcGMCyJpT =Dzot -----END PGP SIGNATURE----- --=-------459435943823349593450-- From nobody Thu Mar 3 06:54:10 2016 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0751D1AD0C1 for ; Thu, 3 Mar 2016 06:54:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.906 X-Spam-Level: X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.006] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5pIPJY4ONHDB for ; Thu, 3 Mar 2016 06:54:06 -0800 (PST) Received: from mail-out4.uio.no (mail-out4.uio.no [IPv6:2001:700:100:10::15]) (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 8A07A1AD0C0 for ; Thu, 3 Mar 2016 06:54:06 -0800 (PST) Received: from mail-mx2.uio.no ([129.240.10.30]) by mail-out4.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1abUdf-0000gz-L3; Thu, 03 Mar 2016 15:54:03 +0100 Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx2.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.80) (envelope-from ) id 1abUdf-0002EH-A5; Thu, 03 Mar 2016 15:54:03 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Michael Welzl In-Reply-To: <40707.1457015491@lawyers.icir.org> Date: Thu, 3 Mar 2016 15:54:02 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <58556ABF-D5CA-4C4F-8679-74B29C4E06E4@ifi.uio.no> References: <40707.1457015491@lawyers.icir.org> To: mallman@icir.org X-Mailer: Apple Mail (2.2104) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 5 msgs/h 2 sum rcpts/h 14 sum msgs/h 6 total rcpts 39015 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-6.0, required=5.0, autolearn=disabled, RP_MATCHES_RCVD=-1.05, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: CF72390F1758374484FCD6CA7DDEBB378EFFABCE X-UiO-SPAM-Test: remote_host: 129.240.68.135 spam_score: -59 maxlevel 80 minaction 2 bait 0 mail/h: 2 total 9372 max/h 17 blacklist 0 greylist 0 ratelimit 0 Archived-At: Cc: Ingemar Johansson S , "tcpm@ietf.org" , "end2end-interest@postel.org" Subject: Re: [tcpm] Question on RFC6298, Managing the RTO Timer and additional lost pakets in Recovery state X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2016 14:54:09 -0000 > On 03 Mar 2016, at 15:31, Mark Allman wrote: >=20 >=20 >> It says quote =E2=80=9C(5.3) When an ACK is received that = acknowledges new >> data, restart the retransmission timer so that it will expire after >> RTO seconds (for the current value of RTO).=E2=80=9D >>=20 >> What is the definition of new data ?. The strict interpretation is >> when SND.UNA advances, but it can also be that the highest SACKed >> sequence number increases. The former case it is more likely that >> RTO happens.=20 >=20 > Seems like something we should have nailed down in the spec at some > point after SACK became widely prevalent. Alas. >=20 > I think "new data" can be interpreted as "cumulative ACK advances". This "new data" stuff is also all over RFC 5681. I remember being = confused by it long ago, exactly with the same two possible = interpretations that Ingemar writes below. Back then I assumed that it must be me; I'm glad to see that I'm not the = only one who got confused by this. But maybe, in the occurrences in RFC 5681, it really was only me? Some = of them are definitely clear, but maybe not all. Cheers, Michael From nobody Thu Mar 3 06:55:16 2016 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35FA31AD0C1 for ; Thu, 3 Mar 2016 06:55:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.906 X-Spam-Level: X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.006] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xTSVW_0o4k0g for ; Thu, 3 Mar 2016 06:55:13 -0800 (PST) Received: from mail-out4.uio.no (mail-out4.uio.no [IPv6:2001:700:100:10::15]) (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 7172E1AD0C0 for ; Thu, 3 Mar 2016 06:55:13 -0800 (PST) Received: from mail-mx1.uio.no ([129.240.10.29]) by mail-out4.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1abUel-0000pw-Ad; Thu, 03 Mar 2016 15:55:11 +0100 Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx1.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.80) (envelope-from ) id 1abUek-0002qC-P8; Thu, 03 Mar 2016 15:55:11 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Michael Welzl In-Reply-To: <58556ABF-D5CA-4C4F-8679-74B29C4E06E4@ifi.uio.no> Date: Thu, 3 Mar 2016 15:55:09 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <912B8EF4-553F-486C-A4F9-28F8DDF67DE0@ifi.uio.no> References: <40707.1457015491@lawyers.icir.org> <58556ABF-D5CA-4C4F-8679-74B29C4E06E4@ifi.uio.no> To: mallman@icir.org X-Mailer: Apple Mail (2.2104) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 9 msgs/h 3 sum rcpts/h 18 sum msgs/h 7 total rcpts 39019 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-6.0, required=5.0, autolearn=disabled, RP_MATCHES_RCVD=-1.05, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 5DDF244485D6336EBF6B1DDE22DCB2B364D1C6B4 X-UiO-SPAM-Test: remote_host: 129.240.68.135 spam_score: -59 maxlevel 80 minaction 2 bait 0 mail/h: 3 total 9373 max/h 17 blacklist 0 greylist 0 ratelimit 0 Archived-At: Cc: Ingemar Johansson S , "tcpm@ietf.org" , "end2end-interest@postel.org" Subject: Re: [tcpm] Question on RFC6298, Managing the RTO Timer and additional lost pakets in Recovery state X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2016 14:55:15 -0000 > On 03 Mar 2016, at 15:54, Michael Welzl wrote: >=20 >=20 >> On 03 Mar 2016, at 15:31, Mark Allman wrote: >>=20 >>=20 >>> It says quote =E2=80=9C(5.3) When an ACK is received that = acknowledges new >>> data, restart the retransmission timer so that it will expire after >>> RTO seconds (for the current value of RTO).=E2=80=9D >>>=20 >>> What is the definition of new data ?. The strict interpretation is >>> when SND.UNA advances, but it can also be that the highest SACKed >>> sequence number increases. The former case it is more likely that >>> RTO happens.=20 >>=20 >> Seems like something we should have nailed down in the spec at some >> point after SACK became widely prevalent. Alas. >>=20 >> I think "new data" can be interpreted as "cumulative ACK advances". >=20 > This "new data" stuff is also all over RFC 5681. I remember being = confused by it long ago, exactly with the same two possible = interpretations that Ingemar writes below. > Back then I assumed that it must be me; I'm glad to see that I'm not = the only one who got confused by this. ... and what can you expect from a guy who can't even get "above" vs. = "below" right? Sigh... sorry folks Michael From nobody Sat Mar 5 07:18:38 2016 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 600711A0398 for ; Sat, 5 Mar 2016 07:18:37 -0800 (PST) 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, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7hOWqSXfL5aw for ; Sat, 5 Mar 2016 07:18:35 -0800 (PST) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C21531A0397 for ; Sat, 5 Mar 2016 07:18:34 -0800 (PST) X-AuditID: c1b4fb25-f794e6d000003d15-2d-56daf8c8c1f9 Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.183.51]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 08.AB.15637.8C8FAD65; Sat, 5 Mar 2016 16:18:32 +0100 (CET) Received: from ESESSMB205.ericsson.se ([169.254.5.194]) by ESESSHC011.ericsson.se ([153.88.183.51]) with mapi id 14.03.0248.002; Sat, 5 Mar 2016 16:18:31 +0100 From: Ingemar Johansson S To: "mallman@icir.org" , Michael Welzl Thread-Topic: [tcpm] Question on RFC6298, Managing the RTO Timer and additional lost pakets in Recovery state Thread-Index: AQHRdVljjXMWYwl7b0WXCW7SiKq2U59K9+Gw Date: Sat, 5 Mar 2016 15:18:31 +0000 Message-ID: <81564C0D7D4D2A4B9A86C8C7404A13DA43D9523A@ESESSMB205.ericsson.se> References: <81564C0D7D4D2A4B9A86C8C7404A13DA43D85BDD@ESESSMB205.ericsson.se> <40707.1457015491@lawyers.icir.org> In-Reply-To: <40707.1457015491@lawyers.icir.org> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.154] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprJIsWRmVeSWpSXmKPExsUyM2K7se6JH7fCDNrfy1vsPjeVxWLammlM Fj/O7mS12HZyPpMDi8e/QzeZPZYs+cnksXr1Q2aPjuMbmANYorhsUlJzMstSi/TtErgyjkyd y1jwTKNi40HNBsYH6l2MnBwSAiYSe2ddZIKwxSQu3FvP1sXIxSEkcJhRouX5RTaQhJDAYkaJ xuvyIDabgI3EykPfGUFsEQFfiXOLv7OA2MwCSRIvPjaBDRIWyJe4sWguM0RNgcTnWxegbCOJ p8vawepZBFQkNly7CjafF2hO489v7BC7SiR6D65gBbE5BQwkJvQ9BYszCshK3P9+D2qXuMSt J/OhjhaQWLLnPDOELSrx8vE/VghbSWLR7c9ANRxA9ZoS63fpQ7QqSkzpfsgOsVZQ4uTMJywT GMVmIZk6C6FjFpKOWUg6FjCyrGIULU4tTspNNzLWSy3KTC4uzs/Ty0st2cQIjLCDW36r7mC8 /MbxEKMAB6MSD2+B8K0wIdbEsuLK3EOMEhzMSiK89q+BQrwpiZVVqUX58UWlOanFhxilOViU xHlZP10OExJITyxJzU5NLUgtgskycXBKNTAyyN88lz3z/Pu+VKXjBfWerffddm08r3hh8kuz lV9vBscssH/6Wdt+z66/0Q6TjC4tq/dueD9xBi/ziayHmws3tbdPjvjL89fgtFqAz+0vS0qi 7m5VdsjWrwyP7VMW797evj9xzdwnDy/pCV0P3HfHrprf54TEF5a8HOc9jhWzf3T/f3FmdRSz EktxRqKhFnNRcSIAgy8AOqwCAAA= Archived-At: Cc: "tcpm@ietf.org" , "end2end-interest@postel.org" Subject: Re: [tcpm] Question on RFC6298, Managing the RTO Timer and additional lost pakets in Recovery state X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Mar 2016 15:18:37 -0000 SGkNCg0KVGhhbmtzIGZvciB0aGUgcmVzcG9uc2UsIGFuZCB0aGFuayBNaWNoYWVsIGFzIHdlbGws IGd1ZXNzIEkgbmVlZCB0byByZWFkIFJGQzU2ODEgYW5kIFJGQzY2NzUgYWdhaW4uDQoNClRoZSBs aW5lIG9mIHJlYXNvbmluZyBzZWVuIGZyb20gYW4gYXBwbGljYXRpb24gcGVyc3BlY3RpdmUgYWN0 dWFsbHkgaGVscHMgdG8gcHV0IHRoZSBwdXp6bGUgdG9nZXRoZXIgZm9yIG1lLg0KQWxzbyBJIHVu ZGVyc3RhbmQgbm93IHRoYXQgY2FzZSAyIGJlbG93IG5lY2Vzc2l0YXRlcyBhbiBSVE8sIGF0bGVh c3Qgd2l0aCBUQ1AuIEkgZ3Vlc3MgUVVJQyBtYXkgYmUgZGlmZmVyZW50IGluIHRoaXMgcmVzcGVj dCBhcyBpdCByZXRyYW5zbWl0dGVkIHNlZ21lbnRzIGhhdmUgYSBuZXcgdHJhbnNwb3J0IHNlcXVl bmNlIG51bWJlciA/Lg0KDQovSW5nZW1hcg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t DQo+IEZyb206IG1hbGxtYW5AaWNpci5vcmcgW21haWx0bzptYWxsbWFuQGljaXIub3JnXQ0KPiBT ZW50OiBkZW4gMyBtYXJzIDIwMTYgMTU6MzINCj4gVG86IEluZ2VtYXIgSm9oYW5zc29uIFMNCj4g Q2M6IHRjcG1AaWV0Zi5vcmc7IGVuZDJlbmQtaW50ZXJlc3RAcG9zdGVsLm9yZw0KPiBTdWJqZWN0 OiBSZTogW3RjcG1dIFF1ZXN0aW9uIG9uIFJGQzYyOTgsIE1hbmFnaW5nIHRoZSBSVE8gVGltZXIg YW5kDQo+IGFkZGl0aW9uYWwgbG9zdCBwYWtldHMgaW4gUmVjb3Zlcnkgc3RhdGUNCj4gDQo+IA0K PiA+IEl0IHNheXMgcXVvdGUg4oCcKDUuMykgV2hlbiBhbiBBQ0sgaXMgcmVjZWl2ZWQgdGhhdCBh Y2tub3dsZWRnZXMgbmV3DQo+ID4gZGF0YSwgcmVzdGFydCB0aGUgcmV0cmFuc21pc3Npb24gdGlt ZXIgc28gdGhhdCBpdCB3aWxsIGV4cGlyZSBhZnRlcg0KPiA+IFJUTyBzZWNvbmRzIChmb3IgdGhl IGN1cnJlbnQgdmFsdWUgb2YgUlRPKS7igJ0NCj4gPg0KPiA+IFdoYXQgaXMgdGhlIGRlZmluaXRp b24gb2YgbmV3IGRhdGEgPy4gVGhlIHN0cmljdCBpbnRlcnByZXRhdGlvbiBpcw0KPiA+IHdoZW4g U05ELlVOQSBhZHZhbmNlcywgYnV0IGl0IGNhbiBhbHNvIGJlIHRoYXQgdGhlIGhpZ2hlc3QgU0FD S2VkDQo+ID4gc2VxdWVuY2UgbnVtYmVyIGluY3JlYXNlcy4gVGhlIGZvcm1lciBjYXNlIGl0IGlz IG1vcmUgbGlrZWx5IHRoYXQgUlRPDQo+ID4gaGFwcGVucy4NCj4gDQo+IFNlZW1zIGxpa2Ugc29t ZXRoaW5nIHdlIHNob3VsZCBoYXZlIG5haWxlZCBkb3duIGluIHRoZSBzcGVjIGF0IHNvbWUgcG9p bnQNCj4gYWZ0ZXIgU0FDSyBiZWNhbWUgd2lkZWx5IHByZXZhbGVudC4gIEFsYXMuDQo+IA0KPiBJ IHRoaW5rICJuZXcgZGF0YSIgY2FuIGJlIGludGVycHJldGVkIGFzICJjdW11bGF0aXZlIEFDSyBh ZHZhbmNlcyIuDQo+IA0KPiBUaGUgc3Bpcml0IG9mICg1LjMpIGlzIHRoYXQgYXMgbG9uZyBhcyB0 aGUgY29ubmVjdGlvbiBpcyBtYWtpbmcgcHJvZ3Jlc3MtLS1mcm9tDQo+IGFuIGFwcGxpY2F0aW9u IHBlcnNwZWN0aXZlLS0td2UgY2FuIGtlZXAgdGhlIFJUTyBhdCBhcm1zIGxlbmd0aCBhbmQgc28g d2UNCj4ganVzdCBrZWVwIHJlLWFybWluZyBpdC4gIEJ1dCwgb25jZSB3ZSBoYXZlIGEgc3RhbGwt LS1vciBldmVuIGFuIGluZGljYXRpb24gdGhhdA0KPiB3ZSBtaWdodCBzdGFsbC0tLWJlY2F1c2Ug YSBwYWNrZXQgaGFzIGJlZW4gbG9zdCB0aGVuIHdlIHN0b3AgcHVzaGluZyB0aGUNCj4gUlRPIG9m Zi4NCj4gDQo+ID4gVGhlIHNlY29uZCBxdWVzdGlvbiBpcyBMaW51eCByZWxhdGVkLiBHaXZlbiB0 aGF0IGEgbG9zdCBwYWNrZXQgcHV0cw0KPiA+IHRoZSBzdGFjayBpbiBSZWNvdmVyeSBzdGF0ZSwg dGhlIGNvbmdlc3Rpb24gd2luZG93IHJlZHVjZXMgb25lIHN0ZXAgYXMNCj4gPiBhbiBlZmZlY3Qg b24gdGhpcy4gV2hhdCBoYXBwZW5zIGlmIGFkZGl0aW9uYWwgcGFja2V0cyBhcmUgbG9zdCB3aGVu IGluDQo+ID4gUmVjb3Zlcnkgc3RhdGUuIEkgZ3Vlc3MgdGhlIGNvbmdlc3Rpb24gd2luZG93IHNo b3VsZCBkZWNyZWFzZSBtb3JlIG9yDQo+ID4gPy4NCj4gDQo+IEZpcnN0LCB0aGlzIGlzIGEgbW9y ZSBnZW5lcmljIGFuc3dlciwgSSBoYXZlIG5vIGlkZWEgd2hhdCBsaW51eCBkb2VzLg0KPiANCj4g SSBjYW4ndCB0ZWxsIHdoaWNoIG9mIHR3byBjYXNlcyB5b3UgYXJlIHRhbGtpbmcgYWJvdXQgaGVy ZS4gIExldCdzIHNheSB5b3Ugc2VuZA0KPiAyMCBwYWNrZXRzIGludG8gdGhlIG5ldHdvcmsgaW4g c29tZSB3aW5kb3cuICBOb3csIHRoZSBjYXNlcyAuLi4NCj4gDQo+ICgxKSBXZSBsb3NlIHBhY2tl dHMgMSwgNSwgMTMgYW5kIDE3LiAgSS5lLiwgbXVsdGlwbGUgcGFja2V0cyBhcmUNCj4gICAgIGxv c3QgZnJvbSBhIHNpbmdsZSB0cmFuc21pc3Npb24gd2luZG93LiAgU28sIHJldHJhbnNtaXR0aW5n DQo+ICAgICBwYWNrZXQgMSBwdXRzIHVzIGluIHJlY292ZXJ5IGFuZCBjYXVzZXMgY29uZ2VzdGlv biBjb250cm9sDQo+ICAgICBhY3Rpb24uICBJIGJlbGlldmUgdGhhdCB0aGUgZmFjdCB0aGF0IHBh Y2tldHMgNSwgMTMgYW5kIDE3IGFyZQ0KPiAgICAgYWxzbyBsb3N0IGRvZXMgbm90IG1lYW4gd2Ug c2hvdWxkIHJlYWN0IHRvIGNvbmdlc3Rpb24gYWdhaW4uDQo+ICAgICBFLmcuLCBSRkMgNjY3NSBj YWxscyBmb3IgYSBzaW5nbGUgQ0MgcmVzcG9uc2UgcmVnYXJkbGVzcyBvZiBob3cNCj4gICAgIG1h bnkgcGFja2V0cyBhcmUgbG9zdCBmcm9tIGEgd2luZG93IG9mIGRhdGEuDQo+IA0KPiAoMikgV2Ug bG9zZSBwYWNrZXRzIDEsIDUsIDEzIGFuZCAxNyBhbmQgYWxzbyB0aGUgcmV0cmFuc21pdCBvZg0K PiAgICAgcGFja2V0IDE3LiAgU28sIHdlIGxvc2UgNCBwYWNrZXRzIGZyb20gdGhlIGZpcnN0IHNp bmdsZQ0KPiAgICAgdHJhbnNtaXNzaW9uIHdpbmRvdy4gIFRoaXMgdHJpZ2dlcnMgb25lIENDIHJl c3BvbnNlLiAgQnV0LCB0aGUNCj4gICAgIHJldHJhbnNtaXQgb2YgcGFja2V0IDE3IGlzIGZyb20g YSBzdWJzZXF1ZW50IHRyYW5zbWlzc2lvbg0KPiAgICAgd2luZG93LCBpbmRpY2F0aW5nIHRoYXQg cGVyaGFwcyB3ZSBoYXZlbid0IHlldCBkb25lIGVub3VnaCB0bw0KPiAgICAgcmVsaWV2ZSB0aGUg Y29uZ2VzdGlvbi4gIENvbnNlcnZhdGl2ZW5lc3Mgd291bGQgbGlrZWx5IHN1Z2dlc3QNCj4gICAg IHRoYXQgaW4gdGhpcyBjYXNlLCB5ZXMsIHdlIHNob3VsZCB0YWtlIGFub3RoZXIgQ0MgYWN0aW9u Lg0KPiANCj4gICAgIEFuZCwgZS5nLiwgUkZDIDY2NzUgZm9yY2VzIHRoaXMgc2Vjb25kIENDIGFj dGlvbiBieSBiZWluZyB1bmFibGUNCj4gICAgIHRvIGNvcGUgd2l0aCBsb3N0IHJldHJhbnNtaXNz aW9ucy4gIFJhdGhlciwgaW4gdGhpcyBjYXNlIHdlIGZhbGwNCj4gICAgIGJhY2sgdG8gdGhlIFJU TyB3aGljaCBtZWFucyBhbm90aGVyIENDIHJlc3BvbnNlLiAgSSBhbSBub3QNCj4gICAgIGNsYWlt aW5nIFJGQyA2Njc1IGlzIHRoZSByaWdodCBhcHByb2FjaCBoZXJlLiAgSnVzdCBub3Rpbmcgd2hh dA0KPiAgICAgc29tZSBzcGVjIGRvZXMuICBXZSBsZWZ0IGl0IHRoaXMgd2F5IGJlY2F1c2Ugd2Ug ZGlkbid0IGZlZWwgdGhhdA0KPiAgICAgdGhlIGNvbXBsZXhpdHkgb2YgZGVhbGluZyB3aXRoIHRo aXMgY2FzZSB3YXMgcmVhbGx5IGdlbmVyYWxseQ0KPiAgICAgd29ydGggaXQuICBCdXQsIG9uZSBj b3VsZCBlbnZpc2lvbiBhIGRpZmZlcmVudCBhbGdvcml0aG0gbWFraW5nDQo+ICAgICBhIGRpZmZl cmVudCBjaG9pY2UuDQo+IA0KPiBJIGhvcGUgdGhhdCBoZWxwcyENCj4gDQo+IGFsbG1hbg0KPiAN Cj4gDQo+IC0tDQo+IGh0dHA6Ly93d3cuaWNpci5vcmcvbWFsbG1hbi8NCj4gDQo+IA0KDQo= From nobody Sat Mar 5 07:53:24 2016 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75DAF1A1B2B for ; Sat, 5 Mar 2016 07:53:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.38 X-Spam-Level: X-Spam-Status: No, score=-1.38 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Eb4mJLiPyQjl for ; Sat, 5 Mar 2016 07:53:21 -0800 (PST) Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c:c09::231]) (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 98ED71A1B2A for ; Sat, 5 Mar 2016 07:53:20 -0800 (PST) Received: by mail-wm0-x231.google.com with SMTP id n186so29371033wmn.1 for ; Sat, 05 Mar 2016 07:53:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=UmeV6kf5A/n8pFyVipnyQQIieXKK0EccWQzsGwr9fRU=; b=ZV/yQz+shxkRXD+5eU01gh9+ooCYu2xTw5sIKf3PmOHeZ4K/haJhvql+Yj437ZzvO9 TWcTfVYwGBRDush9XXi9/z8BaHRVLW5Vo3+8fYPhAK6ra1OV2MEVY7kyVh+DUglHxvaB ZdvULgwvDaAZ549wIE4RutgO+cboCeH8/fOw0ZtgGs0YDyvQQAveAfrV07316JXBL0uH MMkopuTS1/KPrPkKlpipcXFnUajpJe2muo4M8bE6DFtVVEi8wJIld0ItOeOmj4LImCJx NvEgfFPob+39EMMY0sps5gim5rPrwEC5zkyojiscSmucZRa7UqRKEvTP3Zj8/O4vRz0P n54g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=UmeV6kf5A/n8pFyVipnyQQIieXKK0EccWQzsGwr9fRU=; b=B/6NaJNa3iJqWFW/webWEwqDV5QCBnxrltmY+rDieEjZZVTTl4pra93xcvGFviJXei kZWfy54jFcIf1WQ5gzs5Is/FtUK6O/8ZHnmANF/NuytMSsBVoV+lax6t0oQ8q3XptqZu H13fBolBOWJ67tJga4/xP6opC/lULV85b2iHWsAlzmsqZN+7mU3kDbmUYpm1x104pyMT +s6N/Kq3iaA6r4L2zEdGSO/qYqjR5DOvBjjiuSIzKYFeeesDGG/Lx+BicQ4vV03CHFv/ JlF8KjctupHDCB+VXj0Zh2VJ4tvDQv2ZdV6hlSvTerov16qYlhfOuDbbHOP/4bRfVT7P ET6A== X-Gm-Message-State: AD7BkJLf9DV1i+F8RY7qCs52CGesiTuhKBimTtWU4AGrEPiUlrBUgRfcKxY6lYllv8RPT59L23t+nrEIue9tmF4Z X-Received: by 10.194.112.98 with SMTP id ip2mr14661488wjb.24.1457193198975; Sat, 05 Mar 2016 07:53:18 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.222.131 with HTTP; Sat, 5 Mar 2016 07:52:39 -0800 (PST) In-Reply-To: <81564C0D7D4D2A4B9A86C8C7404A13DA43D9523A@ESESSMB205.ericsson.se> References: <81564C0D7D4D2A4B9A86C8C7404A13DA43D85BDD@ESESSMB205.ericsson.se> <40707.1457015491@lawyers.icir.org> <81564C0D7D4D2A4B9A86C8C7404A13DA43D9523A@ESESSMB205.ericsson.se> From: Yuchung Cheng Date: Sat, 5 Mar 2016 07:52:39 -0800 Message-ID: To: Ingemar Johansson S Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "tcpm@ietf.org" , "end2end-interest@postel.org" , Michael Welzl , "mallman@icir.org" Subject: Re: [tcpm] Question on RFC6298, Managing the RTO Timer and additional lost pakets in Recovery state X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Mar 2016 15:53:22 -0000 Linux implements RFC6937 not RFC6675 to adjust cwnd in fast recovery. Specifically it reduces cwnd gradually toward ssthresh as packets are being delivered. if inflight, aka pipe, drops below ssthresh, it tries to slow start toward ssthresh, provided no additional packets are lost. The last condition was added recently and I had a presentation last meeting: https://www.ietf.org/proceedings/94/slides/slides-94-tcpm-7.p= df btw, Linux may adjust RTO by taking RTT samples from newly SACK blocks, which is not standardized. It mitigates issues when RTT continues to raise during recovery in LTE networks (see figure 15 in http://web.eecs.umich.edu/~zmao/Papers/lte_sigcomm13.pdf) On Sat, Mar 5, 2016 at 7:18 AM, Ingemar Johansson S wrote: > > Hi > > Thanks for the response, and thank Michael as well, guess I need to read = RFC5681 and RFC6675 again. > > The line of reasoning seen from an application perspective actually helps= to put the puzzle together for me. > Also I understand now that case 2 below necessitates an RTO, atleast with= TCP. I guess QUIC may be different in this respect as it retransmitted seg= ments have a new transport sequence number ?. > > /Ingemar > > > -----Original Message----- > > From: mallman@icir.org [mailto:mallman@icir.org] > > Sent: den 3 mars 2016 15:32 > > To: Ingemar Johansson S > > Cc: tcpm@ietf.org; end2end-interest@postel.org > > Subject: Re: [tcpm] Question on RFC6298, Managing the RTO Timer and > > additional lost pakets in Recovery state > > > > > > > It says quote =E2=80=9C(5.3) When an ACK is received that acknowledge= s new > > > data, restart the retransmission timer so that it will expire after > > > RTO seconds (for the current value of RTO).=E2=80=9D > > > > > > What is the definition of new data ?. The strict interpretation is > > > when SND.UNA advances, but it can also be that the highest SACKed > > > sequence number increases. The former case it is more likely that RTO > > > happens. > > > > Seems like something we should have nailed down in the spec at some poi= nt > > after SACK became widely prevalent. Alas. > > > > I think "new data" can be interpreted as "cumulative ACK advances". > > > > The spirit of (5.3) is that as long as the connection is making progres= s---from > > an application perspective---we can keep the RTO at arms length and so = we > > just keep re-arming it. But, once we have a stall---or even an indicat= ion that > > we might stall---because a packet has been lost then we stop pushing th= e > > RTO off. > > > > > The second question is Linux related. Given that a lost packet puts > > > the stack in Recovery state, the congestion window reduces one step a= s > > > an effect on this. What happens if additional packets are lost when i= n > > > Recovery state. I guess the congestion window should decrease more or > > > ?. > > > > First, this is a more generic answer, I have no idea what linux does. > > > > I can't tell which of two cases you are talking about here. Let's say = you send > > 20 packets into the network in some window. Now, the cases ... > > > > (1) We lose packets 1, 5, 13 and 17. I.e., multiple packets are > > lost from a single transmission window. So, retransmitting > > packet 1 puts us in recovery and causes congestion control > > action. I believe that the fact that packets 5, 13 and 17 are > > also lost does not mean we should react to congestion again. > > E.g., RFC 6675 calls for a single CC response regardless of how > > many packets are lost from a window of data. > > > > (2) We lose packets 1, 5, 13 and 17 and also the retransmit of > > packet 17. So, we lose 4 packets from the first single > > transmission window. This triggers one CC response. But, the > > retransmit of packet 17 is from a subsequent transmission > > window, indicating that perhaps we haven't yet done enough to > > relieve the congestion. Conservativeness would likely suggest > > that in this case, yes, we should take another CC action. > > > > And, e.g., RFC 6675 forces this second CC action by being unable > > to cope with lost retransmissions. Rather, in this case we fall > > back to the RTO which means another CC response. I am not > > claiming RFC 6675 is the right approach here. Just noting what > > some spec does. We left it this way because we didn't feel that > > the complexity of dealing with this case was really generally > > worth it. But, one could envision a different algorithm making > > a different choice. > > > > I hope that helps! > > > > allman > > > > > > -- > > http://www.icir.org/mallman/ > > > > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Tue Mar 8 02:06:54 2016 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 7A83F12D5E0 for ; Tue, 8 Mar 2016 02:06:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.801 X-Spam-Level: X-Spam-Status: No, score=-0.801 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=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 (1024-bit key) header.d=tieto.com Received: from mail.ietf.org ([127.0.0.1]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id niVnhD2FuNAL for ; Tue, 8 Mar 2016 02:06:48 -0800 (PST) Received: from mail-ig0-x22b.google.com (mail-ig0-x22b.google.com [IPv6:2607:f8b0:4001:c05::22b]) (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 6678312D5E1 for ; Tue, 8 Mar 2016 02:06:48 -0800 (PST) Received: by mail-ig0-x22b.google.com with SMTP id ig19so13749940igb.1 for ; Tue, 08 Mar 2016 02:06:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tieto.com; s=google; h=from:mime-version:thread-index:date:message-id:subject:to; bh=DvCpPDynR8n5KyJJeJUOb25NcNk/mmb90Dn76Ixni2A=; b=HGfnTQvkfQ3Oa+T6vcHBfLPBmUpWDWY4SgjM5nYadABdVt6eKR+DN4nMDNBVyirb/U EHG7rrEsohF/EsagVoNNs80tzsYUWmwBCiEY9bjc5vj3YECgz2RynDLapWAX+t8Lobn1 X3B8wTIUTGuNg4lcrRNBbCLu0ASXse03Fr8fA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:mime-version:thread-index:date:message-id :subject:to; bh=DvCpPDynR8n5KyJJeJUOb25NcNk/mmb90Dn76Ixni2A=; b=gLyh7lJhP0EvbKSzqmd7vfZ8J6uekINEfIInt7QJxgx3g7qCutZyn6/Pilko1MYkax 6Upa7qWxA7uBkqZLwYsoVoP1gEoGMof0YHzQ9FZRU9ABF1zt2CRTvjwmOHx+4LcC/Q2Q /OdKuf1PP4SSGQ/ROeiaiE1CU+D5JloFDI7MT95Y6pe19MkhfKDMQoEWuW131/h2MbKB x6hRh2Z2uaP4fn95fplgQ3sK/Vox19d37eOvz2mzOu3qDkrpkvmPPcoI2aTJlMjdHfJh wDII0VZS00e/yUxETPa8yy+M2oJqmpYznwq8bKC5wtG6iMWP2Zb368VZrLbFUHrN9Slr SPCQ== X-Gm-Message-State: AD7BkJIPQMRSCnSRA+jeXTzAte5mLydvk16DmE4Yv5ktZ1JT0NPqzkO4/0oKKUx7vZvn6s72rRRHz52fyRXxhaj7eWa950TsfcCD1v+mPaYwIT986x+y+CK9x50nbgjruEziu3A= X-Received: by 10.50.43.194 with SMTP id y2mr17085155igl.96.1457431607452; Tue, 08 Mar 2016 02:06:47 -0800 (PST) From: Karen Elisabeth Egede Nielsen MIME-Version: 1.0 X-Mailer: Microsoft Outlook 15.0 Thread-Index: AdF5G955RUuawLpHQySBaD4MNu8nyA== Date: Tue, 8 Mar 2016 11:06:45 +0100 Message-ID: <90e80f38b10a81626591d3cede931e35@mail.gmail.com> To: tcpm@ietf.org, draft-ietf-tcpm-cubic@ietf.org Content-Type: multipart/alternative; boundary=047d7bfea0b63f81cf052d86bdb1 X-DomainID: tieto.com Archived-At: Subject: [tcpm] Question on CUBIC and its TCP CC RFC basics X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 08 Mar 2016 10:06:51 -0000 --047d7bfea0b63f81cf052d86bdb1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, I am reading the TCP CUBIC draft specification with the intend of implementing =E2=80=93 or rather specifically - with the intend of impleme= nting in appropriately adjusted manner for SCTP. I hope that you may help with some clarifying questions to the basic parts ? The reference to RFC6582 and RFC2018 BUT NOT to RFC 6675 makes me wonder if there is some particular point which I am missing =E2=80=93 I.e.: It is said =E2=80=93 section 3.1: The protocol does not make any change to the fast recovery and retransmit of TCP-NewReno [RFC6582] and TCP-SACK [RFC2018]. During congestion ^^^^^^^^^^^^^^^ avoidance after fast recovery, CUBIC changes the window update ^^^^^^^^^^^^^^^^^^ algorithm of Standard TCP. Apart from the missing reference to RFC5681/RFC6675 this sounds clear. CUBIC CC does not impact CC operation during Fast Recovery but only impacts the CC operation once Fast Recovery has completed Is that the correct understanding ? Hmm .. except that the ramp down factor is not 0.5 but 0.2. It is then further said =E2=80=93 section 3.1: The window growth function of CUBIC uses the following function: W_cubic(t) =3D C*(t-K)^3 + W_max (Eq. 1) where C is a constant fixed to determine the aggressiveness of window growth in high BDP networks, t is the elapsed time from the last ^^^^^^^^^^ window reduction,and K is the time period that the above function ^^^^^^^^^^^^^^^ takes to increase the current window size to W_max when there is no ^^^^^^^^^^^^^^ further loss event and is calculated by using the following equation: ^^^^^^^^^^^ My problem with understanding this formulation is that these two events (last window reduction and no further loss event) need not coincide. On the other hand then I assume that the whole idea is that W_MAX is reached when t=3DK and if this is right then we are speaking about the same event =E2=80=93 OR= am I missing something ? If I am right (but perhaps not) in assuming that we are speaking about the same point in time =E2=80=93 then what point in time are we speaking about really ? In my nativity I have assumed that the actual point in time would be at exit of FR =E2=80=93 alternatively =E2=80=93 time of last observed loss event even if this may make the slope steeper at exit of FR. Which is it =E2=80=93 one of the two or something different ? Many Thanks ! BR, Karen --047d7bfea0b63f81cf052d86bdb1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hi,

=C2=A0

I am reading the TC= P CUBIC draft specification with the intend of implementing =E2=80=93 or ra= ther specifically =C2=A0- with the intend of implementing

in appropriately adjusted manner for S= CTP. I hope that you may help with some clarifying questions to the basic p= arts ?

=C2=A0<= /p>

The reference to RFC6582 and= RFC2018 BUT NOT to RFC 6675 makes me wonder if there is some

particular point which I am missi= ng =E2=80=93 I.e.:

= =C2=A0

It is said =E2= =80=93 section 3.1:

= =C2=A0

The

=

=C2=A0=C2=A0 protocol does not = make any change to the fast recovery and retransmit

=C2=A0=C2=A0 of TCP-NewReno [RFC6582] and TC= P-SACK [RFC2018].=C2=A0 During congestion

= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ^^^^^^^^^^^^^^^

=

=C2=A0=C2=A0 avoidance after fa= st recovery, CUBIC changes the window update

=C2=A0 ^^^^^^^^^^^^^^^^^^

=C2=A0=C2=A0 algorithm of Standard TCP.=

=C2=A0

Apart from the missing reference to RFC= 5681/RFC6675 this sounds clear. CUBIC CC does not impact CC operation durin= g Fast Recovery but only impacts the CC operation once Fast Recovery has co= mpleted

=C2=A0

Is that the correct unders= tanding ?

=C2=A0

Hmm .. except that the r= amp down factor is not 0.5 but 0.2.

=C2=A0

It is then further said =E2=80=93 section 3.1:

=C2=A0

The window growth function of CUBIC uses the following functio= n:

=C2=A0

<= p class=3D"MsoNormal">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 W= _cubic(t) =3D C*(t-K)^3 + W_max (Eq. 1)

=C2=A0

=C2=A0=C2=A0 where C is a constant fixed to determine the aggressivene= ss of window

=C2=A0= =C2=A0 growth in high BDP networks, t is the elapsed time from the last

=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 ^^^^^^^^^^

=C2=A0=C2=A0=C2=A0window reduction,and K is the time period that the ab= ove function

=C2=A0 ^= ^^^^^^^^^^^^^^

=C2=A0= =C2=A0 takes to increase the current window size to W_max when there is no<= /span>

=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ^^^^^^^^^^^^^^

=C2=A0=C2=A0 further loss event and= is calculated by using the following equation:

=C2=A0=C2=A0 ^^^^^^^^^^^

=C2=A0

My problem with understanding this formulation is that the= se two events (last window reduction and

<= span lang=3D"EN-US">no further loss event) need not coincide. On the other = hand then I assume that the whole idea is that W_MAX is reached when t=3DK =

and if this is right= then we are speaking about the same event =E2=80=93 OR am I missing someth= ing ?

=C2=A0

If I am right (but perhaps no= t) in assuming that we are speaking about the same point in time =E2=80=93 = then

what point in ti= me are we speaking about really ?

=C2=A0

I= n my nativity I have assumed that the actual point in time would be at exit= of FR =E2=80=93 alternatively =C2=A0=E2=80=93 =C2=A0time

of last observed loss event even if th= is may make the slope steeper at exit of FR.

=C2=A0

Which is it =E2=80=93 one of the two or something different ?

=C2=A0

Many Thanks !

=C2=A0

BR, Karen

=C2=A0

=C2=A0

--047d7bfea0b63f81cf052d86bdb1-- From nobody Tue Mar 8 06:06:10 2016 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 0309C12D719 for ; Tue, 8 Mar 2016 06:06:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 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_LOW=-0.7, 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 ([127.0.0.1]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4bor29PJANd3 for ; Tue, 8 Mar 2016 06:06:04 -0800 (PST) Received: from mail-oi0-x234.google.com (mail-oi0-x234.google.com [IPv6:2607:f8b0:4003:c06::234]) (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 30C9212D6F9 for ; Tue, 8 Mar 2016 06:06:04 -0800 (PST) Received: by mail-oi0-x234.google.com with SMTP id c203so10937730oia.2 for ; Tue, 08 Mar 2016 06:06:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-transfer-encoding; bh=Ivr8Qi7YdJ2FJchHjJ8zfGK2R8tg0zUrHi/zU9RJgEk=; b=BUdU7kCGvaxB38huLkqSZhle8xF4Vtl7KVsVHCk8AjsMNkpwSx5V4sykX2VUhwPxyd cQnZMtg8hVtRfE88ZDOWtdNKoCrgGJOk4+5fxPcfPu4+LKArYjtP1YDCAE9mZJGrEl9O RufgY5o7iVck6Wtc6w2rmifW67MDOLh5Y2E63pj3Gvhx1hXwCJc1mXBpiUMw0w0v9FtD UE7TH+vpEbcmvraEW3C3ENd4VW7FEIr5NIXtbmx+p0yo7+pyMo1CW8W7XFLwuZksu1Pw amGf7sq3PSc56OLc3s5GqAUnuOPqbwhFidBpyag1/43SXmuC9sZPVTBL/u3Fk9dMmIVG u3Og== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-transfer-encoding; bh=Ivr8Qi7YdJ2FJchHjJ8zfGK2R8tg0zUrHi/zU9RJgEk=; b=dqK8N15nUr0zM8LtSu8w3Gb2flBZYEOi0ROIDTs8rwEP9UvYsdpVwrAXQCYWVMuEwM b8A1jB/RSIM4pYXO3Us02A74G+ox6vk1P2dQTqZnMu+Op/Z47yd8r8dtmdWPF/2YCWOf BdjkVCzfvZ8THd6KNvh9PuFn5cPqFYafV8jtY5NQG2C/4+rHY80HS+eoFUDa7znUTQ5O aQ0IEkMd+EnOLuOzhG3geIXyCgvSn8SlZ9tsCFXJVjGokzEOhQJQetjKl1bggSqNC4vk 0DjdEYDw2hyepxZGnVC75O1Rbxi8qswfcgf/GMVjpjeQp370LQJ6ehzMF2GQ8+UplQI5 0rCA== X-Gm-Message-State: AD7BkJLoFQTrh7U1XT/Sx0ev2xypIjBsrY+VKT9EUJ1ntIHxmvlL55NjSxrFys7wp5QWHYuc8PQoU+P0kBQulYfr MIME-Version: 1.0 X-Received: by 10.202.64.132 with SMTP id n126mr12941417oia.80.1457445963459; Tue, 08 Mar 2016 06:06:03 -0800 (PST) Received: by 10.202.203.132 with HTTP; Tue, 8 Mar 2016 06:06:03 -0800 (PST) In-Reply-To: <90e80f38b10a81626591d3cede931e35@mail.gmail.com> References: <90e80f38b10a81626591d3cede931e35@mail.gmail.com> Date: Tue, 8 Mar 2016 09:06:03 -0500 Message-ID: From: Neal Cardwell To: Karen Elisabeth Egede Nielsen Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "tcpm@ietf.org" , draft-ietf-tcpm-cubic@ietf.org Subject: Re: [tcpm] Question on CUBIC and its TCP CC RFC basics X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 08 Mar 2016 14:06:09 -0000 On Tue, Mar 8, 2016 at 5:06 AM, Karen Elisabeth Egede Nielsen wrote: > Apart from the missing reference to RFC5681/RFC6675 this sounds clear. > CUBIC CC does not impact CC operation during Fast Recovery but > only impacts the CC operation once Fast Recovery has completed > > Is that the correct understanding ? Yes, that is correct. > Hmm .. except that the ramp down factor is not 0.5 but 0.2. Earlier versions used 0.2, but the current (long-time) ramp down factor is 0.3 (eg see section 1). CUBIC cuts cwnd to 0.7x the prior value cwnd had before entering recovery. But at least in Linux that is not a change in the fast recovery code; that is a different approach the congestion control module uses to calculate the target cwnd that the fast recovery code (independent of the congestion control module) reaches at the end of recovery. > It is then further said =E2=80=93 section 3.1: ... > window reduction,and K is the time period that the above function > takes to increase the current window size to W_max when there is no > further loss event and is calculated by using the following equation: > > My problem with understanding this formulation is that these two events > (last window reduction and no further loss event) need not coincide. I think the text here in the draft is unclear. The phrase "when there is no further loss event" is not referring to a moment in time, but rather a condition. It might be more clearly expressed by substituting "if" instead of "when", so that it reads: "K is the time period that the above function takes to increase the current window size to W_max if there is no further loss event" I presume this is all in reference to: https://tools.ietf.org/html/draft-ietf-tcpm-cubic-01 cheers, neal From nobody Tue Mar 8 06:19:00 2016 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 9C5A512D735 for ; Tue, 8 Mar 2016 06:18:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=tieto.com Received: from mail.ietf.org ([127.0.0.1]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zLRMcz6INhaf for ; Tue, 8 Mar 2016 06:18:57 -0800 (PST) Received: from mail-ig0-x230.google.com (mail-ig0-x230.google.com [IPv6:2607:f8b0:4001:c05::230]) (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 D1F7512D748 for ; Tue, 8 Mar 2016 06:18:57 -0800 (PST) Received: by mail-ig0-x230.google.com with SMTP id hb3so65465675igb.0 for ; Tue, 08 Mar 2016 06:18:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tieto.com; s=google; h=from:references:in-reply-to:mime-version:thread-index:date :message-id:subject:to:cc:content-transfer-encoding; bh=1VIHqSW4C8s2hIgF52r9QPA1Q2ODdTDXEUI3KePgzY8=; b=umlNwRERiu51TAZhlOgTEQ7/Et8P8qRKHyCscMAGZvYbSmlzr30fdpbAu9wCUfTzjS awdcN9hT9VdUh8dQhtuCwVyO08tNdXpUJTflAoqdcfL7ujDFxR8LeSB+LkAcC46gNztX qMjh91i1a+tFHEw95zS279lPOl72vamEMsqmU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:references:in-reply-to:mime-version :thread-index:date:message-id:subject:to:cc :content-transfer-encoding; bh=1VIHqSW4C8s2hIgF52r9QPA1Q2ODdTDXEUI3KePgzY8=; b=V6AJAnZpxvOQGnXcY9O/w3IBDfrE88Gsq4mbL/ia7l2D2enYifGMUUhtkmsQggnCaV qg2FOBWO5W7sIvdfNajxoOqzH587KmfGnCBHI/5yqc1Ha+VjAduS9EU2SCiOCUBJryFZ U9AuaomUqxYBr4En9l1+7AP4fLuOinyrJkqWqpwx5X6yRfOzbii7mXUMAyAsiCgCqhrH taraAAx9rq+8ooza61Z/U36sLct1GMbdcstXRmq89F7Kc5yuwHzK+Z7KjovdOXldEh1I KDmJiI147f6guLXjpW72/PXZcnvG1Vc0SY4eulevCV9eINcotPsbfMn63LahS6yA8GQt Lzdw== X-Gm-Message-State: AD7BkJKnnU28mcKSl22mje4mQHy9cmiqn6GmQS/+K9SmO7GIWG3ujhtBtQG3fNytU/pld8Rvq5w6ciNCTu/r/KMLvE3sDun7/A+r8y9PtM8vy/cx1G3gP0sO29wlJqCgp1L5Rbg= X-Received: by 10.50.79.136 with SMTP id j8mr5135523igx.24.1457446736613; Tue, 08 Mar 2016 06:18:56 -0800 (PST) From: Karen Elisabeth Egede Nielsen References: <90e80f38b10a81626591d3cede931e35@mail.gmail.com> In-Reply-To: MIME-Version: 1.0 X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQIalpcGbWSSO5ocbu2GX5HnKQuzVgFTaC3bnrK/I/A= Date: Tue, 8 Mar 2016 15:18:55 +0100 Message-ID: <13e7f67fe56c46b4d5d829e83d29a532@mail.gmail.com> To: Neal Cardwell Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-DomainID: tieto.com Archived-At: Cc: tcpm@ietf.org, draft-ietf-tcpm-cubic@ietf.org Subject: Re: [tcpm] Question on CUBIC and its TCP CC RFC basics X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 08 Mar 2016 14:18:59 -0000 Hi Neal, Thanks a lot for your valuable feedback. Yes - Sorry this was in relation to https://tools.ietf.org/html/draft-ietf-tcpm-cubic-01. A little follow up inside below. Something more - do you happen to know why the "Clamp" on the CWND increase is not part of https://tools.ietf.org/html/draft-ietf-tcpm-cubic-01. Is it because it is believed not to be needed given appropriate pacing or has it simply not gotten in yet ? Many Thanks ! > -----Original Message----- > From: Neal Cardwell [mailto:ncardwell@google.com] > Sent: 8. marts 2016 15:06 > To: Karen Elisabeth Egede Nielsen > Cc: tcpm@ietf.org; draft-ietf-tcpm-cubic@ietf.org > Subject: Re: [tcpm] Question on CUBIC and its TCP CC RFC basics > > On Tue, Mar 8, 2016 at 5:06 AM, Karen Elisabeth Egede Nielsen > wrote: > > Apart from the missing reference to RFC5681/RFC6675 this sounds clear. > > CUBIC CC does not impact CC operation during Fast Recovery but only > > impacts the CC operation once Fast Recovery has completed > > > > Is that the correct understanding ? > > Yes, that is correct. > > > Hmm .. except that the ramp down factor is not 0.5 but 0.2. > > Earlier versions used 0.2, but the current (long-time) ramp down factor i= s > 0.3 > (eg see section 1). CUBIC cuts cwnd to 0.7x the prior value cwnd had > before > entering recovery. > [Karen Elisabeth Egede Nielsen] yes that is understood :-) > But at least in Linux that is not a change in the fast recovery code; tha= t > is a > different approach the congestion control module uses to calculate the > target cwnd that the fast recovery code (independent of the congestion > control module) reaches at the end of recovery. > [Karen Elisabeth Egede Nielsen] hmm - not sure I understand this. I asume that the CWND used _during_ FR is the 0.7*prior value CWND And that the factor 0.7 (opposed to RFC5681/RFC6675 factor 0.5 ) impacts th= e fast recovery operation (assuming PRR not in) - while it does of course not impact the fast retransmission code lines which presumably just related to the CWND as updated by the CC logic - is that what you mean ? Or do you mean to say that - in Linux implementation - the 0.7*prior CWND only impacts the CC evaluations at the _end of_ recovery ? > > It is then further said =E2=80=93 section 3.1: > ... > > window reduction,and K is the time period that the above function > > takes to increase the current window size to W_max when there is no > > further loss event and is calculated by using the following equation= : > > > > My problem with understanding this formulation is that these two > > events (last window reduction and no further loss event) need not > coincide. > > I think the text here in the draft is unclear. The phrase "when there is > no > further loss event" is not referring to a moment in time, but rather a > condition. It might be more clearly expressed by substituting "if" instea= d > of > "when", so that it reads: > > "K is the time period that the above function takes to increase the > current window size to W_max if there is no further loss event" > [Karen Elisabeth Egede Nielsen] ok thanks. I think that you have confirmed that the time t starts at _end_ of fast recovery - Correctly understood ? BR, Karen From nobody Tue Mar 8 06:29:01 2016 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 E0EB812D726 for ; Tue, 8 Mar 2016 06:28:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=tieto.com Received: from mail.ietf.org ([127.0.0.1]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CjEt576nieWa for ; Tue, 8 Mar 2016 06:28:57 -0800 (PST) Received: from mail-ig0-x234.google.com (mail-ig0-x234.google.com [IPv6:2607:f8b0:4001:c05::234]) (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 E6C2F12D759 for ; Tue, 8 Mar 2016 06:28:55 -0800 (PST) Received: by mail-ig0-x234.google.com with SMTP id ir4so75973985igb.1 for ; Tue, 08 Mar 2016 06:28:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tieto.com; s=google; h=from:references:in-reply-to:mime-version:thread-index:date :message-id:subject:to:cc:content-transfer-encoding; bh=MFeA+11tkF1VW8eEcsEH6i0oWuTKVhOiOplkAa/kSXM=; b=vbfFo6dmttPPjmGW5xXe2rVDa+f3r4nvpK1rL6QDeC/mZtM+CbGaQkKPlaJgjTttwd sDfKdrQNOw/NB/jyhUEdZtO+Yc4lv7t/5BJh48HF+w6yM/HZL5baycf0LIWMJdyh9FGC 0hCIceyUArGpUGTEDlGSxJDweUEYf7Xi54VZc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:references:in-reply-to:mime-version :thread-index:date:message-id:subject:to:cc :content-transfer-encoding; bh=MFeA+11tkF1VW8eEcsEH6i0oWuTKVhOiOplkAa/kSXM=; b=eAwokhFeVIOLs6jiOJafVPLCzVLV7jYCDRu510HUTGhuL9IWUQfdIK20YpzyY7YSjO 7N4efos+MRx4YdsTZPNKcUm6r5t32Br9cPkImbUU2s482RQWLxd7jm+32OR9UfiZFsjV HEATbWOgS4kSgZhONoHLsQuJ7sGrPAh2k1oKwmX8i7xbmMQ0Byzf4WNGJMJBp5NFOsAT hlNi46wfFaR6Dh7ev4wGiYBSYIGD4xXl3H16R5rqm/jvF/gZ+8gqCu+0QA2zxj0Dpq97 3ic05LFc0zbu5Y+V1yhr4X6g26iEPldJTmkWMNqfHLtflMxgVGjXETJ00uUtypOMt+tq LyDQ== X-Gm-Message-State: AD7BkJLW9vAZHtMI92b/Q6gNDVuBZyzDbBJRMjwHVYuoMdt1h7nNfMxgR/tBrLjjMe6Zx8qnLgSwSIbDIxL/cAuqbQSmvIcuFAS6ZY1u6oiWVYEd/eCOq5HVH6jWEqZyk2nw1SY= X-Received: by 10.50.30.104 with SMTP id r8mr18994740igh.2.1457447335288; Tue, 08 Mar 2016 06:28:55 -0800 (PST) From: Karen Elisabeth Egede Nielsen References: <90e80f38b10a81626591d3cede931e35@mail.gmail.com> 13e7f67fe56c46b4d5d829e83d29a532@mail.gmail.com In-Reply-To: 13e7f67fe56c46b4d5d829e83d29a532@mail.gmail.com MIME-Version: 1.0 X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQIalpcGbWSSO5ocbu2GX5HnKQuzVgFTaC3bnrK/I/CAAAXrUA== Date: Tue, 8 Mar 2016 15:28:53 +0100 Message-ID: To: Neal Cardwell Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-DomainID: tieto.com Archived-At: Cc: tcpm@ietf.org, draft-ietf-tcpm-cubic@ietf.org Subject: Re: [tcpm] Question on CUBIC and its TCP CC RFC basics X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 08 Mar 2016 14:29:00 -0000 Found part of the answer myself - Clamp was removed in Linux 2.6.25 BR, Karen > -----Original Message----- > From: Karen Elisabeth Egede Nielsen [mailto:karen.nielsen@tieto.com] > Sent: 8. marts 2016 15:19 > To: 'Neal Cardwell' > Cc: 'tcpm@ietf.org' ; 'draft-ietf-tcpm-cubic@ietf.org' > ietf-tcpm-cubic@ietf.org> > Subject: RE: [tcpm] Question on CUBIC and its TCP CC RFC basics > > Hi Neal, > > Thanks a lot for your valuable feedback. > Yes - Sorry this was in relation to > https://tools.ietf.org/html/draft-ietf-tcpm- > cubic-01. > > A little follow up inside below. > > Something more - do you happen to know why the "Clamp" on the CWND > increase > is not part of https://tools.ietf.org/html/draft-ietf-tcpm-cubic-01. > Is it because it is believed not to be needed given appropriate pacing or > has it > simply not gotten in yet ? > > Many Thanks ! > > > -----Original Message----- > > From: Neal Cardwell [mailto:ncardwell@google.com] > > Sent: 8. marts 2016 15:06 > > To: Karen Elisabeth Egede Nielsen > > Cc: tcpm@ietf.org; draft-ietf-tcpm-cubic@ietf.org > > Subject: Re: [tcpm] Question on CUBIC and its TCP CC RFC basics > > > > On Tue, Mar 8, 2016 at 5:06 AM, Karen Elisabeth Egede Nielsen > > wrote: > > > Apart from the missing reference to RFC5681/RFC6675 this sounds clear= . > > > CUBIC CC does not impact CC operation during Fast Recovery but only > > > impacts the CC operation once Fast Recovery has completed > > > > > > Is that the correct understanding ? > > > > Yes, that is correct. > > > > > Hmm .. except that the ramp down factor is not 0.5 but 0.2. > > > > Earlier versions used 0.2, but the current (long-time) ramp down factor > > is > 0.3 > > (eg see section 1). CUBIC cuts cwnd to 0.7x the prior value cwnd had > > before > > entering recovery. > > > [Karen Elisabeth Egede Nielsen] yes that is understood :-) > > > But at least in Linux that is not a change in the fast recovery code; > > that is a > > different approach the congestion control module uses to calculate the > > target cwnd that the fast recovery code (independent of the congestion > > control module) reaches at the end of recovery. > > > [Karen Elisabeth Egede Nielsen] hmm - not sure I understand this. I asume > that the CWND used _during_ FR is the 0.7*prior value CWND > And that the factor 0.7 (opposed to RFC5681/RFC6675 factor 0.5 ) impacts > the > fast recovery operation (assuming PRR not in) - while it does of course > not > impact the fast retransmission code lines which presumably just related t= o > the CWND as updated by the CC logic - is that what you mean ? > Or do you mean to say that - in Linux implementation - the 0.7*prior CWND > only impacts the CC evaluations at the _end of_ recovery ? > > > > > It is then further said =E2=80=93 section 3.1: > > ... > > > window reduction,and K is the time period that the above function > > > takes to increase the current window size to W_max when there is n= o > > > further loss event and is calculated by using the following > > > equation: > > > > > > My problem with understanding this formulation is that these two > > > events (last window reduction and no further loss event) need not > > coincide. > > > > I think the text here in the draft is unclear. The phrase "when there i= s > > no > > further loss event" is not referring to a moment in time, but rather a > > condition. It might be more clearly expressed by substituting "if" > > instead of > > "when", so that it reads: > > > > "K is the time period that the above function takes to increase the > > current window size to W_max if there is no further loss event" > > > [Karen Elisabeth Egede Nielsen] ok thanks. > > I think that you have confirmed that the time t starts at _end_ of fast > recovery - > Correctly understood ? > > BR, Karen From nobody Tue Mar 8 07:25:04 2016 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 CD63512D783 for ; Tue, 8 Mar 2016 07:25:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 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_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([127.0.0.1]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OWhxQhY9o15z for ; Tue, 8 Mar 2016 07:24:59 -0800 (PST) Received: from mail-oi0-x232.google.com (mail-oi0-x232.google.com [IPv6:2607:f8b0:4003:c06::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 7C08412D771 for ; Tue, 8 Mar 2016 07:24:57 -0800 (PST) Received: by mail-oi0-x232.google.com with SMTP id c203so12770736oia.2 for ; Tue, 08 Mar 2016 07:24:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=KZITXoL+uo9afzB3R8KLm8AQJYwI8d1Q4Ddl6CeSRXs=; b=W7ibK15y+XhVZ2JlvTN+XTa2ejaJF/rLyS15uQpb05Ng4ZXHhRywtiECZrbKf8bZf/ I1ORoAJqfzmLdfHckn/nLWn7FTYmNHxsGfuXrGDyYWsqFfYXhklLSR4TawG4++yzUxpI KqZApVW5p3z5SRoBjg8YPVmZUTfSW0jR9Z3m9FACU1P9WWfSRN7u46ONZ7mtrYqHZ//n ENK/mzXWUdgke2PGcJ49iZvp8zWfTxzqbyGMUYpm6/lvd9F6XKbU70izRrnf2VxkO4D3 Hdepj7swspZi2sLHIBLI5TS+mV8P9XuN6lnCmPRBmxIGS8e/Ev5xkKJ8y0Wb/8uGhyiN mL/Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=KZITXoL+uo9afzB3R8KLm8AQJYwI8d1Q4Ddl6CeSRXs=; b=YZSRqPbBY4mc7tWIDmzbWBLewpD6DNWBP9o/Kcjj6c8HmTN3TlvCYyVmOOP1iobcQY qZ+Zee9/6L5yyuwUxAEDAkS5FjGbXSU2nRoSwJIUCEQ2lVAEYlzIY9as812h2eC7Yk6j otMTvt7yxmz3pXtomc1XmeRPl/Lmah4cR+OwMYEOShXptf4jY/XmuaMKQu1B65XAXOkS jQZIGBCAiLEkCyoVURNHN4tCl8Ezt3aMqdK2OhwnaA66Dr8smjjpoxAGtVJ2KLDXRdbR ysRASbszb8XvvcYnc2QtMWGKBybMS3AYugv6nlan8wj5upphs7ZYF8+HMk91bftIWfYj aatw== X-Gm-Message-State: AD7BkJKg9+WyUfm0kmVHqCkt9vsAUzQrtaunb7xXxePUX8IF3lVgIDf27Yu3jTPM5rqWBsV0v+1ZbxjHNLzikrxh MIME-Version: 1.0 X-Received: by 10.202.242.2 with SMTP id q2mr17265643oih.137.1457450696775; Tue, 08 Mar 2016 07:24:56 -0800 (PST) Received: by 10.202.203.132 with HTTP; Tue, 8 Mar 2016 07:24:56 -0800 (PST) In-Reply-To: <13e7f67fe56c46b4d5d829e83d29a532@mail.gmail.com> References: <90e80f38b10a81626591d3cede931e35@mail.gmail.com> <13e7f67fe56c46b4d5d829e83d29a532@mail.gmail.com> Date: Tue, 8 Mar 2016 10:24:56 -0500 Message-ID: From: Neal Cardwell To: Karen Elisabeth Egede Nielsen Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tcpm@ietf.org" , draft-ietf-tcpm-cubic@ietf.org Subject: Re: [tcpm] Question on CUBIC and its TCP CC RFC basics X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 08 Mar 2016 15:25:03 -0000 On Tue, Mar 8, 2016 at 9:18 AM, Karen Elisabeth Egede Nielsen wrote: >> But at least in Linux that is not a change in the fast recovery code; that >> is a >> different approach the congestion control module uses to calculate the >> target cwnd that the fast recovery code (independent of the congestion >> control module) reaches at the end of recovery. >> > [Karen Elisabeth Egede Nielsen] hmm - not sure I understand this. I asume > that the CWND used _during_ FR is the 0.7*prior value CWND In Linux CUBIC the cwnd used during FR is determined by the Linux PRR code (RFC 6937), operating with an ssthresh value calculated by the congestion control module. > And that the factor 0.7 (opposed to RFC5681/RFC6675 factor 0.5 ) impacts the > fast recovery operation (assuming PRR not in) - while it does of course not > impact the fast retransmission code lines which presumably just related to > the CWND as updated by the CC logic - is that what you mean ? Yes. > Or do you mean to say that - in Linux implementation - the 0.7*prior CWND > only impacts the CC evaluations at the _end of_ recovery ? The 0.7x impacts behavior during recovery as well (though it is indirect, in the sense of setting a target number of packets to have in flight). > I think that you have confirmed that the time t starts at _end_ of fast > recovery - > Correctly understood ? Yes, the CUBIC t is measured relative to the end of fast recovery. neal From nobody Tue Mar 8 07:26:33 2016 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 9C68C12D77B for ; Tue, 8 Mar 2016 07:26:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=tieto.com Received: from mail.ietf.org ([127.0.0.1]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L08dFfHtK42U for ; Tue, 8 Mar 2016 07:26:30 -0800 (PST) Received: from mail-io0-x22f.google.com (mail-io0-x22f.google.com [IPv6:2607:f8b0:4001:c06::22f]) (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 7C77012D736 for ; Tue, 8 Mar 2016 07:26:29 -0800 (PST) Received: by mail-io0-x22f.google.com with SMTP id z76so29828489iof.3 for ; Tue, 08 Mar 2016 07:26:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tieto.com; s=google; h=from:references:in-reply-to:mime-version:thread-index:date :message-id:subject:to:cc; bh=5JqlESXdH1jav0+qEH5uveu1Nhee2KUPvShGvL9alek=; b=xmtLAtpXFxumY9d4uKD0zQkNqd+CsDYbRFmTxu8qjY1VoRoUfrtKS/ROTDR5inBno3 AzYN4zi7YWi80t0As3O1zB8QTEmLzpt41cc4rHSJZ+exLxbZ2kpGhr3ShWYmG+ZXgmsH bQiRSGhUDRAqXyE+Hs0qNxMJewqEk/4GznDNo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:references:in-reply-to:mime-version :thread-index:date:message-id:subject:to:cc; bh=5JqlESXdH1jav0+qEH5uveu1Nhee2KUPvShGvL9alek=; b=m8O0QoddmxaH7eKFg/mT7LZgvMxnTz9DECfpoVpeqs/Art5/od++AoG4nxdYGUcDVK hPyhOBaUngLzyfB9K1r/vT6j7bzpk6KkDOhjt5Who2ALrS0uBaTh5ufFYj21TkdLUWQW I9l9rjhCj1/RhWq0K5f5GZnzWXTpLKa1UT4NTi71zPbUc7+B7NN3f3/ZIAoYJIQufj05 3PQnYIFNvBBZLskE0KQFn0rOIc2LcHB2fwuI9bxZ3sULJE/6svPK0em6LlEzKgLbrteu KNL3FzohlPd3MRyv/3hnGmbX2ihC/AoVwdn+C2sBZIsl4Y6GrNq6PEJJ6xRqYrLFuLHq Un3g== X-Gm-Message-State: AD7BkJKIPRUV5G3NqfqTyjxPQACVuG2aif++7VLQyEX7lBPIDo87SbAri3Q+w34TpUNA4geUbLTc8x+2q/cgHoVcBM4ExW6GB9ufKmJH2omgv9zDii4Lb/aa4sNlFTai2GKH/Io= X-Received: by 10.107.157.70 with SMTP id g67mr25422808ioe.38.1457450788491; Tue, 08 Mar 2016 07:26:28 -0800 (PST) From: Karen Elisabeth Egede Nielsen References: <90e80f38b10a81626591d3cede931e35@mail.gmail.com> <13e7f67fe56c46b4d5d829e83d29a532@mail.gmail.com> In-Reply-To: MIME-Version: 1.0 X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQIalpcGbWSSO5ocbu2GX5HnKQuzVgFTaC3bAaa6LhUBqgFBOZ6YT1ow Date: Tue, 8 Mar 2016 16:26:27 +0100 Message-ID: <3bf7151e9a9bda38c07af8a620e9d5ab@mail.gmail.com> To: Neal Cardwell Content-Type: text/plain; charset=UTF-8 X-DomainID: tieto.com Archived-At: Cc: tcpm@ietf.org, draft-ietf-tcpm-cubic@ietf.org Subject: Re: [tcpm] Question on CUBIC and its TCP CC RFC basics X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 08 Mar 2016 15:26:31 -0000 Hi Neal, Great ! Many thanks for the information. BR, Karen > -----Original Message----- > From: Neal Cardwell [mailto:ncardwell@google.com] > Sent: 8. marts 2016 16:25 > To: Karen Elisabeth Egede Nielsen > Cc: tcpm@ietf.org; draft-ietf-tcpm-cubic@ietf.org > Subject: Re: [tcpm] Question on CUBIC and its TCP CC RFC basics > > On Tue, Mar 8, 2016 at 9:18 AM, Karen Elisabeth Egede Nielsen > wrote: > >> But at least in Linux that is not a change in the fast recovery code; > >> that is a different approach the congestion control module uses to > >> calculate the target cwnd that the fast recovery code (independent of > >> the congestion control module) reaches at the end of recovery. > >> > > [Karen Elisabeth Egede Nielsen] hmm - not sure I understand this. I > > asume that the CWND used _during_ FR is the 0.7*prior value CWND > > In Linux CUBIC the cwnd used during FR is determined by the Linux PRR code > (RFC 6937), operating with an ssthresh value calculated by the congestion > control module. > > > And that the factor 0.7 (opposed to RFC5681/RFC6675 factor 0.5 ) > > impacts the fast recovery operation (assuming PRR not in) - while it > > does of course not impact the fast retransmission code lines which > > presumably just related to the CWND as updated by the CC logic - is that > what you mean ? > > Yes. > > > Or do you mean to say that - in Linux implementation - the 0.7*prior > > CWND only impacts the CC evaluations at the _end of_ recovery ? > > The 0.7x impacts behavior during recovery as well (though it is indirect, > in the > sense of setting a target number of packets to have in flight). > > > I think that you have confirmed that the time t starts at _end_ of > > fast recovery - Correctly understood ? > > Yes, the CUBIC t is measured relative to the end of fast recovery. > > neal From nobody Tue Mar 8 18:53:33 2016 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 70A2412D7ED; Tue, 8 Mar 2016 18:53:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=uofnelincoln.onmicrosoft.com Received: from mail.ietf.org ([127.0.0.1]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g8KJj5T5EQqH; Tue, 8 Mar 2016 18:53:29 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0187.outbound.protection.outlook.com [207.46.163.187]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24FBA12DDB4; Tue, 8 Mar 2016 18:53:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uofnelincoln.onmicrosoft.com; s=selector1-unl-edu; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=1liuvjS3JAIlW9xgaUY/LA1wedAO+5m5B/y0e5zLVEM=; b=UsHz53Gr0mlroVFa5hTnPZW8s3JapK7wxHT3OuRW3iiI14c+pm1I2heCe+wlNsRErHIduFrdDuNdFcCVMpGyQyWbmslQgmHSawigfqcslyRFWaaus3hDs3+Q/fsSpFVXsaMjCKDE0mTCof/vBHmlKrZql7HevowdukCIvmcsGY4= Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=unl.edu; Received: from [192.168.0.164] (97.98.140.59) by SN1PR08MB1471.namprd08.prod.outlook.com (10.162.2.139) with Microsoft SMTP Server (TLS) id 15.1.434.16; Wed, 9 Mar 2016 02:53:25 +0000 To: Neal Cardwell , Karen Elisabeth Egede Nielsen References: <90e80f38b10a81626591d3cede931e35@mail.gmail.com> <13e7f67fe56c46b4d5d829e83d29a532@mail.gmail.com> <28921_1457450716_u28FPF2J024715_CADVnQymVHbe24Tpv1TsK4XGa1nyxhAv3sKfKudr3uxYFOEtCdA@mail.gmail.com> From: Lisong Xu Organization: University of Nebraska-Lincoln Message-ID: <56DF9033.8090205@unl.edu> Date: Tue, 8 Mar 2016 20:53:39 -0600 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <28921_1457450716_u28FPF2J024715_CADVnQymVHbe24Tpv1TsK4XGa1nyxhAv3sKfKudr3uxYFOEtCdA@mail.gmail.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [97.98.140.59] X-ClientProxiedBy: BY2PR1001CA0081.namprd10.prod.outlook.com (25.164.163.49) To SN1PR08MB1471.namprd08.prod.outlook.com (25.162.2.139) X-MS-Office365-Filtering-Correlation-Id: 59b4c24b-7f86-4935-13b1-08d347c5fce6 X-Microsoft-Exchange-Diagnostics: 1; SN1PR08MB1471; 2:k+wOnIqQoR/KdqqW/jaPhojOnBdLscwIkLLB9Ie3CtYk1NhbqhQF0QjL7ZH4LsNmhDxbYq+9cMF3hZVb9qDtBzoc9gmyZDFNf/u2GTRbrNeBfGjUJIvgCv147TsP91q937wnzTHHORSo1faAXs6ZtXHMVLGcPueaQb/AnQ9WivT2osKV3i51z1rHNPD4x+NW; 3:adD7SQcwDzhZ8Q9uV+PYFBzuXtm2cg53mH+x+TfpzEDHPY/DXdSU99JuCX2d7XS0DWoIWPD6bV1L2zzhxpuU9aPH8xV1XIPTz8obYTqlPLd/4M7TdnjuZ2tnzEDsgCFH; 25:8D8XF4qlQFrTP4yrsPQ6ZnecEK2TxAAL632WXTqZUhZOzSOmmIvMadb9G8PeZn7yJwiQL+XS4B0ecevBuvYEYc5yADjEGMhCU9GEZ6dREdsvT0UNVaqUukc1soGXhEXe03fksZaNy7p6pAjEfcZbItIoQ6/utNuVjXafdf/PVgpo2VettnxCx4gt9T+OtyVt2z/rUcYqnSidhb2+ZrIrC0BiGhmTHmf/UHOXiPNl+4E+4UvJAYRDQRTtktXK9DyQBOxli39zoDlif84dcKbZNU696SGfOM6cNrpiohvPNUw0yvIWje8HrF225pXimBBw1MD0n4WbXgQEiicCkbS+Ug== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN1PR08MB1471; X-Microsoft-Exchange-Diagnostics: 1; SN1PR08MB1471; 20:ATbA4XiPmH0840OwLjQPAclF7pzay8l+A8DWLMB4sTD5nPnYBcF7ds+7M15UBBqI4i5sy/hQbgMS+xNOSGuyfDv+RZty75n9wAkiXuO49gSulzOsmaoaXFlV8zJWsa8mOZ82kfI1feSdiF6T4bsyyoiljW9PPPghr+lcNLdpdliP6t7SRhyv3WztGePiL6MVXkxAzHVSi458w0LGn7q63+dRkI+el+SywKAXi9x98zklU+HDeC5qfE5BzwU8zcWStuCq18+OGReNQ5GESp0cDbd2sQZGGciFVlcdmrQns470RhkB2E5Ro2fRTPJM/ST2JmPA0tKBpILTJ2XkgmzkgNKxA8So/30X93ywEFcwSSe/hedpIO2O1BUjbiOY4ehA4UYoIpd1+/D+GSgmx7hgc093+9FuMBId4JI3ep0S1nkjkcA2KDOSMSUZwR9YBUkm4gre5ZrUjcwMpP/wHQTFM1E2qr9cGJR4BIo20G6Ew/ah2a1q6Sqp5CTrjrO6vXrg; 4:DDvj9p32xM+MEEjQEY27u3o30PgvgAxa6ahF5aIlIQn5SPSnfo+Bjjiua2Ncjy1rcUs3w04n+W8WXVn4t5ofT6s7CgEm8rSMlBWQ8ZlTt1RKAKAtaYcDp8i3/DrKR7zE3TOe4a3PAMqru4/eIeGGY7bshsKzXnJpqhz9du3X6iQOQAYydMUIV9Ch7vlrWWoui5e8jgsfX21oYX5XMvo5Z2/tqYWvkGgaKxMFsU4DtGh6d62ScTnG+uT20Stv5Y8CgzyvqEyJ2wAH7+aFAcvTogsHpR9PuKdslB4x5TDCBJ5OfEU2h7cbDm17hOZyEStItk1VvncRx+dvlMePz/2Vv2d70tWerYZ4AmkAxHrZU0fOAXXUy2T/tp42D4s3rug7 X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001); SRVR:SN1PR08MB1471; BCL:0; PCL:0; RULEID:; SRVR:SN1PR08MB1471; X-Forefront-PRVS: 0876988AF0 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(6049001)(479174004)(377454003)(24454002)(51444003)(164054003)(93886004)(81166005)(75432002)(65816999)(47776003)(42186005)(50466002)(66066001)(65806001)(65956001)(92566002)(23676002)(64126003)(4326007)(586003)(90282001)(189998001)(5001770100001)(4001350100001)(33656002)(1096002)(86362001)(5008740100001)(88552002)(6116002)(3846002)(89122001)(117156001)(76176999)(50986999)(54356999)(87266999)(2906002)(5004730100002)(83506001)(2950100001)(80316001)(36756003)(19580395003)(19580405001)(77096005)(230700001); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1PR08MB1471; H:[192.168.0.164]; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtTTjFQUjA4TUIxNDcxOzIzOjlWMDN2b1ZzNzdueDBDb3BMeEtET1VJcGVx?= =?utf-8?B?RWROMXMvMXEyOGNYYkNmTHIvbjgxY0Y2UTlIZWkyODN6dlBtWWhudTBjVE4y?= =?utf-8?B?QXpCL1NEZUkyRU10ZGwxZGdFT1NzQmYzYjdvcW9ZR1IwSThINitZQjlybTh5?= =?utf-8?B?Um9CYzU2elhpaDkxQ0tqK1Z5NGl2TVhsV3Q2RlhxbWVLQ1licDZ0b2dXWWw0?= =?utf-8?B?Tmx5WmJ5MHlROHArWDlwMjhFV3FqVFYzQUJVUFpxeUdueVIxc1ZtTktkL21D?= =?utf-8?B?UittaVE1eXBkaGdRWENUQVk1Q0Fyd3pRZnlISWxEZHlMNU50RkNpUlZjZDBp?= =?utf-8?B?dUtsam5aUGV0d29GZGtXWS9kTGNDbWZieWxWZkRMejRMOTVWZ2J4elI4b3Fs?= =?utf-8?B?S3N6Y0luTm90LzZoNjVteVZGcFRqR295RDRNa3pVN0hoL3JLN1pTc3dXdTVm?= =?utf-8?B?QUJIMzhkUUZheGpBVmd4RzM4ck0xVmRONWo3cGZCMTdJRWFtUkF6RlQvdm9Z?= =?utf-8?B?ZTd6TkNiZHJQZzVHVkpkQzRPd0JLK2VqdmlzOFNTZTBrbXlTTTlhNjNzay9L?= =?utf-8?B?SjJ6Q0U0WVJJZUZzVlByemRFMVZJMFo3dEN4bmhra3dJQ0FIRHcrcDErbmdU?= =?utf-8?B?VDZINURQWTBpeEJlSUJ3VWVrdVltVUhVaUFjNzNndit2LzIwQXJlMWxJcnds?= =?utf-8?B?cXZxU21WcUwrTFNlaUZvODFodDNXRC9IejFxSVZPNmhiUTNMSGdBYXI5dDNI?= =?utf-8?B?M3dQakE0dDZKL3RBU2wxM0t3bUpEVDUyZENDOXNCUXZHU2EwR29JWlRSZVFD?= =?utf-8?B?WE90dWFCenZzNUl5UEVaSGVuMTBpTXlmeHdWbkNlcVl0blNTcFpQaFUzeEJH?= =?utf-8?B?NTBxWGJoT0tNNnRVYm5RTkt4eWpTOVVQbi9uQU1FenJiVUR4OFlkMEhoZ0s5?= =?utf-8?B?VDJ3WjNyenFTUjg0R3J1RkYxWEorcGFNNUdMZ3hPdEdJblhBVU1sNHBITWZU?= =?utf-8?B?R1NGczl5UlJ5c0gwVmphQlVJVndxTEV4TVNDRXpSNVBVM0ZHdlRVSGRZWTND?= =?utf-8?B?VnlwQXFTV1JydmZTd0ZoOWZCVVBuWnNhT250VXpDdVlIQXB6WVA3cjIzZVJw?= =?utf-8?B?YmtoWE1peUI3eUd4d2FISzRsYzVkZHJJOXFyWHFKNGpiL1pVNWNuTjdsWFl5?= =?utf-8?B?SlZTODZPSnBhSVMxTzkzNkxOZldxVlJKWWFDRlNZbXZGTEZyb1RoSmNOUm0x?= =?utf-8?B?U0N3eG81MzFoRi9BT0Ewd0p0eFpmZUhPcVJSRFJrWFBjSGhrckMrZUFjZ09r?= =?utf-8?B?VkNwUTFFdDdMUHB4dDM4VWNqWHEvbUUzeGIrQnJiL3dTQTZCTm01dEdQVkNL?= =?utf-8?B?VW9DeGtRT1ozaWFmRzhxNWdMMUROTHJ5TlN0VFJ3SmRvRlcwejVKNGw4bzBM?= =?utf-8?B?WEdkcE1ETk9uNmpoa3RmbDZsNW5LL3RjQitKd1BDU3NGS2tScjZhRjRsWGd6?= =?utf-8?B?S3dmMW95cElLVUUrb1hlUUdYNjhmNjB5RWpSSGkzTCtzMkFPaHZBdEtpWEs5?= =?utf-8?B?TVc5c2lzaXhzTW82alhuZ0Z2WVdUTjlLN0plWU1hQXhqZ3Vmai85WWI5bzk3?= =?utf-8?B?T3ZoZThRK3lrQkhBOVUvWHg5UU1jQ0FMOFNBMVA4dm9HYXdCeWwvQUNhU2py?= =?utf-8?B?bkJvQ0h6ekkwSERYendDbGppNE54MVVndmhMMDhobkN5YlBJZG5PV3lhMnFC?= =?utf-8?B?VE80ZXJsQTVyS1lmZ1Z1Zz09?= X-Microsoft-Exchange-Diagnostics: 1; SN1PR08MB1471; 5:7//eO9z1MjUjazaOGepkrfes7F9zn5LqKRheXKYsbXxuY/+7BSF4YlGwG1cd+IAw3VBjp4M7aNrZCxOf48GwoOu9U1925IA/uqXJgrMgBfUZ6SlbO2vMCtMTUySVoEpctaH0POHgaacDT2Y24wTEpQ==; 24:+igAX8FwY2zDBFm3Ixc9C3Tv0rM043g2QDPRMqCzcZab3z1vhh78IASjyCP9qtFAjDG31PQe7siyJ2Uviw5t+/lYRZ5pxYqztaRqKFPjbdY= SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: unl.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 Mar 2016 02:53:25.8000 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR08MB1471 Archived-At: Cc: "tcpm@ietf.org" , draft-ietf-tcpm-cubic@ietf.org Subject: Re: [tcpm] Question on CUBIC and its TCP CC RFC basics X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 09 Mar 2016 02:53:31 -0000 Thanks, Neal, for answering these questions. I was on my trip the whole day, and just came back to home. Lisong On 3/8/2016 9:24 AM, Neal Cardwell wrote: > On Tue, Mar 8, 2016 at 9:18 AM, Karen Elisabeth Egede Nielsen > wrote: >>> But at least in Linux that is not a change in the fast recovery code; that >>> is a >>> different approach the congestion control module uses to calculate the >>> target cwnd that the fast recovery code (independent of the congestion >>> control module) reaches at the end of recovery. >>> >> [Karen Elisabeth Egede Nielsen] hmm - not sure I understand this. I asume >> that the CWND used _during_ FR is the 0.7*prior value CWND > In Linux CUBIC the cwnd used during FR is determined by the Linux PRR > code (RFC 6937), operating with an ssthresh value calculated by the > congestion control module. > >> And that the factor 0.7 (opposed to RFC5681/RFC6675 factor 0.5 ) impacts the >> fast recovery operation (assuming PRR not in) - while it does of course not >> impact the fast retransmission code lines which presumably just related to >> the CWND as updated by the CC logic - is that what you mean ? > Yes. > >> Or do you mean to say that - in Linux implementation - the 0.7*prior CWND >> only impacts the CC evaluations at the _end of_ recovery ? > The 0.7x impacts behavior during recovery as well (though it is > indirect, in the sense of setting a target number of packets to have > in flight). > >> I think that you have confirmed that the time t starts at _end_ of fast >> recovery - >> Correctly understood ? > Yes, the CUBIC t is measured relative to the end of fast recovery. > > neal From nobody Wed Mar 9 02:26:09 2016 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 A695612D8DE for ; Wed, 9 Mar 2016 02:26:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=tieto.com Received: from mail.ietf.org ([127.0.0.1]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JL_jSLq65EoW for ; Wed, 9 Mar 2016 02:26:04 -0800 (PST) Received: from mail-io0-x234.google.com (mail-io0-x234.google.com [IPv6:2607:f8b0:4001:c06::234]) (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 098AA12D5DE for ; Wed, 9 Mar 2016 02:26:03 -0800 (PST) Received: by mail-io0-x234.google.com with SMTP id n190so60547559iof.0 for ; Wed, 09 Mar 2016 02:26:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tieto.com; s=google; h=from:references:in-reply-to:mime-version:thread-index:date :message-id:subject:to:cc; bh=URSGnQzL37Vlg9pAdpuvnnCSYbRfMCae4eGj0/wq730=; b=YVIpTnsPkmLuusQ365ndjb8KSZKmocnBaMd8zt+jpoMPz+BgpT9DADLFwlwy+0Biu2 w9PFImUH7FGbbNUHMurhoiLE7Xhh0qeC1rq8bMisPKR69wCfUjPYsxNZpL9wLRaUh8rS pWUg/WNild8HY8OzIBNN4afR8kRTjRthKx3FI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:references:in-reply-to:mime-version :thread-index:date:message-id:subject:to:cc; bh=URSGnQzL37Vlg9pAdpuvnnCSYbRfMCae4eGj0/wq730=; b=ke8HA4BkDGgNfl20OXIzE31/R61qDXgsndaDijmflb2OvPHnouGRVPEsdofoTKZEfU 13zzg8esgRxVrlwKfWYavICqkUwSm510ItZC2+MrwFbAZNQzsEe69/cCtg9ajn0tJTR4 KUwAAzWGLoC1oueTdS6leUeVDr+QdFxEb1lLECexVbDaFhoPOReWfPY9dDTPmhVOw+IX 6ms5i5zpkSyJ+vFGoj9+4zm8/Br4YW56Ps7r6xtpp6X4NCUS4BsfWfLGV6ZC0jzwthUy Nhuz59lztENME/f1db2305u0gaQOu/WG9XXhTInM9lgD9A6bxb5knyovCJV8C/Rv+ByD 4xHg== X-Gm-Message-State: AD7BkJLynF+xwR7NBlbw2aQHXvACUw2gTdzKXp6QH+cWUNxg0XkbxdFMJMeZ1WirVyvzDSUE8aiQYAd9wwZKUAN++0UvvQCdNq4eOa4kI+1YocoHaJpZjwKS7n9st/VsPA2crCw= X-Received: by 10.107.157.70 with SMTP id g67mr29565349ioe.38.1457519162525; Wed, 09 Mar 2016 02:26:02 -0800 (PST) From: Karen Elisabeth Egede Nielsen References: <90e80f38b10a81626591d3cede931e35@mail.gmail.com> <13e7f67fe56c46b4d5d829e83d29a532@mail.gmail.com> <28921_1457450716_u28FPF2J024715_CADVnQymVHbe24Tpv1TsK4XGa1nyxhAv3sKfKudr3uxYFOEtCdA@mail.gmail.com> <56DF9033.8090205@unl.edu> In-Reply-To: <56DF9033.8090205@unl.edu> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQIalpcGbWSSO5ocbu2GX5HnKQuzVgFTaC3bAaa6LhUCVRGaNgKL5105nn/OzHA= Date: Wed, 9 Mar 2016 11:26:00 +0100 Message-ID: <89a1b31e152a6cb038389eaef39e21fc@mail.gmail.com> To: Lisong Xu , Neal Cardwell Content-Type: text/plain; charset=UTF-8 X-DomainID: tieto.com Archived-At: Cc: tcpm@ietf.org, draft-ietf-tcpm-cubic@ietf.org Subject: Re: [tcpm] Question on CUBIC and its TCP CC RFC basics X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 09 Mar 2016 10:26:07 -0000 HI Neal, Lisong, others Thank you both. Sorry for asking "stupid" questions, but could you be so kind as to comment on the following also, :-): My simple understanding of CUBIC CC (with ABC glasses on) is that instead of incrementing CWND by 1 MTU/MSS per CWND bytes acknowledged, CUBIC CC dictates to increment CWND by 1 MTU per MTU*CWND/(CUBIC_target - CWND) bytes acknowledged. (here CUBIC_Target=W(t+RTT) calculated in bytes)) Can you help me understand why the "TCP friendliness" relates to an average Reno window at a given time and not just simply to that at any given time ( CWND_cnt_bytes =) MTU*CWND/(CUBIC_target - CWND) should be clamped by CWND. I.e., never be allowed to go higher than CWND - ? Perhaps this is just a (choice of) implementation issue (?) - If there are logical reason then I am probably just missing something.... Many Thanks in advance. BR, Karen > -----Original Message----- > From: Lisong Xu [mailto:xu@unl.edu] > Sent: 9. marts 2016 03:54 > To: Neal Cardwell ; Karen Elisabeth Egede Nielsen > > Cc: tcpm@ietf.org; draft-ietf-tcpm-cubic@ietf.org > Subject: Re: [tcpm] Question on CUBIC and its TCP CC RFC basics > > Thanks, Neal, for answering these questions. I was on my trip the whole > day, and just came back to home. > Lisong > > On 3/8/2016 9:24 AM, Neal Cardwell wrote: > > On Tue, Mar 8, 2016 at 9:18 AM, Karen Elisabeth Egede Nielsen > > wrote: > >>> But at least in Linux that is not a change in the fast recovery code; > >>> that > >>> is a > >>> different approach the congestion control module uses to calculate the > >>> target cwnd that the fast recovery code (independent of the congestion > >>> control module) reaches at the end of recovery. > >>> > >> [Karen Elisabeth Egede Nielsen] hmm - not sure I understand this. I > asume > >> that the CWND used _during_ FR is the 0.7*prior value CWND > > In Linux CUBIC the cwnd used during FR is determined by the Linux PRR > > code (RFC 6937), operating with an ssthresh value calculated by the > > congestion control module. > > > >> And that the factor 0.7 (opposed to RFC5681/RFC6675 factor 0.5 ) > >> impacts > the > >> fast recovery operation (assuming PRR not in) - while it does of course > >> not > >> impact the fast retransmission code lines which presumably just related > >> to > >> the CWND as updated by the CC logic - is that what you mean ? > > Yes. > > > >> Or do you mean to say that - in Linux implementation - the 0.7*prior > CWND > >> only impacts the CC evaluations at the _end of_ recovery ? > > The 0.7x impacts behavior during recovery as well (though it is > > indirect, in the sense of setting a target number of packets to have > > in flight). > > > >> I think that you have confirmed that the time t starts at _end_ of fast > >> recovery - > >> Correctly understood ? > > Yes, the CUBIC t is measured relative to the end of fast recovery. > > > > neal From nobody Wed Mar 9 07:21:01 2016 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 DB75212E0B6 for ; Wed, 9 Mar 2016 07:01:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=tieto.com Received: from mail.ietf.org ([127.0.0.1]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 445k0FKe61_m for ; Wed, 9 Mar 2016 07:01:22 -0800 (PST) Received: from mail-ig0-x230.google.com (mail-ig0-x230.google.com [IPv6:2607:f8b0:4001:c05::230]) (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 027B912D71A for ; Wed, 9 Mar 2016 06:55:46 -0800 (PST) Received: by mail-ig0-x230.google.com with SMTP id ig19so80410292igb.0 for ; Wed, 09 Mar 2016 06:55:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tieto.com; s=google; h=from:references:in-reply-to:mime-version:thread-index:date :message-id:subject:to:cc; bh=FOLUk+vq+fTlSkLZWtYllJoVMRBRRi4BfONqZyp4duQ=; b=1vdNgFJLaz+DKresmYhRsCqtyZKMb4QvMvs9bbMhCNoBZ4YBpJJprLtVq32fjytZ6k ogds+wynBj/8Rh/qR5apo9LcN0HR3kP/0np7SXSL6+T568cUpp0GOyGrjZl4p1W6+BLc dzwcZPtp6ljPAmLfCnOgXaR/aappuLxG/Rcp0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:references:in-reply-to:mime-version :thread-index:date:message-id:subject:to:cc; bh=FOLUk+vq+fTlSkLZWtYllJoVMRBRRi4BfONqZyp4duQ=; b=UYSsImna4wLMDEQPBkEqTFO3T24F6fUq++5VLTDiBHeaz2uZ7PSmxgJ/G+iykcyqxV Ab6UCNyy3bIDcV33Zr6sdbbaNVQiMxowQYvD+zpH4UIWWnB5mS+Dl/tT3Z7yoLf/thRH x56LOwHdDnyq5rHN6MVEAMm4mHkybPifJtdmaQ1zjluxSIGJ75CClQoPPy1BgsZDyGiL XXXKwwgCf5VsCGpoFrrbhTAzyGoGNuwN1hy/yTTuMeMRTNXerPEPcCePBhqfHbq0gxJz D7QpGGtFQxUn7tv0erWY68c25hPT1eG2QWYGuP4dIiMZ8chHPgQhd2vVAXJVfAeXv24W d5eQ== X-Gm-Message-State: AD7BkJI/gc6fuSuD+js2Aw+Mj/qYwKcMupt1Sa3c1aJxg0WXDuySllZJj2byxbQzydx0EttmhEc8MFeEzbRa5n7Yjr7w6zwKtC+TUWNSvCSHu5tpCzAjJraIkG7DrTwo0uo6dYg= X-Received: by 10.50.43.194 with SMTP id y2mr24772837igl.96.1457535345783; Wed, 09 Mar 2016 06:55:45 -0800 (PST) From: Karen Elisabeth Egede Nielsen References: <90e80f38b10a81626591d3cede931e35@mail.gmail.com> <13e7f67fe56c46b4d5d829e83d29a532@mail.gmail.com> <28921_1457450716_u28FPF2J024715_CADVnQymVHbe24Tpv1TsK4XGa1nyxhAv3sKfKudr3uxYFOEtCdA@mail.gmail.com> <56DF9033.8090205@unl.edu> 89a1b31e152a6cb038389eaef39e21fc@mail.gmail.com In-Reply-To: 89a1b31e152a6cb038389eaef39e21fc@mail.gmail.com MIME-Version: 1.0 X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQIalpcGbWSSO5ocbu2GX5HnKQuzVgFTaC3bAaa6LhUCVRGaNgKL5105nn/OzHCAAFJQ0A== Date: Wed, 9 Mar 2016 15:55:44 +0100 Message-ID: <8db278c9afd8c2cd18e8315bcf41bb62@mail.gmail.com> To: Lisong Xu , Neal Cardwell Content-Type: text/plain; charset=UTF-8 X-DomainID: tieto.com Archived-At: Cc: tcpm@ietf.org, draft-ietf-tcpm-cubic@ietf.org Subject: Re: [tcpm] Question on CUBIC and its TCP CC RFC basics X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 09 Mar 2016 15:01:45 -0000 HI, Sorry for thinking load here. .. I understand that the slope by purpose should be lower around wmax. Sorry. BR, Karen > -----Original Message----- > From: Karen Elisabeth Egede Nielsen [mailto:karen.nielsen@tieto.com] > Sent: 9. marts 2016 11:26 > To: 'Lisong Xu' ; 'Neal Cardwell' > Cc: 'tcpm@ietf.org' ; 'draft-ietf-tcpm-cubic@ietf.org' > ietf-tcpm-cubic@ietf.org> > Subject: RE: [tcpm] Question on CUBIC and its TCP CC RFC basics > > HI Neal, Lisong, others > > Thank you both. > > Sorry for asking "stupid" questions, but could you be so kind as to > comment > on the following also, :-): > > My simple understanding of CUBIC CC (with ABC glasses on) is that instead > of > incrementing CWND by 1 MTU/MSS per CWND bytes acknowledged, CUBIC > CC dictates to increment CWND by 1 MTU per MTU*CWND/(CUBIC_target - > CWND) bytes acknowledged. > (here CUBIC_Target=W(t+RTT) calculated in bytes)) > > Can you help me understand why the "TCP friendliness" relates to an > average Reno window at a given time and not just simply to that at any > given > time ( CWND_cnt_bytes =) MTU*CWND/(CUBIC_target - CWND) should be > clamped by CWND. > I.e., never be allowed to go higher than CWND - ? > > Perhaps this is just a (choice of) implementation issue (?) - If there > are logical > reason then I am probably just missing something.... > > Many Thanks in advance. > > BR, Karen > > > -----Original Message----- > > From: Lisong Xu [mailto:xu@unl.edu] > > Sent: 9. marts 2016 03:54 > > To: Neal Cardwell ; Karen Elisabeth Egede > > Nielsen > > Cc: tcpm@ietf.org; draft-ietf-tcpm-cubic@ietf.org > > Subject: Re: [tcpm] Question on CUBIC and its TCP CC RFC basics > > > > Thanks, Neal, for answering these questions. I was on my trip the > > whole day, and just came back to home. > > Lisong > > > > On 3/8/2016 9:24 AM, Neal Cardwell wrote: > > > On Tue, Mar 8, 2016 at 9:18 AM, Karen Elisabeth Egede Nielsen > > > wrote: > > >>> But at least in Linux that is not a change in the fast recovery > > >>> code; that is a different approach the congestion control module > > >>> uses to calculate the target cwnd that the fast recovery code > > >>> (independent of the congestion control module) reaches at the end > > >>> of recovery. > > >>> > > >> [Karen Elisabeth Egede Nielsen] hmm - not sure I understand this. I > > asume > > >> that the CWND used _during_ FR is the 0.7*prior value CWND > > > In Linux CUBIC the cwnd used during FR is determined by the Linux > > > PRR code (RFC 6937), operating with an ssthresh value calculated by > > > the congestion control module. > > > > > >> And that the factor 0.7 (opposed to RFC5681/RFC6675 factor 0.5 ) > > >> impacts > > the > > >> fast recovery operation (assuming PRR not in) - while it does of > > >> course not impact the fast retransmission code lines which > > >> presumably just related to the CWND as updated by the CC logic - is > > >> that > what you mean ? > > > Yes. > > > > > >> Or do you mean to say that - in Linux implementation - the > > >> 0.7*prior > > CWND > > >> only impacts the CC evaluations at the _end of_ recovery ? > > > The 0.7x impacts behavior during recovery as well (though it is > > > indirect, in the sense of setting a target number of packets to have > > > in flight). > > > > > >> I think that you have confirmed that the time t starts at _end_ of > > >> fast recovery - Correctly understood ? > > > Yes, the CUBIC t is measured relative to the end of fast recovery. > > > > > > neal From nobody Wed Mar 9 07:40:51 2016 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 CEED112E276; Wed, 9 Mar 2016 07:39:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=uofnelincoln.onmicrosoft.com Received: from mail.ietf.org ([127.0.0.1]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PD9ZGNoUWxGe; Wed, 9 Mar 2016 07:39:56 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0185.outbound.protection.outlook.com [207.46.163.185]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CE7B12E27C; Wed, 9 Mar 2016 07:23:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uofnelincoln.onmicrosoft.com; s=selector1-unl-edu; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=YkQG7tT+pzTQyjIPHpivGua0g8TaT5fohHGeeKBjghs=; b=InLPEQVL/pXrXIreo2KR+78NJIwedORiOPRfA/kRymibHzEWB8MIPN7oIAUWxlx3KoKqOqxWKkhE0qyHQACeMDETRhYjamWqJp3ILuW5asktV0roYeTLfeafqAslvCT2O2GLJJddDSWBkh6WFsFjXzspkDOjNulYOOqUMmlb1ME= Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=unl.edu; Received: from [192.168.0.164] (97.98.140.59) by SN1PR08MB1471.namprd08.prod.outlook.com (10.162.2.139) with Microsoft SMTP Server (TLS) id 15.1.434.16; Wed, 9 Mar 2016 15:22:57 +0000 To: Karen Elisabeth Egede Nielsen References: <90e80f38b10a81626591d3cede931e35@mail.gmail.com> <13e7f67fe56c46b4d5d829e83d29a532@mail.gmail.com> <28921_1457450716_u28FPF2J024715_CADVnQymVHbe24Tpv1TsK4XGa1nyxhAv3sKfKudr3uxYFOEtCdA@mail.gmail.com> <56DF9033.8090205@unl.edu> <89a1b31e152a6cb038389eaef39e21fc@mail.gmail.com> From: Lisong Xu Organization: University of Nebraska-Lincoln Message-ID: <56E03FE0.4090407@unl.edu> Date: Wed, 9 Mar 2016 09:23:12 -0600 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <89a1b31e152a6cb038389eaef39e21fc@mail.gmail.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [97.98.140.59] X-ClientProxiedBy: BY2PR1001CA0065.namprd10.prod.outlook.com (25.164.163.33) To SN1PR08MB1471.namprd08.prod.outlook.com (25.162.2.139) X-MS-Office365-Filtering-Correlation-Id: 5f6b5daa-bd4e-438e-3100-08d3482eb24b X-Microsoft-Exchange-Diagnostics: 1; SN1PR08MB1471; 2:beR+f6+c4AkGE779jdnMz4BURiEMf2uIsSRwOXiFKVWb+z+NX6wmJIyhPSGmhvnivQoJi3ajGnIgv/R/fZ1vxN71obGvboDDnYnf7PUJxFOJE6kwFWbgbLm8H2j8iQI+0ouW5IE9xbBT5eFvLek/mJt7QjCjez+mXqfqmaidJgSQx5T2+B66m6kP3uC5iSr8; 3:v0CPUKTZg+mzgaq3gbbr5B23mWIYF/3sLFRNYj06MyNwKyZa3ND/lI/nMRGVGEhbM3M4TB+W3TpKJ5N6uw8KPP9ZV/zeKi+sZg9n5sBtTWc538R+NWRu719dT8Mx+Otk; 25:FH1Ngcr/A7fIKTQOfwMLWwDw8FkSsJ22UG39TRWGMTHFoMTswKuoQUL4DGCjgMX4knbbrzrE33NqGgZWoTonyqOSOPLpYePKRjdD7BfV0MUtTta0uf6KaKwTB7FkTXqefhRAss0SB+WWKxSNpLrbEgtset6NibxtYj3xJlpC1QGlt8rde6q5PiSZvsGWmuXLw7iC5vRoniX13PtYwuQigHfjoXbuMwcUMe3Hsm49CoU0p7NgsOboQzmdj8uvIsteXjyXaZCdwPdFl59a1cJBO+UBfZskmcJGgAGQaPmYeh1EEQQOyxRosinAYMN/GIJ6uHoweflMzq78rQcrrmFGVYD2qFdYELRzeAZ8Fcj399c= X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN1PR08MB1471; X-Microsoft-Exchange-Diagnostics: 1; SN1PR08MB1471; 20:edGvI1IVVhoH05MTbIYSyYYxv1/ZP3kHHZ03ts3eGR8Oz8t3SxmYe7iPS716jpaeIGyrcJFMP26cZgM7Mn/113ku4R1EkBIE0CJhUpfPtzQx/D19fE5a5O19npP8tZiKEqva0XQlayS1E22tJU6MOAEE95ZzeCjgwDLXcFEZGOkOg/lEyXCbLN4Dz1KZodQ0j8ApbNZQPhNvnzbbnQOPzOHk9nIdxjbVFyAp9pOYX9/oQAZUmHQBJfNxaDtpLyvWbjC5QbP17DKbpdVIUFxHFrJ1txCKV0+AR/Dw73S2ouvZttJK+ZLExRFxGGwAWd9HmIkWBlPNvGu3H2uUfBgqZEa2PiXI5ca86dkD24g3suIqZ68zMInkfZcQnAe7lOMnkViosu77FFSzFv3+Q0YMncs08HKAvD4y6p2vgNi1941Xa1xzIcseGgKkrPAfhEKx8KBiyp22zfFvZIZYwaIqP75X3AGTlNknzuqblGpzEa/E/bSLc1pT3I0NTsi0OyI0; 4:a7lQNmha5zzV/wynhxxDxm8pvumTyB0sXeqk02Ub03bmDsehFX5qrLntaqm8sUJfhTqhBWCkZl3BNfKDGmAUXOnMNnk3wXvwl8IvitQ7E4s8fRf7i5ciP0b08gbRJ8lh7g+m345+W40PKlIufyvzxQQuCwXGrbgODM7Xe7szFSohm1ebph1B3okcHDGIHl3iOuxbUwRksExOy3fnIaulVU9c1/fdzM2oBUT0GFH+B3zaCZmRYxZxysV96wRiD3ZxQxbTLgMy5848OERQ1TRgFukh81T5iaXImOeSiuKeiN3YtXUxaK4L+k0ZulT5rfB1CgWkrrcjLiRkp0s0HrFeNnnIhCD4XFLAxHuBB6FFA8mXgQaDSaFAFzFqv584ER6t X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001); SRVR:SN1PR08MB1471; BCL:0; PCL:0; RULEID:; SRVR:SN1PR08MB1471; X-Forefront-PRVS: 0876988AF0 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6049001)(6009001)(479174004)(24454002)(377454003)(51444003)(164054003)(13464003)(66654002)(93886004)(81166005)(75432002)(65816999)(64126003)(47776003)(66066001)(50466002)(65806001)(92566002)(42186005)(65956001)(23676002)(87266999)(59896002)(4326007)(189998001)(586003)(90282001)(110136002)(4001350100001)(33656002)(3846002)(1096002)(5008740100001)(88552002)(6116002)(86362001)(89122001)(117156001)(76176999)(50986999)(54356999)(2906002)(77096005)(5004730100002)(83506001)(2950100001)(80316001)(36756003)(19580395003)(230700001)(19580405001); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1PR08MB1471; H:[192.168.0.164]; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtTTjFQUjA4TUIxNDcxOzIzOk1Ra2VNWVI1QllJK1hNK1c3US95OUZXZDZ0?= =?utf-8?B?TFBRSWN4R3lOTkMwbG5Fd3ZlajdwVGYxY2hvZmxoVDlDbHBYaGx1R1gwSlBU?= =?utf-8?B?Wm5KUXo2VUpQRDRKSDFsdUZQSUY5cURvTjJZRGd5Vm9lQVNnM1pIeGdIUTJU?= =?utf-8?B?ZXJWaGVKZUQ4ZHBOZmFJZHdyemJZWGtvUkFIbjFxQW10Sm5oNmQ2VVhUSjBz?= =?utf-8?B?ajFkZWpneTI2Mzc4UkZQeHY2Mm5LSGQ3TW1IUDY3bEtRYmlkK3N2YmlZMmtQ?= =?utf-8?B?VjBGMnNmQS9kbHg0WkNxYWh3QThDSzdaYlN5Um1ZRzNGV2FQaDViRHFEUUQv?= =?utf-8?B?K3FGSFdPNnkwZUlmSmhJQ1pSMEYwYjdMYzUxRjlNeTVPcEF4VlV0ZFQ1NEh3?= =?utf-8?B?VERsZkxvR1d0NW82bmNsanpnWTBNWXF1aUFUUyt6VjhwZGw0dmlqdnNvVGEr?= =?utf-8?B?WFJETFJEZjRuODJCRVZ6R0ZQWS91S3FhUkJBcG5jNWRpV3NvdFN5ZmZ5Nzha?= =?utf-8?B?dElKdGZRODhKdUVCc3Y2VEdJZjBBRFRUNFZFYkVhZ2tLYzJmWFJoRmhkMWRx?= =?utf-8?B?d0lOREl3c3VpSU95enN1T3QxRXgzVUM2cVM1bVU4S3Rwd2RydHRuNG53cWxY?= =?utf-8?B?KyszYmtlUlZFSjAwRjBPOUg1MGErbEkyUFNYUkVyNlJiRWlRdzBPOTNIaGY5?= =?utf-8?B?K05tRExjQkNRVEpWcGt2cnlseWZjbEtzMFkrZ2RwR3F0bkRRaDY5WmV3cGh2?= =?utf-8?B?T2kxL3BETFNpeEYyVk9ydlo5bjVieUdkSkpIeUVXTDk4R29rUStEVVBnYkxj?= =?utf-8?B?RHZlVEdPeGs3dnYvQnp0angzMWtnTUtDUWNhU09WMjh0Y3k5NUNhWEM4dlRh?= =?utf-8?B?V0FsMW5neDVsYUdDUGtOQXNXYTdpZ3FqVkJxMkVsbERaL0xkc0VTRGU3dUg3?= =?utf-8?B?aklJS1o1MHJCQ29nWFo0QnVtRUtLSUtLa0llMW1XRTdTQitIU1QwU2xxK0ho?= =?utf-8?B?ZGpUT1ZPMUF6UnNZWlZVYWdYMFo0Tk40dFJHNmhMMEVlSHZNbEhSTmVBQnRw?= =?utf-8?B?RVhaTlBjckhSdzMyWkpxemk2SlNESVdzdXZZT3cwTEJyRDNLUi9UTERJQkhF?= =?utf-8?B?QkdXeTBpQ05LQzhhL1ZiZ0FNVUM4U3VPZ0trVnFUQ3RyS2tEYlJwaUNsNVlY?= =?utf-8?B?M2FOTHhEQUQybmlwRkIwOTREaVZ1N0dSOEdXbE5yWWYvN3F0V2s5b2ZmVUtF?= =?utf-8?B?emtpOENMWkxsYmIxT1lWNk5hUDFmUC80RGdYRXRrejZSZUtwOWIxY2plY01Z?= =?utf-8?B?eDhyd21lMXlyellMcTdDYThXT05raDVxRVh5RWk2OGZnZW44SU1KeVVzU01a?= =?utf-8?B?ZmpPeXFHa2lzMk1wZUF6VUM5Yk5zdVFvQTg1VEIzRlIvME4vR3l0cFVoUnkz?= =?utf-8?B?eFB6WnN3dmZENjVWcEhqSFlWc3pJSlBpUWxDbXh2M1RCQ1RKL3cyVXEzTm8v?= =?utf-8?B?WE45V2hHTlJKQ1RaKzk4cWNWbGtray9iUnAybmRQN0J6Q01WYlFUejZ3VERN?= =?utf-8?B?QlUvSVNkYlhlaEtNbXdzT2FsQ1h6aEhaOW93MFd1bW9ZYTZUTTJMZlBJcEtq?= =?utf-8?B?NjZMRXFKQS92ZWxwTG5zL2RlUXlWaDdkb1FNbndGazFhMi9kUWZtS2NxellJ?= =?utf-8?B?UnYzenJZOEFXMTB3bWtoRldHM1h0UUU0RnVEc1F6WlF3NzJiVXZtNWhRSDZa?= =?utf-8?B?U3dZcDdaVFhCTTRKbk9ybW8wZVpKblRQYlA3aFU5TjhXdzdOcnRITmEvYVZI?= =?utf-8?Q?wEVnz5Mx5u4q1?= X-Microsoft-Exchange-Diagnostics: 1; SN1PR08MB1471; 5:4hsUSIYroQ7OxQPsCAE6+aG626strQ8Qy/isdI1yMCA0hLsqvzgIm/ZaSgTsrkOkOTH6ZX/968dTM9TVzuf2LWUe9JT4+UhB40DHeM9QtaDhsphHvPFwsobTIvl2dWZfwZ7ez0qBNeeZbsBcniaF3g==; 24:ar+OMb4uSkeUEMSsF9HAQKf7TpHP7QYKq19GyZDV/RoruIj9ARU6SO0zBw1JLKOYqSLINwnoa2hV4jgsOD7SuXF9WOixwc+8o9OlqZYyM8c= SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: unl.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 Mar 2016 15:22:57.8683 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR08MB1471 Archived-At: Cc: tcpm@ietf.org, draft-ietf-tcpm-cubic@ietf.org Subject: Re: [tcpm] Question on CUBIC and its TCP CC RFC basics X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 09 Mar 2016 15:39:59 -0000 On 3/9/2016 4:26 AM, Karen Elisabeth Egede Nielsen wrote: > HI Neal, Lisong, others > > Thank you both. > > Sorry for asking "stupid" questions, but could you be so kind as to comment > on the following also, :-): > > My simple understanding of CUBIC CC (with ABC glasses on) is that instead of > incrementing CWND by 1 MTU/MSS per CWND bytes acknowledged, > CUBIC CC dictates to increment CWND by 1 MTU per MTU*CWND/(CUBIC_target - > CWND) bytes acknowledged. > (here CUBIC_Target=W(t+RTT) calculated in bytes)) > > Can you help me understand why the "TCP friendliness" relates to an average > Reno window at a given time and not > just simply to that at any given time ( CWND_cnt_bytes =) > MTU*CWND/(CUBIC_target - CWND) should be clamped by CWND. > I.e., never be allowed to go higher than CWND - ? Hi Karen, "tcp friendliness" is about the relation between the long-term average window size of cubic and that of reno. Because the long-term average window size depends on both the increase function (what you mentioned above) and the decrease parameter (i.e., the beta), we check "tcp friendliness" only periodically at some points. Thanks Lisong > Perhaps this is just a (choice of) implementation issue (?) - If there are > logical reason then I am probably just missing something.... > > Many Thanks in advance. > > BR, Karen > >> -----Original Message----- >> From: Lisong Xu [mailto:xu@unl.edu] >> Sent: 9. marts 2016 03:54 >> To: Neal Cardwell ; Karen Elisabeth Egede Nielsen >> >> Cc: tcpm@ietf.org; draft-ietf-tcpm-cubic@ietf.org >> Subject: Re: [tcpm] Question on CUBIC and its TCP CC RFC basics >> >> Thanks, Neal, for answering these questions. I was on my trip the whole >> day, and just came back to home. >> Lisong >> >> On 3/8/2016 9:24 AM, Neal Cardwell wrote: >>> On Tue, Mar 8, 2016 at 9:18 AM, Karen Elisabeth Egede Nielsen >>> wrote: >>>>> But at least in Linux that is not a change in the fast recovery code; >>>>> that >>>>> is a >>>>> different approach the congestion control module uses to calculate the >>>>> target cwnd that the fast recovery code (independent of the congestion >>>>> control module) reaches at the end of recovery. >>>>> >>>> [Karen Elisabeth Egede Nielsen] hmm - not sure I understand this. I >> asume >>>> that the CWND used _during_ FR is the 0.7*prior value CWND >>> In Linux CUBIC the cwnd used during FR is determined by the Linux PRR >>> code (RFC 6937), operating with an ssthresh value calculated by the >>> congestion control module. >>> >>>> And that the factor 0.7 (opposed to RFC5681/RFC6675 factor 0.5 ) >>>> impacts >> the >>>> fast recovery operation (assuming PRR not in) - while it does of course >>>> not >>>> impact the fast retransmission code lines which presumably just related >>>> to >>>> the CWND as updated by the CC logic - is that what you mean ? >>> Yes. >>> >>>> Or do you mean to say that - in Linux implementation - the 0.7*prior >> CWND >>>> only impacts the CC evaluations at the _end of_ recovery ? >>> The 0.7x impacts behavior during recovery as well (though it is >>> indirect, in the sense of setting a target number of packets to have >>> in flight). >>> >>>> I think that you have confirmed that the time t starts at _end_ of fast >>>> recovery - >>>> Correctly understood ? >>> Yes, the CUBIC t is measured relative to the end of fast recovery. >>> >>> neal From nobody Thu Mar 10 05:20:03 2016 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 9C03712D6A8 for ; Thu, 10 Mar 2016 05:20:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=tieto.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 FafD55J7TNxa for ; Thu, 10 Mar 2016 05:19:57 -0800 (PST) Received: from mail-ig0-x22c.google.com (mail-ig0-x22c.google.com [IPv6:2607:f8b0:4001:c05::22c]) (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 AC7B012D75E for ; Thu, 10 Mar 2016 05:19:57 -0800 (PST) Received: by mail-ig0-x22c.google.com with SMTP id z8so17680887ige.0 for ; Thu, 10 Mar 2016 05:19:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tieto.com; s=google; h=from:references:in-reply-to:mime-version:thread-index:date :message-id:subject:to:cc; bh=Aad3yq6OtvwiUjtrixG2xDtYqFNYdCYvb4LzRsrmwcU=; b=jnEe1KklGBlJF/aDOllierFVfCf/IuIGUHOfS22kMtAUHq5rnDcQaWiCYoBhC68jea 5htd9aUi+aO0eW0AcGoohmpW8FJhGy3O/vtBSrzEQbBXX/x5Mlwzlnxh+c1MKOY4Vsax SJqeg8cRlJSli1eEeYPbGSiJ5zmXTSF86Nehc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:references:in-reply-to:mime-version :thread-index:date:message-id:subject:to:cc; bh=Aad3yq6OtvwiUjtrixG2xDtYqFNYdCYvb4LzRsrmwcU=; b=F+lwfW2Ryhykube1klYmbByg8qkeQ+ZqgIy2YtAfZQ1YDoIRItQ5MTcLVT2fTXI9Vi KKprln+SrXdjOhxjNWnMvdwgBsdEwzBeIvh4h//AvOci7YdaG2c4VHvXZCv2GzXDIE3M LBGoChFISzm4CouFfNI1xZaX8dmKtlubm5zuc79HQmgWTTkz8MgE6k5svPZK2YBAsoYO JWduRZGzXFMOUwB+YyV7S2xjpbPaEUSrSpTMDxZehFzEcx0LX3DHEyJTuvjCwuMDDJ8H 3kyEGeyyVB9KwAKSzeQQgKwj5P7MPLhqaEi9l+fEuqDrlr/o0a86b+ApWL7RMyhm5faG Jo1A== X-Gm-Message-State: AD7BkJLVEmKhM08TbTOlHp7fLC80w+3Mqg6FVxvt7g3USo2ErrW4L6q6fTGvQXm/p1pcvlB90xG6/X/pPrfOi4L3v0TKqgv2PBbdENKeo7J9+xRUsxulURLyETSm14PtJ1RWwS4= X-Received: by 10.50.111.137 with SMTP id ii9mr3660782igb.83.1457615996889; Thu, 10 Mar 2016 05:19:56 -0800 (PST) From: Karen Elisabeth Egede Nielsen References: <90e80f38b10a81626591d3cede931e35@mail.gmail.com> <13e7f67fe56c46b4d5d829e83d29a532@mail.gmail.com> <28921_1457450716_u28FPF2J024715_CADVnQymVHbe24Tpv1TsK4XGa1nyxhAv3sKfKudr3uxYFOEtCdA@mail.gmail.com> <56DF9033.8090205@unl.edu> <89a1b31e152a6cb038389eaef39e21fc@mail.gmail.com> <56E03FE0.4090407@unl.edu> In-Reply-To: <56E03FE0.4090407@unl.edu> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQIalpcGbWSSO5ocbu2GX5HnKQuzVgFTaC3bAaa6LhUCVRGaNgKL5105AiyHCGACCO0kvp5fxsVQ Date: Thu, 10 Mar 2016 14:19:55 +0100 Message-ID: To: Lisong Xu , Neal Cardwell Content-Type: text/plain; charset=UTF-8 X-DomainID: tieto.com Archived-At: Cc: tcpm@ietf.org, draft-ietf-tcpm-cubic@ietf.org Subject: Re: [tcpm] Question on CUBIC and its TCP CC RFC basics X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 10 Mar 2016 13:20:00 -0000 HI Lisong, Neal, Thank you so much for the information. I think that I will have to understand the TCP_friendly reactions a little better. The motivation and the analysis done. Also understanding application limitation aspects. In terms of the CUBIB CC application limitation then for SCTP we may (at least initially) choose the approach of restarting the CUBIC CC slope. Which was not the choice taken for the fix in Linux TCP, I understand from: https://github.com/torvalds/linux/commit/30927520dbae297182990bb21d08762bcc35ce1d But as the application limitation of SCTP is more conservative and restricted than for TCP then this more aggressive ramp up after application limitations may be ok. (We will see about that). Returning to the TCP_friendly function - - - would you say that the behavior _implemented_, analysed and tested (and deployed) is represented by the description in section 3.2 of the draft https://datatracker.ietf.org/doc/draft-ietf-tcpm-cubic/?include_text=1 - i.e.: W_aimd(t) = W_max*beta_aimd + [3*(1-beta_aimd)/(1+beta_aimd)] * (t/RTT) (Eq. 4) I cannot say that I have understood that this is achieved by the linux implementation which seems to relate to a cwnd calculated by CC CUBIC to estimate the TCP CC window. But perhaps it is ok.... Have you modified this to relate to TCP CC implementing cwnd validation during application limitations proper ? Many Thanks. BR, Karen > -----Original Message----- > From: Lisong Xu [mailto:xu@unl.edu] > Sent: 9. marts 2016 16:23 > To: Karen Elisabeth Egede Nielsen > Cc: Neal Cardwell ; tcpm@ietf.org; draft-ietf-tcpm- > cubic@ietf.org > Subject: Re: [tcpm] Question on CUBIC and its TCP CC RFC basics > > > > On 3/9/2016 4:26 AM, Karen Elisabeth Egede Nielsen wrote: > > HI Neal, Lisong, others > > > > Thank you both. > > > > Sorry for asking "stupid" questions, but could you be so kind as to > > comment on the following also, :-): > > > > My simple understanding of CUBIC CC (with ABC glasses on) is that > > instead of incrementing CWND by 1 MTU/MSS per CWND bytes > > acknowledged, CUBIC CC dictates to increment CWND by 1 MTU per > > MTU*CWND/(CUBIC_target - > > CWND) bytes acknowledged. > > (here CUBIC_Target=W(t+RTT) calculated in bytes)) > > > > Can you help me understand why the "TCP friendliness" relates to an > > average Reno window at a given time and not just simply to that at any > > given time ( CWND_cnt_bytes =) MTU*CWND/(CUBIC_target - CWND) > should > > be clamped by CWND. > > I.e., never be allowed to go higher than CWND - ? > > Hi Karen, > > "tcp friendliness" is about the relation between the long-term average > window size of cubic and that of reno. Because the long-term average > window size depends on both the increase function (what you mentioned > above) and the decrease parameter (i.e., the beta), we check "tcp > friendliness" only periodically at some points. > > Thanks > Lisong > > > Perhaps this is just a (choice of) implementation issue (?) - If > > there are logical reason then I am probably just missing something.... > > > > Many Thanks in advance. > > > > BR, Karen > > > >> -----Original Message----- > >> From: Lisong Xu [mailto:xu@unl.edu] > >> Sent: 9. marts 2016 03:54 > >> To: Neal Cardwell ; Karen Elisabeth Egede > >> Nielsen > >> Cc: tcpm@ietf.org; draft-ietf-tcpm-cubic@ietf.org > >> Subject: Re: [tcpm] Question on CUBIC and its TCP CC RFC basics > >> > >> Thanks, Neal, for answering these questions. I was on my trip the > >> whole day, and just came back to home. > >> Lisong > >> > >> On 3/8/2016 9:24 AM, Neal Cardwell wrote: > >>> On Tue, Mar 8, 2016 at 9:18 AM, Karen Elisabeth Egede Nielsen > >>> wrote: > >>>>> But at least in Linux that is not a change in the fast recovery > >>>>> code; that is a different approach the congestion control module > >>>>> uses to calculate the target cwnd that the fast recovery code > >>>>> (independent of the congestion control module) reaches at the end > >>>>> of recovery. > >>>>> > >>>> [Karen Elisabeth Egede Nielsen] hmm - not sure I understand this. I > >> asume > >>>> that the CWND used _during_ FR is the 0.7*prior value CWND > >>> In Linux CUBIC the cwnd used during FR is determined by the Linux > >>> PRR code (RFC 6937), operating with an ssthresh value calculated by > >>> the congestion control module. > >>> > >>>> And that the factor 0.7 (opposed to RFC5681/RFC6675 factor 0.5 ) > >>>> impacts > >> the > >>>> fast recovery operation (assuming PRR not in) - while it does of > >>>> course not impact the fast retransmission code lines which > >>>> presumably just related to the CWND as updated by the CC logic - is > >>>> that what you mean ? > >>> Yes. > >>> > >>>> Or do you mean to say that - in Linux implementation - the > >>>> 0.7*prior > >> CWND > >>>> only impacts the CC evaluations at the _end of_ recovery ? > >>> The 0.7x impacts behavior during recovery as well (though it is > >>> indirect, in the sense of setting a target number of packets to have > >>> in flight). > >>> > >>>> I think that you have confirmed that the time t starts at _end_ of > >>>> fast recovery - Correctly understood ? > >>> Yes, the CUBIC t is measured relative to the end of fast recovery. > >>> > >>> neal From nobody Thu Mar 10 05:22:19 2016 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 2BC9812D76F for ; Thu, 10 Mar 2016 05:22:17 -0800 (PST) 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, 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 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 Wg4sqOeLaytD for ; Thu, 10 Mar 2016 05:22:15 -0800 (PST) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 55D5012D768 for ; Thu, 10 Mar 2016 05:22:14 -0800 (PST) X-AuditID: c1b4fb25-f794e6d000003d15-c9-56e175048062 Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.183.48]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id FA.3A.15637.40571E65; Thu, 10 Mar 2016 14:22:12 +0100 (CET) Received: from ESESSMB205.ericsson.se ([169.254.5.194]) by ESESSHC010.ericsson.se ([153.88.183.48]) with mapi id 14.03.0248.002; Thu, 10 Mar 2016 14:22:04 +0100 From: Ingemar Johansson S To: "ycheng@google.com" Thread-Topic: [tcpm] Question on RFC6298, Managing the RTO Timer and additional lost pakets in Recovery state Thread-Index: AQHRdvckTyX+W1YprkedevSP+dD0kJ9SooCA Date: Thu, 10 Mar 2016 13:22:04 +0000 Message-ID: <81564C0D7D4D2A4B9A86C8C7404A13DA43D9C104@ESESSMB205.ericsson.se> References: <81564C0D7D4D2A4B9A86C8C7404A13DA43D85BDD@ESESSMB205.ericsson.se> <40707.1457015491@lawyers.icir.org> <81564C0D7D4D2A4B9A86C8C7404A13DA43D9523A@ESESSMB205.ericsson.se> In-Reply-To: Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.147] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_01FD_01D17AD8.373EEB50" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrOIsWRmVeSWpSXmKPExsUyM2K7gS5L6cMwg7PPlS12n5vKYjFtzTQm ix9nd7JabDs5n8niy+OrbA6sHgs2lXr8O3ST2WPJkp9MHqtXP2T26Di+gTmANYrLJiU1J7Ms tUjfLoErY/1b9oIlFRXbFlxnbmC8kdXFyMkhIWAicfRhNwuELSZx4d56ti5GLg4hgcOMEvdP T4VyljBKbJrwjhGkik3ARmLloe9gtoiAtsTjns9gRcwC2xglLs7qYQdJCAvkSVx6f4UNoihf onvtLGYI20ji3blnQDUcHCwCqhLd5zxAwrwCvhK7Jxxkhlj2j1Fi6vQTTCAJToFAiVPNy8B6 GQVkJe5/vwd2KrOAuMStJ/OZIM4WkXh48TQbhC0q8fLxP1aQ+RICShLTtqZB3NbLKHH45xpm iGWCEidnPmGZwCg6C8moWcjqZiGpgyjSlnh68ymcvWzha2YI21pixq+DbBC2osSU7ofsELap xOujHxkXMHKsYhQtTi1Oyk03MtZLLcpMLi7Oz9PLSy3ZxAiM4oNbfqvuYLz8xvEQowAHoxIP 74dVD8KEWBPLiitzDzGqAM15tGH1BUYplrz8vFQlEd6skodhQrwpiZVVqUX58UWlOanFhxil OViUxHlZP10OExJITyxJzU5NLUgtgskycXBKNTDy/Li+jC9f5fZai8fPrh5iNmMNUfSY6bUv zC+4LPkAh0yzWbyq79UrCwztn7WtD7CZYW6ia/23w7v7gmdyq6u9lMFrL3eZW91T3257dcB9 Q/EBb8eG2YUdbU1PpSYzanPu0o3hz2c1N2Jc0jxZ8X+7Q/gjHb6p259sy3o2e+6j0Cv/tnyc 663EUpyRaKjFXFScCACUbbPG6gIAAA== Archived-At: Cc: "tcpm@ietf.org" , "end2end-interest@postel.org" , "michawe@ifi.uio.no" , "mallman@icir.org" Subject: Re: [tcpm] Question on RFC6298, Managing the RTO Timer and additional lost pakets in Recovery state X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 10 Mar 2016 13:22:17 -0000 ------=_NextPart_000_01FD_01D17AD8.373EEB50 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi Yuchung, thanks for the help I seem to have gotten the RFC6937 (PRR) behavior in place. Currently I = don't see much gain with PRR, one possible reasons is that AQMs in LTE = are typically a bit on the "bufferbloated" side as too low drop = thresholds easily causes links be underutilized. The effect of this is = that when a loss event occurs, there will be enough data in the RLC = queue to transmit even though the congestion window is cut in half = immediately. There could still be benefits with PRR in terms of less = RTO. I believe then that I am getting closer to a good Linux TCP model in our = simulator.=20 I still have one particular behavior that I don't really understand, I = am almost 100% sure that the error is on my side Thanks for the ref to the sigcomm paper, I seem to have missed it. /Ingemar > -----Original Message----- > From: Yuchung Cheng [mailto:ycheng@google.com] > Sent: den 5 mars 2016 16:53 > To: Ingemar Johansson S > Cc: mallman@icir.org; Michael Welzl; tcpm@ietf.org; end2end- > interest@postel.org > Subject: Re: [tcpm] Question on RFC6298, Managing the RTO Timer and > additional lost pakets in Recovery state >=20 > Linux implements RFC6937 not RFC6675 to adjust cwnd in fast recovery. > Specifically it reduces cwnd gradually toward ssthresh as packets are = being > delivered. if inflight, aka pipe, drops below ssthresh, it tries to = slow start > toward ssthresh, provided no additional packets are lost. The last = condition > was added recently and I had a presentation last meeting: > https://www.ietf.org/proceedings/94/slides/slides-94-tcpm-7.pdf >=20 > btw, Linux may adjust RTO by taking RTT samples from newly SACK = blocks, > which is not standardized. It mitigates issues when RTT continues to = raise > during recovery in LTE networks (see figure 15 in > http://web.eecs.umich.edu/~zmao/Papers/lte_sigcomm13.pdf) >=20 > On Sat, Mar 5, 2016 at 7:18 AM, Ingemar Johansson S > wrote: > > > > Hi > > > > Thanks for the response, and thank Michael as well, guess I need to = read > RFC5681 and RFC6675 again. > > > > The line of reasoning seen from an application perspective actually = helps to > put the puzzle together for me. > > Also I understand now that case 2 below necessitates an RTO, atleast = with > TCP. I guess QUIC may be different in this respect as it retransmitted > segments have a new transport sequence number ?. > > > > /Ingemar > > > > > -----Original Message----- > > > From: mallman@icir.org [mailto:mallman@icir.org] > > > Sent: den 3 mars 2016 15:32 > > > To: Ingemar Johansson S > > > Cc: tcpm@ietf.org; end2end-interest@postel.org > > > Subject: Re: [tcpm] Question on RFC6298, Managing the RTO Timer = and > > > additional lost pakets in Recovery state > > > > > > > > > > It says quote =E2=80=9C(5.3) When an ACK is received that = acknowledges new > > > > data, restart the retransmission timer so that it will expire > > > > after RTO seconds (for the current value of RTO).=E2=80=9D > > > > > > > > What is the definition of new data ?. The strict interpretation = is > > > > when SND.UNA advances, but it can also be that the highest = SACKed > > > > sequence number increases. The former case it is more likely = that > > > > RTO happens. > > > > > > Seems like something we should have nailed down in the spec at = some > > > point after SACK became widely prevalent. Alas. > > > > > > I think "new data" can be interpreted as "cumulative ACK = advances". > > > > > > The spirit of (5.3) is that as long as the connection is making > > > progress---from an application perspective---we can keep the RTO = at > > > arms length and so we just keep re-arming it. But, once we have a > > > stall---or even an indication that we might stall---because a = packet > > > has been lost then we stop pushing the RTO off. > > > > > > > The second question is Linux related. Given that a lost packet > > > > puts the stack in Recovery state, the congestion window reduces > > > > one step as an effect on this. What happens if additional = packets > > > > are lost when in Recovery state. I guess the congestion window > > > > should decrease more or ?. > > > > > > First, this is a more generic answer, I have no idea what linux = does. > > > > > > I can't tell which of two cases you are talking about here. Let's > > > say you send > > > 20 packets into the network in some window. Now, the cases ... > > > > > > (1) We lose packets 1, 5, 13 and 17. I.e., multiple packets are > > > lost from a single transmission window. So, retransmitting > > > packet 1 puts us in recovery and causes congestion control > > > action. I believe that the fact that packets 5, 13 and 17 are > > > also lost does not mean we should react to congestion again. > > > E.g., RFC 6675 calls for a single CC response regardless of = how > > > many packets are lost from a window of data. > > > > > > (2) We lose packets 1, 5, 13 and 17 and also the retransmit of > > > packet 17. So, we lose 4 packets from the first single > > > transmission window. This triggers one CC response. But, the > > > retransmit of packet 17 is from a subsequent transmission > > > window, indicating that perhaps we haven't yet done enough to > > > relieve the congestion. Conservativeness would likely suggest > > > that in this case, yes, we should take another CC action. > > > > > > And, e.g., RFC 6675 forces this second CC action by being = unable > > > to cope with lost retransmissions. Rather, in this case we = fall > > > back to the RTO which means another CC response. I am not > > > claiming RFC 6675 is the right approach here. Just noting = what > > > some spec does. We left it this way because we didn't feel = that > > > the complexity of dealing with this case was really generally > > > worth it. But, one could envision a different algorithm = making > > > a different choice. > > > > > > I hope that helps! > > > > > > allman > > > > > > > > > -- > > > http://www.icir.org/mallman/ > > > > > > > > > > _______________________________________________ > > tcpm mailing list > > tcpm@ietf.org > > https://www.ietf.org/mailman/listinfo/tcpm ------=_NextPart_000_01FD_01D17AD8.373EEB50 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIVYzCCAyAw ggIIoAMCAQICAR0wDQYJKoZIhvcNAQEFBQAwOTELMAkGA1UEBhMCRkkxDzANBgNVBAoTBlNvbmVy YTEZMBcGA1UEAxMQU29uZXJhIENsYXNzMiBDQTAeFw0wMTA0MDYwNzI5NDBaFw0yMTA0MDYwNzI5 NDBaMDkxCzAJBgNVBAYTAkZJMQ8wDQYDVQQKEwZTb25lcmExGTAXBgNVBAMTEFNvbmVyYSBDbGFz czIgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCQF0o1ncrwDZbHRPoWN/xIvb1/ gC01O+FvqGepvwMcTYxvMkfVQWikEwTBNQyahEP8XB3/ibPoFxjNkV/7iePqv05dfBsm03V57eaE 41flrSnE9Doo56V7hDZps/1edr2jLZnTkE4jKH0YY/FUOyaddluXQrL/rvBO7N05lU6DBn/nSUDI xQGyVFpmHT38+ek8Cp6BuHDwAYvkI1R8yK74kB4AlnLUVM9hI7zq+50CldG2uXE6aQg/D7ThQseI 9T+YqKe6HOBxce9YV4FQelxrdEYOgwOYw46obvJ2Mm4ng8Jz89wY6LST6nVEawRgIHFXh53zvqCQ Iz2KJOHaIdvDAgMBAAGjMzAxMA8GA1UdEwEB/wQFMAMBAf8wEQYDVR0OBAoECEqgqliE0148MAsG A1UdDwQEAwIBBjANBgkqhkiG9w0BAQUFAAOCAQEAWs6H+RZyFVdLHdmb56ImMOyTZ9/WLdI0r/c4 pc6rFrmrL3w1y6zQD7RMK/yA72uMkV82dvfbsxsZ6vSyEf1hcUS/KLM6Hb+zQ+ifv9wxCHGwnY3W NEcykMZlJPegSnwEc485bxeMcrW9S8h6+HuDwyhOnAnqZz+yZwQbwxTa+OdJJJHQHWr6YTnva+ch dQYH2BK0ISBwQnGB2jyaNr6mWw1qbJofkXv5+e9Cuk5OnswMjZTc2UWcXuxCUGOu9F3EsRLcyjuo Lp0UWgV1t+zXY+K6NbYECJHo2p2c9ma1GKwKplQmNDPSG8HUfxo6jguqMm7b/E8ln9kyx5ZacKzf TDCCBX0wggRloAMCAQICEQCH7S4aKCZKxRmqOuu5DaLLMA0GCSqGSIb3DQEBCwUAMDkxCzAJBgNV BAYTAkZJMQ8wDQYDVQQKEwZTb25lcmExGTAXBgNVBAMTEFNvbmVyYSBDbGFzczIgQ0EwHhcNMTQx MjA1MDgxOTE1WhcNMjEwNDA1MTAyOTAwWjA3MRQwEgYDVQQKDAtUZWxpYVNvbmVyYTEfMB0GA1UE AwwWVGVsaWFTb25lcmEgUm9vdCBDQSB2MTCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIB AMK+6yfwIaPzaSZVfp3FVRaRXP3vIb9TgHot0pGMYzHw7CTww6XScnwQbfQ3t+XmfHnqjLWCi65I tqwA3GV17CpNX8GH9SBlK4GoRz6JI5UwFpB/6FcHSOcZrr9FZ7E3GwYq/t75rH2D+1665I+XZ75L jo1kB1c4VWk0Nj0TSO9P4tNmHqTPGrdeNjPUtAa9GAH9d4RQAEX1jF3oI7x+/jXh7VB7qTCNGdMJ jmhnXb88lxhTuylixcpecsHHltTbLaC0H2kD7OriUPEMPPCs81Mt8Bz17Ww5OXOAFshSsCPN4D7c 3TxHoLs1iuKYaIu+5b9y7tL6pe0S7fyYGKkmdtwoSxAgHNN/Fnct7W+A90m7UwW7XWjH1Mh1Fj+J Wov3F0fUTPHSiXk+TT2YqGHeOh7S+F4D4MHJHIzTjU3TlTazN19jY5szFPAtJmtTfImMMsJu7D0h ADnJoWjiUIMusDor8zagrC/kb2HCUQk5PotTubtn2txTuXZZNp1D5SDgPTJghSJRt8czu90VL6R4 pgd7gUY2BIbdeTXHlSw7sKMXNeVzH7RcWe/a6hBle3rQf5+ztCo3O3CLm1u5K7fsslESl1MpWtTw EhDcTwK7EpIvYtQ/aUN8Ddb8WHUBiJ1YFkveupD/RwGJBmr2X7KQarMCpgKIv7NHfirZ1fpoeDVN AgMBAAGjggGAMIIBfDBOBggrBgEFBQcBAQRCMEAwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jYS50cnVz dC50ZWxpYXNvbmVyYS5jb20vc29uZXJhY2xhc3MyY2EuY2VyMA8GA1UdEwEB/wQFMAMBAf8wGQYD VR0gBBIwEDAOBgwrBgEEAYIPAgMBAQIwDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBTwj1k4ALP1 j5qWDNXr+nuqF+gTEjCBuQYDVR0fBIGxMIGuMG+gbaBrhmlsZGFwOi8vY3JsLTEudHJ1c3QudGVs aWFzb25lcmEuY29tL2NuPVNvbmVyYSUyMENsYXNzMiUyMENBLG89U29uZXJhLGM9Rkk/Y2VydGlm aWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5hcnkwO6A5oDeGNWh0dHA6Ly9jcmwtMi50cnVzdC50ZWxp YXNvbmVyYS5jb20vc29uZXJhY2xhc3MyY2EuY3JsMBMGA1UdIwQMMAqACEqgqliE0148MA0GCSqG SIb3DQEBCwUAA4IBAQAQ1elFTM6fGkQ/aRKdkUZicO3Cb9uzBJOpOtFctw+1El0/17lsjoVvJkZB D3KnUobnrriFdAa+7FAN55KLmZeB/3Y2bG0bB4toSyaVHjOQnQY9M0dv8U852w0Q7GwchKfebLUI bh9TMt2hI3Xc6j4knFTBUo7C1WAfO51K4bn1irmX6/Ej2VTgiOFsvOAny28W6enFSEQpSHw60VhN fSttSqTOxyrRR/7kW7Y8yb/3DZDZ/dH6ZCfx/y+BNIv2NuSd85M9HXUzplXXohti4Ql/qeaMn6by Ius6XlMWZZfkdVRvTuk2PkeC7UmAJ2+/DUWOPpawaytMXVfF4Hvxk34NMIIGADCCA+igAwIBAgIQ eyeE6FBBHSc8YzDpWR1mVTANBgkqhkiG9w0BAQUFADA6MREwDwYDVQQKDAhFcmljc3NvbjElMCMG A1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MjAeFw0xNDEyMDIxNDI5MTdaFw0xNzEy MDIxNDI5MTZaMHQxETAPBgNVBAoMCEVyaWNzc29uMRwwGgYDVQQDDBNJbmdlbWFyIEpvaGFuc3Nv biBTMS8wLQYJKoZIhvcNAQkBFiBpbmdlbWFyLnMuam9oYW5zc29uQGVyaWNzc29uLmNvbTEQMA4G A1UEBRMHRVBMSUpPSDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK6dOkJu7hl4aOKX k6YBf5PgWpDbO6iINxyYJetBuJZJqEdDqKukaHZmP8Rn5hhiQZDWa89koR41DNS7umMwZtHQkN+j m3b5Z1LUMQle7XDtUy3rn47hgjYUFgZOEp1fWYIoAKxZNOTf4AfiMbOGn2t8IFxe8JUYrAVy6tAE YnSnPM+nn4UeipLBwncBVhxUQU5R4W8b5k7tY8HJB+CWGgSbkyLWfxeuiwAA48nKqa6fOqo2ZpS4 ukNf9u8Hk3fIT8XvDJVnT2NwB7Z29oL3Fq20tm4M96SkuLlNjLZ9wvskfmYAk+PUP44ugvkB7Uon cAzoPXlkz3N5IB9Ly7/SIgsCAwEAAaOCAcYwggHCMEgGA1UdHwRBMD8wPaA7oDmGN2h0dHA6Ly9j cmwudHJ1c3QudGVsaWEuY29tL2VyaWNzc29ubmxpbmRpdmlkdWFsY2F2Mi5jcmwwgYIGCCsGAQUF BwEBBHYwdDAoBggrBgEFBQcwAYYcaHR0cDovL29jc3AyLnRydXN0LnRlbGlhLmNvbTBIBggrBgEF BQcwAoY8aHR0cDovL2NhLnRydXN0LnRlbGlhc29uZXJhLmNvbS9lcmljc3Nvbm5saW5kaXZpZHVh bGNhdjIuY2VyMCsGA1UdEQQkMCKBIGluZ2VtYXIucy5qb2hhbnNzb25AZXJpY3Nzb24uY29tMFUG A1UdIAROMEwwSgYMKwYBBAGCDwIDAQESMDowOAYIKwYBBQUHAgEWLGh0dHBzOi8vcmVwb3NpdG9y eS50cnVzdC50ZWxpYXNvbmVyYS5jb20vQ1BTMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcD AjAdBgNVHQ4EFgQUOrfg77a5Xcj2OffxTY1aeC+5CqEwHwYDVR0jBBgwFoAUsQ3K1Ea3r4YCwy9v BsoOdnF/SzcwDgYDVR0PAQH/BAQDAgWgMA0GCSqGSIb3DQEBBQUAA4ICAQCddA412wylfbLwBiyQ uVz1IDcaYZ14Yh1L52IhX14BGl0eNc/5BbWL3yCF2eGv8h6FmckZHOM7+OS4g+inNZbaKysTkLah T3UbrUWFPpkZFAS1HfaxBJZTVS3UIVnIYP06ZvRRRNf3VJzwpZSES4tu0euzI2CatWCZLa+N4QyT ZkMnw1JLUXbz0dPA40b9Qdoec23PkpMqf1CxNNuaRBF9L5wKGily7RyPOtkcrWJ3R2oSGC7ugKK9 vWzQzEHoE95txgF/kq7MdRJks8BXqnb3w8Fthu+1zIORjcR9yxv1e9gYo0ZcaPqyjC/LDdzsHv59 5hkwQnxAGyPDBgCdq5Ion/4Lx+YI61SKcyGEH+VYD6CJX44/IfRAE+tq8BHZYOJLW8uCd7Jboqd2 jklsUfSPN8i4cvQpfYzDkrSziyfcvdplEvxSEbTEFZ+w6IbvCtV0xBSfS9+RhqBOn6LZSdw/jp+b 9penQAWekRykrKyKroDtwesqg0HbC7bkprqOwSaar5gcFGYVYJ5JuHT3Ou44hGn/yiwbTnc2Mb12 8nWesZQZvIT2n5Y42ZYebo1cLBYdF6U/Q5OHLOUk596LephQggvKphe7F2w87CpaUUoANa4H1ri+ LTOKdz+itrkbu3dDs6oDZuSwMU3fJaf8d/3PPLoGJtFQWQ8v2e/Oxxe0sDCCBrYwggSeoAMCAQIC EQCgDMvMm5mY7OI6cPR8wcBZMA0GCSqGSIb3DQEBBQUAMDcxFDASBgNVBAoMC1RlbGlhU29uZXJh MR8wHQYDVQQDDBZUZWxpYVNvbmVyYSBSb290IENBIHYxMB4XDTE0MDUyNzA3NDYyMVoXDTI0MDUy NzA3NDYyMVowOjERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2 aWR1YWwgQ0EgdjIwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQDaulPrX0iWU5+JOOqj ddx4Gnl17DJhklkoXOgOSBMhW6FzGVt5RR7KPv+rjt2YpbwdoqWSYa4VPkS/72vuQoWsvz2avWWX hPTdNzrB3zs5cJO7sKIyd+LRy4l/8kKK4iPm+Q18XyGF0xTuc5WS3WiMScJSxEKdIOP8xehBraHZ abrGh9OxQHC4iBHkzD0YF3J/vBqBTr7blRzYf1h3j5a7qVIHCPfz+eCE175mResXDQRI7LvMiZtV aqitBl0oAJiJyeBmvEujBNsIEgUQ6JcQFG5ny0EazLywv7clwb7izvLgoXc6SFrd0D7TGJtkdldV JtMwDYXpyFMGAijT6uf8h2kuPIwrDgQFNEyIQZ4q52ZpRGwugC6sMxgHEDGjA/CxX9aC5Vi1EMRJ iOGF6gV3T+V5yHDHSBBeQbVAXm8wSTDBfXQwdro/AXqET0mG6Rpe4q2FGBaauE8qHEO6qR3WAEgv jVfFU2k6xZx1qmvwhkXadxh6ZIMXzgb6WpjivLnR0GEKNrgN2DXdvo+6eAt45Bhvmeka2TrJDxML WiBy8QYgNeNXYQsuREnDsjWo6wF0LqbA5769om9nn/uJzmzxb3nT1iHue5co9J93ta06kxiASHvc IzZwAOjKnmk0vR3IT7Qbzq2of3E1s18xo8DM9D91Cak0Nq+RALtdv1uZKQIDAQABo4IBuDCCAbQw gYoGCCsGAQUFBwEBBH4wfDAtBggrBgEFBQcwAYYhaHR0cDovL29jc3AudHJ1c3QudGVsaWFzb25l cmEuY29tMEsGCCsGAQUFBzAChj9odHRwOi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYXNvbmVyYS5j b20vdGVsaWFzb25lcmFyb290Y2F2MS5jZXIwEgYDVR0TAQH/BAgwBgEB/wIBADBVBgNVHSAETjBM MEoGDCsGAQQBgg8CAwEBAjA6MDgGCCsGAQUFBwIBFixodHRwczovL3JlcG9zaXRvcnkudHJ1c3Qu dGVsaWFzb25lcmEuY29tL0NQUzBLBgNVHR8ERDBCMECgPqA8hjpodHRwOi8vY3JsLTMudHJ1c3Qu dGVsaWFzb25lcmEuY29tL3RlbGlhc29uZXJhcm9vdGNhdjEuY3JsMB0GA1UdJQQWMBQGCCsGAQUF BwMCBggrBgEFBQcDBDAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFLENytRGt6+GAsMvbwbKDnZx f0s3MB8GA1UdIwQYMBaAFPCPWTgAs/WPmpYM1ev6e6oX6BMSMA0GCSqGSIb3DQEBBQUAA4ICAQBu ByBsr6x3PZBCsmGbcSZ/XL+0tnVMblInoJgL1Bh3PiRicgdo8l+6cvWp/ArBwMYNwSNyrvY9Iewy aV8n65c5oN+l2JDUuzrdANVKnYxha7ZyCEiPmY98sB2bnZgxfJLXQYoRwI7pOOwfyoP2fCYVCd+x hsfysYiIl4ORzE3TpeppQ2yWkyBBmoHUXJh97ue6+bJ2fqnVUoOVMVnYYEtvsz67v7w2z3fvdcy0 4/RnoylxSenxADi1tY9iIydHMgyOu3dfzsxU8AivMGG4aKStsCfUEyg0LlkbhqMrdness3e1qAEu eSRNASLfpFwyRmzmiuNh9onzuhER2yYhK/6IeCs4HQHrPhkY8JUmhtmdL2uErOZWOs38FQhGWHWX I0g6SgdDObU0GEHju0MkDziOhm+BVwPZKN7B7wD7OPj6vlLVo6d8vLGK9bywhEfXjxLIC3Qhtu5l JPTgIo5Bup+aBBjiJ/u9BfqryqZpudnWfG+wxC327rpNAq2OKdFsR92wbehSZD3mSSAemDVwGB2Y u0XHQYyyYfpWsGyGEyRSHKFhRwJdINPzWLI89wy4Wc+PgqyekkEmJqe6g4XSQFj4mqtwvqhP4dg2 QCcKM/bh62RwfM7GeSS/LFGe84KmJjTDfvT8c2rK8nEyZ/emOtwCGXQ6tZCByMNLxeDwU1TGbTGC AvMwggLvAgEBME4wOjERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIElu ZGl2aWR1YWwgQ0EgdjICEHsnhOhQQR0nPGMw6VkdZlUwCQYFKw4DAhoFAKCCAXowGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTYwMzEwMTMyMjAyWjAjBgkqhkiG9w0B CQQxFgQULvlgo03m+OWQdHxIJRCrzHU8ieMwWwYJKoZIhvcNAQkPMU4wTDAKBggqhkiG9w0DBzAO BggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwBwYF Kw4DAhowXQYJKwYBBAGCNxAEMVAwTjA6MREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJp Y3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MgIQeyeE6FBBHSc8YzDpWR1mVTBfBgsqhkiG9w0BCRAC CzFQoE4wOjERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1 YWwgQ0EgdjICEHsnhOhQQR0nPGMw6VkdZlUwDQYJKoZIhvcNAQEBBQAEggEAWK3YbP04C7uOTdVC ArlmtjbJzZx/2T4dREqns1So1dyekSwEQ8mld/2/kwko2iEBXuQybSuzE3+cEIj/NpEEEgg0x2q4 O8GhbOLeUzJKV1I9BFmtsmPrZxPnLTm6aDkS871SL1on1TeASJJGq1yzYG2pa21/t8v6xZ8Jb3xr Qan35v1suKdhpnahdssYUPznLgjYz/suA7t11zgXa+SaI5HPhSahFfmh5YeAU4HPUfYdP4XfriVH lR5R4rBS1OcOdXzwJUIlDOYgOwIzYf5GmpRPw5dGGocBBUUFCXffSnVqXor6DA//cvVOfD+LUWXe 9U6d2Eg+2w0dB5uEsxJo/QAAAAAAAA== ------=_NextPart_000_01FD_01D17AD8.373EEB50-- From nobody Thu Mar 10 06:56:56 2016 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 3958212DAAD; Thu, 10 Mar 2016 06:56:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=uofnelincoln.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 zIt_b7w2TrG1; Thu, 10 Mar 2016 06:56:52 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0235.outbound.protection.outlook.com [207.46.163.235]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30E7F12DA78; Thu, 10 Mar 2016 06:48:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uofnelincoln.onmicrosoft.com; s=selector1-unl-edu; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=SV3QaSkatbgjNUXFuW/IiwadPrlgMp6loHv/3X+j/YY=; b=wd3tXR7FQZ5gRUfnIoI/qvsio0cmDwifcLjRkv5xUOvim1dvRQl1SHJY4V64Sq/6QG7n8UleBqtYnR6ThNzr+4ffeK3fjQDI1uShYLPW2z5NlTyAM3b+eN33N6SKXmndcaPR5fgIRWCo3RW0efctMWvjSiEpdhS1snHQCaW2cuI= Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=unl.edu; Received: from [192.168.0.164] (97.98.140.59) by SN1PR08MB1470.namprd08.prod.outlook.com (10.162.2.13) with Microsoft SMTP Server (TLS) id 15.1.427.16; Thu, 10 Mar 2016 14:48:24 +0000 To: Karen Elisabeth Egede Nielsen , Neal Cardwell References: <90e80f38b10a81626591d3cede931e35@mail.gmail.com> <13e7f67fe56c46b4d5d829e83d29a532@mail.gmail.com> <28921_1457450716_u28FPF2J024715_CADVnQymVHbe24Tpv1TsK4XGa1nyxhAv3sKfKudr3uxYFOEtCdA@mail.gmail.com> <56DF9033.8090205@unl.edu> <89a1b31e152a6cb038389eaef39e21fc@mail.gmail.com> <56E03FE0.4090407@unl.edu> From: Lisong Xu Organization: University of Nebraska-Lincoln Message-ID: <56E18949.5060006@unl.edu> Date: Thu, 10 Mar 2016 08:48:41 -0600 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [97.98.140.59] X-ClientProxiedBy: SN1PR0501CA0038.namprd05.prod.outlook.com (25.163.126.176) To SN1PR08MB1470.namprd08.prod.outlook.com (25.162.2.13) X-MS-Office365-Filtering-Correlation-Id: 617dc32e-503f-4d3a-f14b-08d348f308cb X-Microsoft-Exchange-Diagnostics: 1; SN1PR08MB1470; 2:zaLkvOyxTYIH/8UsmnNC4LfBA4fQ1Rn8rGlRbSsTQ7T7jmeCKYvKPmq3UANHcarQ0pdIQz1ZYexdZi6MCMR33hlCekdFsEMouC616xmRqk34EV+40HRxsxkmseYyWbCobtMYABCQ7IHCQsERAUP4TcWOSg04IwsRZ1zVG2uBZ63VijVd72vnyGl07WFBR7lK; 3:l1HTCPDHp1KJjVCqQpyIhU/qMuRSs5wkgWWZf5XwCOkVAb0F/DohnS8Qy9o9NKuqS6Ox6Q9FtedGL70mPkrHBPa+PLTcqJNSd22TbTK3vSZfShRhzxmtVAw6D5uMuezN; 25:9kp7Zfwnw/cbFeMRWR3PnetDDOb0w6xtsjSryWVrxjDEyaBRlY0MxIMs9WeH8Lbqj13D9aitjWNlkrf4nc0Eb5B/YR7Pbjrx222O7d2L64CD5peTzWj8TeWZPGBDm85N2UROL3jamTWT6Hbv/FUYb1Zrop2xPBItkxY0SDIio/qdzK65pKWAzbkwJCJoGH7HO55EjufJ7To8hRT1gtkIBi/3MQf7S0aF4J4i+rm0SmmR5J2Zv8tWbFLoBH88aWCI/KEEbf51LbauoDhnf+c3IY2g3NFllKHiCWn3FkiXR0BO2rO8iZ7MJmdb/UDXqJrg1QRVNmbUsBPKndeudU80AA== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN1PR08MB1470; X-Microsoft-Exchange-Diagnostics: 1; SN1PR08MB1470; 20:Sxwhyjv2uwPYI5LWslSoJAjtx9IlIqmiwieUfev+V8axW4pB3Tg7qeLAwe2uuiORJueFUane6BN3LM5Hz5hoVmujiWHr4kravmMnCHiab/NHYwkuSjME1faTymXKGqzEL6goN3W7Lgtd2i5x8hstnABkP8lfiBqxZOhPbg11ki8BOTXgiRScL3c6Nd8OyaNODdlYKS9k/7WIEyZ8hyGjt1vHbLTj+muiY4uLW5ZUPDumn6LkOgiai6ASHhJgFrtYgoO7AeQjeS/LFrqsTFMEnAiHkiNJgxc8awE0U+WcxPgCBJn/k/uGFmlTE/VqFfyvb/0TmOTkXI8xexH/K+9T3VjZYrKAddNpHL8tkKklYBbaNy7i7Q8vwiq8uis+cZIVTXOLIMWvT+xK8RICob3DelCqGL29mm+AUT/DgCt2BA7JKH8XMiFpREF18gB9BWTzpNdUDaFCgQb4n/tttgovUcwaH0VhvwLZbeHhdtjuDN2bdMW6KNfeT+eyMpcM2Gr3; 4:wPSVeHenRd2eEzqKVpZJRzJVgX+TPGfyceRsbNyfRxLPN7j2jv2FP0QPLPrqg1dk9AB/p7R2UckzBiJcLA38m9WsWPwoxLW+JnWYG4nldD7ERnQm+mQfTYsPk4sqy/uHdQodA1dRq/flWM+ky93JOOSdDHUgru8UKvAdm2O1r5kAob5Y0ldWMLEAfNRbolp2MlzqhvIB+Gb3SINeG6tnIhFPoPv9hbkVPUyIcp0pn7EL6x1ICgHmtcN/4ls1KZuTgmKRlyga7/EWNKESAZpNP8R7qwSSAaJPM9+Td1kO8pYoWyQWPoje/PMNaJHSRM9LV7PMMJ2olWBxbLbuUXrM1acK0JoeDlPUfKV6sJfIyFZj3kGpvUt+YlKmAGYBOBJU X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046); SRVR:SN1PR08MB1470; BCL:0; PCL:0; RULEID:; SRVR:SN1PR08MB1470; X-Forefront-PRVS: 08770259B4 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(6049001)(51874003)(51444003)(164054003)(377454003)(66654002)(13464003)(479174004)(24454002)(33656002)(23676002)(47776003)(81166005)(66066001)(65956001)(65806001)(2950100001)(5004730100002)(75432002)(86362001)(50986999)(76176999)(54356999)(65816999)(3846002)(87266999)(77096005)(6116002)(1096002)(230700001)(586003)(64126003)(93886004)(117156001)(59896002)(36756003)(90282001)(92566002)(5008740100001)(15975445007)(42186005)(189998001)(83506001)(4001350100001)(50466002)(19580395003)(19580405001)(5001770100001)(4326007)(2906002)(89122001)(88552002); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1PR08MB1470; H:[192.168.0.164]; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtTTjFQUjA4TUIxNDcwOzIzOk9GVkVnc2k2NXNIazZlV2VncUcyMDZEL0ti?= =?utf-8?B?akk3ajN3azN0UVl4T04xNTR0QXQ4Zk9EZ2oxWkhQdkRoNHhpMWxMY1pqdFB2?= =?utf-8?B?SWt3NnZiOGdmdWovOTlveDN6NG9xazE5ZTd2bEtkeUxQY09ZMjZaalVRYXo0?= =?utf-8?B?c0ZBSWxtc2FsSnROTFZERU9EK29sNG9wKzVZRUN4S2RyM3hUc2tEcDFjblA1?= =?utf-8?B?dnpMVVhaL3pFc0lFT1JCSllmNEc2RmVTZzlMN0VBZmRHek9UR29Rbk9wb3dK?= =?utf-8?B?WXltajFUS2haVUhHSUFSbUxOdGxrZVBuMEdzeEExNVAvWFVEY2lLUVR4OGdT?= =?utf-8?B?d3d4bzM4MDdQVTJwZC94L1NuMTAxenNZSCthMHRaNC9mczAzMWxiRnpNdTI1?= =?utf-8?B?ZGFrbHV2R2wzdCs3amZNSGJYcHBFa1Rkbno3V3AvaUY3SlZJZGpKTkcra3Yx?= =?utf-8?B?N0hBNTQwUmZ4OFVPZDd3bWRTdVRFSVdNZERyNS9EMjRXV05hOFFtNG1McnN5?= =?utf-8?B?UVFWMTR4NENhYzVZTGUxdGdGWEdxcy9Oek03enpveGlwYUFJWE5mUUZlMEo3?= =?utf-8?B?Q0VSUUFkNU5CRVdKa0JnSjh6NkJEaEoySGQ0RHVSWVEva3hmdU9pelZJamJ0?= =?utf-8?B?ajFRc3B2UDRhUDkrYy9sVDFQUUhkcXgrdWlvOFpVQ3BVN1VoY3R5ZHovTHVP?= =?utf-8?B?VXQ3UEp0akNGZDNQLzF3VUF0K1V0eitJN1I2RmVaZnk4cnpKeGdwZ05QNEhT?= =?utf-8?B?eFpFVlJvcUZXQnJSakpDWDZJSnkxR0Q5VUhNMGNpSytScHQ0RzZ2OHozb0xS?= =?utf-8?B?aE9BZEpFNkJ6S1hyVXdjWXhDQXZ6dE8xM1FHcVA3RDZyUkw3TmkzdXlrVkVZ?= =?utf-8?B?TEh1UmdDZHdFRlNXelZPOGhpajEzUFE3c0xNUWhmcVJTR1F4TVFwZG44WFlC?= =?utf-8?B?VXY1T1FZenF6NXZXbkczZktGdS9Bc2xiWDZ1NmFOQ0JnSUlNNVVwc2Rsa2sw?= =?utf-8?B?WGJXempGRGNpcWk4OVFvc0NyY3VnL0xLRytZSUlib1RVZWlCV3FEU2plWStM?= =?utf-8?B?REtKVTgwYjZCUm1HQURtT3g0cWE4Y0N0clVUbUhIelo4R05Fa1hhL2FzeDBQ?= =?utf-8?B?c2lodVlVVE5DRGpXUXpRR3ZqQm5VaUVkRVdBcGpOS0U5dWhyQW9raUNVUEhZ?= =?utf-8?B?d3hEWW9meFBtZjY5SWpXcUc2bTBvY3ZQdGl2UHQrYUIyeUlvUTBWWXJpV2hr?= =?utf-8?B?dDZndjlQUFMvbFRwbHJxUkwxcnprWS9CVDFaNGVGN1B4UytWeXZPeHpNS2tO?= =?utf-8?B?OVc2SWZWUHVtcGc4SFh4VnVRN2h2ZmxjbTVtWTVQSTk1Z1NkWVg4dkFjQytT?= =?utf-8?B?N1RMYWZMM3hkMVFaNHBSRWhSVGxucWpOdXZvRWRQTGlPZEtjL0srZlVSU1l6?= =?utf-8?B?anJzNjNTN3VSd0ZlUnNpU3FuZjRLZGFldmhMOUhsMGcxdzNzQnpvWUthSWRQ?= =?utf-8?B?cWJqMHEycy9DZmRpTDdJV2RGZ01GRGttK2ViRG1FNkJLVkxoUW9jZ1d6MVF6?= =?utf-8?B?MG9UUkV6RjZVVkZ4bHdxUUlHOXhyenpEREFPbVBqZ2NTSVJmSFNONFhOOXBh?= =?utf-8?B?bldEVE5MUWlaZ0hyR1J5b0RGcHoyUXJUb2t1RC9obzFTM2NwblAwb0NEY2RD?= =?utf-8?B?eVAvNGJVTjQxaHJSQUZZSWRYYXRnU1B5YTlSZzhheS9UUk5BeFR5TW12R0w2?= =?utf-8?B?V2ZSaVdFMGNicnp5Q2lHdjE3QUx0cFpIdWpSM2Fjdm1zcHg0VE1jL1NJRUN5?= =?utf-8?B?OFNIQzFKLy95QUtPeko5aENZUE9jUnhtb1pzZisvZ1dmNjZUeG1tSWowVEw5?= =?utf-8?Q?kGQXM/4QXw0=3D?= X-Microsoft-Exchange-Diagnostics: 1; SN1PR08MB1470; 5:62TFox7j6YOF26EhfB0ePQKVuap/uPe+DvbbVQKewIiFQg8Tk9+eWNNefz4YZL5kzFDpscZ2ZCqrT3vd/c5pEIpXYd/ouJklZ5ZjU0y6NDt/1RIRDVAUm81MdnYbtxMfWeOwO01dohhdbIyGfRBHsA==; 24:vLRuSJDd7zpa1/8dSPxMXaKFcHhxt3M3KsLz9Z2oTjgmdnh4z0xz8IGl9J9NP4AZsRapZfz3sk124Alid+MXoDO2lSojyL34qp6PVxJblsg= SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: unl.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Mar 2016 14:48:24.4176 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR08MB1470 Archived-At: Cc: tcpm@ietf.org, draft-ietf-tcpm-cubic@ietf.org Subject: Re: [tcpm] Question on CUBIC and its TCP CC RFC basics X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 10 Mar 2016 14:56:55 -0000 Hi Karen, Eq 4 is implemented at lines 482-483 and 305-322. https://github.com/torvalds/linux/blob/30927520dbae297182990bb21d08762bcc35ce1d/net/ipv4/tcp_cubic.c Thanks Lisong On 3/10/2016 7:19 AM, Karen Elisabeth Egede Nielsen wrote: > HI Lisong, Neal, > > Thank you so much for the information. > I think that I will have to understand the TCP_friendly reactions a little > better. > The motivation and the analysis done. Also understanding application > limitation aspects. > > In terms of the CUBIB CC application limitation then for SCTP we may (at > least initially) choose the approach of restarting the CUBIC CC slope. > Which was not the choice taken for the fix in Linux TCP, I understand from: > https://github.com/torvalds/linux/commit/30927520dbae297182990bb21d08762bcc35ce1d > But as the application limitation of SCTP is more conservative and > restricted than for TCP then this more aggressive ramp up > after application limitations may be ok. (We will see about that). > > Returning to the TCP_friendly function - - - > > would you say that the behavior _implemented_, analysed and tested (and > deployed) is represented by > > the description in section 3.2 of the draft > https://datatracker.ietf.org/doc/draft-ietf-tcpm-cubic/?include_text=1 - > i.e.: > > W_aimd(t) = W_max*beta_aimd + > [3*(1-beta_aimd)/(1+beta_aimd)] * (t/RTT) (Eq. 4) > > I cannot say that I have understood that this is achieved by the linux > implementation which seems to relate to a cwnd calculated by > CC CUBIC to estimate the TCP CC window. But perhaps it is ok.... > > Have you modified this to relate to TCP CC implementing cwnd validation > during application limitations proper ? > > Many Thanks. > BR, Karen > >> -----Original Message----- >> From: Lisong Xu [mailto:xu@unl.edu] >> Sent: 9. marts 2016 16:23 >> To: Karen Elisabeth Egede Nielsen >> Cc: Neal Cardwell ; tcpm@ietf.org; draft-ietf-tcpm- >> cubic@ietf.org >> Subject: Re: [tcpm] Question on CUBIC and its TCP CC RFC basics >> >> >> >> On 3/9/2016 4:26 AM, Karen Elisabeth Egede Nielsen wrote: >>> HI Neal, Lisong, others >>> >>> Thank you both. >>> >>> Sorry for asking "stupid" questions, but could you be so kind as to >>> comment on the following also, :-): >>> >>> My simple understanding of CUBIC CC (with ABC glasses on) is that >>> instead of incrementing CWND by 1 MTU/MSS per CWND bytes >>> acknowledged, CUBIC CC dictates to increment CWND by 1 MTU per >>> MTU*CWND/(CUBIC_target - >>> CWND) bytes acknowledged. >>> (here CUBIC_Target=W(t+RTT) calculated in bytes)) >>> >>> Can you help me understand why the "TCP friendliness" relates to an >>> average Reno window at a given time and not just simply to that at any >>> given time ( CWND_cnt_bytes =) MTU*CWND/(CUBIC_target - CWND) >> should >>> be clamped by CWND. >>> I.e., never be allowed to go higher than CWND - ? >> Hi Karen, >> >> "tcp friendliness" is about the relation between the long-term average >> window size of cubic and that of reno. Because the long-term average >> window size depends on both the increase function (what you mentioned >> above) and the decrease parameter (i.e., the beta), we check "tcp >> friendliness" only periodically at some points. >> >> Thanks >> Lisong >> >>> Perhaps this is just a (choice of) implementation issue (?) - If >>> there are logical reason then I am probably just missing something.... >>> >>> Many Thanks in advance. >>> >>> BR, Karen >>> >>>> -----Original Message----- >>>> From: Lisong Xu [mailto:xu@unl.edu] >>>> Sent: 9. marts 2016 03:54 >>>> To: Neal Cardwell ; Karen Elisabeth Egede >>>> Nielsen >>>> Cc: tcpm@ietf.org; draft-ietf-tcpm-cubic@ietf.org >>>> Subject: Re: [tcpm] Question on CUBIC and its TCP CC RFC basics >>>> >>>> Thanks, Neal, for answering these questions. I was on my trip the >>>> whole day, and just came back to home. >>>> Lisong >>>> >>>> On 3/8/2016 9:24 AM, Neal Cardwell wrote: >>>>> On Tue, Mar 8, 2016 at 9:18 AM, Karen Elisabeth Egede Nielsen >>>>> wrote: >>>>>>> But at least in Linux that is not a change in the fast recovery >>>>>>> code; that is a different approach the congestion control module >>>>>>> uses to calculate the target cwnd that the fast recovery code >>>>>>> (independent of the congestion control module) reaches at the end >>>>>>> of recovery. >>>>>>> >>>>>> [Karen Elisabeth Egede Nielsen] hmm - not sure I understand this. I >>>> asume >>>>>> that the CWND used _during_ FR is the 0.7*prior value CWND >>>>> In Linux CUBIC the cwnd used during FR is determined by the Linux >>>>> PRR code (RFC 6937), operating with an ssthresh value calculated by >>>>> the congestion control module. >>>>> >>>>>> And that the factor 0.7 (opposed to RFC5681/RFC6675 factor 0.5 ) >>>>>> impacts >>>> the >>>>>> fast recovery operation (assuming PRR not in) - while it does of >>>>>> course not impact the fast retransmission code lines which >>>>>> presumably just related to the CWND as updated by the CC logic - is >>>>>> that what you mean ? >>>>> Yes. >>>>> >>>>>> Or do you mean to say that - in Linux implementation - the >>>>>> 0.7*prior >>>> CWND >>>>>> only impacts the CC evaluations at the _end of_ recovery ? >>>>> The 0.7x impacts behavior during recovery as well (though it is >>>>> indirect, in the sense of setting a target number of packets to have >>>>> in flight). >>>>> >>>>>> I think that you have confirmed that the time t starts at _end_ of >>>>>> fast recovery - Correctly understood ? >>>>> Yes, the CUBIC t is measured relative to the end of fast recovery. >>>>> >>>>> neal From nobody Thu Mar 10 23:38:05 2016 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 E4BEF12D560 for ; Thu, 10 Mar 2016 23:38:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=tieto.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 KQBfmSt0II8r for ; Thu, 10 Mar 2016 23:38:01 -0800 (PST) Received: from mail-io0-x22a.google.com (mail-io0-x22a.google.com [IPv6:2607:f8b0:4001:c06::22a]) (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 D955912D557 for ; Thu, 10 Mar 2016 23:38:00 -0800 (PST) Received: by mail-io0-x22a.google.com with SMTP id g203so135616815iof.2 for ; Thu, 10 Mar 2016 23:38:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tieto.com; s=google; h=from:references:in-reply-to:mime-version:thread-index:date :message-id:subject:to:cc; bh=Rrvr9dfYT5bw86JvMx/e69GOwQl+KQeoMY07fg4pL0g=; b=jIcebjYvtXG/pdINuy+zwoWoLz/sGFdV35VaIP1kchqBbIaIhN7LhnAwgMCcrP/fZ4 khvyQ9DxexfNP2TjdWrYILfyp3P2oHY9N2tPpJ6zI4B33+u4ShjGsAXvKkcNRlIyXZDE jWMrI3PYhCOkC04W9qqNNAQX3f1TAh5EebaJw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:references:in-reply-to:mime-version :thread-index:date:message-id:subject:to:cc; bh=Rrvr9dfYT5bw86JvMx/e69GOwQl+KQeoMY07fg4pL0g=; b=HeFQmrjM6tPoWB3wjaMS5EMPb0fklAhjoManRgOIvntwNfUqEr4rPsU/Or252uCQF3 bnrUzcW5vurrrpjtQovCAoA7yHG7J5OBLefnuh6PAPzFBeX3ENquPwhKjb+irq1xOfcF oMV/L2DQ7WbYaU4/nTcuvMMPjXeXGtaJB9pHyDPxV2kvQ9xxLK2AEKpKmKDHGIZyZR5K 6ybxv0tD3/lF+mT50YIV601G2rETjj4PuBWBMi+dSrB3afVJ4rwnGTjLcNtiTF0iVXop Fiang/tsGEN6qlpiksB22b0cuW/ATWYHCza99n1FObU20+4Mmev3u/BWrTk7afQM1kW+ Y+MQ== X-Gm-Message-State: AD7BkJI4ER3WsOXHA9Lu9yUhc2Q0Rw1NFehK1NutqQkvY1EcT+VWhvOXOXNXyOLsKnLO5dp+N1kstEFc5z9vFtOB98AlFh8N3BeDHFv6HXrv4Zr+vfOQ1WJ8CZcBdxkcLy2P7Vw= X-Received: by 10.107.157.70 with SMTP id g67mr7551960ioe.38.1457681880236; Thu, 10 Mar 2016 23:38:00 -0800 (PST) From: Karen Elisabeth Egede Nielsen References: <90e80f38b10a81626591d3cede931e35@mail.gmail.com> <13e7f67fe56c46b4d5d829e83d29a532@mail.gmail.com> <28921_1457450716_u28FPF2J024715_CADVnQymVHbe24Tpv1TsK4XGa1nyxhAv3sKfKudr3uxYFOEtCdA@mail.gmail.com> <56DF9033.8090205@unl.edu> <89a1b31e152a6cb038389eaef39e21fc@mail.gmail.com> <56E03FE0.4090407@unl.edu> <56E18949.5060006@unl.edu> In-Reply-To: <56E18949.5060006@unl.edu> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQIalpcGbWSSO5ocbu2GX5HnKQuzVgFTaC3bAaa6LhUCVRGaNgKL5105AiyHCGACCO0kvgIzH1Z3AfXk9j6eP9Ia0A== Date: Fri, 11 Mar 2016 08:37:58 +0100 Message-ID: <2986aff9469abac2187377ef602667af@mail.gmail.com> To: Lisong Xu , Neal Cardwell Content-Type: text/plain; charset=UTF-8 X-DomainID: tieto.com Archived-At: Cc: tcpm@ietf.org, draft-ietf-tcpm-cubic@ietf.org Subject: Re: [tcpm] Question on CUBIC and its TCP CC RFC basics X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 11 Mar 2016 07:38:04 -0000 Hi Lisong, Thanks. So it seems application limitations are not taken into account in the TCP friendliness function. I.e. ACK's arriving while window is underutilized will make the window be increased. Correct ? BR, Karen > -----Original Message----- > From: Lisong Xu [mailto:xu@unl.edu] > Sent: 10. marts 2016 15:49 > To: Karen Elisabeth Egede Nielsen ; Neal > Cardwell > Cc: tcpm@ietf.org; draft-ietf-tcpm-cubic@ietf.org > Subject: Re: [tcpm] Question on CUBIC and its TCP CC RFC basics > > Hi Karen, > > Eq 4 is implemented at lines 482-483 and 305-322. > > https://github.com/torvalds/linux/blob/30927520dbae297182990bb21d08762 > bcc35ce1d/net/ipv4/tcp_cubic.c > > Thanks > Lisong > > > On 3/10/2016 7:19 AM, Karen Elisabeth Egede Nielsen wrote: > > HI Lisong, Neal, > > > > Thank you so much for the information. > > I think that I will have to understand the TCP_friendly reactions a > > little better. > > The motivation and the analysis done. Also understanding application > > limitation aspects. > > > > In terms of the CUBIB CC application limitation then for SCTP we may > > (at least initially) choose the approach of restarting the CUBIC CC > > slope. > > Which was not the choice taken for the fix in Linux TCP, I understand > > from: > > > https://github.com/torvalds/linux/commit/30927520dbae297182990bb21d08 > 7 > > 62bcc35ce1d But as the application limitation of SCTP is more > > conservative and restricted than for TCP then this more aggressive > > ramp up after application limitations may be ok. (We will see about > > that). > > > > Returning to the TCP_friendly function - - - > > > > would you say that the behavior _implemented_, analysed and tested > > (and > > deployed) is represented by > > > > the description in section 3.2 of the draft > > https://datatracker.ietf.org/doc/draft-ietf-tcpm-cubic/?include_text=1 > > - > > i.e.: > > > > W_aimd(t) = W_max*beta_aimd + > > [3*(1-beta_aimd)/(1+beta_aimd)] * (t/RTT) (Eq. 4) > > > > I cannot say that I have understood that this is achieved by the linux > > implementation which seems to relate to a cwnd calculated by CC CUBIC > > to estimate the TCP CC window. But perhaps it is ok.... > > > > Have you modified this to relate to TCP CC implementing cwnd > > validation during application limitations proper ? > > > > Many Thanks. > > BR, Karen > > > >> -----Original Message----- > >> From: Lisong Xu [mailto:xu@unl.edu] > >> Sent: 9. marts 2016 16:23 > >> To: Karen Elisabeth Egede Nielsen > >> Cc: Neal Cardwell ; tcpm@ietf.org; > >> draft-ietf-tcpm- cubic@ietf.org > >> Subject: Re: [tcpm] Question on CUBIC and its TCP CC RFC basics > >> > >> > >> > >> On 3/9/2016 4:26 AM, Karen Elisabeth Egede Nielsen wrote: > >>> HI Neal, Lisong, others > >>> > >>> Thank you both. > >>> > >>> Sorry for asking "stupid" questions, but could you be so kind as to > >>> comment on the following also, :-): > >>> > >>> My simple understanding of CUBIC CC (with ABC glasses on) is that > >>> instead of incrementing CWND by 1 MTU/MSS per CWND bytes > >>> acknowledged, CUBIC CC dictates to increment CWND by 1 MTU per > >>> MTU*CWND/(CUBIC_target - > >>> CWND) bytes acknowledged. > >>> (here CUBIC_Target=W(t+RTT) calculated in bytes)) > >>> > >>> Can you help me understand why the "TCP friendliness" relates to an > >>> average Reno window at a given time and not just simply to that at > >>> any given time ( CWND_cnt_bytes =) MTU*CWND/(CUBIC_target - > CWND) > >> should > >>> be clamped by CWND. > >>> I.e., never be allowed to go higher than CWND - ? > >> Hi Karen, > >> > >> "tcp friendliness" is about the relation between the long-term > >> average window size of cubic and that of reno. Because the long-term > >> average window size depends on both the increase function (what you > >> mentioned > >> above) and the decrease parameter (i.e., the beta), we check "tcp > >> friendliness" only periodically at some points. > >> > >> Thanks > >> Lisong > >> > >>> Perhaps this is just a (choice of) implementation issue (?) - If > >>> there are logical reason then I am probably just missing something.... > >>> > >>> Many Thanks in advance. > >>> > >>> BR, Karen > >>> > >>>> -----Original Message----- > >>>> From: Lisong Xu [mailto:xu@unl.edu] > >>>> Sent: 9. marts 2016 03:54 > >>>> To: Neal Cardwell ; Karen Elisabeth Egede > >>>> Nielsen > >>>> Cc: tcpm@ietf.org; draft-ietf-tcpm-cubic@ietf.org > >>>> Subject: Re: [tcpm] Question on CUBIC and its TCP CC RFC basics > >>>> > >>>> Thanks, Neal, for answering these questions. I was on my trip the > >>>> whole day, and just came back to home. > >>>> Lisong > >>>> > >>>> On 3/8/2016 9:24 AM, Neal Cardwell wrote: > >>>>> On Tue, Mar 8, 2016 at 9:18 AM, Karen Elisabeth Egede Nielsen > >>>>> wrote: > >>>>>>> But at least in Linux that is not a change in the fast recovery > >>>>>>> code; that is a different approach the congestion control module > >>>>>>> uses to calculate the target cwnd that the fast recovery code > >>>>>>> (independent of the congestion control module) reaches at the > >>>>>>> end of recovery. > >>>>>>> > >>>>>> [Karen Elisabeth Egede Nielsen] hmm - not sure I understand this. > >>>>>> I > >>>> asume > >>>>>> that the CWND used _during_ FR is the 0.7*prior value CWND > >>>>> In Linux CUBIC the cwnd used during FR is determined by the Linux > >>>>> PRR code (RFC 6937), operating with an ssthresh value calculated > >>>>> by the congestion control module. > >>>>> > >>>>>> And that the factor 0.7 (opposed to RFC5681/RFC6675 factor 0.5 ) > >>>>>> impacts > >>>> the > >>>>>> fast recovery operation (assuming PRR not in) - while it does of > >>>>>> course not impact the fast retransmission code lines which > >>>>>> presumably just related to the CWND as updated by the CC logic - > >>>>>> is that what you mean ? > >>>>> Yes. > >>>>> > >>>>>> Or do you mean to say that - in Linux implementation - the > >>>>>> 0.7*prior > >>>> CWND > >>>>>> only impacts the CC evaluations at the _end of_ recovery ? > >>>>> The 0.7x impacts behavior during recovery as well (though it is > >>>>> indirect, in the sense of setting a target number of packets to > >>>>> have in flight). > >>>>> > >>>>>> I think that you have confirmed that the time t starts at _end_ > >>>>>> of fast recovery - Correctly understood ? > >>>>> Yes, the CUBIC t is measured relative to the end of fast recovery. > >>>>> > >>>>> neal From nobody Fri Mar 11 05:05:15 2016 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 C059112D68E for ; Fri, 11 Mar 2016 05:05:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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, 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 KUMiJxbKaWnu for ; Fri, 11 Mar 2016 05:05:09 -0800 (PST) Received: from mail-ob0-x231.google.com (mail-ob0-x231.google.com [IPv6:2607:f8b0:4003:c01::231]) (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 3547C12D57C for ; Fri, 11 Mar 2016 05:05:09 -0800 (PST) Received: by mail-ob0-x231.google.com with SMTP id ts10so112184993obc.1 for ; Fri, 11 Mar 2016 05:05:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=xyoJhmsmwgciuchWcnTgs5Eot+7khBq72FwLtNDMrfw=; b=mUgitUC48qnAEnTYC/4n9pTRR8R2hlfTxwYnj8ZUNcxfTwzhDQ1DyBpbMkQXE48+Ju XSYfZzGZxB6OXwcRnZuUoPNdKubj2PD/162vYMf8yTlCM0hoRScNcDJndTt4PyEbIbVV 0zSFEE3Ax7dJOCAsN5MevR3B5vhdbCDJZOx2hcXyPL3LW0d05FDFbmvP3tZonrbd9FzK 6kOUKso8HAfTXWIgAPCr628PZrnrYtjlAjm+sTuN8IKcFOWssEYiFuK9dvpJpMBlSB5T Zc+bVt9PnG+H/Uy/zi91lKtC35eBG44zuE+zERFisIHg5JYggJzi0qWcXFh1Ws+9rzzJ 5+Kw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=xyoJhmsmwgciuchWcnTgs5Eot+7khBq72FwLtNDMrfw=; b=I6kAF49rYFY+DAI3koN00ARQfWvhBZd3YpFYfKtDohzfa97ZHjqxSafqOOAJeiZPtn Gm7WyyKkivWgPp+dmVWRVfPS4M10r3yDS1yWwfxNuSI+KEwIvW+6qby5G9L69TpVdysv yvdMWV4rGF2dbMKCy/R0QIxsjz/V6du9saL/8GlYnfGJ+ISLD35gcF+LKLk6EtwPlqly qxQz517mAtfzYbzw1AnDmZ0N9K3nxd/h1/jtFe7GBgCp1JCWaWKt/5d5k3BHWJQW8sTG TpOrGxOlIorMKQQUugpKR3hhr3hozSXA3eRvWvaYki0KFsvBcBxWvEsIuNVvSqM99yqK T3DQ== X-Gm-Message-State: AD7BkJIfAeM7DWuq2xH55z0zgVcwiOq+G1g3gGjJBQsHNnRCUfppSDdUJ8JH+mbSe2jLm5dCLCnx6FPBb2gj66NB MIME-Version: 1.0 X-Received: by 10.182.225.231 with SMTP id rn7mr5820132obc.2.1457701508515; Fri, 11 Mar 2016 05:05:08 -0800 (PST) Received: by 10.202.203.132 with HTTP; Fri, 11 Mar 2016 05:05:08 -0800 (PST) In-Reply-To: <2986aff9469abac2187377ef602667af@mail.gmail.com> References: <90e80f38b10a81626591d3cede931e35@mail.gmail.com> <13e7f67fe56c46b4d5d829e83d29a532@mail.gmail.com> <28921_1457450716_u28FPF2J024715_CADVnQymVHbe24Tpv1TsK4XGa1nyxhAv3sKfKudr3uxYFOEtCdA@mail.gmail.com> <56DF9033.8090205@unl.edu> <89a1b31e152a6cb038389eaef39e21fc@mail.gmail.com> <56E03FE0.4090407@unl.edu> <56E18949.5060006@unl.edu> <2986aff9469abac2187377ef602667af@mail.gmail.com> Date: Fri, 11 Mar 2016 08:05:08 -0500 Message-ID: From: Neal Cardwell To: Karen Elisabeth Egede Nielsen Content-Type: multipart/alternative; boundary=001a11c2f2029afde0052dc594dc Archived-At: Cc: "tcpm@ietf.org" , draft-ietf-tcpm-cubic@ietf.org Subject: Re: [tcpm] Question on CUBIC and its TCP CC RFC basics X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 11 Mar 2016 13:05:14 -0000 --001a11c2f2029afde0052dc594dc Content-Type: text/plain; charset=UTF-8 On Fri, Mar 11, 2016 at 2:37 AM, Karen Elisabeth Egede Nielsen < karen.nielsen@tieto.com> wrote: > Hi Lisong, > > Thanks. > > So it seems application limitations are not taken into account in the TCP > friendliness function. > I.e. ACK's arriving while window is underutilized will make the window be > increased. > Correct ? > I suggest reading the Linux CUBIC code. The code (in the first check in the main CUBIC function, bictcp_cong_avoid()) returns without doing anything if the flow is not cwnd-limited, as determined by calling tcp_is_cwnd_limited(): http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/net/ipv4/tcp_cubic.c?id=afd2ff9b7e1b367172f18ba7f693dfb62bdcb2dc#n341 So the TCP friendliness function will not use ACKs that arrive while the connection is not cwnd-limited. neal --001a11c2f2029afde0052dc594dc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On F= ri, Mar 11, 2016 at 2:37 AM, Karen Elisabeth Egede Nielsen <karen.ni= elsen@tieto.com> wrote:
Hi Lisong,

Thanks.

So it seems application limitations are not taken into account in the TCP friendliness function.
I.e. ACK's arriving while window is underutilized will make the window = be
increased.
Correct ?

I suggest reading the Linux CUBIC = code. The code (in the first check in the main CUBIC function, bictcp_cong_= avoid()) returns without doing anything if the flow is not cwnd-limited, as= determined by calling tcp_is_cwnd_limited():


So the TCP friendliness function will not use ACKs that a= rrive while the connection is not cwnd-limited.

ne= al

--001a11c2f2029afde0052dc594dc-- From nobody Fri Mar 11 05:34:00 2016 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 D44BD12D6C0 for ; Fri, 11 Mar 2016 05:33:55 -0800 (PST) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=tieto.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 h77trjhr1unP for ; Fri, 11 Mar 2016 05:33:52 -0800 (PST) Received: from mail-ig0-x231.google.com (mail-ig0-x231.google.com [IPv6:2607:f8b0:4001:c05::231]) (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 D425812D6D7 for ; Fri, 11 Mar 2016 05:33:41 -0800 (PST) Received: by mail-ig0-x231.google.com with SMTP id ig19so10891956igb.1 for ; Fri, 11 Mar 2016 05:33:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tieto.com; s=google; h=from:references:in-reply-to:mime-version:thread-index:date :message-id:subject:to:cc; bh=YzfuewhtP2DDPrXffAR1TgNeFSUIbo40SQ0Dx056M2I=; b=WfwpmQBai+bdJzqginOkgGhOsByvW1Bh+vK2KdR5ZQ0crPWn3/WG98Qahy0c8nKC3e Q6jeQ814YltDoyPJOzgyjjeQRJTLfaCA75tlyNYyrDxj+90hVw14DW5lbkZZms7cnUya EYShdu2YtfZqbuk5icUwKXbAZA50utnRE7ckE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:references:in-reply-to:mime-version :thread-index:date:message-id:subject:to:cc; bh=YzfuewhtP2DDPrXffAR1TgNeFSUIbo40SQ0Dx056M2I=; b=JOGeJdqkGVyWzL9F7S6dxjn9UKRqu6enEjSeaGe/AiiQfr0Jb9krHZr8cdlgF0OCYT zrFeIrKi+ihM+PiYLVbZqrLudxg8x5sj8LflrxJJo4RXfMmOEDNdBtPOkCF3f+wKUkBR oaDTrSLd8x9v1Eyi+tMLbnKXNqgkuOajPFS8SRmAQ091lY9t2d5BrAQhTm7zphO3DhxB 79LvNA+1qpLW2XptYEbfZxGmsJQIYhJFAtsgTrAtP0W9CZb2MzphbkfASKF/QyxtDDd8 pyF+Hw7j+Xt10mlkA1a2coHKBDxlkumobNL4xEszrRAMBzKCn3GMzDuW5wKDDVvuGw1e z3Jg== X-Gm-Message-State: AD7BkJL5stuUr1EwEo0MyZLB9aAZPZAY4wz0kH7Qg9EjPgWTS5gOsurNcu78mvUiu51iH36V3PFL7LED2uM5GgBwyQKNC8spwSPieOqeMWI7pfg4qBfWlvzjh6rNVA//9oZG1Vw= X-Received: by 10.50.79.136 with SMTP id j8mr3353940igx.24.1457703221202; Fri, 11 Mar 2016 05:33:41 -0800 (PST) From: Karen Elisabeth Egede Nielsen References: <90e80f38b10a81626591d3cede931e35@mail.gmail.com> <13e7f67fe56c46b4d5d829e83d29a532@mail.gmail.com> <28921_1457450716_u28FPF2J024715_CADVnQymVHbe24Tpv1TsK4XGa1nyxhAv3sKfKudr3uxYFOEtCdA@mail.gmail.com> <56DF9033.8090205@unl.edu> <89a1b31e152a6cb038389eaef39e21fc@mail.gmail.com> <56E03FE0.4090407@unl.edu> <56E18949.5060006@unl.edu> <2986aff9469abac2187377ef602667af@mail.gmail.com> In-Reply-To: MIME-Version: 1.0 X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQIalpcGbWSSO5ocbu2GX5HnKQuzVgFTaC3bAaa6LhUCVRGaNgKL5105AiyHCGACCO0kvgIzH1Z3AfXk9j4BneAi6wFZvdaknih7o1A= Date: Fri, 11 Mar 2016 14:33:39 +0100 Message-ID: To: Neal Cardwell , Lisong Xu Content-Type: multipart/alternative; boundary=089e013a110ab04b61052dc5fa57 X-DomainID: tieto.com Archived-At: Cc: tcpm@ietf.org, draft-ietf-tcpm-cubic@ietf.org Subject: Re: [tcpm] Question on CUBIC and its TCP CC RFC basics X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 11 Mar 2016 13:33:56 -0000 --089e013a110ab04b61052dc5fa57 Content-Type: text/plain; charset=UTF-8 Hi Neal, Thanks for the information. (I have not followed up by checking consistency of the code ;-)) as my particular concern is to understand what CUBIC CC is (or is supposed to be). I think that it would be very useful to add this description of the TCP friendliness function in https://datatracker.ietf.org/doc/draft-ietf-tcpm-cubic/ as it is supposed to reflect the Linux CUBIC implementation. BR, Karen *From:* Neal Cardwell [mailto:ncardwell@google.com] *Sent:* 11. marts 2016 14:05 *To:* Karen Elisabeth Egede Nielsen *Cc:* Lisong Xu ; tcpm@ietf.org; draft-ietf-tcpm-cubic@ietf.org *Subject:* Re: [tcpm] Question on CUBIC and its TCP CC RFC basics On Fri, Mar 11, 2016 at 2:37 AM, Karen Elisabeth Egede Nielsen < karen.nielsen@tieto.com> wrote: Hi Lisong, Thanks. So it seems application limitations are not taken into account in the TCP friendliness function. I.e. ACK's arriving while window is underutilized will make the window be increased. Correct ? I suggest reading the Linux CUBIC code. The code (in the first check in the main CUBIC function, bictcp_cong_avoid()) returns without doing anything if the flow is not cwnd-limited, as determined by calling tcp_is_cwnd_limited(): http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/net/ipv4/tcp_cubic.c?id=afd2ff9b7e1b367172f18ba7f693dfb62bdcb2dc#n341 So the TCP friendliness function will not use ACKs that arrive while the connection is not cwnd-limited. neal --089e013a110ab04b61052dc5fa57 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hi= Neal,

=C2= =A0

Thanks f= or the information. (I have not followed up by checking consistency of the = code ;-)) as my particular concern

is to understand what CUBIC CC is (or is supposed to= be).

=C2=A0=

I think tha= t it would be very useful to add this description of the TCP friendliness f= unction in

<= a href=3D"https://datatracker.ietf.org/doc/draft-ietf-tcpm-cubic/">https://= datatracker.ietf.org/doc/draft-ietf-tcpm-cubic/

as it is supposed to reflect the Li= nux CUBIC implementation.

=C2=A0

BR, Karen

=C2=A0

From: Neal Cardwell [mailto:ncardwell@google.com]
Sent:= 11. marts 2016 14:05
To: Karen Elisabeth Egede Nielsen <karen.nielsen@tieto.com>
Cc: Lisong Xu <xu@unl.edu>; tcpm@ietf.org; draft-ietf-tcpm-cubic@ietf.org
Subject:<= /b> Re: [tcpm] Question on CUBIC and its TCP CC RFC basics

=

=C2=A0

On Fri, Mar 11, 2016 at 2:37 AM, Karen Elisab= eth Egede Nielsen <karen.nielsen@tieto.com> wrote:

Hi Lisong,

Thanks.=

So it seems application limitations are not taken into account in t= he TCP
friendliness function.
I.e. ACK's arriving while window is= underutilized will make the window be
increased.
Correct ?

=C2=A0

I= suggest reading the Linux CUBIC code. The code (in the first check in the = main CUBIC function, bictcp_cong_avoid()) returns without doing anything if= the flow is not cwnd-limited, as determined by calling tcp_is_cwnd_limited= ():

=C2=A0

=C2=A0

So the TCP friendliness function will not use ACKs that arri= ve while the connection is not cwnd-limited.

=C2=A0

neal

=C2=A0

--089e013a110ab04b61052dc5fa57-- From nobody Fri Mar 11 05:44:23 2016 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 E38DE12D65C; Fri, 11 Mar 2016 05:44:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.921 X-Spam-Level: X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-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 PhIW2XpC12tH; Fri, 11 Mar 2016 05:44:19 -0800 (PST) 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 496F412D1DC; Fri, 11 Mar 2016 05:44:19 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.24,320,1455004800"; d="asc'?scan'208,217";a="103379086" Received: from hioexcmbx07-prd.hq.netapp.com ([10.122.105.40]) by mx144-out.netapp.com with ESMTP; 11 Mar 2016 05:43:53 -0800 Received: from HIOEXCMBX07-PRD.hq.netapp.com (10.122.105.40) by hioexcmbx07-prd.hq.netapp.com (10.122.105.40) with Microsoft SMTP Server (TLS) id 15.0.1156.6; Fri, 11 Mar 2016 05:43:53 -0800 Received: from HIOEXCMBX07-PRD.hq.netapp.com ([::1]) by hioexcmbx07-prd.hq.netapp.com ([fe80::2562:be45:d6a5:1743%21]) with mapi id 15.00.1156.000; Fri, 11 Mar 2016 05:43:53 -0800 From: "Eggert, Lars" To: Karen Elisabeth Egede Nielsen Thread-Topic: [tcpm] Question on CUBIC and its TCP CC RFC basics Thread-Index: AdF5G955RUuawLpHQySBaD4MNu8nyAAatXyAAABzCoAACZd++wAgkKwAAAphLQAALfxdgAADGaOAACM/sgAAC20ZAAAA/vaAAABa5YA= Date: Fri, 11 Mar 2016 13:43:53 +0000 Message-ID: References: <90e80f38b10a81626591d3cede931e35@mail.gmail.com> <13e7f67fe56c46b4d5d829e83d29a532@mail.gmail.com> <28921_1457450716_u28FPF2J024715_CADVnQymVHbe24Tpv1TsK4XGa1nyxhAv3sKfKudr3uxYFOEtCdA@mail.gmail.com> <56DF9033.8090205@unl.edu> <89a1b31e152a6cb038389eaef39e21fc@mail.gmail.com> <56E03FE0.4090407@unl.edu> <56E18949.5060006@unl.edu> <2986aff9469abac2187377ef602667af@mail.gmail.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.3112) x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.120.60.34] Content-Type: multipart/signed; boundary="Apple-Mail=_71ED25E8-32E0-408B-A58F-954551423640"; protocol="application/pgp-signature"; micalg=pgp-sha256 MIME-Version: 1.0 Archived-At: Cc: "tcpm@ietf.org" , "draft-ietf-tcpm-cubic@ietf.org" Subject: Re: [tcpm] Question on CUBIC and its TCP CC RFC basics X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 11 Mar 2016 13:44:22 -0000 --Apple-Mail=_71ED25E8-32E0-408B-A58F-954551423640 Content-Type: multipart/alternative; boundary="Apple-Mail=_C18604EF-8541-4B0A-9EAA-3B71885778CE" --Apple-Mail=_C18604EF-8541-4B0A-9EAA-3B71885778CE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 2016-03-11, at 14:33, Karen Elisabeth Egede Nielsen = wrote: >=20 > I think that it would be very useful to add this description of the = TCP friendliness function in > https://datatracker.ietf.org/doc/draft-ietf-tcpm-cubic/ = > as it is supposed to reflect the Linux CUBIC implementation. Agreed. The main reason for the ID is to document CUBIC so that people = do not have to read GPL code to implement it. Lars --Apple-Mail=_C18604EF-8541-4B0A-9EAA-3B71885778CE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On 2016-03-11, at 14:33, Karen Elisabeth Egede Nielsen <karen.nielsen@tieto.com> wrote:

I think that it would = be very useful to add this description of the TCP friendliness function = in
https://datatracker.ietf.org/doc/draft-ietf-tcpm-cubic/
as = it is supposed to reflect the Linux CUBIC = implementation.

Agreed. The main reason for the ID is to document = CUBIC so that people do not have to read GPL code to implement = it.

Lars
= --Apple-Mail=_C18604EF-8541-4B0A-9EAA-3B71885778CE-- --Apple-Mail=_71ED25E8-32E0-408B-A58F-954551423640 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQIcBAEBCAAGBQJW4suWAAoJEFS1wwm/cMFXsacP/1+JBu3ItjG7uRkVhnqWof5y WZkAbYtkpl7dzOihPngsENSa5uyy32WHUuIuGDGedoFOZQykk6ETF8TrVzhIQ/Yk 8v9hLzgluDTPQ1Qa9NKitehu3OqGF4bqxuwwmbrMkg3Cta+0o2FNy1FYHM5lpAIM SBglvsg6aNYWNcxrEQGtRvpTRjiIoHXubNYgeYrJrw6AhTBBRt+CC3j9enBRZO7K TMHUZd5uO3n3/uJ0YgTtT7g8V+pBO9YUS1SJhsx4RRDsQ/8Hiq0OuWfJM5aRtkUI 2NRUpdOxdcv50eyz5sBOPG/OGiOb7B3AeielpvtPrTOtYDOzMrHksUN/SP9ceUqV 0o1NRAraffbFA0MnvOYhyTmb7sCilEG9fMKRL88RcezeprImEmHfzy1ib44yEggJ fc62+xE8xRBaC0rTLnU/J2qV+5lVCYwyzMSr3HBrLYjpM9liUlXnFONz+5l3R13K Po7QY1uhuN6FdUoNgREaO9RnT0+18k3YXaC442xl2ocs4sk0tosmWflqUjEOx6it 0NkoxFcMJxYuFFXyFFfoI2deKO/kV9kpQn+Dcz57nfjmAAYvV3oxBy+ETJbmLamf ucxV2d/Nn5Qo33a9BycUbGPB7krnmveohyUUZMMm6gGZGzdrsxPMOFZHnL2ldThc w5dZNsRFdKKCARFv7j+Y =X1GQ -----END PGP SIGNATURE----- --Apple-Mail=_71ED25E8-32E0-408B-A58F-954551423640-- From nobody Fri Mar 11 06:54:34 2016 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 BF9B812D771; Fri, 11 Mar 2016 06:54:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.791 X-Spam-Level: X-Spam-Status: No, score=-1.791 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=uofnelincoln.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 JXA2jFNmER57; Fri, 11 Mar 2016 06:54:28 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0182.outbound.protection.outlook.com [207.46.163.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77D7612D7E4; Fri, 11 Mar 2016 06:54:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uofnelincoln.onmicrosoft.com; s=selector1-unl-edu; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=IlD5V4GF/0dBl6AszRI6kC6Vsh8MCu3cpqY53QPZ4Jg=; b=DrSK7nHdOFGhjzp5tcLbm3T+VUw2vlkmcR0T3k/74qXY8VKOSQNzREqc6uxgyNau9ntqACF1ZuOHkbEomMr/EgTq7Yk6fyQagpEd+LB4N3CrCfCjiuI6P/qe8CL5uZ+9niEYjM2lmVi25IQJaQo1TMwRME7lb155RFm1Xb6RNNo= Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=unl.edu; Received: from [192.168.0.164] (97.98.140.59) by SN1PR08MB1470.namprd08.prod.outlook.com (10.162.2.13) with Microsoft SMTP Server (TLS) id 15.1.427.16; Fri, 11 Mar 2016 14:54:05 +0000 To: "Eggert, Lars" , Karen Elisabeth Egede Nielsen References: <90e80f38b10a81626591d3cede931e35@mail.gmail.com> <13e7f67fe56c46b4d5d829e83d29a532@mail.gmail.com> <28921_1457450716_u28FPF2J024715_CADVnQymVHbe24Tpv1TsK4XGa1nyxhAv3sKfKudr3uxYFOEtCdA@mail.gmail.com> <56DF9033.8090205@unl.edu> <89a1b31e152a6cb038389eaef39e21fc@mail.gmail.com> <56E03FE0.4090407@unl.edu> <56E18949.5060006@unl.edu> <2986aff9469abac2187377ef602667af@mail.gmail.com> <9492_1457703864_u2BDiOsD015461_EABBC867-4851-4CC9-AABF-E7F8659DF50B@netapp.com> From: Lisong Xu Organization: University of Nebraska-Lincoln Message-ID: <56E2DC1D.80501@unl.edu> Date: Fri, 11 Mar 2016 08:54:21 -0600 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <9492_1457703864_u2BDiOsD015461_EABBC867-4851-4CC9-AABF-E7F8659DF50B@netapp.com> Content-Type: multipart/alternative; boundary="------------010606000300090104000806" X-Originating-IP: [97.98.140.59] X-ClientProxiedBy: BY2PR1001CA0079.namprd10.prod.outlook.com (25.164.163.47) To SN1PR08MB1470.namprd08.prod.outlook.com (25.162.2.13) X-MS-Office365-Filtering-Correlation-Id: c3b894cd-5aae-41c5-1cf2-08d349bcfebe X-Microsoft-Exchange-Diagnostics: 1; SN1PR08MB1470; 2:wJ7mTQeStE8qoGojPTETS3kx1Yyp/lPKK3qR6w1PG0CIGNckcP+SfxPVG/UIl2svfBI81+IdLb7xmce0TRiOjkMA9DGnGn9zRv8/WOXI2y9VmDVbH/lBEVEoxeYUOfmVOZSkrh4stHNu4ahXmVh/1YGDcRSb90Vs70SN032ZBFVJGV+AGVI1pKxcW8fm2XiN; 3:PtUTP2lg1rITl5cOaayDuGbhzz5GGrShCggNbVc/r8opIGZM+sC3GWJFejeaS7StVoLJbf1ld9QTMArLzXyJ6yHRBw+DYcDXGrEI+/VHy+yanUyZCewMkTnvN2+DFTo3; 25:yXzxHrsU5A8xYdCmnRNADQMNUlodK1M8pVl1ZQ++ZONMzCzi5GanbNP0cySLEqhQGGCKRtUG7V98mRLTBQiZeabVJM2SmgG7vdxfHZ8uDKyBYZRNDGkYABXIA707bbf80nN+SUp7/vH86+7akuLaBFYN5RqxEvPkC0Ioei+fBo00sjdQeuOYn28rCYaFCX5x6/pZwdPQa+tZ/IXCknfFBZloX1OpIV5i4U0kqfm9jL2X2Hd1aGRt8QKFbw0H3Ql7HYFSlR1v/Mo4btgdmmSzglYcdAeVRYuyA6biwmcmq+KWe0eLQS9BjgE7f4yfrzCjk4CK+YBeVy7iMqfarPmDtA== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN1PR08MB1470; X-Microsoft-Exchange-Diagnostics: 1; SN1PR08MB1470; 20:O1nYO0tgGxEb68P6BBdTP4InShgZehJsdbPh+Cksdw+Qy3ux6ayL8naWmsmltT8TDT9qdmd94zfBnSgEMv3BjmW3U8gNYpXLlPOslpWSbrhIay5qAH4fIXhCbi/3zmUsWWltBpcMBaQw7rgAY10dpNyiq+hTz8E0hOhSTKpyHMOksL909RKYM76yYatCAZc62WcyU0y+n6aJhkGwJft3x2IFQFr47uUlMrxXvtP+zRZVP4n5w63EhXrU0/A+WHI3Jckb8oLxChId4pyXZqVQV40sjnPL++P7BGDVwtQrjUQB3QAEmnVVIA9vici39tHyvdg4mfxEfZTO5t7NhnL7TQZforWDbjMWCql3SMBCUWWCJf8y3usL/UliHqx3kgracAp6xX8xwj7EXHHuagpn6ef3IRewKwJtoclEcwIEdkraTkrATynv/JUBr5aaoAZMSavaPQS58MhWy82MnfWpm5WYXFCvWNNGaQBkQatNBh7XobqZYkWMDB4YdJLlrRzJ; 4:ADn5s1C/3wj4A6HcViXLzKRgtTi9siKaAVlBMxi6PhdvsQlCf1jEUNJtikM1R2Any+zOXihSloxBFEJBU54UkzsJt1xQGzPSGn4w/bIn6lK+PTF4OBKGL9hSuoEttxCwfGUpUp0t8G9L6svj8McA1/ovixOJ+OLYEfPcdV6cmecJFUCb/3T1d87ZRkTAubxz529U/ByhA0sTqIiKQwrpYvc3eDU81cW4+x/YdC49Jlh8xPkHOokj6jnt2E0Nx8ObhcKd4Wy75JV1CeZKFeEkBgRsO/6E5zpOwtlyjpXP8QLV2a/UWSoNWK34S1yGCx0wvc20CfRk91Dv1sZsT6mvSZymcXenoEZG4hOsn0uBD92p4i9rMfgbpGabndWKZSRN X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001); SRVR:SN1PR08MB1470; BCL:0; PCL:0; RULEID:; SRVR:SN1PR08MB1470; X-Forefront-PRVS: 087894CD3C X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6049001)(377454003)(377424004)(479174004)(24454002)(33656002)(81166005)(65806001)(66066001)(50986999)(2950100001)(5004730100002)(76176999)(270700001)(77096005)(3846002)(54356999)(1096002)(75432002)(6116002)(65816999)(19617315012)(16236675004)(586003)(86362001)(64126003)(117156001)(93886004)(36756003)(92566002)(512944002)(90282001)(5008740100001)(15975445007)(42186005)(189998001)(83506001)(19580405001)(5001770100001)(4001350100001)(4326007)(89122001)(2906002)(88552002)(84326002)(19580395003); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1PR08MB1470; H:[192.168.0.164]; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; SN1PR08MB1470; 23:ijvpR2jcMs0npLjRwU0UBfFivqoD72UzMhUl8dgRw?= =?us-ascii?Q?qfZsnA9zSG0hij5HHpwgXQatHvgzy/klu1xO+aD1leB6F59JYIfpAo/Br5E1?= =?us-ascii?Q?Nh7dcJBrjB68wjsF5+0fEoH+Bh5Ur87JQ6yWkz2UBbmiFL7gpTElq4zXW3T8?= =?us-ascii?Q?RcWL+2CKJI3WB68akkASaygkEKRzcR7GHAWtFtvWTKk6wj0oGrH3ebBZJ9qE?= =?us-ascii?Q?oC1qEAwb/BhBsQregT/reQCt5l3nHtn7w3kpHtmTrEWaqy6s+wU5jRYPiAND?= =?us-ascii?Q?vMTWfpk5CwYMb59Y9Cy9F+qnHVuyyuxwWqICSUlwHpf0QK53MJ6MCXUam+ln?= =?us-ascii?Q?nUospMEymEE0u3bRzAUZPjlRWVKwvYdSq2/BNodYBcTp5BQ2TOsZXjmTIzbo?= =?us-ascii?Q?6CkqWShUXVVQ5Ac/ncqV+fK+JSi/iPuSorovYyDGd1LNA/g9sjV7mqHZ19bb?= =?us-ascii?Q?/RIWPTOnobHYe9fqblrj+qBpLVeU9SXZE8V6j5ZiGkwKVhzYGL1xhXwkBMtj?= =?us-ascii?Q?JhQRdMmvLGsUINGWcdcO2U4OrHhxhHV+kavAUoT7Kk1QL5dEKaVg89bcpnoe?= =?us-ascii?Q?y7jzGlR15sJnG+Vwe4+D0YlWaGiDwiTRs2CKgPbc0LHrynQO4v6hvRs5u0mo?= =?us-ascii?Q?x/4nAoNQ+XSGacwvf4/YsuoOOCcSeqIFMOQg3ZGut7ubd93rD2alg884fnTz?= =?us-ascii?Q?cG67NSt4/RsuzPssA2jloPSXOVxhP4+hiuoPmY05DZw4IgKJhpGrcyq5u4Jl?= =?us-ascii?Q?CJTk94VkPAq6b/DWC1vv6EjNkmqpwHCjHUNaDjqkahfLhpLvOP4WDcOxU9QV?= =?us-ascii?Q?cnpFp/SwktaGGiVbqQGfVj0KHDE/YNI6a8KVvQbuGSc6EHKUTf1pFhpycIdX?= =?us-ascii?Q?TCKD9MJxxAOoRcHJ4xhw1ToA6UDxcd1ZTatPo5aG3TwbGo8Y8QsO965JQVqu?= =?us-ascii?Q?kAxYDTvmdH900rTdpfANmaBlAt4PkYmJBl8ZK7/VGpKIozqYYbRuADwdSrOn?= =?us-ascii?Q?cnbae0cTPhBjI9mJrBCXYbNgvGaNP4KMVZ5vZz7h0i6tEKsVSNRjmzc7Dw/M?= =?us-ascii?Q?VIZ3EavB0Mm2B3Ev0rF5aykZ7XQBeoRmcowyk/UM4VHh0bbGu0qEd8cKhKVh?= =?us-ascii?Q?IKCVrV7oUGXJkrPymuvtHrRBCgsU+il4fo4vsIUvK5AI1w4C4HOnWgqu3CKr?= =?us-ascii?Q?NkUrlPLrx+AoNYmlYuV6qILf3EMwpTQq3O3tJAVb6+3FSd3ZfNcFju16FU3D?= =?us-ascii?Q?qiw3ruApGbQO1fr+yo=3D?= X-Microsoft-Exchange-Diagnostics: 1; SN1PR08MB1470; 5:ah9ewCkJoXorly38e8s3mfycEnq0NWY10Nte29WZVQtKA7LnB2OFzVVwmlpkxk7r+pNTr3LNwnJv+n0eXMmxoUTCEpGuYoHt7YuppcL91DW2cdSM4QqPS/zwOhQtSTFyP0FkJNnMwxyOgEzS5KXbPw==; 24:ZiQy1om5T97vyjjzbYKH7ja28SQvD0mgSU5CMhQK90ytHC+ImoNpgdE0MByyhnpFjsZdA0OXkX8CBHrKhUZv+pZTIMnQafJS0WVyMgGTkR0= SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: unl.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Mar 2016 14:54:05.6235 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR08MB1470 Archived-At: Cc: "tcpm@ietf.org" , "draft-ietf-tcpm-cubic@ietf.org" Subject: Re: [tcpm] Question on CUBIC and its TCP CC RFC basics X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 11 Mar 2016 14:54:31 -0000 --------------010606000300090104000806 Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit Thank you all. I will make the following changes in the next version of cubic draft. 1. a new subsection 4.10: add the description about the behaviors of cubic when it is not cwnd-limited. Specifically, cubic does not do anything, when the flow is not limited by the cubic congestion window size. 2. section 3.1 "when there is no further loss event" --> "if there is no further loss event" 3. section 3.1, "t is the elapsed time from the last window reduction" --> "t is the elapsed time from the last window reduction (measured right after the fast recovery)" Is there anything else that I missed? Thanks Lisong On 3/11/2016 7:43 AM, Eggert, Lars wrote: > On 2016-03-11, at 14:33, Karen Elisabeth Egede Nielsen > > wrote: >> >> I think that it would be very useful to add this description of the >> TCP friendliness function in >> https://datatracker.ietf.org/doc/draft-ietf-tcpm-cubic/ >> as it is supposed to reflect the Linux CUBIC implementation. > > Agreed. The main reason for the ID is to document CUBIC so that people > do not have to read GPL code to implement it. > > Lars --------------010606000300090104000806 Content-Type: text/html; charset="windows-1252" Content-Transfer-Encoding: 8bit Thank you all. 

I will make the following changes in the next version of cubic draft.

1. a new subsection 4.10: add the description about the behaviors of cubic when it is not cwnd-limited. Specifically, cubic does not do anything, when the flow is not limited by the cubic congestion window size.

2. section 3.1 "when there is no further loss event" --> "if there is no further loss event"

3. section 3.1, "t is the elapsed time from the last window reduction" --> "t is the elapsed time from the last window reduction (measured right after the fast recovery)"

Is there anything else that I missed?

Thanks
Lisong

On 3/11/2016 7:43 AM, Eggert, Lars wrote:
On 2016-03-11, at 14:33, Karen Elisabeth Egede Nielsen <karen.nielsen@tieto.com> wrote:

I think that it would be very useful to add this description of the TCP friendliness function in
as it is supposed to reflect the Linux CUBIC implementation.

Agreed. The main reason for the ID is to document CUBIC so that people do not have to read GPL code to implement it.

Lars

--------------010606000300090104000806-- From nobody Fri Mar 11 07:18:12 2016 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 2B35212D7B4 for ; Fri, 11 Mar 2016 07:18:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 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_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=unavailable 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 W6KrptUeZPdQ for ; Fri, 11 Mar 2016 07:18:08 -0800 (PST) Received: from mail-oi0-x235.google.com (mail-oi0-x235.google.com [IPv6:2607:f8b0:4003:c06::235]) (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 900C412D7D6 for ; Fri, 11 Mar 2016 07:18:08 -0800 (PST) Received: by mail-oi0-x235.google.com with SMTP id r187so87840945oih.3 for ; Fri, 11 Mar 2016 07:18:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=+Au6yy3spYAGdYaL+F9XVIxunPsKct0FDEXWYCxtA6Q=; b=dPZ+kZFJWBzX9VDgIYMb0iHFleNLU9YCyTWM/W7KonX3Xd8UVIQYaWkFADzz81DJCR enXKyLGGRkCrUvC0y4TH2J88eQFfJqqKmErvTbNDeX+EcRjB0xC5C4afHimj1pWYwOg8 otXHxvaZcq6T9yzIfgZU2ob9uqIr80P0MEPEwc+ugotxyKqVACEjTCp4dnPS4cXKAUBP utz/cw60ja1m+PZgy3IVmLE5/3RyYibOaEfR33B8vsw+/QOBCZYe8hRGGShIS8N5DH9x Nzn4bbsKZiuI4eCjFJdCP7VwEOlp3ANYKvujhSj7zqi4e3H5G+d3vORt3JbQV4Ct//dp Y8qA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=+Au6yy3spYAGdYaL+F9XVIxunPsKct0FDEXWYCxtA6Q=; b=F5IVEwjoWXh8glPRyqpVy+Aw/usNClQXWOvyOZKYXIPLWehVb+YhrmIgNlcXOVaJ1J GOnuO/PeIx21Qff6G+EpwUcl+7WagPId+JcbG3s/a+MusoFh3YWtMZJJmvUFCRwWQJ+Z Sz5u5wKtHmjOECceXlDxTQYmeEv+ntWztMe8bVsKTdYZZPRWDPYUlGp2TdWP0OND0A5M ybLWGZ33fxc1tWeAtUSEe92vcpFsGszYvcwov8hUxk9YdtX8z7TIcX7DzCrRLNc/2vDd XFCTlJTiqgZB2AZLC8ZrrRgabHRkmgOZ1Zg8fuTyaWkYDecOtZwYmm3MCKcQYiitAXhU GTfQ== X-Gm-Message-State: AD7BkJJrP2BkDiS66stRDFggobqr/EuQn8KabB7m9KYYkX4blziyGJPcNRYvR/10SKEXKKynXWQUgXuaxgCZb4Qb MIME-Version: 1.0 X-Received: by 10.202.198.19 with SMTP id w19mr5779339oif.90.1457709487811; Fri, 11 Mar 2016 07:18:07 -0800 (PST) Received: by 10.202.203.132 with HTTP; Fri, 11 Mar 2016 07:18:07 -0800 (PST) In-Reply-To: <56E2DC1D.80501@unl.edu> References: <90e80f38b10a81626591d3cede931e35@mail.gmail.com> <13e7f67fe56c46b4d5d829e83d29a532@mail.gmail.com> <28921_1457450716_u28FPF2J024715_CADVnQymVHbe24Tpv1TsK4XGa1nyxhAv3sKfKudr3uxYFOEtCdA@mail.gmail.com> <56DF9033.8090205@unl.edu> <89a1b31e152a6cb038389eaef39e21fc@mail.gmail.com> <56E03FE0.4090407@unl.edu> <56E18949.5060006@unl.edu> <2986aff9469abac2187377ef602667af@mail.gmail.com> <9492_1457703864_u2BDiOsD015461_EABBC867-4851-4CC9-AABF-E7F8659DF50B@netapp.com> <56E2DC1D.80501@unl.edu> Date: Fri, 11 Mar 2016 10:18:07 -0500 Message-ID: From: Neal Cardwell To: Lisong Xu Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tcpm@ietf.org" , "draft-ietf-tcpm-cubic@ietf.org" Subject: Re: [tcpm] Question on CUBIC and its TCP CC RFC basics X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 11 Mar 2016 15:18:11 -0000 Related to the question of being cwnd-limited, and this sentence in section 3.1: t is the elapsed time from the last window reduction I think it is important to mention that recent versions of Linux CUBIC take care to not include idle time in this "t". The fixes are here: tcp_cubic: better follow cubic curve after idle period http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=30927520dbae297182990bb21d08762bcc35ce1d tcp_cubic: do not set epoch_start in the future http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=c2e7204d180f8efc80f27959ca9cf16fa17f67db The issue was that after long idle periods "t" was including a lot of time spent idle, which was implicitly treated by the algorithm as time spent probing the network without packet loss, leading to very high cwnd values after restarting from idle. If the code takes care to exclude idle time, as in the above changes, then this problem does not show up. neal On Fri, Mar 11, 2016 at 9:54 AM, Lisong Xu wrote: > Thank you all. > > I will make the following changes in the next version of cubic draft. > > 1. a new subsection 4.10: add the description about the behaviors of cubic > when it is not cwnd-limited. Specifically, cubic does not do anything, when > the flow is not limited by the cubic congestion window size. > > 2. section 3.1 "when there is no further loss event" --> "if there is no > further loss event" > > 3. section 3.1, "t is the elapsed time from the last window reduction" --> > "t is the elapsed time from the last window reduction (measured right after > the fast recovery)" > > Is there anything else that I missed? > > Thanks > Lisong > > On 3/11/2016 7:43 AM, Eggert, Lars wrote: > > On 2016-03-11, at 14:33, Karen Elisabeth Egede Nielsen > wrote: > > > I think that it would be very useful to add this description of the TCP > friendliness function in > https://datatracker.ietf.org/doc/draft-ietf-tcpm-cubic/ > as it is supposed to reflect the Linux CUBIC implementation. > > > Agreed. The main reason for the ID is to document CUBIC so that people do > not have to read GPL code to implement it. > > Lars > > From nobody Fri Mar 11 07:21:00 2016 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 37A8C12D7A5 for ; Fri, 11 Mar 2016 07:20:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.69 X-Spam-Level: X-Spam-Status: No, score=-2.69 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, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=tieto.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 XaaCPddD9Oqw for ; Fri, 11 Mar 2016 07:20:56 -0800 (PST) Received: from mail-io0-x22e.google.com (mail-io0-x22e.google.com [IPv6:2607:f8b0:4001:c06::22e]) (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 0F70512D529 for ; Fri, 11 Mar 2016 07:20:55 -0800 (PST) Received: by mail-io0-x22e.google.com with SMTP id g203so149357846iof.2 for ; Fri, 11 Mar 2016 07:20:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tieto.com; s=google; h=from:references:in-reply-to:mime-version:thread-index:date :message-id:subject:to:cc; bh=jSkFq+aDHrYRFgP9kYRgjzix3frPmCMKtvGuvHX7lv8=; b=W37jpe0IUn8F66jZsBkZteR7p5kdAKadUZV2kKvEXVZi8MqlHuwzGtNCQeetfVT+iC Y2mhQQYfEkNiUwqXcmVrOTl0ZDdmyGGSXajAZrIB7ANQxxK1uk/98McVBhLFm6S1OmX7 RJFH9EfSHuLKsT0joRVb24Igss8Tk77l+sPpg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:references:in-reply-to:mime-version :thread-index:date:message-id:subject:to:cc; bh=jSkFq+aDHrYRFgP9kYRgjzix3frPmCMKtvGuvHX7lv8=; b=Jrqer+Ev4Fx//3H33ibsOmih5GOPK7nLZTj0rR0yoifWJ0nPZF4rDIS+4+BxH/CW9k DZPr5kt8Pf0ISyGQZ8oULRuu7HlYB97frQ6k2x9mU2JWMY7jPE0yQBa1i3h0G9srJg9O TnoifBQFRvYcWq/451yOXvMfE8pX0CInCYHOFJaImj2pehbVRGpCewdgqNHZTfeQoPXj KpMxk+LqpN4dX3SVSEz3kq4fPbxtM3OFXJTLY9bb6Nz6goO0wXwd7ZDj530vgygAVdeO cyKRayRwESHxuCtKsQfuXftUkVg6JdVEDQDESo5b+PfnY44k05J7NJZEZHN50NESkpZE gx1g== X-Gm-Message-State: AD7BkJITdKhi4CY8cbJu1lxAfjwkIKTEe2X4KBxiCg86QzQayx8InRM9sf9wKaD9MBSbRHkKlP7g6xsiRoB9jowBpjQx4SLlkkc69eAPcCbPsEruy4tCl+nwAr3cgw1h6qki9aM= X-Received: by 10.107.12.207 with SMTP id 76mr11428203iom.70.1457709655196; Fri, 11 Mar 2016 07:20:55 -0800 (PST) From: Karen Elisabeth Egede Nielsen References: <90e80f38b10a81626591d3cede931e35@mail.gmail.com> <13e7f67fe56c46b4d5d829e83d29a532@mail.gmail.com> <28921_1457450716_u28FPF2J024715_CADVnQymVHbe24Tpv1TsK4XGa1nyxhAv3sKfKudr3uxYFOEtCdA@mail.gmail.com> <56DF9033.8090205@unl.edu> <89a1b31e152a6cb038389eaef39e21fc@mail.gmail.com> <56E03FE0.4090407@unl.edu> <56E18949.5060006@unl.edu> <2986aff9469abac2187377ef602667af@mail.gmail.com> <9492_1457703864_u2BDiOsD015461_EABBC867-4851-4CC9-AABF-E7F8659DF50B@netapp.com> <56E2DC1D.80501@unl.edu> In-Reply-To: <56E2DC1D.80501@unl.edu> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQIalpcGbWSSO5ocbu2GX5HnKQuzVgFTaC3bAaa6LhUCVRGaNgKL5105AiyHCGACCO0kvgIzH1Z3AfXk9j4BneAi6wFZvdakAT4CNH8BhBxwpQItYaMongEfNeA= Date: Fri, 11 Mar 2016 16:20:53 +0100 Message-ID: <27cc5aefa2da6b1f135f3850ec8685f7@mail.gmail.com> To: Lisong Xu , "Eggert, Lars" Content-Type: multipart/alternative; boundary=001a113eca062f34e5052dc77a91 X-DomainID: tieto.com Archived-At: Cc: tcpm@ietf.org, draft-ietf-tcpm-cubic@ietf.org Subject: Re: [tcpm] Question on CUBIC and its TCP CC RFC basics X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 11 Mar 2016 15:20:58 -0000 --001a113eca062f34e5052dc77a91 Content-Type: text/plain; charset=UTF-8 Hi, Thanks, Well the description of TCP friendliness (which as CUBIC relates to a real time parameter (!)) as well as the description of CUBIC CC need to relate to what should happen in respect to application limitation. As fully recognized in the Linux TCP implementation it seems, real time does not stop just because CUBIC does nothing. BR, Karen *From:* Lisong Xu [mailto:xu@unl.edu] *Sent:* 11. marts 2016 15:54 *To:* Eggert, Lars ; Karen Elisabeth Egede Nielsen < karen.nielsen@tieto.com> *Cc:* Neal Cardwell ; tcpm@ietf.org; draft-ietf-tcpm-cubic@ietf.org *Subject:* Re: [tcpm] Question on CUBIC and its TCP CC RFC basics Thank you all. I will make the following changes in the next version of cubic draft. 1. a new subsection 4.10: add the description about the behaviors of cubic when it is not cwnd-limited. Specifically, cubic does not do anything, when the flow is not limited by the cubic congestion window size. 2. section 3.1 "when there is no further loss event" --> "if there is no further loss event" 3. section 3.1, "t is the elapsed time from the last window reduction" --> "t is the elapsed time from the last window reduction (measured right after the fast recovery)" Is there anything else that I missed? Thanks Lisong On 3/11/2016 7:43 AM, Eggert, Lars wrote: On 2016-03-11, at 14:33, Karen Elisabeth Egede Nielsen < karen.nielsen@tieto.com> wrote: I think that it would be very useful to add this description of the TCP friendliness function in https://datatracker.ietf.org/doc/draft-ietf-tcpm-cubic/ as it is supposed to reflect the Linux CUBIC implementation. Agreed. The main reason for the ID is to document CUBIC so that people do not have to read GPL code to implement it. Lars --001a113eca062f34e5052dc77a91 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hi,

=C2=A0

Thanks,

=C2=A0

Well the description of TCP friendliness (which as CUBIC relate= s to a real time parameter (!))

=C2=A0as well as the description of CUBIC CC need to r= elate to what

should happen in respect to application limitation. As fully recognized= in the Linux TCP implementation

it seems, real time does not stop just because CUBIC d= oes nothing.

=C2=A0

BR, = Karen

=C2=A0=

From: Lisong Xu= [mailto:xu@unl.edu]
Sent: 11.= marts 2016 15:54
To: Eggert, Lars <lars@netapp.com>; Karen Elisabeth Egede Nielsen <karen.nielsen@tieto.com>
C= c: Neal Cardwell <ncardwell@= google.com>; tcpm@ietf.org; draft-ietf-tcpm-cubic@ietf.o= rg
Subject: Re: [tcpm] Question on CUBIC and its TCP CC RFC b= asics

=C2=A0

Thank you all.=C2=A0

I will= make the following changes in the next version of cubic draft.

1. a= new subsection 4.10: add the description about the behaviors of cubic when= it is not cwnd-limited. Specifically, cubic does not do anything, when the= flow is not limited by the cubic congestion window size.

2. section= 3.1 "when there is no further loss event" --> "if there = is no further loss event"

3. section 3.1, "t is the elapse= d time from the last window reduction" --> "t is the elapsed t= ime from the last window reduction (measured right after the fast recovery)= "

Is there anything else that I missed?

Thanks
Lisong=

On 3/11/2016 7:43 AM, Eggert, Lars wrote:

On 2016-03-11, at 14:33, Karen Elisabeth Egede Nielsen <<= a href=3D"mailto:karen.nielsen@tieto.com">karen.nielsen@tieto.com> w= rote:

=C2=A0

I think that it would be very useful to add this descri= ption of the TCP friendliness function in

as it is supposed to = reflect the Linux CUBIC implementation.

=

=C2=A0

Agreed. = The main reason for the ID is to document CUBIC so that people do not have = to read GPL code to implement it.

=C2= =A0

Lars

=C2=A0

--001a113eca062f34e5052dc77a91-- From nobody Fri Mar 11 20:47:47 2016 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 5864E12D553; Fri, 11 Mar 2016 20:47:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=uofnelincoln.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 4jbCAfq_Oct8; Fri, 11 Mar 2016 20:47:43 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0206.outbound.protection.outlook.com [207.46.163.206]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8481512D53F; Fri, 11 Mar 2016 20:47:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uofnelincoln.onmicrosoft.com; s=selector1-unl-edu; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=6VM070kU0WbZF/4ZgvCpfI6zN1RLqSoJLNVv5T4A0dk=; b=tEGBvlCoJ8Y/y88V0nu+WElA4lAwiN1OCECWQZz7fsDVjQqppGV94Z0LZz0+hq/0daToCOX7qHLdbvlegsC9kGwYRyzx7FocCLMxm0OVEdRc7nistgGmzvFEraXMX6gttZffUdiruWaFcujVQaRzGiw91VYLDkgiCY8jGlgdGNM= Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=unl.edu; Received: from [192.168.0.164] (97.98.140.59) by SN1PR08MB1472.namprd08.prod.outlook.com (10.162.2.14) with Microsoft SMTP Server (TLS) id 15.1.427.16; Sat, 12 Mar 2016 04:47:41 +0000 To: Neal Cardwell References: <90e80f38b10a81626591d3cede931e35@mail.gmail.com> <13e7f67fe56c46b4d5d829e83d29a532@mail.gmail.com> <28921_1457450716_u28FPF2J024715_CADVnQymVHbe24Tpv1TsK4XGa1nyxhAv3sKfKudr3uxYFOEtCdA@mail.gmail.com> <56DF9033.8090205@unl.edu> <89a1b31e152a6cb038389eaef39e21fc@mail.gmail.com> <56E03FE0.4090407@unl.edu> <56E18949.5060006@unl.edu> <2986aff9469abac2187377ef602667af@mail.gmail.com> <9492_1457703864_u2BDiOsD015461_EABBC867-4851-4CC9-AABF-E7F8659DF50B@netapp.com> <56E2DC1D.80501@unl.edu> From: Lisong Xu Organization: University of Nebraska-Lincoln Message-ID: <56E39F80.2060503@unl.edu> Date: Fri, 11 Mar 2016 22:48:00 -0600 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [97.98.140.59] X-ClientProxiedBy: BLUPR01CA034.prod.exchangelabs.com (25.160.23.24) To SN1PR08MB1472.namprd08.prod.outlook.com (25.162.2.14) X-MS-Office365-Filtering-Correlation-Id: d8e7658b-7960-4501-7ca9-08d34a317238 X-Microsoft-Exchange-Diagnostics: 1; SN1PR08MB1472; 2:btKX74H3/lCfc655wOUGZQdxRUR+ayl21Rc4/86egePcfoqvW3puhnUo+0SBm8LSBs5S37o0iqa/+2841KuI2bFBbUQvWP4eWq/QrP24pjTTfweX+oXh3pG3i3oZHMW+ceG3NVHFmz/ALjaoguPY25gRwpHDbKvenJVLs/o/NPKAw3EbwCSgScgZdOrpq+Gt; 3:jIenEbAEf5aJOyIXufzNRjnodK3728NZU9A2IB6hgPid55OlnM7pYPRWWybaR/IprPK41q+ppoJupfZs8LkrEXUa1WxD505Ba9/Up2KthIuZqz+hEpCsoZV8oYFtQRGL; 25:8HPndPv1etRFscLD2SOy1t/OzeLO2Kq/Edt4n0pf8PinbjVI2qMQijebup7cBPR20WOQ56dxR/zAdsN7uCryS9rdK4+kG1MjyJvFZFYGpZKpfK731Z94pPTEEJ81P6AcJ8rRv2yTMUen0UdWkkjK65RHqhEyrvg4QiAwZ3Rm2DHi3oz/hyBKsnyo3u4/Ew12gPS4zNkpeMObdc2mJRXJtZO16PNFWF+QLauSI9IoGcDlgVQ7hogn/LAx1Dn7+M+JhApf69iaodLknjOo2OuvVKJgcIcTCYr2zmY2I4lGZBXu6SzHyrcJfTB4uWmWnW73tl1WzdYYPVsgI5xiBma80upEI1/AFS0N8MWF/eqHlbr8qPMyGeJ9GMovoQhmM9LkkvB0kD8d8GdQyGxWSWvE4g== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN1PR08MB1472; X-Microsoft-Exchange-Diagnostics: 1; SN1PR08MB1472; 20:CPn1bt9+UXsU45CCpCsfboubk3jYSZFw555hBg2lBHuTo7wNJHGQHkhCds5ugOQe11AqzucP43iR1Jnu4JdXw/ob3WlrWURPFL1Vof0MRy65xbemghfPihHmwhEWM/S7slUBUidqiI+IWlzOZ+6Y625B5oT72+gxu3t8nQGxNqD9EbkPWsRs8iQiJSUSTUyzIaRYSNspaE8Tbtz+UlXP3VfBzqUZc3+vOeHAh0lcYmzH0u/hRR7Mma8LANFBP4j/yLdUJkaFu1CEB15+9qrcY2F6/SKFN0X0kykTodDh741SMocVEQH7Lx3QZfSOXePuqefhnlLd0X8m8jVRL9lwMIrCHUBZ30Ti9mTmDksWr+QrbON5/IG2OfBKlKwr+8TnJgK8CixN+vWJcOdsei18850Wy2qJ8zzgn6fziVNuCDD+GCaNvSXZjvfEjPEglaAFClb0SELVUSK1f7LyTFdRI0ETMIclT/Ih7ydxbDRV3BefLcFyno458CDh0KYWAxth; 4:DmdVYSmfdqgBVY991cNHcdLbS4qTloZaY1G62RjfiPa3kOw2Wjn/m6N9i5/0lruKJG7iN6emZ8Xfh90TEt3Khs03URmh5e1GRQIin4ee5TtxNtcDlxwdTw3rpsdsRCRUh+SPfKrQ6dVdm7dS6i/c3w6ZqbEGHTHMPfggrnQzmTBh5G88bQjYUfZwPXfA6RUs2MYNzEJqv6mcdLYkDCy9AfhksF/5uC1Rd56fxObLoT6SvGmVGf4QROyNK89ccNjUwZ6myPXBrVk1KDyQLMDWoI143EbWeC4+BTUsblvkyruIQNra69ZlTO4ylY0FNv/8QU2fs5x0ARRuifQ6Gpbhp9b4XP8aqsfPY7sktaBFv3m5YQS8f4FHaME6bC8dbHiw X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046); SRVR:SN1PR08MB1472; BCL:0; PCL:0; RULEID:; SRVR:SN1PR08MB1472; X-Forefront-PRVS: 0879599414 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(6049001)(24454002)(43544003)(51444003)(377424004)(164054003)(377454003)(479174004)(586003)(1096002)(66066001)(47776003)(5004730100002)(81166005)(6116002)(3846002)(2906002)(4326007)(86362001)(33656002)(4001350100001)(65806001)(65956001)(19580395003)(19580405001)(80316001)(90282001)(5008740100001)(36756003)(2950100001)(77096005)(88552002)(15975445007)(230700001)(54356999)(87266999)(76176999)(92566002)(75432002)(50986999)(93886004)(117156001)(189998001)(89122001)(42186005)(50466002)(110136002)(23676002); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1PR08MB1472; H:[192.168.0.164]; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtTTjFQUjA4TUIxNDcyOzIzOk5va1EwaEVCNWJIcmlaOW9JbWhEMFVnVnBP?= =?utf-8?B?eEJPYnpZVnRVQ2VRdGdxRyt2blhZcTZ3MWZuNytZa3RJWVBvTTVFdng4NlRS?= =?utf-8?B?dy9lSGY4ME5NV0tOUGFSeGE4S1J4Y0lQYXhPc0x4dTd0ME1VanIvSDFla3F6?= =?utf-8?B?RXFFWEliT2VFb0hxeEgzZ1hNNWkxYWNRMElkYUJKUTRvcVhub1I2eE15NWdD?= =?utf-8?B?TXZXUDZXc3lFNWZmNE5VWG0za2F2YzhOTG1mVUhvOTdNM1E1OHh6SmdDUmdY?= =?utf-8?B?TGN6clUxNlovTWhWWWJnVjlnNkh6andTdWxVTFQ1ZUxwZE9TY3NOdkVWUGF2?= =?utf-8?B?Z3ZUd3craTFrUE9OUER1ZFIxK2NDUmIxRnU3blJ4ZDkzRjcrUkI0Qk5PeDc5?= =?utf-8?B?K3lvc3N5SDVOTkV0NVM3TWFvYSswQWl0Zi9yZGxZNHRWM280TzBuWDZHVU55?= =?utf-8?B?Y0RxeHhoN0d1QitPeWhtZHNOeHR3bEg4RW5lL09MQnZTajlQcUhYT2t3Vy9x?= =?utf-8?B?WHZZZHNESmFKYTM5TVU5bWdnRHRRaGdLRmwrOFI3WmVZVG02OE9Db2gzVHg0?= =?utf-8?B?c2hYQ09tVnhEaVRkTy9UTC9GMDVUaWtjRmlTa0dWYitmSERpWlp4S0xELzdZ?= =?utf-8?B?Rld2aUZMdG5QSGdWd0h5akU4c3phejFCMWJsQkI2NVBVeUR5ZW5QS2tKaVY3?= =?utf-8?B?bHk3WHdxSGQ4ZXRQd0lpdTVKcFkwanRtMUpMTEFmZHlYbHhyams2SFdrS0Mv?= =?utf-8?B?bkdHbkRPTFk5WWY2eSs0ZWE4WFJxWFR1QWYvTFQzK2tGQTY3UUNMd2c4TUVa?= =?utf-8?B?UkY4QmtaVnplTG10ay9rVUxDRU5wcHJqSW9SRVlDdkkxMitBUGNOa3VNZ3RR?= =?utf-8?B?NTVxanpMWU90a1R6S0dIM05rYlVnQWFxTHh3QmNRZ09PZDhmd2FaOGVYRlRC?= =?utf-8?B?STdhV1RoczlJYzVwWTdWbGQ3SFd2VHJ4M3Q5MnlHb1RqbWZOVWdZN2tyTE5R?= =?utf-8?B?VVVXTms1R0JEd1hkOFF6NXFUYWlFWDd4WmZEODhCem96TXZRS0g0bDdhUzdk?= =?utf-8?B?NURvR0pqY2RFRVBvcUVKUzVqdW9vRnZYZkxOSVFqcElIc29mUmJ6azZqM2N0?= =?utf-8?B?VDlFUy9XRlNoY2xEdXFYYkJMR2U5Y2FVZnp0YlBPNGRMK2NJNmd5TkNFRXJU?= =?utf-8?B?MExXckltK2NUTHVCV2tscTBtQWwrTkR6M25LSjJVYTl6TGlvM1cxYytHcmZn?= =?utf-8?B?UmRaMTNDSEozUTF5cHhQWEw1VjZ4T2ZxTXk4dGZBd01oaDc2TFhxUlZUaFN3?= =?utf-8?B?aUdFSWdxUlNBSWM1S2ZEZWUvZFNpdmNmTlJyTmJBWlczeCtOdUNlTlcyL2d3?= =?utf-8?B?WWFYSDM0ZE1KdXA4VjVaK2lhSDJ3ZFNNQm54aTd5aHkyaGh1VXlkK0xBTEg1?= =?utf-8?B?VnEycTkrbHp5eSt2TTBqV1BxSWlRVy9Ed0xpTWl1UzJyRXg0ZWg5ZzRxZ2ZL?= =?utf-8?B?ejI0ZnBFMlJ3UUtGOFVZQW84M2JTSUNiWVlSOWVMSnZsZSs1dGg4R0hlK1Rv?= =?utf-8?B?Ni9GUjNjU2FHOVd0NXRGL290QkRQTW1XOEZGT2hPeUZnUDlFTVY3RXFoeHRG?= =?utf-8?B?Qjd4Mjl2cVBlb09qZ0p2aVI0dGdCRlBlRmhHeXpLRldzd1gyaGdaODVPcFRH?= =?utf-8?B?b1lkSmMwbTR3SG9Ibm0rVUJlRG5UNXNQTkdpWUVQUHY5cmNidUNZNytJRzYr?= =?utf-8?B?TXJ6a1BDY2htelM4RXp5dz09?= X-Microsoft-Exchange-Diagnostics: 1; SN1PR08MB1472; 5:5oEEJK7vF2naOYPE3BVGauJ/l/xC8wtMj/gWASfEAWVzlBytDXOehrYVB/ULY7+4o7vTXZHCEOLh7Mn+ApuUBupEvJla53BdB/pfrV/5zVAV4lBxVf9OC5/0gxBq9HDGfQeWQl1q2BFAnf6LSVrRQA==; 24:dgg6m8QyTutW9rqn5C/dm9nL1UTQZ/h8DXim2gXdrwu07ZThUnrY2CzciPQce6nxvNzMntMAhUOZCyFMPc5IB1L3mimohNHOHwCwl3Zer5w= SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: unl.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 Mar 2016 04:47:41.1248 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR08MB1472 Archived-At: Cc: "tcpm@ietf.org" , "draft-ietf-tcpm-cubic@ietf.org" Subject: Re: [tcpm] Question on CUBIC and its TCP CC RFC basics X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 12 Mar 2016 04:47:46 -0000 Thanks, Neal! Lisong On 3/11/2016 9:18 AM, Neal Cardwell wrote: > Related to the question of being cwnd-limited, and this sentence in > section 3.1: > > t is the elapsed time from the last window reduction > > I think it is important to mention that recent versions of Linux CUBIC > take care to not include idle time in this "t". The fixes are here: > > tcp_cubic: better follow cubic curve after idle period > http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=30927520dbae297182990bb21d08762bcc35ce1d > > tcp_cubic: do not set epoch_start in the future > http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=c2e7204d180f8efc80f27959ca9cf16fa17f67db > > The issue was that after long idle periods "t" was including a lot of > time spent idle, which was implicitly treated by the algorithm as time > spent probing the network without packet loss, leading to very high > cwnd values after restarting from idle. If the code takes care to > exclude idle time, as in the above changes, then this problem does not > show up. > > neal > > > On Fri, Mar 11, 2016 at 9:54 AM, Lisong Xu wrote: >> Thank you all. >> >> I will make the following changes in the next version of cubic draft. >> >> 1. a new subsection 4.10: add the description about the behaviors of cubic >> when it is not cwnd-limited. Specifically, cubic does not do anything, when >> the flow is not limited by the cubic congestion window size. >> >> 2. section 3.1 "when there is no further loss event" --> "if there is no >> further loss event" >> >> 3. section 3.1, "t is the elapsed time from the last window reduction" --> >> "t is the elapsed time from the last window reduction (measured right after >> the fast recovery)" >> >> Is there anything else that I missed? >> >> Thanks >> Lisong >> >> On 3/11/2016 7:43 AM, Eggert, Lars wrote: >> >> On 2016-03-11, at 14:33, Karen Elisabeth Egede Nielsen >> wrote: >> >> >> I think that it would be very useful to add this description of the TCP >> friendliness function in >> https://datatracker.ietf.org/doc/draft-ietf-tcpm-cubic/ >> as it is supposed to reflect the Linux CUBIC implementation. >> >> >> Agreed. The main reason for the ID is to document CUBIC so that people do >> not have to read GPL code to implement it. >> >> Lars >> >> From nobody Tue Mar 15 01:20:02 2016 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 1E3C012D896 for ; Tue, 15 Mar 2016 01:20:01 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=tieto.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 k4UgZGOGyDN0 for ; Tue, 15 Mar 2016 01:19:57 -0700 (PDT) Received: from mail-io0-x22b.google.com (mail-io0-x22b.google.com [IPv6:2607:f8b0:4001:c06::22b]) (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 C1B8512D53B for ; Tue, 15 Mar 2016 01:19:56 -0700 (PDT) Received: by mail-io0-x22b.google.com with SMTP id g203so15161848iof.2 for ; Tue, 15 Mar 2016 01:19:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tieto.com; s=google; h=from:mime-version:thread-index:date:message-id:subject:to:cc; bh=jRGAENbEfIqIyel56iu4UQzlNzcqcQ+T6/LwifVRTtg=; b=UQe8yZuYaMGb2Y8TPSItNUSm8czknOHvKWo6ik/UdB+ppiVkOnuB5KQve6RTVkvcoN 3JHhydltwQIv1A9KZAZhLbqTB6iFCGncKy+mCx1iNdhktI3zXc2zFozWpyCNshNUFWbr 0bniAW2EUx+R8qoslMgFHug2xSiyMdNsOUJCw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:mime-version:thread-index:date:message-id :subject:to:cc; bh=jRGAENbEfIqIyel56iu4UQzlNzcqcQ+T6/LwifVRTtg=; b=ISkGWpUoc0hj9zGUl9r3D6Mf+/1kzOA+1GPLTUC+I7/evhBFqu4gHWl8WInw+98IbJ KRin7UL2GjSAcDqrJVfvMCRpLrrzSJnEbuIu7kEBYFnf2ic5LxWbr8hweSBym1nB7jDK zWxWGeJU8FADn08MaiDjb+nJHWfzq2Wc1HXSkbnQx3PXkpKhsql/6Dto2HWhkTKPYq6h OeoGib/vG9Y5dT6FCDTan33Y0mvJVBtr8qZYjcChGOCVXcut0xbuAmM6uSfJF5A4PbsP oT9RCLcWGJfODJ+kaiXvL8gf9RUaNjh/A8NYJwHFhfE22FXPgRyL2ImrtT4OpHCFZ2za Bocw== X-Gm-Message-State: AD7BkJKjZ+PY9CnhwarKWf0XTizvPh5B+VdNx3hcGfDLu7GPznznt4b3AGubS3MshJBWAwmpiXrDY/S9/lyWxk0z+/0h67JXSZ/8O4sqg4BoxlxNcAYHl2s/QzDbmZNUYLXsT18= X-Received: by 10.107.12.207 with SMTP id 76mr29525197iom.70.1458029996143; Tue, 15 Mar 2016 01:19:56 -0700 (PDT) From: Karen Elisabeth Egede Nielsen MIME-Version: 1.0 X-Mailer: Microsoft Outlook 15.0 Thread-Index: AdF+j4T4gNXP7HLCRGOj5AgAyoUrOg== Date: Tue, 15 Mar 2016 09:19:54 +0100 Message-ID: To: draft-ietf-tcpm-cubic@ietf.org, Lisong Xu Content-Type: multipart/alternative; boundary=001a113eca06fe3a43052e120f4a X-DomainID: tieto.com Archived-At: Cc: tcpm@ietf.org Subject: [tcpm] TCP friendly formulation in CUBIC-draft ? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 15 Mar 2016 08:20:01 -0000 --001a113eca06fe3a43052e120f4a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Lisong, Neal, All, I understand the basic principle of the TCP friendliness function and I have no problem with having the window follow TCP New Reno when the CUBIC algorithm would return a smaller value. I.e., following section 1 of the draft: When the cubic function grows slower than the window of Standard TCP, CUBIC simply follows the window size of Standard TCP to ensure fairness to Standard TCP in a small BDP network. With the disclaimer that I have not studied reference [FHP00] I have, however, a problem understanding how this is achieved with formula (Eq. 4) of section 3.2 of draft-ietf-tcpm-cubic-01. >From whatever in [FDP00] one get that the average window of AIMD TCP CC is AVG_W_aimd =3D [ alpha_aimd * (1+beta_aimd) / (2*(1-beta_aimd)*p) ]^0.5 (eq. 3) which with alpha =3D 1 and beta =3D 0,5 indeed yields AVG_W_Newreno =3D (1.5/p)^0.5. (Good otherwise we were in trouble). One can further observe from (3), of course, that generally for AIMD CC with alpha equal to 3*(1-beta)/(1+beta) then one get the same average window as of NewReno TCP. But how does it follow that W_aimd(t) =3D W_max*beta_aimd + [3*(1-beta_aimd)/(1+beta_aimd)] * (t/RTT) (Eq. 4) is a reasonable estimate for the window of standard TCP CC as quoted as being the intention in section 1 ? QUESTION: Is (Eq. 4) the best implementation choice for comparison with TCP New Reno that were manageable from an implementation perspective or is (Eq 4) the rule that a CUBIC implementation should aim to follow ? I.e., that the Linux TCP implementation aims to follow ? In the latter case, then I think one should probably use the following formulation in Section 1: When the cubic function grows slower than the window of standard AIMD CC, CUBIC simply follows the window size of standard AIMD CC to ensure fairness to Standard TCP in a small BDP network. And then probably relate to that the fairness comes (?) from calibration towards same average window - - - Thanks ! BR, Karen ***************************************************************************= **************** *Karen Egede Nielsen* Software Architect, Ph.D. *Tieto Denmark A/S* R&D, Telecom & Media =C3=85have Parkvej, 8260 Viby J, DK-Denmark Direct Phone / Mobile +45 25134336 E-mail: karen.nielsen@tieto.com ***************************************************************************= ************** www.tieto.com *Please note: The information contained in this message may be legally privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, you are hereby notified that any unauthorised use, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank You.* --001a113eca06fe3a43052e120f4a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hi Liso= ng, Neal, All,

=C2=A0=

I understand the bas= ic principle of the TCP friendliness function and I have no problem =

with having the window foll= ow TCP New Reno when the CUBIC algorithm would return a smaller value.

I.e., following section 1= of the draft:

=C2=A0=

When the cubic

=C2=A0=C2=A0 function grows slo= wer than the window of Standard TCP, CUBIC simply

=C2=A0=C2= =A0 follows the window size of Standard TCP to ensure fairness to

=C2=A0=C2=A0 Standard TCP in a small BDP network.

=C2=A0

=C2=A0

With the disclaimer that I have not studied reference [FHP00] I hav= e, however, a problem understanding how this is achieved

with formula (Eq. 4) of section 3.2 of = draft-ietf-tcpm-cubic-01.

=C2=A0

From what= ever in [FDP00] one get that the average window of AIMD TCP CC is

=C2=A0

=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 AVG_W_aimd =3D [ alpha_aimd * (1+beta_aimd) /

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0(2*(1-be= ta_aimd)*p) ]^0.5=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (eq= . 3)

=C2=A0

=C2=A0

which with alpha =3D 1 and beta =
=3D 0,5 indeed yields AVG_W_Newreno =3D (1.5/p)^0.5.=
 (Good otherwise we were in trouble).
One can further observe from (3), of course, =C2=A0that generally fo=
r AIMD CC with =C2=A0alpha equal to

=C2=A0=C2=A0 3*(1-beta)= /(1+beta) then one get the same average window as of NewReno TCP.=C2=A0 But= how does it follow that

=C2=A0

W_aimd(t) =3D W_max*beta_aimd +

=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 [3*(1-beta_aimd)/(1+beta_aimd)] * (t/RTT) (E= q. 4)

<= span lang=3D"EN-US">=C2=A0

is a reasonable estimate for the window of standard TCP CC as quoted = as being the intention in section 1 ?

=C2=A0

QUESTION:

Is (Eq. = 4) the best implementation choice for comparison with TCP New Reno that wer= e manageable from an implementation perspective or is (Eq 4) the rule that = a CUBIC implementation

should aim to follow ? I.e., that the Linux TCP implementation aims to fo= llow ?

=C2=A0<= /p>

In the latter case, then I t= hink one should probably use the following formulation in Section 1:=

=C2=A0

When= the cubic

=C2=A0=C2=A0 function grows slower than the window= of standard AIMD CC, CUBIC simply

=C2=A0=C2=A0 follows the= window size of standard AIMD CC to ensure fairness to

=C2= =A0=C2=A0 Standard TCP in a small BDP network.

=C2=A0=

And then probably relate to that the fairness comes (?) from calibr= ation towards same average window - - -

<= span lang=3D"EN-US">=C2=A0

Thanks !

=C2= =A0

BR, Karen<= /p>

=C2=A0

************************************************************= *****************************

Karen = Egede Nielsen

Software Architect, Ph.D.

=C2=A0

Tieto Denmark A/S

R&am= p;D, Telecom & Media

=C3=85have Parkvej, 8260 Viby J, = DK-Denmark

Direct Phone / Mobile +45 251343= 36

E-mail: karen.nielsen@tieto.com

******= ***************************************************************************= ********

w= ww.tieto.com=C2=A0

=C2=A0

Please note: The information contained in this message may be legally= privileged and confidential and protected from disclosure. If the reader o= f this message is not the intended recipient, you are hereby notified that = any unauthorised use, distribution or copying of this communication is stri= ctly prohibited. If you have received this communication in error, please n= otify us immediately by replying to the message and deleting it from your c= omputer. Thank You.

=C2=A0

--001a113eca06fe3a43052e120f4a-- From nobody Tue Mar 15 20:30:27 2016 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 A0BB212D879; Tue, 15 Mar 2016 20:30:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=uofnelincoln.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 D-amac-IS6xX; Tue, 15 Mar 2016 20:30:24 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0189.outbound.protection.outlook.com [207.46.163.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D276212D88F; Tue, 15 Mar 2016 20:30:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uofnelincoln.onmicrosoft.com; s=selector1-unl-edu; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=phWeHI2Iz31n1nlxsV8965nih4nBGEfNno0Ga4vhl6A=; b=iWba5gzdNeHhK/bRRcNrMLfz5bBiGO7Ak2r1Eb1qNK9/jQ5UtovVLMzzsl05fYjLF3tIKa651S42DtPaEUwknxSBdqII2PUDq6xyqigY4ne6wyi6ywvz4SPNBvPmXyJKSmF5RDPi1JDb17WDq8Vp0KdHe6JLtnjVDZSajndo9mw= Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=unl.edu; Received: from [192.168.0.164] (97.98.140.59) by SN1PR08MB1469.namprd08.prod.outlook.com (10.162.2.12) with Microsoft SMTP Server (TLS) id 15.1.434.16; Wed, 16 Mar 2016 03:30:20 +0000 To: Karen Elisabeth Egede Nielsen , References: <28265_1458030005_u2F8K4us025832_bb0b000b861f2a1e54225a8662b87a69@mail.gmail.com> From: Lisong Xu Organization: University of Nebraska-Lincoln Message-ID: <56E8D363.2080801@unl.edu> Date: Tue, 15 Mar 2016 22:30:43 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <28265_1458030005_u2F8K4us025832_bb0b000b861f2a1e54225a8662b87a69@mail.gmail.com> Content-Type: multipart/alternative; boundary="------------010906060804030300000805" X-Originating-IP: [97.98.140.59] X-ClientProxiedBy: BLUPR01CA025.prod.exchangelabs.com (25.160.23.15) To SN1PR08MB1469.namprd08.prod.outlook.com (25.162.2.12) X-MS-Office365-Filtering-Correlation-Id: 02c1bca2-d449-496c-595e-08d34d4b4dc2 X-Microsoft-Exchange-Diagnostics: 1; SN1PR08MB1469; 2:yu0rARwKeuJgJkbmHMHb39B/4YhOWGBarrb+3SqgHTgSrdzt+xARFPZenMlGaZEI/T5ALHb4qk/CQdC7KpMxNRFSh4Teu0nu47LfWI5RCSkOpimWlO5QA5Gp6fiWOjJkBJ+LLbaJwgjwbFi1V2EFXStpdzk7GlyaTGnAYrHKttyGLc7ovE4VciNflUSbRD9/; 3:1Nf0qkQ4Ha3OzfBRvxRit+YmZH0iyBCH+vLvQjW6jx3fAFwZklzQ0BJe+XRWBxGTOzPga+qJjqPCcspawtt03ybWqAC0OPEwNnF88Z2PiKe6Jb+fyWABPdougy/9RKKf; 25:P4/pmjosx8foE0C8Pfy8cJDhCDEaDR+DzMjlxr1LxViD7LaySpSOcu/ImvNUfSN4OueOEZwXRxox988ez7RpxVa1cfKa//tlhBbH/XKre9irpev6rns8s2oLmvmALozhUcjbPDjKS4D2iF/4Vioi/pLqjuLoVu4e1A0chvUuslJHl9F2kukkJSYJ0uqV5b5MSHBRKAPnInT0lfpiKL200fcsMGuQP7jyggWhqX2hsMnW9bYDoZuLGaE+/KTBhT5Ur1wSU3qedQSQF5yWpHsRKFr3/813UcxTJvs6CfULQePAV1TewtFXPug2yIwcLgyEb5JaK/og+vtRr6Ohs/W02OgVDiRWn8MjMTc9Ol7M2BihXx0ezcxLNJjrGzyPj79f X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN1PR08MB1469; X-Microsoft-Exchange-Diagnostics: 1; SN1PR08MB1469; 20:UMDCMPhW67mUCWMIM0/Xb46S7nxyOUcSq19osxiicw0+kRfZOOv7vVzS5/IaNZp/THFPOSz3zLUlbyk1aPeE0Wn9DFmzA/yBVeqI/+2xTtvT2WOg60H/TozTlLePZuSku2aMISwSM5v9M+R3XuvS64txlENJG3m9d/gssEPhZFxArDj826Lv28QeIz632iJOW2sZV/lW3k/myvcyirJOaqMuAaGHE04NRHb+3Ie30aBSfWz5yip3x4rjk6sW/rIILSRSQOaXz0AJIjnS5pJSKM6VZTyfPg2o/r6LDuxHLNt4ISGYWnqwo6NczQFdQ/X6XHnP3vLoRPnVX2DtAuFBRWJIOe5Y6kGzkZ9N4qlP8ivQugt8U2klH99SxJD0AQcT3IGBjpqqE/FyiX6YA/Y79aH7NFyDsXVHzoGk91xFgJNz2ShI2mRUSs/PtvTcZcA2iqGVd4l88AeUgr5WVM2msmDI7V0R8/zezOJXmMMwJaAXwIigFii6/lQP99K0X+d8; 4:el0GpOre6tuw2xoDoVrU8tF11tigKYZwgV7i4kLfnV8P967wk9Yj07esX3bTV56iS1jcnRkP6CBfykPfATDciSFLXL8P/GEw3FxBfo2GOt6EoN/QNLuHtoKk6eJJJ2NYHUXFP9j0Stj9vjD37NBGhc6QnA+7GKX+VHkAE3gra8gewSlYrigQz6z3Us+a/uHs45NVfc62c3OYfuPTVK5i5vsgNNUq400SvWxvHcrirHyuN7+XarfD5yXm1tTRiFtdUpgPBJri0UFaOufG3ZbOdBdF0KfnxpEwozr7rA4NLyW+uOChILKc7CWZ0EFGW36D7Tx6QiNHFTeSzlMWsb5gbCZqQdKFqyvPkRJoBsNkfJTGp1ImsMzVNngCWwJ237c4 X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001); SRVR:SN1PR08MB1469; BCL:0; PCL:0; RULEID:; SRVR:SN1PR08MB1469; X-Forefront-PRVS: 08831F51DC X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6049001)(252514010)(479174004)(377454003)(24454002)(19617315012)(87266999)(54356999)(76176999)(65816999)(50986999)(75432002)(83506001)(86362001)(84326002)(1096002)(89122001)(92566002)(2906002)(42186005)(4326007)(88552002)(5001770100001)(19580405001)(19580395003)(512874002)(16236675004)(189998001)(15975445007)(77096005)(16601075003)(33656002)(36756003)(6116002)(5004730100002)(19625215002)(5008740100001)(59896002)(117156001)(586003)(3846002)(64126003)(90282001)(65956001)(65806001)(81166005)(66066001)(2950100001)(15974865002); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1PR08MB1469; H:[192.168.0.164]; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; SN1PR08MB1469; 23:3+v3v3wjJvYX9SR4UWsi0MgnjDQGyEAK9q12t0il5?= =?us-ascii?Q?0OFhd8lF9Ncpg1W1pnzqTUX6hsgB+SNMmGkcxvr5dFwaVlbXgfU77/8KtTE7?= =?us-ascii?Q?FuiMTqWLVTnep1xx1nNR1M6em+l+5TFJcrrd1b/RCyhszATbdl9KWqLaLpGc?= =?us-ascii?Q?Fr9XTL/4KHfPmyef9y+ePn2WaQZb12TIoAAirUH7X7q5s+Nblm72yi3Aro2g?= =?us-ascii?Q?L4D6SM9Sy2Py4kNLM3hxaI/ks7AlDyByhU84PMvFDQ+VDb3ZVOKgHhOQIOnP?= =?us-ascii?Q?s4Ns/WsnplriyZcRRvid7czpQST2WVaSE1YHYz8NEWj/CBzow/tBjWDYUH+B?= =?us-ascii?Q?HzoIjidubqrXJ6qt4V06xXeGIE8zFCjbOnnEcWDOXqDEjCXNcIDGKK8D7HV+?= =?us-ascii?Q?uBJZrUXvYJ1twhNfq/eM5QKxAVjvIPa1WTt8fv43HXZmv+CkrCiQ4URArnqM?= =?us-ascii?Q?tYjMCZI6zmx5vCWQERHE9TI3pr9uEf9h5w3fBgXoDQ1cCCd+zMpZ5Z0HlHQr?= =?us-ascii?Q?qXHl0IL7aUUHAKVPQfVTPdbGvO9ubzz6QPmf7uP5MDGaHUVwMO+Ua4plBlvd?= =?us-ascii?Q?rIBBQQuLAHwb+gY7EXsUEZu6Ix79RrSJ+Asaxl8Il4xIe1vGmrZiJjnQvSbz?= =?us-ascii?Q?JK5stw16nV9UFfUiOqPkZNRjOpxdGAQuLAmoQWw3J65qoUnhfEKN0K2ftD7x?= =?us-ascii?Q?+nKzdu56LDYldiDlrhGZzXt5iBehN11E0fl+PJnBVZD8SkgdDPbzNrw41/1B?= =?us-ascii?Q?oU26EDUsRzF4qA/H/v6rAZwYu2osopy4cTkZwqZzIyk1TrRTuVp1f74v6Pk1?= =?us-ascii?Q?RlKCNXB5n1JFIVc6cFar+GDlqxSGkmUH5+L9xiVGsswq9jGQlRUnetQBIqvD?= =?us-ascii?Q?rRng5CethdHzwn1tzzx+Sb/1lirw7HQRqjaurWQ1pdqBJOCyjMnjg0TwEhft?= =?us-ascii?Q?7883H+nGXKI2osTET1lH4Vlkf6tf2fWqUPdG7mViCt7/Z7uCNLx5THvOIPJ1?= =?us-ascii?Q?inBhEus6NrPrSmKovFhktF+ki96ljsiCChZAJyQJ7ywN0KeDaC94u+P4AbAU?= =?us-ascii?Q?VYUO/LNHhJY+st9thPP5N9vNyAh5FlHSvmGFprWeQ010Ge1z2K0AODQDjOHh?= =?us-ascii?Q?9DjNMfMPHhcC2PJTwXN8f/ec7G0jj3loZKvqlyw91JD7ZJ6/Dj1X1WjqKWYg?= =?us-ascii?Q?zd4j4K+xlHbwU+O80PKoBIkInfrsfG7zG8RY8URfgB/m3cB6ZaEv5ZyOwcY6?= =?us-ascii?Q?0gj1tnKB5YbGtBM2M27rKTPqbqbfwvbHjPLt9Uf9Ecb4QoH1SyWsOUs9+/Xd?= =?us-ascii?Q?EMkqHsQiyHaiZ9WyH8PktE=3D?= X-Microsoft-Exchange-Diagnostics: 1; SN1PR08MB1469; 5:1rP9+6k55FOEWYYBy8YN5whb2+qpa93obIvNMIReJQXuyBHiDnMdz0nI8tB1hZ8sfJKAssht9vTkXp3/z1XJYC82Bh6qrl+UQ/VviD4H/+homhTxLFuubQngwv+5r77a8Ld7XhiJSjwXXbhZ1iiyng==; 24:VPrBdx/t0ALZhzfY0DiPLVFKt/Og2vuhQPImsd5fjR11vms6v/4xD1/CSfx5JAYP/kQJQQARN7PQLiENBe7MR0k0cDTtKMddCMLHA9ZcG/4= SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: unl.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Mar 2016 03:30:20.5590 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR08MB1469 Archived-At: Cc: tcpm@ietf.org Subject: Re: [tcpm] TCP friendly formulation in CUBIC-draft ? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 16 Mar 2016 03:30:26 -0000 --------------010906060804030300000805 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit On 3/15/2016 3:19 AM, Karen Elisabeth Egede Nielsen wrote: > > Hi Lisong, Neal, All, > > I understand the basic principle of the TCP friendliness function and > I have no problem > > with having the window follow TCP New Reno when the CUBIC algorithm > would return a smaller value. > > I.e., following section 1 of the draft: > > When the cubic > > function grows slower than the window of Standard TCP, CUBIC simply > > follows the window size of Standard TCP to ensure fairness to > > Standard TCP in a small BDP network. > > With the disclaimer that I have not studied reference [FHP00] I have, > however, a problem understanding how this is achieved > > with formula (Eq. 4) of section 3.2 of draft-ietf-tcpm-cubic-01. > > From whatever in [FDP00] one get that the average window of AIMD TCP CC is > > AVG_W_aimd = [ alpha_aimd * (1+beta_aimd) / > > (2*(1-beta_aimd)*p) ]^0.5 (eq. 3) > > which with alpha = 1 and beta = 0,5 indeed yields AVG_W_Newreno = > (1.5/p)^0.5.(Good otherwise we were in trouble). > One can further observe from (3), of course, that generally for AIMD > CC with alpha equal to > > 3*(1-beta)/(1+beta) then one get the same average window as of > NewReno TCP. But how does it follow that > > W_aimd(t) = W_max*beta_aimd + > > [3*(1-beta_aimd)/(1+beta_aimd)] * (t/RTT) (Eq. 4) > > is a reasonable estimate for the window of standard TCP CC as quoted > as being the intention in section 1 ? > We can prove that Eq (4) has the same average window size as a reno flow. > QUESTION: > > Is (Eq. 4) the best implementation choice for comparison with TCP New > Reno that were manageable from an implementation perspective or is (Eq > 4) the rule that a CUBIC implementation > > should aim to follow ? I.e., that the Linux TCP implementation aims to > follow ? > > In the latter case, then I think one should probably use the following > formulation in Section 1: > > When the cubic > > function grows slower than the window of standard AIMD CC, CUBIC simply > > follows the window size of standard AIMD CC to ensure fairness to > > Standard TCP in a small BDP network. > > And then probably relate to that the fairness comes (?) from > calibration towards same average window - - - > There are two methods to get the average window size of a reno flow. 1. simulate a reno flow for each ack and each packet. but this method requires more variables and more code to simulate reno. 2. use Eq (4) to directly calculate the average window size of a reno flow. this method is much simpler than the first method, because it does not need to simulate a reno flow. this is what Cubic does. Lisong > Thanks ! > > BR, Karen > > ******************************************************************************************* > > *Karen Egede Nielsen* > > Software Architect, Ph.D. > > *Tieto Denmark A/S* > > R&D, Telecom & Media > > Ă…have Parkvej, 8260 Viby J, DK-Denmark > > Direct Phone / Mobile +45 25134336 > > E-mail: karen.nielsen@tieto.com > > ***************************************************************************************** > > www.tieto.com > > // > > /Please note: The information contained in this message may be legally > privileged and confidential and protected from disclosure. If the > reader of this message is not the intended recipient, you are hereby > notified that any unauthorised use, distribution or copying of this > communication is strictly prohibited. If you have received this > communication in error, please notify us immediately by replying to > the message and deleting it from your computer. Thank You./ > --------------010906060804030300000805 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 8bit

On 3/15/2016 3:19 AM, Karen Elisabeth Egede Nielsen wrote:

Hi Lisong, Neal, All,

 

I understand the basic principle of the TCP friendliness function and I have no problem

with having the window follow TCP New Reno when the CUBIC algorithm would return a smaller value.

I.e., following section 1 of the draft:

 

When the cubic

   function grows slower than the window of Standard TCP, CUBIC simply

   follows the window size of Standard TCP to ensure fairness to

   Standard TCP in a small BDP network.

 

 

With the disclaimer that I have not studied reference [FHP00] I have, however, a problem understanding how this is achieved

with formula (Eq. 4) of section 3.2 of draft-ietf-tcpm-cubic-01.

 

From whatever in [FDP00] one get that the average window of AIMD TCP CC is

 

       AVG_W_aimd = [ alpha_aimd * (1+beta_aimd) /

                      (2*(1-beta_aimd)*p) ]^0.5          (eq. 3)

 

 

which with alpha = 1 and beta = 0,5 indeed yields AVG_W_Newreno = (1.5/p)^0.5. (Good otherwise we were in trouble).
One can further observe from (3), of course,  that generally for AIMD CC with  alpha equal to

   3*(1-beta)/(1+beta) then one get the same average window as of NewReno TCP.  But how does it follow that

 

W_aimd(t) = W_max*beta_aimd +

                   [3*(1-beta_aimd)/(1+beta_aimd)] * (t/RTT) (Eq. 4)

 

is a reasonable estimate for the window of standard TCP CC as quoted as being the intention in section 1 ?


We can prove that Eq (4) has the same average window size as a reno flow.


 

QUESTION:

Is (Eq. 4) the best implementation choice for comparison with TCP New Reno that were manageable from an implementation perspective or is (Eq 4) the rule that a CUBIC implementation

should aim to follow ? I.e., that the Linux TCP implementation aims to follow ?

 

In the latter case, then I think one should probably use the following formulation in Section 1:

 

When the cubic

   function grows slower than the window of standard AIMD CC, CUBIC simply

   follows the window size of standard AIMD CC to ensure fairness to

   Standard TCP in a small BDP network.

 

And then probably relate to that the fairness comes (?) from calibration towards same average window - - -

 


There are two methods to get the average window size of a reno flow.

1. simulate a reno flow for each ack and each packet. but this method requires more variables and more code to simulate reno.

2. use Eq (4) to directly calculate the average window size of a reno flow. this method is much simpler than the first method, because it does not need to simulate a reno flow. this is what Cubic does.

Lisong

Thanks !

 

BR, Karen

 

*****************************************************************************************

Karen Egede Nielsen

Software Architect, Ph.D.

 

Tieto Denmark A/S

R&D, Telecom & Media

Ă…have Parkvej, 8260 Viby J, DK-Denmark

Direct Phone / Mobile +45 25134336

E-mail: karen.nielsen@tieto.com

*****************************************************************************************

www.tieto.com 

 

Please note: The information contained in this message may be legally privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, you are hereby notified that any unauthorised use, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank You.

 


--------------010906060804030300000805-- From nobody Wed Mar 16 01:10:49 2016 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 7B8C412D722 for ; Wed, 16 Mar 2016 01:10:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.69 X-Spam-Level: X-Spam-Status: No, score=-2.69 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, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=tieto.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 FkdqxIU8DXMb for ; Wed, 16 Mar 2016 01:10:44 -0700 (PDT) Received: from mail-ig0-x230.google.com (mail-ig0-x230.google.com [IPv6:2607:f8b0:4001:c05::230]) (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 D3BAF12D634 for ; Wed, 16 Mar 2016 01:10:42 -0700 (PDT) Received: by mail-ig0-x230.google.com with SMTP id mh10so36143102igb.0 for ; Wed, 16 Mar 2016 01:10:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tieto.com; s=google; h=from:references:in-reply-to:mime-version:thread-index:date :message-id:subject:to:cc; bh=BfDiZEUA6B7tx+/YrA0Yt/qsENVPemyUryiKZ8sHAxg=; b=JZTcCsVkyH33kuut4OraRCiqO5YWCmemFtpBGO+BEQk4RIaVap8zRlXeZTm66KJyCs zb47hhSisIo80ojBTM2/FjJd8McJJL6LLs2BddP//vs50b2/tBpTcdbV7r/epZPIulbC 9G7ABqiqHrjvrW8apj/LgK21HbWY/Aj4qcrYg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:references:in-reply-to:mime-version :thread-index:date:message-id:subject:to:cc; bh=BfDiZEUA6B7tx+/YrA0Yt/qsENVPemyUryiKZ8sHAxg=; b=FbFduFhCuVbJFn8CirCMkBIwv4mC+Y/QiyCOfDVpL2MULf71O1twg8PWhagz6vmJBH gH6Qxxfw3PfP7PyuSqU6+YAiJ8j/k8nkGsATSiQ10/WSBuGTVHYVT8x4fr399K0ebO6n adKVDouaz9uVOab4GnJECjh9dI/upyi/JNWKjAI0TI3WVZJwQLUUkKbAxcpFrScQQXA1 nuGpjFPz67E5+ThadoOVuCovgL9bIVBrryFDNOpCwRBcI62VPFr4p3yQkZNTuAlGO7R8 NagFFeQwuhgzx8NwPCkD7tpyDlBGzWphy+ZYVMtT2h4/2/34/JVSQ85onpJPtpZlpCuP eTFw== X-Gm-Message-State: AD7BkJJ7V2dzDJjkBawbuOLnqS4zcd48hLdKTL9HIYRJybEAyueD/n+3FeupOjoyo5L+Pinr3nG07LozLNTviUyKb1q9fbFK++GM772X1GGVxaK0I8yRKvWvEqdmBpPz/gadMy4= X-Received: by 10.50.43.194 with SMTP id y2mr3439615igl.96.1458115840772; Wed, 16 Mar 2016 01:10:40 -0700 (PDT) From: Karen Elisabeth Egede Nielsen References: <28265_1458030005_u2F8K4us025832_bb0b000b861f2a1e54225a8662b87a69@mail.gmail.com> <56E8D363.2080801@unl.edu> In-Reply-To: <56E8D363.2080801@unl.edu> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQIbw19NaMpQgnr/3M9AdWgbjB7BugM9Fpq6nq0+7AA= Date: Wed, 16 Mar 2016 09:10:39 +0100 Message-ID: <22021b5df9cac80a9d8c0ba9ea526ef4@mail.gmail.com> To: Lisong Xu , draft-ietf-tcpm-cubic@ietf.org Content-Type: multipart/alternative; boundary=047d7bfea0b6bb4a36052e260c7a X-DomainID: tieto.com Archived-At: Cc: tcpm@ietf.org Subject: Re: [tcpm] TCP friendly formulation in CUBIC-draft ? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 16 Mar 2016 08:10:47 -0000 --047d7bfea0b6bb4a36052e260c7a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable HI Lisong, Thanks. Please see below. BR, Karen *From:* Lisong Xu [mailto:xu@unl.edu] *Sent:* 16. marts 2016 04:31 *To:* Karen Elisabeth Egede Nielsen ; draft-ietf-tcpm-cubic@ietf.org *Cc:* tcpm@ietf.org *Subject:* Re: TCP friendly formulation in CUBIC-draft ? On 3/15/2016 3:19 AM, Karen Elisabeth Egede Nielsen wrote: Hi Lisong, Neal, All, I understand the basic principle of the TCP friendliness function and I have no problem with having the window follow TCP New Reno when the CUBIC algorithm would return a smaller value. I.e., following section 1 of the draft: When the cubic function grows slower than the window of Standard TCP, CUBIC simply follows the window size of Standard TCP to ensure fairness to Standard TCP in a small BDP network. With the disclaimer that I have not studied reference [FHP00] I have, however, a problem understanding how this is achieved with formula (Eq. 4) of section 3.2 of draft-ietf-tcpm-cubic-01. >From whatever in [FDP00] one get that the average window of AIMD TCP CC is AVG_W_aimd =3D [ alpha_aimd * (1+beta_aimd) / (2*(1-beta_aimd)*p) ]^0.5 (eq. 3) which with alpha =3D 1 and beta =3D 0,5 indeed yields AVG_W_Newreno =3D (1.5/p)^0.5. (Good otherwise we were in trouble). One can further observe from (3), of course, that generally for AIMD CC with alpha equal to 3*(1-beta)/(1+beta) then one get the same average window as of NewReno TCP. But how does it follow that W_aimd(t) =3D W_max*beta_aimd + [3*(1-beta_aimd)/(1+beta_aimd)] * (t/RTT) (Eq. 4) is a reasonable estimate for the window of standard TCP CC as quoted as being the intention in section 1 ? We can prove that Eq (4) has the same average window size as a reno flow. *[Karen Elisabeth Egede Nielsen] Sure =E2=80=93 I don=E2=80=99t doubt that.= * QUESTION: Is (Eq. 4) the best implementation choice for comparison with TCP New Reno that were manageable from an implementation perspective or is (Eq 4) the rule that a CUBIC implementation should aim to follow ? I.e., that the Linux TCP implementation aims to follow ? In the latter case, then I think one should probably use the following formulation in Section 1: When the cubic function grows slower than the window of standard AIMD CC, CUBIC simply follows the window size of standard AIMD CC to ensure fairness to Standard TCP in a small BDP network. And then probably relate to that the fairness comes (?) from calibration towards same average window - - - There are two methods to get the average window size of a reno flow. 1. simulate a reno flow for each ack and each packet. but this method requires more variables and more code to simulate reno. 2. use Eq (4) to directly calculate the average window size of a reno flow. this method is much simpler than the first method, because it does not need to simulate a reno flow. this is what Cubic does. *[Karen Elisabeth Egede Nielsen] You don=E2=80=99t use (Eq 4) to calculate = the average window. You use eq 4 =E2=80=93 you say - because this algorithm giv= es the same average window as New Reno and therefore you say it is a valid approach.* *From an implementation perspective I am not sure there is so much difference, there is one namely the ramp down at FR, but otherwise they need to do the same, just with a different alpha (the beta_scale in Linux. Both needs to take care of underutilization. * *[Karen Elisabeth Egede Nielsen] Yes =E2=80=93 my question was whether you = wanted 1, but were doing 2 because of ease of implementation, or whether you from a model perspective wanted to do 2.* *What I hear you saying is that you want 1, but is doing 2.* *1 and 2 are really two different things =E2=80=93 at least from a theoreti= cal perspective. Especially as you only use the calculation on a fraction of the domain only. * *I think it should be obvious that 2 can give a higher CWND just after FR, but also that the difference goes away over time (at which point CUBIC then likely uses the CUBIC graph **J**).* *On the other hand Eg 4 may be more modest generally =E2=80=93 e.g. when in= creasing from a non-validated window. Just thinking out load.* *Have you experimented with to which extend 2 _significantly_ differs from 1 =E2=80=93 especially in conjunction with CUBIC ?* *I am not saying even that 2 is not the ideal approach =E2=80=93 but it nee= d some more persuading to tell that it models New Reno well in the way it is being used.* *[Karen Elisabeth Egede Nielsen] It had actually been simpler (I think) if the argument was that you wanted 2 and then argue for why this is reasonable fair with New Reno.* *As said before, we are defining this for SCTP =E2=80=93 let=E2=80=99s see = - we may experiment with both 1 and 2. * *I have not understood (not tried to understand) what kind of validation TCP Linux is running with when the cwnd is underutilized (not cwnd limited). In SCTP there is no cwnd increase during* *cwnd underutilization, but not any cwnd decaying either. This may give a difference in the overall resulting behavior of course.* Many Thanks. Lisong Thanks ! BR, Karen ***************************************************************************= **************** *Karen Egede **N**ielsen* Software Architect, Ph.D. *Tieto Denmark A/S* R&D, Telecom & Media =C3=85have Parkvej, 8260 Viby J, DK-Denmark Direct Phone / Mobile +45 25134336 E-mail: karen.nielsen@tieto.com ***************************************************************************= ************** www.tieto.com *Please note: The information contained in this message may be legally privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, you are hereby notified that any unauthorised use, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank You.* --047d7bfea0b6bb4a36052e260c7a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

HI Lisong,

=C2=A0

Thanks.

=C2=A0

Please see below.

=C2=A0

BR, Karen

=C2=A0

From: Lisong Xu [mailto:xu@unl.edu]
Sent: 16. marts 2016 04:31
To: Kar= en Elisabeth Egede Nielsen <k= aren.nielsen@tieto.com>; draft-ietf-tcpm-cubic@ietf.org
Cc: tcpm@ietf.org
Subject: Re: TCP friendly formula= tion in CUBIC-draft ?

=C2=A0

=C2=A0

On 3/15/2016 3:1= 9 AM, Karen Elisabeth Egede Nielsen wrote:

Hi Lisong, Neal, All,

=C2=A0

I unders= tand the basic principle of the TCP friendliness function and I have no pro= blem

with having the= window follow TCP New Reno when the CUBIC algorithm would return a smaller= value.

I.e., followi= ng section 1 of the draft:

=C2=A0

When the cubic

=C2= =A0=C2=A0 function grows slower than the window of Standard TCP, CUBIC simp= ly

=C2=A0=C2=A0 follows the window size of Standard TC= P to ensure fairness to

=C2=A0=C2=A0 Standard TCP in a= small BDP network.

= =C2=A0

=C2=A0<= /p>

With the disclaimer that I h= ave not studied reference [FHP00] I have, however, a problem understanding = how this is achieved

= with formula (Eq. 4) of section 3.2 of draft-ietf-tcpm-cubic-01.

=

=C2=A0

From whatever in [FDP00] one get that the ave= rage window of AIMD TCP CC is

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= AVG_W_aimd =3D [ alpha_aimd * (1+beta_aimd) /

=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0(2*(1-beta_aimd)*p) ]^0.5= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (eq. 3)

=C2=A0

=C2=A0

which with alpha =3D 1 and beta =3D=
 0,5 indeed yields AVG_W_Newreno =3D (1.5/p)^0.5. (Good otherwise we were in trouble).
= 
One can further obs=
erve from (3), of course, =C2=A0that generally for AIMD CC with =C2=A0alpha=
 equal to

=C2=A0=C2=A0 3*(1-beta)/(1+beta) then one get the= same average window as of NewReno TCP.=C2=A0 But how does it follow that

=C2=A0

W_aimd(t) =3D W_max*beta_aimd +

=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 [3*(1-beta_aimd)/(1+beta_aimd)] * (t/RTT) (Eq. 4)=

=C2=A0

is a r= easonable estimate for the window of standard TCP CC as quoted as being the= intention in section 1 ?


We can prove that Eq (4) has the same average window size as a reno fl= ow.

[Karen Elisabeth E= gede Nielsen] Sure =E2=80=93 I don=E2=80=99t doubt that.

=

=C2=A0=

QUESTION:

Is (Eq. 4) the best implementation cho= ice for comparison with TCP New Reno that were manageable from an implement= ation perspective or is (Eq 4) the rule that a CUBIC implementation<= /p>

should aim to follow ? I.e.,= that the Linux TCP implementation aims to follow ?

=C2=A0

In the latter case, then I think one should probably use t= he following formulation in Section 1:

=C2=A0

When the cubic

=C2=A0=C2=A0 function grows slower than the window of standard AIMD = CC, CUBIC simply

=C2=A0=C2=A0 follows the window size = of standard AIMD CC to ensure fairness to

=C2=A0=C2=A0= Standard TCP in a small BDP network.

=C2=A0

And then probably relate to that the fairness comes (?) from calibrat= ion towards same average window - - -

=C2=A0

=
There are two methods to get the average window size of a reno flow.
1. simulate a reno flow for each ack and each packet. but this method = requires more variables and more code to simulate reno.

2. use Eq (4= ) to directly calculate the average window size of a reno flow. this method= is much simpler than the first method, because it does not need to simulat= e a reno flow. this is what Cubic does.

=C2=A0=

=C2=A0

[Karen Elisabeth Egede Nielsen] You don= =E2=80=99t use (Eq 4) to calculate the average window. You use eq 4 =E2=80= =93 you say - because this algorithm gives the same average window as New R= eno and therefore you say it is a valid approach.

=C2=A0

From an implementation perspective I am not sure there is s= o much difference, there is one namely the ramp down at FR, but otherwise t= hey need to do the same, just with a different alpha (the beta_scale in Lin= ux. Both needs to take care of underutilization.

=C2=A0

[Karen Elisabeth Egede Nielsen] Yes =E2=80=93 my question w= as whether you wanted 1, but were doing 2 =C2=A0because of ease of implemen= tation, or whether you from a model perspective wanted to do 2.<= /b>

What I hear you saying is that you want 1, but is doing 2.=

=C2=A0

1 and 2 are really two different things =E2= =80=93 at least from a theoretical perspective. Especially as you only use = the calculation on a fraction of the domain only.

=C2=A0<= /span>

I think it should be obvious that 2 can give a higher CW= ND just after FR, but also that the difference goes away over time (at whic= h point CUBIC then likely uses the CUBIC graph J).

On = the other hand Eg 4 may be more modest generally =E2=80=93 e.g. when increa= sing from a non-validated window. Just thinking out load.

= =C2=A0

Have you experimented with to which extend 2 _signi= ficantly_ differs from 1 =E2=80=93 especially in conjunction with CUBIC ?

=C2=A0

I am not saying even that 2 is not = the ideal approach =E2=80=93 but it need some more persuading to tell that = it models New Reno well in the way it is being used.

=C2=A0

[Karen Elisabeth E= gede Nielsen] It had actually been simpler (I think) if the argument was th= at you wanted 2 and then argue for why this is reasonable fair with New Ren= o.

=C2=A0

<= span lang=3D"EN-US" style=3D"color:#1f497d">As said before, we are defining= this for SCTP =E2=80=93 let=E2=80=99s see=C2=A0 - we may experiment with b= oth 1 and 2.

I have not understood (not tried to understa= nd) what kind of validation TCP Linux is running with when the cwnd is unde= rutilized (not cwnd limited). In SCTP there is no cwnd increase during

cwnd underutilization, but not any cwnd decaying either. This = may give a difference in the overall resulting behavior of course.

=C2=A0

Many Thanks= .

Lisong


Thanks !

=C2=A0

BR, Kare= n

=C2=A0

****************************************************************= *************************

Karen Egede Nielsen=

Software Architect, Ph.D.<= span lang=3D"EN-US">

=C2=A0=

Tieto Denmark A/S

R&D, Telecom & Media=

=C3=85have Parkvej, 8260 Viby J, DK-Denmark

Direct Phone / Mobile +45 25134336

E-mail: karen.nie= lsen@tieto.com

************************************= *****************************************************

<= a href=3D"http://www.tieto.com">www.tieto.com=C2=A0

=C2=A0

Please note: The information contain= ed in this message may be legally privileged and confidential and protected= from disclosure. If the reader of this message is not the intended recipie= nt, you are hereby notified that any unauthorised use, distribution or copy= ing of this communication is strictly prohibited. If you have received this= communication in error, please notify us immediately by replying to the me= ssage and deleting it from your computer. Thank You.

=C2=A0

=C2=A0

--047d7bfea0b6bb4a36052e260c7a-- From nobody Fri Mar 18 21:07:04 2016 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 71DAC12D6C3; Fri, 18 Mar 2016 21:07:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.491 X-Spam-Level: X-Spam-Status: No, score=-0.491 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=uofnelincoln.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 SgQKktPkoW3j; Fri, 18 Mar 2016 21:06:59 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0235.outbound.protection.outlook.com [207.46.163.235]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80B5312D66B; Fri, 18 Mar 2016 21:06:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uofnelincoln.onmicrosoft.com; s=selector1-unl-edu; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=47INQpnOs+1+uYyZFSQDGuIEiNFyqSwuAPKQoLUco38=; b=0C7dzvwjStI5HNGsw+mQBKk9mPWB2gRLOxQmi2ehHvXeVBz9kjSnsIAvzfxM2XBS7/k9hpY84ujxM60kCI9SQPK08qJNhl0vyI6ZzOVNo3vLITV7iTgMZ51mS/tyZDI2ubdlLQnM/wAH6rQVKE4fWMNorh+ZAKqfxMluX5w9Wv8= Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=unl.edu; Received: from [192.168.0.164] (97.98.140.59) by BY2PR08MB1460.namprd08.prod.outlook.com (10.162.81.153) with Microsoft SMTP Server (TLS) id 15.1.443.12; Sat, 19 Mar 2016 04:06:56 +0000 To: Karen Elisabeth Egede Nielsen , References: <28265_1458030005_u2F8K4us025832_bb0b000b861f2a1e54225a8662b87a69@mail.gmail.com> <56E8D363.2080801@unl.edu> <14035_1458115854_u2G8AskH024517_22021b5df9cac80a9d8c0ba9ea526ef4@mail.gmail.com> From: Lisong Xu Organization: University of Nebraska-Lincoln Message-ID: <56ECD07A.3010407@unl.edu> Date: Fri, 18 Mar 2016 23:07:22 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <14035_1458115854_u2G8AskH024517_22021b5df9cac80a9d8c0ba9ea526ef4@mail.gmail.com> Content-Type: multipart/alternative; boundary="------------010203040409050808070806" X-Originating-IP: [97.98.140.59] X-ClientProxiedBy: BLUPR0401CA0015.namprd04.prod.outlook.com (25.162.114.153) To BY2PR08MB1460.namprd08.prod.outlook.com (25.162.81.153) X-MS-Office365-Filtering-Correlation-Id: 937b43b1-a462-4059-a267-08d34fabea0c X-Microsoft-Exchange-Diagnostics: 1; BY2PR08MB1460; 2:D6xfKoqkK7zhrgQu1jkROo7KJRLGqNhMcn+clNE3rNN595For27Q7aole0QMSsFExUuvdaDeyJ9WiNJL8iPJ7n4SBxMeF6JJ7eJtmIjcOHO8vOvOkUdVhnxMN1z1mvFZQeRaK4k/UuCZe3ASNNp9yursT3J2+AuZhXsyAXu7cP7yIX6+2E9y6yTF6ksrmuHC; 3:4lhHJYc6oiP7fAgGswD7uQiCZaSwK6l9UspuEdIFYyLvnhj9wFJzEw5iM/9puCKrqM015ro2anMSrwg9cNkL5tBlFTYK6WedZi3pt6mriAZ5EiygCVQ3/qqtwWxLdmdB X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR08MB1460; X-Microsoft-Exchange-Diagnostics: 1; BY2PR08MB1460; 25:3jmlPhiCZNKTFk5IluX4/sJ7NcuX9i3ekhInRs+8C+0h+L//i2az6NIpwt4za51Rla0e04iAliIZKMblNUxljifWQYOvGh0Fa1YWITlvaGo47bIM5gLOdOoqP0COlDDG+Jdw4zmW3ZCj3bAuBpdMK9HJTMzZlQZa2bJ5h29nkmNnyBZR5F1JrAyCg10h1pQ41imI4N04QsxkwqzUVnvKCdzg9yGAUvXriCT8QHzz0TC9y8/Kx8ud559+VfXtjAmm+akAzh/y6GjktEyhS8t5OGNOdZtf0N7UqL6qybD9QzcaL+teTuzjUkflYfywvSnbDWBmXu9vZgpEi8FEHlN2ne6lOlEfhk2DjcuS+6pwm5E5JINHR1czJmACmpJKzM47WO7eKPanc0aL/Vrc99b6SR+k9ZhSMc8zuQ38w9vcvcrl0piVDJhNvF0EmAhuAi78Mg9c6RbdoVe6HmaVJba+vWv43hxkzvE89fR19/XI3Xp6NqOnKeAppjKUgi6LLnCAgxJ9CQZCZY3II30cmsdTEk3evJUDDdvs8izhLRoRxxIKuGCoDsMC5Nodwj5yabP6VWTZcYI4wBR5aUUjnSMdKrsp125E0A+zLaHmC/mycq92BnJlMLaJTaDdlkovTQo6727vi3cGGbRaD501gxkb0B1Ic/GzPF4EfTcTkiiICcdBpduo0uJotPGxjrQVoA2o4XreA1FvaFJ3015FAikYwi6ypT25rVrMV+hvecpqUYQWf5KjNkjKSxr0STHjtrac X-Microsoft-Exchange-Diagnostics: 1; BY2PR08MB1460; 20:1x3HX5rw4FTj8m9b+Ea8MlQfYPQOVOHISVB3PM3gO1N+th1rfh74okNypdO2rV7CJIKFucpoSAxR4hha66S8sDiKYEoO4rPLTzMpKPlSJaFwT3zXcUXd7aEGjSsbsSFspvcWRf/YQKkWIgdtq5W5yLpU3rZbDMBYFbg7/e5yMqUPzvjfqP+PUkb9LTlTL58hlS+RMXa2hNX7lGqCGWfMdrynMd8sVKZuKUsFgh1WtM4Ta9/bPzXOp9bOFHc/9wigeImtAYRP5M0+eyPPIPqCqRYVhQEyt305QStKkRXt562JqEAsp+D90gaOkq7F4YXltR/ki+LRf3T3Bf8HKSeYciJ5dt8CQlMzkVjOVnHAGVxvlGsr0yau59ev6L2mgQni2qkf3vNHxKOvhNSyh5kUHNgJpTqXZDis95btM7SMe46bcMIJVFwovH46KnJ5iOLBgS2U431c21uTsRiUQ2mxWNkrIT7+wmZ/QP6Y3tYI14i4fwtIQ18jYgXIbJ3II3mC; 4:jaIIHr8pwYQRwXFpRPAfzXxQ7xOZm0ouaE2TPjJe1a9FS3Fa01fFACaINqQQYCqGjXZ+NmGXhUD/nJfDafom1eDoCkxjSia7eaSKgw6rt+4o8ZO+TrwMDIsie7HT4SiT4GHzw/jIOsB2xEXKC51JunypRDopRcTfAJLjlBtfYDXbXnH6PhIINbxf9p60DtV3VkjThWDyeJ+FEdVDJlEbWcIB6llGkZHzO7Qbf+YYb1CXRsz8GVTiyZZ90tFyOipIo0toCMPvOa/Q7GqB3rP1PU3h7SEew8e26+QeUEUnIbvN1am8kZZifnDqoR8FVqdzyi1oYz88zNKgKA5jZWCU6AhoSO4wYoqATe3QG1LEYXYHo2KEibQfhlaSLRd7HNf/ X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001); SRVR:BY2PR08MB1460; BCL:0; PCL:0; RULEID:; SRVR:BY2PR08MB1460; X-Forefront-PRVS: 08864C38AC X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(24454002)(66654002)(252514010)(43544003)(377454003)(84326002)(81166005)(92566002)(64126003)(89122001)(19580405001)(512874002)(86362001)(42186005)(19580395003)(3846002)(83506001)(4001350100001)(5008740100001)(16236675004)(33656002)(75432002)(5001770100001)(189998001)(5004730100002)(19617315012)(76176999)(117156001)(2906002)(6116002)(59896002)(87266999)(586003)(65956001)(50986999)(65816999)(66066001)(65806001)(19625215002)(54356999)(36756003)(2950100001)(77096005)(15974865002)(15975445007)(4326007)(16601075003)(1096002)(88552002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR08MB1460; H:[192.168.0.164]; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BY2PR08MB1460; 23:WNHo8ZA0ChaQvgqWiH4hia1ZXlh3ctvt0htGINRK1?= =?us-ascii?Q?Uj3tD8Er3nz5ymT+bWIneE6v6ZbafxcYsWMeL9O9GmuQzYtS0y5YyW0FOEHA?= =?us-ascii?Q?3ED1IO6Mepj9yUO6a8jzMhvneN3Y6E/fdclYDAdT9hH/WoynVkaOnc5SGfsj?= =?us-ascii?Q?kqHIj5UydIq+bCvsR6FSBhPlu1KVt/y97ZB8INSr5mhRk0Cax6Uxzx7sMvy8?= =?us-ascii?Q?NdEQZRTSHyE0Kor4xLRftMc+hZcPHsKjBjI25gO1naohreGv3KSzIW7Dagr6?= =?us-ascii?Q?w3I6ao7aNjLbKT5jp66b7eyJlNWKd0hqWDdQEbf5n1Ntftpj4/gEgYF4C+Fw?= =?us-ascii?Q?U18Hto2HGMTtdnjUTFry3jr8NIUDBX+SbymdIF57pn/CcawyH7gcZ9/OPLjp?= =?us-ascii?Q?shzN3LMMtAc3IUt2s5O9wpxnmjx0SoQTvcNZI19uJUSd5vMdWCg02e6JwUHK?= =?us-ascii?Q?Au/J7gAcAXGGNAmRI10PpvUHQ6cm4MMNg1kfoZ+fm/SMCan4GET4a6eZd3VQ?= =?us-ascii?Q?FsqruPZFTrdfIsrxsGxiEwEF5FuBWvlf1XNf0W+v8BXVrhWpxxY+zfhKP4fc?= =?us-ascii?Q?KD5FNIOIIsLs9XZ3bihpqKJfiWnq/8jZKtlEyuvEqDH3vOsM+pv6VokAgjmH?= =?us-ascii?Q?H/nvwqlZBQ7NnqX1oykszXUE7R56M4uBxnzjwswaV6deAdUMhKfeaxhFP5Fj?= =?us-ascii?Q?LpsFWGoSV619EttDmi2AXdm2jUIncuI6g8I01HT8h43ZZsB3geonuE92gnO8?= =?us-ascii?Q?7LPD8yrjz4hBmPlO8Lw7C+3xaaGNOuPS7hmTyusIpTx6p3fxaf5TVsX0tIjE?= =?us-ascii?Q?KYdpktF4o/Daa9eeL8846b3gMk0DgC5sqY8uKAh4jKPTihzL4tLNB5mGuCZQ?= =?us-ascii?Q?K5Y5w47H1voOMk1knhqQvwMRX2f+S6+vPj5PXPDPHCOnrA44V93ljJImhiTR?= =?us-ascii?Q?Owa8fXPXxBXk9QfVOgx+oaWxlqdaDyvFQtwy+ue/i5ZoRo88rAog9j/iZi/Y?= =?us-ascii?Q?19re6p2esFzWQ8/su4GSefRy7ZGAe6efu108wQ1wGCbbecAtCxSxLU8JKUIS?= =?us-ascii?Q?m2Jn36291Dz+1aOyLzap+4GUcgKqIfaBi9Z/FTa0PNnoCu0nlD7NzvreZphv?= =?us-ascii?Q?UQZz/30ahN2ol8W3BIk516676p7iwBy0qiT8DCD9gETVPOs1aRbgNerbJcYq?= =?us-ascii?Q?Rjs9+HZe7WpEM57ep3PCapA3P7M6SV4RA2HRIpwriDFQsi7BnnsSdH3+o2mR?= =?us-ascii?Q?h+gyJyWwDG5/DftSMvIqpvWUa3OeJ0Ot1x1ByY4TXL3pa0SzphnzfmSH1lof?= =?us-ascii?Q?QUhf4XVznIHco4OB0sNnEFCstORLidTMIUN++JYc8Y7?= X-Microsoft-Exchange-Diagnostics: 1; BY2PR08MB1460; 5:Vx2z/zTs1WtBJHBBsHgBF4glsWnM8aA/CbvDbmxTQpjucRRuDgMcCR8oSI2q9/sbnWitGD9kMpd63KXLG2FlqhnFLCkJpr6P1mD6Gv3m4lGCaP7yENrahgbUwDMhLDYfJY/r2951JZ1RoxYN3DlMyA==; 24:/DcGuz3K5KGxtsDTLURIssxs2bhOr4s1kHf9snmO6v3jgFTozSWtlMP4/RQFTnjcFsWRig3Dy6oSur0MgpjRn/q++9c8fumgyGKZFLC/j/Q= SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: unl.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Mar 2016 04:06:56.6882 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR08MB1460 Archived-At: Cc: tcpm@ietf.org Subject: Re: [tcpm] TCP friendly formulation in CUBIC-draft ? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 19 Mar 2016 04:07:03 -0000 --------------010203040409050808070806 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit Hi Karen, What we want is to make sure that the average window size is not less than that of reno. We do not need the instantaneous reno window size in each rtt, and thus what we want is not exactly (1). Both (1) and (2) can be used to achieve what we want. But (2) is simpler to implement, because (2) only considers the cwnd increase function whereas (1) must consider both the cwnd increase function and the cwnd decrease function (i.e., beta). Have a good weekend! Lisong On 3/16/2016 3:10 AM, Karen Elisabeth Egede Nielsen wrote: > > HI Lisong, > > Thanks. > > Please see below. > > BR, Karen > > *From:*Lisong Xu [mailto:xu@unl.edu ] > *Sent:* 16. marts 2016 04:31 > *To:* Karen Elisabeth Egede Nielsen >; draft-ietf-tcpm-cubic@ietf.org > > *Cc:* tcpm@ietf.org > *Subject:* Re: TCP friendly formulation in CUBIC-draft ? > > On 3/15/2016 3:19 AM, Karen Elisabeth Egede Nielsen wrote: > > Hi Lisong, Neal, All, > > I understand the basic principle of the TCP friendliness function > and I have no problem > > with having the window follow TCP New Reno when the CUBIC > algorithm would return a smaller value. > > I.e., following section 1 of the draft: > > When the cubic > > function grows slower than the window of Standard TCP, CUBIC simply > > follows the window size of Standard TCP to ensure fairness to > > Standard TCP in a small BDP network. > > With the disclaimer that I have not studied reference [FHP00] I > have, however, a problem understanding how this is achieved > > with formula (Eq. 4) of section 3.2 of draft-ietf-tcpm-cubic-01. > > From whatever in [FDP00] one get that the average window of AIMD > TCP CC is > > AVG_W_aimd = [ alpha_aimd * (1+beta_aimd) / > > (2*(1-beta_aimd)*p) ]^0.5 (eq. 3) > > which with alpha = 1 and beta = 0,5 indeed yields AVG_W_Newreno = > (1.5/p)^0.5.(Good otherwise we were in trouble). > > One can further observe from (3), of course, that generally for > AIMD CC with alpha equal to > > 3*(1-beta)/(1+beta) then one get the same average window as of > NewReno TCP. But how does it follow that > > W_aimd(t) = W_max*beta_aimd + > > [3*(1-beta_aimd)/(1+beta_aimd)] * (t/RTT) (Eq. 4) > > is a reasonable estimate for the window of standard TCP CC as > quoted as being the intention in section 1 ? > > > We can prove that Eq (4) has the same average window size as a reno flow. > > */[Karen Elisabeth Egede Nielsen] Sure – I don’t doubt that. > > /* > > QUESTION: > > Is (Eq. 4) the best implementation choice for comparison with TCP > New Reno that were manageable from an implementation perspective > or is (Eq 4) the rule that a CUBIC implementation > > should aim to follow ? I.e., that the Linux TCP implementation > aims to follow ? > > In the latter case, then I think one should probably use the > following formulation in Section 1: > > When the cubic > > function grows slower than the window of standard AIMD CC, > CUBIC simply > > follows the window size of standard AIMD CC to ensure fairness to > > Standard TCP in a small BDP network. > > And then probably relate to that the fairness comes (?) from > calibration towards same average window - - - > > > There are two methods to get the average window size of a reno flow. > > 1. simulate a reno flow for each ack and each packet. but this method > requires more variables and more code to simulate reno. > > 2. use Eq (4) to directly calculate the average window size of a reno > flow. this method is much simpler than the first method, because it > does not need to simulate a reno flow. this is what Cubic does. > > *//* > > */[Karen Elisabeth Egede Nielsen] You don’t use (Eq 4) to calculate > the average window. You use eq 4 – you say - because this algorithm > gives the same average window as New Reno and therefore you say it is > a valid approach./* > > *//* > > */From an implementation perspective I am not sure there is so much > difference, there is one namely the ramp down at FR, but otherwise > they need to do the same, just with a different alpha (the beta_scale > in Linux. Both needs to take care of underutilization. /* > > *//* > > */[Karen Elisabeth Egede Nielsen] Yes – my question was whether you > wanted 1, but were doing 2 because of ease of implementation, or > whether you from a model perspective wanted to do 2./* > > */What I hear you saying is that you want 1, but is doing 2./* > > *//* > > */1 and 2 are really two different things – at least from a > theoretical perspective. Especially as you only use the calculation on > a fraction of the domain only. /* > > *//* > > */I think it should be obvious that 2 can give a higher CWND just > after FR, but also that the difference goes away over time (at which > point CUBIC then likely uses the CUBIC graph /**/J/**/)./* > > */On the other hand Eg 4 may be more modest generally – e.g. when > increasing from a non-validated window. Just thinking out load./* > > *//* > > */Have you experimented with to which extend 2 _significantly_ differs > from 1 – especially in conjunction with CUBIC ?/* > > *//* > > */I am not saying even that 2 is not the ideal approach – but it need > some more persuading to tell that it models New Reno well in the way > it is being used./* > > */[Karen Elisabeth Egede Nielsen] It had actually been simpler (I > think) if the argument was that you wanted 2 and then argue for why > this is reasonable fair with New Reno./* > > *//* > > */As said before, we are defining this for SCTP – let’s see - we may > experiment with both 1 and 2. /* > > */I have not understood (not tried to understand) what kind of > validation TCP Linux is running with when the cwnd is underutilized > (not cwnd limited). In SCTP there is no cwnd increase during/* > > */cwnd underutilization, but not any cwnd decaying either. This may > give a difference in the overall resulting behavior of course./* > > Many Thanks. > > Lisong > > > Thanks ! > > BR, Karen > > ******************************************************************************************* > > *Karen Egede **N**ielsen* > > Software Architect, Ph.D. > > *Tieto Denmark A/S* > > R&D, Telecom & Media > > Åhave Parkvej, 8260 Viby J, DK-Denmark > > Direct Phone / Mobile +45 25134336 > > E-mail: karen.nielsen@tieto.com > > ***************************************************************************************** > > www.tieto.com > > // > > /Please note: The information contained in this message may be > legally privileged and confidential and protected from disclosure. > If the reader of this message is not the intended recipient, you > are hereby notified that any unauthorised use, distribution or > copying of this communication is strictly prohibited. If you have > received this communication in error, please notify us immediately > by replying to the message and deleting it from your computer. > Thank You./ > --------------010203040409050808070806 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 8bit Hi Karen,

What we want is to make sure that the average window size is not less than that of reno.  We do not need the instantaneous reno window size in each rtt, and thus what we want is not exactly (1). Both (1) and (2) can be used to achieve what we want. But (2) is simpler to implement, because (2) only considers the cwnd increase function whereas (1) must consider both the cwnd increase function and the cwnd decrease function (i.e., beta).

Have a good weekend!
Lisong

On 3/16/2016 3:10 AM, Karen Elisabeth Egede Nielsen wrote:

HI Lisong,

 

Thanks.

 

Please see below.

 

BR, Karen

 

From: Lisong Xu [mailto:xu@unl.edu]
Sent: 16. marts 2016 04:31
To: Karen Elisabeth Egede Nielsen <karen.nielsen@tieto.com>; draft-ietf-tcpm-cubic@ietf.org
Cc: tcpm@ietf.org
Subject: Re: TCP friendly formulation in CUBIC-draft ?

 

 

On 3/15/2016 3:19 AM, Karen Elisabeth Egede Nielsen wrote:

Hi Lisong, Neal, All,

 

I understand the basic principle of the TCP friendliness function and I have no problem

with having the window follow TCP New Reno when the CUBIC algorithm would return a smaller value.

I.e., following section 1 of the draft:

 

When the cubic

   function grows slower than the window of Standard TCP, CUBIC simply

   follows the window size of Standard TCP to ensure fairness to

   Standard TCP in a small BDP network.

 

 

With the disclaimer that I have not studied reference [FHP00] I have, however, a problem understanding how this is achieved

with formula (Eq. 4) of section 3.2 of draft-ietf-tcpm-cubic-01.

 

From whatever in [FDP00] one get that the average window of AIMD TCP CC is

 

       AVG_W_aimd = [ alpha_aimd * (1+beta_aimd) /

                      (2*(1-beta_aimd)*p) ]^0.5          (eq. 3)

 

 

which with alpha = 1 and beta = 0,5 indeed yields AVG_W_Newreno = (1.5/p)^0.5. (Good otherwise we were in trouble).
One can further observe from (3), of course,  that generally for AIMD CC with  alpha equal to

   3*(1-beta)/(1+beta) then one get the same average window as of NewReno TCP.  But how does it follow that

 

W_aimd(t) = W_max*beta_aimd +

                   [3*(1-beta_aimd)/(1+beta_aimd)] * (t/RTT) (Eq. 4)

 

is a reasonable estimate for the window of standard TCP CC as quoted as being the intention in section 1 ?


We can prove that Eq (4) has the same average window size as a reno flow.

[Karen Elisabeth Egede Nielsen] Sure – I don’t doubt that.

 

QUESTION:

Is (Eq. 4) the best implementation choice for comparison with TCP New Reno that were manageable from an implementation perspective or is (Eq 4) the rule that a CUBIC implementation

should aim to follow ? I.e., that the Linux TCP implementation aims to follow ?

 

In the latter case, then I think one should probably use the following formulation in Section 1:

 

When the cubic

   function grows slower than the window of standard AIMD CC, CUBIC simply

   follows the window size of standard AIMD CC to ensure fairness to

   Standard TCP in a small BDP network.

 

And then probably relate to that the fairness comes (?) from calibration towards same average window - - -

 


There are two methods to get the average window size of a reno flow.

1. simulate a reno flow for each ack and each packet. but this method requires more variables and more code to simulate reno.

2. use Eq (4) to directly calculate the average window size of a reno flow. this method is much simpler than the first method, because it does not need to simulate a reno flow. this is what Cubic does.

 

 

[Karen Elisabeth Egede Nielsen] You don’t use (Eq 4) to calculate the average window. You use eq 4 – you say - because this algorithm gives the same average window as New Reno and therefore you say it is a valid approach.

 

From an implementation perspective I am not sure there is so much difference, there is one namely the ramp down at FR, but otherwise they need to do the same, just with a different alpha (the beta_scale in Linux. Both needs to take care of underutilization.

 

[Karen Elisabeth Egede Nielsen] Yes – my question was whether you wanted 1, but were doing 2  because of ease of implementation, or whether you from a model perspective wanted to do 2.

What I hear you saying is that you want 1, but is doing 2.

 

1 and 2 are really two different things – at least from a theoretical perspective. Especially as you only use the calculation on a fraction of the domain only.

 

I think it should be obvious that 2 can give a higher CWND just after FR, but also that the difference goes away over time (at which point CUBIC then likely uses the CUBIC graph J).

On the other hand Eg 4 may be more modest generally – e.g. when increasing from a non-validated window. Just thinking out load.

 

Have you experimented with to which extend 2 _significantly_ differs from 1 – especially in conjunction with CUBIC ?

 

I am not saying even that 2 is not the ideal approach – but it need some more persuading to tell that it models New Reno well in the way it is being used.

 

[Karen Elisabeth Egede Nielsen] It had actually been simpler (I think) if the argument was that you wanted 2 and then argue for why this is reasonable fair with New Reno.

 

As said before, we are defining this for SCTP – let’s see  - we may experiment with both 1 and 2.

I have not understood (not tried to understand) what kind of validation TCP Linux is running with when the cwnd is underutilized (not cwnd limited). In SCTP there is no cwnd increase during

cwnd underutilization, but not any cwnd decaying either. This may give a difference in the overall resulting behavior of course.

 

Many Thanks.

Lisong


Thanks !

 

BR, Karen

 

*****************************************************************************************

Karen Egede Nielsen

Software Architect, Ph.D.

 

Tieto Denmark A/S

R&D, Telecom & Media

Ă…have Parkvej, 8260 Viby J, DK-Denmark

Direct Phone / Mobile +45 25134336

E-mail: karen.nielsen@tieto.com

*****************************************************************************************

www.tieto.com 

 

Please note: The information contained in this message may be legally privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, you are hereby notified that any unauthorised use, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank You.

 

 


--------------010203040409050808070806-- From nobody Mon Mar 21 00:28:55 2016 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 B8EE412D617 for ; Mon, 21 Mar 2016 00:28:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.69 X-Spam-Level: X-Spam-Status: No, score=-2.69 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, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=tieto.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 aygM_Z2vuhBm for ; Mon, 21 Mar 2016 00:28:51 -0700 (PDT) Received: from mail-io0-x229.google.com (mail-io0-x229.google.com [IPv6:2607:f8b0:4001:c06::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 E473312D113 for ; Mon, 21 Mar 2016 00:28:50 -0700 (PDT) Received: by mail-io0-x229.google.com with SMTP id 124so48535135iov.3 for ; Mon, 21 Mar 2016 00:28:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tieto.com; s=google; h=from:references:in-reply-to:mime-version:thread-index:date :message-id:subject:to:cc; bh=OJGo3RIS2DJalZjgLqkb28ovOLLYJEPvEUTK/YOwd2E=; b=UbluPU3c7C2RAkaSEqAXI1ISm6//1nbMdyc8XQVyvpb3hgRphJoVMjZQ2tpr5moVv0 /9+8lBqOZhD2uGhFZHHFBZdK/ja8YvwPNPFllBw+O1+YDWWxtN+34cCjddkKCcka1Yvu w5mXNZMdEWUmhQ3HEEJ8rWYCQyjj/Xx1pHFLY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:references:in-reply-to:mime-version :thread-index:date:message-id:subject:to:cc; bh=OJGo3RIS2DJalZjgLqkb28ovOLLYJEPvEUTK/YOwd2E=; b=g1o680RJV+WttZhHoCq5bwn3322ac30K61vtG3MwbUDXHMxt5flB/g5fjIDe4X5H0K CcIFTO8B6qyNWVICl9YHICw6wYapHuWRiRW1TonubyWghLMf3Ax0z9kDs9Oqjmcxj0Sz EAb1xFn/vs1mvyJRw+y9zIWVGpG7AgXr3RqNcMrrVGGdQO7nsw8SzO4s4eg4rcjwdtsz EItZAL3Mx1bmbLE2lZLqtxtoWXWHQcxKgJWQZ1akwyXtdBAsS21prIlIHzaPSP3K9CtE DP7vlH9i7RBJ90NmeQV+XGGGozrV2M/2u1lTSi0Am2fX3pavdMPjfpVWBpbxL/l/jThA C92w== X-Gm-Message-State: AD7BkJIcMc638y11QZSANB5aHdzMV+73ytWj0xfMPWY6AFtRavnKGzty8QhOykqUeRttY8V2/3t8muATZu8pnv75Mjh73f0GMPJnsUj79w218+j12kpCht6QsKVm6Irh7khAsGA= X-Received: by 10.107.12.207 with SMTP id 76mr28129825iom.70.1458545330163; Mon, 21 Mar 2016 00:28:50 -0700 (PDT) From: Karen Elisabeth Egede Nielsen References: <28265_1458030005_u2F8K4us025832_bb0b000b861f2a1e54225a8662b87a69@mail.gmail.com> <56E8D363.2080801@unl.edu> <14035_1458115854_u2G8AskH024517_22021b5df9cac80a9d8c0ba9ea526ef4@mail.gmail.com> <56ECD07A.3010407@unl.edu> In-Reply-To: <56ECD07A.3010407@unl.edu> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQIbw19NaMpQgnr/3M9AdWgbjB7BugM9Fpq6AnWoUP4BZPwWCZ6WP8Lg Date: Mon, 21 Mar 2016 08:28:49 +0100 Message-ID: To: Lisong Xu , draft-ietf-tcpm-cubic@ietf.org Content-Type: multipart/alternative; boundary=001a113eca064b2a6a052e8a0cae X-DomainID: tieto.com Archived-At: Cc: tcpm@ietf.org Subject: Re: [tcpm] TCP friendly formulation in CUBIC-draft ? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 21 Mar 2016 07:28:54 -0000 --001a113eca064b2a6a052e8a0cae Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Lisong, I am not opposed to what you=E2=80=99re doing. Just to make that absolutely= clear ! I also think that you achieve a larger average than Reno, which is part of what you want for the RTT fairness generally of CUBIC. I don=E2=80=99t understand _*your argumentation*_ for the TCP friendliness = function though. Again I am not (necessarily) opposed to the function itself, whether (1) or (2). It is the argumentation which isn=E2=80=99t clear. You take two functions (1) and (2) that have the same average (integral) over a large domain and then apply them on _*a subset of subset of the domain*_ and CUBIC in another subset of the domain. Have you proven that (1) and (2) have the same average in the subset of the domain where they are applied (i.e. away from where CUBIC is applied). Otherwise please change your argumentation to Better reflect exactly what you=E2=80=99re doing. Thanks. BR, Karen *From:* Lisong Xu [mailto:xu@unl.edu] *Sent:* 19. marts 2016 05:07 *To:* Karen Elisabeth Egede Nielsen ; draft-ietf-tcpm-cubic@ietf.org *Cc:* tcpm@ietf.org *Subject:* Re: TCP friendly formulation in CUBIC-draft ? Hi Karen, What we want is to make sure that the average window size is not less than that of reno. We do not need the instantaneous reno window size in each rtt, and thus what we want is not exactly (1). Both (1) and (2) can be used to achieve what we want. But (2) is simpler to implement, because (2) only considers the cwnd increase function whereas (1) must consider both the cwnd increase function and the cwnd decrease function (i.e., beta). Have a good weekend! Lisong On 3/16/2016 3:10 AM, Karen Elisabeth Egede Nielsen wrote: HI Lisong, Thanks. Please see below. BR, Karen *From:* Lisong Xu [mailto:xu@unl.edu] *Sent:* 16. marts 2016 04:31 *To:* Karen Elisabeth Egede Nielsen ; draft-ietf-tcpm-cubic@ietf.org *Cc:* tcpm@ietf.org *Subject:* Re: TCP friendly formulation in CUBIC-draft ? On 3/15/2016 3:19 AM, Karen Elisabeth Egede Nielsen wrote: Hi Lisong, Neal, All, I understand the basic principle of the TCP friendliness function and I have no problem with having the window follow TCP New Reno when the CUBIC algorithm would return a smaller value. I.e., following section 1 of the draft: When the cubic function grows slower than the window of Standard TCP, CUBIC simply follows the window size of Standard TCP to ensure fairness to Standard TCP in a small BDP network. With the disclaimer that I have not studied reference [FHP00] I have, however, a problem understanding how this is achieved with formula (Eq. 4) of section 3.2 of draft-ietf-tcpm-cubic-01. >From whatever in [FDP00] one get that the average window of AIMD TCP CC is AVG_W_aimd =3D [ alpha_aimd * (1+beta_aimd) / (2*(1-beta_aimd)*p) ]^0.5 (eq. 3) which with alpha =3D 1 and beta =3D 0,5 indeed yields AVG_W_Newreno =3D (1.5/p)^0.5. (Good otherwise we were in trouble). One can further observe from (3), of course, that generally for AIMD CC with alpha equal to 3*(1-beta)/(1+beta) then one get the same average window as of NewReno TCP. But how does it follow that W_aimd(t) =3D W_max*beta_aimd + [3*(1-beta_aimd)/(1+beta_aimd)] * (t/RTT) (Eq. 4) is a reasonable estimate for the window of standard TCP CC as quoted as being the intention in section 1 ? We can prove that Eq (4) has the same average window size as a reno flow. *[Karen Elisabeth Egede Nielsen] Sure =E2=80=93 I don=E2=80=99t doubt that.= * QUESTION: Is (Eq. 4) the best implementation choice for comparison with TCP New Reno that were manageable from an implementation perspective or is (Eq 4) the rule that a CUBIC implementation should aim to follow ? I.e., that the Linux TCP implementation aims to follow ? In the latter case, then I think one should probably use the following formulation in Section 1: When the cubic function grows slower than the window of standard AIMD CC, CUBIC simply follows the window size of standard AIMD CC to ensure fairness to Standard TCP in a small BDP network. And then probably relate to that the fairness comes (?) from calibration towards same average window - - - There are two methods to get the average window size of a reno flow. 1. simulate a reno flow for each ack and each packet. but this method requires more variables and more code to simulate reno. 2. use Eq (4) to directly calculate the average window size of a reno flow. this method is much simpler than the first method, because it does not need to simulate a reno flow. this is what Cubic does. *[Karen Elisabeth Egede Nielsen] You don=E2=80=99t use (Eq 4) to calculate = the average window. You use eq 4 =E2=80=93 you say - because this algorithm giv= es the same average window as New Reno and therefore you say it is a valid approach.* *From an implementation perspective I am not sure there is so much difference, there is one namely the ramp down at FR, but otherwise they need to do the same, just with a different alpha (the beta_scale in Linux. Both needs to take care of underutilization. * *[Karen Elisabeth Egede Nielsen] Yes =E2=80=93 my question was whether you = wanted 1, but were doing 2 because of ease of implementation, or whether you from a model perspective wanted to do 2.* *What I hear you saying is that you want 1, but is doing 2.* *1 and 2 are really two different things =E2=80=93 at least from a theoreti= cal perspective. Especially as you only use the calculation on a fraction of the domain only. * *I think it should be obvious that 2 can give a higher CWND just after FR, but also that the difference goes away over time (at which point CUBIC then likely uses the CUBIC graph **J**).* *On the other hand Eg 4 may be more modest generally =E2=80=93 e.g. when in= creasing from a non-validated window. Just thinking out load.* *Have you experimented with to which extend 2 _significantly_ differs from 1 =E2=80=93 especially in conjunction with CUBIC ?* *I am not saying even that 2 is not the ideal approach =E2=80=93 but it nee= d some more persuading to tell that it models New Reno well in the way it is being used.* *[Karen Elisabeth Egede Nielsen] It had actually been simpler (I think) if the argument was that you wanted 2 and then argue for why this is reasonable fair with New Reno.* *As said before, we are defining this for SCTP =E2=80=93 let=E2=80=99s see = - we may experiment with both 1 and 2. * *I have not understood (not tried to understand) what kind of validation TCP Linux is running with when the cwnd is underutilized (not cwnd limited). In SCTP there is no cwnd increase during* *cwnd underutilization, but not any cwnd decaying either. This may give a difference in the overall resulting behavior of course.* Many Thanks. Lisong Thanks ! BR, Karen ***************************************************************************= **************** *Karen Egede **N**ielsen* Software Architect, Ph.D. *Tieto Denmark A/S* R&D, Telecom & Media =C3=85have Parkvej, 8260 Viby J, DK-Denmark Direct Phone / Mobile +45 25134336 E-mail: karen.nielsen@tieto.com ***************************************************************************= ************** www.tieto.com *Please note: The information contained in this message may be legally privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, you are hereby notified that any unauthorised use, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank You.* --001a113eca064b2a6a052e8a0cae Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable --001a113eca064b2a6a052e8a0cae-- From nobody Mon Mar 21 09:21:54 2016 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 DF29C12D89C; Mon, 21 Mar 2016 09:21:53 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.17.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160321162153.31944.19492.idtracker@ietfa.amsl.com> Date: Mon, 21 Mar 2016 09:21:53 -0700 Archived-At: Cc: tcpm@ietf.org Subject: [tcpm] I-D Action: draft-ietf-tcpm-rfc793bis-02.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2016 16:21:54 -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 : Transmission Control Protocol Specification Author : Wesley M. Eddy Filename : draft-ietf-tcpm-rfc793bis-02.txt Pages : 86 Date : 2016-03-21 Abstract: This document specifies the Internet's Transmission Control Protocol (TCP). TCP is an important transport layer protocol in the Internet stack, and has continuously evolved over decades of use and growth of the Internet. Over this time, a number of changes have been made to TCP as it was specified in RFC 793, though these have only been documented in a piecemeal fashion. This document collects and brings those changes together with the protocol specification from RFC 793. This document obsoletes RFC 793 and several other RFCs (TODO: list all actual RFCs when finished). RFC EDITOR NOTE: If approved for publication as an RFC, this should be marked additionally as "STD: 7" and replace RFC 793 in that role. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tcpm-rfc793bis/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-tcpm-rfc793bis-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-rfc793bis-02 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 Wed Mar 23 01:04:55 2016 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 4FF1412D75D; Wed, 23 Mar 2016 01:04:53 -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 i1BVQl3J7k9i; Wed, 23 Mar 2016 01:04:51 -0700 (PDT) Received: from mail-out5.uio.no (mail-out5.uio.no [IPv6:2001:700:100:10::17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 776B312D719; Wed, 23 Mar 2016 01:04:51 -0700 (PDT) Received: from mail-mx3.uio.no ([129.240.10.44]) by mail-out5.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1aidmb-00059b-QD; Wed, 23 Mar 2016 09:04:49 +0100 Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx3.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.80) (envelope-from ) id 1aidmb-0000L9-5L; Wed, 23 Mar 2016 09:04:49 +0100 From: Michael Welzl Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 23 Mar 2016 09:04:48 +0100 References: To: tcpm IETF list , tsvwg@ietf.org Message-Id: <28FFF903-C446-46A1-AA9E-4BD2566F1088@ifi.uio.no> Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) X-Mailer: Apple Mail (2.2104) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 3 msgs/h 2 sum rcpts/h 7 sum msgs/h 4 total rcpts 39577 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, T_RP_MATCHES_RCVD=-0.01, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: FC462D5C80E0C6EF3FDCEC403C816EBFDEFABF6E X-UiO-SPAM-Test: remote_host: 129.240.68.135 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 2 total 9498 max/h 17 blacklist 0 greylist 0 ratelimit 0 Archived-At: Subject: [tcpm] Fwd: New Version Notification for draft-welzl-irtf-iccrg-tcp-in-udp-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 23 Mar 2016 08:04:53 -0000 Hi, This could be of interest to folks here. We'd be glad to get your = comments - please send them to the ICCRG list only, at iccrg@irtf.org. Cheers, Michael > Begin forwarded message: >=20 > From: Michael Welzl > Subject: Fwd: New Version Notification for = draft-welzl-irtf-iccrg-tcp-in-udp-00.txt > Date: 23 Mar 2016 09:02:38 CET > To: iccrg@irtf.org >=20 > (..) >=20 > Chair hat off: >=20 > Dear all, >=20 > I'm submitting this to ICCRG as the primary (and possibly ultimate? = We'll see) forum to discuss this draft. We'd be happy to get your = comments - please keep them on the ICCRG list. > We have FreeBSD code, from which we can already confirm that the = encapsulation is indeed relatively easy to do (as our draft states). = However, it doesn't do the congestion control coupling yet; we're = working on it. For that, so far, we have simulations - from these, we = hope to be able to show some first results in BA. >=20 > Cheers, > Michael >=20 >=20 >=20 >> Begin forwarded message: >>=20 >> From: >> Subject: New Version Notification for = draft-welzl-irtf-iccrg-tcp-in-udp-00.txt >> Date: 21 Mar 2016 18:45:57 CET >> To: Jianjie You , Michael Welzl = , Safiqul Islam , Kristian = Hiorth >> Resent-From: >>=20 >>=20 >> A new version of I-D, draft-welzl-irtf-iccrg-tcp-in-udp-00.txt >> has been successfully submitted by Michael Welzl and posted to the >> IETF repository. >>=20 >> Name: draft-welzl-irtf-iccrg-tcp-in-udp >> Revision: 00 >> Title: TCP in UDP >> Document date: 2016-03-21 >> Group: Individual Submission >> Pages: 17 >> URL: = https://www.ietf.org/internet-drafts/draft-welzl-irtf-iccrg-tcp-in-udp-00.= txt >> Status: = https://datatracker.ietf.org/doc/draft-welzl-irtf-iccrg-tcp-in-udp/ >> Htmlized: = https://tools.ietf.org/html/draft-welzl-irtf-iccrg-tcp-in-udp-00 >>=20 >>=20 >> Abstract: >> This document specifies a method to encapsulate multiple TCP >> connections using only one UDP port number pair. Doing so allows = for >> a relatively easy implementation of coupled congestion control for >> the TCP connections. This can have several performance benefits, = and >> it makes it possible to precisely assign a share of the congestion >> window to the connections based on priorities. It also enables use >> of UDP-based NAT traversal techniques, and it can act as a framework >> for experimentation with novel changes to the TCP standard. >>=20 >>=20 >>=20 >>=20 >>=20 >> Please note that it may take a couple of minutes from the time of = submission >> until the htmlized version and diff are available at tools.ietf.org. >>=20 >> The IETF Secretariat >>=20 >=20 From nobody Tue Mar 29 10:40:19 2016 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 6F51812DB66; Tue, 29 Mar 2016 10:40:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.891 X-Spam-Level: X-Spam-Status: No, score=-1.891 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=-0.001, SPF_HELO_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=uofnelincoln.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 GRV9v1ThLBN3; Tue, 29 Mar 2016 10:40:14 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0210.outbound.protection.outlook.com [207.46.163.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0163B12DA53; Tue, 29 Mar 2016 10:22:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uofnelincoln.onmicrosoft.com; s=selector1-unl-edu; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=y8LAcUrQRGPTUg74mc9mrCvcNMew+j4Z8GlTwHx+BDc=; b=Bhg74nqF3SJw+00DiowQ8Tq8E6mNonb5LwvmYsyVM8vJPb2EziGvgs70+A+0pc7uynyonvw5bTYEaxMmifBENIx6fBdS6RbknGSpxMf+HJacqMFlkiw6qq/IFDuGHyWdsJ7Q8eRR4kmx/5jgSIqfrIrB+L3euCZwuhJUnFCeS04= Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=unl.edu; Received: from [192.168.0.164] (97.98.140.59) by SN1PR08MB1469.namprd08.prod.outlook.com (10.162.2.12) with Microsoft SMTP Server (TLS) id 15.1.447.15; Tue, 29 Mar 2016 17:22:51 +0000 To: Karen Elisabeth Egede Nielsen , References: <28265_1458030005_u2F8K4us025832_bb0b000b861f2a1e54225a8662b87a69@mail.gmail.com> <56E8D363.2080801@unl.edu> <14035_1458115854_u2G8AskH024517_22021b5df9cac80a9d8c0ba9ea526ef4@mail.gmail.com> <56ECD07A.3010407@unl.edu> From: Lisong Xu Organization: University of Nebraska-Lincoln Message-ID: <56FABA13.30102@unl.edu> Date: Tue, 29 Mar 2016 12:23:31 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------000802000609090305020405" X-Originating-IP: [97.98.140.59] X-ClientProxiedBy: SN1PR17CA0040.namprd17.prod.outlook.com (10.169.33.178) To SN1PR08MB1469.namprd08.prod.outlook.com (10.162.2.12) X-MS-Office365-Filtering-Correlation-Id: ba0325eb-781e-4297-9de1-08d357f6c22b X-Microsoft-Exchange-Diagnostics: 1; SN1PR08MB1469; 2:pT6PUMoRPxE5hpwy0ba0g0Z0Q5LKLv0R6WN72ZWvbVqMb93Caz1dM6UurOyzRT5X8QE+dzQ5I6ewH3Z8JAgdx7atzY6n13ytg+r7ARRhz2kYSL7JVjWjICFNdps7SWmVeUrlhLdqdQtnEjzvHrP5FpS1zMfui29xSC662XeesZAAMh2QK9GPh71k1FHXw26p; 3:KybXgadsb1FPfn5nYsJ7aR1De7O7NlAlC0kjMGluTzD8P4J4Dc19H+g4npPGRpnqwVWjy/H7ATaVnf1rgNFXfSFRSp7ehcOoWrcwifN6EPE/yvrbWdxKQvb+3jMQ7TMo X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN1PR08MB1469; X-Microsoft-Exchange-Diagnostics: 1; SN1PR08MB1469; 25:N92O74dDtRPFdlGubrle2+gj66Ltu+Yy4deqj826IjmoOpLiiFVbew09Sn5h1FSbK7DsqCHXHWvdHyplrRwQJCiy41zs8+lxzqiRThIlv4T2IFOtGX6cQeKONs0uUec4eJGkcRLyzOnughZB4Xwh2JvWnJbCEGnLq5IIwZdM2zzEp9DdpGhQWVrllaOoIBAd+9YLh3yLJTqbw1VJGMA6OxM0R/mWGc/4Jk/9r0FGUP9uMI1WuN/O9VeZPQak1WJYyV2hvcp55hkINQc6KD73Mkkd4h5CjKHCNfDRoMVc5ZH39mYI3E7twj7ujzGGRzq728PxapoqLm0rZaG0IZkGn+a5DIiMsnesDvYipwp/TtXuw92llO99noRK4bXcajhRtkmcsBUeWXGGZ89JQTJhVRDSbXGxKh9nz6YLFPxadmSAp3uFgLcqt7snnLuY+bqVAgLEtYMrtF/7cnZDejrFs6VfAxx0KRsLJGohccXaIfPSknyIc42EqlQC+eld94e4j2XmyobOXlNp9/BcC4G9Uf1rlTwq6ucuj7qbJGHb0c52xQW3IE7LD9EEMconYBCxj4GdXyhAvb+KjIiJsK+m758slTHdtU2xtmFW1AbFuXnMIkooNo1xZwSdrVM5DIPGFUn0FJ7HB/B/sq8/Bt3/WwVajiSWqDBMpimqKZKb/hTce/1Ji3q4peSVFT9TG3tKY2QMt5F/nTPNF3HWlzUISnfp31ACiVVxquDPKGRkQJHGL3xL69CB0vEDGLIiy7QcO18uercprFSkH2gH4fPaVFlSr6B5LRmOWAGaq1UUm1KfJYJwWKLyvuzAEx6kMm+D X-Microsoft-Exchange-Diagnostics: 1; SN1PR08MB1469; 20:MxReZSuiysYc8YIpoA7ecHcshtkrcwwxWVRlI0QL5yZkpNhXTJ7+W0zeyxGSF7D/NYzYgKfK2hJeyPOuCTSuh2jnAhZ3lTbgahjlBqMZpU5fsy6OhRYAGP3ERs3zeZ5rYcFwv7gThvn/RczrGvjofUgIyxPjayfmWtLzlVCCNAHQXyeaIL966iF7JrJe0L8V9Fqr9F4EUjaScc0WqJPYGNOSvXGVTd6VrZ+DrATczPLn6X+zlc3E4YBXX9cT2S3AntS0WcFSGxJjS7Ga0CHxZe2/8CbLosd2PqpDy5lI0cXniQW4EmMgv4tBlPnbLYWhToXXoU0uRIucB8WpDtFrtlJtBhxMzr5Vj7g3Y5dof0y6m20UN4vwDvurc+tf2irD1QLKqXF8vCCUbIiax8D1ZX7g/UxkW9Uj460OeY5mR/h+Hc4Qe3YpeROS6w0/AMN0YWEkTrmHzBG98LDgnsIva/fePYRLKlkmJl1FGzZrtgbdKnnCNLx4RDoJZoQejFJT; 4:VUDmdzofE5hh9/nxfVS49q78st+v4GnC7htwsZm2gsTso914zkfhOYSE8w5qsddufTUyybfMWjKRj4JkodB92FDSrYqFLnWBN4c8kTnZSdjvZuvIbF8up25mM/7ZmxPlRyDfy4+7jBY1guD/ZgokG0wvF8vDZEp9ppjc0YpxICVdfc8KbQokXi8wsTHGk6DC3PwHr010VEBdwrt+E1N9f8mbmgFF9WYNwnuKqH9EtGk3RYEQ7SS6JwSarh64t9AvVu7A3EUe4GhIUw1kidhlqyDH9lXym6WJYsZdt9iiYMxuAbubkb4cRcp+KGLn2aK+1O1k2R1U/q6l7esC5+FktT8WYKHQc474jJeVe5zzmh7wfbiHMbH1piJ+C7Gqb6ON X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046); SRVR:SN1PR08MB1469; BCL:0; PCL:0; RULEID:; SRVR:SN1PR08MB1469; X-Forefront-PRVS: 0896BFCE6C X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(979002)(6049001)(66654002)(377454003)(43544003)(24454002)(252514010)(65816999)(50986999)(76176999)(54356999)(83506001)(2950100001)(15975445007)(77096005)(84326002)(19580405001)(92566002)(75432002)(36756003)(5008740100001)(19625215002)(33656002)(86362001)(81166005)(64126003)(93886004)(16236675004)(1096002)(586003)(2906002)(4326007)(88552002)(3846002)(6116002)(189998001)(5004730100002)(4001350100001)(19617315012)(117156001)(15974865002)(19580395003)(90282001)(66066001)(89122001)(42186005)(16601075003)(512874002)(65806001)(5001770100001)(65956001)(11771545001)(579004)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1PR08MB1469; H:[192.168.0.164]; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; SN1PR08MB1469; 23:lCGCKSCakt2jvOGUFxVC2XVuDYfbSIYvc8Dea1o8E?= =?us-ascii?Q?zoR6vALdkHg8Kf2jhvLjFVHd3rcr6aMnnqTkz2akfG7fizgTg7s9lDpLo7FA?= =?us-ascii?Q?NOAN7zYjEHfI00RincCzChKn5wz1tw7ZOqVLOZybOASrJkowpbvHlM8rwQ72?= =?us-ascii?Q?d7UH87rHvYUcEBbHkftpVrFs4KxXwKc8FLBWWwGi2gaXc35W1xw4/AeTXHfd?= =?us-ascii?Q?+hCPQ35atQ9iofkvEm1a4kfXL9N7WRkMJv7TKYZqhdo3TzDlC2+k0n+ZtM5w?= =?us-ascii?Q?cuZQOCyea3X2PsFt4ggVyPE7YT6XWILUq/ea6Ne01YGkDcn/SxbgUtiWy2qc?= =?us-ascii?Q?JTEku38Dy9dHVstGBfsHDpTMDG7kr0ZwWLoKTItadC/yqQpOz+XZmKyWv21l?= =?us-ascii?Q?SpVwiaH+xYnJuk8npxd8j+/ygHatdxWznBLOUhvCLgi6kDzld2z2fWSqbphu?= =?us-ascii?Q?9bYUwFk4poZZVqfIgOBuYE0q3b3J+wd5aIo6d3U0eK874pp2ELW/UImUembv?= =?us-ascii?Q?zZ0uBeGSzzwbAkbl0NE7iuo97aJpBBnGLgI5rAR1hJHs5DNrAayssGloBhq6?= =?us-ascii?Q?30bCqai1mOrJkQzgysrXYqjMpBTzs92apdbT1ojb+cOcO6qoWNsYKJTwKV9t?= =?us-ascii?Q?UBIacjqb8L+ngopYjDlEhpFh12SBn3RCsg749q3oiGe/y+zVLnDzs2PF0/lp?= =?us-ascii?Q?d0e5Jup+7MIQqO+o25qS75x5xEHMMN4fTYjbBdTenmYmNl8TNs/glxlY2x+R?= =?us-ascii?Q?z6uccaQViv46CFu+tkSwYqxbZ8DyLVBPaWcwRHL3Vdof+1k5k5G0DUWAG3qq?= =?us-ascii?Q?wE6nFGFlCDj/XMWF4RgFE0yWEiv934GmlHcmWEZUcw8sWMntImHKYRiAs+lJ?= =?us-ascii?Q?2hhtGb+8NKmclcSdbcSHX1hk+G/HmruM0sc41XqbAF7OA2CuPrNeC/fBiyu3?= =?us-ascii?Q?uNa8fJE3InxxK4gCe8L3QZsVqLm62SD3ZbeNSDvPjsISPh2P63ZB3Olf2hji?= =?us-ascii?Q?ccPulh5oJ2GIXqxKu/0hG0GtNsZx3mDwCtkYy8uYaEAHTCZ5K8wUgic4wAyi?= =?us-ascii?Q?UJ0RjcDRYv+0mj1PwztZHipzCGIBSsHHQqM6qVBwxSasbiXzs9XWXI+P948p?= =?us-ascii?Q?1CysuJ+AHxYkdeIW80cW9d6vwrpAaWY4JsO7ZKtpbe5NnIRJWwk71twwFeYL?= =?us-ascii?Q?UCe3VRNW2BztAa1cZRmgKkCnMTihsXzZUsZq9lIAqIck0iHkkOqjoKY5ZjGo?= =?us-ascii?Q?Qqjz+JChP1SY0xPruqy82V8TBT1pE4p2ydL1kBr09+pL3sJBYXW78T9B06pU?= =?us-ascii?Q?JEspQixkaIyT89FRcbl/Rlxbv2uMUH0/KOTVGJ0B5JGuXZgbpWvag+Ek93lw?= =?us-ascii?Q?ZQ1vGbyjZ7ljsXUeYwneaAlxW2JjRQ4f4KOzafMN5h6KoUaClMzQP+P1sf9u?= =?us-ascii?Q?6oSo+oNAqGGNsAZiVFPinPD0J5MwL/UPCAr3UbcWDm28dQliD52yFCJ0NL3Y?= =?us-ascii?Q?1+GmHVOrQDJ2A=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1; SN1PR08MB1469; 5:dCEFLZ7vN1b8pR+NoKz6du5EZxgFfJIN8UP3SXppt7bK1emwbyoOhnwfExYoZrWV+am7qPCUGTYxv8ENp5N9jv4icxYwRCR9DMYxYXCbVZsTmrKA03t9k/F74YVajjggUINom1raGoFjJ+gNCtG0rA==; 24:O7Y2unuTNesckWdXr84f7ar7GffPYCNuV+dpKq2YbjipcEmd0E1GgCV+PlB/odl9fIQP1XQwVOfP6XLJC7bn4q53pbiF9zbb7mxxuW8HDSU= SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: unl.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 29 Mar 2016 17:22:51.8237 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR08MB1469 Archived-At: Cc: tcpm@ietf.org Subject: Re: [tcpm] TCP friendly formulation in CUBIC-draft ? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 29 Mar 2016 17:40:18 -0000 --------------000802000609090305020405 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit Hello Karen, Sorry for the late reply. I see your questions now. You are right. Our goal is not to very accurately estimate the window size of reno, and we did not rigorously prove that our implementation has the same average as reno even in a short interval. Thanks Lisong On 3/21/2016 2:28 AM, Karen Elisabeth Egede Nielsen wrote: > > Hi Lisong, > > I am not opposed to what you’re doing. Just to make that absolutely > clear ! > > I also think that you achieve a larger average than Reno, which is > part of what you want for the RTT fairness generally of CUBIC. > > I don’t understand _/your argumentation/_ for the TCP friendliness > function though. Again I am not (necessarily) opposed to the function > itself, whether (1) or (2). > > It is the argumentation which isn’t clear. > > You take two functions (1) and (2) that have the same average > (integral) over a large domain and then apply them on _/a subset of > subset of the domain/_ > > and CUBIC in another subset of the domain. > > Have you proven that (1) and (2) have the same average in the subset > of the domain where they are applied (i.e. away from where CUBIC is > applied). Otherwise please change your argumentation to > > Better reflect exactly what you’re doing. > > Thanks. > > BR, Karen > > *From:*Lisong Xu [mailto:xu@unl.edu ] > *Sent:* 19. marts 2016 05:07 > *To:* Karen Elisabeth Egede Nielsen >; draft-ietf-tcpm-cubic@ietf.org > > *Cc:* tcpm@ietf.org > *Subject:* Re: TCP friendly formulation in CUBIC-draft ? > > Hi Karen, > > What we want is to make sure that the average window size is not less > than that of reno. We do not need the instantaneous reno window size > in each rtt, and thus what we want is not exactly (1). Both (1) and > (2) can be used to achieve what we want. But (2) is simpler to > implement, because (2) only considers the cwnd increase function > whereas (1) must consider both the cwnd increase function and the cwnd > decrease function (i.e., beta). > > Have a good weekend! > Lisong > > On 3/16/2016 3:10 AM, Karen Elisabeth Egede Nielsen wrote: > > HI Lisong, > > Thanks. > > Please see below. > > BR, Karen > > *From:*Lisong Xu [mailto:xu@unl.edu ] > *Sent:* 16. marts 2016 04:31 > *To:* Karen Elisabeth Egede Nielsen >; draft-ietf-tcpm-cubic@ietf.org > > *Cc:* tcpm@ietf.org > *Subject:* Re: TCP friendly formulation in CUBIC-draft ? > > On 3/15/2016 3:19 AM, Karen Elisabeth Egede Nielsen wrote: > > Hi Lisong, Neal, All, > > I understand the basic principle of the TCP friendliness > function and I have no problem > > with having the window follow TCP New Reno when the CUBIC > algorithm would return a smaller value. > > I.e., following section 1 of the draft: > > When the cubic > > function grows slower than the window of Standard TCP, > CUBIC simply > > follows the window size of Standard TCP to ensure fairness to > > Standard TCP in a small BDP network. > > With the disclaimer that I have not studied reference [FHP00] > I have, however, a problem understanding how this is achieved > > with formula (Eq. 4) of section 3.2 of draft-ietf-tcpm-cubic-01. > > From whatever in [FDP00] one get that the average window of > AIMD TCP CC is > > AVG_W_aimd = [ alpha_aimd * (1+beta_aimd) / > > (2*(1-beta_aimd)*p) ]^0.5 (eq. 3) > > which with alpha = 1 and beta = 0,5 indeed yields > AVG_W_Newreno = (1.5/p)^0.5.(Good otherwise we were in trouble). > > One can further observe from (3), of course, that generally > for AIMD CC with alpha equal to > > 3*(1-beta)/(1+beta) then one get the same average window as > of NewReno TCP. But how does it follow that > > W_aimd(t) = W_max*beta_aimd + > > [3*(1-beta_aimd)/(1+beta_aimd)] * (t/RTT) (Eq. 4) > > is a reasonable estimate for the window of standard TCP CC as > quoted as being the intention in section 1 ? > > > We can prove that Eq (4) has the same average window size as a > reno flow. > > */[Karen Elisabeth Egede Nielsen] Sure – I don’t doubt that./* > > QUESTION: > > Is (Eq. 4) the best implementation choice for comparison with > TCP New Reno that were manageable from an implementation > perspective or is (Eq 4) the rule that a CUBIC implementation > > should aim to follow ? I.e., that the Linux TCP implementation > aims to follow ? > > In the latter case, then I think one should probably use the > following formulation in Section 1: > > When the cubic > > function grows slower than the window of standard AIMD CC, > CUBIC simply > > follows the window size of standard AIMD CC to ensure > fairness to > > Standard TCP in a small BDP network. > > And then probably relate to that the fairness comes (?) from > calibration towards same average window - - - > > > There are two methods to get the average window size of a reno flow. > > 1. simulate a reno flow for each ack and each packet. but this > method requires more variables and more code to simulate reno. > > 2. use Eq (4) to directly calculate the average window size of a > reno flow. this method is much simpler than the first method, > because it does not need to simulate a reno flow. this is what > Cubic does. > > *//* > > */[Karen Elisabeth Egede Nielsen] You don’t use (Eq 4) to > calculate the average window. You use eq 4 – you say - because > this algorithm gives the same average window as New Reno and > therefore you say it is a valid approach./* > > *//* > > */From an implementation perspective I am not sure there is so > much difference, there is one namely the ramp down at FR, but > otherwise they need to do the same, just with a different alpha > (the beta_scale in Linux. Both needs to take care of > underutilization. /* > > *//* > > */[Karen Elisabeth Egede Nielsen] Yes – my question was whether > you wanted 1, but were doing 2 because of ease of implementation, > or whether you from a model perspective wanted to do 2./* > > */What I hear you saying is that you want 1, but is doing 2./* > > *//* > > */1 and 2 are really two different things – at least from a > theoretical perspective. Especially as you only use the > calculation on a fraction of the domain only. /* > > *//* > > */I think it should be obvious that 2 can give a higher CWND just > after FR, but also that the difference goes away over time (at > which point CUBIC then likely uses the CUBIC graph /**/J/**/)./* > > */On the other hand Eg 4 may be more modest generally – e.g. when > increasing from a non-validated window. Just thinking out load./* > > *//* > > */Have you experimented with to which extend 2 _significantly_ > differs from 1 – especially in conjunction with CUBIC ?/* > > *//* > > */I am not saying even that 2 is not the ideal approach – but it > need some more persuading to tell that it models New Reno well in > the way it is being used./* > > */[Karen Elisabeth Egede Nielsen] It had actually been simpler (I > think) if the argument was that you wanted 2 and then argue for > why this is reasonable fair with New Reno./* > > *//* > > */As said before, we are defining this for SCTP – let’s see - we > may experiment with both 1 and 2. /* > > */I have not understood (not tried to understand) what kind of > validation TCP Linux is running with when the cwnd is > underutilized (not cwnd limited). In SCTP there is no cwnd > increase during/* > > */cwnd underutilization, but not any cwnd decaying either. This > may give a difference in the overall resulting behavior of course./* > > Many Thanks. > > Lisong > > Thanks ! > > BR, Karen > > ******************************************************************************************* > > *Karen Egede **N**ielsen* > > Software Architect, Ph.D. > > *Tieto Denmark A/S* > > R&D, Telecom & Media > > Åhave Parkvej, 8260 Viby J, DK-Denmark > > Direct Phone / Mobile +45 25134336 > > E-mail: karen.nielsen@tieto.com > > ***************************************************************************************** > > www.tieto.com > > // > > /Please note: The information contained in this message may be > legally privileged and confidential and protected from > disclosure. If the reader of this message is not the intended > recipient, you are hereby notified that any unauthorised use, > distribution or copying of this communication is strictly > prohibited. If you have received this communication in error, > please notify us immediately by replying to the message and > deleting it from your computer. Thank You./ > --------------000802000609090305020405 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 8bit Hello Karen,

Sorry for the late reply. I see your questions now. You are right. Our goal is not to very accurately estimate the window size of reno, and we did not rigorously prove that our implementation has the same average as reno even in a short interval.

Thanks
Lisong

On 3/21/2016 2:28 AM, Karen Elisabeth Egede Nielsen wrote:

Hi Lisong,

 

I am not opposed to what you’re doing. Just to make that absolutely clear !

 

I also think that you achieve a larger average than Reno, which is part of what you want for the RTT fairness generally of CUBIC.

 

I don’t understand _your argumentation_ for the TCP friendliness function though.  Again I am not (necessarily) opposed to the function itself, whether (1) or (2).

It is the argumentation which isn’t clear.

You take two functions (1) and (2) that have the same average (integral) over a large domain and then apply them on _a subset of subset of the domain_

and CUBIC in another subset of the domain.

 

Have you proven that (1) and (2) have the same average in the subset of the domain where they are applied (i.e. away from where CUBIC is applied). Otherwise please change your argumentation to

Better reflect exactly what you’re doing.

 

Thanks.

 

BR, Karen

 

From: Lisong Xu [mailto:xu@unl.edu]
Sent: 19. marts 2016 05:07
To: Karen Elisabeth Egede Nielsen <karen.nielsen@tieto.com>; draft-ietf-tcpm-cubic@ietf.org
Cc: tcpm@ietf.org
Subject: Re: TCP friendly formulation in CUBIC-draft ?

 

Hi Karen,

What we want is to make sure that the average window size is not less than that of reno.  We do not need the instantaneous reno window size in each rtt, and thus what we want is not exactly (1). Both (1) and (2) can be used to achieve what we want. But (2) is simpler to implement, because (2) only considers the cwnd increase function whereas (1) must consider both the cwnd increase function and the cwnd decrease function (i.e., beta).

Have a good weekend!
Lisong

On 3/16/2016 3:10 AM, Karen Elisabeth Egede Nielsen wrote:

HI Lisong,

 

Thanks.

 

Please see below.

 

BR, Karen

 

From: Lisong Xu [mailto:xu@unl.edu]
Sent: 16. marts 2016 04:31
To: Karen Elisabeth Egede Nielsen <karen.nielsen@tieto.com>; draft-ietf-tcpm-cubic@ietf.org
Cc: tcpm@ietf.org
Subject: Re: TCP friendly formulation in CUBIC-draft ?

 

 

On 3/15/2016 3:19 AM, Karen Elisabeth Egede Nielsen wrote:

Hi Lisong, Neal, All,

 

I understand the basic principle of the TCP friendliness function and I have no problem

with having the window follow TCP New Reno when the CUBIC algorithm would return a smaller value.

I.e., following section 1 of the draft:

 

When the cubic

   function grows slower than the window of Standard TCP, CUBIC simply

   follows the window size of Standard TCP to ensure fairness to

   Standard TCP in a small BDP network.

 

 

With the disclaimer that I have not studied reference [FHP00] I have, however, a problem understanding how this is achieved

with formula (Eq. 4) of section 3.2 of draft-ietf-tcpm-cubic-01.

 

From whatever in [FDP00] one get that the average window of AIMD TCP CC is

 

       AVG_W_aimd = [ alpha_aimd * (1+beta_aimd) /

                      (2*(1-beta_aimd)*p) ]^0.5          (eq. 3)

 

 

which with alpha = 1 and beta = 0,5 indeed yields AVG_W_Newreno = (1.5/p)^0.5. (Good otherwise we were in trouble).
One can further observe from (3), of course,  that generally for AIMD CC with  alpha equal to

   3*(1-beta)/(1+beta) then one get the same average window as of NewReno TCP.  But how does it follow that

 

W_aimd(t) = W_max*beta_aimd +

                   [3*(1-beta_aimd)/(1+beta_aimd)] * (t/RTT) (Eq. 4)

 

is a reasonable estimate for the window of standard TCP CC as quoted as being the intention in section 1 ?


We can prove that Eq (4) has the same average window size as a reno flow.

[Karen Elisabeth Egede Nielsen] Sure – I don’t doubt that.

 

QUESTION:

Is (Eq. 4) the best implementation choice for comparison with TCP New Reno that were manageable from an implementation perspective or is (Eq 4) the rule that a CUBIC implementation

should aim to follow ? I.e., that the Linux TCP implementation aims to follow ?

 

In the latter case, then I think one should probably use the following formulation in Section 1:

 

When the cubic

   function grows slower than the window of standard AIMD CC, CUBIC simply

   follows the window size of standard AIMD CC to ensure fairness to

   Standard TCP in a small BDP network.

 

And then probably relate to that the fairness comes (?) from calibration towards same average window - - -

 


There are two methods to get the average window size of a reno flow.

1. simulate a reno flow for each ack and each packet. but this method requires more variables and more code to simulate reno.

2. use Eq (4) to directly calculate the average window size of a reno flow. this method is much simpler than the first method, because it does not need to simulate a reno flow. this is what Cubic does.

 

 

[Karen Elisabeth Egede Nielsen] You don’t use (Eq 4) to calculate the average window. You use eq 4 – you say - because this algorithm gives the same average window as New Reno and therefore you say it is a valid approach.

 

From an implementation perspective I am not sure there is so much difference, there is one namely the ramp down at FR, but otherwise they need to do the same, just with a different alpha (the beta_scale in Linux. Both needs to take care of underutilization.

 

[Karen Elisabeth Egede Nielsen] Yes – my question was whether you wanted 1, but were doing 2  because of ease of implementation, or whether you from a model perspective wanted to do 2.

What I hear you saying is that you want 1, but is doing 2.

 

1 and 2 are really two different things – at least from a theoretical perspective. Especially as you only use the calculation on a fraction of the domain only.

 

I think it should be obvious that 2 can give a higher CWND just after FR, but also that the difference goes away over time (at which point CUBIC then likely uses the CUBIC graph J).

On the other hand Eg 4 may be more modest generally – e.g. when increasing from a non-validated window. Just thinking out load.

 

Have you experimented with to which extend 2 _significantly_ differs from 1 – especially in conjunction with CUBIC ?

 

I am not saying even that 2 is not the ideal approach – but it need some more persuading to tell that it models New Reno well in the way it is being used.

 

[Karen Elisabeth Egede Nielsen] It had actually been simpler (I think) if the argument was that you wanted 2 and then argue for why this is reasonable fair with New Reno.

 

As said before, we are defining this for SCTP – let’s see  - we may experiment with both 1 and 2.

I have not understood (not tried to understand) what kind of validation TCP Linux is running with when the cwnd is underutilized (not cwnd limited). In SCTP there is no cwnd increase during

cwnd underutilization, but not any cwnd decaying either. This may give a difference in the overall resulting behavior of course.

 

Many Thanks.

Lisong

Thanks !

 

BR, Karen

 

*****************************************************************************************

Karen Egede Nielsen

Software Architect, Ph.D.

 

Tieto Denmark A/S

R&D, Telecom & Media

Ă…have Parkvej, 8260 Viby J, DK-Denmark

Direct Phone / Mobile +45 25134336

E-mail: karen.nielsen@tieto.com

*****************************************************************************************

www.tieto.com 

 

Please note: The information contained in this message may be legally privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, you are hereby notified that any unauthorised use, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank You.

 

 

 


--------------000802000609090305020405-- From nobody Wed Mar 30 01:47:25 2016 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 F2ACF12DF56 for ; Wed, 30 Mar 2016 01:47:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.69 X-Spam-Level: X-Spam-Status: No, score=-2.69 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, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=tieto.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 wS8ONKFViRhU for ; Wed, 30 Mar 2016 01:47:20 -0700 (PDT) Received: from mail-ig0-x231.google.com (mail-ig0-x231.google.com [IPv6:2607:f8b0:4001:c05::231]) (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 E255212DECA for ; Wed, 30 Mar 2016 01:47:07 -0700 (PDT) Received: by mail-ig0-x231.google.com with SMTP id ma7so57407573igc.0 for ; Wed, 30 Mar 2016 01:47:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tieto.com; s=google; h=from:references:in-reply-to:mime-version:thread-index:date :message-id:subject:to:cc; bh=wGskdYTrretOsOp/TZl0WMNpmmmkpY5VxD/ZaxNSPeI=; b=PglNIw0/wvVCCocgmLPsL1VTC0Gz62csJqzZGoTGfzT/eqfFaUGd50rm6EYGhxDfBn I/X6STui9xb+MyaO5KNQue/gdh081XPIponlInm4TVL7l4IL6lTr710CAqWozDl1wTcM U4KkctcgPVc0mZs0/m2+pX5uJGjEgh3W8ZGis= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:references:in-reply-to:mime-version :thread-index:date:message-id:subject:to:cc; bh=wGskdYTrretOsOp/TZl0WMNpmmmkpY5VxD/ZaxNSPeI=; b=Z7pcYf2e3cSLLq4Alv376OXGiESlshGA+MSvjc16JWwJxZB3JMc4rIuJIetxvnkxIL fEDRp9DtdaUBl238ZF1H+oHn3iuRXKynfJkx3yhxLNJmhHMVpLNap2XS/gBZnMfQn/Hu 48Mtyir/DtlAIQ3kYXieJ7IqbQoHd3RgtJwtJOwUkJdrnCulvWEgZ13Ysih0I56ub/sc QbKS5I00ml7ME7kQjRb0EwhyOJL+a7NVeWQD0iEOD4Qd+MHJmymMqF3IxPUeIWvZfgtb 3uzflkf5r/PeucQFNBgobrIRznGhM+ORcJeKTFKp40JBrtXGaejx++8FA7ILaEovq6gv hKeQ== X-Gm-Message-State: AD7BkJL8kZXfeVnhtmQMJ9t/gDi4h7g2m1m5ad/H8wkbtQOlvF0a/88oNAU/gH/V1wRe0EQ90Mdc6VWgrC2IgzG4o85yseH2tAM8AUeqTnuESMdY2UrXv2HED/CughwswhRiAew= X-Received: by 10.50.20.161 with SMTP id o1mr21043738ige.2.1459327626483; Wed, 30 Mar 2016 01:47:06 -0700 (PDT) From: Karen Elisabeth Egede Nielsen References: <28265_1458030005_u2F8K4us025832_bb0b000b861f2a1e54225a8662b87a69@mail.gmail.com> <56E8D363.2080801@unl.edu> <14035_1458115854_u2G8AskH024517_22021b5df9cac80a9d8c0ba9ea526ef4@mail.gmail.com> <56ECD07A.3010407@unl.edu> <56FABA13.30102@unl.edu> In-Reply-To: <56FABA13.30102@unl.edu> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQIbw19NaMpQgnr/3M9AdWgbjB7BugM9Fpq6AnWoUP4BZPwWCQH4X04GAdXMnMWehgI68A== Date: Wed, 30 Mar 2016 10:47:04 +0200 Message-ID: To: Lisong Xu , draft-ietf-tcpm-cubic@ietf.org Content-Type: multipart/alternative; boundary=047d7bd75708c9e172052f403094 X-DomainID: tieto.com Archived-At: Cc: tcpm@ietf.org Subject: Re: [tcpm] TCP friendly formulation in CUBIC-draft ? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 30 Mar 2016 08:47:24 -0000 --047d7bd75708c9e172052f403094 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable HI Lisong, Thank you. Thanks a lot for your support in understanding the function ! I am happy that we seem to have reached a common understanding. So what we have is an argumentation of the TCP friendliness function which follows (1): Make CUBIC CWND be no less than what TCP New Reno would give And an implementation of CUBIC TCP friendliness function which does: (2): Make CUBIC CWND be no less than what AIMD( 3*(1-beta)/(1+beta) , beta ) would give I think that it is substantially more straightforward to make a theoretical argumentation for why (1) is the right thing to do, than for why (2) is an appropriate thing to do. The theoretical arguments for (1) is in the CUBIC draft and in the CUBIC papers. Not knowing so much about this from a general research perspective, I wonder if there exists theoretical evidence for why (2) is appropriate or proper in respect of the argumentation of =E2=80=9CTCP friendliness=E2=80=9D. But also if one have a good understanding of the actual difference in between (1) and (2), then this may serve as input for such an argumentation= . Finally of course then safe deployment of (2)/CUBIC is another way to back the appropriateness of the function. BR, Karen *From:* Lisong Xu [mailto:xu@unl.edu] *Sent:* 29. marts 2016 19:24 *To:* Karen Elisabeth Egede Nielsen ; draft-ietf-tcpm-cubic@ietf.org *Cc:* tcpm@ietf.org *Subject:* Re: TCP friendly formulation in CUBIC-draft ? Hello Karen, Sorry for the late reply. I see your questions now. You are right. Our goal is not to very accurately estimate the window size of reno, and we did not rigorously prove that our implementation has the same average as reno even in a short interval. Thanks Lisong On 3/21/2016 2:28 AM, Karen Elisabeth Egede Nielsen wrote: Hi Lisong, I am not opposed to what you=E2=80=99re doing. Just to make that absolutely= clear ! I also think that you achieve a larger average than Reno, which is part of what you want for the RTT fairness generally of CUBIC. I don=E2=80=99t understand _*your argumentation*_ for the TCP friendliness = function though. Again I am not (necessarily) opposed to the function itself, whether (1) or (2). It is the argumentation which isn=E2=80=99t clear. You take two functions (1) and (2) that have the same average (integral) over a large domain and then apply them on _*a subset of subset of the domain*_ and CUBIC in another subset of the domain. Have you proven that (1) and (2) have the same average in the subset of the domain where they are applied (i.e. away from where CUBIC is applied). Otherwise please change your argumentation to Better reflect exactly what you=E2=80=99re doing. Thanks. BR, Karen *From:* Lisong Xu [mailto:xu@unl.edu] *Sent:* 19. marts 2016 05:07 *To:* Karen Elisabeth Egede Nielsen ; draft-ietf-tcpm-cubic@ietf.org *Cc:* tcpm@ietf.org *Subject:* Re: TCP friendly formulation in CUBIC-draft ? Hi Karen, What we want is to make sure that the average window size is not less than that of reno. We do not need the instantaneous reno window size in each rtt, and thus what we want is not exactly (1). Both (1) and (2) can be used to achieve what we want. But (2) is simpler to implement, because (2) only considers the cwnd increase function whereas (1) must consider both the cwnd increase function and the cwnd decrease function (i.e., beta). Have a good weekend! Lisong On 3/16/2016 3:10 AM, Karen Elisabeth Egede Nielsen wrote: HI Lisong, Thanks. Please see below. BR, Karen *From:* Lisong Xu [mailto:xu@unl.edu] *Sent:* 16. marts 2016 04:31 *To:* Karen Elisabeth Egede Nielsen ; draft-ietf-tcpm-cubic@ietf.org *Cc:* tcpm@ietf.org *Subject:* Re: TCP friendly formulation in CUBIC-draft ? On 3/15/2016 3:19 AM, Karen Elisabeth Egede Nielsen wrote: Hi Lisong, Neal, All, I understand the basic principle of the TCP friendliness function and I have no problem with having the window follow TCP New Reno when the CUBIC algorithm would return a smaller value. I.e., following section 1 of the draft: When the cubic function grows slower than the window of Standard TCP, CUBIC simply follows the window size of Standard TCP to ensure fairness to Standard TCP in a small BDP network. With the disclaimer that I have not studied reference [FHP00] I have, however, a problem understanding how this is achieved with formula (Eq. 4) of section 3.2 of draft-ietf-tcpm-cubic-01. >From whatever in [FDP00] one get that the average window of AIMD TCP CC is AVG_W_aimd =3D [ alpha_aimd * (1+beta_aimd) / (2*(1-beta_aimd)*p) ]^0.5 (eq. 3) which with alpha =3D 1 and beta =3D 0,5 indeed yields AVG_W_Newreno =3D (1.5/p)^0.5. (Good otherwise we were in trouble). One can further observe from (3), of course, that generally for AIMD CC with alpha equal to 3*(1-beta)/(1+beta) then one get the same average window as of NewReno TCP. But how does it follow that W_aimd(t) =3D W_max*beta_aimd + [3*(1-beta_aimd)/(1+beta_aimd)] * (t/RTT) (Eq. 4) is a reasonable estimate for the window of standard TCP CC as quoted as being the intention in section 1 ? We can prove that Eq (4) has the same average window size as a reno flow. *[Karen Elisabeth Egede Nielsen] Sure =E2=80=93 I don=E2=80=99t doubt that.= * QUESTION: Is (Eq. 4) the best implementation choice for comparison with TCP New Reno that were manageable from an implementation perspective or is (Eq 4) the rule that a CUBIC implementation should aim to follow ? I.e., that the Linux TCP implementation aims to follow ? In the latter case, then I think one should probably use the following formulation in Section 1: When the cubic function grows slower than the window of standard AIMD CC, CUBIC simply follows the window size of standard AIMD CC to ensure fairness to Standard TCP in a small BDP network. And then probably relate to that the fairness comes (?) from calibration towards same average window - - - There are two methods to get the average window size of a reno flow. 1. simulate a reno flow for each ack and each packet. but this method requires more variables and more code to simulate reno. 2. use Eq (4) to directly calculate the average window size of a reno flow. this method is much simpler than the first method, because it does not need to simulate a reno flow. this is what Cubic does. *[Karen Elisabeth Egede Nielsen] You don=E2=80=99t use (Eq 4) to calculate = the average window. You use eq 4 =E2=80=93 you say - because this algorithm giv= es the same average window as New Reno and therefore you say it is a valid approach.* *From an implementation perspective I am not sure there is so much difference, there is one namely the ramp down at FR, but otherwise they need to do the same, just with a different alpha (the beta_scale in Linux. Both needs to take care of underutilization. * *[Karen Elisabeth Egede Nielsen] Yes =E2=80=93 my question was whether you = wanted 1, but were doing 2 because of ease of implementation, or whether you from a model perspective wanted to do 2.* *What I hear you saying is that you want 1, but is doing 2.* *1 and 2 are really two different things =E2=80=93 at least from a theoreti= cal perspective. Especially as you only use the calculation on a fraction of the domain only. * *I think it should be obvious that 2 can give a higher CWND just after FR, but also that the difference goes away over time (at which point CUBIC then likely uses the CUBIC graph **J**).* *On the other hand Eg 4 may be more modest generally =E2=80=93 e.g. when in= creasing from a non-validated window. Just thinking out load.* *Have you experimented with to which extend 2 _significantly_ differs from 1 =E2=80=93 especially in conjunction with CUBIC ?* *I am not saying even that 2 is not the ideal approach =E2=80=93 but it nee= d some more persuading to tell that it models New Reno well in the way it is being used.* *[Karen Elisabeth Egede Nielsen] It had actually been simpler (I think) if the argument was that you wanted 2 and then argue for why this is reasonable fair with New Reno.* *As said before, we are defining this for SCTP =E2=80=93 let=E2=80=99s see = - we may experiment with both 1 and 2. * *I have not understood (not tried to understand) what kind of validation TCP Linux is running with when the cwnd is underutilized (not cwnd limited). In SCTP there is no cwnd increase during* *cwnd underutilization, but not any cwnd decaying either. This may give a difference in the overall resulting behavior of course.* Many Thanks. Lisong Thanks ! BR, Karen ***************************************************************************= **************** *Karen Egede **N**ielsen* Software Architect, Ph.D. *Tieto Denmark A/S* R&D, Telecom & Media =C3=85have Parkvej, 8260 Viby J, DK-Denmark Direct Phone / Mobile +45 25134336 E-mail: karen.nielsen@tieto.com ***************************************************************************= ************** www.tieto.com *Please note: The information contained in this message may be legally privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, you are hereby notified that any unauthorised use, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank You.* --047d7bd75708c9e172052f403094 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hi Lisong,

=C2=A0

I am not oppose= d to what you=E2=80=99re doing. Just to make that absolutely clear !=

=C2= =A0

I also think that you achieve a larger average than Reno, which is p= art of what you want for the RTT fairness generally of CUBIC.

=C2=A0

= I don=E2=80=99t understand _your argumentation_ for the TCP friendli= ness function though.=C2=A0 Again I am not (necessarily) opposed to the fun= ction itself, whether (1) or (2).

It is the argumentation which isn=E2= =80=99t clear.

You take two functions (1) and (2) that have the same av= erage (integral) over a large domain and then apply them on _a subset of= subset of the domain_

and CUBIC in another subset of the domain.

=C2=A0

Have you proven that (1) and (2) have the same average in the s= ubset of the domain where they are applied (i.e. away from where CUBIC is a= pplied). Otherwise please change your argumentation to

Better reflect = exactly what you=E2=80=99re doing.

=C2=A0

Thanks.

=C2=A0

BR, K= aren

=C2=A0

From: Lisong Xu [mailto:xu@unl.edu]
Sent: 19. marts 2016 05:07
To:= Karen Elisabeth Egede Nielsen <karen.nielsen@tieto.com>; draft-ietf-tcpm-cubic@ietf.org
Cc: tcpm@ietf.org
Subject: Re: TCP friendly for= mulation in CUBIC-draft ?

=C2= =A0

Hi Karen,
<= br>What we want is to make sure that the average window size is not less th= an that of reno.=C2=A0 We do not need the instantaneous reno window size in= each rtt, and thus what we want is not exactly (1). Both (1) and (2) can b= e used to achieve what we want. But (2) is simpler to implement, because (2= ) only considers the cwnd increase function whereas (1) must consider both = the cwnd increase function and the cwnd decrease function (i.e., beta).
Have a good weekend!
Lisong=

On 3/16/2016 3:10 AM, Karen Elisabeth Egede= Nielsen wrote:

HI Lisong,

=C2=A0<= /p>

Thanks.

<= p class=3D"MsoNormal">=C2=A0

Please see below.

=

=C2=A0

BR, Karen

=C2=A0

From: = Lisong Xu [mailto:xu@unl.edu]
Sent= : 16. marts 2016 04:31
To: Karen Elisabeth Egede Nielsen <= karen.nielsen@tieto.com>;= draft-ietf-tcpm-cubic@ie= tf.org
Cc: tcpm@ietf.org=
Subject: Re: TCP friendly formulation in CUBIC-draft ?

=C2=A0

=C2=A0

On 3/15/2016 3:19 AM, Karen Elisabeth Egede Ni= elsen wrote:

Hi Lisong, Neal, All,

=C2=A0

I understand the basic principle of th= e TCP friendliness function and I have no problem

with having the window follow TCP New Reno wh= en the CUBIC algorithm would return a smaller value.

I.e., following section 1 of the draft:

=C2=A0

When the cubic<= /span>

=C2=A0=C2=A0 follows the window size of Standard TCP to ensure fa= irness to

=C2=A0=C2=A0 Standard TCP in a small BDP network.

=C2=A0

=C2=A0

With the disclaimer that I have not studied reference [FHP00] = I have, however, a problem understanding how this is achieved

with formula (Eq. 4) of section 3.= 2 of draft-ietf-tcpm-cubic-01.

=C2=A0

Fro= m whatever in [FDP00] one get that the average window of AIMD TCP CC is

=C2=A0

=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 AVG_W_aimd =3D [ alpha_aimd * (1+beta_aimd) /<= /p>

=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0(2*(1-beta_aimd)*p) ]^0.= 5=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (eq. 3)

<= p class=3D"MsoNormal" style=3D"page-break-before:always">=C2=A0

= =C2=A0

which with alpha =3D 1 and beta =3D 0,5 indeed yields AVG_W_Newreno =3D =
(1.5/p)^0.5. (Good other=
wise we were in trouble).
One can further observe from (3), of course, =C2=A0that =
generally for AIMD CC with =C2=A0alpha equal to

=C2=A0=C2= =A0 3*(1-beta)/(1+beta) then one get the same average window as of NewReno = TCP.=C2=A0 But how does it follow that

=C2=A0

W_aimd(t) =3D W_max*beta_aimd +

=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 [3*(1-beta_aimd)/(1+beta_aimd)] * (t/RTT) (Eq. 4)

=C2=A0

is = a reasonable estimate for the window of standard TCP CC as quoted as being = the intention in section 1 ?


We can prove that Eq (4) has = the same average window size as a reno flow.

[Karen Elisabeth Egede Nielsen] Sure = =E2=80=93 I don=E2=80=99t doubt that.

=C2=A0

QUE= STION:

Is (Eq. 4) the= best implementation choice for comparison with TCP New Reno that were mana= geable from an implementation perspective or is (Eq 4) the rule that a CUBI= C implementation

shou= ld aim to follow ? I.e., that the Linux TCP implementation aims to follow ?=

=C2=A0

In the latter case, then I think o= ne should probably use the following formulation in Section 1:

=C2=A0

When the cubic

=C2=A0= =C2=A0 function grows slower than the window of standard AIMD CC, CUBIC sim= ply

=C2=A0=C2=A0 follows the window size of standard AIMD CC to ensure fa= irness to

=C2=A0=C2=A0 Standard TCP in a small BDP network.

=C2=A0

And then probably relate to that the fairness comes (?) from cal= ibration towards same average window - - -

=C2=A0


There are two methods to get the average window size of a r= eno flow.

1. simulate a reno flow for each ack and each packet. but = this method requires more variables and more code to simulate reno.

= 2. use Eq (4) to directly calculate the average window size of a reno flow.= this method is much simpler than the first method, because it does not nee= d to simulate a reno flow. this is what Cubic does.

=C2=A0

=C2= =A0

[Karen Elisabeth Egede Nielsen] You don=E2=80=99t use = (Eq 4) to calculate the average window. You use eq 4 =E2=80=93 you say - be= cause this algorithm gives the same average window as New Reno and therefor= e you say it is a valid approach.

= =C2=A0

= >From an implementation perspective I am not sure there is so much differenc= e, there is one namely the ramp down at FR, but otherwise they need to do t= he same, just with a different alpha (the beta_scale in Linux. Both needs t= o take care of underutilization.

= =C2=A0

= [Karen Elisabeth Egede Nielsen] Yes =E2=80=93 my question was whether you w= anted 1, but were doing 2 =C2=A0because of ease of implementation, or wheth= er you from a model perspective wanted to do 2.

What I he= ar you saying is that you want 1, but is doing 2.

=C2=A0

1 and 2 are really two different things =E2=80=93 at least = from a theoretical perspective. Especially as you only use the calculation = on a fraction of the domain only.

=C2=A0

I think it should be obvious that 2 can give a higher CWND just after FR, = but also that the difference goes away over time (at which point CUBIC then= likely uses the CUBIC graph J).

On the other hand Eg= 4 may be more modest generally =E2=80=93 e.g. when increasing from a non-v= alidated window. Just thinking out load.

=C2=A0=

Have you experimented with to which extend 2 _significantly_ differs= from 1 =E2=80=93 especially in conjunction with CUBIC ?

=

= =C2=A0

I am not saying even that 2 is not the ideal approa= ch =E2=80=93 but it need some more persuading to tell that it models New Re= no well in the way it is being used.

=C2=A0

[Karen El= isabeth Egede Nielsen] It had actually been simpler (I think) if the argume= nt was that you wanted 2 and then argue for why this is reasonable fair wit= h New Reno.

=C2=A0

As said before, we are= defining this for SCTP =E2=80=93 let=E2=80=99s see=C2=A0 - we may experime= nt with both 1 and 2.

I have not understood (not tried to= understand) what kind of validation TCP Linux is running with when the cwn= d is underutilized (not cwnd limited). In SCTP there is no cwnd increase du= ring

cwnd underutilization, but not any cwnd decaying eith= er. This may give a difference in the overall resulting behavior of course.=

=C2=A0

Many Thanks.

Lisong

Thanks !

=C2=A0

BR, Karen<= /span>

=C2=A0

******************************************************************= ***********************

Karen Egede <= b>= Nielsen

Software Archite= ct, Ph.D.

=C2=A0

Tieto Denmark= A/S

R&D, Telecom & Media

=C3=85have Parkvej, 8260 Viby J, DK-Denmark

Direct P= hone / Mobile +45 25134336

E-mail: karen.nielsen@tieto.com

*******= ***************************************************************************= *******

www.tieto.com<= /a>=C2=A0

=C2=A0

Please = note: The information contained in this message may be legally privileged a= nd confidential and protected from disclosure. If the reader of this messag= e is not the intended recipient, you are hereby notified that any unauthori= sed use, distribution or copying of this communication is strictly prohibit= ed. If you have received this communication in error, please notify us imme= diately by replying to the message and deleting it from your computer. Than= k You.

=C2=A0

=C2=A0

=C2=A0

HI Lisong,

=C2=A0

Thank you.

=C2=A0

Thanks a lot for your support in understanding the f= unction !

I am happy that we seem to have reached a common understanding= .

=C2=A0

So what we have is an argumentation of the TCP friendliness = function which follows

(1): Make CUBIC CWND be no less than what TCP Ne= w Reno would give

=C2=A0

And an implementation of CUBIC TCP friendlin= ess function which does:

(2): Make CUBIC CWND be no less than what AIMD(= =C2=A03*(1-beta)/(1+beta) , beta ) would give

=C2=A0

I think tha= t it is substantially more straightforward to make a theoretical argumentat= ion for why (1) is the right thing to do, than for why (2) is an appropriat= e thing to do.

The theoretical arguments for (1) is in the CUBIC draft = and in the CUBIC papers.

=C2=A0

Not knowing so much about this from a= general research perspective, I wonder if there exists theoretical evidenc= e

for why (2) is appropriate or proper in respect of the argumentation = of =E2=80=9CTCP friendliness=E2=80=9D.

But also if one have a good under= standing of the actual difference in between (1) and (2), then this may ser= ve as input for such an argumentation.

Finally of course then safe deplo= yment of (2)/CUBIC is another way to back the appropriateness of the functi= on.

=C2=A0

BR, Karen

=C2=A0

=C2=A0

From: Lisong= Xu [mailto:xu@unl.edu]
Sent: = 29. marts 2016 19:24
To: Karen Elisabeth Egede Nielsen <karen.nielsen@tieto.com>; draft-ietf-tcpm-cubic@ietf.org=
Cc: tcpm@ietf.org
Subject: Re: TCP friendly formulation in CUBIC-draft ?

=C2=A0

Hello Karen,

Sorry for the late reply. I see your= questions now. You are right. Our goal is not to very accurately estimate = the window size of reno, and we did not rigorously prove that our implement= ation has the same average as reno even in a short interval.

Thanks<= br>Lisong

On 3/21/2016 2:28 AM, Karen Elisabeth Egede Nielsen wrote:

<= blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt">

Hi Lisong,

=C2=A0

= I am not opposed to what you=E2=80=99re doing. Just to make that absolutely= clear !

=C2=A0

I also think that you achieve a larger average than R= eno, which is part of what you want for the RTT fairness generally of CUBIC= .

=C2=A0

I don=E2=80=99t understand _your argumentation_ for t= he TCP friendliness function though.=C2=A0 Again I am not (necessarily) opp= osed to the function itself, whether (1) or (2).

It is the argumentation= which isn=E2=80=99t clear.

You take two functions (1) and (2) that have= the same average (integral) over a large domain and then apply them on _a subset of subset of the domain_

and CUBIC in another subset of t= he domain.

=C2=A0

Have you proven that (1) and (2) have the same aver= age in the subset of the domain where they are applied (i.e. away from wher= e CUBIC is applied). Otherwise please change your argumentation to <= /p>

Bett= er reflect exactly what you=E2=80=99re doing.

=C2=A0

Thanks.<= /p>

=C2= =A0

BR, Karen

=C2=A0

From: Lisong Xu [mailto:xu@unl.edu]
Sent: 19. marts 2016 05:07To: Karen Elisabeth Egede Nielsen <karen.nielsen@tieto.com>; draft-ietf-tcpm-cubic@ietf.org
Cc: tcpm@ietf.org
Subject: Re: TCP = friendly formulation in CUBIC-draft ?

=C2=A0

Hi = Karen,

What we want is to make sure that the average window size is = not less than that of reno.=C2=A0 We do not need the instantaneous reno win= dow size in each rtt, and thus what we want is not exactly (1). Both (1) an= d (2) can be used to achieve what we want. But (2) is simpler to implement,= because (2) only considers the cwnd increase function whereas (1) must con= sider both the cwnd increase function and the cwnd decrease function (i.e.,= beta).

Have a good weekend!
Lisong

On 3/16/2016 3:10 AM, Karen Elisabeth Egede Nielsen wrote:

HI Lisong,

=C2=A0

Thanks.

=C2=A0

Please see below.

=C2=A0

BR, Karen

=C2=A0

From: Lisong Xu [mailto:xu@unl.edu]
Sent: 16. marts 2016 04:31To: Karen Elisabeth Egede Nielsen <karen.nielsen@tieto.com>; draft-ietf-tcpm-cubic@ietf.org
Cc: tcpm@ietf.org
Subject: Re: TCP f= riendly formulation in CUBIC-draft ?

=C2=A0

=C2=A0

O= n 3/15/2016 3:19 AM, Karen Elisabeth Egede Nielsen wrote:

<= span lang=3D"EN-US">Hi Lisong, Neal, All,

= =C2=A0

I understand the basic principle of the TCP friendliness function an= d I have no problem

= with having the window follow TCP New Reno when the CUBIC algorithm would r= eturn a smaller value.

I.e., following section 1 of the draft:

= =C2=A0

When the cubic

=C2=A0=C2=A0 fun= ction grows slower than the window of Standard TCP, CUBIC simply

=

= =C2=A0=C2=A0 follows the window size of Standard TCP to ensure fairness to<= /span>

=C2=A0=C2=A0 Standard TCP in a small BDP network.

=C2=A0

=C2=A0

With the disclaimer that I have not studied reference [FHP00] I = have, however, a problem understanding how this is achieved

with formula (Eq. 4) of section 3.2 = of draft-ietf-tcpm-cubic-01.

=C2=A0

From w= hatever in [FDP00] one get that the average window of AIMD TCP CC is=

=C2=A0

=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 AVG_W_aimd =3D [ alpha_aimd * (1+beta_aimd) /

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0(2*(1-beta_aimd= )*p) ]^0.5=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (eq. 3)

=C2=A0

=C2=A0

which with alpha =3D 1 and beta =3D 0,5 indeed yiel=
ds AVG_W_Newreno =3D (1.5/p)^0.5. (Good otherwise we were in trouble).
One can further observe from (3), =
of course, =C2=A0that generally for AIMD CC with =C2=A0alpha equal to

=C2=A0=C2=A0 3*(1-beta)/(1+beta) then one get the same average w= indow as of NewReno TCP.=C2=A0 But how does it follow that

=C2=A0

W_aimd(t) =3D W_max*be= ta_aimd +

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 [3*(1-beta_aimd)/(1+bet= a_aimd)] * (t/RTT) (Eq. 4)

=C2=A0

is a reasonable estimate for the window of stand= ard TCP CC as quoted as being the intention in section 1 ?


We can= prove that Eq (4) has the same average window size as a reno flow.

= [Karen Elisabe= th Egede Nielsen] Sure =E2=80=93 I don=E2=80=99t doubt that.=

=C2=A0

QUESTION:

Is (Eq. 4) the best implementation choice for comparison with TCP Ne= w Reno that were manageable from an implementation perspective or is (Eq 4)= the rule that a CUBIC implementation

should aim to follow ? I.e., that the Linux TCP implementa= tion aims to follow ?

=C2=A0

In the latter= case, then I think one should probably use the following formulation in Se= ction 1:

=C2=A0

When the cubic

=C2=A0=C2=A0 function grows slower than the win= dow of standard AIMD CC, CUBIC simply

=C2=A0=C2=A0 follows the wind= ow size of standard AIMD CC to ensure fairness to

=C2=A0=C2=A0 Stan= dard TCP in a small BDP network.

=C2=A0

And then pro= bably relate to that the fairness comes (?) from calibration towards same a= verage window - - -

= =C2=A0


There are two = methods to get the average window size of a reno flow.

1. simulate a= reno flow for each ack and each packet. but this method requires more vari= ables and more code to simulate reno.

2. use Eq (4) to directly calc= ulate the average window size of a reno flow. this method is much simpler t= han the first method, because it does not need to simulate a reno flow. thi= s is what Cubic does.

=C2=A0

=C2=A0

[Karen El= isabeth Egede Nielsen] You don=E2=80=99t use (Eq 4) to calculate the averag= e window. You use eq 4 =E2=80=93 you say - because this algorithm gives the= same average window as New Reno and therefore you say it is a valid approa= ch.

=C2=A0

= From an implementation perspec= tive I am not sure there is so much difference, there is one namely the ram= p down at FR, but otherwise they need to do the same, just with a different= alpha (the beta_scale in Linux. Both needs to take care of underutilizatio= n.

=C2=A0

= [Karen Elisabeth Egede Nielsen= ] Yes =E2=80=93 my question was whether you wanted 1, but were doing 2 =C2= =A0because of ease of implementation, or whether you from a model perspecti= ve wanted to do 2.

What I hear you saying is that you want= 1, but is doing 2.

=C2=A0

1 and 2 are re= ally two different things =E2=80=93 at least from a theoretical perspective= . Especially as you only use the calculation on a fraction of the domain on= ly.

=C2=A0

I think it should be obvious = that 2 can give a higher CWND just after FR, but also that the difference g= oes away over time (at which point CUBIC then likely uses the CUBIC graph <= /span>J).

On the other hand Eg 4 may be more modest generally= =E2=80=93 e.g. when increasing from a non-validated window. Just thinking = out load.

=C2=A0

= Have you experimented wi= th to which extend 2 _significantly_ differs from 1 =E2=80=93 especially in= conjunction with CUBIC ?

=C2=A0

I am not= saying even that 2 is not the ideal approach =E2=80=93 but it need some mo= re persuading to tell that it models New Reno well in the way it is being u= sed.

=C2=A0

[Karen Elisabeth Egede Nielsen] It had actu= ally been simpler (I think) if the argument was that you wanted 2 and then = argue for why this is reasonable fair with New Reno.

=C2= =A0

As said before, we are defining this for SCTP =E2=80= =93 let=E2=80=99s see=C2=A0 - we may experiment with both 1 and 2. <= /i>

I have not understood (not tried to understand) what kind of vali= dation TCP Linux is running with when the cwnd is underutilized (not cwnd l= imited). In SCTP there is no cwnd increase during

cwnd und= erutilization, but not any cwnd decaying either. This may give a difference= in the overall resulting behavior of course.

=C2=A0

Many Thanks.
Lisong

Thanks !

=C2=A0

BR, Karen

=C2=A0

**********************************= *******************************************************

Karen Egede Nielsen=

Software Architect, Ph.D.

=C2=A0

Tieto Denmark A/S

R&D, Tele= com & Media

=C3=85have Parkvej, 8260 Viby J, DK-Den= mark

Direct Phone / Mobile +45 25134336

E-mail: karen.nielsen@tieto.co= m

*************************************************= ****************************************

www.tieto.com=C2=A0

=C2=A0<= /span>

Please note: The information contained in this m= essage may be legally privileged and confidential and protected from disclo= sure. If the reader of this message is not the intended recipient, you are = hereby notified that any unauthorised use, distribution or copying of this = communication is strictly prohibited. If you have received this communicati= on in error, please notify us immediately by replying to the message and de= leting it from your computer. Thank You.

=C2=A0

=C2=A0

=C2=A0

=C2=A0

--047d7bd75708c9e172052f403094-- From nobody Wed Mar 30 07:15:11 2016 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 C19FA12D68A; Wed, 30 Mar 2016 07:15:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=uofnelincoln.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 ng7YusYMkKZ1; Wed, 30 Mar 2016 07:15:07 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0142.outbound.protection.outlook.com [207.46.163.142]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2DF812D577; Wed, 30 Mar 2016 07:15:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uofnelincoln.onmicrosoft.com; s=selector1-unl-edu; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Wi0KFjxrIc1lxEuEfGmZAXiaFPmaWCUQo7wYhPAg84s=; b=GMqugTi7pFmTGpKIe9XUuC2lq7YprhD6j9oTxVaw3cUsBbv8ok+4hleYySXebMSiMQuhd4jywlg4oQr9yojNvGEw3YFsoHBje1ksAZ7KH6yhSCjanpshKPUswA7pObtmdfHBWzNJ9smrovpcNO0hOX7oBktrsGlc3Oorhl64hVM= Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=unl.edu; Received: from [10.211.131.94] (129.93.4.24) by DM2PR08MB1465.namprd08.prod.outlook.com (10.161.144.15) with Microsoft SMTP Server (TLS) id 15.1.434.16; Wed, 30 Mar 2016 14:15:04 +0000 To: Karen Elisabeth Egede Nielsen , References: <28265_1458030005_u2F8K4us025832_bb0b000b861f2a1e54225a8662b87a69@mail.gmail.com> <56E8D363.2080801@unl.edu> <14035_1458115854_u2G8AskH024517_22021b5df9cac80a9d8c0ba9ea526ef4@mail.gmail.com> <56ECD07A.3010407@unl.edu> <56FABA13.30102@unl.edu> <12368_1459328224_u2U8v3nZ025730_e84025e79d2ea1449205fe7a7b7c1059@mail.gmail.com> From: Lisong Xu Organization: University of Nebraska-Lincoln Message-ID: <56FBDF8F.1010805@unl.edu> Date: Wed, 30 Mar 2016 09:15:43 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <12368_1459328224_u2U8v3nZ025730_e84025e79d2ea1449205fe7a7b7c1059@mail.gmail.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [129.93.4.24] X-ClientProxiedBy: CY1PR0601CA0020.namprd06.prod.outlook.com (25.160.162.30) To DM2PR08MB1465.namprd08.prod.outlook.com (25.161.144.15) X-MS-Office365-Filtering-Correlation-Id: f49062c9-8efb-4e43-8a04-08d358a5b0e3 X-Microsoft-Exchange-Diagnostics: 1; DM2PR08MB1465; 2:WRHPXLwF0Lfo5KE4yq83HmLtzTpvU9qGeHPRZy97qPvVbUYldgf0wjsuc4eBAxlM6nNHcRF0AJt+z/yEzIZqnLSrTXuePE4Jkg/+HtyTnSBQBIxc6mPhKc0eCT3nVApuNKThJSvYWsDC9XALYqmHC6qPAxfZV526R6W7DceE9Mq3iyudoGst1C/pSf5zxTkB; 3:ZTb1cn2OltqPtV2WGuG5Q9TVJbAp4QfVY3wVjxB8OGIuyDFYtM0CIvSB3hP7iwpfhmTUOgSzjvHlezepzoyrzOJtzjIuT9+Ud1NiAtQWxuR+8/8TNvL1qAy3gYSp6/m6; 25:y3umeyaLTcQSVIFRCl6MpbpcRxPAPY+sX0BGyuo50gOB2C1x9ltS1TW+1C03k6Lp3yRjRHLQKaMuaHfECKNKl1EVWQDtAlsp2ffdUuXtXZfc7GEM50i8G8df/WszsRf6pPS2uAts/gvgkjJzE0zaIJM5WhqiiiyD/OT1e0lNRyhtJvNwXfKB9XRtkcOQJQQtZ6frGF7CuzlCc3fov7CtkCKV1fLUZv39djoFKdqOJb2FxS5jgYbxBRSHnJVKvAc/M7Huk0K9Tsqp2kuR9D1TTWdyYQVaJ+K2QwmxPimqDbC0bvhs3HqAv8iRFXs0lVaFsnYNSBRF8p8CeoWLlzuIFm4nI9X6Eatth7zL9JvYSPRBW/D4ePd/T9F/E+f4aomIDcrmuNuiwMW77gjUW3N1fbIXOd8ZfDKgRzvMUjHacZKkIEBpL1jr1gpzqkDWB9U+hQ8SYq3VSvySm4HIFypKQtv0RJyTGl7kgR52j5fy+SwQMR2tnZKUmo7m8//c9+P92/yWCFPaW/Nt8/fXpLsWKT5KHvqqKtc8yDzGtbshwZtuL3eoj7opN/xVPRhBTDVH X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR08MB1465; X-Microsoft-Exchange-Diagnostics: 1; DM2PR08MB1465; 20:tROYmAseYhxqVwwK8FTKsXrm666v+6FwN8lLTCjcXooAWSz0MImPJre+usXjtcsfeV4iR7euJe7KeWJ3q8V/1cC7I8y30Ogwti4GuhlvOtstq6DlIzChry9ahZe4WOAV5Y6kUwKcd2UuGugQJ6p9y5L16MFRaho+HX5bZwcZXrdmwII4WifUbjIR8KOn4A8mrk1puc6tMRhO5ug97m9Xm5jGRSlTUMvDOLtG3mm59blz1FCfNe/5zSRvHwQxWbaDHpQVmxoiYwdrcykykuBbFN0TClRVZLdh9qevUnZWZqUVmTm1FVKWQlb7spEPRZojoVu/AAB8wXhMfzyvzgID3A81OlDwAkLvVGj0XLO1e0Rotz578+iuOetn66n8Z9DjCH//KjBrQ1atuEXP6gWH1ZyV1PLlMjkgcfhzkHxCJ1EZdMaLnwsubsfJ3eJZMbmk04NAJQSuBZnCRUTsNRvdeShaW7mN3KZ7qiv5DEGjSSuqsvP3xc+ASQl6xpaCLaHi; 4:+g6UkiGmU4fQojySluoxziYytGdTdLxtFIhVaZjbP37NlELR9M7GDFExLxKGdjfV/oig1UPLTOyUTvef2jvUZ3vne27OZWhcUXy4uU0AA0ONH/CXxUuiXoXTC4o9WnbsS+EMwS+J+rd3O/tovDlofg0vHJpg1UOuU6Gunbzua3atQTWC3m1wKMow7XI8NMObxf6p1mU/Xc18Lruwp3yO13WN0q1QUhvKUEqz6v28V0FfoADjFUL6RpaF17yztSgnx9/6R7XX81FyBqU9kmf198bYT2+kcqAeVKOZLobl4dzYLpaks3zD0CMcplxTWTK70UCPO+54ezPTaaBH7DGD7w2XYDNO6Uhrbf0BvVejOiD1uT0QAqOMv8Cy/azSOJ09 X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001); SRVR:DM2PR08MB1465; BCL:0; PCL:0; RULEID:; SRVR:DM2PR08MB1465; X-Forefront-PRVS: 08978A8F5C X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(6049001)(24454002)(377454003)(66066001)(586003)(88552002)(1096002)(2870700001)(6116002)(50466002)(89122001)(92566002)(36756003)(90282001)(3846002)(189998001)(42186005)(93886004)(2906002)(33656002)(5008740100001)(5001770100001)(4001350100001)(4326007)(75432002)(2950100001)(86362001)(47776003)(65956001)(23676002)(65806001)(65816999)(64126003)(50986999)(81166005)(54356999)(87266999)(76176999)(77096005)(5004730100002)(11771545001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR08MB1465; H:[10.211.131.94]; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtETTJQUjA4TUIxNDY1OzIzOjNNVlJFWlZyRnF4bi95YnpuUHEzcTVwZ01w?= =?utf-8?B?NzM1TTR3MFBobFhtVFZjUGZKTjBwcXI3TFdISHFxWVhXaGthUXVTcFB0SlJB?= =?utf-8?B?WGk1M3U5cTBvSGNlNmdUMVBXditVRCtDbDkyTGRGVHNkdDB1WFNVU3dZSklZ?= =?utf-8?B?cG43RXgvRWZHeG5oU0t2V0QxTUZGc05aQmptSHJGZzZtWXJ4aXBZb2ZwWWta?= =?utf-8?B?T1cvNG5ldUh5L0s4VVBtQ3IzM2VxcWsxQ3dsU3UyRCthc2dmK2FiNTBIbWlZ?= =?utf-8?B?U3ExTkFVekFSWFB1cnl5dEtGOWdVU0RVMUtJV0NwYXB2R3gvdjZ5aDBnWHdi?= =?utf-8?B?dUZscEZiVE1SSGUyb0lWV1l4SjBpVThkdDNPcHR5aEllTzZKODUwSkhoOWRa?= =?utf-8?B?amFvWUx3VEZrMGJHeFFyQ1hteHBIK0tUTVFPNEt6citGTWkveG1EZjVEYzBm?= =?utf-8?B?TDUrOERCaGR6UUVOSHRqSG5rY3N3akxxMUY5dDNNQjlUVDFrbmRralRWYmxZ?= =?utf-8?B?akJhMEM5SkVrT3V2eUZZeG5ISmkvUXlDemc0bGFyc1E2ckM0M2VzRkdEOGRY?= =?utf-8?B?RGpoUDlCL2hHNDdib0dSNDBmU2NQem5ITnB1UkkxWlFhRjVHTlpWS0g1Ym1q?= =?utf-8?B?ZTJiTWo3K3pua0JUL25QRGFxYkl2U056TEV6aWJVTmV2MUgvUVZSMjljUisy?= =?utf-8?B?M3dMWjhSZmhvSFFybnhMMy9oM3FxWlhTREYrQ1ZvZHpEYWcvb28vRmdUWWJy?= =?utf-8?B?aXc2TDZnNzlQaE05aVg4eExTL1N4ZDlER3dEbTZXUXVpWHBtTEd3Ny9mcXlB?= =?utf-8?B?RHZ3LzZlUmVoTlFaK2E5bk9oTlVyc3VmK09QUUwyMGE2MWQrcHp4TWRqYlRm?= =?utf-8?B?UjB2VWYrM3E0bjVqQUdoUlAzS21iYUZPK1F1TVJoTGJUVlg2aHNNTXhESmlX?= =?utf-8?B?bnVMS3gxSGt5Z0RjeHpRSThySHdoUmh4RGVyOC9Vc2o0ZmRWdWtpZjZjdklD?= =?utf-8?B?cVBhOVhkUmdzZDN0Qk1OeUZBOXVsZjZlSnZ3V1NRZ1BkMGhwcytrOWtQY2t0?= =?utf-8?B?U0d3UHlPV2VjZFlSenJmRTlRMVprbzN4TVR2cTM4eVFSSkEvRklMRFkwUmlw?= =?utf-8?B?Q2xiaXRidHg3ZWt5M3ZscC9OOSs0UUVsajJDVE5Mb0VyVnBoR2k3UFNxNm1D?= =?utf-8?B?ZkFjVUM4SDlzUUZlNHdUeG91SkJaNHJoN01FdEd0ZitHT0x6ZVA0bGVhN3ZB?= =?utf-8?B?K1pvWlRGd1FRUEJWWW5wSFZtU2MySzVUSkxFMjU5VnZmazg1Zlk3ZUtJakdD?= =?utf-8?B?Y0lCSWJNUHlCTWtwSlFGblBtVXJjZWNlSUR1Q2NLcDUxWGtqWmROSEZhZUFB?= =?utf-8?B?UGJIeUkyWk10L1JaMThvYzBYQmpGbjNCV3Y2K1NjM2dEd2Z2QnlZTitIZ0FZ?= =?utf-8?B?bnpKT1d1ZW92UmNOb2owMnQxWTBjQlVPVSttN2U2TEVvVzBadVJReEZROU9N?= =?utf-8?Q?sGNvtiDp54g9SWJZe82W+0W5IYOA/66M/hg2Fl2ofvAWpW?= X-Microsoft-Exchange-Diagnostics: 1; DM2PR08MB1465; 5:gF1SZt6DxSAIIllSH5MY+miJNI9efGVXVnC2pnMfCBf9hf4Bkq5oJoFypNvA/lMAZBJRRMZ2P7zsK6uSWlpxQlCfIrQuajogg+AIDXytH+DVG4gcBlKo0RedaypjKvFwTDUYjRQs4lgF4WZJ+VO/EA==; 24:0vvlrT/5e6IfJa1rhEdbcxkH/xYIC0V0ZSpsGQIJ4sUG5Wc2zJMND1YeUhYBDaj6BT4SetmTYg69GR2J8EMMM7qHxz9nLrYFJTyq3IDXGpo= SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: unl.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 30 Mar 2016 14:15:04.6640 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR08MB1465 Archived-At: Cc: tcpm@ietf.org Subject: Re: [tcpm] TCP friendly formulation in CUBIC-draft ? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 30 Mar 2016 14:15:10 -0000 Hi Karen, I guess I need to clarify that the code segment that we were discussing is only part of the "TCP friendliness". There are two parts of TCP friendliness. 1) make sure that CUBIC does not starve Reno in high BDP (bandwidth delay product) networks, and achieves a similar rate as Reno in low BDP networks. This is achieved mainly by the parameters of CUBIC. This is the typical and more important "meaning" of TCP friendliness. 2) make sure that CUBIC average rate is never lower than Reno in any networks. What we were discussing is only about part 2). Thanks Lisong On 3/30/2016 3:47 AM, Karen Elisabeth Egede Nielsen wrote: > HI Lisong, > > > > Thank you. > > > > Thanks a lot for your support in understanding the function ! > > I am happy that we seem to have reached a common understanding. > > > > So what we have is an argumentation of the TCP friendliness function which > follows > > (1): Make CUBIC CWND be no less than what TCP New Reno would give > > > > And an implementation of CUBIC TCP friendliness function which does: > > (2): Make CUBIC CWND be no less than what AIMD( 3*(1-beta)/(1+beta) , > beta ) would > give > > > > I think that it is substantially more straightforward to make a theoretical > argumentation for why (1) is the right thing to do, than for why (2) is an > appropriate thing to do. > > The theoretical arguments for (1) is in the CUBIC draft and in the CUBIC > papers. > > > > Not knowing so much about this from a general research perspective, I > wonder if there exists theoretical evidence > > for why (2) is appropriate or proper in respect of the argumentation of > “TCP friendliness”. > > But also if one have a good understanding of the actual difference in > between (1) and (2), then this may serve as input for such an argumentation From nobody Wed Mar 30 07:49:56 2016 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 D8B3A12D161 for ; Wed, 30 Mar 2016 07:49:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=tieto.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 1X4Gfixci2la for ; Wed, 30 Mar 2016 07:49:48 -0700 (PDT) Received: from mail-io0-x234.google.com (mail-io0-x234.google.com [IPv6:2607:f8b0:4001:c06::234]) (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 2E23C12D551 for ; Wed, 30 Mar 2016 07:49:48 -0700 (PDT) Received: by mail-io0-x234.google.com with SMTP id g185so74605548ioa.2 for ; Wed, 30 Mar 2016 07:49:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tieto.com; s=google; h=from:references:in-reply-to:mime-version:thread-index:date :message-id:subject:to:cc:content-transfer-encoding; bh=b3drI2JvoxTE4aGZIhUpE7DPL+QDa5JMUSiiKncqfRo=; b=MMZIZ01mUC1/J6QvUkI5kjeiaPCQ/IrFy2q+VrkOjnW6JYDrxmHxQa4/jWlZV6uuSm 45NkCJkS2UjDz5j/bA5VwW6eJ/eEDUxdLS81IzirPGXaGQrxtGqk3xoAnVn/jceZobbm BrWei70HFYxOVASboBDOcRvGKZ7H+huVBri+4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:references:in-reply-to:mime-version :thread-index:date:message-id:subject:to:cc :content-transfer-encoding; bh=b3drI2JvoxTE4aGZIhUpE7DPL+QDa5JMUSiiKncqfRo=; b=IaPo7Fnfz4wvlJxHCHQ8f3K1ogd1NcaMWPKtBjs9KnUJDrV5S8e8qIhg4ea3YDKV7F DK9kMIPj4Wje/KvzDylM7+nlrQ7PwuKhop9AUHwRNcPuR7qfpIX9wtLcViBLvKB1BkFc FJa2/p46o3DMgI09dAKNxGERg3JNNQ9rhvbZSiSevG2BAps1+/SnZRLHsaJiSRcYoLWu 4oxLGnNCepCiTVRwjQj4ClNPDwSwsHYNlBJEbhxkn4ksKfInXFyzxqsOudXjGpiWLcve IHxeWoWrnQNjJSTN3VlCo6GsYMKXIoQIEeFA+m0tPTaS3UZNpoasGtiuv8aAUSqKvL9I 6bIQ== X-Gm-Message-State: AD7BkJLZ6rfsBWUKpKupfz5aFItbYUA59WWTjvUOCFkTjsxkLlL8qhs/vAA6yETPe6WwxClHXf6V6F4JioIXCOb1O+ltxE7d2ZG85tD2ixrKmvdvhOkE4Cu7nQIYkg2YL4Omkrk= X-Received: by 10.107.30.71 with SMTP id e68mr10105966ioe.145.1459349387519; Wed, 30 Mar 2016 07:49:47 -0700 (PDT) From: Karen Elisabeth Egede Nielsen References: <28265_1458030005_u2F8K4us025832_bb0b000b861f2a1e54225a8662b87a69@mail.gmail.com> <56E8D363.2080801@unl.edu> <14035_1458115854_u2G8AskH024517_22021b5df9cac80a9d8c0ba9ea526ef4@mail.gmail.com> <56ECD07A.3010407@unl.edu> <56FABA13.30102@unl.edu> <12368_1459328224_u2U8v3nZ025730_e84025e79d2ea1449205fe7a7b7c1059@mail.gmail.com> <56FBDF8F.1010805@unl.edu> In-Reply-To: <56FBDF8F.1010805@unl.edu> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQIbw19NaMpQgnr/3M9AdWgbjB7BugM9Fpq6AnWoUP4BZPwWCQH4X04GAdXMnMUBdtOJ/wIsvi3RnmlLE6A= Date: Wed, 30 Mar 2016 16:49:46 +0200 Message-ID: To: Lisong Xu , draft-ietf-tcpm-cubic@ietf.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-DomainID: tieto.com Archived-At: Cc: tcpm@ietf.org Subject: Re: [tcpm] TCP friendly formulation in CUBIC-draft ? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 30 Mar 2016 14:49:55 -0000 Hi Lisong, Yes I understand that we are not speaking part 1). We are speaking the CUBI= C operation in TCP Friendly region only As far as I have understood the argumentation behind 2) you are making sure that CUBIC CWND is never lower than TCP Reno CWND. But perhaps this has been a misunderstanding and you aim instead - as you say right below - is to make sure that the _average_ CUBIC window is not lower than Reno ? Either way the theoretical argumentation based on average window of AIMD alone does not hold, but empirics may tell that it is ok. Please note that I am not trying to "kill" CUBIC at all. On the contrary we are working to implement the algorithm. But still we want to make sure to understand the aims right. BR, Karen > -----Original Message----- > From: Lisong Xu [mailto:xu@unl.edu] > Sent: 30. marts 2016 16:16 > To: Karen Elisabeth Egede Nielsen ; draft-ietf- > tcpm-cubic@ietf.org > Cc: tcpm@ietf.org > Subject: Re: TCP friendly formulation in CUBIC-draft ? > > Hi Karen, > > I guess I need to clarify that the code segment that we were discussing i= s > only part of the "TCP friendliness". > > There are two parts of TCP friendliness. > > 1) make sure that CUBIC does not starve Reno in high BDP (bandwidth delay > product) networks, and achieves a similar rate as Reno in low BDP > networks. > This is achieved mainly by the parameters of CUBIC. This is the typical > and > more important "meaning" of TCP friendliness. > > 2) make sure that CUBIC average rate is never lower than Reno in any > networks. > > What we were discussing is only about part 2). > > Thanks > Lisong > > > On 3/30/2016 3:47 AM, Karen Elisabeth Egede Nielsen wrote: > > HI Lisong, > > > > > > > > Thank you. > > > > > > > > Thanks a lot for your support in understanding the function ! > > > > I am happy that we seem to have reached a common understanding. > > > > > > > > So what we have is an argumentation of the TCP friendliness function > > which follows > > > > (1): Make CUBIC CWND be no less than what TCP New Reno would give > > > > > > > > And an implementation of CUBIC TCP friendliness function which does: > > > > (2): Make CUBIC CWND be no less than what AIMD( 3*(1-beta)/(1+beta) , > > beta ) would give > > > > > > > > I think that it is substantially more straightforward to make a > > theoretical argumentation for why (1) is the right thing to do, than > > for why (2) is an appropriate thing to do. > > > > The theoretical arguments for (1) is in the CUBIC draft and in the > > CUBIC papers. > > > > > > > > Not knowing so much about this from a general research perspective, I > > wonder if there exists theoretical evidence > > > > for why (2) is appropriate or proper in respect of the argumentation > > of =E2=80=9CTCP friendliness=E2=80=9D. > > > > But also if one have a good understanding of the actual difference in > > between (1) and (2), then this may serve as input for such an > > argumentation From nobody Wed Mar 30 08:01:40 2016 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 4025712D76C; Wed, 30 Mar 2016 08:01:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=uofnelincoln.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 NDxfVWHYKOo1; Wed, 30 Mar 2016 08:01:35 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0241.outbound.protection.outlook.com [207.46.163.241]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5115C12D77F; Wed, 30 Mar 2016 08:01:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uofnelincoln.onmicrosoft.com; s=selector1-unl-edu; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=FXhWerJRYzZTVYBxz0dkt5gJycl346BT2vN1pDfOf7A=; b=imCRIT1aDSvvgKJhe/iusejhbF8DJV6ZYAB3uKTCRwaLEU9inSfQZsNlNopIhvQZMgDS6GkynujdZctZ+PdLrfXVq3CQLYp0/FBAI7tCVIM4grVYuMEXWfja5/SrdrbrG1gCLSjTEmDqY0QOZ93iWK/kG4vj79nBORuy/W/8b7Y= Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=unl.edu; Received: from [10.211.131.94] (129.93.4.24) by SN1PR08MB1470.namprd08.prod.outlook.com (10.162.2.13) with Microsoft SMTP Server (TLS) id 15.1.447.15; Wed, 30 Mar 2016 15:01:24 +0000 To: Karen Elisabeth Egede Nielsen , References: <28265_1458030005_u2F8K4us025832_bb0b000b861f2a1e54225a8662b87a69@mail.gmail.com> <56E8D363.2080801@unl.edu> <14035_1458115854_u2G8AskH024517_22021b5df9cac80a9d8c0ba9ea526ef4@mail.gmail.com> <56ECD07A.3010407@unl.edu> <56FABA13.30102@unl.edu> <12368_1459328224_u2U8v3nZ025730_e84025e79d2ea1449205fe7a7b7c1059@mail.gmail.com> <56FBDF8F.1010805@unl.edu> <16322_1459349393_u2UEnqW7004410_feff4fc139a45c2519a3d806e052cde7@mail.gmail.com> From: Lisong Xu Organization: University of Nebraska-Lincoln Message-ID: <56FBEA6C.1060502@unl.edu> Date: Wed, 30 Mar 2016 10:02:04 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <16322_1459349393_u2UEnqW7004410_feff4fc139a45c2519a3d806e052cde7@mail.gmail.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [129.93.4.24] X-ClientProxiedBy: BLUPR19CA0036.namprd19.prod.outlook.com (10.162.230.174) To SN1PR08MB1470.namprd08.prod.outlook.com (10.162.2.13) X-MS-Office365-Filtering-Correlation-Id: 94ea8299-2d88-4116-a991-08d358ac29b4 X-Microsoft-Exchange-Diagnostics: 1; SN1PR08MB1470; 2:nzVxKewWPSbysRlr4Yek9nvJAIi/PdtSBKaqL4sSPA3cNGjg/tN+DmWccMfoG+UHJxQmEKFUeM0DUVSx1sA0fyS7+pHDIG04UXH51a8X8b7qgVURO9sgowvWKEwJ5VPWKViydroDDrEksptIqkh9ltj0Sw48nn5+zkHjP6NlZXpu+dWLUzqVFgIvuwds6rN8; 3:WMI+u/gY8YAx93beAWDD72HBP+lZeBH0HDbX9DjyscmBOnz/wwNa0cN4SveWDESGIoOs+v0HgNNiBIXVj6kdf5navxJGCmC3HUkwLRe4nS+fCTXSgk5eWJtXsnxB6Bd5 X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN1PR08MB1470; X-Microsoft-Exchange-Diagnostics: 1; SN1PR08MB1470; 25:UFvgcn6V4bmuJT5UHuwyd50ok5kojNFS3DK04Kgw1n2Z0g/Liqkm0Q+dIiCebRfApli7M9VKaKnlmrpoX+zOZKsLUiUbCMIQNZLKJrAO7ktuDkbvwYz2uxBwhhfGMi9MXDvQKxt1nlj0GJy99qnvKl/8bvDukEsz9eAzjpO6jbQTfqqxS7JWjdcJqQe5EIqcXgUZB6egIeIDb//HnE/2Cx/0sFQToF2xDeeFPPo5qfFhz1hetrkArEsKIqYy6ab0+uuOIT/cM+6b1Lx+KSg9uYSPG4CuFlNvAlo+vIY7SoGLbUbsldZRYpUFeVCVuPpjRWWK0EKbH3AZ5PzOuwwoq0Lf5UGy5/VD1Or0b4z0QD7rBgUYVH41TaFqTeEKLzTC9L8D3xarojjGX+qF8ZSjMsZfbT4VLM5JUFDMthCVZnadfFyMPLwO96//Dx5L9tnAi2fQ1H17Wk0hegmNAS3wxOR5j//SWL1rQTEIGVOE3KtcOxIEHbJTW1GpGd/9p7tZFuquS7+TthTUq/QPtPswkEa4ELcB9khqbHK98bvkmoz3Xhzm2GfUh3sS1sCfj55YrRM4wZ4XhhMKiBgCfBlGyX9q3CstoP9Db3Fl82QLwFeo46Qd7CeUtG/f4mcxM158ikE0hwMLXxy6RTYa3B6E1A== X-Microsoft-Exchange-Diagnostics: 1; SN1PR08MB1470; 20:HDwFM5X9Ph0P5GB3UghHH1FSqqjS9/YJMgCbCPde6jNTP+K21SP/C55TQOtl8gl5dIKhCW2WAxZ37mN+IVPNDDnTHMqLWG7R5hT6/fgXMrnExrP9NrfGvXW7I569zzX19T4QU+YTaajZ6I+PprTUjVCxKfze7PabAp49gQs1/ud8/yMIbZ3RFoEYITkHPcPgKSKCPIs79c3DZrkUT6hwxRg1gsF7KHF5bAQOTP8Vclr2Otu26M3tseWXu2yc06cqtIUU1rbkcSleAcPouREsNgTcmH2QuG0q31a6yfpeQaAFMN08XcW5OQfOEao1QmGFlyh3IP4ZKSD9A3Pci3cAoTYK+rqZah6cXhUo88odzplFB0pw5YOEfst4mGd6Q0uCAPuKXDqAoXfUIAp92wacWm8pmcpv48LBz3jgKqwjCNLysG8hYlJYfIsyfPlehakQ2ymOfhS5EKsiTslX0TE/i6srGNuv+PKR2wBDRu8jtbdQpO0ZsYAH9QeZeR3asm2z; 4:Ama4n441htMSb6Kk1K/loqzfjfIqsvBXDXlSOfrGf0hjga8I5UEN1y2XkWlr2DnQsykqKmTVSyL6tNhtZeDJgakWyxalqtH4kbCViRVCf63m5oMv88KbHGl5BCKLlJU/eevxI+p3o8KtC+SPReNqiiEjhjkP2yfNKZCOa/1ivp65PuyW8qEeLefKBpoqo4xWh5H6xqFp1bhIyQGsakYnbwLW6M69rTW8czeS2jFAHwU6O58wEwSecgpJyGQLcs3iagTKUWBZadS35yPepCtf4XqfVB/L2OOvE8cjNo66lmelF950g7Dj/oronwUjmaA05e8of8q4JYOFtEsIN2vQ5jR4wMd5ZesSoQKMCet9l9/rVD8BCH8gM7v5RuKW0Wp+ X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001); SRVR:SN1PR08MB1470; BCL:0; PCL:0; RULEID:; SRVR:SN1PR08MB1470; X-Forefront-PRVS: 08978A8F5C X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6049001)(6009001)(13464003)(377454003)(243025005)(24454002)(65806001)(92566002)(86362001)(1096002)(2906002)(19580395003)(65956001)(66066001)(89122001)(189998001)(36756003)(47776003)(19580405001)(5001770100001)(33656002)(64126003)(4001350100001)(5004730100002)(81166005)(90282001)(4326007)(50466002)(75432002)(93886004)(42186005)(23676002)(87266999)(65816999)(54356999)(2950100001)(50986999)(76176999)(77096005)(15975445007)(19300405004)(2870700001)(3846002)(6116002)(88552002)(19273905006)(5008740100001)(586003)(11771545001)(562404015)(563064011); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1PR08MB1470; H:[10.211.131.94]; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtTTjFQUjA4TUIxNDcwOzIzOnhXVERCRW1hVkpXaWpJZitLZGk3RkxrS1Z6?= =?utf-8?B?UTRNMUh4NWhZVWhGTXVDOHE1MHNQY3lka0dYTEQxempyMy9MdzdjeWlkMHpH?= =?utf-8?B?OFEzNWNvV1doM0Nqc21vVGpieXJjUEtwdk9ibkpjcXpPWUVyMmt3aDFrb3JN?= =?utf-8?B?aE9vNHZIVHErWm9RcjhNbmtBaVBtc093NnJCcWFvR0JQRkh0bnJ1eWlpNFFM?= =?utf-8?B?ditraHhRZ0tzdllNWnlvT2N6OHVHRDduZFZWZWEzQlh6Mi9DajhkaHl6QnZa?= =?utf-8?B?RERkTi9PdlVrcFF2YkYvK3UwSkJ1RXdEclVkNXJaelVSL1BORldvMXJVeWpY?= =?utf-8?B?SVh4anlKejZNZ2NWYUFYb3NTNDMvb0lnUXkxQ3lXUnB6YkdZS3d3Tzh0RVFr?= =?utf-8?B?alpPcWxRbEY1RVRJcm1pY0kwYjdwdFZWdmQwQ1d2R2Y4c1ZDZDlrVmloTWpn?= =?utf-8?B?bThIT2lyUHVEYWgxREFMU29WWlNMTjhQKzJ0UVl0dmdJbUpkMWtYQUsyakUr?= =?utf-8?B?Q1hpNjBNUlkxdVJBaVF1WXMvRkhvSDNtclBNS00vUUNIaVFEdzlwSVp6aHdx?= =?utf-8?B?RGl1czU2NzQ2U21aczUyeExBQVcwUkhZNDBjUTdHYnRsVmVXajdSbW9FNzk3?= =?utf-8?B?UmJZaFdzR094clVSclVVcVBPUFpDL1gvS0VCTkJEWGppcm5oSytnN0VCWUk5?= =?utf-8?B?ZEQvWUVxYXJ4USt0SWtTd1RGZ0IrV0RjRW1lbXhlZGhZclNybURMdHRndHl1?= =?utf-8?B?Ky9ub094aHVzQkgwRVh3a050eWQ2NTQ0WW1za2ZjSkdjb0ZySnNvejljKzJH?= =?utf-8?B?cXQ3WG8ycEhLaUJuVTQyY1VZTnFCUElPelovL01tWVVReW90NGVuMlY1T3I2?= =?utf-8?B?UXZERkltSVZwaHpJd0RSRnpPOHV6UEhpWVlWS1JuVTFFd1JvSXBNemlMMldr?= =?utf-8?B?U1VhTmZXdXduOXBGQ3hIRkpHNXpldlN0VTJ0SCttdjJsK0JqRG1TS1Q1N0F1?= =?utf-8?B?ajBhejdRVHRrSVptbEdON3FYUVVNaStlSEIxUW9KVVFxVCtMSm1RY1owS3No?= =?utf-8?B?T2RnZWZtcGxRT1dNeklLVjZFMC83VGw0THA5V0htT3czTVNNeVdIeVJ1OWVE?= =?utf-8?B?SzVtcExJTFZtSCtUNzlCZjRtaXdOU2lZMXhzNXdMdkx4WXVmTitkS293V2R6?= =?utf-8?B?V1pCMXFaSnNRK2UrWG5YODJSNElTOXYrWmVMSlRtOUttUVM3eWpUMFJJRG5Y?= =?utf-8?B?bGR2RHFJS2FuZTZTQmFYZy9pWWxnVzRjdzhVNDZnTklnckVQZmJIWE8wdTls?= =?utf-8?B?VEU3LzNtV1hjNmVpL3ZmYWhSaW9oQVNXY2Z1QzlOSnlzMm1IZzlQY3lWWXFr?= =?utf-8?B?RkZZanpULzA3Zy9NaG51dmxRM1dsNGV3TThGUjRHeXZpZy93YUlZSnQwTGU1?= =?utf-8?B?bzgvOFpsNlU5dHAyajk5ZC81SjhjNldrZXFtRS9CTVRObm53KzV6VEhtV3dE?= =?utf-8?B?YW5hY0xhL0JNejRzaG1RaUUzMHJSdUU5YVNtVFEwMThXV282MGwyTzUyVnZ2?= =?utf-8?B?QzhiRUFueWt3VUVDQlhJaDE2UVdPd3lVVnE5ckRoV0t3dm5XTjNrMU1PbTBF?= =?utf-8?B?cS9UZkIyZ2o5eDlYTjZHYysvVmhjK3J0TFZPdEIrZHlMTVpmMjdRME1NNVlY?= =?utf-8?B?US8rbkhtNnVpMXFlSzdGQVFlM25sVnJIa05mTGg3TWN5bVFLdGl1MzZ4NnhN?= =?utf-8?B?ZEdRY2dISC9tZ29BaDRmV2poMHdiVlZEZkZjZVArSGFWN092MThJTHZHWXYw?= =?utf-8?B?UC9HbUZHRU9zMFNzcUtiMGFNZ0FML3ZSK3NheC8wbDFBL1E9PQ==?= X-Microsoft-Exchange-Diagnostics: 1; SN1PR08MB1470; 5:9edwwGZPwo+mblKmVIfBFtVQhNmX6LILUa3nLtZxZI+2RQzQDQ89MVjPVdcJ6ZXEG5pyO2NW5fjvhwLyxbM0y6xkVzUZnb4lzO9HTqJ5D8S7gLAB/S/G1PTQnCmDb/5bEAHNaXom2/iNWidTmOGw0w==; 24:ag3dvEET3s64VYJpVVsHIP0YUxedgdmZd9A9C0sb0KDOxFKmoinpx8V8dzvdAn7zGcIWxxUTkIKBi98Jq8vZHypPz+Q2n+3P4hEwZT5ryo8= SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: unl.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 30 Mar 2016 15:01:24.3103 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR08MB1470 Archived-At: Cc: tcpm@ietf.org Subject: Re: [tcpm] TCP friendly formulation in CUBIC-draft ? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 30 Mar 2016 15:01:38 -0000 Hi Karen, The equivalence between (alpha=1, beta=0.5) and (alpha=3*(1-beta)/(1+beta), beta) is explained in the following paper. Equation (9). http://www.icir.org/tfrc/aimd.pdf Thanks Lisong On 3/30/2016 9:49 AM, Karen Elisabeth Egede Nielsen wrote: > Hi Lisong, > > Yes I understand that we are not speaking part 1). We are speaking the CUBIC > operation in TCP Friendly region only > > As far as I have understood the argumentation behind 2) you are making sure > that CUBIC CWND is never lower than TCP Reno CWND. > But perhaps this has been a misunderstanding and you aim instead - as you > say right below - is to make sure that the _average_ CUBIC window is not > lower than Reno ? > Either way the theoretical argumentation based on average window of AIMD > alone does not hold, but empirics may tell that it is ok. > > Please note that I am not trying to "kill" CUBIC at all. On the contrary we > are working to implement the algorithm. But still we want to make sure to > understand the aims right. > > BR, Karen > >> -----Original Message----- >> From: Lisong Xu [mailto:xu@unl.edu] >> Sent: 30. marts 2016 16:16 >> To: Karen Elisabeth Egede Nielsen ; draft-ietf- >> tcpm-cubic@ietf.org >> Cc: tcpm@ietf.org >> Subject: Re: TCP friendly formulation in CUBIC-draft ? >> >> Hi Karen, >> >> I guess I need to clarify that the code segment that we were discussing is >> only part of the "TCP friendliness". >> >> There are two parts of TCP friendliness. >> >> 1) make sure that CUBIC does not starve Reno in high BDP (bandwidth delay >> product) networks, and achieves a similar rate as Reno in low BDP >> networks. >> This is achieved mainly by the parameters of CUBIC. This is the typical >> and >> more important "meaning" of TCP friendliness. >> >> 2) make sure that CUBIC average rate is never lower than Reno in any >> networks. >> >> What we were discussing is only about part 2). >> >> Thanks >> Lisong >> >> >> On 3/30/2016 3:47 AM, Karen Elisabeth Egede Nielsen wrote: >>> HI Lisong, >>> >>> >>> >>> Thank you. >>> >>> >>> >>> Thanks a lot for your support in understanding the function ! >>> >>> I am happy that we seem to have reached a common understanding. >>> >>> >>> >>> So what we have is an argumentation of the TCP friendliness function >>> which follows >>> >>> (1): Make CUBIC CWND be no less than what TCP New Reno would give >>> >>> >>> >>> And an implementation of CUBIC TCP friendliness function which does: >>> >>> (2): Make CUBIC CWND be no less than what AIMD( 3*(1-beta)/(1+beta) , >>> beta ) would give >>> >>> >>> >>> I think that it is substantially more straightforward to make a >>> theoretical argumentation for why (1) is the right thing to do, than >>> for why (2) is an appropriate thing to do. >>> >>> The theoretical arguments for (1) is in the CUBIC draft and in the >>> CUBIC papers. >>> >>> >>> >>> Not knowing so much about this from a general research perspective, I >>> wonder if there exists theoretical evidence >>> >>> for why (2) is appropriate or proper in respect of the argumentation >>> of “TCP friendliness”. >>> >>> But also if one have a good understanding of the actual difference in >>> between (1) and (2), then this may serve as input for such an >>> argumentation From nobody Wed Mar 30 13:13:37 2016 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 DB3D612D93F; Wed, 30 Mar 2016 13:13:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 xEEIaG1Yq3Zz; Wed, 30 Mar 2016 13:13:33 -0700 (PDT) Received: from mail-yw0-x22e.google.com (mail-yw0-x22e.google.com [IPv6:2607:f8b0:4002:c05::22e]) (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 D028612D54F; Wed, 30 Mar 2016 13:13:29 -0700 (PDT) Received: by mail-yw0-x22e.google.com with SMTP id g127so72380623ywf.2; Wed, 30 Mar 2016 13:13:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=FO9vnKbA3LXtnZ4BS7vK+MSMLCDMEFPr/zF5QJa4bvk=; b=Nm4G05nU56H3n0IlYKW/lQE2O6bfyUPHm0wRJckUuvABl9MQDgy4w2K205yPWOxY0e CCyHUDZaxP11t37Si6z1lPnlsfF8h0iqPaMBJBjiQ5zXUH4TIJ5Vd3BzT6Az4Ejhnp0J XNG/YR1gG9oY4pKWmMaUx/Qkk0WYSiNohO9hoqZU8ov5DTvD7V/uFAy156s873/PsSm+ i6SLAEhLRcLhD1TDrYl6DTNRhIGjdVX6Joy9n1zZTZkRQK/hu3Lo2ye7RKf+YpaDWUd7 4hkJO26tgsZpD++B8CEHfNswG0fbgLG7+6X6x+ejZZuzhqct3wwWJOqQ2xGRyKEq2qjW 2jLQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=FO9vnKbA3LXtnZ4BS7vK+MSMLCDMEFPr/zF5QJa4bvk=; b=mBhnGnYriuAJqrVDKGgdKGMwC7yGQt3guB0MyccIX0iWJMJR2xnslxOcEUPjuOj8zw kWfMZ0pNddmAxmhKrj7235lVoX3lqriLLtigyeyGHaXPFv2yOp6d2oQ7kyRMNlF4NC1c C/iIksdypmXPa2I55rVHJF4lZsf6romCHWKWu3oPpUzJI6RSaVHYTaaEXl9jD7F0RHx7 wvLH2pTlWLW4eWxeYkjiZoCE7BOY0qcfdBOxCzQ3hquO719FHRfzP1GuAJcRxdXW7v0q qj5911nCwSmYyDVb9PHMFpY6RuP1fvjxfLTLpmBY6YsRI8IdpHWQnSv2m32/Sdd1LsDb r+XQ== X-Gm-Message-State: AD7BkJJ3hCtjfIppvcKWeZB7QSHzTjRFNPaLcTx668fVpEYgKN5SWb+3ijltnbghggEj7v7KiFKWgSjgEttauQ== MIME-Version: 1.0 X-Received: by 10.129.99.197 with SMTP id x188mr5113243ywb.61.1459368809062; Wed, 30 Mar 2016 13:13:29 -0700 (PDT) Received: by 10.37.70.198 with HTTP; Wed, 30 Mar 2016 13:13:28 -0700 (PDT) In-Reply-To: References: <56C71869.9080503@bobbriscoe.net> <20160219182359.GA74531@verdi> <56CACCB1.2080502@bobbriscoe.net> Date: Wed, 30 Mar 2016 16:13:28 -0400 Message-ID: From: Aaron Falk To: Spencer Dawkins at IETF Content-Type: multipart/alternative; boundary=001a1135a06875ecc8052f49c75e Archived-At: Cc: tcpm IETF list , tsvwg IETF list , TCP Prague List , "tsv-ads@ietf.org" , AQM IETF list Subject: Re: [tcpm] [tcpPrague] [tsvwg] (Bar) BoF @IETF-95 'Ultra-Low Queuing Delay for All' (L4S, DualQ Coupled AQM, TCP Prague)? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 30 Mar 2016 20:13:35 -0000 --001a1135a06875ecc8052f49c75e Content-Type: text/plain; charset=UTF-8 Did this get scheduled? --aaron On Mon, Feb 22, 2016 at 12:21 PM, Spencer Dawkins at IETF < spencerdawkins.ietf@gmail.com> wrote: > Just to try to be helpful ... > > On Mon, Feb 22, 2016 at 2:54 AM, Bob Briscoe wrote: > >> John, >> >> On 19/02/16 18:23, John Leslie wrote: >> >>> Bob Briscoe wrote: >>> >>>> I'm cross-posting 'cos this impacts 3 IETF WGs and interested >>>> implementers. >>>> >>>> We would like to propose a Bar BoF at the Buenos Aires IETF, about L4S, >>>> DualQ and solutions to the TCP Prague Requirements. >>>> >>> This feels like it belongs as a non-WG-forming formal BoF. >>> >>> It describes work spanning at least three WGs; and could benefit from >>> formal scheduling to avoid conflicts with those WGs and others. >>> >>> OTOH, it really isn't to the point where a WG charter can reasonably >>> be drafted. First we must decide whether the work _can_ be split among >>> existing WGs. >>> >>> However this may turn out, I wish to participate remotely. >>> >> OK, we'll see if the secretariat can help us with that. >> > > I believe that happens at http://www.ietf.org/meeting/amreq.html. If you > put "TSV" in as "type of meeting", your happy TSV ADs would see the request. > > Thanks, > > Spencer > > >> Unfortunately we ran out of time for the formal BoF deadline on Friday. >> >> >> Bob >> >> >>> -- >>> John Leslie >>> >>> _______________________________________________ >>> tcpPrague mailing list >>> tcpPrague@ietf.org >>> https://www.ietf.org/mailman/listinfo/tcpprague >>> >> >> -- >> ________________________________________________________________ >> Bob Briscoe http://bobbriscoe.net/ >> >> > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > > --001a1135a06875ecc8052f49c75e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Did this get scheduled?

--aaron

On Mon, Feb 22, 201= 6 at 12:21 PM, Spencer Dawkins at IETF <spencerdawkins.ietf@gm= ail.com> wrote:
Just to try to be helpful ...

On Mon, Feb 22, 2016 at 2:54 AM, Bob Bri= scoe <ietf@bobbriscoe.net> wrote:
John= ,

On 19/02/16 18:23, John Leslie wrote:
Bob Briscoe <ie= tf@bobbriscoe.net> wrote:
I'm cross-posting 'cos this impacts 3 IETF WGs and interested imple= menters.

We would like to propose a Bar BoF at the Buenos Aires IETF, about L4S,
DualQ and solutions to the TCP Prague Requirements.
=C2=A0 =C2=A0 This feels like it belongs as a non-WG-forming formal BoF.
=C2=A0 =C2=A0 It describes work spanning at least three WGs; and could bene= fit from
formal scheduling to avoid conflicts with those WGs and others.

=C2=A0 =C2=A0 OTOH, it really isn't to the point where a WG charter can= reasonably
be drafted. First we must decide whether the work _can_ be split among
existing WGs.

=C2=A0 =C2=A0 However this may turn out, I wish to participate remotely.
OK, we'll see if the secretariat can help us with that.

I believe that happens at=C2=A0http://www.ietf.org/me= eting/amreq.html. If you put "TSV" in as "type of meetin= g", your happy TSV ADs would see the request.

Thanks,

Spencer
=C2=A0=
Unfortunately we ran out of time for the formal BoF deadline on Friday.


Bob


--
John Leslie <john@jlc.= net>

_______________________________________________
tcpPrague mailing list
tcpPrague@ietf.org<= /a>
https://www.ietf.org/mailman/listinfo/tcpprague

--
________________________________________________________________
Bob Briscoe=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0http://bobbriscoe.net/



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


--001a1135a06875ecc8052f49c75e-- From nobody Thu Mar 31 03:50:58 2016 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 4262E12D55B for ; Thu, 31 Mar 2016 03:50:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=tieto.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 0Vu2BVf5YqiJ for ; Thu, 31 Mar 2016 03:50:54 -0700 (PDT) Received: from mail-io0-x229.google.com (mail-io0-x229.google.com [IPv6:2607:f8b0:4001:c06::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 CCC7812D573 for ; Thu, 31 Mar 2016 03:50:52 -0700 (PDT) Received: by mail-io0-x229.google.com with SMTP id q128so107095108iof.3 for ; Thu, 31 Mar 2016 03:50:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tieto.com; s=google; h=from:references:in-reply-to:mime-version:thread-index:date :message-id:subject:to:cc:content-transfer-encoding; bh=FHQ3cqqHvtb6lYvVYbulKlS45ywS7c/MrtCWyuscwzE=; b=nCvHYKksrRtjDsJQI/j3n/alrAEW6bXq485cNq/b5CemIJeUKDbGViSHf/bAKRd7ig 7wd9lKlDsoGu7MjIsa3idjfdawJfIKuVNSo0kp6bDqXrB1UvwJLJEijKRtgN9zwdY6Uv Z6oRRBow0xsoE2FpeRpkzGNdZkJpyKpnrYeAU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:references:in-reply-to:mime-version :thread-index:date:message-id:subject:to:cc :content-transfer-encoding; bh=FHQ3cqqHvtb6lYvVYbulKlS45ywS7c/MrtCWyuscwzE=; b=a8zwIr/OSFTKESsU7qARFNF8LCW6LFbf3/RpQLeTTUT5NJnz9hDqFpBdVsYnRZs2SP Hr/X/FnyLoorKatoQW7sy0ldJfLJ8QvlXdCgohEhFq4+1QJrzzxnVHUUpP5hEIrOc9DE KhTewHuXzSTc5AhtXrcB9ynce2DLgwDI+LrBlU9xJuxRlNfKkgznZRY6RjDtxI9vIA2Y ASmzoZtKAduLIgPP1/pbMW8CwXKIw5XGUM5xgLBD4R//Hk4p+zEXVptPkxAHaiaAzild 7VB+MZYvCEwhWA8rjzqZa/l1RqGMzunZfYosISVoCmLS+RSKvmj98p92H+m2gj68scKJ 2GAw== X-Gm-Message-State: AD7BkJJRdDlzviGTiWdQy2SkNoYC5/mtdkfJ6dI3BuwtzrDzYUSGI+mK8jWMZhvRZcJwl6/su4Kw70Fy85hgbpoad5BePYZdBB8vNMxmV1UEl65EzqrYTzDS5PzBrI88JvA1W5g= X-Received: by 10.107.30.71 with SMTP id e68mr1405877ioe.145.1459421451854; Thu, 31 Mar 2016 03:50:51 -0700 (PDT) From: Karen Elisabeth Egede Nielsen References: <28265_1458030005_u2F8K4us025832_bb0b000b861f2a1e54225a8662b87a69@mail.gmail.com> <56E8D363.2080801@unl.edu> <14035_1458115854_u2G8AskH024517_22021b5df9cac80a9d8c0ba9ea526ef4@mail.gmail.com> <56ECD07A.3010407@unl.edu> <56FABA13.30102@unl.edu> <12368_1459328224_u2U8v3nZ025730_e84025e79d2ea1449205fe7a7b7c1059@mail.gmail.com> <56FBDF8F.1010805@unl.edu> <16322_1459349393_u2UEnqW7004410_feff4fc139a45c2519a3d806e052cde7@mail.gmail.com> <56FBEA6C.1060502@unl.edu> In-Reply-To: <56FBEA6C.1060502@unl.edu> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQIbw19NaMpQgnr/3M9AdWgbjB7BugM9Fpq6AnWoUP4BZPwWCQH4X04GAdXMnMUBdtOJ/wIsvi3RAQgFcF0Al1cUe55do5ew Date: Thu, 31 Mar 2016 12:50:50 +0200 Message-ID: <9241ef51bda537b7a52e00c94a1e0272@mail.gmail.com> To: Lisong Xu , draft-ietf-tcpm-cubic@ietf.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-DomainID: tieto.com Archived-At: Cc: tcpm@ietf.org Subject: Re: [tcpm] TCP friendly formulation in CUBIC-draft ? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 31 Mar 2016 10:50:57 -0000 Hi Lisong, Many thanks. This is still average considerations and the carryover of the argument to the TCP friendly sub-domain of CUBIC does not follow straightaway. I would suggest, in section 3.2 of the CUBIBC draft, not to make something that looks like a mathematical argument for that AIMD(3*(1-beta)/(1+beta), beta) is a good approximation for TCP New Reno in the TCP friendly region. But rather refer to that based on the evaluations of [FHP00], showing the general approximation (and fairness) of AIMD(3*(1-beta)/(1+beta), beta) compared to TCP New Reno, this AIMD profile is used to define the TCP Friendly region and this profil= e is used as a replacement of the CUBIC window in this region. In whatever way you want to formulate this... But I will stop pressing this point. Thanks for the patience ! :-) BR, Karen > -----Original Message----- > From: Lisong Xu [mailto:xu@unl.edu] > Sent: 30. marts 2016 17:02 > To: Karen Elisabeth Egede Nielsen ; draft-ietf- > tcpm-cubic@ietf.org > Cc: tcpm@ietf.org > Subject: Re: TCP friendly formulation in CUBIC-draft ? > > Hi Karen, > > The equivalence between (alpha=3D1, beta=3D0.5) and (alpha=3D is explained in the following paper. > Equation (9). > > http://www.icir.org/tfrc/aimd.pdf > > Thanks > Lisong > > > > On 3/30/2016 9:49 AM, Karen Elisabeth Egede Nielsen wrote: > > Hi Lisong, > > > > Yes I understand that we are not speaking part 1). We are speaking the > > CUBIC operation in TCP Friendly region only > > > > As far as I have understood the argumentation behind 2) you are making > > sure that CUBIC CWND is never lower than TCP Reno CWND. > > But perhaps this has been a misunderstanding and you aim instead - as > > you say right below - is to make sure that the _average_ CUBIC window > > is not lower than Reno ? > > Either way the theoretical argumentation based on average window of > > AIMD alone does not hold, but empirics may tell that it is ok. > > > > Please note that I am not trying to "kill" CUBIC at all. On the > > contrary we are working to implement the algorithm. But still we want > > to make sure to understand the aims right. > > > > BR, Karen > > > >> -----Original Message----- > >> From: Lisong Xu [mailto:xu@unl.edu] > >> Sent: 30. marts 2016 16:16 > >> To: Karen Elisabeth Egede Nielsen ; > >> draft-ietf- tcpm-cubic@ietf.org > >> Cc: tcpm@ietf.org > >> Subject: Re: TCP friendly formulation in CUBIC-draft ? > >> > >> Hi Karen, > >> > >> I guess I need to clarify that the code segment that we were > >> discussing is only part of the "TCP friendliness". > >> > >> There are two parts of TCP friendliness. > >> > >> 1) make sure that CUBIC does not starve Reno in high BDP (bandwidth > >> delay > >> product) networks, and achieves a similar rate as Reno in low BDP > >> networks. > >> This is achieved mainly by the parameters of CUBIC. This is the > >> typical and more important "meaning" of TCP friendliness. > >> > >> 2) make sure that CUBIC average rate is never lower than Reno in any > >> networks. > >> > >> What we were discussing is only about part 2). > >> > >> Thanks > >> Lisong > >> > >> > >> On 3/30/2016 3:47 AM, Karen Elisabeth Egede Nielsen wrote: > >>> HI Lisong, > >>> > >>> > >>> > >>> Thank you. > >>> > >>> > >>> > >>> Thanks a lot for your support in understanding the function ! > >>> > >>> I am happy that we seem to have reached a common understanding. > >>> > >>> > >>> > >>> So what we have is an argumentation of the TCP friendliness function > >>> which follows > >>> > >>> (1): Make CUBIC CWND be no less than what TCP New Reno would give > >>> > >>> > >>> > >>> And an implementation of CUBIC TCP friendliness function which does: > >>> > >>> (2): Make CUBIC CWND be no less than what AIMD( 3*(1-beta)/(1+beta) > >>> , beta ) would give > >>> > >>> > >>> > >>> I think that it is substantially more straightforward to make a > >>> theoretical argumentation for why (1) is the right thing to do, than > >>> for why (2) is an appropriate thing to do. > >>> > >>> The theoretical arguments for (1) is in the CUBIC draft and in the > >>> CUBIC papers. > >>> > >>> > >>> > >>> Not knowing so much about this from a general research perspective, > >>> I wonder if there exists theoretical evidence > >>> > >>> for why (2) is appropriate or proper in respect of the argumentation > >>> of =E2=80=9CTCP friendliness=E2=80=9D. > >>> > >>> But also if one have a good understanding of the actual difference > >>> in between (1) and (2), then this may serve as input for such an > >>> argumentation From nobody Thu Mar 31 10:04:06 2016 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 1D51912D6AE for ; Thu, 31 Mar 2016 10:04:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.711 X-Spam-Level: X-Spam-Status: No, score=-2.711 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_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 7m3-7iWwm7ZL for ; Thu, 31 Mar 2016 10:04:02 -0700 (PDT) Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::22e]) (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 6EB1C12D536 for ; Thu, 31 Mar 2016 10:04:02 -0700 (PDT) Received: by mail-wm0-x22e.google.com with SMTP id p65so122803147wmp.0 for ; Thu, 31 Mar 2016 10:04:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=nKISF5KDUI4bYvpdoqDQ8pcqynHGu9BF/ajTlRwu1ZQ=; b=Tm/N2DOudwMqeCbMd4A+bo5WCp3dZrGvTG4R1bq8XCcX6ObAJ0Lj2gO/aGHsF++glV 4x8E1si8mx2VW8i7MSkEnGv8K8ek4YD5iomnoMZRn6FDCjzQwVt1U2/Az8s9/VHnVmMA GtNGdY11ZETmff6cIEey96s0aGM1sZpfHdM3PbnG+tO85QyUjPyDON8vRDCL6csWGuc5 JaFRZkC0wUdEsjrA1Adb4Ex72vA4bss9NK7RKVBFEFJjSPd5xQ0pP3kI1iSs+NIV6L8D slnZQV+I8WFWJSA8aSyACCOyvFittRyuJ/isxFPBy1MiHNUWAckazB4022UoEsPaC2H4 pqtQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=nKISF5KDUI4bYvpdoqDQ8pcqynHGu9BF/ajTlRwu1ZQ=; b=VzE9qI8nXvLjVbig3jvB4AYLZrVjz9n5dgxEm57bdj1r3n9/lBOd5qj6asxaojDRWn zCO0wlQCCb1m9OxxdyaPuDVlN7dAwSkwYM56nrBHURKlC/0bieFB0ZqkEWSwP5ejNfVp lO6EAQz43AhBO4qmY77p+dP8oP30G7XpbtkfixQborvpLLoe+yRHzvRaza6NjCWBf/eC XkmMyoeNLXKNP2yk2BseRLC3kRYNW4LKLfbsP9reUOS40QasG/546j4H8xQsWus106Wd 0TpcAq8qQiBb+ocRmzmpwdyZLvPkQeYp4U76igQzlTaLsJzT93kzyeLIUdQ79//2KgZF RnBA== X-Gm-Message-State: AD7BkJLf8xi8P3jMFvArzb7ZxDHmGCPm2suBTwnD+BbEMyIRa9MlKDK1XqmRD5I95jpPPwluJosoGInxpURDZPaE X-Received: by 10.28.150.195 with SMTP id y186mr16593613wmd.43.1459443840807; Thu, 31 Mar 2016 10:04:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.222.131 with HTTP; Thu, 31 Mar 2016 10:03:21 -0700 (PDT) In-Reply-To: <9241ef51bda537b7a52e00c94a1e0272@mail.gmail.com> References: <28265_1458030005_u2F8K4us025832_bb0b000b861f2a1e54225a8662b87a69@mail.gmail.com> <56E8D363.2080801@unl.edu> <14035_1458115854_u2G8AskH024517_22021b5df9cac80a9d8c0ba9ea526ef4@mail.gmail.com> <56ECD07A.3010407@unl.edu> <56FABA13.30102@unl.edu> <12368_1459328224_u2U8v3nZ025730_e84025e79d2ea1449205fe7a7b7c1059@mail.gmail.com> <56FBDF8F.1010805@unl.edu> <16322_1459349393_u2UEnqW7004410_feff4fc139a45c2519a3d806e052cde7@mail.gmail.com> <56FBEA6C.1060502@unl.edu> <9241ef51bda537b7a52e00c94a1e0272@mail.gmail.com> From: Yuchung Cheng Date: Thu, 31 Mar 2016 10:03:21 -0700 Message-ID: To: Karen Elisabeth Egede Nielsen Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "tcpm@ietf.org Extensions" , draft-ietf-tcpm-cubic@ietf.org Subject: Re: [tcpm] TCP friendly formulation in CUBIC-draft ? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 31 Mar 2016 17:04:05 -0000 On Thu, Mar 31, 2016 at 3:50 AM, Karen Elisabeth Egede Nielsen wrote: > > Hi Lisong, > > Many thanks. > > This is still average considerations and the carryover of the argument to > the TCP friendly sub-domain of CUBIC > does not follow straightaway. > > I would suggest, in section 3.2 of the CUBIBC draft, not to make somethi= ng > that looks like a mathematical argument for that > AIMD(3*(1-beta)/(1+beta), beta) is a good approximation for TCP New Reno = in > the TCP friendly region. But rather refer to that based on the Somewhat irrelevant to the discussion, but I can't resist to point out that TCP NewReno (RFC 6582) really is NOT a new or better congestion control over TCP Reno. New Reno is merely a loss detection heuristic for multiple losses in a window before SACK was invented. It is hardly a congestion control. In Linu= x NewReno is never used when SACK is negotiated. So if you are thinking of AIMD, it is Reno. NewReno does not make that part newer :-) > evaluations of [FHP00], showing the general approximation (and fairness) = of > AIMD(3*(1-beta)/(1+beta), beta) compared to TCP New Reno, > this AIMD profile is used to define the TCP Friendly region and this prof= ile > is used as a replacement of the CUBIC window in this region. > In whatever way you want to formulate this... > > But I will stop pressing this point. Thanks for the patience ! :-) > > BR, Karen > > > -----Original Message----- > > From: Lisong Xu [mailto:xu@unl.edu] > > Sent: 30. marts 2016 17:02 > > To: Karen Elisabeth Egede Nielsen ; draft-ietf= - > > tcpm-cubic@ietf.org > > Cc: tcpm@ietf.org > > Subject: Re: TCP friendly formulation in CUBIC-draft ? > > > > Hi Karen, > > > > The equivalence between (alpha=3D1, beta=3D0.5) and (alpha=3D > is explained in the following paper. > > Equation (9). > > > > http://www.icir.org/tfrc/aimd.pdf > > > > Thanks > > Lisong > > > > > > > > On 3/30/2016 9:49 AM, Karen Elisabeth Egede Nielsen wrote: > > > Hi Lisong, > > > > > > Yes I understand that we are not speaking part 1). We are speaking th= e > > > CUBIC operation in TCP Friendly region only > > > > > > As far as I have understood the argumentation behind 2) you are makin= g > > > sure that CUBIC CWND is never lower than TCP Reno CWND. > > > But perhaps this has been a misunderstanding and you aim instead - as > > > you say right below - is to make sure that the _average_ CUBIC windo= w > > > is not lower than Reno ? > > > Either way the theoretical argumentation based on average window of > > > AIMD alone does not hold, but empirics may tell that it is ok. > > > > > > Please note that I am not trying to "kill" CUBIC at all. On the > > > contrary we are working to implement the algorithm. But still we want > > > to make sure to understand the aims right. > > > > > > BR, Karen > > > > > >> -----Original Message----- > > >> From: Lisong Xu [mailto:xu@unl.edu] > > >> Sent: 30. marts 2016 16:16 > > >> To: Karen Elisabeth Egede Nielsen ; > > >> draft-ietf- tcpm-cubic@ietf.org > > >> Cc: tcpm@ietf.org > > >> Subject: Re: TCP friendly formulation in CUBIC-draft ? > > >> > > >> Hi Karen, > > >> > > >> I guess I need to clarify that the code segment that we were > > >> discussing is only part of the "TCP friendliness". > > >> > > >> There are two parts of TCP friendliness. > > >> > > >> 1) make sure that CUBIC does not starve Reno in high BDP (bandwidth > > >> delay > > >> product) networks, and achieves a similar rate as Reno in low BDP > > >> networks. > > >> This is achieved mainly by the parameters of CUBIC. This is the > > >> typical and more important "meaning" of TCP friendliness. > > >> > > >> 2) make sure that CUBIC average rate is never lower than Reno in any > > >> networks. > > >> > > >> What we were discussing is only about part 2). > > >> > > >> Thanks > > >> Lisong > > >> > > >> > > >> On 3/30/2016 3:47 AM, Karen Elisabeth Egede Nielsen wrote: > > >>> HI Lisong, > > >>> > > >>> > > >>> > > >>> Thank you. > > >>> > > >>> > > >>> > > >>> Thanks a lot for your support in understanding the function ! > > >>> > > >>> I am happy that we seem to have reached a common understanding. > > >>> > > >>> > > >>> > > >>> So what we have is an argumentation of the TCP friendliness functio= n > > >>> which follows > > >>> > > >>> (1): Make CUBIC CWND be no less than what TCP New Reno would give > > >>> > > >>> > > >>> > > >>> And an implementation of CUBIC TCP friendliness function which does= : > > >>> > > >>> (2): Make CUBIC CWND be no less than what AIMD( 3*(1-beta)/(1+beta) > > >>> , beta ) would give > > >>> > > >>> > > >>> > > >>> I think that it is substantially more straightforward to make a > > >>> theoretical argumentation for why (1) is the right thing to do, tha= n > > >>> for why (2) is an appropriate thing to do. > > >>> > > >>> The theoretical arguments for (1) is in the CUBIC draft and in the > > >>> CUBIC papers. > > >>> > > >>> > > >>> > > >>> Not knowing so much about this from a general research perspective, > > >>> I wonder if there exists theoretical evidence > > >>> > > >>> for why (2) is appropriate or proper in respect of the argumentatio= n > > >>> of =E2=80=9CTCP friendliness=E2=80=9D. > > >>> > > >>> But also if one have a good understanding of the actual difference > > >>> in between (1) and (2), then this may serve as input for such an > > >>> argumentation > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Thu Mar 31 10:24:07 2016 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 7B0EC12D6D8 for ; Thu, 31 Mar 2016 10:24:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=tieto.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 Cum5p589kzQq for ; Thu, 31 Mar 2016 10:24:03 -0700 (PDT) Received: from mail-ig0-x229.google.com (mail-ig0-x229.google.com [IPv6:2607:f8b0:4001:c05::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 5141E12D6D2 for ; Thu, 31 Mar 2016 10:24:03 -0700 (PDT) Received: by mail-ig0-x229.google.com with SMTP id sy18so67820545igc.1 for ; Thu, 31 Mar 2016 10:24:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tieto.com; s=google; h=from:references:in-reply-to:mime-version:thread-index:date :message-id:subject:to:cc:content-transfer-encoding; bh=KV9HM1kz6DVB2OD8msXGG5por5eIN9TsD0SmQWEq/uk=; b=NvqZIJVHJi3Uq2vWB2ms9arw9EJ/UKqaoZMs8H2RkC3pqwARNV6g2oM1Bk7LdZ01dR 6O8xeLeLFtO8ricPf62QmYnhtDH5yfA5QQ5KQnwg1Yh3d3jcfoYXJ3VYK7sGhr+B+ww4 W9fv8m+Oc8ULPEvBLrmddP3jBedecWUkCeZpE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:references:in-reply-to:mime-version :thread-index:date:message-id:subject:to:cc :content-transfer-encoding; bh=KV9HM1kz6DVB2OD8msXGG5por5eIN9TsD0SmQWEq/uk=; b=dT8/U+Wx4TJIOcoSlKQBqoOQSEBKoBQo/xgpkyXg84a17VconYqel6LkwnUKAAaXXt KHZTcQCORotxeM3h4Uy7GeRH1kXYe1IG8k6TmV5ONA0Fqz5a7nFVf5AjiTKWXIlsHfiW Li5e7G8oW0+NT6NEbvFsy03LL8R169dcjwbBEXuezpCMg737PExVx8i4rxpujmy3/xmX bTPd13f5aIleZsZHTAKvAcMQ7KQc2YABy9whmEDIFStHoOEZJdrmPVJBYAwsuEoYEIH3 SWmLBhhFLRBcozDYcS5Rp6YFlQ3r73QrELkv2KPGbJYfXTeythc32hm4nNhlXEipUpYI Pkjw== X-Gm-Message-State: AD7BkJIs4yBIeksXSdZzVnoPmLrQ4KcpAQGB9SGyfpI6cAXDpA4yOT0bQhD0vBkP6+wyfZ1i9hLK3UY15SqNYeZbnYgS9n18xh+IKqHkQNtV4N9XoVl+YioDrEe03LGlmrpmX+0= X-Received: by 10.50.30.101 with SMTP id r5mr2468421igh.2.1459445042484; Thu, 31 Mar 2016 10:24:02 -0700 (PDT) From: Karen Elisabeth Egede Nielsen References: <28265_1458030005_u2F8K4us025832_bb0b000b861f2a1e54225a8662b87a69@mail.gmail.com> <56E8D363.2080801@unl.edu> <14035_1458115854_u2G8AskH024517_22021b5df9cac80a9d8c0ba9ea526ef4@mail.gmail.com> <56ECD07A.3010407@unl.edu> <56FABA13.30102@unl.edu> <12368_1459328224_u2U8v3nZ025730_e84025e79d2ea1449205fe7a7b7c1059@mail.gmail.com> <56FBDF8F.1010805@unl.edu> <16322_1459349393_u2UEnqW7004410_feff4fc139a45c2519a3d806e052cde7@mail.gmail.com> <56FBEA6C.1060502@unl.edu> <9241ef51bda537b7a52e00c94a1e0272@mail.gmail.com> In-Reply-To: MIME-Version: 1.0 X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQIbw19NaMpQgnr/3M9AdWgbjB7BugM9Fpq6AnWoUP4BZPwWCQH4X04GAdXMnMUBdtOJ/wIsvi3RAQgFcF0Al1cUewFor0QHAm1o6heeP2I+IA== Date: Thu, 31 Mar 2016 19:24:00 +0200 Message-ID: To: Yuchung Cheng Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-DomainID: tieto.com Archived-At: Cc: tcpm@ietf.org, draft-ietf-tcpm-cubic@ietf.org Subject: Re: [tcpm] TCP friendly formulation in CUBIC-draft ? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 31 Mar 2016 17:24:06 -0000 HI Yuchung, I refer to RFC5681 & RFC6675 as Reno (or New Reno) for TCP with SACK. For TCP without SACK we can discuss the differences of Reno or New Reno, in regard to whether RFC6582 is implemented or not, but I was not thinking about non-SACK here at all. The term in the CUBIC draft is "applicable to all Reno style TCP standards and their variants, including TCP-RENO [RFC5681], TCP-NewReno [RFC6582], TCP- SACK [RFC2018], SCTP [RFC4960]" I did question earlier on the list why there is no reference to RFC6675, bu= t I have not received any answer yet, I think. Anyway the argument in the CUBIC draft and in prior CUBID research refers t= o Reno or to standard TCP CC. I would not have thought that standard TCP CC or that TCP New Reno (or Reno= ) CC for TCP SACK generally is perceived as referring to any AIMD with any alpha or beta values or with any alpha or beta values that gives the same average window as RFC5681&RFC6675. BR, Karen > -----Original Message----- > From: Yuchung Cheng [mailto:ycheng@google.com] > Sent: 31. marts 2016 19:03 > To: Karen Elisabeth Egede Nielsen > Cc: Lisong Xu ; draft-ietf-tcpm-cubic@ietf.org; tcpm@ietf.org > Extensions > Subject: Re: [tcpm] TCP friendly formulation in CUBIC-draft ? > > On Thu, Mar 31, 2016 at 3:50 AM, Karen Elisabeth Egede Nielsen > wrote: > > > > Hi Lisong, > > > > Many thanks. > > > > This is still average considerations and the carryover of the argument > > to the TCP friendly sub-domain of CUBIC does not follow straightaway. > > > > I would suggest, in section 3.2 of the CUBIBC draft, not to make > > something that looks like a mathematical argument for that > > AIMD(3*(1-beta)/(1+beta), beta) is a good approximation for TCP New > > Reno in the TCP friendly region. But rather refer to that based on the > Somewhat irrelevant to the discussion, but I can't resist to point out > that TCP > NewReno (RFC 6582) really is NOT a new or better congestion control over > TCP Reno. > > New Reno is merely a loss detection heuristic for multiple losses in a > window > before SACK was invented. It is hardly a congestion control. In Linux > NewReno is never used when SACK is negotiated. > > So if you are thinking of AIMD, it is Reno. NewReno does not make that > part > newer :-) > > > evaluations of [FHP00], showing the general approximation (and > > fairness) of AIMD(3*(1-beta)/(1+beta), beta) compared to TCP New Reno, > > this AIMD profile is used to define the TCP Friendly region and this > > profile is used as a replacement of the CUBIC window in this region. > > In whatever way you want to formulate this... > > > > But I will stop pressing this point. Thanks for the patience ! :-) > > > > BR, Karen > > > > > -----Original Message----- > > > From: Lisong Xu [mailto:xu@unl.edu] > > > Sent: 30. marts 2016 17:02 > > > To: Karen Elisabeth Egede Nielsen ; > > > draft-ietf- tcpm-cubic@ietf.org > > > Cc: tcpm@ietf.org > > > Subject: Re: TCP friendly formulation in CUBIC-draft ? > > > > > > Hi Karen, > > > > > > The equivalence between (alpha=3D1, beta=3D0.5) and (alpha=3D > > is explained in the following paper. > > > Equation (9). > > > > > > http://www.icir.org/tfrc/aimd.pdf > > > > > > Thanks > > > Lisong > > > > > > > > > > > > On 3/30/2016 9:49 AM, Karen Elisabeth Egede Nielsen wrote: > > > > Hi Lisong, > > > > > > > > Yes I understand that we are not speaking part 1). We are speaking > > > > the CUBIC operation in TCP Friendly region only > > > > > > > > As far as I have understood the argumentation behind 2) you are > > > > making sure that CUBIC CWND is never lower than TCP Reno CWND. > > > > But perhaps this has been a misunderstanding and you aim instead - > > > > as you say right below - is to make sure that the _average_ CUBIC > > > > window is not lower than Reno ? > > > > Either way the theoretical argumentation based on average window > > > > of AIMD alone does not hold, but empirics may tell that it is ok. > > > > > > > > Please note that I am not trying to "kill" CUBIC at all. On the > > > > contrary we are working to implement the algorithm. But still we > > > > want to make sure to understand the aims right. > > > > > > > > BR, Karen > > > > > > > >> -----Original Message----- > > > >> From: Lisong Xu [mailto:xu@unl.edu] > > > >> Sent: 30. marts 2016 16:16 > > > >> To: Karen Elisabeth Egede Nielsen ; > > > >> draft-ietf- tcpm-cubic@ietf.org > > > >> Cc: tcpm@ietf.org > > > >> Subject: Re: TCP friendly formulation in CUBIC-draft ? > > > >> > > > >> Hi Karen, > > > >> > > > >> I guess I need to clarify that the code segment that we were > > > >> discussing is only part of the "TCP friendliness". > > > >> > > > >> There are two parts of TCP friendliness. > > > >> > > > >> 1) make sure that CUBIC does not starve Reno in high BDP > > > >> (bandwidth delay > > > >> product) networks, and achieves a similar rate as Reno in low BDP > > > >> networks. > > > >> This is achieved mainly by the parameters of CUBIC. This is the > > > >> typical and more important "meaning" of TCP friendliness. > > > >> > > > >> 2) make sure that CUBIC average rate is never lower than Reno in > > > >> any networks. > > > >> > > > >> What we were discussing is only about part 2). > > > >> > > > >> Thanks > > > >> Lisong > > > >> > > > >> > > > >> On 3/30/2016 3:47 AM, Karen Elisabeth Egede Nielsen wrote: > > > >>> HI Lisong, > > > >>> > > > >>> > > > >>> > > > >>> Thank you. > > > >>> > > > >>> > > > >>> > > > >>> Thanks a lot for your support in understanding the function ! > > > >>> > > > >>> I am happy that we seem to have reached a common understanding. > > > >>> > > > >>> > > > >>> > > > >>> So what we have is an argumentation of the TCP friendliness > > > >>> function which follows > > > >>> > > > >>> (1): Make CUBIC CWND be no less than what TCP New Reno would > > > >>> give > > > >>> > > > >>> > > > >>> > > > >>> And an implementation of CUBIC TCP friendliness function which > does: > > > >>> > > > >>> (2): Make CUBIC CWND be no less than what AIMD( > > > >>> 3*(1-beta)/(1+beta) , beta ) would give > > > >>> > > > >>> > > > >>> > > > >>> I think that it is substantially more straightforward to make a > > > >>> theoretical argumentation for why (1) is the right thing to do, > > > >>> than for why (2) is an appropriate thing to do. > > > >>> > > > >>> The theoretical arguments for (1) is in the CUBIC draft and in > > > >>> the CUBIC papers. > > > >>> > > > >>> > > > >>> > > > >>> Not knowing so much about this from a general research > > > >>> perspective, I wonder if there exists theoretical evidence > > > >>> > > > >>> for why (2) is appropriate or proper in respect of the > > > >>> argumentation of =E2=80=9CTCP friendliness=E2=80=9D. > > > >>> > > > >>> But also if one have a good understanding of the actual > > > >>> difference in between (1) and (2), then this may serve as input > > > >>> for such an argumentation > > > > _______________________________________________ > > tcpm mailing list > > tcpm@ietf.org > > https://www.ietf.org/mailman/listinfo/tcpm From nobody Thu Mar 31 17:05:25 2016 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 14CF512D179 for ; Thu, 31 Mar 2016 17:05:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.711 X-Spam-Level: X-Spam-Status: No, score=-2.711 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_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 jokYZnEPug-C for ; Thu, 31 Mar 2016 17:05:21 -0700 (PDT) Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::235]) (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 169B412D1D5 for ; Thu, 31 Mar 2016 17:05:21 -0700 (PDT) Received: by mail-wm0-x235.google.com with SMTP id 20so2634543wmh.1 for ; Thu, 31 Mar 2016 17:05:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=Q+0e9LyjBc1GTlqr1k0wtzA60lcnBeuLH6QvxSF7ZB8=; b=mNW7u+i+jbSVOfGr8KiNdPioqAMkOJLAipNnVqtzb2hQU+INH3DvH/IWpYdaIjcDaE 5cQCrMEpGwPN+9GRhk+k+m43eu/1ZlbWyK3O9E1EKvaKdtFTDcVArAcMuubt8J3Xls/D cWZ1qVh3BnEYvMvvkEbydjgNZjZum8aH89mM0Uw0SCm1EmiWHL4CSdpgvRpKw4pxd8kw 4Tg0IlkHFeZKcVANI4FAy34EARO4DSA5lUNQd5crAd1riG10JFroRL+xyWy7/gkcc6OL PoFa9aILy7ivJTHrBJlmaBSaO5IqEKZbudmYyhKCOzb69HVaIzYX+Tdb5bEvk3Y26xwG iIjQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=Q+0e9LyjBc1GTlqr1k0wtzA60lcnBeuLH6QvxSF7ZB8=; b=jd+9gvxv12axOX3y/tz52vJuEAEeRrO2SZTiMw65OSnkp+oDsnOMnWkQoZZ/f3coQA dmxjZqGdjg9Qb8cO65lOguJynVN0yeqQ5lPGL86sEcq5BHubE3kkoUvbpPqGe+8VIWiT XHvoZMGuxMIMt3qx1zrT/xAukUUREBL50GF7ygZ9T2xbRi4XcTKW9jQiZpPMDk6pBX+q uH5ATnS1r6aTzDtJczXBW3hnlIzO+/WkH4wvdSs3dIdSYJpPOzLeHDkYBQLWZd1pY92n 3E9GODEiiC/knbFhCHLfYCWm80VnthUXOCumS1C7LNdhM+evTZRCt2FOj2kXHsyDR0mp Fuow== X-Gm-Message-State: AD7BkJKlDlCrhyEJD2pRb73Tr69N1na858tgXZJoGFcXWcfF013LuAcLf2ZoOXFUjQzQ41+2TL8bIuJTQJyOJBaK X-Received: by 10.194.6.234 with SMTP id e10mr5689535wja.118.1459469119236; Thu, 31 Mar 2016 17:05:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.222.131 with HTTP; Thu, 31 Mar 2016 17:04:39 -0700 (PDT) In-Reply-To: References: <28265_1458030005_u2F8K4us025832_bb0b000b861f2a1e54225a8662b87a69@mail.gmail.com> <56E8D363.2080801@unl.edu> <14035_1458115854_u2G8AskH024517_22021b5df9cac80a9d8c0ba9ea526ef4@mail.gmail.com> <56ECD07A.3010407@unl.edu> <56FABA13.30102@unl.edu> <12368_1459328224_u2U8v3nZ025730_e84025e79d2ea1449205fe7a7b7c1059@mail.gmail.com> <56FBDF8F.1010805@unl.edu> <16322_1459349393_u2UEnqW7004410_feff4fc139a45c2519a3d806e052cde7@mail.gmail.com> <56FBEA6C.1060502@unl.edu> <9241ef51bda537b7a52e00c94a1e0272@mail.gmail.com> From: Yuchung Cheng Date: Thu, 31 Mar 2016 17:04:39 -0700 Message-ID: To: Karen Elisabeth Egede Nielsen Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "tcpm@ietf.org Extensions" , draft-ietf-tcpm-cubic@ietf.org Subject: Re: [tcpm] TCP friendly formulation in CUBIC-draft ? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 01 Apr 2016 00:05:24 -0000 On Thu, Mar 31, 2016 at 10:24 AM, Karen Elisabeth Egede Nielsen wrote: > HI Yuchung, > > I refer to RFC5681 & RFC6675 as Reno (or New Reno) for TCP with SACK. > > For TCP without SACK we can discuss the differences of Reno or New Reno, = in > regard to whether RFC6582 is implemented or not, > but I was not thinking about non-SACK here at all. > > The term in the CUBIC draft is "applicable to all Reno style TCP standard= s > and their > variants, including TCP-RENO [RFC5681], TCP-NewReno [RFC6582], TCP- > SACK [RFC2018], SCTP [RFC4960]" > > I did question earlier on the list why there is no reference to RFC6675, = but > I have not received any answer yet, I think. It'd be nice to mention that indeed. RFC6675 and NewReno are two distinct loss recovery algorithms for SACK and non-SACK respectively. The former is much more faster. The latter takes N RTT to recover N losses in a window. > > Anyway the argument in the CUBIC draft and in prior CUBID research refers= to > Reno or to standard TCP CC. > > I would not have thought that standard TCP CC or that TCP New Reno (or Re= no) > CC for TCP SACK > generally is perceived as referring to any AIMD with any alpha or beta > values or with any alpha or beta values that > gives the same average window as RFC5681&RFC6675. > > BR, Karen > >> -----Original Message----- >> From: Yuchung Cheng [mailto:ycheng@google.com] >> Sent: 31. marts 2016 19:03 >> To: Karen Elisabeth Egede Nielsen >> Cc: Lisong Xu ; draft-ietf-tcpm-cubic@ietf.org; tcpm@ietf.or= g >> Extensions >> Subject: Re: [tcpm] TCP friendly formulation in CUBIC-draft ? >> >> On Thu, Mar 31, 2016 at 3:50 AM, Karen Elisabeth Egede Nielsen >> wrote: >> > >> > Hi Lisong, >> > >> > Many thanks. >> > >> > This is still average considerations and the carryover of the argument >> > to the TCP friendly sub-domain of CUBIC does not follow straightaway. >> > >> > I would suggest, in section 3.2 of the CUBIBC draft, not to make >> > something that looks like a mathematical argument for that >> > AIMD(3*(1-beta)/(1+beta), beta) is a good approximation for TCP New >> > Reno in the TCP friendly region. But rather refer to that based on the >> Somewhat irrelevant to the discussion, but I can't resist to point out >> that TCP >> NewReno (RFC 6582) really is NOT a new or better congestion control over >> TCP Reno. >> >> New Reno is merely a loss detection heuristic for multiple losses in a >> window >> before SACK was invented. It is hardly a congestion control. In Linux >> NewReno is never used when SACK is negotiated. >> >> So if you are thinking of AIMD, it is Reno. NewReno does not make that >> part >> newer :-) >> >> > evaluations of [FHP00], showing the general approximation (and >> > fairness) of AIMD(3*(1-beta)/(1+beta), beta) compared to TCP New Reno, >> > this AIMD profile is used to define the TCP Friendly region and this >> > profile is used as a replacement of the CUBIC window in this region. >> > In whatever way you want to formulate this... >> > >> > But I will stop pressing this point. Thanks for the patience ! :-) >> > >> > BR, Karen >> > >> > > -----Original Message----- >> > > From: Lisong Xu [mailto:xu@unl.edu] >> > > Sent: 30. marts 2016 17:02 >> > > To: Karen Elisabeth Egede Nielsen ; >> > > draft-ietf- tcpm-cubic@ietf.org >> > > Cc: tcpm@ietf.org >> > > Subject: Re: TCP friendly formulation in CUBIC-draft ? >> > > >> > > Hi Karen, >> > > >> > > The equivalence between (alpha=3D1, beta=3D0.5) and (alpha=3D >> > is explained in the following paper. >> > > Equation (9). >> > > >> > > http://www.icir.org/tfrc/aimd.pdf >> > > >> > > Thanks >> > > Lisong >> > > >> > > >> > > >> > > On 3/30/2016 9:49 AM, Karen Elisabeth Egede Nielsen wrote: >> > > > Hi Lisong, >> > > > >> > > > Yes I understand that we are not speaking part 1). We are speaking >> > > > the CUBIC operation in TCP Friendly region only >> > > > >> > > > As far as I have understood the argumentation behind 2) you are >> > > > making sure that CUBIC CWND is never lower than TCP Reno CWND. >> > > > But perhaps this has been a misunderstanding and you aim instead - >> > > > as you say right below - is to make sure that the _average_ CUBIC >> > > > window is not lower than Reno ? >> > > > Either way the theoretical argumentation based on average window >> > > > of AIMD alone does not hold, but empirics may tell that it is ok. >> > > > >> > > > Please note that I am not trying to "kill" CUBIC at all. On the >> > > > contrary we are working to implement the algorithm. But still we >> > > > want to make sure to understand the aims right. >> > > > >> > > > BR, Karen >> > > > >> > > >> -----Original Message----- >> > > >> From: Lisong Xu [mailto:xu@unl.edu] >> > > >> Sent: 30. marts 2016 16:16 >> > > >> To: Karen Elisabeth Egede Nielsen ; >> > > >> draft-ietf- tcpm-cubic@ietf.org >> > > >> Cc: tcpm@ietf.org >> > > >> Subject: Re: TCP friendly formulation in CUBIC-draft ? >> > > >> >> > > >> Hi Karen, >> > > >> >> > > >> I guess I need to clarify that the code segment that we were >> > > >> discussing is only part of the "TCP friendliness". >> > > >> >> > > >> There are two parts of TCP friendliness. >> > > >> >> > > >> 1) make sure that CUBIC does not starve Reno in high BDP >> > > >> (bandwidth delay >> > > >> product) networks, and achieves a similar rate as Reno in low BDP >> > > >> networks. >> > > >> This is achieved mainly by the parameters of CUBIC. This is the >> > > >> typical and more important "meaning" of TCP friendliness. >> > > >> >> > > >> 2) make sure that CUBIC average rate is never lower than Reno in >> > > >> any networks. >> > > >> >> > > >> What we were discussing is only about part 2). >> > > >> >> > > >> Thanks >> > > >> Lisong >> > > >> >> > > >> >> > > >> On 3/30/2016 3:47 AM, Karen Elisabeth Egede Nielsen wrote: >> > > >>> HI Lisong, >> > > >>> >> > > >>> >> > > >>> >> > > >>> Thank you. >> > > >>> >> > > >>> >> > > >>> >> > > >>> Thanks a lot for your support in understanding the function ! >> > > >>> >> > > >>> I am happy that we seem to have reached a common understanding. >> > > >>> >> > > >>> >> > > >>> >> > > >>> So what we have is an argumentation of the TCP friendliness >> > > >>> function which follows >> > > >>> >> > > >>> (1): Make CUBIC CWND be no less than what TCP New Reno would >> > > >>> give >> > > >>> >> > > >>> >> > > >>> >> > > >>> And an implementation of CUBIC TCP friendliness function which >> does: >> > > >>> >> > > >>> (2): Make CUBIC CWND be no less than what AIMD( >> > > >>> 3*(1-beta)/(1+beta) , beta ) would give >> > > >>> >> > > >>> >> > > >>> >> > > >>> I think that it is substantially more straightforward to make a >> > > >>> theoretical argumentation for why (1) is the right thing to do, >> > > >>> than for why (2) is an appropriate thing to do. >> > > >>> >> > > >>> The theoretical arguments for (1) is in the CUBIC draft and in >> > > >>> the CUBIC papers. >> > > >>> >> > > >>> >> > > >>> >> > > >>> Not knowing so much about this from a general research >> > > >>> perspective, I wonder if there exists theoretical evidence >> > > >>> >> > > >>> for why (2) is appropriate or proper in respect of the >> > > >>> argumentation of =E2=80=9CTCP friendliness=E2=80=9D. >> > > >>> >> > > >>> But also if one have a good understanding of the actual >> > > >>> difference in between (1) and (2), then this may serve as input >> > > >>> for such an argumentation >> > >> > _______________________________________________ >> > tcpm mailing list >> > tcpm@ietf.org >> > https://www.ietf.org/mailman/listinfo/tcpm