From mthornbu@adobe.com Fri May 3 11:41:41 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAAB721F8930 for ; Fri, 3 May 2013 11:41:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w0VGgMlXjX1S for ; Fri, 3 May 2013 11:41:27 -0700 (PDT) Received: from exprod6og119.obsmtp.com (exprod6og119.obsmtp.com [64.18.1.234]) by ietfa.amsl.com (Postfix) with ESMTP id 66E6021F965C for ; Fri, 3 May 2013 11:41:21 -0700 (PDT) Received: from outbound-smtp-2.corp.adobe.com ([193.104.215.16]) by exprod6ob119.postini.com ([64.18.5.12]) with SMTP ID DSNKUYQE0H6wjilwE8th75aucMfJGcXgcPaX@postini.com; Fri, 03 May 2013 11:41:21 PDT Received: from inner-relay-4.eur.adobe.com (inner-relay-4b [10.128.4.237]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id r43IfJ99026100 for ; Fri, 3 May 2013 11:41:19 -0700 (PDT) Received: from nahub02.corp.adobe.com (nahub02.corp.adobe.com [10.8.189.98]) by inner-relay-4.eur.adobe.com (8.12.10/8.12.9) with ESMTP id r43IfHGU010072 for ; Fri, 3 May 2013 11:41:18 -0700 (PDT) Received: from SJ1SWM219.corp.adobe.com (10.5.77.61) by nahub02.corp.adobe.com (10.8.189.98) with Microsoft SMTP Server (TLS) id 8.3.298.1; Fri, 3 May 2013 11:41:17 -0700 Received: from nambx05.corp.adobe.com ([10.8.189.124]) by SJ1SWM219.corp.adobe.com ([fe80::d55c:7209:7a34:fcf7%11]) with mapi; Fri, 3 May 2013 11:41:16 -0700 From: Michael Thornburgh To: "tsvwg@ietf.org" Date: Fri, 3 May 2013 11:41:14 -0700 Thread-Topic: [tsvwg] feedback request: draft-thornburgh-adobe-rtmfp Thread-Index: Ac39s2vnDiiS8429RMSUZn9wy7XbEwNU2fdgC7898bADikWjoA== Message-ID: <02485FF93524F8408ECA9608E47D9F20098D3904CF@nambx05.corp.adobe.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [tsvwg] feedback request: draft-thornburgh-adobe-rtmfp X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 May 2013 18:41:41 -0000 there is a new revision of draft-thornburgh-adobe-rtmfp addressing the deta= iled on- and off-list comments and feedback from Richard Scheffenegger. th= ank you Richard. --- Filename: draft-thornburgh-adobe-rtmfp Revision: 07 Title: Adobe's Secure Real-Time Media Flow Protocol Creation date: 2013-05-02 Group: Individual Submission Number of pages: 107 URL: http://www.ietf.org/internet-drafts/draft-thornburgh-adobe= -rtmfp-07.txt Status: http://datatracker.ietf.org/doc/draft-thornburgh-adobe-rtm= fp Htmlized: http://tools.ietf.org/html/draft-thornburgh-adobe-rtmfp-07 Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-thornburgh-adobe-= rtmfp-07 IPR: https://datatracker.ietf.org/ipr/1942/ Abstract: This memo describes the Secure Real-Time Media Flow Protocol (RTMFP), an endpoint-to-endpoint communication protocol designed to securely transport parallel flows of real-time video, audio, and data messages, as well as bulk data, over IP networks. RTMFP has features making it effective for peer-to-peer (P2P) as well as client-server communications, even when Network Address Translators (NATs) are used. --- -michael thornburgh > From: Michael Thornburgh > Sent: Monday, April 15, 2013 11:25 AM >=20 > there is a new revision of draft-thornburgh-adobe-rtmfp addressing commen= ts and feedback i received at > the Orlando meeting. new since the Feb 14th revision: >=20 > * a new appendix describes a real-time-appropriate window-based congest= ion control algorithm to use > with RTMFP. this algorithm happens to be what Flash Player and related pr= oducts implement at the time > of writing. >=20 > * a missing transition condition was added to the Session state transit= ion diagram (figure 7). >=20 > * a new section (3.5.1.7) describes load distribution and fault toleran= ce. >=20 [...] >=20 > -michael thornburgh >=20 >=20 > > From: Michael Thornburgh > > Sent: Thursday, February 14, 2013 3:05 PM > > > > there is a new revision of draft-thornburgh-adobe-rtmfp addressing deta= iled feedback i received from > > the Responsible AD. > > > [...] > > > > -michael thornburgh > > > > > > > From: Michael Thornburgh > > > Sent: Monday, January 28, 2013 3:59 PM > > > > > > hello TSV Working Group. > > > > > > i have recently uploaded an Internet-Draft describing a vendor networ= k transport protocol, "Secure > > > Real-Time Media Flow Protocol (RTMFP)" from Adobe Systems Incorporate= d. this protocol is the > > > foundation for the real-time and peer-to-peer communication capabilit= ies in Flash Player and > related > > > Adobe products, which are widely deployed on the Internet today. we = believe this transport > protocol > > > has applicability beyond Flash and will be of interest to the Interne= t community. this is the > > > protocol presented by Matthew Kaufman to the TSV Area at IETF-77. > > > > > > we are looking toward this specification being published as an Inform= ational RFC. to that end i > am > > > soliciting feedback, comments, and reviews of the I-D to gauge commun= ity interest and to help us > > > improve its quality. > > > > > > there is IPR associated with this specification, which i have disclos= ed along with a royalty-free > > > license declaration. that disclosure/declaration is linked from the = HTML-ized I-D page. > > > > > [...] > > > > > > thank you. > > > > > > -michael thornburgh From Karen.Nielsen@tieto.com Mon May 6 03:46:56 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B70D21F8556 for ; Mon, 6 May 2013 03:46:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Wazpe-dNBv8 for ; Mon, 6 May 2013 03:46:38 -0700 (PDT) Received: from ebb06.tieto.com (ebb06.tieto.com [131.207.168.38]) by ietfa.amsl.com (Postfix) with ESMTP id 7C7E121F8FA7 for ; Mon, 6 May 2013 03:46:37 -0700 (PDT) X-AuditID: 83cfa826-b7f4b6d000000a28-cb-51878a0cc70f Received: from FIHGA-EXHUB01.eu.tieto.com ( [131.207.136.34]) by ebb06.tieto.com (SMTP Mailer) with SMTP id 8D.DE.02600.C0A87815; Mon, 6 May 2013 13:46:36 +0300 (EEST) Received: from EXMB03.eu.tieto.com ([169.254.1.39]) by FIHGA-EXHUB01.eu.tieto.com ([131.207.136.34]) with mapi; Mon, 6 May 2013 13:46:35 +0300 From: To: Date: Mon, 6 May 2013 13:46:34 +0300 Thread-Topic: 10 IW also for SCTP Thread-Index: Ac5KRvl8lgQKZSOERNiDcgX1DkuDXw== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CF340E42AED0874C81947E18863DE77B29A8EE1938EXMB03eutieto_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrNIsWRmVeSWpSXmKPExsXSfL5DSZenqz3QYMNyAYtjb+6yOTB6LFny kymAMYrLJiU1J7MstUjfLoEr49WfVSwFE0wq5i7ex9bAuF+vi5GDQ0LARGLqf5cuRk4gU0zi wr31bF2MXBxCAqsYJQ7cmMoC4UxilDj59wMzSBWbgLzE3L2r2EGaRQREJLp36IOYLAIqEvcm GIBUCAvISGz58oYVxBYRUJS4vfk4C4StJ/Ft8k4wm1fAR+LY+qNgExmB9n4/tYYJxGYWEJe4 9WQ+E8Q9AhJL9pxnhrBFJV4+/scKUS8qcad9PSNEfb5E836Iel4BQYmTM5+wTGAUmoVk1Cwk ZbOQlEHEdSQW7P7EBmFrSyxb+JoZxj5z4DETsvgCRvZVjPypSUkGZnolmakl+XrJ+bmbGMEx sEJtB+OzB1KHGAU4GJV4eAuetAUKsSaWFVfmHmKU5GBSEuX939EeKMSXlJ9SmZFYnBFfVJqT WnyIUYKDWUmE12cvUDlvSmJlVWpRPkxKhoNDSYKXtROoTbAoNT21Ii0zBxjpMGkmDk6Qdh6g 9m8go3mLCxJzizPTIfKnGBWlxHm3gyQEQBIZpXlwvbA084pRHOhYYV5VkBU8wBQF1/0KaDAT 0OAEPrDBJYkIKakGRjlLiYD3F05vyfF83FF+RsbtxUsfUYYtPyvOaQfOc3s7f0ZE0qvt6y6v DDq1ouiTTrJxzrEH8jrtj+ZIvslt2d5yUG7JvI7LETeuSUxNaOh5t/2Zwcn3YXl3TOeJztmm pDjZ4GM4Y879k7UNj9sv2FquOPnWfuNdB0Oj/TMMcxSfWU6am27+dJkSS3FGoqEWc1FxIgAq egHmDgMAAA== Subject: [tsvwg] 10 IW also for SCTP X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 May 2013 10:46:56 -0000 --_000_CF340E42AED0874C81947E18863DE77B29A8EE1938EXMB03eutieto_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Experimental RFC6928 proposes to increase initial window for TCP from the 4= segments from RFC3390 to 10 segments. >From RC2960 to RFC4960, SCTP was augmented to operate with initial window o= f 4MTUs following RFC3390. Indeed RFC4460 says the following: "RFC 2960 was published with the intention of having the same congestion control properties as TCP. Since the publication of RFC 2960, TCP's initial congestion window size has been increased via RFC 3390. This same update will be needed for SCTP to keep SCTP's congestion control properties equivalent to that of TCP." >From a technical perspective there does not seem to be anything in RFC6928 = that is particularly specific to TCP compared with SCTP and based on this o= bservation I suppose that it would be equally relevant to think about intro= ducing an equivalent experimental usage of larger IWs, up to 10MTUs, also f= or SCTP and to have such usage be appropriately specified at some point in = time. I wonder if this is also how the tsvwg sees this ? Thanks! BR, Karen --_000_CF340E42AED0874C81947E18863DE77B29A8EE1938EXMB03eutieto_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,<= /span>

 

Exp= erimental RFC6928 proposes to increase initial window for TCP from the 4 se= gments from RFC3390

to 10 segments.=

 

From R= C2960 to RFC4960, SCTP was augmented to operate with initial window of 4MTU= s following RFC3390.

Indeed RFC4460 says = the following:

 

"RFC 2960 was published with the intention of having the = same

   congestion control prope= rties as TCP.  Since the publication of RFC

   2960, TCP's initial congestion window size has been inc= reased via RFC

   3390.  Th= is same update will be needed for SCTP to keep SCTP's

=

   congestion control properties equivalent to that o= f TCP."

 

<= p class=3DMsoNormal>From a technical perspective there does not seem to be anything = in RFC6928 that is particularly specific to TCP compared with SCTP and base= d on this observation I suppose that it would be equally relevant to think = about introducing an equivalent experimental usage of larger IWs, up to 10M= TUs, also for SCTP and to have such usage be appropriately specified at som= e point in time.

 <= /p>

I wonder if this is also how the tsvwg sees this ?

 

Thanks!

 

BR, K= aren

= --_000_CF340E42AED0874C81947E18863DE77B29A8EE1938EXMB03eutieto_-- From Michael.Tuexen@lurchi.franken.de Mon May 6 03:57:23 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6F2F21F8D7A for ; Mon, 6 May 2013 03:57:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U2PN75Il-+ey for ; Mon, 6 May 2013 03:57:23 -0700 (PDT) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by ietfa.amsl.com (Postfix) with ESMTP id 17DA121F8C23 for ; Mon, 6 May 2013 03:57:22 -0700 (PDT) Received: from [192.168.1.100] (p508F3DA6.dip0.t-ipconnect.de [80.143.61.166]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id A48B51C105786; Mon, 6 May 2013 12:57:20 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Michael Tuexen In-Reply-To: Date: Mon, 6 May 2013 12:57:20 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: X-Mailer: Apple Mail (2.1283) Cc: tsvwg@ietf.org Subject: Re: [tsvwg] 10 IW also for SCTP X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 May 2013 10:57:23 -0000 On May 6, 2013, at 12:46 PM, = wrote: > Hi, > =20 > Experimental RFC6928 proposes to increase initial window for TCP from = the 4 segments from RFC3390 > to 10 segments. > =20 > =46rom RC2960 to RFC4960, SCTP was augmented to operate with initial = window of 4MTUs following RFC3390. > Indeed RFC4460 says the following: > =20 > "RFC 2960 was published with the intention of having the same > congestion control properties as TCP. Since the publication of RFC > 2960, TCP's initial congestion window size has been increased via = RFC > 3390. This same update will be needed for SCTP to keep SCTP's > congestion control properties equivalent to that of TCP." > =20 > =46rom a technical perspective there does not seem to be anything in = RFC6928 that is particularly specific to TCP compared with SCTP and = based on this observation I suppose that it would be equally relevant to = think about introducing an equivalent experimental usage of larger IWs, = up to 10MTUs, also for SCTP and to have such usage be appropriately = specified at some point in time. > =20 > I wonder if this is also how the tsvwg sees this ? One difference between SCTP and TCP is that SCTP uses a Max.Burst = parameter. So you won't send 10 packets without changing also the Max.Burst parameter. In the FreeBSD = implementation you can tune the Max.Burst parameter and the initial window via sysctls. Best regards Michael > =20 > Thanks! > =20 > BR, Karen From Karen.Nielsen@tieto.com Mon May 6 04:02:43 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F24221F902C for ; Mon, 6 May 2013 04:02:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5xpCKfw5XZ4Q for ; Mon, 6 May 2013 04:02:32 -0700 (PDT) Received: from ebb05.tieto.com (ebb05.tieto.com [131.207.168.36]) by ietfa.amsl.com (Postfix) with ESMTP id 266DE21F8FA5 for ; Mon, 6 May 2013 04:02:31 -0700 (PDT) X-AuditID: 83cfa824-b7ef76d00000627b-dd-51878dc61fd2 Received: from FIHGA-EXHUB01.eu.tieto.com ( [131.207.136.34]) by ebb05.tieto.com (SMTP Mailer) with SMTP id 40.5D.25211.6CD87815; Mon, 6 May 2013 14:02:30 +0300 (EEST) Received: from EXMB03.eu.tieto.com ([169.254.1.39]) by FIHGA-EXHUB01.eu.tieto.com ([131.207.136.34]) with mapi; Mon, 6 May 2013 14:02:30 +0300 From: To: Date: Mon, 6 May 2013 14:02:29 +0300 Thread-Topic: [tsvwg] 10 IW also for SCTP Thread-Index: Ac5KSHy9fhA1qQJESlWYMqF+tZCx+wAAFhAQ Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrAKsWRmVeSWpSXmKPExsXSfL5DSfdYb3ugwZ2HlhYXm5YwWhx7c5fN gcljyZKfTB4bWnYwBTBFcdmkpOZklqUW6dslcGX8mtXHUjCPteLB/dtMDYyNLF2MnBwSAiYS 257eYoSwxSQu3FvP1sXIxSEksIpRYumEX6wQziRGiWv9b1lBqtgE5CXm7l3FDmKLCKhJ3Dv9 ECjOwcEsICIx57cGSJhFQEXiz4a1TCC2sICGxN/W1UwQ5ZoSLbfXQLUaSWzp384MYvMK+EhM 376dHWJXO6NE98t9bCAJTgFXie0n74Ndygh03fdTa8AGMQuIS9x6Mp8J4moBiSV7zjND2KIS Lx//Y4WoF5W4076eEaJeR2LB7k9sELa2xLKFr6EWC0qcnPmEZQKj2CwkY2chaZmFpGUWkpYF jCyrGPlTk5IMTPVKMlNL8vWS83M3MYKjZoXKDsazD6QOMQpwMCrx8BY+aQsUYk0sK67MPcQo ycGkJMr7v6M9UIgvKT+lMiOxOCO+qDQntfgQowQHs5IIr89eoHLelMTKqtSifJiUDAeHkgTv jW6gNsGi1PTUirTMHGBqgEkzcXCCtPMAtW/tAarhLS5IzC3OTIfIn2LU5Xhz7cVrRiGWvPy8 VClxXk6QIgGQoozSPLg5sIT1ilEc6HBhXhOQKh5gsoOb9ApoCRPQkgQ+sCUliQgpqQZG0Th9 Jsmp847+7P6foiB36ceOpfe+K9+95j7NeqXbpnn5Nywroo5rujh219gurLV+/uXszvbWxbPc r0oyzc/8Gvz1wRLFC5sYJaovb9B/v1Po2bXek+4v+gyzS6Vn/u4Nnt9yT+bmnin+bGcy51lz bmDYd1TQWdllW9EVxbJDnY/ro42vyUrbKbEUZyQaajEXFScCAGH1UMIzAwAA Cc: tsvwg@ietf.org Subject: Re: [tsvwg] 10 IW also for SCTP X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 May 2013 11:02:43 -0000 Hi, >> I wonder if this is also how the tsvwg sees this ? >One difference between SCTP and TCP is that SCTP uses a Max.Burst paramete= r. >So you won't send 10 packets without changing also the Max.Burst parameter= . In >the FreeBSD implementation you can tune the Max.Burst parameter and the in= itial >window via sysctls. > > But even if Max.Burst parameter is set to 4, can more than 4 full size pack= ets be send prior to return of SACK. Max.Burst only regulate burst, not CWND. Do you see any reason that SCTP should not follow TCP experimental usage of= 10 IWs ? BR, Karen >Best regards >Michael >> >> Thanks! >> >> BR, Karen From Michael.Tuexen@lurchi.franken.de Mon May 6 05:15:26 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA82921F8EA4 for ; Mon, 6 May 2013 05:15:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wRJ+ov+oufJE for ; Mon, 6 May 2013 05:15:26 -0700 (PDT) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by ietfa.amsl.com (Postfix) with ESMTP id B119321F8E5D for ; Mon, 6 May 2013 05:15:25 -0700 (PDT) Received: from [192.168.1.100] (p508F3DA6.dip0.t-ipconnect.de [80.143.61.166]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id D23331C1057E6; Mon, 6 May 2013 14:15:24 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Michael Tuexen In-Reply-To: Date: Mon, 6 May 2013 14:15:24 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <35233085-F7FE-49B3-AAE5-ECC99AC424D0@lurchi.franken.de> References: To: X-Mailer: Apple Mail (2.1283) Cc: tsvwg@ietf.org Subject: Re: [tsvwg] 10 IW also for SCTP X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 May 2013 12:15:26 -0000 On May 6, 2013, at 1:02 PM, wrote: > Hi, >=20 >>> I wonder if this is also how the tsvwg sees this ? >> One difference between SCTP and TCP is that SCTP uses a Max.Burst = parameter. >> So you won't send 10 packets without changing also the Max.Burst = parameter. In >> the FreeBSD implementation you can tune the Max.Burst parameter and = the initial >> window via sysctls. >>=20 >>=20 >=20 > But even if Max.Burst parameter is set to 4, can more than 4 full size = packets be send prior to return of > SACK. Max.Burst only regulate burst, not CWND. It depends what you consider a burst. Do include an application calling = send() in a loop, you might want to change cwnd by the formula given in section 6.1, D). = So you wouldn't send more than 4 packets... >=20 > Do you see any reason that SCTP should not follow TCP experimental = usage of 10 IWs ? I think you would need to change Max.Burst at the same time. Then you = should get the same behavior. You can do the experiment... However, Randy did some testing a while ago and reported that using = Max.Burst of 4 really helps to avoid messages being dropped. Maybe I'm wrong, but IW of 10 just disables CC for short flows. For long = living flows, I'm not sure if the IW makes a huge difference. Except for the Max.Burst dependency, I don't see a huge difference = between TCP and SCTP. Best regards Michael >=20 > BR, Karen >=20 >=20 >> Best regards >> Michael >>>=20 >>> Thanks! >>>=20 >>> BR, Karen >=20 >=20 From Karen.Nielsen@tieto.com Mon May 6 05:42:48 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 128D121F87C5 for ; Mon, 6 May 2013 05:42:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tVqsOW7jWJ0C for ; Mon, 6 May 2013 05:42:31 -0700 (PDT) Received: from ebb06.tieto.com (ebb06.tieto.com [131.207.168.38]) by ietfa.amsl.com (Postfix) with ESMTP id 14BA221F8FF5 for ; Mon, 6 May 2013 05:42:10 -0700 (PDT) X-AuditID: 83cfa826-b7f4b6d000000a28-ac-5187a52148d0 Received: from FIHGA-EXHUB01.eu.tieto.com ( [131.207.136.34]) by ebb06.tieto.com (SMTP Mailer) with SMTP id CE.99.02600.125A7815; Mon, 6 May 2013 15:42:09 +0300 (EEST) Received: from EXMB03.eu.tieto.com ([169.254.1.39]) by FIHGA-EXHUB01.eu.tieto.com ([131.207.136.34]) with mapi; Mon, 6 May 2013 15:42:08 +0300 From: To: Date: Mon, 6 May 2013 15:42:07 +0300 Thread-Topic: [tsvwg] 10 IW also for SCTP Thread-Index: Ac5KU2RRnILCKj4mQSqAAjgps1msawAAGHfA Message-ID: References: <35233085-F7FE-49B3-AAE5-ECC99AC424D0@lurchi.franken.de> In-Reply-To: <35233085-F7FE-49B3-AAE5-ECC99AC424D0@lurchi.franken.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrAKsWRmVeSWpSXmKPExsXSfL5DSVdxaXugwcxnshYXm5YwWhx7c5fN gcljyZKfTB4bWnYwBTBFcdmkpOZklqUW6dslcGXsedHPUtAmVvF31x32BsZ/Al2MnBwSAiYS E7fMYoawxSQu3FvP1sXIxSEksIpR4v6rv4wQziRGib0ndoFVsQnIS8zdu4odxBYRUJO4d/oh axcjBwezgIjEnN8aIGEWARWJw5tOgZULC2hI/G1dzQRRrinRcnsNVKuRxOGJPWA1vAI+Etu2 rWGG2NXKJLFy/0ewBk4BV4ktLf/ZQGxGoOu+n1oDFmcWEJe49WQ+E8TVAhJL9pyH+kBU4uXj f6wQ9aISd9rXM0LU60gs2P2JDcLWlli28DXUYkGJkzOfsExgFJuFZOwsJC2zkLTMQtKygJFl FSN/alKSgZleSWZqSb5ecn7uJkZw1KxQ28H47IHUIUYBDkYlHt6CJ22BQqyJZcWVuYcYJTmY lER5/ee0BwrxJeWnVGYkFmfEF5XmpBYfYpTgYFYS4fXZC1TOm5JYWZValA+TkuHgUJLgfbUY qE2wKDU9tSItMweYGmDSTBycIO08QO2MS4BqeIsLEnOLM9Mh8qcYdTneXHvxmlGIJS8/L1VK nPcAyCABkKKM0jy4ObCE9YpRHOhwYd4vIFU8wGQHN+kV0BImoCUJfGBLShIRUlINjEEtG8IV BVrvy64uKb+3/6RExMwu1secB35liL/IO22l/fDh19k7RSdKNUV56r5xL5hzfp7O2f4Anvf8 tdVd02dLr7g0n1me999ZH4YPKr3ijfNLVcM3Niy+kPRR4KJq3De5FAl33i/uR8+vTepIjGJb M3tn3aVatUtcemkMZzqeWOtMuni5RYmlOCPRUIu5qDgRALRGUKAzAwAA Cc: tsvwg@ietf.org Subject: Re: [tsvwg] 10 IW also for SCTP X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 May 2013 12:42:48 -0000 Hi, >> But even if Max.Burst parameter is set to 4, can more than 4 full size >> packets be send prior to return of SACK. Max.Burst only regulate burst, = not >CWND. >It depends what you consider a burst. Do include an application calling se= nd() in a >loop, you might want to change cwnd by the formula given in section 6.1, D= ). So >you wouldn't send more than 4 packets... >> I believe that section 6.1 D) proposes a way to implement Max.Burst in an i= nternal routine, not a way to limit initial CWND to 4 MTUs.=20 It says: . The limit MAY be applied by adjusting cwnd as follows: if((flightsize + Max.Burst*MTU) < cwnd) cwnd =3D flightsize + Max.Burst*MTU Or it MAY be applied by strictly limiting the number of packets emitted by the output routine. So perhaps you are saying that FreeBSD implementation would effectively lim= it the IW to Max.Burst. If so, this would not be the case for all SCTP implementations. Or do you mean to say that the intention of Section 6.1 D) also was to keep= the IW under Max.Burst*MTU. >> Do you see any reason that SCTP should not follow TCP experimental usage= of >10 IWs ? >I think you would need to change Max.Burst at the same time. Then you shou= ld get >the same behavior. You can do the experiment... > >However, Randy did some testing a while ago and reported that using Max.Bu= rst of >4 really helps to avoid messages being dropped. > That is very interesting as this sounds as to go against the TCP experiment= s that say that using 10 IWs is not an issue in today's networks. Or perhaps the situations tested were situations where a high, now unused, = CWND had been build up ? >Maybe I'm wrong, but IW of 10 just disables CC for short flows. For long l= iving >flows, I'm not sure if the IW makes a huge difference. > Yes, I think that this is true. The same is the case for TCP. This does depend, however, on whether one also augments the restart window = and possibly also the window (CWND/2) used after loss recovery. ( If so, then for both, one should have to follow the prescriptions of RFC6928 of no= t to increase the CWND in these situations.) It can be noted that RFC6928 does not speak about allowing the window after= loss recovery to be=20 higher then 2MTUs (if CWND/2 <=3D 2MTU). The same is the case for RFC3390, = but nevertheless RFC4960 implements that the window after loss recovery does no= t go beneath 4 MTUs. >Except for the Max.Burst dependency,=20 I do not see any such dependency from Section 6.1 D). I don't see a huge difference between TCP >and SCTP. Thanks. BR, Karen > >Best regards >Michael >> >> BR, Karen >> >> >>> Best regards >>> Michael >>>> >>>> Thanks! >>>> >>>> BR, Karen >> >> From Michael.Tuexen@lurchi.franken.de Mon May 6 05:57:26 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9244821F89D5 for ; Mon, 6 May 2013 05:57:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y4lBOz0llzlp for ; Mon, 6 May 2013 05:57:18 -0700 (PDT) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by ietfa.amsl.com (Postfix) with ESMTP id 2A49921F85D7 for ; Mon, 6 May 2013 05:57:16 -0700 (PDT) Received: from [192.168.1.100] (p508F3DA6.dip0.t-ipconnect.de [80.143.61.166]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 228881C1049A0; Mon, 6 May 2013 14:57:11 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Michael Tuexen In-Reply-To: Date: Mon, 6 May 2013 14:57:10 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <05CC7816-B0BE-4A07-A497-6E8D8AC9D0BC@lurchi.franken.de> References: <35233085-F7FE-49B3-AAE5-ECC99AC424D0@lurchi.franken.de> To: X-Mailer: Apple Mail (2.1283) Cc: tsvwg@ietf.org Subject: Re: [tsvwg] 10 IW also for SCTP X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 May 2013 12:57:26 -0000 On May 6, 2013, at 2:42 PM, = wrote: > Hi, >=20 >>> But even if Max.Burst parameter is set to 4, can more than 4 full = size >>> packets be send prior to return of SACK. Max.Burst only regulate = burst, not >> CWND. >> It depends what you consider a burst. Do include an application = calling send() in a >> loop, you might want to change cwnd by the formula given in section = 6.1, D). So >> you wouldn't send more than 4 packets... >>>=20 >=20 > I believe that section 6.1 D) proposes a way to implement Max.Burst in = an internal routine, > not a way to limit initial CWND to 4 MTUs.=20 >=20 > It says: >=20 > . The limit MAY be applied by adjusting > cwnd as follows: >=20 > if((flightsize + Max.Burst*MTU) < cwnd) cwnd =3D flightsize + > Max.Burst*MTU >=20 > Or it MAY be applied by strictly limiting the number of packets > emitted by the output routine. Before that RFC 4960 says: D) When the time comes for the sender to transmit new DATA chunks, the protocol parameter Max.Burst SHOULD be used to limit the number of packets sent. Assume that the application sends a lot of messages in a tight loop. = Shouldn't Max.Burst limit the number of packets sent even if IW allows for more? A way to = implement this, is given by changing cwnd as described above. >=20 > So perhaps you are saying that FreeBSD implementation would = effectively limit the IW to Max.Burst. > If so, this would not be the case for all SCTP implementations. I think if an SCTP implementation implements the above SHOULD, IW would = be limited to Max.Burst. >=20 > Or do you mean to say that the intention of Section 6.1 D) also was to = keep the IW under Max.Burst*MTU. I just want to stress the point that in the case of SCTP there is = Max.Burst which has to be taken into account. >=20 >>> Do you see any reason that SCTP should not follow TCP experimental = usage of >> 10 IWs ? >> I think you would need to change Max.Burst at the same time. Then you = should get >> the same behavior. You can do the experiment... >>=20 >> However, Randy did some testing a while ago and reported that using = Max.Burst of >> 4 really helps to avoid messages being dropped. >>=20 >=20 > That is very interesting as this sounds as to go against the TCP = experiments that say that using 10 IWs is not an issue in today's = networks. > Or perhaps the situations tested were situations where a high, now = unused, CWND had been build up ? >=20 >> Maybe I'm wrong, but IW of 10 just disables CC for short flows. For = long living >> flows, I'm not sure if the IW makes a huge difference. >>=20 > Yes, I think that this is true. The same is the case for TCP. > This does depend, however, on whether one also augments the restart = window and possibly > also the window (CWND/2) used after loss recovery. ( If so, > then for both, one should have to follow the prescriptions of RFC6928 = of not to increase the CWND in these situations.) >=20 > It can be noted that RFC6928 does not speak about allowing the window = after loss recovery to be=20 > higher then 2MTUs (if CWND/2 <=3D 2MTU). The same is the case for = RFC3390, but > nevertheless RFC4960 implements that the window after loss recovery = does not go beneath 4 MTUs. >=20 >> Except for the Max.Burst dependency,=20 >=20 > I do not see any such dependency from Section 6.1 D). >=20 > I don't see a huge difference between TCP >> and SCTP. >=20 > Thanks. >=20 > BR, Karen >>=20 >> Best regards >> Michael >>>=20 >>> BR, Karen >>>=20 >>>=20 >>>> Best regards >>>> Michael >>>>>=20 >>>>> Thanks! >>>>>=20 >>>>> BR, Karen >>>=20 >>>=20 >=20 >=20 From Karen.Nielsen@tieto.com Mon May 6 06:57:03 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C394521F896B for ; Mon, 6 May 2013 06:57:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_35=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GOO3+ySTFmA0 for ; Mon, 6 May 2013 06:56:58 -0700 (PDT) Received: from ebb06.tieto.com (ebb06.tieto.com [131.207.168.38]) by ietfa.amsl.com (Postfix) with ESMTP id 621D821F8956 for ; Mon, 6 May 2013 06:56:57 -0700 (PDT) X-AuditID: 83cfa826-b7f4b6d000000a28-a0-5187b6a88f89 Received: from FIVLA-EXHUB02.eu.tieto.com ( [131.207.136.42]) by ebb06.tieto.com (SMTP Mailer) with SMTP id 93.AF.02600.8A6B7815; Mon, 6 May 2013 16:56:56 +0300 (EEST) Received: from EXMB03.eu.tieto.com ([169.254.1.39]) by FIVLA-EXHUB02.eu.tieto.com ([131.207.136.42]) with mapi; Mon, 6 May 2013 16:56:55 +0300 From: To: Date: Mon, 6 May 2013 16:56:54 +0300 Thread-Topic: [tsvwg] 10 IW also for SCTP Thread-Index: Ac5KWTofVT6c2BBUSmS2TPV3L43v+QAAPaIA Message-ID: References: <35233085-F7FE-49B3-AAE5-ECC99AC424D0@lurchi.franken.de> <05CC7816-B0BE-4A07-A497-6E8D8AC9D0BC@lurchi.franken.de> In-Reply-To: <05CC7816-B0BE-4A07-A497-6E8D8AC9D0BC@lurchi.franken.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprLKsWRmVeSWpSXmKPExsXSfL5DS3fFtvZAgyu3RS0uNi1htDj25i6b A5PHkiU/mTw2tOxgCmCK4rJJSc3JLEst0rdL4Mr48vw+Y8FO3YqOowsZGxiXKXcxcnBICJhI PGrn7GLkBDLFJC7cW8/WxcjFISSwilFi6aOrjBDOJEaJc9NaGEGq2ATkJebuXcUOYosIqEnc O/2QFWQQs4CIxJzfGiAmi4CKRPcjfpAKYQENib+tq5kgqjUlWm6vgeo0knj3djEriM0r4CPx cOZ+FhBbSKCZWeLmNGMQm1PAVeJg01SwXkag276fWgNmMwuIS9x6Mp8J4mYBiSV7zjND2KIS Lx//Y4WoF5W4076eEaJeR2LB7k9sELa2xLKFr5kh9gpKnJz5hGUCo9gsJGNnIWmZhaRlFpKW BYwsqxj5U5OSDMz0SjJTS/L1kvNzNzGC42WF2g7GZw+kDjEKcDAq8fAWPGkLFGJNLCuuzD3E KMnBpCTK67S1PVCILyk/pTIjsTgjvqg0J7X4EKMEB7OSCG/lGqAcb0piZVVqUT5MSoaDQ0mC 9zhIm2BRanpqRVpmDjApwKSZODhB2nmA2heC1PAWFyTmFmemQ+RPMepyvLn24jWjEEtefl6q lDjvOpAiAZCijNI8uDmwVPWKURzocGHemSBVPMA0BzfpFdASJqAlCXxgS0oSEVJSDYxy6a1J Fmzz6vfeUdLsCbg274fZC97jaSLLJFZGGEfzXz5TudtcJu31J+e0Iv2GYqlnD5Wv/3z1zyNj 8c2+henL3YXmlGTtmKPXN2P9llVPp8syaT+bbbzn4Sb2Gb+5nKZdYBGe2NUkbjTT+UtMmbNS 2PUfMUbL555Jmb74/ZtTj9Klr/ZXSj5SYinOSDTUYi4qTgQAUfIHvzADAAA= Cc: tsvwg@ietf.org Subject: Re: [tsvwg] 10 IW also for SCTP X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 May 2013 13:57:03 -0000 Hi, >-----Original Message----- >From: Michael Tuexen [mailto:Michael.Tuexen@lurchi.franken.de] >Sent: Monday, May 06, 2013 2:57 PM >To: Nielsen Karen >Cc: tsvwg@ietf.org >Subject: Re: [tsvwg] 10 IW also for SCTP > >On May 6, 2013, at 2:42 PM, > wrote: > >> Hi, >> >>>> But even if Max.Burst parameter is set to 4, can more than 4 full >>>> size packets be send prior to return of SACK. Max.Burst only >>>> regulate burst, not >>> CWND. >>> It depends what you consider a burst. Do include an application >>> calling send() in a loop, you might want to change cwnd by the >>> formula given in section 6.1, D). So you wouldn't send more than 4 pack= ets... >>>> >> >> I believe that section 6.1 D) proposes a way to implement Max.Burst in >> an internal routine, not a way to limit initial CWND to 4 MTUs. >> >> It says: >> >> . The limit MAY be applied by adjusting >> cwnd as follows: >> >> if((flightsize + Max.Burst*MTU) < cwnd) cwnd =3D flightsize + >> Max.Burst*MTU >> >> Or it MAY be applied by strictly limiting the number of packets >> emitted by the output routine. >Before that RFC 4960 says: > D) When the time comes for the sender to transmit new DATA chunks, > the protocol parameter Max.Burst SHOULD be used to limit the > number of packets sent. > Yes, Section 6.1 D) in full reads: "When the time comes for the sender to transmit new DATA chunks, the protocol parameter Max.Burst SHOULD be used to limit the number of packets sent. The limit MAY be applied by adjusting cwnd as follows: if((flightsize + Max.Burst*MTU) < cwnd) cwnd =3D flightsize + Max.Burst*MTU Or it MAY be applied by strictly limiting the number of packets emitted by the output routine." However "When the time comes for the sender to transmit new DATA chunks" is= not very well specified. It certainly does not clearly say that this assumes arrival of SACK and/or that new arrival of da= ta from application does not initiate new transmit. >Assume that the application sends a lot of messages in a tight loop. Shoul= dn't >Max.Burst limit the number of packets sent even if IW allows for more?=20 Well as specified it says that in one output routine, no more than Max.burs= t *MTU SHOULD be send. If the intention was that at most Max.burst*MTU SHOULD be sent in between S= ACK arrival and that it is new SACK arrival that allow for a new output routine to be initiated (or something like that), th= en I think this deserves to be spelled out. A way to >implement this, is given by changing cwnd as described above. >> >> So perhaps you are saying that FreeBSD implementation would effectively = limit >the IW to Max.Burst. >> If so, this would not be the case for all SCTP implementations. >I think if an SCTP implementation implements the above SHOULD, IW would be >limited to Max.Burst. >> If the intention of the above SHOULD is as revealed in this thread, I would appreciate if an Errata was to be issued. I think that it would also be good to understand the exact motivation for t= his limitation. No I am not certain that IW would be limited to Max.Burst even if the above= SHOULD was to be interpreted in this manner. I suppose that the arrival of SACK would allow for new data transmit (or wh= at else should then trick that a new output operation can be=20 started). If such SACK acknowledges the first 2*MTUs, I suppose that one, w= ith an IW of 10IW, could end up having 6*MTUs outstanding now. With IW of 4*MTU, at most 5 *MTUs could be outstanding at this point in tim= e.=20 BR, Karen >> Or do you mean to say that the intention of Section 6.1 D) also was to k= eep the >IW under Max.Burst*MTU. >I just want to stress the point that in the case of SCTP there is Max.Burs= t which has >to be taken into account. >> >>>> Do you see any reason that SCTP should not follow TCP experimental >>>> usage of >>> 10 IWs ? >>> I think you would need to change Max.Burst at the same time. Then you >>> should get the same behavior. You can do the experiment... >>> >>> However, Randy did some testing a while ago and reported that using >>> Max.Burst of >>> 4 really helps to avoid messages being dropped. >>> >> >> That is very interesting as this sounds as to go against the TCP experim= ents that >say that using 10 IWs is not an issue in today's networks. >> Or perhaps the situations tested were situations where a high, now unuse= d, CWND >had been build up ? >> >>> Maybe I'm wrong, but IW of 10 just disables CC for short flows. For >>> long living flows, I'm not sure if the IW makes a huge difference. >>> >> Yes, I think that this is true. The same is the case for TCP. >> This does depend, however, on whether one also augments the restart >> window and possibly also the window (CWND/2) used after loss recovery. >> ( If so, then for both, one should have to follow the prescriptions of >> RFC6928 of not to increase the CWND in these situations.) >> >> It can be noted that RFC6928 does not speak about allowing the window >> after loss recovery to be higher then 2MTUs (if CWND/2 <=3D 2MTU). The >> same is the case for RFC3390, but nevertheless RFC4960 implements that t= he >window after loss recovery does not go beneath 4 MTUs. >> >>> Except for the Max.Burst dependency, >> >> I do not see any such dependency from Section 6.1 D). >> >> I don't see a huge difference between TCP >>> and SCTP. >> >> Thanks. >> >> BR, Karen >>> >>> Best regards >>> Michael >>>> >>>> BR, Karen >>>> >>>> >>>>> Best regards >>>>> Michael >>>>>> >>>>>> Thanks! >>>>>> >>>>>> BR, Karen >>>> >>>> >> >> From bidulock@openss7.org Mon May 6 12:42:34 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C42C421F93A5 for ; Mon, 6 May 2013 12:42:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4 X-Spam-Level: X-Spam-Status: No, score=-4 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zwJdKXQc4zG8 for ; Mon, 6 May 2013 12:42:30 -0700 (PDT) Received: from gw.openss7.com (gw.openss7.com [142.59.210.7]) by ietfa.amsl.com (Postfix) with ESMTP id 2238E21F939E for ; Mon, 6 May 2013 12:42:26 -0700 (PDT) Received: from wilbur.pigworks.openss7.net (ns5.evil.openss7.net [192.168.9.5]) by gw.openss7.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id r46JgPB0020395; Mon, 6 May 2013 13:42:25 -0600 Received: from wilbur.pigworks.openss7.net (localhost [127.0.0.1]) by wilbur.pigworks.openss7.net (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id r46JgOkM023520; Mon, 6 May 2013 13:42:24 -0600 Received: (from brian@localhost) by wilbur.pigworks.openss7.net (8.14.3/8.14.3/Submit) id r46JgOwi023519; Mon, 6 May 2013 13:42:24 -0600 Date: Mon, 6 May 2013 13:42:24 -0600 From: "Brian F. G. Bidulock" To: Karen.Nielsen@tieto.com Message-ID: <20130506194223.GA15990@openss7.org> Mail-Followup-To: Karen.Nielsen@tieto.com, Michael.Tuexen@lurchi.franken.de, tsvwg@ietf.org References: <35233085-F7FE-49B3-AAE5-ECC99AC424D0@lurchi.franken.de> <05CC7816-B0BE-4A07-A497-6E8D8AC9D0BC@lurchi.franken.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Organization: http://www.openss7.org/ Dsn-Notification-To: X-Spam-To: User-Agent: Mutt/1.5.18 (2008-05-17) Cc: Michael.Tuexen@lurchi.franken.de, tsvwg@ietf.org Subject: Re: [tsvwg] 10 IW also for SCTP X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: bidulock@openss7.org List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 May 2013 19:42:34 -0000 Karen, There was some discussion on this back in 2006 in the ladder that starts with this message: http://www.ietf.org/mail-archive/web/tsvwg/current/msg07054.html --brian -- Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ From Michael.Tuexen@lurchi.franken.de Mon May 6 12:55:12 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D23C21F9283 for ; Mon, 6 May 2013 12:55:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.6 X-Spam-Level: X-Spam-Status: No, score=0.6 tagged_above=-999 required=5 tests=[J_CHICKENPOX_35=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IHMxXC65ST-P for ; Mon, 6 May 2013 12:55:11 -0700 (PDT) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by ietfa.amsl.com (Postfix) with ESMTP id 7471F21F9121 for ; Mon, 6 May 2013 12:55:03 -0700 (PDT) Received: from [192.168.1.200] (p508F3DA6.dip0.t-ipconnect.de [80.143.61.166]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 65EB11C0ACD89; Mon, 6 May 2013 21:54:56 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Michael Tuexen In-Reply-To: Date: Mon, 6 May 2013 21:54:55 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <300485F2-2BB1-4761-ACA5-96C564B0D6B3@lurchi.franken.de> References: <35233085-F7FE-49B3-AAE5-ECC99AC424D0@lurchi.franken.de> <05CC7816-B0BE-4A07-A497-6E8D8AC9D0BC@lurchi.franken.de> To: X-Mailer: Apple Mail (2.1283) Cc: tsvwg@ietf.org Subject: Re: [tsvwg] 10 IW also for SCTP X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 May 2013 19:55:12 -0000 On May 6, 2013, at 3:56 PM, = wrote: > Hi, >=20 >> -----Original Message----- >> From: Michael Tuexen [mailto:Michael.Tuexen@lurchi.franken.de] >> Sent: Monday, May 06, 2013 2:57 PM >> To: Nielsen Karen >> Cc: tsvwg@ietf.org >> Subject: Re: [tsvwg] 10 IW also for SCTP >>=20 >> On May 6, 2013, at 2:42 PM, >> wrote: >>=20 >>> Hi, >>>=20 >>>>> But even if Max.Burst parameter is set to 4, can more than 4 full >>>>> size packets be send prior to return of SACK. Max.Burst only >>>>> regulate burst, not >>>> CWND. >>>> It depends what you consider a burst. Do include an application >>>> calling send() in a loop, you might want to change cwnd by the >>>> formula given in section 6.1, D). So you wouldn't send more than 4 = packets... >>>>>=20 >>>=20 >>> I believe that section 6.1 D) proposes a way to implement Max.Burst = in >>> an internal routine, not a way to limit initial CWND to 4 MTUs. >>>=20 >>> It says: >>>=20 >>> . The limit MAY be applied by adjusting >>> cwnd as follows: >>>=20 >>> if((flightsize + Max.Burst*MTU) < cwnd) cwnd =3D flightsize + >>> Max.Burst*MTU >>>=20 >>> Or it MAY be applied by strictly limiting the number of packets >>> emitted by the output routine. >> Before that RFC 4960 says: >> D) When the time comes for the sender to transmit new DATA chunks, >> the protocol parameter Max.Burst SHOULD be used to limit the >> number of packets sent. >>=20 > Yes, Section 6.1 D) in full reads: >=20 > "When the time comes for the sender to transmit new DATA chunks, > the protocol parameter Max.Burst SHOULD be used to limit the > number of packets sent. The limit MAY be applied by adjusting > cwnd as follows: >=20 > if((flightsize + Max.Burst*MTU) < cwnd) cwnd =3D flightsize + > Max.Burst*MTU >=20 > Or it MAY be applied by strictly limiting the number of packets > emitted by the output routine." >=20 > However "When the time comes for the sender to transmit new DATA = chunks" is not very well specified. It certainly does not > clearly say that this assumes arrival of SACK and/or that new arrival = of data from application does not initiate new transmit. True. The intention is to mitigate packet bursts. For the network it = doesn't matter how the burst are generated. So the text is generic. >=20 >> Assume that the application sends a lot of messages in a tight loop. = Shouldn't >> Max.Burst limit the number of packets sent even if IW allows for = more?=20 >=20 > Well as specified it says that in one output routine, no more than = Max.burst *MTU SHOULD be send. > If the intention was that at most Max.burst*MTU SHOULD be sent in = between SACK arrival and that it is new SACK arrival that > allow for a new output routine to be initiated (or something like = that), then I think this deserves to be spelled out. Only limiting to Max.burst in the output routing would avoid bursts in = response to incoming SACks. It would not cover bursts initiated by an application = calling send in bursts. I agree, the text is not very explicit, but taking the = goal into account helps... This goes back to burst mitigation stuff by Mark Allman. For whatever = reason it didn't make it into an TCP RFC... >=20 >=20 > A way to >> implement this, is given by changing cwnd as described above. >>>=20 >>> So perhaps you are saying that FreeBSD implementation would = effectively limit >> the IW to Max.Burst. >>> If so, this would not be the case for all SCTP implementations. >> I think if an SCTP implementation implements the above SHOULD, IW = would be >> limited to Max.Burst. >>>=20 >=20 > If the intention of the above SHOULD is as revealed in this thread, > I would appreciate if an Errata was to be issued. >=20 > I think that it would also be good to understand the exact motivation = for this limitation. Have a look at http://www.icsi.berkeley.edu/pubs/networking/measuringinteractions05.pdf >=20 > No I am not certain that IW would be limited to Max.Burst even if the = above SHOULD was to be interpreted in this manner. > I suppose that the arrival of SACK would allow for new data transmit = (or what else should then trick that a new output operation can be=20 > started). If such SACK acknowledges the first 2*MTUs, I suppose that = one, with an IW of 10IW, could end up having 6*MTUs outstanding now. > With IW of 4*MTU, at most 5 *MTUs could be outstanding at this point = in time.=20 I'm not saying that the IW is limited to value of Max.Burst. I'm saying = that the Max.Burst limitation has to be considered and results in not = immediately being able to send the whole IW. Best regards Michael >=20 > BR, Karen >=20 >>> Or do you mean to say that the intention of Section 6.1 D) also was = to keep the >> IW under Max.Burst*MTU. >> I just want to stress the point that in the case of SCTP there is = Max.Burst which has >> to be taken into account. >>>=20 >>>>> Do you see any reason that SCTP should not follow TCP experimental >>>>> usage of >>>> 10 IWs ? >>>> I think you would need to change Max.Burst at the same time. Then = you >>>> should get the same behavior. You can do the experiment... >>>>=20 >>>> However, Randy did some testing a while ago and reported that using >>>> Max.Burst of >>>> 4 really helps to avoid messages being dropped. >>>>=20 >>>=20 >>> That is very interesting as this sounds as to go against the TCP = experiments that >> say that using 10 IWs is not an issue in today's networks. >>> Or perhaps the situations tested were situations where a high, now = unused, CWND >> had been build up ? >>>=20 >>>> Maybe I'm wrong, but IW of 10 just disables CC for short flows. For >>>> long living flows, I'm not sure if the IW makes a huge difference. >>>>=20 >>> Yes, I think that this is true. The same is the case for TCP. >>> This does depend, however, on whether one also augments the restart >>> window and possibly also the window (CWND/2) used after loss = recovery. >>> ( If so, then for both, one should have to follow the prescriptions = of >>> RFC6928 of not to increase the CWND in these situations.) >>>=20 >>> It can be noted that RFC6928 does not speak about allowing the = window >>> after loss recovery to be higher then 2MTUs (if CWND/2 <=3D 2MTU). = The >>> same is the case for RFC3390, but nevertheless RFC4960 implements = that the >> window after loss recovery does not go beneath 4 MTUs. >>>=20 >>>> Except for the Max.Burst dependency, >>>=20 >>> I do not see any such dependency from Section 6.1 D). >>>=20 >>> I don't see a huge difference between TCP >>>> and SCTP. >>>=20 >>> Thanks. >>>=20 >>> BR, Karen >>>>=20 >>>> Best regards >>>> Michael >>>>>=20 >>>>> BR, Karen >>>>>=20 >>>>>=20 >>>>>> Best regards >>>>>> Michael >>>>>>>=20 >>>>>>> Thanks! >>>>>>>=20 >>>>>>> BR, Karen >>>>>=20 >>>>>=20 >>>=20 >>>=20 >=20 >=20 From erblichs@earthlink.net Tue May 7 02:55:03 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0A5821F8D2C for ; Tue, 7 May 2013 02:55:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_35=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aZnG63m4tW0g for ; Tue, 7 May 2013 02:54:57 -0700 (PDT) Received: from elasmtp-galgo.atl.sa.earthlink.net (elasmtp-galgo.atl.sa.earthlink.net [209.86.89.61]) by ietfa.amsl.com (Postfix) with ESMTP id B062921F8C23 for ; Tue, 7 May 2013 02:54:57 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=EXKvvt01OziOxmKgYJW9sx1umjeMOBM1YOTKRaOgzvGasxDDN7zPGhZHjho+Z70E; h=Received:Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [99.151.253.109] (helo=[10.0.1.5]) by elasmtp-galgo.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1UZebo-0004Xn-4A; Tue, 07 May 2013 05:54:56 -0400 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=windows-1252 From: Mitchell Erblich In-Reply-To: Date: Tue, 7 May 2013 02:54:53 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <7FAB0DE0-C8AF-4A01-8325-756FB43FBFDD@earthlink.net> References: <35233085-F7FE-49B3-AAE5-ECC99AC424D0@lurchi.franken.de> <05CC7816-B0BE-4A07-A497-6E8D8AC9D0BC@lurchi.franken.de> To: tsvwg X-Mailer: Apple Mail (2.1283) X-ELNK-Trace: 074f60c55517ea841aa676d7e74259b7b3291a7d08dfec790648012ce6fbe7caf0eaf229a30f31d2350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.151.253.109 Cc: "Karen.Nielsen@tieto.com>" , Michael.Tuexen@lurchi.franken.de Subject: Re: [tsvwg] 10 IW also for SCTP X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 May 2013 09:55:03 -0000 Hello, Maybe I am wrong, but it seems that everyone with the emails is = only considering MTU / MSS sized segments=85 and that any protocol including SCTP would limit an app bursting = segments onto a wire,,, In the cases of an application initially limiting, aka pacing = TCP flow, such as a fair number of wirespeed echo requests/pings, then both protocols SHOULD NOT limit the flow and wrt to = Allman's ABC, a large number of smaller segments SHOULD then generate the sender equiv of ACK splitting=85. grow = the initial window faster than normal=85 Thus, IMO, if the 10 or so segments are sub-MTU sized (i.e. = 128bytes) and sent with some minimal spacing, I would expect to be able = to grow the window faster in SS, mitigate any possible DELACKs and/or = loss of ACKs=85. And if at the same time, additionally while segments are placed = on the wire, a few could be growing in size, additional growth can be = obtained (?unfairly obtained?) while probing for the number of = outstanding bytes (segments * avg size per segment) that could cause a = drop (or can frags occur below MTU sized segs or =85 ) =85.=20 Mitchell Erblich On May 6, 2013, at 6:56 AM, = wrote: > Hi, >=20 >> -----Original Message----- >> From: Michael Tuexen [mailto:Michael.Tuexen@lurchi.franken.de] >> Sent: Monday, May 06, 2013 2:57 PM >> To: Nielsen Karen >> Cc: tsvwg@ietf.org >> Subject: Re: [tsvwg] 10 IW also for SCTP >>=20 >> On May 6, 2013, at 2:42 PM, >> wrote: >>=20 >>> Hi, >>>=20 >>>>> But even if Max.Burst parameter is set to 4, can more than 4 full >>>>> size packets be send prior to return of SACK. Max.Burst only >>>>> regulate burst, not >>>> CWND. >>>> It depends what you consider a burst. Do include an application >>>> calling send() in a loop, you might want to change cwnd by the >>>> formula given in section 6.1, D). So you wouldn't send more than 4 = packets... >>>>>=20 >>>=20 >>> I believe that section 6.1 D) proposes a way to implement Max.Burst = in >>> an internal routine, not a way to limit initial CWND to 4 MTUs. >>>=20 >>> It says: >>>=20 >>> . The limit MAY be applied by adjusting >>> cwnd as follows: >>>=20 >>> if((flightsize + Max.Burst*MTU) < cwnd) cwnd =3D flightsize + >>> Max.Burst*MTU >>>=20 >>> Or it MAY be applied by strictly limiting the number of packets >>> emitted by the output routine. >> Before that RFC 4960 says: >> D) When the time comes for the sender to transmit new DATA chunks, >> the protocol parameter Max.Burst SHOULD be used to limit the >> number of packets sent. >>=20 > Yes, Section 6.1 D) in full reads: >=20 > "When the time comes for the sender to transmit new DATA chunks, > the protocol parameter Max.Burst SHOULD be used to limit the > number of packets sent. The limit MAY be applied by adjusting > cwnd as follows: >=20 > if((flightsize + Max.Burst*MTU) < cwnd) cwnd =3D flightsize + > Max.Burst*MTU >=20 > Or it MAY be applied by strictly limiting the number of packets > emitted by the output routine." >=20 > However "When the time comes for the sender to transmit new DATA = chunks" is not very well specified. It certainly does not > clearly say that this assumes arrival of SACK and/or that new arrival = of data from application does not initiate new transmit. >=20 >> Assume that the application sends a lot of messages in a tight loop. = Shouldn't >> Max.Burst limit the number of packets sent even if IW allows for = more?=20 >=20 > Well as specified it says that in one output routine, no more than = Max.burst *MTU SHOULD be send. > If the intention was that at most Max.burst*MTU SHOULD be sent in = between SACK arrival and that it is new SACK arrival that > allow for a new output routine to be initiated (or something like = that), then I think this deserves to be spelled out. >=20 >=20 > A way to >> implement this, is given by changing cwnd as described above. >>>=20 >>> So perhaps you are saying that FreeBSD implementation would = effectively limit >> the IW to Max.Burst. >>> If so, this would not be the case for all SCTP implementations. >> I think if an SCTP implementation implements the above SHOULD, IW = would be >> limited to Max.Burst. >>>=20 >=20 > If the intention of the above SHOULD is as revealed in this thread, > I would appreciate if an Errata was to be issued. >=20 > I think that it would also be good to understand the exact motivation = for this limitation. >=20 > No I am not certain that IW would be limited to Max.Burst even if the = above SHOULD was to be interpreted in this manner. > I suppose that the arrival of SACK would allow for new data transmit = (or what else should then trick that a new output operation can be=20 > started). If such SACK acknowledges the first 2*MTUs, I suppose that = one, with an IW of 10IW, could end up having 6*MTUs outstanding now. > With IW of 4*MTU, at most 5 *MTUs could be outstanding at this point = in time.=20 >=20 > BR, Karen >=20 >>> Or do you mean to say that the intention of Section 6.1 D) also was = to keep the >> IW under Max.Burst*MTU. >> I just want to stress the point that in the case of SCTP there is = Max.Burst which has >> to be taken into account. >>>=20 >>>>> Do you see any reason that SCTP should not follow TCP experimental >>>>> usage of >>>> 10 IWs ? >>>> I think you would need to change Max.Burst at the same time. Then = you >>>> should get the same behavior. You can do the experiment... >>>>=20 >>>> However, Randy did some testing a while ago and reported that using >>>> Max.Burst of >>>> 4 really helps to avoid messages being dropped. >>>>=20 >>>=20 >>> That is very interesting as this sounds as to go against the TCP = experiments that >> say that using 10 IWs is not an issue in today's networks. >>> Or perhaps the situations tested were situations where a high, now = unused, CWND >> had been build up ? >>>=20 >>>> Maybe I'm wrong, but IW of 10 just disables CC for short flows. For >>>> long living flows, I'm not sure if the IW makes a huge difference. >>>>=20 >>> Yes, I think that this is true. The same is the case for TCP. >>> This does depend, however, on whether one also augments the restart >>> window and possibly also the window (CWND/2) used after loss = recovery. >>> ( If so, then for both, one should have to follow the prescriptions = of >>> RFC6928 of not to increase the CWND in these situations.) >>>=20 >>> It can be noted that RFC6928 does not speak about allowing the = window >>> after loss recovery to be higher then 2MTUs (if CWND/2 <=3D 2MTU). = The >>> same is the case for RFC3390, but nevertheless RFC4960 implements = that the >> window after loss recovery does not go beneath 4 MTUs. >>>=20 >>>> Except for the Max.Burst dependency, >>>=20 >>> I do not see any such dependency from Section 6.1 D). >>>=20 >>> I don't see a huge difference between TCP >>>> and SCTP. >>>=20 >>> Thanks. >>>=20 >>> BR, Karen >>>>=20 >>>> Best regards >>>> Michael >>>>>=20 >>>>> BR, Karen >>>>>=20 >>>>>=20 >>>>>> Best regards >>>>>> Michael >>>>>>>=20 >>>>>>> Thanks! >>>>>>>=20 >>>>>>> BR, Karen >>>>>=20 >>>>>=20 >>>=20 >>>=20 >=20 From Karen.Nielsen@tieto.com Tue May 7 03:06:04 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49B5221F88EA for ; Tue, 7 May 2013 03:06:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ORvQDizVuSDY for ; Tue, 7 May 2013 03:05:54 -0700 (PDT) Received: from ebb06.tieto.com (ebb06.tieto.com [131.207.168.38]) by ietfa.amsl.com (Postfix) with ESMTP id 4F4B421F84D9 for ; Tue, 7 May 2013 03:05:46 -0700 (PDT) X-AuditID: 83cfa826-b7f4b6d000000a28-a7-5188d1f90f3e Received: from FIVLA-EXHUB02.eu.tieto.com ( [131.207.136.42]) by ebb06.tieto.com (SMTP Mailer) with SMTP id 52.28.02600.9F1D8815; Tue, 7 May 2013 13:05:45 +0300 (EEST) Received: from EXMB03.eu.tieto.com ([169.254.1.39]) by FIVLA-EXHUB02.eu.tieto.com ([131.207.136.42]) with mapi; Tue, 7 May 2013 13:05:44 +0300 From: To: Date: Tue, 7 May 2013 13:05:43 +0300 Thread-Topic: QUESTION on Return of SACKs and HB ACKs Thread-Index: Ac5LCk3wahIxP0L2QdKUCt4joy00VQ== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CF340E42AED0874C81947E18863DE77B29A8EE1D77EXMB03eutieto_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrLIsWRmVeSWpSXmKPExsXSfL5DS/fnxY5AgxX35C2OvbnL5sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujClvV7MW3PGomL7yLFMD4yHbLkZODgkBE4lX94+yQdhiEhfu rQeyuTiEBFYxSlz8t4sZwpnEKPFm/SKwKjYBeYm5e1exdzFycIgIiEh079AHCbMIqEj8XTGX CcQWFjCU+PaoGaxcRMBMYseFVcwQtp7Eu2NHwWxeAR+JztZZjCA2I9Di76fWgPUyC4hL3Hoy nwniIAGJJXvOM0PYohIvH/9jhagXlbjTvp4Roj5fomtGOyPETEGJkzOfsExgFJqFZNQsJGWz kJRBxHUkFuz+xAZha0ssW/iaGcY+c+AxE7L4Akb2VYz8qUlJBmZ6JZmpJfl6yfm5mxjBcbBC bQfjswdShxgFOBiVeHgVTrUHCrEmlhVX5h5ilORgUhLl/XC+I1CILyk/pTIjsTgjvqg0J7X4 EKMEB7OSCO+Ng0A53pTEyqrUonyYlAwHh5IE75kLQCnBotT01Iq0zBxgtMOkmTg4Qdp5gNof gdTwFhck5hZnpkPkTzEqSonz3gVJCIAkMkrz4HphqeYVozjQscK8R0CqeIBpCq77FdBgJqDB CXztIINLEhFSUg2M+jY/La5P4pC3n95dGFd2+XlCks6XbydUW86V2q2+kWCm4vbCVXu/94U5 HKZhn3butd4z8++s8NtTTz7aE8yoXsV5+vZCqad7dqmHb5p1daGKb1Gx2yXWuPNNDvs85ITm JWdGZe+4o3jy+tpXEW85L17cN/+evnGM7d3FfGcyvBvz78378m6tjhJLcUaioRZzUXEiAIxx fPEQAwAA Subject: [tsvwg] QUESTION on Return of SACKs and HB ACKs X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 May 2013 10:06:04 -0000 --_000_CF340E42AED0874C81947E18863DE77B29A8EE1D77EXMB03eutieto_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, RFC4960 in Section 6.4 opens up for the possibility that SACKs may be retur= ned on a different path (or IP Path) that the reflected path (or IP Path) of the incoming Data. This, as said in RFC4960, can be the situation when a SACK acknowledges Dat= a TSNs that have come in on different paths as well as it may (MAY) be a beneficial reaction if evidence is available that indicates= the unavailability of the reflected data path. Such unavailability evidence could come from arrival of duplicate Data chunks (as pointed to in= RFC4960) possibly such evidence could also be established by other means (like e.g., if HBs indicates the reflected Path to be unavai= lable). The latter aspect are not mentioned in RFC4960. I am wondering, if anybody (IETF SCTP community and/or RFC4960 Authors) has= any view on the validity (or the contrary) of not returning SACKs on the reflected IP Path ? Obviously it is very important for the path selection for return of SACKs t= o be as stable and consistent as feasible, as one otherwise risks to jeopardize the= validity of Data RTT measurements of peer, and using the reflected IP path is one way to achieve this. But having said this, then I wonder if there ot= herwise are considered to be significant problems with the return of SACKs via paths there are different from the reflected IP Path of= Data. Issues that makes is so that an SCTP implementation should best poss= ible prevent situations where data and SACK do not follow the same path (in= opposite directions). Possibly also the situation with return of SACKs acknowledging Data chunks = that have come in on multiple paths will be even more relevant for CMT-SCTP= . This may open up for either demanding for SACKs to be returned split accord= ing to the incoming path of Data or for the recommendation of RFC4960 to us= e reflected path of Data to be broaden up to recommend for consistent choic= e of return path of SACKs. Finally following the thoughts above for SACK return, then one may also thi= nk about the corresponding situation with the return of HB ACKs. RFC4960 seems to assume for HB ACKs always to be returned on the reflected = path of the HB as it says, Section 3.3.6, but notably the only Keyword that applies to return of HB ACK is the SHOULD of Section 6.4 : A HEARTBEAT ACK is always sent to the source IP address of the IP datagram containing the HEARTBEAT chunk to which this ack is responding. Also here one can wonder as to whether it is best to have the HB ACK return= ed in the path over which it is most likely to reach peer or whether it must (?) be returned on the reflect path of the incoming HB. I am not su= re if the RFC4960 SHOULD here should be read mostly as a MUST or mostly as = a SHOULD unless other things make it beneficiary to use a different path ? A BIG Thanks in Advance ! BR, Karen --_000_CF340E42AED0874C81947E18863DE77B29A8EE1D77EXMB03eutieto_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

RFC4960 in= Section 6.4 opens up for the possibility that SACKs may be returned on a d= ifferent path (or IP Path)

that the refl= ected path (or IP Path) of the incoming Data.

 

This, as said in RFC4960, c= an be the situation when a SACK acknowledges Data TSNs that have come in on= different paths as well as it

 ma= y (MAY) be a beneficial reaction if evidence is available that indicates th= e unavailability of the reflected data path. Such unavailability=

evidence could come from arrival of duplicate Data= chunks (as pointed to in RFC4960) possibly such evidence could also be est= ablished

by other means (like e.g., if H= Bs indicates the reflected Path to be unavailable). The latter aspect are n= ot mentioned in RFC4960.

 

I am wondering, if anybody (IETF SCTP community = and/or RFC4960 Authors) has any view on the validity (or the contrary) of <= o:p>

not returning SACKs on the reflected IP = Path ?

 

Obviously it is very important for the path selection for return o= f SACKs to be as

stable and consistent a= s feasible, as one otherwise risks to jeopardize the validity of Data RTT m= easurements of peer, and using the reflected IP path

is one way to achieve this. But having said this, then I wonde= r if there otherwise are considered to be significant problems with the

return of SACKs via paths there are differe= nt from the reflected IP Path of Data. Issues that makes is so that an SCTP= implementation should best possible prevent situations where data and SACK= do not follow the same path (in opposite directions).

 

Possibly also the = situation with return of SACKs acknowledging Data chunks that have come in = on multiple paths will be even more relevant for CMT-SCTP.

This may open up for either demanding for SACKs to be re= turned split according to the incoming path of Data or for the recommendati= on of RFC4960 to use reflected path of Data to be broaden up to recommend f= or consistent choice of return path of SACKs.

 

Finally following the thoug= hts above for SACK return, then one may also think about the corresponding = situation with the return of HB ACKs.

 

RFC4960 seems to assume for HB ACKs= always to be returned on the reflected path of the HB as it says, Section = 3.3.6, but notably the only Keyword

tha= t applies to return of HB ACK is the SHOULD of Section 6.4 :

=

 

A HEARTBEAT = ACK is always

   sent to the s= ource IP address of the IP datagram containing the

   HEARTBEAT chunk to which this ack is responding.<= o:p>

 

Also here one can wonder as to whether it is best to have the HB ACK retu= rned in the path over which it is most likely to reach peer or whether=

it must (?) be returned on the reflect path = of the incoming HB. I am not sure if the RFC4960 SHOULD here should be read= mostly as a MUST or mostly as a

SHOULD = unless other things make it beneficiary to use a different path ?

 

A BIG T= hanks in Advance !

 

=

BR, Karen

= --_000_CF340E42AED0874C81947E18863DE77B29A8EE1D77EXMB03eutieto_-- From Michael.Tuexen@lurchi.franken.de Tue May 7 15:12:37 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9045911E80A5 for ; Tue, 7 May 2013 15:12:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.7 X-Spam-Level: X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, J_CHICKENPOX_35=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id amvALwaKM3k4 for ; Tue, 7 May 2013 15:12:36 -0700 (PDT) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by ietfa.amsl.com (Postfix) with ESMTP id B321121F92E8 for ; Tue, 7 May 2013 15:12:35 -0700 (PDT) Received: from [192.168.1.100] (p508F3C19.dip0.t-ipconnect.de [80.143.60.25]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 4D0691C0B3D00; Wed, 8 May 2013 00:12:24 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=windows-1252 From: Michael Tuexen In-Reply-To: <7FAB0DE0-C8AF-4A01-8325-756FB43FBFDD@earthlink.net> Date: Wed, 8 May 2013 00:12:24 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <3BCAAD04-E3C9-40F4-8FBE-4811F8B86E0A@lurchi.franken.de> References: <35233085-F7FE-49B3-AAE5-ECC99AC424D0@lurchi.franken.de> <05CC7816-B0BE-4A07-A497-6E8D8AC9D0BC@lurchi.franken.de> <7FAB0DE0-C8AF-4A01-8325-756FB43FBFDD@earthlink.net> To: Mitchell Erblich X-Mailer: Apple Mail (2.1283) Cc: "Karen.Nielsen@tieto.com>" , tsvwg Subject: Re: [tsvwg] 10 IW also for SCTP X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 May 2013 22:12:37 -0000 On May 7, 2013, at 11:54 AM, Mitchell Erblich wrote: > Hello, >=20 > Maybe I am wrong, but it seems that everyone with the emails is = only considering MTU / MSS sized segments=85 > and that any protocol including SCTP would limit an app bursting = segments onto a wire,,, >=20 > In the cases of an application initially limiting, aka pacing = TCP flow, such as a fair number of wirespeed echo requests/pings, > then both protocols SHOULD NOT limit the flow and wrt to = Allman's ABC, a large number of smaller segments > SHOULD then generate the sender equiv of ACK splitting=85. grow = the initial window faster than normal=85 I don't understand how using small messages instead of large messages = would grow the cwnd faster than allowed for SCTP. SCTP does ABC. >=20 > Thus, IMO, if the 10 or so segments are sub-MTU sized (i.e. = 128bytes) and sent with some minimal spacing, I would expect to be able = to grow the window faster in SS, mitigate any possible DELACKs and/or = loss of ACKs=85. Could you explain how this works for SCTP? >=20 > And if at the same time, additionally while segments are placed = on the wire, a few could be growing in size, additional growth can be = obtained (?unfairly obtained?) while probing for the number of = outstanding bytes (segments * avg size per segment) that could cause a = drop (or can frags occur below MTU sized segs or =85 ) =85.=20 Not sure I understand this... SCTP is counting the outstanding bytes. = This should cover messages of different sizes. Best regards Michael >=20 > Mitchell Erblich >=20 >=20 > On May 6, 2013, at 6:56 AM, = wrote: >=20 >> Hi, >>=20 >>> -----Original Message----- >>> From: Michael Tuexen [mailto:Michael.Tuexen@lurchi.franken.de] >>> Sent: Monday, May 06, 2013 2:57 PM >>> To: Nielsen Karen >>> Cc: tsvwg@ietf.org >>> Subject: Re: [tsvwg] 10 IW also for SCTP >>>=20 >>> On May 6, 2013, at 2:42 PM, >>> wrote: >>>=20 >>>> Hi, >>>>=20 >>>>>> But even if Max.Burst parameter is set to 4, can more than 4 full >>>>>> size packets be send prior to return of SACK. Max.Burst only >>>>>> regulate burst, not >>>>> CWND. >>>>> It depends what you consider a burst. Do include an application >>>>> calling send() in a loop, you might want to change cwnd by the >>>>> formula given in section 6.1, D). So you wouldn't send more than 4 = packets... >>>>>>=20 >>>>=20 >>>> I believe that section 6.1 D) proposes a way to implement Max.Burst = in >>>> an internal routine, not a way to limit initial CWND to 4 MTUs. >>>>=20 >>>> It says: >>>>=20 >>>> . The limit MAY be applied by adjusting >>>> cwnd as follows: >>>>=20 >>>> if((flightsize + Max.Burst*MTU) < cwnd) cwnd =3D flightsize + >>>> Max.Burst*MTU >>>>=20 >>>> Or it MAY be applied by strictly limiting the number of packets >>>> emitted by the output routine. >>> Before that RFC 4960 says: >>> D) When the time comes for the sender to transmit new DATA chunks, >>> the protocol parameter Max.Burst SHOULD be used to limit the >>> number of packets sent. >>>=20 >> Yes, Section 6.1 D) in full reads: >>=20 >> "When the time comes for the sender to transmit new DATA chunks, >> the protocol parameter Max.Burst SHOULD be used to limit the >> number of packets sent. The limit MAY be applied by adjusting >> cwnd as follows: >>=20 >> if((flightsize + Max.Burst*MTU) < cwnd) cwnd =3D flightsize + >> Max.Burst*MTU >>=20 >> Or it MAY be applied by strictly limiting the number of packets >> emitted by the output routine." >>=20 >> However "When the time comes for the sender to transmit new DATA = chunks" is not very well specified. It certainly does not >> clearly say that this assumes arrival of SACK and/or that new arrival = of data from application does not initiate new transmit. >>=20 >>> Assume that the application sends a lot of messages in a tight loop. = Shouldn't >>> Max.Burst limit the number of packets sent even if IW allows for = more?=20 >>=20 >> Well as specified it says that in one output routine, no more than = Max.burst *MTU SHOULD be send. >> If the intention was that at most Max.burst*MTU SHOULD be sent in = between SACK arrival and that it is new SACK arrival that >> allow for a new output routine to be initiated (or something like = that), then I think this deserves to be spelled out. >>=20 >>=20 >> A way to >>> implement this, is given by changing cwnd as described above. >>>>=20 >>>> So perhaps you are saying that FreeBSD implementation would = effectively limit >>> the IW to Max.Burst. >>>> If so, this would not be the case for all SCTP implementations. >>> I think if an SCTP implementation implements the above SHOULD, IW = would be >>> limited to Max.Burst. >>>>=20 >>=20 >> If the intention of the above SHOULD is as revealed in this thread, >> I would appreciate if an Errata was to be issued. >>=20 >> I think that it would also be good to understand the exact motivation = for this limitation. >>=20 >> No I am not certain that IW would be limited to Max.Burst even if the = above SHOULD was to be interpreted in this manner. >> I suppose that the arrival of SACK would allow for new data transmit = (or what else should then trick that a new output operation can be=20 >> started). If such SACK acknowledges the first 2*MTUs, I suppose that = one, with an IW of 10IW, could end up having 6*MTUs outstanding now. >> With IW of 4*MTU, at most 5 *MTUs could be outstanding at this point = in time.=20 >>=20 >> BR, Karen >>=20 >>>> Or do you mean to say that the intention of Section 6.1 D) also was = to keep the >>> IW under Max.Burst*MTU. >>> I just want to stress the point that in the case of SCTP there is = Max.Burst which has >>> to be taken into account. >>>>=20 >>>>>> Do you see any reason that SCTP should not follow TCP = experimental >>>>>> usage of >>>>> 10 IWs ? >>>>> I think you would need to change Max.Burst at the same time. Then = you >>>>> should get the same behavior. You can do the experiment... >>>>>=20 >>>>> However, Randy did some testing a while ago and reported that = using >>>>> Max.Burst of >>>>> 4 really helps to avoid messages being dropped. >>>>>=20 >>>>=20 >>>> That is very interesting as this sounds as to go against the TCP = experiments that >>> say that using 10 IWs is not an issue in today's networks. >>>> Or perhaps the situations tested were situations where a high, now = unused, CWND >>> had been build up ? >>>>=20 >>>>> Maybe I'm wrong, but IW of 10 just disables CC for short flows. = For >>>>> long living flows, I'm not sure if the IW makes a huge difference. >>>>>=20 >>>> Yes, I think that this is true. The same is the case for TCP. >>>> This does depend, however, on whether one also augments the restart >>>> window and possibly also the window (CWND/2) used after loss = recovery. >>>> ( If so, then for both, one should have to follow the prescriptions = of >>>> RFC6928 of not to increase the CWND in these situations.) >>>>=20 >>>> It can be noted that RFC6928 does not speak about allowing the = window >>>> after loss recovery to be higher then 2MTUs (if CWND/2 <=3D 2MTU). = The >>>> same is the case for RFC3390, but nevertheless RFC4960 implements = that the >>> window after loss recovery does not go beneath 4 MTUs. >>>>=20 >>>>> Except for the Max.Burst dependency, >>>>=20 >>>> I do not see any such dependency from Section 6.1 D). >>>>=20 >>>> I don't see a huge difference between TCP >>>>> and SCTP. >>>>=20 >>>> Thanks. >>>>=20 >>>> BR, Karen >>>>>=20 >>>>> Best regards >>>>> Michael >>>>>>=20 >>>>>> BR, Karen >>>>>>=20 >>>>>>=20 >>>>>>> Best regards >>>>>>> Michael >>>>>>>>=20 >>>>>>>> Thanks! >>>>>>>>=20 >>>>>>>> BR, Karen >>>>>>=20 >>>>>>=20 >>>>=20 >>>>=20 >>=20 >=20 >=20 From Karen.Nielsen@tieto.com Wed May 8 06:36:34 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8CBE21F93F4 for ; Wed, 8 May 2013 06:36:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_35=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 56YYh98b4rXw for ; Wed, 8 May 2013 06:36:30 -0700 (PDT) Received: from ebb06.tieto.com (ebb06.tieto.com [131.207.168.38]) by ietfa.amsl.com (Postfix) with ESMTP id 525FE21F899E for ; Wed, 8 May 2013 06:36:28 -0700 (PDT) X-AuditID: 83cfa826-b7f4b6d000000a28-02-518a54da0c84 Received: from FIHGA-EXHUB01.eu.tieto.com ( [131.207.136.34]) by ebb06.tieto.com (SMTP Mailer) with SMTP id C0.BB.02600.AD45A815; Wed, 8 May 2013 16:36:26 +0300 (EEST) Received: from EXMB03.eu.tieto.com ([169.254.1.45]) by FIHGA-EXHUB01.eu.tieto.com ([131.207.136.34]) with mapi; Wed, 8 May 2013 16:36:26 +0300 From: To: Date: Wed, 8 May 2013 16:36:25 +0300 Thread-Topic: [tsvwg] 10 IW also for SCTP Thread-Index: Ac5Kk5adH1kpUWJ8T8m3RHksj+0ZEgBUgJtQ Message-ID: References: <35233085-F7FE-49B3-AAE5-ECC99AC424D0@lurchi.franken.de> <05CC7816-B0BE-4A07-A497-6E8D8AC9D0BC@lurchi.franken.de> <300485F2-2BB1-4761-ACA5-96C564B0D6B3@lurchi.franken.de> In-Reply-To: <300485F2-2BB1-4761-ACA5-96C564B0D6B3@lurchi.franken.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprHKsWRmVeSWpSXmKPExsXSfL5DSfdWSFegwa7zBhYXm5YwWhx7c5fN gcljyZKfTB4bWnYwBTBFcdmkpOZklqUW6dslcGXsWjWHqeC3Y8XKycsYGxh7TLoYOTkkBEwk 7l3rYoKwxSQu3FvP1sXIxSEksIpRYtXE08wQziRGiX2fbrKAVLEJyEvM3buKHcQWEVCTuHf6 IWsXIwcHs4CIxJzfGiAmi4CKxPX1YDOFBTQk/rauZoKo1pRoub0GqtNIYveW5cwgNq+Aj0T3 /OWsILaQQCOLxJ5reiA2p4CrxLb/u9hAbEag276fWgM2h1lAXOLWk/lQNwtILNlznhnCFpV4 +fgfK0S9qMSd9vWMEPU6Egt2f2KDsLUlli18DbVXUOLkzCcsExjFZiEZOwtJyywkLbOQtCxg ZFnFyJ+alGRgpleSmVqSr5ecn7uJERwxK9R2MD57IHWIUYCDUYmH14K7M1CINbGsuDL3EKMk B5OSKO8hz65AIb6k/JTKjMTijPii0pzU4kOMEhzMSiK8Ag+BynlTEiurUovyYVIyHBxKEry1 wUBtgkWp6akVaZk5wLQAk2bi4ARp5wFqnwJSw1tckJhbnJkOkT/FqMvx5tqL14xCLHn5ealS 4rySIEUCIEUZpXlwc2DJ6hWjONDhwrxHQKp4gIkObtIroCVMQEsS+NpBlpQkIqSkGhhzLnE2 BcXH1RrNOLLhrg1n2AuulTdD1Xa+lhVeo+Kk/fhLpuWcahuBfCXlwqMZyysyPz5cekND3sfP R/r/1IQ+/+xDZQfarPZN05b5wJjAKbDZ/3H+U5H5rkK8v+Xv6Qr+7BfV+bCvzTPbl5+NyXfy 7v93Z2tN0vqsHKZSr8mz5fPXC9UnLyqxFGckGmoxFxUnAgAWGCx+MQMAAA== Cc: tsvwg@ietf.org Subject: Re: [tsvwg] 10 IW also for SCTP X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 May 2013 13:36:35 -0000 Hi Michael, I think that it is fair to conclude that it is not exactly clear from RFC49= 60 (or RFC4460) what is meant by the term "When the time comes for the sender to transmit new DATA chunks"=20 in Section 6.1. D) of RFC4960. The communication from=20 http://www.ietf.org/mail-archive/web/tsvwg/current/msg07095.html also makes it painfully clear that consensus on the exact meaning has not b= een reached. I think what at this stage we can conclude only that the Max.Burst paramete= r of SCTP may=20 impact (limit, but not prevent) the ability of an SCTP implementation to ex= ploit an Initial Window larger than Max.Burst*MTU. But also that the exact limitatio= n that the Max.Burst=20 parameter constitutes in this respect will depend on the SCTP implementatio= n. As to the topic of deploying larger initial window for SCTP we shall see as= what will come from such experiments. I think that the feedback here was that there are no particular reasons why= it should not be equally relevant to do such for SCTP as for TCP.=20 BR, Karen >-----Original Message----- >From: Michael Tuexen [mailto:Michael.Tuexen@lurchi.franken.de] >Sent: Monday, May 06, 2013 9:55 PM >To: Nielsen Karen >Cc: tsvwg@ietf.org >Subject: Re: [tsvwg] 10 IW also for SCTP > >On May 6, 2013, at 3:56 PM, > wrote: > >> Hi, >> >>> -----Original Message----- >>> From: Michael Tuexen [mailto:Michael.Tuexen@lurchi.franken.de] >>> Sent: Monday, May 06, 2013 2:57 PM >>> To: Nielsen Karen >>> Cc: tsvwg@ietf.org >>> Subject: Re: [tsvwg] 10 IW also for SCTP >>> >>> On May 6, 2013, at 2:42 PM, >>> wrote: >>> >>>> Hi, >>>> >>>>>> But even if Max.Burst parameter is set to 4, can more than 4 full >>>>>> size packets be send prior to return of SACK. Max.Burst only >>>>>> regulate burst, not >>>>> CWND. >>>>> It depends what you consider a burst. Do include an application >>>>> calling send() in a loop, you might want to change cwnd by the >>>>> formula given in section 6.1, D). So you wouldn't send more than 4 pa= ckets... >>>>>> >>>> >>>> I believe that section 6.1 D) proposes a way to implement Max.Burst >>>> in an internal routine, not a way to limit initial CWND to 4 MTUs. >>>> >>>> It says: >>>> >>>> . The limit MAY be applied by adjusting >>>> cwnd as follows: >>>> >>>> if((flightsize + Max.Burst*MTU) < cwnd) cwnd =3D flightsize + >>>> Max.Burst*MTU >>>> >>>> Or it MAY be applied by strictly limiting the number of packets >>>> emitted by the output routine. >>> Before that RFC 4960 says: >>> D) When the time comes for the sender to transmit new DATA chunks, >>> the protocol parameter Max.Burst SHOULD be used to limit the >>> number of packets sent. >>> >> Yes, Section 6.1 D) in full reads: >> >> "When the time comes for the sender to transmit new DATA chunks, >> the protocol parameter Max.Burst SHOULD be used to limit the >> number of packets sent. The limit MAY be applied by adjusting >> cwnd as follows: >> >> if((flightsize + Max.Burst*MTU) < cwnd) cwnd =3D flightsize + >> Max.Burst*MTU >> >> Or it MAY be applied by strictly limiting the number of packets >> emitted by the output routine." >> >> However "When the time comes for the sender to transmit new DATA >> chunks" is not very well specified. It certainly does not clearly say th= at this >assumes arrival of SACK and/or that new arrival of data from application d= oes not >initiate new transmit. >True. The intention is to mitigate packet bursts. For the network it doesn= 't matter >how the burst are generated. So the text is generic. >> >>> Assume that the application sends a lot of messages in a tight loop. >>> Shouldn't Max.Burst limit the number of packets sent even if IW allows = for >more? >> >> Well as specified it says that in one output routine, no more than Max.b= urst *MTU >SHOULD be send. >> If the intention was that at most Max.burst*MTU SHOULD be sent in >> between SACK arrival and that it is new SACK arrival that allow for a ne= w output >routine to be initiated (or something like that), then I think this deserv= es to be >spelled out. >Only limiting to Max.burst in the output routing would avoid bursts in res= ponse to >incoming SACks. It would not cover bursts initiated by an application call= ing send in >bursts. I agree, the text is not very explicit, but taking the goal into a= ccount helps... > >This goes back to burst mitigation stuff by Mark Allman. For whatever reas= on it >didn't make it into an TCP RFC... >> >> >> A way to >>> implement this, is given by changing cwnd as described above. >>>> >>>> So perhaps you are saying that FreeBSD implementation would >>>> effectively limit >>> the IW to Max.Burst. >>>> If so, this would not be the case for all SCTP implementations. >>> I think if an SCTP implementation implements the above SHOULD, IW >>> would be limited to Max.Burst. >>>> >> >> If the intention of the above SHOULD is as revealed in this thread, I >> would appreciate if an Errata was to be issued. >> >> I think that it would also be good to understand the exact motivation fo= r this >limitation. >Have a look at >http://www.icsi.berkeley.edu/pubs/networking/measuringinteractions05.pdf >> >> No I am not certain that IW would be limited to Max.Burst even if the ab= ove >SHOULD was to be interpreted in this manner. >> I suppose that the arrival of SACK would allow for new data transmit >> (or what else should then trick that a new output operation can be start= ed). If such >SACK acknowledges the first 2*MTUs, I suppose that one, with an IW of 10IW= , >could end up having 6*MTUs outstanding now. >> With IW of 4*MTU, at most 5 *MTUs could be outstanding at this point in = time. >I'm not saying that the IW is limited to value of Max.Burst. I'm saying th= at the >Max.Burst limitation has to be considered and results in not immediately b= eing able >to send the whole IW. > >Best regards >Michael >> >> BR, Karen >> >>>> Or do you mean to say that the intention of Section 6.1 D) also was >>>> to keep the >>> IW under Max.Burst*MTU. >>> I just want to stress the point that in the case of SCTP there is >>> Max.Burst which has to be taken into account. >>>> >>>>>> Do you see any reason that SCTP should not follow TCP experimental >>>>>> usage of >>>>> 10 IWs ? >>>>> I think you would need to change Max.Burst at the same time. Then >>>>> you should get the same behavior. You can do the experiment... >>>>> >>>>> However, Randy did some testing a while ago and reported that using >>>>> Max.Burst of >>>>> 4 really helps to avoid messages being dropped. >>>>> >>>> >>>> That is very interesting as this sounds as to go against the TCP >>>> experiments that >>> say that using 10 IWs is not an issue in today's networks. >>>> Or perhaps the situations tested were situations where a high, now >>>> unused, CWND >>> had been build up ? >>>> >>>>> Maybe I'm wrong, but IW of 10 just disables CC for short flows. For >>>>> long living flows, I'm not sure if the IW makes a huge difference. >>>>> >>>> Yes, I think that this is true. The same is the case for TCP. >>>> This does depend, however, on whether one also augments the restart >>>> window and possibly also the window (CWND/2) used after loss recovery. >>>> ( If so, then for both, one should have to follow the prescriptions >>>> of >>>> RFC6928 of not to increase the CWND in these situations.) >>>> >>>> It can be noted that RFC6928 does not speak about allowing the >>>> window after loss recovery to be higher then 2MTUs (if CWND/2 <=3D >>>> 2MTU). The same is the case for RFC3390, but nevertheless RFC4960 >>>> implements that the >>> window after loss recovery does not go beneath 4 MTUs. >>>> >>>>> Except for the Max.Burst dependency, >>>> >>>> I do not see any such dependency from Section 6.1 D). >>>> >>>> I don't see a huge difference between TCP >>>>> and SCTP. >>>> >>>> Thanks. >>>> >>>> BR, Karen >>>>> >>>>> Best regards >>>>> Michael >>>>>> >>>>>> BR, Karen >>>>>> >>>>>> >>>>>>> Best regards >>>>>>> Michael >>>>>>>> >>>>>>>> Thanks! >>>>>>>> >>>>>>>> BR, Karen >>>>>> >>>>>> >>>> >>>> >> >> From Michael.Tuexen@lurchi.franken.de Wed May 8 11:12:54 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B138221F926E for ; Wed, 8 May 2013 11:12:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.349 X-Spam-Level: X-Spam-Status: No, score=-1.349 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, J_CHICKENPOX_35=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AtbcjH1kwfDL for ; Wed, 8 May 2013 11:12:53 -0700 (PDT) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by ietfa.amsl.com (Postfix) with ESMTP id 1143B21F9080 for ; Wed, 8 May 2013 11:12:52 -0700 (PDT) Received: from [192.168.1.100] (p508F3DC9.dip0.t-ipconnect.de [80.143.61.201]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 4CAEF1C1051EA; Wed, 8 May 2013 20:12:49 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Michael Tuexen In-Reply-To: Date: Wed, 8 May 2013 20:12:48 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <49D61567-CE0B-4BF0-A0A7-E8CAC7B304E9@lurchi.franken.de> References: <35233085-F7FE-49B3-AAE5-ECC99AC424D0@lurchi.franken.de> <05CC7816-B0BE-4A07-A497-6E8D8AC9D0BC@lurchi.franken.de> <300485F2-2BB1-4761-ACA5-96C564B0D6B3@lurchi.franken.de> To: X-Mailer: Apple Mail (2.1283) Cc: tsvwg@ietf.org Subject: Re: [tsvwg] 10 IW also for SCTP X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 May 2013 18:12:54 -0000 On May 8, 2013, at 3:36 PM, = wrote: > Hi Michael, >=20 > I think that it is fair to conclude that it is not exactly clear from = RFC4960 (or RFC4460) what is meant by the term >=20 > "When the time comes for the sender to transmit new DATA chunks"=20 >=20 > in Section 6.1. D) of RFC4960. I agree.=20 >=20 > The communication from=20 >=20 > http://www.ietf.org/mail-archive/web/tsvwg/current/msg07095.html >=20 > also makes it painfully clear that consensus on the exact meaning has = not been reached. >=20 > I think what at this stage we can conclude only that the Max.Burst = parameter of SCTP may=20 > impact (limit, but not prevent) the ability of an SCTP implementation = to exploit an > Initial Window larger than Max.Burst*MTU. But also that the exact = limitation that the Max.Burst=20 > parameter constitutes in this respect will depend on the SCTP = implementation. Agreed. >=20 > As to the topic of deploying larger initial window for SCTP we shall = see as what will come from such experiments. > I think that the feedback here was that there are no particular = reasons why it should not be equally relevant to do such > for SCTP as for TCP.=20 Agreed. Best regards Michael >=20 > BR, Karen >=20 >=20 >> -----Original Message----- >> From: Michael Tuexen [mailto:Michael.Tuexen@lurchi.franken.de] >> Sent: Monday, May 06, 2013 9:55 PM >> To: Nielsen Karen >> Cc: tsvwg@ietf.org >> Subject: Re: [tsvwg] 10 IW also for SCTP >>=20 >> On May 6, 2013, at 3:56 PM, >> wrote: >>=20 >>> Hi, >>>=20 >>>> -----Original Message----- >>>> From: Michael Tuexen [mailto:Michael.Tuexen@lurchi.franken.de] >>>> Sent: Monday, May 06, 2013 2:57 PM >>>> To: Nielsen Karen >>>> Cc: tsvwg@ietf.org >>>> Subject: Re: [tsvwg] 10 IW also for SCTP >>>>=20 >>>> On May 6, 2013, at 2:42 PM, >>>> wrote: >>>>=20 >>>>> Hi, >>>>>=20 >>>>>>> But even if Max.Burst parameter is set to 4, can more than 4 = full >>>>>>> size packets be send prior to return of SACK. Max.Burst only >>>>>>> regulate burst, not >>>>>> CWND. >>>>>> It depends what you consider a burst. Do include an application >>>>>> calling send() in a loop, you might want to change cwnd by the >>>>>> formula given in section 6.1, D). So you wouldn't send more than = 4 packets... >>>>>>>=20 >>>>>=20 >>>>> I believe that section 6.1 D) proposes a way to implement = Max.Burst >>>>> in an internal routine, not a way to limit initial CWND to 4 MTUs. >>>>>=20 >>>>> It says: >>>>>=20 >>>>> . The limit MAY be applied by adjusting >>>>> cwnd as follows: >>>>>=20 >>>>> if((flightsize + Max.Burst*MTU) < cwnd) cwnd =3D flightsize + >>>>> Max.Burst*MTU >>>>>=20 >>>>> Or it MAY be applied by strictly limiting the number of packets >>>>> emitted by the output routine. >>>> Before that RFC 4960 says: >>>> D) When the time comes for the sender to transmit new DATA chunks, >>>> the protocol parameter Max.Burst SHOULD be used to limit the >>>> number of packets sent. >>>>=20 >>> Yes, Section 6.1 D) in full reads: >>>=20 >>> "When the time comes for the sender to transmit new DATA chunks, >>> the protocol parameter Max.Burst SHOULD be used to limit the >>> number of packets sent. The limit MAY be applied by adjusting >>> cwnd as follows: >>>=20 >>> if((flightsize + Max.Burst*MTU) < cwnd) cwnd =3D flightsize + >>> Max.Burst*MTU >>>=20 >>> Or it MAY be applied by strictly limiting the number of packets >>> emitted by the output routine." >>>=20 >>> However "When the time comes for the sender to transmit new DATA >>> chunks" is not very well specified. It certainly does not clearly = say that this >> assumes arrival of SACK and/or that new arrival of data from = application does not >> initiate new transmit. >> True. The intention is to mitigate packet bursts. For the network it = doesn't matter >> how the burst are generated. So the text is generic. >>>=20 >>>> Assume that the application sends a lot of messages in a tight = loop. >>>> Shouldn't Max.Burst limit the number of packets sent even if IW = allows for >> more? >>>=20 >>> Well as specified it says that in one output routine, no more than = Max.burst *MTU >> SHOULD be send. >>> If the intention was that at most Max.burst*MTU SHOULD be sent in >>> between SACK arrival and that it is new SACK arrival that allow for = a new output >> routine to be initiated (or something like that), then I think this = deserves to be >> spelled out. >> Only limiting to Max.burst in the output routing would avoid bursts = in response to >> incoming SACks. It would not cover bursts initiated by an application = calling send in >> bursts. I agree, the text is not very explicit, but taking the goal = into account helps... >>=20 >> This goes back to burst mitigation stuff by Mark Allman. For whatever = reason it >> didn't make it into an TCP RFC... >>>=20 >>>=20 >>> A way to >>>> implement this, is given by changing cwnd as described above. >>>>>=20 >>>>> So perhaps you are saying that FreeBSD implementation would >>>>> effectively limit >>>> the IW to Max.Burst. >>>>> If so, this would not be the case for all SCTP implementations. >>>> I think if an SCTP implementation implements the above SHOULD, IW >>>> would be limited to Max.Burst. >>>>>=20 >>>=20 >>> If the intention of the above SHOULD is as revealed in this thread, = I >>> would appreciate if an Errata was to be issued. >>>=20 >>> I think that it would also be good to understand the exact = motivation for this >> limitation. >> Have a look at >> = http://www.icsi.berkeley.edu/pubs/networking/measuringinteractions05.pdf >>>=20 >>> No I am not certain that IW would be limited to Max.Burst even if = the above >> SHOULD was to be interpreted in this manner. >>> I suppose that the arrival of SACK would allow for new data transmit >>> (or what else should then trick that a new output operation can be = started). If such >> SACK acknowledges the first 2*MTUs, I suppose that one, with an IW of = 10IW, >> could end up having 6*MTUs outstanding now. >>> With IW of 4*MTU, at most 5 *MTUs could be outstanding at this point = in time. >> I'm not saying that the IW is limited to value of Max.Burst. I'm = saying that the >> Max.Burst limitation has to be considered and results in not = immediately being able >> to send the whole IW. >>=20 >> Best regards >> Michael >>>=20 >>> BR, Karen >>>=20 >>>>> Or do you mean to say that the intention of Section 6.1 D) also = was >>>>> to keep the >>>> IW under Max.Burst*MTU. >>>> I just want to stress the point that in the case of SCTP there is >>>> Max.Burst which has to be taken into account. >>>>>=20 >>>>>>> Do you see any reason that SCTP should not follow TCP = experimental >>>>>>> usage of >>>>>> 10 IWs ? >>>>>> I think you would need to change Max.Burst at the same time. Then >>>>>> you should get the same behavior. You can do the experiment... >>>>>>=20 >>>>>> However, Randy did some testing a while ago and reported that = using >>>>>> Max.Burst of >>>>>> 4 really helps to avoid messages being dropped. >>>>>>=20 >>>>>=20 >>>>> That is very interesting as this sounds as to go against the TCP >>>>> experiments that >>>> say that using 10 IWs is not an issue in today's networks. >>>>> Or perhaps the situations tested were situations where a high, now >>>>> unused, CWND >>>> had been build up ? >>>>>=20 >>>>>> Maybe I'm wrong, but IW of 10 just disables CC for short flows. = For >>>>>> long living flows, I'm not sure if the IW makes a huge = difference. >>>>>>=20 >>>>> Yes, I think that this is true. The same is the case for TCP. >>>>> This does depend, however, on whether one also augments the = restart >>>>> window and possibly also the window (CWND/2) used after loss = recovery. >>>>> ( If so, then for both, one should have to follow the = prescriptions >>>>> of >>>>> RFC6928 of not to increase the CWND in these situations.) >>>>>=20 >>>>> It can be noted that RFC6928 does not speak about allowing the >>>>> window after loss recovery to be higher then 2MTUs (if CWND/2 <=3D >>>>> 2MTU). The same is the case for RFC3390, but nevertheless RFC4960 >>>>> implements that the >>>> window after loss recovery does not go beneath 4 MTUs. >>>>>=20 >>>>>> Except for the Max.Burst dependency, >>>>>=20 >>>>> I do not see any such dependency from Section 6.1 D). >>>>>=20 >>>>> I don't see a huge difference between TCP >>>>>> and SCTP. >>>>>=20 >>>>> Thanks. >>>>>=20 >>>>> BR, Karen >>>>>>=20 >>>>>> Best regards >>>>>> Michael >>>>>>>=20 >>>>>>> BR, Karen >>>>>>>=20 >>>>>>>=20 >>>>>>>> Best regards >>>>>>>> Michael >>>>>>>>>=20 >>>>>>>>> Thanks! >>>>>>>>>=20 >>>>>>>>> BR, Karen >>>>>>>=20 >>>>>>>=20 >>>>>=20 >>>>>=20 >>>=20 >>>=20 >=20 >=20 From nishida@sfc.wide.ad.jp Wed May 8 12:02:09 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC7DE21F8481 for ; Wed, 8 May 2013 12:02:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.977 X-Spam-Level: X-Spam-Status: No, score=-101.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W6OQgRqKF2jp for ; Wed, 8 May 2013 12:02:09 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (ns.sfc.wide.ad.jp [IPv6:2001:200:0:8803:203:178:142:143]) by ietfa.amsl.com (Postfix) with ESMTP id BA69F21F84D9 for ; Wed, 8 May 2013 12:01:57 -0700 (PDT) Received: from mail-lb0-f169.google.com (mail-lb0-f169.google.com [209.85.217.169]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 4BBC42780A7 for ; Thu, 9 May 2013 04:01:55 +0900 (JST) Received: by mail-lb0-f169.google.com with SMTP id z5so2285402lbh.0 for ; Wed, 08 May 2013 12:01:52 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=If7aFN3Exywt+XkZtPJu3MBFRNYSqIJk4KR/AUO/9N4=; b=cEkCwe2b9k9gvQguyxwOt/9TtFWgV2mtM3Fwl2nWYooRRhEPQRmtDVso0mto7IMjaR Q9+xAPFOjgvWM61tmPlbO1pYDjjefX4IK3K/9CGMGRQxJv8Aszlv4KD569nUnjBmYOLp z9aGQFbjyD1ugq8rFr+qwycw5j1HCbEYPbWMkuIf15zLxMI1DHrQZYQLm3lgifov+JW6 7qChUJhNczNUlqR0EJVko2taFIKgmEo4XHvKeyoND6eBZjzqI1fHDf9wPJYLRjYA8CJB XUgz1I32xWyAGnwFVZzm5BD0X1NnMkQuxO1PySoW+ObE21ggyGXOujSw8jgTJSSPLspN OuhQ== MIME-Version: 1.0 X-Received: by 10.112.5.137 with SMTP id s9mr3848113lbs.68.1368039712454; Wed, 08 May 2013 12:01:52 -0700 (PDT) Received: by 10.114.62.237 with HTTP; Wed, 8 May 2013 12:01:52 -0700 (PDT) In-Reply-To: References: Date: Wed, 8 May 2013 12:01:52 -0700 Message-ID: From: Yoshifumi Nishida To: Karen.Nielsen@tieto.com Content-Type: text/plain; charset=ISO-8859-1 Cc: tsvwg Subject: Re: [tsvwg] QUESTION on Return of SACKs and HB ACKs X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 May 2013 19:02:09 -0000 Hi Karen, I'm trying to see what kind of benefits we can get by this. Do you have some use cases? Thanks, -- Yoshifumi On Tue, May 7, 2013 at 3:05 AM, wrote: > Hi, > > > > RFC4960 in Section 6.4 opens up for the possibility that SACKs may be > returned on a different path (or IP Path) > > that the reflected path (or IP Path) of the incoming Data. > > > > This, as said in RFC4960, can be the situation when a SACK acknowledges Data > TSNs that have come in on different paths as well as it > > may (MAY) be a beneficial reaction if evidence is available that indicates > the unavailability of the reflected data path. Such unavailability > > evidence could come from arrival of duplicate Data chunks (as pointed to in > RFC4960) possibly such evidence could also be established > > by other means (like e.g., if HBs indicates the reflected Path to be > unavailable). The latter aspect are not mentioned in RFC4960. > > > > I am wondering, if anybody (IETF SCTP community and/or RFC4960 Authors) has > any view on the validity (or the contrary) of > > not returning SACKs on the reflected IP Path ? > > > > Obviously it is very important for the path selection for return of SACKs to > be as > > stable and consistent as feasible, as one otherwise risks to jeopardize the > validity of Data RTT measurements of peer, and using the reflected IP path > > is one way to achieve this. But having said this, then I wonder if there > otherwise are considered to be significant problems with the > > return of SACKs via paths there are different from the reflected IP Path of > Data. Issues that makes is so that an SCTP implementation should best > possible prevent situations where data and SACK do not follow the same path > (in opposite directions). > > > > Possibly also the situation with return of SACKs acknowledging Data chunks > that have come in on multiple paths will be even more relevant for CMT-SCTP. > > This may open up for either demanding for SACKs to be returned split > according to the incoming path of Data or for the recommendation of RFC4960 > to use reflected path of Data to be broaden up to recommend for consistent > choice of return path of SACKs. > > > > Finally following the thoughts above for SACK return, then one may also > think about the corresponding situation with the return of HB ACKs. > > > > RFC4960 seems to assume for HB ACKs always to be returned on the reflected > path of the HB as it says, Section 3.3.6, but notably the only Keyword > > that applies to return of HB ACK is the SHOULD of Section 6.4 : > > > > A HEARTBEAT ACK is always > > sent to the source IP address of the IP datagram containing the > > HEARTBEAT chunk to which this ack is responding. > > > > Also here one can wonder as to whether it is best to have the HB ACK > returned in the path over which it is most likely to reach peer or whether > > it must (?) be returned on the reflect path of the incoming HB. I am not > sure if the RFC4960 SHOULD here should be read mostly as a MUST or mostly as > a > > SHOULD unless other things make it beneficiary to use a different path ? > > > > A BIG Thanks in Advance ! > > > > BR, Karen From bidulock@openss7.org Thu May 9 15:19:34 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC1BB21F902D for ; Thu, 9 May 2013 15:19:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.3 X-Spam-Level: X-Spam-Status: No, score=-5.3 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eEK9J4csyyLg for ; Thu, 9 May 2013 15:19:30 -0700 (PDT) Received: from gw.openss7.com (gw.openss7.com [142.59.210.7]) by ietfa.amsl.com (Postfix) with ESMTP id 2602921F9017 for ; Thu, 9 May 2013 15:19:29 -0700 (PDT) Received: from wilbur.pigworks.openss7.net (ns5.evil.openss7.net [192.168.9.5]) by gw.openss7.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id r49MJSYU008693; Thu, 9 May 2013 16:19:28 -0600 Received: from wilbur.pigworks.openss7.net (localhost [127.0.0.1]) by wilbur.pigworks.openss7.net (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id r49MJSl2001963; Thu, 9 May 2013 16:19:28 -0600 Received: (from brian@localhost) by wilbur.pigworks.openss7.net (8.14.3/8.14.3/Submit) id r49MJRI4001951; Thu, 9 May 2013 16:19:27 -0600 Date: Thu, 9 May 2013 16:19:27 -0600 From: "Brian F. G. Bidulock" To: Karen.Nielsen@tieto.com Message-ID: <20130509221927.GB24653@openss7.org> Mail-Followup-To: Karen.Nielsen@tieto.com, tsvwg@ietf.org References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Organization: http://www.openss7.org/ Dsn-Notification-To: X-Spam-To: User-Agent: Mutt/1.5.18 (2008-05-17) Cc: tsvwg@ietf.org Subject: Re: [tsvwg] QUESTION on Return of SACKs and HB ACKs X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: bidulock@openss7.org List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 May 2013 22:19:34 -0000 Karen, First off, I would like to discourage you from using the term "path": SCTP has no concept of a path (largely because IP underneath it doesn't either). The only real choice SCTP has over how a packet gets to the peer is by setting the destination IP address. So consider whether packets containing response chunks should be sent to the destination address that was provided as a source address in the corresponding request chunk, rather than paths. Indeed, by sending a response packet to the source address of the packet containing the request may not take the reverse path through the network that was traversed by the request packet at all. In fact, it might not even be the normal case for all but the most trivial of networks. Please see more comment inline... Karen.Nielsen@tieto.com wrote: (Tue, 07 May 2013 13:05:43) > > I am wondering, if anybody (IETF SCTP community and/or RFC4960 > Authors) has any view on the validity (or the contrary) of not > returning SACKs on the reflected IP Path ? IMO there no reason to send SACK and DATA to different destinations. Bundling SACK and DATA are essential for efficiency at high throughputs. The "best" destination should be used for both, where the "best" destination is the primary DATA destination for non-CMT. > Possibly also the situation with return of SACKs acknowledging > Data chunks that have come in on multiple paths will be even more > relevant for CMT-SCTP. CMT needs to perform some sort of gap-ack merging to suppress spurious fast retransmit. It can be done both at the sender and at the receiver. SACKs that make it out of this logic at the sender should still be sent to the "best" destination and bundled with DATA wherever possible. The "best" destination in this case is determined by the CMT distribution logic. > Finally following the thoughts above for SACK return, then one may > also think about the corresponding situation with the return of HB > ACKs. > Also here one can wonder as to whether it is best to have the HB > ACK returned in the path over which it is most likely to reach > peer or whether it must (?) be returned on the reflect path of the > incoming HB. I am not sure if the RFC4960 SHOULD here should be > read mostly as a MUST or mostly as a SHOULD unless other things > make it beneficiary to use a different path ? HB are a little different. COOKIE-ACK, HEARTBEAT-ACK, SHUTDOWN-ACK, SHUTDOWN-COMPLETE, ASCONF-ACK, should IMO be sent to the source address contained in the corresponding request chunk, so long as the destination is considered viable. Otherwise, it should send to the "best" destination. These approaches work quite well in practice. --brian -- Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ From david.black@emc.com Mon May 13 15:32:23 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 249AB21F9184 for ; Mon, 13 May 2013 15:32:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5+qLbDw-fi1r for ; Mon, 13 May 2013 15:32:13 -0700 (PDT) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id 5686821F90C1 for ; Mon, 13 May 2013 15:32:12 -0700 (PDT) Received: from hop04-l1d11-si03.isus.emc.com (HOP04-L1D11-SI03.isus.emc.com [10.254.111.23]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r4DMW5a6027512 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 13 May 2013 18:32:10 -0400 Received: from mailhub.lss.emc.com (mailhubhoprd05.lss.emc.com [10.254.222.129]) by hop04-l1d11-si03.isus.emc.com (RSA Interceptor) for ; Mon, 13 May 2013 18:31:52 -0400 Received: from mxhub31.corp.emc.com (mxhub31.corp.emc.com [128.222.70.171]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r4DMVpeE025009 for ; Mon, 13 May 2013 18:31:52 -0400 Received: from mx15a.corp.emc.com ([169.254.1.105]) by mxhub31.corp.emc.com ([128.222.70.171]) with mapi; Mon, 13 May 2013 18:31:51 -0400 From: "Black, David" To: Transport Area Working Group Discussion List Date: Mon, 13 May 2013 18:31:49 -0400 Thread-Topic: NomCom 2013-2014 Call for Volunteers - CORRECTED dates in first sentence Thread-Index: AQHOUCCmBLbvJmEKmEyg4la0xaxgjpkDsskg Message-ID: <8D3D17ACE214DC429325B2B98F3AE712953BA68F@MX15A.corp.emc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 Subject: [tsvwg] FW: NomCom 2013-2014 Call for Volunteers - CORRECTED dates in first sentence X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 May 2013 22:32:23 -0000 Please give some thought to participating in this year's NomCom. This is a great way to contribute to the IETF. Thanks, --David -----Original Message----- From: ietf-announce-bounces@ietf.org [mailto:ietf-announce-bounces@ietf.org= ] On Behalf Of Mankin, Allison Sent: Monday, May 13, 2013 5:27 PM To: ietf-announce@ietf.org Subject: NomCom 2013-2014 Call for Volunteers - CORRECTED dates in first se= ntence The IETF nominating committee (nomcom) process for 2013-14 has begun. The=20 IETF nomcom appoints folks to fill the open slots on the IAOC, the IAB, and the IESG. Ten voting members for the nomcom are selected in a verifiabl= y random way from a pool of volunteers. The more volunteers, the better chanc= e we have of choosing a random yet representative cross section of the IETF population. This year, a challenge: let's get beyond the 100-mark for number of volunteers. Let's get to 200 volunteers! The details of the operation of the nomcom can be found in RFC 3777. =20 =20 Volunteers must have attended 3 of the past 5 IETF meetings. As specified = in RFC 3777, that means three out of the five past meetings up to the time thi= s email announcement goes out to start the solicitation of volunteers. The fi= ve meetings out of which you must have attended three are IETF 82, 83, 84, 85,= 86. If you qualify, please volunteer. However, much as we want this, before yo= u=20 decide to volunteer, please be sure you are willing to forgo appointment to any of the positions for which this nomcom is responsible. =20 =20 The list of people and posts whose terms end with the March 2014 IETF meeting, and thus the positions for which this nomcom is responsible, are IAOC: Chris Griffiths IAB: Bernard Aboba Marc Blanchet Ross Callon Eliot Lear Hannes Tschofenig IESG: Barry Leiba (Applications) Brian Haberman (Internet) Benoit Claise (Operations and Management) Gonzalo Camarillo (RAI) Stewart Bryant (Routing) Sean Turner (Security) Martin Stiemerling (Transport) The primary activity for this nomcom will begin in July 2013 and should be completed in January 2014. The nomcom will have regularly scheduled conference calls to ensure progress. There will be activities to collect=20 requirements from the community, review candidate questionnaires, review feedback from community members about candidates, and talk to=20 candidates. Thus, being a nomcom member does require some time commitment. Please volunteer by sending me an email before 11:59 pm EDT (UTC -4 hours)= =20 June 16, 2013, as follows: To: amankin@verisign.com Subject: Nomcom 2013-14 Volunteer Please include the following information in the email body: =20 // First/Given Name followed by Last/Family Name // matching how you enter it in the IETF Registration Form) // Typically what goes in the Company field // in the IETF Registration Form [] =20 =20 // For confirmation if selected You should expect an email response from me within 3 business days stating whether or not you are qualified. If you don't receive this response, please re-send your email with the tag "RESEND"" added to the subject line. If you are not yet sure if you would like to volunteer, please consider that nomcom members play a very important role in shaping the leadership of the IETF. Volunteering for the nomcom is a great way to contribute to the IETF!=20 I will be publishing a more detailed target timetable, as well as details=20 of the randomness seeds to be used for the RFC 3797 selection process,=20 within the next couple weeks. =20 Thank you! Allison Mankin amankin@verisign.com P.S. Because the 2012-2013 nomcom is still at work, we cannot use the ietf addresses for the nomcom chair or the nomcom committee yet, so please send all the volunteer mail (and any questions/comments you may have) to the=20 address given.=20 From steing@ifi.uio.no Wed May 15 08:11:50 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53DBF21F8F83; Wed, 15 May 2013 08:11:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iGIrVo0PEbGg; Wed, 15 May 2013 08:11:45 -0700 (PDT) Received: from mail-out1.uio.no (mail-out1.uio.no [IPv6:2001:700:100:10::57]) by ietfa.amsl.com (Postfix) with ESMTP id E8FA821F8AD8; Wed, 15 May 2013 08:11:44 -0700 (PDT) Received: from mail-mx2.uio.no ([129.240.10.30]) by mail-out1.uio.no with esmtp (Exim 4.75) (envelope-from ) id 1UcdMl-0005Wl-5S; Wed, 15 May 2013 17:11:43 +0200 Received: from 1x-193-157-202-195.uio.no ([193.157.202.195]) by mail-mx2.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user steing (Exim 4.80) (envelope-from ) id 1UcdMk-0004fY-EU; Wed, 15 May 2013 17:11:43 +0200 From: Stein Gjessing Content-Type: multipart/alternative; boundary="Apple-Mail=_4CA7AC64-6758-4240-93E4-84B414877C93" Date: Wed, 15 May 2013 17:11:41 +0200 Message-Id: To: aqm@ietf.org, rtcweb@ietf.org, lmap@ietf.org, tsvwg@ietf.org, rmcat@ietf.org, multipathtcp@ietf.org, video-codec@ietf.org Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 8 msgs/h 1 sum rcpts/h 13 sum msgs/h 4 total rcpts 2607 max rcpts/h 28 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.5, required=5.0, autolearn=disabled, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.551, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 45A26AF8F0515C0711EDC4E4402EEAD2BB95E78D X-UiO-SPAM-Test: remote_host: 193.157.202.195 spam_score: -54 maxlevel 99990 minaction 1 bait 0 mail/h: 1 total 36 max/h 6 blacklist 0 greylist 0 ratelimit 0 Subject: [tsvwg] CFP Packet Video 2013 - Special Session on Low-Latency Interactive Video X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 May 2013 15:11:50 -0000 --Apple-Mail=_4CA7AC64-6758-4240-93E4-84B414877C93 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi, Here is an excellent venue for discussions and publication of results. Cheers,=20 Stein __________________________________________________________ Packet Video 2013 - Special Session on Low-Latency Interactive Video Sponsored by IEEE Communications Society December 12. and 13., 2013, San Jose, Ca, USA Call for papers. =20 http://pv2013.itec.aau.at/call-for-papers/accepted-special-sessions/#ss1 Several years ago, it was found that users do not like video quality = fluctuations. At that time the predominant belief was that network rate = fluctuations should be minimized, in order to reasonably interoperate = with TCP in the network. This led to the creation of a number of = so-called "TCP-friendly" congestion controls that exhibit a smoother = sending rate than TCP, while avoiding to send more than a conformant TCP = under similar conditions. TFRC is perhaps the best known example of such = a congestion control mechanism. A lot has happened since then: =95 The notion of TCP-friendliness has received massive = criticism; the widespread deployment of a more aggressive TCP variant, = CUBIC, has not led to an Internet meltdown, making the case that = diverging from strict TCP-friendliness is possible. =95 Latency minimization has become a major goal, especially in = the face of =93bufferbloat=94: large delays from large buffers with = simplistic FIFO-queue management. =95 Codecs have improved; novel video codecs are able to adjust = the data rate, but modern codecs may also produce variable bitrate = transmissions with burstier packet flows than before. =95 TFRC has been embedded in the DCCP protocol, which has = probably never been used for anything other than experiments; instead of = running over DCCP, RTP-based applications now contain proprietary = congestion control mechanisms. The emergence of the RTCWEB protocol suite for real-time communication = between Web browsers has renewed the interest in developing congestion = control standards for real-time media. This time, however, the goal is = to get things right: delay should be minimized, and standards should = realize congestion control using RTP with RTCP signaling. The IETF = =93Real-time Media Congestion Avoidance Techniques=94 (RMCAT) working = group has been founded to address this need. New questions arise: what = type of congestion controls do we need? How much feedback should we = send? How do we make this work in multi-user scenarios, e.g., for video = conferencing? What should be the API between a video codec and a new = delay-based congestion controlled RTP stream? What is the quality that = can be expected from the combination of a codec and congestion control = mechanism, when we consider better metrics than plain PSNR? Topics of interest include, but are not limited to: =95 Congestion control algorithms for interactive real-time = video: requirements, evaluation criteria, and mechanisms =95 Necessary RTP/RTCP extensions =95 Field experience with video codecs in a low-delay, real-time = setting =95 Interactions between applications and RTP flows =95 Failing to meet real-time schedules: impact, techniques to = detect, instrument or diagnose it Organizers: =95 Michael Welzl, University of Oslo (michawe at ifi.uio.no) =95 Stein Gjessing, University of Oslo (steing at ifi.uio.no)= --Apple-Mail=_4CA7AC64-6758-4240-93E4-84B414877C93 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 http://pv2013.itec.aau.at/call-for-papers/accepted-special-session= s/#ss1

Several years ago, it was found that users do not like = video quality fluctuations. At that time the predominant belief was that = network rate fluctuations should be minimized, in order to reasonably = interoperate with TCP in the network. This led to the creation of a = number of so-called "TCP-friendly" congestion controls that exhibit a = smoother sending rate than TCP, while avoiding to send more than a = conformant TCP under similar conditions. TFRC is perhaps the best known = example of such a congestion control mechanism.

A lot has = happened since then:
=95 The notion of = TCP-friendliness has received massive criticism; the widespread = deployment of a more aggressive TCP variant, CUBIC, has not led to an = Internet meltdown, making the case that diverging from strict = TCP-friendliness is possible.
=95 Latency minimization has = become a major goal, especially in the face of =93bufferbloat=94: large = delays from large buffers with simplistic FIFO-queue = management.
=95 TFRC = has been embedded in the DCCP protocol, which has probably never been = used for anything other than experiments; instead of running over DCCP, = RTP-based applications now contain proprietary congestion control = mechanisms.

The emergence of the RTCWEB protocol suite for = real-time communication between Web browsers has renewed the interest in = developing congestion control standards for real-time media. This time, = however, the goal is to get things right: delay should be minimized, and = standards should realize congestion control using RTP with RTCP = signaling. The IETF =93Real-time Media Congestion Avoidance Techniques=94 = (RMCAT) working group has been founded to address this need. New = questions arise: what type of congestion controls do we need? How much = feedback should we send? How do we make this work in multi-user = scenarios, e.g., for video conferencing? What should be the API between = a video codec and a new delay-based congestion controlled RTP stream? = What is the quality that can be expected from the combination of a codec = and congestion control mechanism, when we consider better metrics than = plain PSNR?

Topics of interest include, but are not limited = to:
= =95 Congestion control algorithms for interactive real-time = video: requirements, evaluation criteria, and mechanisms
=95 = Necessary RTP/RTCP extensions
=95 Field experience with video = codecs in a low-delay, real-time setting
=95 Interactions between = applications and RTP flows
=95 Failing to meet real-time = schedules: impact, techniques to detect, instrument or diagnose = it

Organizers:
=95 Michael Welzl, University of = Oslo (michawe at ifi.uio.no)
=95 Stein = Gjessing, University of Oslo (steing at ifi.uio.no)= --Apple-Mail=_4CA7AC64-6758-4240-93E4-84B414877C93-- From Karen.Nielsen@tieto.com Sun May 19 07:17:37 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0664E21F8900 for ; Sun, 19 May 2013 07:17:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iA9RBpr7PzZE for ; Sun, 19 May 2013 07:17:32 -0700 (PDT) Received: from ebb06.tieto.com (ebb06.tieto.com [131.207.168.38]) by ietfa.amsl.com (Postfix) with ESMTP id 5C09C21F845D for ; Sun, 19 May 2013 07:17:29 -0700 (PDT) X-AuditID: 83cfa826-b7f916d00000798f-3b-5198def7145a Received: from FIVLA-EXHUB02.eu.tieto.com ( [131.207.136.42]) by ebb06.tieto.com (SMTP Mailer) with SMTP id 38.07.31119.7FED8915; Sun, 19 May 2013 17:17:27 +0300 (EEST) Received: from EXMB03.eu.tieto.com ([169.254.1.240]) by FIVLA-EXHUB02.eu.tieto.com ([131.207.136.42]) with mapi; Sun, 19 May 2013 17:17:27 +0300 From: To: Date: Sun, 19 May 2013 17:17:25 +0300 Thread-Topic: [tsvwg] QUESTION on Return of SACKs and HB ACKs Thread-Index: Ac5NA0lWkHcbbYcAR7ubpQZpR87kYgHk3bwQ Message-ID: References: <20130509221927.GB24653@openss7.org> In-Reply-To: <20130509221927.GB24653@openss7.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrOKsWRmVeSWpSXmKPExsXSfL5DS/f7vRmBBj279S0mPPzIaHGxaQmj xZOen6wWx97cZXNg8Viy5CeTR//85SweG1p2MHk0N39jDmCJ4rJJSc3JLEst0rdL4Mq4fnEP c8F7hYrVizQaGFdKdTFyckgImEic//mLFcIWk7hwbz1bFyMXh5DAKkaJHRNWM0E4Uxglnlw4 ywJSxSYgLzF37yp2EFtEQEqi89EpsDizQJDEtoUPwCaxCKhKdLxZyAZiCwvYSNxtPcYIUW8r sb2pkxXCNpJYOmMfWJxXwEfi0dkDYDOFBIolGo4+BpvJKWAosWTSJrA5jEDXfT+1hglil7jE rSfzmSCuFpBYsuc8M4QtKvHy8T9WiHpRiTvt6xkh6nUkFuz+xAZha0ssW/iaGWKvoMTJmU9Y JjCKzUIydhaSlllIWmYhaVnAyLKKkT81KcnATK8kM7UkXy85P3cTIzi2VqjtYHz2QOoQowAH oxIPb8f36YFCrIllxZW5hxglOZiURHlFb8wIFOJLyk+pzEgszogvKs1JLT7EKMHBrCTCmzYR KMebklhZlVqUD5OS4eBQkuD9excoJViUmp5akZaZA0wgMGkmDk6Qdh6g9i8gNbzFBYm5xZnp EPlTjIpS4rwcwAQEDFygREZpHlwvLH29YhQHOlaY9wJIOw8w9cF1vwIazAQ0mPXaVJDBJYkI KakGRr/n7Lq1scetZS5O8H+2W77FeseXPWX6K3Z8kX6yjPnI41+8LZ95lqU7cdYvOCpVUXec /5NtrqfJUQ7XvJR3devTYzVq8g1mSO2//eezwEOOox/3Rk8MSbixzVxAOOBAT+nGS/oHZjxK U+xIe8p94c60k59fMluL7vH7yXn9h9XRBlWthvrWV0osxRmJhlrMRcWJALX607s6AwAA Cc: Michael.Tuexen@lurchi.franken.de, tsvwg@ietf.org, randall@lakerest.net Subject: Re: [tsvwg] QUESTION on Return of SACKs and HB ACKs X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 May 2013 14:17:37 -0000 Hi, Sorry for the wait. I am coping in Randy and Michael as this touches the interpretation of a SH= OULD in the RFC and it will be very valuable to understand to which extend the solution that we= are discussing is seen as being=20 in compliance with the RFC, or if not, if it is considered a reasonable, ac= ceptable and perhaps even a recommended deviation from the RFC. ... Thanks in advance ..=20 >> >> I am wondering, if anybody (IETF SCTP community and/or RFC4960 >> Authors) has any view on the validity (or the contrary) of not >> returning SACKs on the reflected IP Path ? > >IMO there no reason to send SACK and DATA to different destinations. >Bundling SACK and DATA are essential for efficiency at high throughputs. = The >"best" destination should be used for both, where the "best" destination i= s the >primary DATA destination for non-CMT. Agree completely. Apart from the mere throughput considerations, I would al= so like to point to that return of SACK to the Primary DATA destination also should be better f= rom a robustness perspective as the SACK returner are likely to have fresh and reliable information on the = "availability" of the Primary DATA destination (availability =3D=20 data or HB's send to the Primary DATA destination are acknowledge to be rec= eived) While availability of other destination addresses may not be fresh (dependi= ng on Path monitoring and HB intervals). Generally in simple scenarios where one can trust there to be either "bi-di= rectional" connectivity or no connectivity at all in between end-point addresses, then the receipt of DATA on a path of cours= e is fresh information that the return path works, but this is not generally the situation in today's network - at least not on a perma= nent basis. I.e., in failure situations, connectivity may only work in one direction until the network has recovered= (whether by fault recovery or by route migration). The return of SACK to the Primary DATA destination will provide more robus= t delivery of the SACK. If the SACK is not bundled with forward DATA, e.g., if no data is in transit in this direction, one co= uld then argue for that implementations=20 could bundle HBs with solely returned SACKs (though surely one should imple= ment appropriate rate limiting on such HBs) thereby making sure to keep the path availability information fresh (If the= HBs consistently fail, the Primary DATA destination should be changed). > >> Possibly also the situation with return of SACKs acknowledging Data >> chunks that have come in on multiple paths will be even more relevant >> for CMT-SCTP. > >CMT needs to perform some sort of gap-ack merging to suppress spurious fas= t >retransmit. It can be done both at the sender and at the receiver. SACKs= that make >it out of this logic at the sender should still be sent to the "best" dest= ination and >bundled with DATA wherever possible. The "best" destination in this case = is >determined by the CMT distribution logic. > Yes - Thanks. >> Finally following the thoughts above for SACK return, then one may >> also think about the corresponding situation with the return of HB >> ACKs. > >> Also here one can wonder as to whether it is best to have the HB ACK >> returned in the path over which it is most likely to reach peer or >> whether it must (?) be returned on the reflect path of the incoming >> HB. I am not sure if the RFC4960 SHOULD here should be read mostly as >> a MUST or mostly as a SHOULD unless other things make it beneficiary >> to use a different path ? > >HB are a little different. COOKIE-ACK, HEARTBEAT-ACK, SHUTDOWN-ACK, >SHUTDOWN-COMPLETE, ASCONF-ACK, should IMO be sent to the source >address contained in the corresponding request chunk, so long as the desti= nation is >considered viable. Otherwise, it should send to the "best" destination. > Sounds good IMO. >These approaches work quite well in practice. > It could be very interesting to have such C P or B C P be written up, I thi= nk. Thanks a lot. BR, Karen >--brian > >-- >Brian F. G. Bidulock >bidulock@openss7.org >http://www.openss7.org/ From Karen.Nielsen@tieto.com Sun May 19 07:50:08 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AB7121F896D for ; Sun, 19 May 2013 07:50:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3X69gH4UIfnM for ; Sun, 19 May 2013 07:50:02 -0700 (PDT) Received: from ebb05.tieto.com (ebb05.tieto.com [131.207.168.36]) by ietfa.amsl.com (Postfix) with ESMTP id 7350521F888F for ; Sun, 19 May 2013 07:50:01 -0700 (PDT) X-AuditID: 83cfa824-b7fa96d000007867-d4-5198e697057f Received: from FIHGA-EXHUB01.eu.tieto.com ( [131.207.136.34]) by ebb05.tieto.com (SMTP Mailer) with SMTP id 50.A4.30823.796E8915; Sun, 19 May 2013 17:49:59 +0300 (EEST) Received: from EXMB03.eu.tieto.com ([169.254.1.240]) by FIHGA-EXHUB01.eu.tieto.com ([131.207.136.34]) with mapi; Sun, 19 May 2013 17:49:59 +0300 From: To: Date: Sun, 19 May 2013 17:49:58 +0300 Thread-Topic: [tsvwg] QUESTION on Return of SACKs and HB ACKs Thread-Index: Ac5MHohQJMZ0vpIUTpCW2z8S7BOrnwIfhsHw Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprMKsWRmVeSWpSXmKPExsXSfL5DSXf6sxmBBl3XjS02LrnBZnHszV02 ByaPJUt+MnlcfH2dOYApissmJTUnsyy1SN8ugStj9dzzbAU71Ctamg+wNjD+leti5OSQEDCR WLf6MQuELSZx4d56NhBbSGAVo8SSRxZdjFxA9hRGic47H5lAEmwC8hJz965iB7FFBGQk/n75 z9rFyMHBLCAiMee3BkiYRUBVonX/J7ByYQEbibutxxghym0ltjd1skLYRhK7Z/4Hq+EV8JE4 tWQ9K8SuyYwS6zYsBDuIUyBQYvWK38wgNiPQcd9PrQFrYBYQl7j1ZD4TxNECEkv2nGeGsEUl Xj7+xwpRLypxp309I0S9jsSC3Z/YIGxtiWULXzNDLBaUODnzCcsERrFZSMbOQtIyC0nLLCQt CxhZVjHypyYlGZjqlWSmluTrJefnbmIEx8wKlR2MZx9IHWIU4GBU4uG1+DM9UIg1say4MvcQ oyQHk5Ior+iNGYFCfEn5KZUZicUZ8UWlOanFhxglOJiVRHjTJgLleFMSK6tSi/JhUjIcHEoS vO1PgVKCRanpqRVpmTnAxACTZuLgBGnnAWp3AKnhLS5IzC3OTIfIn2JUlBLntQFJCIAkMkrz 4HphaekVozjQscK80iBVPMCUBtf9CmgwE9Bg1mtTQQaXJCKkpBoYD0ckFM3d7nQ1t4tlq9mO 1YvXvl+9kv/EySVabxZ8jw5PdK7sNv6uKMdt0NQtt6aiR0tLX7lvirrEiRMLn0/8Xz9x3s4V 02aE7ucJis/lv1vZ7OYhqDVxhfOirfOPTpB3PJp0OqK4aXL/istVKyPq53+888TQRn3XqrW7 exk0v56PmTC1zs81S4mlOCPRUIu5qDgRAMiPSnsmAwAA Cc: tsvwg@ietf.org Subject: Re: [tsvwg] QUESTION on Return of SACKs and HB ACKs X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 May 2013 14:50:08 -0000 Hi, The motivation and/or use-cases behind the discussion is the following: * The return path of an incoming DATA path may not be working. I.e., there = can be connectivity from source address of incoming DATA to destination address of incoming DATA, bu= t not the other way around. * The Primary Path of the SACK returner is generally the path which is cons= idered best in the direction that the SACK should take. Would one then not think that it generally would be best to return also the SACKs on = this path. Indeed if the SACK returner is itself transmitting DATA (which then would b= e transmitted on the Primary Path) then: * fresh path availability information is available on the Primary Path as d= riven by the DATA SACKs * from throughput perspectives (including packet processing costs in sender= , receiver and intermediate routers) it is beneficiary to bundle the SACK with the DATA, opposed to have them be sent as two differen= t packets. One argument that motivates SACK return on the "reflected" path of the DATA= is to keep the SRTT stable. But as long as the SACK consistently is returned on the Primary Path the fluctuations t= hat could come from Primary Path changes should be infrequent in time. The reasoning is that such infrequent fluctuations in SRTT would be an acce= ptable price to pay to have a more robust SACK return. BR, Karen >-----Original Message----- >From: Yoshifumi Nishida [mailto:nishida@sfc.wide.ad.jp] >Sent: Wednesday, May 08, 2013 9:02 PM >To: Nielsen Karen >Cc: tsvwg >Subject: Re: [tsvwg] QUESTION on Return of SACKs and HB ACKs > >Hi Karen, > >I'm trying to see what kind of benefits we can get by this. Do you have so= me use >cases? > >Thanks, >-- >Yoshifumi > >On Tue, May 7, 2013 at 3:05 AM, wrote: >> Hi, >> >> >> >> RFC4960 in Section 6.4 opens up for the possibility that SACKs may be >> returned on a different path (or IP Path) >> >> that the reflected path (or IP Path) of the incoming Data. >> >> >> >> This, as said in RFC4960, can be the situation when a SACK >> acknowledges Data TSNs that have come in on different paths as well as >> it >> >> may (MAY) be a beneficial reaction if evidence is available that >> indicates the unavailability of the reflected data path. Such >> unavailability >> >> evidence could come from arrival of duplicate Data chunks (as pointed >> to in >> RFC4960) possibly such evidence could also be established >> >> by other means (like e.g., if HBs indicates the reflected Path to be >> unavailable). The latter aspect are not mentioned in RFC4960. >> >> >> >> I am wondering, if anybody (IETF SCTP community and/or RFC4960 >> Authors) has any view on the validity (or the contrary) of >> >> not returning SACKs on the reflected IP Path ? >> >> >> >> Obviously it is very important for the path selection for return of >> SACKs to be as >> >> stable and consistent as feasible, as one otherwise risks to >> jeopardize the validity of Data RTT measurements of peer, and using >> the reflected IP path >> >> is one way to achieve this. But having said this, then I wonder if >> there otherwise are considered to be significant problems with the >> >> return of SACKs via paths there are different from the reflected IP >> Path of Data. Issues that makes is so that an SCTP implementation >> should best possible prevent situations where data and SACK do not >> follow the same path (in opposite directions). >> >> >> >> Possibly also the situation with return of SACKs acknowledging Data >> chunks that have come in on multiple paths will be even more relevant fo= r CMT- >SCTP. >> >> This may open up for either demanding for SACKs to be returned split >> according to the incoming path of Data or for the recommendation of >> RFC4960 to use reflected path of Data to be broaden up to recommend >> for consistent choice of return path of SACKs. >> >> >> >> Finally following the thoughts above for SACK return, then one may >> also think about the corresponding situation with the return of HB ACKs. >> >> >> >> RFC4960 seems to assume for HB ACKs always to be returned on the >> reflected path of the HB as it says, Section 3.3.6, but notably the >> only Keyword >> >> that applies to return of HB ACK is the SHOULD of Section 6.4 : >> >> >> >> A HEARTBEAT ACK is always >> >> sent to the source IP address of the IP datagram containing the >> >> HEARTBEAT chunk to which this ack is responding. >> >> >> >> Also here one can wonder as to whether it is best to have the HB ACK >> returned in the path over which it is most likely to reach peer or >> whether >> >> it must (?) be returned on the reflect path of the incoming HB. I am >> not sure if the RFC4960 SHOULD here should be read mostly as a MUST or >> mostly as a >> >> SHOULD unless other things make it beneficiary to use a different path ? >> >> >> >> A BIG Thanks in Advance ! >> >> >> >> BR, Karen From subramanian.vijay@gmail.com Fri May 10 17:51:04 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA67E21F8AA8 for ; Fri, 10 May 2013 17:51:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MpYqU0Bz3VfG for ; Fri, 10 May 2013 17:51:03 -0700 (PDT) Received: from mail-qc0-x22e.google.com (mail-qc0-x22e.google.com [IPv6:2607:f8b0:400d:c01::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 9CD7821F8B27 for ; Fri, 10 May 2013 17:51:01 -0700 (PDT) Received: by mail-qc0-f174.google.com with SMTP id m16so2585540qcq.33 for ; Fri, 10 May 2013 17:50:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:content-type; bh=oaNULsLL1ZaMuCpDKgFwQkBQgJWYy+p3J9p4v/EB3a8=; b=t5YZYQmYRtGN9lTA5wFGOR7l3g8yjzvFSWSGS07tdyxK3QDya/4DjWKLnOFmXluIkp uFqFp3RJfYProWE+iWrXtJdlbMQrDMeTNzvAQKpd7NvrRQWLpDHOyF7Z+ZXFytrxqjoY ZZOC502HBxxfElcqewlnLcmLAtbG8+ElWg2ujDxU5iV5ID89W0HdSwD/sijQY6NoL8J7 dBrZRQDxyzrkP2nizNCgvDCNjecgiwQSQeCI7WcjG8HH+3WBaPtDT+Q8J9qXNUvaLCle oVd19MAxxcqC9k9h4wuAuDQ+Y6r3gMbL+NgCYGZ9hpmWDRap384qHBKGyF3fhcCtHSfO 1A+A== MIME-Version: 1.0 X-Received: by 10.229.21.199 with SMTP id k7mr1637136qcb.64.1368233457352; Fri, 10 May 2013 17:50:57 -0700 (PDT) Received: by 10.49.121.202 with HTTP; Fri, 10 May 2013 17:50:57 -0700 (PDT) In-Reply-To: References: Date: Fri, 10 May 2013 17:50:57 -0700 Message-ID: From: Vijay Subramanian To: iccrg@irtf.org, tsvwg@ietf.org, "Rong Pan (ropan)" , "Preethi Natarajan (prenatar)" , "Fred Baker (fred)" , "Vijay Subramanian (vijaynsu)" Content-Type: multipart/alternative; boundary=14dae9d67f443297d604dc66ade0 X-Mailman-Approved-At: Mon, 20 May 2013 01:56:24 -0700 Subject: [tsvwg] Fwd: PIE code available X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 May 2013 00:51:04 -0000 --14dae9d67f443297d604dc66ade0 Content-Type: text/plain; charset=ISO-8859-1 Hi, I sent out the following note to bufferbloat lists and got feedback that iccrg and tsvwg may be interested in this so here is the forwarded email. Thanks, Vijay Subramanian ---------- Forwarded message ---------- From: Vijay Subramanian Date: 10 May 2013 16:39 Subject: PIE code available To: Dave Taht , "aqm@ietf.org" , bloat@lists.bufferbloat.net, Eric Dumazet Cc: "Rong Pan (ropan)" , "Preethi Natarajan (prenatar)" < prenatar@cisco.com>, mysuryan@cisco.com, cpiglion@cisco.com Hi folks, We are finally in a position to release the PIE (Proportional Integral controller Enhanced) Linux code. Many of you are already aware of the work at IETF and discussions on PIE on the aqm and bloat mailing lists. Thanks for all the feedback. Documents and code are available over ftp at ftp://ftpeng.cisco.com/pie The Linux code is available at ftp://ftpeng.cisco.com/pie/linux_code PIE is written as a kernel module and should work with recent kernels. There is also a patch to iproute-3.9 tc tool to configure PIE. README files explain the usage. The complete source files are also available so it should not be too difficult to make it compile on a different iproute2 version. Please check that your basic tests are in sync with what we have seen. Sample results are available at ftp://ftpeng.cisco.com/pie/linux_code/linux_sampleresults/ Please let us know if you see any discrepancies. Thanks in advance for all code reviews. If you have suggestions to improve the code, they are welcome. (Thanks to Eric Dumazet and Dave Taht for Codel codebase). We will also release a version of PIE called Fair-queue-PIE soon (hopefully by the end of the month). If you have any questions, let us know. Thanks, on behalf of PIE team, Vijay Subramanian --14dae9d67f443297d604dc66ade0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,
I sent out the following no= te to bufferbloat lists and got feedback that iccrg and tsvwg may be intere= sted in this so here is the forwarded email.

Thanks,
Vijay Subramanian


---------- Forwarded message ----------
From: Vijay Subramanian <subramanian.vijay@gmail.com>
Date: 10 May 2013 16:39
Subject: PIE code available
To: Dave Taht <= ;dave.taht@gmail.c= om>, "aqm@iet= f.org" <aqm@i= etf.org>, bloat@lists.bufferbloat.net, Eric Dumazet <eric.dumazet@gmail.com> Cc: "Rong Pan (ropan)" <ropan@cisco.com>, "Preethi Natarajan (prenatar)&= quot; <prenatar@= cisco.com>, = mysuryan@cisco.com, cpiglion@cisco.com


Hi folks,

We are finally in a p= osition to release the PIE (Proportional Integral controller Enhanced) Linu= x code.
Many of you are already aware of the work at IETF and dis= cussions on PIE on the aqm and bloat mailing lists. Thanks for all the feed= back.=A0

Documents and code are available over ftp at=A0ftp://ftpeng.cisco.com/pi= e
The Linux code is available at=A0ftp://ftpeng.cisco.com/pie/linux_= code

PIE is written as a kernel module and should work with = recent kernels. There is also a patch to
iproute-3.9 tc tool to c= onfigure PIE. README files explain the usage. The complete source files are= also available so it should not be too difficult to make it compile on a d= ifferent iproute2 version.

Please check that your basic tests are in sync with wha= t we have seen. Sample results are available at=A0ftp://ftpen= g.cisco.com/pie/linux_code/linux_sampleresults/
Please let us know if you see any discrepancies.

<= div>Thanks in advance for all code reviews. If you have suggestions to impr= ove the code, they are welcome. (Thanks to Eric Dumazet and Dave Taht for C= odel codebase). We will also release a version of PIE called Fair-queue-PIE= soon (hopefully by the end of the month).

If you have any questions, let us know.

<= /div>
Thanks,
on behalf of PIE team,

Vijay Subramanian



--14dae9d67f443297d604dc66ade0-- From internet-drafts@ietf.org Thu May 23 23:19:18 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B3DB21F9697; Thu, 23 May 2013 23:19:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.464 X-Spam-Level: X-Spam-Status: No, score=-102.464 tagged_above=-999 required=5 tests=[AWL=0.136, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8aCVod-gdMWg; Thu, 23 May 2013 23:19:17 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 67C4C21F9687; Thu, 23 May 2013 23:19:17 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.50 Message-ID: <20130524061917.4902.84132.idtracker@ietfa.amsl.com> Date: Thu, 23 May 2013 23:19:17 -0700 Cc: tsvwg@ietf.org Subject: [tsvwg] I-D Action: draft-ietf-tsvwg-byte-pkt-congest-10.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 May 2013 06:19:18 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Transport Area Working Group Working Grou= p of the IETF. Title : Byte and Packet Congestion Notification Author(s) : Bob Briscoe Jukka Manner Filename : draft-ietf-tsvwg-byte-pkt-congest-10.txt Pages : 45 Date : 2013-05-23 Abstract: This document provides recommendations of best current practice for dropping or marking packets using any active queue management (AQM) algorithm, such as random early detection (RED), BLUE, pre-congestion notification (PCN), etc. We give three strong recommendations: (1) packet size should be taken into account when transports read and respond to congestion indications, (2) packet size should not be taken into account when network equipment creates congestion signals (marking, dropping), and therefore (3) in the specific case of RED, the byte-mode packet drop variant that drops fewer small packets should not be used. This memo updates RFC 2309 to deprecate deliberate preferential treatment of small packets in AQM algorithms. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tsvwg-byte-pkt-congest There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-tsvwg-byte-pkt-congest-10 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tsvwg-byte-pkt-congest-10 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nishida@sfc.wide.ad.jp Fri May 24 03:24:04 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20FA621F96F5 for ; Fri, 24 May 2013 03:24:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.978 X-Spam-Level: X-Spam-Status: No, score=-101.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iC1oEScV6bFj for ; Fri, 24 May 2013 03:24:03 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (ns.sfc.wide.ad.jp [IPv6:2001:200:0:8803:203:178:142:143]) by ietfa.amsl.com (Postfix) with ESMTP id D8BBF21F96EC for ; Fri, 24 May 2013 03:24:02 -0700 (PDT) Received: from mail-la0-x230.google.com (mail-la0-x230.google.com [IPv6:2a00:1450:4010:c03::230]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 23AFE278094 for ; Fri, 24 May 2013 19:23:59 +0900 (JST) Received: by mail-la0-f48.google.com with SMTP id fs12so4242498lab.21 for ; Fri, 24 May 2013 03:23:57 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=m078jldSybHlpBYcW8S5+SR+0h72NtS6hLrptibWu3k=; b=M34FUoBpzDwltEoww0pO+u6vfqddgHzBLhNo2DMADduJ7B3E7NE5wp5dLPv5wQFhch saZ1OZbTIEoffipUZ7amFCYghzeseKhJDT0GfDgYkby5jktfDGg6y4/4zeaOss/Ub9/5 omORsR+c/CtR1Hyt5mo1COvIrcNtcZ/EwevKF7RjXyfYjRsBDkxMXRUJNW5MBHJ7eUiG aJ7IoTaDYyvEnnqDyTqldZSl9HDn4QmfP1mc9lAQqU3XrrjXVLQ5awOphSMcT/EX4u5c uvd9bC7jh9TQyythoUiDd2l3MIqRnXRVB7XnCc0JIqZmvthyI8GkcI+mpZpi8je0rMgy Li9Q== MIME-Version: 1.0 X-Received: by 10.112.7.4 with SMTP id f4mr8467299lba.132.1369391037594; Fri, 24 May 2013 03:23:57 -0700 (PDT) Received: by 10.114.27.165 with HTTP; Fri, 24 May 2013 03:23:57 -0700 (PDT) In-Reply-To: References: Date: Fri, 24 May 2013 03:23:57 -0700 Message-ID: From: Yoshifumi Nishida To: Karen.Nielsen@tieto.com Content-Type: text/plain; charset=ISO-8859-1 Cc: tsvwg Subject: Re: [tsvwg] QUESTION on Return of SACKs and HB ACKs X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 May 2013 10:24:04 -0000 Hi Karen, Thanks for your response. I think there'll be situations where this approach will be beneficial. I can see that when the destination is inactive, it would be better to send SACK or HB ACK to the different path. I guess this is possible with the current spec by ignoring SHOULD. However, I'm not very sure if bundling SACK for CMT is always beneficial. It's sometimes better to have path diversity. If the return path is congested, it will affect all data transfer. When to try this might be a tricky question. Thanks, -- Yoshifumi On Sun, May 19, 2013 at 7:49 AM, wrote: > Hi, > > The motivation and/or use-cases behind the discussion is the following: > > * The return path of an incoming DATA path may not be working. I.e., there can be connectivity from > source address of incoming DATA to destination address of incoming DATA, but not the other way around. > > * The Primary Path of the SACK returner is generally the path which is considered best in the direction that the SACK should take. Would one > then not think that it generally would be best to return also the SACKs on this path. > Indeed if the SACK returner is itself transmitting DATA (which then would be transmitted on the Primary Path) then: > * fresh path availability information is available on the Primary Path as driven by the DATA SACKs > * from throughput perspectives (including packet processing costs in sender, receiver and intermediate routers) it is beneficiary to > bundle the SACK with the DATA, opposed to have them be sent as two different packets. > > One argument that motivates SACK return on the "reflected" path of the DATA is to keep the SRTT stable. But as long > as the SACK consistently is returned on the Primary Path the fluctuations that could come from Primary Path changes should be infrequent in time. > The reasoning is that such infrequent fluctuations in SRTT would be an acceptable price to pay to have a more robust SACK return. > > BR, Karen > >>-----Original Message----- >>From: Yoshifumi Nishida [mailto:nishida@sfc.wide.ad.jp] >>Sent: Wednesday, May 08, 2013 9:02 PM >>To: Nielsen Karen >>Cc: tsvwg >>Subject: Re: [tsvwg] QUESTION on Return of SACKs and HB ACKs >> >>Hi Karen, >> >>I'm trying to see what kind of benefits we can get by this. Do you have some use >>cases? >> >>Thanks, >>-- >>Yoshifumi >> >>On Tue, May 7, 2013 at 3:05 AM, wrote: >>> Hi, >>> >>> >>> >>> RFC4960 in Section 6.4 opens up for the possibility that SACKs may be >>> returned on a different path (or IP Path) >>> >>> that the reflected path (or IP Path) of the incoming Data. >>> >>> >>> >>> This, as said in RFC4960, can be the situation when a SACK >>> acknowledges Data TSNs that have come in on different paths as well as >>> it >>> >>> may (MAY) be a beneficial reaction if evidence is available that >>> indicates the unavailability of the reflected data path. Such >>> unavailability >>> >>> evidence could come from arrival of duplicate Data chunks (as pointed >>> to in >>> RFC4960) possibly such evidence could also be established >>> >>> by other means (like e.g., if HBs indicates the reflected Path to be >>> unavailable). The latter aspect are not mentioned in RFC4960. >>> >>> >>> >>> I am wondering, if anybody (IETF SCTP community and/or RFC4960 >>> Authors) has any view on the validity (or the contrary) of >>> >>> not returning SACKs on the reflected IP Path ? >>> >>> >>> >>> Obviously it is very important for the path selection for return of >>> SACKs to be as >>> >>> stable and consistent as feasible, as one otherwise risks to >>> jeopardize the validity of Data RTT measurements of peer, and using >>> the reflected IP path >>> >>> is one way to achieve this. But having said this, then I wonder if >>> there otherwise are considered to be significant problems with the >>> >>> return of SACKs via paths there are different from the reflected IP >>> Path of Data. Issues that makes is so that an SCTP implementation >>> should best possible prevent situations where data and SACK do not >>> follow the same path (in opposite directions). >>> >>> >>> >>> Possibly also the situation with return of SACKs acknowledging Data >>> chunks that have come in on multiple paths will be even more relevant for CMT- >>SCTP. >>> >>> This may open up for either demanding for SACKs to be returned split >>> according to the incoming path of Data or for the recommendation of >>> RFC4960 to use reflected path of Data to be broaden up to recommend >>> for consistent choice of return path of SACKs. >>> >>> >>> >>> Finally following the thoughts above for SACK return, then one may >>> also think about the corresponding situation with the return of HB ACKs. >>> >>> >>> >>> RFC4960 seems to assume for HB ACKs always to be returned on the >>> reflected path of the HB as it says, Section 3.3.6, but notably the >>> only Keyword >>> >>> that applies to return of HB ACK is the SHOULD of Section 6.4 : >>> >>> >>> >>> A HEARTBEAT ACK is always >>> >>> sent to the source IP address of the IP datagram containing the >>> >>> HEARTBEAT chunk to which this ack is responding. >>> >>> >>> >>> Also here one can wonder as to whether it is best to have the HB ACK >>> returned in the path over which it is most likely to reach peer or >>> whether >>> >>> it must (?) be returned on the reflect path of the incoming HB. I am >>> not sure if the RFC4960 SHOULD here should be read mostly as a MUST or >>> mostly as a >>> >>> SHOULD unless other things make it beneficiary to use a different path ? >>> >>> >>> >>> A BIG Thanks in Advance ! >>> >>> >>> >>> BR, Karen From Karen.Nielsen@tieto.com Fri May 24 04:05:45 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D955521F8E99 for ; Fri, 24 May 2013 04:05:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PHktuSeMYL6g for ; Fri, 24 May 2013 04:05:40 -0700 (PDT) Received: from ebb06.tieto.com (ebb06.tieto.com [131.207.168.38]) by ietfa.amsl.com (Postfix) with ESMTP id 487A721F8AF7 for ; Fri, 24 May 2013 04:05:39 -0700 (PDT) X-AuditID: 83cfa826-b7f5f6d000001d4d-0a-519f49814231 Received: from FIHGA-EXHUB01.eu.tieto.com ( [131.207.136.34]) by ebb06.tieto.com (SMTP Mailer) with SMTP id 84.EB.07501.1894F915; Fri, 24 May 2013 14:05:38 +0300 (EEST) Received: from EXMB03.eu.tieto.com ([169.254.1.240]) by FIHGA-EXHUB01.eu.tieto.com ([131.207.136.34]) with mapi; Fri, 24 May 2013 14:05:37 +0300 From: To: Date: Fri, 24 May 2013 14:05:36 +0300 Thread-Topic: [tsvwg] QUESTION on Return of SACKs and HB ACKs Thread-Index: Ac5YaNQSw+SfP7xoSJeExMCAOwvVLgAAiuDw Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrEKsWRmVeSWpSXmKPExsXSfL5DSbfJc36gwbIlLBYbl9xgszj25i6b A5PHkiU/mTwuvr7OHMAUxWWTkpqTWZZapG+XwJUx+eETtoIGs4rzx3+yNTA+0+pi5OSQEDCR uPnmBTuELSZx4d56ti5GLg4hgVWMEstOzGCEcKYwShzung9WxSYgLzF37yowW0RARuLvl/+s XYwcHMwCIhJzfmuAhFkEVCXW989hBbGFBWwk7rYeY4Qot5XY3tTJCmEbSdy53AcW5xXwkVh+ uJEVYtdcJolTmw6zgCQ4BQIlVj16D9bACHTd91NrmEBsZgFxiVtP5jNBXC0gsWTPeWYIW1Ti 5eN/UPWiEnfa1zNC1OtILNj9iQ3C1pZYtvA1M8RiQYmTM5+wTGAUm4Vk7CwkLbOQtMxC0rKA kWUVI39qUpKBmV5JZmpJvl5yfu4mRnDUrFDbwfjsgdQhRgEORiUe3hk68wKFWBPLiitzDzFK cjApifJedZ8fKMSXlJ9SmZFYnBFfVJqTWnyIUYKDWUmEdxYfUI43JbGyKrUoHyYlzcGiJM67 XhRokkB6YklqdmpqQWoRTFaGg0NJgtfCA6hRsCg1PbUiLTOnBCHNxMEJMpwHaLg+SA1vcUFi bnFmOkT+FKOilDivN0hCACSRUZoH1wtLaq8YxYFeEeZ1AqniASZEuO5XQIOZgAYvPTUHZHBJ IkJKqoGx8t/5a85ebfGSUyve/VrP+/3oJN4+afMHZoo7sm8qn1v634rBwUZmfZtEv2Dkrou/ Nn0yijc9OtP3+7OJ3MdL7OYn7r+52IKp6GuYeuwMs/n505U3Sumsf/A1PPesRts5qej5enev cFnsz0g7pXPDOkLb8z7XqhClpz++PL+VPOHYijvvqxh/K7EUZyQaajEXFScCAGN+V0JFAwAA Cc: tsvwg@ietf.org Subject: Re: [tsvwg] QUESTION on Return of SACKs and HB ACKs X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 May 2013 11:05:46 -0000 Hi Yoshifumi, > >Thanks for your response. I think there'll be situations where this approa= ch will be >beneficial. >I can see that when the destination is inactive, it would be better to sen= d SACK or >HB ACK to the different path. >I guess this is possible with the current spec by ignoring SHOULD. > Yes, I agree. Though I find it unfortunate that one need to go to the lengt= h of ignoring a SHOULD for something which indeed sounds like a beneficial approach.=20 There is also a chicken egg issue here in that the destination will only be= stepped to inactive if data (or HBs) if flowing towards it. That's why I think that effectively one will have to= take one of the following approaches: * Send SACK on return path as long as the destination is not inactive. Bund= le HB with SACK if no data is in transit. * Always send SACK on primary path. Bundle HB with SACK if no data is in tr= ansit. (Some rate limiting shall be implemented on the HB bundling). >However, I'm not very sure if bundling SACK for CMT is always beneficial. = It's >sometimes better to have path diversity. >If the return path is congested, it will affect all data transfer. >When to try this might be a tricky question. Yes. But doesn't this again boil down to choosing a good path for return of= SACKs, and with CMT then multiple good return paths for SACK, when/if multiple paths are available.=20 Thanks a lot. BR, Karen > >Thanks, >-- >Yoshifumi > > >On Sun, May 19, 2013 at 7:49 AM, wrote: >> Hi, >> >> The motivation and/or use-cases behind the discussion is the following: >> >> * The return path of an incoming DATA path may not be working. I.e., >> there can be connectivity from source address of incoming DATA to destin= ation >address of incoming DATA, but not the other way around. >> >> * The Primary Path of the SACK returner is generally the path which is >> considered best in the direction that the SACK should take. Would one th= en not >think that it generally would be best to return also the SACKs on this pat= h. >> Indeed if the SACK returner is itself transmitting DATA (which then woul= d be >transmitted on the Primary Path) then: >> * fresh path availability information is available on the Primary Path >> as driven by the DATA SACKs >> * from throughput perspectives (including packet processing costs in >> sender, receiver and intermediate routers) it is beneficiary to bundle t= he SACK with >the DATA, opposed to have them be sent as two different packets. >> >> One argument that motivates SACK return on the "reflected" path of the >> DATA is to keep the SRTT stable. But as long as the SACK consistently is >returned on the Primary Path the fluctuations that could come from Primary= Path >changes should be infrequent in time. >> The reasoning is that such infrequent fluctuations in SRTT would be an a= cceptable >price to pay to have a more robust SACK return. >> >> BR, Karen >> >>>-----Original Message----- >>>From: Yoshifumi Nishida [mailto:nishida@sfc.wide.ad.jp] >>>Sent: Wednesday, May 08, 2013 9:02 PM >>>To: Nielsen Karen >>>Cc: tsvwg >>>Subject: Re: [tsvwg] QUESTION on Return of SACKs and HB ACKs >>> >>>Hi Karen, >>> >>>I'm trying to see what kind of benefits we can get by this. Do you >>>have some use cases? >>> >>>Thanks, >>>-- >>>Yoshifumi >>> >>>On Tue, May 7, 2013 at 3:05 AM, wrote: >>>> Hi, >>>> >>>> >>>> >>>> RFC4960 in Section 6.4 opens up for the possibility that SACKs may >>>> be returned on a different path (or IP Path) >>>> >>>> that the reflected path (or IP Path) of the incoming Data. >>>> >>>> >>>> >>>> This, as said in RFC4960, can be the situation when a SACK >>>> acknowledges Data TSNs that have come in on different paths as well >>>> as it >>>> >>>> may (MAY) be a beneficial reaction if evidence is available that >>>> indicates the unavailability of the reflected data path. Such >>>> unavailability >>>> >>>> evidence could come from arrival of duplicate Data chunks (as >>>> pointed to in >>>> RFC4960) possibly such evidence could also be established >>>> >>>> by other means (like e.g., if HBs indicates the reflected Path to be >>>> unavailable). The latter aspect are not mentioned in RFC4960. >>>> >>>> >>>> >>>> I am wondering, if anybody (IETF SCTP community and/or RFC4960 >>>> Authors) has any view on the validity (or the contrary) of >>>> >>>> not returning SACKs on the reflected IP Path ? >>>> >>>> >>>> >>>> Obviously it is very important for the path selection for return of >>>> SACKs to be as >>>> >>>> stable and consistent as feasible, as one otherwise risks to >>>> jeopardize the validity of Data RTT measurements of peer, and using >>>> the reflected IP path >>>> >>>> is one way to achieve this. But having said this, then I wonder if >>>> there otherwise are considered to be significant problems with the >>>> >>>> return of SACKs via paths there are different from the reflected IP >>>> Path of Data. Issues that makes is so that an SCTP implementation >>>> should best possible prevent situations where data and SACK do not >>>> follow the same path (in opposite directions). >>>> >>>> >>>> >>>> Possibly also the situation with return of SACKs acknowledging Data >>>> chunks that have come in on multiple paths will be even more >>>> relevant for CMT- >>>SCTP. >>>> >>>> This may open up for either demanding for SACKs to be returned split >>>> according to the incoming path of Data or for the recommendation of >>>> RFC4960 to use reflected path of Data to be broaden up to recommend >>>> for consistent choice of return path of SACKs. >>>> >>>> >>>> >>>> Finally following the thoughts above for SACK return, then one may >>>> also think about the corresponding situation with the return of HB ACK= s. >>>> >>>> >>>> >>>> RFC4960 seems to assume for HB ACKs always to be returned on the >>>> reflected path of the HB as it says, Section 3.3.6, but notably the >>>> only Keyword >>>> >>>> that applies to return of HB ACK is the SHOULD of Section 6.4 : >>>> >>>> >>>> >>>> A HEARTBEAT ACK is always >>>> >>>> sent to the source IP address of the IP datagram containing the >>>> >>>> HEARTBEAT chunk to which this ack is responding. >>>> >>>> >>>> >>>> Also here one can wonder as to whether it is best to have the HB ACK >>>> returned in the path over which it is most likely to reach peer or >>>> whether >>>> >>>> it must (?) be returned on the reflect path of the incoming HB. I am >>>> not sure if the RFC4960 SHOULD here should be read mostly as a MUST >>>> or mostly as a >>>> >>>> SHOULD unless other things make it beneficiary to use a different path= ? >>>> >>>> >>>> >>>> A BIG Thanks in Advance ! >>>> >>>> >>>> >>>> BR, Karen From bidulock@openss7.org Sun May 26 02:32:57 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAEE121F8F12 for ; Sun, 26 May 2013 02:32:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZopbK99-ntj3 for ; Sun, 26 May 2013 02:32:53 -0700 (PDT) Received: from gw.openss7.com (gw.openss7.com [142.59.210.7]) by ietfa.amsl.com (Postfix) with ESMTP id 436B421F8EEC for ; Sun, 26 May 2013 02:32:52 -0700 (PDT) Received: from wilbur.pigworks.openss7.net (ns5.evil.openss7.net [192.168.9.5]) by gw.openss7.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id r4Q9WowW024577; Sun, 26 May 2013 03:32:50 -0600 Received: from wilbur.pigworks.openss7.net (localhost [127.0.0.1]) by wilbur.pigworks.openss7.net (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id r4Q9Wn8B002781; Sun, 26 May 2013 03:32:49 -0600 Received: (from brian@localhost) by wilbur.pigworks.openss7.net (8.14.3/8.14.3/Submit) id r4Q9WkFo002780; Sun, 26 May 2013 03:32:46 -0600 Date: Sun, 26 May 2013 03:32:46 -0600 From: "Brian F. G. Bidulock" To: Karen.Nielsen@tieto.com Message-ID: <20130526093246.GA1480@openss7.org> Mail-Followup-To: Karen.Nielsen@tieto.com, tsvwg@ietf.org, randall@lakerest.net, Michael.Tuexen@lurchi.franken.de References: <20130509221927.GB24653@openss7.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Organization: http://www.openss7.org/ Dsn-Notification-To: X-Spam-To: User-Agent: Mutt/1.5.18 (2008-05-17) Cc: Michael.Tuexen@lurchi.franken.de, tsvwg@ietf.org, randall@lakerest.net Subject: Re: [tsvwg] QUESTION on Return of SACKs and HB ACKs X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: bidulock@openss7.org List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 May 2013 09:32:58 -0000 Karen, Please see comments below... Karen.Nielsen@tieto.com wrote: (Sun, 19 May 2013 17:17:25) > > > > >IMO there no reason to send SACK and DATA to different destinations. > >Bundling SACK and DATA are essential for efficiency at high > >throughputs. The "best" destination should be used for both, where > >the "best" destination is the primary DATA destination for non-CMT. > > Agree completely. Apart from the mere throughput considerations, I > would also like to point to that return of SACK to the Primary DATA > destination also should be better from a robustness perspective as the > SACK returner are likely to have fresh and reliable information on the > "availability" of the Primary DATA destination (availability = data or > HB's send to the Primary DATA destination are acknowledge to be > received) While availability of other destination addresses may not be > fresh (depending on Path monitoring and HB intervals). Generally in > simple scenarios where one can trust there to be either > "bi-directional" connectivity or no connectivity at all in between > end-point addresses, then the receipt of DATA on a path of course is > fresh information that the return path works, but this is not > generally the situation in today's network - at least not on a > permanent basis. I.e., in failure situations, connectivity may only > work in one direction until the network has recovered (whether by > fault recovery or by route migration). > > The return of SACK to the Primary DATA destination will provide more > robust delivery of the SACK. If the SACK is not bundled with forward > DATA, e.g., if no data is in transit in this direction, one could then > argue for that implementations could bundle HBs with solely returned > SACKs (though surely one should implement appropriate rate limiting on > such HBs) thereby making sure to keep the path availability > information fresh (If the HBs consistently fail, the Primary DATA > destination should be changed). Yes and no. When sending SACKs only to a destination, RTT calculations are not performed and eventually a HB/ACK exchange must be performed in accordance with the RFC. The SACK sender has one other indication of failure and that is the receipt of duplications and the sending of dup acks. Sending of SACKs only is a typically situation when the data flow is unidirectional (or primarily unidirectional, or unidirectional over a significant interval). What I do is keep track of duplicates for destinations by remembering where the first SACK was sent for a TSN. If I receive a duplicate TSN for a SACK that was sent, I immediately trigger a heartbeat procedure for the destination (which will result in a HB being sent if one is not already outstanding or if data is not outstanding to the destination: i.e. no RTO timer is running for the destination). This cuts down non-CMT failure detection to an RTO instead of nominally 1/2 of the heartbeat interval. I do CMT, so when I receive duplicates that pass the ack-splitting logic, the destination is lowered in priority with respect to other destinations due to the dups. For CMT the triggering of heartbeat serves to restore the priority of the destination very quickly (in 1 RTT--RTT not RTO) in the event of a SACK loss anomaly. Otherwise it would take a nominal 1/2 HB interval to restore the priority of the destination. These procedures tested out as providing failure recovery of 1/2 the granularity of the system clock, even under purely unidirectional data flows! I would recommend against sending HB with SACK under any kind of basis, even rate limited, as there is no point in increasing the traffic to a destination that is under suspicion of failure. Also, exponential back-off of HB sending is essential. Therefore, I send one, and only if one is not already outstanding and only if no data is outstanding that would do the job otherwise. > >These approaches work quite well in practice. > > > > It could be very interesting to have such C P or B C P be written up, > I think. Do we write BCPs for PSs? Michael wrote some good RFCs and drafts on related subjects. -- Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ From salvatore.loreto@ericsson.com Mon May 27 06:34:40 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E9BE21F92F5 for ; Mon, 27 May 2013 06:34:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.229 X-Spam-Level: X-Spam-Status: No, score=-104.229 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, LOCALPART_IN_SUBJECT=2.02, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I4hQJmoCMKxX for ; Mon, 27 May 2013 06:34:34 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id E4E0221F960F for ; Mon, 27 May 2013 06:34:33 -0700 (PDT) X-AuditID: c1b4fb25-b7efb6d000007c26-99-51a360e88758 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id BD.2D.31782.8E063A15; Mon, 27 May 2013 15:34:32 +0200 (CEST) Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.279.1; Mon, 27 May 2013 15:34:32 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id CC3C823E9; Mon, 27 May 2013 16:34:31 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 508315513A; Mon, 27 May 2013 16:34:30 +0300 (EEST) Received: from Salvatore-Loretos-MacBook-Pro.local (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id EB34255097; Mon, 27 May 2013 16:34:29 +0300 (EEST) Message-ID: <51A360E7.7020209@ericsson.com> Date: Mon, 27 May 2013 16:34:31 +0300 From: Salvatore Loreto User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: , Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrKLMWRmVeSWpSXmKPExsUyM+Jvre6LhMWBBl9Xi1t8eLuP2eJQ60wW i2Nv7rI5MHssWfKTyePQ8yCPL5c/swUwR3HZpKTmZJalFunbJXBl7H94g6lgt2rFu+ZmpgbG pXJdjBwcEgImEocupXcxcgKZYhIX7q1n62Lk4hASOMUoMXfNTXYIZwOjxM1n25ghnN2MEgcu XINy1jFKLPw0CapnO6PEnIZVjCDDeAW0Ja4vAklwcrAIqEosfbKYBcRmEzCTeP5wCzOILSqQ LDF56goWiHpBiZMzn4DZIgKuEk93HQSbwyxgLHGxu4Ed5FZhAUeJidPtQExmAXuJB1vLICrk JZq3zmaGeEFN4uq5TWC2kICWRO/ZTqYJjMKzkCyYhdA9C0n3AkbmVYzsuYmZOenlRpsYgUF9 cMtv1R2Md86JHGKU5mBREufV410cKCSQnliSmp2aWpBaFF9UmpNafIiRiYNTqoFxzsxd4Rtb ygvWHp9ywzXO4llmYDzPng16u99d+rivxTnk+uL75Q/a/TO93F4LiTDeqD718cb2Mw8urnBZ 9OoGQ0NZ/xWz6/Omb9bfmxb5fu2FELZwo+OhYce+fLT+dHe+mOasYIbevbw2q6dGR4vOOM3d eUM+xbSWaeau/L6nRuqP93+1m9GtqcRSnJFoqMVcVJwIABJvPBc4AgAA Cc: "Karen E. E. Nielsen" Subject: [tsvwg] draft-ietf-tsvwg-sctp-failover: comments and suggestions X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 May 2013 13:34:40 -0000 Hi there, Karen (in cc) and I have reviewed together the draft and written down the following comments and suggestions - Section 5.1: CWND Handling for Potentially Failed Destinations The draft speaks about setting the CWND to 1 MTU (or 2MTU ?) when a Potentially Failed Path (destination) is reinstated in ACTIVE state as a result of the receipt of an HB ACK. We are not sure what is the motivation for any special measures to be taken in this situation. Generally the CWND settings are governed by RFC4960 prescriptions as to set the CWND to 1 MTU after T3-rtx (but not afterHB timeout) as well as RFC4960 guidelines to converge the CWND to the initial CWND towards idle destination addresses. We believe, in this respect, it is appropriate to keep the standard behaviour of RFC4960. - Section 5.3: Permanent Failover We have good experiences from live networks with running SCTP in a “no switchback” mode of operation with no automatic migration back to a preferred primary path. Once the primary path is left due to it being potentially failed, then a selected alternative path automatically becomes the new primary path. This mode of operation corresponds to a simplified variant of the permanent failover operation proposed in [CAR002] with alpha = beta = SCTP_PEER_ADDR:THLDS. The mode of operation is run with notifications of change of primary path being provided to upper layers via RFC6458 SCTP_PEER_ADDR_CHANGE semantics (SCTP_ADDR_MADE_PRIM). The mode of operation does not suit all purposes, but in networks environments where a number of equally preferred paths are available, then by this mode of operation one minimizes the effects of unnecessary path bouncing and the thereby associated effects of throughput degradation due to path changes and slow start operation. Based on our experiences we would recommend and support that the Permanent Failover mode of operation, at least in the simple variant described above, is promoted as a valid alternative approach. For the purpose of activation of this mode of operation a switchback (or failover) mode operation parameter could be introduced as configurable by the introduction of an appropriate new read/write socket option in the Socket API. - Section 5.4: The impact of HB timeouts in association error counter The draft recommends for excluding HB timeouts from contributing to the (association) error counter. We fully support this approach for all timeouts of HBs that are send to probe the state of destinations addresses that are in PF state and we would even propose for the draft to demand that generally timeouts stemming from HBs, which are not sent on the Primary Path, will be excluded from the association error counter. Thereby the association error counter and thus the association fate reflects the forward progress of the data transmission to peer endpoint while at the same time it will be appropriately isolated from timeouts of HBs sent on non-data carrying paths. Allowing timeout of HBs sent on the Primary Path to impact the association error counter will serve to validate the aliveness of the peer endpoint when there is no data in transit. This suggestion follows the thought expressed in http://www.ietf.org/mail-archive/web/tsvwg/current/msg11294.html and it is thus believed to fulfil the original intend of RFC4960. - Section 5.1 Thoughts on the destination address state machine In RFC4960 address state machine, notification of cease of use of the current primary path as transmission path for new data is provided to upper layer via (coupled with) the announcement of the destination as being UNREACHABLE. With the introduction of the potentially failed state as a semi-hidden state (not resulting in notified state transition to UL) the information on the fail-over to use a new data carrying path is lost. While there may be merits in suppressing notifications on potentially failed addresses, then we believe that it is unfortunate that the notification of failover from usage of the primary path for new data is lost. This is especially problematic in path bouncing scenarios where the primary path is unstable but still works some. E.g., HBs may go through, but the path breaks (data transmission fails) as soon as it is more loaded. In such a situation no notifications may be generated to UL, even if new data transmission consistently cycles to and from the primary path. The solution to such path bouncing scenarios will have to come from more advanced path failover mechanism, like [CAR002] (and would not be solved just by notification), but it would be a great help if appropriate notifications were provided. From Karen.Nielsen@tieto.com Tue May 28 07:54:02 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 686F821F976F for ; Tue, 28 May 2013 07:54:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E0ON1EYZ9GrO for ; Tue, 28 May 2013 07:53:57 -0700 (PDT) Received: from ebb06.tieto.com (ebb06.tieto.com [131.207.168.38]) by ietfa.amsl.com (Postfix) with ESMTP id B845B21F976E for ; Tue, 28 May 2013 07:53:55 -0700 (PDT) X-AuditID: 83cfa826-b7f5f6d000001d4d-ff-51a4c5017382 Received: from FIHGA-EXHUB01.eu.tieto.com ( [131.207.136.34]) by ebb06.tieto.com (SMTP Mailer) with SMTP id 48.3A.07501.105C4A15; Tue, 28 May 2013 17:53:53 +0300 (EEST) Received: from EXMB03.eu.tieto.com ([169.254.1.240]) by FIHGA-EXHUB01.eu.tieto.com ([131.207.136.34]) with mapi; Tue, 28 May 2013 17:53:53 +0300 From: To: Date: Tue, 28 May 2013 17:53:52 +0300 Thread-Topic: [tsvwg] QUESTION on Return of SACKs and HB ACKs Thread-Index: Ac5Z9AaaFdi3vrdiQqOkSYJG+qwmUgBuMUKw Message-ID: References: <20130509221927.GB24653@openss7.org> <20130526093246.GA1480@openss7.org> In-Reply-To: <20130526093246.GA1480@openss7.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrMKsWRmVeSWpSXmKPExsXSfL5DSZfx6JJAgxt7TC0mPPzIaHGxaQmj xZOen6wWx97cZXNg8Viy5CeTR//85SweG1p2MHk0N39jDmCJ4rJJSc3JLEst0rdL4Mr4ceU/ S8FF3Yo1N74yNjCuUOli5OSQEDCRODShmRXCFpO4cG89WxcjF4eQwCpGiddfu5kgnCmMEieX bWEBqWITkJeYu3cVO4gtIiAl0fnoFFicWSBIYsbuPWA2i4CqxLMN29hAbGEBG4m7rccYIept JbY3dbJC2EYSbWu2gc3hFfCROLjnLTPEsjuMEvc6Z4EVcQoYSHRtng02iBHovO+n1jBBLBOX uPVkPhPE2QISS/acZ4awRSVePv7HClEvKnGnfT0jRL2exI2pU9ggbG2JZQtfM0MsFpQ4OfMJ ywRGsVlIxs5C0jILScssJC0LGFlWMfKnJiUZmOmVZKaW5Osl5+duYgTH1wq1HYzPHkgdYhTg YFTi4Z2QvThQiDWxrLgy9xCjJAeTkiiv8uElgUJ8SfkplRmJxRnxRaU5qcWHGCU4mJVEeC+t BMrxpiRWVqUW5cOkpDlYlMR514vOCxQSSE8sSc1OTS1ILYLJynBwKEnwvgIZKliUmp5akZaZ U4KQZuLgBBnOAzT8P0gNb3FBYm5xZjpE/hSjLsfm85PfMQqx5OXnpUqJ8wofASoSACnKKM2D mwNLi68YxYHeEuZlB6niAaZUuEmvgJYwAS0RZ14MsqQkESEl1cCY/zEub0aILPOawq2X+03k JGLjjr5Y2KQecL/NecFGQ+0fexyUq2ysNbh5Uq+K3Ba8+a3g2XzlH1Vf93Vw5Dv25cytZd+f 3sbBZLRu3yR9liPM16sPzD8kpFKtFJb/PaKs/Vva5uhj89uuq32+6MGYf3GRZYii28etdnZL w5UeHDJpYzz8tEKJpTgj0VCLuag4EQC3VSU4ZgMAAA== Cc: Michael.Tuexen@lurchi.franken.de, tsvwg@ietf.org, randall@lakerest.net Subject: Re: [tsvwg] QUESTION on Return of SACKs and HB ACKs X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 May 2013 14:54:02 -0000 Hi Brian, >Yes and no. > >When sending SACKs only to a destination, RTT calculations are not perform= ed and >eventually a HB/ACK exchange must be performed in accordance with the RFC. >The SACK sender has one other indication of failure and that is the receip= t of >duplications and the sending of dup acks. Sending of SACKs only is a typi= cally >situation when the data flow is unidirectional (or primarily unidirectiona= l, or >unidirectional over a significant interval). What I do is keep track of d= uplicates for >destinations by remembering where the first SACK was sent for a TSN. If I= receive a >duplicate TSN for a SACK that was sent, I immediately trigger a heartbeat = procedure >for the destination (which will result in a HB being sent if one is not al= ready >outstanding or if data is not outstanding to the >destination: i.e. no RTO timer is running for the destination). >This cuts down non-CMT failure detection to an RTO instead of nominally 1/= 2 of the >heartbeat interval. > Yes, I think that your "reactive" approach has advantages compared to the "= proactive" approach of having all sole SACKs be bundled with HBs (provided, of course, no data or = HB is outstanding=20 to the destination). With the "proactive" approach (HB sent with each sole SACK, HB bundling rat= e limited to max one HB per RTO, No HB if data or other HB is outstanding) then one will adjust return path of SACK faster than with your proposed "re= active" approach. Namely after 1=BD RTO in average. On the other hand a loss of one isolated = HB bundled with SACK will, with the "proactive" approach, result in change of return path of SACK even if it was just a single isolat= ed loss that resulted in no problems from a data transmit perspective. I.e., no duplicate data. Whereas then wit= h your approach, actions are only taken when arrival of duplicate data hints at there being problems with loss of S= ACKs. I would still argue that the immediate HB sent once a duplicate data packet= is received should be bundled with the=20 SACK that also needs to be returned immediately. This at least for non-CMT = SCTP. I would further stress that one should discourage that the arrival of dupli= cate data in any way is treated as reliable indication that SACKs have been lost. Such would be vulnerable to packet duplications in th= e network as well as it would be very vulnerable to=20 malicious nodes that are able to insert duplicates in the network. Thus in = non-CMT SCTP I would say that change of SACK return path should not occur unless loss of connectivity is confirmed by lo= ss of the HB bundled with the immediately returned SACK. I wonder if you agree with this ? I suppose that your immediately returned HB also need to be rate limited. I= t should rather not be so that every duplicate data packet is allowed to result in transmit of HB (assuming that the HB subsequently is successfully= acked). Rate limiting is required also for the reactive approach. I think that remembering SACK return path on a per TSN basis sounds relativ= ely expensive, but for non-CMT SCTP it should suffice to remember the only and only Primary Path, knowledge which already is maintained, and= use this path also for SACKs. For CMT-SCTP I recognize that more state will have to be maintained. >I do CMT, so when I receive duplicates that pass the ack-splitting logic, = the >destination is lowered in priority with respect to other destinations due = to the dups. >For CMT the triggering of heartbeat serves to restore the priority of the = destination >very quickly (in >1 RTT--RTT not RTO) in the event of a SACK loss anomaly. Otherwise it wou= ld take >a nominal 1/2 HB interval to restore the priority of the destination. > >These procedures tested out as providing failure recovery of 1/2 the granu= larity of >the system clock, even under purely unidirectional data flows! > >I would recommend against sending HB with SACK under any kind of basis, ev= en >rate limited, as there is no point in increasing the traffic to a destinat= ion that is under >suspicion of failure.=20 Actually I think that both approaches does exactly this - namely they send = HBs to destinations that are under suspicion of failure. The difference is that in the "proactive" approach HBs are sent by default,= whereas in your approach the HBs are sent only when there is reason to suspect problems. I agree with the benefit of eliminating some of the unnecessary HBs at the = cost of=20 detection problems only a little later on. Further I think that your approa= ch is more robust as one have two sources of problems: the duplicate data packet PLUS a subseque= ntly lost HB (and SACK). Also, exponential back-off of HB sending is essential. >Therefore, I send one, and only if one is not already outstanding and only= if no data >is outstanding that would do the job otherwise. > Sure. >> >These approaches work quite well in practice. >> > >> >> It could be very interesting to have such C P or B C P be written up, >> I think. > >Do we write BCPs for PSs? > I don't know where the line is drawn exactly. Is the right approach then to create an RFC4960bis or an separate work item= that=20 clarifies this part of RFC4960 ? Part of what we are discussing here are additional details that may not nee= d to be specified (I don't know) ? But it seems that we agree that the SHOULD in section 6.4 of RFC4960 in reg= ard to return of SACKs is something which one=20 should generally not feel constrained by. Do you agree ? Thanks a lot ! BR, Karen >Michael wrote some good RFCs and drafts on related subjects. > >-- >Brian F. G. Bidulock >bidulock@openss7.org >http://www.openss7.org/ From wwwrun@rfc-editor.org Wed May 29 09:15:38 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 731BE21F9347; Wed, 29 May 2013 09:15:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.233 X-Spam-Level: X-Spam-Status: No, score=-101.233 tagged_above=-999 required=5 tests=[AWL=0.767, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rzCRtH4a4aPd; Wed, 29 May 2013 09:15:37 -0700 (PDT) Received: from rfc-editor.org (unknown [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id CFBDB21F9302; Wed, 29 May 2013 09:15:37 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 47421B1E003; Wed, 29 May 2013 09:14:39 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20130529161439.47421B1E003@rfc-editor.org> Date: Wed, 29 May 2013 09:14:39 -0700 (PDT) Cc: tsvwg@ietf.org, rfc-editor@rfc-editor.org Subject: [tsvwg] RFC 6951 on UDP Encapsulation of Stream Control Transmission Protocol (SCTP) Packets for End-Host to End-Host Communication X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 May 2013 16:15:38 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6951 Title: UDP Encapsulation of Stream Control Transmission Protocol (SCTP) Packets for End-Host to End-Host Communication Author: M. Tuexen, R. Stewart Status: Standards Track Stream: IETF Date: May 2013 Mailbox: tuexen@fh-muenster.de, randall@lakerest.net Pages: 12 Characters: 25676 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-tsvwg-sctp-udp-encaps-14.txt URL: http://www.rfc-editor.org/rfc/rfc6951.txt This document describes a simple method of encapsulating Stream Control Transmission Protocol (SCTP) packets into UDP packets and its limitations. This allows the usage of SCTP in networks with legacy NATs that do not support SCTP. It can also be used to implement SCTP on hosts without directly accessing the IP layer, for example, implementing it as part of the application without requiring special privileges. Please note that this document only describes the functionality required within an SCTP stack to add on UDP encapsulation, providing only those mechanisms for two end-hosts to communicate with each other over UDP ports. In particular, it does not provide mechanisms to determine whether UDP encapsulation is being used by the peer, nor the mechanisms for determining which remote UDP port number can be used. These functions are out of scope for this document. This document covers only end-hosts and not tunneling (egress or ingress) endpoints. This document is a product of the Transport Area Working Group Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From bidulock@openss7.org Thu May 30 03:20:48 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B72F921F9703 for ; Thu, 30 May 2013 03:20:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VRrx7UmgQZB2 for ; Thu, 30 May 2013 03:20:43 -0700 (PDT) Received: from gw.openss7.com (gw.openss7.com [142.59.210.7]) by ietfa.amsl.com (Postfix) with ESMTP id D1B6721F955C for ; Thu, 30 May 2013 03:20:42 -0700 (PDT) Received: from wilbur.pigworks.openss7.net (ns5.evil.openss7.net [192.168.9.5]) by gw.openss7.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id r4UAKeHF019102; Thu, 30 May 2013 04:20:40 -0600 Received: from wilbur.pigworks.openss7.net (localhost [127.0.0.1]) by wilbur.pigworks.openss7.net (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id r4UAKdCG022638; Thu, 30 May 2013 04:20:40 -0600 Received: (from brian@localhost) by wilbur.pigworks.openss7.net (8.14.3/8.14.3/Submit) id r4UAKcCD022637; Thu, 30 May 2013 04:20:38 -0600 Date: Thu, 30 May 2013 04:20:38 -0600 From: "Brian F. G. Bidulock" To: Karen.Nielsen@tieto.com Message-ID: <20130530102038.GA21134@openss7.org> Mail-Followup-To: Karen.Nielsen@tieto.com, Michael.Tuexen@lurchi.franken.de, tsvwg@ietf.org, randall@lakerest.net References: <20130509221927.GB24653@openss7.org> <20130526093246.GA1480@openss7.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Organization: http://www.openss7.org/ Dsn-Notification-To: X-Spam-To: User-Agent: Mutt/1.5.18 (2008-05-17) Cc: Michael.Tuexen@lurchi.franken.de, tsvwg@ietf.org, randall@lakerest.net Subject: Re: [tsvwg] QUESTION on Return of SACKs and HB ACKs X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: bidulock@openss7.org List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 May 2013 10:20:48 -0000 Karen.Nielsen, Please see comments below... Karen.Nielsen@tieto.com wrote: (Tue, 28 May 2013 17:53:52) > > With the "proactive" approach (HB sent with each sole SACK, HB > bundling rate limited to max one HB per RTO, No HB if data or other HB > is outstanding) then one will adjust return path of SACK faster than > with your proposed "reactive" approach. Namely after 1½ RTO in > average. On the other hand a loss of one isolated HB bundled with SACK > will, with the "proactive" approach, result in change of return path > of SACK even if it was just a single isolated loss that resulted in no > problems from a data transmit perspective. I.e., no duplicate data. > Whereas then with your approach, actions are only taken when arrival > of duplicate data hints at there being problems with loss of SACKs. No--for a number of reasons: 1. Senders are not required to bundle 2. SACKs that are not dup-acks can be (and normally are) delayed up to 200ms. 3. HB interval is required to be settable in ms and is often set to less than 200ms on high performance networks (i.e. SIGTRAN). 4. SACK rates depend on DATA flow in the reverse direction. If data in the reverse direction stops, SACKs stop. 5. HB are sent according to a HB interval which is statistically varied to avoid having many hosts sending HB's synchronously and simultaneously. If HB are bundled with SACK and data is flowing continuously in the reverse direction (common situation), HB will be sent ever 200ms if data flow is slow, and every two packet emission times when data is fast. In either case, HBs can be sent synchronously, defeating the entire statistical interval varying feature of the HB mechanism. You cannot support your 1-1/2 RTO figure. In fact the nominal recovery due to that approach alone can be >100ms, making it instead an "inactive" approach. ;) > I would still argue that the immediate HB sent once a duplicate data > packet is received should be bundled with the SACK that also needs to > be returned immediately. This at least for non-CMT SCTP. Do not bundle them together. The HB is going to the destination that is suspect of losing SACKs. Why send a SACK there? The SACK needs to go to the destination to which you are going to send SACKs and any pending DATA when it comes time to send (and there is still the incoming queue to process). > I would further stress that one should discourage that the arrival of > duplicate data in any way is treated as reliable indication that SACKs > have been lost. Such would be vulnerable to packet duplications in the > network as well as it would be very vulnerable to malicious nodes that > are able to insert duplicates in the network. Any MIM attacker that can duplicate packets can do way worse damage with far less effort than merely attempting to make the sender think his SACKs might not be getting through. Also, true network packet duplication can be curtailed at the network layer without even involving SCTP. Further on a CMT implementations, the duplicates must pass the multiple queue ack-splitting logic before being considered non-spurious and an attacker would be very hard pressed to time it perfectly. Nevertheless, the HB I send acts to "restore" the destination in one RTT. In my CMT algorithm, dups are weighted quite low as they are a weak signal. > Thus in non-CMT SCTP I would say that change of SACK return path > should not occur unless loss of connectivity is confirmed by loss of > the HB bundled with the immediately returned SACK. I wonder if you > agree with this ? No. Operational experience shows that, for non-CMT, SACKs should be sent on the primary path. When the primary path changes, the destination of the SACKs changes. Using loss of a HB bundled with a SACK (which you shouldn't do anyway), is an inadequate reason to change the primary path, even for unidirectional traffic flows, and could easily lead to thrashing. The same is true for CMT. Receipt of duplicates is a poor indicator of path availability and can really only support a weak suspicion, worthy of no more than a Red October ping ("one ping only"). In CMT however, it can serve to alter the order of paths selected for transmission when all other factors are equal between the paths and can support failover times on the order of the granularity of the system clock, particularly in the face of single path failures under unidirectional traffic flows, where duplicates are the ONLY indication of path failure other than the normal heartbeat mechanism (which, even at 25ms is too slow). The factor that makes it an even weaker indicator is CMT is the fact that SACKs are cumulative. Therefore, particularly when sending SACKs on multiple paths, it is difficult to determine with any certainty which destination lost the SACK (or SACKs) that caused the duplication. There are some ways I get around that, but there are far too complicated to discuss adequately in this note. > I suppose that your immediately returned HB also need to be rate > limited. It should rather not be so that every duplicate data packet > is allowed to result in transmit of HB (assuming that the HB > subsequently is successfully acked). Rate limiting is required also > for the reactive approach. It is effectively rate limited. I only send them when I receive a duplicate, no delayed SACK is pending (handles RTO < SACKdelay), no data in flight to the destination. I am required to send a SACK package even when the last two conditions do not hold, so the rate cannot be of concern. > I think that remembering SACK return path on a per TSN basis sounds > relatively expensive, but for non-CMT SCTP it should suffice to > remember the only and only Primary Path, knowledge which already is > maintained, and use this path also for SACKs. For CMT-SCTP I > recognize that more state will have to be maintained. Actually no. The destination I send the heartbeat to is the current preferred CMT destination or the current primary non-CMT destination (the one to which DATA and SACKs are sent) for less than full saturation traffic flows, and particularly unidirectional traffic flows, this is the likely destination to which the SACK was sent). The procedure is intended on handling unidirectional traffic flows where there is no other (fast) indicator of destination failure. BTW, I send the HB immediately, and do not bundle the SACK. This is because the SACK should be bundled with DATA in any event, and as a result of the duplicate pegging, is likely to be sent to a different destination as the HB: remember?--the destination to which the HB is going is already suspected of not passing SACKs, why would one send it to the suspect destination? > Part of what we are discussing here are additional details that may > not need to be specified (I don't know) ? But it seems that we agree > that the SHOULD in section 6.4 of RFC4960 in regard to return of SACKs > is something which one should generally not feel constrained by. > Do you agree ? I think that operational experience shows that it should be changed to say that SACKs should be bundled with DATA (when bundling is supported) and sent to the primary destination. --brian -- Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ From Karen.Nielsen@tieto.com Fri May 31 03:54:36 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7B5621F96EC for ; Fri, 31 May 2013 03:54:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IyzaEroHEoJm for ; Fri, 31 May 2013 03:54:31 -0700 (PDT) Received: from ebb06.tieto.com (ebb06.tieto.com [131.207.168.38]) by ietfa.amsl.com (Postfix) with ESMTP id DD51721F95E9 for ; Fri, 31 May 2013 03:54:30 -0700 (PDT) X-AuditID: 83cfa826-b7f876d000003dae-af-51a881640f48 Received: from FIVLA-EXHUB02.eu.tieto.com ( [131.207.136.42]) by ebb06.tieto.com (SMTP Mailer) with SMTP id 49.41.15790.46188A15; Fri, 31 May 2013 13:54:28 +0300 (EEST) Received: from EXMB03.eu.tieto.com ([169.254.1.240]) by FIVLA-EXHUB02.eu.tieto.com ([131.207.136.42]) with mapi; Fri, 31 May 2013 13:54:28 +0300 From: To: Date: Fri, 31 May 2013 13:54:27 +0300 Thread-Topic: [tsvwg] QUESTION on Return of SACKs and HB ACKs Thread-Index: Ac5d7TYjzHnqq+kwRwaLlxKd7caaxQ== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrJKsWRmVeSWpSXmKPExsXSfL5DSzelcUWgweG5OhYTHn5ktLjYtITR 4knPT1aLY2/usjmweCxZ8pPJo3/+chaPDS07mDyam78xB7BEcdmkpOZklqUW6dslcGXs/fGW reBeRsWun2+YGhhnBHcxcnJICJhIfD2/jxnCFpO4cG89WxcjF4eQwCpGiT8nVzFDOFMYJZZd XscEUsUmIC8xd+8qdhBbREBKovPRKRYQm1kgSGLG7j1ANgcHi4CqxNVPgiBhYQEbibutxxgh ym0ltjd1skLYehJ3b84BG8kr4CPxadcOsBpGoCO+n1rDBDFSXOLWk/lMEMcJSCzZcx7qUFGJ l4//sULUi0rcaV/PCFGvJ3Fj6hQ2CFtbYtnC18wQ8wUlTs58wjKBUWQWkrGzkLTMQtIyC0nL AkaWVYz8qUlJBmZ6JZmpJfl6yfm5mxjBsbJCbQfjswdShxgFOBiVeHgzkpYHCrEmlhVX5h5i lORgUhLl3Vi9IlCILyk/pTIjsTgjvqg0J7X4EKMEB7OSCO+6GqAcb0piZVVqUT5MSpqDRUmc 98DCpYFCAumJJanZqakFqUUwWRkODiUJ3iN1QI2CRanpqRVpmTklCGkmDk6Q4TxAw1+C1PAW FyTmFmemQ+RPMepybD4/+R2jEEtefl6qlDjvKZAiAZCijNI8uDmwFPeKURzoLWFe7XqgKh5g eoSb9ApoCRPQkifWy0GWlCQipKQaGCc1P7n/a6eTXlrQvo4P22xkn6o9mvBUSu9lsOmzckHf WX+WZVdfYs+eO6Gr23V1y976z7VhCin8Hzc3Tvq1UoFD9c1JAau4fh/m1dIfXm/I0w1bFxr0 YMnpxc83eK36eejKJp2j6j0KqQu7HRXkiw50twvn7k65klL8Zl/vPFuFa/OYM1+8mqLEUpyR aKjFXFScCADXzgDqTAMAAA== Cc: Michael.Tuexen@lurchi.franken.de, tsvwg@ietf.org, randall@lakerest.net Subject: Re: [tsvwg] QUESTION on Return of SACKs and HB ACKs X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 May 2013 10:54:37 -0000 Hi Brian, >-----Original Message----- >From: Brian F. G. Bidulock [mailto:bidulock@openss7.org] >Sent: Thursday, May 30, 2013 12:21 PM >To: Nielsen Karen >Cc: Michael.Tuexen@lurchi.franken.de; tsvwg@ietf.org; randall@lakerest.net >Subject: Re: [tsvwg] QUESTION on Return of SACKs and HB ACKs > >Karen.Nielsen, > >Please see comments below... > >Karen.Nielsen@tieto.com wrote: (Tue, 28 May 2013 17:53= :52) >> >> With the "proactive" approach (HB sent with each sole SACK, HB >> bundling rate limited to max one HB per RTO, No HB if data or other HB >> is outstanding) then one will adjust return path of SACK faster than >> with your proposed "reactive" approach. Namely after 1=BD RTO in >> average. On the other hand a loss of one isolated HB bundled with SACK >> will, with the "proactive" approach, result in change of return path >> of SACK even if it was just a single isolated loss that resulted in no >> problems from a data transmit perspective. I.e., no duplicate data. >> Whereas then with your approach, actions are only taken when arrival >> of duplicate data hints at there being problems with loss of SACKs. > >No--for a number of reasons: > >1. Senders are not required to bundle [Karen] Not sure what bundling that you refer to here. >2. SACKs that are not dup-acks can be (and normally are) delayed up to 200= ms. [Karen] Yes. I am sorry for the sloppiness and the resulting waste of time. In the SIGTRAN networks setting that I am aware of, however, a set of RTO_= MIN below delay_ack (or conversely a set of delay_ack larger than RTO_MIN) = is considered a mis-configuration. Now one may argue that here I am compari= ng apples and pears as, in theory at least, one could have different settin= g of delay_ack and RTO_MIN on the two sides and then have RTO_MIN on one si= de comply with delay_ack setting on other side while the delay_ack and the = RTO_MIN on the same side do not match. Such situations perhaps needs to be = considered for full generality. The 1=BDRTO referenced was intended to indicate the average time it takes t= o detect that the path used for sending SACKs is not working (or at least t= here was a loss) when no data is flowing. It is right that this evaluation = is sloppy as it did not take into consideration delay-ack nor did it take d= ata tails (data stop) into consideration. If we take data tail into consideration and delay ack, I suppose that we ar= e speaking, worst case, something like MAX(RTO_data_sender, delay_ack_SACK_= sender, RTO_SACK_sender)+RTO_SACK-sender before we discover (by HB timeout = of HB bundled with SACK) that SACK Path is not working. In the SIGTRAN network settings that I know of this would be below 2*RTO wo= rst case for data tail and ~1=BDRTO in average otherwise.=20 The norm in the SIGTRAN networks that I am familiar with is not 200ms for d= elay_ack. It is lower and it is definitively kept below RTO_MIN. Further RTO_MIN/RTO_MAX << HB interval.=20 When data is flowing, I do not think we need to discuss anything. We have a= lready agreed that SACK should go on data path and then data will serve to detect if the data path (and thus = the path used for SACK) is working. >3. HB interval is required to be settable in ms and is often set to > less than 200ms on high performance networks (i.e. SIGTRAN). [Karen] I wasn't aware that such aggressive HB intervals really was used. T= he SIGTRAN networks that I am familiar with=20 do not use such aggressive settings for the HB interval. Here typically RTO= << HB interval. I concur that this changes the picture quite a lot. I have not considered the situation where HB interval and RTO are comparabl= e. >4. SACK rates depend on DATA flow in the reverse direction. If data in > the reverse direction stops, SACKs stop. [Karen] Yes.=20 >5. HB are sent according to a HB interval which is statistically varied > to avoid having many hosts sending HB's synchronously and simultaneousl= y. [Karen] Are you referring to RTO jitter or to something else entirely ? > If HB are bundled with SACK and data is flowing continuously in the > reverse direction (common situation), HB will be sent ever 200ms if > data flow is slow, and every two packet emission times when data is > fast. =20 [Karen] Depending on delay_ack setting. The default values that I hear of a= re in the area of 50-100 msecs for delay_ack. I also know that some use 200ms= ecs. If delay_ack is 200msecs, RTO will be above 200 msecs. Rate-limiting HBs to= RTO would mean that not every SACK would carry a HB.=20 In either case, HBs can be sent synchronously, defeating the > entire statistical interval varying feature of the HB mechanism. > [Karen] I agree that I have not considered such aggressive HB intervals at = all. I am not sure why the varying of HBs bundled with a SACK (and driven by a S= ACK) is of concern. >You cannot support your 1-1/2 RTO figure. In fact the nominal recovery du= e to that >approach alone can be >100ms, making it instead an "inactive" >approach. ;) [Karen] 1=BD RTO, not =BD-1 RTO, but that's beyond the point of this discus= sion. Yes I would expect detection to happen after 100msec. You expect to have re= transmissions of data arrive faster=20 than after 100 msecs. Perhaps as a result of fast retransmission, but then = some SACKs are going back.=20 I=20 > >> I would still argue that the immediate HB sent once a duplicate data >> packet is received should be bundled with the SACK that also needs to >> be returned immediately. This at least for non-CMT SCTP. > >Do not bundle them together. The HB is going to the destination that is s= uspect of >losing SACKs. Why send a SACK there? > [Karen] We send SACK on assumed transfer data path (primary path). With your approach, I thought not to change neither SACK path nor data tran= sfer path (primary path), as a result of the arrival of a duplicate data packet. But to only change b= oth when=20 a HB had confirmed that the SACK return path (aka the primary path) had iss= ues. I understand now that you take a more "active", ;-), approach and change=20 SACK path (an data transfer path) immediately based on the hint from the du= plicate data packet. I was concerned that this would be too aggressive (and vulnerable to DoS), but you may have result that prove otherwise and the benefits may be so great that they outweigh potential DoS considerations. >The SACK needs to go to the destination to which you are going to send SAC= Ks >and any pending DATA when it comes time to send (and there is still the in= coming >queue to process). > >> I would further stress that one should discourage that the arrival of >> duplicate data in any way is treated as reliable indication that SACKs >> have been lost. Such would be vulnerable to packet duplications in the >> network as well as it would be very vulnerable to malicious nodes that >> are able to insert duplicates in the network. > >Any MIM attacker that can duplicate packets can do way worse damage with f= ar >less effort than merely attempting to make the sender think his SACKs migh= t not be >getting through. Also, true network packet duplication can be curtailed a= t the >network layer without even involving SCTP. >Further on a CMT implementations, the duplicates must pass the multiple qu= eue >ack-splitting logic before being considered non-spurious and an attacker w= ould be >very hard pressed to time it perfectly. > >Nevertheless, the HB I send acts to "restore" the destination in one RTT. = In my CMT >algorithm, dups are weighted quite low as they are a weak signal. > [Karen] Is there no reason to be concerned with the RTT fluctuations that t= emporary change of SACK path=20 could cause in other end ?=20 >> Thus in non-CMT SCTP I would say that change of SACK return path >> should not occur unless loss of connectivity is confirmed by loss of >> the HB bundled with the immediately returned SACK. I wonder if you >> agree with this ? > >No. Operational experience shows that, for non-CMT, SACKs should be sent = on the >primary path. When the primary path changes, the destination of the SACKs >changes. Using loss of a HB bundled with a SACK (which you shouldn't do >anyway), is an inadequate reason to change the primary path, even for unid= irectional >traffic flows, and could easily lead to thrashing. > [Karen] I concur, and did concur, that it is better to use the HBs only for= confirmation of=20 problems that are hinted at from the arrival of duplicate data. What happens once the duplicate data arrives is the discussion.=20 >The same is true for CMT. Receipt of duplicates is a poor indicator of pa= th >availability and can really only support a weak suspicion, worthy of no mo= re than a >Red October ping ("one ping only"). In CMT however, it can serve to alter= the order >of paths selected for transmission when all other factors are equal betwee= n the >paths and can support failover times on the order of the granularity of th= e system >clock, particularly in the face of single path failures under unidirection= al traffic >flows, where duplicates are the ONLY indication of path failure other than= the normal >heartbeat mechanism (which, even at 25ms is too slow). [Karen] You have an timeout on the HBs that is below 25msecs ? > >The factor that makes it an even weaker indicator is CMT is the fact that = SACKs are >cumulative. Therefore, particularly when sending SACKs on multiple paths,= it is >difficult to determine with any certainty which destination lost the SACK = (or SACKs) >that caused the duplication. There are some ways I get around that, but t= here are far >too complicated to discuss adequately in this note. [Karen] yes I can see this getting very tricky with CMT.=20 > >> I suppose that your immediately returned HB also need to be rate >> limited. It should rather not be so that every duplicate data packet >> is allowed to result in transmit of HB (assuming that the HB >> subsequently is successfully acked). Rate limiting is required also >> for the reactive approach. > >It is effectively rate limited. I only send them when I receive a duplica= te, no delayed >SACK is pending (handles RTO < SACKdelay), no data in flight to the destin= ation. I >am required to send a SACK package even when the last two conditions do no= t >hold, so the rate cannot be of concern. > >> I think that remembering SACK return path on a per TSN basis sounds >> relatively expensive, but for non-CMT SCTP it should suffice to >> remember the only and only Primary Path, knowledge which already is >> maintained, and use this path also for SACKs. For CMT-SCTP I recognize >> that more state will have to be maintained. > >Actually no. The destination I send the heartbeat to is the current prefe= rred CMT >destination=20 [Karen] I thought perhaps that you had multiple such preferred CMT destinations to = choose among. or the current primary non-CMT destination (the one to which DATA and >SACKs are sent) for less than full saturation traffic flows, and particula= rly >unidirectional traffic flows, this is the likely destination to which the = SACK was sent). >The procedure is intended on handling unidirectional traffic flows where t= here is no >other (fast) indicator of destination failure. > >BTW, I send the HB immediately, and do not bundle the SACK. This is becau= se the >SACK should be bundled with DATA in any event, and as a result of the dupl= icate >pegging, is likely to be sent to a different destination as the HB: rememb= er?--the >destination to which the HB is going is already suspected of not passing S= ACKs, >why would one send it to the suspect destination? > [Karen] I am not sure that it is wise to have hints from the arrival of a d= uplicate packet change the data transfer path. If there is DATA going out with the SACK, DATA will= much better serve to tell about whether the destination works or not. DATA, given Fast Retransmi= ssion, is not as prone to single losses as SACK or HBs are.=20 If there is no data going out (in the direction of the SACK) then one is le= ft with working with the information gained from the HB and the duplicate packets that arrive.=20 Whether one react on the duplicate packet alone or whether one awaits poten= tial back-up confirmation of failure from the HB is what divided us above. Agree ? I am still not 100% sure what is right (or best), but then we have not done= the experiments. >> Part of what we are discussing here are additional details that may >> not need to be specified (I don't know) ? But it seems that we agree >> that the SHOULD in section 6.4 of RFC4960 in regard to return of SACKs >> is something which one should generally not feel constrained by. >> Do you agree ? > >I think that operational experience shows that it should be changed to say= that >SACKs should be bundled with DATA (when bundling is >supported) and sent to the primary destination. > Great - Thanks ! BR, Karen >--brian > >-- >Brian F. G. Bidulock >bidulock@openss7.org >http://www.openss7.org/