From nobody Wed Aug 6 05:23:58 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F353F1B29E3 for ; Wed, 6 Aug 2014 05:23:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.903 X-Spam-Level: X-Spam-Status: No, score=-106.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WwsXseV3kZA6 for ; Wed, 6 Aug 2014 05:23:55 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) by ietfa.amsl.com (Postfix) with ESMTP id 2BB2D1B29E1 for ; Wed, 6 Aug 2014 05:23:55 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 265ED18001B; Wed, 6 Aug 2014 05:22:27 -0700 (PDT) To: randall@lakerest.net, spencerdawkins.ietf@gmail.com, mls.ietf@gmail.com, gorry@erg.abdn.ac.uk, david.black@emc.com, jmpolk@cisco.com X-PHP-Originating-Script: 6000:errata_mail_lib.php From: RFC Errata System Message-Id: <20140806122227.265ED18001B@rfc-editor.org> Date: Wed, 6 Aug 2014 05:22:27 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/NNRWtBIRy8Wr9QZmhu95LPNSbIw Cc: rfc-editor@rfc-editor.org, tsvwg@ietf.org, federico.zuccardimerli@ericsson.com Subject: [tsvwg] [Editorial Errata Reported] RFC4960 (4071) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Aug 2014 12:23:57 -0000 The following errata report has been submitted for RFC4960, "Stream Control Transmission Protocol". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=4960&eid=4071 -------------------------------------- Type: Editorial Reported by: Federico Zuccardi Merli Section: 6.1 Original Text ------------- However, regardless of the value of rwnd (including if it is 0), the data sender can always have one DATA chunk in flight to the receiver if allowed by cwnd (see rule B below). This rule allows the sender to probe for a change in rwnd that the sender missed due to the SACK having been lost in transit from the data receiver to the data sender. Corrected Text -------------- [empty] Notes ----- The whole paragraph is a one-to-one repetition of the final part of first paragraph of Rule A). The position of the paragraph does not affect meaning, but the repetition hinders readability. Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC4960 (draft-ietf-tsvwg-2960bis-05) -------------------------------------- Title : Stream Control Transmission Protocol Publication Date : September 2007 Author(s) : R. Stewart, Ed. Category : PROPOSED STANDARD Source : Transport Area Working Group Area : Transport Stream : IETF Verifying Party : IESG From nobody Thu Aug 7 17:07:17 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 296BC1A0564 for ; Thu, 7 Aug 2014 17:07:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y8w6lINqoZSj for ; Thu, 7 Aug 2014 17:07:11 -0700 (PDT) Received: from mailuogwdur.emc.com (mailuogwdur.emc.com [128.221.224.79]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6DE5A1A000A for ; Thu, 7 Aug 2014 17:07:11 -0700 (PDT) Received: from maildlpprd54.lss.emc.com (maildlpprd54.lss.emc.com [10.106.48.158]) by mailuogwprd54.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s780790e026388 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 7 Aug 2014 20:07:10 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd54.lss.emc.com s780790e026388 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1407456430; bh=QiqpSG5QZ9RKHPRx0rwBq6KUL1o=; h=From:To:Date:Subject:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=k4Jl+d9t0i5njs6cEzGxx9MFG/YFO3hzkORa/QtBvX3r8lBguaoOQNd/0TihNsTyS Dw6l6gFrI6QWdMw0WMNboJSGaKXrQSDWwr1wIwVaDrSXtMJsh8b/gi4UZ7qk8GKlGD RzkHRaiGheMxm6+PSRnVdkdHXciLpW0oihZix/n8= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd54.lss.emc.com s780790e026388 Received: from mailusrhubprd04.lss.emc.com (mailusrhubprd04.lss.emc.com [10.253.24.22]) by maildlpprd54.lss.emc.com (RSA Interceptor) for ; Thu, 7 Aug 2014 20:06:59 -0400 Received: from mxhub27.corp.emc.com (mxhub27.corp.emc.com [10.254.110.183]) by mailusrhubprd04.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s7806xnd010345 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 7 Aug 2014 20:06:59 -0400 Received: from mx15a.corp.emc.com ([169.254.1.175]) by mxhub27.corp.emc.com ([10.254.110.183]) with mapi; Thu, 7 Aug 2014 20:06:59 -0400 From: "Black, David" To: "tsvwg@ietf.org" Date: Thu, 7 Aug 2014 20:06:58 -0400 Thread-Topic: WG Adoption Call for draft-fairhurst-tsvwg-circuit-breaker- 22 August 2014 Thread-Index: Ac+ynKuV3jqxrlUtQCavOPlrAQqLrA== Message-ID: <8D3D17ACE214DC429325B2B98F3AE712077B951766@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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd04.lss.emc.com X-RSA-Classifications: public Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/mSJWqCvhsW8TrAgACk3Q1qmMc20 Subject: [tsvwg] WG Adoption Call for draft-fairhurst-tsvwg-circuit-breaker- 22 August 2014 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Aug 2014 00:07:14 -0000 The TSVWG chairs are considering adoption of the above draft. This draft has been discussed at previous IETF meetings and on the list. At the recent Toronto IETF meeting, the draft received strong support from the people present in the meeting room, and no comments against adopting this draft as a TSVWG work item. The WG chairs now invite any further comments on this adoption. If there are concerns or comments about adoption please send comments to the list or to the Chairs. We plan to make a final decision on this adoption on 22 August 2014. Also, would the draft author (Gorry) please send a note to the list indicating whether you know of any IPR related to this draft that requires disclosure in accordance with BCP 79. Needless to say, Gorry is recused from this decision, as he is the author of this draft. Thanks, --David (tsvwg WG co-chair) ---------------------------------------------------- David L. Black, Distinguished Engineer EMC Corporation, 176 South St., Hopkinton, MA=A0 01748 +1 (508) 293-7953=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 FAX: +1 (508) 293-778= 6 david.black@emc.com=A0=A0=A0=A0=A0=A0=A0 Mobile: +1 (978) 394-7754 ---------------------------------------------------- From nobody Fri Aug 8 10:32:36 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7791A1B2845 for ; Fri, 8 Aug 2014 10:32:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zza-9vY8p98m for ; Fri, 8 Aug 2014 10:32:31 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9BE791B2B72 for ; Fri, 8 Aug 2014 10:32:27 -0700 (PDT) Received: from [128.9.160.211] (mul.isi.edu [128.9.160.211]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id s78HVnGK026861 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 8 Aug 2014 10:31:50 -0700 (PDT) Message-ID: <53E50985.9010009@isi.edu> Date: Fri, 08 Aug 2014 10:31:49 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: "Black, David" , "tsvwg@ietf.org" References: <8D3D17ACE214DC429325B2B98F3AE712077B951766@MX15A.corp.emc.com> In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE712077B951766@MX15A.corp.emc.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/QNd7BvcxyZkaFC3X-8JUe_IzbEk Subject: Re: [tsvwg] WG Adoption Call for draft-fairhurst-tsvwg-circuit-breaker- 22 August 2014 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Aug 2014 17:32:34 -0000 I support the adoption of this document, and know of no IPR. Joe On 8/7/2014 5:06 PM, Black, David wrote: > The TSVWG chairs are considering adoption of the above draft. This draft > has been discussed at previous IETF meetings and on the list. > > At the recent Toronto IETF meeting, the draft received strong support from > the people present in the meeting room, and no comments against adopting > this draft as a TSVWG work item. > > The WG chairs now invite any further comments on this adoption. If there > are concerns or comments about adoption please send comments to the list > or to the Chairs. We plan to make a final decision on this adoption on > 22 August 2014. > > Also, would the draft author (Gorry) please send a note to the list > indicating whether you know of any IPR related to this draft that > requires disclosure in accordance with BCP 79. Needless to say, > Gorry is recused from this decision, as he is the author of this draft. > > Thanks, > --David (tsvwg WG co-chair) > ---------------------------------------------------- > David L. Black, Distinguished Engineer > EMC Corporation, 176 South St., Hopkinton, MA 01748 > +1 (508) 293-7953 FAX: +1 (508) 293-7786 > david.black@emc.com Mobile: +1 (978) 394-7754 > ---------------------------------------------------- > > > From nobody Fri Aug 8 11:05:26 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BAC31B2B49 for ; Fri, 8 Aug 2014 11:05:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6xLmDs3sLgN5 for ; Fri, 8 Aug 2014 11:05:01 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2EC31B2861 for ; Fri, 8 Aug 2014 11:05:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1687; q=dns/txt; s=iport; t=1407521100; x=1408730700; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=Zl7oKIZIr2Rlc8O/ahxxSqIFmCEZ5fysU/bYjEGaW+E=; b=N+OZj9PpqDMtvcVkAq887H4fDJdQ1ld6iYs1BktAWXldZeJUGdWChJxC 8Dw2NqROfaOB2gzsiVvnXjJLuXbedDK+TR4eP8UASIfJ2q8lJrpewRa7N adIq0LFfb+GABQsgGvM2AY9tb/413TWccExrv+82Odp3wkaixHP2qvNzh Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhAFAGcQ5VOtJV2a/2dsb2JhbABXA4MNgSkE1DQBgRUWd4QDAQEBBB0dSwQCAQgRBAEBAQoUCQcyFAkIAQEEEwiIOsVkF4wdgn4hFwYLgx6BHAWKI4Zzlw2IfoIRgUZsgUc X-IronPort-AV: E=Sophos;i="5.01,826,1400025600"; d="scan'208";a="67687512" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-6.cisco.com with ESMTP; 08 Aug 2014 18:05:00 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s78I50IT021853 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 8 Aug 2014 18:05:00 GMT Received: from xmb-rcd-x12.cisco.com ([169.254.2.108]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.03.0123.003; Fri, 8 Aug 2014 13:05:00 -0500 From: "Michael Ramalho (mramalho)" To: "tsvwg@ietf.org" Thread-Topic: [tsvwg] WG Adoption Call for draft-fairhurst-tsvwg-circuit-breaker- 22 August 2014 Thread-Index: Ac+ynKuV3jqxrlUtQCavOPlrAQqLrAAu9+SAAAlZbwA= Date: Fri, 8 Aug 2014 18:04:59 +0000 Message-ID: References: <8D3D17ACE214DC429325B2B98F3AE712077B951766@MX15A.corp.emc.com> <53E50985.9010009@isi.edu> In-Reply-To: <53E50985.9010009@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.213.24] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/SDJj2DiQP02RgoVAGNUKjtfYJrw Subject: Re: [tsvwg] WG Adoption Call for draft-fairhurst-tsvwg-circuit-breaker- 22 August 2014 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Aug 2014 18:05:09 -0000 +1 Michael Ramalho -----Original Message----- From: tsvwg [mailto:tsvwg-bounces@ietf.org] On Behalf Of Joe Touch Sent: Friday, August 08, 2014 1:32 PM To: Black, David; tsvwg@ietf.org Subject: Re: [tsvwg] WG Adoption Call for draft-fairhurst-tsvwg-circuit-bre= aker- 22 August 2014 I support the adoption of this document, and know of no IPR. Joe On 8/7/2014 5:06 PM, Black, David wrote: > The TSVWG chairs are considering adoption of the above draft. This=20 > draft has been discussed at previous IETF meetings and on the list. > > At the recent Toronto IETF meeting, the draft received strong support=20 > from the people present in the meeting room, and no comments against=20 > adopting this draft as a TSVWG work item. > > The WG chairs now invite any further comments on this adoption. If=20 > there are concerns or comments about adoption please send comments to=20 > the list or to the Chairs. We plan to make a final decision on this=20 > adoption on > 22 August 2014. > > Also, would the draft author (Gorry) please send a note to the list=20 > indicating whether you know of any IPR related to this draft that=20 > requires disclosure in accordance with BCP 79. Needless to say, Gorry=20 > is recused from this decision, as he is the author of this draft. > > Thanks, > --David (tsvwg WG co-chair) > ---------------------------------------------------- > David L. Black, Distinguished Engineer EMC Corporation, 176 South St.,=20 > Hopkinton, MA 01748 > +1 (508) 293-7953 FAX: +1 (508) 293-7786 > david.black@emc.com Mobile: +1 (978) 394-7754 > ---------------------------------------------------- > > > From nobody Fri Aug 8 12:53:01 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEB061A03F4 for ; Fri, 8 Aug 2014 12:52:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p_ML-6wpLLKh for ; Fri, 8 Aug 2014 12:52:45 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E4EAE1A03BB for ; Fri, 8 Aug 2014 12:52:44 -0700 (PDT) X-AuditID: c1b4fb3a-f79da6d0000008c7-0a-53e52a8afb07 Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.183.75]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id DF.98.02247.A8A25E35; Fri, 8 Aug 2014 21:52:42 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.62]) by ESESSHC019.ericsson.se ([153.88.183.75]) with mapi id 14.03.0174.001; Fri, 8 Aug 2014 21:52:32 +0200 From: Salvatore Loreto To: Joe Touch Thread-Topic: [tsvwg] WG Adoption Call for draft-fairhurst-tsvwg-circuit-breaker- 22 August 2014 Thread-Index: AQHPsy7A4lTrmNYqvkeWpB+r6KjvHpvG/COA Date: Fri, 8 Aug 2014 19:52:30 +0000 Message-ID: <1C64A5E7-5BE5-4601-9F15-1F70F34F3EBB@ericsson.com> References: <8D3D17ACE214DC429325B2B98F3AE712077B951766@MX15A.corp.emc.com> <53E50985.9010009@isi.edu> In-Reply-To: <53E50985.9010009@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.150] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupnkeLIzCtJLcpLzFFi42KZGbHdW7dL62mwwZKHlhZbD69lt1j3Zy6L xbE3d9kcmD2OHJnN4rFkyU8mj93vt7IEMEdx2aSk5mSWpRbp2yVwZfzYuoO1YBpPxYy2F4wN jFc4uxg5OSQETCS+LfvIBmGLSVy4tx7I5uIQEjjCKPH97Q0mCGcRo8Tu7duYQKrYBMwknj/c wgxiiwjISjz484YdxGYW8JY4duc8WI2wQKLExOXb2SFqkiS2rjnB2MXIAWQbSZz8kwUSZhFQ kXjZ2AO2mFfAXmLx1rlgtpBAhsTtrYfBxnAKqEu8vbieEcRmBDru+6k1TBCrxCVuPZnPBHG0 gMSSPeeZIWxRiZeP/7FC2EoSK7ZfYoSoN5B4f24+M4RtLfF3/Q2ouLbEsoWvmSFuEJQ4OfMJ ywRG8VlIVsxC0j4LSfssJO2zkLQvYGRdxShanFpcnJtuZKSXWpSZXFycn6eXl1qyiREYgwe3 /LbawXjwueMhRgEORiUe3gX7HgcLsSaWFVfmHmKU5mBREuddeG5esJBAemJJanZqakFqUXxR aU5q8SFGJg5OqQbGvIZNW5cIb1vb1c/2SlSgWGxySq//Y3HrozkG5zmal0xbb/Lgy8cFagW7 5vezzPw1QajYxePiUu2feX+zpbPkv1393qaVVeGw2igzt6v35g/Jwm3RK7zvZOz92sa+5aig 87mNJxYeetondC3v1vOFXJ9WGC0MOlDy4+STTuN5Qtvz/m5dGBlyQomlOCPRUIu5qDgRAC1W 17+iAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/9tJgGF5KdkGyZ-uL3VZf_PNOmkg Cc: "tsvwg@ietf.org" Subject: Re: [tsvwg] WG Adoption Call for draft-fairhurst-tsvwg-circuit-breaker- 22 August 2014 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Aug 2014 19:52:56 -0000 I also support the adoption of this document Salvatore On Aug 8, 2014, at 7:31 PM, Joe Touch wrote: > I support the adoption of this document, and know of no IPR. >=20 > Joe >=20 > On 8/7/2014 5:06 PM, Black, David wrote: >> The TSVWG chairs are considering adoption of the above draft. This draft >> has been discussed at previous IETF meetings and on the list. >>=20 >> At the recent Toronto IETF meeting, the draft received strong support fr= om >> the people present in the meeting room, and no comments against adopting >> this draft as a TSVWG work item. >>=20 >> The WG chairs now invite any further comments on this adoption. If there >> are concerns or comments about adoption please send comments to the list >> or to the Chairs. We plan to make a final decision on this adoption on >> 22 August 2014. >>=20 >> Also, would the draft author (Gorry) please send a note to the list >> indicating whether you know of any IPR related to this draft that >> requires disclosure in accordance with BCP 79. Needless to say, >> Gorry is recused from this decision, as he is the author of this draft. >>=20 >> Thanks, >> --David (tsvwg WG co-chair) >> ---------------------------------------------------- >> David L. Black, Distinguished Engineer >> EMC Corporation, 176 South St., Hopkinton, MA 01748 >> +1 (508) 293-7953 FAX: +1 (508) 293-7786 >> david.black@emc.com Mobile: +1 (978) 394-7754 >> ---------------------------------------------------- >>=20 >>=20 >>=20 >=20 From nobody Fri Aug 8 13:03:11 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 150811A0421 for ; Fri, 8 Aug 2014 13:03:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.978 X-Spam-Level: X-Spam-Status: No, score=-0.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MISSING_HEADERS=1.021, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hCThs_X8OzMh for ; Fri, 8 Aug 2014 13:03:06 -0700 (PDT) Received: from mail-ie0-x232.google.com (mail-ie0-x232.google.com [IPv6:2607:f8b0:4001:c03::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E71221A044D for ; Fri, 8 Aug 2014 13:03:01 -0700 (PDT) Received: by mail-ie0-f178.google.com with SMTP id rd18so7020011iec.37 for ; Fri, 08 Aug 2014 13:03:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:cc :content-type; bh=kjQEEs9XkJIDY4uyBR7F2Hka83QbWrIfo67bCRnKgAg=; b=hUqgX9mwCFCZGjAvLBwL4PeA+2uEJB7En1Z2vk8RdWf5NsiHV18DRln1KII2HaVm0j J6NUG5sfQLeFacpST2P1bu12zQDT54E9SaeXCWnSGJlVgApk9de6pcUzF9VtLXbVYp/b RRACQmDpIteREWYUupVEq/f+lc9oVryqrKV0rB9ANGinEjfwbm/MHJMwly0W5YocoE6Z tJMBnL5WbR0ceKIA4hcILwyqehnbUMbwum8PXqcNcJSb52P2cuVzFPyGpOSDvH/+3wtz 45DAqNJBA4Ljr90cuTW9ZIpVN6cdBz39/zdEjX2WPIkUmBqCziS401rX2z3gdKv03kFI 74cQ== MIME-Version: 1.0 X-Received: by 10.50.107.7 with SMTP id gy7mt5638418igb.15.1407528181306; Fri, 08 Aug 2014 13:03:01 -0700 (PDT) Received: by 10.50.251.175 with HTTP; Fri, 8 Aug 2014 13:03:01 -0700 (PDT) Received: by 10.50.251.175 with HTTP; Fri, 8 Aug 2014 13:03:01 -0700 (PDT) In-Reply-To: <53E50985.9010009@isi.edu> References: <8D3D17ACE214DC429325B2B98F3AE712077B951766@MX15A.corp.emc.com> <53E50985.9010009@isi.edu> Date: Fri, 8 Aug 2014 23:03:01 +0300 Message-ID: From: Varun Singh Content-Type: multipart/alternative; boundary=e89a8ffbae41422fc2050023b193 Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/ClIIiYtLuz7bbGYClObFBlXXiTA Cc: "tsvwg@ietf.org" Subject: Re: [tsvwg] WG Adoption Call for draft-fairhurst-tsvwg-circuit-breaker- 22 August 2014 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Aug 2014 20:03:08 -0000 --e89a8ffbae41422fc2050023b193 Content-Type: text/plain; charset=UTF-8 I support the adoption of this draft and volunteer to review future versions of the document. Varun. On 8 Aug 2014 20:32, "Joe Touch" wrote: > I support the adoption of this document, and know of no IPR. > > Joe > > On 8/7/2014 5:06 PM, Black, David wrote: > >> The TSVWG chairs are considering adoption of the above draft. This draft >> has been discussed at previous IETF meetings and on the list. >> >> At the recent Toronto IETF meeting, the draft received strong support from >> the people present in the meeting room, and no comments against adopting >> this draft as a TSVWG work item. >> >> The WG chairs now invite any further comments on this adoption. If there >> are concerns or comments about adoption please send comments to the list >> or to the Chairs. We plan to make a final decision on this adoption on >> 22 August 2014. >> >> Also, would the draft author (Gorry) please send a note to the list >> indicating whether you know of any IPR related to this draft that >> requires disclosure in accordance with BCP 79. Needless to say, >> Gorry is recused from this decision, as he is the author of this draft. >> >> Thanks, >> --David (tsvwg WG co-chair) >> ---------------------------------------------------- >> David L. Black, Distinguished Engineer >> EMC Corporation, 176 South St., Hopkinton, MA 01748 >> +1 (508) 293-7953 FAX: +1 (508) 293-7786 >> david.black@emc.com Mobile: +1 (978) 394-7754 >> ---------------------------------------------------- >> >> >> >> > --e89a8ffbae41422fc2050023b193 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

I support the adoption of this draft and volunteer to review= future versions of the document.

Varun.=C2=A0

On 8 Aug 2014 20:32, "Joe Touch" <<= a href=3D"mailto:touch@isi.edu">touch@isi.edu> wrote:
I support the adoption of this document, and know of no IPR.

Joe

On 8/7/2014 5:06 PM, Black, David wrote:
The TSVWG chairs are considering adoption of the above draft. This draft has been discussed at previous IETF meetings and on the list.

At the recent Toronto IETF meeting, the draft received strong support from<= br> the people present in the meeting room, and no comments against adopting this draft as a TSVWG work item.

The WG chairs now invite any further comments on this adoption. If there are concerns or comments about adoption please send comments to the list or to the Chairs. =C2=A0We plan to make a final decision on this adoption o= n
22 August 2014.

Also, would the draft author (Gorry) please send a note to the list
indicating whether you know of any IPR related to this draft that
requires disclosure in accordance with BCP 79. =C2=A0Needless to say,
Gorry is recused from this decision, as he is the author of this draft.

Thanks,
--David (tsvwg WG co-chair)
----------------------------------------------------
David L. Black, Distinguished Engineer
EMC Corporation, 176 South St., Hopkinton, MA =C2=A001748
+1 (508) 293-7953=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0FAX: +1 (508) 293-7786
david.black@emc.co= m =C2=A0 =C2=A0 =C2=A0 =C2=A0Mobile: +1 (978) 394-7754 ----------------------------------------------------




--e89a8ffbae41422fc2050023b193-- From nobody Fri Aug 8 13:39:51 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A71651A0B14 for ; Fri, 8 Aug 2014 13:39:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A7zvl_P9cW7c for ; Fri, 8 Aug 2014 13:39:48 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE0261A00D8 for ; Fri, 8 Aug 2014 13:39:47 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BLA74594; Fri, 08 Aug 2014 20:39:46 +0000 (GMT) Received: from DFWEML704-CHM.china.huawei.com (10.193.5.141) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 8 Aug 2014 21:39:45 +0100 Received: from DFWEML701-CHM.china.huawei.com ([10.193.5.50]) by dfweml704-chm ([10.193.5.141]) with mapi id 14.03.0158.001; Fri, 8 Aug 2014 13:39:34 -0700 From: Lucy yong To: "tsvwg@ietf.org" Thread-Topic: [tsvwg] WG Adoption Call for draft-fairhurst-tsvwg-circuit-breaker- 22 August 2014 Thread-Index: Ac+ynKuV3jqxrlUtQCavOPlrAQqLrAAzKMaAAATpzgAADQ5nUA== Date: Fri, 8 Aug 2014 20:39:33 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D453C9DDA@dfweml701-chm.china.huawei.com> References: <8D3D17ACE214DC429325B2B98F3AE712077B951766@MX15A.corp.emc.com> <53E50985.9010009@isi.edu> <1C64A5E7-5BE5-4601-9F15-1F70F34F3EBB@ericsson.com> In-Reply-To: <1C64A5E7-5BE5-4601-9F15-1F70F34F3EBB@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.138.88] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/jW0AEMfWE2uhKjvHmUfViZCSKpc Subject: Re: [tsvwg] WG Adoption Call for draft-fairhurst-tsvwg-circuit-breaker- 22 August 2014 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Aug 2014 20:39:49 -0000 Support! Lucy=20 On Aug 8, 2014, at 7:31 PM, Joe Touch wrote: > I support the adoption of this document, and know of no IPR. >=20 > Joe >=20 > On 8/7/2014 5:06 PM, Black, David wrote: >> The TSVWG chairs are considering adoption of the above draft. This=20 >> draft has been discussed at previous IETF meetings and on the list. >>=20 >> At the recent Toronto IETF meeting, the draft received strong support=20 >> from the people present in the meeting room, and no comments against=20 >> adopting this draft as a TSVWG work item. >>=20 >> The WG chairs now invite any further comments on this adoption. If=20 >> there are concerns or comments about adoption please send comments to=20 >> the list or to the Chairs. We plan to make a final decision on this=20 >> adoption on >> 22 August 2014. >>=20 >> Also, would the draft author (Gorry) please send a note to the list=20 >> indicating whether you know of any IPR related to this draft that=20 >> requires disclosure in accordance with BCP 79. Needless to say,=20 >> Gorry is recused from this decision, as he is the author of this draft. >>=20 >> Thanks, >> --David (tsvwg WG co-chair) >> ---------------------------------------------------- >> David L. Black, Distinguished Engineer EMC Corporation, 176 South=20 >> St., Hopkinton, MA 01748 >> +1 (508) 293-7953 FAX: +1 (508) 293-7786 >> david.black@emc.com Mobile: +1 (978) 394-7754 >> ---------------------------------------------------- >>=20 >>=20 >>=20 >=20 From nobody Sat Aug 9 02:38:07 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 193431A0B13 for ; Sat, 9 Aug 2014 02:38:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ubf0AwuJV7wJ for ; Sat, 9 Aug 2014 02:38:01 -0700 (PDT) Received: from mail-out5.uio.no (mail-out5.uio.no [IPv6:2001:700:100:10::17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C5011A0B07 for ; Sat, 9 Aug 2014 02:38:00 -0700 (PDT) Received: from mail-mx1.uio.no ([129.240.10.29]) by mail-out5.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1XG366-0006t3-1O for tsvwg@ietf.org; Sat, 09 Aug 2014 11:37:58 +0200 Received: from 25.71.202.84.customer.cdi.no ([84.202.71.25] helo=[192.168.0.114]) by mail-mx1.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1XG365-0007oi-Du for tsvwg@ietf.org; Sat, 09 Aug 2014 11:37:57 +0200 From: Michael Welzl Content-Type: multipart/alternative; boundary="Apple-Mail=_329D2762-1613-43A3-8AB5-5E3A38B65765" Message-Id: <539EA622-839D-4CA4-815C-F8D0F95DD714@ifi.uio.no> Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) Date: Sat, 9 Aug 2014 11:37:55 +0200 References: <8D3D17ACE214DC429325B2B98F3AE712077B951766@MX15A.corp.emc.com> <53E50985.9010009@isi.edu> To: "tsvwg@ietf.org" In-Reply-To: X-Mailer: Apple Mail (2.1878.2) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 1 msgs/h 1 sum rcpts/h 2 sum msgs/h 1 total rcpts 19070 max rcpts/h 44 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, HTML_MESSAGE=0.001, TVD_RCVD_IP=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 8C259409B9C65CBCCF3822D770AB191F4B5D7E55 X-UiO-SPAM-Test: remote_host: 84.202.71.25 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 95 max/h 5 blacklist 0 greylist 0 ratelimit 0 Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/BSYIwk3c3fKZIQWvNNFXvj3hr78 Subject: Re: [tsvwg] WG Adoption Call for draft-fairhurst-tsvwg-circuit-breaker- 22 August 2014 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Aug 2014 09:38:04 -0000 --Apple-Mail=_329D2762-1613-43A3-8AB5-5E3A38B65765 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii +1 On 8. aug. 2014, at 22:03, Varun Singh wrote: > I support the adoption of this draft and volunteer to review future = versions of the document. >=20 > Varun.=20 >=20 > On 8 Aug 2014 20:32, "Joe Touch" wrote: > I support the adoption of this document, and know of no IPR. >=20 > Joe >=20 > On 8/7/2014 5:06 PM, Black, David wrote: > The TSVWG chairs are considering adoption of the above draft. This = draft > has been discussed at previous IETF meetings and on the list. >=20 > At the recent Toronto IETF meeting, the draft received strong support = from > the people present in the meeting room, and no comments against = adopting > this draft as a TSVWG work item. >=20 > The WG chairs now invite any further comments on this adoption. If = there > are concerns or comments about adoption please send comments to the = list > or to the Chairs. We plan to make a final decision on this adoption = on > 22 August 2014. >=20 > Also, would the draft author (Gorry) please send a note to the list > indicating whether you know of any IPR related to this draft that > requires disclosure in accordance with BCP 79. Needless to say, > Gorry is recused from this decision, as he is the author of this = draft. >=20 > Thanks, > --David (tsvwg WG co-chair) > ---------------------------------------------------- > David L. Black, Distinguished Engineer > EMC Corporation, 176 South St., Hopkinton, MA 01748 > +1 (508) 293-7953 FAX: +1 (508) 293-7786 > david.black@emc.com Mobile: +1 (978) 394-7754 > ---------------------------------------------------- >=20 >=20 >=20 >=20 --Apple-Mail=_329D2762-1613-43A3-8AB5-5E3A38B65765 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii +1


On 8. aug. 2014, at 22:03, Varun Singh <vsingh.ietf@gmail.com> wrote:

I support the adoption of this draft and volunteer to review future versions of the document.

Varun. 

On 8 Aug 2014 20:32, "Joe Touch" <touch@isi.edu> wrote:
I support the adoption of this document, and know of no IPR.

Joe

On 8/7/2014 5:06 PM, Black, David wrote:
The TSVWG chairs are considering adoption of the above draft. This draft
has been discussed at previous IETF meetings and on the list.

At the recent Toronto IETF meeting, the draft received strong support from
the people present in the meeting room, and no comments against adopting
this draft as a TSVWG work item.

The WG chairs now invite any further comments on this adoption. If there
are concerns or comments about adoption please send comments to the list
or to the Chairs.  We plan to make a final decision on this adoption on
22 August 2014.

Also, would the draft author (Gorry) please send a note to the list
indicating whether you know of any IPR related to this draft that
requires disclosure in accordance with BCP 79.  Needless to say,
Gorry is recused from this decision, as he is the author of this draft.

Thanks,
--David (tsvwg WG co-chair)
----------------------------------------------------
David L. Black, Distinguished Engineer
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
david.black@emc.com        Mobile: +1 (978) 394-7754
----------------------------------------------------





--Apple-Mail=_329D2762-1613-43A3-8AB5-5E3A38B65765-- From nobody Sat Aug 9 11:50:55 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A593D1A0196; Sat, 9 Aug 2014 11:48:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.132 X-Spam-Level: X-Spam-Status: No, score=0.132 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RP_MATCHES_RCVD=-0.668] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vSQSEH-718yU; Sat, 9 Aug 2014 11:48:16 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C66561A0009; Sat, 9 Aug 2014 11:48:16 -0700 (PDT) Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id s79ImD3G015211 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 9 Aug 2014 13:48:15 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.23] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ben Campbell Date: Sat, 9 Aug 2014 13:48:13 -0500 X-Mao-Original-Outgoing-Id: 429302893.093861-e61d2b4180cda6697e5d18b3ca4c2570 Content-Transfer-Encoding: quoted-printable Message-Id: <941BB385-72AA-42F2-A40C-0C1ACC3D2334@nostrum.com> References: To: tsvwg@ietf.org, avt@ietf.org, "clue@ietf.org" , mmusic@ietf.org, rtcweb@ietf.org, rmcat@ietf.org X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/asJbwe6KdQ50x2znW329KwGPBCs Cc: draft-ietf-dart-dscp-rtp.all@tools.ietf.org Subject: [tsvwg] Fwd: WGLC: draft-ietf-dart-dscp-rtp-02 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Aug 2014 18:48:24 -0000 X-List-Received-Date: Sat, 09 Aug 2014 18:48:24 -0000 Hi, The DART working group has started a last call for = draft-ietf-dart-dscp-rtp-02, ending on August 22. This informational = draft describes considerations for the use of DiffServ code points in = situations where one multiplexes multiple RTP packet streams, and = potentially other protocol streams, that share the same 5-tuple.=20 Since this draft is likely of interest to several working groups, I = would like to solicit additional reviews from participants of TSVWG, = AVTCORE, MMUSIC, CLUE, RTCWEB, and RMCAT. Please send any feedback = (including feedback to the effect of "this is ready to progress") to the = DART working group mailing list. Thanks! Ben. Begin forwarded message: > Resent-From: draft-alias-bounces@tools.ietf.org > From: Ben Campbell > Subject: WGLC: draft-ietf-dart-dscp-rtp-02 > Date: August 9, 2014 at 12:50:16 PM CDT > Resent-To: ben@nostrum.com, david.black@emc.com, paulej@packetizer.com > To: dart@ietf.org > Cc: draft-ietf-dart-dscp-rtp.all@tools.ietf.org, mls.ietf@gmail.com, = Richard Barnes >=20 > This is a DART Working Group Last Call of draft-ietf-dart-dscp-rtp-02. = It's available on the data tracker at the following URL: >=20 > https://datatracker.ietf.org/doc/draft-ietf-dart-dscp-rtp/ >=20 > The WGLC will conclude on 22 August, 2014. Please send your comments = to the authors and the DART mailing list. If you've reviewed it and = think it's good to go, please say so. >=20 > Thanks! >=20 > Ben. >=20 From nobody Sat Aug 9 23:25:51 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 278E51A0661; Sat, 9 Aug 2014 23:25:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dmXVB8bH_5Nq; Sat, 9 Aug 2014 23:25:46 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 216D91A02F6; Sat, 9 Aug 2014 23:25:46 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p5 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140810062546.27368.13420.idtracker@ietfa.amsl.com> Date: Sat, 09 Aug 2014 23:25:46 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/lkDZDMMk_OTpC-FmcyFU9ItImAE Cc: tsvwg@ietf.org Subject: [tsvwg] I-D Action: draft-ietf-tsvwg-rsvp-pcn-09.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Aug 2014 06:25:47 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Area Working Group Working Group of the IETF. Title : Generic Aggregation of Resource ReSerVation Protocol (RSVP) for IPv4 And IPv6 Reservations over PCN domains Authors : Georgios Karagiannis Anurag Bhargava Filename : draft-ietf-tsvwg-rsvp-pcn-09.txt Pages : 28 Date : 2014-08-09 Abstract: This document specifies extensions to Generic Aggregated RSVP RFC 4860 for support of the PCN Controlled Load (CL) and Single Marking (SM) edge behaviors over a Diffserv cloud using Pre- Congestion Notification. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rsvp-pcn/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-tsvwg-rsvp-pcn-09 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-rsvp-pcn-09 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sat Aug 9 23:33:51 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AA6A1A0665 for ; Sat, 9 Aug 2014 23:33:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OY4SDvZxLhVZ for ; Sat, 9 Aug 2014 23:33:47 -0700 (PDT) Received: from out68-ams.mf.surf.net (out68-ams.mf.surf.net [145.0.1.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59B081A065F for ; Sat, 9 Aug 2014 23:33:46 -0700 (PDT) Received: from EXEDGE01.ad.utwente.nl (exedge01.ad.utwente.nl [130.89.5.48]) by outgoing3-ams.mf.surf.net (8.14.4/8.14.4/Debian-4) with ESMTP id s7A6YESg007965; Sun, 10 Aug 2014 08:34:15 +0200 Received: from EXHUB02.ad.utwente.nl (130.89.4.229) by EXEDGE01.ad.utwente.nl (130.89.5.48) with Microsoft SMTP Server (TLS) id 14.3.181.6; Sun, 10 Aug 2014 08:31:32 +0200 Received: from EXMBX24.ad.utwente.nl ([169.254.4.146]) by EXHUB02.ad.utwente.nl ([130.89.4.229]) with mapi id 14.03.0181.006; Sun, 10 Aug 2014 08:31:25 +0200 From: To: Thread-Topic: New Version Notification - draft-ietf-tsvwg-rsvp-pcn-09.txt Thread-Index: AQHPtGP1mT7riAMml0izGM2+rxrI3JvJX1Dy Date: Sun, 10 Aug 2014 06:31:24 +0000 Message-ID: References: <20140810062546.27368.82453.idtracker@ietfa.amsl.com> In-Reply-To: <20140810062546.27368.82453.idtracker@ietfa.amsl.com> Accept-Language: nl-NL, en-US Content-Language: nl-NL X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.89.9.237] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Bayes-Prob: 0.0001 (Score 0, tokens from: utwente-out:default, base:default, @@RPTN) X-CanIt-Geo: ip=130.89.5.48; country=NL; region=Provincie Overijssel; city=Enschede; latitude=52.2195; longitude=6.8912; http://maps.google.com/maps?q=52.2195,6.8912&z=6 X-CanItPRO-Stream: utwente-out:default (inherits from utwente:default, base:default) X-Canit-Stats-ID: 0bMASyewG - 83ee23c7e1bb - 20140810 (trained as not-spam) X-Scanned-By: CanIt (www . roaringpenguin . com) Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/hTjD0Fj_uFZ77R9KJcgolfQ6Mag Cc: iana-prot-param@iana.org, anuragb@cisco.com Subject: [tsvwg] FW: New Version Notification - draft-ietf-tsvwg-rsvp-pcn-09.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Aug 2014 06:33:49 -0000 Hi all, Please note that in the new version of the RSVP over PCN draft, see below, = we have incorporated the IANA changes associated with the recommendations o= f Francois. Best regards, Georgios ________________________________________ Van: internet-drafts@ietf.org [internet-drafts@ietf.org] Verzonden: zondag 10 augustus 2014 8:25 Aan: tsvwg-chairs@tools.ietf.org; draft-ietf-tsvwg-rsvp-pcn@tools.ietf.org;= spencerdawkins.ietf@gmail.com Onderwerp: New Version Notification - draft-ietf-tsvwg-rsvp-pcn-09.txt A new version (-09) has been submitted for draft-ietf-tsvwg-rsvp-pcn: http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-rsvp-pcn-09.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rsvp-pcn/ Diff from previous version: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tsvwg-rsvp-pcn-09 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. IETF Secretariat.= From nobody Sun Aug 10 12:14:17 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5249C1A014F for ; Sun, 10 Aug 2014 12:14:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.969 X-Spam-Level: X-Spam-Status: No, score=-4.969 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E28MMvaBvHm8 for ; Sun, 10 Aug 2014 12:14:14 -0700 (PDT) Received: from mailuogwdur.emc.com (mailuogwdur.emc.com [128.221.224.79]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 673281A0009 for ; Sun, 10 Aug 2014 12:14:14 -0700 (PDT) Received: from maildlpprd54.lss.emc.com (maildlpprd54.lss.emc.com [10.106.48.158]) by mailuogwprd52.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s7AJE149006581 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 10 Aug 2014 15:14:01 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd52.lss.emc.com s7AJE149006581 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1407698042; bh=CuPjsNTVNtaJkBwv1rdDmLZkT+I=; h=From:To:CC:Date:Subject:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=Sc6iZbhP/vkM6vmH6TRLaqxM7ffVsW8vJJFJ/BF90J2XRo9gGF5RS2W0uUsnaXG9u mm1rsHrTB12ioes6QUUa6FQNvY4I1otvaTZXL29AmH5azVcjzqM6bv3Y3dmvLvTZr+ U/TNZSfTGqIPxXIqfFHRLM9O1v07Zj6O69mFJM5g= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd52.lss.emc.com s7AJE149006581 Received: from mailusrhubprd53.lss.emc.com (mailusrhubprd53.lss.emc.com [10.106.48.18]) by maildlpprd54.lss.emc.com (RSA Interceptor); Sun, 10 Aug 2014 15:13:49 -0400 Received: from mxhub04.corp.emc.com (mxhub04.corp.emc.com [10.254.141.106]) by mailusrhubprd53.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s7AJDlJX021969 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 10 Aug 2014 15:13:49 -0400 Received: from mx15a.corp.emc.com ([169.254.1.175]) by mxhub04.corp.emc.com ([10.254.141.106]) with mapi; Sun, 10 Aug 2014 15:13:47 -0400 From: "Black, David" To: "karagian@cs.utwente.nl" , "tsvwg@ietf.org" Date: Sun, 10 Aug 2014 15:13:46 -0400 Thread-Topic: [tsvwg] FW: New Version Notification - draft-ietf-tsvwg-rsvp-pcn-09.txt Thread-Index: AQHPtGP1mT7riAMml0izGM2+rxrI3JvJX1DygADVaaA= Message-ID: <8D3D17ACE214DC429325B2B98F3AE712077B951941@MX15A.corp.emc.com> References: <20140810062546.27368.82453.idtracker@ietfa.amsl.com> 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-Sentrion-Hostname: mailusrhubprd53.lss.emc.com X-RSA-Classifications: DLM_1, public Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/6VtxztV3JDNyNgPdMrovPDxxVLc Cc: "anuragb@cisco.com" Subject: Re: [tsvwg] FW: New Version Notification - draft-ietf-tsvwg-rsvp-pcn-09.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Aug 2014 19:14:16 -0000 Here's a bit more explanation - because this draft is intended to become an Experimental RFC (and not Proposed Standard), it was necessary to perform the IANA actions prior to submitting the RFC publication request. With Francois's able help as the Designated Expert, those IANA actions have now been performed, the results have been recorded in this -09 version of the draft, and I have just sent off the RFC publication request for that -09 version to our AD (Spencer). Thanks, --David (tsvwg WG co-chair) > -----Original Message----- > From: tsvwg [mailto:tsvwg-bounces@ietf.org] On Behalf Of > karagian@cs.utwente.nl > Sent: Sunday, August 10, 2014 2:31 AM > To: tsvwg@ietf.org > Cc: iana-prot-param@iana.org; anuragb@cisco.com > Subject: [tsvwg] FW: New Version Notification - draft-ietf-tsvwg-rsvp-pcn= - > 09.txt >=20 > Hi all, >=20 > Please note that in the new version of the RSVP over PCN draft, see below= , we > have incorporated the IANA changes associated with the recommendations of > Francois. >=20 > Best regards, > Georgios >=20 >=20 > ________________________________________ > Van: internet-drafts@ietf.org [internet-drafts@ietf.org] > Verzonden: zondag 10 augustus 2014 8:25 > Aan: tsvwg-chairs@tools.ietf.org; draft-ietf-tsvwg-rsvp-pcn@tools.ietf.or= g; > spencerdawkins.ietf@gmail.com > Onderwerp: New Version Notification - draft-ietf-tsvwg-rsvp-pcn-09.txt >=20 > A new version (-09) has been submitted for draft-ietf-tsvwg-rsvp-pcn: > http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-rsvp-pcn-09.txt >=20 >=20 >=20 > The IETF datatracker page for this Internet-Draft is: > https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rsvp-pcn/ >=20 > Diff from previous version: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tsvwg-rsvp-pcn-09 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. >=20 > IETF Secretariat. From nobody Mon Aug 11 00:32:24 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F58C1A0360 for ; Mon, 11 Aug 2014 00:32:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CPhkRI5th1n1 for ; Mon, 11 Aug 2014 00:32:20 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F8141A0361 for ; Mon, 11 Aug 2014 00:32:19 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: tsvwg@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p5 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140811073219.18657.17229.idtracker@ietfa.amsl.com> Date: Mon, 11 Aug 2014 00:32:19 -0700 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/bda_R-dKBvObxIXziwHYunCUqqk Subject: [tsvwg] Milestones changed for tsvwg WG X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Aug 2014 07:32:22 -0000 Changed milestone "Submit 'DTLS Encapsulation of SCTP Packets for RTCWEB ' to IESG for consideration as a Proposed Standard RFC", set due date to October 2014 from January 2014. Changed milestone "Submit 'Recommendations for Transport Port Uses' to the IESG", set due date to December 2014 from June 2014. URL: http://datatracker.ietf.org/wg/tsvwg/charter/ From nobody Mon Aug 11 03:22:09 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6E091A03FF; Mon, 11 Aug 2014 03:21:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.118 X-Spam-Level: X-Spam-Status: No, score=-3.118 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NAHagK2RxI3P; Mon, 11 Aug 2014 03:21:47 -0700 (PDT) Received: from tcmail43.telekom.de (tcmail43.telekom.de [80.149.113.173]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D7031A03F7; Mon, 11 Aug 2014 03:21:46 -0700 (PDT) Received: from qdezc2.de.t-internal.com ([10.125.181.10]) by tcmail41.telekom.de with ESMTP; 11 Aug 2014 12:21:39 +0200 X-IronPort-AV: E=Sophos;i="5.01,840,1400018400"; d="scan'208";a="118455659" Received: from he111630.emea1.cds.t-internal.com ([10.134.93.22]) by qde0ps.de.t-internal.com with ESMTP/TLS/AES128-SHA; 11 Aug 2014 12:21:14 +0200 Received: from HE111643.EMEA1.CDS.T-INTERNAL.COM ([10.134.93.12]) by HE111630.emea1.cds.t-internal.com ([::1]) with mapi; Mon, 11 Aug 2014 12:21:13 +0200 From: To: Date: Mon, 11 Aug 2014 12:21:12 +0200 Thread-Topic: [Dart] WGLC: draft-ietf-dart-dscp-rtp-02 Thread-Index: Ac+z+nRLTxiz6TcWSyWF7k9hB70xAwBPUAHQ Message-ID: References: In-Reply-To: Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/u7S8dDL_9FKOtPpkRlk0Ti_nlYQ Cc: dart@ietf.org, tsvwg@ietf.org Subject: Re: [tsvwg] [Dart] WGLC: draft-ietf-dart-dscp-rtp-02 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Aug 2014 10:21:51 -0000 Hi David, new EF related text has been added in the -01 version. I've copied=20 in some text of RFC3246 related to EF remarking and policing below.=20 My take: . remarking of entire flows is an option, but no remarking of=20 packets exceeding EF capacity limits. - looking at the EF jitter and delay properties, I doubt that=20 shaping is desirable. RFC3246 doesn't mention shaping as part=20 of EF conditioning. I personally wouldn't expect EF shaping=20 in sections where policing is applied.=20 - dropping of packets exceeding EF capacity is a MUST, if I=20 interpret RFC3246 correctly. I suggest to adapt the section of draft-dart-dscp to be more=20 precise regarding the optional remarking of EF traffic and to=20 remove shaping as a conditioning option if traffic is beyond=20 the EF forwarding capacity limit. A Proposal for the final=20 sentence: ...exceeds that capacity must be dropped. EF compliant flows may=20 be remarked to a different DSCP. All other new text indicated by the Diff version looks allright. Regards, Ruediger draft-dart-dscp: 3. Expedited Forwarding (EF) [RFC3246] intended for inelastic=09 traffic. Beyond the basic EF PHB, the VOICE-ADMIT PHB [RFC5865]=09 is an admission controlled variant of the EF PHB. Both of these=09 PHBs are based on pre-configured limited forwarding capacity;=09 traffic that exceeds that capacity may be shaped, remarked to a=09 different DSCP, or dropped. ######################################## RFC3246 (three excerpts): Packets belonging to a single microflow within the EF aggregate passing through a device SHOULD NOT experience re-ordering in normal operation of the device. Packets marked for EF PHB MAY be remarked at a DS domain boundary only to other codepoints that satisfy the EF PHB. Packets marked for EF PHBs SHOULD NOT be demoted or promoted to another PHB by a DS domain. If the EF PHB is implemented by a mechanism that allows unlimited preemption of other traffic (e.g., a priority queue), the implementation MUST include some means to limit the damage EF traffic could inflict on other traffic (e.g., a token bucket rate limiter). Traffic that exceeds this limit MUST be discarded. -----Urspr=FCngliche Nachricht----- Von: Dart [mailto:dart-bounces@ietf.org] Im Auftrag von Ben Campbell Gesendet: Samstag, 9. August 2014 19:50 An: dart@ietf.org Cc: Richard Barnes; draft-ietf-dart-dscp-rtp.all@tools.ietf.org; mls.ietf@g= mail.com Betreff: [Dart] WGLC: draft-ietf-dart-dscp-rtp-02 This is a DART Working Group Last Call of draft-ietf-dart-dscp-rtp-02. It's= available on the data tracker at the following URL: https://datatracker.ietf.org/doc/draft-ietf-dart-dscp-rtp/ The WGLC will conclude on 22 August, 2014. Please send your comments to the= authors and the DART mailing list. If you've reviewed it and think it's go= od to go, please say so. Thanks! Ben. _______________________________________________ Dart mailing list Dart@ietf.org https://www.ietf.org/mailman/listinfo/dart From nobody Mon Aug 11 06:16:10 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37B081A06FA; Mon, 11 Aug 2014 06:16:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.369 X-Spam-Level: X-Spam-Status: No, score=-3.369 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vWy2IqjMVU_I; Mon, 11 Aug 2014 06:16:04 -0700 (PDT) Received: from mailuogwhop.emc.com (mailuogwhop.emc.com [168.159.213.141]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 637871A0172; Mon, 11 Aug 2014 06:16:03 -0700 (PDT) Received: from maildlpprd03.lss.emc.com (maildlpprd03.lss.emc.com [10.253.24.35]) by mailuogwprd03.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s7BDFxum030574 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 11 Aug 2014 09:16:02 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd03.lss.emc.com s7BDFxum030574 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1407762962; bh=Yk6q0gx7Cycl8Hrs5K2zu3TzRuQ=; h=From:To:CC:Date:Subject:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=Y3WtXWi/G0waln9CRnqEx9tXuyeOc4VMObFZmob9FuTZ9JmlTU4++I8BdN1y0fxTJ jTyrIFZuQUmJC4BOwsSUZ3gtRgpDepbLliFeDk/p/h60FeAppy9g2AKsvfR7mT5OqU d9OlatvwYrorvbr0VjUjbuDgFU6jzcJ99oluWYUk= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd03.lss.emc.com s7BDFxum030574 Received: from mailusrhubprd03.lss.emc.com (mailusrhubprd03.lss.emc.com [10.253.24.21]) by maildlpprd03.lss.emc.com (RSA Interceptor); Mon, 11 Aug 2014 09:15:40 -0400 Received: from mxhub30.corp.emc.com (mxhub30.corp.emc.com [128.222.70.170]) by mailusrhubprd03.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s7BDFe41005128 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 11 Aug 2014 09:15:40 -0400 Received: from mx15a.corp.emc.com ([169.254.1.175]) by mxhub30.corp.emc.com ([128.222.70.170]) with mapi; Mon, 11 Aug 2014 09:15:39 -0400 From: "Black, David" To: "Ruediger.Geib@telekom.de" Date: Mon, 11 Aug 2014 09:15:37 -0400 Thread-Topic: [Dart] WGLC: draft-ietf-dart-dscp-rtp-02 Thread-Index: Ac+z+nRLTxiz6TcWSyWF7k9hB70xAwBPUAHQAAsWe6A= Message-ID: <8D3D17ACE214DC429325B2B98F3AE712077B9519E3@MX15A.corp.emc.com> 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd03.lss.emc.com X-RSA-Classifications: DLM_1, public Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/JNo2q6K8SQzPJF9JeB8lT8PQmA0 Cc: "dart@ietf.org" , "tsvwg@ietf.org" Subject: Re: [tsvwg] [Dart] WGLC: draft-ietf-dart-dscp-rtp-02 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Aug 2014 13:16:07 -0000 > I suggest to adapt the section of draft-dart-dscp to be more > precise regarding the optional remarking of EF traffic and to > remove shaping as a conditioning option if traffic is beyond > the EF forwarding capacity limit. Yes, something definitely needs to be done, as shaping excess traffic is not consistent with the EF service. In addition, RFC 3246 recommends against (SHOULD NOT) remarking EF traffic within a DS domain in one of the text excerpts that was in your email, so remarking should not be mentioned as a possibility. Further, RFC 3246 recommends that excess traffic SHOULD be dropped (section 3): To protect itself against denial of service attacks, the edge of a DS domain SHOULD strictly police all EF marked packets to a rate negotiated with the adjacent upstream domain. Packets in excess of the negotiated rate SHOULD be dropped. I'll reword the dart draft text as follows: OLD Both of these PHBs are based on pre-configured limited forwarding capacity; traffic that exceeds that capacity may be shaped, remarked to a different DSCP, or dropped. NEW Both of these PHBs are based on pre-configured limited forwarding capacity; traffic in excess of that capacity is expected to be dropped. Thanks for noticing this, --David > -----Original Message----- > From: Ruediger.Geib@telekom.de [mailto:Ruediger.Geib@telekom.de] > Sent: Monday, August 11, 2014 6:21 AM > To: Black, David > Cc: dart@ietf.org; tsvwg@ietf.org > Subject: AW: [Dart] WGLC: draft-ietf-dart-dscp-rtp-02 >=20 > Hi David, >=20 > new EF related text has been added in the -01 version. I've copied > in some text of RFC3246 related to EF remarking and policing below. > My take: >=20 > . remarking of entire flows is an option, but no remarking of > packets exceeding EF capacity limits. > - looking at the EF jitter and delay properties, I doubt that > shaping is desirable. RFC3246 doesn't mention shaping as part > of EF conditioning. I personally wouldn't expect EF shaping > in sections where policing is applied. > - dropping of packets exceeding EF capacity is a MUST, if I > interpret RFC3246 correctly. >=20 > I suggest to adapt the section of draft-dart-dscp to be more > precise regarding the optional remarking of EF traffic and to > remove shaping as a conditioning option if traffic is beyond > the EF forwarding capacity limit. A Proposal for the final > sentence: >=20 > ...exceeds that capacity must be dropped. EF compliant flows may > be remarked to a different DSCP. >=20 > All other new text indicated by the Diff version looks allright. >=20 > Regards, >=20 > Ruediger >=20 >=20 >=20 > draft-dart-dscp: >=20 > 3. Expedited Forwarding (EF) [RFC3246] intended for inelastic > traffic. Beyond the basic EF PHB, the VOICE-ADMIT PHB [RFC5865] > is an admission controlled variant of the EF PHB. Both of these > PHBs are based on pre-configured limited forwarding capacity; > traffic that exceeds that capacity may be shaped, remarked to a > different DSCP, or dropped. >=20 > ######################################## >=20 > RFC3246 (three excerpts): >=20 > Packets belonging to a single microflow within the EF aggregate > passing through a device SHOULD NOT experience re-ordering in normal > operation of the device. >=20 > Packets marked for EF PHB MAY be remarked at a DS domain boundary > only to other codepoints that satisfy the EF PHB. Packets marked for > EF PHBs SHOULD NOT be demoted or promoted to another PHB by a DS > domain. >=20 > If the EF PHB is implemented by a mechanism that allows unlimited > preemption of other traffic (e.g., a priority queue), the > implementation MUST include some means to limit the damage EF traffic > could inflict on other traffic (e.g., a token bucket rate limiter). > Traffic that exceeds this limit MUST be discarded. >=20 >=20 >=20 >=20 >=20 > -----Urspr=FCngliche Nachricht----- > Von: Dart [mailto:dart-bounces@ietf.org] Im Auftrag von Ben Campbell > Gesendet: Samstag, 9. August 2014 19:50 > An: dart@ietf.org > Cc: Richard Barnes; draft-ietf-dart-dscp-rtp.all@tools.ietf.org; > mls.ietf@gmail.com > Betreff: [Dart] WGLC: draft-ietf-dart-dscp-rtp-02 >=20 > This is a DART Working Group Last Call of draft-ietf-dart-dscp-rtp-02. It= 's > available on the data tracker at the following URL: >=20 > https://datatracker.ietf.org/doc/draft-ietf-dart-dscp-rtp/ >=20 > The WGLC will conclude on 22 August, 2014. Please send your comments to t= he > authors and the DART mailing list. If you've reviewed it and think it's g= ood > to go, please say so. >=20 > Thanks! >=20 > Ben. >=20 > _______________________________________________ > Dart mailing list > Dart@ietf.org > https://www.ietf.org/mailman/listinfo/dart From nobody Mon Aug 11 06:37:50 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3F291A02F6 for ; Mon, 11 Aug 2014 06:37:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.169 X-Spam-Level: X-Spam-Status: No, score=-2.169 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Goi8TI1Wr6gS for ; Mon, 11 Aug 2014 06:37:46 -0700 (PDT) Received: from spey.erg.abdn.ac.uk (spey.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id C01121A02EF for ; Mon, 11 Aug 2014 06:37:45 -0700 (PDT) Received: from www.erg.abdn.ac.uk (blake.erg.abdn.ac.uk [139.133.210.30]) by spey.erg.abdn.ac.uk (Postfix) with ESMTPSA id 151F52B427B for ; Mon, 11 Aug 2014 14:37:45 +0100 (BST) Received: from 139.133.204.3 (SquirrelMail authenticated user gorry) by www.erg.abdn.ac.uk with HTTP; Mon, 11 Aug 2014 14:37:45 +0100 Message-ID: Date: Mon, 11 Aug 2014 14:37:45 +0100 From: gorry@erg.abdn.ac.uk To: tsvwg@ietf.org User-Agent: SquirrelMail/1.4.22 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/2zUm_nVGz1ilpvXPejDejNNeyJw Subject: [tsvwg] TSVWG Status update, August 2014. X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Aug 2014 13:37:49 -0000 The list below shows the status of the working group documents as we see it. Please check below and comment on drafts using the list. Please do send any corrections/omissions to the chairs. Gorry, David & James (TSVWG Chairs) August 2014 ------------------------------------------------------------------- Document recently published: RFC 7141, formerly draft-ietf-tsvwg-byte-pkt-congest - Document Shepherd: Gorry ------------------------------------------------------------------- IDs in RFC Editor Queue (http://www.rfc-editor.org/queue.html) : None ---------------------------------------------------------- IDs in IESG processing: draft-ietf-tsvwg-rsvp-pcn - Document Shepherd: James/David Document adopted, status will be EXP (IETF-84 due to dependencies on RSVP) RSVP-DIR review received (BB, KC). WGLC concluded Friday, August 23rd, 2013. Nov 2013, Next step new ID required to address RSVP model and then repeat WGLC Document revised. Francois added as author. No noted disagreement from WG. Mar 2014, WGLC started on the updated text. Scott Bradner commented on document in WGLC. Because this is intended to become an Experimental RFC (and not Proposed Standard), it was necessary to perform the IANA actions prior to submitting the RFC publication request. - Done. Aug 2014 - IANA actions performed, write-up submitted; RFC publication requested. ------------------------------------------------------------------- New proposed work: draft-fairhurst-tsvwg-circuit-breaker (adoption request on tsvwg list) draft-eggert-tsvwg-rfc5405bis (adoption request soon) draft-geib-tsvwg-diffserv-intercon-02.txt (next version expected to be called for adoption) draft-welzl-ecn-benefits (please read) ------------------------------------------------------------------- WG Drafts with Chairs: draft-ietf-tsvwg-sctp-dtls-encaps - PS - Document Shepherd: Gorry Replaces: draft-tuexen-tsvwg-sctp-dtls-encaps-01 WG adopted 13/12/2013. Support {AB, IR, SL, MB, TD} [Milestone: Jan 2014, PS] Implemented in Firefox (FF21). Required by RTCweb. Comments received. WGLC ended 28th February 2014. Comments from Joe Touch (draft updated) Review comments and revised ID published. ++ Eric Rescorla has reviewed this. DUE: Security input needed to determine text describing DTLS version. DUE: WG Shepherd write-up to be prepared. --- draft-ietf-tsvwg-sctp-prpolicies - PS - Document Shepherd: Gorry Replaces: draft-tuexen-tsvwg-sctp-prpolicies Nov 2013, Adopted SCTP PR Polices intended for publication as a PS RFC March 2014, Next revision expected for WGLC. Gorry read 20-May-2014, needs to be PS, explain Info section in wrietup Revised ID May 2014. 1-Jul-2014 Gorry reviewed standards language WGLC started to end July 21st, 2014 - support JHS, KN, MB, IR, GF; comments from Karen Nielson, Brian Bidulock, Gorry DUE: Revised ID now needed after WGLC DUE: WG Shepherd write-up to be prepared - Gorry ------------------------------------------------------------------- WG Drafts --- draft-ietf-tsvwg-port-use - Document Shepherd: Gorry Replaces: draft-touch-tsvwg-port-use-00 - Intended to be advice to protocol designers needing a port. 5 people looked at this document, Prague IETF-80 Individual -01 July 2011 IETF-81 insufficient feedback from WG at this time. IETF-82, discussed. Adopted by WG Presented IETF-86, March 2013 Milestone updated to June 2014 Mar 2014, Chairs WGLC to be started after current WG actions. - IANA review comments received - Sent review requests to RAI, APPS, and SEC areas during 1st WGLC. + Comments May 2014: Paul Hoffman; Lars Eggert; IANA; David Black; 5 Jun 2014, WGLC completed - comments received. DUE: Revised ID needed. --- draft-ietf-tsvwg-rsvp-app-id-vv-profiles Replaces: draft-polk-tsvwg-rsvp-app-id-vv-profiles -01 Presented in Beijing, IETF-79. -02, 14-Mar-2011 Presented IETF-80. Seek to coordinate with music with partner ID: draft-polk-mmusic-traffic-class-for-sdp Gorry liaised with MMUSIC WG Chairs on companion draft (norm ref from this tsvwg draft). Adopted as a TSVWG work item, December 2013, [Milestone Jul 2013]. This will update a RFC 2872 (PS). Presented at IETF-86, Mar 2013 (no comments) Expected ready for WGLC (waiting on MMUSIC) DUE: Reviewers are needed to prepare for a WGLC --- draft-ietf-tsvwg-natsupp-tsvwg - Document Shepherd: James Replaces: draft-stewart-natsupp-tsvwg Dependency from BEHAVE WG. Adopted as a work item 21 Sept 2010 (Gorry). WG -00, 29/11/2010 Uploaded as: draft-ietf-natsupp-tsvwg Authors restructured draft (-03) Added support for single and multi-homed support. IETF-86: 3 people in meeting had read -04 or -05. Feb 2014, Authors please update following comments and align to related draft on SCTP NAT (conflicts found in language) Authors expected to produce a single document to replace both. ++ Dan Wing has committed to review this. ++ Fred Baker has committed to review this. Chairs: We plan to start a WGLC, but are expecting this document to be restructured and merged with draft-ietf-tsvwg-sctpnat --- draft-ietf-tsvwg-sctpnat - Document Shepherd: Gorry Replaces: draft-ietf-behave-sctpnat-03.txt Adopted Nov 2013. Former BEHAVE WG work item that defines SCTP NAT support Feb 2014, Authors please update following comments and align to related draft on SCTP NAT (conflicts found in language) Chairs: - authors have requested a single document to replace both. ++ Fred Baker will review next version. Separated the simpler case for single-homed use - this separation should be clearer Chairs: We plan to start a WGLC, but are expecting this document to be restructured and merged with draft-ietf-tsvwg-sctpnat --- draft-ietf-tsvwg-behave-requirements-update - Document Shepherd: David Replaces: draft-ietf-behave-requirements-update-00 Nov 2013, Former BEHAVE WG work item intended for publication as a BCP Mar 2014, Irene R reviewed this and found no conflict with SCTP drafts. Some suggestions (in no particular order) for a shepherd: ++ Dave Thaler, may review, as former behave co-chair ++ David Harrington, has been around in behave, and he knows how to do this and volunteered multiple times. ++ Ask Jana to review this. ++ Dan has committed to review this. Chairs: Check intention and planned timeline. DUE: Please comment on list --- draft-ietf-tsvwg-sctp-failover - Document Shepherd: James Replaces: draft-nishida-tsvwg-sctp-failover Individual-00 Presented in Prague, IETF-80. - Understood not to conflict with draft-tuexen-tsvwg-sctp-multipath - PF has been coded into FreeBSD Adopted by WG 26/6/2012. [Milestone: Jul 2013, EXP] DUE: March 2014. DUE: Please comment on list. --- draft-ietf-tsvwg-sctp-ndata - PS - replaces: draft-stewart-tsvwg-sctp-ndata-03 Nov 2013, Adopted , intended for publication as a PS RFC Mar 2014, 5-6 people had read. DUE: Revised ID needed. --- draft-tsvwg-gre-in-udp-encap - PS Document Shepherd: David - replaces: draft-yong-tsvwg-gre-in-udp-encap Dec 2013, Adopted , intended for publication as a PS RFC Feb 2014, discussion of scope and applicability of circuit breakers Mar 2014 consider MUST implement, SHOULD use in these environments for CB DUE: Revised ID needed, waiting on RTG AD text inclusion with draft-ietf-mpls-in-udp draft that will also be used in this draft. --- draft-ietf-tsvwg-rtcweb-qos - PS - Document Shepherd: David - Replaces: draft-dhesikan-tsvwg-rtcweb-qos - RTCweb and QoS Markings - Authors requested TSVWG adoption. - Who has read the draft? (lots 10's of people) 25-Mar-2014, Adopted by tsvwg - Who thinks it is important to do work in the IETF? (Many) I-D updated after initial TSVWG feedback Mar 2014, Adoption call (strong support in WG meeting London) Adoption call concluded 24 Match 2014: intended as a PS RFC for Sept 2014 ++ Magnus agreed to review this. Mar 2014, Please subscribe to "DART" for other related discussions. Aug 2014, DART draft (draft-ietf-dart-dscp-rtp) is now in WGLC; that draft needs to be completed before we can WGLC this rtcweb-qos draft. DUE: Please comment on list, see IETF DART WG. --- draft-ietf-tsvwg-ecn-encap-guidelines - Document Contact: Gorry replaced draft-briscoe-tsvwg-ecn-encap-guidelines -00 Presented in Prague, IETF-80. - comments at IETF-80 (see minutes) New ID presented in Atlanta, IETF-85. ID presented in IETF-88,89 ++ forward an appropriate message (perhaps your note to the mailing list for approval to adopt) to ieee-ietf-coord@ietf.org) ++ Reviewers: Andrew McGregor, Dirk Kutscher, Richard Scheffnegger, Brian Tramwell. Mar 2014, WG Call for adoption started, to end 4th March 2014 19 for, 1 against. 8 echoed on the list Adoption call concluded and document adopted. * ecn-encap-guidelines and AQM are the main new things they need to know about. on IEEE802.1Q) DUE: Please comment on list. ------------------------------------------------------------------- Expired WG documents: draft-ietf-tsvwg-intserv-multiple-tspec - Document Shepherd: David WG interest in this topic recorded at IETF-78. Charter update needed to progress this work. 5 Reviews needed to determine energy/technical direction. WG -05 (presented in Beijing, IETF-79) WG -06 (presented in Prague, IETF-80) 2 reviews from RSVP-DIR received (Bruce Davie, ?) 2 additional reviews promised (Ken Carlberg, Francois LeF) Chairs asked AD for a Charter update (IESG agreed) Draft discussed at IETF-80, and request to update charter agreed - AD advised 4 named reviewers will be required Adopted for progression as PS, for May 2012 - New name: 'RSVP Multiple Instance'. Draft is now expired and dead. DUE: Draft authors will request replacement with draft-polk-rsvp-multi-instance-object (and WG adoption of that draft in Honolulu, IETF-91) ------------------------------------------------------------------- The following have received recent discussion at TSVWG meetings or on the list. Inclusion in the list below does not indicate support for these specific drafts and other contributions are also warmly welcomed. --------------------------------------------------------------- Authors request to be considered for adoption: --- draft-geib-tsvwg-diffserv-intercon-02.txt - Document Contact: David DiffServ interconnection classes New ID presented in Atlanta, IETF-85. ID presented in Orlando, IETF-86, Mar 2013. Mar 2014, intended scope unclear at IETF London Adoption call to be considered, but scope needs to be first refined and a revised draft is necessary to avoid implications of broader applicability. July 2014 - ID presented in Toronto. Strong hum of support to work on this, but a revised draft is needed first. DUE: revised draft required, WG adoption call expected on that next version. --- draft-eggert-tsvwg-rfc5405bis - Individual (Gorry & Lars) Mar 2014, the ADs proposed the WG re-open the UDP Guidelines RFC for update to include this work and other topics. NOTE: Update milestone in charter, if adopted: ‘Multicast UDP Guidelines’ is being incorporated in this. Presented IETF-90, Hum supporting adoption, none against. ++ Brian Tramwell and Jana agreed to review this. Chairs:Adoption call to be started on list. --- draft-fairhurst-tsvwg-circuit-breaker - Individual (Gorry Fairhurst) Call for WG adoption issued - August 2014 DUE: Please comment on list --- draft-wing-tsvwg-turn-flowdata-00.txt - Individual (no decision to adopt at this time) - QoS-aspects to be discussed in tsvwg (thought to also be relevant to TURN WG) ---- draft-welzl-ecn-benefits - Individual (Michael Welzl) - Thought to be within tsvwg or aqm WGs, to be proposed as a work item in AQM. +++ END OF LIST +++ From nobody Mon Aug 11 13:13:09 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E8CB1A0004; Mon, 11 Aug 2014 13:13:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1 X-Spam-Level: X-Spam-Status: No, score=-1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mToK_Zrb7Trc; Mon, 11 Aug 2014 13:13:05 -0700 (PDT) Received: from mail-pa0-x232.google.com (mail-pa0-x232.google.com [IPv6:2607:f8b0:400e:c03::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E54A91A0002; Mon, 11 Aug 2014 13:13:04 -0700 (PDT) Received: by mail-pa0-f50.google.com with SMTP id et14so11510119pad.23 for ; Mon, 11 Aug 2014 13:13:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=m1e5pZ4q/VR2MWt66JLLjGGm8LAxjhTXV3DCiYfFKuU=; b=Ur2N9LXBgn3f/kvVM+wfE02+PW328N+0sDBVBubTFcgf7kFMXlD1u43EN43wl9R1Yl AktYDmcy5NNvpoTLVL/+P4b4vPnvq/BXIj5/e6Hhqp2iQN5GzmIo5IjajPzjybprIEw9 7kYsyXZI5aHa4E17z2cIFgcUWVDzGPtfWEuk3BFBjWGw/nmZ2n6xSlewJ6E7jKTwnvMc Lrjxe/RlJYopQ1rMUkjbiWD5Vtr6K+cavMnjTEq8COBzP8Vo23ILrJ2Ai6o2YnL/J9++ U99XPgenmp8W0X4PFkZRhcRD1OAyyiHBY5+pqCGu8v0dm0EcHsmJOYcI73SuC02d0pSe ps8Q== X-Received: by 10.66.122.175 with SMTP id lt15mr27061pab.77.1407787984588; Mon, 11 Aug 2014 13:13:04 -0700 (PDT) Received: from [192.168.178.23] (110.199.69.111.dynamic.snap.net.nz. [111.69.199.110]) by mx.google.com with ESMTPSA id rv10sm8642126pbc.5.2014.08.11.13.13.02 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 11 Aug 2014 13:13:03 -0700 (PDT) Message-ID: <53E923CE.1000803@gmail.com> Date: Tue, 12 Aug 2014 08:13:02 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Ruediger.Geib@telekom.de References: In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/2kgQGeQlTOrF8v934nc6-4UsVPc Cc: dart@ietf.org, tsvwg@ietf.org Subject: Re: [tsvwg] [Dart] WGLC: draft-ietf-dart-dscp-rtp-02 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Aug 2014 20:13:06 -0000 Hi Ruediger, On 11/08/2014 22:21, Ruediger.Geib@telekom.de wrote: > Hi David, >=20 > new EF related text has been added in the -01 version. I've copied=20 > in some text of RFC3246 related to EF remarking and policing below.=20 > My take: >=20 > . remarking of entire flows is an option, but no remarking of=20 > packets exceeding EF capacity limits. > - looking at the EF jitter and delay properties, I doubt that=20 > shaping is desirable. RFC3246 doesn't mention shaping as part=20 > of EF conditioning. I personally wouldn't expect EF shaping=20 > in sections where policing is applied.=20 > - dropping of packets exceeding EF capacity is a MUST, if I=20 > interpret RFC3246 correctly. Well, it seems to me to be a SHOULD, with the MUST that you cite below being conditional on "a mechanism that allows unlimited preemption of other traffic." So I would not be at all surprised by deployments that support shaping and remarking. Also, there are certainly implementations that are closer to RFC 2598 or RFC 3248 and therefore less strict. I think the draft should make it clear that there is likely to be variation in actual behaviour for EF traffic that exceeds the nominal rate. (Leaving aside the fact that without a string of matching SLAs along the path, the nominal rate might not even be well defined.) Brian >=20 > I suggest to adapt the section of draft-dart-dscp to be more=20 > precise regarding the optional remarking of EF traffic and to=20 > remove shaping as a conditioning option if traffic is beyond=20 > the EF forwarding capacity limit. A Proposal for the final=20 > sentence: >=20 > ...exceeds that capacity must be dropped. EF compliant flows may=20 > be remarked to a different DSCP. >=20 > All other new text indicated by the Diff version looks allright. >=20 > Regards, >=20 > Ruediger >=20 >=20 >=20 > draft-dart-dscp: >=20 > 3. Expedited Forwarding (EF) [RFC3246] intended for inelastic=09 > traffic. Beyond the basic EF PHB, the VOICE-ADMIT PHB [RFC5865]=09 > is an admission controlled variant of the EF PHB. Both of these=09 > PHBs are based on pre-configured limited forwarding capacity;=09 > traffic that exceeds that capacity may be shaped, remarked to a=09 > different DSCP, or dropped. >=20 > ######################################## >=20 > RFC3246 (three excerpts): >=20 > Packets belonging to a single microflow within the EF aggregate > passing through a device SHOULD NOT experience re-ordering in normal= > operation of the device. >=20 > Packets marked for EF PHB MAY be remarked at a DS domain boundary > only to other codepoints that satisfy the EF PHB. Packets marked fo= r > EF PHBs SHOULD NOT be demoted or promoted to another PHB by a DS > domain. >=20 > If the EF PHB is implemented by a mechanism that allows unlimited > preemption of other traffic (e.g., a priority queue), the > implementation MUST include some means to limit the damage EF traffi= c > could inflict on other traffic (e.g., a token bucket rate limiter). > Traffic that exceeds this limit MUST be discarded. >=20 >=20 >=20 >=20 >=20 > -----Urspr=C3=BCngliche Nachricht----- > Von: Dart [mailto:dart-bounces@ietf.org] Im Auftrag von Ben Campbell > Gesendet: Samstag, 9. August 2014 19:50 > An: dart@ietf.org > Cc: Richard Barnes; draft-ietf-dart-dscp-rtp.all@tools.ietf.org; mls.ie= tf@gmail.com > Betreff: [Dart] WGLC: draft-ietf-dart-dscp-rtp-02 >=20 > This is a DART Working Group Last Call of draft-ietf-dart-dscp-rtp-02. = It's available on the data tracker at the following URL: >=20 > https://datatracker.ietf.org/doc/draft-ietf-dart-dscp-rtp/ >=20 > The WGLC will conclude on 22 August, 2014. Please send your comments to= the authors and the DART mailing list. If you've reviewed it and think i= t's good to go, please say so. >=20 > Thanks! >=20 > Ben. >=20 > _______________________________________________ > Dart mailing list > Dart@ietf.org > https://www.ietf.org/mailman/listinfo/dart >=20 > _______________________________________________ > Dart mailing list > Dart@ietf.org > https://www.ietf.org/mailman/listinfo/dart > . >=20 From nobody Tue Aug 12 00:38:37 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FDB91A0772; Tue, 12 Aug 2014 00:38:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.218 X-Spam-Level: X-Spam-Status: No, score=-2.218 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, MANGLED_BEEF=2.3, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2IAInZo2BQ9q; Tue, 12 Aug 2014 00:38:31 -0700 (PDT) Received: from tcmail13.telekom.de (tcmail13.telekom.de [80.149.113.165]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A047A1A0771; Tue, 12 Aug 2014 00:38:30 -0700 (PDT) Received: from qdezc2.de.t-internal.com ([10.125.181.10]) by tcmail11.telekom.de with ESMTP; 12 Aug 2014 09:38:28 +0200 X-IronPort-AV: E=Sophos;i="5.01,847,1400018400"; d="scan'208";a="118910454" Received: from he113675.emea1.cds.t-internal.com ([10.134.99.28]) by qde0ps.de.t-internal.com with ESMTP/TLS/AES128-SHA; 12 Aug 2014 09:38:27 +0200 Received: from HE111643.EMEA1.CDS.T-INTERNAL.COM ([10.134.93.12]) by HE113675.emea1.cds.t-internal.com ([::1]) with mapi; Tue, 12 Aug 2014 09:38:27 +0200 From: To: Date: Tue, 12 Aug 2014 09:38:26 +0200 Thread-Topic: [Dart] WGLC: draft-ietf-dart-dscp-rtp-02 Thread-Index: Ac+1oKteIQhICmhbQ1SA6rD/HaR1EAAVuKCg Message-ID: References: <53E923CE.1000803@gmail.com> In-Reply-To: <53E923CE.1000803@gmail.com> Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/qgDBNvgLIA9-2QCkH6NtGNZ7nnE Cc: dart@ietf.org, tsvwg@ietf.org Subject: Re: [tsvwg] [Dart] WGLC: draft-ietf-dart-dscp-rtp-02 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Aug 2014 07:38:33 -0000 SGkgQnJpYW4sDQoNCndpdGggRUYgSSBsaW5rIGFuIGV4cGVjdGF0aW9uIG9mIGV4Y2VzcyB0cmFm ZmljIGJlaW5nIA0KZHJvcHBlZC4NCg0KQSByYXRlIHNjaGVkdWxlciB3aXRoIHNpbmdsZSBkaWdp dCBtaWxsaXNlY29uZCBidWZmZXIgDQpkZXB0aCBhbmQgdGFpbCBkcm9wIGxpa2UgYmVoYXZpb3Ig aXMgbm90IGFuIGlzc3VlLiANClRvIG1lLCB0aGF0J3MgYSBzaGFwZXIgY29uZmlndXJlZCB0byBi ZSBFRiBjb21wbGlhbnQuIA0KSWYgc3VjaCBhIGNvbnN0cmFpbnQgaXMgbm90IGRlc2lyZWQgdGhl biB0aGUgdGV4dCANCm1heSBzYXkgImlmIG1hcHBlZCB0byBhIG5vbi1FRiBQSEIsIGV4Y2VzcyB0 cmFmZmljIA0KbWF5IGJlIHNoYXBlZCIuIEknZCBsaWtlIHRvIGFzayBmb3Igc29tZSBleHBsYWlu aW5nIA0KdGV4dCBpZiBzaGFwaW5nIG9mIEVGIGV4Y2VzcyB0cmFmZmljIGlzIHJlZ2FyZGVkIA0K YXMgYSBwcm9wZXJ0eSB0byBiZSBleHBlY3RlZCBmb3IgdGhpcyBQSEIuDQoNCklmIGFuIEFGIGNs YXNzIGlzIHVzZWQgdG8gdHJhbnNwb3J0IEVGLCB0aGVuIGFueSBwb3RlbnRpYWwgDQpyZW1hcmtp bmcgc2hvdWxkIGJlIGRvbmUgaW4gYSB3YXkgYXZvaWRpbmcgcmUtb3JkZXJpbmcgDQooaS5lLiBy ZW1hcmsgdG8gRFNDUHMgd2l0aGluIHRoZSBzYW1lIEFGIGNsYXNzIG9ubHkpLiANClRoZXJlJ3Mg bm8gcG9pbnQgaW4gcmVtYXJraW5nIGV4Y2VzcyBFRiB0cmFmZmljIHRvIGEgUEhCIA0Kd2hpY2gg bWF5IGNhdXNlIHJlb3JkZXJpbmcuIEkgdGhpbmsgdGhhdCdzIHdoYXQgYSB0ZXh0IA0Kb24gcmVt YXJraW5nIG9mIEVGIHNob3VsZCBleHByZXNzLCBpZiByZW1hcmtpbmcgaXMgDQprZXB0IGFzIGFu IG9wdGlvbiB0byBiZSBleHBlY3RlZCAoSSd2ZSBub3QgeWV0IGhlYXJkIG9mIA0Kc3VjaCBhIGRl cGxveW1lbnQpLg0KDQpSZWdhcmRzLA0KDQpSdWVkaWdlcg0KDQoNCi0tLS0tVXJzcHLDvG5nbGlj aGUgTmFjaHJpY2h0LS0tLS0NClZvbjogQnJpYW4gRSBDYXJwZW50ZXIgW21haWx0bzpicmlhbi5l LmNhcnBlbnRlckBnbWFpbC5jb21dIA0KR2VzZW5kZXQ6IE1vbnRhZywgMTEuIEF1Z3VzdCAyMDE0 IDIyOjEzDQpBbjogR2VpYiwgUsO8ZGlnZXINCkNjOiBkYXZpZC5ibGFja0BlbWMuY29tOyBkYXJ0 QGlldGYub3JnOyB0c3Z3Z0BpZXRmLm9yZw0KQmV0cmVmZjogUmU6IFtEYXJ0XSBXR0xDOiBkcmFm dC1pZXRmLWRhcnQtZHNjcC1ydHAtMDINCg0KSGkgUnVlZGlnZXIsDQoNCk9uIDExLzA4LzIwMTQg MjI6MjEsIFJ1ZWRpZ2VyLkdlaWJAdGVsZWtvbS5kZSB3cm90ZToNCj4gSGkgRGF2aWQsDQo+IA0K PiBuZXcgRUYgcmVsYXRlZCB0ZXh0IGhhcyBiZWVuIGFkZGVkIGluIHRoZSAtMDEgdmVyc2lvbi4g SSd2ZSBjb3BpZWQgaW4gDQo+IHNvbWUgdGV4dCBvZiBSRkMzMjQ2IHJlbGF0ZWQgdG8gRUYgcmVt YXJraW5nIGFuZCBwb2xpY2luZyBiZWxvdy4NCj4gTXkgdGFrZToNCj4gDQo+IC4gcmVtYXJraW5n IG9mIGVudGlyZSBmbG93cyBpcyBhbiBvcHRpb24sIGJ1dCBubyByZW1hcmtpbmcgb2YgDQo+ICAg cGFja2V0cyBleGNlZWRpbmcgRUYgY2FwYWNpdHkgbGltaXRzLg0KPiAtIGxvb2tpbmcgYXQgdGhl IEVGIGppdHRlciBhbmQgZGVsYXkgcHJvcGVydGllcywgSSBkb3VidCB0aGF0IA0KPiAgIHNoYXBp bmcgaXMgZGVzaXJhYmxlLiBSRkMzMjQ2IGRvZXNuJ3QgbWVudGlvbiBzaGFwaW5nIGFzIHBhcnQg DQo+ICAgb2YgRUYgY29uZGl0aW9uaW5nLiBJIHBlcnNvbmFsbHkgd291bGRuJ3QgZXhwZWN0IEVG IHNoYXBpbmcgDQo+ICAgaW4gc2VjdGlvbnMgd2hlcmUgcG9saWNpbmcgaXMgYXBwbGllZC4gDQo+ IC0gZHJvcHBpbmcgb2YgcGFja2V0cyBleGNlZWRpbmcgRUYgY2FwYWNpdHkgaXMgYSBNVVNULCBp ZiBJIA0KPiAgIGludGVycHJldCBSRkMzMjQ2IGNvcnJlY3RseS4NCg0KV2VsbCwgaXQgc2VlbXMg dG8gbWUgdG8gYmUgYSBTSE9VTEQsIHdpdGggdGhlIE1VU1QgdGhhdCB5b3UgY2l0ZSBiZWxvdyBi ZWluZyBjb25kaXRpb25hbCBvbiAiYSBtZWNoYW5pc20gdGhhdCBhbGxvd3MgdW5saW1pdGVkIHBy ZWVtcHRpb24gb2Ygb3RoZXIgdHJhZmZpYy4iIFNvIEkgd291bGQgbm90IGJlIGF0IGFsbCBzdXJw cmlzZWQgYnkgZGVwbG95bWVudHMgdGhhdCBzdXBwb3J0IHNoYXBpbmcgYW5kIHJlbWFya2luZy4g QWxzbywgdGhlcmUgYXJlIGNlcnRhaW5seSBpbXBsZW1lbnRhdGlvbnMgdGhhdCBhcmUgY2xvc2Vy IHRvIFJGQyAyNTk4IG9yIFJGQyAzMjQ4IGFuZCB0aGVyZWZvcmUgbGVzcyBzdHJpY3QuDQoNCkkg dGhpbmsgdGhlIGRyYWZ0IHNob3VsZCBtYWtlIGl0IGNsZWFyIHRoYXQgdGhlcmUgaXMgbGlrZWx5 IHRvIGJlIHZhcmlhdGlvbiBpbiBhY3R1YWwgYmVoYXZpb3VyIGZvciBFRiB0cmFmZmljIHRoYXQg ZXhjZWVkcyB0aGUgbm9taW5hbCByYXRlLiAoTGVhdmluZyBhc2lkZSB0aGUgZmFjdCB0aGF0IHdp dGhvdXQgYSBzdHJpbmcgb2YgbWF0Y2hpbmcgU0xBcyBhbG9uZyB0aGUgcGF0aCwgdGhlIG5vbWlu YWwgcmF0ZSBtaWdodCBub3QgZXZlbiBiZSB3ZWxsIGRlZmluZWQuKQ0KDQogICBCcmlhbg0KDQo+ IA0KPiBJIHN1Z2dlc3QgdG8gYWRhcHQgdGhlIHNlY3Rpb24gb2YgZHJhZnQtZGFydC1kc2NwIHRv IGJlIG1vcmUgcHJlY2lzZSANCj4gcmVnYXJkaW5nIHRoZSBvcHRpb25hbCByZW1hcmtpbmcgb2Yg RUYgdHJhZmZpYyBhbmQgdG8gcmVtb3ZlIHNoYXBpbmcgDQo+IGFzIGEgY29uZGl0aW9uaW5nIG9w dGlvbiBpZiB0cmFmZmljIGlzIGJleW9uZCB0aGUgRUYgZm9yd2FyZGluZyANCj4gY2FwYWNpdHkg bGltaXQuIEEgUHJvcG9zYWwgZm9yIHRoZSBmaW5hbA0KPiBzZW50ZW5jZToNCj4gDQo+IC4uLmV4 Y2VlZHMgdGhhdCBjYXBhY2l0eSBtdXN0IGJlIGRyb3BwZWQuIEVGIGNvbXBsaWFudCBmbG93cyBt YXkgYmUgDQo+IHJlbWFya2VkIHRvIGEgZGlmZmVyZW50IERTQ1AuDQo+IA0KPiBBbGwgb3RoZXIg bmV3IHRleHQgaW5kaWNhdGVkIGJ5IHRoZSBEaWZmIHZlcnNpb24gbG9va3MgYWxscmlnaHQuDQo+ IA0KPiBSZWdhcmRzLA0KPiANCj4gUnVlZGlnZXINCj4gDQo+IA0KPiANCj4gZHJhZnQtZGFydC1k c2NwOg0KPiANCj4gMy4gRXhwZWRpdGVkIEZvcndhcmRpbmcgKEVGKSBbUkZDMzI0Nl0gaW50ZW5k ZWQgZm9yIGluZWxhc3RpYwkNCj4gICAgdHJhZmZpYy4gQmV5b25kIHRoZSBiYXNpYyBFRiBQSEIs IHRoZSBWT0lDRS1BRE1JVCBQSEIgW1JGQzU4NjVdCQ0KPiAgICBpcyBhbiBhZG1pc3Npb24gY29u dHJvbGxlZCB2YXJpYW50IG9mIHRoZSBFRiBQSEIuIEJvdGggb2YgdGhlc2UJDQo+ICAgIFBIQnMg YXJlIGJhc2VkIG9uIHByZS1jb25maWd1cmVkIGxpbWl0ZWQgZm9yd2FyZGluZyBjYXBhY2l0eTsJ DQo+ICAgIHRyYWZmaWMgdGhhdCBleGNlZWRzIHRoYXQgY2FwYWNpdHkgbWF5IGJlIHNoYXBlZCwg cmVtYXJrZWQgdG8gYQkNCj4gICAgZGlmZmVyZW50IERTQ1AsIG9yIGRyb3BwZWQuDQo+IA0KPiAj IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjDQo+IA0KPiBSRkMzMjQ2ICh0 aHJlZSBleGNlcnB0cyk6DQo+IA0KPiAgICBQYWNrZXRzIGJlbG9uZ2luZyB0byBhIHNpbmdsZSBt aWNyb2Zsb3cgd2l0aGluIHRoZSBFRiBhZ2dyZWdhdGUNCj4gICAgcGFzc2luZyB0aHJvdWdoIGEg ZGV2aWNlIFNIT1VMRCBOT1QgZXhwZXJpZW5jZSByZS1vcmRlcmluZyBpbiBub3JtYWwNCj4gICAg b3BlcmF0aW9uIG9mIHRoZSBkZXZpY2UuDQo+IA0KPiAgICBQYWNrZXRzIG1hcmtlZCBmb3IgRUYg UEhCIE1BWSBiZSByZW1hcmtlZCBhdCBhIERTIGRvbWFpbiBib3VuZGFyeQ0KPiAgICBvbmx5IHRv IG90aGVyIGNvZGVwb2ludHMgdGhhdCBzYXRpc2Z5IHRoZSBFRiBQSEIuICBQYWNrZXRzIG1hcmtl ZCBmb3INCj4gICAgRUYgUEhCcyBTSE9VTEQgTk9UIGJlIGRlbW90ZWQgb3IgcHJvbW90ZWQgdG8g YW5vdGhlciBQSEIgYnkgYSBEUw0KPiAgICBkb21haW4uDQo+IA0KPiAgICBJZiB0aGUgRUYgUEhC IGlzIGltcGxlbWVudGVkIGJ5IGEgbWVjaGFuaXNtIHRoYXQgYWxsb3dzIHVubGltaXRlZA0KPiAg ICBwcmVlbXB0aW9uIG9mIG90aGVyIHRyYWZmaWMgKGUuZy4sIGEgcHJpb3JpdHkgcXVldWUpLCB0 aGUNCj4gICAgaW1wbGVtZW50YXRpb24gTVVTVCBpbmNsdWRlIHNvbWUgbWVhbnMgdG8gbGltaXQg dGhlIGRhbWFnZSBFRiB0cmFmZmljDQo+ICAgIGNvdWxkIGluZmxpY3Qgb24gb3RoZXIgdHJhZmZp YyAoZS5nLiwgYSB0b2tlbiBidWNrZXQgcmF0ZSBsaW1pdGVyKS4NCj4gICAgVHJhZmZpYyB0aGF0 IGV4Y2VlZHMgdGhpcyBsaW1pdCBNVVNUIGJlIGRpc2NhcmRlZC4NCj4gDQo+IA0KPiANCj4gDQo+ IA0KPiAtLS0tLVVyc3Byw7xuZ2xpY2hlIE5hY2hyaWNodC0tLS0tDQo+IFZvbjogRGFydCBbbWFp bHRvOmRhcnQtYm91bmNlc0BpZXRmLm9yZ10gSW0gQXVmdHJhZyB2b24gQmVuIENhbXBiZWxsDQo+ IEdlc2VuZGV0OiBTYW1zdGFnLCA5LiBBdWd1c3QgMjAxNCAxOTo1MA0KPiBBbjogZGFydEBpZXRm Lm9yZw0KPiBDYzogUmljaGFyZCBCYXJuZXM7IGRyYWZ0LWlldGYtZGFydC1kc2NwLXJ0cC5hbGxA dG9vbHMuaWV0Zi5vcmc7IA0KPiBtbHMuaWV0ZkBnbWFpbC5jb20NCj4gQmV0cmVmZjogW0RhcnRd IFdHTEM6IGRyYWZ0LWlldGYtZGFydC1kc2NwLXJ0cC0wMg0KPiANCj4gVGhpcyBpcyBhIERBUlQg V29ya2luZyBHcm91cCBMYXN0IENhbGwgb2YgZHJhZnQtaWV0Zi1kYXJ0LWRzY3AtcnRwLTAyLiBJ dCdzIGF2YWlsYWJsZSBvbiB0aGUgZGF0YSB0cmFja2VyIGF0IHRoZSBmb2xsb3dpbmcgVVJMOg0K PiANCj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1kYXJ0LWRz Y3AtcnRwLw0KPiANCj4gVGhlIFdHTEMgd2lsbCBjb25jbHVkZSBvbiAyMiBBdWd1c3QsIDIwMTQu IFBsZWFzZSBzZW5kIHlvdXIgY29tbWVudHMgdG8gdGhlIGF1dGhvcnMgYW5kIHRoZSBEQVJUIG1h aWxpbmcgbGlzdC4gSWYgeW91J3ZlIHJldmlld2VkIGl0IGFuZCB0aGluayBpdCdzIGdvb2QgdG8g Z28sIHBsZWFzZSBzYXkgc28uDQo+IA0KPiBUaGFua3MhDQo+IA0KPiBCZW4uDQo+IA0KPiBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBEYXJ0IG1haWxp bmcgbGlzdA0KPiBEYXJ0QGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vZGFydA0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCj4gRGFydCBtYWlsaW5nIGxpc3QNCj4gRGFydEBpZXRmLm9yZw0KPiBodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RhcnQNCj4gLg0KPiANCg0K From nobody Tue Aug 12 13:35:24 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47B041A0009; Tue, 12 Aug 2014 13:35:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.3 X-Spam-Level: X-Spam-Status: No, score=0.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MANGLED_BEEF=2.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aafDgaDZJhjg; Tue, 12 Aug 2014 13:35:15 -0700 (PDT) Received: from mail-pa0-x229.google.com (mail-pa0-x229.google.com [IPv6:2607:f8b0:400e:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94E051A0005; Tue, 12 Aug 2014 13:35:15 -0700 (PDT) Received: by mail-pa0-f41.google.com with SMTP id rd3so13655701pab.28 for ; Tue, 12 Aug 2014 13:35:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=ZzAqtJwtG2OYu0b2l4XLO9uvXuseLXSHge7+UuboxQ8=; b=pTtTgA80aE3TmJUNgCLIXZxlzNhDg7RBbYfEEd/tqmgaGsOqSnroTLWdag2u4IZmsM h9OYx5hVx94RElxC6X/jFfkl1e/vOno61PPoDfjcvFMf4nhkR4ATDJx9lkjd07YHV546 RRDV7BEkg6OlW3MOSxrTmAezQl5efGeXnRRw9nPCAkAedmnsKQmYjYQUWANVmMvL3kNC R4lpag4pcVIc4h41R+uvyaooexT2FiaOcXSDrcTfYo14DrweuEz/KFblcVJkeYGVCt+3 UsjhNo3GOiIITPbm4/qO95VhMvu3Pk74dGcyT/iqE6PxeKM4itEjVQVwNPpVGUy+JIpP 3Ncw== X-Received: by 10.68.139.162 with SMTP id qz2mr3423309pbb.153.1407875714300; Tue, 12 Aug 2014 13:35:14 -0700 (PDT) Received: from [192.168.178.23] (19.198.69.111.dynamic.snap.net.nz. [111.69.198.19]) by mx.google.com with ESMTPSA id am3sm15499652pbd.18.2014.08.12.13.35.10 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 12 Aug 2014 13:35:13 -0700 (PDT) Message-ID: <53EA7A80.6010800@gmail.com> Date: Wed, 13 Aug 2014 08:35:12 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Ruediger.Geib@telekom.de References: <53E923CE.1000803@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/eAfzhCjkiUKjWgXft883TqPD1wo Cc: dart@ietf.org, tsvwg@ietf.org Subject: Re: [tsvwg] [Dart] WGLC: draft-ietf-dart-dscp-rtp-02 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Aug 2014 20:35:20 -0000 Hi Ruediger, On 12/08/2014 19:38, Ruediger.Geib@telekom.de wrote: > Hi Brian, >=20 > with EF I link an expectation of excess traffic being=20 > dropped. In general I agree; but that only makes sense if there is an agreement (or mechanism) to define the nominal rate, and rate control of some kind at the source. (An IP phone is in effect a rate controller, for example.) >=20 > A rate scheduler with single digit millisecond buffer=20 > depth and tail drop like behavior is not an issue.=20 > To me, that's a shaper configured to be EF compliant.=20 > If such a constraint is not desired then the text=20 > may say "if mapped to a non-EF PHB, excess traffic=20 > may be shaped". I'd like to ask for some explaining=20 > text if shaping of EF excess traffic is regarded=20 > as a property to be expected for this PHB. Yes, technically that's correct - but a shaper could be inserted at the boundary between two DS domains, and for the end-to-end user that will appear as a property of the PHB. > If an AF class is used to transport EF, then any potential=20 > remarking should be done in a way avoiding re-ordering=20 > (i.e. remark to DSCPs within the same AF class only).=20 > There's no point in remarking excess EF traffic to a PHB=20 > which may cause reordering.=20 I fully agree. > I think that's what a text=20 > on remarking of EF should express, if remarking is=20 > kept as an option to be expected (I've not yet heard of=20 > such a deployment). Yes. I'm not advocating such behaviour; my point is only that EF may not always be strictly conformant to RFC 3246. Brian > Regards, >=20 > Ruediger >=20 >=20 > -----Urspr=C3=BCngliche Nachricht----- > Von: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com]=20 > Gesendet: Montag, 11. August 2014 22:13 > An: Geib, R=C3=BCdiger > Cc: david.black@emc.com; dart@ietf.org; tsvwg@ietf.org > Betreff: Re: [Dart] WGLC: draft-ietf-dart-dscp-rtp-02 >=20 > Hi Ruediger, >=20 > On 11/08/2014 22:21, Ruediger.Geib@telekom.de wrote: >> Hi David, >> >> new EF related text has been added in the -01 version. I've copied in = >> some text of RFC3246 related to EF remarking and policing below. >> My take: >> >> . remarking of entire flows is an option, but no remarking of=20 >> packets exceeding EF capacity limits. >> - looking at the EF jitter and delay properties, I doubt that=20 >> shaping is desirable. RFC3246 doesn't mention shaping as part=20 >> of EF conditioning. I personally wouldn't expect EF shaping=20 >> in sections where policing is applied.=20 >> - dropping of packets exceeding EF capacity is a MUST, if I=20 >> interpret RFC3246 correctly. >=20 > Well, it seems to me to be a SHOULD, with the MUST that you cite below = being conditional on "a mechanism that allows unlimited preemption of oth= er traffic." So I would not be at all surprised by deployments that suppo= rt shaping and remarking. Also, there are certainly implementations that = are closer to RFC 2598 or RFC 3248 and therefore less strict. >=20 > I think the draft should make it clear that there is likely to be varia= tion in actual behaviour for EF traffic that exceeds the nominal rate. (L= eaving aside the fact that without a string of matching SLAs along the pa= th, the nominal rate might not even be well defined.) >=20 > Brian >=20 >> I suggest to adapt the section of draft-dart-dscp to be more precise=20 >> regarding the optional remarking of EF traffic and to remove shaping=20 >> as a conditioning option if traffic is beyond the EF forwarding=20 >> capacity limit. A Proposal for the final >> sentence: >> >> ...exceeds that capacity must be dropped. EF compliant flows may be=20 >> remarked to a different DSCP. >> >> All other new text indicated by the Diff version looks allright. >> >> Regards, >> >> Ruediger >> >> >> >> draft-dart-dscp: >> >> 3. Expedited Forwarding (EF) [RFC3246] intended for inelastic=09 >> traffic. Beyond the basic EF PHB, the VOICE-ADMIT PHB [RFC5865]=09 >> is an admission controlled variant of the EF PHB. Both of these=09 >> PHBs are based on pre-configured limited forwarding capacity;=09 >> traffic that exceeds that capacity may be shaped, remarked to a=09 >> different DSCP, or dropped. >> >> ######################################## >> >> RFC3246 (three excerpts): >> >> Packets belonging to a single microflow within the EF aggregate >> passing through a device SHOULD NOT experience re-ordering in norma= l >> operation of the device. >> >> Packets marked for EF PHB MAY be remarked at a DS domain boundary >> only to other codepoints that satisfy the EF PHB. Packets marked f= or >> EF PHBs SHOULD NOT be demoted or promoted to another PHB by a DS >> domain. >> >> If the EF PHB is implemented by a mechanism that allows unlimited >> preemption of other traffic (e.g., a priority queue), the >> implementation MUST include some means to limit the damage EF traff= ic >> could inflict on other traffic (e.g., a token bucket rate limiter).= >> Traffic that exceeds this limit MUST be discarded. >> >> >> >> >> >> -----Urspr=C3=BCngliche Nachricht----- >> Von: Dart [mailto:dart-bounces@ietf.org] Im Auftrag von Ben Campbell >> Gesendet: Samstag, 9. August 2014 19:50 >> An: dart@ietf.org >> Cc: Richard Barnes; draft-ietf-dart-dscp-rtp.all@tools.ietf.org;=20 >> mls.ietf@gmail.com >> Betreff: [Dart] WGLC: draft-ietf-dart-dscp-rtp-02 >> >> This is a DART Working Group Last Call of draft-ietf-dart-dscp-rtp-02.= It's available on the data tracker at the following URL: >> >> https://datatracker.ietf.org/doc/draft-ietf-dart-dscp-rtp/ >> >> The WGLC will conclude on 22 August, 2014. Please send your comments t= o the authors and the DART mailing list. If you've reviewed it and think = it's good to go, please say so. >> >> Thanks! >> >> Ben. >> >> _______________________________________________ >> Dart mailing list >> Dart@ietf.org >> https://www.ietf.org/mailman/listinfo/dart >> >> _______________________________________________ >> Dart mailing list >> Dart@ietf.org >> https://www.ietf.org/mailman/listinfo/dart >> . >> >=20 From nobody Tue Aug 12 15:38:21 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00B1E1A0A82; Tue, 12 Aug 2014 15:38:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 39tDKRlVThSP; Tue, 12 Aug 2014 15:38:10 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B32981A0A77; Tue, 12 Aug 2014 15:38:10 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p5 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20140812223810.18961.10501.idtracker@ietfa.amsl.com> Date: Tue, 12 Aug 2014 15:38:10 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/G9_ViD_OA_Zmd85nCtfPkbdxOZo Cc: tsvwg@ietf.org Subject: [tsvwg] Last Call: (Generic Aggregation of Resource ReSerVation Protocol (RSVP) for IPv4 And IPv6 Reservations over PCN domains) to Experimental RFC X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Aug 2014 22:38:12 -0000 The IESG has received a request from the Transport Area Working Group WG (tsvwg) to consider the following document: - 'Generic Aggregation of Resource ReSerVation Protocol (RSVP) for IPv4 And IPv6 Reservations over PCN domains' as Experimental RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2014-08-26. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document specifies extensions to Generic Aggregated RSVP RFC 4860 for support of the PCN Controlled Load (CL) and Single Marking (SM) edge behaviors over a Diffserv cloud using Pre- Congestion Notification. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-tsvwg-rsvp-pcn/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-tsvwg-rsvp-pcn/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Tue Aug 12 16:56:56 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65B841A0A8D; Tue, 12 Aug 2014 16:56:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mmvFOxsHpewP; Tue, 12 Aug 2014 16:56:52 -0700 (PDT) Received: from mail-ob0-x229.google.com (mail-ob0-x229.google.com [IPv6:2607:f8b0:4003:c01::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5C8D1A079F; Tue, 12 Aug 2014 16:56:51 -0700 (PDT) Received: by mail-ob0-f169.google.com with SMTP id nu7so7848740obb.0 for ; Tue, 12 Aug 2014 16:56:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=TvOMDq5bVsm7hrc0pMtqzJ3nCKU6PoaHcLOkO23aYxw=; b=Q2edh9KLW9eYpiJj7ynYizJxi2kDLXhA+WMrRGDFSwuWjFjw6l7ID0T4Cg4ifLYflI 9krQwPRmtajzhKepJRPiSlzdXx726KuTAfhsHatbGMn2PfyKAhIOjoWJ27DuD5y/A53P PbBoP81QEVdyfvvvWR+QdV0mYtj+A0i99lN7eVoE+OCrf6UcJ3EuE1I5sJw/CxQVrurK gV3yjCrAWpFCOV+tm+2rpCZZpgVDtgUDTu1gC4rdWCmoxN0AKcgu1WZGgiZm1gEsMV37 1KinnXCsG9qOV6vcurtE3jA6biqj7Ww9hH7tH+XHpMIS5p83eAeiKksRp4xThpJgT3y9 f1VQ== MIME-Version: 1.0 X-Received: by 10.60.74.104 with SMTP id s8mr1039793oev.5.1407887811135; Tue, 12 Aug 2014 16:56:51 -0700 (PDT) Received: by 10.202.93.69 with HTTP; Tue, 12 Aug 2014 16:56:51 -0700 (PDT) In-Reply-To: <941BB385-72AA-42F2-A40C-0C1ACC3D2334@nostrum.com> References: <941BB385-72AA-42F2-A40C-0C1ACC3D2334@nostrum.com> Date: Tue, 12 Aug 2014 16:56:51 -0700 Message-ID: From: Dave Taht To: Ben Campbell Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/3CjQetmaBlXelcOkrM4I2DEVzqg Cc: mmusic@ietf.org, draft-ietf-dart-dscp-rtp.all@tools.ietf.org, "clue@ietf.org" , avt@ietf.org, "rmcat@ietf.org" , "rtcweb@ietf.org" , "tsvwg@ietf.org" Subject: Re: [tsvwg] [rtcweb] Fwd: WGLC: draft-ietf-dart-dscp-rtp-02 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Aug 2014 23:56:54 -0000 This is also of some interest to me at least, and perhaps some members of the AQM working group who are working out weighted fair queuing and wred like approaches to these needs. Anyway, I do try to track thinking in this area in the ongoing development of cerowrt's sqm system, which has pluggable modules for all the known aqm and fq schedulers, and a three tier system modeled on wondershaper for managing traffic, which uses what diffserv markings that I have observed make sense... Some relevant links: http://www.bufferbloat.net/projects/cerowrt/wiki/Wondershaper_Must_Die http://www.bufferbloat.net/projects/cerowrt/wiki/Setting_up_SQM_for_CeroWrt= _310 http://www.bufferbloat.net/projects/cerowrt/wiki/Smart_Queue_Management Missing from this discussion so far is what is actually deployed out there... I am only familiar with stuff like the above as an egress/ingress queue management system... AND: in the case of linux based wireless routers, none of the AF codepoints are respected explicitly, and how the codepoints are mapped are described by 802.11e - and that is far more about scheduling priority for airtime rather than drop probability. It is kind of hard to wrap your head around how 802.11e actually works, but, this is a start: http://en.wikipedia.org/wiki/IEEE_802.11e-2005#Enhanced_distributed_channel= _access_.28EDCA.29 In linux wifi at least: CS0, CS3 are mapped into the BE hw queue CS1, CS2 are mapped into the BK hw queue CS4, CS5 are mapped into the VI hw queue CS6, CS7 are mapped into the VO hw queue Bit patterns for the other classes to whatever extent they map into CSX are mapped into the underlying hardware queue. I am not saying this is an optimal state of affairs, (as notably VO should be as completely disabled as possible in the 802.11n and ac age), and am very interested in how other OSes (ios, osx, windows), and router/switch OSes do it, but the wireless scheduling aspect of all these codepoints does not seem to be well touched upon. On a personal note I tend to think that having 17+ ways to slice up traffic is about 13 or 14 too many, particularly those targetting a drop probability. When you have drop rates well below a few percentage points, adding another percentage point of granularity seems futile. Lastly, there is also an implementation issue in linux presently in that doing extensive diffserv classification basically requires one iptables or tc rule per class, which is inefficient. Someone (not me!) doing some code for doing diffserv saner there would go a long way... On Sat, Aug 9, 2014 at 11:48 AM, Ben Campbell wrote: > Hi, > > The DART working group has started a last call for draft-ietf-dart-dscp-r= tp-02, ending on August 22. This informational draft describes consideratio= ns for the use of DiffServ code points in situations where one multiplexes = multiple RTP packet streams, and potentially other protocol streams, that s= hare the same 5-tuple. > > Since this draft is likely of interest to several working groups, I would= like to solicit additional reviews from participants of TSVWG, AVTCORE, MM= USIC, CLUE, RTCWEB, and RMCAT. Please send any feedback (including feedback= to the effect of "this is ready to progress") to the DART working group ma= iling list. > > Thanks! > > Ben. > > Begin forwarded message: > >> Resent-From: draft-alias-bounces@tools.ietf.org >> From: Ben Campbell >> Subject: WGLC: draft-ietf-dart-dscp-rtp-02 >> Date: August 9, 2014 at 12:50:16 PM CDT >> Resent-To: ben@nostrum.com, david.black@emc.com, paulej@packetizer.com >> To: dart@ietf.org >> Cc: draft-ietf-dart-dscp-rtp.all@tools.ietf.org, mls.ietf@gmail.com, Ric= hard Barnes >> >> This is a DART Working Group Last Call of draft-ietf-dart-dscp-rtp-02. I= t's available on the data tracker at the following URL: >> >> https://datatracker.ietf.org/doc/draft-ietf-dart-dscp-rtp/ >> >> The WGLC will conclude on 22 August, 2014. Please send your comments to = the authors and the DART mailing list. If you've reviewed it and think it's= good to go, please say so. >> >> Thanks! >> >> Ben. >> > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --=20 Dave T=C3=A4ht NSFW: https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_= indecent.article From nobody Tue Aug 12 23:39:47 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E24141A6FFF; Tue, 12 Aug 2014 23:39:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.218 X-Spam-Level: X-Spam-Status: No, score=-2.218 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, MANGLED_BEEF=2.3, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jSksI0OObaQU; Tue, 12 Aug 2014 23:39:40 -0700 (PDT) Received: from tcmail13.telekom.de (tcmail13.telekom.de [80.149.113.165]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4636D1A6FFA; Tue, 12 Aug 2014 23:39:39 -0700 (PDT) Received: from s4de8nsazdfe010.bmbg.telekom.de ([10.175.246.202]) by tcmail11.telekom.de with ESMTP; 13 Aug 2014 08:39:37 +0200 X-IronPort-AV: E=Sophos;i="5.01,855,1400018400"; d="scan'208";a="513890320" Received: from he113657.emea1.cds.t-internal.com ([10.134.99.17]) by q4de8nsa015.bmbg.telekom.de with ESMTP/TLS/AES128-SHA; 13 Aug 2014 08:39:37 +0200 Received: from HE111643.EMEA1.CDS.T-INTERNAL.COM ([10.134.93.12]) by HE113657.emea1.cds.t-internal.com ([::1]) with mapi; Wed, 13 Aug 2014 08:39:36 +0200 From: To: Date: Wed, 13 Aug 2014 08:39:36 +0200 Thread-Topic: AW: [Dart] WGLC: draft-ietf-dart-dscp-rtp-02 Thread-Index: Ac+2bO5f3WR7i7TTT2C8E/wL7+YxHAAUuAdQ Message-ID: References: <53E923CE.1000803@gmail.com> <53EA7A80.6010800@gmail.com> In-Reply-To: <53EA7A80.6010800@gmail.com> Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/Os_Hm3yNJEpCm9yMYAB_x1QfHOY Cc: dart@ietf.org, tsvwg@ietf.org Subject: Re: [tsvwg] [Dart] WGLC: draft-ietf-dart-dscp-rtp-02 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Aug 2014 06:39:44 -0000 SGkgQnJpYW4sDQoNCndlIGFyZSBpbiBhZ3JlZW1lbnQgaW4gbW9zdCBwb2ludHMuIA0KDQpPZiBj b3Vyc2UgYSBwcm92aWRlciBjb3VsZCBzaGFwZSBFRiB0cmFmZmljIG9uIGFuIA0KaW50ZXJjb25u ZWN0aW9uLiBUaGlzIG1heSBub3QgYmUgYSBzb2x1dGlvbiB3aGljaCANCkkgZmF2b3IsIGJ1dCBp dCBpcyBwb3NzaWJsZS4gDQoNClJlZ2FyZHMsDQoNClJ1ZWRpZ2VyDQoNCi0tLS0tVXJzcHLDvG5n bGljaGUgTmFjaHJpY2h0LS0tLS0NClZvbjogQnJpYW4gRSBDYXJwZW50ZXIgW21haWx0bzpicmlh bi5lLmNhcnBlbnRlckBnbWFpbC5jb21dIA0KR2VzZW5kZXQ6IERpZW5zdGFnLCAxMi4gQXVndXN0 IDIwMTQgMjI6MzUNCkFuOiBHZWliLCBSw7xkaWdlcg0KQ2M6IGRhdmlkLmJsYWNrQGVtYy5jb207 IGRhcnRAaWV0Zi5vcmc7IHRzdndnQGlldGYub3JnDQpCZXRyZWZmOiBSZTogQVc6IFtEYXJ0XSBX R0xDOiBkcmFmdC1pZXRmLWRhcnQtZHNjcC1ydHAtMDINCg0KSGkgUnVlZGlnZXIsDQoNCk9uIDEy LzA4LzIwMTQgMTk6MzgsIFJ1ZWRpZ2VyLkdlaWJAdGVsZWtvbS5kZSB3cm90ZToNCj4gSGkgQnJp YW4sDQo+IA0KPiB3aXRoIEVGIEkgbGluayBhbiBleHBlY3RhdGlvbiBvZiBleGNlc3MgdHJhZmZp YyBiZWluZyBkcm9wcGVkLg0KDQpJbiBnZW5lcmFsIEkgYWdyZWU7IGJ1dCB0aGF0IG9ubHkgbWFr ZXMgc2Vuc2UgaWYgdGhlcmUgaXMgYW4gYWdyZWVtZW50IChvciBtZWNoYW5pc20pIHRvIGRlZmlu ZSB0aGUgbm9taW5hbCByYXRlLCBhbmQgcmF0ZSBjb250cm9sIG9mIHNvbWUga2luZCBhdCB0aGUg c291cmNlLiAoQW4gSVAgcGhvbmUgaXMgaW4gZWZmZWN0IGEgcmF0ZSBjb250cm9sbGVyLCBmb3Ig ZXhhbXBsZS4pDQoNCj4gDQo+IEEgcmF0ZSBzY2hlZHVsZXIgd2l0aCBzaW5nbGUgZGlnaXQgbWls bGlzZWNvbmQgYnVmZmVyIGRlcHRoIGFuZCB0YWlsIA0KPiBkcm9wIGxpa2UgYmVoYXZpb3IgaXMg bm90IGFuIGlzc3VlLg0KPiBUbyBtZSwgdGhhdCdzIGEgc2hhcGVyIGNvbmZpZ3VyZWQgdG8gYmUg RUYgY29tcGxpYW50LiANCj4gSWYgc3VjaCBhIGNvbnN0cmFpbnQgaXMgbm90IGRlc2lyZWQgdGhl biB0aGUgdGV4dCBtYXkgc2F5ICJpZiBtYXBwZWQgDQo+IHRvIGEgbm9uLUVGIFBIQiwgZXhjZXNz IHRyYWZmaWMgbWF5IGJlIHNoYXBlZCIuIEknZCBsaWtlIHRvIGFzayBmb3IgDQo+IHNvbWUgZXhw bGFpbmluZyB0ZXh0IGlmIHNoYXBpbmcgb2YgRUYgZXhjZXNzIHRyYWZmaWMgaXMgcmVnYXJkZWQg YXMgYSANCj4gcHJvcGVydHkgdG8gYmUgZXhwZWN0ZWQgZm9yIHRoaXMgUEhCLg0KDQpZZXMsIHRl Y2huaWNhbGx5IHRoYXQncyBjb3JyZWN0IC0gYnV0IGEgc2hhcGVyIGNvdWxkIGJlIGluc2VydGVk IGF0IHRoZSBib3VuZGFyeSBiZXR3ZWVuIHR3byBEUyBkb21haW5zLCBhbmQgZm9yIHRoZSBlbmQt dG8tZW5kIHVzZXIgdGhhdCB3aWxsIGFwcGVhciBhcyBhIHByb3BlcnR5IG9mIHRoZSBQSEIuDQoN Cj4gSWYgYW4gQUYgY2xhc3MgaXMgdXNlZCB0byB0cmFuc3BvcnQgRUYsIHRoZW4gYW55IHBvdGVu dGlhbCByZW1hcmtpbmcgDQo+IHNob3VsZCBiZSBkb25lIGluIGEgd2F5IGF2b2lkaW5nIHJlLW9y ZGVyaW5nIChpLmUuIHJlbWFyayB0byBEU0NQcyANCj4gd2l0aGluIHRoZSBzYW1lIEFGIGNsYXNz IG9ubHkpLg0KPiBUaGVyZSdzIG5vIHBvaW50IGluIHJlbWFya2luZyBleGNlc3MgRUYgdHJhZmZp YyB0byBhIFBIQiB3aGljaCBtYXkgDQo+IGNhdXNlIHJlb3JkZXJpbmcuDQoNCkkgZnVsbHkgYWdy ZWUuDQoNCj4gSSB0aGluayB0aGF0J3Mgd2hhdCBhIHRleHQNCj4gb24gcmVtYXJraW5nIG9mIEVG IHNob3VsZCBleHByZXNzLCBpZiByZW1hcmtpbmcgaXMga2VwdCBhcyBhbiBvcHRpb24gDQo+IHRv IGJlIGV4cGVjdGVkIChJJ3ZlIG5vdCB5ZXQgaGVhcmQgb2Ygc3VjaCBhIGRlcGxveW1lbnQpLg0K DQpZZXMuIEknbSBub3QgYWR2b2NhdGluZyBzdWNoIGJlaGF2aW91cjsgbXkgcG9pbnQgaXMgb25s eSB0aGF0IEVGIG1heSBub3QgYWx3YXlzIGJlIHN0cmljdGx5IGNvbmZvcm1hbnQgdG8gUkZDIDMy NDYuDQoNCiAgIEJyaWFuDQoNCj4gUmVnYXJkcywNCj4gDQo+IFJ1ZWRpZ2VyDQo+IA0KPiANCj4g LS0tLS1VcnNwcsO8bmdsaWNoZSBOYWNocmljaHQtLS0tLQ0KPiBWb246IEJyaWFuIEUgQ2FycGVu dGVyIFttYWlsdG86YnJpYW4uZS5jYXJwZW50ZXJAZ21haWwuY29tXQ0KPiBHZXNlbmRldDogTW9u dGFnLCAxMS4gQXVndXN0IDIwMTQgMjI6MTMNCj4gQW46IEdlaWIsIFLDvGRpZ2VyDQo+IENjOiBk YXZpZC5ibGFja0BlbWMuY29tOyBkYXJ0QGlldGYub3JnOyB0c3Z3Z0BpZXRmLm9yZw0KPiBCZXRy ZWZmOiBSZTogW0RhcnRdIFdHTEM6IGRyYWZ0LWlldGYtZGFydC1kc2NwLXJ0cC0wMg0KPiANCj4g SGkgUnVlZGlnZXIsDQo+IA0KPiBPbiAxMS8wOC8yMDE0IDIyOjIxLCBSdWVkaWdlci5HZWliQHRl bGVrb20uZGUgd3JvdGU6DQo+PiBIaSBEYXZpZCwNCj4+DQo+PiBuZXcgRUYgcmVsYXRlZCB0ZXh0 IGhhcyBiZWVuIGFkZGVkIGluIHRoZSAtMDEgdmVyc2lvbi4gSSd2ZSBjb3BpZWQgaW4gDQo+PiBz b21lIHRleHQgb2YgUkZDMzI0NiByZWxhdGVkIHRvIEVGIHJlbWFya2luZyBhbmQgcG9saWNpbmcg YmVsb3cuDQo+PiBNeSB0YWtlOg0KPj4NCj4+IC4gcmVtYXJraW5nIG9mIGVudGlyZSBmbG93cyBp cyBhbiBvcHRpb24sIGJ1dCBubyByZW1hcmtpbmcgb2YgDQo+PiAgIHBhY2tldHMgZXhjZWVkaW5n IEVGIGNhcGFjaXR5IGxpbWl0cy4NCj4+IC0gbG9va2luZyBhdCB0aGUgRUYgaml0dGVyIGFuZCBk ZWxheSBwcm9wZXJ0aWVzLCBJIGRvdWJ0IHRoYXQgDQo+PiAgIHNoYXBpbmcgaXMgZGVzaXJhYmxl LiBSRkMzMjQ2IGRvZXNuJ3QgbWVudGlvbiBzaGFwaW5nIGFzIHBhcnQgDQo+PiAgIG9mIEVGIGNv bmRpdGlvbmluZy4gSSBwZXJzb25hbGx5IHdvdWxkbid0IGV4cGVjdCBFRiBzaGFwaW5nIA0KPj4g ICBpbiBzZWN0aW9ucyB3aGVyZSBwb2xpY2luZyBpcyBhcHBsaWVkLiANCj4+IC0gZHJvcHBpbmcg b2YgcGFja2V0cyBleGNlZWRpbmcgRUYgY2FwYWNpdHkgaXMgYSBNVVNULCBpZiBJIA0KPj4gICBp bnRlcnByZXQgUkZDMzI0NiBjb3JyZWN0bHkuDQo+IA0KPiBXZWxsLCBpdCBzZWVtcyB0byBtZSB0 byBiZSBhIFNIT1VMRCwgd2l0aCB0aGUgTVVTVCB0aGF0IHlvdSBjaXRlIGJlbG93IGJlaW5nIGNv bmRpdGlvbmFsIG9uICJhIG1lY2hhbmlzbSB0aGF0IGFsbG93cyB1bmxpbWl0ZWQgcHJlZW1wdGlv biBvZiBvdGhlciB0cmFmZmljLiIgU28gSSB3b3VsZCBub3QgYmUgYXQgYWxsIHN1cnByaXNlZCBi eSBkZXBsb3ltZW50cyB0aGF0IHN1cHBvcnQgc2hhcGluZyBhbmQgcmVtYXJraW5nLiBBbHNvLCB0 aGVyZSBhcmUgY2VydGFpbmx5IGltcGxlbWVudGF0aW9ucyB0aGF0IGFyZSBjbG9zZXIgdG8gUkZD IDI1OTggb3IgUkZDIDMyNDggYW5kIHRoZXJlZm9yZSBsZXNzIHN0cmljdC4NCj4gDQo+IEkgdGhp bmsgdGhlIGRyYWZ0IHNob3VsZCBtYWtlIGl0IGNsZWFyIHRoYXQgdGhlcmUgaXMgbGlrZWx5IHRv IGJlIA0KPiB2YXJpYXRpb24gaW4gYWN0dWFsIGJlaGF2aW91ciBmb3IgRUYgdHJhZmZpYyB0aGF0 IGV4Y2VlZHMgdGhlIG5vbWluYWwgDQo+IHJhdGUuIChMZWF2aW5nIGFzaWRlIHRoZSBmYWN0IHRo YXQgd2l0aG91dCBhIHN0cmluZyBvZiBtYXRjaGluZyBTTEFzIA0KPiBhbG9uZyB0aGUgcGF0aCwg dGhlIG5vbWluYWwgcmF0ZSBtaWdodCBub3QgZXZlbiBiZSB3ZWxsIGRlZmluZWQuKQ0KPiANCj4g ICAgQnJpYW4NCj4gDQo+PiBJIHN1Z2dlc3QgdG8gYWRhcHQgdGhlIHNlY3Rpb24gb2YgZHJhZnQt ZGFydC1kc2NwIHRvIGJlIG1vcmUgcHJlY2lzZSANCj4+IHJlZ2FyZGluZyB0aGUgb3B0aW9uYWwg cmVtYXJraW5nIG9mIEVGIHRyYWZmaWMgYW5kIHRvIHJlbW92ZSBzaGFwaW5nIA0KPj4gYXMgYSBj b25kaXRpb25pbmcgb3B0aW9uIGlmIHRyYWZmaWMgaXMgYmV5b25kIHRoZSBFRiBmb3J3YXJkaW5n IA0KPj4gY2FwYWNpdHkgbGltaXQuIEEgUHJvcG9zYWwgZm9yIHRoZSBmaW5hbA0KPj4gc2VudGVu Y2U6DQo+Pg0KPj4gLi4uZXhjZWVkcyB0aGF0IGNhcGFjaXR5IG11c3QgYmUgZHJvcHBlZC4gRUYg Y29tcGxpYW50IGZsb3dzIG1heSBiZSANCj4+IHJlbWFya2VkIHRvIGEgZGlmZmVyZW50IERTQ1Au DQo+Pg0KPj4gQWxsIG90aGVyIG5ldyB0ZXh0IGluZGljYXRlZCBieSB0aGUgRGlmZiB2ZXJzaW9u IGxvb2tzIGFsbHJpZ2h0Lg0KPj4NCj4+IFJlZ2FyZHMsDQo+Pg0KPj4gUnVlZGlnZXINCj4+DQo+ Pg0KPj4NCj4+IGRyYWZ0LWRhcnQtZHNjcDoNCj4+DQo+PiAzLiBFeHBlZGl0ZWQgRm9yd2FyZGlu ZyAoRUYpIFtSRkMzMjQ2XSBpbnRlbmRlZCBmb3IgaW5lbGFzdGljCQ0KPj4gICAgdHJhZmZpYy4g QmV5b25kIHRoZSBiYXNpYyBFRiBQSEIsIHRoZSBWT0lDRS1BRE1JVCBQSEIgW1JGQzU4NjVdCQ0K Pj4gICAgaXMgYW4gYWRtaXNzaW9uIGNvbnRyb2xsZWQgdmFyaWFudCBvZiB0aGUgRUYgUEhCLiBC b3RoIG9mIHRoZXNlCQ0KPj4gICAgUEhCcyBhcmUgYmFzZWQgb24gcHJlLWNvbmZpZ3VyZWQgbGlt aXRlZCBmb3J3YXJkaW5nIGNhcGFjaXR5OwkNCj4+ICAgIHRyYWZmaWMgdGhhdCBleGNlZWRzIHRo YXQgY2FwYWNpdHkgbWF5IGJlIHNoYXBlZCwgcmVtYXJrZWQgdG8gYQkNCj4+ICAgIGRpZmZlcmVu dCBEU0NQLCBvciBkcm9wcGVkLg0KPj4NCj4+ICMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMjIyMjIyMjIyMNCj4+DQo+PiBSRkMzMjQ2ICh0aHJlZSBleGNlcnB0cyk6DQo+Pg0KPj4gICAg UGFja2V0cyBiZWxvbmdpbmcgdG8gYSBzaW5nbGUgbWljcm9mbG93IHdpdGhpbiB0aGUgRUYgYWdn cmVnYXRlDQo+PiAgICBwYXNzaW5nIHRocm91Z2ggYSBkZXZpY2UgU0hPVUxEIE5PVCBleHBlcmll bmNlIHJlLW9yZGVyaW5nIGluIG5vcm1hbA0KPj4gICAgb3BlcmF0aW9uIG9mIHRoZSBkZXZpY2Uu DQo+Pg0KPj4gICAgUGFja2V0cyBtYXJrZWQgZm9yIEVGIFBIQiBNQVkgYmUgcmVtYXJrZWQgYXQg YSBEUyBkb21haW4gYm91bmRhcnkNCj4+ICAgIG9ubHkgdG8gb3RoZXIgY29kZXBvaW50cyB0aGF0 IHNhdGlzZnkgdGhlIEVGIFBIQi4gIFBhY2tldHMgbWFya2VkIGZvcg0KPj4gICAgRUYgUEhCcyBT SE9VTEQgTk9UIGJlIGRlbW90ZWQgb3IgcHJvbW90ZWQgdG8gYW5vdGhlciBQSEIgYnkgYSBEUw0K Pj4gICAgZG9tYWluLg0KPj4NCj4+ICAgIElmIHRoZSBFRiBQSEIgaXMgaW1wbGVtZW50ZWQgYnkg YSBtZWNoYW5pc20gdGhhdCBhbGxvd3MgdW5saW1pdGVkDQo+PiAgICBwcmVlbXB0aW9uIG9mIG90 aGVyIHRyYWZmaWMgKGUuZy4sIGEgcHJpb3JpdHkgcXVldWUpLCB0aGUNCj4+ICAgIGltcGxlbWVu dGF0aW9uIE1VU1QgaW5jbHVkZSBzb21lIG1lYW5zIHRvIGxpbWl0IHRoZSBkYW1hZ2UgRUYgdHJh ZmZpYw0KPj4gICAgY291bGQgaW5mbGljdCBvbiBvdGhlciB0cmFmZmljIChlLmcuLCBhIHRva2Vu IGJ1Y2tldCByYXRlIGxpbWl0ZXIpLg0KPj4gICAgVHJhZmZpYyB0aGF0IGV4Y2VlZHMgdGhpcyBs aW1pdCBNVVNUIGJlIGRpc2NhcmRlZC4NCj4+DQo+Pg0KPj4NCj4+DQo+Pg0KPj4gLS0tLS1VcnNw csO8bmdsaWNoZSBOYWNocmljaHQtLS0tLQ0KPj4gVm9uOiBEYXJ0IFttYWlsdG86ZGFydC1ib3Vu Y2VzQGlldGYub3JnXSBJbSBBdWZ0cmFnIHZvbiBCZW4gQ2FtcGJlbGwNCj4+IEdlc2VuZGV0OiBT YW1zdGFnLCA5LiBBdWd1c3QgMjAxNCAxOTo1MA0KPj4gQW46IGRhcnRAaWV0Zi5vcmcNCj4+IENj OiBSaWNoYXJkIEJhcm5lczsgZHJhZnQtaWV0Zi1kYXJ0LWRzY3AtcnRwLmFsbEB0b29scy5pZXRm Lm9yZzsNCj4+IG1scy5pZXRmQGdtYWlsLmNvbQ0KPj4gQmV0cmVmZjogW0RhcnRdIFdHTEM6IGRy YWZ0LWlldGYtZGFydC1kc2NwLXJ0cC0wMg0KPj4NCj4+IFRoaXMgaXMgYSBEQVJUIFdvcmtpbmcg R3JvdXAgTGFzdCBDYWxsIG9mIGRyYWZ0LWlldGYtZGFydC1kc2NwLXJ0cC0wMi4gSXQncyBhdmFp bGFibGUgb24gdGhlIGRhdGEgdHJhY2tlciBhdCB0aGUgZm9sbG93aW5nIFVSTDoNCj4+DQo+PiBo dHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWRhcnQtZHNjcC1ydHAv DQo+Pg0KPj4gVGhlIFdHTEMgd2lsbCBjb25jbHVkZSBvbiAyMiBBdWd1c3QsIDIwMTQuIFBsZWFz ZSBzZW5kIHlvdXIgY29tbWVudHMgdG8gdGhlIGF1dGhvcnMgYW5kIHRoZSBEQVJUIG1haWxpbmcg bGlzdC4gSWYgeW91J3ZlIHJldmlld2VkIGl0IGFuZCB0aGluayBpdCdzIGdvb2QgdG8gZ28sIHBs ZWFzZSBzYXkgc28uDQo+Pg0KPj4gVGhhbmtzIQ0KPj4NCj4+IEJlbi4NCj4+DQo+PiBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4gRGFydCBtYWlsaW5n IGxpc3QNCj4+IERhcnRAaWV0Zi5vcmcNCj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vZGFydA0KPj4NCj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQo+PiBEYXJ0IG1haWxpbmcgbGlzdA0KPj4gRGFydEBpZXRmLm9yZw0KPj4g aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kYXJ0DQo+PiAuDQo+Pg0KPiAN Cg0K From nobody Wed Aug 13 09:54:19 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB1A71A0331 for ; Wed, 13 Aug 2014 09:54:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.269 X-Spam-Level: X-Spam-Status: No, score=-3.269 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0-qB6ijjSr23 for ; Wed, 13 Aug 2014 09:54:15 -0700 (PDT) Received: from hubrelay-by-03.bt.com (hubrelay-by-03.bt.com [62.7.242.139]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 116981A0943 for ; Wed, 13 Aug 2014 09:54:13 -0700 (PDT) Received: from EVMHR72-UKRD.domain1.systemhost.net (10.36.3.110) by EVMHR03-UKBR.bt.com (10.216.161.35) with Microsoft SMTP Server (TLS) id 8.3.348.2; Wed, 13 Aug 2014 17:54:10 +0100 Received: from EPHR02-UKIP.domain1.systemhost.net (147.149.100.81) by EVMHR72-UKRD.domain1.systemhost.net (10.36.3.110) with Microsoft SMTP Server (TLS) id 8.3.348.2; Wed, 13 Aug 2014 17:54:11 +0100 Received: from bagheera.jungle.bt.co.uk (132.146.168.158) by EPHR02-UKIP.domain1.systemhost.net (147.149.100.81) with Microsoft SMTP Server id 14.3.181.6; Wed, 13 Aug 2014 17:54:10 +0100 Received: from BTP075694.jungle.bt.co.uk ([10.215.130.93]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id s7DGs9Rw029223; Wed, 13 Aug 2014 17:54:09 +0100 Message-ID: <201408131654.s7DGs9Rw029223@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 13 Aug 2014 17:54:09 +0100 To: "BLACK, David" From: Bob Briscoe In-Reply-To: <539EA622-839D-4CA4-815C-F8D0F95DD714@ifi.uio.no> References: <8D3D17ACE214DC429325B2B98F3AE712077B951766@MX15A.corp.emc.com> <53E50985.9010009@isi.edu> <539EA622-839D-4CA4-815C-F8D0F95DD714@ifi.uio.no> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/hAPzZQMQakmfT5ZaeSQhcT0SCBU Cc: "tsvwg@ietf.org" Subject: Re: [tsvwg] WG Adoption Call for draft-fairhurst-tsvwg-circuit-breaker- 22 August 2014 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Aug 2014 16:54:18 -0000 David, I support adoption of this draft. Note we already cite this draft in http://tools.ietf.org/html/draft-ietf-pwe3-congcons, which has just finished WG last call, which already starts to prove its worth. ________________________________________________________________ Bob Briscoe, BT From nobody Wed Aug 13 10:14:37 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B72C61A02FB for ; Wed, 13 Aug 2014 10:14:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.269 X-Spam-Level: X-Spam-Status: No, score=-3.269 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Av-IreaFUiQo for ; Wed, 13 Aug 2014 10:14:33 -0700 (PDT) Received: from hubrelay-rd.bt.com (hubrelay-rd.bt.com [62.239.224.99]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBD0A1A02D7 for ; Wed, 13 Aug 2014 10:14:32 -0700 (PDT) Received: from EVMHR71-UKRD.domain1.systemhost.net (10.36.3.109) by EVMHR68-UKRD.bt.com (10.187.101.23) with Microsoft SMTP Server (TLS) id 8.3.348.2; Wed, 13 Aug 2014 18:14:31 +0100 Received: from EPHR02-UKIP.domain1.systemhost.net (147.149.100.81) by EVMHR71-UKRD.domain1.systemhost.net (10.36.3.109) with Microsoft SMTP Server (TLS) id 8.3.348.2; Wed, 13 Aug 2014 18:14:30 +0100 Received: from bagheera.jungle.bt.co.uk (132.146.168.158) by EPHR02-UKIP.domain1.systemhost.net (147.149.100.81) with Microsoft SMTP Server id 14.3.181.6; Wed, 13 Aug 2014 18:14:30 +0100 Received: from BTP075694.jungle.bt.co.uk ([10.215.130.93]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id s7DHER3b029285; Wed, 13 Aug 2014 18:14:27 +0100 Message-ID: <201408131714.s7DHER3b029285@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 13 Aug 2014 18:14:28 +0100 To: From: Bob Briscoe In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/GFLkE4-Oxf-tVq-snWiP3xvoanE Cc: tsvwg@ietf.org Subject: Re: [tsvwg] Draft notes from Toronto meeting X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Aug 2014 17:14:36 -0000 Gorry, The notes on the morning session seem to end in the middle of a sentence. Then the afternoon session starts. Has there been some text lost? The break happens during the discussion of Tunnel Congestion Feedback (which was last in the morning). But I'm interested to know what the end of the discussion was. Cheers Bob At 13:38 28/07/2014, gorry@erg.abdn.ac.uk wrote: >Please review the draft notes and send any comments/corrections, they are >available at: >http://www.ietf.org/proceedings/90/minutes/minutes-90-tsvwg > >Gorry ________________________________________________________________ Bob Briscoe, BT From nobody Wed Aug 13 10:29:02 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B34F1A01E2 for ; Wed, 13 Aug 2014 10:29:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.869 X-Spam-Level: X-Spam-Status: No, score=-4.869 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IKJzPKRVYYxH for ; Wed, 13 Aug 2014 10:29:00 -0700 (PDT) Received: from spey.erg.abdn.ac.uk (spey.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id D3B6F1A00E6 for ; Wed, 13 Aug 2014 10:28:59 -0700 (PDT) Received: from www.erg.abdn.ac.uk (blake.erg.abdn.ac.uk [139.133.210.30]) by spey.erg.abdn.ac.uk (Postfix) with ESMTPSA id E164A2B41E7; Wed, 13 Aug 2014 18:28:58 +0100 (BST) Received: from 212.159.18.54 (SquirrelMail authenticated user gorry) by www.erg.abdn.ac.uk with HTTP; Wed, 13 Aug 2014 18:28:59 +0100 Message-ID: <21dbe23ef30f81a5e1625dd7c1957e05.squirrel@www.erg.abdn.ac.uk> In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE712077B951766@MX15A.corp.emc.com> References: <8D3D17ACE214DC429325B2B98F3AE712077B951766@MX15A.corp.emc.com> Date: Wed, 13 Aug 2014 18:28:59 +0100 From: gorry@erg.abdn.ac.uk To: "Black, David" User-Agent: SquirrelMail/1.4.22 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/eVzZ0KZyCiYhhNvIGn0iZrqVJKo Cc: "tsvwg@ietf.org" Subject: Re: [tsvwg] WG Adoption Call for draft-fairhurst-tsvwg-circuit-breaker- 22 August 2014 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Aug 2014 17:29:01 -0000 > The TSVWG chairs are considering adoption of the above draft. This draft > has been discussed at previous IETF meetings and on the list. > ... > > Also, would the draft author (Gorry) please send a note to the list > indicating whether you know of any IPR related to this draft that > requires disclosure in accordance with BCP 79. Needless to say, > Gorry is recused from this decision, as he is the author of this draft. > > Thanks, > --David (tsvwg WG co-chair) > ---------------------------------------------------- For the record, I claim no IPR related to this draft, and do not know of any that requires disclosure in accordance with BCP 79. Gorry From nobody Wed Aug 13 10:53:25 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B23911A0292 for ; Wed, 13 Aug 2014 10:53:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.869 X-Spam-Level: X-Spam-Status: No, score=-4.869 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sTD5FDxW7oum for ; Wed, 13 Aug 2014 10:53:17 -0700 (PDT) Received: from spey.erg.abdn.ac.uk (spey.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id CB4711A01EE for ; Wed, 13 Aug 2014 10:53:16 -0700 (PDT) Received: from www.erg.abdn.ac.uk (blake.erg.abdn.ac.uk [139.133.210.30]) by spey.erg.abdn.ac.uk (Postfix) with ESMTPSA id EA39B2B41E7 for ; Wed, 13 Aug 2014 18:53:15 +0100 (BST) Received: from 212.159.18.54 (SquirrelMail authenticated user gorry) by www.erg.abdn.ac.uk with HTTP; Wed, 13 Aug 2014 18:53:16 +0100 Message-ID: <4a102873eb0b5b9b07a4fd029543ccd4.squirrel@www.erg.abdn.ac.uk> In-Reply-To: <201408131714.s7DHER3b029285@bagheera.jungle.bt.co.uk> References: <201408131714.s7DHER3b029285@bagheera.jungle.bt.co.uk> Date: Wed, 13 Aug 2014 18:53:16 +0100 From: gorry@erg.abdn.ac.uk To: tsvwg@ietf.org User-Agent: SquirrelMail/1.4.22 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/vajtCeLnmPQ2adG_9mXCzHxi4w4 Subject: Re: [tsvwg] Draft notes from Toronto meeting X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Aug 2014 17:53:22 -0000 Thanks for noting this - I added the comments from the Chairs at the end. Gorry > Gorry, > > The notes on the morning session seem to end in the middle of a > sentence. Then the afternoon session starts. Has there been some text > lost? > > The break happens during the discussion of Tunnel Congestion Feedback > (which was last in the morning). But I'm interested to know what the > end of the discussion was. > > Cheers > > > > Bob > > At 13:38 28/07/2014, gorry@erg.abdn.ac.uk wrote: > >>Please review the draft notes and send any comments/corrections, they are >>available at: >>http://www.ietf.org/proceedings/90/minutes/minutes-90-tsvwg >> >>Gorry > > ________________________________________________________________ > Bob Briscoe, BT > From nobody Thu Aug 21 13:43:41 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08B7A1A8A0D; Thu, 21 Aug 2014 13:43:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mpDLI8KWGZZA; Thu, 21 Aug 2014 13:43:36 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 750051A6FAC; Thu, 21 Aug 2014 13:43:36 -0700 (PDT) Received: from unnumerable.local (pool-173-57-89-168.dllstx.fios.verizon.net [173.57.89.168]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id s7LKhZbe097933 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=OK); Thu, 21 Aug 2014 15:43:35 -0500 (CDT) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host pool-173-57-89-168.dllstx.fios.verizon.net [173.57.89.168] claimed to be unnumerable.local Message-ID: <53F659F7.3080106@nostrum.com> Date: Thu, 21 Aug 2014 15:43:35 -0500 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: General Area Review Team , "ietf@ietf.org" , tsvwg@ietf.org, draft-ietf-tsvwg-rsvp-pcn.all@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/IMz2s2m8_5JsBjU5F9SJ6P6pe9I Subject: [tsvwg] Gen-art LC review: draft-ietf-tsvwg-rsvp-pcn-09 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Aug 2014 20:43:39 -0000 I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at . Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-tsvwg-rsvp-pcn-09 Reviewer: Robert Sparks Review Date: 21 Aug 2014 IETF LC End Date: 26 Aug 2014 IESG Telechat date: 2 Oct 2014 Summary: Ready (with nits) for publication as Experimental. David's shepherd writeup points out that implementation and usage experience is desired before producing a proposed standard. Are there any points of concern about how this might behave (or misbehave) in a deployed network that such experience would inform? If so, it would be useful to call them out in the document. It would be nicer if the document argued why there are no new security considerations introduced by the new behavior defined in this draft, rather than tacitly asserting that there aren't any. The terminology section has lots of 2119 words in it. It's hard to tell when these have been copied from some other draft (and this is just restating them) vs when this draft is introducing a new requirement. Since a new requirement would likely be missed if it appeared only in a terminology section, would it be feasible to make sure anything new is well covered in section 3 or 4 and remove 2119 from these definitions altogether? The rest of these comments are minor editorial nits: Section 1.2, paragraph 3: "Intserv over Diffserv can operate over a statically provisioned Diffserv region or RSVP aware." is missing a a word somewhere. Section 1.2 paragraph 4: "By using multiple aggregate reservations for the same PHB allows enforcement of the different preemption priorities within the aggregation region." doesn't parse. Should the initial "By" be deleted? The definition for PCN-domain is very close to circular. Perhaps some words can be removed? From nobody Sun Aug 24 05:39:14 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A2741A892C for ; Sun, 24 Aug 2014 05:39:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.52 X-Spam-Level: X-Spam-Status: No, score=0.52 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xyx_y4Si53gv for ; Sun, 24 Aug 2014 05:39:10 -0700 (PDT) Received: from mail-we0-x231.google.com (mail-we0-x231.google.com [IPv6:2a00:1450:400c:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C0E01A8765 for ; Sun, 24 Aug 2014 05:39:09 -0700 (PDT) Received: by mail-we0-f177.google.com with SMTP id w62so12004595wes.8 for ; Sun, 24 Aug 2014 05:39:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tieto.com; s=google; h=from:references:in-reply-to:mime-version:thread-index:date :message-id:subject:to:content-type; bh=GpEiKXHNRMGeERKSTGwIBXcPZ8kXrTreqOveCcM+MaU=; b=lZEuy2AeJlOFSeYRzBjOXwEGh2A/3cbWZHxHNcqoRTK5y/Za5OxVEFYYXU96tmfNY/ xKdRC34rwqtOTblMnmol0/Nx28n/g43x1xSMZt3rBQN3Ebq3DZdq7iaWwQjLawNm8xrz flcbXXDuNYhL3IaZ+4wzpdz8ELOMnjHo0uabk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:references:in-reply-to:mime-version :thread-index:date:message-id:subject:to:content-type; bh=GpEiKXHNRMGeERKSTGwIBXcPZ8kXrTreqOveCcM+MaU=; b=Yee94XAUdWk7PKT5SPCeyDQsLcbN6xgUdYvDnamTBQnWeaMfYu+syx5j6jFfzsqeWH IzGaT0DjuvpMtMjsJYHN5r6fAFRn703uSbFrfF5Byvx44mHb5zvUzYSBK5kBhRKweR8q vYRtFMVlkEObwCsmBpYdl0Cguk5gq68qWQoJ3Zmq6hWiSPYZXIE1StC6lJ4XCVj7PWzO /YD9SaV7LH3QWsAeYBB81j4EaJuIbo/jOpIodZRrO0xv5vHY0anBemVG7pIU65KDyViJ 5KTuWf6x+CDF2SLbxPS2NcNxw7os4M6DFO7ipR8Pqe1pxo3nWljkITaLEcBLjBPDNP8M wNeQ== X-Gm-Message-State: ALoCoQlZGUVtFL9FE5P1b6PI55nbej0Q/eLWR/t28Dzr61e2Phv/YzaQ/57gc+Ppwit3qZU6YvW3ZTVRxj73NaSys3Fl5+nO6JszEpx6rEQdslPFKtY0fsw= X-Received: by 10.180.75.17 with SMTP id y17mr8837577wiv.3.1408883947756; Sun, 24 Aug 2014 05:39:07 -0700 (PDT) From: Karen Elisabeth Egede Nielsen References: In-Reply-To: MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQINWHZQWdkBp0KZmAHPIOVeQRGZvJtkfjcw Date: Sun, 24 Aug 2014 14:39:07 +0200 Message-ID: <937b7c688c454aa2faa3bf33e0d994cf@mail.gmail.com> To: gorry@erg.abdn.ac.uk, tsvwg@ietf.org, Yoshifumi Nishida Content-Type: text/plain; charset=UTF-8 X-DomainID: tieto.com Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/5q8gfKp5w_3hHQku8hcE9IVe9KY Subject: Re: [tsvwg] TSVWG Status update, August 2014. X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Aug 2014 12:39:12 -0000 Hi, > --- > draft-ietf-tsvwg-sctp-failover - Document Shepherd: James > Replaces: draft-nishida-tsvwg-sctp-failover > Individual-00 Presented in Prague, IETF-80. > - Understood not to conflict with draft-tuexen-tsvwg-sctp-multipath > - PF has been coded into FreeBSD [Karen] The feature is supported as well in Ericsson in-house SCTP SW implementation. The feature is partially implemented in Linux SCTP SW (July 2014) with the intent to implement full support in accordance with most recent version of the draft. > Adopted by WG 26/6/2012. [Milestone: Jul 2013, EXP] > DUE: March 2014. > DUE: Please comment on list. > --- [Karen] From the authors perspective we are looking for a WGLC assessment of this work. BR, Karen From nobody Mon Aug 25 14:26:20 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFDC71A038E for ; Mon, 25 Aug 2014 14:26:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.321 X-Spam-Level: * X-Spam-Status: No, score=1.321 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yflbrf_EqICm for ; Mon, 25 Aug 2014 14:26:13 -0700 (PDT) Received: from mail-wg0-x231.google.com (mail-wg0-x231.google.com [IPv6:2a00:1450:400c:c00::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5319E1A0381 for ; Mon, 25 Aug 2014 14:26:13 -0700 (PDT) Received: by mail-wg0-f49.google.com with SMTP id k14so13899942wgh.32 for ; Mon, 25 Aug 2014 14:26:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tieto.com; s=google; h=from:mime-version:thread-index:date:message-id:subject:to:cc :content-type:content-transfer-encoding; bh=a0RcnhC0sJvCdhvQoyitOImwPbVWNv9Vn5aUuVFQ9bg=; b=W8rKcNXARlW4IEuRlVkXzHdnY8psooiTrOBnOm9Nrd5avSQ2RZwGLPWzCBsfc2DK6k bPKKgmQi5ODekZM5B4miunqzsvl2aw9uxtX+4ePs7N5xXSVBkn/tVI1AwuNNLp7LYIQv 0f/+bTzAOu1M9iqt+SgxMI5ECxu3LIzWgpY9c= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:mime-version:thread-index:date:message-id :subject:to:cc:content-type:content-transfer-encoding; bh=a0RcnhC0sJvCdhvQoyitOImwPbVWNv9Vn5aUuVFQ9bg=; b=ebJVXS8SSGu1tWy7mo1RZM58/kNsyYhc84XI6Yx5i2aefGVJQVqKAWCA+EmL6TCYVB dv5Q74CfyrdanmrV4bClvElKwAyoa9YtBPiel8kUU7spVnbX56PtAHPazM6ujZ3/5dnp h3E4NyiLdwRFMuVooqmtK417vUVsu/+w4gyEvGd3Daepowr70oJNxJFN+ganwdeZNdiH tTGtgnADXISuxGQOpsErIWCWGBWANL0dkOx1TYGFbkz/FM0d9rr0o3N3OXxRsTQgj8PW ICcLRQS09xGR2BimobANDDr1+JuSrZDNJxnsoLnoof8UdVOQqIQpdc1KhknfKDqIpMrr K6Mg== X-Gm-Message-State: ALoCoQmE5VlCFdDjUmd90c3Mtl5VI9oiig2/Rv7p/uHzgy7cMdOp5HQi9MzmUyvPxX2kQdSSeZbQJTMicLamMyWaiYF8NvPmf5xAZQoMx803haN8wWoKdcY= X-Received: by 10.180.211.71 with SMTP id na7mr17415525wic.14.1409001971745; Mon, 25 Aug 2014 14:26:11 -0700 (PDT) From: Karen Elisabeth Egede Nielsen MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac/Aqy725mvL7qjhQAOhlSeunNHoow== Date: Mon, 25 Aug 2014 23:26:10 +0200 Message-ID: <505124209b8c450eb7a539ec36b5a358@mail.gmail.com> To: Michael Tuexen Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-DomainID: tieto.com Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/A4XaVNduvQePBKYEPMiIdAI2Mjg Cc: Randall Stewart , tsvwg@ietf.org Subject: Re: [tsvwg] draft-stewart-tsvwg-sctp-ndata-03.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Aug 2014 21:26:15 -0000 Hi Michael, Sorry for the late follow up. Please find some feedback inline below. Generally I should note that the section numbering in the more recent versions of the draft does not correspond to the section numbering of the version to which the comments were provided. Still I hope that we can make sense of the below.. BR, Karen > -----Original Message----- > From: Michael Tuexen [mailto:Michael.Tuexen@lurchi.franken.de] > Sent: 4. juli 2014 22:42 > To: Karen E. Egede Nielsen > Cc: Randall Stewart; tsvwg@ietf.org; Salvatore Loreto > Subject: Re: draft-stewart-tsvwg-sctp-ndata-03.txt > > On 05 Nov 2013, at 00:51, Karen E. Egede Nielsen > wrote: > > > Hi, > > > > Please accept the folowing comments to draft-stewart-tsvwg-sctp-ndata- > 03.txt. > > Please use as fit. > Hi Karen, > > thank you very much for your comments. I'm sorry for not responding > earlier... > See my comments in-line. > > Best regards > Michael > > > > General comments: > > ----------------------- > > > > The draft draft-stewart-tsvwg-sctp-ndata-03.txt, in my opinion, > > addresses an important limitation of SCTP message fragmentation The > > limitation is important to have removed in order to support large message > transfer by SCTP without detroying concurrent transmission of data with real- > time characteristics. > > > > The advanced stream scheduling modes, suggested in the draft, also > > seems very instrumental in order to instantiate different real time > characteristics on different streams. > > > > Title: Given the scheduling aspects included in the draft, one should > consider to adjust the title so that it better accommodate for the scheduling > parts. Actually stream scheduling seems to be main topic of the draft with > the new (or extended) data chunk format just a mean to support more > flexible (interleaved) scheduling of fragments. > The is correct. > > > > Something else: The =E2=80=9CN=E2=80=9D as =E2=80=9CNew=E2=80=9D in N-= DATA seems not so future-proof. > Perhaps E for word =E2=80=9CExtended=E2=80=9D (E-DATA) would be a better = naming ? > Possibly. But we are using N-DATA in several places... Will think about it. > > [Karen] A suggestion given at the tsvwg session at IETF 90 was I-data chunk where I is for interleaving. A different alternative is the E-data chunk where E is for extended. > > It should be clarified in the Introduction that the draft makes use of the > Supported Extension Parameter as defined in RFC5061. > Make sense. Done. > > > > Detailed Comments: > > --------------------------- > > > > Section 1.1: > > 1. It should be clarified that the draft defines a new data chunk option as > well as that it defines an advanced stream scheduler function and that these > are independent functions. > Correct. I agree. > > 2. It could be clarified that the intention is for the new data chunk to be > used for all data transmitted on a particular association (i.e., not only > fragments). > Done. > > 3. It could be clarified that the usage of the new data chunk will > differentiable on a per association basis and that an SCTP implementation as > such shall support coexistence of associations which use the existing data > chunk format and associations which use the new data chunk format. > Sure. Done. > > > > Section 3.1: > > 1. In the third paragraph that starts with =E2=80=9CSender side u= sage.. =E2=80=9D, it should > be clarified that the new data chunk is used for all data chunks and not for > only data chunks that need fragmentation. > Fixed. > > 2. The situation, when the peer does not support N-DATA but the user > request it, should preferably be elaborated on in this section or somewhere > else in the draft. Presumably then in this situation the SCTP layer simply uses > the legacy data chunk with its in-build limitations. However this should be > described. > Fixed. > > 3. Information should preferably be provided to UL about whether peer > supports usage of N-DATA. For a socket api compliant implementation such > information could possibly be provided in an extension of SCTP_STATUS ? > I would prefer to signal it in the SCTP_ASSOC_CHANGE indicating > SCTP_COMM_UP or SCTP_RESTART by using > SCTP_SUPPORTS_INTERLEAVING similar to SCTP_ASSOC_SUPPORTS_PR, > SCTP_ASSOC_SUPPORTS_AUTH, ... > However, this goes into the socket API section. > > [Karen] Yes I agree that the realization of the function over the socket api goes into the socket api section. The requirement to provision information to ULP about what was negotiated for the association is part of the substance of the function and should go here. Right ? > > Section 4.1 =E2=80=93 minor/editorial: > > > > 1. The text could be clarified so that it more clearly refers to =E2=80=9Cone-to- > many=E2=80=9D and to > > =E2=80=9Cone-to-one=E2=80=9D sockets. The text could also better descri= be the behaviour of > the socket option on each type. > Could you be more specific where information is missing? [Karen] Right now the text of section 4.1.2 says that the socket option SCTP_NDATA_ENABLE applies to future associations. Yes I can interpret this also for a one-to-one style socket but I would prefer to have this written out. Like what happens for a one-to-one socket; is this option rejected or ignored (?) on already established associations. I further think that one wants to cache (as for the number of streams) both what was negotiated as well as what was intended to be negotiated. If the SCTP_NDATA_ENABLE, when read, tells what was intended to be negotiated, then we need somewhere else (e.g. SCTP_STATUS) to read what got negotiated. > > 2. The second paragraph sentence: =E2=80=9CAn N-DATA chunk aware application > should also set the fragment interleave level to 2=E2=80=9D =E2=80=93 sho= uld refer to > appropriate option of RFC6458. > > > > > Section 4.1 =E2=80=93 substance: > > > > 1. I would like to press for that the ability to change the N-DATA setting > on current (established) associations is removed. It looks to open up for a > number of complexities both in SCTP layer as well as in O&M layer; E.g., if N- > DATA feature is disabled, what about retransmissions where original was > send as N-DATA. When the O&M operation is made, then how to control > when it takes effect in the SCTP layer in respect to data already in SND > buffer. Further the disabling only effectively can control the sending side. > These details would have to be described in draft and, secondly, > implemented, both of which could be somewhat of a challenge. Are there > some important use-cases that demands for this =E2=80=9Cflexibility=E2=80= =9D ? > This functionality isn't there. I agree completely with you. Isn't the text in > 4.1.1 on SCTP_NDATA_ENABLE clear on this? [Karen] The new text is much better. Section 4.2.1 still has the following: "and will also prevent current associations from producing N-DATA chunks for future large fragmented messages" Do you really want to have this ? I would not... > > 2. I believe that one NEED to have the possibility, on a per association > basis, to read whether the peer supports N-DATA or not. This regardless of > whether it be an association belonging > Isn't the notification good enough? You can't query ASCONF support, Stream > Reset, and so on. > This is currently only done via the notification. I'm open to discuss a generic > method... > > to a one-to-many socket or a one-to-one socket. Support for read via > socket api should be described in the draft. This may be provided via an > extension of SCTP_STATUS (?). Optionally one may also prescribe for such > information to be returned as part of an extension of RFC3873, > sctpAssocTable object. > Let's talk about MIB stuff in general in a separate document. We are lacking > MIB support for all SCTP extensions. If there is a real need in this, we should > think about updating the MIB RFC. Years ago, when I implemented it for > FreeBSD, I had a bunch of comments. > > 3. Situation with association restart on SCTP level should preferably be > described. > You get a new notification... [Karen] Fine :-) .. But what I want to know is the following: Can usage of N-DATA be re-negotiated during restart of association. Which setting of the local side dictates what should happen on a one-to-one association during restart. Will SCTP layer cache what originally was set in the SCTP_NDATA_ENABLE option and use this to guide re-negotiation during restart ? > > > > Section 4.1.2: > > > > > > 1. Would it be reasonable to specify a subset of the listed scheduling > options as something that an implementation that support N-DATA MUST > support and others as MAY or optional. Alternatively one may specify that at > least one of the options need to be supported ? > I would just look which constants are defined... We can make a statement > that not all implementation support all. > > 2. The SCTP_SS_FAIR_BANDWIDTH could be demanding from an > implementation perspective. > As will be the SCTP_SS_WEIGHTED_FAIR_QUEUEING... > > 3. It should be clarified that these scheduling options are applicable for > sending normal DATA chunks also when peer does not support usage of N- > DATA. > Yepp. I'll work on this while polishing/testing the implementation.. > > > > > > Possible addition to the draft content: (?) > > > > Possibly one could contemplate to include improvement of the receiver > side operation also. As follows: > > > > =C2=B7 The SCTP receive operation could be extended to allow fo= r > specification of read stream scheduling - possibly options =E2=80=93 to = start with (RS: > Read Scheduling): > > o SCTP_RS_FIRST_COME: The simple first-come, first-serve algorithm > > is selected by using this value. It just queues messages that are readable in > the order in which they have been received by the SCTP layer. > > o SCTP_RS_PRIORITY: SCTP operates with a number of receive queues > per association according to a number of priorities set. For each priority > queue simple first-come, first-serve algorithm is used .I.e., for each priority > queue messages are queued as readable in the order in which they have > been received by the SCTP layer .The priority can be assigned on a per > stream basis. Value 0 is default priority, higher values are higher priority (or > lower), lower values are lower priority (or higher). > > Select, poll (BSD) and epoll (Linux) mechanism must be extended to > support specification, and notification, of receiving readable event on a per > priority RCV queue basis. > As we discussed, I think this could go into a separate document... > > > > > > Editorial: > > > > Abstract: which which =C3=A0 which > > Section 2: FSN's are unsigned number =C3=A0 FSN's are unsigned numbers > Fixed. > > > > BR, Karen From nobody Tue Aug 26 09:03:57 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7AB41A00AA for ; Tue, 26 Aug 2014 09:03:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.099 X-Spam-Level: X-Spam-Status: No, score=0.099 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D69LXWU5X6cV for ; Tue, 26 Aug 2014 09:03:51 -0700 (PDT) Received: from mail-pa0-f51.google.com (mail-pa0-f51.google.com [209.85.220.51]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 544BB1A876E for ; Tue, 26 Aug 2014 09:03:51 -0700 (PDT) Received: by mail-pa0-f51.google.com with SMTP id ey11so24068610pad.10 for ; Tue, 26 Aug 2014 09:03:51 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-type:content-transfer-encoding:date :subject:to:message-id:mime-version; bh=VvvugWmsPGD/aABesc2Mo0QE1UtbX6d5UTaPSVLX1WA=; b=a0uK/DHmyDhvSC0eXjbcCGqiWy+kqjsrP5d3S7KJGpKNAUNCiPKrgqxbaT7d0BGMoV SgkGWJocBHjI8S0rF1Sops0MTiLB2pcHPvdph8TYF3oo0/cZSyb4hHjPx6ImJPsoP/2g h382+oWtAMY+MBeCi1TbkaczgfwXv1o8TMgYXBJJdiCb5A1mzD7HlqLkTw/nSzHM9m5q qSr1tcH+6yXfrGsB2jMe0A3CTA3SsRoAeVikSKl5F+jHve7e/VGiSy+5gNVyeZUg8m1m IV+6Xc2MKvCcQa9AwVPuTnJAWPv8s6a0HLzN+2r2S4L2KRk1g/zAle1D4rImDXUdYBUt 8EQw== X-Gm-Message-State: ALoCoQlNs/Wlmx2i6K27wUzoWBA6TVsHdv6dzMvMP3C7SlCwrVaQBuX97Nkj6P9M5op18qGS7nJO X-Received: by 10.70.140.163 with SMTP id rh3mr21897801pdb.53.1409069030843; Tue, 26 Aug 2014 09:03:50 -0700 (PDT) Received: from [10.1.2.95] ([64.125.103.162]) by mx.google.com with ESMTPSA id na4sm5305594pdb.96.2014.08.26.09.03.48 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 26 Aug 2014 09:03:49 -0700 (PDT) From: Caitlin Bestler Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Date: Tue, 26 Aug 2014 09:03:46 -0700 To: tsvwg@ietf.org Message-Id: Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/6HRLsR0UE5AGdOCHHBfQsFDKEw0 Subject: [tsvwg] Draft IETF message to disclose Transactional Multicast within Clusters X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Aug 2014 16:03:56 -0000 Nexenta has been developing a multicast based transport/storage protocol = for Object Clusters at Nexenta. This applies multicast datagrams to creation and = replication of Objects such as those supported by the Amazon S3 protocol. Creating = replicas of object payload on multiple servers is an inherent part of any storage cluster, = which makes multicast addressing very inviting. There are issues of congestion = control and reliability to settle, which we were able to do. However, we found that the existing protocols for controlling multicast = group membership (IGMP and MLD) are not suitable for our storage application. We doubt = this is unique to our application. It should apply to many clusters that have a need to = distribute transactional messages to dynamically selected subsets of a group within = a cluster to multiple known recipients. HPC clusters using MPI are also potential = users of transactional multicasting. Multicast repication over a VLAN for the internal = communications of a pNFS cluster is another potential application. This is just one example of = synchronizing cluster data where the synchronization does not replicate all of the shared data = with the entire cluster. But these are merely initial hunches, the purpose of this email = is to determine exactly how common the need for =93transactional multicast=94 is, and possibly = to incorporate the needs of other clusters, before submitting a draft. To be clear, this is a submission to the IETF process proposing enhanced = methods for controlling multicast group membership. This and later posts may make = reference to specific applications, including the Nexenta Replicast protocol for = multicast replication in our Cloud Copy-on-Write (CCOW) Object Cluster. Such examples are = merely for illustrative purposes. Any IETF standardization of the Replicast storage = protocols would be done via the Storm or NFS groups, and would require adoption of a = definition of Object Storage as a service before defining a specific protocol for providing = Object Storage services. What will be proposing is focused on the management of multicast groups, = specifically two additional methods for setting the membership of a multicast group which = can radically reduce the latency in setting up a group within a known cluster. The potential for such dramatic savings is that transactional messaging = within a cluster is a radically different use-case from traditional multicast. This covers a variety of factors: * How is the group Selected? * What are the endpoints that receive the messages? * What is the duration of the group? * Who are the potential members of the group? * How much latency does the application tolerate? Question 1: How is the Group Selected? In IGMP/MLD the membership of a multicast group is controlled by the = listeners joining and leaving the group. The sender does not control or even know the = recipients. This matches the multicast streaming use-case very well. However it does not match a = cluster that needs to distribute a transactional message to a subset of a known cluster. The target group is also assumed to be stable for a long sequence of = packets, such as streaming a video. The targeted applications direct transactions to a = subset of a stable group. One example of the need to distribute a transactional message to a = subset of a known cluster is replication within an object cluster. A set of targets has = been selected through an higher layer protocol. IGMP-style setup here adds excessive = latency to the process. The targets must be informed of their selection, they must = execute IGMP joins and confirm their joining to the source before the multicast delivery can = begin. Only replication of large storage assets can tolerate this setup penalty. A distributed computation may similarly have data that is relevant to a = specific set of recipients within the cluster. Having to replicate the transfer over = multiple unicast connections is undesirable, as is having to incur the latency of IGMP = setup. Two solutions will be proposed where a sender can form or select a = multicast group to match a set of targets, without requiring any extra interaction with = THOSE targets as long as the targets are already members of a pre-existing multicast group. = Allowing a sender to multicast to *any* set of IP addresses would clearly be unacceptable for = both security and network administration reasons. Question 2: What are the endpoints that receive the messages? For the specific storage protocol we were working on the desired = endpoints are virtual drives, not IP endpoints. A given storage server can determine which of = its virtual drives is being addressed solely from the destination multicast IP address. One of the questions for the mailing list is whether this is unique to = this storage protocol, or whether the ability to identify a multicast group as a set = of higher layer objects is generally desirable. Question 3: What is the duration of the group? IGMP/MLD is designed primarily for the multicast streaming use-case. A = group has an indefinite lifespan, and members come and go at any time during this = lifespan, which might be measured in minutes, hours or days. Transactional multicasting seeks to identify a multicast group for the = duration of sending a set of multicast datagrams related to a specific transaction. = Recipients either receive the entire set of datagrams or they do not. Multicast streaming = typically is transmitting error tolerant content, such as MPEG encoded material. Transaction = multicasting will typically transmit data with some form of validating signature that = allows each recipient to confirm full reception of the transaction. This obviously needs to be combined with applicable congestion control = strategies being deployed by the upper layer protocols. The Nexenta Replicast protocol = only does bulk transfers against reserved bandwidth, but there are probably as many = solutions for this problem as there are applications. Replicast relies upon IEEE I802.1 = Datacenter Bridging (DCB) protocols such as Priority Flow Control and Congestion = Notification to provide=20 no-drop service. The DCB protocols deal with the fine timing of = congestion avoidance, but require higher layer transport or application protocols to keep the = sustained traffic rates below the sustained capacity. Creating explicit = reservations for bulk transfers is the main method for accomplishing this. The important distinction between Replicast and conventional multicast = applications is that there is no need to dynamically adjust multicast forwarding tables = during the lifespan of a transaction, while IGMP and MLD are designed to allow the = addition and deletion of members while a multicast group is in use. This distinction = is not unique to Nexenta's Replicast storage application. Transactional replication is a = common element in cluster protocol design. The limited duration of a transactional multicast group implies that = there is no need for the multicast forwarding element to rebuild its forwarding tables after = it restarts. Any transaction in progress will have failed, and been retried by the = higher-layer protocol. Merely limiting the rate at which it fails and restarts is all that is = required of each forwarding element. Another implication is that there is no need for the forwarding elements = to rebuild the membership list of a transactional multicast group after the forwarding = element has been reset. The transactions using the forwarding element will all fail, and = be retried by a higher layer transport or application protocol. Assuming that forwarding = elements do not reset multiple times a minute this will have very limited impact on = overall application throughput. The duration of a transaction is application specific, but inherently = limited. A failed transaction will be retried at the application layer, so obviously it = has a duration=20 measured in seconds at the longest. Question 4: Who are the members of the group? IGMP/MLD is designed to allow any number of recipients to join or leave = a group at will. Transactional multicast requires that the group be identified as a small = subset of a pre-existing multicast group. Building forwarding rules that are a subset of forwarding rules for an = existing multicast group can done substantially faster than creating forwarding rules to = arbitrary and potentially previously unknown destinations. Question 5: How much latency does the application tolerate? While no application likes latency, multicast streaming is very tolerant = of setup latency. If the end application is viewing or listening to media, how many msecs = are required to subscribe to the group will not have a measurable impact to the end = user. For transactions in a cluster, however, every msec is delaying forward = progress. The time it takes to do an IGMP join would be a significant addition to the = latency of storing an object in an object cluster using SSD or other fast storage technology. Proposed Method 1: Set the multicast forwarding rules for pre-existing multicast forwarding = address X to be the subset of the forwarding rules for existing group Y required to = reach a specified member list. This is done by communicating the same instruction (above) to each = multicast forwarding network element. This can be done by unicast addressing with each of = them, or by=20 multicasting the instructions. Each multicast forwarder will set its multicast forwarding port set to = be the union of the unicast forwarding it has for the listed members, but result must be a = subset of the forwarding ports for the parent group. For example, consider an instruction is to create a transaction = multicast group I which is a subset of multicast group J to reach addresses A,B and C. Addresses A and B are attached to multicast forwarder X, while C is = attached to multicast forwarder Y. On forwarder X the forwarding rule for new group I contains: The forwarding port for A. The forwarding port for B. The forwarding port to forwarder Y (a hub link). This eventually = leads to C. While on forwarder Y the forwarding rule for the new group I will = contain: The forwarding port for forwarder X (a hub link). This = eventually leads to A and B. The forwarding port for C. Many ethernet switches already support command line and/or SNMP methods = of setting these multicast forwarding rules, but it is challenging for an application to = reliably apply the same changes using multiple vendor specific methods. Having a = standardized method of pushing the membership of a multicast group from the sender would be = desirable. Proposed Method 2: There is a large group of pre-configured multicast groups which are an = enumeration of the possible subsets of a master group. This will be a specific subset, such = as all combinations of 3 members for multicast group X. These groups are = enumerated and assuaged successive multicast addresses within a block. The sender first obtains exclusive permission to utilize a portion of = the reception capacity of each desire target, and then selects the multicast address = that will reach that group. In a straightforward enumeration of 3 members out of a group of 20, = there are 20*19*18/3*2 or 1040 possible groups. Typically the higher layer protocol will have = negotiated the right to send the transaction with the member prior to selecting the = multicast group. In making the final selection, the actual multicast group is selected and some offered targets are declined. Those 1040 possible groups can be enumerated in order (starting with M1, = M2 and M3 and ending with M18, M19 and M20) and assigned multicast addresses from N to = N+1039. When the transaction requires reaching M4, M5 and M19, you simply select = that group. Because exclusive rights to use multicasting to M4, M5 and M19 have = already been obtained through the higher layer protocol the group [M4,M5,M19] is already = exclusively claimed. These 1040 groups may be set up through any of the following means: * Traditional IGMP/MLD joining/leaving. * Setting static forwarding rules using SNMP MIBs and/or switch-specific = command line interfaces. Note that the wide-spread existence of command line = interfaces to custom set multicast forwarding rules is an indicator that there are existing = applications that find the exising IGMP/MLD protocols to be inadequate to fulfill = their needs. * Method 1 as described previously. Security Considerations The methods described here enable no sender to multicast messages to any = destination that was not already addressable by it. Therefore no new security = vulnerabilities are enabled by these techniques. Summary The proposal provides for two new methods to manage multicast group = membership, Thee are simple techniques, but provide a cohesive cluster-wide = approach to providing transactional multicasting. These techniques are better suited for = transactional multicasting that the existing methods, IGMP and MLD, which are oriented to the = streaming use-cases. Caitlin Bestler caitlin.bestler@nexenta.com cait@asomi.com From nobody Wed Aug 27 03:07:16 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1CE61A04B1; Wed, 27 Aug 2014 03:06:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DvLifyrV0veL; Wed, 27 Aug 2014 03:06:33 -0700 (PDT) Received: from out24-ams.mf.surf.net (out24-ams.mf.surf.net [145.0.1.24]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A8A71A0466; Wed, 27 Aug 2014 03:06:32 -0700 (PDT) Received: from EXEDGE02.ad.utwente.nl (exedge02.ad.utwente.nl [130.89.5.49]) by outgoing1-ams.mf.surf.net (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id s7RA6Uaq014491; Wed, 27 Aug 2014 12:06:30 +0200 Received: from EXMBX33.ad.utwente.nl (130.89.4.148) by EXEDGE02.ad.utwente.nl (130.89.5.49) with Microsoft SMTP Server (TLS) id 14.3.181.6; Wed, 27 Aug 2014 12:06:34 +0200 Received: from EXMBX31.ad.utwente.nl (130.89.4.146) by EXMBX33.ad.utwente.nl (130.89.4.148) with Microsoft SMTP Server (TLS) id 15.0.913.22; Wed, 27 Aug 2014 12:06:29 +0200 Received: from EXMBX31.ad.utwente.nl ([130.89.4.146]) by EXMBX31.ad.utwente.nl ([130.89.4.146]) with mapi id 15.00.0913.011; Wed, 27 Aug 2014 12:06:29 +0200 From: To: Thread-Topic: [tsvwg] Gen-art LC review: draft-ietf-tsvwg-rsvp-pcn-09 Thread-Index: AQHPvYC56TQhJvX6SEGWF3S8060py5vkQcrA Date: Wed, 27 Aug 2014 10:06:29 +0000 Message-ID: References: <53F659F7.3080106@nostrum.com> In-Reply-To: <53F659F7.3080106@nostrum.com> Accept-Language: nl-NL, nl-BE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.89.12.129] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Bayes-Prob: 0.0001 (Score 0, tokens from: utwente-out:default, base:default, @@RPTN) X-CanIt-Geo: ip=130.89.5.49; country=NL; region=Provincie Overijssel; city=Enschede; latitude=52.2195; longitude=6.8912; http://maps.google.com/maps?q=52.2195,6.8912&z=6 X-CanItPRO-Stream: utwente-out:default (inherits from utwente:default, base:default) X-Canit-Stats-ID: 0uMHK6u6J - 05abb4fd8678 - 20140827 (trained as not-spam) X-Scanned-By: CanIt (www . roaringpenguin . com) Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/MqxeP4wHXdVWPsKj4LODh0Ui6z0 Cc: gen-art@ietf.org, ietf@ietf.org, draft-ietf-tsvwg-rsvp-pcn.all@tools.ietf.org, tsvwg@ietf.org Subject: Re: [tsvwg] Gen-art LC review: draft-ietf-tsvwg-rsvp-pcn-09 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Aug 2014 10:06:45 -0000 Hi Robert, Thank you very much for your constructive comments! We will try to work them out as soon as possible! Best regards, Georgios > -----Original Message----- > From: tsvwg [mailto:tsvwg-bounces@ietf.org] On Behalf Of Robert Sparks > Sent: donderdag 21 augustus 2014 22:44 > To: General Area Review Team; ietf@ietf.org; tsvwg@ietf.org; draft-ietf- > tsvwg-rsvp-pcn.all@tools.ietf.org > Subject: [tsvwg] Gen-art LC review: draft-ietf-tsvwg-rsvp-pcn-09 >=20 > I am the assigned Gen-ART reviewer for this draft. For background on Gen- > ART, please see the FAQ at >=20 > . >=20 > Please resolve these comments along with any other Last Call comments you > may receive. >=20 > Document: draft-ietf-tsvwg-rsvp-pcn-09 > Reviewer: Robert Sparks > Review Date: 21 Aug 2014 > IETF LC End Date: 26 Aug 2014 > IESG Telechat date: 2 Oct 2014 >=20 > Summary: Ready (with nits) for publication as Experimental. >=20 > David's shepherd writeup points out that implementation and usage > experience is desired before producing a proposed standard. Are there any > points of concern about how this might behave (or misbehave) in a deploye= d > network that such experience would inform? If so, it would be useful to c= all > them out in the document. >=20 > It would be nicer if the document argued why there are no new security > considerations introduced by the new behavior defined in this draft, rath= er > than tacitly asserting that there aren't any. >=20 > The terminology section has lots of 2119 words in it. It's hard to tell w= hen > these have been copied from some other draft (and this is just restating > them) vs when this draft is introducing a new requirement. > Since a new requirement would likely be missed if it appeared only in a > terminology section, would it be feasible to make sure anything new is we= ll > covered in section 3 or 4 and remove 2119 from these definitions altogeth= er? >=20 > The rest of these comments are minor editorial nits: >=20 > Section 1.2, paragraph 3: "Intserv over Diffserv can operate over a stati= cally > provisioned Diffserv region or RSVP aware." is missing a a word somewhere= . >=20 > Section 1.2 paragraph 4: "By using multiple aggregate reservations for th= e > same PHB allows enforcement of the different preemption priorities within > the aggregation region." doesn't parse. Should the initial "By" > be deleted? >=20 > The definition for PCN-domain is very close to circular. Perhaps some wor= ds > can be removed? >=20 >=20 From nobody Thu Aug 28 10:02:38 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C26E1A876B for ; Thu, 28 Aug 2014 10:02:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.702 X-Spam-Level: X-Spam-Status: No, score=-0.702 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VS82YehilKV0 for ; Thu, 28 Aug 2014 10:02:32 -0700 (PDT) Received: from mail-pa0-f42.google.com (mail-pa0-f42.google.com [209.85.220.42]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 806AE1A8754 for ; Thu, 28 Aug 2014 10:02:32 -0700 (PDT) Received: by mail-pa0-f42.google.com with SMTP id lf10so3278822pab.15 for ; Thu, 28 Aug 2014 10:02:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:content-transfer-encoding:message-id:references:to; bh=Iq2qbt2/e1dQv648OOxRV0A0VaHDmKU80nDvLw4l18c=; b=KXYBO1Qavf8uTqE+F70gaM+NtQKjacAFFA5CF6rDkBTWRAXHldaj1xbsR4m6rBSpR6 joZcO+Mq6lZYnKtUanh0tn4aiqyI9/U0WQojRbLtASkemR4oZedAdBhbmsvbzfYf5478 Zv/bttUWPpmjlXlhT8wQDB91fTPqSI4d6Je+t2XP6zS+tOSGdThfA/wAAOBE0MOl6wFd LEhn4TRg2lNd1XPoEwtviYks9XcW+s1BYfw8YmgKzksLYtRGFs5/NRqG8XWDQvK8asy/ JkAmBxfj4TXn+XFkB0FxDNlY7MfSLNPPK/jYu/HQ9hsLPNBUXo77qrnFqz8iLoalrUcl pIcQ== X-Gm-Message-State: ALoCoQmc2fwXtsEM0Uj385kPKpW6xt/LvoLOEBeSvLBoUxt72h6GQf5jJv8NPJvE1Srn6fOYhVkR X-Received: by 10.68.94.226 with SMTP id df2mr7834260pbb.122.1409245348579; Thu, 28 Aug 2014 10:02:28 -0700 (PDT) Received: from [10.1.2.95] ([64.125.103.162]) by mx.google.com with ESMTPSA id ov5sm4046898pbc.85.2014.08.28.10.02.26 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 28 Aug 2014 10:02:27 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Caitlin Bestler In-Reply-To: Date: Thu, 28 Aug 2014 10:02:26 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Dave Taht , tsvwg@ietf.org X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/FCn5CD9bCvM1au4P-G6AtCJR7NY Subject: Re: [tsvwg] Transactional Multicast within Clusters X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Aug 2014 17:02:35 -0000 On Aug 26, 2014, at 8:43 PM, Dave Taht wrote: > This made my head hurt. Got code? This is a very distributed algorithm. Actual code would be very = dependent on implementation specifics at each of the execution locations. But to break this down, there are four relevant locations in this = protocol: 1) The sender 2) The data plane forwarder of multicast frames/packets in the = switch/mrouter. 3)The software which updates the control data that the data plane = forwarder uses. This may be a processor that is part of the switch/mrouter. = Concieably this could be built =93in-line=94 in the forwarding chip, but that is not required = and is probably not desirable. The amount of logic that can be considered trivial grows every year, = so I don=92t want to state that it would *never* be done in-line, but I wouldn=92t want to buy = such a switch anytime soon. 4) The receiver. Something that I neglected to highlight in the first message is that 2) = is unchanged from existing switches/mrouters. This was a major constraint on the design, = but it can be so obvious when your working on it that you can forget to state it. The detailed logic example for Method 1 provide in the original post = applies to 3) the forwarder-associated editing of the data used by the data plane to control multicast = forwarding. >=20 >>=20 >> On forwarder X the forwarding rule for new group I contains: >> The forwarding port for A. >> The forwarding port for B. >> The forwarding port to forwarder Y (a hub link). This = eventually leads to C. >>=20 >> While on forwarder Y the forwarding rule for the new group I will = contain: >> The forwarding port for forwarder X (a hub link). This = eventually leads to A and B. >> The forwarding port for C. >>=20 This assumes the common data plane forwarding model: * VLAN ID + multicast address indexes to a set of ports. The frame is = forwarded on all of those ports except the port the frame arrived upon. So the forwarding port set to reach [A,B,C] is the union of the port = sets for [A],[B] and [C]. This is done when the dynamic transactional multicast group is set, not = on a per frame/packet basis. For method 1 the sender and the receivers have agreed to transmit a = transaction on transaction multicast group X, and that the membership of the transactional group will be [A,B,C]. Rather than having A,B and C = use IGMP/MLD to *join* the group, the sender uses method 1 to *push* the membership of the group to the relevant switches/mrouters. Method 2 has the same two layer approach. The setup command is just more = ambitious. It is creating a large set of transactional multicast groups to cover = every legitimate set of targets within an existing multicast group. For example, all combinations of 3 = members of a 10 member reference group. One implementation would be as follows: t_group =3D base_t_group do set forwarding rule for t_group to union of forwarding = ports for t_group=92s members t_group =3D t_group + 1 while permuting membership yields a new combination With method 2 the sender uses the master group (referred to as the = =93Negotiating Group=94 in Nexenta=92s Replicast protocol) to announce = which of the pre-existing transactional_groups will be used to complete a = given transaction. That transctional group is now associated with the transaction because each of the receivers has already granted some form = of exclusive right to multicast to it for a specific overlapping=20 duration. This may be exclusive to the port/VLAN, or could conceivably = be for a more specific scope. This is dependent on the higher layer protocol that is using these new methods for creating = transactional multicast groups. =09 >>=20 >>=20 >> Caitlin Bestler >> caitlin.bestler@nexenta.com >> cait@asomi.com >>=20 >>=20 >=20 From nobody Thu Aug 28 11:07:07 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87F741A889D for ; Thu, 28 Aug 2014 11:07:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KWLK6ScuQhJZ for ; Thu, 28 Aug 2014 11:07:00 -0700 (PDT) Received: from mail-oa0-x22b.google.com (mail-oa0-x22b.google.com [IPv6:2607:f8b0:4003:c02::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49CBF1A0B79 for ; Thu, 28 Aug 2014 11:07:00 -0700 (PDT) Received: by mail-oa0-f43.google.com with SMTP id jd19so910516oac.16 for ; Thu, 28 Aug 2014 11:06:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=ufKnzDcr1LZPbuUvVpEkl0sm5IRUN/ZQQ0MqIwqvuJA=; b=GUkpSlNCOSDNcTPdNh7s8GJt4doeqQDsGv6QXskSnbZTDcq+muku+ftPf4Pixzb3Sh YCdHkfamhFgbS8eEaA+ipEXF1K9noZGj/+lM+khaZGouVE5KFHlSbHOlPwO4DXcL4BgN KF8g4khW7T4fgVMoJxUGscbuxPOvqe+CAHqr8Lq59cf1CufGiRzuBTDHM+BoyV0DaImX ABOBVrSHRip+BlMR6K9Z0yNpZXQvZywt528OstF36NqpUqi2Y83HZWyHNo10UtxvzjBX gacqNQnTVhmnl78lbxugO6BYhZNZevgSa72091PwoD4JI4r0oI8bhYUWz7ZW53uOv71i akAg== MIME-Version: 1.0 X-Received: by 10.60.115.133 with SMTP id jo5mr5307703oeb.39.1409249219713; Thu, 28 Aug 2014 11:06:59 -0700 (PDT) Received: by 10.202.93.69 with HTTP; Thu, 28 Aug 2014 11:06:59 -0700 (PDT) In-Reply-To: References: Date: Thu, 28 Aug 2014 11:06:59 -0700 Message-ID: From: Dave Taht To: Caitlin Bestler Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/iQJ427K1VT-zoa9lDwsBItQ87n4 Cc: "tsvwg@ietf.org" Subject: Re: [tsvwg] Transactional Multicast within Clusters X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Aug 2014 18:07:04 -0000 On Thu, Aug 28, 2014 at 10:02 AM, Caitlin Bestler wrote: > > On Aug 26, 2014, at 8:43 PM, Dave Taht wrote: > >> This made my head hurt. Got code? > > This is a very distributed algorithm. Actual code would be very dependent= on implementation specifics > at each of the execution locations. Point being it's easier to grok with an example in front of me. Running code and rough consensus and all that. The main multicast transfer protocol I work with is uftp, which relies on IGMP also, does not require any changes at the switch level (relies on an application level proxy to forward across domains, which, could, indeed, run on a switch), and uses tcp-friendly techniques to do its job. (see: http://uftp-multicast.sourceforge.net/ for details of the app, protocol, and methods) How does the intent and practice differ for your protocol vs uftp? > > But to break this down, there are four relevant locations in this protoco= l: > > 1) The sender > 2) The data plane forwarder of multicast frames/packets in the switch/mro= uter. > 3)The software which updates the control data that the data plane forward= er uses. > This may be a processor that is part of the switch/mrouter. Concieabl= y this could be > built =E2=80=9Cin-line=E2=80=9D in the forwarding chip, but that is n= ot required and is probably not desirable. > The amount of logic that can be considered trivial grows every year, s= o I don=E2=80=99t want to state > that it would *never* be done in-line, but I wouldn=E2=80=99t want to = buy such a switch anytime soon. > 4) The receiver. > > Something that I neglected to highlight in the first message is that 2) i= s unchanged from > existing switches/mrouters. This was a major constraint on the design, bu= t it can be so > obvious when your working on it that you can forget to state it. > > > The detailed logic example for Method 1 provide in the original post appl= ies to 3) the forwarder-associated > editing of the data used by the data plane to control multicast forwardin= g. > >> >>> >>> On forwarder X the forwarding rule for new group I contains: >>> The forwarding port for A. >>> The forwarding port for B. >>> The forwarding port to forwarder Y (a hub link). This eventually= leads to C. >>> >>> While on forwarder Y the forwarding rule for the new group I will conta= in: >>> The forwarding port for forwarder X (a hub link). This eventuall= y leads to A and B. >>> The forwarding port for C. >>> > > This assumes the common data plane forwarding model: > * VLAN ID + multicast address indexes to a set of ports. The frame is for= warded on all of those ports except the port the frame arrived upon. > > So the forwarding port set to reach [A,B,C] is the union of the port set= s for [A],[B] and [C]. > > This is done when the dynamic transactional multicast group is set, not o= n a per frame/packet basis. > > For method 1 the sender and the receivers have agreed to transmit a trans= action on transaction multicast group X, and that the membership > of the transactional group will be [A,B,C]. Rather than having A,B and C = use IGMP/MLD to *join* the group, the sender uses method 1 to > *push* the membership of the group to the relevant switches/mrouters. > > > Method 2 has the same two layer approach. The setup command is just more = ambitious. > It is creating a large set of transactional multicast groups to cover eve= ry legitimate set of targets > within an existing multicast group. For example, all combinations of 3 m= embers of a 10 member > reference group. > > One implementation would be as follows: > > t_group =3D base_t_group > do > set forwarding rule for t_group to union of forwarding po= rts for t_group=E2=80=99s members > t_group =3D t_group + 1 > while permuting membership yields a new combination > > With method 2 the sender uses the master group (referred to as the =E2=80= =9CNegotiating Group=E2=80=9D in Nexenta=E2=80=99s Replicast protocol) to a= nnounce which > of the pre-existing transactional_groups will be used to complete a given= transaction. That transctional group is now associated with the > transaction because each of the receivers has already granted some form o= f exclusive right to multicast to it for a specific overlapping > duration. This may be exclusive to the port/VLAN, or could conceivably be= for a more specific scope. This is dependent on the higher > layer protocol that is using these new methods for creating transactional= multicast groups. > > > >>> >>> >>> Caitlin Bestler >>> caitlin.bestler@nexenta.com >>> cait@asomi.com >>> >>> >> > --=20 Dave T=C3=A4ht http://www.bufferbloat.net From nobody Thu Aug 28 11:19:47 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D4301A886D for ; Thu, 28 Aug 2014 11:19:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kg3yW-JtMQqa for ; Thu, 28 Aug 2014 11:19:43 -0700 (PDT) Received: from mail-pa0-f41.google.com (mail-pa0-f41.google.com [209.85.220.41]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BFC851A6ED9 for ; Thu, 28 Aug 2014 11:19:43 -0700 (PDT) Received: by mail-pa0-f41.google.com with SMTP id lj1so3667131pab.0 for ; Thu, 28 Aug 2014 11:19:43 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=ox6mkGJMQmrBUF/h0gfTjwtN3egF8QA3fj5mUQ5PBLM=; b=AceQEGzJXpc7MXSkqndJ982jUWenCUXVi2V+U/pHye/b9xUvXVSL3wtbQvglaJO84J XYwEAUxkJGiGspmFJ462kwrVVwcJXX4UPLaAG73eSpDD5Bxd0I8sJK1qFT3CWNJZCtFK wJtU7OS/asFJvbrhiuP/ni1V9xa6PSaxPiqBXegQY9HS9NxUL76cOKFF68Hm+/vvxBGA 1t5L0kYVDJ08iq9Bnb9qcbfX+k0ERuja2HEgOijj92Bv/bxp5zAM5Zyj6p+l/ixMvJwo Hm8LJ+Rcuxt4sUa/OJ+Ag9eCtDGQ6opq9TrY8SGWox6rJLeJhiNByW1izuyis1Wx/PBM mp4g== X-Gm-Message-State: ALoCoQlXqyid0ewwSjIzDRNPfwPgiHlqH0QbWWU3jj3TRyNiwFS5V6TREmJx+8u6hwKh64PXKDN9 X-Received: by 10.66.164.9 with SMTP id ym9mr8430584pab.139.1409249983348; Thu, 28 Aug 2014 11:19:43 -0700 (PDT) Received: from [10.1.2.95] ([64.125.103.162]) by mx.google.com with ESMTPSA id ft9sm6482624pdb.24.2014.08.28.11.19.41 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 28 Aug 2014 11:19:42 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_57DBB5F2-32F3-46F1-B6AD-587CF194CE62" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Caitlin Bestler In-Reply-To: Date: Thu, 28 Aug 2014 11:19:39 -0700 Message-Id: References: To: Dave Taht X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/1gvuCgdLWEn2mB-Fq8FMMi39jlA Cc: "tsvwg@ietf.org" Subject: Re: [tsvwg] Transactional Multicast within Clusters X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Aug 2014 18:19:45 -0000 --Apple-Mail=_57DBB5F2-32F3-46F1-B6AD-587CF194CE62 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Aug 28, 2014, at 11:06 AM, Dave Taht wrote: > On Thu, Aug 28, 2014 at 10:02 AM, Caitlin Bestler > wrote: >>=20 >> On Aug 26, 2014, at 8:43 PM, Dave Taht wrote: >>=20 >>> This made my head hurt. Got code? >>=20 >> This is a very distributed algorithm. Actual code would be very = dependent on implementation specifics >> at each of the execution locations. >=20 > Point being it's easier to grok with an example in front of me. > Running code and rough consensus and all that. >=20 > The main multicast transfer protocol I work with is uftp, which relies > on IGMP also, does not require any changes at the switch level (relies > on an application level proxy to forward across domains, which, could, > indeed, run on a switch), and uses tcp-friendly techniques to do its > job. >=20 > (see: http://uftp-multicast.sourceforge.net/ for details of the app, > protocol, and methods) >=20 > How does the intent and practice differ for your protocol vs uftp? The key difference is that transactional multicasting is aimed at = performing multiple high bandwidth transfers within a single cluster = concurrently. Within the scope of the cluster the application protocol can be much = more aggressive at running the transfers at near wire speed by relying on the combination of a reservation and 802.1 DCB protocols such as PFC, = ETS and CN. With slower long-haul file transfers (=93over the web=94 versus =93inside = a cluster=94) the overhead of IGMP/MLD group creation is tolerable. UFTP *could* use the techniques described here, if the scope was doing = transfers within a pre-existing group. Support for long-haul multicast is very thin outside of data centers, however, so I doubt this = would make sense for most UFTP users. The example cited of doing replication within a pNFS cluster is closer = to the Replicast object cluster that led to our developing transactional multicasting. Like uftp, you are transferring to a set of known members = that are selected by the sender, and the selection is from within a known set of destinations. --Apple-Mail=_57DBB5F2-32F3-46F1-B6AD-587CF194CE62 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
On Aug 28, 2014, at 11:06 AM, Dave = Taht <dave.taht@gmail.com> = wrote:

On Thu, Aug 28, 2014 at 10:02 AM, = Caitlin Bestler
<caitlin.bestler@nexenta.com> wrote:

On Aug 26, 2014, at 8:43 = PM, Dave Taht <dave.taht@gmail.com> = wrote:

This made my head hurt. Got = code?

This is a very distributed algorithm. Actual = code would be very dependent on implementation specifics
at each of = the execution locations.

Point being it's easier to = grok with an example in front of me.
Running code and rough consensus = and all that.

The main multicast transfer protocol I work with is = uftp, which relies
on IGMP also, does not require any changes at the = switch level (relies
on an application level proxy to forward across = domains, which, could,
indeed, run on a switch), and uses = tcp-friendly techniques to do its
job.

(see: http://uftp-multicast.sour= ceforge.net/ for = details of the app,
protocol, and methods)

How does the intent = and practice differ for your protocol vs = uftp?

The key difference is that = transactional multicasting is aimed at performing multiple high = bandwidth transfers within a single cluster = concurrently.

Within the scope of the cluster = the application protocol can be much more aggressive at running the = transfers at near wire speed by relying
on the combination of = a reservation and 802.1 DCB protocols such as PFC, ETS and = CN.

With slower long-haul file transfers (=93over= the web=94 versus =93inside a cluster=94) the overhead of IGMP/MLD = group creation is tolerable.
UFTP *could* use the techniques = described here, if the scope was doing transfers within a pre-existing = group. Support for long-haul
multicast is very thin outside of = data centers, however, so I doubt this would make sense for most UFTP = users.

The example cited of doing replication = within a pNFS cluster is closer to the Replicast object cluster that led = to our developing transactional
multicasting. Like uftp, you = are transferring to a set of known members that are selected by the = sender, and the selection is from within a
known set of = destinations.

= --Apple-Mail=_57DBB5F2-32F3-46F1-B6AD-587CF194CE62-- From nobody Thu Aug 28 11:26:08 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0B381A8911 for ; Thu, 28 Aug 2014 11:26:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.969 X-Spam-Level: X-Spam-Status: No, score=-4.969 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SqcNYGidLaBD for ; Thu, 28 Aug 2014 11:26:03 -0700 (PDT) Received: from mailuogwdur.emc.com (mailuogwdur.emc.com [128.221.224.79]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D50C1A890F for ; Thu, 28 Aug 2014 11:26:02 -0700 (PDT) Received: from maildlpprd51.lss.emc.com (maildlpprd51.lss.emc.com [10.106.48.155]) by mailuogwprd52.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s7SIQ0YD011813 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 28 Aug 2014 14:26:01 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd52.lss.emc.com s7SIQ0YD011813 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1409250361; bh=+TL5jnU48HAMmwbKnkP5NydUvx8=; h=From:To:Date:Subject:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=dQfQYZ6jL36nRGMfkABpoRgRt71cwjZPzNUJXHv6K6w8FHJIzxJOOmN37BD8lP4wb 9WO2WJEem44vQ1MTa7rfKfR5gqxVH+PnuZ4mGOc8roTOCyKmLCwOCKqqDMbf5Y9CHk 0ZChSVi9uzgOMXvqsLvbS4DPfkN1/iMoVVk2VqeE= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd52.lss.emc.com s7SIQ0YD011813 Received: from mailusrhubprd52.lss.emc.com (mailusrhubprd52.lss.emc.com [10.106.48.25]) by maildlpprd51.lss.emc.com (RSA Interceptor); Thu, 28 Aug 2014 14:25:50 -0400 Received: from mxhub03.corp.emc.com (mxhub03.corp.emc.com [10.254.141.105]) by mailusrhubprd52.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s7SIPlrf019766 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 28 Aug 2014 14:25:52 -0400 Received: from mx15a.corp.emc.com ([169.254.1.175]) by mxhub03.corp.emc.com ([10.254.141.105]) with mapi; Thu, 28 Aug 2014 14:24:56 -0400 From: "Black, David" To: Caitlin Bestler , "tsvwg@ietf.org" Date: Thu, 28 Aug 2014 14:24:55 -0400 Thread-Topic: [tsvwg] Draft IETF message to disclose Transactional Multicast within Clusters Thread-Index: Ac/BR2DAh2rWHLgFRzCtOS+jqthmNABpOJXg Message-ID: <8D3D17ACE214DC429325B2B98F3AE712077BC667E3@MX15A.corp.emc.com> 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-Sentrion-Hostname: mailusrhubprd52.lss.emc.com X-RSA-Classifications: DLM_1, public Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/LB4cMWdCmjHEDX7uFva1ZrNHU2Q Subject: Re: [tsvwg] Draft IETF message to disclose Transactional Multicast within Clusters X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Aug 2014 18:26:06 -0000 Caitlin, The interest is appreciated, but this message itself is long enough that it also would benefit from being written up and submitted as an Internet Draft= , among other things because multicast work and interest in multicast extends well beyond the tsvwg WG and the transport area. Thanks, --David (tsvwg WG co-chair) > -----Original Message----- > From: tsvwg [mailto:tsvwg-bounces@ietf.org] On Behalf Of Caitlin Bestler > Sent: Tuesday, August 26, 2014 12:04 PM > To: tsvwg@ietf.org > Subject: [tsvwg] Draft IETF message to disclose Transactional Multicast w= ithin > Clusters >=20 > Nexenta has been developing a multicast based transport/storage protocol = for Object > Clusters at Nexenta. This applies multicast datagrams to creation and rep= lication of > Objects such as those supported by the Amazon S3 protocol. Creating repli= cas of object > payload on multiple servers is an inherent part of any storage cluster, w= hich makes > multicast addressing very inviting. There are issues of congestion contr= ol and > reliability to settle, which we were able to do. >=20 > However, we found that the existing protocols for controlling multicast g= roup membership > (IGMP and MLD) are not suitable for our storage application. We doubt th= is is unique to > our application. It should apply to many clusters that have a need to dis= tribute > transactional messages to dynamically selected subsets of a group within = a cluster to > multiple known recipients. HPC clusters using MPI are also potential user= s of transactional > multicasting. Multicast repication over a VLAN for the internal communica= tions of a pNFS > cluster is another potential application. This is just one example of syn= chronizing cluster > data where the synchronization does not replicate all of the shared data = with the entire > cluster. But these are merely initial hunches, the purpose of this email = is to determine exactly > how common the need for "transactional multicast" is, and possibly to inc= orporate the needs > of other clusters, before submitting a draft. >=20 > To be clear, this is a submission to the IETF process proposing enhanced = methods for > controlling multicast group membership. This and later posts may make ref= erence to > specific applications, including the Nexenta Replicast protocol for multi= cast replication > in our Cloud Copy-on-Write (CCOW) Object Cluster. Such examples are merel= y for > illustrative purposes. Any IETF standardization of the Replicast storage = protocols would > be done via the Storm or NFS groups, and would require adoption of a defi= nition of Object > Storage as a service before defining a specific protocol for providing Ob= ject Storage > services. >=20 > What will be proposing is focused on the management of multicast groups, = specifically two > additional methods for setting the membership of a multicast group which = can radically > reduce the latency in setting up a group within a known cluster. >=20 > The potential for such dramatic savings is that transactional messaging w= ithin a cluster > is a radically different use-case from traditional multicast. > This covers a variety of factors: > * How is the group Selected? > * What are the endpoints that receive the messages? > * What is the duration of the group? > * Who are the potential members of the group? > * How much latency does the application tolerate? >=20 >=20 > Question 1: How is the Group Selected? >=20 > In IGMP/MLD the membership of a multicast group is controlled by the list= eners > joining and > leaving the group. The sender does not control or even know the recipient= s. > This matches > the multicast streaming use-case very well. However it does not match a > cluster that needs > to distribute a transactional message to a subset of a known cluster. >=20 > The target group is also assumed to be stable for a long sequence of pack= ets, > such as > streaming a video. The targeted applications direct transactions to a sub= set > of a stable group. >=20 > One example of the need to distribute a transactional message to a subset= of a > known > cluster is replication within an object cluster. A set of targets has bee= n > selected > through an higher layer protocol. IGMP-style setup here adds excessive la= tency > to the > process. The targets must be informed of their selection, they must execu= te > IGMP joins and > confirm their joining to the source before the multicast delivery can beg= in. > Only > replication of large storage assets can tolerate this setup penalty. >=20 > A distributed computation may similarly have data that is relevant to a > specific set of > recipients within the cluster. Having to replicate the transfer over mult= iple > unicast > connections is undesirable, as is having to incur the latency of IGMP set= up. >=20 > Two solutions will be proposed where a sender can form or select a multic= ast > group to > match a set of targets, without requiring any extra interaction with THOS= E > targets as long > as the targets are already members of a pre-existing multicast group. All= owing > a sender to > multicast to *any* set of IP addresses would clearly be unacceptable for = both > security and > network administration reasons. >=20 >=20 >=20 > Question 2: What are the endpoints that receive the messages? >=20 > For the specific storage protocol we were working on the desired endpoint= s are > virtual > drives, not IP endpoints. A given storage server can determine which of i= ts > virtual drives > is being addressed solely from the destination multicast IP address. >=20 > One of the questions for the mailing list is whether this is unique to th= is > storage > protocol, or whether the ability to identify a multicast group as a set o= f > higher layer > objects is generally desirable. >=20 >=20 >=20 > Question 3: What is the duration of the group? >=20 > IGMP/MLD is designed primarily for the multicast streaming use-case. A gr= oup > has an > indefinite lifespan, and members come and go at any time during this life= span, > which might > be measured in minutes, hours or days. >=20 > Transactional multicasting seeks to identify a multicast group for the > duration of sending > a set of multicast datagrams related to a specific transaction. Recipient= s > either receive > the entire set of datagrams or they do not. Multicast streaming typically= is > transmitting > error tolerant content, such as MPEG encoded material. Transaction > multicasting will > typically transmit data with some form of validating signature that allow= s > each recipient > to confirm full reception of the transaction. >=20 > This obviously needs to be combined with applicable congestion control > strategies being > deployed by the upper layer protocols. The Nexenta Replicast protocol onl= y > does bulk > transfers against reserved bandwidth, but there are probably as many solu= tions > for this > problem as there are applications. Replicast relies upon IEEE I802.1 > Datacenter Bridging > (DCB) protocols such as Priority Flow Control and Congestion Notification= to > provide > no-drop service. The DCB protocols deal with the fine timing of congestio= n > avoidance, > but require higher layer transport or application protocols to keep the > sustained > traffic rates below the sustained capacity. Creating explicit reservation= s for > bulk > transfers is the main method for accomplishing this. >=20 > The important distinction between Replicast and conventional multicast > applications is > that there is no need to dynamically adjust multicast forwarding tables d= uring > the > lifespan of a transaction, while IGMP and MLD are designed to allow the > addition and > deletion of members while a multicast group is in use. This distinction i= s not > unique to > Nexenta's Replicast storage application. Transactional replication is a c= ommon > element in cluster protocol design. >=20 > The limited duration of a transactional multicast group implies that ther= e is > no need for > the multicast forwarding element to rebuild its forwarding tables after i= t > restarts. Any > transaction in progress will have failed, and been retried by the higher-= layer > protocol. > Merely limiting the rate at which it fails and restarts is all that is > required of each > forwarding element. >=20 > Another implication is that there is no need for the forwarding elements = to > rebuild the > membership list of a transactional multicast group after the forwarding > element has been > reset. The transactions using the forwarding element will all fail, and b= e > retried by a > higher layer transport or application protocol. Assuming that forwarding > elements do not > reset multiple times a minute this will have very limited impact on overa= ll > application > throughput. >=20 > The duration of a transaction is application specific, but inherently lim= ited. > A failed > transaction will be retried at the application layer, so obviously it has= a > duration > measured in seconds at the longest. >=20 >=20 >=20 > Question 4: Who are the members of the group? >=20 > IGMP/MLD is designed to allow any number of recipients to join or leave a > group at will. >=20 > Transactional multicast requires that the group be identified as a small > subset of a > pre-existing multicast group. >=20 > Building forwarding rules that are a subset of forwarding rules for an > existing multicast > group can done substantially faster than creating forwarding rules to > arbitrary and > potentially previously unknown destinations. >=20 >=20 >=20 > Question 5: How much latency does the application tolerate? >=20 > While no application likes latency, multicast streaming is very tolerant = of > setup latency. > If the end application is viewing or listening to media, how many msecs a= re > required to > subscribe to the group will not have a measurable impact to the end user. >=20 > For transactions in a cluster, however, every msec is delaying forward > progress. The time > it takes to do an IGMP join would be a significant addition to the latenc= y of > storing an > object in an object cluster using SSD or other fast storage technology. >=20 >=20 >=20 > Proposed Method 1: >=20 > Set the multicast forwarding rules for pre-existing multicast forwarding > address X to be > the subset of the forwarding rules for existing group Y required to reach= a > specified > member list. >=20 > This is done by communicating the same instruction (above) to each multic= ast > forwarding > network element. This can be done by unicast addressing with each of the= m, or > by > multicasting the instructions. >=20 > Each multicast forwarder will set its multicast forwarding port set to be= the > union of the > unicast forwarding it has for the listed members, but result must be a su= bset > of the > forwarding ports for the parent group. >=20 > For example, consider an instruction is to create a transaction multicast > group I which is > a subset of multicast group J to reach addresses A,B and C. >=20 > Addresses A and B are attached to multicast forwarder X, while C is attac= hed > to multicast > forwarder Y. >=20 > On forwarder X the forwarding rule for new group I contains: > The forwarding port for A. > The forwarding port for B. > The forwarding port to forwarder Y (a hub link). This eventually leads > to C. >=20 > While on forwarder Y the forwarding rule for the new group I will contain= : > The forwarding port for forwarder X (a hub link). This eventually leads > to A and B. > The forwarding port for C. >=20 > Many ethernet switches already support command line and/or SNMP methods o= f > setting these > multicast forwarding rules, but it is challenging for an application to > reliably apply the > same changes using multiple vendor specific methods. Having a standardize= d > method of > pushing the membership of a multicast group from the sender would be > desirable. >=20 >=20 >=20 > Proposed Method 2: >=20 > There is a large group of pre-configured multicast groups which are an > enumeration of the > possible subsets of a master group. This will be a specific subset, such = as > all > combinations of 3 members for multicast group X. These groups are enumera= ted > and assuaged > successive multicast addresses within a block. >=20 > The sender first obtains exclusive permission to utilize a portion of the > reception > capacity of each desire target, and then selects the multicast address th= at > will reach > that group. >=20 > In a straightforward enumeration of 3 members out of a group of 20, there= are > 20*19*18/3*2 > or 1040 possible groups. Typically the higher layer protocol will have > negotiated the > right to send the transaction with the member prior to selecting the mult= icast > group. In > making the final selection, the actual multicast group is > selected and some offered targets are declined. >=20 > Those 1040 possible groups can be enumerated in order (starting with M1, = M2 > and M3 and > ending with M18, M19 and M20) and assigned multicast addresses from N to > N+1039. >=20 > When the transaction requires reaching M4, M5 and M19, you simply select = that > group. > Because exclusive rights to use multicasting to M4, M5 and M19 have alrea= dy > been obtained > through the higher layer protocol the group [M4,M5,M19] is already exclus= ively > claimed. >=20 > These 1040 groups may be set up through any of the following means: > * Traditional IGMP/MLD joining/leaving. > * Setting static forwarding rules using SNMP MIBs and/or switch-specific > command line > interfaces. Note that the wide-spread existence of command line interfac= es to > custom > set multicast forwarding rules is an indicator that there are existing > applications > that find the exising IGMP/MLD protocols to be inadequate to fulfill the= ir > needs. > * Method 1 as described previously. >=20 >=20 >=20 > Security Considerations >=20 > The methods described here enable no sender to multicast messages to any > destination > that was not already addressable by it. Therefore no new security > vulnerabilities > are enabled by these techniques. >=20 >=20 > Summary >=20 > The proposal provides for two new methods to manage multicast group > membership, > Thee are simple techniques, but provide a cohesive cluster-wide approach= to > providing > transactional multicasting. These techniques are better suited for > transactional multicasting > that the existing methods, IGMP and MLD, which are oriented to the stream= ing > use-cases. >=20 >=20 >=20 >=20 >=20 > Caitlin Bestler > caitlin.bestler@nexenta.com > cait@asomi.com >=20 From nobody Thu Aug 28 11:45:48 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66D2C1A8968 for ; Thu, 28 Aug 2014 11:45:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dod1Vot4AAhj for ; Thu, 28 Aug 2014 11:45:44 -0700 (PDT) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92C721A6EDA for ; Thu, 28 Aug 2014 11:45:44 -0700 (PDT) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id s7SIjgJN028046; Thu, 28 Aug 2014 19:45:42 +0100 Received: from 950129200 ([66.129.246.4]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id s7SIjdPT028008 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 28 Aug 2014 19:45:41 +0100 From: "Adrian Farrel" To: "'Caitlin Bestler'" , References: In-Reply-To: Date: Thu, 28 Aug 2014 19:45:38 +0100 Message-ID: <01b901cfc2f0$44a83e50$cdf8baf0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJA4dApmzDotXkMKGIqgu6PPuxf7ZsEGXlA Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1018-20914.001 X-TM-AS-Result: No--7.762-10.0-31-10 X-imss-scan-details: No--7.762-10.0-31-10 X-TMASE-MatchedRID: nVQUmLJJeyanykMun0J1wsrT39PoDNtWCQ3xS+zL6e0JF2U8dKhm+YpG tCmuhU7r+7QcRaVoa8nyXH6dEQg1mrrHY8Lbk0RmzNY33yIEF4Yo5R/A9DJ4V7V5fSMRD1zqN/I PgHUHVfC+t/Gktbfoh7TnbwF0CSwb2qjKAYV8LUZdtN+hx8BZv30tCKdnhB58vqq8s2MNhPB/KM EkOe61SFBIVsvVu9ABec3QM3secWbYbF+LhiAebX531p+tvdxOs9socU5jsyPlzw63Q+viOhyUp fPuZvhMlExlQIQeRG0= Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/Nfa75BioZ_MRYcwDmhlaGsGzEQQ Cc: int-ads@tools.ietf.org, tsvwg-ads@tools.ietf.org, pim-chairs@tools.ietf.org Subject: Re: [tsvwg] Draft IETF message to disclose Transactional Multicast within Clusters X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Aug 2014 18:45:46 -0000 Carsten, Thanks for this long and content-rich email. I think I understand why you brought this to TSV, but it seems to me that a lot of the discussion is about the appropriateness of MLD and IGMP. The expertise for that stuff is in the PIM WG and a little in the INT Area. I wonder whether you would like to try to kindle discussion there as well. Thanks, Adrian > -----Original Message----- > From: tsvwg [mailto:tsvwg-bounces@ietf.org] On Behalf Of Caitlin Bestler > Sent: 26 August 2014 17:04 > To: tsvwg@ietf.org > Subject: [tsvwg] Draft IETF message to disclose Transactional Multicast within > Clusters > > Nexenta has been developing a multicast based transport/storage protocol for > Object Clusters at Nexenta. [snip] From nobody Thu Aug 28 11:56:46 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC2CE1A898D for ; Thu, 28 Aug 2014 11:56:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.869 X-Spam-Level: X-Spam-Status: No, score=-4.869 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NpmenR6Mafac for ; Thu, 28 Aug 2014 11:56:38 -0700 (PDT) Received: from spey.erg.abdn.ac.uk (spey.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id EB2FC1A899B for ; Thu, 28 Aug 2014 11:56:25 -0700 (PDT) Received: from www.erg.abdn.ac.uk (blake.erg.abdn.ac.uk [139.133.210.30]) by spey.erg.abdn.ac.uk (Postfix) with ESMTPSA id A8D4D2B427B; Thu, 28 Aug 2014 19:56:24 +0100 (BST) Received: from 212.159.18.54 (SquirrelMail authenticated user gorry) by www.erg.abdn.ac.uk with HTTP; Thu, 28 Aug 2014 19:56:24 +0100 Message-ID: <8a1e3d9076291258626ce07f028c00bc.squirrel@www.erg.abdn.ac.uk> In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE712077BC667E3@MX15A.corp.emc.com> References: <8D3D17ACE214DC429325B2B98F3AE712077BC667E3@MX15A.corp.emc.com> Date: Thu, 28 Aug 2014 19:56:24 +0100 From: gorry@erg.abdn.ac.uk To: "Black, David" User-Agent: SquirrelMail/1.4.22 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/m7T9XWB6wXcGtRiXmnfzfxztxbw Cc: "tsvwg@ietf.org" , Caitlin Bestler Subject: Re: [tsvwg] Draft IETF message to disclose Transactional Multicast within Clusters X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Aug 2014 18:56:42 -0000 I'm not sure you express the problem in a way I understand as an IP multicast person - see some comments in-line, but I stopped half-way through because I think this isn't the right place to unpack this. I think actually a lot of this is a topic related to MBONED/PIM WG - the task of controlling L2 membership lies somewhere between these groups. However, if your proposal is more linked to direct communication with switches, perhaps you should first compare this with GMRP, etc. A short draft would certainly help a lot to clarify the issues and help people discuss. I'd be happy to review a draft, or help find other contacts in the IETF who can help (if that is useful). Gorry tsvwg co-chair > >> -----Original Message----- >> From: tsvwg [mailto:tsvwg-bounces@ietf.org] On Behalf Of Caitlin Bestler >> Sent: Tuesday, August 26, 2014 12:04 PM >> To: tsvwg@ietf.org >> Subject: [tsvwg] Draft IETF message to disclose Transactional Multicast >> within >> Clusters >> >> Nexenta has been developing a multicast based transport/storage protocol >> for Object >> Clusters at Nexenta. This applies multicast datagrams to creation and >> replication of >> Objects such as those supported by the Amazon S3 protocol. Creating >> replicas of object >> payload on multiple servers is an inherent part of any storage cluster, >> which makes >> multicast addressing very inviting. There are issues of congestion >> control and >> reliability to settle, which we were able to do. >> >> However, we found that the existing protocols for controlling multicast >> group membership >> (IGMP and MLD) are not suitable for our storage application. We doubt >> this is unique to >> our application. It should apply to many clusters that have a need to >> distribute >> transactional messages to dynamically selected subsets of a group within >> a cluster to >> multiple known recipients. HPC clusters using MPI are also potential >> users of transactional >> multicasting. Multicast repication over a VLAN for the internal >> communications of a pNFS >> cluster is another potential application. This is just one example of >> synchronizing cluster >> data where the synchronization does not replicate all of the shared data >> with the entire >> cluster. But these are merely initial hunches, the purpose of this email >> is to determine exactly >> how common the need for "transactional multicast" is, and possibly to >> incorporate the needs >> of other clusters, before submitting a draft. >> >> To be clear, this is a submission to the IETF process proposing enhanced >> methods for >> controlling multicast group membership. This and later posts may make >> reference to >> specific applications, including the Nexenta Replicast protocol for >> multicast replication >> in our Cloud Copy-on-Write (CCOW) Object Cluster. Such examples are >> merely for >> illustrative purposes. Any IETF standardization of the Replicast storage >> protocols would >> be done via the Storm or NFS groups, and would require adoption of a >> definition of Object >> Storage as a service before defining a specific protocol for providing >> Object Storage >> services. >> >> What will be proposing is focused on the management of multicast groups, >> specifically two >> additional methods for setting the membership of a multicast group which >> can radically >> reduce the latency in setting up a group within a known cluster. >> >> The potential for such dramatic savings is that transactional messaging >> within a cluster >> is a radically different use-case from traditional multicast. >> This covers a variety of factors: >> * How is the group Selected? >> * What are the endpoints that receive the messages? >> * What is the duration of the group? >> * Who are the potential members of the group? >> * How much latency does the application tolerate? >> >> >> Question 1: How is the Group Selected? >> >> In IGMP/MLD the membership of a multicast group is controlled by the >> listeners >> joining and >> leaving the group. The sender does not control or even know the >> recipients. >> This matches >> the multicast streaming use-case very well. However it does not match a >> cluster that needs >> to distribute a transactional message to a subset of a known cluster. >> >> The target group is also assumed to be stable for a long sequence of >> packets, >> such as >> streaming a video. The targeted applications direct transactions to a >> subset >> of a stable group. >> Not necessarily, multicast is used in other ways as well. Sometimes apps join to groups and the server occasionally sends to a specific group to target a specific subset of hosts that it knows is listening. >> One example of the need to distribute a transactional message to a >> subset of a >> known >> cluster is replication within an object cluster. A set of targets has >> been >> selected >> through an higher layer protocol. IGMP-style setup here adds excessive >> latency >> to the >> process. >> I didn't get the problem, why does an IGMP join cause delay? - My mental model would have thought the clients had already joined to the group when they started running the service, and simply "waited" for something to arrive. >> The targets must be informed of their selection, they must >> execute >> IGMP joins and >> confirm their joining to the source before the multicast delivery can >> begin. >> That sounds rather odd - multicast apps that I know are not built this way. The starting of the client, generally registers to a set of groups. The server doesn't wait for clients to join - if you want to synchronise then that's a transport issue, not a L2 membership one. >> Only >> replication of large storage assets can tolerate this setup penalty. >> >> A distributed computation may similarly have data that is relevant to a >> specific set of >> recipients within the cluster. Having to replicate the transfer over >> multiple >> unicast >> connections is undesirable, as is having to incur the latency of IGMP >> setup. >> >> Two solutions will be proposed where a sender can form or select a >> multicast >> group to >> match a set of targets, without requiring any extra interaction with >> THOSE >> targets as long >> as the targets are already members of a pre-existing multicast group. >> Allowing >> a sender to >> multicast to *any* set of IP addresses would clearly be unacceptable for >> both >> security and >> network administration reasons. >> Ah you mean you would like to do L2 security, that's a complicated thing in multicast - there are proposals in the mboned WG, but this isn't part of the classic multicast service model. >> >> >> Question 2: What are the endpoints that receive the messages? >> >> For the specific storage protocol we were working on the desired >> endpoints are >> virtual >> drives, not IP endpoints. A given storage server can determine which of >> its >> virtual drives >> is being addressed solely from the destination multicast IP address. >> >> One of the questions for the mailing list is whether this is unique to >> this storage >> protocol, or whether the ability to identify a multicast group as a set >> of higher layer >> objects is generally desirable. >> I think you need to write-up the problem. >> >> Question 3: What is the duration of the group? >> >> IGMP/MLD is designed primarily for the multicast streaming use-case. >> Not really. >> A group has an >> indefinite lifespan, and members come and go at any time during this >> lifespan, which might >> be measured in minutes, hours or days. >> >> Transactional multicasting seeks to identify a multicast group for the >> duration of sending >> a set of multicast datagrams related to a specific transaction. >> You can use the port space and build apps on the network service this provides which can themselves filter on the data they receive - several apps do this, and work with existing L2 switches. >> Recipients >> either receive >> the entire set of datagrams or they do not. Multicast streaming >> typically is >> transmitting >> error tolerant content, such as MPEG encoded material. Transaction >> multicasting will >> typically transmit data with some form of validating signature that >> allows >> each recipient >> to confirm full reception of the transaction. >> >> This obviously needs to be combined with applicable congestion control >> strategies being >> deployed by the upper layer protocols. The Nexenta Replicast protocol >> only >> does bulk >> transfers against reserved bandwidth, but there are probably as many >> solutions >> for this >> problem as there are applications. Replicast relies upon IEEE I802.1 >> Datacenter Bridging >> (DCB) protocols such as Priority Flow Control and Congestion >> Notification to >> provide >> no-drop service. The DCB protocols deal with the fine timing of >> congestion >> avoidance, >> but require higher layer transport or application protocols to keep the >> sustained >> traffic rates below the sustained capacity. Creating explicit >> reservations for >> bulk >> transfers is the main method for accomplishing this. >> >> The important distinction between Replicast and conventional multicast >> applications is >> that there is no need to dynamically adjust multicast forwarding tables >> during >> the >> lifespan of a transaction, while IGMP and MLD are designed to allow the >> addition and >> deletion of members while a multicast group is in use. This distinction >> is not >> unique to >> Nexenta's Replicast storage application. Transactional replication is a >> common >> element in cluster protocol design. >> >> The limited duration of a transactional multicast group implies that >> there is >> no need for >> the multicast forwarding element to rebuild its forwarding tables after >> it >> restarts. Any >> transaction in progress will have failed, and been retried by the >> higher-layer >> protocol. >> Merely limiting the rate at which it fails and restarts is all that is >> required of each >> forwarding element. >> >> Another implication is that there is no need for the forwarding elements >> to >> rebuild the >> membership list of a transactional multicast group after the forwarding >> element has been >> reset. The transactions using the forwarding element will all fail, and >> be >> retried by a >> higher layer transport or application protocol. Assuming that forwarding >> elements do not >> reset multiple times a minute this will have very limited impact on >> overall >> application >> throughput. >> >> The duration of a transaction is application specific, but inherently >> limited. >> A failed >> transaction will be retried at the application layer, so obviously it >> has a >> duration >> measured in seconds at the longest. >> >> >> >> Question 4: Who are the members of the group? >> >> IGMP/MLD is designed to allow any number of recipients to join or leave >> a >> group at will. >> >> Transactional multicast requires that the group be identified as a small >> subset of a >> pre-existing multicast group. >> >> Building forwarding rules that are a subset of forwarding rules for an >> existing multicast >> group can done substantially faster than creating forwarding rules to >> arbitrary and >> potentially previously unknown destinations. >> >> >> >> Question 5: How much latency does the application tolerate? >> >> While no application likes latency, multicast streaming is very tolerant >> of >> setup latency. >> If the end application is viewing or listening to media, how many msecs >> are >> required to >> subscribe to the group will not have a measurable impact to the end >> user. >> >> For transactions in a cluster, however, every msec is delaying forward >> progress. The time >> it takes to do an IGMP join would be a significant addition to the >> latency of >> storing an >> object in an object cluster using SSD or other fast storage technology. >> >> >> >> Proposed Method 1: >> >> Set the multicast forwarding rules for pre-existing multicast forwarding >> address X to be >> the subset of the forwarding rules for existing group Y required to >> reach a >> specified >> member list. >> >> This is done by communicating the same instruction (above) to each >> multicast >> forwarding >> network element. This can be done by unicast addressing with each of >> them, or >> by >> multicasting the instructions. >> >> Each multicast forwarder will set its multicast forwarding port set to >> be the >> union of the >> unicast forwarding it has for the listed members, but result must be a >> subset >> of the >> forwarding ports for the parent group. >> >> For example, consider an instruction is to create a transaction >> multicast >> group I which is >> a subset of multicast group J to reach addresses A,B and C. >> >> Addresses A and B are attached to multicast forwarder X, while C is >> attached >> to multicast >> forwarder Y. >> >> On forwarder X the forwarding rule for new group I contains: >> The forwarding port for A. >> The forwarding port for B. >> The forwarding port to forwarder Y (a hub link). This eventually leads >> to C. >> >> While on forwarder Y the forwarding rule for the new group I will >> contain: >> The forwarding port for forwarder X (a hub link). This eventually leads >> to A and B. >> The forwarding port for C. >> >> Many ethernet switches already support command line and/or SNMP methods >> of >> setting these >> multicast forwarding rules, but it is challenging for an application to >> reliably apply the >> same changes using multiple vendor specific methods. Having a >> standardized >> method of >> pushing the membership of a multicast group from the sender would be >> desirable. >> >> >> >> Proposed Method 2: >> >> There is a large group of pre-configured multicast groups which are an >> enumeration of the >> possible subsets of a master group. This will be a specific subset, such >> as >> all >> combinations of 3 members for multicast group X. These groups are >> enumerated >> and assuaged >> successive multicast addresses within a block. >> >> The sender first obtains exclusive permission to utilize a portion of >> the >> reception >> capacity of each desire target, and then selects the multicast address >> that >> will reach >> that group. >> >> In a straightforward enumeration of 3 members out of a group of 20, >> there are >> 20*19*18/3*2 >> or 1040 possible groups. Typically the higher layer protocol will have >> negotiated the >> right to send the transaction with the member prior to selecting the >> multicast >> group. In >> making the final selection, the actual multicast group is >> selected and some offered targets are declined. >> >> Those 1040 possible groups can be enumerated in order (starting with M1, >> M2 >> and M3 and >> ending with M18, M19 and M20) and assigned multicast addresses from N to >> N+1039. >> >> When the transaction requires reaching M4, M5 and M19, you simply select >> that >> group. >> Because exclusive rights to use multicasting to M4, M5 and M19 have >> already >> been obtained >> through the higher layer protocol the group [M4,M5,M19] is already >> exclusively >> claimed. >> >> These 1040 groups may be set up through any of the following means: >> * Traditional IGMP/MLD joining/leaving. >> * Setting static forwarding rules using SNMP MIBs and/or switch-specific >> command line >> interfaces. Note that the wide-spread existence of command line >> interfaces to >> custom >> set multicast forwarding rules is an indicator that there are existing >> applications >> that find the exising IGMP/MLD protocols to be inadequate to fulfill >> their >> needs. >> * Method 1 as described previously. >> >> >> >> Security Considerations >> >> The methods described here enable no sender to multicast messages to any >> destination >> that was not already addressable by it. Therefore no new security >> vulnerabilities >> are enabled by these techniques. >> >> >> Summary >> >> The proposal provides for two new methods to manage multicast group >> membership, >> Thee are simple techniques, but provide a cohesive cluster-wide >> approach to >> providing >> transactional multicasting. These techniques are better suited for >> transactional multicasting >> that the existing methods, IGMP and MLD, which are oriented to the >> streaming >> use-cases. >> >> >> >> >> >> Caitlin Bestler >> caitlin.bestler@nexenta.com >> cait@asomi.com >> > From nobody Thu Aug 28 13:22:33 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81C461A8A61 for ; Thu, 28 Aug 2014 13:22:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sFclAYRXrQXl for ; Thu, 28 Aug 2014 13:22:26 -0700 (PDT) Received: from mail-pa0-f51.google.com (mail-pa0-f51.google.com [209.85.220.51]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C8A11A8A16 for ; Thu, 28 Aug 2014 13:22:25 -0700 (PDT) Received: by mail-pa0-f51.google.com with SMTP id rd3so3906687pab.24 for ; Thu, 28 Aug 2014 13:22:24 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:mime-version:content-type:from :in-reply-to:date:cc:message-id:references:to; bh=yeMe9Mn11KojIKiPOcjGcwgvNG1MLQzY/jMEOtWq0O8=; b=D182OXtiVj1p+AK7+Z0D4Mcf18b3SJLGJJLDZp5kEOFCjnBbnPoTglDfJ9KPqaXJhR tm/c2J6Er7pDOlpyrjsVZaG6zx73iOby3He191pYwuYzNGw8/0vDyvFHmBMT8BdzXIvt 9nutiuPoEsqOBFNnt2bU3G9Ak7y39yS2i9GY0SkfVTBFIaBSoBJzACL5Gh1JyNJpHP7/ dNtjxv2nMwojtkQmEzCeGwLC0e+3BKVBOZkf3TIIVvrhKsaWcno8LM9SPlTPQrnTXmti zDZALDi0ffV0Zi2zwIjNfR3Hx+O1vhiL0MgUCflZ4lTqzVmrtUuIxFXt5gt/FyBuYu2u s+Uw== X-Gm-Message-State: ALoCoQkgdxswJxbPbZ7uk0mCUevp3IWKB3Uvoj8JQqKTEzEIElvbnBBZtvPDVVLCYOCtxmYAPiey X-Received: by 10.70.102.200 with SMTP id fq8mr9411892pdb.152.1409257344815; Thu, 28 Aug 2014 13:22:24 -0700 (PDT) Received: from [10.1.2.95] ([64.125.103.162]) by mx.google.com with ESMTPSA id yh3sm4455902pbb.38.2014.08.28.13.22.22 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 28 Aug 2014 13:22:23 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Content-Type: multipart/alternative; boundary="Apple-Mail=_636FB4EA-C049-46FE-B9F3-D89423A80825" From: Caitlin Bestler X-Priority: 3 (Normal) In-Reply-To: <8a1e3d9076291258626ce07f028c00bc.squirrel@www.erg.abdn.ac.uk> Date: Thu, 28 Aug 2014 13:22:23 -0700 Message-Id: References: <8D3D17ACE214DC429325B2B98F3AE712077BC667E3@MX15A.corp.emc.com> <8a1e3d9076291258626ce07f028c00bc.squirrel@www.erg.abdn.ac.uk> To: gorry@erg.abdn.ac.uk X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/J6ityvrBiBKuEtXYKJazaDatfs8 Cc: "tsvwg@ietf.org" Subject: Re: [tsvwg] Transactional Multicast within Clusters X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Aug 2014 20:22:30 -0000 --Apple-Mail=_636FB4EA-C049-46FE-B9F3-D89423A80825 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Aug 28, 2014, at 11:56 AM, gorry@erg.abdn.ac.uk wrote: >=20 > I'm not sure you express the problem in a way I understand as an IP > multicast person - see some comments in-line, but I stopped half-way > through because I think this isn't the right place to unpack this. >=20 > I think actually a lot of this is a topic related to MBONED/PIM WG - = the > task of controlling L2 membership lies somewhere between these groups.=20= > However, if your proposal is more linked to direct communication with > switches, perhaps you should first compare this with GMRP, etc. >=20 > A short draft would certainly help a lot to clarify the issues and = help > people discuss. I'd be happy to review a draft, or help find other > contacts in the IETF who can help (if that is useful). >=20 > Gorry > tsvwg co-chair Actually the group that has the most relevant expertise is probably = TRILL, but this is a complete non-fit with the TRILL charter. But I=92ll repackage the proposal and submit to the other groups = suggested within the next day or so. >=20 >>=20 >>> -----Original Message----- >>> From: tsvwg [mailto:tsvwg-bounces@ietf.org] On Behalf Of Caitlin = Bestler >>> Sent: Tuesday, August 26, 2014 12:04 PM >>> To: tsvwg@ietf.org >>> Subject: [tsvwg] Draft IETF message to disclose Transactional = Multicast >>> within >>> Clusters >>>=20 >>> Nexenta has been developing a multicast based transport/storage = protocol >>> for Object >>> Clusters at Nexenta. This applies multicast datagrams to creation = and >>> replication of >>> Objects such as those supported by the Amazon S3 protocol. Creating >>> replicas of object >>> payload on multiple servers is an inherent part of any storage = cluster, >>> which makes >>> multicast addressing very inviting. There are issues of congestion >>> control and >>> reliability to settle, which we were able to do. >>>=20 >>> However, we found that the existing protocols for controlling = multicast >>> group membership >>> (IGMP and MLD) are not suitable for our storage application. We = doubt >>> this is unique to >>> our application. It should apply to many clusters that have a need = to >>> distribute >>> transactional messages to dynamically selected subsets of a group = within >>> a cluster to >>> multiple known recipients. HPC clusters using MPI are also potential >>> users of transactional >>> multicasting. Multicast repication over a VLAN for the internal >>> communications of a pNFS >>> cluster is another potential application. This is just one example = of >>> synchronizing cluster >>> data where the synchronization does not replicate all of the shared = data >>> with the entire >>> cluster. But these are merely initial hunches, the purpose of this = email >>> is to determine exactly >>> how common the need for "transactional multicast" is, and possibly = to >>> incorporate the needs >>> of other clusters, before submitting a draft. >>>=20 >>> To be clear, this is a submission to the IETF process proposing = enhanced >>> methods for >>> controlling multicast group membership. This and later posts may = make >>> reference to >>> specific applications, including the Nexenta Replicast protocol for >>> multicast replication >>> in our Cloud Copy-on-Write (CCOW) Object Cluster. Such examples are >>> merely for >>> illustrative purposes. Any IETF standardization of the Replicast = storage >>> protocols would >>> be done via the Storm or NFS groups, and would require adoption of a >>> definition of Object >>> Storage as a service before defining a specific protocol for = providing >>> Object Storage >>> services. >>>=20 >>> What will be proposing is focused on the management of multicast = groups, >>> specifically two >>> additional methods for setting the membership of a multicast group = which >>> can radically >>> reduce the latency in setting up a group within a known cluster. >>>=20 >>> The potential for such dramatic savings is that transactional = messaging >>> within a cluster >>> is a radically different use-case from traditional multicast. >>> This covers a variety of factors: >>> * How is the group Selected? >>> * What are the endpoints that receive the messages? >>> * What is the duration of the group? >>> * Who are the potential members of the group? >>> * How much latency does the application tolerate? >>>=20 >>>=20 >>> Question 1: How is the Group Selected? >>>=20 >>> In IGMP/MLD the membership of a multicast group is controlled by the >>> listeners >>> joining and >>> leaving the group. The sender does not control or even know the >>> recipients. >>> This matches >>> the multicast streaming use-case very well. However it does not = match a >>> cluster that needs >>> to distribute a transactional message to a subset of a known = cluster. >>>=20 >>> The target group is also assumed to be stable for a long sequence of >>> packets, >>> such as >>> streaming a video. The targeted applications direct transactions to = a >>> subset >>> of a stable group. >>>=20 > Not necessarily, multicast is used in other ways as well. Sometimes = apps > join to groups and the server occasionally sends to a specific group = to > target a specific subset of hosts that it knows is listening. The IGMP/MLD protocols have features to maintain forwarding of packets to the group members even in the event of network re-configuration. That is a valuable feature, for target groups that have an indefinite = life span. It is worthless overhead for transactions measured in seconds or msecs. >=20 >>> One example of the need to distribute a transactional message to a >>> subset of a >>> known >>> cluster is replication within an object cluster. A set of targets = has >>> been >>> selected >>> through an higher layer protocol. IGMP-style setup here adds = excessive >>> latency >>> to the >>> process. >>>=20 > I didn't get the problem, why does an IGMP join cause delay? - My = mental > model would have thought the clients had already joined to the group = when > they started running the service, and simply "waited" for something to > arrive. The IGMP join can take longer than the actual transfer. The receiving members have joined the reference or master group already, but we want to deliver to a subset of that group. Specifcially so that = we can have two disjoint subsets delivering concurrently. This implies that the=20= selection of members for the subset groups is some form of load = balancing. For storage this could be latency and/or capacity balancing. But = dispatching work within a cluster would also want to assign members to different = subset groups on a transactional basis. The first draft of our Repicast storage protocol had the receivers join = the transactional group. What we found is that the latency of the joins made the overall transaction take way too long except when the chunks to be transferred were quite large. We are currently using what was described in proposal 2, because it the transactional groups can still be formed using IGMP/MLD. We are planning on adding option 1 for specific switch models in a later release. The point is that IGMP takes *far* too long for transactional purposes within a cluster. I believe this is inherently related to requirements = that traditional multicast groups have legitimate needs for. That=92s why I = don=92t think of this as =93challenging=94 IGMP/MLD, it is mmerely identifying a = different use-case for multicast communications. IGMP/MLD works well of what they were designed for, but not transactions within a cluster. >=20 >>> The targets must be informed of their selection, they must >>> execute >>> IGMP joins and >>> confirm their joining to the source before the multicast delivery = can >>> begin. >>>=20 > That sounds rather odd - multicast apps that I know are not built this > way. The starting of the client, generally registers to a set of = groups. > The server doesn't wait for clients to join - if you want to = synchronise > then that's a transport issue, not a L2 membership one. Chicken and egg problem. Multicast apps do not do this because=20 the multicast tools do not support them. The fact that I was familiar with how switches actually forward frames (for both unicast and multicast) might have been why the overall solution occurred to me. If my thinking had been guided by IGMP/MLD I would have rejected using multicast for bulk transfers. The upper layer logic required here is doing no-drop bulk transfers. The recent DCB extensions to Ethernet make a multicast congestion protocol feasible. Any attempts to do this pre-DCB would have been futile because the L4 transport protocol would never get the precise timing right. The fudge factors required would have wasted more=20 bandwidth than TCP does. >=20 >>> Only >>> replication of large storage assets can tolerate this setup penalty. >>>=20 >>> A distributed computation may similarly have data that is relevant = to a >>> specific set of >>> recipients within the cluster. Having to replicate the transfer over >>> multiple >>> unicast >>> connections is undesirable, as is having to incur the latency of = IGMP >>> setup. >>>=20 >>> Two solutions will be proposed where a sender can form or select a >>> multicast >>> group to >>> match a set of targets, without requiring any extra interaction with >>> THOSE >>> targets as long >>> as the targets are already members of a pre-existing multicast = group. >>> Allowing >>> a sender to >>> multicast to *any* set of IP addresses would clearly be unacceptable = for >>> both >>> security and >>> network administration reasons. >>>=20 > Ah you mean you would like to do L2 security, that's a complicated = thing > in multicast - there are proposals in the mboned WG, but this isn't = part > of the classic multicast service model. Im relying on existing controls of the reference multicast groups, both standards based and existing techniques used by intrusion detection = systems and firewalls. The point is that the subset rule prevents the introduction of any new attack vectors. You cannot use these new methods of forming multicast groups to reach any unwilling targets that you could not have reached already. Without such a feature the ability of a *sender* to add a target to a = multicast group could be used for a Denial of Service attack. >=20 >>>=20 >>>=20 >>> Question 2: What are the endpoints that receive the messages? >>>=20 >>> For the specific storage protocol we were working on the desired >>> endpoints are >>> virtual >>> drives, not IP endpoints. A given storage server can determine which = of >>> its >>> virtual drives >>> is being addressed solely from the destination multicast IP address. >>>=20 >>> One of the questions for the mailing list is whether this is unique = to >>> this storage >>> protocol, or whether the ability to identify a multicast group as a = set >>> of higher layer >>> objects is generally desirable. >>>=20 >=20 > I think you need to write-up the problem. >=20 >>>=20 >>> Question 3: What is the duration of the group? >>>=20 >>> IGMP/MLD is designed primarily for the multicast streaming use-case. >>>=20 > Not really. >=20 >>> A group has an >>> indefinite lifespan, and members come and go at any time during this >>> lifespan, which might >>> be measured in minutes, hours or days. >>>=20 >>> Transactional multicasting seeks to identify a multicast group for = the >>> duration of sending >>> a set of multicast datagrams related to a specific transaction. >>>=20 > You can use the port space and build apps on the network service this > provides which can themselves filter on the data they receive - = several > apps do this, and work with existing L2 switches. Receiver filtering does not work if you want to enable concurrent = transfers to disjoint subsets of an existing multicast group. The goal is to support a cluster distributing bulk data to be processed = and/or stored by dynamical selected subsets of the entire group. Dropping = irrelevant data in the destination stack does not help if the links going to the = destination become overloaded. >>>=20 >>>=20 >>> Caitlin Bestler >>> caitlin.bestler@nexenta.com >>> cait@asomi.com --Apple-Mail=_636FB4EA-C049-46FE-B9F3-D89423A80825 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
On Aug 28, 2014, at 11:56 AM, gorry@erg.abdn.ac.uk = wrote:


I'm not sure you express the = problem in a way I understand as an IP
multicast person - see some = comments in-line, but I stopped half-way
through because I think this = isn't the right place to unpack this.

I  think actually a = lot of this is a topic related to MBONED/PIM WG - the
task of = controlling L2 membership lies somewhere between these groups. 
However, if your = proposal is more linked to direct communication with
switches, = perhaps you should first compare this with GMRP, etc.

A short = draft would certainly help a lot to clarify the issues and = help
people discuss. I'd be happy to review a draft, or help find = other
contacts in the IETF who can help (if that is = useful).

Gorry
tsvwg = co-chair

Actually the group = that has the most relevant expertise is probably TRILL,
but = this is a complete non-fit with the TRILL = charter.

But I=92ll repackage the proposal and = submit to the other groups suggested
within the next day or = so.




-----Original = Message-----
From: tsvwg [mailto:tsvwg-bounces@ietf.org] = On Behalf Of Caitlin Bestler
Sent: Tuesday, August 26, 2014 12:04 = PM
To: tsvwg@ietf.org
Subject:= [tsvwg] Draft IETF message to disclose Transactional = Multicast
within
Clusters

Nexenta has been developing a = multicast based transport/storage protocol
for Object
Clusters at = Nexenta. This applies multicast datagrams to creation and
replication = of
Objects such as those supported by the Amazon S3 protocol. = Creating
replicas of  object
payload on multiple servers is = an inherent part of any storage cluster,
which makes
multicast = addressing very inviting.  There are issues of = congestion
control and
reliability to settle, which we were able = to do.

However, we found that the existing protocols for = controlling multicast
group membership
(IGMP and MLD) are not = suitable for our storage application. We doubt
this is unique = to
our application. It should apply to many clusters that have a need = to
distribute
transactional messages to dynamically selected = subsets of a group within
a cluster to
multiple known recipients. = HPC clusters using MPI are also potential
users of = transactional
multicasting. Multicast repication over a VLAN for the = internal
communications of a pNFS
cluster is another potential = application. This is just one example of
synchronizing = cluster
data where the synchronization does not replicate all of the = shared data
with the entire
cluster. But these are merely initial = hunches, the purpose of this email
is to determine exactly
how = common the need for "transactional multicast" is, and possibly = to
incorporate the needs
of other clusters, before submitting a = draft.

To be clear, this is a submission to the IETF process = proposing enhanced
methods for
controlling multicast group = membership. This and later posts may make
reference to
specific = applications, including the Nexenta Replicast protocol for
multicast = replication
in our Cloud Copy-on-Write (CCOW) Object Cluster. Such = examples are
merely for
illustrative purposes. Any IETF = standardization of the Replicast storage
protocols would
be done = via the Storm or NFS groups, and would require adoption of = a
definition of Object
Storage as a service before defining a = specific protocol for providing
Object = Storage
services.

What will be proposing is focused on the = management of multicast groups,
specifically two
additional = methods for setting the membership of a multicast group which
can = radically
reduce the latency in setting up a group within a known = cluster.

The potential for such dramatic savings is that = transactional messaging
within a cluster
is a radically different = use-case from traditional multicast.
This covers a variety of = factors:
* How is the group Selected?
* What are the endpoints = that receive the messages?
* What is the duration of the group?
* = Who are the potential members of the group?
* How much latency does = the application tolerate?


Question 1: How is the Group = Selected?

In IGMP/MLD the membership of a multicast group is = controlled by the
listeners
joining and
leaving the group. The = sender does not control or even know the
recipients.
This = matches
the multicast streaming use-case very well. However it does = not match a
cluster that needs
to distribute a transactional = message to a subset of a known cluster.

The target group is also = assumed to be stable for a long sequence of
packets,
such = as
streaming a video. The targeted applications direct transactions = to a
subset
of a stable = group.

Not necessarily, multicast is = used in other ways as well. Sometimes apps
join to groups and the = server occasionally sends to a specific group to
target a specific = subset of hosts that it knows is = listening.

The IGMP/MLD = protocols have features to maintain forwarding of packets
to = the group members even in the event of network = re-configuration.

That is a valuable feature, = for target groups that have an indefinite life span.
It is = worthless overhead for transactions measured in seconds or = msecs.



One example of the need to distribute a transactional = message to a
subset of a
known
cluster is replication within an = object cluster. A set of targets has
been
selected
through an = higher layer protocol. IGMP-style setup here adds = excessive
latency
to = the
process.

I didn't get the = problem, why does an IGMP join cause delay? - My mental
model would = have thought the clients had already joined to the group when
they = started running the service, and simply "waited" for something = to
arrive.

The IGMP join can = take longer than the actual transfer.

The = receiving members have joined the reference or master group = already,
but we want to deliver to a subset of that group. = Specifcially so that we can
have two disjoint subsets = delivering concurrently. This implies that the 
selection = of members for the subset groups is some form of load = balancing.
For storage this could be latency and/or capacity = balancing. But dispatching
work within a cluster would also = want to assign members to different subset
groups on a = transactional basis.

The first draft of our = Repicast storage protocol had the receivers join = the
transactional group. What we found is that the latency of = the joins made
the overall transaction take way too long = except when the chunks to be
transferred were quite = large.

We are currently using what was = described in proposal 2, because it the
transactional groups = can still be formed using IGMP/MLD. We are planning
on adding = option 1 for specific switch models in a later = release.

The point is that IGMP takes *far* too = long for transactional purposes
within a cluster. I believe = this is inherently related to requirements that
traditional = multicast groups have legitimate needs for. That=92s why I = don=92t
think of this as =93challenging=94 IGMP/MLD, it is = mmerely identifying a different
use-case for multicast = communications. IGMP/MLD works well of what they
were designed = for, but not transactions within a = cluster.


The targets must be informed of their selection, they = must
execute
IGMP joins and
confirm their joining to the source = before the multicast delivery = can
begin.

That sounds rather odd - = multicast apps that I know are not built this
way. The starting of = the client, generally registers to a set of groups.
The server = doesn't wait for clients to join - if you want to synchronise
then = that's a transport issue, not a L2 membership = one.

Chicken and egg problem. = Multicast apps do not do this because 
the multicast = tools do not support them. The fact that I was familiar
with = how switches actually forward frames (for both unicast = and
multicast) might have been why the overall solution = occurred to me.
If my thinking had been guided by IGMP/MLD I = would have rejected
using multicast for bulk = transfers.

The upper layer logic required here = is doing no-drop bulk transfers.
The recent DCB extensions to = Ethernet make a multicast congestion
protocol feasible. Any = attempts to do this pre-DCB would have been
futile because the = L4 transport protocol would never get the precise
timing = right. The fudge factors required would have wasted = more 
bandwidth than TCP = does.




Only
replication of large = storage assets can tolerate this setup penalty.

A distributed = computation may similarly have data that is relevant to a
specific = set of
recipients within the cluster. Having to replicate the = transfer over
multiple
unicast
connections is undesirable, as = is having to incur the latency of IGMP
setup.

Two solutions = will be proposed where a sender can form or select = a
multicast
group to
match a set of targets, without requiring = any extra interaction with
THOSE
targets as long
as the targets = are already members of a pre-existing multicast group.
Allowing
a = sender to
multicast to *any* set of IP addresses would clearly be = unacceptable for
both
security and
network administration = reasons.

Ah you mean you would like to = do L2 security, that's a complicated thing
in multicast - there are = proposals in the mboned WG, but this isn't part
of the classic = multicast service model.

Im relying = on existing controls of the reference multicast groups, = both
standards based and existing techniques used by intrusion = detection systems
and firewalls.

The = point is that the subset rule prevents the introduction of any = new
attack vectors. You cannot use these new methods of = forming multicast
groups to reach any unwilling targets that = you could not have = reached
already.

Without such a = feature the ability of a *sender* to add a target to a = multicast
group could be used for a Denial of Service = attack.




Question 2: What are the endpoints that receive = the messages?

For the specific storage protocol we were working = on the desired
endpoints are
virtual
drives, not IP endpoints. = A given storage server can determine which of
its
virtual = drives
is being addressed solely from the destination multicast IP = address.

One of the questions for the mailing list is whether = this is unique to
this storage
protocol, or whether the ability to = identify a multicast group as a set
of  higher layer
objects = is generally desirable.


I think you = need to write-up the problem.


Question 3: What is the duration of the = group?

IGMP/MLD is designed primarily for the multicast streaming = use-case.

Not = really.

A = group has an
indefinite lifespan, and members come and go at any time = during this
lifespan, which might
be measured in minutes, hours or = days.

Transactional multicasting seeks to identify a multicast = group for the
duration of sending
a set of multicast datagrams = related to a specific transaction.

You = can use the port space and build apps on the network service = this
provides which can themselves filter on the data they receive - = several
apps do this, and work with existing L2 = switches.

Receiver filtering does = not work if you want to enable concurrent transfers
to = disjoint subsets of an existing multicast = group.

The goal is to support a cluster = distributing bulk data to be processed and/or
stored by = dynamical selected subsets of the entire group. Dropping = irrelevant
data in the destination stack does not help if the = links going to the destination
become = overloaded.


= = --Apple-Mail=_636FB4EA-C049-46FE-B9F3-D89423A80825-- From nobody Thu Aug 28 13:28:15 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A43BB1A8A64 for ; Thu, 28 Aug 2014 13:28:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.969 X-Spam-Level: X-Spam-Status: No, score=-4.969 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y_fWd5JZ6n-j for ; Thu, 28 Aug 2014 13:28:08 -0700 (PDT) Received: from mailuogwdur.emc.com (mailuogwdur.emc.com [128.221.224.79]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32D0A1A8A5F for ; Thu, 28 Aug 2014 13:28:07 -0700 (PDT) Received: from maildlpprd51.lss.emc.com (maildlpprd51.lss.emc.com [10.106.48.155]) by mailuogwprd53.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s7SKS6gL011291 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 28 Aug 2014 16:28:06 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd53.lss.emc.com s7SKS6gL011291 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1409257686; bh=XOntY95SspBujX+gunWYLcdsegE=; h=From:To:Date:Subject:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=jLsDCXZZD7avM2yN/w2iHggEIKIGL0vHoYBs8UoIy/i1+/yjM6/ZfHzZ2Wm7vRypC UQjEUnmp8Ec6lglomt7aLhd/YYKfK14zCbrBnMaWoQ9NuEYuhTGg0Ca9KPNl5kcLjk +bV+BDK+5D58t5Hfjb82uDUBzgSbREsvXvJJqvAk= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd53.lss.emc.com s7SKS6gL011291 Received: from mailusrhubprd53.lss.emc.com (mailusrhubprd53.lss.emc.com [10.106.48.18]) by maildlpprd51.lss.emc.com (RSA Interceptor) for ; Thu, 28 Aug 2014 16:27:53 -0400 Received: from mxhub11.corp.emc.com (mxhub11.corp.emc.com [10.254.92.106]) by mailusrhubprd53.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s7SKRsHh007298 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 28 Aug 2014 16:27:55 -0400 Received: from mx15a.corp.emc.com ([169.254.1.175]) by mxhub11.corp.emc.com ([10.254.92.106]) with mapi; Thu, 28 Aug 2014 16:27:54 -0400 From: "Black, David" To: "Black, David" , "tsvwg@ietf.org" Date: Thu, 28 Aug 2014 16:27:53 -0400 Thread-Topic: WG Adoption Call for draft-fairhurst-tsvwg-circuit-breaker- 22 August 2014 Thread-Index: Ac+ynKuV3jqxrlUtQCavOPlrAQqLrAQYWO9w Message-ID: <8D3D17ACE214DC429325B2B98F3AE712077BC66845@MX15A.corp.emc.com> References: <8D3D17ACE214DC429325B2B98F3AE712077B951766@MX15A.corp.emc.com> In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE712077B951766@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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd53.lss.emc.com X-RSA-Classifications: public Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/sJU_ryxRcjrgQWcYRkMbpLftxGM Subject: Re: [tsvwg] WG Adoption Call for draft-fairhurst-tsvwg-circuit-breaker- 22 August 2014 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Aug 2014 20:28:11 -0000 Having seen significant support both in the Toronto meeting and on the list, this draft is hereby adopted by the tsvwg WG - the author (Gorry) should submit a -00 WG version (draft-ietf-tsvwg- ...) at his earliest convenience. Many thanks to everyone who responded, and particularly people who offered to review future versions. Thanks, --David (tsvwg WG co-chair) > -----Original Message----- > From: tsvwg [mailto:tsvwg-bounces@ietf.org] On Behalf Of Black, David > Sent: Thursday, August 07, 2014 8:07 PM > To: tsvwg@ietf.org > Subject: [tsvwg] WG Adoption Call for draft-fairhurst-tsvwg-circuit-break= er- > 22 August 2014 >=20 > The TSVWG chairs are considering adoption of the above draft. This draft > has been discussed at previous IETF meetings and on the list. >=20 > At the recent Toronto IETF meeting, the draft received strong support fro= m > the people present in the meeting room, and no comments against adopting > this draft as a TSVWG work item. >=20 > The WG chairs now invite any further comments on this adoption. If there > are concerns or comments about adoption please send comments to the list > or to the Chairs. We plan to make a final decision on this adoption on > 22 August 2014. >=20 > Also, would the draft author (Gorry) please send a note to the list > indicating whether you know of any IPR related to this draft that > requires disclosure in accordance with BCP 79. Needless to say, > Gorry is recused from this decision, as he is the author of this draft. >=20 > Thanks, > --David (tsvwg WG co-chair) > ---------------------------------------------------- > David L. Black, Distinguished Engineer > EMC Corporation, 176 South St., Hopkinton, MA=A0 01748 > +1 (508) 293-7953=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 FAX: +1 (508) 293-7= 786 > david.black@emc.com=A0=A0=A0=A0=A0=A0=A0 Mobile: +1 (978) 394-7754 > ---------------------------------------------------- >=20 >=20 From nobody Thu Aug 28 14:08:32 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B3EA1A02BD for ; Thu, 28 Aug 2014 14:08:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.868 X-Spam-Level: X-Spam-Status: No, score=-4.868 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XKIObm1xXlRG for ; Thu, 28 Aug 2014 14:08:14 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 909A31A01E2 for ; Thu, 28 Aug 2014 14:08:12 -0700 (PDT) Received: from [128.9.184.208] ([128.9.184.208]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id s7SL7aS3010090 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 28 Aug 2014 14:07:36 -0700 (PDT) Message-ID: <53FF9A1F.2070704@isi.edu> Date: Thu, 28 Aug 2014 14:07:43 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Caitlin Bestler , gorry@erg.abdn.ac.uk References: <8D3D17ACE214DC429325B2B98F3AE712077BC667E3@MX15A.corp.emc.com> <8a1e3d9076291258626ce07f028c00bc.squirrel@www.erg.abdn.ac.uk> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/9UoBadZnn-IdjKLNRV-1_0lU7Sg Cc: "tsvwg@ietf.org" Subject: Re: [tsvwg] Transactional Multicast within Clusters X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Aug 2014 21:08:18 -0000 On 8/28/2014 1:22 PM, Caitlin Bestler wrote: > > On Aug 28, 2014, at 11:56 AM, gorry@erg.abdn.ac.uk > wrote: > >> >> I'm not sure you express the problem in a way I understand as an IP >> multicast person - see some comments in-line, but I stopped half-way >> through because I think this isn't the right place to unpack this. >> >> I think actually a lot of this is a topic related to MBONED/PIM WG - the >> task of controlling L2 membership lies somewhere between these groups. >> However, if your proposal is more linked to direct communication with >> switches, perhaps you should first compare this with GMRP, etc. >> >> A short draft would certainly help a lot to clarify the issues and help >> people discuss. I'd be happy to review a draft, or help find other >> contacts in the IETF who can help (if that is useful). >> >> Gorry >> tsvwg co-chair > > Actually the group that has the most relevant expertise is probably TRILL, > but this is a complete non-fit with the TRILL charter. I don't see this as having any relationship to TRILL; TRILL is about using Internet routing protocols for L2, and is not at all related to multicast or application-layer group membership. Joe